Group Policy Central

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

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.

Listen

Multiple Page Post: Page 1 Page 2 Page 3 Page 4 Page 5