The bane of every administrator's existence. The pain
in the rear of system management. That never-ceasing headache that
pounds at CIOs everywhere. You might have guessed by now that I'm
speaking of patch management.
And I use the term
"management" loosely. In 2003, there were more than 40 updates that
needed to be applied to a new Dell computer running Windows XP. There
were over 20 updates for Windows 2000 Service Pack 3 that needed to be
applied to new systems before Microsoft released Service Pack 4 in the
summer of 2003. And right now, machines running Windows XP Service Pack
2--released in summer of 2004--need around ten patches, including a
couple that require reboots—to get up to speed. This ever-growing
hairball of security fixes, bug fixes, critical updates, and patch
revisions has almost gotten to the point where it would be easier to
disconnect all machines from the Internet and work with stone tablets
than deploy new systems.
1. About Windows Server Update Services
As part of its
Strategic Technology Protection Program, Microsoft sought to leverage
its Windows Update technology—the software that runs the universal
update site for all but the oldest versions of Windows—and integrate it
into a LAN-based patch management solution. WSUS at this point does NOT
focus on adding new features to already released software; it's only
concerned with critical updates that allow administrators to somewhat
easily deploy critical updates to servers running Windows 2000 or
Windows Server 2003, and desktop computers running Windows 2000
Professional or Windows XP Professional. It's designed to work
especially in networks with an Active Directory implementation, but it
will function without one.
Installing WSUS on
your network requires at least one server, running either Windows 2000
Server or Windows Server 2003 connected to the Internet running the
actual server component of WSUS. This server needs, for all practical
purposes, at least a 1 GHz processor and 512 MB of RAM. This machine
acts as a local version of the public Windows Update site, which
contains critical updates and service packs for all supported operating
systems. This server synchronizes with the public Windows Update site on
a schedule that the corporate administrator selects. That administrator
then approves or rejects the availability of certain updates on the
WSUS server. You can also have multiple WSUS servers on an intranet and
configure which client machines are directed to specific WSUS servers
for updates.
On the client side,
WSUS also requires the Automatic Updates feature of Windows 2000
Service Pack 3 and higher, Windows XP Professional at any revision
level, or any edition of Windows Server 2003. Directed by a variety of
methods, the client computers that are running this Automatic Updates
feature are sent to the local network's WSUS server on a set schedule to
download updates appropriate to their machines. The WSUS server will
analyze the operating system, service-pack level, and any currently
installed updates, and push only those updates that are both needed AND
that have been approved by the administrator beforehand.
2. Using Windows Server Update Services: On the Server Side
There are a few phases to
the WSUS installation. First, you should download and install the
software, which includes the Windows SQL Server 2000 Desktop Engine
(WMSDE):
Download WSUSSetup.exe to a folder on the server where you want to install the product.
Double-click the file using the server on which you want to install or upgrade WSUS.
Click Next on the Welcome screen to continue.
Decide whether to accept or reject the license agreement, and click Next.
The
Select Update Source screen appears. Here, you can choose where the
client computers will get their updates. You can either allow the WSUS
server to store update content locally by clicking the Store updates
locally checkbox and selecting a location on your filesystem, or direct
clients to the Internet-based Microsoft Update site by leaving it
unchecked. Click Next to continue.
The
Database Options page is next, where you select the software used to
store information about the updates that are offered. Select the default
option of using WSMDE, which the wizard will install for you, unless
you have an available instance of a SQL Server 2000 database to use
instead. Click Next.
Next
comes the Web Site Selection page, where you specify the web site that
WSUS will use. Be careful to note the two important addresses presented
on this page: the URL that clients will use to get updates, and the URL
for the administrative console. If you're installing WSUS on a computer
that already has a web site running on port 80, you may need to create a
custom web site running on a different port. You can use IIS Manager
(in the Administrative Tools area of the Start menu) to accomplish this.
Click Next to continue.
You
should now see the Mirror Update Settings page, where you specify which
management role this WSUS server should serve. For the purposes of this
demonstration, you're installing the first WSUS server on your network,
so you can skip this screen. (It comes in handy when you have multiple
WSUS servers that should contain identical updates and approval records
within their databases.) Click Next to continue.
On the Ready to Install Windows Server Update Services screen, confirm your selections, and then click Next.
The next step is to make sure
that your WSUS server can receive update information from the Internet.
If you restrict Internet access via your firewall to certain domains,
be sure to add the following domains to your exceptions list:
2.1. The administrative console
To open the
administrative console for WSUS, open the Start menu, point to All
Programs, Administrative tools, and then select Microsoft Windows Server
Update Services. You can also open this console from your web browser
by surfing to http://WSUSServerName/WSUSAdmin.
You can also navigate through Start, All Programs, Administrative
Tools, and click Windows Software Update Services. You'll see something
much like that in Figure 1.
You may need to set a
proxy server configuration if you use such a system to connect to the
Internet. To do so, on the console toolbar, select Options, and then
click Synchronization Options. Select the Use a proxy server when
synchronizing checkbox in the Proxy server box, and then enter the
appropriate name and port number. (This form is used in much the same
way that you would Internet Explorer's options.) You can also enter
credentials should they be needed by clicking the Use user credentials
to connect to the proxy server box. To apply these settings, click Save
settings under Tasks, and then click OK to confirm this action.
2.2. Synchronizing content
When you start the content synchronization
process, which actually retrieves the updates for you to configure and
deploy, the WSUS server goes out to either the public Windows Update
servers or another local WSUS server (as configured in the "Mirror
Update Settings" section) and downloads the entire library of available
critical updates and service packs for each language you've configured.
This initial synchronization usually results in about 150 MB worth of
data being transferred for just
English updates, or close to
600 MB of data for updates in every localization. After that, WSUS is
able to determine if any new updates have been released since the last
time you synchronized.
To synchronize content, surf to the WSUS administrative web site, and then do the following:
On the toolbar, click Options.
Click the Synchronize Now button under Tasks to begin the transfer.
There are also some
advanced synchronization options that you can set, which can all be
found under Options on the toolbar and Synchronization Options. Under
Update Files and Languages, click Advanced, then read the warning and
click OK. Then, select your preferred option or options:
Use the "Download
updates to this server only when updates are approved" option to
determine if updates should be fetched from Microsoft Update during the
synchronization process itself, or if updates should be downloaded only
when an update is approved. This is a great bandwidth management
feature.
Use the
"Download express installation files" option to specify whether express
installation files should be downloaded during synchronization for
faster installation on client computers.
Use
the Languages section to filter updates that are written in languages
that aren't deployed on your network, so that when you synchronize,
bandwidth and time isn't wasted downloading patches for those localized
versions. You can choose to match the locale of the server, download all
localizations regardless, or to download updates in languages that you
specify in a list.
2.3. Creating a computer group
Computer groups are an important part of even the most basic WSUS
systems. Computer groups enable you to target updates to specific sets
of computers that likely share some common criteria. WSUS ships with two
default groups, called All Computers and Unassigned Computers. When
each client computer initially contacts the WSUS server , the server adds it to both these
groups. Of course, it's likely that you'll want to create your own
computer groups, since you can control the deployment of updates much
more granularly with them. For example, you can create a group named
Test that contains some lab machines. You can initially deploy a new
patch to the test group, and then, once you've verified the patch works
on those machines, roll it out to other groups. Since there's no limit
to the number of custom groups you can create, you can also block off
machines into departments, function, roles, or any other denominator you
wish to use.
Setting up computer
groups takes three steps. First, specify whether you intend to use
server-side targeting, which involves manually adding each computer to
its group by using WSUS; or client-side targeting, which involves
automatically adding the clients by using either Group Policy or
registry keys. Next, create the computer group on WSUS. Finally, move
the computers into groups by using whichever method you chose in the
first step.
In this section, I'll talk about server-side targeting, since it's the most likely method you'll use by far.
To specify that you'll use server-side targeting to select members of computer groups:
In the console toobar, click Options, and then click Computer Options.
Click "Use the Move computers" task in Windows Server Update Services in the Computer Options box.
Within Tasks, click Save settings, and then OK to confirm your selection.
Next, create a computer group. In this example, we'll create the Test group I mentioned earlier:
In the console toobar, click Computers.
Within Tasks, click "Create a computer group."
Enter test into the "Group name" box and then click OK.
Finally, add a machine
to that group. Of course, you'll need to follow the instructions within
the client-side portion to get the Automatic Updates
software deployed, which will populate the WSUS console with a list of
available computers. Once that's done, though, follow these steps to add
a machine to a group:
In the console toobar, click Computers.
In the Groups box, click the All Computers group, and then in the list, click the computer you want to move into the Test group.
Under Tasks, click "Move the selected computer," select the Test group, and click OK to perform the move.
And that's all there is to
it. Lather, rinse, and repeat until you have a group structure
appropriate to your network and deployment methodology.
2.4. Approving content
Now that you have an
actual library of updates on or near your WSUS host machine, and you've
defined a couple of computer groups, you can approve the updates
individually for distribution to client machines within your network.
The approval process makes it easy to withhold patches until further
testing is done, which partly assuages the general fear that's caused by
installing patches that might cause more problems than they fix. To
begin the update approval process, do the following:
In
the console toolbar, click Updates. On the resulting page, you'll see
only critical and security updates that have been approved for use on
client computers; this is by virtue of a filter that you can later
adjust to view only updates relevant to what you're currently
administering.
Within
the update list, select the updates that you would like to approve. You
can click the Details tab for more information about the updates, and
you can select multiple updates at one time using the shift key.
When you've finished your selection, click "Change approval" under Update Tasks.
The Approve Updates dialog box appears. Click Install within the Approval column for the Test group, and then click OK.
WSUS will notify you
when the approval is complete. In the righthand pane, where all the
updates are shown, each patch's status is shown as one of five possible
values. A new update is one that was just recently downloaded and hasn't
been approved yet. An approved update is available for distribution to
each client machine. An update that isn't approved will not be
distributed to clients, but the actual patch file remains in the library
on the WSUS host machine. An updated patch indicates a new version of
an earlier patch that currently exists in the library. And finally, a
temporarily unavailable patch is one whose dependent files were
downloaded incorrectly, could not be found, or were otherwise unable to
be located by WSUS.
If, for some reason, you
would like to clear the list of approved updates, you can clear all
checkboxes on the list of available updates and then click Approve. This
will remove any available updates from the WSUS catalog, and your
client machines will stop downloading the updates until you approve more
fixes. This will not, however, uninstall the patches from the client
machines.
2.5. Checking the status of update deployments
Once a full 24 hours has
passed, you can check the status of the approved update deployment. On
the console toolbar, click Reports, and then on the resulting page,
click Status of Updates. You can apply a filter by adjusting the
settings under View, and you can change the view (perhaps to see the
status of an update by computer group and then by computer, for example)
by adjusting the controls on that page.
You can also print a status report by clicking "Print report" under Tasks.
2.6. Pushing out the automated updates client
Once your client
computers first contact the WSUS server, the latest Automatic Updates
software installed on your client computers will self-update to the
latest version. There is one exception to this: the version of Automatic
Updates included with Windows XP without any service packs cannot
update itself automatically. You'll need to manually push this out via
Group Policy, a login script, or "sneakernet"-style management.
You can install
the updated Automatic Updates client on your clients by using the MSI
install package, self-updating from the old Critical Update Notification
(CUN) tool, installing Windows 2000 Service Pack 3 or 4, installing
Windows XP Service Pack 1 or 2, or installing Windows Server 2003.
You can download the Automatic Updates client from the Microsoft web site at the WSUS web page, located at http://www.microsoft.com/WSUS. On a standalone machine, the AU client can simply be added by running the MSI file on the machine.
Manually installing a
file can quickly become a pain when you have more than just a few
machines to handle. Fortunately, because the client installation program
is in the form of an MSI, you can easily push the program to clients by
using Group Policy. To create a new GPO, assign it to your computers,
and then have it installed automatically:
Open the Active Directory Users and Computers MMC snap-in.
Right-click the domain or organizational unit to which you're interested in deploying the client, and select Properties.
Click the Group Policy tab.
Click New to create a new Group Policy object (GPO). Type in a name for the GPO.
Select the new GPO from the list, and click Edit to open the Group Policy Object Editor.
Expand Computer Configuration, and then select Software Settings.
Right-click Software Installation in the left pane, select New, and then click Package.
Enter
the path to the Automatic Updates MSI file you downloaded from the web.
Make sure you use a network path and not a local path to ensure that
your clients can find the file at boot time. Click Open.
Choose Assigned to assign the package to the computers in the domain or organizational unit, and then click OK.
Allow time for polices to replicate through the domain. Usually this is accomplished within 15 minutes.
Restart
the client computers. The client software should be installed before
the Logon dialog box is displayed, although on Windows XP machines you
might need to reboot up to three times for the software installation
policy to take effect (this is because of the fast logon optimization
feature).
The
application will be installed in the context of the local computer, so
make sure that authenticated users have rights on the source folders. |
|
You can also deploy the
client MSI through a logon script by calling MSIEXEC followed by the
client software file name as an argument. The software will be installed
as requested.
2.7. Configuring the automatic updates client
The Automatic Updates
client doesn't have any user-interface options for determining the
origin of updates to install. You must set this with either a Registry
change on each of the client computers or through Group Policy, either
locally or based through a domain. Once the changes take effect, you'll
be able to see the machines within the Computers page of the WSUS
console.
Through a domain-based Group Policy, direct clients to the WSUS server by using the following procedure:
Open the Default Domain Policy GPO in Active Directory Users and Computers and click the Edit button.
Expand Computer Configuration, Administrative Templates, and Windows Components.
Select Windows Update. The right pane will contain four options that pertain to the Automatic Updates client, as depicted in Figure 2.
These options are described here in more detail:
Configure Automatic Updates
This option
specifies whether this computer will receive security updates and
critical bug fixes. The first option makes sure that the currently
logged-on user is notified before downloading updates. The user will
then be notified again before installing the downloaded updates. The
selcond option ensures that updates will automatically be downloaded,
but not installed until a logged-on user acknowledges the updates'
presence and authorizes the installation. The third option makes sure
that updates are automatically downloaded and installed on a schedule
that you can set in the appropriate boxes on the sheet. The fourth
option, which will only appear if the AU software has updated itself to
the version compatible with WSUS, allows local administrators to use AU
in Control Panel to select their own configuration. To use this setting,
click Enabled, and then select one of the options.
Specify Intranet Microsoft Update Service Location
This option
designates a WSUS server from which to download updates. To use this
setting, you must set two server name values: the server from which the
Automatic Updates client detects and downloads updates, and the server
to which updated workstations upload statistics. You can set both values
to be the same server.
Enable Client-Side Targeting
This option
enables client computers to automatically populate groups on thw SUS
server. To use this option, click the Enabled option and then type the
name of the group to which this computer should belong on the WSUS and
then click OK. Keep in mind that you need to actually create the group
on the WSUS server for this to take effect.
Reschedule Automatic Updates Scheduled Installations
This option
specifies the amount of time to wait after booting before continuing
with a scheduled installation that was missed previously for whatever
reason (power outage, system powered off, network connection lost, and
so on). If the status is set to Enabled, a missed scheduled installation
will occur the specified number of minutes after the computer is next
started. If the status is set to Disabled or Not Configured, a missed
scheduled installation will simply roll over to the next scheduled
installation.
No Auto-restart for Scheduled Automatic Updates Installations
This
option designates whether a client computer should automatically reboot
or not when an update that's just installed requires a system restart.
If the status is set to Enabled, Automatic Updates will not restart a
computer automatically during a scheduled installation if a user is
logged in to the computer. Instead, it will notify the user to restart
the computer to complete the installation. If the status is set to
Disabled or Not Configured, Automatic Updates will notify the user that
the computer will automatically restart in five minutes to complete the
installation.
Automatic Update Detection Frequency
This option
details the hours that Windows will use to figure out how long to wait
before contacting the WSUS server to see if new updates are available.
This time is actually determined by using the hours specified in this
option and subtracting anywhere from zero to 20% of the hours specified.
This offset helps to manage load. If the status is set to Enabled, you
need to specify the number of hours; if it's set to Disabled or Not
Configured, AU will check for new updates every 22 hours.
Allow Automatic Update Immediate Installation
This option
specifies whether AU should automatically install updates that don't
interrupt Windows or need a reboot. If you enable this option, AU will
auto-install such updates; if you disable it, they will not be
immediately installed.
Delay Restart for Scheduled Installations
This setting defines
the amount of time AU will wait before executing a scheduled reboot. If
this setting is enabled, the scheduled restart will happen after the
number of minutes you specify. If this setting is disabled or not
configured, the default waiting period is five minutes.
Re-Prompt for Restart with Scheduled Installations
If this setting
is enabled, a scheduled restart will occur in the specified number of
minutes after the prompt for restarting was postponed by the user. If
this setting is disabled or not configured, the scheduled restart will
take place ten minutes after the first prompt.
Allow Non-Administrators to Receive Update Notifications
If this setting is
enabled, all users can receive notifications that updates are ready for
download and/or installation. If this setting is disabled or not
configured, AU will notify only logged-on administrators that pending
update action is necessary.
Remove Links and Access to Windows Update
If this setting
is enabled, end users cannot get updates from a Windows Update web site
that you have not approved. If this policy is not enabled, the Windows
Update icon remains in place for local administrators to visit. Such
local administrators can in fact install unapprovcd updates.
You will want to allow
10 to 15 minutes for the changes to the domain's policy to replicate
among all domain controllers. To manually initiate detection of these
client machines, on the client, open a command prompt and type
wuauclt.exe /detectnow.
To adjust the Group
Policy on a machine that isn't managed by Active Directory, you need to
load the appropriate templates into the Microsoft Management Console.
Follow these steps:
Click Start, select Run, and type GPEDIT.msc to load the Group Policy snap-in.
Expand Computer Configuration and Administrative Templates.
Click Add/Remove Templates, and then click Add.
Enter
the name of the Automatic Updates ADM file, which you can find in the
INF subdirectory within your Windows root. In addition, you can find it
in the INF subdirectory within the WSUS server machine's Windows root.
Click Open, and then click Close to load the wuau.adm file.
You can now adjust the policy settings as described in the previous subsection.
Finally, to adjust some
of these behavior settings through Registry changes, use the appropriate
key for each of the following settings:
To enable or disable Automatic Updates: Create the value NoAutoUpdate in the key:
- HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU
The value is a DWORD with possible values zero (enabled) or one (disabled).
To configure the update download and notification behavior: Create the value AUOptions in the key:
- HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU
The
value is a DWORD that includes integers 2 (notify of download and
notify before installation), 3 (automatically download but notify before
installation), 4 (automatically download and schedule the
installation), and 5 (let the local administrator choose the setting).
To schedule an automated installation: Create the values ScheduledInstallDay and ScheduledInstallTime in the key:
- HKEY_LOCAL_ _MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU
The value for each is a DWORD. For ScheduledInstallDay,
the range is from 0 to 7, with 0 indicating every day and 1 through 7
indicating the days of the week, Sunday through Saturday. For ScheduledInstallTime, the range is from 0 to 23, signifying the hour of the day in military time.
To specify a particular WSUS server to use with the Automatic Updates client: Create the value UseWUServer in the key:
- HKEY_LOCAL_MACHINE\_SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU
The value is a DWORD; set it to 1 to enable the custom WSUS server name. Then, create the values WUServer and WUStatusServer in the same key, of types Reg_SZ, and specify the name (with the http://) as the value.
To specify how long to wait before completing a missed installation: Create the value RescheduleWaitTime in the key:
- HKEY_LOCAL_MACHINE\_SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU
The value is a DWORD that ranges from 1 to 60, measured in minutes.
To specify whether to restart a scheduled installation with a currently logged-in nonadministrative user: Create the NoAutoRebootWithLoggedOnUsers value in the key:
- HKEY_LOCAL_ _MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU
The
value is a DWORD that can be 0, which indicates that a reboot will
indeed take place, or 1, which indicates the reboot will be postponed
while a user is logged on.
