You are on page 1of 23

Check IT List: Seven steps for a patch

management process

Patch management is a never-ending process. In the last few years, virulent code such as Code Red, Nimda,
Nachi, SoBig, Blaster and Slammer has hammered networks. Many of these malicious programs had
patches available long before the exploit code was released. Introduce these to a small or midsize business,
and you've got big time problems with little resources to fix them.

Patch management takes a lot of time to set up, and it's not cheap. However, it's well worth the investment
up front. Here are some guidelines for implementing a patch management process.

1. Develop a complete network inventory. Create a list of what systems run what software. This may
take some time, but the results will be worth it.
2. Implement a change control policy. An inventory list is only effective if you can track and control
changes to your network.
3. Monitor for new vulnerabilities and patches that are available for the inventory you've identified.
4. Test the patches. Develop a well-defined deployment process. If you can't afford a lab, try to
duplicate mission-critical processes.
5. Include when and where patches are deployed in your inventory control system.
6. Make a list of sites that you can use to review the latest vulnerabilities. Several sites worth checking
out are Microsoft; Mitre; CERT; and NIST.
7. Look into the various software tools that help manage patch deployment. Vendors such as Big Fix,
Computer Associates, ConfigureSoft, IBM, Microsoft, Shavlik Technologies and St. Bernard
Software are just some of the companies that offer these tools.

Improving Web Application Security: Threats and Countermeasures

J.D. Meier, Alex Mackman, Michael Dunner, Srinath Vasireddy, Ray Escamilla and Anandha Murukan

Microsoft Corporation

Published: June 2003

Last Revised: January 2006

See the "patterns & practices Security Guidance for Applications Index" for links to additional security
resources.

See the Landing Page for the starting point and a complete overview of Improving Web Application
Security: Threats and Countermeasures.

Summary: This How To explains patch management, including how to keep single or multiple servers up to
date. Additional software is not required, except for the tools available for download from Microsoft.
Operations and security policy should adopt a patch management process. This How To defines the
processes required to create a sound patch management system. The patch management process can be
automated using the guidance in this How To.

Contents

This How To shows you how to implement each phase of the patch management process. These phases
include:

What You Must Know Before You Begin Detecting Assessing Acquiring Testing Deploying Maintaining
Additional Resources

What You Must Know


Before using this How To, you should be aware of the following issues and considerations.

The Patch Management Process

Patch management is a circular process and must be ongoing. The unfortunate reality about software
vulnerabilities is that, after you apply a patch today, a new vulnerability must be addressed tomorrow.

Develop and automate a patch management process that includes each of the following:

• Detect. Use tools to scan your systems for missing security patches. The detection should be
automated and will trigger the patch management process.
• Assess. If necessary updates are not installed, determine the severity of the issue(s) addressed by
the patch and the mitigating factors that may influence your decision. By balancing the severity of
the issue and mitigating factors, you can determine if the vulnerabilities are a threat to your current
environment.
• Acquire. If the vulnerability is not addressed by the security measures already in place, download
the patch for testing.
• Test. Install the patch on a test system to verify the ramifications of the update against your
production configuration.
• Deploy. Deploy the patch to production computers. Make sure your applications are not affected.
Employ your rollback or backup restore plan if needed.
• Maintain. Subscribe to notifications that alert you to vulnerabilities as they are reported. Begin the
patch management process again.

The Role of MBSA in Patch Management

The Microsoft Baseline Security Analyzer (MBSA) is a tool that is designed for two purposes: first, to scan a
computer against vulnerable configurations; and second, to detect the availability of security updates that
are released by Microsoft.

In this How To, you use MBSA without scanning for vulnerable configurations. When using the graphical user
interface (GUI), specify this by unchecking the options in Figure 1 and only choosing Check for security
updates.
Figure 1

MBSA scan options

When using the command line interface (Mbsacli.exe), you can use the following command to scan only
missing security updates.

Mbsacli.exe /n OS+IIS+SQL+PASSWORD

The option /n specifies the checks to skip. The selection (OS+IIS+SQL+PASSWORD) skips the checks for
vulnerabilities and weak passwords.

For more details about using MBSA, including the security configuration scan, see "How To: Use MBSA" in
the How To section of this guide.

Backups and Patch Management

You should perform backups prior to deploying an update on production servers. Regularly test backups as
well as your backup process. Discovering that your backup process is broken during restoration can be
devastating.

Before You Begin


This section provides information about downloads and documentation that are needed before you walk
through the steps in this How To.

Tools You Will Need

You need the following tools in order to be able to perform the steps in this How To:

• Microsoft Baseline Security Analyzer (MBSA)

Download MBSA from the MBSA Home Page:


http://www.microsoft.com/technet/security/tools/Tools/mbsahome.asp

• Latest Mssecure.cab

By default, MBSA downloads the latest update list (Mssecure.cab) from Microsoft.com. If you do not
have Internet access from the computer running MBSA, you must download the file and copy it to
the MBSA installation directory. You can download the update file from:
http://technet.microsoft.com/en-us/security/cc184923.aspx

• Microsoft Software Update Service (SUS)

