Taking the First Step: Patch Management

Microsoft is spending a lot of time and money to increase the security of its products. However, its efforts to build patches and get them to you don’t do any good unless you take the time to keep your systems patched. Microsoft had a number of large enterprise customers that were unaffected by CodeRed and Nimda. Why? Because these customers took the time to secure their systems, including locking down Access Control Lists (ACLs) on system files, removing unnecessary services, and installing security patches when the patches were released, not after the attacks had started. For a relatively small investment of time and effort, you can gain a great degree of security. That’s why I cover patch management first—good security policies and great intentions are worthless if you have unpatched vulnerabilities on your servers!

Where Patches Come From

Before discussing the details of patch management, let me briefly digress to describe how patches are created and distributed. During the Microsoft Windows 2000 development process, Microsoft launched an internal program called the Secure Windows Initiative (SWI). SWI’s goal was to strengthen Windows security by cleaning up past implementation flaws in Windows components, as well as instituting new policies and procedures to help reduce future flaws. Concurrently, Microsoft beefed up the staffing and authority of the Microsoft Security Response Center (MSRC), the folks who write the security bulletins Microsoft uses to tell us about new vulnerabilities or patches.

Patches are created to address specific vulnerabilities. These vulnerabilities can be identified through several methods:

• Internal efforts (one example is the early-2002 security push that took all 8,500 Windows developers away from new product development to focus on bug fixing)

• Customer reports (Microsoft averages more than 500 e-mail reports a month, many of which are duplicates or the result of configuration problems)

• Reports from external researchers, or even “black hats,” on public security mailing lists and discussion forums

No matter the source of the report, when a vulnerability is reported the MSRC studies it to figure out whether it’s really a vulnerability. (More than 98% of the reports they get are duplicates or bogus.) If the vulnerability is real, and not the result of a configuration issue, MSRC prioritizes the flaw according to its seriousness and works with the development team to build a fix for it. For serious flaws, Microsoft will immediately issue a security bulletin covering the issue in detail and discussing workarounds or alternate protections. For those that can be quickly patched, the bulletin and patch are released at the same time.

Note

To read an interesting document that explains in great detail how the MSRC works and what they do, visit http://www.microsoft.com/technet/columns/security/essays/sectour.asp.

Once the patch is completed, it’s made available in several ways: through the Windows Update and Software Update Services Web sites (more on those in a minute), through direct download from the Microsoft download center, and through direct distribution to customers who’ve purchased Microsoft Premier or Alliance Support agreements. Critical fixes might be released as quick-fix engineering (QFE) patches, better known as hotfixes. Hotfixes differ from regular security patches in that they undergo hundreds of hours of testing, not the thousands of hours that go into complete service packs—but if the flaw is dangerous enough, an immediate fix that hasn’t been completely regression-tested is much better than no fix at all.

No matter how you get the fix, you’re still stuck with the task of testing the patch in your environment and deploying it on your systems. However, before you can do that, you must decide which systems need which patches—a process that begins with the risk assessments you should have done after reading Chapter 4, “Threats and Risk Assessment,” and Chapter 5, “Physical and Operational Security.”

Figuring Out What Needs Patching

In a perfect world, there would be no need for security systems or patches—code would be perfectly secure, and no one would ever attack computer systems. The next-best scenario would be to have each system that required a patch alert us that a patch was necessary—sort of like the Check Engine light in your car. Unfortunately, we don’t live in a perfect world, so it’s up to us as administrators to track which systems need to be patched and then get the job done. This can be a huge hassle, especially when dealing with large numbers of machines, but it’s a crucial task. Failing to patch one machine can make the entire network vulnerable! An attacker needs to find only a single weak spot in your defenses to gain entry, so you have to close every entry point for an attack. Fortunately, Microsoft is shipping free tools that reduce this hassle by letting you know what needs to be patched and helping you patch it.

Note

