Windows Update agents suddenly and unexpectedly start downloading all updates from the Microsoft Update site

Article
01/17/2012

Hi everyone, Joao Madureira here. Here on the WSUS support team we occasionally run into an issue where all of the client machines at a customer site suddenly and unexpectedly start accessing the Microsoft Update site and downloading all available updates. The immediate problem here is that the sudden increase in traffic can overload the network, causing severe performance issues throughout the company.

So why does this happen? This series of events is triggered by a change in the Windows Update policy (the GPO) in the domain, and once you understand how the update agent is designed to work it is actually expected behavior. In this scenario, the update policy is changed in such a way that the update source is no longer specified (is blank) although “configure automatic updates" is still configured with the default value of 4, which translates to automatically install and download updates on a scheduled interval. This GPO change triggers an immediate online scan, causing all affected clients to immediately start downloading all patches all at the same time from the Microsoft Update site, causing the network bandwidth issue we described above.

The reason the clients do this is due to security reasons. If the source for updates changes but updates are still configured to occur, the client needs to automatically connect to the new update server and ensure that it is in compliance. If the update source is blank then that means we should contact the Microsoft Update site (Windows Update), and since all updates for all products are approved on the Microsoft Update site then the clients will suddenly start downloading and installing all available updates all at the same time.

In order to understand the mechanics behind this, let’s start with the policy. All agent configurations for the GPO are located here:

HKLM\software\policies\Microsoft\Windows\Windowsupdate

The Windows Update agent continually monitors these registry settings in order to configure its own behavior. So what happens when the GPO for the WSUS source is not in place or changes? When policy version changes and updates the registry keys for the Windows Update agent, the WU agent detects the change and restarts the service and will then load the new registry settings from the registry hive above. You can actually observe this in the log file:

2012-01-16 17:09:11:721 984 97c AU AU received policy change subscription event
2012-01-16 17:11:57:190 984 97c Agent *********** Agent: Refreshing global settings cache ***********
2012-01-16 17:11:57:190 984 97c Agent * WSUS server: https://contoso-wsus.contoso-joaoma.com:80 (Changed)
2012-01-16 17:11:57:190 984 97c Agent * WSUS status server: https://contoso-wsus.contoso-joaoma.com:80 (Changed)
2012-01-16 17:11:57:190 984 97c Agent * Target group: (Unassigned Computers) (Unchanged)
2012-01-16 17:11:57:190 984 97c Agent * Windows Update access disabled: No (Unchanged)
2012-01-16 17:11:57:190 984 97c AU AU received policy change subscription event
2012-01-16 17:11:57:190 984 97c AU Sus server changed through policy.
2012-01-16 17:11:57:190 984 97c AU AU Options changed from policy.
2012-01-16 17:11:57:190 984 97c AU Successfully wrote event for AU health state:0
2012-01-16 17:11:57:190 984 97c AU ########### AU: Policy change processed ###########
2012-01-16 17:11:57:190 984 97c AU # Policy changed, AU refresh required = No
2012-01-16 17:11:57:190 984 97c AU # WSUS server: https://contoso-wsus.contoso-joaoma.com:80
2012-01-16 17:11:57:190 984 97c AU # Detection frequency: 22
2012-01-16 17:11:57:190 984 97c AU # Approval type: Scheduled (Policy)
2012-01-16 17:11:57:190 984 97c AU # Scheduled install day/time: Every day at 3:00
2012-01-16 17:11:57:190 984 97c AU # Auto-install minor updates: Yes (User preference)
2012-01-16 17:11:57:190 984 97c AU # Will interact with non-admins (Non-admins are elevated (User preference))
2012-01-16 17:11:57:190 984 97c AU AU Refresh required....
2012-01-16 17:11:57:315 984 97c AU AU setting next detection timeout to 2012-01-16 23:11:57
2012-01-16 17:12:00:488 984 97c AU AU setting next featured software notification timeout to 2012-01-16 23:12:00
2012-01-16 17:12:00:488 984 97c AU Successfully wrote event for AU health state:0
2012-01-16 17:12:00:488 984 97c AU Triggering Online detection (non-interactive)
2012-01-16 17:12:00:660 984 97c AU #############
2012-01-16 17:12:00:660 984 97c AU ## START ## AU: Search for updates
2012-01-16 17:12:00:660 984 97c AU #########
2012-01-16 17:12:00:660 2580 83c CltUI AU client got new directive = 'Shutdown', serviceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, return = 0
2012-01-16 17:12:01:816 984 97c AU <<## SUBMITTED ## AU: Search for updates [CallId = {FC09C147-9B65-40C3-87A7-7565612BC1DC}]

When the source changes and the agent restarts, it goes to the new source immediately to make sure the machine is compliant with the update source it is currently configured to use. Now in my example above, I changed it to use an internal WSUS, but what happens if I leave that GPO setting for "specify intranet Microsoft update service location" blank? The machines will still scan but will now go to the Microsoft Update site instead, and since on the Microsoft Update site all updates are visible for detection by BITS (which is responsible for downloading the patches for the Windows Update agent) it will start downloading everything needed to be compliant to the new source.

In order to imagine the same process for Windows Update, you just have to think of it as a WSUS that already has all of the updates already approved for every product and every classification. The machines will get products and classifications you may not have had in your WSUS and download the patches immediately.

NOTE This behavior for the Windows Update agent can be thought of as what I call “In case of emergency”. For example, let’s say a virus outbreak has just occurred and you need to deploy a patch rapidly and cannot wait for the client machines to trigger the scan. What you would do is approve the patch with a deadline that occurred in the past, then go to the GPO for Windows Update and change any value for the policy, thus triggering a scan for updates on the clients. After triggering the online scan, the agent will see your patch approved with a deadline in the past and install it immediately, making all client machines compliant as soon as possible.

So assuming this has already occurred, here are the common questions we normally see:

1. How do I stop this behavior of all clients downloading all patches?

A. Reconfigure the GPO to point back to a valid WSUS. As soon as the Windows Update agent sees that it has a new source it will restart the agent and check for the approvals for the new patches. Since the previous BITS jobs for download won't be valid anymore (the new source for the updates is different) BITS will clear the jobs and will only try to download new updates if approved.

2. What happens with updates already cached on the clients?

A. They will be deleted after 7 days. Note that this is hardcoded on the agent and cannot be changed.

As a side note, there is one more scenario where client machines will go to the Internet instead of the local WSUS and that is when WSUS is not set to store updates locally. This setting is on the WSUS under Options –> Update files and languages –> Do not store update files locally. Configured in this manner, client computers will obtain their updates from Microsoft Update.

Joao Madureira | Senior Support Escalation Engineer

Get the latest System Center news on Facebook and Twitter :

The Forefront Server Protection blog: https://blogs.technet.com/b/fss/
The Forefront Identity Manager blog : https://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: https://blogs.technet.com/b/isablog/
The Forefront UAG blog: https://blogs.technet.com/b/edgeaccessblog/

Windows Update agents suddenly and unexpectedly start downloading all updates from the Microsoft Update site

Additional resources