Ms Patch Man Ch8

Patch ManagementBy Jeff Fellinge

Keeping Your BusinessSAFE from Attack:

Patch ManagementBy Jeff Fellinge

Keeping Your BusinessSAFE from Attack:

ContentsChapter 1 Introduction to Patch Management . . . . . . . . . . . . . . . . . . . . . 1

Building the Foundation: Processes, Software, and Training . . . . . . . . . . . . . . . 2

Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2Create a Patch Management Triage and Deployment Team . . . . . . . . . . . . . . . . . 2Determine SLAs for Different Levels of Patches . . . . . . . . . . . . . . . . . . . . . . . . . 5Ensure that the Appropriate Groups Test and Sign Off on a Patch . . . . . . . . . . . . 5Subscribe to Patch and Security Advisories and Bulletins . . . . . . . . . . . . . . . . . . . 6Review All New Security Bulletins with the Team to Assess Risk and Triage Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Weigh Deploying Updates vs. Exploit Mitigation Efforts . . . . . . . . . . . . . . . . . . . 9

Choosing Software to Deploy Patches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Windows Automatic Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Microsoft Software Update Services and Windows Update Services . . . . . . . . . . . 11Microsoft SMS 2003 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Beyond Microsoft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

The Full Rally . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

i

http://www.windowsitlibrary.com/Ebooks

http://www.microsoft.com/security

ContentsChapter 2 Microsoft Update Bulletin and Communications . . . . . . . . . . . . 17

Spreading the Word Quickly: Microsoft Email Notifications . . . . . . . . . . . . . . . 18

Soliciting Help from Your Peers: Microsoft Newsgroups . . . . . . . . . . . . . . . . . . 19

Microsoft Security Bulletin Web Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Security Bulletin Titles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Bulletin Summaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Learning More Details about the Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31The Frequency of Patch Releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Interactive Education: Webcasts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Processing All the Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

ii



Contents

Chapter 3 The Dry Run: Setting Up a Lab to Test Patches and Updates and Using Microsoft Baseline Security Analyzer to Scan for Missing Patches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

The Test Lab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Creating Your Lab: Using Virtual Machines vs. Dedicated Hardware . . . . . . . . . . . . . 39Configuring Forests, Domains, and DCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Patch Deployment Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Network Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Living Dangerously: Using Production as Your Test Lab . . . . . . . . . . . . . . . . . . . . . . 41

The Test Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Verifying Installation and Scanning for Missing Patches with MBSA . . . . . . . . . 43MBSA Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43MBSA Installation and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Start Scanning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45MBSA Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Viewing Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47MBSA as HFNetChk Replacement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49MBSA Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

The Timeline from Test to Production . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

iii



Contents

Chapter 4 Microsoft Patching Technologies . . . . . . . . . . . . . . . . . . . . . . . 52

Decoding a Software Patch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Discovering the Installer Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53How the Patch Installs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Microsoft’s Most Common Patch Engines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Update.exe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Hotfix.exe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65Ohotfix.exe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Normal Updates and Administrative Updates . . . . . . . . . . . . . . . . . . . . . . . . . . 67Normal Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Administrative Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Integrating Office Patches into the Install Sources . . . . . . . . . . . . . . . . . . . . . . . 70Obtaining Ohotfix.exe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Dahotfix.exe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Off the Beaten Track: Older and Unique Update Engines . . . . . . . . . . . . . . . . . . . . 71

Vgxupdate.exe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Iexpress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Installing Mutliple Hotfixes with Qchain Technology . . . . . . . . . . . . . . . . . . . . 72

Installer Wrap-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

iv



Contents

Chapter 5 Individual Solutions: Windows Update and Office Update . . . . 74

Solutions for Individual Computers: Using Automatic Updates to Scan and Install Patches . . . . . . . . . . . . . . . . . . . . 74

Configuring Automatic Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Option 1: Automatically Download and Install Security Updates . . . . . . . . . . . . . 77Option 2: Automatically Download but Prompt to Install the Security Updates . . . 78Option 3: Notify Only When New Updates are Available . . . . . . . . . . . . . . . . . . 78Option 4: Disable Automatic Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78Behind the Scenes: Automatic Updates Registry Settings . . . . . . . . . . . . . . . . . . 79

Phoning Home: Automatic Updates Routinely Checks with Microsoft . . . . . . . . . . . . 80Using Automatic Updates to Download Updates from Microsoft . . . . . . . . . . . . . . . 81Installing the Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

The Windows Update Web Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

The Office Update Web Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Using the Office Update Inventory Tool to Scan for Missing Office Updates . . . 91

Using an Administrative Point to Deploy Office Updates . . . . . . . . . . . . . . . . . . 92

Keeping Up to Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

v



Contents

Chapter 6 Corporate Solutions: Microsoft SUS and WSUS . . . . . . . . . . . . 95

Centrally Managed Passive Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95Configuring Automatic Updates Clients with Group Policy . . . . . . . . . . . . . . . . . . . 97

Exploring the Windows Update GPO Settings . . . . . . . . . . . . . . . . . . . . . . . . . . 99Deploying Service Packs with SUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100SUS Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101Configuring SUS Server Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

WSUS Revealed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Exploring the New WSUS Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Approving Updates with WSUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105Support for Computer Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

What if I don’t see my computer in the list to choose from? . . . . . . . . . . . . . . . . 106Approving Updates with WSUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107Reports Added in WSUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110Configuring WSUS Global Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Corporate Solutions Reviewed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

vi



Contents

Chapter 7 Enterprise Solutions: SMS 2003 . . . . . . . . . . . . . . . . . . . . . . . . 115

Preparing Your Environment for SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116Setting Up AD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Installing SMS 2003 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117Configuring a Base SMS Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

Specify the Management Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118Enable Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118Prepare the Deployment of the SMS Client Software . . . . . . . . . . . . . . . . . . . . . 119

Decrease Polling Intervals and Increase Polling Frequency for Testing . . . . . . 120Enable Client Push Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120Specify the Account to Use for Software Distribution . . . . . . . . . . . . . . . . . . 120

Client Discovery and Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120Review Newly Discovered Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121Troubleshooting Missing or Unassigned Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 122Other Methods for Installing the SMS Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122Checking the SMS Client on the Client Computer . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Using SMS for Software Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123Installing the Office Update Inventory Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Installing the Security Update Inventory Tool . . . . . . . . . . . . . . . . . . . . . . . . . . 125

SMS Vernacular: Programs, Packages, Advertisements, and Collections . . . . . . 126

Creating Your Package of Updates: Working with the Distribute Software Updates Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Advertise Your Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

SMS 2003 Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

Manually Refreshing the Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

Patch Management with SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

vii



1

Brought to you by Microsoft and Windows IT Pro eBooks

Chapter 1:

Introduction to Patch ManagementDue to the rapid proliferation of nefarious worms, with names such as MS Blaster, Nimda, and CodeRed, applying Microsoft Security Updates is becoming a staple of any business connected to theInternet or outside world. However, hackers and crackers will continue to exploit computer softwareand your company will always need information security protection from zero-day exploits. However,a majority of the fast-spreading, heavy-hitting worms leveraged and exploited weaknesses in softwarethat were previously identified and fixed weeks—in some cases months—earlier. Target damageaside, the proliferation of these worms affects the Internet by clogging routers and Internet gateways.In all, these worms have sent a loud-and-clear wakeup call to IT departments everywhere to getserious about patch management.

To reduce the shellshock of frequent patch releases, Microsoft continues to introduce softwareand processes to help triage and deploy their Security Updates. Microsoft formalized the SecurityUpdates release cycle to occur on the second Tuesday of every month. All Security Updates areranked in severity and classified by products. They also include detailed descriptions of the exploitand list mitigating factors. Microsoft also released several patch deployment software products in addi-tion to the flood of new third-party patch management software products. These software productsexist to help test and deploy all the patches. Most patch management software supports Microsoftproducts and some extends to third-party software as well.

However, the process of deploying the patches is only the tip of the iceberg. A successful andcomprehensive patch management program combines well-defined processes, effective software, andtraining into a strategic program for assessing, triaging, obtaining, testing, and deploying softwarepatches. Patching software is not a new phenomenon: software updates are a frequent and regularoccurrence and historically patches improved performance, stability, or even added new program fea-tures. But of late, the proliferation of Internet worms and viruses have put the spotlight on patchmanagement vis-à-vis Microsoft Security Updates. The rapid assessment and successful deployment ofthese Security Updates causes the most anxiety in IT shops throughout the world. These shops mustbalance the potential threats to unpatched systems, project priority, time necessary to identify andassess security vulnerabilities, and the testing and deployment of patches with the potential businessimpact of patch installation (e.g., reboot downtime, unsuccessful patch deployment).

This book describes attributes of a successful patch management program and explainsMicrosoft’s update technologies and security update communications network. Your internal processescoupled with Microsoft’s evolving update distribution program will define your patch managementprogram. Partially due to the recent attention drawn to the Security Updates, Microsoft continues toimprove its security update communications. The latest bulletins describe the updates in sufficientdetail to help most organizations identify and triage patches relevant to their environment.

This text will also outline how to assemble a patch testing program that calls on the expertise ofresources across your enterprise to minimize adverse effects that a patch might have on your net-work’s business-critical systems and applications. You’ll learn how to set up a patch testing program

that provides an important safety net for your production servers. The later chapters will examine theMicrosoft patch mechanisms and Microsoft’s update distribution software: Windows Update, WindowsUpdate Server, and Systems Management Server (SMS) 2003.

Building the Foundation: Processes, Software, and Training Let’s look at what constitutes a solid patch management program. The details vary by organizationbut traits common to all successful programs include:• Identifying the processes to assess, test, deploy, and audit the patch installation• Selecting effective patch testing and distribution software for your organization, then using this

software to deploy the updates• Training to ensure that everyone is capable and ready to test and deploy patches when the time

comes • Gaining support from executive management that includes sponsorship and setting overall goals

for patch management

Processes The patch management process defines the strategy and tactics encompassing your patching programand includes activities ranging from the selection and deployment of patch management software, tocreating a Patch Management Triage and Deployment Team, to rolling out the individual patches.Customize each of these elements for your particular organizational needs. Smaller organizationsmight not have a formal process but will benefit from a structured approach nonetheless. Be sure toinclude in your process early planning topics such as researching, purchasing, and deploying thepatch delivery software for each of your organization’s locations, including branch offices and remoteusers. Consider these elements when defining your patch management processes:• Create a Patch Management Triage and Deployment Team.• Subscribe to Microsoft and non-Microsoft patch and security advisories and bulletins.• Review all new security bulletins with the team to assess risk and triage deployment of new

patches or evaluate workarounds.• Weigh deploying updates versus exploit mitigation efforts for different patches, environments, or

targets.• Determine service level agreements (SLAs) for different patch levels, such as internal versus pro-

duction or workstation versus server.• Devise and document testing procedures to ensure that the appropriate groups test and sign off

on a patch before it’s released to production. When feasible, consider a burn in period in which thepatch is tested in a live yet limited environment.

Create a Patch Management Triage and Deployment Team Effective emergency response or disaster recovery teams drill repeatedly so that when the time comesthey are prepared to handle the event. This training is no different from an Information Security alertteam tasked with investigating unknown events or attacks. Adopting the effective strategies of theseemergency response teams is becoming more important for your patch deployment team. Criticalpatch deployments increasingly require fast action—especially when an exploit is in the wild.

In many organizations, the patch deployment team consists of systems administrators or engi-neers who have primary responsibilities beyond patching systems. Since the burst of the dot-com

2 Keeping Your Business Safe from Attack: Patch Management


bubble in 2000, most IT spending budgets have shrunk and resources have thinned considerably. Inmany companies, the IT staff is being asked to do more with less help, which unfortunately canmean that nonrevenue or maintenance activities might be unintentionally (or purposely) reprioritized.

To help ensure that patching is not an afterthought at your company, consider forming a PatchManagement Triage and Deployment Team that includes representatives from each of the disciplinesor functional areas of your organizations: Microsoft SQL Server, Microsoft Exchange Server, ActiveDirectory, file and print, Web, custom and proprietary applications, etc. By involving subject matterexperts from each of these disciplines, you make certain that when patching time comes you can relyon each expert to test and deploy the patches to their systems. Especially in large organizations,involving these folks early on helps with team building so that when a patching crisis arises responseteam members already know one another, which implicitly improves communication. Include Busi-ness Decision Makers (BDMs) and representative customers who can help assess system risk toler-ance. The BDMs can work with the technical teams to schedule and test patches for specificbusiness-critical systems. Customers of these systems can provide valuable insight into usage patternsfor scheduling server reboots and downtime or into when workarounds would be beneficial until apatch can be applied. For large enterprises, your Patch Management Triage and Deployment Teammight include multiple BDMs.

Even during times when you are not deploying patches, schedule regular weekly meetings withthe team members to discuss current or upcoming patches, deployment systems, triage strategies, orgeneral training. Schedule these reoccurring, standing meetings out into the future so that they are onkey participants’ calendars. Then when a patch needs a quick assessment, testing, and deployment,the right people already have the time reserved.

Consider establishing different states of alert for your Patch Management Triage and DeploymentTeam. Under normal circumstances when no patches need deployment, use the meetings to discuss orreview your patch deployment technologies. Discuss upcoming projects that might tie up key patchingresources, such as testing labs or deployment personnel. These meetings are also an ideal time to trainyour team in the process of deploying patches when necessary. Also consider developing two patchmanagement processes, one for regular patch releases (e.g., a worm is in the wild) and one for emer-gency patch deployment (e.g., a worm is inside your company’s network boundaries).

Of course when patches must be deployed, the primary role of the team comes into direct play.In general, the second Tuesday of every month is the day that Microsoft releases the majority of itspatches for the month. Microsoft typically announces the patches by noon PST, so Tuesday after-noons are good times to meet and be ready when Microsoft releases a new batch of updates. Notethat critical patches for exploits in the wild can be released outside of this timeframe at Microsoft’sdiscretion. For this reason, subscribing to Microsoft’s free Security Update notification service is agood idea. The next section describes this service in more detail.

Upon notification of new Security Updates, rally the Patch Management Triage and DeploymentTeam and begin your patch management process. Assess the patches and triage their applicabilityand exploit risk to your environment. Figure 1-1 shows a sample process.

For example, you will likely handle an Internet Explorer (IE) patch differently than a core Win-dows OS patch such as a Local Security Authority Subsystem (LSASS) security update. The IE patch’sfocus might be on deployment to employee workstation computers whereas the OS patch mightneed immediate rollout to any Internet connected computers and possibly others depending on thespecific exploit attack vector.

Chapter 1 Introduction to Patch Management 3


Figure 1-1 Reviewing the patch management process

The exploit attack vector is the mechanism an attacker uses to compromise a vulnerable system. Forexample, an IE exploit attack vector might be a visit to a Web site containing malicious code. Thismeans that a user must actively visit an infected site. Depending on your organizations IE security

Install Patchon Affected

Systems



SecurityBulletin

Released

Test PatchInstallation in

Lab

Audit Serverfor Successful

Installation

Verify ServerOperation

PostInstallation

Yes

NeedsMore Testing

No

AutomatedBulletinNotifiesTeam

ImplementIdentified

WorkaroundsUntil TestingIs Complete

Team ReviewsSecurityBulletin

Bulletin Appliesto Immediately

At-Risk Systems

Resolve PatchDeployment

Issues

NoPatch TeamApproves

Deployment

policy this may or may not be a critical patch to deploy to your end users. Contrast this to the vul-nerability of a primary security DLL such as LSASS. This DLL is used by many externally accessiblecomponents and depending on the vulnerability, can be exploitable from an unsolicited external con-nection attempt via Secure Sockets Layer (SSL), remote procedure call (RPC), or other LSASS-enabledprotocol. To exploit this vulnerability, an external attacker might only need network access to a vul-nerable server. If an SSL-protected Web site exposes this vulnerability, then that company’s Internetconnected Web site might be at risk. The exploit attack vector might be anyone on the Internet estab-lishing an SSL connection to your Web site. Worms that spread from one vulnerable server to anotherfrequently use this type of exploit attack vector. These malicious software programs exploit anunpatched vulnerability, infect the computer, then launch new attacks from the compromised com-puter. Code Red, Sasser, and MS Blaster are all examples of worms that spread by exploiting vulnera-bilities that had official patches available months earlier.

The Patch Management Triage and Deployment Team must consider all these factors when deter-mining when and how quickly patches need testing and deployment. Later this chapter explains howmitigating factors can help buy your company time to conduct adequate testing of new patches.However, even with these mitigations, patching has no substitute. The time between disclosure of avulnerability and the availability of an automated exploit shrinks every year—from more than 300days a couple of years ago to only 17 days for the recent Sasser exploit. Chapter 3 describes tech-niques and processes for testing the patches and updates.

Determine SLAs for Different Levels of Patches Let’s face it, patching disrupts normal business operations and, unless your IT department is over-staffed, you will have to make concessions to other projects to accommodate your patch deploy-ments. To acknowledge your patching activities alongside other business projects, create a policy thatspecifies patching SLAs that both the businesses and technical leadership approve.

Include in these SLAs definitions of different levels and types of patches (e.g., internal versus pro-duction, workstation versus server), define their priority, and set an expectation for when specificcomputers will be patched after the release of a new alert. A very basic SLA might assert that allpatches deemed critical by Microsoft will be deployed within 48 hours and all other patches will bedeployed within 2 weeks. Of course you will want to customize this to your environment and tailor itto suite your needs. A well-defined SLA will not only help ensure that patches get deployed shortlyafter release but they also help clear any roadblocks in securing resources to assist with the patchdeployments. Plus by defining your SLAs up front, your business management will probably be moretolerant of a delayed business project milestone due to a patch deployment exercise.

Ensure that the Appropriate Groups Test and Sign Off on a Patch You need to devise and document testing procedures for the patches. These procedures are toensure that the appropriate groups test and sign off on a patch before released to production. Youalso need to consider a burn in period when feasible.

All too often—especially in the heat of battle—patches are deployed without adequate testing.Many times, administrators assume that it will work and more-or-less hope that the computer will suc-cessfully restart. Although for the most part this is true due to Microsoft’s rigorous testing, a couple ofpatches have had serious problems. For example, the MS04-011 patch released in 2004 caused somecombinations of hardware to stop responding. Although infrequent, a patch might dramatically



change how software behaves between a patched and unpatched system. An example of this wasSQL Server Service Pack 3 (SP3), which implemented additional security settings that affected cus-tomer’s custom application code in some circumstances.

By involving many cross-functional groups in your Patch Management Triage and DeploymentTeam you will have the right people on hand to perform this testing. They will be the experts whodeploy the patches to their systems, then test or watch the system over a period of time to look forany anomalous behavior.

You might be able to gain flexibility for deploying your patches if you can deploy patches instages to certain groups of servers. For example if you manage a Web farm of multiple Web servers,even after testing in a lab, consider deploying the patch to one Web server and watching it for a fewdays. This burn in period tests the patch in a live environment, and if no apparent problems appear,then after some time you can deploy the patch to the remaining servers with more confidence. How-ever with a progressive type of rollout, waiting a few days can be the difference between deployingbefore a worm and being infected by a worm.

Chapter 3 delves into the detail aspects of testing that help create a solid testing program. Makesure to include testing in your process and training.

Subscribe to Patch and Security Advisories and Bulletins The proliferation of worms that exploit known software vulnerabilities has spawned several patch andsecurity advisory Web sites and bulletins. The primary Security Updates Web site for Windows is theMicrosoft Security Bulletin Web site at http://www.microsoft.com/security/bulletins, which Figure 1-2shows.

Figure 1-2 Viewing Microsoft’s searchable Security Updates Web site

Bookmark this page, then subscribe to the bulletin notification service to ensure notificationwhen Microsoft releases new Security Update bulletins. Also, if you subscribe to a specialized support



http://www.microsoft.com/security/bulletins

program like Premier Support, ask your Technical Account Manager (TAM) to add you to any notifi-cations they send out.

Unfortunately, for now, Microsoft Office uses Office Update, which is a separate update servicethan Windows Update. For information about patching Office applications visit the Office UpdateWeb site at http://office.microsoft.com/officeupdate. This Web site also can scan your computer formissing Office updates, as Figure 1-3 shows.

Figure 1-3Scanning the Microsoft Office Update Web site for missing updates

Subscribe to the Microsoft newsletter Inside Office—Product Updates Alert at http://www.microsoft.com/office/using/newsletter.asp to get notified when Microsoft releases a product update including thelatest security and performance improvements.

In addition to Microsoft, bookmark other security sites and subscribe to other patch-centric ser-vices to keep abreast of newly discovered vulnerabilities and subsequent software updates. Every daythese distribution lists send a deluge of information, but keep these messages for at least 30 days.When patch day comes, or if you suspect you have been attacked, you will appreciate the built-uplibrary of technical articles and correspondence.

Don’t overlook the Usenet groups, which provide huge and largely unmoderated discussionsabout most everything including patching. Subscribe to the Microsoft patch and security newsgroupsat http://www.microsoft.com/technet/community/newsgroups/security. To search other newsgroupsfor vulnerabilities, use your own provider or a public provider such as Google Groups athttp://groups.google.com.



http://office.microsoft.com/officeupdate

http://www.microsoft.com/office/using/newsletter.asp

http://www.microsoft.com/office/using/newsletter.asp

http://www.microsoft.com/technet/community/newsgroups/security

http://groups.google.com

Other good third-party notification services for exploits, vulnerabilities, patches, and other securityupdates include the SecurityFocus Bugtraq at http://www.securityfocus.com/subscribe?listname=1,Mitre’s Common Vulnerabilities and Exposures at http://www.cve.mitre.org, the Carnegie Mellon Uni-versity CERT at http://www.cert.org, the United States Computer Emergency Readiness Team (US-CERT) at http://www.us-cert.gov, and the SANS Internet Storm Center at http://isc.sans.org amongothers. Even most antivirus vendors provide links and descriptive information outlining new attacks,vulnerabilities and include links to vendor patches or mitigating steps. For example, check outSymantec at http://www.sarc.com and TrendMicro at http://www.antivirus.com for detailed informa-tion about new viruses and worms and how to prevent them.

Proactive and comprehensive access to new vulnerability and exploit information is essential tomaking appropriate triage decisions surrounding patching vulnerabilities in your organization. Chapter2 delves into the contents of Microsoft Security Bulletin Updates in much more detail.

Review All New Security Bulletins with the Team to Assess Risk and Triage Deployment Now that you have assembled the team and meet regularly, define your process of reviewing newSecurity Bulletins to assess risk and triage the deployment of new patches. The triage process isimportant because large companies cannot immediately deploy all patches all the time. You will needto make tradeoff decisions as to when patches will be deployed and how the patching effort will beprioritized with the other work your business conducts.

Although a small company might be able to patch everything right away when a new update isreleased, a large company hosting complex or mission- and business-critical applications generallydoes not have this luxury. Updates need testing and deployment in a systematic fashion that reducesthe chance that a patch will adversely affect an important system. You never want the cure to beworse than the illness! To intelligently assess new Security Bulletins and their effect on your systems,you must triage each patch. An example of a triage process follows:• Rank the patch’s applicability to your environment.• Assess the risk if you do not deploy the patch. Generally, you calculate risk as the probability of

an event multiplied by the damage that the event could cause. In terms of a patch, the risk mightbe the chance that someone could compromise the system multiplied by the effect of the breakin. Let’s use the LSASS DLL as an example again. The risk for this vulnerability is very highbecause it is easy for an attacker to access the vulnerability through an SSL Web site. And thedamage is high because the attacker could take full control of the computer system. High proba-bility times high potential damage equals high risk.

• Assess the damage if someone exploiting the vulnerability that the patch addresses attacks you. • Assess the patches based on target platform. Microsoft Security Bulletins specify the target of a

patch, such as Windows, SQL Server, IE, or Office. • Determine whether you can make any mitigating efforts in the short-term to shoreup your

defenses while patch testing occurs.

At the end of this triage assessment, set your sights on determining the criticality and priority fordeploying each patch to specific computers in your environment. For example, priority patches likelyinclude immediately exploitable attack vectors such as employees using a vulnerable version of IE tosurf infected pages or attackers attempting to infiltrate an unprotected Web server.



http://www.securityfocus.com/subscribe?listname=1

http://www.cve.mitre.org

http://www.cert.org

http://www.us-cert.gov

http://isc.sans.org

http://www.sarc.com

http://www.antivirus.com

Most corporations protect their Internet connections with perimeter firewalls that inspect andpermit inbound and outbound network traffic based on ACLs. The use of a perimeter firewall willhelp mitigate many exploit attack vectors. For example, the RPC exploit required a computer listeningon TCP port 135. Most corporate perimeter firewalls ordinarily block this port. Consideration of thesemitigating factors when triaging new patches is important, but don’t assume that you are always pro-tected. Most firewalls will not protect you from worms or viruses that are distributed through emailmessages unless those firewalls have built-in antivirus scanning or intrusion prevention capabilities.

When considering your firewall protection, keep the following scenario in mind. Your remoteusers routinely breech your perimeter firewall by transporting their work laptop from inside your pro-tected LAN to their home, which might be directly connected to the Internet using a DSL or cableconnection. Perhaps they are running a base version of SQL Server and Microsoft IIS on their worklaptop. They disconnect from the corporate LAN and connect their home computer by pluggingdirectly into their cable modem. Worms that attack IIS and SQL Server (e.g., Nimda, Code Red, SQLSlammer) still plague the Internet and developer’s computers run a high probability of being infected.After infection they might either establish a VPN tunnel back into the company or physically carryand connect their laptop onto the company LAN. When reconnected to the LAN and inside theperimeter firewall, infected computers can propagate the worms to other internal systems.

This scenario might affect your triage decision regarding when to deploy a patch to your internalsystems. This scenario also provides a good example for implementing system-startup-based andtime-based patch management scanning software that routinely checks that patch management statusof any system on your LAN. Systems not patched are updated or else quarantined from the network.This practice ensures that even after an initial wave of patch updates, computers brought onto thenetwork later will be patched.