Remember, patching is just the first line of a solid defense in depth. Your defensive strategy should also include components such as strong password policies, firewalls, access controls, and encryption systems. Defense in depth makes things much harder for an attacker, because penetrating one layer of security doesn’t give him or her entry to your whole network.

Stop, Drop, and Bulletin!

It’s tempting to get your security news from mass media outlets—that way, you can find out about new security holes as you check the stock market’s performance and find out which Hollywood stars are abusing which substances. However, you’ll be better off getting your security advisories from a more trustworthy (and technically accurate) source than the New York Times, CNN, the Wall Street Journal, or sites maintained by random Internet publishers (many of whom might amplify rumors or half-facts into full blown controversies) all of which have flubbed security disclosures in the past. What source do I recommend? Microsoft.

The MSRC-produced bulletins are available for free from a number of sources. Microsoft’s bulletin site (http://www.microsoft.com/technet/security/current.asp) is the most authoritative, and it allows you to subscribe to a service that e-mails new bulletins to you as soon as they’re released. A number of reputable security-related mailing lists (including NTbugtraq and Bugtraq) republish and rebroadcast these bulletins, often with commentary providing more detail on the threat level. However, this additional commentary sometimes delays the bulletins’ arrival in your inbox, and the mail-list processing strips off the Pretty Good Privacy (PGP) signature you would normally use to verify the bulletins’ authenticity.

Why am I interrupting the chapter to tell you all this? Because it’s important. Right now, put this book down and go sign up to receive security bulletins through e-mail. Signing up only takes a short time and virtually guarantees you won’t be taken unaware by future problems.

Security bulletins tell you which version of the product needs to be patched (for example, Exchange 2000 with Service Pack 1, Windows 2000 with Service Pack 2, and so on). They generally don’t tell you which specific files or services need fixing, but that isn’t particularly useful information anyway. (If you’re interested in those details, check the associated Microsoft Knowledge Base article released with the patch—that’s where the file-by-file details reside.) You can check the version information for individual dynamic link libraries (DLLs) or executables by opening the file’s properties in Windows Explorer and clicking the Version tab. However, this is about as much fun as eating sand, particularly when you don’t know which files need to be patched—and you won’t! Two better ways to scan systems to ensure they have the right patches are by using the command-line HFNetChk tool and the Microsoft Baseline Security Analyzer (MBSA).

Tip

The easiest way to know which version of Exchange a server is running is to open Exchange System Manager, select the Servers container in the server’s Admin group, and look in the right content pane—the server version will be clearly displayed. For example, a machine running Exchange 2000 SP3 will show up as “Version 6.0 (Build 6249.4; Service Pack 3).”

Using the Microsoft Baseline Security Analyzer (MBSA)

The MBSA is a security scanning and analysis tool that checks for a wide range of vulnerabilities, from configuration mistakes to missing hotfixes and patches. It can scan a single machine or a range of Internet Protocol (IP) addresses (although it can check only machines to which you have administrator access), and it produces a variety of useful reports. Figure 6-1 shows a sample report produced by scanning my Microsoft Windows XP Professional laptop—note that MBSA flagged a hotfix whose presence it couldn’t confirm, but everything else is solid.

6-1 : This machine came out looking like a winner after its MBSA scan.

Note

As of this writing, MBSA is at Version 1.1. Version 1.0 checks the configuration of Microsoft SQL Server 7.0, Microsoft SQL Server 2000, Microsoft Internet Information Server 4.0, Microsoft Internet Information Server 5.0, Microsoft Windows NT 4, Windows 2000, Windows XP, and desktop applications (Microsoft Internet Explorer 5.01 and later versions, Microsoft Office 2000, and Microsoft Office XP). MBSA version 1.1 adds support for scanning Microsoft Exchange 5.5, and Exchange 2000; it also checks for security updates to Microsoft Windows Media Player 6.4 and later.

The scanning and comparison process is driven by an Extensible Markup Language (XML) file, Mssecure.xml, that contains a list of all existing patches. When you launch MBSA, its first task is to see whether there’s a newer version of the XML file available from Microsoft. If so, MBSA downloads it from Microsoft’s public site. Once the most recent patch list has been loaded, MBSA can begin checking for missing security updates. Actually, it checks for five distinct areas:

• Known Windows vulnerabilities These vulnerabilities include the use of file allocation table (FAT) file systems, too many local Administrator accounts, enabled Guest accounts, and so on. Note that this scan is looking for configuration mistakes that lead to vulnerabilities, not the presence or absence of specific patches. As a bonus, the scanner can check for configuration vulnerabilities in Internet Explorer 5.01 and later versions.

• Missing security updates This scan compares the list of hotfixes you should be running (according to the defaults included in Mssecure.xml) to the list of hotfixes actually installed on the target machine. All hotfixes are weighted equally, so a patch to a service you don’t run will still show up with a red X if you don’t install it. You’ll have to perform your own risk assessment to ensure MBSA’s recommendations are appropriate for you. The scanner can scan Windows NT 4 (Service Pack 4 or later), Windows 2000, and Windows XP systems (although the scans of Windows XP Home computers are somewhat more limited than the others). However, it runs only on Windows 2000 and Windows XP.

  How does MBSA know whether a particular patch is installed? It makes that decision based on three factors. The first factor is the registry key that each hotfix adds to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates key. This registry key is enough to indicate whether a particular hotfix has ever been installed, but it doesn’t indicate whether it’s still installed—it’s possible for the updated files to be overwritten after the hotfix is applied. Because hotfixes are sometimes revised after release, MBSA also checks the version of the files installed by the hotfix. As a third check, it computes a checksum of the installed patch and compares it to the corresponding checksum in the patch list. This check prevents an attacker from de-patching a computer by reinstalling an old version of a patched component. If the registry key, checksum, file versions, or file dates of an installed patch don’t match the patch list, MBSA flags the patch as missing.

• Weak account passwords In this context, “weak” refers to passwords that match the user name, a few well-known words (such as “administrator” and “password”), or blank passwords. This quick check is useful, but it’s no substitute for enforcing a strong password policy.

• IIS vulnerabilities This scan checks whether IIS Lockdown has been run on the machine by looking for the configuration files that IIS Lockdown leaves behind, as well as by looking for potential danger points such as the existence of exploitable IIS samples or parent paths. The scanner works against IIS 4 and 5.

  Note

  The Oblt-log.log files are what allow IIS Lockdown to uninstall itself and restore the settings you had in place before it was installed. Removing them means you lose the ability to uninstall, but it also denies an attacker a potential way to learn what security changes you’ve made.

• SQL Server vulnerabilities The SQL scanner checks for common vulnerabilities in SQL Server 7 and SQL Server 2000, including the notorious blank SA password. If there are multiple SQL instances on the server, they’ll all be scanned.

• Exchange Server vulnerabilities The Exchange scanner checks Exchange 5.5 and Exchange 2000 to make sure that they have the correct set of security fixes.

  Note

  Sharp-eyed users will probably notice that there’s no separate checkbox for Exchange scanning. MBSA 1.1 and later do check Exchange for security hotfixes and proper configuration settings, but inexplicably there’s no option in the MBSA GUI to control whether Exchange gets scanned or not: if you run MBSA against an Exchange server, Exchange will be scanned, period.

It’s worth noting a few things that MBSA doesn’t do. First and foremost, MBSA is a read-only tool—it does not configure or change any machine settings during or after a scan. It does not use dictionary lists to detect passwords that could be cracked by brute-force attacks. It only checks for the most commonly occurring vulnerabilities publicly announced by Microsoft. Even though Microsoft has been very diligent about keeping MBSA up to date, new exploits against particular services or configurations won’t be scannable until the Mssecure.xml file is updated, which usually happens when the hotfix that closes the vulnerability becomes available.

Downloading and Installing MBSA

MBSA itself is packaged as a Windows Installer (.msi) file you can obtain from http://www.microsoft.com/technet/security/tools/Tools/MBSAhome.asp. Any user who has the ability to install programs can install MBSA; however, you can scan only the machines on which you have administrative rights, and that includes the local machine. This restriction is an important safety feature; because MBSA can scan IP ranges and domains, you wouldn’t want anyone using it for nefarious purposes.

To install the product, just download the package to your local computer, saving it somewhere that you can find it again. Alternatively, when your Web browser asks whether you want to open or save the file, you can choose to open it to install the package without saving it locally.

Because MBSA is built as a Windows Installer package, you can make it available through Active Directory group policy objects. Doing so allows you to automatically install the tool on multiple computers. This can be useful in circumstances in which you don’t have, and can’t get, administrative access to every machine. Use MBSA in multiple-computer mode to scan machines you do have access to, and then install it locally on the others so that the local administrators can scan for flaws themselves.

Installation is simple: you are presented with a summary page and then the ever- popular end user license agreement page (EULA). Once you’ve agreed to the EULA, you’ll be asked to personalize MBSA with your name and organization, and to choose whether you want MBSA to be available to everyone on the computer or just to the account you’re installing it with. Consider this question carefully. If an attacker actually gets on your machine and can elevates his or her privileges to admin level to run MBSA, he or she might be able to get a list of all of the potential vulnerabilities in your domain—because administrators often configure systems identically (or close to it). This information could be very useful to an attacker. For this reason, we recommend that you restrict MSBA access to essential people only. After indicating your preference, there are a few more pages to click through— including one on which you specify the install location—but they’re so simple there’s no real point in discussing them.

Running MBSA

Once MBSA is installed, you’re ready to run it. MBSA contains both a command- line interface (Mbsacli.exe) and a graphical user interface (GUI; Mbsa.exe). The first time MBSA is launched (using either the shortcuts it installs or by running either of the mentioned executables), it attempts to download the current version of Mssecure.xml over a local Internet connection. It does so by contacting the Microsoft Download Center Web site and downloading a digitally signed .cab file that contains a compressed version of the XML file. After verifying the signature, the .cab file is decompressed and the local copy of the XML file is used until the next time MBSA is launched. Each time you run it, the tool checks the Download Center to see whether a newer version of the XML file is available. This might cause you to see notifications like the one shown in Figure 6-2, indicating that a new version of the .cab file is being downloaded.

Figure 6-2: : If you have good security settings in Internet Explorer, you’ll be notified whenever a signed ActiveX component or .cab file is downloaded.

Note

If your network requires the use of a proxy server, MBSA might not be able to download Mssecure.xml. You can always download it manually from http://download.microsoft.com/download/xml/security/1.0/nt5/en-us/mssecure.cab. If you download the file manually, you’ll need to move it to the MBSA installation folder, which is also where the uncompressed file ends up.

Starting a Scan When you first launch MBSA, you’ll see a window with three choices:

• Scan A Computer allows you to scan a single machine. You can specify its IP address, its machine name, or a combination of its name and the name of the domain it’s in. You can specify a format for the name of the generated scan report. MBSA defaults to a combination of the domain, the machine name, and the scan date. All MBSA reports are stored in the SecurityScans folder in the currently logged-on user’s profile directory.

• Scan More Than One Computer allows you to specify a range of IP addresses to scan, along with a domain. (See Figure 6-3.) MBSA pings each machine in the range you specify. Machines that respond to the ping will be scanned, though of course, non-Windows machines will ignore the scan requests. MBSA can scan up to 20 machines concurrently. Microsoft recommends that for performance reasons you include no more than a few hundred machines in a single scan. As with the one machine scan, you can change the way MBSA generates names for the saved reports. Some customization here can help you keep track of which machines in which domains were scanned. Because all the reports will by default go in your profile directory, you might want to use a script to periodically move them to a safer location so that you can archive and analyze them. (This is an ideal application for the Systems Management Server (SMS) Feature Pack if you’re using SMS.)

  
  Figure 6-3: The MBSA scanning interface is very straightforward.

• View Existing Security Reports allows you to view the results of previous scans. You get a nicely formatted list of scan reports, sorted by computer name, IP address, scan date, or risk level. Each individual report is stored as an XML file in the MBSA installation directory. MBSA displays the reports in a nice-looking format (which is great, because even nontechnical users can scan their machines and get understandable results), but the real win here is that because the files are XML, you can write code to parse them however you like. For example, it would be simple to write a script that would load each file in the directory and parse it, sending you e-mail with a list of all machines that hadn’t been scanned in the last seven days and all machines with any missing hotfixes.

Choosing Scan Options The five check boxes in the Pick A Computer To Scan and Pick Multiple Computers To Scan pages are simple to understand: all they do is implement the scan types I described earlier. If you want to scan a machine for SQL problems, make sure the Check For SQL Vulnerabilities check box is selected, and so on for the other check boxes. Remember, because MBSA checks for weak passwords by attempting to change passwords for each account, the weak password check can take a long time on machines with lots of accounts, such as—domain controllers. That’s no excuse not to run the test, though!

Note

Checking for blank or nonexpiring passwords is really important, which is why MBSA does it. You should run such a scan as soon as you can to flag accounts that might be vulnerable to compromise. After you fix them, scan again to verify the fixes. Once MBSA reports no problem accounts, you can run the other scans without a password test; however, you should still run a password test periodically to catch any infractions.

Editing Services.txt As part of the Windows vulnerability test, MBSA checks for unnecessary services. The goal of this check is to get you to turn off every possible service, because services that aren’t running cannot be compromised (think of this as the “principle of least services”). You can customize the list of services that MBSA checks for. By default, it only includes five services: File Transfer Protocol (FTP), IIS, Simple Mail Transfer Protocol (SMTP), Telnet, and the RAS manager—none of which are necessary on standard member servers. However, the configuration for Exchange will of course be somewhat different, as you’ll need to have IIS running on Exchange servers. More importantly, you can customize Services.txt so that it checks for the proper set of services on front-end Exchange servers. As you’ll learn in Chapter 14, “Securing Outlook Web Access,” front-end servers can get by without many of the conventional Exchange services. That chapter also describes a Services.txt file for scanning front ends.

Using MBSA From the Command Line

MBSA’s scanning has always been based on the HFNetChk engine (a commercial version of that same engine, with several useful added features, is available from Shavlik Technologies, at http://www.shavlik.com). When MBSA was first released, it had some command-line options, but its primary value lay in the fact that it provided a graphical interface, more detailed reporting, and the ability to scan multiple machines. Hfnetchk had many more command-line switches, making it the tool of choice for command-line scanning.

Tip

The Security Operations Guide for Windows 2000 Server contains some useful Hfnetchk scripts that can easily be adapted for use with MBSA 1.1 and Exchange.

With the release of MBSA 1.1, Microsoft has unified the two tools. You can still use MBSA as described above if you want a GUI interface. If you prefer a command- line interface, you get not one, but two choices: you can use the original set of MBSA command-line switches or the ones from Hfnetchk. In either case, you run the Mbsacli.exe tool and specify the options you want. The next two sections describe these switches; the only thing to remember before reading them is that you must include the /hf switch in your command line. This switch tells MBSA that you’re using the old-school Hfnetchk format for your commands.

MBSA Command-Line Switches

Table 6-1 shows the MBSA command-line options. These options simplify the process of using MBSA from the command line, although they don’t eliminate the need for you to understand how to use the command-line interpreter.

Table 6.1: MBSA Command-Line Options

Command-Line Switch	What It Does	Notes
/c domainName\ computerName	Scans the named computer only.	Use this switch to specify a single remote computer to scan.
/d domainName	Scans all computers that are members of domainName.	Use this option to scan all member computers in a domain (provided that the account you’re using has appropriate privileges).
/e	Shows all errors found in the latest scan.
/f "filename"	Redirects MBSA’s output to the specified file.	MBSA will always produce a report file. This switch controls where its progress information goes.
/i ipAddress	Scans the specified IP address.
/l	Lists all reports in the SecurityScans folder of the logged-in user’s profile directory.	Use this option to see which reports are available (and thus when scans were run in the past).
/ld "reportName"	Shows detailed version of the specified report. The detailed version includes descriptions of each reported problem and its meaning.
/lr "reportName"	Shows abbreviated overview of the report named reportName. The overview only summarizes those problems that were found.
/ls	Lists reports associated only with the latest scan.
/n scanType	Skips the specified scan type: Hotfix, IIS, OS, Password, and SQL are valid scan types. These can be concatenated (for example, "/n IIS+SQL" skips SQL and IIS checks on the target machines).
/O "filenameTemplate"	Specifies the format of report file names. You cannot include a path, but you can include static text and the %domain%, %date%, and %computername% variables. (Note that the %date% variable produces reports with slashes in their name, which causes problems for a number of command- line tools and scripts.)	If you’re going to use this option, make sure you use it on all machines so that all reports, domain-wide, follow a common standard.
/qX	Be quiet! /q suppresses all output. /qp hides progress information, /qe suppresses errors, and /qr doesn’t list reports.
/r "startIP – endIP"	Scans all computers in the range between startIP and endIP. Don’t forget the dash between the two addresses!

Using HFNetChk-Style Command Line Switches

HFNetChk has a great set of command-line options that give you somewhat more flexibility than the MBSA-style options. You can use these options by specifying the /hf switch, followed by the switches you want to use. Since the MBSA GUI does a lot of the work for you, don’t be surprised if your HFNetChk-style command lines are longer than the MBSA equivalents.

Choosing Which Machines to Scan The first step to using HFNetChk is telling it which machines you want to scan. You can scan individual machines, lists of machines, or ranges of IP addresses. The options that accept lists require you to create a file with one machine IP address or NetBIOS name per line, with no more than 256 entries in each file. Here’s how to specify which machines get scanned:

• -h hostname—This switch scans the host with the NetBIOS name hostname.

• -fh "hostListPath"—This switch scans the hosts whose NetBIOS names appear in the file specified by hostListPath.

• -i ipAddress—This switch scans the host at the specified IP address.

• -fip "hostListPath"—This switch takes the list of IP addresses in the specified file and scans each machine.

• -r "startIP-endIP"—This switch scans all machines in the inclusive range between startIP and endIP.

• -d domain—This switch scans all member computers in the named domain. You can specify a NetBIOS domain name or a DNS-style name.

• -n—This switch scans all hosts that are visible in Network Neighborhood.

Controlling the Scanner’s Behavior The HFNetChk engine has many switches that can be used to tweak the scan settings. The most useful of these are probably -Z, which suppresses checking the registry of remote machines for hotfix information, and –nosum, which tells HFNetChk not to compute checksums for files it scans.

The –b switch performs a baseline check: it scans for the minimum required set of hotfixes, as described by the MSRC. Using –b is a good way to get a quick read on the security level of a group of machines (for example, your Exchange servers) without taking the time to do a complete scan.

There are some other useful miscellaneous switches, too. The -x dataSource switch specifies a Uniform Resource Locator (URL) or path name for a .cab file or XML file containing the patch list. By default, HFNetChk always fetches the Mssecure.cab file from http://download.microsoft.com/download/xml/security/1.0/NT5/EN-US, but you can override this (perhaps editing the file to include information on patches for installed applications). The –u and –p switches let you specify a username and password to use when connecting to remote machines. If you use –u, you must also specify –p; the program won’t prompt you for a password like net use does.

Finally, you can control the number of concurrent threads used to perform multimachine scans with the –t switch, up to a maximum of 128 (for example, -t 96 bumps the thread count from the default of 64 up to 96).

Controlling Reporting HFNetChk’s reports are much less attractive than those produced by MBSA, but you get more flexibility in customizing them. The first step is understanding the difference between a NOTE message (information that’s nice to know but perhaps not critical) and a WARNING (which means, “fix this or you’ll be sorry”). By default, HFNetChk produces both types of messages. The –s switch takes either 1 or 2 as arguments: -s 1 hides all NOTE messages, and –s 2 hides NOTE and WARNING messages—useful for scans in which you want a simple informational summary of your systems’ state.

The –f switch redirects output to a file that you specify. This switch is obviously useful when running HFNetChk in batch mode. The Pro version of HFNetChk can also produce XML output directly, a useful feature if you want to build scripts or code that processes the reports.

By default, HFNetChk doesn’t explain why it thinks a particular patch is missing or invalid. If you specify the –v switch, which puts HFNetChk in verbose mode, each NOTE or WARNING is accompanied by an explanation of why the patch is tagged as missing. For example, this output explains exactly why a certain hotfix is marked as missing:

Patch NOT Found MS02-008 Q318203 File C:\winnt\system32\msxml3.dll has an invalid checksum and its file version is equal to or less than what is expected.

HFNetChk reports are normally formatted for humans to read; they’re nicely word- wrapped. However, if you’re running the tool to get a set of data that you can process with a macro or script, it’s more useful to be able to get tab-delimited output. The –o switch controls this; -o tab produces tabular output (for each machine, the machine name, security bulletin number, Knowledge Base article number, and reason are listed), whereas –o wrap produces word-wrapped reports.

A Few Useful Examples To get a sense for what you can easily do with HFNetChk, here are a few sample commands to help you get started:

• HFNetChk –b –n does a baseline scan of all the machines your computer can see on the network. Note that because HFNetChk depends on Windows name resolution, it might attempt (and fail) to scan computers that aren’t currently on your network.

• HFNetChk –fip exchServers.txt –b –s 1 –f auditFile.txt takes a list of the IP addresses of your Exchange servers and runs a baseline scan on them, saving the results to auditFile.txt. This would make a terrific scheduled task for you to run against your servers.

• HFNetChk –fh exchServers.txt –u adminAccount –p mySecretPassword –f exchange-08-02- 02.txt scans the specified list of Exchange servers using the administrative account and password, redirecting the results to a file. (Why is this useful? Well, you shouldn’t be logged in as an administrator for ordinary tasks— remember the principle of least privilege!)

Automating Patch Distribution

The topic of how to get patches (or other software, for that matter) distributed to the right place at the right time is worthy of a book on its own. There are several methods available; which ones you use will depend on how many machines you have to manage and how much time you have to manage them.

Tip

Many administrators prefer to install operating system and application service packs on test machines first to see if they cause any problems. This is a sensible approach, and I endorse it—as long as you actively check for problems and move to install the service packs on your production machines within a reasonable timeframe. Most sites test for a maximum of about two weeks, although you can lengthen or shorten the interval depending on your specific site’s needs. Don’t be like the many sites that skipped installing Service Pack 3 for Exchange 5.5 because they were trying to freeze their configurations for Y2K!

The tried-and-true method of patch distribution for small numbers of machines, of course, is just to apply patches manually. As long as you have a small number of servers and are diligent about applying patches when they’re released, this might not be a bad option. However, what happens if you’re on vacation and a critical patch hits the streets? Will anyone else install it? What if you have a patch that has to be installed on every machine on your network? How long will it take to deploy?

The next step up is the Windows Update service that Microsoft offers. On the plus side, Windows Update is easy to use and is supported by Microsoft Windows 98 and later versions. Unfortunately, it still requires users to install things manually. In fact, the wide range of non-patch-related stuff (from Microsoft Windows Media Player to MSN Messenger to various beta versions of Internet Explorer) is often a fatal temptation to users, and might make an administrator’s job more difficult. Windows Update is still quite useful for updating small numbers of machines, as long as you can control who performs the updates and when.

Using the Microsoft Software Update Services

Shortly before the release of Windows 2000 Service Pack 3, Microsoft released the Software Update Services (SUS) package, a radical upgrade to the Windows Update engine. Where Windows Update was originally targeted at individual users of any of the Windows family of operating systems, SUS is targeted squarely at medium- sized corporate and institutional networks that are using Windows 2000, Windows XP, and Microsoft Windows .NET as their base operating systems.

The basic idea behind SUS is that a synchronization server on your network periodically pulls updates from the master Windows Update catalog and makes them available on your internal network. (See Figure 6-4.) As an administrator, you control which updates are copied to the synchronization server and when they’re released to servers and desktops on your network. Those servers and desktops, in turn, can pull updates from your intranet’s SUS server (think of it as your own personal Windows Update machine) on a schedule you specify. For example, you can set a schedule that tells the SUS client on your Exchange servers to automatically download and install any needed updates at 2 a.m. local time each day, rebooting if necessary. If you’re the hands-on type, you could set a policy that would allow the Exchange servers to download the patches so that you could install them yourself.

Note

If you prefer, SUS can be set to automatically install patches. However, you’ll almost certainly be happier, and safer, if you manually install patches on a test server, evaluate their impact, and then push those patches (and only those patches) to your internal SUS server for distribution to your production machines.

Figure 6-4: The SUS server pulls data from Windows Update and makes it available on your intranet, subject to the policies you define.

The complete deployment and installation process for the SUS update servers you’ll need on your network is straightforward but outside the scope of this book. Although you can make your Exchange servers act as SUS distribution points, I don’t recommend doing so. Keep them separate, because both SUS and Exchange are providing security-sensitive services. Configuring the SUS client to receive updates from those servers, however, is simple enough:

1. Update your servers to include the SUS client by installing Windows .NET (any version) or Windows 2000 with Service Pack 3. Windows XP includes the SUS client; for Windows 2000 Professional desktops, installing Service Pack 3 adds the needed components.

2. Decide how you want to configure the clients. SUS includes a group policy template (WUAU.adm) you can use to distribute SUS settings using Active Directory. This method is the simplest and most flexible; it gives you the ability to set different SUS policies for different organizational units (OUs), Active Directory sites, or Active Directory domains. If you prefer, you can create registry subkeys beneath the HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU key.

   • The “Deploying Microsoft Software Update Services” whitepaper (available from http://www.microsoft.com/windows2000/docs/SUS-Deployguide.doc ) describes the registry keys you can use to configure SUS manually.

3. Set your SUS client policies. These policies can include following:

   • Which update server should be used to pull updates. If none is specified or if the specified server can’t be reached, the client will use the public Windows Update site.

   • How updates will be downloaded. You can specify three policies: notify for download and notify for install, download automatically and notify for install, or download automatically and schedule install. These policies do exactly what you’d expect, and nonadministrative users cannot change these options.

Tip

You can use group policy objects to specify that SUS be used, but did you know that there’s already a Group Policy setting that blocks users from using Windows Update? In Windows XP, the Remove Access To Use All Windows Update Features Group Policy setting (located in User Configuration\Administrative Templates\Windows Components\Windows Update) blocks user access to Windows Update. Combine the two to automatically push patches to workstations and servers without giving even local administrators the ability to fool around with Windows Update.

Using Microsoft Systems Management Server

Microsoft Systems Management Server (SMS) is an extremely powerful product usually found in medium-scale to large-scale enterprise networks, where it is normally used to inventory software and operating system configuration and push predefined sets of applications and components to machines based on their role, physical location, or network location. The big difference between SMS and SUS is that the latter is designed only for pushing out critical software updates, whereas the former is a general-purpose tool for distributing arbitrary bits to machines on your network. SMS has some additional capabilities, too: it can target updates to machines based on their IP subnet, group, or (OU) membership, and it understands the concept of Active Directory sites and the links between them, making it useful for large wide area network (WAN) environments with varying kinds, speeds, and latencies of communication links.

Note

The easiest way to distribute security fixes with SMS is to use the SMS Feature Pack. For more information on how to do this and how to configure SMS to push security patches, see the SMS web site at http://www.microsoft.com/smserver/