“Failure configuring Windows updates. Reverting changes” on a Lenovo Laptop

I recently had to apply Windows updates to a new Lenovo laptop running Windows 8. There were about 50 or so updates to apply, but each time I tried to install them I received the following error message on reboot:

“Failure configuring Windows Updates. Reverting Changes”

After the reboot had completed, I examined the update history and found that none of the updates had installed and all were marked as failed. I did a bit of digging, and in the end it turned out that this is a common problem with Lenovo laptops and was caused by a service called the ‘Nalpeiron Licensing Service’. I am not sure why this is pre installed, but it appears that it is not an essential service, so I simply opened the services console (services.msc) and stopped and then disabled this service. After completing this action Windows updates installed without error.

Windows 7 SP1 installation fails with error 0x800f0818

I came across a peculiar problem today trying to install SP1 on a Windows 7 laptop. Whenever I ran the Windows 7 SP1 installer or tried to update to SP1 using Windows Update the installation failed with a cryptic error ‘0x800f0818‘. I tried various things such as running sfc /scannow and installing the Windows 7 System Readiness Tool (64 bit in my case), but neither reported problems.

After a bit of digging I found an entry in the CheckSUR log file found in C:\Windows\Logs\CBS which seemed to be related. In this case a .Net Framework update had failed to install a few times and this particular update was referenced in the log file:

Checking Windows Servicing Packages

Checking Package Manifests and Catalogs (f) CBS MUM Corrupt 0x00000000 servicing\Packages\Package_for_KB979916_RTM~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

Summary: Seconds executed: 485  Found 1 errors   CBS MUM Corrupt Total count: 1

Unavailable repair files:  servicing\packages\Package_for_KB979916_RTM~31bf3856ad364e35~amd64~~  servicing\packages\Package_for_KB979916_RTM~31bf3856ad364e35~amd64~~

To fix the problem I had to remove entries for the corrupt package from the registry (IMPORTANT: taking a backup first) from:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages

The specific entries are shown below. There are two, the highlighted entry, and the one beneath:

Deleting corrupt package entries from the registry


After deleting the two entries I reran Windows Update checking for updates and this package was redownloaded and then installed without issue. After this the service pack 1 installation proceeded without error. You may find that the specific update referenced in your CheckSUR log is different to the one mentioned here, but the method is the same.

Generate a new SID on Windows Server 2008 and Windows 7

With the NewSID tool no longer supported by Microsoft for more recent versions of Windows, you may find yourself in a situation where you need to generate a new SID on a Windows Server 2008 or Windows 7 computer, and wonder which tool you need to use. I myself have run across an issue in the past in our development environment where duplicate SIDs caused a problem. Care needs to be taken when cloning Windows virtual machines, particularly if they will later be used as domain controllers.

In order to avoid any issues like this, the new preferred method to set a new SID on a Windows machine is to use Sysprep. Before running Sysprep, you may wish to verify the current SID on the sytem that you wish to modify. This can easily be done by running the psgetsid utility, which is part of the excellent Pstools developed by Mark Russinovich. The output of the psgetsid command can be seen below, showing the current machine SID:

Output of psgetsid before running Sysprep on Windows Server 2008 R2

 Next you can sysprep by running the following command:


Running Sysprep
On the Sysprep, screen make sure that you tick the ‘Generalize’ tick box as shown below:

Choose settings for the System Preparation Tool

 The Sysprep process will take a few minutes to run, and will automatically reboot the system if you chose to do so. On reboot, the following screen will be displayed. Click ‘Next’ to continue:


Click next to continue the Sysprep process

 After the sysprep process is complete, you can run psgetsid again to verify that a new SID has been generated for this computer:

Output of psgetsid after running Sysprep on Windows Server 2008 R2



Could not load the file or assembly Microsoft.Web.Administration Version= when running the Exchange Management Console

Earlier today I received the following error message while using the Exchange 2007 32bit Admin tools on a Windows 7 client computer, when trying to access information under ‘Server Configuration’ in the Exchange Management Console:


