Wrestling with WSUS Bandwidth

We recently deployed Windows Server Update Services (WSUS) at the office to help with patch and update management for Microsoft OS and apps. After some initial confusion, it seems to be working well and I suspect will save me a lot of time in the future. A positive investment in time so far (and the software itself is free).

One of the nice features is that now I only have one machine getting patches – the WSUS server – and all other clients pull from that server. It not only saves on bandwidth when patches are released, but it also speeds up the patch time when bringing up a new installation. It also gives me one place to go to mange what patches are released to which machines and when. I love that.

I ran into a bit of a challenge with our first new OS installations post WSUS install. See, they needed a lot of the older patches to get current. After I approved those patches in WSUS it merrily went off to get them and totally destroyed our network bandwidth!

After a bit of research, I realized the issue was with BITS (Background Intelligent Transfer Service) and I clearly was going to need to do a bit of configuration with it. Fortunately, it can be controlled by Policy.

On the WSUS server I ran MMC and then added the Group Policy Object Editor for the Local Machine. I then browsed to “Computer Configuration \ Administrative Templates \ Network \ Background Intelligent Transfer Service| and found a setting for “Maximum network bandwidth that BITS uses.” By default, it is unset so I enabled it and promptly changed the business hours cap from 10 to 100Kbps (10 is way small!):

This is a “real time” change, so just hitting OK or Apply will cause an immediate change in bandwidth usage – but I didn’t see any change and the bandwidth saturation persisted.

A bit more web searching turned up a forums topic about bandwidth throttling that didn’t work. It turns out WSUS can run in “Foreground Mode.” Now, I’m not clear on if that’s a default or something we did, but it causes my earlier change to be ignored. Fortunately, someone responded with a solution.

I needed to grab the WSUS server debug utility and check my mode. Sure enough, I was in this Foreground mode (WsusDebugTool.exe /Tool:GetConfiguration).

The debug tool makes it easy to change that though: WsusDebugTool.exe /Tool:ResetForegroundDownload and a reboot had my bandwidth back under control and my earlier bandwidth limit was now in effect.

Problem solved and we can now get updates during business hours without saturating bonded T-1’s. Everyone wins!

Possibly Related posts: