Today, I was checking on some things in our virtual server host environment when one of the servers displayed the following when clicking on the “Roles” module in Server Manager.
“No signature was present in the subject. (Exception from HRESULT: 0x800B0100)”
This was not a happy thing to find as the virtual host in question is a production server with virtual machines running. The last thing I wanted to do in the middle of the day was to reboot this server.
As the error message suggests, I looked in an area of the Server 2008 Event Logs that I’ve never been before. This event log gets noted as “Microsoft-Windows-ServerManager/Operational”. The error event ID I had in this log was 1601.
A little BING-ing and I happened upon the following article - http://dwjack.spaces.live.com/blog/cns!3EE7D7517C0BC5AE!250.entry. This provides a great run down of the steps involved to resolve this issue. To my surprise, the result of this did NOT require a reboot of the server to implement the changes.
However, I found that the documentation here was a little thin in just the right place. Part of the solution for this “no signature” error is to copy the missing files from a Windows Update into the C:\windows\servicing\Packages directory. The way to do that is to take ownership of the Packages folder and add yourself with full control. However, the initial owner of the folder is TrustedInstaller.
Microsoft Starting with Windows Vista and Server 2008 Windows incorporates Mandatory Integrity Control, which adds Integrity Levels (IL) to processes running in a login session. MIC restricts the access permissions of applications that are running under the same user account and which may be less trustworthy. Five integrity levels are defined: Low, Medium, High, System, and Trusted Installer.
When I went back to add TrustedInstaller as the owner, I was not able to find the account. Turns out that the account is an NT SERVICE. I followed the steps in this article to restore ownership to correct account, http://www.vistax64.com/tutorials/159360-trustedinstaller-restore-owner.html. When specifying the account, be sure to change the “Locations…” to the local machine.