This page looks best with JavaScript enabled

Managing Windows Updates with Group Policy

 ·  ☕ 12 min read

In this post I’ll walk through how I manage and test the delivery of Windows Updates to all my clients and servers. I’ll also go through how I manage essential servers like Domain Controllers, Hyper-V hosts and I’ll touch on getting started with Cluster-Aware Updating. We’re going to group our machines into Clients and Servers, and then group each of those groups into Ring 1 and Ring 2. If you want, you can create more rings for more control, but generally I find two rings are sufficient.

Ring 1 Testing

Updates are initially approved here and installed on specially selected machines that you have chosen. For clients I’d suggest a cross section of users, preferably who are communicative and easy to work with. I find it helps if they have volunteered to begin your victims beta testers. For servers, you’ll want a selection of non-critical servers running a variety of services.

Ring 2 General Availability

When updates have passed testing, they can be approved for general availability and installed on all clients and servers.

Special Note

I know that a lot of people have the viewpoint that they “shouldn’t have to be testing Microsoft’s updates for them” and I can understand this frustration, but the reality is that currently the updates coming out have issues that aren’t being picked up by internal testing. So to look at it from a slightly different perspective; you’re not testing for Microsoft, you’re doing your due diligence, testing for your systems to maximise up time and also reduce the stress and extra work that you and/or your team have to cope with.

Getting Started

To put this all in place we need to create some Group Policy Objects, Active Directory groups and make some changes to WSUS. To Install and configure Active Directory Domain Controllers, click here. To install and configure WSUS, click here.

Create the following Group Policy Objects:

  • WSUS_General
  • WSUS_Clients_Ring1
  • WSUS_Servers_Ring1

Create the following Active Directory groups:

  • WSUS_Clients_Ring1
  • WSUS_Clients_Ring2
  • WSUS_Servers_Ring1
  • WSUS_Servers_Ring2

Create the follow computer groups in WSUS:

  • Clients - Ring 1
  • Clients - Ring 2
  • Servers - Ring 1
  • Servers - Ring 2

You’ll also need to change some options in WSUS: Under the Options node, go to Computers and select Use Group Policy or registry settings on computers.

Group Policy Object Settings

The WSUS_General GPO is where we will configure core settings that we want to apply to all computers regardless of which ring they will be in. Configure the following settings:

Computer Configuration/Policies/Administrative Templates/Windows Components/Delivery Optimization

Download Mode > Enabled - Lan (1)

Explanation: Enable the above setting to allow your clients and servers to download updates from each other. They will still only download and install updates that have been approved for their group, but it will lighten the load on your WSUS server.

Computer Configuration/Policies/Administrative Templates/Windows Components/Windows Update

Specify intranet Microsoft update service location > Enabled

Set the intranet update service for detecting updates > http://wsus.contoso.com:8530

Set the intranet statistics server > http://wsus.contoso.com:8530

Set the alternate download server > http://wsus.contoso.com:8530

Download files with no Url in the metadata if alternate download server is set > Disabled

Client Group Policy Object Settings

We’re now going to configure the WSUS_Clients_Ring1 GPO. We’re going to use this GPO as a template for the other client ring GPOs too. The reason we’re not putting all these common settings in the general GPO above, is because these settings control the installation of updates and if we need to tweak them in future, we can test the settings first using the ring system.

Configure the settings in the WSUS_Clients_Ring1 GPO as below:

Computer Configuration/Policies/Administrative Templates/Windows Components/Windows Update

Automatic Updates detection frequency > Enabled

Check for updates at the following interval (hours) > 4

Configure Automatic Updates > Enabled

Configure automatic updating > 4 - Auto download and schedule the install

Install during automatic maintenance > Disabled

Scheduled install day > 0 - Every day

Scheduled install time > 17:00

Every week > Enabled

Install updates for other Microsoft products > Disabled

Configure auto-restart reminder notifications for updates > Enabled

Specify the period for auto-restart reminder notifications > 60

Enable client-side targeting > Enabled

Target group name for this computer > Clients - Ring 1

No auto-restart with logged on users for scheduled automatic updates installations > Disabled

Specify deadline before auto-restart for update installation > Enabled

Specify the number of days before a pending restart will automatically be executed outside of active hours:

Quality Updates (days) > 7

Feature Updates (days) > 7

Turn off auto-restart for updates during active hours > Enabled

Active Hours Start > 8 AM

Active Hours End > 5 PM

