Blog: WSUS

While making sure a server was being automatically patched every month through Windows Updates, I logged on and made the necessary changes to get the server into WSUS, but then I wanted to verify that this server would install and reboot automatically. Opening the Group Policy Management Console, I was greeted with "The Network Name could not be found."

Troubleshooting this message, I found that if I connected to the other domain controller, I could load the GPMC without any issues. Furthermore, the DC I originally attempted work on was reporting the following error:

Event Type:       Error
Event Source:     NtFrs
Event Category:   None
Event ID:         13568
Description:      The File Replication Service has detected that the replica set "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)" is in JRNL_WRAP_ERROR.

Further troubleshooting showed that this DC didn't seem to have any replicated data from the other domain controller. Fortunately, this same event had a resolution in the log as well.

Setting the "Enable Journal Wrap Automatic Restore" registry parameter to 1 will cause the following recovery steps to be taken to automatically recover from this error state.

1. At the first poll, which will occur in 5 minutes, this computer will be deleted from the replica set. If you do not want to wait 5 minutes, then run "net stop ntfrs" followed by "net start ntfrs" to restart the File Replication Service.
2. At the poll following the deletion this computer will be re-added to the replica set. The re-addition will trigger a full tree sync for the replica set.

WARNING: During the recovery process data in the replica tree may be unavailable. You should reset the registry parameter described above to 0 to prevent automatic recovery from making the data unexpectedly unavailable if this error condition occurs again.

To change this registry parameter, run regedit.

Click on Start, Run and type regedit.
Expand HKEY_LOCAL_MACHINE.
Click down the key path:
   "System\CurrentControlSet\Services\NtFrs\Parameters"
Double click on the value name
   "Enable Journal Wrap Automatic Restore"
and update the value.

If the value name is not present you may add it with the New->DWORD Value function under the Edit Menu item. Type the value name exactly as shown above.

After running through the steps listed above, everything synced up like it was supposed to and the GPMC started working on the original DC.

We needed to clear disk space on a hard drive containing WSUS and other applications.  WSUS was taking up about 40 GB of the 50GB drive. 

WSUS has a cleanup wizard you can use to remove unneeded and superseded updates, but when we ran it only a few megabytes worth of data was cleaned.  The trick to clean up a lot of disk space and remove superseded updates[more] is to filter your view to see all the approved updates in WSUS, then select the approved updates marked as superseded (can be in the hundreds), and decline these updates.  The next time the cleanup wizard is run, it will remove the unneeded install files.

It appears, by default, the cleanup wizard does not touch approved superseded updates when it runs; however, by declining these superseded updates, we were able to remove over 17GB of unneeded installation files.

I was recently assigned a task for one of our customers in West Texas to get their servers checking in with WSUS correctly.  After talking to a coworker, I found out that since we deploy every virtual machine from a template that has the OS already installed on it.  Each virtual machine deployed will have the same “SusClientID” for WSUS that the template has.  Here are several steps that you can go through in order to issue each machine a new “SusClientID”: [more]

• Stop the Windows Update service “net stop wuauserv”
• Delete “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\ SusClientId”
• Start the Windows Update service “net start wuauserv”
• In a command prompt, run “wuauclt /detectnow”

Following those steps will recreate the string and that system should begin reporting in with a different SusClientID.

I had an issue where wsus on a Windows SBS 2008 system was saying it was synchronizing successfully, but it wasn't downloading updates. All you would get was a message in the event logs from Windows Server Update Services (event id 10032) saying that "The server is failing to download some updates". Clients would show that they needed updates through the WSUS console and via the SBS Console, but the updates would never show up on the server for installation. In the local client WindowsUpdate.log file you would see something similar to the following [more]

2010-10-12  10:39:45:574  784  1a20 PT       +++++++++++  PT: Synchronizing server updates  +++++++++++
2010-10-12  10:39:45:574  784  1a20 PT       + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://...
2010-10-12  10:39:49:011  784  1a20 PT       +++++++++++  PT: Synchronizing extended update info  +++++++++++
2010-10-12  10:39:49:011  784  1a20 PT       + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://...
2010-10-12  10:39:52:433  784  1a20 Agent  * Found 0 updates and 57 categories in search; evaluated appl. rules of 643 out of 1075 deployed entities

So why would the WSUS server recognize the server needed updates and the client not recognize and download them? Further investigation uncovered the fact that the WSUS Content Repository was nearly empty. Total size of the repository was less than 100 MB. Obviously, none of the patch data had been downloaded.

So why was the sync successful? Moving on, after more investigation, I discovered that the ISA server was blocking what appeared to be anonymous web traffic from the SBS server even though there was a access rule set to allow all http, https, and ftp traffic from the SBS server. So, skipping to the solution. First, ISA 2004 has a problem with BITS 7.0 that is used in Windows 2008 and Windows 7. Because the initial synchronization from WSUS ONLY downloads metadata, ISA was letting that out and it would show success in the consoles. Then WSUS turns over processing and downloading of the actual patch files (.cabs, etc.) to BITS. ISA was blocking BITS background download processing so what we had was metadata for the updates, but no updates. WSUS knew the servers needed the updates, but the servers had nothing to download because the actual content for the updates wasn’t there. The fix is to change the processing of update downloads using BITS from a background to a foreground process. ISA seems to allow that just fine.

