Blog: Patch Management

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



I have been looking for a multi-purpose network monitoring tool for use at several network customer location and came across a light-weight app called SpiceWorks. Its open source and has a number of nice features. Here is a list of some of the most useful ones

  • Schedulable network scans based on domain name or subnet
  • Asset classification based on collected data
  • Software inventory (including MS patches)
  • Basic service/system alerts & monitoring
  • User knowledge base portal w/integrated ticketing system
  • Warranty lookup for monitored assets
  • Antivirus tracking (no AV, outdated defs, versions, etc) for a number of popular packages


On April 8, 2008 Adobe released a Security Bulletin regarding vulnerabilities with various versions of Adobe Flash Player.  In the Security Bulletin they recommend upgrading to the latest version of Adobe Flash Player (at least to version or higher).  However, various reports were published today from security firms and security related websites reminding users about the threats associated with continuing to run earlier versions of Adobe Flash Player.[more]  If you have not already verified your system(s) (or your companies systems) have the "patched" version of Adobe Flash Player, you should do so.  You will need to check for both Microsoft Internet Explorer and FireFox.  The plug-ins are different, so updating in FireFox does not update IE and vice versa.  To read more, visit the links below.



The security vendor Trend Micro announced Thursday that the company's website had been hacked earlier in week.  Mike Sweeny, a Trend Micro spokesman said "We took the pages down overnight Tuesday night - and took corrective action." [more]

On Thursday security vendor McAfee reported that more than 20,000 Web pages have been affected by the attack.  The pages are infected with malicious code that tries to install password-stealing software on the PCs of people who visit the sites.

Researchers are still not sure how the attackers are managing to hack these Web pages, but the pages all seem to use Microsoft's Active Server Page (ASP) technology, which is used by many Web development programs to create dynamic HTML pages.  A software bug in any of those programs is all the attackers need to install their malicious code.  The infected Web pages are not obviously malicious, but the attackers have added a small bit of JavaScript code that redirects visitors' browsers to an invisible attack launched from servers based in China.  The JavaScript attack code hosted on these infected Web sites takes advantage of bugs that have already been patched, so users whose software is up-to-date are not at risk.  However, McAfee warns that some of the exploits are for obscure programs such as ActiveX controls for online games, which users may not think to patch.

For more information visit or