WSUS Syncs Metadata, but Doesn't Download Updates

Recently, I visited a customer who was having some challenges getting WSUS to synchronize with the public Windows Update service. While the fix is fairly straightforward, there isn't a lot of information around on this topic and was hard to find when doing Internet searches, so I'm documenting this here.

In this particular case, this company had gone ahead and added the Windows Server role, configured the products they were after and update categories, and sync was successful. However, no matter what they tried, the updates themselves wouldn't download.

To make this more confusing, there were no errors in the event log to help narrow down the problem. Turns out this particular issue was a problem with BITS (Background Intelligent Transfer Service) traffic and interactions with their "next generation" firewall doing inspection/modification of the traffic.

If you are experiencing this, try running BITS in Foreground Download Mode. This essentially means that certain protocol commands (such as the RANGE parameters) aren't used as part of the query to get the content.

The easiest way to do this in a way that just affects WSUS is to modify the configuration in the WSUS database directly. If you're hosting the WSUS database as a Windows Internal Database (WID), then the following command will do the trick:

 sqlcmd -S \\.\pipe\MICROSOFT##WID\tsql\query -E -Q "update tbConfigurationC set BitsDownloadPriorityForeground=1"

Otherwise, if you're using SQL to host the database, you just need to execute the following against the SUSDB database either using the sqlcmd command above (changing out the WID DB for your SQL instance & DB) or just executing the following query using the SQL Management Studio and selecting the SUSDB database (recommended):

 update tbConfigurationC set BitsDownloadPriorityForeground=1

After doing the above, restart the BITS Service (which will also restart WSUS which by default has a dependency on it) and requeue your downloads / syncs.

Note that this issue generally doesn't occur with WSUS when used as part of System Center Configuration Manager since ConfigMgr queues the downloads itself rather than the call coming from WSUS, which has different defaults.

Hope this helps!