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