Now that we saw in the previous posts of WSUS (Part I and Part II) about the first steps of the deployment, we are going to take a quick look about handling the tool itself.

Once you get to know the WSUS interface, you’ll see that everything it’s pretty much intuitive. You have to know that when there are tools like WSUS involved, the process of patching that you defined (testing the updates, defining how and when you’ll apply those updates, period of time involved, etc.) is the crucial matter to get WSUS work as you planned. In this case, the process it’s even more important than the technology.

Let’s take a final look to the group policies. We already talk about that it’s a common best practice to implement different layers of GPOs, but which are the ones that you actually have to enable for each OU? This is an example of a GPO applied on an OU with all the testing computers.

We decide that in those testing computers the updates will download and install automatically at a certain hour of the day. But what happens if that computer is not available at that time? Then you must use the option “Reschedule Automatic Updates schedule installations”, when you enable it, you can set that the updates will install on those computers at the moment that they become available again (you actually have to set only the minutes that Automatic Updates will wait after the startup).

If we applied a common GPO over the domain, and we set the WSUS server on that policy, then there’s no need to configure the intranet location of Microsoft Update on this GPO.

The “Enable client-side targeting” GPO it can be really helpful to you, meaning that all computers that you move to this specific OU will automatically join the WSUS group that you define in this GPO. But the policy can’t do the job on its own; you must also change the “Computers” entry on the “Options” item of the WSUS console. It must be set to “Use Group Policy or registry settings on computers”

It’s always recommendable that you take a look to all the GPOs explanations to see that if they apply for your environment.

If you set different GPOs for Servers, Domain Controllers, Mobiles, Workstations, etc; they shouldn’t be much different.

Before setting any other GPO on others OUs, it’s good to remember some of the points that we discussed in the previous WSUS posts: about when to apply the option of “Schedule Install” of the Updates without any intervention of the user.

You must be careful on setting that option to your organization users, if there’s an open session at the moment of installation, depending on the updates, the process can take a lot of the resources of memory, disk and processor.

You must also be careful on the moment you choose to install on your servers. For example, you plan that in your working hours you will install the updates (that you already tested) on your servers, and restart them later at night. But you have to know that some of the critical updates of SQL Server, for example, can actually stop the services when you install them, and to take back online the database server you must restart the computer first.

Let’s take a quick look to some of the WSUS options:

Automatic Approval

This is probably a great option to use when you are working with a test phase before approving any updates to production. This is an example of a rule created to approve for my own group of testing computers “Staging” almost all the available updates.

Express Installation Files

Basically an update is a new version of a file that you already have on your computer, so when a user wants to install an available update, downloads the complete file and installs it on his computer. An express installation file represents the “delta” between the version of the file that you already have and the updated file.

You can use express installation files to limit the bandwidth consumed on your local network, at the cost of bandwidth consumption on your Internet connection and disk space.

Why the Internet bandwidth increase if I only want the deltas? Because the files that need to be downloaded from the web, must contain all the possible deltas of that file. You may triple the size of a regular updates download if you implement the express installation files, but you gain on the cost of bandwidth when you install those updates.

Maintaining your WSUS Server

There are several options and tools that are included with WSUS console, which can really help you maintaining the health of your server.

Server Clean Up Wizard

This option you can run it periodically to delete, for example, old updates (replaced for new versions), updates that are not needed, etc.

E-Mail Notifications

This can help you check the status of WSUS updates in a brief summary and without accessing the console. Here’s an example of the report that is send, in my case, daily

To Do List

The “To Do List” you can find it on the root of the WSUS console, where an overview of all the status is available.

The To Do List shows some of the things that you should take notice. In this example, there are computers that, by group policy, have requested join to WSUS groups that doesn’t exist.

Command Lines to remember

Whenever you apply different options, policies or both with WSUS you always want to know if the changes are made as you plan. The GPOs usually takes to 90mins on client computers to be applied, so if you want to see the reaction on a client with a group policy remember to use on the client this command-line:

gpupdate /force

And when you try to see what happens with the updates, there’s a command line that you can use to automatically ask the WSUS server for new updates:

wuauclt /detectnow

Remember, if you have set to download the updates automatically on the clients, to see if there are new updates available, you must wait until the client downloads all the updates and then the notification will appear.

If you just moved a client from different WSUS groups or you are suspecting that something is wrong on the client side and detection of the updates, run this:

wuauclt /resetauthorization /detectnow

WSUS uses a a cookie on client computers where it stores some of the clients configuration, like group membership (this cookie expires an hour later from its creation). Using the /resetauthorization will automatically expire the cookie and look again for the client configuration.

Troubleshooting Clients

Some of the things that I recently ran into when I tried to install some critical updates is that several of computers appeared on my WSUS console with errors installing those updates. The problem seemed very strange because every time I tried to install the update, manually or automatically, it failed.

Taking a look to the problem I also found out that in all of the clients that a message of “Low Virtual Memory” also appeared.

If you are thinking that the problem is that the clients do not have enough RAM, you are wrong.

Don’t worry, there’s a solution to that problem, install this hotfix (for Windows 2003) on those client computers and the problem should be solved. You can find more information here:

http://support.microsoft.com/kb/925336/en-us

I guess this is pretty much it about Windows Server Update Services 3.0.

Any comments or questions are welcome.

WSUS 3.0: Deployment and First Configurations (Part I)
WSUS 3.0: Deployment and First Configurations (Part II)

Cheers!!