svchost.exe using 100% CPU on Windows XP when scanning for Windows updates against WSUS

I thought I had seen the last of this issue several years ago, but we still have a couple of legacy single core CPU Windows XP boxes knocking around, and last week this problem reared its ugly head once more on a couple of machines. The symptom of this problem is that shortly after login, the automatic updates service runs to check for new updates against WSUS. While this scan occurs if you look in Task Manager the process svchost.exe is consuming 100 % of CPU resources making the machine pretty much unusable. You can verify whether wuauclt (the Windows update client) is the culprit in your case by running Process Explorer, and seeing if wuauclt is running under the svchost process. This issue always used to affect single core machines with relatively small amounts of RAM by todays standards. At the time this issue was fixed in the majority of cases by installing an updated version of the Windows Update agent which can be found here.

Anyway, back to the present, and after releasing a handful of windows updates for XP in the WSUS console a few days ago I found that a couple of legacy XP machines had become unusable after login as svchost.exe was consuming 100% CPU. The client machines would stay like this indefinitely and never seemingly finished their scan for updates against WSUS. Straight away I looked in the C:\Windows\windowsupdate.log to check the client version and to see if anything else unusual was occurring. The update agent was up to date (version 7.4.7600.226) so this didn’t appear to be the old problem.

As the first part of the fix, I ran the WSUS ‘Server Cleanup Wizard’ on the server that the client was checking for updates against. I selected all the options as shown below to make sure the client wasn’t checking for any unecessary or superceded updates.

WSUS Server Cleanup Wizard Options


Secondly, I followed method 1 of this technet tutorial:

1.Click Start, click Run, type cmd in the Open box, and then click OK.

2.At the command prompt, type net stop wuauserv, and then press ENTER.

3.Click Start, click Run, type regedit in the Open box, and then click OK.

4.Locate and then click the following registry subkey:


5.In the details pane of Registry Editor, delete the following registry entries:

  • PingID
  • AccountDomainSid
  • SusClientId
  • SusClientIDValidation

Note Windows Update Agent 3.0 adds the SusClientIDValidation value. This value was released in May 2007. The other registry entries exist in both Windows Update Agent 2.0 and in Windows Update Agent 3.0.

6.Exit Registry Editor.

7.At the command prompt, type net start wuauserv, and then press ENTER.

8.At the command prompt, type wuauclt.exe /resetauthorization /detectnow, and then press ENTER.

9.Wait 10 minutes for a detection cycle to finish. 10.Start the WSUS console to make sure that the clients appear in the WSUS console.

After carrying out the above steps, the XP client machine completed the update scan within a few minutes and the CPU usage returned to normal.

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.


Citrix – The following requested video mode was not available

Recently we received the following error message when accessing Citrix Presentation Server on a few client machines which had had large wide screen monitor upgrades. The application that had been started would also not enter full screen mode.

The following requested video mode was not available: 1920 x 1080 x 24 BPP

The video mode has been set to the following mode: 1847 x 1038 x 24 BPP

Video mode restricted by administrator.

Citrix Error: The following requested video mode was not available

This was due to the fact that not enough memory had been allocated to the graphics for individual client sessions to support the resolution on larger monitors. This can be resolved by modifying the Farm ICA Display settings in the Citrix Access Management Console. Right click on the Farm object in the Citrix Access Management Console and choose ‘Properties’. Then under ‘Server Default’, ICA, click on ‘Display’. Change ‘Maximum memory to use for each sessions’s graphics’ from the default (in my case 5625) to 8192 as shown below:

Changing the 'Maximum memory to use for each session's graphics' setting under Server Default, ICA, Display

After increasing the memory available for each sessions graphics, you should find that Citrix is able to support the higher resolutions OK.

Restrict or filter GAL access for OWA users using MSExchQueryBaseDN in Exchange 2007

When hosting Exchange 2007 mailboxes for use purely with Outlook Web Access (OWA) you may wish to limit access to the Global Address List (GAL), so that logged in users can only see a subset of the contacts in the GAL. This would be particularly relevant in hosting environments where mailboxes may be hosted for multiple companies in the same active directory, and you might want users to only see contact information from users for their company, rather than all companies.

A while ago we had a situation where this was a requirement. In our case there were several groups of users who would only be accessing email through OWA, and only needed contact information for a subset of staff. We were able to use custom address lists and the MSExchQueryBaseDN user attribute to solve this problem.

If you run adsiedit.msc and look at the properties of a user object you can scroll down the list of attributes to find MSExchQueryBaseDN.

The MSExchQueryBaseDn attribute in adsiedit

In order to limit which contacts a particular user or group of users can access, firstly you need to set up a new Address List either using the Exchange Management Console, or Exchange Management Shell. The address list should contain the contacts that you want the user or group of users to be able to view. Please note that you could point the MSExchQueryBaseDN attribute to an Organizational Unit, so it would filter contact information for just the users in that OU, but if you need the flexibilty to include contact information for users from various OUs in active directory, it may be easier to use a custom address list.

Once this is done you need to set the MSExchQueryBaseDN attribute of each of the users who you want to restrict to the distinguished name of the address list you created.


CN=YOUR_RESTRICTED_ADDRESS_LIST,CN=All Address Lists,CN=Address Lists Container,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=YOUR_DOMAIN,DC=local

Where YOUR_RESTRICTED_ADDRESS_LIST is the name of your address list and YOUR_DOMAIN is the name of your domain.

Obviously it would be too time consuming to set this attribute manually for hundreds of users so you could either use ADModify if you want to use a GUI:

Set MSExchQueryBaseDN using ADModify.Net

To reset to the default value using ADModify.Net use a value of ‘null’.

You could also use  to achieve this in Powershell if you would prefer to use the command line. Further details can be found here.

Please note: Using this attribute in Exchange 2010 SP1 may result in undesirable consequences. It has been reported that if this attribute is used you may find that users with the attribute set cannot view the contents of their address list, particularly in Outlook.

Export a list of members from an Active Directory group to a text file

I needed to export a list of all the members in an active directory group today. Here are two methods which work well. The first example uses the net group command. In both examples ‘Group Name’ is the name of the group that you want to export the member list for, and memberlist.txt is the name of the output file.

net group “Group Name” /domain > memberlist.txt

The second example uses dsquery and dsget, which will return the full distinguished names of the user objects that are members of the group. This could be useful if you also need to know which organizational unit the members accounts reside in.

dsquery group -name “Group Name” | dsget group -members > memberlist.txt

Force KCC (Knowledge Consistency Checker) to run on a domain controller

Sometimes after demoting domain controllers you may be left with inconsistent NTDS connection objects in Active directory. In my case there was an NTDS connection object listed under one of the domain controllers at our central site which referenced a recently demoted domain controller at a remote site. I needed an NTDS connection object pointing pointing to the newly installed DC at the remote site instead. To fix this i simply deleted the incorrect NTDS connection object in the ‘Sites and Services’ console, from the central site domain controller, and then forced KCC to run on the same domain controller by running:

repadmin /kcc

This forces the domain controller that you run the command on to check its inbound replication topology immediately and generate any missing connections. After running this command a new NTDS connection object was generated from the new DC at the remote site. This can either be verified by checking under the Domain Controllers NTDS Settings, in the ‘Sites and Services’ Console or by running:

repadmin /showrepl