How to block Windows Update

[David]

Automatic Windows Update is simultaneously a blessing and a curse, depending on the environment, timing, production impact, etc. Wouldn’t it be nice to have another point of control as to when it happens, especially for endpoints that cannot have an agent or be managed for various reasons?

One solution we will explore today is to selectively allow FQDNs related to windows update to only run during designated maintenance windows. Or, not at all. Use cases that our clients report, for example:

1. They want to avoid changes in the middle of a most important business week… but rather update on the Friday (after patch Tuesday) so that the weekend can be used to check for any problems

2. They want update servers to be reachable only at night time when bandwidth is less costly and more available, as many parts in the world still are bandwidth-constrained

3. PLC controllers that are supported by various vendors up to a specific Windows version… in many such cases, updating Windows

You might say “but wait, are you advocating taking risks by not patching Windows immediately on Patch Tuesday?” The short answer to that: Updating is a risk/reward scenario. If security is achieved otherwise, with a strong Zero Trust connectivity policy and network isolation, for example, the reward is clear for avoiding patching if it can interrupt production.

A short blocklist of domains can be used to control Windows update at the gateway using adam:ONE with a blocklist applied to the policy in use.

The rule we’ve tested with Windows 10/11 requires these domains (including subdomains):

windowsupdate.microsoft.com
update.microsoft.com
windowsupdate.com
msupdate.microsoft.com
ntservicepack.microsoft.com

The blocklist rule by way of a sample screenshot:

Potential Usage

Scenario 1 - Manual adjustment when applying updates

These are some of the ways that the above rule can be used in policies and schedules:

• Never allow updates except for manual intervention, at scheduled maintenance windows, presumably on any day but Patch Tuesday

• In this case, the rule that blocks Windows Updates can simply be turned off during maintenance windows and re-enabled thereafter

• Policy is simply assigned as shown and manually changed during planned updates:

  

Scenario 2 - Scheduled weekly update window

• Allow updates only after-hours or weekends for bandwidth or risk management reasons

• In this case, we use a Schedule where a policy allows for Windows Update to occur only during pre-determined times, e.g.:

  

• The policy labeled DNSharmony - Allow Windows Update differs only in that the Blocklist is not enabled

Potential Side Effects

The side effects are minimal, but any other Microsoft download that depends on one of the domains above will also be unreachable. This includes the download of free viewers such as Word Viewer, Excel Viewer, etc. Note it does not impact the operation of a computer with the complete version of Microsoft Office (any version).

[nckrwlmn]

This is a good use case for windows machines. But wouldn’t it be so nice if this could be accomplished in the dashboard without having to create a whole new policy, and start flipping switches ad nauseum ……Making a list, and checking it twice…… And then having to make sure all windows machines are on said policy……

No, instead, stuff like this should be able to be applied globally even, outside of any policy. I can think of many other scenarios that would benefit from this. Or, the scheduling could happen with a small “child” policy, that would only include: from x hour to x hour, apply this black list. That’s all the child policy would show.