Defining Patch Options for Groups
Using the Install and Remove options, in conjunction with groups of test computers, gives you an easy mechanism to test new patches within your organization. You can push new patches to a selected group of test systems, evaluate the servers and their applications to make sure everything is still running properly, then deploy the patches throughout the rest of the organization.
The ability to group together sets of computers is a new feature of WSUS—one that SUS sorely lacked. SUS administrators typically didn't want to deploy the same set of patches to their servers that they'd deploy to desktops (for example, most servers don't need to have Windows Media Player—WMP—patched), so they invented creative workarounds for that situation, usually involving running multiple SUS servers within their organization. WSUS removes the need for using multiple SUS servers by letting administrators group computers together according to criteria that suit their organization. When you approve a patch for installation, you can define different options for different groups of computers. For instance, you might want to have servers detect only whether or not a patch is necessary initially, whereas end-user desktops have the patch installed automatically. You can designate multiple actions for each patch that WSUS stores and distinguish those actions by groups of computers.
Besides defining the appropriate detect, install, and remove options that you want to apply to a patch, you can define a date and time by which WSUS and Automatic Updates will force an installation if it hasn't already taken place. This capability is a lifesaver when the CIO wants a guarantee that the latest security hotfix can be deployed throughout the enterprise within a certain timeframe. To set a deadline for a patch, click the None option next to the Deadline field, which Figure 6 shows. Doing so displays the Edit Deadline dialog box that Figure 7 shows.
Basically, you have three options when it comes to considering a deadline for a patch: Let users apply it whenever they want to; let users apply it whenever they want to, but force an installation if a certain date and time pass; or force an installation immediately. To let users apply the patch when they want, simply leave the Deadline field set to None when you select to install a patch. To ensure that users perform an installation by a specific date and time, set the deadline in the Edit Deadline dialog box. After the specified deadline has passed, users will be required to install the patch. Finally, to force a patch out throughout your organization as quickly as possible, simply set date and time values to the current date and time, and all systems will start working on the update as soon as possible.
Configuring Clients
You'll need to make some configuration changes to Automatic Updates clients so that they can receive patches deployed by WSUS. You must reconfigure the clients to talk with your WSUS server instead of the default Windows Update server that Microsoft manages. By default, the Automatic Updates client will always try to attach to Microsoft's Windows Update server. However, with WSUS, you're effectively running your own version of Windows Update, so you'll need to reconfigure the client accordingly.
If you've ever configured Automatic Updates before, you might be thinking that you don't remember seeing anywhere that you could add or change a server name. You're right; to make these changes, we'll need to go into the registry. Start the registry editor and navigate to the HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows subkey. Under this subkey, you might find the WindowsUpdate subkey in your configuration. Don't worry if you don't see it; it might not exist on some systems because it isn't created by default. Create the HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate subkey, if it doesn't already exist. This subkey will be the container for two values that we'll create: one to tell Automatic Updates that it should look for a WSUS server, and another to tell Automatic Updates where it can find the WSUS server.
Next, under the WindowsUpdate subkey, you'll need to create a subkey called AU, then for the AU subkey a REG_DWORD value called UseWUServer that has a value of 1 (true). This value tells Automatic Updates to use a custom WSUS server instead of the standard Windows Update server that Microsoft maintains.
While you're still in the AU subkey, create an additional value of type REG_DWORD and name it AUOptions. This value defines how you want the Automatic Updates client to behave: Simply notify users that patches are available, notify and download the patches, or do a full installation. I recommend that you initially enter a value of 3 (notify and download); you can change the value later, if necessary.
Next, navigate back to the HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate subkey and add two REG_SZ values named WUServer and WUStatusServer. For both values, enter the URL for your WSUS server, as Figure 8 shows. These values tell Automatic Updates where it can find your custom WSUS server.
Of course, manually making registry changes to every workstation and server in your organization could be a considerable task. Therefore, I recommend that you use Group Policy to set these parameters, or distribute a .reg file within your organization (perhaps through a logon script) to apply the changes to each system you maintain.
While you're twiddling around in the registry to set these values, you might also want to change some of the other standard Automatic Updates client parameters. Those parameters, which Web Table 1 lists are stored in the HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU subkey.
Worry-Free Patching
Now you can sit back, relax, and watch WSUS do all the patch-deployment work for you! As long as you have a correctly configured implementation, WSUS can retrieve patches for you, approve them, and require them to be installed throughout your organization. The headaches of patching are a thing of the past, and I know that I sleep a little better knowing that I have a tool like WSUS available to help me when I need it most.
End of Article
Register
