1. Planning Your Software Updates Strategy
Deploying
patches successfully with any tool requires planning and preparation.
There are numerous aspects to consider, many of which depend on your
specific environment and user requirements. This section lists items to
consider when developing your patch management strategy:
Scope—
Start by determining which systems and applications to patch. Although
not updating all systems or applications for a particular flaw may pose
a security risk, there may be specific reasons not to patch a
particular piece of software (for example, due to third-party vendor
support, as described in the next bullet).
Third-party support—
Check with the vendors of your applications before applying patches.
Many vendors will not support their products if you apply a Windows
patch they have not tested with that product. Vendors may also issue
patches to a product because a Microsoft patch caused it to break. This
is vendor dependent, and varies from vendor to vendor.
Depending
on the severity of the flaw a patch addresses, you may have to weigh
the risk of not applying it versus the possibility of breaking the
application or going out of compliance with the vendor’s recommended
Windows patch level. Only you, in coordination with your user
population and other Information Technology (IT) support staff, can
decide to apply the patch.
Patch testing—
Testing patches before deploying them to your production systems is
highly recommended. Even if you do not have a full test environment at
your disposal, do not let that deter you from testing. At a minimum,
identify a group of systems for each patch category as your guinea
pigs. You might categorize this by operating system (such as Windows
Vista workstations or Windows 2008 servers) or hosted application (such
as PeopleSoft servers or Finance department workstations).
Deploy
patches to your identified test systems before the scheduled production
rollout of the patches, leaving you sufficient time to troubleshoot and
resolve any problems caused by the patches.
Coordination and scheduling—
Because Windows patches typically require a reboot, they do not lend
themselves to deployment during business hours. Coordinate with other
IT staff, server administrators, application administrators, your
users, and management to establish maintenance windows defining
acceptable times to reboot servers and workstations. Although
maintenance windows are useful for all types of system maintenance,
they are a definite requirement for patch management.
Do
not necessarily limit yourself to a single maintenance window for all
your systems, because deploying everywhere at once increases the risk
of a single bad patch affecting your entire environment. Additionally,
rebooting all your systems in a short period of time most likely will
result in unexpected side effects from resource dependencies or other
contention-type issues. As an example, if you patch your Domain Name
System (DNS) servers and they all reboot at the same time, clients will
not be able to resolve Internet Protocol (IP) addresses until those
servers are operational. This may, in turn, cause other applications
that rely on resolving IP addresses to fail.
Additionally,
there may be application-specific jobs that run at particular times.
Rebooting the system running the job or a remote system referenced by
the job may cause that job to fail. Examples of scheduled jobs include
accounting reports, payroll processing, and database maintenance.
Many
organizations include patch management in their established change
control process or create a process to deal with the many ramifications
of updates and patches.
Notification—
Always issue fair warning to anyone potentially affected by a patch
update or a system reboot. Even when you coordinate maintenance
windows, sending additional notifications to other administrators and
users to let them know what will transpire prevents a lot of finger
pointing and many sleepless nights. Consider using multiple
notifications from different sources and different channels.
Notifications from an IT manager, CIO, and such are also highly
recommended because they carry additional political weight and garner
more attention. As an example, an email blast from the IT manager and
an announcement on the company intranet or newsletter not only goes a
long way in preventing the “I didn’t know” excuse, but also actually
invalidates it!
Political policies and support—
IT professionals all know the risks of not patching systems and
applications. To implement a successful patching strategy, you must
have the political support in your organization to establish a policy
that dictates and enforces applying patches. Without such a top-down
policy, you will continue to face opposition to patching, not only from
users but also within IT. A policy enforced by your CIO (or equivalent)
will eliminate any quibbling over patching.
Compliance
regulations in the United States such as the Health Insurance
Portability and Accountability Act (HIPAA), Sarbanes-Oxley Act of 2002
(SOX), and Gramm-Leach-Bliley Act (GLBA) are another driver for
patching, eliminating any question about its necessity. Although none
of these compliance laws specifically requires patching, it is one of
the first things checked by auditors.
Based
on the information listed, plus other factors that may be unique to
your own organization or environment, consider developing a patch
strategy and policy document that include things such as a timeline,
rollback process, and testing procedure. Update this document every
month to indicate which patches are in scope, and distribute it as part
of your notification process.
The
recommendations in this section are applicable no matter which tool you
use to update and patch your systems, including the ITMU in SMS 2003.
However, the ITMU used with SMS 2003 and Software Updates in ConfigMgr
2007 are distinctly different tools using very different ways to get
the same job done. The next section discusses these differences.
2. Software Update Options in Microsoft Products
ConfigMgr
Software Updates replaces the ITMU feature pack used in SMS 2003 and
SMS 2.0. Microsoft designed ConfigMgr’s Software Updates to be a
first-class citizen in ConfigMgr 2007 and take advantage of the
built-in Windows Updates infrastructure. The following sections discuss
the Windows Update Agent used by WSUS and ConfigMgr as well as compare
the ConfigMgr patching process to that in ITMU and WSUS.
The Windows Update Agent
The
Windows Update Agent (WUA), in Windows operating systems since Windows
2000 Service Pack (SP) 1, provides a standard method to detect and
report patch applicability for Windows and other Microsoft
products—such as Office—on all Windows systems. Additionally, Microsoft
updates the agent regularly to ensure it can properly detect the need
for the latest available patches. You can configure the Windows Update
Agent manually or through group policy to detect, download, and apply
necessary patches automatically.
ConfigMgr
2007 uses the WUA to detect which patches are necessary on a system.
This eliminates using separate scanning tools, which frees up the
ConfigMgr administrator from maintaining these tools and Microsoft’s
ConfigMgr development team from creating and testing them. Using the
WUA also ensures consistent patch-scanning results between ConfigMgr,
Windows Server Update Services (WSUS), and manual patching.
The SMS Inventory Tool for Microsoft Updates
The
ITMU is an add-on that never seemed to fit well with the rest of
Microsoft’s SMS product. The ITMU incorporates a separate scanning tool
to detect when patches are necessary on managed systems. On occasion,
Microsoft has released separate scanning tools to detect if specific
patches are applicable because the base ITMU scanning tool did not
detect them. Using multiple scanning utilities causes the ITMU and
Windows Update to detect patch applicability differently, occasionally
causing discrepancies between the two tools when identifying necessary
patches.
Both the ITMU and ConfigMgr deliver and apply patches using packages. The ConfigMgr packages (called update packages) differ from the ITMU because they have their own branch in the Configuration Manager console, displayed in Figure 1. Unlike ConfigMgr software packages , update packages do not have programs, although
you must install the packages on distribution points (DPs) to use them.
The ITMU and Software Updates also download Microsoft’s catalog of available updates differently:
The ITMU uses a separate command-line tool that runs using a Software Distribution package.
Software
Updates integrates with an installation of WSUS, removing from
ConfigMgr the task of downloading the catalog from the Internet and
instead using the standard mechanism built in to WSUS. Managed systems
connect to this instance of WSUS to perform scans, although they do not
actually report results to it.
Standalone WSUS
With
a standalone installation of WSUS, clients are configured (either
manually or with group policy) to report their status to a WSUS server
and pull applicable updates from that WSUS server. Configuring when
updates are installed is somewhat limited, particularly if group policy
is not used. Reporting is also limited, and centrally managing and
deploying patches to systems connected through a wide area network
(WAN), Virtual Private Network (VPN), or the Internet is problematic.
Configuration Manager 2007
Using
Software Updates in ConfigMgr 2007 addresses the shortcomings of WSUS,
eliminates the requirement for ITMU, and utilizes the now ubiquitous
WUA. It also provides powerful and customizable reporting that
integrates with ConfigMgr’s asset management and inventory
capabilities. The next section begins discussing the steps required to
start using this new tool.