Explanation: With the settings above, this should provide a good balance of getting updates installed without interrupting users. The active hours ensure that automatic reboots will not happen during these hours. Now we’re going to ensure that this GPO only applies to the clients we want it to by using Active Directory groups and Security Filtering on the GPO.

Using Group Policy Management, go to Group Policy Objects > WSUS_Clients_Ring1 and click on the GPO.

Select the Scope tab in the larger right hand pane, and under the Security Filtering section, remove the Authenticated Users group and add the WSUS_Clients_Ring1 group we created earlier.

You might be wondering why we didn’t create the WSUS_Clients_Ring2 GPO above. We’re going to copy the WSUS_Clients_Ring1 and use it as a template.

To copy the Group Policy, right-click on the WSUS_Clients_Ring1 and select Copy, then right-click on the Group Policy Objects node in the left hand side of the Group Policy Management console and select Paste.

Specify the permissions for the new GPO and then click on OK.

You will now have a GPO called Copy of WSUS_Clients_Ring1. Rename the GPO to WSUS_Clients_Ring2 and then edit it and change the setting below:

Target group name for this computer > Clients - Ring 2

Server Group Policy Object Settings

We’re now going to setup the WSUS_Servers_Ring1. Like the client GPO this as a template for the other server ring GPOs too. The reason we’re not putting all these common settings in the general GPO, is because these settings control the installation of updates and if we need to tweak them in future, we can test the settings first.

Configure the settings in the WSUS_Servers_Ring1 GPO as below.

Allow Automatic Updates immediate installation > Enabled

Automatic Updates detection frequency > Enabled

Check for updates at the following interval (hours) > 4

Configure Automatic Updates > Enabled

Configure automatic updating > 4 - Auto download and schedule the install

Install during automatic maintenance > Disabled

Scheduled install day > 0 - Every day

Scheduled install time > 06:00

Every week > Enabled

Install updates for other Microsoft products > Disabled

Enable client-side targeting > Enabled

Target group name for this computer > Servers - Ring 1

No auto-restart with logged on users for scheduled automatic updates installations > Disabled

Turn off auto-restart for updates during active hours > Enabled

Active Hours Start > 6AM

Active Hours End > 11PM

Explanation: With the settings above, the servers should reboot only when an update requires it and only outside of the active hours configured. It’s important to note that the Active Hours can only have a maximum range of 18 hours.

Now just like the clients GPO we’re going to set up this GPO so it only applies to the servers we want it to by using Active Directory groups and Security Filtering on the GPO.

Using Group Policy Management, go to Group Policy Objects > WSUS_Servers_Ring1 and click on the GPO. Select the Scope tab in the larger right hand pane, and under the Security Filtering section, remove the Authenticated Users group and add the WSUS_Servers_Ring1 group we created earlier.

We’re now going to copy the WSUS_Servers_Ring1 and use it as a template for the ring 2 GPO. To copy the Group Policy, right-click on the WSUS_Servers_Ring1 and select Copy, then right-click on the Group Policy Objects node in the left hand side of the Group Policy Management console and select Paste.

Specify the permissions for the new GPO and then click on OK. You will now have a GPO called Copy of WSUS_Servers_Ring1. Rename the GPO to WSUS_Servers_Ring2 and then edit it and change the setting below:

Target group name for this computer > Servers - Ring 2

Putting It All Together

In Active Directory, find the computer accounts you want to use for testing updates and add them to the group WSUS_Clients_Ring1. Add all the other computer accounts to the WSUS_Clients_Ring2 group.

Next add the servers that you are going top test updates on to the WSUS_Servers_Ring1 group, and the other servers to the WSUS_Servers_Ring2 group.

Do not add Domain Controllers, Hyper-V hosts or servers that are in clusters, we’ll cover how to manage updates for these later on.

Link the WSUS_General GPO to the most top level Organisational Unit(s) you can that contains the computer accounts you want to receive the settings.

Now link the WSUS_Clients_Ring1 GPO to the OU(s). Only the computer accounts that are in the WSUS_Clients_Ring1 group will receive the settings.

Repeat these steps for the WSUS_Clients_Ring2 GPO and the WSUS_Servers_Ring_1 & 2 GPOs.

Over time (a reboot may be required for the settings to fully take effect) the clients and servers should begin to appear in the WSUS console under the Computers node in the configured groups.

Domain Controllers

