Microsoft Update as a Software Update Solution
Two questions are
pertinent when planning the deployment of any software update
technology. The first is, “How are software updates approved for
deployment?” and the second is, “Where are the update files stored and
retrieved from after they have been approved for deployment?” How you,
as the planner of your organization’s software update infrastructure,
answer these questions determines the type of solution to incorporate
into your designs.
The default
configuration of Windows Server 2008 and Windows Vista uses the
Microsoft Update servers, hosted by Microsoft and accessible across the
Internet, as the source of software update approvals and software update
files. When you use this method, the approval of updates is entirely
under Microsoft control. Although sole reliance on Microsoft Update
reduces an administrator’s workload, this method of software update
deployment has the following drawbacks in most enterprise environments:
Each update must be
downloaded separately to each client from the Microsoft Update servers.
In enterprise environments where there might be thousands of clients,
this can have a significant impact on bandwidth usage and cost.
This
method does not allow for testing updates to determine whether they
conflict with any existing applications within the environment. Although
Microsoft rigorously tests each update prior to deployment, the company
cannot test updates against unique custom software deployed in your
enterprise environment.
There
is no provision for centralized reporting. Administrators must use
software tools to scan all client computers to determine whether an
update has installed correctly. This data cannot be extracted directly
from the Microsoft Update servers.
There are certain times
when you should plan to use Microsoft Update as a complete software
update solution in your enterprise environment. These cases are specific
and apply to parts of the organization only, rather than to the
organization as a whole. Incorporate Microsoft Update into your patch
management design when you must plan for the following scenarios:
Your
organization has satellite offices or retail outlets where there are a
small number of standalone clients. In these circumstances, it is often
simpler to enable automatic updates on the clients than to attempt
centralized management.
Your
organization’s mobile computers rarely connect to the organizational
network, and a central list of approved updates would rarely be
accessed. In this situation, you would also use Network Access
Protection to ensure that when these mobile computers do connect to the
organizational network, their system health is verified before access is
granted to the protected network.
In many cases, it is
necessary to separate update approvals from update storage. Taking this
approach enables you to manage which updates are installed although the
update files themselves are downloaded from the Microsoft Update servers
on the Internet. You would plan this solution for satellite or branch
offices where you must exert control over the distribution of updates
but where there is not a strong case to store updates locally. Remember
that update approval traffic has only a small bandwidth footprint
whereas downloading update files can clog a slow wide area network (WAN)
link. For example, imagine that your organization has a small satellite
office that has fast Internet connectivity and a virtual private
network (VPN) WAN link to a branch office. In this situation, you can
configure client computers to poll a software update server for a list
of approved updates and then to obtain those updates from the Microsoft
Update servers on the Internet. A small amount of data is pulled across
the VPN WAN link, but the larger amount of update data is pulled across
the Internet link.
Windows Server Update Services as a Software Update Solution
Rather than
having each update downloaded multiple times to clients on the same
network, planning the deployment of WSUS enables you to configure the
update server settings so that the update server downloads the update
once, and clients retrieve the update from the WSUS server. Another
feature of WSUS offers administrators the ability to roll back the
installation of updates that have already been deployed. WSUS is not
limited to updates and can provide a local copy of all content that is
published on Microsoft Update. This includes drivers, service packs,
feature packs, and security updates.
WSUS 3.0 SP1 is the
first version of WSUS compatible with Windows Server 2008. Although not
included as a role or feature, the software itself is freely available,
and you can install the software
on licensed computers running Windows Server 2008. You cannot install
WSUS 3.0 SP1 on computers running a Server Core installation of Windows
Server 2008, although this functionality might be available in later
versions of the update server software. In the first exercise at the end
of this lesson, you will install WSUS 3.0 SP1 on a computer running
Windows Server 2008.
Managing WSUS
You can manage a WSUS
server locally or remotely by using the Update Services console. WSUS
uses administrative roles to assign permissions. Each role can perform a
specific set of functions, and you can assign roles to users by adding
their user accounts to one of the following local groups:
WSUS Administrators
Users who have accounts that are members of this local group are able
to administer the WSUS server. This includes WSUS administration tasks
from approving updates and configuring computer groups to configuring
automatic approvals and the update source of the server running WSUS. A
user who is a member of this group can use the Update Services console
to connect remotely to manage WSUS.
WSUS Reporters
Users who have accounts that are members of this local group are able
to create reports on the WSUS server. A user who is a member of this
group can connect remotely to the server running WSUS, using the Update
Services console to run these reports.
WSUS Deployment Hierarchies
Each WSUS 3.0 SP1
server is capable of providing software updates to 25,000 client
computers. This means that, in theory, a single WSUS server can service
the requests of all but the largest enterprise environments. In large
organizations, WSUS servers are usually deployed in each Active
Directory Domain Services (AD DS) site so that update and approval data
can be retrieved from a server on the local network rather than over WAN
links. You specify the WSUS server’s update source during installation.
Updates are stored locally on the WSUS server, or client computers use
the WSUS server for a list of approved updates and then download those
updates from the Microsoft Update servers on the Internet.
WSUS server
hierarchies involve an upstream server at the top of the hierarchy and
downstream servers that retrieve data from the upstream server. It is
possible to have multiple layers in the hierarchy, with each downstream
server using the server above it as a source of update approvals and
software update files. In many real-world WSUS deployments, the
hierarchy structure is used for the approval of updates only, and the
downstream servers retrieve the update files from the Microsoft Update
servers. This configuration is popular in organizations that have branch
offices connected to a head office by slow WAN links but where each
branch office
has a high-speed link to the Internet. In this configuration, approval
data travels to the branch office site across the WAN link, and update
files are downloaded from the Internet.
WSUS Administration Models
The administration
model determines how update approvals flow through the organization.
There are two options when configuring the administration model for your
organization’s downstream WSUS servers. The first option, shown in Figure 1,
is to configure the downstream WSUS server as a replica of the upstream
server. When you configure a WSUS server as a replica, all approvals,
settings, computers, and groups from the upstream server are used on the
downstream server. The downstream server cannot approve updates when
configured in replica mode, although you can change a replica server to
the second mode—called autonomous mode—if you urgently need to deploy an
update.
Autonomous mode
enables a local WSUS administrator to configure separate update
approval settings but still retrieves updates from the upstream WSUS
server. Autonomous mode conserves bandwidth for the organization by
ensuring that updates are downloaded only once from the Internet but retains the benefit of allowing local administrators discretion over the approval of updates.
When planning the
deployment of WSUS in an enterprise environment, it is likely that you
will need to use a mixture of autonomous and replica modes. For example,
an organization with two Active Directory forests shares a single
Internet connection. The organization wants to minimize the number of
updates downloaded from the Internet, but the administrators of each
forest want control over which updates are deployed in their
organization. To resolve this problem, you can place a WSUS server in
the first forest and configure it in autonomous mode. You can place a
second WSUS server in the second forest and configure it in autonomous
mode, but instead of drawing update files from Microsoft Update, these
files can be obtained from the WSUS server in the first forest. All
future WSUS servers deployed in each environment can then be configured
as replicas of their respective forest’s autonomous WSUS server.
WSUS Computer Groups
In the most basic form of
WSUS deployment, every computer that is a client of the WSUS server
receives approved updates at the same time. Although this method works
well for many organizations, other organizations prefer to perform
staggered rollouts of updates. Staggered rollouts, usually to a test
group of computers, enable organizations to determine whether a software
update has an adverse impact on their client computer’s configuration.
Internally developed custom software can conflict with an update in an
unforeseen manner.
By creating a test
group, you can deploy newly released updates to a special group of
computers in your organization so you can verify that new updates do not
conflict with existing deployed configurations. When you are confident
that the update causes no problems, you can roll out the update to all
clients in the enterprise.
WSUS computer groups have the following properties:
The two
default computer groups are All Computers and Unassigned Computers.
Unless a client computer is already assigned to a group, when it
contacts the WSUS server for the first time, it will be added to the
Unassigned Computers group.
Groups
can be organized in a hierarchy. An update deployed to a group at the
top of the hierarchy will also be deployed to computers that are in
groups lower in the hierarchy. The Unassigned Computers group is a part
of the All Computers hierarchy.
Computers can be assigned to multiple groups.
As Figure 2
shows, administrators can use two methods to assign computer accounts
to WSUS groups. The first method is known as server-side targeting. To
use this method, choose the Use The Update Services Console option under
Computers in the Options section of the Update Services console. A user
with WSUS Administrator privileges manually assigns computers in the
Unassigned Computers group to specific computer groups, using the WSUS
console.
The
other method of assigning computers to groups is to use Group Policy or
registry settings on clients of the WSUS server. This method, known as
client-side targeting, is less time-consuming in enterprise environments
and simplifies the group assignment process. Regardless of which method
you use to assign computers to groups, you must first create the groups
by using the WSUS console.
Update Installation Behavior
Other than the
policies that determine the assignment of computers to WSUS groups and
the location of the local WSUS server, the most important WSUS-related
group policies relate to how and when WSUS updates are downloaded and
installed. As an administrator, you want to avoid the situation of
updates never being installed—either because a user intervenes to cancel
update installation or because the updates are always scheduled to be
installed when the computer is off. You must balance interrupting a
user’s work with stopping user intervention. No one will be particularly
happy to lose several hours of work on an important spreadsheet because
you have configured the update settings to install and reboot the
computer without alerting the user in advance.
When scheduling update deployments, consider the following policy settings:
Enabling Windows Update Power Management To Automatically Wake Up The System To Install Scheduled Updates
This policy works only with instances of Windows Vista that are running
on compatible hardware and that have an appropriately configured BIOS.
Rather than worrying about whether reboots will interrupt users during
the update deployment
process, use this policy to awaken computers in the middle of the
night, deploy the relevant updates, and then return to sleep. This
policy works well in enterprise environments in which hundreds, if not
thousands, of computers are deployed, and finding a convenient time
during business hours is difficult.
Configure Automatic Updates
The Configure Automatic Updates policy enables you to specify whether
updates are automatically downloaded and scheduled for installation or
whether the user is simply notified that updates (either already
downloaded or on the WSUS server) are available.
Automatic Updates Detection Frequency
If this policy is not enabled, the default detection frequency is 22
hours. If you want to configure a more frequent interval, use this
policy to do so.
Allow Automatic Updates Immediate Installation
When enabled, this policy automatically installs all updates that do
not require a service interruption or for Microsoft Windows to restart.
No Auto-Restart For Scheduled Automatic Updates Installations
When this policy is enabled, the computer will not automatically
restart but will wait for the user to restart the computer on his or her
own time. The user will be notified that the computer needs to be
restarted before the installation of updates is completed. If this
policy is not enabled, the computer will automatically restart five
minutes after the updates are installed to complete update installation.
Delay Restart For Scheduled Installations
This policy enables you to vary the automatic restart period. As
mentioned previously, the default period is five minutes. This policy
enables you to set a delay period of up to 30 minutes.
Reschedule Automatic Updates Scheduled Installations
This policy ensures that a scheduled installation that did not
occur—perhaps because the computer was switched off or disconnected from
the network—will occur the specified number of minutes after the
computer is next started. If this policy is disabled, a missed scheduled
installation will occur with the next scheduled installation.
Planning Automatic Approvals
Part of planning a software
update infrastructure for an enterprise environment involves
determining the level of administrator intervention required during the
approval process. Automatic approval rules enable you to approve
specific categories of updates so that they are deployed without
requiring administrator intervention. You can configure updates to apply
to specific WSUS computer groups, for a specific classification, or for
specific products.
You can have multiple
automatic approval rules, and you can enable and disable them as
necessary. Configure automatic approval rules through the Automatic
Approvals dialog box shown in Figure 3,
which is available under Options in the Update Services console. By
default, no updates are automatically approved for distribution by WSUS
3.0 SP1.
Organizational
policy influences planning for automatic approval rules more than
technical reasons do. In organizations with highly customized software
configurations, a rigorous testing process is likely to be in place for
all updates, and automatic approval is unlikely to be enabled. In
organizations in which administrators do not test updates prior to
deployment, using automatic approval rules can minimize staff workload.
Planning the Deployment of WSUS in Enterprise Environments
The key question that you
must deal with in planning the deployment of WSUS in enterprise
environments is who is ultimately responsible for approving updates. In
some organizations, it can mean that you have to deploy multiple WSUS
servers configured in autonomous mode within the same domain; in other
organizations, multiple downstream replica servers deployed throughout
multiple forests might use a single autonomous WSUS server as an
upstream server.
The deployment
of WSUS servers themselves in enterprise environments is also dependent
on WAN bandwidth configuration. The branch offices of many organizations
have a direct connection to the Internet and WAN links, either through a
direct link or through a VPN tunnel, to their head office location. In
these situations, it makes little sense to pull the software update
files over the WAN when they can also be downloaded directly from the
Microsoft Update servers on the Internet.
