Downloading Drivers into WSUS (bad idea)

WSUS deployments containing master/replica servers synchronize patch updates, computer objects, and binaries internally between WSUS servers. When you configure WSUS, you have an option to specify which update categories should be downloaded from Microsoft – service packs, rollups, updates, etc. Among them is “drivers” category, which is mostly the subject of this write-up.

If your environment contains more than one WSUS server, do NOT download drivers into your solution.

As this Microsoft post explains, a large number of updates will be showing in WSUS 3.0 if you include drivers. The reason for this is that drivers have to be defined many times in WSUS metadata, once per each unique hardware ID to which a particular driver may apply. This results in drivers for Realtek AC’97 sound chips and ATI video cards to be listed hundreds if not thousands of times.

A reasonably sized WSUS system that is configured to pull updates for about 2/3rds of Microsoft products serviced through Windows Update, is expected to download approximately 6,000-7,000 various update definitions. When you add driver updates, that number blows up to 26,000+, which means that driver updates add roughly 20,000 definitions to the metadata database.

That database blows up to 3 GB, and that EXCLUDES actual binary downloads of the updates themselves; updates for just the English localization could go past 25 GB mark depending on which Microsoft products and which update categories you selected for download.

What happens next is that your incredibly bloated WSUS metadata database starts to replicate through the WSUS infrastructure, and mostly works fine – at least initially. Then, about 1-2 weeks into the project, you start noticing occasional sync failures (timeouts). You start troubleshooting them and run through the WSUS Cleanup Wizard and database index defragmentation tasks outlined here, and initially that seems to help.

Give it another 1-2 weeks and internal sync between replica WSUS server and master WSUS server stops entirely. It kind of works, and shows that product updates and expirations are flowing through to the replicas, but rollups of reports and other information does not seem to be replicating properly to the master and generally speaking all confidence is lost in the WSUS platform.

Solution?

  1. First step is to select ALL updates of Driver classification and expressly DECLINE them in WSUS console on the master server. Regrettably, that simply removes some overhead during patch detection between clients and WSUS servers; it does not remove Drivers from the metadata database and will not fix sync errors
  2. Second step is to defragment indexes and run WSUS Cleanup Wizard on all WSUS servers, starting with the replica servers. See this article for info.
  3. Try syncing replicas with the master now; if it works and does not break down again in a week, problem is solved.

However, chances are that it won’t work, or will break down again in a week.

Officially, there does not seem to be a way to delete these drivers from the metadata physically. The only solution here is a full rebuild of entire WSUS structure; basically, start with a blank WSUS database, re-download metadata sans the drivers… You may save some bandwidth by re-importing WSUS binary updates using wsusutil.exe.

Note, that the master WSUS server does not seem to be affected by this issue, and so if driver updates are critical to your network, you may want to consider limiting the hierarchy of your WSUS solution to just one root server. Otherwise, consider baking all relevant drivers right into your server/desktop image, and also consider keeping your server drivers/firmware up to date manually or using some non-WSUS approach (for example, HP Systems Insight Manager in the case of HP servers).

 

Leave a Reply

Your email address will not be published. Required fields are marked *