我们有一个基于MSI的安装程序,最近停止在Windows 2008 R2环境中工作 . 使用 \\servername\c$\
admin UNC共享将安装程序复制到目标计算机,然后使用WMI Win32_Process class上的create方法远程执行 . 远程执行现在失败,并在事件查看器中显示以下错误消息:
找不到来自源MsiInstaller的事件ID 10837的描述 . 引发此事件的组件未安装在本地计算机上,或者安装已损坏 . 您可以在本地计算机上安装或修复该组件 . 如果事件源自另一台计算机,则必须随事件一起保存显示信息 . 事件中包含以下信息:产品:我们的产品名称 - 无法完成请求的操作 . 必须信任计算机以进行委派,并且必须将当前用户帐户配置为允许委派 .
搜索后看起来这是由最近发布的security patch for Windows Installer引起的 . 当我卸载KB2918614时,安装程序再次开始工作,如果我重新安装KB2918614,MSI将再次停止工作 .
错误消息表明,要解决此问题,我们必须让域管理员使用Active Directory Users and Computers编辑目标计算机以允许委派,但MSI不使用任何远程资源,因此我不明白为什么这是必需的 . 相同的MSI和远程执行过程在Windows Server 2012上运行正常,所以我想知道这是否是2008 R2补丁的问题 .
有没有其他方法来解决此错误消息?
UPDATE :这似乎不是WMI远程执行的问题,因为当我们尝试使用Powershell,WinRM和 Invoke-Commmand -ComputerName TargetComputer ...
cmdlet远程安装MSI时也会出现这种情况 . 安装KB2918614后,2008 R2上的Windows Installer的工作方式发生了变化,现在阻止自定义操作完成它的任务 .
9 回答
据我所知,
对于KB2918614,MS显然已尝试在Windows Installer服务中修复某些内容 .
新东西:
他们正在%windir%\ Windows \ Installer下按名称"SourceHash"创建文件 . 这适用于机器上安装的每个产品(已安装KB2918614) .
SECREPAIR-他们正在为给定的MSI计算'Stored Hash Value'和'Current Hash' .
错误:
并且,在这个比较中,出于某种原因,这些不匹配! (在MSI详细日志中找到这些) .
一旦失败,它会查找机器策略值'AlwaysInstallElevated'用户策略值'AlwaysInstallElevated'
现在,如果您正在运行静默安装“qn”,则会抛出此错误:MSI_LUA:已禁用静默安装的提升提示 .
删除msiexec- ex . ,"qr"或"qb"的静默安装cmdline选项将抛出UAC提示符 . (这很可能不是预期的行为) .
其他信息:
我的MSI通过bootstrapper exe进行了ivk . 但是,这并不重要 . 即使通过cmd行手动调用msiexec的行为也是一样的 .
任何输入/解决方案,任何人?
这是来自MS Enterprise支持人员的话 .
显然他们不知道有任何解决方法 . 至少截至目前 . 他们只是说这个KB是为了修复安全漏洞 . 我不明白这是什么类型的安全修复程序 - 允许在没有UAC提示的情况下进行全新安装,但仅为升级引发UAC提示 .
Workaround 1: 分发哈希 .
在一台计算机中捕获哈希文件*并将其分发到其他计算机 . 散列文件在“%windir%\ installer”目录下创建 . 命名约定如下:“SourceHash *仅当在计算机上安装了KB2918614安装产品时才会创建此文件 . 此目录已隐藏 . 使用“以管理员身份运行”打开cmd提示符 . 遍历此路径并使用“资源管理器”打开文件夹 . 命令 . [我无法使用此方法解决问题 - 可能是因为访问此目录需要Windows安装程序本身可能没有的管理员权限]
Workaround 2: 白名单 .
只有当您信任该应用程序时,它始终经过数字签名且不包含任何恶意内容(即使将来) .
Step 1: Enable Whitelisting
在Key“HKLM \ SOFTWARE \ Policies \ Microsoft \ Windows \ Installer”下,创建一个DWORD:“SecureRepairPolicy”并将其Value设置为2 .
Step 2: Add the application to the whitelist 在“HKLM \ SOFTWARE \ Policies \ Microsoft \ Windows \ Installer”下创建一个新密钥“SecureRepairWhitelist”,并使用产品的产品代码(包括花括号{})创建StringValues .
......遗憾的是,这两种解决方法都需要管理员权限!
这是我使用微软网站上提到的注册表白名单工作的自动方式 .
现在,在我对远程计算机运行安装命令之前,我查看MSI并使用Get-ProductCodeFromMSI提取产品代码,然后使用Add-GuidToWhitelist将每个GUID添加到该计算机上的列表中 . 这是一个例子:
在此之前,可以分别使用Test-SecureRepairPolicy和Repair-SecureRepairPolicy对每台计算机进行测试和修复以获得解决方法 .
Get-ProductCodeFromMSI将要求引用的DLL放在某处 and unblocked - 可以从Wix工具集中检索此DLL .
我引用的函数代码如下:
我也遇到了这个问题 . 我有PowerShell脚本在远程机器上安装MSI(使用Invoke-Command cmdlet并提供凭证和脚本),但突然无法安装MSI,我想也是从这个安全补丁 .
使用域帐户(从远程桌面)在目标计算机上手动运行MSI安装文件后,powershell脚本突然可以使用域帐户运行MSI安装,但如果我使用目标计算机本地管理员帐户仍然无法安装 .
我更愿意将其添加为评论,但我也不愿意也知道这一点 . 谢谢 .
这与\ windows \ installer目录下的SourceHash 文件有关 . 这个文件可以用Orca打开,你可以阅读内容 . 它包含文件名,哈希算法说明符和哈希 . 在Windows 2k3上,此哈希是base64ed sha256哈希,最后一个字节已更改 .
如果你 rename the SourceHash file for your product out of the way ,我发现升级工作,之后生成一个新的SourceHash文件 . 然后,您可以区分两个源哈希文件 . 在我正在调查的情况下,当你对两个文件进行区分时,只有原始msi列出的哈希值不同 . 成功升级后,源哈希文件中列出的新msi的哈希值将与安装源的哈希值相匹配 . 破碎的sourcehash文件显然是从修改后的/不同的源MSI生成的,尽管我还是无法识别哪个 .
我也有同样的问题 . 无法使用Invoke-Command PoSH安装MSI . 我发现,如果我在服务器本地服务器上安装任何MSI,用于Invoke-Command的同一帐户,问题就解决了,Invoke-Command开始像往常一样工作 .
Microsoft的回复:此安全更新可解决Microsoft Windows中一个秘密披露的漏洞 . 如果攻击者运行试图修复以前安装的应用程序的特制应用程序,则该漏洞可能允许特权提升 . 攻击者必须拥有有效的登录凭据,并且能够在本地登录才能利用此漏洞 .
如果您在修复应用程序时遇到问题,请解决此问题:
卸载应用程序并在安装了安全更新的情况下重新安装 . (使用安全更新生成的sourcehash文件)
手动将sourcehash文件复制到c:\ windows \ installer文件夹 . 由于sourcehash文件是基于应用程序文件生成的,因此计算机A上生成的sourcehash文件可以在计算机B上使用 .
http://happysccm.com/kb2918614-uac-gate/ - 要卸载它的命令 .
我在不同的服务器上也有这个 . 经过几个小时的挖掘后,我发现他们无法访问域控制器 . 检查您的DNS设置,确保他们可以访问AD . 修好后,此错误消失了 .
如果您正在通过psexec执行,只需添加-s参数也可以解决错误 . 然后它作为远程系统用户运行,不需要UAC .