“Could not load file or assembly ‘Microsoft.Web.Administration, Version, Culture=neutral,PublicKeyToken=31bf3856ad364e35’ or one of its dependencies. The system cannot find the file specified.”

Error message Could not load file or assembly Microsoft.Web.Administration


To correct this error I opened the ‘Turn Windows features on or off’ screen and enabled the Internet Information Services (IIS) Web Management Tools, as shown below:


Enabling the IIS Web Management Tools in Windows 7


I then restarted the Exchange Management Console and the desired functionality was restored.

Set deadline for windows update installation in WSUS

In certain circumstances, when using WSUS (Windows Server Update Services) in your environment, you may wish to deploy a critical Windows update sooner than your scheduled installation window. Personally, I would excercise extreme caution using this setting due to the gotchas outlined at the end of this post.  However, this can easily be achieved by setting a deadline for installation when you approve the update or updates. In the WSUS console simply select the update or updates, and then right click them and choose ‘Approve …’ as shown.

Approving an update in the WSUS console

Once the ‘Approve Updates’ screen opens, choose which group of computers you want to approve the update for. In this case I have chosen ‘All Computers’, and then  ‘Approved for Install’. Next right click the ‘All Computers’ group again and choose ‘Deadline’ and then ‘Custom’ as shown:

Set a custom deadline for installation of an update in the WSUS console

The ‘Choose Deadline’ screen opens. Choose the date and time that you want the update or updates to be installed at, as shown:

Choose the date and time for your deadline

Thats it, your update will now be installed at the time that you have set. There are a couple gotchas using this setting that it is worth being aware of. Firstly if the update with the deadline requires a restart, the computer will reboot after installation regardless of what the user is doing at the time. It is therefore probably best to avoid deadline times in the middle of the working day when users may suddenly find their computers reboot with little or no warning causing them to lose work. Secondly, a deadline will override the ‘No auto-restart with logged on users for scheduled automatic updates installations’ Group Policy setting, so again be careful if you have this GPO setting enabled, as you may not expect your computers to reboot, but they will in this case.



Enable a KMS Host for Windows 7 and Office 2010 Volume Activation

In order to simplify licensing and activation for Windows clients and servers on you network, you can set up a KMS host to automatically activate these machine with Microsoft, rather than having to install license keys individually on machines.

There are two types of license keys with Windows Vista, Windows 7, and Windows Server 2008, which are KMS and MAK. MAK (Multiple Activation Keys) are more like your traditional license keys, which you can use to manually license a product. Once the key is installed, that product stays licensed on that machine indefinitely. If you have multiple machines that you want to license using MAK keys in one go, you can use the Volume Activation Management Tool (VAMT 2.0).

The second option is to use KMS (Key Management Service). When using KMS you set up a server on the network to act as a KMS Host. This host collects licensing information information about client computers on the network, and then activates them in bulk with Microsoft’s activation servers, at regular intervals.

When you install Windows Vista, Windows 7, or Windows Server 2008 from Volume Licensing media, these machines will be installed as KMS clients by default. This means a fresh installation using volume licensing media will install a KMS license key on the client during the installation. Once the machine is installed and joined to your domain, if a KMS host is available on the network the new machine will report in to the KMS host, and the KMS host will in turn activate the client. There is a caveat to this. You need to have at least 25 KMS clients (for Windows 7 and Vista), or 5 KMS Clients (With Windows Server 2008) on your network in order for the KMS host to activate these machines with Microsoft. So in summary, for small deployments of less than 25 computers you will need to use MAK keys, but for larger  deployments, you can take advantage of the simplified activation process, by using a KMS host on your network.

So how do we set up a KMS host? Actually the process is pretty simple, especially if you set up a Windows Server 2008 R2 machine as your KMS host. You will need to obtain the ‘Server 2008 R2 Std and Ent Volume:CSVLK (KMS_B)’ KMS license key from the Microsoft Volume Licensing Service Center. To be sure that I was using the correct key, I verified it using the product key verify function using VAMT 2.0. The good thing about using this key, and indeed setting up your KMS host on a Server 2008 R2 computer is the fact that it will license and activate Windows Vista, Windows 7, Windows Server 2008 and Windows Server 2008 R2 KMS clients! Once you have the key handy you need to run up a command prompt using elevated privileges on the host that you want to set up as the KMS host.