Microsoft Software Update Services (SUS) Server 1.0 Service Pack 1 (SP1) enables administrators to
deploy critical updates to Windows 2000-based, Windows XP, and Windows Server 2003 computers.
You can download it from: [Content link no longer available, original
URL:"http://www.microsoft.com/downloads/details.aspx?FamilyId=A7AA96E4-6E41-4F54-972C-
AE66A4E4BF6C&displaylang=en"]
Detecting
Use MBSA to detect missing security patches for Windows 2000, Windows XP, and Windows Server 2003.
You can use MBSA in two modes; GUI and command line. Both modes are used to scan single or multiple
computers. The command line can be scripted to run on a schedule.

Note The login used to run MBSA must be a member of the Administrators group on the target
computer(s). To verify adequate access and privilege, use the command net use \\computername\c$
where computername is the network name of a machine which you are going to scan for missing patches.
Resolve any issues accessing the administrative share before using MBSA to scan the remote computer.

To manually detect missing updates using the MBSA graphical interface

1. Run MBSA by double-clicking the desktop icon or by selecting it from the Programs menu.
2. Click Scan a computer. MBSA defaults to the local computer. To scan multiple computers, select
Scan more than one computer and select either a range of computers to scan or an IP address
range.
3. Clear all check boxes except Check for security updates. This option detects uninstalled patches
and updates.
4. Click Start scan. Your server is now analyzed. When the scan is complete, MBSA displays a security
report and also writes the report to the %userprofile%\SecurityScans directory.
5. Download and install the missing updates.

Click the Result details link next to each failed check to view the list of uninstalled security updates.
A dialog box displays the Microsoft security bulletin reference number. Click the reference to find out
more about the bulletin and to download the update.

To detect missing updates using the MBSA command line interface

• From a command window, change directory to the MBSA installation directory, and type the
following command:
• mbsacli /i 127.0.0.1 /n OS+IIS+SQL+PASSWORD

You can also specify a computer name. For example:

mbsacli /c domain\machinename /n OS+IIS+SQL+PASSWORD

You can also specify a range of computers by using the /r option. For example:

mbsacli /r 192.168.0.1-192.168.0.254 /n OS+IIS+SQL+PASSWORD

Finally, you can scan a domain by using the /d option. For example:

mbsacli /d NameOfMyDomain /n OS+IIS+SQL+PASSWORD

To analyze the generated report

1. Run MBSA by double-clicking the desktop icon or by selecting it from the Programs menu.
2. Click Pick a security report to view and open the report or reports, if you scanned multiple
computers.
3. To view the results of a scan against the target machine, mouse over the computer name listed.
Individual reports are sorted by the timestamp of the report.
As previously described, the advantage of the command line method is that it may be scripted and
scheduled to execute. This schedule is determined by the exposure of your systems to hostile networks, and
by your security policy.

MBSA Output Explained

The following example was taken using the MBSA version 1.1.

Figure 2

Screenshot of the report details for a scanned machine

The top portion of the MBSA screenshot shown in Figure 2 is self explanatory.

Red crosses indicate that a critical issue has been found. To view the list of missing patches, click the
associated Result details link.

The results of a security update scan might show two types of issues:

• Missing patches
• Patch cannot be confirmed

Both types include links to the relevant Hotfix and security bulletin pages that provide details about the
patch together with download instructions.

Missing patches are indicated by a red cross. An example is shown in Figure 3.

Figure 3

Missing patch indication


When a patch cannot be confirmed, it is indicated by a blue asterisk. This occurs when your system has a
file that is newer than the file provided with a security bulletin. This might occur if you install a new version
of a product that updates a common file.

Figure 4

Patch cannot be confirmed indication

For updates that cannot be confirmed, review the information in the bulletin and follow the instructions. This
may include installing a patch or making configuration changes. For more information on patches that
cannot be verified by MBSA, see Microsoft Knowledge Base article, 306460, "HFNetChk Returns Note
Messages for Installed Patches."

Assessing
With the list of missing patches identified by MBSA, you must determine if the vulnerabilities pose a
significant risk. Microsoft Security Bulletins provide technical details to help you determine the level of
threat the vulnerability poses to your systems.

The details from security bulletins that help you assess the risk of attack are:

• Technical details of requirements an attacker needs to exploit the vulnerability addressed


by the bulletin. For example, an attack may require physical access or the user must open a
malicious email attachment.
• Mitigating factors that you need to compare against your security policy to determine your
level of exposure to the vulnerability. It may be that your security policy mitigates the need to
apply a patch. For example, if you do not have the Indexing Service running on your server, you do
not need to install patches to address vulnerabilities in the service.
• Severity rating that assists in determining priority. The severity rating is based on multiple
factors including the role of the machines that may be vulnerable, and the level of exposure to the
vulnerability.

For more information about the severity rating system used by the security bulletins, see the
TechNet article, "Microsoft Security Response Center Security Bulletin Severity Rating System" at
http://www.microsoft.com/technet/security/bulletin/rating.mspx

Note If you use an affected product, you should almost always apply patches that address
vulnerabilities rated critical or important. Patches rated critical should be applied as soon as
possible.

Acquiring
There are several ways you can obtain patches, including:

• Using MBSA report details. MBSA links to the security bulletin that contains the patch, or
instructions about obtaining the patch. You can use the link to download the patch and save it on
your local network. You can then apply the patch to multiple computers.
• Windows Update. With a list of the updates you want to install, use Internet Explorer on the server
that requires the patch, and access http://windowsupdate.microsoft.com/. Then select the required
updates for installation. The updates are installed from the site and cannot be downloaded
for installation on another computer. Windows Update requires that an ActiveX control is installed on
the server (you will be prompted when you visit the site if the control is not found.) This method
works well for standalone workstations or where a small number of servers are involved.
• HotFix & Security Bulletin Search. MBSA includes the Microsoft Knowledge Base article ID of the
corresponding article for a given security bulletin. You can use the article ID at the HotFix and
Security Bulletin Search site to reach the matching security bulletin. The search page is located at
http://www.microsoft.com/technet/security/current.aspx. The bulletin contains the details to acquire
the patch.

Testing
If the results of your assessment determine that a patch must be installed, you should test that patch
against your system to ensure that no breaking changes are introduced or, if a breaking change is expected,
how to work around the change.

Methods for Testing Security Patches

Methods used to test the installation of security patches against your systems include:

• Testing security patches against a test mirror of your live server configuration and
scenario. This method allows you to both test the installation offline, without disrupting service, and
the freedom to test workarounds if a breaking change is introduced, again without disrupting
service.
• Testing the patch on a few select production systems prior to fully deploying the update. If
a test network that matches your live configuration is not available, this is the safest method to
introduce the security patch. If this method is employed, you must perform a backup prior to
installing the update.

Confirming the Installation of a Patch

Before deploying a patch to production servers, confirm that the tested patch has made the appropriate
changes on the test servers. Each security bulletin includes the information you need to confirm that the
patch has been installed. In each bulletin, the Additional information about this patch section contains
the entry Verifying patch installation. It includes registry values, file versions, or similar configuration
changes that you can use to verify that the patch is installed.

Uninstalling a Security Patch

If you need to uninstall a patch, use Add/Remove Programs in the Control Panel. If an uninstall routine is
not an option for the patch and its installation introduces breaking changes, you must restore your system
from backup. Make sure that your testing process also covers the patch uninstall routine.

The security bulletin lists the availability of an uninstall routine in the Additonal information about this
patch section.

Deploying
If you decide that the patch is safe to install, you must deploy the update to your production servers in a
reliable and efficient way. You have a number of options for deploying patches throughout the enterprise.
These include:

• Using Windows Server Update Services (WSUS)


• Using Systems Management Server (SMS)
Using Windows Server Update Services (WSUS)

WSUS provides a way to automatically deploy crucial updates and security rollups to computers throughout
a network, without requiring you to visit each computer or write script. For more information about WSUS,
see "Windows Server Update Services Product Information" at http://technet.microsoft.com/en-
us/wsus/bb466202.aspx.

Using Systems Management Server (SMS)

SMS is an enterprise management tool for delivering configuration and change management of Microsoft
Windows server and workstation operating systems. For more information about using SMS to deploy
updates, see TechNet article, "Patch Management Using Microsoft Systems Management Server" at
http://technet.microsoft.com/en-us/solutionaccelerators/default.aspx.

Maintaining
Bringing your servers up to date with the latest patches is part of the patch management cycle. The patch
management cycle begins again by knowing when new security vulnerabilities are found and missing
security updates become available.

Keeping your servers up to date with the latest security patches involves this entire cycle. You start the
cycle again by:

• Performing security assessments


• Using security notification services

Performing Security Assessments

Use MBSA to regularly check for security vulnerabilities and to identify missing patches and updates.
Schedule MBSA to run daily and analyze the results to take action as needed. For more information about
automating MBSA, see "How To: Use MBSA" in the How To section of this guide.

Using Security Notification Services

Register to receive notifications of security bulletins released by Microsoft. Use the following services:

• Microsoft Security Notification Service at http://technet.microsoft.com/en-


us/security/dd252948.aspx.
• TechNet security Web site at http://technet.microsoft.com/en-us/security/default.aspx

Additional Considerations

When bringing a new service online on an existing server, run MBSA to verify the patches for the service
have been applied prior to having the server and service listening on the network. For example, disconnect
the network cable or apply network based rules that block the newly added service's ports.

Additional Resources
For related information, see the following resources:

• For more information about Software Update Services, see:


o The WSUS homepage at http://technet.microsoft.com/en-us/wsus/bb466202.aspx.
o TechNet article, "Patch Management Using Microsoft Software Update Services" at
http://technet.microsoft.com/en-us/solutionaccelerators/default.aspx.
o Software Update Services Deployment white paper at http://technet.microsoft.com/en-
us/wsus/bb466200.aspx
o Download Windows Server Update Services page at [Content link no longer available, original
URL:"http://www.microsoft.com/downloads/details.aspx?FamilyId=A7AA96E4-6E41-4F54-
972C-AE66A4E4BF6C&displaylang=en"]
http://www.microsoft.com/windowsserversystem/updateservices/downloads/WSUS.mspx.

Microsoft patch management policy


24 Sep 2007 | SearchWindowsSecurity.com

Advice for securing Windows


Digg This! StumbleUpon Del.icio.us

The Windows Patch Management Tutorial is designed to give you a one-stop comprehensive resource for
all of your Microsoft patching needs. In the first section of our tutorial, learn about setting patch
management policy, prioritizing your patching process, managing a testing budget and the pros and cons of
using third-party patch management tools.

Windows patch management policy


Windows patch maintenance and post-patch security
Windows patch management tools

Windows patch management policy

Prioritizing Windows desktop patches

This list covers the major categories of things that can be patched or updated in a typical desktop
configuration and the order in which you should apply them whenever possible. Patch your systems in this
order and your patch management policy will be stronger than ever.

1. Bios: As with servers, start here. Managing BIOS updates across multiple systems is all the easier
when they're of the same make and manufacturer, but it requires "hard" downtime: The computer has
to be powered down and rebooted to apply the new BIOS, and the administrator usually has to baby-
sit each system individually that will be upgraded. Fortunately, many PC manufacturers now allow
centralized updates to BIOSes through a management application -- Altiris, for instance, has a
management solution for Dell desktops and notebooks that allows remote BIOS updates.
2. Device BIOSes: These include things like BIOS updates for disk controllers, video cards or other
devices. Device BIOS updates go into a separate category from regular BIOS updates for two
reasons: One, they are easy to overlook and not often considered for desktops; two, you usually
cannot update them en masse. For example: If you're administering a group of graphical
workstations that need updates to their video card's BIOSes -- and the only way to do that is via a
16-bit DOS-based updater -- you'll probably have to do that by hand for each computer. However, if
you could perform the update through a 32-bit Windows application, you could probably push out
your Windows patches as you would any other update.
3. Device drivers: As with servers, one of the more common hardware device-driver updates published
for a desktop computer is for the network controller. Make sure you test the update ahead of time. If
you automate patching on a whole slew of machines with such a driver and the end result is that
they're all knocked off the network, your only choice might be to either re-image them from scratch
or fix each one manually.
4. The OS: Patching Windows OSes is the part almost everyone is directly familiar with and it needs
relatively little elaboration here. One thing I'll add is something I also wrote about in the server
version of this article: If there are device driver updates, they should be examined separately from
other updates in case an OEM-provided version of the driver is more urgently needed.
5. Middleware: This normally includes elements such as ODBC drivers but should also include things
like the Microsoft .NET Framework. Note that with the .NET Framework, the 1.1 and 2.0 iterations
(and the upcoming 3.0 edition as well) exist side-by-side and don't eclipse each other.
6. Application patches: As with the OS and its attendant patches, you can roll out application patches
through the usual automated mechanisms, and it should be done only after everything else has
already been applied.

Managing your patch testing budget

The biggest Windows patch management costs related to creating a test lab are hardware and software.
Although both are necessities, there are some ways that you can really hold down the costs. Let's talk about
the hardware first.

One way you can economize on hardware is to purchase PCs instead of servers. If all you do is test the
impact of occasional patches, then you don't need things like multiple processors and RAID arrays. You can
save an absolute fortune just by using a basic PC with plenty of disk space and memory for testing purposes.

Another cost-saving technique is to use virtual machines. Products such as Microsoft's Virtual Server 2005
and VMware from VMware Inc. allow you to simultaneously run multiple virtual computers on a single
physical computer.

Reduce cost of Microsoft patch management software

Try using Windows patch evaluation software in your lab. Microsoft offers 120-day evaluation copies of
most of their products for free. Therefore, if you are testing an entire patch management configuration, a
single patch, an upgrade or whatever for less than 120 days, you could just download some evaluation
software and not have to worry about the cost.

If you are going to be testing for an extended amount of time, one option is to get an MSDN subscription. A
subscription to MSDN Universal costs about $2,000. That sounds like a lot of money but, along with the
subscription, you receive multiple licenses for almost all of Microsoft's products. I don't know what
Microsoft's official policy is regarding using MSDN software in testing labs, but because MSDN is intended
for developers, I'm pretty sure that using MSDN software in a test lab would be allowed by the license
agreement.

Using third-party patches


Most of us have been there before. It's the beginning of the month, Patch Tuesday is about ten days away
and we hear about a new exploit that we know we are susceptible to. At such a time, it's frustrating to know
we have to wait for the second Tuesday of the month before a software fix arrives. You might think that
deploying a third party patch is a good idea. Well, sometimes it is. And sometimes it isn't.

The cons of third-party patches

IT administrators deploying off-cycle patches from third parties, in many instances, will have no idea what
the patch contains. So before you consider deploying an off-cycle patch, you should ask yourself how much
you trust the company that produced it. Even patches from a company without any malicious intent can
inadvertently be infected by malicious code.

In the worst case, if a company producing third-party patches has less than honorable intentions, it
potentially could distribute a patch containing spyware or code that makes it easier to exploit the
vulnerability that the patch supposedly addresses.

Another potential problem with deploying third-party patches is that these patches might break parts of your
system that are currently running just fine. After all, in the case of a Windows patch at least, many of these
fixes are actually replacing operating system code. Even the slightest change to code could have
catastrophic effects.

The pros of third-party patches

In the opinion of some Windows security experts, the risk of accidentally introducing bugs or malicious
code into a system, along with the risk of Microsoft not supporting the system, far outweighs the risk of
having to wait for a legitimate Microsoft patch. After all, Microsoft does have a history of expediting
patches for more serious security issues. At times, Microsoft even provides detailed instructions on how to
protect a system against a newly discovered vulnerability until a patch can be produced.

Essentially then, the debate between using third-party patches and waiting for Microsoft patches comes
down to an issue of timing. If you feel you are facing a serious Windows security vulnerability and Patch
Tuesday is weeks away, you might want to run the risk that the third-party patch could produce bugs just to
protect yourself from greater danger. If the risk is not so great, you might want to just wait for Microsoft to
release their own patches.

The four myths of Windows patch management

Myth #1: You should always wait a month before applying a new patch.

Perhaps the most common myth of patch management policy is that an organization is better off waiting for
a few weeks after vendors release a patch before deploying it internally. The idea is that if you wait a month
and don't hear any screaming on security mailing lists, it will be safe to apply the patch.

The problem with this thinking is that you should be using the results of your own testing to decide whether
or not a patch is safe. You shouldn't be using anecdotal evidence off the Internet. Sure, the anecdotal
evidence might point to some problems, but these are problems that your own testing regimen would have
found anyway. So why wait a month to hear what other people say when your own tests, which you should
be running regardless of what you hear, would find any faults earlier?
Myth #2: If a patch doesn't break most of your configurations, it will not break all of your
configurations.

You need to apply a newly released patch to all of the desktop computers in your organization. You test the
patch on the Windows XP boxes in the IT department without encountering any problems. You test it on the
workstation used by the CEO's administrative assistant without encountering any problems. You test it on
five computers used by people in the HR department and everything works perfectly. You use your patch
management software to deploy the new patch to all of the computers in your company. That's when you
find out that the patch causes a problem with an application that is only installed on the accounting
department computers.

Myth #3: You only have to deploy a patch once.

You automatically deploy patches to all the computers on your network. A week later, you do a scan to
check that all computers have had the update applied. Unfortunately, you still can't assume that every
computer in the organization has been patched. In my experience, there is always some computer in some
remote branch office that has been switched off for a couple of weeks because it is broken or the person that
regularly uses it has gone on leave. Eventually the computer is switched on, but remains unpatched because
you've moved on to patching newer vulnerabilities. When checking that the current patch has been
successfully applied, spend a little extra time verifying that other patches are also present.

Myth #4: There is a one true method for patch management.

Although there are some basic principles that should be kept in mind when developing a patch management
plan, there is no one true method. Each organization is unique. A technique that works for one place (such
as rolling out patches each Friday at 5 p.m.) might not work for another. Administrators should tailor their
patch management plans to the needs of their unique organizations.

A patch management policy should not be static. You should review it on a regular basis with the goal of
ensuring that it continues to meet your organization's needs. The structure of very few organizations remains
static, and structural changes will influence your existing patch management plan -- WAN links might be up
or downgraded or budgets might have changed allowing you to do more (or, more likely, less) with
available resources.

Microsoft patch maintenance and post-patch


security
24 Sep 2007 | SearchWindowsSecurity.com

Digg This! StumbleUpon Del.icio.us

Sometimes, even a Windows patch needs patching. Windows patches might not fully correct the problem
they are designed to fix, or they might break other parts of a program. The fact of the matter is that when it
comes to Microsoft patches, there is no such thing as "set it and forget it." In this section of our Windows
patch management tutorial, learn what to do in order to ensure that your Windows machines are running
smoothly long after Patch Tuesday has come and gone.

Windows patch management policy


Windows patch maintenance and post-patch security
Windows patch management tools

Windows patch maintenance and post-patch


security

Here are some basic tenets to keep in mind after applying patches -- especially after Microsoft's Patch
Tuesday -- culled from many different people's experiences with administering both remote servers and
local workstations.

Be mindful of changes in general system behavior. If something is clearly wrong, it'll tend to announce
itself. That said, this is a little easier to do when you are solely responsible for the system in question -- for
instance, a server. If you deal with multiple workstations, stay close to one of the patched machines, if you
can, and if anyone reports bizarre behaviors, you can investigate them and then try and duplicate them on
your own "pet" machine. Check this tip out for some advise on handling patch emergencies.

Inspect the system logs. Compare error logs both before and after a patch, and see if anything new or
unusual jumps out at you. Sometimes it might not be anything, or it might be coincidental, but error logs are
one of the best places to go to for concrete information about something not working correctly. This is
especially important if what is going wrong has no other outward symptoms yet, except for a logged error.
(Also keep in mind that some errors may simply be false alarms and have no real connection to anything;
sometimes it can be hard to tell the difference.)

Check compatibility on any potentially affected applications. If there's a chance a given patch might
affect the way a program works, test it before and after the fact. For instance, test a patch to a middleware
component by making sure no database connections are suddenly throwing errors. In addition, make sure
other non-trivial database operations that take place in your environment -- and that require middleware
(like retrieving large amounts of data or opening many connections at once -- also get tested whenever
possible.

Rolling back Windows patches

• Roll back by hand

Microsoft's hotfixes and service packs for Windows come pre-equipped with their own Windows
patch rollback mechanisms that can be activated manually if the need arises. If you want to uninstall
a given hotfix, here's the procedure for doing so.

1. Set Explorer to show hidden and system files if you haven't already done so.
2. Open the %SystemRoot% directory and look for a series of directories with the name
$NTUninstallKBXXXXXX$, where XXXXXX is the Knowledge Base article number for
the hotfix in question.
3. Within that directory is another directory named spuninst.
4. Inside spuninst is an executable named spuninst.exe. Run it, and the hotfix in question will
be rolled back through a Wizard interface.
5. If spuninst.exe doesn't work or is unavailable, type batch spuninst.txt. This executes a
batch-file version of the same recovery options.
• System restore
Windows also has a global mechanism for restoring settings and components to an earlier state. It's
one most of us should be familiar with: System Restore. This method is something of a brute force
way to move back to before a hotfix was installed. And it's slow -- it can take many minutes for a
System Restore to complete -- but it covers absolutely everything that might have been touched by a
hotfix.

Be mindful, though. You cannot run System Restore from the Recovery Console, at least not without
a good deal of manual hacking. However, you can run an individual patch rollback as described
before from the Recovery Console.

• Third-party software
The most complete way of dealing with patch roll back is probably through a third-party package.
Plenty of third-party software products exist for rolling a system back to an earlier state, with
undoing changes made by patches as part of that.

Fixing post-patch problems: Auditing revision levels

Just because you patch something once doesn't mean that you won't have to patch it (or something else)
later. The list below details how you can audit revision levels to fix problems after deploying Windows
patches.

• In Explorer: The most obvious way to determine the revision of a component is just to right-click
on it in Explorer and select Properties | Version. Or, you could switch to the Details view in Explorer
and show the File Version and Product Version as columns. But, with this view, you can't easily
export the results. Note that .DLLs will have a Version tab, but .EXE files will not, so this limits its
usefulness a bit.
• Through Process Explorer: The endlessly useful Process Explorer utility from Sysinternals lists the
revision levels of all loaded components. If you click on the name of a process and select View |
Lower Panel View | Show DLLs, you can see all of the loaded DLLs in use by that process as well
as their revision levels. This is only useful for running processes, but the program does support
exporting the information shown to a delimited text file. Note that it may take several seconds for the
program to poll all the used .DLLs for a given process.
• Through an external resource: This method is best if you want to find out what other revisions
there might be for a process or component. For Microsoft components, Microsoft itself has a site
called DLL Help. There you can look up any component from a Microsoft or Microsoft-supported
product, see all of the tracked revisions for the component and learn more about each of them.
However, DLL Help is only useful for Microsoft components, not third-party apps.
• Through a script: This option is the most effective way to report back on a whole slew of
components at once. For instance, use a script if you want to audit all of the items in a directory that
represent what a patch will put into place, and you want to see a quick side-by-side comparison of
component revision information. One such script is available online at JSWare and, with a little
work, it can be used to obtain the revision information for all files that match a wildcard or are in a
directory.

Optimize your WSUS performance


Most of the time Windows Server Update Services (WSUS) does a pretty good job of deploying patches to
computers throughout an organization. If you want to make sure that WSUS deploys each patch in as timely
a manner as possible, then it's worth spending a little time to optimize the patch management process.
WSUS is a Web application, so it doesn't have any settings of its own that are directly related to
performance, but there are several WSUS settings that you can use to improve the efficiency of your
patching operation though.

Download files when available

One of the first things that I recommend in Windows patch management is configuring WSUS to download
patches as soon as they are available, not when they are approved. Normally, patches are not downloaded
until you approve them. The problem with that is that as soon as patches are approved, computers try to
install them. If the patch has not yet been downloaded though, the update process has to stop and wait for
the patch to be downloaded. This whole process can be made more efficient by downloading files as soon as
they become available.

To change the download option:

• Open the WSUS Admin console and click the Options button in the upper left corner of the screen.
• When the Options screen appears, click the Synchronization Options link
• Scroll all the way to the bottom of the screen and click the Advanced button.
• The Advanced Synchronization Options dialog box will appear.
• Make sure that the Store Update Files Locally option is enabled and that the Download Update
Files to This Server Only When Updates Are Approved option is not selected.

Download express installation files

By default, WSUS downloads patches and pushes those patches to the clients. As you can imagine though,
if a patch is large or if you have a large number of clients, this method of installation can consume a
considerable amount of network bandwidth and it may take a long time to update all of the clients.

Express installation files tend to be larger than the normal patches that WSUS downloads, which means that
the download may take a little bit longer to complete. This extended download time is usually more than
made up for by the reduced time and bandwidth requirements when updating clients.

Check out other helfpful hints on optimizing WSUS performance in security expert Brien Posey's article,
including why to use a dedicated WSUS server and why you should be downloading patches in specific
languages only.

Microsoft patch management tools


24 Sep 2007 | SearchWindowsSecurity.com
Digg This! StumbleUpon Del.icio.us

Knowing the ins and outs of Windows patch management is great, but what good is that knowledge without
the proper tools? In the final section of our Windows Patch Management Tutorial, we've got a whole
assortment of free patch management tools that will make your life easier. Check out our selection of third-
party tools, patch management reporting tools, management and deployment tools and our Windows patch
management toolbox, which features nine free testing tools!

Windows patch management policy


Windows patch maintenance and post-patch security
Windows patch management tools

Windows patch management tools

Different approaches to patch management tools

An organization with more than a few workstations or servers needs some kind of automated way to handle
patch management, and there is a plethora of free patch management tools choose from. Because there's
more than one way to accomplish patch management, it's not uncommon for two or more parts of the same
organization to be updated and managed using different applications.

You can find that situation in environments where a branch office or division of a company is moved or
acquired. Suddenly, what worked before is not what works for the new parent. In this and almost all other
cases, the best approach is to pick one system and consolidate on it as aggressively as possible.

There are two types of patch management tools out there.

Reporting tools:

• Microsoft's HFNETCHK tool


• The commercial version of the same program, HFNetChkPro

These tools scan local machines or computers on a network, audit whatever's in reach and then produce
detailed summaries or digests about what is installed where as well as what might need to be installed or
updated. They do the research and make recommendations, but they don't make any actual changes.

Management or deployment tools:

• Microsoft's own Windows Server Update Services


• Gravity Storm Software's Service Pack Manager
• Ecora Patch Manager 5.0

These programs do the actual work of downloading and applying patches to local or remote machines. In
many cases, they are also reporting tools -- they audit computers to see what's installed and what's needed,
then download the needed updates and push them out according to an administrator's directives.
If you use multiple auditing or reporting tools, one caveat is that if there are inconsistencies between the
depth or breadth of reporting provided by each tool, you should be aware of that ahead of time so you're not
thrown off. If you are using multiple patch management or deployment tools, the problem isn't so much that
one tool duplicates or undoes the work of another, but that the administrator (or administrators) becomes
confused by the presence of multiple tools to get the same job done.

Using third-party tools for Windows patch management

The debate rages on about if and when to use third-party patching tools in lieu of waiting for Microsoft's
Patch Tuesday. Here are some reasons to say yes to third party patching tools.

Yes to third-party patching tools

• Additional features: Third-party patch management systems often have additional features that
aren't present in the standard Microsoft way of doing things. For instance, Service Pack Manager
2000 allows the administrator to create multiple arbitrary groups of computers to better govern who
gets what updates.
• Automation: Some third-party applications have automated functions that are above and beyond
what's available by default, and they don't require scripting to be effective.
• Additional coverage and information: Many of these tools have detailed reporting and research
functions -- for instance, the ability to automatically generate a summary of what's installed on a
given machine and relevant details from Microsoft Knowledge Base articles that apply to each fix.

No to third party patching tools

• Internal consistency: If you have one department that's using a third-party tool and another that's
using the standard Microsoft patch deployment methods, it can become confusing for people trying
to maintain standards across organizations -- and it might not be convenient or politically possible to
get everyone to use the same tools. In such a case it might be best to fall back on Microsoft
standards.
• Retraining: When people come in from another company or department where no such third-party
tools are in use, you'll need to retrain them. If this happens often, it can be a drain on time and
energy.
• Unneeded additional features: Not every organization needs the advanced features offered by
third-party products. Sometimes the defaults work just fine.

These are not the only reasons to use or not use third-party tools for patching. If you need more convincing
on either side of the topic, check out security expert Serdar Yegulalp's article on third-party patch
management tools.

Free patch management tools!

Numara patch management


In any IT network, one vulnerable workstation is one too many. Numara™ Patch Manager is the complete
patch management solution that scans, updates and downloads patches for Microsoft Operating Systems and
applications across your entire network — directly from your desktop.
Download Numara Patch Management
PatchLink Security Patch and Vulnerability Management Solution
PatchLink is a security patch and vulnerability management solution that combines vulnerability
assessment, patch management, network access control and reporting to help organizations address the
emerging security threats while minimizing costs and complexity.
Download PatchLink Security Patch and Vulnerability Management Solution

UpdateEXPERT Premium
UpdateEXPERT Premium is an advanced policy-based patch management solution that greatly speeds and
simplifies the patching of systems whether your organization is an SME or large enterprise.
Download UpdateEXPERT Premium

For a comprehensive list of free patch management tools, check out our entire patch management toolbox.

System Center Configuration Manager


From Wikipedia, the free encyclopedia
Jump to: navigation, search
System Center Configuration Manager
Developer(s) Microsoft Corporation
Stable release Configuration Manager 2007 R2 / 2008
Development status Active
Operating system Microsoft Windows
Platform x86
Available in Multilingual
Type Systems management
License MS-EULA
Microsoft System Center Configuration
Website
Manager

System Center Configuration Manager (ConfigMgr or SCCM), formerly Systems Management Server
(SMS), is a systems management software product by Microsoft for managing large groups of Windows-
based computer systems. Configuration Manager provides remote control, patch management, software
distribution, operating system deployment, network access protection, and hardware and software inventory.

There have been three major iterations of SMS. The 1.x versions of the product defined the scope of control
of the management server (the site) in terms of the NT domain that was being managed. Since the 2.x
versions, that site paradigm has switched to a group of subnets that will be managed together. Since SMS
2003, the site could also be defined as one or more Active Directory sites. The most frequently used feature
is inventory management, which provides both hardware and software inventory across a business
enterprise.
The major difference between the 2.x product and SMS 2003 is the introduction of the Advanced Client.
The Advanced Client communicates with a more scalable management infrastructure, namely the
Management Point. A Management Point (MP) can manage up to twenty five thousand Advanced Clients.

The Advanced Client was introduced to provide a solution to the problem that a managed laptop might
connect to a corporate network from multiple locations and should not always download content from the
same place within the enterprise (though it should always receive policy from its own site). When an
Advanced Client is within another location (SMS Site), it may use a local distribution point to download or
run a program which can conserve bandwidth across a WAN.

Microsoft announced the next generation of the product, System Center Configuration Manager 2007 (code
name "V4") at the Microsoft Management Summit in April 2005. The product was released to
manufacturing in August of 2007 and was available for general release in November of 2007. A free
evaluation edition of System Center Configuration Manager 2007 is available on the Microsoft download
center[1].

Contents
[hide]

• 1 Version history
• 2 See also
• 3 External links

• 4 References

[edit] Version history


Year of Service Feature
Product Revision Version/Build Notes
Release Pack Pack
Systems Management
1.0 1994
Server (SMS)
Systems Management
1.1 1995
Server (SMS)
Systems Management
1.2 1996
Server (SMS)
Systems Management
2.0 1999
Server (SMS)
Systems Management
2003 2003
Server (SMS)
Systems Management
2003 R2 2006
Server (SMS)
System Center
Configuration Manager 2007 2007 RTM 4.00.5931.0000
(ConfigMgr)
System Center 2007 SP1 2008 SP1 4.00.6221.1000
Configuration Manager (May)
(ConfigMgr)
System Center The R2 feature add-on
Configuration Manager 2007 R2 2008 R2 no change requires at least SP1, and
(ConfigMgr) can be installed after SP2.
System Center
Configuration Manager 2007 SP2 2009 SP2 4.00.6487.2000
(ConfigMgr)
System Center
Configuration Manager 2007 R3 TBA R3
(ConfigMgr)
System Center
Configuration Manager 2011
(ConfigMgr)

What is the diference between GPOs, WSUS, SCCM and SCE in


software and patch deployment?
With GPOs you can only do basic software distribution tasks (i.e. automatically install some software), and you don't
have much control on this process.

With WSUS you can do all of your patch management, but it's not a full-featured desktop management solution.

SCCM is exactly this: you can manage almost everything on your network using it.

System Center Essentials is a reduced bundle of SCCM and SCOM, tailored to small- and medium-sized companies.

You can find a product comparison between SCCM, SCOM and SCE here

thanks, can you tell me


what is the limitation of
GPO ? – Iyad Feb 16 at
16:32
You can only deploy .MSI packages, you have no control on when the installation will happen,
you can't handle dependencies, you can't check if an application is already installed, GPOs
must be linked to specific Active Directory OUs, there is no centralized reporting... and
probably many else. – Massimo Feb 16 at 18:46

WSUS is the Microsoft's basic offering for enterprise OS and Microsoft application patching. It is capable of
connecting to Microsoft's update catalogue, has a small amount of configuration around scheduling rollouts by groups
etc, and limited reporting details on patch deployment.

SCCM (System Centre Config Manager) is the replacement for SMS, it has SCUP (System Centre Updates
Publisher) as one of it's components. This builds on top of the WSUS infrastructure and components and gives you
massively more configuration and reporting, as well as having the ability to connect to other vendors' update
catalogues (Adobe, Dell, HP, etc) and also deploy your own custom patches for any apps. In addition to patching,
SCCM also retains all the software packaging, and deployment, OS deployment, etc of SMS.

GPOs (Group Policies) can be used for software deployment, but doesn't have any special patch-specific functions,
and has very limited info/reporting on deployments

SCE (System Centre Essentials) is a cut-down SCCM for smaller businesses that shares much of the functionality of
it's big brother.

what do you mean


"special patch-specific
functions" ? – Iyad Feb
16 at 16:32
For patch installation, you can either do a 'dumb' this is an installer, send it to the PC and run it;
or a proper patch package scans the machine, checks exact version ranges of installed software
and only sends out what's needed, reports back on machines that install/reject/don't need it and
history, and use the Windows Update Agent infrastructure on the PCs to do this. – GAThrawn
Feb 16 at 18:05

Compare Products
System Center for Midsize Businesses
• Built for midsized businesses (50-500 PCs)
• Target user is IT generalist who performs broad range of IT tasks
• Scale limits: 50 Windows Servers and 500 Windows Clients
• Single management server solution (limit one per domain)
• Easy to use
• Easy to useAggressively priced
• Aggressively priced

System Center Enterprise Solutions


• Built for Large Enterprise companies (greater than 500 PCs)
• Target user is IT specialist with dedicated admin roles
• Scales up to Large Enterprise IT environment
• Multiple management server solution
• Formal compliance and reporting support
• Advanced features and configuration
• Native management of VMware

Feature Comparison With Operations Manager 2007


Operations Manager
Monitoring 2007 SCE 2010 SCE 2010 difference

Monitoring of Windows servers, Essentials ships with a Network device


clients, hardware, software, and management pack
services

Management Packs with Expert


Knowledge
Operations Manager
Monitoring 2007 SCE 2010 SCE 2010 difference

Agentless Exception Monitoring


(AEM)

Add Monitoring Wizard

Reporting Essentials data storage limited to 40 days.


No report authoring

Branch office monitoring Essentials 2010 is a single server solution;


no tiered connection of servers

Role-based security Local or domain admin only for Essentials


2010 server

Connector Framework

Audit Collection Services

Web Console

Cross-platform support

Feature Comparison with Configuration Manager 2007


Configuration ConfigMgr 2007 SCE 2010 SCE 2010 difference

Patch Mgmt (Microsoft


and Third party)

Software Distribution Essentials offers basic .MSI and .EXE deployment with
optional command line parameters. No advanced packaging
capability.

Hardware and Software Essentials collects 60+ fixed software and hardware
Inventory attributes. Configuration Manager 2007 inventory is
extensible

Branch office updates and Essentials is a single server solution using BITS 2.0
software dist. (bandwidth aware). No site replication servers

Operating System Windows XP or Vista to Windows 7 using MDT MP


Deployment

Desired Configuration
management

Wake on LAN

Network Address
Protection (NAP)
integration
Feature Comparison with Virtual Machine Manager 2008 and Hyper-V
Configuration Hyper-V Console SCE 2010 VMM 2008 R2

Templates

Candidate Identification

Physical to Virtual Conversion

Virtual to Virtual Conversion (Vmware)

Migration across physical machines

Virtualization Reports

Monitoring VMs

Physical resource optimization (PRO)

Library

Provisioning

VM configuration & properties

VM state

Checkpoints (Snapshots)

64 bit guest OS

Hardware Assisted Virtualization

Live thumbnail

Synthetic Network Support

Import VM (multiple VHD + snapshot)

Virtual Network Configuration

Inspect Disk

VM cloning

VMWare Management

Self-service console

You might also like