Thursday, 24 February 2011

Server Manager 2008 failing to detect system status

While setting up a new server recently I ran into an unexpected problem. It was quite a straightforward setup, nothing unusual. A Server 2008 R2 os, with SQL, IIS, a couple basic services and the latest updates.

A couple restarts later, I open the server manager, and am greeted with a white page, and the request to check some error logs. Specifically the following branch: Event Viewer -> Applications and Services Logs -> Microsoft -> Windows -> ServerManager -> Operational. Inside, I've found a number of error logs, all of them complaining about the same thing:

Could not discover the state of the system. An unexpected exception was found:
System.Runtime.InteropServices.COMException (0x800F0818): Exception from HRESULT: 0x800F0818

With a system that was just installed the previous day, I could just drop it and start from scratch, but I didn't want to just give up. Plus, I was curious about what exactly was causing the problem. So I decided to dig deeper, and check online what exactly was the problem.

A quick search online, and I was reading a topic on one of the Microsoft forums Server Manager 2008 could not discover state of system, discussing a very similar issue. After a quick read, I learned that the core of the issue was in a failed Windows Update installation, after which one of the packages had a corrupt package manifest.

Unfortunately a simple reinstall of the package doesn't help, so to fix the issue one would have to get his hands dirty, open up the update package file, pluck out the right files, and drop them in the right place. Finding out what exactly has to be done should be relatively easy, if you know what to do.

I'll explain the steps I had to follow, to solve the problem, and hopefully this will save someone's time and help do the same

To fix such a failed update, you will need the download the System Update Readiness Tool from Microsoft KB947821. Once you run it, and it successfully "installs", you can read the log report it creates in C:\Windows\Logs\CBS. The file we're interested in is CheckSUR.log. It might take some time for the app to finish it's report, MS reports that it will usually take less than 15 minutes to run.

Note that you can run this tool multiple times. Each time, it will "install", and create a new log file. The CheckSUR.persist.log contains all previous copies of the log file, so you can see the changes between each test.

My log file contained the following:

Checking System Update Readiness.
Binary Version 6.1.7601.21645
Package Version 11.0
2011-02-24 11:09

Checking Windows Servicing Packages

Checking Package Manifests and Catalogs
(f)	CBS MUM Corrupt	0x00000000	servicing\Packages\Package_for_KB2488113_SP1~31bf3856ad364e35~amd64~~		Expected file name Microsoft-Windows-Foundation-Package~31bf3856ad364e35~amd64~~6.1.7600.16385.mum does not match the actual file name

Checking Package Watchlist

Checking Component Watchlist

Checking Packages

Checking Component Store

Seconds executed: 273
 Found 1 errors
  CBS MUM Corrupt Total count: 1

Unavailable repair files:

(w)	Unable to get system disk properties	0x0000045D	IOCTL_STORAGE_QUERY_PROPERTY	Disk Cache

From this, we can learn that the KB2488113 package has a corrupted manifest, and two files within the package are "unavailable". Not sure why are they unavailable, but the files actually exist in the right folder.

What you'd have to do is download the right KB once again (in my case this is KB2488113, so I've navigated to and downloaded the package for my version of Windows). You'll get a file with .msu extension, and you should change it's extension to .cab. Once I've extracted the archive, I found another .cab inside, containing the package files (I suppose that the file name should be pretty obvious, as in my case it was

Now, there are a couple things we must do. Remember, back in the log file, it was complaining about a corrupt manifest file? The file it was complaining was Package_for_KB2488113_SP1~31bf3856ad364e35~amd64~~ At the bottom of the log file, it was also complaining about some unavailable repair files. Find these "unavailable" files in this folder, and copy them to a separate directory. I also had to copy the "update" files ( and update.mum), which should be renamed to the correct name for this package. In my case, it was Package_for_KB2488113~31bf3856ad364e35~amd64~~

Once I've done this, I got a folder with the following files:


These files have to be copied to %windir%\servicing\packages\, replacing any existing files in the destination dir. Note, that these files will be locked to the SYSTEM user, so you'll have to take ownership, and change the permissions on them, to be able to overwrite them.

With the right files replaced, you should be able to open the Server Manager and see the server roles without any issues. No restart is required. You can run the Update Readiness Tool again, to make sure that the packages are now all valid.