At the command prompt type in the following to install the KMS_B key on your KMS host, where YOUR_KMS_B_LICENSE_KEY is the license key that you obtained from the Microsoft Volume Licensing Center:

slmgr.vbs /ipk YOUR_KMS_B_LICENSE_KEY

You should get a message like the following:

Installing the KMS Host license key

Next you need to activate the new license key by typing:

slmgr.vbs /ato

After a few seconds you should get a confirmation message like the following:

Successful activation of the KMS Host key

Next there are a few other checks you can make to ensure that your KMS host is enabled successfully. Firstly run the following command and review the output:

slmgr.vbs /dlv

Displaying detailed licensing information about your KMS host

You can use the output from this command to see the number of licensing requests that have been received by the KMS host. In the example above a single request has been received, and the current count is 1. As mentioned earlier in order for the KMS host to activate Windows 7 clients, the count must reach 25 i.e. 25 computers on the network must all have sent license requests to the KMS host. The command slmgr.vbs /dlv is an easy way to keep track of the progress of the current count in the early stages of your KMS deployment. If you want to obtain this infomation from a remote client machine you can use the slmgr.vbs KMS_HOST_NAME /dlv, where the KMS_HOST_NAME is the name of your KMS host.

A second useful check after enabling your KMS host is to make sure that the relevant DNS SRV record has been created, in order for KMS clients to discover the location of your KMS host. In the DNS console on one of your DNS servers look for a record called _VLMCS._tcp.YOURDOMAINNAME


Finally, check that tcp port 1688 is enabled incoming on your firewall in the domain profile on the KMS host to allow clients to make licensing requests.

Verify the Key Management Service (TCP-in) rule is enabled

After that your KMS host should happily pick up licensing requests for Windows Vista, 7, and Server 2008. In the early stages of our deployment we had set up a few clients using MAK licensing keys, until such time as we had 25 computers available on the network. Once we had enough Windows 7 machines available we converted them back to KMS clients, using the default KMS client keys listed here, and the VAMT 2.0 to install these keys on the client computers.

Next up, setting up the Office 2010 KMS host. In our environment it made sense to use the same server that was already acting as our Windows KMS host. Firstly we downloaded the Microsoft Office 2010 KMS Host License Pack. On Windows server 2003 other steps are required to install this (outlined in the system requirements), but on Windows Server 2008 R2, just run the downloaded KeyManagementServiceHost.exe file.

Accept the license agreement, and the file will run. You will receive confirmation that the license pack has installed correctly. Next you will be asked to enter your Office 2010 KMS Host license key, which you can obtain from the Volume Licensing Service Center. Enter your key and click OK, and you will receive the following confirmation:

Office 2010 KMS host activation success message

You can verify that the computer is activated, as a KMS host for Office 2010 by running the following command :

slmgr.vbs /dlv bfe7a195-4f8f-4f0b-a622-cf13c7d16864

The long code shown in the command is the Office 2010 activation ID. Running this command will give you a similar summary to the slmgr.vbs /dlv command for Windows Clients. It will show you the current count for Office 2010 KMS client installations as well as the number of license requests. With Office 2010 the current count must reach 5 before the KMS host will activate your Office 2010 installations i.e. there must be at least 5 computers running Office 2010 with a KMS client product key installed before the KMS host will activate these clients. More information on Deploying Office 2010 using KMS can be found here.

As a final note, you will notice in the above example that the output of the slmgr.vbs file is directed to a popup dialog box. If you would prefer to direct the output of the slmgr.vbs script to the command window that you are working in you can use cscript to run slmgr.vbs. To do this firstly navigate to the C:\Windows\System32 folder using the command:

cd C:\Windows\System32

You can then run slmgr.vbs using cscript as shown below:

cscript slmgr.vbs /dlv

As you can see below, the output will display in the command window rather than a pop up dialog box. I mention this for completeness as I have seen slmgr.vbs run both ways. It doesn’t really matter which you choose.

Running slmgr.vbs using cscript