Windows Server Update Service (a.k.a. WSUS) is Microsoft free tool they provide for deploying patches and updates. In my experience this tool is pretty much used by every organisation in the world that has more than a hand full of computers. WSUS is also a requirement for the Software Update option in SCCM 2007.
What I hope this post will teach you is how to use Group Policy in your environment to milk the absolute most out of your existing WSUS infrastructure. I am also going to assume that you are familiar with WSUS and already have it deployed in your organisation…
Is WSUS the right tool for your organisation?
Having implement WSUS for an environment of over a combination of 10,000 servers and workstations I can truly say that this tool scales really well. I also believe that even if you have bought and implemented System Center Configuration Manager in your environment then you are probably still better off using WSUS for manage you updates for your Microsoft software. The reason why I still normally recommend that people using WSUS over SCCM is that the product overall is much easier to use and its just human nature for people to want to do the easier tool where possible…
However there are a couple of reason why I think SCCM should still be used over WSUS and they are:
- You require to wake computers using WOL for them to be patched out of hours. (However there is a way to do something similar using Group Policy).
- You want to ensure that computers are only patched during a “Maintenance Window” (however even this can be done using Group Policy) and that these patches do not install if it will take longer than that window.
- The SCCM Software Update supports third party updates when used in conjunction with System Center Updates Publisher 2011. This is very handy if you want to deploy third-party updates from HP, Dell or Adobe (yes! Flash and Reader). But unfortunately even though SCCM SU feature is built on WSUS there is no way to import these third-party updates directly into a standalone WSUS server.
WSUS Tip’s and Tricks
Below are a collecting of configuration recommendations and tips that help you get the most our of your WSUS infrastructure in your environment. These are in no particular order of importance and you might chose to implement only some of these setting depending on your environment.
Terminology: In this post i will use the term “client” many times. When I make this reference note that I am talking about any client of the WSUS Server, which could mean a “client” is either a server or workstation.
WSUS Computer Group Assignment
One of the first things you should do once you have installed WSUS and performed the first sync is enabled the Group Policy computer group assignment. This allows the clients that connect to your WSUS server to be automatically configured in the correct targeting group when they connect to the WSUS server. The target group on the client is controlled using the “Enable client-side target” group policy setting (more on this later).
If you don’t enable this option you will quickly find that you need to manually categorise even new computer that reports into the WSUS server. This is fine if you only have few computers but once you star managing many hundreds or thousands of computers this quickly becomes impractical.
DNS Alias for WSUS Server
One of the options you can set using Group Policy is called “Specify intranet Microsoft update service location” which allows you to specify the WSUS Server name. Even thought this setting can be controlled via Group Policy and thus can be changed in about 2 hours, I still strongly recommend that you create a DNS Alias. Creating a DNS alias for your WSUS Server will give you another way to easily migrate your clients to a new WSUS server without the need to keep a legacy alias of your old server name after you move to a new WSUS server.
Default Top Level GPO
Another great thing about WSUS is that the Automatic Update agent, which is the software the client uses to connect to the server, is included out of the box in every single copy of Windows Since XP. This means that there is no additional software agents that need to be deployed to the computers to get starting using WSUS. This being the case… You can set a policy at the very top level of your domain using the “Specify intranet Microsoft update service location” setting to configure every computer on your domain to point to the WSUS servers. I find that once an organisation does this they are amazed how this discovers a number of “hiding” computers on their network that have never been patched.
In conjunction with this setting I would also recommend that you set the “Configure Automatic Updates” to option 2 so that by default you are NOT inadvertently pushing out any patches to any computers.
Doing this this is more a discovery process so that you can at least be aware of any un-patched computers on then network that you can then appropriately remediate… An added side benefit doing this is you also get an accurate picture as to home real computer’s are actually on your network.
Hierarchical Naming of Target Groups
Back in the day of WSUS v2 you could allocate computers to target groups however these target groups could not be nested and it meant that every target group had to be unique. Even though WSUS v3 now has the ability to have nested target groups it still has the same restriction that all target groups must be made unique. I suspect that it is due to the ability for a WSUS v3 server to act as a parent to a WSUS v2 server during a migration of WSUS. That being the case, you need to deploy you target group naming strategy in a way to avoid need two target groups with the same name…
Here I will tell you to go visit my Best Practice: Active Directory Structure Guidelines – Part 1 post where I talk about the number of ways you can build your OS structure.
Now we will use the example “Two Level Hybrid (Resource / Location)” (see image below) from the AD Structure Guideline for out WSUS target groups.
You would use the following Target Group Structure…
You might also notice in the above image I also have “Terminal Servers” and “Servers” at the top level of the WSUS Structure. Generally I recommend in most environments these are the only top three WSUS groups you will need. I will go into more detail on this further on in the “Top level Patch Approval Groups” section but for now just ignore the server and terminal server target groups…
What you will find is that the OU design of your organisation will largely mirror your OU Structure. You might also notice that the names of the target groups are “Workstations SITENAME” and not just “SITENAME”. The Workstation prefix is required as you might also want to patch Servers in the same site and therefore due to the unique target group requirement you will need to have a “Workstations Sydney” and “Servers Sydney” group.
Now also take a look at the “Keep the GPO’s name consistent with the OU names” section in my Best Practice: Group Policy Design Guidelines – Part 2 post you can see how the WSUS Target Groups are also very consistent (but not the same) as the OU’s that the computer are located. The advantage of doing this is that it makes it a lot easier to determine what OU a computer is a member of just by looking at the target group it has in the WSUS console.
Here you can see an example of how the Group Policy Object would also be applied to support the OU Structure and WSUS Target Group Structure above….
So now if you have actually read my other two AD and GP Best Practices blog posts you might actually be seeing the sheer genius of how these designs are related (Yes I know I am modest). I know that this might not be practically to implement this utopia design for most environments but if you strive to have at least a consistent naming and structure to you organisation I find that it makes finding, troubleshooting and configuring your environment a whole lot easier…
Configure Update Setting and Target Groups Separately
If you have chosen to use a “Resource\Location” OU Structure in your organisation (as seen above) then you should also apply a default “Configure Automatic Updates” on the GPO linked to the Workstations OU. This allows you to apply the default action for patches and if and when they are applied to all workstations consistently from one policy meaning if you ever need to change these setting you only have to do it once.
The other configuration you need to apply is the “Enable client-side targeting” which assigns the WSUS Target Group to your clients. This policy should be applied at in the GPO linked to the lowest level of your OU structure. The example below applies the target group “Workstations Sydney” in the GPO called “Workstations Sydney” (notice the same name) which would be applied on the OU “Workstations\Sydney” (Assuming you are using my genius Group Policy Object naming convention).
Essentially what this means is that the minimum settings are being applied to all clients by using the sum total of setting applied using multiple GPO’s at different levels.
Just to recap we are applying three essential Group Policy setting at three different levels which get combined together when the policy is applied to the client:
- “Specify intranet Microsoft update service location” is applied at the top level domain so it is configured once for all clients.
- “Configure Automatic Updates” is applied via the relevant GPO that applies to all computer of a particular type. (e.g. “Workstations” GPO allied to all Workstations).
- “Enable client-side targeting” is applied at the lowest level to allow granular reporting of the status of computer groups by Site or Role.
Once you have applied the above three settings to your computers then your clients should have the minimum setting to report into your WSUS server.
Implement a WSUS Update Test Group of Computers
One of the reasons you have a WSUS server hosted internally (besides saving a whole heap of bandwidth) is to allow you to manage the approval of patches to deploy to your computers. The main reason you want to do this is of course it allows you to test these patches to make sure they don’t break anything…
To establish a test group for patches you will need to create a number of security groups. These groups will have the computer accounts in them that you want to use for testing patches. At minimum you probably need to create two security groups, one for workstations and one for servers. However you might find that you need to have to additional groups if you want to have additional independent test groups.
In this example I am establishing a Workstations Test groups using the security group called “WSUS Workstations Test”. Note, I have prefixed the group name with WSUS so it is easy to find all the WSUS related security groups in my organisation.
Next you need to create a Group Policy object at the highest level possible that will apply to all your workstations in your organisation. In this example I have linked the policy at the Workstations OU as this will contain all the workstations in my test environment. However if I have workstations under various top level OU’s then you will need to link the policy at the top of the domain.
The next thing to do is to configure the advanced security of the policy to remove “Apply group policy” from Authentications Users and Add the group “WSUS Workstations Test” (see images below). This will make sure that this policy ONLY applied to the workstations that are member of the “WSUS Workstations Test” security group.
Now you have configured the security delegation you can configure the “Enabled client-side targeting” setting to “Workstations Test” and then enabled the “Enforced” option of the policy (see images below).
Your test policy should now look something like the image below.
As the GPO is configured with the “Enforced” option it will override any lower level target group configuration. This has the slight disadvantage of not having the granularity of the lower level targeting (e.g. Workstations Sydney) as all the computers in the test group will be targeted using “Workstations Test”. But this is normally an acceptable trade-off as these computer are going to be patched at a different schedule anyway…
TIP: Make sure that the computers you have selected to perform patch testing are a good cross section of your environment. You may also want to make sure that the people that use these computers are technically proficient and are likely to report an issues if something goes wrong.
Next you need to make the “Workstations Test” group in WSUS under the “Workstations” Group. The main reason why this is a sub group of the “Workstations” group is that you want to ensure that your test workstations have at least all the same patches approved to them as the other non-test workstations.
If you then create the “Workstations Test” group at the top level you would need to 1. approve all patches twice to both top level groups and 2. risk approving a patch to the one group and not the other and thus making your test computer not an accurate representation of your non-test computers.
Now that you have selected your test workstation, added them to the test security group and have them in the “Workstations Test” WSUS group you are right to start testing update to this group of computers.
Once you have finished testing of the patch and you are going to approve it for the rest of the computers ensure that you reset the approval for that patch on the “Workstations Test” group by using the “Same as Parent” option.
Doing this will ensure that the patch approval to the “Workstation Test” are a complete superset of the patches approved on the “Workstations” WSUS group.
Applying patches to sub roles of computer
If you have some need to separately approve patches to a group of computers that is not just a workstation, terminal server or server (e.g. Exchange Servers) then simple go through the same process in the about “Implement a WSUS Update Test Group of Computers” section giving it what ever name is appropriate (see images below).
Configure All Workstation to “4 – Auto download and schedule the install”
Generally speaking the vast majority of clients for your WSUS server will be workstations and as such you probably DON’T want to manually installed patches on these computers simply because you have much better stuff to do with your time. Therefore in the “Workstations” GPO that I talked about earlier you should configure the “Configure Automatic Updates” option to “4 – Auto download and schedule the install” and the schedule to “0 – Every day”. The affect of this is of course any workstation on you network will have the patches scheduled install within 24 hours of you approve a patch.
The exact scheduled time is up to you, however the default time of 3:00am has served me well over the years and I have never come across any reason to change this time for the bulk of the workstations being patched. I am not sure of the exact reason why 3am has been selected by Microsoft but I am sure they have there reasons…
Reference TechNet: Best Practices with Windows Server Update Services
one of your main goals is to have any planned downtime occur when there is little chance for lost productivity
Obvious question however is What happens if the computer is off at 3am? Good question… and i will talk about that more later.