Weigh Deploying Updates vs. Exploit Mitigation Efforts The triage team also needs to review and recommend mitigating factors for patches, environments,and targets. In the Security Update Bulletins for each patch, Microsoft lists several common mitigatingfactors specific to that vulnerability. In addition to these, it is important for your triage team to considerfactors relevant to your environment. For example, in the IE exploit attack vector described earlier,mitigating factors might be to install a client-based IPSec or perimeter firewall ACL that prohibits out-bound Web requests to specific sites. The mitigating action does not necessarily solve the problembut it might buy you time so that patches can be appropriately tested and deployed.

Choosing Software to Deploy Patches Fundamentally, patching a computer consists of downloading the appropriate software update andexecuting it on a target computer. Historically, Microsoft product teams introduced distinct patch man-agement technologies. This means that Windows OS updates are very different from Office updatesand your patch deployment tools might support one better than the other. (Microsoft is addressing thisconcern and promises to one day combine all product updates into a common delivery mechanism.)

When configured properly, Automatic Update will check for updates automatically. However, themanual process for deploying patches usually consists of logging onto computers and either visitingWindows Update or manually downloading and installing the appropriate patches. This process issometimes complicated because Microsoft might release multiple (sometimes three or four) updatefiles per security update depending on the version of software installed. For example, an IE patch



might be released as separate files for IE 5.0, IE 5.5, IE 6.0, etc. This slows the manual processbecause in a mixed environment you must download each of these versions, then choose the correctpatch to run for each computer system you manage. This patch version disparity alone is a com-pelling reason to purchase and use an effective patch management tool.

A good patch management tool not only scans a computer for the missing patch, but will alsodiscern the proper version needed, download it, and install it. For example, you can use several toolsto scan a set of computers running different software versions, then simply instruct the patch installa-tion software to deploy patch MS04-xx. This system ensures the correction version of MS04 is deployeddespite the platform. The patch management tool scans the targets, determines the patches necessary,downloads the patches from Microsoft, then installs the correct version on the appropriate systems.Some third-party patch management tools repackage the Microsoft patches into a different format thatlets them add features, such as support for multiple (non-Microsoft) software vendors and additionalinstallation functionality. Later this chapter discusses some of the features to watch for when selectingpatch management software.

Windows Automatic Updates Microsoft offers several patch management software packages aimed at different audiences. Smalloffice/home office (SOHO) and individual computer users without a network infrastructure can con-figure the Windows XP Automatic Updates feature which regularly polls the Microsoft Web site fornewly available patches. The Automatic Updates client software identifies the correct patch requiredfor each individual computer and when new patches are available a system tray icon pops up, asFigure 1-4 shows, and notifies the user.

Figure 1-4Receiving notification that new updates are ready to be installed



From the Automatic Updates dialog box, the user can review the updates, select updates toinstall, and automatically install the patch at a specified time, which Figure 1-5 shows.

Figure 1-5Reviewing and selecting which updates to install

Windows Automatic Update covers patches for a variety of Microsoft products including: Win-dows, Office, Crystal Reports Web Viewer, Exchange Server, Internet Security and Acceleration Server(ISA Server), MSN Messenger, Virtual PC for Mac, BizTalk Server, Content Management Server (CMS),FrontPage Server Extensions, IIS, SQL Server, and more.

Chapter 2 describes in detail the Microsoft communications. The chapter also contains links to thepatches so that you can download them and manually install them on your computer systems.

Microsoft Software Update Services and Windows Update Services Microsoft also created Software Update Services (SUS) and the soon-to-be-released Windows UpdateServices (WUS) to provide large companies more control over patch deployment to end user com-puters. SUS leverages the same client as the previously mentioned Windows Update. This client isincluded in Windows 2000 SP2 and later and Windows XP SP1 and later releases. But systems usingWindows 2000 SP1 or earlier or Windows XP (without SP1 or SP2) need a separate Automatic Updateclient.

SUS lets you centrally manage the automatic update settings of your end user computers and alsolets you deploy your patches from a centralized SUS server in your network. A systems administratorcan approve all updates on SUS server and those approved will be sent to the clients. This practicesaves WAN bandwidth because not every end user computer needs to repeatedly download the samepatches from Microsoft. Instead the SUS server downloads the patches from Microsoft, as Figure 1-6shows, then each end user’s computer downloads the patches from that SUS Server.



Figure 1-6Downloading updates from a centralized SUS server

After you install SUS inside your corporate network boundaries, it polls the Windows Updateserver on the Internet for new updates, downloads them, and makes them available for deploymentin your corporate environment.

Your central SUS server can also feed other SUS servers located in branch offices, for example forremote deployment to reduce network traffic. Additionally, SUS provides centralized configuration bymeans of a Group Policy Object (GPO). Configure when and how to download and deploy patches,then assign that GPO to your computers in specified GPO containers such as sites, domains, or OUs.Chapter 6 will cover more details about SUS and the newer WUS.

Microsoft SMS 2003 Microsoft created SMS to help enterprise-size organizations manage a large number of end-user com-puters. SMS 2003 integrates the patch management features released for SMS 2.0 Feature Pack 1. SMS2003 provides a much higher degree of targeting and more robust reporting than SUS. For example,you can specify to deploy patches based on machine attributes (e.g., laptops versus desktops) andyou also have a fine degree of control over patch deployment. In addition, you can set up a patchdeployment package that lets the user choose the most convenient time to install patches within a



3-day window after patch deployment. Chapter 7 explores some of the SMS 2003 features sur-rounding patch management.

Beyond Microsoft The software involved in a patch management solution generally scans target systems for missingpatches, then deploys patches on those computers. Various software applications add features andfunctionality to help this process.

Many patch management applications let you create several groups that contain desktops orservers, such as IIS servers, database servers, infrastructure servers. Look for products that ease theprocess of populating to these groups. For example, can they read Active Directory (AD) to get groupor structure information such as domains, sites, or organizational units (OUs)? Can they create groupsbased on IP address or other characteristics (e.g., software installed) of the target systems? Look forthe ability to quickly customize and save patch group memberships. Using predefined groups willsave you time during subsequent scanning and deployment procedures.

The patch scanning features vary by product. The most accurate (but frequently slowest) scan-ning methodologies involve comparing the registry and specific file versions (including size or date)of a target computer with the desired values stored in a patch database. The patch management toolflags a computer when any of the values do not match.

The scan and deployment features also vary by product so be sure to put several products to thetest. Some products let you deploy patches immediately following a scan and some let you scheduleboth the scan and deployment. For example, you can scan anytime to check compliance, thendeploy later during specific change windows or at night. Some patch management tools retain a his-tory of scans for auditing purposes or in case a rescan is necessary. Many Microsoft updates require areboot when installed and different patch management tools let you specify when and how thereboot should occur. Some products use QChain, the Microsoft utility that keeps track of changedfiles, to minimize multiple reboots through a succession of patch updates. Also check whether theproducts support Microsoft update rollback features. Not all patches support this feature, but youmight find it useful for your patch management software to support patch uninstallation also.

Patching Office products may require the Office installation files. If you want to deploy Officepatches, make sure the patch management tool supports Office deployments and check with thevendor to determine whether they support updating multiple versions of Office (each needing sepa-rate source files) with a single scan and deploy action.

Installing patches requires administrator access at some level, so make sure the products youselect will fit into your user privilege model. For example, will your end users need to be localadministrators or does the patch management tool run under a separate privileged account? Somepatch management solutions require that a software agent be installed on every computer, yet othersolutions scan and deploy entirely from one management console. Agents can provide better feed-back and installation control but also increase the software footprint of the computer, which may bean important consideration for server deployments. Agents also tend to provide more robust remotemanagement options and may include basic Quality of Service (QoS) controls, such as bandwidththrottling and checkpoint restarts.



Training The final essential element to a solid patch management program is to provide quality, comprehen-sive training to everyone involved with the patch management program. At first consideration youmight think of training the systems administrators who use the patch management software day today. But don’t forget about training management who must buy into your patch management programand fund the software and resources required to roll out the patches.

Extend your training efforts beyond how to use your patch management software. Includetraining for the processes behind your entire patch management strategy and tactics. This includesdeveloping documentation and holding meetings regarding the elements presented earlier in thischapter, such as the roles of the various Patch Management Triage and Deployment Team members,how to interpret Microsoft’s security software update communications, and how to keep your systeminventory current to facilitate patch triage decisions.

When a new exploit ravages the Internet, bring together your patch deployment team and reviewthe exploit’s attack vector (the method that the exploit used to leverage a particular vulnerability). Dis-cuss how your patching efforts saved (or could have saved) your organization from this exploit. Ifyou were a victim of an exploit resulting from an unpatched vulnerability, immediately conduct apostmortem review. Use this review to play back the steps leading up to the attack. Use the sessionto help train others affected by the exploit on the importance of your patching processes. Anotherbenefit of a postmortem review immediately following an exploit is that everyone is much moreacutely aware of the issues and problems leading up to the exploit and are likely to accept actionitems for any corrective actions that lead to process improvements. Even if you were not vulnerableto a widespread exploit such as a mass-infecting worm, use the publicity of the event to rally yourteam to confirm your processes and drill team members with what if scenarios to encourage continualprocess improvement.

Develop training materials that document your patch management process. These materialsdefine the goals of the patch management team and the roles and responsibilities of each teammember. For example, a systems administrator might be the point person for installing the patches onspecific systems but a developer might be responsible for testing the effect of the patches on thesystem applications. Clearly document your organization’s entire patch management process: fromsystem and application inventory, to patch triage activities, to patch testing, to deployment, and evento follow-up testing. Review with team members their roles in the process and distribute the docu-ment for reference. You will find that physically documenting the process helps bring auxiliary teammembers into your process, which ultimately improves the effectiveness of the entire program.

Training consists of both formal and informal meetings. Formal meetings might include Web-based seminars from your patch management software vendor or in-house expert. Formal trainingmight also include dry-run sessions and drills, which keep staff current and skilled on your chosenpatch deployment methodology. Informal training comes in the form of discussion groups or emailsthat are sure to circulate when preparing for or during a patch management exercise.

Keep up to date on the version and features of your patch management deployment software.This industry is still somewhat new and Microsoft will continue to consolidate and improve its patchupdate delivery mechanisms. As Microsoft evolves its technologies patch management software ven-dors will do the same.



Also train Quality Assurance (QA) testers and patch deployment engineers to proficiently useyour tools and testing methodologies to ensure that new patches are thoroughly tested and promptlyand effectively applied.

Even if you are not a software development company, you might be surprised at the QAresources available to assist with the testing of your patches. Whereas QA testers for software compa-nies test developer’s code to look for bugs and performance issues, application service providers(ASPs) use QA staff to test Web sites for proper operation across the target audience of that ASP.Large organizations in more traditional lines of business (LOB) sometimes employ QA testers to testnew functionality for enterprise software such as large financial applications, customer relationshipmanagement (CRM) systems, point of sale (POS) systems, etc. These people are also commonlyexperts with the target systems and you will likely find it valuable to tap their knowledge and famil-iarity with their systems. Plus they might be able to help put together appropriate tests or review yourtriage decisions to ensure that after a patching exercise the target platform remains fully operational.

Chapter 3 describes ideas and attributes for a patch management testing plan. Ensure that theexecutors of these testing plans are also familiar with the patching process and methodology. Whenintegrated into the patch management program your organization’s QA resources will become yourfrontline scouts to warn you of any problems that might arise as a result of a particular patch.

The Full Rally A solid patch management program consists of well-defined processes, effective software, and com-prehensive training. Consider developing a Patch Management Triage and Deployment Team to regu-larly meet and review and prioritize upcoming patches and help marshal the deployment process. Insummary, consider these pointers to help set up your patch management program:• Identify your processes to assess, test, and deploy the updates.• Create a Patch Management Triage and Deployment Team to help coordinate your patch man-

agement activities.• Subscribe to Microsoft and non-Microsoft patch and security advisories and bulletins. For central-

ized management, consider subscribing an internal distribution list to the Microsoft Security Bul-letins newsletter for distribution within your company.

• Review all new Security Bulletins with the team to assess risk and triage deployment of newpatches.

• Weigh deploying updates versus exploit mitigation efforts for different patches, environments, ortargets.

• Determine SLAs for different levels of patches, for example, internal versus production or work-station versus server.

• Devise and document testing procedures to ensure that the appropriate groups test and sign offon a patch before released to production. Consider a burn in period when feasible.

• Select patch testing and distribution software effective for your organization and train staff onhow to use this software to deploy the updates.

• Scope and cost will often dictate whether to use Windows Update or an external patch manage-ment software such as SUS, SMS, or third-party tool to manage the deployment of new updates.

• Drill and train staff not only on the patch management tools but the processes for triaging andtesting new software updates.



• Train QA testers to use the same patch management tools and processes as your productionteams to ensure consistent testing between labs and production.

Microsoft offers and supports low-cost patch deployment tools and tools that scale for very largeenterprises. If Microsoft does not have a solution that fits your organization, consider one of the manynew third-party patch management and deployment software packages that have hit the market.

Chapter 2 will examine the Microsoft Update Bulletin and communications. Microsoft uses theseprimary information delivery mechanisms to inform its customers about newly available patches.



17


Chapter 2:

Microsoft Update Bulletin and CommunicationsA software update fundamentally changes the way that the OS or application code works and insome cases these internal patches can affect the outward operation or behavior of your systems.Additionally, the vulnerabilities that some software updates address might not apply directly (or at all)to every one of your servers and workstations because of their function or location. For these reasonsit’s crucial that you and your Patch Management Triage and Deployment Team understand exactly thescope of the update, including what vulnerabilities the patch addresses and what existing softwarecomponents it updates and affects. This fundamental data will help you triage when and where todeploy the update. For example, you might want to deploy a Windows Media security fix toemployee workstations before applying the fix to Web farm servers because of the greater potentialharm to the workstations. Of course each of these decisions must be made individually for your organization and on a per-computer or class-of-computer basis.

To help answer your questions about software updates, Microsoft continues to improve theirsecurity update communication tools. Microsoft uses email and the Microsoft Security Web site athttp://www.microsoft.com/security as the primary vehicles for communicating new software updatesbut also supports Usenet newsgroups, chats, and Webcasts to get the word out about new updates.

The email messages proactively notify you of all new updates. These notifications describe theupdate, the vulnerability it corrects, the level of severity or urgency, and contains links to other information including the Microsoft Security Bulletin Web site.

The Microsoft Security Bulletin Web site contains detailed information on all Microsoft softwareupdates. Microsoft identifies each update with a unique, sequential label (e.g., MS04-XXX means it isthe XXXth Microsoft Security Update in 2004) and includes summary information about the update aswell as technical details and FAQs about the update including alternate methods for mitigating thevulnerability. Not all updates will have workarounds applicable to your environment for mitigatingthe vulnerability without deploying the patches, but the bulletins explain the steps to implement anyworkarounds.

Microsoft security newsgroups and chats also include a discussion board question and answerforum where end users of Microsoft systems can post questions and other users (often Microsoftemployees or other experts) can respond with answers. Bearing in mind that the information presented in these forums is subjective and unofficial, they are a terrific place to learn about otherpeople’s experiences with a particular update. Microsoft also offers live and archived Webcasts highlighting information about security bulletins.


Spreading the Word Quickly: Microsoft Email Notifications Microsoft primarily uses email messages to alert customers of new security updates. Anyone can subscribe to the Microsoft Security notifications. Additionally if you are a member of an enhancedsupport program such as Microsoft Premier Support, your technical account manager (TAM) mightsupplement these email messages with additional information or early warning of updates specificallyrelevant to your company. (If you are a Premier Support subscriber, talk with your TAM aboutoptions available to you.)

Microsoft sends out email notifications as a part of their newsletter subscription service and theywrite multiple security-related newsletters that target different audiences. When starting out, you mightfind value in subscribing to all the newsletters to get a sense of the content, tone, and audience untilyou find several that best fit your needs. Even if you are a small- to medium-sized business youmight benefit from the additional information provided in the Microsoft Security Newsletter for HomeUsers. This newsletter is aimed at less technical users but often includes additional information thatmight, if forwarded to employees, be useful in helping them secure their home systems (which inturn will likely improve security for your business, especially when mobile users connect remotely).

Signing up for Microsoft security updates is easy. Navigate your Web browser to the MicrosoftSubscription Center at https://profile.microsoft.com/RegSysSubscriptionCnt—you must have aMicrosoft Passport—and sign up for any of the available newsletters that interest you. The securityupdate related newsletters offered in mid-2004 included:

• Microsoft Security Newsletter• Microsoft Security Newsletter for Home Users• Microsoft Security Notification Service• Microsoft Security Notification Service: Comprehensive Version• Microsoft Security Update

Each of these newsletters targets a specific audience with specific information. You can click linksto sample newsletters for each. Table 2-1 lists the security-related newsletters and provides a shortsummary of each newsletter as described on the Microsoft Web site.



https://profile.microsoft.com/RegSysSubscriptionCnt

Table 2-1 Microsoft Security Software Update Newsletters

Newsletter Title Description from the Microsoft Subscription Web SiteMicrosoft Security This monthly newsletter is the authoritative information source for understanding the Newsletter Microsoft security strategy and priorities. Written for IT professionals, developers, and

business managers, it provides links to the latest security bulletins, FAQs, prescriptiveguidance, community resources, events, and more.

Microsoft Security This bimonthly newsletter offers easy-to-follow security tips, FAQs, expert advice, and Newsletter for Home Users other resources that help you enjoy a private and secure computing experience.Microsoft Security Microsoft’s monthly Security Notification Service provides links to security-related Notification Service software updates. The goal of this service is to provide accurate information you can use

to protect your computers and systems from malicious attacks. These bulletins are writtenfor IT professionals and contain in-depth technical information.

Microsoft Security The Comprehensive Updates version serves as an incremental supplement to Microsoft’s Notification Service: Security Notification Service. It provides timely notification of any minor changes to Comprehensive Version previously released Microsoft Security Bulletins. These notifications are written for IT

professionals and contain in-depth technical information.Microsoft Security Update Geared toward home users and small businesses, these monthly alerts notify you when

Microsoft releases an important security bulletin or virus alert and explain, in non-technical terms, when you might need to take action to guard against a circulating threat.

Soliciting Help from Your Peers: Microsoft Newsgroups Let’s say you have received the email notification and visited the Microsoft Security Bulletin Web sitebut you still crave information about how others are responding and handling a new security update.Or maybe you simply have a question that you want to ask a community of users like yourself. To help gather more information about a patch, you can peruse the official Microsoft Security newsgroups or the Internet Usenet for a broad source of supplemental information. The newsgroupsconsist of a threaded conversation forum in which a community of users ask questions and responddirectly with answers to other users’ postings. In many large newsgroups Microsoft Most ValuableProfessionals (MVPs), who are Microsoft-designated experts on a particular product or solution, orother experts will chime in with recommendations or clarifications to the myriad of postings.

Realize that the forum is unmoderated and the information is not official Microsoft (e.g., something a user recommends might be a best practice and recommended for your environment, at times the information might be incorrect). But when you need a quick response from a field

of peers, the newsgroups are a great place to get information. After a few days of assessing the newsgroups, you will more easily recognize the quality information from the bad information.

You can use your Web browser or a newsreader client to access the newsgroups. To visit theMicrosoft security-related newsgroups, navigate to http://www.microsoft.com/technet/community/newsgroups/security/default.mspx and select the newsgroup security topic that interests you. Fromthis Web page you can click one of two links depending on whether you are using a Web browseror newsreader client to access the forum. The Web browser offers fairly sophisticated browser controls, which Figure 2-1 shows, which are fine for casual browsing or searching. You will find that using Outlook Express or another third-party newsgroup reader is much better for frequentnewsgroup usage.

Chapter 2 Microsoft Update Bulletin and Communications 19


http://www.microsoft.com/technet/community/newsgroups/security/default.mspx

http://www.microsoft.com/technet/community/newsgroups/security/default.mspx

Figure 2-1Viewing the Microsoft newsgroup discussions in Windows Update General

The Microsoft Security newsgroup topics include:• Security General• Security HfNetChk• Security Microsoft Baseline Security Analyzer (MBSA)• Security Toolkit• Security Virus

The Microsoft Products and Technologies newsgroups cover:• Access Security• Internet Information Services (IIS) Security• Microsoft SQL Server Security• Windows 2000 Security• Windows SDK: Security API• Windows XP Security and Administration

If for some reason, Microsoft does not list a Windows Update newsgroup on this security page,you can obtain a broader list of newsgroups (including Windows Update newsgroups) from theMicrosoft Communities newsgroups Web site at http://communities2.microsoft.com/communities/newsgroups/en-us/default.aspx. From the left pane of this Web page you can select the language,



http://communities2.microsoft.com/communities/newsgroups/en-us/default.aspx

http://communities2.microsoft.com/communities/newsgroups/en-us/default.aspx

product, and newsgroup that interest you. For example, for a patch management problem firstexpand your language of choice, next look for Windows Update, then click Windows Update General to visit the content of the Windows Update newsgroups.

For faster access and a richer UI than a Web browser provides, use Outlook Express or a third-party newsreader client to subscribe to the Microsoft software update-related newsgroups. Youcan specify to connect to any of the Microsoft newsgroups by configuring your newsreader to connect to the Network News Transfer Protocol (NNTP) server msnews.microsoft.com. Download alist of all available newsgroups, search them, select those that interest you, and subscribe to them, asFigure 2-2 shows. Another benefit of a newsreader is that you can subscribe to a newsgroup and thenewsreader will download new messages for you. This tool makes it easy to check regularly for newinformation or follow particular threads or responses to your postings.

Figure 2-2 Displaying the newsgroups with subscriptions



Msnews.microsoft.com hosts around 10 Windows Update centric newsgroups in different languages. The English software update centric newsgroups include:

• Microsoft.public.officeupdate• Microsoft.public.softwareupdatesvcs• Microsoft.public.win2000.windows_update• Microsoft.public.win98.internet.windows_update• Microsoft.public.windowsceupdate• Microsoft.public.windowsupdate

The popularity of the newsgroups ebbs and flows, so sometimes the content can be quite sparse.At publication time for this eBook, the microsoft.public.windowsupdate newsgroup contained themost messages. If you are looking for an answer to a specific question about a Microsoft softwareupdate, this particular newsgroup is an excellent place to start searching.

The Microsoft newsgroups are not the only newsgroups discussing Microsoft Software Updates.When you need to quickly search the entire Usenet (all public newsgroups on the Internet), try usingGoogle Groups available at http://groups.google.com. This Web-based search engine returns a veryfast search with a threaded conversation of newsgroups containing your search criteria.

You can use Google Groups to search a specific newsgroup too. For example, to search only the Microsoft.public.windowsupdate for all postings containing the words Service Pack 2, enter thefollowing search syntax in the Google Groups search field:

service pack 2 group:microsoft.public.windowsupdate

Click the Advanced Groups Search for even more options.

Microsoft Security Bulletin Web Site So far this chapter has explained how Microsoft uses email messages to proactively let customersknow about new security update releases and it has explored how newsgroups let peers interact toanswer questions about updates. However, the most detailed source of information on Microsoftsecurity updates is the Microsoft Security Bulletin Web site. This site contains the official Microsoftcommunication about specific software updates. These Web pages of information contain detailedinformation about every security update that Microsoft releases. Microsoft lists these bulletins in multiple formats.

To scan for security updates by product and date, which Figure 2-3 shows, navigate tohttp://www.microsoft.com/security/bulletins/default.mspx.



http://groups.google.com

http://www.microsoft.com/security/bulletins/default.mspx

Figure 2-3Scanning security updates by product and date

This page sorts the updates by product and month. Drill down on any month to get more detailson the bulletin, as Figure 2-4 shows.



Figure 2-4Drilling down to the Windows security updates for July 2004

Alternatively, the Microsoft Bulletin Search Web page provides a more useful view and moredirect route to the bulletins. On this page you can view all updates in chronological order, search byproduct or technology, or filter by severity rating. The Microsoft Security Bulletin Search, which Figure 2-5 shows, is available at http://www.microsoft.com/technet/security/current.aspx.



http://www.microsoft.com/technet/security/current.aspx

Figure 2-5Displaying the Microsoft Security Bulletin Search Web site

From this page, select a specific update to drill down to the full bulletin description, which Figure 2-6 shows. The Security Bulletin Search page contains specific information about the bulletin ina consistent format that your Patch Management Triage and Deployment Team can use to maketriage decisions.



Figure 2-6Viewing the full description of a bulletin

The upper section of each bulletin includes the issue date, the version, and any update dateswhen applicable. A Summary section lists

• Who should read this document• Impact of Vulnerability• Maximum Severity Rating• Recommendation• Security Update Replacement• Caveats• Version Requirements for Dependent Components for this Update• Tested Software and Security Update Download Locations• Affected Software



The following four sections contain the crux of the bulletin:• Executive Summary• FAQ• Vulnerability Details• Security Update Information

Ancillary information about the update is described in• Acknowledgements• Obtaining Other Security Updates• Support• Security Resources• Software Update Services• Systems Management Server• Disclaimer• Revisions

The following sections of this chapter describe these items in more detail.

Security Bulletin Titles Microsoft suffixes the title of each bulletin with the Microsoft Knowledge Base number. As Figure 2-5shows, the heading of bulletin MS04-026 is:

Microsoft Security Bulletin MS04-026Vulnerability in Exchange Server 5.5 Outlook Web Access Could Allow Cross-Site Scripting andSpoofing Attacks (842436)

You will notice that Microsoft categorizes its security updates by a number similar to MSYY-XXX(e.g., MS04-025). The YY is the year and the XXX is the number of the bulletin. So in the case ofMS04-026, it is the 26th bulletin of 2004. Some bulletins also list an update number, such as 842436.The update number corresponds to the Knowledge Base article ID number.

So by looking at the earlier name, you can deduce that this is the 26th security bulletin of 2004and the title is Vulnerability in Exchange Server 5.5 Outlook Web Access Could Allow Cross-SiteScripting and Spoofing Attacks. The corresponding Knowledge Base article is 842436.

The name is important because it is the first piece of information that can help you triage theupdate. Generally the update title begins with one of the following:

