Group Policy for WSUS



image

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:

  1. 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).
  2. 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.
  3. 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).

image

image

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.

image

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.

image

You would use the following Target Group Structure…

image

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….

image

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.

image

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).

image

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:

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.

image

imageimage

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).

image

image

Your test policy should now look something like the image below.

image

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.

image

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.

image

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.

image

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).

image

image

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.

image

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.



30 Comments

  1. Hello and thanks for this article, which shows WSUS configuration within a large IT environment.

    I do have a question about client-side targeting. I had to disable them because they werent working and preventing computers from being detected and patched. Are they really useful in small environments ?

    Cheers,

  2. Hi,

    I don’t seem to be having any luck scheduling my updates to a group on computers. I have created a global security group (WSUS-WED-5AM) containing the target computers and added that to the GPO with the settings to apply (e.g Sunday at 5AM)

    I’m able to apply the global WSUS settings as you recommended which I see getting applied when I do a gpresult /r on the servers I see it as an applied Computer Policy. The only way I seem to be able to get the scheduled GPO to apply is to remove the Computer group (WSUS-WED-5AM) from the security filtering and adding back in Authenticated users. Of course doing this negates the effect of being able to target a set group of computers. This GPO has been set on the OU containing the target servers.

    It doesn’t matter which OU the WSUS-WED-5AM group resides in does it!?

    Thanks
    David

    • No that should not matter… Run a GPRESULT /R report on the computer to see when updates should be applied… Of course the computer will need to have some updated pending for them to install…

  3. It’s definitely something to do with the way the group is configured because if I put the computer account directly in the scope it picks up the settings and the GPO is applied. I even tried making a Domain Local group and adding that to the scope with the computer account in it but still the GPO is filtered out; Filtering: Denied (Security)

    I’ve even tried nesting a Global Group inside the Domain Local group but the same result is achieved. Very frustrating.

    I’ve read through the Microsoft doco and I’m pretty sure I’ve got everything in place for it to work http://technet.microsoft.com/en-us/library/cc781988%28WS.10%29.aspx

  4. Problem I ran into with the automatic server patching:

    As the general wsus policy is enforced in the parent OU the child OU will never take the settings of the gpo concerning automatic reboots at least that is what the modelling wizard tells me. So is there a workaround for this?

  5. never mind, I found it. Link it to the same container as the original WSUS policy, enforce it as well and then change the link order so it has precedence. Thanks for the attention though.

  6. Hi, With WinXP clients I am able to approve updates in WSUS 3.2, with deadlines. Users are notified of downloaded updates (yellow shield icon) and have a window of opportunity to do the installs at a time convenient to them. If they put it off, the deadline eventually arrives and the updates are forcibly installed. This is with the “3 Auto download and notify for install” setting in group policy.

    With Win7 clients I have set up exactly the same group policy settings but it appears the client behaviour is now different. If a deadline is imposed at the WSUS approval stage there are no notifications on the client or a tray icon to initiate installs. Users simply have the updates forcibly installed at the deadline time with no opportunity to do them themselves beforehand.

    Is this how it is now or is there a way to replicate the WinXP behaviour? Thanks.

  7. Update: Notifications do appear for Win7 clients, with a little *ahem* patience.
    However, with the “Remove links and access to Windows Update” setting also turned on in group policy, users don’t have an option to install the updates. They have to wait for the deadline. If the above setting is turned off, users get the option to install the updates that have downloaded from the WSUS server. The trouble is they also get the option to go to the Windows Update site and pull down updates you may not want them to have.
    I’d like them to be notified of internal WSUS updates, be able to install them at leisure up to a deadline, but not be able to access the Windows Update site directly.

  8. Hi Nebby, there is a real easy and simple workaround where you could hardcode of WSUS into the servers/workstation registry. Those servers/workstations will report back to your WSUS automatically.

  9. Pingback: Test d’intrusion active directory

  10. Pingback: نکات Active Directory | شبکه آموزش مجازی

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>