This article continues from the previous post. Before getting into group policy configuration for WSUS, let’s keep in mind the following timing aspects around WSUS.
- WSUS GPO template files will take some time to replicate to all domain controllers
- WSUS GPO, once replicated, is picked up by affected PCs, this will take up to 90 minutes
- Regular PC/servers re-apply GPO policies once every 90 minutes
- Domain controllers check GPO policies every 5 minutes by default
- When computers finally detect GPO changes and apply the new WSUS settings, they will start reporting status to the respective WSUS servers. Domain controllers will show up in WSUS console quickly. Other servers may take several hours to show up. But, if WSUS servers are set up as replicas of the master, computers that report to replicas won’t show up in the master server until the next sync run of the replica server – configurable in the replica server settings
- By default WSUS does not download patches until you approve them. After patches are approved, there is going to be a delay between WSUS master server and Microsoft Update servers; patches will be downloaded during the next sync
- Next, approvals and patches need to be synced to all replica WSUS servers, which again is subject to a delay introduced by the replica-master sync settings
- Finally, when all approvals and patches are distributed to all PCs/servers, GPO settings take over once again and determine when computers will download patches and if they will be installed automatically. It is not unusual to configure the policy to check for updates frequently (at least daily) but download/install them once a week
- Windows update components use a random offset time before actually contacting their counterparties; in the case of WSUS master server, this offset can be up to 30 minutes. This is done to spread the load and prevent bottlenecks
In short, don’t expect to see computer objects in the WSUS console right away, don’t expect to see status reports right away after the first call by a new computer into WSUS, etc. On a brand new WSUS installation it will take a day for the servers to show up and the system to fully sync. That’s normal, but there are ways to speed things up when it is required:
- To trigger GPO redetection, use gpupdate /force command
- To trigger Windows Update call into WSUS, use wuauclt /detectnow command
- Keep replica servers on a frequent sync schedule at least initially
- Keep master server on a frequent sync schedule at least initially. Patches won’t be downloaded unless they are approved, and even then they are transferred once
- To force compliance status report from the client to the server, use wuauclt /reportnow
- To force the client to reset its association with WSUS server and re-enroll, use wuauclt /resetauthorization command. This command is useful when your computer object does not show up in the right WSUS computer group when client-side targeting is used
- To force sync between replica servers or between master and Microsoft Update, use WSUS console and trigger sync manually
- If you have a multi-site AD environment with lengthy delays on site links, use repadmin /syncall command on the domain controllers to speed up GPO AD object replication and FRS template replication
- Review WSUS GPO settings and increase update check frequency
Or simply wait for a day.
Group policy allows administrators to assign computers to WSUS computer groups automatically. The benefit of doing this is that you don’t need to go into the WSUS console and drag a newly built server into its proper WSUS group. The downside of using client-side targeting is that you will need to create more GPO objects, to configure different target groups for different OUs/computer objects. Without client-side targeting, you could deploy one master GPO policy that tells all computers to use a particular WSUS server, and then periodically assign newly build servers to WSUS computer groups manually using WSUS administration console.
There is really no right or wrong answer here, either way works. If you use client-side targeting, you will need to pre-create computer groups used in GPOs in the WSUS console – wuauclt client on the server will use GPO CST settings to magically end up in the correct WSUS computer group. If you have master/replica WSUS servers, create WSUS computer groups on the master server – replica will replicate them down, and also replicate computer assignments in both directions (depending on which WSUS server received a call from a particular client).
If your servers don’t end up in the right group and you end up reconfiguring group policy to retarget them into a different WSUS group, it may take hours for the computer to move within WSUS console – use wuauclt /detectnow /resetauthorization command to accelerate this and then don’t forget to synchronize any replicas with the master, so they have a consistent picture of computer assignments.
OU Structure for GPO CST
When you use CST, inherently there will be more GPO policies and potentially more OUs. Reason is simple – you are targeting different computer objects for assignment to different WSUS computer groups. You could use security group filtering to limit scope of a particular GPO to a specific set of servers/computers, but best practice is to use OUs, as it should prove to be easier to troubleshoot.
One of the approaches in setting up an OU structure for CST is to split Servers OU into sub-OUs, such as Hypervisors, Critical Servers, Staging Servers, Exchange Servers, etc. In this structure, you would create one master GPO object that would configure general Windows Update behavior on servers, configure download/install schedules, WSUS service location points, etc – and link this policy to the common Servers OU. Then at the more specific OU level, you would add a one-setting policy, basically enable CST and specify how affected servers should be assigned within WSUS. Essentially, a waterfall structure.
What follows is a collection of a few more WSUS tips I found helpful.
Frequency of Synchronizing Downstream Replica Servers
Personally, I do not see any harm in keeping synchronization interval small between internal WSUS servers. If they have nothing to synchronize, there won’t be much traffic on the network. If they do, you will see data flowing more dynamically, rolling up into master WSUS faster.
Checking Windows Updates vs. Local WSUS Server
As soon as GPO with WSUS settings are applied, computers start checking local WSUS managed service. Depending on which patches administrator has reviewed and approved, substantially more patches could be available through Windows Update as opposed to WSUS.
Sometimes this can be a good thing – for example, if you have non-default-language OS or other Microsoft software, and if you decided to not enable non-default-language patch downloads into WSUS (it would make more sense to have a regional autonomous WSUS server for this purpose, but maybe you have reasons not to deploy another WSUS server). In this case you could instruct local administrators to use Windows Update instead of WSUS (they would use the same Windows Update applet, just click on a different link to check for updates from Microsoft vs. WSUS).
If you would like to block this ability to check directly from Microsoft, as in the case of preventing potentially untested patches to be rolled out, you could use group policy setting called “Remove access to use all Windows Update features” which is located in the User Configuration section of the group policy object. Normally WSUS configuration isn’t user-specific, and settings such as location of the WSUS service are applied at the Computer Configuration level.
Always Use WSUS Server FQDN in GPO
It may be tempting to use a single-label server name when configuring service location points in group policy, just because Microsoft’s sample URL shown in the setting description uses a single label server name. As a general rule of thumb, I use FQDNs whenever possible. This may come in handy in distributed WSUS environments where you are not always in control of what’s on the local network at the remote location. FQDN uniquely identifies WSUS servers in the DNS/AD namespace.
And if you are planning to enable SSL on your WSUS server you will want WSUS FQDN to match the subject name of your SSL certificate. (Generally speaking I SSL everything but SSLing patch traffic might put undue stress on the WSUS server resources, with rather questionable benefits).
Do Not Forget About Domain Controllers
If you are setting up a WSUS GPO as a separate policy and plan to link it to the relevant server OUs, don’t forget about Domain Controllers OU. All of your domain controllers will sit in that OU, and you should not move them. Instead you should link your WSUS GPO to the Domain Controllers OU (or create a different GPO that may be more applicable to the domain controllers).
Do Not Forget About DMZ Servers
This one is obvious – most people will have some infrastructure outside of the scope of GPO. In these cases you can configure local policy on the non-domain servers to make them call internal WSUS and minimize Internet pipe utilization. Side benefit is that you will have centralized compliance/reporting for all Windows servers. Make sure to check internal firewall rules and name resolution to ensure that your DMZ servers can reach internal WSUS servers.
Moving WSUS GPO from OU to Domain/Site Level
After the initial rollout (and most likely a major patching push), it might be a good idea to consider generalizing policy settings and moving them from migration/staging OUs higher up to ensure greater coverage. In a simple environment you could move WSUS GPO up to the domain level and with that, cover all computer objects that join the domain (regardless of their OU location, be it default Computers container, Domain Controllers OU, or something else).
In an environment that has multiple replica or autonomous servers in remote AD sites, you could link WSUS policy that is common to a specific location to the corresponding AD site. This way you are still ensuring that all computer objects (including domain controllers) are covered by the policy, with the added benefit of targeting local WSUS servers.
Approve WSUS Patches at the “All Computers” Root Group Level
When your environment is more or less up to date, chances are, you will have at least one computer group for testing/staging new patches before rolling them out en masse. As a matter of consistency, approve your patches at the root level (i.e. at the “All Computers” computer group level) and make all sub-groups inherit approvals from parent – AFTER you test/stage patches. The point of this approach is that, in the event that you are using server-side targeting, and have some computer objects showing up in the “Unassigned” computer group, but only approve patches to go out to certain specific computer groups, you may inadvertently miss some “mis-targeted” computers in your patching run.