• Vulnerabiltiy in…• Security Update for…• Cumulative Security Update for…

The phrase Vulnerabiltity in means that Microsoft found vulnerability in one of its products ortechnologies and this security update fixes this vulnerability. (You must still read the details to assessthe vulnerability and the Microsoft response.)



Examples of recent Vulnerability in titled updates include:• Vulnerability in HTML Help Could Allow Code Execution (840315)• Vulnerability in Task Scheduler Could Allow Code Execution (841873)• Vulnerability in POSIX Could Allow Code Execution (841872)• Vulnerability in Utility Manager Could Allow Code Execution (842526)

A bulletin with a title prefixed with Security Update for might contain fixes to multiple vulnerabilities. For example, the security bulletin MS04-011 lists 14 vulnerabilities addressed in a single update:

• LSASS Vulnerability - CAN-2003-0533 • LDAP Vulnerability - CAN-2003-0663 • PCT Vulnerability - CAN-2003-0719 • Winlogon Vulnerability - CAN-2003-0806 • Metafile Vulnerability - CAN-2003-0906 • Help and Support Center Vulnerability - CAN-2003-0907 • Utility Manager Vulnerability - CAN-2003-0908 • Windows Management Vulnerability - CAN-2003-0909 • Local Descriptor Table Vulnerability - CAN-2003-0910 • H.323 Vulnerability - CAN-2004-0117 • Virtual DOS Machine Vulnerability - CAN-2004-0118 • Negotiate SSP Vulnerability - CAN-2004-0119 • SSL Vulnerability - CAN-2004-0120• ASN.1 “Double Free” Vulnerability - CAN-2004-0123