Do it by running the following query against the WSUS database. The connection can be made via SQL Management Studio Express in most cases…you are just looking to run the query against the SUSDB database.

update tbConfigurationC set BitsDownloadPriorityForeground=1

If you are using Windows 2008 with the Microsoft Internal Database (as SBS 2008 does), this proves to be a little more challenging because you have to connect with SQ Management Studio Express using named pipes instead of TCP/IP. Connect using named pipes by using this as the server

\\.\pipe\mssql$microsoft##ssee\sql\query

I ran into a very interesting 32/64-bit problem the other day that looks to me like Microsoft has goofed. The issue involved installing the x64 version of WSUS on Windows 2008. In Windows 2008, WSUS is now a feature and can be installed without a download.  During setup of one of our new customers, WSUS was installed on an x64 Windows 2008 server that was currently hosting some .NET web services in IIS. After the install of WSUS, the web services would return a 500 error for every request. The error page noted a problem with DynamicCompressionLibrary. After much digging, the problem was caused by installing the x64 version of WSUS alongside x86 web applications in IIS. [more]

When WSUS is installed, it installs a dynamic compression library called suscomp.dll globally in IIS. This compression library is used to compress updates before they are streamed down to clients via BITS. However, due the inherited nature of .NET configuration (web apps inherit global settings in IIS), these .NET web services were looking for the x86 version of the suscomp.dll (search path is by default at c:\windows\SYSWOW64\) which WSUS DOES NOT install. It installs the x64 version (default path at c:\windows\system32\). Without a matching suscomp.dll compression library, the inheritance chain is broken, and you will get 500 internal server errors. This could all be avoided if Microsoft would just include the x86 version of suscomp.dll in the install of x64 WSUS. The fix is to find an x86 version of suscomp.dll (from another install of WSUS) and copy it to c:\windows \SYSWOW64\ and do and iisreset. Thanks Microsoft!

Imaged clients with a duplicate WSUS Client ID will only appear once in the WSUS Admin Console. Each auto update client must have a unique id which is created for each individual install. The WSUS admin console will only display one client for each unique ID. If you have multiple clients created from one image which are sharing the same ID, only one will appear in the WSUS admin console. All clients will check in and download updates, but only one will appear and display status in the WSUS admin console. Even if it the machine were imaged the proper way with SYSPREP, with a new Name and SID, the WSUS Client ID is not being stripped. In cases where clients are not checking in, and they were created from images, the following steps will reset the existing duplicative client IDs. [more] 

1. Run regedit and go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate
2. Delete the PingID, SUSClientID and the AccountDomainSID values
3. Stop and start the Wuauserv Service
4. From the command prompt run: wuauclt /resetauthorization /detectnow

Or you can create a batch file using the sample below:

rem Fixes problem with client machines not showing up on the server due to imaging method

reg delete HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate /v AccountDomainSid /f
reg delete HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate /v PingID /f
reg delete HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate /v SusClientId /f
cls
@echo Triggering detection after resetting WSUS client identity
net stop wuauserv
net start wuauserv
wuauclt /resetauthorization /detectnow

After a clean install of WSUS 3.0sp1 (including installing several pre-reqs) the application log started getting 'selfupdate tree not working' errors.  I searched the web and found a KB article (http://support.microsoft.com/kb/920659) as well as many forum postings describing similar problems.  Many users think there is a bug in the install.  However, Microsoft does not confirm this.  The error condition can take many forms.  In my situation, I was using the default IIS website.  The 'selfupdate' virtual folder was not created, so I created it, mapping to the actual folder, and then corrected permissions for the local IUSR acct. After restarting the website, I immediately got a 'selfupdate' success entry in the log and PCs started checking in.

When approving new updates for WSUS recently, the server I was working on ran completely out of space on its drive were the WSUS content folders were stored and this caused WSUS to crash. There is a utility located in WSUS’s ./Tools folder named WSUSUTIL.EXE. This utility can be used for many different WSUS tasks such as copying the WSUS content folders to a new location. The syntax for this is:

wsusutil movecontent contentpath logfile

contentpath = The new root for content files. This must exist ahead of time
logfile = The path and file name of the log file to create

Despite the name of the command, this does not actually “move” the content folder. It only copies the files and redirects WSUS to begin using this new folder instead. You will still need to clean up the old path. [more]

A full list of switches and commands can be found via TechNet: http://technet.microsoft.com/en-us/library/cc720466.aspx

We recently noticed a situation where our clients systems were not getting Daylight Savings Time (DST) or Windows Malicious Software Removal Tool updates. After researching I found that Microsoft classifies some updates as Update Rollups in WSUS.

• Cumulative Security Updates for ActiveX Killbits
• Updates for Intelligent Message Filter for Exchange
• Daylight Savings Time updates
• Windows Malicious Software Removal Tool

So, you must  select Update Rollups in order to have them available in WSUS.  For any given product or product family, updates could also be available among multiple classifications (for example, Windows XP family Critical Updates and Security Updates).

The following table lists examples of update classifications: [more]