MSI Error “The computer must be trusted for delega

Question

We have an MSI based installer that recently stopped working on a Windows 2008 R2 environment. The installer is copied over to the target computer using the \\servername\c$\ admin UNC shares and then is remotely executed using the create method on the WMI Win32_Process class. The remote execution now fails with the following error message in the Event Viewer:

The description for Event ID 10837 from source MsiInstaller cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

If the event originated on another computer, the display information had to be saved with the event.

The following information was included with the event:

Product: OUR PRODUCT NAME -- The requested operation cannot be completed. The computer must be trusted for delegation and the current user account must be configured to allow delegation.

After searching it looks like this is caused by a recently released security patch for Windows Installer. When I uninstall KB2918614 the installer starts working again, and if I reinstall KB2918614 the MSI stops working again.

The error message indicates that to solve the issue we would have to have a Domain Administrator edit the target computer using Active Directory Users and Computers to allow delegation, however the MSI is NOT using any remote resources, so I don't see why this is required. The same MSI and remote execution process works fine on Windows Server 2012, so I wonder if this is an issue with the patch for 2008 R2.

Are there any other ways to get around this error message?

UPDATE: This doesnt appear to be an issue with the WMI remote execution, as it also occurs when we try to install the MSI remotely using Powershell, WinRM, and the Invoke-Commmand -ComputerName TargetComputer ... cmdlet. There is a change in the way the Windows Installer on 2008 R2 works after installing KB2918614 that now prevents the custom action from completing it's task.

Answer 1

I have the same problem. MSIs failed to be installed with Invoke-Command PoSH. I've found that if I install any MSI on the server locally under the same account which is used for Invoke-Command the issue is fixed and Invoke-Command starts to work as usual.

Answer 2

I had this as well on different servers. After a few hours of digging I discovered that they could not reach the domain controllers. Check your DNS settings and ensure they can reach the AD. After fixing this this error disappeared.

Answer 3

This is to be to do with the SourceHash{product-code} files under \windows\installer directory. This file can be opened with Orca you can read the contents. It contains a file name, hash algorithm specifier, and hash. On Windows 2k3 this hash is a base64ed sha256 hash with the last byte changed.

If you rename the SourceHash file for your product out of the way, I found the upgrade worked and after that a new SourceHash file is generated. You can then diff the two source hash files. In the case I am investigating, when you diff the two files only the hash listed for the original msi is different. After a successful upgrade the hash of the new msi listed in the source hash file will match that of installation source. The broken sourcehash file was obviously generated from a modified/different source MSI, although I have as yet been unable to identify which.