The code CAN-200X-XXXX that follows the name of the vulnerabilities means it is a candidate forinclusion into the Common Vulnerabilities and Exposures (CVE) dictionary managed by the MITRECorporation and funded by the US Department of Homeland Security. (For more information aboutCVE, visit the Web site at http://www.cve.mitre.org/about.)

Fixes to each of these vulnerabilities are wrapped up into one update: MS04-011. When Microsoft bundles many fixes into a single update such as this one, you might think it’s easier todeploy because you need to run only one update. But be careful because if you have a problem orincompatibility with any one of these fixes, you might not be able to install the update and mustforego protection from the remaining vulnerabilities. For this reason it’s very important to read thedetails of each of these bulletins to understand which components will be patched, then assess howthe patches might affect your systems or applications.

If an update’s title begins with Cumulative Security Update for it generally means that this updatesupersedes (and rolls up) all previous updates for that particular product or technology. For example,Microsoft released cumulative updates for the following products on these respective dates:

• Internet Explorer (IE) on July 30, 2004• Outlook Express on July 13, 2004• Microsoft remote procedure call (RPC) and Distributed Com (DCOM) on April 13, 2004

So when installing a base OS, you should be able to install the July 30, 2004 cumulative updatefor IE to make it current as of July for all previously identified IE vulnerabilities.



http://www.cve.mitre.org/about

The title also contains the Knowledge Base number associated with the security bulletin. You can navigate to the Microsoft Help and Support Web site at http://support.microsoft.com and searchfor the Knowledge Base article number, as Figure 2-7 shows, to get a link to any Knowledge Basearticles referencing the security bulletin. In many cases this Knowledge Base article is simply a linkback to the Security Bulletin Web site for that bulletin but sometimes other Knowledge Base articlesmight be available that describe related technical concerns in reference to the security bulletin.

Figure 2-7Using a Knowledge Base article number to search for articles

In addition to the title, every bulletin has an issue date and version number. The issue date isgenerally the second Tuesday of every month but you can spot special (usually critical) updates bydates that break this schedule. For example, MS04-025 was a cumulative update for IE released onJuly 30, 2004. Microsoft deemed it important not to delay this update to the August 10, 2004 (thesecond Tuesday in August) release and released it outside of the normal schedule. The versionnumber reflects the release version of the bulletin. Most bulletins are 1.0 but Microsoft might increment them as new information develops. At the bottom of every security bulletin is a Revisionssection that describes the history of the revisions.



http://support.microsoft.com

Bulletin Summaries Each bulletin includes a Summary section, which Figure 2-6 shows. The Summary consists of a synopsis of the security update suitable for initial reconnaissance and quick triage. Essentially, theSummary informs you whether or not you are an immediate candidate for the update.

The first bit of triage information is listed in the first line of the Summary, titled Who should readthis document. Microsoft lists the audience that the update likely affects, for example: Customers whouse Microsoft Windows or Systems Administrators who have servers running Microsoft Exchange Server5.5 Outlook Web Access.

Microsoft also lists the Impact of the Vulnerability and the Maximum Severity Rating. The Impact of Vulnerability section describes what could happen if someone successfully leveraged thevulnerability. One of the more severe consequences is Remote Code Execution. Other effects might be Local Elevation of Privilege, Denial of Service, or Information Disclosure.

The Maximum Severity Rating is the Microsoft ranking of the security bulletin in level of importance from Critical, Important, Moderate, to Low. Numerous factors go into determining theMaximum Severity Rating of a bulletin. If a bulletin includes fixes to multiple vulnerabilities, then the severity rating for the entire bulletin is set to the highest individual ranking of an included vulnerability. Microsoft also provides a short Recommendation, such as Customers should considerapplying the security update, or Customers should consider applying this security update at the earliestopportunity, or Customers should apply this update immediately.

Microsoft lists the Security Update Replacement that this bulletin’s update replaces (and supersedes), which can be useful in collecting background information about the patch or remem-bering a past test plan used for a previous patch deployment. In addition to the recommendation,Microsoft lists any caveats associated with the update. Caveats are nuances or particularities that customers should consider when assessing or deploying the patch. For example, MS04-026 lists thefollowing caveat, which is useful when considering how to deploy and test the patch:

Customers who have customized any of the Active Server Pages (ASP) pages that are listed inthe File Information section in this document should back up those files before they apply thisupdate because those ASPs will be overwritten when the update is applied. Any customizationswould then have to be reapplied to the new ASP pages.

New patches for complex software such as the OS can touch many different files across differentOS components. Microsoft documents the Version Requirements for Dependent Components for thisupdate to help you determine any necessary upgrades to software that you must perform beforeapplying the security update.

Microsoft also lists the Tested Software and Security Update Download Locations for the affectedsoftware, unaffected software, and affected components. This section contains the links to downloadthe individual updates from Microsoft. After reviewing a few security bulletins, you’ll quickly see the benefit of using a comprehensive patch management tool. For example, the Security BulletinMS04-024 references 10 downloads for the same security update—each one designed and compiledfor a specific platform (e.g., from Microsoft Windows Workstation 4.0 Service Pack—SP—6a throughWindows Server 2003 64-Bit edition). A high quality patch management tool will scan and detect theplatform version of each of your systems and download only the specific updates that apply. Compare this with the arduous process of downloading up to 10 different platform-based updates



(for just one security update), saving them into specific locations, and manually running the properupdate for each different platform. Yuck! Use these testing and versioning notes to help you triagethe update and determine whether the update applies to your specific servers in your environment orwhether other software needs to be updated before the update is applied.

Learning More Details about the Update The General Information section of the security bulletin update includes four sections:

• Executive Summary• FAQ• Vulnerability Details• Security Update Information

Each of these sections includes comprehensive information about the update and in most casesincludes links to other sources of information about the vulnerability or update.

The Executive Summary, which Figure 2-8 shows, presents a short description of the update andthe vulnerability it addresses.

Figure 2-8Viewing the Executive Summary of a security bulletin

It differs from the Summary in that it pulls together all the Summary elements into one narrativeand includes more details. For example, after reading the Executive Summary you should haveenough basic information to determine whether the update is applicable to your environment andwhether you concur with the Microsoft recommendation and severity rating.

A single Microsoft security update can include fixes to multiple vulnerabilities and the ExecutiveSummary will include the individual Severity Ratings and Vulnerability Identifiers for each of the



vulnerabilities as well as available links to third-party information about the vulnerability. Forexample, the update commonly includes CVE identifiers that describe where you can find more information about the vulnerability from the Web site at http://www.cve.mitre.org/cve/.

Sometimes the technical details surrounding an update can be complex and to keep the Executive Summary lean, Microsoft often provides more details about the update as Frequently AskedQuestions (FAQ) related to this security update, as Figure 2-9 shows.

Figure 2-9Displaying the FAQ for a security bulletin

This section’s length and content varies greatly by update. It is a great resource for determiningan update’s applicability and can also answer questions you might have surrounding triaging ordeploying the update. Whereas the Executive Summary aims to succinctly describe the update andvulnerability, the FAQ section can be much more lengthy and can address a variety of ancillary questions surrounding the update.

Microsoft also provides a section in the security bulletin that describes the Vulnerability Details,which Figure 2-10 shows, and delves into the specifics of each vulnerability in the update.



http://www.cve.mitre.org/cve/

Figure 2-10Reviewing the Vulnerability Details for a security bulletin

This section supplies additional background for the vulnerability, presents any mitigating factorssurrounding the vulnerability, offers workarounds for the vulnerability, and provides another FAQsection that focuses solely on the vulnerability.

Two areas in the security bulletin that are important to consider when making triage decisionsconcerning whether or not to roll out the update are the mitigating factors and workarounds provided in the Vulnerability Details. The mitigating factors describe circumstances that lessen theeffects of the vulnerability. An example of a mitigating factor is that a user must be logged on to asystem before a specific vulnerability can be exploited. This means that not everyone could exploitthe vulnerability, only trusted users. This essentially removes the threat of anonymous or noncreden-tialed users from attacking the system.

An RPC-based vulnerability might include workarounds similar to the following examples. Theworkaround might be to block RPC ports at the firewall to prevent Internet users from exploiting thisvulnerability on your internal network. Or a workaround might be to disable Outlook Web Access(OWA) on Exchange Servers that reside on an external network and are not used for OWA. (Bydefault, OWA is installed on all Exchange servers.) The vulnerability FAQ section provides more detailabout the vulnerability and often addresses both novice and expert questions.

Think of the mitigating circumstances and workarounds as stop-gap measures that lessen the risk of exploit until you can deploy the software update—especially for zero-day exploits when aworm or attack is infecting the Internet and you have not had time to test and patch your vulnerable



systems. Generally speaking, these are short-term solutions and you should not rely on them in lieuof deploying the update.

In addition to the executive summary, the FAQ section, and the vulnerability details, the securitybulletin also describes in detail many of the mechanics of the security update including:

• Prerequisites• Installation Information • Deployment Information• Restart Requirement• Removal Information • File Information• Verifying Update Installation

The Prerequisites section lists any software that you must install or upgrade before installing thesecurity update. These prerequisites also might be listed in the Executive Summary under the versionrequirements or recommendations.

The Installation Information describes how to install the update such as what parameter switchesthe update supports. Microsoft uses multiple update installation engines for different products and theinstallation information section of the security bulletin is a good place to find out which engine a particular update uses and how to control the specific deployment of the update.

For example, many updates use the GUI Hotfix utility, which supports a common set of switches.Ordinarily when you double-click the executable of the update (or run it from the command linewithout specifying any switches), the update will run and invoke a dialog box and prompt youthrough the installation. However for GUI Hotfix utility supported updates, you can also run theupdate with the following supported switches:

/x to generate a list of packaged files /s to perform a silent installation /z to generate a list of packaged files and restart the computer/m to prompt you for folder locations

Many patch management distribution tools remove you from these manual processes but if you needto deploy a patch directly (such as by logon script or while logged on to the console), these switchescan come in handy.

The Deployment Information section of the security bulletin lists the specific step-by-step instructions for deploying the security update. Many simple updates might provide an example ofrunning the update from a command prompt using common switches (such as to restart the computer or to run in a quiet or silent mode). Other deployment information examples mightdescribe how to install updates that contain multiple files that you must apply in a specific order. The deployment information explains exactly how to install the update.

To restart or not to restart is often the question. Restarting a server equals downtime but runningupdated software without a restart can cause stability problems. In the Restart Requirement section ofthe security update information Microsoft tells you whether a restart is required after deploying a specific update. Restarts are not always required and it is good to know in case your patch manage-ment software is configurable to optionally restart the computer. For example, when updating thecode of a running service, update installer might try to stop the service, patch its files, then restart



the service. If any of these actions fail, the installer might notify you that a restart is required. Additionally, many of the Microsoft installers and update engines let you specify whether to force orprevent a restart.

In the unfortunate event that a software update adversely affects a server or application or in therare circumstance that the update contains errors, many updates support rollback to the pre-updatecode. Not all updates support rollback. The security bulletin tells you whether the patch can be uninstalled in the Removal Information instructions. To uninstall an update, you can generally useeither the Add/Remove Programs tool in the Control Panel or the command-line uninstall executableinstalled with the update. Remember that not all updates can be uninstalled, so be sure to test firstand use the uninstall feature only as an emergency fallback in case the unanticipated occurs.

When triaging an update it is sometimes helpful to know how invasive the update is. In otherwords, what files does the update change? The File Information of a security update lists all theaffected files and their new attributes such as file date, time, size, version, name, folder, and in somecases the platform (e.g., IA-64 or X86). This table, as Figure 2-11 shows, tells you first hand what fileswill be changed and gives you a sense of how expansive the update is.

Figure 2-11Viewing the File Information of a security bulletin



Of course after the files have been copied and the update installed, it’s always important to verifythat the patch has been successfully installed. This verification information also comes in handy whenyou are applying patches across many servers and want to check which computers have beenupdated and which have not. The security bulletin describes how to check the status in the VerifyingUpdate Information section, which Figure 2-11 shows. This section describes how to use tools likethe MBSA to check whether the hotfix has been installed on a local or remote system. Additionally,this section describes how to compare the files on your computer’s hard disk with the updated fileslisted in the Updated Files section of the bulletin (described earlier) or by checking the registry for anew key specifying the update. Checking the file version is usually more reliable than checking theregistry and many of the third-party patch management tools use a combination of methods to ensurethat the patches are successfully installed.

The remaining content of the security bulletin lists information sources for other security updates,provides links to Microsoft security resources, and describes the Microsoft patch management toolssuch as Microsoft Software Update Services (SUS) and Microsoft Systems Management Server (SMS).At the bottom of each security bulletin is a chronological list of the Revisions made to the bulletinand the information changed in the bulletin.

The Frequency of Patch Releases In October 2003, as a part of the Microsoft Trustworthy Computing initiative, Microsoft began toannounce and distribute security software updates on the second Tuesday of every month. Only critical updates or updates with exploits circulating in the wild are released outside of this schedule.This schedule benefits your Patch Management Triage and Deployment Team because it lets you plan regular meetings and potentially balance (and reserve or allocate) resources around theseannouncements. Also, deploying batches of updates is generally more efficient to triage than anunpredictable trickle of updates.

A few days before “Patch Tuesday” some Microsoft contract support programs (such as PremierSupport) might notify you of the quantity or severity of pending patches for preplanning purposes.However, this information definitely can change right up to when the patches are released. To beginMicrosoft generally releases the patches in the late morning, next updates the security bulletin Websites, then sends out the security bulletin email notifications. Updates to patch management programslike SUS and third-party solutions generally follow within 24 hours or so of the first announcement ofthe patch.

Interactive Education: Webcasts Every month Microsoft hosts live Webcasts during which Microsoft presenters discuss that month’s setof updates. View and sign up for the security-related Webcasts at the Security Program Guide locatedat http://www.microsoft.com/seminar/events/security/default.mspx.

Some of these Webcasts are technical and target the experienced IT Professional whereas others, such as the Microsoft Executive Circle Webcast, target business decision-makers (BDMs). Thetechnical Webcasts describe in detail the updates and vulnerabilities as well as provide a forum forquestions and answers about that month’s updates. These Webcasts usually cover an overview of thebulletins, list and discuss any workarounds to the vulnerabilities, explain how to determine what systems the updates apply to, and show how you can deploy the updates to your systems. TheseWebcasts follow the content in the security bulletins but provide a different forum for learning about



http://www.microsoft.com/seminar/events/security/default.mspx

the updates than just the Web-based security updates alone. The Webcasts do not contain as muchdetailed information as the security bulletins but they might present additional information notincluded in the bulletin depending upon the presenter’s background and knowledge. Additionally, thequestion and answer session might address areas not covered in the Web bulletin. In case you missone, the Webcasts are available for replay after the live presentation.

Processing All the Information Microsoft provides multiple channels for disseminating information about new security updates. Onthe second Tuesday of every month Microsoft releases new security updates but they occasionallywill release an out of band update under certain circumstances. By subscribing to email notifications,posting your questions to security update focused newsgroups or pursuing in-depth Web security bulletins, you can be sure to stay up-to-date and educated about the latest Microsoft security updates.

Microsoft also provides Webcasts and chats as another forum for getting the word out. To helpwith your patch triage and distribution program, be sure that you are up to speed with and knowledgeable about the Microsoft security update communication network so that you can

• subscribe to the Microsoft Security email notifications• visit the Microsoft Security Update Bulletin Web site to get detailed information for all

Microsoft security bulletins• understand each of the security bulletin sections so that when a critical patch is released you

know where to quickly look for information• use the Microsoft security update newsgroups, which provide an unregulated forum for

posting questions and responding to your peers’ questions and comments• be on the lookout for new and evolving communication, such as the Microsoft Webcasts that

provide live or specialized channels of security update information

The next chapter will examine test plans, methodologies, and other best practices for testing andpreparing for the deployment of security updates in your environment.



38


Chapter 3:

The Dry Run: Setting Up a Lab to Test Patches and Updatesand Using Microsoft Baseline Security Analyzerto Scan for Missing Patches As with just about everything, practice makes perfect and patching systems makes no exception. Ok,so installing a patch doesn’t require too much practice. But your patch deployment tactics as a wholewill directly benefit from careful planning and execution, which can be facilitated by dry runs andpatching drills. If you manage an organization with many different systems performing a variety ofroles, you’ll find practice and planning of your patch deployment process invaluable to minimizingdowntime and unpleasant surprises when rolling out patches to all your production servers andworkstations.

The extent and ability to test patches depends on your organization’s size and varies by system.For example, heavy-load Web servers or large database servers might be hard to replicate in a labenvironment, but perhaps smaller versions of the same equipment can be tested. Also, plan to spendmore time testing critical servers or servers running custom applications. Third-party applications willnot have been tested as a part of Microsoft’s prerelease patch quality assurance (QA) process, so youwill want to ensure that a new patch does not adversely affect your non-Microsoft applications. Forexample, you should test an external Web site running custom code differently than a more or lessvanilla file and print server running only the Windows OS.

This chapter examines different ideas and approaches to putting together a test environment tohelp with predeployment testing to minimize the risk of a patch adversely affecting your productionsystems. Consider the ideas in this chapter as guidelines that you can mold to fit your particular organization and server topology. In an ideal world, we would have a comprehensive lab thatmatches our production systems exactly and no time constraints so that we could perform full software and patch regression testing. Not surprisingly, you will have to make day-to-day decisionsincluding not only when and where to deploy a patch, but also what level of testing you willundergo. You must continuously weigh the risk of an unpatched server against a shortened testschedule.

Lastly, this chapter examines Microsoft Baseline Security Analyzer (MBSA) a freely downloadabletool from Microsoft that you can use in your lab and production environment to find missing patchesand confirm patch deployment success. If you are using a deployment tool that does not supportuser-initiated scans of targeted systems, then you will find MBSA an especially important tool in yoursecurity update toolkit.

Chapter 3 The Dry Run 39


The Test Lab Creating a test lab that emulates your production systems provides an important foundation for constructing your patch management program. This test lab will let you deploy patches, test newpatches for compatibility with your existing applications, and let you conduct load testing, penetrationtesting, or other specialized testing not feasible to perform on production systems.

Ideally your test lab will consist of a subset of servers with each representing a type of server in your production environment. Include at least one of every type of server that you have in production. You may have multiple Exchange servers, a cluster of Web servers, or multiple SQLServers configured to replicate between each other. Best case, you need to configure all these typesof components and interactions in your lab. If you have a Web farm of many servers, you mightneed to use only one or two computers (depending on how they interact with each other) to represent this configuration in a lab. If you use clustering for load balancing or high availability oruse Application Center to configure your production servers, then you will likely want to configure asimilar system in your lab comprised of fewer servers but that uses these same services. Even thoughcreating a lab to this level of detail can be difficult or time consuming, you will find reward the firsttime a patch breaks something in your lab and you discover it there instead of production.

Your lab computers need to run on hardware platforms similar to production to ensure that the BIOS, hardware drivers, monitoring software, array software, and other drivers closely matchthose used in production. You might not want to match the hardware exactly due to cost, size, orother reasons. Most server manufactures produce a line of servers that use many of the same components throughout the family. Check whether you can represent your more powerful servers byless expensive counterparts in the lab. Perhaps your quad-processor server with 4GB memory and amassive disk array can be represented in the lab by a much smaller dual-processor server of the same line.

Also, consider the similitude of your lab to production. Configure your domain controllers (DCs)and domains in your lab like your DCs and domains in production, mimicking any Group PolicyObject (GPO) settings including security templates.

Creating Your Lab: Using Virtual Machines vs. Dedicated Hardware Advances in virtual PC/server software such as Microsoft Virtual PC and VMware Workstation orVMware Server let you host multiple and independent PC instances on one server. In essence youcan install a DC, Web server, and other member servers all as separate virtual computers hosted fromone hardware platform. The OS within virtual instance thinks it’s running on its hardware.

These virtual PC technologies can help lower costs and make it quicker to restore the states ofcomputers after a lab exercise. (For example, you can generally make a backup of the files thatdefine the virtual computer, then simply copy them back to restore the original state of the computer.If you use Microsoft Virtual PC, then you can use an undo disk (directly from the Virtual PC application) to return to a known state.

Use virtual machines to test nonhardware-related patches or to build up a lab infrastructure thatyou will not use for direct patch testing. However, do not rely on virtual machines for end-to-endpatch testing because the hardware in the virtual computer will be different than your productionserver hardware.

For example, a virtual PC can be beneficial to patch testing when you want to deploy patches toseveral Web applications each running on separate Microsoft Internet Information Server (IIS) servers.You can install these Web applications on multiple virtual servers, then test how a patch might affectyour Web application code. But this testing examines the patch against only your code—not the OScode and its interaction with the hardware platform. For this complete end-to-end testing you need totest on a platform base consisting of the same server platform family (or when feasible, testing on thesame server model), OS version, and similar ancillary software installed. Don’t forget to also installyour monitoring software or other agent-based software possibly installed on your production servers.You need to consider each of these software components, although possibly very small, when creating your lab because they can affect the success or failure of your patch installation.

As a guide during your security update triage exercises, remember to consider what componentsa specific patch affects. The Microsoft security bulletin lists each of the files that a patch replaces and updates so that you can use this information to help construct or confirm that your test lab isadequate in appropriately relevant areas. For example, if you plan to apply a security update that corrects a problem in the SNMP subsystem, you will want to be sure that you have all of your monitoring software (such as HP OpenView or other SNMP-based monitoring software) installed andrunning on your test systems before applying the patch. After installing the update, you can confirmthat the systems continue to operate as expected.

Configuring Forests, Domains, and DCs Install a test lab with a forest structure that matches production. Configure user accounts similar toyour production domain. If you rebuild your lab (which is a good idea to do from time to time), consider writing a script to programmatically create your user accounts and groups and assign security group memberships. The more that you can automate, the quicker it will be to restore alab—especially if it is used for purposes other than security update testing. Also don’t forget toupdate or extend your lab schema to match production, such as running Adprep. Again, the closeryour lab matches production, the higher the chances of discovering patch deployment problemsbefore they adversely affect production.

You can use a virtual computer environment to build out your forest in which you functionallyrepresent multiple domains by installing multiple DCs on one virtual computer hosting server. However, remember to keep in mind the caveats described earlier and avoid patching these virtualcomputers as a legitimate test. You can use the virtual computer servers to help you build out yourdomain structure, but do not use them as members of the test bed. (Of course, you will want topatch these computers anyway to harden them from possible exploits just as if they were in yourproduction environment. Don’t forget to patch your virtual computer host servers as well!)

Patch Deployment Software Use the same patch deployment software in your lab that you will use in production. If you useMicrosoft Software Update Services (SUS) to deploy your patches in your production environment,include an SUS server in your lab and use it to deploy the updates in your lab. Following your production process as closely as possible will help identify any problems associated with themechanics of rolling out the patches and give you a feel for the particular deployment. Considerwatching for these characteristics in the lab:



• Observe the time taken for patch deployment from start and end. • Make notes of any dialog boxes that might prompt during the rollout process and how to handle

them. • Ensure that your patching software successfully downloads the proper updates, stages them for

deployment, then copies and installs the patches on the target systems. • Conduct a postinstallation scan with your patch management software or another tool like MBSA

to confirm that each test patch was deployed correctly. (The last part of this chapter describesMBSA and how to use it to scan for missing updates.)

Another benefit of using the same production and lab patch deployment software is to ensureproper configuration for deploying updates to the wide variety of software that might need updates.For example, some Microsoft Office patches require access to the Office application files distributionpoint from which to copy source files. Using your patch deployment software in the lab, you canuncover these types of requirements early in testing. When you are ready to roll out to production,you will have already vetted your deployment process from start to finish. Scanning new softwarewith antivirus software to ensure that viruses are not introduced into your network is also a goodidea.

Network Considerations In some cases with more sophisticated labs, you might want to simulate deployments across networkconnections like those used in the production network. For example, you can use a network latencysimulator to emulate the characteristics of a slow WAN connection between your main office and abranch office. Testing your patch deployment software across a slow link such as this will help youidentify network-related concerns early on. An example of a network latency simulator is theFreeBSD DUMMYNET program. This emulator lets you simulate a variety of network scenarios, whichmight be useful when you are testing the deployment of a service pack to several computers in aremote office and you wonder what the effect might be on the WAN link or how long a remotedeployment might take when using your deployment software.

Deploy firewalls in your lab the same as those in production, including a similar access control list (ACL). For example, if your production servers cannot access the Internet, then your labcomputers need to have a similar restriction. These restrictions can help identify potential problemswith your patch deployment process before they surprise you in production.

Living Dangerously: Using Production as Your Test Lab Although not advisable, sometimes you must test in production. In some circumstances you mighthave a test lab (and have fully tested the patches to your satisfaction) but still prefer to roll out toproduction in a staged manner. These types of live deployments best work in environments that havemany servers performing one role, such as a Web farm consisting of many load-balanced Webservers. For example, let’s say you have 20 Web servers each sharing the incoming Web traffic load.Perhaps to build in redundancy, you added extra Web servers so that several could fail withoutaffecting overall service availability. In essence you have a tolerance to risks associated withdeploying an untested patch in production. (Of course, you will want to consider what happens if arogue patch on even one server affects data integrity to a backend database or other downstream





server.) Even in this scenario end-to-end testing is preferable to deploying an untested patch to a production environment.

However, deploying a patch to a live production server will give you real-world data not available in any lab. This data will tell you exactly how the patch will perform in your daily environment. Again, however, this type of deployment is final and much more risky when performedin lieu of formal testing. For better results, test the patch fully in a lab, then deploy it to one or twoservers in production to burn in the patch before deploying it to all your servers. However, there isno panacea. This extensive testing and burn in period is disadvantageous as it takes time, therebyincreasing the risk to your unpatched servers, which are possibly vulnerable to exploit. Rememberthat patching a computer system is changing the software code running on it, so be sure that youhave a reliable (and tested) backup and restore process or failover/high availability options for serversless tolerant to downtime and outages.

The Test PlanA well-defined test plan that exercises the functionality of your systems after deploying a patch is justas important as a properly configured test lab. Your test plan needs to flex and test key aspects ofyour servers and the applications that run on them. A plan can be very basic, such as deploying anupdate to a corporate workstation, then testing the functionality of the update by logging onto thenetwork, running Office programs, and accessing the company intranet.

Other plans might be specific to a server function. For example, if your company hosts a Webapplication, you might be able to borrow regression tests from your QA department that test all components of the Web application. Depending on the sophistication of your application your company might even have developed automated testing scripts or programs that you can leverage foryour patch testing.

Automated testing probes many different aspects of an application’s functionality in a reliable and repeatable manner. To take this one step further, automated unit testing systematically tests thelow-level functionality of many different systems—often times at the object level. Although unit testingmight not be possible for all organizations, you might be surprised at what you can find alreadyexists in your organization—especially if you already employ a QA department whose job it is to testserver-based applications. Also, unit testing is not necessarily limited to a single server. The testingmodules might be able to test everything from the Web application to backend data-processing components such as database servers or n-tier servers.

A test plan for conducting regression testing on patches is an important component in reducingrisk when deploying new patches in your environment. Microsoft releases patches monthly, so youwill be more efficient if you devise a repeatable plan that you can use for every patch deployment.The test plan should not only exercise the functions of the application before and after deploying thepatch, but also search for signs of possible deployment problems, such as errors in the event log.

Verifying Installation and Scanning for Missing Patches with MBSA Scanning your test and production systems is an important component to confirming that the patchhas been installed successfully. Most patch management software products provide this type of scanning because it is an important first step towards the deployment of the patches. An exception tothis is SUS, which uses the client-based Automatic Updates to determine whether or not a patch isdeployed. SUS also lacks a target-based scanner. Therefore, using this tool to determine your level ofpatch compliance for target systems in your organization is somewhat difficult. For example, if youhave configured SUS to download but prompt users to install the patch, you can’t easily determinehow many users have installed the security update.

To complement Microsoft’s patch-deployment systems—or to implement a simple update-detection system—you can use the small, yet agile, and feature-packed MBSA to regularly scan yournetwork. MBSA not only scans local and remote systems for patch-update status but also performsmore than 65 vulnerability-scanning tests specific to Microsoft products. And although MBSA doesn’tpatch your systems or plug your holes, the product’s fast and lightweight approach provides a quickand efficient method for canvassing your systems for common vulnerabilities.

No stranger to update scanning, MBSA provides the scanning engine that the enterprise-focusedMicrosoft Systems Management Server (SMS) uses. MBSA also supports vintage HFNetChk function-ality. HFNetChk, MBSA’s predecessor, enables local and remote scanning of Microsoft OS securityupdates, as well as updates for Microsoft’s enterprise applications such as Microsoft Exchange Serverand Microsoft SQL Server. To extend HFNetChk’s functionality, MBSA features product security scansthat search for known OS misconfigurations that can result in system vulnerabilities.

MBSA includes both a graphical front-end version for ad hoc scanning and a script-friendly command-line interface version. MBSA saves its scan results in an easy-to-read XML format, furtherincreasing the product’s usefulness by writing custom reports that fit your needs.

MBSA CompatibilityMicrosoft released MBSA 1.2.1 in August 2004. Although you must run this version of MBSA from aWindows Server 2003, Windows XP, or Windows 2000 (Win2K) computer, you can remotely scanWindows 2003, XP, Win2K, and Windows NT 4.0 systems. Using one scanner to scan multipleMicrosoft products presents a challenge because of update-format compatibility problems. Microsoftuses multiple update engines and processes for many of its products, and until the company concen-trates on one method, many of its update tools will work with only specific products. (For example,the Microsoft Office update tools work differently from the Windows Update tools, resulting in incom-patible update-distribution methods.) Despite these challenges, MBSA supports security and updatescanning for the Microsoft products that Table 3-1 lists.



Table 3-1 MBSA-Supported Microsoft Products

OSs Server Software Desktop Applications ToolsWindows 2003 BizTalk Server Internet Explorer (IE) Microsoft Data Access

Components (MDAC)Windows XP Commerce Server Office MSXMLWindows 2000 Content Management Server (CMS) Windows Media Player (WMP) Microsoft Virtual

Machine (VM)Windows NT 4.0 Exchange Server

Host Integration Server (HIS)IISSQL Server

MBSA Installation and Configuration MBSA installation is a snap. Download the MBSASetup-EN.msi Windows Installer (.msi) file from the MBSA Web site at http://www.microsoft.com/technet/security/tools/mbsahome.mspx. This sitecontains detailed information about MBSA, including descriptions of the MBSA scans and an FAQ thataddresses how MBSA interoperates with other patch-deployment systems (e.g., SUS).

By default, the setup program installs MBSA in the C:\Program Files\Microsoft Baseline SecurityAnalyzer directory. This folder contains the MBSA executables mbsa.exe and mbsacli.exe, which provide the GUI and command-line interface to the scanning application. The installation directoryalso contains the HTTP and Extensible Style Language Transformations (XSLT) templates that MBSAuses to format and display the builtin reports. A Help directory provides comprehensive descriptionsof each test that MBSA performs.

Every time you run an MBSA scan, the program attempts to download a file called mssecure.cabfrom the Microsoft Web site. If your computer is not connected to the Internet, you will need todownload the XML file manually to update MBSA and have new patches reflected in the reports. Thiscompressed XML file contains all the most recent software updates. Optionally, if you host an SUSserver, you can direct MBSA to obtain its list of approved updates from that server instead of directlyfrom the Microsoft Web site. Consequently, your reports will reflect only updates that you approvedwith your SUS server. MBSA’s ability to reference and use your list of previously approved SUSupdates helps you enforce your corporate update policy without the distractions of false positivesfrom unapproved updates. For example, you might use SUS as the gatekeeper to manage the rollout of new updates to your end users. After you’ve assessed the applicability and tested the compatibility of a particular update, you approve its deployment through SUS. Then, depending onyour environment’s SUS configuration, end users’ computers will either automatically download andinstall the patch or download and prompt them for manual installation. To enforce your updatepolicy, use the graphical MBSA or the command-line mbsacli utility to scan your end users’ computers for missing updates. Schedule MBSA to run weekly and pull its list of updates to checkfrom your SUS server’s list of approved updates. The resulting XML reports will show you which systems haven’t been successfully updated with your specifically approved updates.

To perform all the MBSA-supported scans, you need Local Administrator privileges on the targetsystems. Run mbsa.exe to launch the scanner’s graphical version. This version provides a simple-to-



http://www.microsoft.com/technet/security/tools/mbsahome.mspx

use interface so you can quickly specify which scans you want to run and which computers youwant to run them on, as Figure 3-1 shows.

Figure 3-1 Selecting computers to scan and which scans to perform

First, to specify the targets of your scan, in the MBSA GUI click Pick a computer to scan or Pickmultiple computers to scan, then enter an IP address, a range of IP addresses, or a domain name.Next, select the scan options, including Check for Windows vulnerabilities, Check for weak passwords,Check for IIS vulnerabilities, Check for SQL vulnerabilities, and Check for security updates. Optionally,you can specify an SUS server whose list MBSA will use to compare with each client. Otherwise,MBSA will use the list of all updates that Microsoft provides. By default, the graphical MBSA clientperforms what Microsoft calls a baseline scan, which scans for and reports on only critical updates(which Windows Update defines) as opposed to all security updates.

Start Scanning To begin a scan, click Start scan. The length of time a scan takes depends on which options you’vechosen. For example, in my environment a comprehensive scan of a 16-computer network comprisedof a variety of services, including IIS, SQL Server, and Exchange, took about 5 minutes to finish. Bydefault, MBSA writes the security reports to the \%userprofile%\securityscans folder as XML files.MBSA creates a separate XML report for every computer it scans, each time it scans the computer.These reports are generally about 20KB in size.



After you run the scan, click Pick a security report to view and select the name of the report youwant to view. Although MBSA lets you sort by computer name, IP address, and scan date, you mightneed to delete old reports to keep the list from cluttering your folder after running multiple scans. InFigure 3-2 an example report shows which critical security updates are missing from a computer.

Figure 3-2 Showing missing critical security updates



MBSA Command Line The command-line version of MBSA supports two syntax structures: a command-line equivalent ofMBSA and a syntax that matches the popular command-line patch-checking tool HFNetChk. (In fact,MBSA replaces the standalone HFNetChk tool.) Run the

mbsacli /?

command for a listing of command-line options and the

mbsacli /hf /?

command for a listing of arguments that this improved HFNetChk supports.The console-based mbsacli lets you use command-line arguments to specify most configuration

options. Therefore, you can use any Windows scripting technology to script a wrapper that callsmbsacli to scan multiple systems or networks. You can even schedule a scan to regularly check thestatus of your domain or specific computers. For example, a scheduled scan that reports only missingupdates on one computer might look like

mbsacli /n os+sql+iis+passwords /i 192.168.0.151

Microsoft understands that many people want to script or schedule such scans, so the productprovides several output-suppression and output-redirection options. The following command redirectsthe scan output to the network share \\wkstn\logon and writes it to the scan.txt file:

mbsacli -f \\wkstn\logon\scan.txt -c sl-blvu\dc4

To configure MBSA to pull the list of updates to check for from your SUS server’s list ofapproved updates use the command

mbsacli /sus “http://susserver” /i 192.168.0.10

Viewing Reports Mbsacli doesn’t display verbose scan details to the console, as HFNetChk does, but instead displays asummary of results, which Figure 3-3 shows.



Figure 3-3 Displaying summary scan results

However, mbsacli generates the same XML reports that the graphical version of MBSA createsand also supports command-line arguments for listing and displaying these reports. For example, asFigure 3-4 shows, the mbsacli -l command lists all XML reports that reside under the user profile ofthe person running the command (\%userprofile%\securityscans).

Figure 3-4 Listing XML reports that reside under the user’s profile

You can use the -ld report name option to access the reports. For example, using the data fromFigure 3-4, you can use the following command to display the most recent scan of the computercalled dc4:

mbsacli -ld “SL-BLVU - DC4 (10-15-2004 11-24 AM)”



As Figure 3-5 shows, this command displays a text interpretation of the XML report that you can parse. However, using XML scripting technologies to directly extract the data provides greaterflexibility and control over the data.

Figure 3-5 Displaying a text interpretation of an XML report

MBSA as HFNetChk Replacement Although HFNetChk doesn’t provide the security checking or XML reporting that MBSA offers, it doesprovide a quick and easy method of listing all missing updates on a specific computer. WhereasMBSA defaults to performing baseline scans, HFNetChk scans all security-related updates. Using the -b switch to force HFNetChk to perform a baseline scan looks like

mbsacli -hf -b

If you want to simply view all security updates missing on a specific server, run the command

mbsacli -hf -h sl

where -hf instructs mbsacli to use the HFNetChk argument parser and -h sl specifies the hostnamed sl. The output of this command displays all missing updates, as Figure 3-6 shows.



Figure 3-6 Displaying all missing updates using the HFNetChk-based scanner

Notice that MBSA reports several Note messages and one Warning message. MBSA (both thegraphical and command-line version) displays these messages when it can’t determine whether anupdate has been installed or to notify a user of a security problem that an update can’t fix. Forexample, if an update exists for both Microsoft XML Core Services (MSXML) 4.0 and MXSML 3.0 andthe target machine has MSXML 4.0 installed, MBSA might display a note informing you that theMSXML 3.0 update hasn’t been installed. The Microsoft article “Microsoft Baseline Security Analyzer(MBSA) returns note messages for some updates” at http://support.microsoft.com/?kbid=306460 liststhe explanations behind many of these notes and warnings.

MBSA reports these notes for every scan. However, you can use the -s n argument to disablenotes and exclude them from your reports. Use the -s 1 argument to suppress notes and use -s 2 tosuppress both notes and warnings.



http://support.microsoft.com/?kbid=306460

MBSA Limitations Although MBSA performs admirably as an all-in-one update-checking tool and basic Microsoft productsecurity-configuration checker, it has limitations. MBSA doesn’t scan for Office updates or updates thataren’t related to security, so you’ll need to rely on other tools to report those updates. MBSA is strictlya scanner and doesn’t deploy patches or remediate misconfigurations. (However, it provides usefulHelp documents that walk you through the remediation of any discovered vulnerability.)

The Timeline from Test to Production Testing is a valuable step to reducing the risk involved in deploying a new security update. The two hurdles to an effective testing regiment are cost and time. A lab can be expensive in terms ofserver costs and the resources needed to build and manage the lab computers and supporting infrastructure. The second hurdle to a comprehensive testing program is the time needed to evaluatethe update, install the update in the lab, perform adequate testing of the patch against your systemsand applications, then formally approve the update for deployment to production. These steps usuallytake days to weeks, which can significantly increase the risk to your frontline systems—especiallythose susceptible to an attack vector.

Deciding what amount of testing is the right amount is difficult. As guidance you will find the most success in creating a lab that is representative of production and defining a set of test procedures that you can execute for new patches. Next, when updates are released, spend time tolearn about their types, the vulnerabilities they address, and any mitigating factors. This knowledgewill help you establish a timeline to work with and assess the risk of delaying the deployment whileyou execute your tests. Also, the security bulletins should provide an understanding of the intrusive-ness of the updates. A service pack will require more testing than the update of one, less frequentlyused application. Lastly, execute your test procedures in full before and after applying the update.This step will give you confidence (as well as punctuate any tactical steps necessary during patchdeployment) when you deploy the patch in production.



52


Chapter 4:

Microsoft Patching TechnologiesWhen you download a patch from the Microsoft Web site and run it, you are running an installerapplication configured to install the patch. Today, Microsoft relies on several different patchingengines to apply security updates to its products, although the company is making an effort to reducethis number. Depending on the type of patch management software that you use, you might findyourself having to work with these different types of installers. For example, you might need tocreate custom deployment scripts such as logon scripts to install patches, you might need to customize deployment packages of a product like Microsoft Systems Management Server (SMS), oryou might just find yourself needing to test a new patch or troubleshoot a failed deployment. Understanding how these different installers work will make it much easier to do tasks like these.

Almost every Microsoft patch is wrapped up into a self-extracting executable that you downloadfrom the Microsoft security Web site, then run on the target system to install the patch. However,depending on the patch installer chosen to package the patch, you might be able to customize thedeployment, such as quietly deploying the patch without user interaction or suppressing a rebootafter the patch has been installed. To take advantage of these custom installation options, you willneed to know the type of patch installer that was used to create the patch, as well as the command-line switches for that specific installer. Many patch management software packages absolve you fromworrying about these details, but even if you use a sophisticated product like SMS to deploy yourpatches, you might find yourself needing to learn the parameter syntax for the different installers tocreate specialized patch deployment packages.

This chapter is not intended to promote manual patching in lieu of using patch management software. Due to many patch installers, the increasing frequency of patch releases, and the variety ofOS platforms and software versions that must be supported, using robust patch management softwareis a must. Also, patching a computer system is not necessarily a one-time process. When you install anew software component or if Microsoft updates the patch, you might need to reapply the patch. Forexample, if you install Microsoft IIS, apply several IIS security updates, and later uninstall and reinstallIIS, you will need to reinstall the related security updates. Plus, knowing which patches relate to eachcomponent is difficult. So when you install a new component, rescanning the entire system formissing patches is a good idea. Use a full-featured patch management software that fully scans thefiles installed on a system, as opposed to simply checking the registry for installed patches. This way,through regular scanning, you can ensure that all systems are up to date with the latest securityupdates.

This chapter takes a look at Microsoft’s most popular patch installer engines and their command-line syntax to explain how to use these programs for customized deployments.

Chapter 4 Microsoft Patching Technologies 53


The technologies and techniques discussed in this chapter make up the core essence of installingMicrosoft updates which consists of

• Downloading a wrapper that includes the installer and the patched files• Decompressing the files and starting the patch installer• Replacing the vulnerable files with the updated files

Historically many of the major Microsoft product families (such as Windows, Office, SQL Server,Internet Explorer (IE), and Windows Media Player—WMP) used different patch installer engines,which made using a single method to deploy the patches difficult. Today Microsoft uses theupdate.exe patch installer for packaging its Windows and IE security updates and service packs andOHotFix for deploying Office updates. You will encounter other installers if you support SQL Serveror older platforms such as Windows NT 4.0.

Decoding a Software Patch Most Microsoft security updates consist of a software patch to correct an identified vulnerability in theoriginal code. After Microsoft releases a new security update and you have deemed it appropriate toyour environment, you need to do a few things to install the software patch. To begin you mustdownload the appropriate software patch from the Microsoft Web site to a computer on your net-work, then copy the file to the target computer that you want to install the patch on. These files arealmost always self-extracting executables. This means to install the patch you simply run the patch fileby double-clicking it or executing it from a script or command line. Running the patch file from thecommand prompt with additional command-line parameters lets you control the patch installation, forexample suppressing reboots or installing quietly in the background without user interaction. Mostpatch management software deployment programs use Microsoft’s original patch files and many use acombination of these command-line parameters to deploy the software.

Discovering the Installer Version You can discern a lot about the patch from its name. The name might even help you determinewhich patch installer a particular update uses. You can identify patches created using the update.exe installer by their consistent naming convention. For example, when you download the Microsoft security update MS04-030 for Windows XP, you download a file named WindowsXP-KB824151-x86-enu.exe. The name is delimited by dashes (-) into four fields:

• The first field is the product name. • The second field is the name of the Microsoft Knowledgebase article that describes the

vulnerability that this patch fixes. • The third field contains the name of the platform on which the patch is compiled. • The fourth field is the language version of the patch.

In addition to the name, you might also be able to discover the patch installer type from its fileproperties. Select the patch, open its properties dialog box, click the Version tab, and select theInstaller Engine, as Figure 4-1 shows.

Figure 4-1 Viewing patch properties to discover its installer type

Here you can see that the Installer Engine is update.exe. Another less direct way to tell theinstaller type is to start a command window and run the patch with the /help parameter, as Figure 4-2shows.



Figure 4-2 Viewing the /help parameter and other available switches

Although this method does not tell you the name of the installer, it might provide the syntax ofthe supported parameters, from which can infer the installer used with that patch.

How the Patch Installs The patch software file that you download is a self-extracting executable that wraps the patch installertogether with the patched files. When you run this program, the wrapper decompresses the patchedfiles and starts the patch installer. The wrapper accepts optional command-line parameters that itpasses through to the installer program. For example, to install the MS04-030 XP patch quietly andsuppress the reboot you can execute the wrapper

WindowsXP-KB824151-x86-enu.exe /quiet /norestart

When you execute the wrapper, it decompresses the patch files into a temporary folder on your hard drive. The location of these files depends on the patch installer engine used. For example,the patch associated with the security bulletin MS04-030 uses the update.exe installer that creates anew directory on the primary partition of your hard disk and names the folder a random string (e.g., c:\aecb766510779209e2087587e1838a).

After the wrapper decompresses the patch files, it launches the patch installer. Depending on theversion of the installer, it might perform patch applicability checks before installing the patch. Forexample, the update.exe installer checks the date of the patch against the date of previously installedservice packs. If the patch was released after the service pack, the installer will install the patch. Otherwise the patch installation will quit.





The wrapper decompresses the patch files into subdirectories depending on the patch installer.Figure 4-3 shows an example of the directory structure for the XP security update MS04-030, whichuses the update.exe installer.

Figure 4-3 Showing the directory structure for the MS04-030 security update

The update directory contains the patch installation engine update.exe and its support files. Thispatch also includes two patch specific folders, rtmqfe and splqfe, which contain the new patched software files. With Windows Server 2003 and XP Service Pack 2 (SP2) patches, you will more frequently see the folders with the nomenclature GDR, which stands for general distribution release.The GDR and Quick Fix Engineering (QFE) folders (among others) can coexist within one patchunder a multibranch-aware file structure. This method allows multiple installation scenarios in thesame package. GDR files represent security updates as released through Windows Update and QFE represent hotfixes released by Microsoft Product Support.

These file names and versions will be the same files listed as affected files in the Security Bulletin for that patch. (More information about decoding Microsoft Security Bulletins is in Chapter 2.)Continuing to use MS04-030 as an example, there are two files that need updated: msxml3.dll andhttpext.dll. Notice that both the rtmqfe and splqfe folders contain the same files, but that the httpext.dllis a different size. This means that the release to manufacturing (RTM) version of XP requires a different version of the update than a XP SP1 version. Imagine how many versions of httpext.dll mustbe updated, tested, and tracked by Microsoft for all the different OS platforms, processor platforms,and languages—and this is for only one update!

The Windows 2000 (Win2K) patch for the same security update also uses the update.exe enginebut contains only one folder (update) in addition to the patch files, which in Figure 4-4 shows. Itrequires only one folder because the Win2K version does not provide multibranch support. For mostorganizations, simply downloading the patches from the Windows Update Web site will suffice. However, if your organization is running specifically one version (QFE or GDR), then you will wantto work with your Microsoft support team to ensure that you continue to receive the proper versionsof your updates.

Figure 4-4 Viewing the update folder and files for a Win2K patch



Deploying this update requires quite a bit of overhead. Uncompressed, the two crucial files inthis example patch (msxml3.dll and httpext.dll) together are about 1380KB in size. But this entireupdate takes up about 3560KB of space. This package is over two-and-a-half-times the size of thefiles that make up the patch, with the bulk coming from two slightly different versions of the samefiles plus the patch installer. Microsoft compresses this entire patch directory into one self-extractingexecutable to reduce its size to around 942KB, but this package size can be reduced even more. Inthe future, Microsoft might include the patch installer with the base Windows OS and remove it fromeach patch.

In addition to the patch installer and patch files, the wrapper usually contains a configuration filefor the installer. In the previous example for MS04-030, notice that the update directory contains thepatch engine executable update.exe and two configuration files named update_RTMQFE.inf andupdate_SP1QFE.inf. Ordinarily you’ll find one update.inf, but because this wrapper patches two different XP builds, Microsoft included two configuration files—one for each build. Figure 4-5 showsa sample configuration file for the update.exe installer.



Figure 4-5 Showing a configuration file for the update.exe installer

This file contains all the instructions on how update.exe should install the patch, including registry keys to update and file locations to copy the new files.

The configuration file also tells you where in the registry the update installation will be recorded.In the HKEY LOCAL MACHINE hive under the Software, Microsoft, Windows NT, CurrentVersion,Hotfix key, Microsoft adds the KB article number (in this case KB824151) for the patch. Browse to



this registry key on your own computer and review the list of patches that have been applied. Avoidlower-function patch management software that merely queries this registry key to see which patchesare applied. Instead choose a robust patch management software that compares the date and size (orchecksum) of an installed file with the patched file to ensure that the updated file is installed. Thisapproach of checking the file is important as the following example explains.

Let’s say you apply this patch to a computer and its registry is updated to reflect this update.Later you install (or reinstall) a component like IIS that copied files from the Windows source CD-ROM. The files copied from the source CD-ROM might overwrite existing patched files. However,the registry would not be updated to reflect this, because the IIS installation does not know about thehotfix. Subsequent scans by patch management software that only verify this key would erroneouslyreport that the patch is indeed installed.

Microsoft’s Most Common Patch Engines The most common Microsoft patch engines are update.exe and ohotfix.exe. You might alsoencounter older or other product specific patch installers such as hotfix.exe, dahotfix.exe, IExpress,and even one-off derivatives such as vgxupdate. The following sections briefly describe each of theseinstallers.

Update.exe Update.exe is currently Microsoft’s preferred software patch installation engine to install patches forWindows 2003, XP, and Win2K OSs, Microsoft Exchange Server, and IE. Update.exe can add ordelete files, registry keys, and back up files before patching them. Update.exe supports single filedeployment to the deployment of hundreds of files from a service pack. For example, Microsoft usesupdate.exe to install XP SP2.

An update consists of three key parts. The first part is the installer application named update.exe.To perform the patching, this 650KB program updates the registry and copies the updated files. Thesecond part is the configuration file, commonly named update.inf, which tells update.exe how toinstall the patch and where to locate the files. The final part consists of the updated files to install onthe target system.

Update.exe supports different parameters to customize the patch installation. Figure 4-2 showsthe supported update.exe parameters that you can invoke through the patch wrapper executable. AsFigure 4-2 summarizes, running

WindowsXP-KB824151-x86-enu.exe /quiet /norestart

instructs the installer to quietly install the patch and not to restart to computer when finished.A summary of these parameters follows:

/help

Displays a help dialog box listing the parameters supported by the patch installer.

/quiet or /Q

When you simply double-click a downloaded patch executable to begin installation, it might recommend you back up current files or ask you to present an End User License Agreement (EULA),as Figures 4-6 and 4-7 show.



Figure 4-6 Viewing the wizard’s recommendation to back up current files

Figure 4-7 Viewing the patch’s EULA



Executing the path with the /quiet parameter suppresses these prompts. This option is usefulwhen you want to deploy the patch in the background as a part of a logon script or other action andyou don’t want to interfere with the current user of the system.

/passive or /U

Similar to the quiet parameter, specifying the passive parameter instructs the patch engine todeploy the patch without user intervention. However, whereas quiet suppresses all output, passivestill shows a progress bar notifying the user of installation progress. This parameter can come inhandy when you are deploying larger patches and want to keep your users apprised of the progress.After you execute a patch installation with the /passive parameter, the user will see dialog boxesinforming them of the stages of the patch installation, including backing up files, copying new files,finalizing the patch installation, then following with an immediate reboot if needed. The user will notbe prompted for any interaction during a passive installation.

/uninstall

The uninstall parameter uninstalls the patch, if possible. Not all patches can be uninstalled. Youcan also remove an update from the Control Panel Add or Remove Programs applet. (On a pre-XPSP2 you will see the updates listed alongside your other programs. With XP SP2, Microsoft hides thelist of updates and you must enable the checkbox Show updates to display the updates.) From thisapplet, select the update you want to remove and click the Change/Remove button.

/norestart or /Z

A patch might or might not require a restart after installation. Specify the /norestart parameter andthe system will not restart after the patch is installed. Patches released since May 2002 include Qchainfunctionality; you can use this parameter to automatically suppress a restart. The end of this chapterdiscusses using Qchain technology to install multiple patches between reboots. When you use thisparameter, remember that some patches require the computer to be restarted for the patch to takeaffect, so if you suppress the restart during the patch installation, don’t forget to restart the computersoon after.

/forcerestart

The /forcerestart parameter restarts the computer after the patch installation regardless how thepatch configuration file specifies a reboot.

/L

The /L parameter lists all the installed patches on a computer as recorded in the registry, whichFigure 4-8 shows.



Figure 4-8 Displaying all the installed patches on a computer

Be aware that this example only provides a query of the registry for installed patches; you shouldnot regard this list as a guarantee that the patched files are installed. Instead, you need to use a patchmanagement program that checks the file information against a database of known patches to seewhether the patches are indeed installed.

/O

Many times computer hardware vendors write specialized drivers for their hardware that super-sedes builtin Windows drivers. For example, a laptop vendor might include custom network adapteror USB drivers. Windows keeps track of the source of these OEM files, and when you install a patchthat wants to replace one of these OEM drivers, Windows might ask whether to replace the OEM filewith the patched file. The /O parameter instructs the installer to overwrite any OEM files it encoun-ters with the new patched files without prompting the user.



/N

The /N parameter prevents the patch update engine from backing up the original files it replaces.Although this parameter saves disk space and decreases the time of the update installation (especiallyfor large service pack installations), it disables your ability to uninstall the patch.

/F

During a computer restart Windows prompts the active user to save any open documents. Some-times these prompts interrupt the restart process and leave the system at a prompt waiting forsomeone to click Yes to save the open document, No, or Cancel, as Figure 4-9 shows.

Figure 4-9 Prompting the user to save file changes

Specify the /F parameter to force Windows to close any open programs. Note that the user willlose any unsaved work on the computer if the open applications are forced closed.

/integrate:<fullpath>

Most of the time you will be installing patches on individual computers in your environment. Butwhen you use the original Windows installation files (available on the Windows CD-ROM or the i386directory from a network share) to build out a new computer, it will not be patched with anyupdates. The integrated parameter lets you install a patch into a Windows source file directory. Thismeans that any computer built with these files (or later installations of optional components that usethis source) will use the patched files. To use the integrated switch, you need to point to the sourceroot folder for the Windows installation files (e.g., the folder immediately before the i386 folder). Forexample, if your XP source files are at c:\winxppro\dist, then you use the command

WindowsXP-KB824151-x86-enu.exe /integrate:c:\winxppro\dist



The installer copies the necessary files and upon completion displays a success dialog box, whichFigure 4-10 shows.

Figure 4-10 Signaling the successful installation of patch files

Update.exe is the predominate installer for the latest patches. However if you support earlier platforms like NT 4.0, you will still encounter other patch installers like hotfix.exe.

Hotfix.exe The predecessor to update.exe is a program called hotfix.exe, which is still used for NT 4.0 patchdeployment. New patches for NT 4.0 reflect the update.exe naming convention (e.g.,WindowsNT4Server-KB873350-x86-ENU.exe) and can consistently be decoded. But if you run the/help parameter on this patch, you’ll see that it uses the hotfix engine, as Figure 4-11 shows.



Figure 4-11 Using the /help parameter to reveal the hotfix patch installer

The decompressed patch tells the whole story, as Figure 4-12 shows. Here you can see theinstaller engine hotfix.exe, its configuration file hotfix.inf, and the three updated files. The hotfix.inffile looks a lot like the update.inf file that update.exe uses. The hotfix.inf file tells how to install thepatch files and how to update the registry with any patch related information. The temporary direc-tory location and patch installer parameters for the hotfix installer are similar to those of update.exe.

Figure 4-12 Decompressing the patch to reveal its patch installer information

Ohotfix.exe Microsoft uses ohotfix.exe to deploy patches to Microsoft Office products. OHotfix differs fromupdate.exe and hotfix.exe. Whereas update.exe and hotfix.exe install the patches, ohotfix.exe onlybrokers the installation of a patch for the target computer. Ohotfix.exe relies on Windows Installerpatch files (designated by the .msp file extension) to install the updated files. A benefit of this system



is that to scan and install multiple patches at one time, you can use ohotfix.exe to reference a foldercontaining several .msp files. OHotFix will scan the target computer and apply only the necessarypatches. Ohotfix.exe offers no command-line parameters. All the instructions for how to useohotfix.exe are contained in the configuration file ohotfix.ini, which is well documented. In this fileyou can specify how to log the installation, whether to show the OHotFix UI or suppress it (quietmode), how to handle reboots, and other patch-related settings. But first, let’s look at the two dif-ferent ways to run ohotfix.exe-based patches.

Normal Updates and Administrative Updates OHotFix supports two classes of updates that it calls Normal Updates and Administrative Updates.Normal Updates are similar to updates installed with update.exe and consist of installing one patchon a target system. Administrative Updates are a centralized method for applying multiple patches toa target system. First, let’s examine Normal Updates.

Normal Updates You needn’t do anything special to deploy OHotfix updates on a single system beyond executing thedownloaded patch on the target system. Like other patching engines, the Microsoft Office patches arecontained in a self-extracting executable that wraps the OHotFix installer and the patch files. Whenyou execute the wrapper, the patch files are decompressed to the user’s temporary directory. (To findyour temp directory, you can issue a set command from the command prompt or in the Start, Runbox type in %temp%. In this directory, the patch installer creates a directory named IXP000.TMP thatcontains the patch engine ohotfix.exe, its configuration file ohotfix.ini, a helper DLL, and the patch.The patch is not a folder containing the updated files as with update.exe. Instead, the individualupdated files are packaged into a Windows Installer patch file format with a .msp extension. The.msp extension works with the Windows Installer system (previously known as Microsoft Installer—MSI). After decompressing the files, the original wrapper executable runs the ohotfix.exe programwhich scans the newly created patch directory for any .msp files and installs them when applicable.

The OHotFix patches support several command-line switches, which Figure 4-13 shows, and aredescribed as follows:

/Q (set to quite mode)

Execute the patch from a command line or script with the /Q parameter and the patch will beextracted and installed quietly without user interaction.

/T:<fullpath> (specify a temporary working directory)

You can specify the temporary working folder where the patch will be uncompressed. By defaultthis folder is %temp%\IXP000.TMP.

/C (to uncompress the files only)

This will extract the files only to the path specified with the /T switch (which you must also use).The patch will not be installed.

/C:<Cmd>

This parameter lets you override the Install command defined by the patch author.



Figure 4-13 Displaying command-line switches that OHotFix supports

This two-tiered operation opens up administrator managed deployment opportunities not available with other Microsoft patch engines. Let’s take a look at the possibilities. For example, forone Office update Microsoft provides two files named

Office2003-kb838905-client-enu.exe

Office2003-kb838905-fullfile-enu.exe

The naming convention is similar to update.exe except for the third field that contains thedescriptor client and fullfile. The Microsoft Office update Web page describes the client file as theinstaller of choice for basic installations. The process for installing the client patch is straightforward:simply download and double-click the executable and it will install the patch in one swift action.

However, the fullfile program is targeted at administrators. When you run this program, itprompts you to specify a target directory to decompress the files. Inside this directory is one .msp file(in our example, the downloadable wrapper file Office2003-kb838905-fullfile-enu.exe decompressesto a single file named gdiplus-FullFile-GLB.msp.) The wrapper executable exists without attemptingto install this file or starting ohotfix.exe. This feature is for administrators and will be described inmore detail in the next section.

Administrative Updates You can use OHotFix to deploy multiple Office updates from a centralized location for AdministrativeUpdates. Copy multiple .msp files into a commonly accessible directory, then use a logon script orother means of running ohotfix.exe on each target system. OHotFix will run with the configurationspecified in ohotfix.ini and will scan the target system for applicability with each .msp file. If OHotFixdetermines that a patch is needed, it will attempt to run the .msp file which will install the patch onthe target system. OHotfix logs the installation history and you can specify the verbosity of the log-ging in the ohotfix.ini configuration file. By default OHotFix logs status messages to %temp%\ohotfix.



For example, Figure 4-14 shows an example of a folder containing OHotfix and two .msp filesrepresenting two different patches to Microsoft Office.

Figure 4-14 Viewing a folder containing OHotFix and .msp patch files

Anytime you run OHotfix from this folder it will attempt to install both of these patches. How-ever before it runs the patch, it scans the target system to see whether the relevant Office product isinstalled or whether the patch has already been installed. When OHotFix runs, nothing might appearto happen but if you review the OHotFix logs, similar to Figure 4-15, you’ll see that both patch fileswere evaluated and rejected because the software was not installed or because a newer patch wasinstalled. In this manner you can copy new .msp files into this folder and anytime OHotFix is run itwill sweep the directory and execute the .msp files it finds. No manual updating of log files isrequired.



Figure 4-15 Reviewing the OhotFix logs

Integrating Office Patches into the Install Sources Additionally, ohotfix provides the capability (which is similar to the update.exe integrate parameter)to integrate your office updates into your source files. To do this for Office products, update theohotfix.ini file and specify the location of the AdminPath variable including the name of the targetMSI file that needs to be upgraded. For example, if your Administrative update for Office 11 is onyour deployment server at c:\OfficeAdmin\office11, then specify your admin path as

AdminPath=c:\OfficeAdmin\office11\pro11.msi



Obtaining Ohotfix.exe Ohotfix.exe is included in each Office client patch. However, if you want to set up a centralized location for all of your Office patches, you can download ohotfix.exe separately from the MicrosoftWeb site. (An Office XP version is available from the Web at http://download.microsoft.com/download/OfficeXPProf/Install/4.71.1015.0/W982KMeXP/EN-US/offinst.EXE).

Dahotfix.exe Microsoft uses another patch installer engine for updating Microsoft Data Access Components (MDAC)called the MDAC Hotfix Installer. Microsoft uses this installer, which Figure 4-16 shows, to install SQLServer and MDAC updates.

Figure 4-16 Viewing the Microsoft Data Access Components Hotfix Installer

This installer consists of an application named dahotfix.exe and a configuration file nameddahotfix.ini. The configuration file and command-line switches for the self-extracting executable aresimilar to those used for ohotfix.exe and described in the previous section. An example of an updatethat uses this installer is the MDAC update ENU_Q832483_MDAC_x86.exe released January 13, 2004and released under MS04-003.

Off the Beaten Track: Older and Unique Update Engines This chapter has covered the major update engines. But you might come across some of Microsoft’solder update engines, update engines that have been renamed, and update engines that weredesigned to deploy only one update.

Vgxupdate.exe The latest security update for IE 6 SP1 (IE6.0sp1-KB833989-x86-ENU.exe) released on September 20,2004 uses the vgxupdate.exe update engine to update the Vector Graphics engine vgx.dll.



http://download.microsoft.com/download/OfficeXPProf/Install/4.71.1015.0/W982KMeXP/EN-US/offinst.EXE

http://download.microsoft.com/download/OfficeXPProf/Install/4.71.1015.0/W982KMeXP/EN-US/offinst.EXE

Iexpress Microsoft released the IExpress Deployment Kit to help generate user specific profiles and customhotfixes and patches aimed primarily at administrators seeking to create custom deployments of Outlook (using the Microsoft Outlook 98 Deployment Kit—ODK) and IE (using the Internet ExplorerAdministration Kit- IEAK). The most recent IE updates have migrated to use update.exe.

Installing Mutliple Hotfixes with Qchain Technology Installing a security update might require you to restart the target computer. If you install four to fivesecurity updates (which is now common during a patch deployment session), those updates mightinclude patches that individually require a computer restart. Deploying the patches independentlymight necessitate multiple sequential reboots, which can dramatically increase the computer’s downtime.

System restarts are sometimes needed to free up a file that otherwise might be in use. Forexample, if you need to patch a system file that is in use, the OS might already have locked it as “inuse” and prevent the patch from being installed. When you deploy a patch that must replace thislocked file, the system recognizes this and prompts you to restart the computer. When the computeris restarted the file is unlocked, and before it can be locked again, it is replaced with the new file.

So what happens when you have multiple patches that might update the same files? Several yearsago, Microsoft released a program named qchain.exe which addresses this problem. Qchain keepstrack of the files that a patch updates allowing you to install multiple updates without having toworry about file version conflicts. Essentially this functionality lets you install multiple updates withoutrestarting the computer between each installation. A system restart is required after the last patchinstallation. All updates released since May 18, 2001 that use update.exe include Qchain functionalitybuilt in. When you specify the /Z or /norestart parameter (described earlier in the Update.exe sec-tion), you instruct Windows to suppress the reboot and prepare for subsequent update installations.

For example, to deploy multiple updates you can use this syntax (example taken from theMicrosoft Web site):

%PATHTOFIXES%\WindowsXP-KB######-x86-LLL.exe /quiet /norestart

%PATHTOFIXES%\WindowsXP-KB######-x86-LLL.exe /quiet /norestart

%PATHTOFIXES%\WindowsXP-KB######-x86-LLL.exe /quiet /forcerestart

Installer Wrap-Up Microsoft has used several patch installers for its different products over the years. Today Microsoft isstandardizing on update.exe and Windows Installer. However, you might encounter some of theseolder installers or other obscure installers. Even though most patch management software abstractsyou from needing to deal with the installers on a per-patch basis, if you ever need to customize apatch installation or troubleshoot a failed patch installation, you might find yourself tinkering withthese individual installation programs.

Points to remember:• Update.exe and the Windows Installer are the most common Microsoft installers.• Most patch management software uses the same parameters that you use when you manually

install the patch from the command line.



• You don’t need to use qchain.exe on patches later than May 18, 2001 and you can install multiple patches with the /norestart parameter to suppress the reboot.

• The Office patch installer is quite different from the Windows patch installer. To install multiple Office patches, you can run one executable that in turn will install a series of patcheslocated in a folder.

The next chapter explores the Windows Update and Office Update solutions. These solutionshelp individuals keep their systems up to date.



74


Chapter 5:

Individual Solutions: Windows Update and Office UpdateMicrosoft includes a built-in patch management client in Windows that you can use right away toscan for and install any missing patches anytime you have an Internet connection. Windows Automatic Updates works on Windows 2000 (Win2K) and later but received a significant upgradewith Windows XP Service Pack 2 (SP2). With this latest service pack, Windows XP notifies you whenpatch management is not configured for the host computer and will prompt you to set it up. Afteryou configure Automatic Updates, it will routinely check for new updates and download and installthem as they become available, according to a schedule that you set. In addition to the AutomaticUpdates client, you can visit the Windows Update Web site anytime to check a computer’s patchcompliance. Both of these tools help you quickly check a single computer for its patch status andMicrosoft leverages these tools for some of their larger patch management products.

You can also update Microsoft Office over the Internet from the Office Update Web site. Whenvisiting this Web site, you can scan your computer for any missing Office security updates, theninstall them directly from the site. After visiting the site and electing to scan your computer for anymissing patches, you must install the Office Update Installation Engine, a small ActiveX program thatscans for and installs the latest Office updates.

These free patch management tools can help you check individual computers such as those athome or ones otherwise disconnected from your enterprise patch management system. Because theseprograms are so easy to use and require only an Internet connection, you will want to include theirlinks in your Security Update notification email messages. Even though you can use an enterprisepatch management tool to centrally manage patch scanning and deployment, include links to the freetools as reminders to scan and patch any computer the employee uses, such as a home computer.Even with an enterprise patch management solution in place, you might find yourself at the keyboardof an unknown computer wanting to check its patch status. These free tools can help and thischapter explores Microsoft’s individual patch management solutions: Automatic Updates and theMicrosoft update Web sites, Windows Update and Office Update.

Solutions for Individual Computers: Using Automatic Updates to Scan and Install PatchesMicrosoft makes configuration of the Automatic Updates client very easy. After you turn it on, Automatic Updates will routinely check the Microsoft Web site for the latest security updates and willnotify you when new updates are available. You can configure the program to notify you or evenautomatically install the updates for you. The Automatic Updates client will scan for and install security updates, critical updates, and even Windows service packs. For example, you might havenoticed Windows XP SP2 is available for download and installation using only Automatic Updates.Deploying patches with Automatic Updates is advantageous in that you don’t need to search for

Chapter 5 Individual Solutions: Windows Update and Office Update 75


patch executables on a Web site, nor do you have to download or install the files individually. Automatic Updates tracks all this for you and depending on how you configure it, you can select thepatches to install or let the client manage the entire process.

Automatic Updates is great for laptop computers that might be disconnected from your corporatenetwork and patch management solution for long lengths of time. It is also an ideal method forkeeping home systems up to date. The inclusion of Automatic Updates with all current versions ofWindows Server 2003 and Windows XP and the ability to install and configure it on previous versionsof Windows, makes it highly convenient to use. After you enable and configure the AutomaticUpdates client, the computer’s users don’t have to remember to visit the Windows Update site topatch the system. Depending on whether or not critical services run on the host computer, you canconfigure how Automatic Updates will behave: simply notifying the user when new updates are available, automatically deploying updates, and even sometimes restarting the computer. However aseasy as this program is to use, it is not suited or designed as an enterprise patch management tool.This book will cover the qualities and benefits of enterprise tools such as Microsoft Software UpdateServices (SUS) and Windows Update Services (WUS) in upcoming chapters. Yet, Automatic Updates isterrific for individual systems in small environments such as home offices.

The Automatic Updates client routinely downloads the list of updates from the Microsoft Web site (or from an SUS server), then scans your computer for missing patches. Depending on its configuration, Automatic Updates will automatically install the updates for you or else prompt you totake action when new updates are available. To notify you of new updates, the client presents anAutomatic Updates icon in the System Tray. As Figure 5-1 shows, in Windows XP SP2 the icon is ayellow shield and in Windows 2003 the icon is a globe with a Windows icon on it.

Figure 5-1 Displaying the Automatic Updates icons

An SUS-enhanced version of Automatic Updates comes with Windows XP SP1 and Win2K SP3.Alternatively, you can use a standalone installation program, which is available from Microsoft athttp://www.microsoft.com/windows2000/downloads/recommended/susclient/default.asp, to install thisversion separately on a Win2K SP2 or later machine.

Download and install Windows XP SP2 to ensure you have the latest version of AutomaticUpdates. This service pack imparts many new features of Automatic Updates. For example, if afterinstalling Windows XP SP2 Automatic Updates is not yet configured, you will receive a configurationscreen prompting you to configure the service, as Figure 5-2 shows. You can enable it here or youcan configure it from the Control Panel or System application.

http://www.microsoft.com/windows2000/downloads/recommended/susclient/default.asp

Figure 5-2 Receiving a prompt to configure the Automatic Updates service

You can access the Automatic Updates client two ways. To launch it from the Control Panel, runAutomatic Updates as Figure 5-3 shows.



Figure 5-3 Launching Automatic Updates from the Control Panel

Alternatively to access it from a tab on the System application, right click My Computer, clickProperties, then select the Automatic Updates tab. You must be a member of the computer’s Administrators group to configure the Automatic Updates client. If you are not an Administrator, theAutomatic Update options will be grayed out and not selectable.

Configuring Automatic Updates To configure Automatic Updates, you need to choose from one of four options. These options provide various levels of control as this section outlines.

Option 1: Automatically Download and Install Security Updates Windows XP SP2 defaults to the first option called Automatic (recommended) which instructs theAutomatic Updates client to download the updates from Microsoft as soon as they are available, theninstall the updates at the time you designated, for example every day at 3:00 A.M. You can specify in hourly intervals any day of the week or every day of the week. Automatic (recommended) runswith Local System privileges so a user does not need to be logged on or a member of the localAdministrators group for Automatic Updates to run and install updates. In fact, Automatic (recommended) is the only option that you can choose to successfully install updates if the computer’s user is not a member of the computer’s Administrators group.

Unfortunately some Microsoft Windows Updates require that you accept an End User LicenseAgreement (EULA), so these updates cannot be automatically installed. When these updates are





downloaded and a member of the Administrators group is logged onto the computer, WindowsUpdate will display the Windows Update Icon and allow an administrator to install the patch.

Option 2: Automatically Download but Prompt to Install the Security Updates The second option, named Download updates for me, but let me choose when to install them, doesjust that. With this option, the updates are automatically downloaded to C:\Windows\SoftwareDistribution\Download and when a new update is ready for installation, Windows Automatic Updates alerts you with a notification icon in the system tray. The active user must be a member of the computer’s Administrators group to receive these notifications. To install theupdates, the user can click the Automatic Update icon, then follow the prompts to install the downloaded updates.

Option 3: Notify Only When New Updates are Available The third option that you can choose is Notify me but don’t automatically download or install them.With this option, the Automatic Updates client still routinely communicates with the Microsoft UpdateWeb site, but when a new update is available, it will only notify the user of the newly availableupdate. The client will not download or install the update. Like Option 2, an administrator can clickthe Automatic Updates icon, then download and install the update.

Option 4: Disable Automatic Updates The final option lets you disable the Automatic Updates client by selecting Turn off AutomaticUpdates. After disabling Automatic Updates, the new Security Center service, which monitors newWindows XP SP2 security features (e.g., the Windows Firewall) in addition to this update service, will complain as Figure 5-4 shows.

Figure 5-4 Receiving a recommendation to turn on Automatic Updates

If you have an independent patch management solution and choose not to use Microsoft’s Automatic Updates client, don’t just disable the Security Center service because you will be turningoff other useful monitoring as well. Instead, configure its alerts. From Control Panel, select the Security Center application, then click Change the way Security Center alerts me in the left Resourcespane. Clear the Automatic Updates option.

However, leaving this option turned on can be helpful, especially when troubleshooting a computer that you don’t use every day. Seeing the alert that Automatic Updates is not installed canremind you to check whether the computer is indeed patched, especially when coupled with otherinformation such as the computer being connected directly to the Internet. If the computer isunpatched and directly connected to the Internet without a firewall, it might have been exploited.The Security Center can alert you to possible vulnerabilities that can lead to these scenarios.

Behind the Scenes: Automatic Updates Registry Settings When you configure Automatic Updates it sets registry keys for the client computer instructing Automatic Updates how to behave. (The next chapter, which outlines SUS indepth, examines howyou can use Group Policy to set these same registry keys centrally.)

The Automatic Updates registry keys are under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update. These keys provide an easy target to script againstwhen trying to assess the state of the Automatic Updates client for many computers across your network. An explanation of the keys and their meanings follows.

“AUOptions”=dword:00000004

The AUOptions key specifies how Automatic Updates should run and has a value from 1 to 4:

0x00000001 Automatic Updates is disabled

0x00000002 Automatic Updates will notify you when new updates are available but not

download or install any updates

0x00000003 Automatic Updates will notify you when new updates are available and

will download the updates but will not install them.

0x00000004 Automatic Updates will notify you when new updates are available, auto-

matically download them, and will install them as scheduled.

“ScheduledInstallDay”=dword:00000000

The ScheduledInstallDay is a dword value of 00000000 through 00000007 as follows:

0x00000000 Every day

0x00000001 Sunday

0x00000002 Monday

0x00000003 Tuesday

0x00000004 Wednesday

0x00000005 Thursday

0x00000006 Friday

0x00000007 Saturday

“ScheduledInstallTime”=dword:00000003

The ScheduledInstallTime is a value from 0 to 24 and corresponds to the hour that you wantAutomatic Updates to install any new patches. This option works only if AUOptions is set to 4 indi-cating that Automatic Updates will automatically download and install new updates. The registry hex-adecimal values correspond to time as follows:



0x00000000 12:00 A.M.

0x00000001 1:00 A.M.

0x00000002 2:00 A.M.

0x00000003 3:00 A.M.

0x00000004 4:00 A.M.

0x00000005 5:00 A.M.

0x00000006 6:00 A.M.

0x00000007 7:00 A.M.

0x00000008 8:00 A.M.

0x00000009 9:00 A.M.

0x0000000a 10:00 A.M.

0x0000000b 11:00 A.M.

0x0000000c 12:00 P.M.

0x0000000d 1:00 P.M.

0x0000000e 2:00 P.M.

0x0000000f 3:00 P.M.

0x00000010 4:00 P.M.

0x00000011 5:00 P.M.

0x00000012 6:00 P.M.

0x00000013 7:00 P.M.

0x00000014 8:00 P.M.

0x00000015 9:00 P.M.

0x00000016 10:00 P.M.

0x00000017 11:00 P.M.

Phoning Home: Automatic Updates Routinely Checks with Microsoft When you enable Automatic Updates (and each time the computer starts up), your computer opens aconnection with the Microsoft Windows Update Web site. This connection checks the status of theAutomatic Updates client and will periodically look for new updates. Microsoft collects the followinginformation about your computer when you connect to Windows Update (per the Microsoft WindowsPrivacy Statement dated April 15, 2004):

• Computer make and model • Version information for the OS, browser, and any other Microsoft software for which updates

might be available • Plug and Play (PnP) ID numbers of hardware devices • Region and language setting • Globally unique identifier (GUID) • Product ID and Product Key • BIOS name, revision number, and revision date • IP address is logged but used only to generate aggregate statistics



Microsoft uses the Product ID and Product Key to confirm that the computer is running a validlicensed version of Windows. Microsoft uses the anonymous GUID to generate statistics for WindowsUpdates downloads and installations.

Using Automatic Updates to Download Updates from Microsoft Using the Background Intelligent Transfer Service (BITS), Automatic Updates requests newly availableupdates. BITS is a Microsoft developed file transfer technology used to trickle down updates to yourcomputer over idle network bandwidth.

BITS starts when a program such as Automatic Updates schedules a new download job. Becausethe job is run under BITS, it works in the background of the user activity. If a user logs off or if thecomputer restarts, the BITS job will resume when the network connection is restored. BITS monitorsthe client computer’s network traffic and will reduce the bandwidth of its jobs if the user begins touse another application requiring the network, such as a Web browser. Therefore, even when downloading a large update such as a service pack, you can still use network applications such as aWeb browser without experiencing noticeable slowness.

However, BITS is not aware of the network utilization beyond the client. So if you have manyclients using BITS to download updates across a slow WAN connection, they will compete for bandwidth and the WAN connection can quickly reach capacity. To address this potential problem,you can configure a Group Policy setting title MaxInternetBandwidth, which sets the maximumamount of bandwidth per client that BITS applications can use. All BITS connections use the Webprotocols HTTP (TCP port 80) or HTTPS (TCP port 443).

If your computer is powered off during a scheduled update, then the update will occur the next time you power on your computer. Remember too that if you enable Automatic Updates toautomatically download and install new updates, some updates require a computer restart. Afterwarning the user, Automatic Updates will automatically restart the computer. So remind the users of computers that apply Automatic Updates to save their work just before Automatic Updates isscheduled to install patches. (This is always a good idea anyway.)

Installing the Updates Recall that with any option other than Automatic (recommended) and when new updates are available to be installed on your computer, you will receive an Automatic Updates icon prompt,which Figure 5-1 shows. This icon signals that new updates are either available for download orready for installation, depending on how you have configured Automatic Updates. If you click theicon, you will receive more information about update options, as Figure 5-5 shows.



Figure 5-5 Receiving update installation information

To automatically install all the missing updates select the Express Install option or to choose individual updates to install select the Custom Install (Advanced) option, which Figure 5-6 shows.

Figure 5-6 Selecting Custom Install options

The Windows XP SP2 Automatic Updates client is more user-friendly than previous versions ofthe update client. It informs you when it is installing the updates, then minimizes back to the systemtray so that you or your users can continue working. If the update requires a computer restart, Automatic Updates will prompt the current user to perform one. Also, Windows XP SP2 includes a



new feature to install downloaded (but not yet installed) security updates when the computer is shutdown. This option is presented as a new Shut Down Windows option, which Figure 5-7 shows.

Figure 5-7 Viewing the Install updates and shut down option

The Windows Update Web Site In addition to the Automatic Updates client, Microsoft supports the Windows Update Web site athttp://windowsupdate.microsoft.com that scans and installs updates for the Windows platform.Whereas Automatic Updates routinely checks Microsoft for the latest updates, you can manually visitthe Windows Update Web site to check whether a computer has the latest security updates installed.The site uses an ActiveX control to scan your computer, so you must use Microsoft Internet Explorer(IE) 5.0 or later to visit the site.

When you visit Windows Update, you will be redirected to one of two other sites. If you useWindows XP, you will be redirected to a consumer-oriented update site (http://v5.windowsupdate.microsoft.com/v5consumer). This site presents fewer options and is designed to make scanning thecomputer for updates very easy. The site also detects the state of Automatic Updates on your com-puter and will let you enable it directly from the Web site. Windows Update looks very similar to theAutomatic Updates interface. In fact, as Figure 5-8 shows, the Web site patch installation options arethe same as presented in the Automatic Updates installation dialog box.



http://windowsupdate.microsoft.com

http://v5.windowsupdate.microsoft.com/v5consumer

http://v5.windowsupdate.microsoft.com/v5consumer

Figure 5-8 Assessing patch installation options

Select either Express Install or Custom Install to start the scan for missing patches and follow upwith installation. This version of the Windows Update Web site also lets you hide an update. Ahidden update won’t install and won’t be flagged as missing in future scans. This feature is handy tosquelch a noisy update that you don’t want to install but prefer not to clutter your Windows Updatescreen by its presence after every scan. Not all updates can be hidden. You can unhide an updatefrom the Add Remove programs application.

Windows 2003 and Win2K users will be redirected to an older version of the update site(http://v4.windowsupdate.microsoft.com). When you visit this site, it prompts you for approval toscan the computer, as Figure 5-9 shows.



http://v4.windowsupdate.microsoft.com

Figure 5-9 Receiving a request to scan for updates

The scan ordinarily takes just a few minutes, then you will be presented with an option toreview and install the updates. The Web site shows you the details of the missing security updatesand also shows any noncritical updates such as OS updates or driver updates, as Figure 5-10 shows.



Figure 5-10 Displaying all updates available to install

In addition to scanning and installing patches, from the Windows Update Web site you can alsoreview the list of updates that already have been installed on the computer. From the Web site’s leftnavigation pane, select View installation history. This history shows all installed updates on the com-puter, as Figure 5-11 shows.



Figure 5-11 Showing all installed updates on a computer

You can also view a history of installed patches from the Control Panel Add or Remove Programsapplet. In the Windows XP SP2 version of this application, you can select the Show updatescheckbox, which Figure 5-12 shows, to view all the installed updates. To view the installed updatesyou need only user privileges on the computer.



Figure 5-12 Selecting Show updates to view all installed updates

The Office Update Web Site Microsoft provides the Office Update Web site at http://officeupdate.microsoft.com to scan for andinstall Office updates. Unfortunately you must visit this Web site individually and cannot use Automatic Updates to deploy Office updates. Like Windows Update, the Office Update Web site alsorequires IE 5.0 or later.

When you visit the Office Update site, go to the Office Update Check for Updates link, whichFigure 5-13 shows, and click it to begin scanning the computer for any missing Office updates.



http://officeupdate.microsoft.com

Figure 5-13 Selecting Check for Updates to scan for missing Office updates

The next Web page, which Figure 5-14 shows, displays each of the critical Office updatesmissing from your computer. You can then click Agree and Start Installation to begin the wizard thatinstalls the patches. The wizard prompts you through the process of installing the Office patches andwarns you to get your Office product CD-ROM (or know the network location of your Office installation files).



Figure 5-14 Displaying critical Office updates missing from a computer

Historically, Office has been slightly trickier to patch than the Windows OS because it sometimesrequires the installation files from the Office Setup CD-ROM. The source installation files are necessary because the Windows Installer package (.msi file) used to install and patch Office uses thesource installation files for versioning control. Office 2003 supports a new feature called the localinstallation source (LIS), which caches the installation files on the local hard drive so they can beused by Office update in lieu of the setup CD-ROMs. (If you want to use the LIS, be sure to clear theDelete installation files checkbox during the original Office installation steps.) The Office Update Website uses the binary versions of the patches. These versions are much smaller than the fullfile versionsbut may require the source CD-ROMS.

Another way to avoid the Office source files requirement is to use the fullfile version of theupdates to install the missing updates. Unfortunately you must separately (and manually) downloadand execute these files outside of the Office Update managed installation methods. Still, your



third-party patching tool might use the fullfile method to circumvent the necessity to access the original Office Setup files. Many third-party patch managements programs that handle Office updateslet you specify a network share that it can reference when deploying Office updates.

Using the Office Update Inventory Tool to Scan for Missing Office Updates Microsoft also provides the Office Update Inventory tool to check the update status of Office productson individual computers. You can find documentation explaining how to use this tool and links tothe tool at the Microsoft Web site http://office.microsoft.com/en-us/assistance/HA011402491033.aspx.

Download and run the two files that make up this inventory tool: invcm.exe and invcif.exe. By default these tools will be extracted to the c:\inventory folder. The first file, invcm.exe, is theinventory tool and is comprised of two executables, inventory.exe and convert.exe, as well as alibrary binary. The file invcif.exe contains the Office Update inventory catalog and patch data information stored in the /cifs folder. It also contains the patchdata.xml file that the convert program(convert.exe) uses to generate meaningful reports.

After you become familiar with running the tool and how it references the update information,you can move the files to other locations depending how you want to deploy the tool. The tool isvery rudimentary and must be run on the computer that you want to check. This means that tocheck multiple computers you will need to run it from a logon script or other method. (As an aside,the Microsoft Systems Management Server—SMS—2.0 Feature Pack uses this same inventory tool toscan for missing Office updates as a part of its enterprise patch management support.)

The easiest way to become familiar with this tool is to extract all the files to their default locations (e.g., c:\inventory), then from a command prompt, run the program inventory.exe. With noparameters set, it will use update catalog information from current directory to scan the computer forOffice updates and will output its results to a proprietary log file named computername.log.

Next, these results need converted into something more meaningful. Run convert.exe to convertthe log file to either XML, comma delimited, or a Managed Object Format (MOF): The /d parameterspecifies the folder that contains the log files and the /o parameter specifies the name of the outputfile that contains all the results. Notice that the /d parameter specifies a folder name and not just thename of the log file. This is because the convert.exe program can process multiple log files andaggregate them to one output file making it much easier to consolidate scan results across many computers. Additionally, you need to ensure that the patchdata.xml file is also present in the samedirectory as your log files.

For example,

convert /d c:\inventory /o patchstatus.xml

will create an XML formatted file showing the installed and applicable Office updates for any log filescontained in the c:\inventory folder.

Extending this tool to run across multiple computers in a network environment is pretty straight-forward. To do this you need to use additional parameters for the inventory.exe tool and configure aserver to host the update data and store the output data. The /s parameter specifies where the updatecatalog files are located. The /o parameter denotes where to write the output log. So for example,you can configure a logon script to run this program on every computer as follows:



http://office.microsoft.com/en-us/assistance/HA011402491033.aspx

inventory.exe /s \\server\OfficeUpdateStatus\cifs /o \\server\OfficeUpdateStatus\logs

It will check the status of each of the Office updates listed in the \\server\OfficeUpdateStatus\cifsnetwork share and will write the results to a log file in the server’s logs folder.

Lastly, you will need to run the convert.exe program on the server to create the output reportfrom the collected log data. Continuing with the previous example, copy the patchdata.xml file to the\logs folder and run the convert application like so:

convert /d c:\OfficeUpdateStatus\logs /o myReport.xml

This generates the XML file named myReport.xml containing a summary of all the Office updatesfor any scanned computers.

Using an Administrative Point to Deploy Office Updates An Administrative Installation Point for Office is a network location accessible to all client

computers that contains a special installation of the Office setup files. Previously Chapter 4 detailedhow to install fullfile updates to an administrative point. To use the Administrative point to updateclients, you must recache and reinstall Office on each of these computers. The main drawback of thismethod is the high overhead associated with reinstalling Office, but this installation method can beideal for users of a shared Office installation. However, you will probably find that using a qualitypatch management program is advantageous in many ways over reinstalling each user’s entire Officepackage, which this method requires.

If you want to use the Office Update Web site to manage your patches locally, an alternative tothe Administrative Point installation is to simply copy the setup CD-ROMs to a network file share andinstall Office from the setup.exe file from this network location. When you run the Office setup program from a network share in this manner, it will first copy and compress all the installation filesto the local computer’s LIS. The setup program then installs Office from the LIS, and Office Updatecan reference the LIS. When you install a binary version of the patch (this is the smaller version, notthe fullfile version of the patch), it will silently look to this local cache of the Office setup files andnot prompt you for the source CD-ROMs.

Office 2003 supports the LIS. You can download a new tool called the Local Installation Source Tool (LISTool.exe) from Microsoft.com at http://download.microsoft.com/download/b/7/b/b7b7d0e1-f125-46ed-9d65-95350e8d3f96/LISTool.exe. This tool lets you manage the LIS on aparticular computer including creating, moving, or deleting a LIS, as Figure 5-15 shows. This tool supports all Office 2003 products including Visio 2003 and OneNote 2003 and you can use it to helptroubleshoot a failed Office update installation.



http://download.microsoft.com/download/b/7/b/b7b7d0e1-f125-46ed-9d65-95350e8d3f96/LISTool.exe

http://download.microsoft.com/download/b/7/b/b7b7d0e1-f125-46ed-9d65-95350e8d3f96/LISTool.exe

Figure 5-15 Managing the LIS tool on a computer

Keeping Up to DateMicrosoft provides the Automatic Updates client in the Windows OS to help users keep their computers patched without needing to take action. This program routinely checks the Microsoft Windows Update Web site for new updates, then notifies, downloads, or installs new updatesdepending on the user’s preference. This solution is ideally suited for home users or remote workerswho do not have access to a large enterprise patch management tool that provides additional assurance and patch deployment reporting.

When used alone, Automatic Updates requires the end user to individually configure it. And eachclient will attempt to communicate with the Microsoft Web site, which increases WAN traffic.

In addition to Automatic Updates, Microsoft provides two update Web sites for the Windows andOffice products. Users of any Win2K and later computer can visit the Microsoft Web sites, WindowsUpdate and Office Update, to scan a computer for any missing updates. These sites provide a quickand effective method for assessing and patching any Win2K or later computer and requires only anInternet connection.

This chapter examined some specific update information worthy of a final review:• Automatic Updates provides home users, remote workers, and companies without any other

patch management an automatic method for installing missing security updates.• Automatic Updates must be enabled on every computer and each computer must have access

to the Internet (unless you use SUS or WUS, which the next chapter will cover).



• Administrator privileges are required to use Automatic Updates to install updates in any modeother than the Automatic (recommended) setting.

• Even when the Automatic Updates client is set to Automatic (recommended) an Administratormust manually accept the EULA that some updates require.

• The Microsoft Web sites at http://windowsupdate.microsoft.com andhttp://officeupdate.microsoft.com offer Web-based patch scanning and installation servicesfrom the Internet.

The next chapter will look at one of the Microsoft solutions for extending the Automatic Updatesclient for use in larger environments. Through SUS (and the upcoming WUS), Microsoft extends thefunctionality of Automatic Updates to the enterprise by providing a centralized application to approveand download new updates.



http://officeupdate.microsoft.com

http://windowsupdate.microsoft.com

95


Chapter 6:

Corporate Solutions: Microsoft SUS and WSUS So far this patch management book has looked at patching strategies and the technologies behindpatching individual workstations. This chapter takes a look at Microsoft’s free patch management software, which you can use to manage the approval and deployment process of Microsoft SecurityUpdates. The benefit of a central service is that you can centrally approve all new updates beforedeploying them to potentially untested clients. Additionally, you can host the updates from withinyour LAN instead of requiring each client to download them directly from the Microsoft Web site. Theprocess of downloading new updates only one time to an inhouse patch management server, thendeploying the patches to client computers using your LAN can mean a huge savings of your WANconnections.

In particular, small to midsize companies will appreciate the quick and reasonably transparentcapabilities of Microsoft Software Update Services. SUS regularly and automatically distributes criticalsecurity updates (and now service packs, beginning with Windows XP Service Pack 2—SP2) fromMicrosoft and provides one point from which Windows clients can fetch applicable updates. Best ofall, Microsoft provides SUS as a free download.

Microsoft released SUS in 2002 and recently finalized the follow-on product renamed WindowsServer Update Services (WSUS)—during its beta, this product was called Windows Update Services(WUS) and the names in the figures in this chapter reflect the beta installation. Although these products do not offer as sophisticated pushing, tracking, and reporting features as some third-partypatch management products their zero cost and ease-of-installation make them attractive to manyorganizations—especially those without any other patch management software or when financialresources or staffing is tight. Plus WSUS overcomes many of the SUS limitations, so even if youlooked at SUS before you should check out WSUS and its new features. This chapter will firstexamine the patch management architecture of these services, then dive into some of the features ofeach product.

Centrally Managed Passive Protection SUS and WSUS provide a centralized method for deploying critical Microsoft updates to XP and Windows 2000 (Win2K) SP2 client computers. (Note that Microsoft no longer supports Win2K SP2, soif you are not running the latest service pack at least make sure that Microsoft still supports the version you are running. Also, although you might not choose to deploy a service pack immediatelyupon its release, it’s important to consider a timely migration plan. This practice ensures that your systems remain up-to-date and continue to qualify for Microsoft security updates.) These productsleverage the client-update technology from XP’s builtin Windows Update feature and add improve-ments—such as centralized configuration, an update-approval process, and inhouse deployment capability—that are beneficial to corporate deployments. When you use inhouse deployment, yourcompany downloads an update once from Microsoft, then your clients download the update from an



inhouse location. This feature requires sufficient storage space for all approved security updates butreduces network load. Patch management using SUS or WSUS is more passive than using other PatchManagement tools because after setting it up, you merely approve new updates that are thendeployed automatically depending on your preconfigured preferences. Using Active Directory (AD)Group Policy Objects (GPOs) you can configure computers in your organization to use these products. For example, if you link an SUS configured GPO to an organizational unit (OU) containingyour computers, then any new computer moved into this OU will automatically be patched accordingto the approved SUS updates.

SUS and WSUS are client/server applications. The server component runs on Win2K SP2 or laterand requires Microsoft Internet Information Server (IIS). You must install Automatic Updates 2.2 orlater client software on SUS clients. An SUS-enhanced version of Automatic Updates comes with XPSP1 and Win2K SP3. Alternatively, you can use a standalone installation program—available from theWin2K Web site at http://www.microsoft.com/windows2000/downloads/recommended/susclient/default.asp—to install this version separately on a Win2K SP2 or later machine.

The deceptively simple architecture will probably be popular in the intended market of small tomidsize organizations that don’t have sophisticated reporting or client-targeting needs. (Larger organi-zations that require more comprehensive update management features might consider Microsoft Sys-tems Management Server (SMS) or a third-party patch management product. If you want to compareSUS and WSUS with SMS, you can read Chapter 7 of this book which covers the security updatedeployment features of SMS 2003.) The SUS and WSUS server maintain a synchronized catalog ofMicrosoft-obtained updates and push these updates to subscribing clients in your organization. Thefirst synchronization takes some time because the SUS server must download all critical updates fromthe Microsoft Windows Update server, as Figure 6-1 shows.

http://www.microsoft.com/windows2000/downloads/recommended/susclient/default.asp

Figure 6-1 Downloading updates to the SUS server

Subsequent scheduled synchronizations complete much faster because the software downloadsonly new updates since the previous synchronization. You manage the SUS update server through anIIS Web-based interface (by default, http://susserver/susadmin). From this interface, you can reviewand approve each update intended for the SUS client base.

Configuring Automatic Updates Clients with Group Policy The Automatic Updates client on each computer regularly checks with the SUS or WSUS server forapproved and applicable updates, then obtains the updates and installs them according to that client’ssettings. In each client computer’s registry, you can configure (as Chapter 5 covers) client settingssuch as whether to automatically download and install updates or prompt the end user to approveeach update; however, most organizations will appreciate the capability to use AD’s Group Policy tocentrally configure the Automatic Updates client. You can use AD GPOs to configure all the settingsdiscussed in Chapter 5 for the Automatic Updates client. Because the client portion of SUS and WSUSis the same as the Automatic Updates client, you can use these same AD GPO settings to manageSUS and WSUS clients too.

You can configure the AD GPO settings from any computer with the latest Windows Update ADtemplate (.adm file) installed. By default, any installed SUS or WSUS server and Windows Server 2003and XP SP2 clients come with an updated Windows Update administrative template that you can useto create centrally managed Windows Update GPOs. On earlier versions of Windows (such asWin2K) you must install a new GPO administrative template to have this functionality. Alternatively,

Chapter 6 Corporate Solutions: Microsoft SUS and WSUS 97


you can simply manage your SUS and WSUS GPO settings from the SUS or WSUS server, which addthis template during installation.

Checking whether you have the Windows Update GPO properties is easy. First, open the Group Policy Management Console (available from the Windows Server System Web site athttp://www.microsoft.com/windowsserver2003/gpmc/default.mspx) and expand the Computer Configuration node, Administrative Templates, and click Windows Components. Look for the nodecalled Windows Update and left click it. On an XP SP2 computer you should see around 11 Windows Update GPO settings.

If you do not have the Windows Update Administrative Template, you can add it fairly easily.Copy the new Windows Update Automatic Updates template from your SUS or WSUS server to theclient that you use to manage your AD GPO settings. The file named wuau.adm is located in theWindows INF directory (%windir%\inf\wuau.adm). Next, on the computer that you want to installthe template, go to the Group Policy Management Console and expand the Computer Configurationnode. Right-click Administrative Templates and click Add/Remove Templates to load the new Windows Update administrative template (%windir%\inf\wuau.adm). Next, expand the ComputerConfiguration Windows Components node and select Windows Update to display the new SUS configuration settings.

If you create a GPO that modifies Windows Update configuration settings, then view the detailsof these GPO settings on a computer without the administrative template installed, you will see thesettings under Extra Registry Settings, as Figure 6-2 shows.

Figure 6-2 Viewing the SUS GPO settings



http://www.microsoft.com/windowsserver2003/gpmc/default.mspx

This view does not impede the settings and occurs only because the computer that you are usingto view these settings does not have the Windows Update Automatic Updates .adm template installed.Either install the template on this computer or manage the settings from a computer with the .admtemplate installed.

Exploring the Windows Update GPO Settings Since the initial release of SUS to the latest pending version of WSUS, Microsoft has released new set-tings to control the Windows Update clients. As of the XP SP2 release, there are 11 configurable set-tings, which Figure 6-3 shows.

Figure 6-3 Viewing configurable Windows Update settings

.

Most of these settings are similar to the registry settings explained in Chapter 5. A few settings arenew features that WSUS offers:

• Do not display “Install Updates and Shut Down” option in Shut Down Windows dialog box• Do not adjust default option to “Install Updates and Shut Down” in Shut Down Windows

dialog box• Configure Automatic Updates• Specify intranet Microsoft update service location• Enable client-side targeting• Reschedule Automatic Updates scheduled installations• No auto-restart for scheduled Automatic Updates installations• Automatic Updates detection frequency• Allow Automatic Updates immediate installation• Delay Restart for scheduled installations• Re-prompt for restart with scheduled installations



In the GPO editor you can select any of these settings and read verbose descriptions of whateach does. At the very least to configure clients to use an SUS or WSUS server, edit the properties ofthe item, Configure Automatic Updates, to specify the folder location, notification parameters, andschedules of automatic updates. For example, you can notify your users when updates are ready forinstallation or you can schedule automatic installations. Next, edit the item Specify intranet Microsoftupdate service location to define the location of the SUS or WSUS update server (e.g., http://susserveror http://wsusserver). Also, specify the statistics server that you want clients to use. The statisticsserver collects update report data. (SUS did a poor job with report data but WSUS includes betterpatch management result feedback.) You can set both to the same server; however, you might wantto configure a separate statistics server to handle reporting from multiple SUS update servers (e.g., fordifferent geographic offices).

Another useful setting is Automatic Updates detection frequency, which lets you specify howoften the Automatic Updates client will poll the SUS or WSUS server for any new updates. By defaultthis setting is 22 hours. The setting Allow Automatic Updates immediate installation lets you configureAutomatic Updates to install updates that will not interrupt the client (such as those that don’t promptthe user or require a restart). Therefore, updates that are quiet can install without bothering yourusers. Some updates require a restart before they are effective, so be wary if you suppress a restartwhen installing these: They will not be fully installed until the computer is restarted.

You’ll notice that some of the features described in Chapter 5, such as prompting to installupdates when the computer is shutdown or restarted, can be centrally configured using a GPO. Inthis example, you can specify patch deployment behavior during a computer restart under the Re-prompt for restart with scheduled installations setting.

Deploying Service Packs with SUS The latest version of SUS supports the deployment of SP2 for XP and both SUS and WSUS will support future service packs. SUS doesn’t support deployment of service packs earlier than XP SP2.With SUS and WSUS, installing a service pack is the same as installing a security update. In theSUS/WSUS console, you will see the service pack along side other security updates in the list ofupdates to be approved. Approve the service pack, then clients will download and install the servicepack according to your SUS and WSUS update policy.

However, to deploy service packs that SUS or WSUS do not support, you can use the AD GroupPolicy Software installation feature to install service packs, as Figure 6-4 shows. You can defineGroup Policy software installation for computers or users and commonly at an OU level. To deploy amandatory software update, such as a service pack, to every machine regardless of who is logged on,you assign the software to the computer. Group Policy software installation supports WindowsInstaller (.msi) files, which come with most new service packs and other Microsoft corporate prod-ucts. To verify or troubleshoot installation at the client level, you can review the Application event logfor a failed or successful Application Installation message.



Figure 6-4 Showing the AD Group Policy Software installation feature

SUS Reporting SUS reporting consists of recording client-update downloads to a standard IIS Web log on your speci-fied SUS servers (by default, these files reside on the SUS Server in \%systemroot%\logfiles\w3svcx).Unfortunately, SUS offers no predefined reports, data aggregation, or other summary-level reporting toconvey your organization’s patch compliance. However, you can troll the logs to determine whethera specific machine has requested a specific patch. Reporting is a feature that has been greatlyimproved in WSUS.

After you configure Group Policy, on an affected client refresh the policy (by running the pro-gram gpudate /force from a command prompt) and verify the SUS settings. Open the Control PanelSystem applet and select the Automatic Updates tab to review a client’s settings. Figure 6-5 shows aclient configuration in which the Automatic Updates client automatically downloads and installsapproved patches every day at 3:00 A.M. Notice that the user cannot change these settings; they areconfigured centrally using the GPO.



Figure 6-5 Verifying the SUS Automatic Update settings

To begin deploying updates, you don’t need to perform much additional configuration. Thissimple approach to patch deployment will be welcome news if you’ve ever manually installed multiple patches. (New Microsoft Internet Explorer—IE—updates typically include three separatepatches for IE 6.0, IE 5.5, and IE 5.0. Therefore, your installation logic must check the version andpush the appropriate update.) SUS transparently handles patch management for you, ensuring thateach client gets the correct version of an approved patch. One major drawback of SUS is its inabilityto manage different levels of patching for different groups of computers. If you want to use SUS toroll out updates to a set of test servers before rolling out to a wider production set, you must installmultiple SUS update servers. (Alternatively, you can save updates to a local machine and manuallyinstall them for testing; however, this solution doesn’t use the SUS deployment mechanism.) If youuse multiple servers, be cautious when sharing existing IIS servers with SUS because upon installationSUS runs IIS Lockdown, which might cause the failure of other Web applications on a shared server.After you configure your SUS servers, separate your test computers from your production computersby placing them in different AD OUs. Configure an OU Group Policy to point the test OU computersto the staging SUS update server and the production OU computers to the production SUS updateserver.



Configuring SUS Server Options You can configure your SUS clients to synchronize their updates (and, optionally, approved items)from another local SUS server or directly from Windows Update servers. Doing so helps you scaleSUS and offers a good solution for placing SUS servers in multiple offices. For example, you can configure a master SUS server at corporate headquarters to pull its catalog from Microsoft, then configure child SUS servers at satellite offices that pull their catalogs from the corporate SUS parent.Such a configuration eliminates the need for each SUS server to be connected to the Internet. However, at least one SUS server must have Internet access to communicate with the WindowsUpdate server.

WSUS Revealed WSUS is the follow-on product to SUS. WSUS improves on SUS in most every way. At publicationtime for this chapter WSUS was in a public beta test in early 2005 and has recently been released.(You can learn more about WSUS at http://www.microsoft.com/windowsserversystem/updateservices/default.mspx.) Users of SUS will feel at home with WSUS and immediately appreciatethe additional granularity of patch management features that this updated product offers.

WSUS requires IIS 5.0 or later, .NET Framework 1.1 SP1, and Background Intelligent Transfer Service (BITS) 2.0. WSUS uses a database to manage the status and configuration of its patches.WSUS installs Windows SQL Server 2000 Desktop Edition or you can point WSUS to an existing SQLServer database instance. Like SUS, WSUS clients depend on the Automatic Updates client that comeswith Win2K Professional or Server SP3 or later. During the WSUS installation process, the setup program asks you whether or not to store updates locally on the WSUS server. If you choose not tostore the updates locally, then clients will need to download them directly from the Microsoft Website (although you can still manage the approval process for these updates). Like SUS, storing updateson the WSUS server takes additional storage space: approximately 6GB. If you choose to performinstallation with a locally installed database, you will need a total of approximately 8GB to installWSUS and have room for all the downloaded updates.

Also like SUS, the administration interface for WSUS is via a Web page hosted on IIS athttp://wsusserver/WsusAdmin. However, the setup program for WSUS lets you customize the Website location. Create a new GPO to configure the Automatic Updates clients to get their updates fromthe new WSUS server (e.g., http://wsusserver). In fact, the GPO and Automatic Updates configurationwhen using a WSUS server is almost identical to that of an SUS server.

Exploring the New WSUS Interface Users familiar with SUS will immediately notice the updated WSUS interface, as Figure 6-6 shows. The program data displays in the main Window and you access all the WSUS features from the fivenavigation icon buttons in the upper right of the Window. These icons let you view an overall WSUSsummary, approve updates, view reports that show the status of update deployment, configure thenew WSUS computer groups, and configure WSUS options.



http://www.microsoft.com/windowsserversystem/updateservices/default.mspx

Figure 6-6 Examining the updated WSUS interface

The WSUS home page shows an overall summary of the program including update statisticsstatus, synchronization status, download status, and a count of client computers. This page also showsa To Do List summarizing interesting information about the state of the product; for example, itinforms you of any new unapproved updates or recently added products or classifications. To manually start an update synchronization task with the Microsoft updates Web site, you can click theSynchronize now link on this page. WSUS uses HTTP (TCP 80) and HTTP Secure (HTTPS—TCP 443)to synchronize its updates with the Microsoft Windows Update Web site.

After configuring your Automatic Update clients to point to the WSUS server, you need to con-figure your WSUS server. For basic installations start by synchronizing the WSUS server with theMicrosoft Windows Update Web site. For more complex configurations, such as pointing the WSUSserver to a proxy server or to install multiple WSUS servers, click the WSUS configuration button.(This chapter will cover those features in a bit.) The first time you synchronize your WSUS server be prepared to wait: the initial synchronization takes close to an hour. This length of time is not necessarily dependent upon your Internet connection. This synchronization process seems to dribbleto your WSUS server and is regulated by the server instead of the available Internet bandwidth. Thissynchronization does not download the updates. The updates download after they are approved forinstallation. After you synchronize the updates, you will have populated the WSUS server and can



begin to approve and deploy the updates. Subsequent synchronization activities take much less timedepending on the number of updates needed.

Approving Updates with WSUS Because the Automatic Updates client more-or-less transparently takes care of the installation of theupdates, the crux of the program revolves around the approval management of each individualupdate. This process consists of managing the computer groups, approving updates for the computergroups, and viewing reports to track the update process. The process for installing and configuringclients for WSUS is the same as for SUS as described earlier in this chapter. Configure the Specifyintranet Microsoft update service location GPO setting to point to your WSUS server and set theoptions that pertain to your environment. Most of these settings were described in the earlier sectionsbut new settings that WSUS supports will be described in the following sections.

Support for Computer Groups A major improvement of WSUS over SUS is its ability to classify computers into different managementgroups for which you can then approve specific updates. (Recall previously that SUS requires a newinstallation of SUS on a separate computer when you want to deploy different updates to differentcomputers.) This book has stressed the importance of testing patches before deployment to production environments and using the same patch processes and tools for your lab as you use forproduction. WSUS now supports this methodology.

For example, let’s say you want to approve a newly released set of updates for your lab computers but not for your production computers. Using SUS you would need to configure twoGPOs (one linked to an OU containing the lab computers and one linked to an OU containing theproduction computers), then configure each GPO to point to two different SUS servers. This configuration requires the purchase and set up of two different servers and SUS installations and management of multiple GPOs.

Using WSUS with its new support of Computer Groups you can create a single GPO for all yourcomputers which points to a single WSUS server. Then, within the WSUS server you can define andpopulate multiple computer groups and set the approval status of an update for each computergroup. In the previous example, this means that you need only one WSUS server and one GPO, thenfrom the WSUS updates console you can approve updates for installation on the Lab Computers butnot the Production Computers. Later when you are ready, you can simply approve the updates forthe Production Computers. This feature dramatically increases the scalability of WSUS.

Click the Computers icon from the WSUS navigation bar to access the Computers-group configuration page, as Figure 6-7 shows. This figure shows quite a bit, so let’s look at it piece bypiece. First off notice that there are three computers listed for the Computer Group All Computers.WSUS comes with two predefined builtin groups, All Computers and Unassigned Computers. Bydefault the Unassigned Computers group is defined with the same approval and deadline parametersas the All Computers group. The All Computers group is a superset containing all computers config-ured to use this WSUS server. In Figure 6-7 you can see the computer name, OS, the date and timethe computer was last contacted, and the specific computer group to which the computer is assigned.To use WSUS you don’t need to configure any computer groups (in which case you approve updatesfor All Computers). The granularity lets you do a lot more with WSUS and most administrators willfind this granularity an invaluable upgraded feature from SUS.



Figure 6-7Examining the WSUS Computers-group configuration page

Figure 6-7 shows the computer named 2k3.security.local highlighted and selected. In the bottompane you can see the status of updates for that specific computer. This feature is another terrificupgrade to WSUS. You can now see missing patches on a computer-by-computer basis. This capability of WSUS was not previously available in SUS.

Lastly in the left pane in addition to the builtin groups All Computers and Unassigned Computers,you can see three custom groups named Employee Workstations, Lab Computers, and ProductionServers. As you’ll see in the next section, you can approve updates for each of these groups independently.

To add a new group, click the task Create a computer group and name the group. To populate agroup click the All Computers group (or another group that contains the computer you want tomove) and click the Move the selected computer task and specify the target group.

What if I don’t see my computer in the list to choose from? Unlike many other patch management tools, you cannot add computers to WSUS by computer name,IP address, or other mechanism from within WSUS. Instead, you must create a GPO (or manuallyconfigure the client computer registry) to point its Automatic Update clients to the WSUS server. Thefirst time the client contacts the WSUS server it is added to the WSUS server’s database of client computers. If you do not see a computer in the list of All Computers, then check whether



• the GPO is created and configured to use the WSUS server• the GPO is linked to an OU, domain, or site containing your client computers• the client computers Group Policy has been updated (either by rebooting or running the

GPUPDATE command)

This approach makes WSUS quite easy to manage. After you set it up, any new computer addedto a WSUS GPO OU will be automatically added to WSUS. Furthermore, to specify the group at theAD Group Policy level, you can use the Windows Update GPO setting Enable client-side targeting. Inthis setting, specify the name of the group that you want any computers under this GPO to belong.

This approach requires that you organize your different computer groups by OU but for manybusinesses this organization is already complete. For example, you might already have configuredyour OU hierarchy to separate Employee Workstations from Production Servers from Lab Computers.If you have not configured client-side targeting, all newly added computers to WSUS will be unassigned. If you remove a computer from a group, it reverts to belonging to the Unassigned Computers group. To configure the WSUS global setting to use client-side targeting, you must use theregistry, a GPO, or else directly use WSUS.

Another new GPO setting included with the new WSUS Automatic Updates client is the ability fornonadministrators to receive update notifications. Enabling the setting Allow non-administrators toreceive update notifications lets your nonprivileged users receive and install approved updates.

Approving Updates with WSUS Those of you familiar with SUS can recall its process of approving updates which consists of scrollingthrough a very long list of every update released by Microsoft and selecting those to approve. Toimprove upon this process WSUS adds a robust view-filter that lets you see specific updates and letsyou approve updates by computer group. Additionally, WSUS improves how it displays update data,making it easier to scan information about an update before you approve it. To manage the WSUSlist of updates, click the Updates icon in the WSUS navigation bar.

WSUS lets you customize the view of all the updates but it defaults to showing only Critical andsecurity updates, as Figure 6-8 shows. In the left pane of this figure you can see the criteria availableto filter the list of updates including the classifications and products, approval status, and the time-frame when last synchronized.



Figure 6-8Viewing the Updates-group default settings

You can show all updates or limit the view by product or classification. For example, you cancustomize your view to only include specific products by version such as Office updates (Office 2003,Office XP), updates by OS (Windows 2003, XP, Win2K), or Exchange Server (Exchange 2003,Exchange 2000). In addition to filtering by product, you can filter by classification. Classifications bywhich you can filter your view include critical updates, development kits, drivers, feature packs, security updates, service packs, tools, and others. You can also view all approved or not yetapproved updates or filter the updates by time, such as displaying only updates within the last 2months. If you know exactly what you want to find, you can sort by a text keyword, which is usefulwhen you want to find a patch associated with a specific Knowledge Base article or to list all servicepacks. Furthermore, you can sort each of the categories.

WSUS also integrates the deployment status of a specific update together with the approvalstatus, which Figure 6-8 shows in the bottom pane. This window shows the approval status anddeployment status for the selected update. In this example, the selected update named WindowsInstaller 3.0 is approved for installation for all computers but needs installed on two computers, oneof which is the computer named 2k3.security.local located in the Lab Computers group.

This lower pane contains three tabs that present information about the updates. The Details tabshows information about the update such as the summary of the update, whether the update isremovable, if it requires a restart, and what other updates (if any) supersede the specific update. The



Status tab shows WSUS information about the update such as whether the installation files have beendownloaded as well as the update status by computer group. When you approve an update you cancheck this tab for the status of the update download. The Revisions tab lists any revisions to anupdate including the revision number, title, the release date, and its approval status.

One of the finest new features of WSUS is its ability to approve updates on an individual computer group basis. When WSUS first downloads a new update it classifies the update as Detectonly. This classification means that your clients will immediately begin to report on the update’sdeployment status even if you have not approved it yet.

To change the approval of an update, select it (or select multiple updates) and click the Changeapproval task to open a new Web dialog box, as Figure 6-9 shows. From this dialog box you canchange the default behavior for the update as it applies to all computers or you can specify an overriding behavior for specific computer groups. Figure 6-9 shows how you can use this granularityto approve updates for different groups.

Figure 6-9Changing approval of an update from a Web Page Dialog box

For example, let’s say that Microsoft released five new patches on the Windows Update Web site.After your next update synchronization cycle, WSUS will begin to detect whether the patches areinstalled or missing. To begin testing these patches, in the WSUS update console you can select thesefive patches and approve them for Install on the Lab Computers computer group (which you previously defined as containing your test servers). After completing testing, you return to theapproval page and approve the patches for Install on a different computer group representing awider deployment.



The first time you approve the updates will take a bit of time if you select to approve all theupdates. As of January 2005, the initial backlog of updates necessary for a fresh WSUS installation isclose to 300 updates. After you approve the updates, WSUS starts the background file transfer processusing BITS to download each of the updates. This process will also take considerable time to buildup the library of updates that must download to your WSUS server.

WSUS has also improved the user interaction for when to install the updates. For each updateyou can also specify a deadline for installation, as Figure 6-10 shows. A new feature of WSUS letsyou specify whether or not to let the users choose when to install the updates or else force the installation of the update by a specific date and time.

Figure 6-10Viewing the Edit Deadline dialog box

Reports Added in WSUS To access the reporting features of WSUS, click the Reports icon in the WSUS navigation bar. WSUSincludes three different patch management reports that help you assess the proliferation of a newpatch deployment. These reports show you the Status of Updates, Synchronization Results, and Settings Summaries.

The Status of Updates page, as Figure 6-11 shows, reports the count of computers with Installed,Needed, and Failed updates on a per-update and per-group basis. You can drill down to these aggregated numbers for detailed computer-by-computer status of any particular update.



Figure 6-11Reporting the Status of Updates

WSUS also stores information about the client computer. Click the name of a computer (such asthe name 2k3.security.local in Figure 6-11) to retrieve data about the WSUS client, which Figure 6-12shows. These drill-down and cross-section view reports can assist with tracking the deployment ofpatches across many computers.



Figure 6-12Retrieving data about a WSUS client

The Synchronization Results report shows detailed information about the last time WSUS synchronized its updates with Microsoft. The report shows the time the synchronization Started andFinished, the Result (Success or Failure), and how many updates were retrieved or revised, whichFigure 6-13 shows. Additionally, this report shows a list of all the new updates during this period.



Figure 6-13 Showing detailed Synchronization Results

What is remarkable about this report is that you can specify the synchronization period. So forexample, if you have a patch management meeting every week but you synchronize your updatesnightly, you can run a report that shows all the updates in the past 7 days, then use this report as ameeting agenda from which to schedule the testing and deployment of the updates.

The last report named Settings Summary shows at a glance the system-wide configuration settingsof WSUS. This report is a great way to audit the configuration of a particular WSUS server. It tells youhow the server is configured for automatic approval settings, revisions, the synchronization schedule,update source, and other settings.

Configuring WSUS Global Options To access the WSUS Global Settings page, click the Options icon in the WSUS navigation bar. WSUSorganizes its options by Synchronization, Automatic Approval, and Client Computer.

In the Synchronization Options, specify whether to synchronize manually or daily at a time ofyour choosing. Additionally, you can configure WSUS to use a proxy server or another upstreamWSUS server when synchronizing.

WSUS adds new features for automatic approval of new updates. By default WSUS automaticallyapproves Critical and Security Updates for Detection only and adds them to the All Computers group.



You can also define how WSUS will approve updates for installation. Review these settings and selectthose that complement your patch testing and deployment process. For example, you might not wantto automatically approve any updates for installation until your patch management team has triagedthe updates.

WSUS also lets you configure how to handle revisions to an update and the default action is toautomatically approve the latest revision of the update. The final configuration setting lets you specifywhether to Use the Move computers task in the Windows Update Services or else the Group Policy orregistry settings to assign client computers to groups.

Corporate Solutions Reviewed SUS and the upcoming and dramatically improved WSUS products from Microsoft offer a centrallymanaged, mostly hands-off approach to patch management that dramatically eases the deploymentprocess of Microsoft patches. SUS and WSUS support deploying updates to only Microsoft productsand they are somewhat passive—meaning that you can’t directly target and deploy a specific patch toa specific computer. But these products are free and very easy to use. SUS and WSUS use the Auto-matic Updates client, which is installed on every new version of Windows. This builtin client makesusing SUS and WSUS for deployment and tracking of updates easier than using third-party patchmanagement products that require a separate client installation. Even if you use a third-party patchmanagement product, you might find benefit in using WSUS and SUS as a backup or to increase yourdefense-in-depth as yet another mechanism to ensure that your systems are up-to-date and patched.

Some of SUS and WSUS features include:• Central management using AD Group Policy• Downloading updates directly from Microsoft Windows Update Web site• Using the builtin Windows Update client that comes with every Windows platform• WSUS’s support for computer groups, granular update approval, and patch deployment reports

(features sorely lacking in SUS)• Support of only Microsoft products

The WSUS features that support multiple computer groups and its improved reporting make it anecessary upgrade for SUS users. Some larger organizations that use a third-party patch managementproduct might find that the new features in WSUS coupled with its ease of use and low administra-tion requirements make it a compelling Microsoft software patch management solution.

Keeping your software up-to-date is more important than ever. After you get SUS or WSUS running, you can maintain a current and applicable set of patches for all new production machines.Update scanning will occur regularly and approved patches will automatically flow to machines. This consistent and methodical approach will help ensure that new systems introduced into your production environment—months after a flurry of patching—will instantly be at the same patch levelas their peers.



115


Chapter 7:

Enterprise Solutions: SMS 2003 Staying one step ahead of new exploits of known vulnerabilities takes time and effort. At a minimum,such preparedness requires knowledge that new updates are available and that you’ve protected yoursystems with the most current updates. This book has explored processes, mechanisms, and freelyavailable patch management technologies to assist with the triage and deployment of Windows security updates and service packs. Microsoft also offers a highly flexible commercial software patchmanagement product: Systems Management Server. SMS 2003 Service Pack 1 (SP1) provides softwareupdate scanning of both Windows and Microsoft Office platforms, as well as detailed and customiz-able reports showing the status of software updates. SMS is regarded as a complex enterprise productfor large organizations, but even small to midsize businesses can benefit from SMS’s enhanced inventory and reporting capabilities. SMS 2003 integrates with Active Directory (AD) and for smalldeployments can be installed on a single server. Yet, SMS scales very well to accommodate patchmanagement for very large enterprises.

The SMS platform does more than patch management. This powerful enterprise tool lets you centrally manage your client machines and it includes features such as hardware and software inventory, software distribution, software metering, and remote control services. It includes client-server features that recognize and accommodate remote and mobile computers and fast or slow WANnetwork links. In fact, it wasn’t until 2002 that Microsoft added specific patch management capabilitiesto SMS through the SMS 2.0 Software Update Services (SUS) Feature Pack. Users of SMS 2.0 coulddownload the feature pack for free and add inventory and deployment capabilities to their SMSinfrastructure specifically tuned for patch management.

Since then, Microsoft has integrated many of the patch management features into SMS 2003 SP1.You can use SMS 2003’s inventory and software distribution mechanisms to assess and install updatesfor both Windows Security and Microsoft Office products. SMS 2003 also supports a flexible queryand reporting engine for presenting a wide variety of highly customizable update-summary data ofyour patch status. You might wonder what SMS offers for patch management that is different fromSUS and Windows Server Update Services (WSUS). In a nutshell, SMS provides more granular targeting criteria, is cognizant of your WAN topology (so it works better for deploying patches toremote offices and mobile users), and offers broader support of software deployments. For example,instead of simply approving an update to a group of computers (like you can do with WSUS), with SMS you can deploy an update to laptops of only a particular brand or model and track theinstallation progress on a daily report.

To take advantage of these features and enhancements, you must first face the rather steeplearning curve of successfully deploying and managing SMS 2003?especially if you have a large orcomplex organization. Not only is the initial deployment more complex than with SUS or WSUS, buteach security update also takes more time to prepare for deployment. Fortunately, many resourcesare available to help answer questions you might have about this multifaceted product. For SMS 2003planning, deployment, and administration tutorials, you can check out the Web site at



http://www.microsoft.com/smserver. Also at the Microsoft Web site, you can go to the Technet VirtualLab sessions at http://www.microsoft.com/technet/traincert/virtuallab/sms.mspx.

SMS 2003 provides an entire suite of systems management capabilities and this chapter will walkyou through configuring a basic installation of SMS 2003 to scan and inventory, deploy, and report onthe status of security updates and Microsoft Office updates.

Preparing Your Environment for SMS As with any new technology or application, I recommend setting up a simple test environment that isseparate from any production machines. If you haven’t worked with SMS, I suggest that you readabout deployment considerations, recommendations, and best practices at the Microsoft Web site,http://www.microsoft.com/smserver. This example is based on a Windows 2003 AD domain: all theclient computers run Windows 2000 (Win2K) or later and are members of this domain. Therefore, wewill use the latest SMS features such as Advanced Security and the advanced client. (These featuresare available to SMS 2003 installations. If you are upgrading from SMS 2.0, or running on NT 4.0 orWindows 98, then you might need to use standard security and the legacy client.) Under advancedsecurity, all the SMS servers are in AD and SMS runs under the local system account, which reducesthe number of domain accounts needed to run the program. (Integration with AD is a huge benefitof SMS 2003 over earlier versions.)

This chapter walks you through a basic SMS 2003 installation that consists of one server and afew clients. The server plays multiple roles as a primary site, a management point, distribution point,and reporting point. Before installing SMS we need to configure the server platform. On this serverinstall Windows Server 2003 OS, Internet Information Server (IIS) 6.0, and the Background IntelligentTransfer Service (BITS) Server Extensions.

SMS 2003 uses a SQL Server database to store all its data, and for our test environment we’llinstall SMS onto a server running SQL Server 2000 SP3a. The client machines consist of several Windows XP workstations and a computer running Windows Server 2003. The clients are all withinthe same class C subnet (192.168.0.0/24) and have Internet access.

First, confirm that your SMS Server has been built as follows:• Windows Server 2003 with all security updates applied• Application Server with IIS 6.0 and BITS Server Extensions installed• SQL Server 2000 with SP3a installed

Setting Up AD Next we need to create the user accounts that SMS will use and enable the SMS Site Server to updateAD. First, let’s create the account that we will use to deploy software on each client computer.Launch Active Directory Users and Computers and create a domain account (e.g., smsDeploy). Thisaccount needs to have administrative privileges on each client computer that you want to managewith SMS. (This account does not need to be a member of the Domain Admin group and, if possible,you should refrain from using that privileged group.)

We will configure SMS 2003 to run under the advanced security option, so we need to give permissions for the primary Site Server computer to update the System container in AD. To do this,open Active Directory Users and Computers, and from the menu select View, Advanced features.Navigate to the System container, right click it, and select Properties. Select the Security tab and click

http://www.microsoft.com/smserver

http://www.microsoft.com/technet/traincert/virtuallab/sms.mspx

http://www.microsoft.com/smserver

Add. In Select Users, Computers, or Groups make sure the Object Type includes Computers, then typethe name of the computer on which you will install SMS. Click Check Names to ensure that the computer name is recognized and click OK. Now, in the group or user names list, select the name ofyour computer and make sure that Read, Write, Create All Child Objects, and Delete All Child Objectsare selected. Next, click Advanced, select the computer account again, then click Edit. In the Applyonto drop down menu, select This object and all child objects. Click OK until you exit the dialog box.

SMS 2003 integrates with AD and leverages AD Sites to define SMS Site Boundaries. An SMS siteboundary defines SMS’s scope when looking for computers to manage. To define the AD Site, launchActive Directory Sites and Services from the Administrative tools. The default name of the first AD siteis Default-First-Site-Name. You can either rename this to something that defines your site (in ourexample, we define the AD site name as seattle) or leave the default name. Next, right-click the Subnets node, and left click New Subnet to define the subnet (e.g., 192.168.0.0 with a subnet mask of 255.255.255.0). Assign that subnet to the site name by clicking on the site, then click OK. Whencompleted your Active Directory Sites and Services will look similar to Figure 7-1.

Figure 7-1Viewing Active Directory Sites and Services after setup

Installing SMS 2003 Running the SMS 2003 setup program is very straightforward. From the SMS 2003 installation media,run autorun.exe and select to install SMS 2003 to start the installation wizard. First specify to install anSMS Primary Site. In our example, our site code is SEA, the site name is seattle, and the site domainis security. Next in the installation process, the setup program will ask whether to extend the ADschema for you. (You must be a member of the schema admins group to perform this step.) Whenprompted, choose to install SMS 2003 under Advanced Security. In the last few steps of the wizard itwill create the database for you; by default it’s named SMS_sitename (e.g., SMS_SEA).

The basic installation of SMS 2003 is now complete. Now, let’s make it functional.

Chapter 7 Enterprise Solutions: SMS 2003 117


Launch the SMS Administration console by clicking Start, All Programs, Systems ManagementServer, then SMS Administrator Console. From this Microsoft Management Console (MMC) you will be able to perform most of your patch management activities. Now, let’s begin the base configurationof SMS.

Configuring a Base SMS Installation Navigate to Site Database, Site Hierarchy, right-click the Site Name, then click Properties to see theproperties for the site. As Figure 7-2 shows, click the Site Boundaries tab, then click the yellow staricon to add a new Site boundary.

Figure 7-2Adding a new site boundary

Choose the site boundary and add the AD site that you created earlier (e.g., seattle). (You canalso define a site boundary by subnet ID, but I’ve found that leveraging AD sites for this is more flexible and easier to manage.)

Specify the Management Point The clients will communicate with the SMS infrastructure through SMS Management Points. The management points are the primary point of contact for clients. By default this point is undefined andwe must assign this role to our new SMS server. Navigate to Site Database, Site Hierarchy, Site Name,Site Settings, then click Site Systems. In the right pane, double-click the site name (e.g., \\SMS) tobring up the Site System Properties. Click the tab Management Point and enable the checkbox Usethis site system as a management point.

Enable Reporting To view reports from this SMS Server we need to define it as a Reporting Point. (If you do not havea reporting point enabled the Run reports option will be grayed out.) Navigate to Site Database, Site



Hierarchy, Site Name, Site Settings, and Site Systems. In the right pane, right-click the name of yourSMS server, and left-click Properties to bring up the Site System Properties. Click the Reporting Pointtab and enable the Use this site system as a reporting point checkbox. You can leave the defaults forthe remaining values, as Figure 7-3 shows.

Figure 7-3Showing the Reporting Point settings

Add the user accounts that you want to provide with access to the SMS reports to the SMSserver’s local group SMS Reporting Users. Adding these users is an important step because, by default,even local administrators cannot view the reports. Test the installation by opening your Web browserto http://smsserver/SMSReporting_sitecode. We’ll look at the reports specific to patch managementafter we’ve completed the SMS configuration and used it to deploy a few patches.

Prepare the Deployment of the SMS Client Software Now we’ll configure SMS to load the SMS Systems Management client on the computers in our testdomain. Navigate to Site Database, Site Hierarchy, Site Name, Site Settings, then click Client Agents. In the right pane of the MMC, double-click the names of the agents you want to install. For patchmanagement you need to enable the Hardware Inventory Client Agent, Software Inventory ClientAgent, and Advertised Programs Client Agent. (The remaining agents are used for other SMS features.)



http://smsserver/SMSReporting_sitecode

Decrease Polling Intervals and Increase Polling Frequency for Testing A lot of SMS functionality revolves around polling client computers for status and information. Manypolling intervals are set to 1 day or 1 week by default. To facilitate testing, I recommend decreasingsome of these settings to much more frequent intervals. This adjustment will let you witness changesmore frequently when evaluating and using the system. For both the Software and Hardware Inventory agents decrease the time to run the inventory to a time less than the default (e.g., 1 hour).Similarly, for the Advertised Programs Client Agent, increase the polling time to a more frequentinterval (e.g., 5 minutes). These settings facilitate testing while increasing network and system load.Remember to restore these settings to default values when you deploy to your production environment.

Enable Client Push Installation Now, let’s configure SMS to deploy the agents to your test systems. Navigate to Site Database, SiteHierarchy, Site Name, Site Settings, then click Client Installation Methods. In the right pane, double-click the Client Push Installation and enable the checkbox Enable Client Push Installation to assignedresources. Also, enable the checkboxes next to the platforms on which you want to deploy the client:servers, workstations, or domain controllers (DCs).

Earlier we created a domain account with administrative permissions on the SMS client computers; now we need to specify this account in SMS. Click the Accounts tab and click the yellowstar icon to add the account that will be used to install the SMS client software. Enter the domain and account name of the previously created client software deployment account (e.g., security\smsDeploy). Click OK to exit the Client Push Installation properties. With this configuration SMS 2003will install the SMS client on any computers that are running and that SMS has discovered andassigned to this site.

Specify the Account to Use for Software Distribution In addition to installing the SMS Client software, we need to also configure an account for SMS to use to install the software updates. Navigate to Site Database, Site Hierarchy, Site Name, Site Settings,then click Component Configuration. In the right pane of the MMC, double-click Software Distribu-tion. On the General Tab for the Advanced Client Network Access Account, click Set, enter thedomain and account name of the service account you want to use for the client installation (e.g.,security\smsDeploy), and enter the password. Click OK.

At this point, the majority of the configuration of our basic SMS installation is complete. Now weneed to run a discovery to populate the SMS database with potential client computers. When a discovery runs, a discovery data record (DDR) is created for each object found. Because we enabledthe Client Installation Push, any objects that are discovered, are within the site boundary, and can beadministratively managed by the SMS computer, will be installed with the SMS client.

Client Discovery and Installation SMS 2003 retains many of the flexible discovery processes of earlier SMS versions, such as networkand heartbeat discovery, but also recognizes objects in AD. So now in addition to using SNMP andother techniques to scan the network, SMS can query an AD DC directly for computer and userobjects. For our test domain, we’ll use the SMS Discovery Method Active Directory System Discoveryto populate our collection of objects on which we want to install and manage the SMS client.



Navigate to Site Database, Site Hierarchy, Site Name, Site Settings, then click Discovery Methods.In the right pane, double-click Active Directory System Discovery. Enable the Enable Active DirectorySystem Discovery checkbox. Click the New icon, select Local Domain, and ensure Recursive isselected. When you click OK, you will be prompted to select the container to poll. Specify the container (e.g., organizational unit—OU—or domain name) then click OK. The distinguished name(DN) of the container you selected will appear in the Active Directory System Discovery dialog box.Click the Polling Schedule tab and notice that polling occurs every day. Click the checkbox to enableRun Discovery as soon as possible. This will initiate the discovery now. SMS will create a DDR foreach resource it finds and will automatically begin to deploy the client software, based on our earlierconfiguration.

Review Newly Discovered Clients Each new system discovered with DDR will be viewable in the collection All Systems. Navigate to theSite Database, Site Hierarchy, expand the Collections node, and click All Systems. Depending on thesize of your network and network link speed, the computers in your specified AD container willappear in the right pane. (AD is not the only discovery method and you can use other network-oriented methods to pick up nondomain objects. However, you will not be able to use the SMSadvanced client or other techniques presented in this chapter to manage these.)

If you make changes to your site definition, add new clients and follow up with a manual discovery, or change your client installation options, then you can manually update the collectionmembership. Under the collections node, right-click the All Systems node, left-click All Tasks, theselect Update Collection Membership. An hourglass will appear next to the All Systems collectionwhile the update is processing and you can click the Refresh button at the top of the MMC to updatethe status until the update has completed. In the right pane, you’ll see all the computers, as Figure 7-4 shows.

Figure 7-4 Viewing the All Systems computer collection



Troubleshooting Missing or Unassigned Clients If following a discovery your clients are neither assigned nor have a client installed, double-checkthat:

• The site boundary is correctly defined. If you specified only a subnet ID, define the siteboundary through AD site and make sure that AD site has been correctly associated with thecorrect subnets.

• The SMS Client Installation features are configured to use an account with administrative permissions on the clients.

• SMS has been configured to deploy the clients.

Other Methods for Installing the SMS Client In the earlier configuration example we configured the Client Push Installation option Enable ClientPush Installation to assigned resources to automatically deploy and install the SMS clients. You canuse several other methods to install the client: by manual installation, using a logon script, through aWindows Group Policy software installation, through a software image, and more.

SMS 2003 supports two types of clients: the advanced client and the legacy client. This examplesupports only the advanced client because it does not have any NT 4.0 or SMS 2.0 systems. Thelegacy client is based on SMS 2.0, supports NT 4.0 and Windows 98, and does not have as many features as the new SMS 2003 advanced client. The advanced client offers better security; forexample, it runs under the local system account on the client computer and is not dependent upondomain accounts as was the SMS 2.0 client. Also the Advanced Client supports BITS technology,which provides better support for mobile and remote users. Also, the client agents (e.g., the hardwareand software inventory agents) are included in the advanced client. When using the legacy client, theclient agents must be downloaded and installed separately.

If you need to manually install the SMS client, run \\smsserver\SMS_sitecode\Client\i386\ccmsetup.exe to install the advanced client (or run smsman.exe to install the legacy client).

At any time you can initiate a client installation directly from the SMS Administrators console.From the list of clients in the collections node, right-click the name of the computer on which youwant to install the client, and select All Tasks, Install Client. Follow the short wizard to initiate theclient installation process.

Checking the SMS Client on the Client Computer On a computer that you have installed the SMS client, open the Control Panel. If the SMS Client was successful, you will see a new program called Systems Management. Launch the Systems Management applet and confirm that it contains information about your newly installed site. Click theComponents tab to verify that the components (i.e., SMS Inventory Agent, SMS Software UpdateAgent, and Software Distribution Agent) are installed. Also check that the client has been correctlyassigned to your site. On the Advanced tab, confirm that your site is listed as the Currently assignedto Site Code Value. If it is not, click the Discover button or enter the site code (e.g., SEA) and clickOK. The advanced client files are in %SystemRoot%\System32\CCM. The legacy client files areinstalled to %windir%\MS\SMS.



Using SMS for Software Updates Now that we’ve installed a base SMS platform and deployed the SMS client to our test computers, wecan focus on the Software Update Management features. In this section we’ll look at how to use SMSto scan for and deploy missing security updates and run reports to show the status of the updates.

SMS 2003 integrated many, but not all, of SMS 2.0 Feature Pack’s patch management features.You must add two modules separately. By default, the following software update modules areinstalled in SMS 2003:

• The Distribute Software Updates Wizard • The Software Updates Installation Agent• Software Update Reports

You must download and install these add-on modules separately:• Microsoft Office Inventory Tool for updates (officepatch_enu.exe)• Security Update Inventory Tool (securitypatch_enu.exe)

You can download these two modules as a single file from the Microsoft Web site athttp://www.microsoft.com/smserver/downloads/2003/featurepacks/suspack/default.asp. Copy the fileto your SMS site server and run it to extract the files to a directory of your choosing. To install thetwo scanning tools, navigate to the chosen directory, then to the directory named SMS2003SP1ScanTools_ENU and run the two installation programs OfficePatch_ENU.exe and SecurityPatch_ENU.exe.

Installing the Office Update Inventory Tool The Office Inventory Tool for Updates module is an SMS add-on that runs weekly to check theupdate status for Office 2003, Office XP, and Office 2000 on your SMS client machines. Both thismodule and the Security Update Inventory Tool module independently integrate available Microsoftutility tools for use within SMS. This integration provides a common interface and reporting mechanism for these scanning tools. SMS saves time from running these tools independently byscheduling when these tools run and collecting the results in the SMS database. Then you can use theSMS Reporting capabilities to view the update status and create new update deployment packagesthat install only on machines that need specific updates.

To install the Office Update Inventory Tool, run the self-installing executable file, then specify adestination directory (e.g., C:\Program Files\OfficePatch). Click Next. Because the module relies onan existing tool for the scanning process, it prompts you to download the most recent version of thetool directly from the Microsoft Web site. Click Download, and the installer will download the latestversions of invcm.exe and invcif.exe. (If your test server doesn’t have direct Internet access, you mustdownload these files separately and copy them to this machine. Search Microsoft.com for the latestversion of these files. At the time of publishing, you could download invcm.exe from the OfficeUpdate Inventory Tool Version 2.1 Web site at http://www.microsoft.com/downloads/details.aspx?FamilyID=1687c33e-d2c8-4766-937f-6e97e3e0f299&displaylang=en and invcif.exe from theMicrosoft Office Online Web site at http://go.microsoft.com/fwlink/?linkid=19074&clcid=0x409.) ClickNext, and the installation wizard extracts and installs the tools into your SMS installation. Afterinstalling the tool, the setup wizard, which Figure 7-5 shows, walks you through the configuration.



http://www.microsoft.com/smserver/downloads/2003/featurepacks/suspack/default.asp

http://go.microsoft.com/fwlink/?linkid=19074&clcid=0x409

http://www.microsoft.com/downloads/details.aspx?FamilyID=1687c33e-d2c8-4766-937f-6e97e3e0f299&displaylang=en

Figure 7-5Using the Microsoft Office Inventory Tool for Updates Installation setup wizard

Confirm that the Create Collection, Create Advertisement, and Assign Package to all DistributionPoints check boxes are selected. This tool creates a new SMS deployment package and assignment.When asked, enter a package name (such as OfficeUpdates), specify the names of any test computersto include in the initial advertisement, then complete the remaining steps of the wizard. Then SMScreates the programs, packages, and advertisements for the Office Update Inventory Tool.

To review the Office Update Inventory Tool module’s settings, open the SMS Administrator Console, click Site Database, select Packages, and click the name of your new OfficeUpdates package(e.g., OfficeUpdates). Next, click the Programs node in which you’ll find your three new programs:OfficeUpdates, OfficeUpdates (expedited), and OfficeUpdates Sync, which Figure 7-6 shows.



Figure 7-6Showing OfficeUpdates programs in the Programs node

Additionally, two advertisements appear in your site: OfficeUpdates and OfficeUpdates Sync. TheOfficeUpdates advertisement starts the program of the same name once a week to scan your SMSclient computers for installed Office components and updates. The OfficeUpdates Sync advertisementdownloads new update information from Microsoft each week.

Installing the Security Update Inventory ToolTo check for crucial OS security updates the Security Update Inventory Tool module scans a machinefor installed updates and compares the results against a Microsoft database (mssecure.cab) of updates.When installed, this tool integrates into SMS and runs weekly to collect security update data fromyour SMS clients. As with the Office Update Inventory Tool module, you will be able to use SMS2003’s builtin reporting to view the status of the updates. Using the Distribute Software UpdatesWizard, you can also create and deploy packages of updates that install on machines that need theupdate. SMS schedules and manages the application of the module.

Installing the Security Update Inventory Tool is similar to installing the Office Update InventoryTool. Run the program SecurityPatch_ENU.exe to initiate the installation wizard. Specify a destinationdirectory for the tools (e.g., C:\Program Files\SecurityPatch). Then the tool prompts you to downloadthe latest version of the security patch bulletin catalog file (mssecure.cab), an XML file. Continuethrough the wizard to install the Security Update Tool. Like with the Office Update tool, enter a name



for the Package (e.g., SecurityUpdates). Review and specify the Distribution settings, DatabaseUpdates, and a test computer. Then install the module. As Figure 7-7 shows, new SMS advertisementsassociated with the Security Update Inventory Tool have been added to your SMS installation.

Figure 7-7Viewing new SMS advertisements for updates

SMS Vernacular: Programs, Packages, Advertisements, and Collections Before we get too far into the nuts and bolts of scheduling scans and deploying security updates, let’stake a crash course in SMS lingo. In SMS vernacular, a program defines the binary application (e.g., patchinstall.exe) that describes the command line, the starting directory, and the rights underwhich the application runs (e.g., administrative rights). The package encapsulates multiple programsand specifies the distribution points, or locations, to deliver the package. For example, if you havegeographically dispersed offices connected by a slow link, you will likely place a distribution point ineach office. The package also contains information about how to deliver the programs to the distribution points: for example, whether to compress the files. An SMS advertisement scheduleswhen a program will run and configures the program for a specific collection. Collections are logicalgroupings of SMS clients used to target SMS actions. For example, the Microsoft Office Update Inventory Tool module creates several collections for testing and production computers, which Figure 7-8 shows.



Figure 7-8 Showing Collections for testing and production computers

Creating Your Package of Updates: Working with the Distribute Software Updates Wizard The Distribute Software Updates Wizard was previously a separately installed add-on to SMS 2.0 available from the SMS Feature Pack, but it is fully integrated into SMS 2003 SP1. This module analyzes data that the Office Update Inventory Tool and the Security Update Inventory Tool modulescollect, then recommends patches to install. This wizard pulls a list of applicable updates identifiedduring an earlier run of either the Office Updated Inventory Tool or the Security Update InventoryTool scan, then walks you through the process of downloading the updates and configuring them fordeployment through SMS. Although SMS package creation can be challenging, the Distribute SoftwareUpdates Wizard eases the challenge a bit by setting the package parameters, downloading theupdates, and configuring the SMS programs and packages for you.

Open the SMS Administrator Console, expand Site Database, right click Software Updates, expandAll Tasks, and select Distribute Software Updates to invoke the Distribute Software Updates wizard.On the first step of the wizard, select the software update type: MBSA (for Security Updates) orMicrosoft Office (for Office Updates), as Figure 7-9 shows.



Figure 7-9 Selecting a software update type

The wizard notifies you that you must create a new package; in subsequent runs, the wizard letsyou edit existing packages. This new package will contain the security updates for deployment. Nameyour package (e.g., MyFirstSecurityUpdates) and enter the name of your organization. Next, specifythe Inventory Scan Tool package and the Program name. For this example, select Security Updatesfor each, as Figure 7-10 shows.

Figure 7-10 Selecting the Inventory Scan Tool package and the Program name



The next wizard screen displays applicable security updates. The wizard generates this list bycomparing the available Microsoft security updates against the results of previous security updateinventory scans. Select the updates you want to include in this package. Click Next, then specify thesource directory in which the update files will reside. SMS can download the updates for you andcopy them to your distribution point. If a download fails, you’ll need to download the update separately. At times SMS can’t download an update (e.g., the URL might point to an incorrect orbroken update link), so you will need to become familiar with the process of downloading updatesand pointing the wizard to them. SMS sometimes stumbles as it tries to reconcile and automate themany different update formats that Microsoft offers. If the wizard fails to identify the update executable file, you must manually open the Microsoft Security Bulletin Web site, search for anddownload the correct version of the specific update, and copy it manually to a location that the SMSDistribute Software Updates Wizard specifies. Even with the help of the wizard selecting the individual updates, waiting for them to download then configuring them for deployment is a timeconsuming process compared to SUS and WSUS’s simpler update process.

After downloading each patch to your distribution point, the status of each update shows notReady, which Figure 7-11 shows. To make an update ready, you must specify the command-lineparameters the update will use when it runs.

Figure 7-11 Showing the status of the patches

Select each update and click Properties to view details about the update. By default, the Parameters box might be blank, as Figure 7-12 shows.



Figure 7-12 Showing a blank Parameters box

You must specify parameters to suppress reboots and limit user interaction (i.e., silent or quietinstall). Unfortunately, as explained in earlier chapters, Microsoft employs multiple engines to deployits updates, and each engine uses specific command-line variants. When in doubt, click Syntax to display a Microsoft Web site showing the myriad of command-line switch information about a specific update’s engine or go to the Microsoft Web site at http://support.microsoft.com/default.aspx?scid=KB;en-us;q810232. Table 7-1 provides several command-line variants excerptedfrom the table at the Microsoft Web site.



http://support.microsoft.com/default.aspx?scid=KB;en-us;q810232

Table 7-1 SMS Software Update Command-Line Switches for Silent Installations

Product or Component Command Line ExamplesWindows NT 4.0 and Windows 2000 (Win2K) SP3 and earlier -q –z q123456i.exe -q -zWin2K SP4 and later, and Windows XP /q /u /z q123456_w2k_sp4_x86_en.exe /q /u /z(Switches vary depending upon /norestart /quiet /passive q123456_w2k_sp4_x86_en.exe /norestart update.exe version.) /quiet /passiveInternet Information Services (IIS) /q /z q123456.exe /q /z4.0 and 5.0 q1234356_w2k_sp2_x86_en.exe /q /zInternet Explorer (IE) /q:a /r:n q123456.exe /q:a /r:nWindows Media Player (WMP) /q:a /r:n wm320920_71.exe /q:a /r:nExchange 2000 Server /q /z 811853_enu_i386.exe /q /zExchange 2003 Server /q /z Exchange2003-KB832759-x86-enu /q /zOffice See the SUS Feature Pack release notes

and online documentation.SQL Server 2000 /a /q DISABLESTATUS=AUTO SQLHotfix_ENU.exe /a /q

DISABLESTATUS=AUTOVirtual Machine (VM) /c:"javatrig.exe msjavwu.exe /c:"javatrig.exe /exe_install

/exe_install /l /q" /q:a /r:n /l /q" /q:a /r:nMicrosoft Data Access Components /C:"dahotfix.exe /q /n" /q:a /C:"dahotfix.exe /q /n" /q:a(MDAC), and Microsoft XML enu_Q832483_mdac_x86Core Services (MSXML) Commerce Server Please refer to the bulletin for the available

command-line syntax.Content Management Server (CMS) Please refer to the bulletin for the available

command-line syntax.BizTalk Server Please refer to the bulletin for the available

command-line syntax.Host Integration Server (HIS) Please refer to the bulletin for the available

command-line syntax.Dell system updates or No need to specify. The correct command line is provided byDell component updates the Dell update catalog.[Note: This table is reprinted from Microsoft Knowledge Base article 810232.]

Click the Information button to go to an update’s TechNet Web page. These pages give youquick and detailed information about specific updates. After you have added the parameters for eachupdate, click Next to specify the distribution points that will push the package to clients. At this pointin the process you can specify whether to immediately collect client inventory and postpone restartsfor servers or workstations.

Lastly, configure the desired behavior of the Software Updates Installation Agent. The SoftwareUpdates Installation Agent runs on a client machine during the update package installation to ensurethat you don’t install redundant or unnecessary updates. This agent provides granular control over thedeployment process for a set of updates. For example, you can specify the number of minutes thatthe process should wait for a user to accept an update before installing it automatically. This agentcan also monitor update installations and cancel installations that hang or fail. As Figure 7-13 shows,you can also let users install updates at their convenience.



Figure 7-13 Viewing the Configure Installation Agent Settings dialog box

For example, you can allow users to wait 2 days before having the update install automatically orrestart the system. Users like to be able to specify when to install updates, and you can rest assuredthat the updates will deploy. Additionally, you can configure the Installation Agent to report successful and failed installations and elect to postpone system restarts for servers and workstations.This feature is handy when you’re deploying a package to a mixed group of servers and workstationsand you want to reboot the workstations immediately after installing an update, but want to delayrebooting servers until you take them offline for maintenance. This last step completes the DistributeSoftware Updates wizard but the package will not deploy yet. We must advertise the package.

Advertise Your Updates Navigate to Site Database, right click the Advertisements node, select New, then Advertisement. Onthe General tab, name the advertisement (e.g., MyFirstSecurityUpdates Advertisement), select thePackage and Program, and enter the name of the Collection that includes the target computers for theadvertisement to include. In this example, as in Figure 7-14, you can see that most of the entries arefrom objects we created earlier.



Figure 7-14 Viewing Advertisement Properties

Also in our example, the collection SecurityUpdates includes one computer defined for testing,named xppro. Click the Schedule tab and define the time that you want to deploy the software. Regularly scheduled SMS advertisements are available for installation from a users Add Remove Programs control panel program. But with security updates, you will most likely want the securityupdates to install automatically without user interaction. To do this, you must assign the package byscheduling it for mandatory assignment. On the Schedule tab, click new mandatory assignment, andspecify a time (or specify As soon as possible). After you click OK, you can see that your new advertisement is listed under Advertisements.

At this point you can switch over to an affected client and watch the SMS client install the newupdates. Because this example is a security update, while watching task manager you will see theMicrosoft Baseline Security Analyzer (mbsacli.exe) scan the computer before the update is installed(the security update inventory tool uses mbsacli.exe to scan the client computer). This scan ensuresthat only the necessary updates are deployed. Lastly, depending on your package preferences, yourusers might be presented with a dialog box instructing them to restart their computer within a specified timeframe, as Figure 7-15 shows.



Figure 7-15 Receiving notification of an update and restart time

Run the update and check that the patches have installed successfully. (For testing purposes, you can run MBSA on the test machine to quickly verify that the appropriate updates applied successfully.) If you encounter any problems, examine your client machine’s CCM\logs directory (e.g., \%windir%\system32\ccm\logs) for the patchinstall.log file. This file lists all the applicableupdates for that client and which updates are authorized in that package. This step can help youdetermine why a particular update or package isn’t installing correctly.

SMS 2003 Reporting SMS 2003 also includes builtin Web reports from the SMS server defined as a reporting point. Accessthe SMS Web Reports home page (by default this page is located at http://smsreportserver/SMSReporting_sitecode) to view any data collected since installing the update tools and running theinventory.

Manually Refreshing the Reports To manually refresh report data—for example, after installing updates on a machine—you mustspecify a new time for the Security Update Inventory Tool and the Office Update Inventory Tooladvertisement to run. When these programs finish running, you must run a hardware inventory onthe client machine. On the client system, run the Systems Management applet. Click the Componentstab, select the Hardware Inventory Agent, and click Start Component. This process will gather theupdate information from the client machine and post it to the SMS database, thereby updating theSMS Software Update reports.

Standard SMS reports include Hardware Inventory, Software Inventory, details on the SMS Site,and Status Message Reports. Patch status reports include drilldown-capable reports that show patchesby machine, all patches, or patches by product. Microsoft includes many different reports that let youeasily survey your organization’s overall patch landscape or drill down into details about an individualpatch or machine’s deployment status.

Patch Management with SMS SMS 2003 provides a high degree of flexibility for deploying Microsoft Security updates, but it is not for the feint of heart. Although SMS is an enterprise tool, it can be used in small to midsizeshops. But to use SMS successfully requires more training and configuration than Microsoft’s lesssophisticated products, such as SUS and WSUS. Plus the preparation of the patches for deployment is



http://smsreportserver/SMSReporting_sitecode

much more hands on than with SUS, WSUS, or other commercial patch management programs. Butfor those that do invest the time, SMS provides a widely customizable platform from which to scanfor and deploy updates and most any other software.

Remember these tips when installing SMS 2003 for patch management:• SMS is designed to scale for very large enterprise deployments, so many of its components are

modules. For a small or lab environment, install SMS on one server for basic testing of thepatch deployment features.

• An SMS client must be installed on each target computer.• Programs include the definition of the updates that you want to deploy.• Packages define the distribution points for groups of related programs.• Advertisements define the schedule and logistics for deploying a package—including the

targeted collections.• Collections are groups of computers based on system attributes or manually defined.• In an SMS 2003 environment you must install the Office Update and Security Update scanning

tools.• Use SQL Server’s backend, builtin queries, custom queries, and reports to generate a stunning

array of views into your data.

The combination of reports, inventory tools, and targeted patch distribution that SMS offers mightbe compelling enough to lure non-SMS converts into the fold. Properly deployed, SMS becomes apowerful foundation for patch management.



Ms Patch Man Ch8

Technology

Transcript of Ms Patch Man Ch8