I separate domain controllers from the other servers because they need to have a staggered reboot from each other. If they reboot at the same time the whole domain goes down, and this is a bad thing not desirable. To do this I create GPOs for each DC, with different install times and I put the DCs in ring 2, so they only install updates which have been tested.

Here are the settings for the WSUS_DC01_Ring2 GPO:

Allow Automatic Updates immediate installation > Enabled

Automatic Updates detection frequency > Enabled

Check for updates at the following interval (hours) > 4

Configure Automatic Updates > Enabled

Configure automatic updating > 4 - Auto download and schedule the install

Install during automatic maintenance > Disabled

Scheduled install day > 0 - Every day

Scheduled install time > 01:00

Every week > Enabled

Install updates for other Microsoft products > Disabled

Enable client-side targeting > Enabled

Target group name for this computer > Servers - Ring 2

No auto-restart with logged on users for scheduled automatic updates installations > Disabled

Turn off auto-restart for updates during active hours > Enabled

Active Hours Start > 6 AM

Active Hours End > 11 PM

The GPO settings for WSUS_DC02_Ring2 are the same, except I set a different install time:

Scheduled install time > 02:00

This gives DC01 an hour to install, restart and stabilize before DC02 installs its updates and restarts. We now need to link the GPOs to the DCs. One way we can accomplish this is by linking the GPOs to the Domain Controllers OU and set security filtering on the GPOs for each DC.

So WSUS_DC01_Ring2 would have Authenticated Users removed from security filtering and the DC01$ computer account would be in its place.

However, I’ve had trouble getting this to work recently. So, I’ve taken to creating an OU for each DC, and then linking the GPO to the OU and leaving Authenticated Users in the security filtering. See below:

[Group Policy for DCs

This may not be the best way to do it, but for a small number of DCs, I think it’s good enough. For larger numbers of DCs (more than four I’d say), I’d recommend creating groups, and grouping up the DCs, as with running more than four DCs rebooting a couple at the same time shouldn’t be an issue.

Hyper-V Hosts

Like with Domain Controllers, I separate the Hyper-V hosts if they are not in a cluster. For the Hyper-V hosts I copy the WSUS_Servers_Ring2 GPO and set the install time setting to something that doesn’t conflict with the DCs or the other servers.

Since Windows Server 2012 R2 there’s been a setting for updates to Install during automatic maintenance. This sounds like a good idea as it installs updates and restarts at a random point within a period of time that you can set. Unfortunately, I’ve never been able to get it to work reliably on Windows Server 2016 and 2019, so I don’t use it.

Here are the settings for my WSUS_VS01_Ring2 GPO:

Allow Automatic Updates immediate installation > Enabled

Automatic Updates detection frequency > Enabled

Check for updates at the following interval (hours) > 4

Configure Automatic Updates > Enabled

Configure automatic updating > 4 - Auto download and schedule the install

Install during automatic maintenance > Disabled

Scheduled install day > 0 - Every day

Scheduled install time > 03:00

Every week > Enabled

Install updates for other Microsoft products > Disabled

Enable client-side targeting > Enabled

Target group name for this computer > Servers - Ring 2

No auto-restart with logged on users for scheduled automatic updates installations > Disabled

Turn off auto-restart for updates during active hours > Enabled

Active Hours Start > 6 AM

Active Hours End > 11 PM

I don’t configure security filtering on this GPO, leaving Authenticated Users in place.

Cluster-Aware Updating (CAU)

Cluster-Aware Updating is entirely different and doesn’t use Group Policy at all, except to disable Windows managing updates itself. To use Cluster-Aware Updating, open the application named Cluster-Aware Updating in the Windows Administration Tools and connect to the failover cluster you wish to manage.

Once connected you can configure how you want updates to be installed and when just like with Group Policy, except CAU manages the installs and reboots for each node in a cluster, making sure the cluster stays up. One change you have to make when setting up Cluster-Aware Updating is disabling Windows from managing updates using GPO. To achieve this, it’s best if you have an Organisation Unit setup for each cluster, and all the AD objects for that cluster inside the OU. We’ll create a GPO named WSUS_Disabled_CAU and disable Automatic Updates entirely.

Computer Configuration/Policies/Administrative Templates/Windows Components/Windows Update

Configure Automatic Updates > Disable

Link this GPO to the OU containing the cluster objects and now the cluster should install updates as configured in the Cluster-Aware Updating tool.

If you have any questions or comments please leave them below.

-Mike

Share on
Support the author with