Augusto Alvarez

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!!

To pull off some of the best practices that we talked about on the first part of the WSUS 3.0 posts, we’ll take a look to some technical configurations. At this point you must already have set different OUs for the type of computers you have in your environment. This OU separation will help you to improve your patching process.

· Group Policies Configuration

If you are using Windows Server 2003, first of all let me say that you must install Group Policies Management Console to apply and access all of the policies on your domain, this tool gives you a nice interface to interact with those objects. But if you are using Windows Server 2008, this console comes integrated with the operating system, so there’s no need on installing it.

Like you remember, on the first part we talk about applying different policies for different computers and also different levels of GPOs: A “common” GPO for the entire domain and over the OUs (and sub OUs if is the case) applying another GPO for more restrictive options.

Let’s start then opening the GPMC and over our domain click on “Create and Link a GPO Here”:

After we insert the proper name for our WSUS GPO, we right click on the GPO and select “Edit”. The “Group Policy Object Editor” opens.

The location of the most important group policies that we need to configure are located in “Computer Configuration” -> “Administrative Templates” -> “Windows Components” -> “Windows Update”

Like this policy will apply for all the computers in the domain, you have to find out the common GPOs on all the computers, no matter which OU they belong. In my case, I’m setting only the options “Specify Intranet Microsoft Update service location” pointing to my WSUS server and “Configure Automatic Updates” to “Notify to download and notify to install”.

If you don’t have these two policies set every time a computer joins to the domain, since they automatically they are stored on the “Computers” OU, and if they also have set the default option for Automatic Updates installation, that computer will automatically download from Internet and install those updates without using the WSUS server. Remember that you cannot apply a GPO over the Computers OU, so applying to the domain will ensure you that these computers will follow the WSUS GPO.

On the OUs that you have set for storing your computers and servers, you can link all the GPOs as you please: Frequency that the computers will ask for the WSUS server about new updates, hours that the updates will auto install, etc. Take a look to each explanation of the options to find the correct combination for you. This is an example of a GPO applied on a workstations organization unit:

Take a look also to the option available on “User Configuration” -> “Administrative Templates” -> “Start Menu and Taskbar” -> “Remove links and access to Windows Update”.

This option when it’s enabled prevents user to access Windows Update Website and removes any links available on Control Panel or Start Menu.

· When should I apply the updates on my servers?

Well you should have a good plan about how and when to deploy the updating process on your servers, after all that is the critical point on every scenario.

Microsoft has a certain “policy” about when the updates are released, which is commonly on every Tuesday of the week. Why? :

Tuesday: Update released.
Wednesday: Install on test lab.
Thursday: Test the update.
Friday: Install on production.
Weekend: Reboot the servers.

You should avoid to leave your servers without the proper reboot when a critical update is installed.

Before finishing this second part of mine WSUS 3.0 posts I have two warnings to consider when applying Group Policies:

1 – If you apply the option on “Configure Updates” enabled and selecting “Auto download and notify for install”.

Combined with enabling the option “Remove links and access to Windows Update”, and you apply this combination on a OU that contains computers with Windows Vista operating system, the users on those computers won’t be able to install the updates.

It will notify that are new updates available for installation but the Windows Update panel disables the option for installation. So, if your patching process lets the users to decide when they want to install the updates, you must not configure (or set as disable) the option “Remove links and access to Windows Update”.

2 – If your plan is set to “Auto download and schedule the install” of the updates, keep in mind that most of the updates released by Microsoft, when they are installing on the operating system, often requires several of disk and processor usage; making an uncomfortable session if there’s a user on the computer at that moment. Maybe it’s not a bad idea to let the user decide when the updates must be installed. You will still have good control over the health status of each computer using the Windows Server Updates Services console.

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

Cheers!

Fortunately there’s a lot of information on Microsoft WSUS official site about almost anything you want to know about how to get started with this powerful tool:

WSUS 3.0 Overview

Step-by-Step: Getting Started with WSUS 3.0

Deploying WSUS 3.0

This post it’s intended to help about the WSUS first configurations and recommendations about how to use it.

When you install WSUS, the configuration wizard it’s pretty much self explained and with the Step-by-Step guide you shouldn’t have any problem.

The first warning that we can make at this point it’s about the “Specify Proxy Server” step. If you have one on your network, like an ISA Server 2006, remember that this server use the 8080 port when it works as a proxy. Configure this port on the WSUS, otherwise your connection will fail.

Always remember when you are selecting the languages of the updates and the products that you want to receive these updates, you should only select the ones that you actually need. Otherwise the duration of all synchronizations with Windows Update and the WSUS server will increase significantly.

Note:
The first synchronization of the WSUS server always takes a lot of time.

When you have your WSUS server online it’s time to configure your environment. Here are some of the best practices:

Best Practices

· Test phase first

Before applying any patch on your users’ computers or servers, you must always have a stage environment. Replicating all base computers or servers from which you will apply these updates. For example, using some Virtual Machines.

· Different users and different computers means different policies

If you are working with different type of clients on your organization (like with different OS, different schedules, etc) you should consider to set these clients with different policies to apply those updates.

You can accomplish this assigning, first, different Organization Units for workstations, mobiles, servers, etc. And then applying the correct Group Policies to each organization unit. You will add more layers to these configurations by creating different computers groups for approving updates.

· No computer, by any circumstance, must use Windows Update over the Internet

Apply different GPO levels that can assure you that any user or computer that it was just added to your domain use your WSUS server as the update point.

For example, in this case we apply a GPO for the domain that only specifies that the Windows Update process should be done only with our WSUS server; and on the different OUs of contoso.com we apply more restrictive policies for each case.

· Keep track of the updating process

Installing and configuring WSUS on your network won’t magically solve or improve all of the updates implementation. Be careful on the policies that you apply on which users and follow periodically the patching process. WSUS 3.0 improves significantly the reports view, making it easier to find out how many computers needs important updates.

Like this example: Shows all Vista Security Updates that are not installed yet on your computers groups.

I’ll be revisiting some of these best practices in other posts.

WSUS 3.0 Deployment and First Configurations (Part II)
WSUS 3.0 Deployment and First Configurations (Part III)

Cheers!