Hotfix and Service Packs Management

The process of keeping your computers up-to-date with the latest fixes has always been somewhat difficult. Microsoft actually offers different types of fixes, which many administrators choose to deal with in different ways:

• Hotfixes? Also called quick-fix engineering (QFE) or simply updates, these offer fixes for bugs and other anomalous conditions. Generally, these fixes aren't fully regression-tested, which means they haven't been subjected to an extensive beta-testing process to ensure full compatibility with all operating environments. Microsoft usually recommends that you apply a hotfix only if you're experiencing the specific problem the hotfix corrects.

  Note Microsoft doesn't usually make hotfixes as easily available as other updates. Hotfixes that correct common problems are often available for download from Microsoft's Web site but aren't often included in Windows Update (which we'll discuss momentarily). Many additional hotfixes are available only from Microsoft's Product Support Services (PSS), after Microsoft determines that the hotfix will correct a problem you're experiencing.

• Security hotfixes? Now called security updates, these correct specific security flaws in Windows. Because they address security issues, these updates are almost always considered critical and Microsoft recommends that they be deployed to all your computers as rapidly as possible. These updates are generally available from Windows Update (and are, in fact, listed in the "Critical Updates" section of Windows Update). Deploying these fixes has been a major nightmare for most organizations: Unfortunately, Microsoft has had to release a lot of these for Windows 2000 and Windows XP, and hasn't?until recently?offered great tools to make the deployment process easy and automatic.

• Service packs? These are collections of hotfixes, security updates, new features, and other product improvements that are released periodically. Service packs go through a complete beta-testing process, making them more stable than individual hotfixes. Service packs are cumulative, which means they contain all fixes from prior service packs, hotfixes, and security updates.

Managing these updates involves two distinct tasks: Deploying updates and inventorying updates. Windows Server 2003 includes tools that assist with both tasks.

Software Update Services

You can think of SUS as a corporate internal version of Windows Update, Microsoft's Web-based application for software update management. In fact, SUS was originally named Windows Corporate Update, reflecting its Windows Update origins.

To learn more about Windows Update and how it works, visit www.samspublishing.com and enter this book's ISBN number (no hyphens or parentheses) in the Search field; then click the book's cover image to access the book details page. Click the Web Resources link in the More Information section, and locate article ID# A011402.

Windows Update enables users to easily check for updates to their operating systems, download the updates, and install them automatically. Unfortunately, Windows Update has several major drawbacks in a corporate environment:

• Most updates require users to be administrators of their computers? That was fine on Windows 98 (where Windows Update debuted), which had no concept for administrative privileges. However, in Windows 2000 and Windows XP, administrative privileges aren't usually provided to end users, making Windows Update less useful.

• Windows Update provides a one-on-one update service? This means each computer must connect to the Windows Update Web site individually to retrieve updates. In organizations with hundreds or thousands of computers, this technique is inefficient and unreliable. It's mainly a waste of Internet bandwidth because each computer must individually download the same updates.

• Windows Update isn't automatic? Windows XP did introduce a new feature called Automatic Updates (which was released for Windows 2000 in Service Pack 3); this feature automatically checks for updates, downloads them, and asks for permission to apply them.

Windows Update also includes the Windows Update Catalog, which allows administrators to access the entire update library. Using the Catalog, administrators can download individual updates for any operating system. Unfortunately, there is no tool to easily distribute the downloaded updates.

SUS is designed to fix all of that. Essentially, SUS is your very own version of Windows Update, which you install on one or more servers within your environment. Each SUS server can be configured to download updates from Windows Update (which serves as the central worldwide source for updates) or from another SUS server. Client computers and other servers running the Automatic Updates client (also referred to as the SUS client) can be directed to a SUS server for their updates. This architecture allows you to create your own internal, distributed update infrastructure, such as the one shown in Figure 14.1.

SUS is available as a free download from Microsoft's Web site. It can be installed on any Windows 2000 Server or Windows Server 2003 computer, except domain controllers. During the installation, you specify where you want downloaded updates to be saved, as shown in Figure 14.2. Updates can be saved to a local folder, or they can be retained on the Windows Update server. Generally, you'll store updates locally; if you leave them on Windows Update, each client will have to use your Internet bandwidth to download its updates.

After you install SUS, you configure its synchronization schedule. To do so, click the Synchronize item in the left menu bar and then click the Schedule button. The dialog box shown in Figure 14.3 appears, allowing you to tell SUS when to download recent updates from the Windows Update servers. We recommend a weekly synchronization during idle hours, such as Sunday mornings at 3 a.m.

Keep in mind that you can change SUS's operating options at any time by clicking the Options menu item. As shown in Figure 14.4, you can choose to store updates locally, automatically approve new versions of updates, and select the languages supported in your environment. (You'll read more about automatically approving new versions of updates a little later.) Language support is useful in large, multinational corporations because it allows SUS to maintain updates in multiple languages, supporting all of a corporation's users.

Because your first SUS synchronization can take several hours, you might want to start it manually, so that you can keep an eye on it as it downloads the available updates. Simply click the Synchronize button to start the synchronization process and, as shown in Figure 14.5, SUS will display progress bars indicating how it's doing. As we've mentioned, your first synchronization will include every available update for the products SUS supports: Internet Explorer 5.0x, Internet Explorer 5.5x, Internet Explorer 6.x, Windows 2000, Windows XP, and Windows Server 2003.

Microsoft recognizes that not all organizations will want to deploy every single update to their computers. For example, one of the updates available for Windows XP is the Windows Movie Maker, which probably isn't a major line-of-business application for most companies. To give administrators maximum control, SUS doesn't make any of its updates available to your network until you approve them. To approve updates, click the Approve Updates menu item. You'll see a list of all updates, as shown in Figure 14.6.

The list of updates includes several pieces of valuable information:

• The name of the update and the date on which it was released.

• The size of the update.

• Whether the installation of the update requires a reboot.

• The operating systems to which the update applies. Note that SUS doesn't support Windows NT or Windows 9x operating systems; only Windows 2000 and higher are supported.

• The language of the update. If you're downloading multiple languages, you'll find each update listed multiple times?once for each language you support.

• A brief description of the update. A Details link pops up a new window with a more complete description of the update.

After you approve an update, it becomes available to clients running Automatic Updates. Where do your computers get Automatic Updates? A version of it is included with Windows XP, but that's not the latest version and it isn't SUS compatible. The correct version can come from several places:

• You can manually install the client by using the Windows Installer package you download from the Windows Web site.

• Any Windows XP computers that have been using the built-in Automatic Update have probably already downloaded and installed the new version.

• Windows 2000 Service Pack 3 contains the new version of Automatic Updates.

• Windows XP Service Pack 1 contains the new version of Automatic Updates.

• All editions of Windows Server 2003 ship with the correct version of Automatic Updates.

Administrators can use group policies to centrally configure Automatic Updates within a domain; doing so enables you to create a consistent update configuration for all computers in a domain. You can also manually configure Automatic Updates on each computer. On Windows XP and Windows Server 2003, right-click My Computer and select Properties from the pop-up menu. Locate the Automatic Updates tab, shown in Figure 14.7, and select the desired update option.

It's important to remember that Automatic Updates is configured by default to use only the Windows Update Web site to obtain updates. If you've deployed SUS on your network, you must reconfigure Automatic Updates on your client computers to use your SUS server. This configuration must come from a centralized group policy, which means your computers must all belong to a Windows 2000 or Windows Server 2003 Active Directory domain.

Automatic Updates uses new group policy settings that aren't included in Windows 2000 domains by default. The new settings are specified in the WUAU.adm file, which is added to the %windir%\inf folder when you install Automatic Updates. To create a group policy object (GPO) that configures Automatic Updates, first install the newest Automatic Updates client on an administrative workstation (any Windows 2000 or Windows XP computer with Active Directory Users and Computers installed). Then, follow these steps:

The Automatic Updates client runs at all times, even when no user is logged on to the computer. If you've configured the client to automatically download and install updates, its behavior is as follows:

• If no user is logged on, updates are automatically installed. If a restart is required, the computer is automatically restarted.

• If an administrator is logged on, updates are automatically installed. If a restart is required, a warning is displayed before installation begins, giving the administrator time to shut down any critical processes. Administrators can cancel the update, which will remain pending. The update will automatically apply at a later time, even if cancelled.

• If a non-administrative user is logged on, a countdown is displayed before updates are automatically installed. If a restart is required, the computer is automatically restarted. The countdown is designed to give users time to shut down their applications without allowing them to interrupt the update process.

You should be aware of how Automatic Updates functions when configured via group policy, and when other group policies exist that define Windows Update behavior:

• If you've enabled the Remove Access to Use All Windows Update Features policy setting, Automatic Updates continues to function but displays no notices to logged-on users. This policy setting is available only on Windows XP.

• If you've enabled the Remove Links and Access to Windows Update policy setting, Automatic Updates continues to operate if configured to download updates from an intranet SUS server. If you don't enable this policy, users can still manually access Windows Update. We recommend enabling this policy in conjunction with SUS to ensure that users' computers obtain updates only from your SUS server or servers.

After your clients are configured, they'll contact your SUS server according to the schedule you set. If you've configured them to automatically download and install updates and configured your SUS server(s) to automatically download new updates, you'll have an almost hands-off system for managing software updates in your environment. The only regular task you'll need to perform is approving new updates for deployment to your clients.

Managing and Monitoring Updates

SUS provides two tools for managing and monitoring updates: the Approval Log and the Monitor Server link. Both are accessible as menu items from the main SUS administration screen. The Approval Log, shown in Figure 14.8, simply lists the approval actions that have been taken on the server. This log enables you to review which updates might have been approved by other administrators, and it can be useful when troubleshooting problems with package deployment. The Monitor Server page, shown in Figure 14.9, displays a summary of updates available from your SUS server broken down by operating system or product. Clicking a product name displays a complete list of packages, including their globally unique identifiers (GUIDs), file sizes, and other information.

Inventorying Updates

Sadly, Microsoft has provided better free tools for deploying updates than for finding out which ones have already been deployed. Unfortunately, SUS is designed only to make updates available; it can't force client computers to download updates unless they're properly configured, and SUS can't help you determine whether all your clients have successfully downloaded and applied a particular update. Microsoft SMS can do all of these things, but it represents a significant additional investment in both time and money.

The best you can do for free is a downloadable tool from Microsoft called Hfnetchk.exe. This tool, combined with an XML-based database, is designed to check for the presence and proper installation of Microsoft security updates. The tool can be run against remote computers, providing a rudimentary centralized update inventory. Unfortunately, the tool is designed for use only with security updates, not other hotfixes, and not for service packs in general (although the tool does properly detect security updates installed as part of a service pack).

After Hfnetchk is installed, you execute it from a command line. For example, running Hfnetchk -v -z -s 1 produces a basic output. The tool is primarily designed to list security updates that are defined in its database but not found on the system that the tool is scanning. The -v switch provides specific details about why an update wasn't found; reasons can range from missing files or Registry keys to incorrect configuration settings on the computer. Hfnetchk always provides a reference to a Microsoft Security Bulletin or Knowledge Base article that provides instructions on how to obtain and properly install each update.

You can have Hfnetchk scan multiple remote computers simultaneously by using the -h switch: hfnetchk -h computer1, computer2, computer3. Alternatively, you can use the -fh switch to point to a text file containing a computer name on each line of the file. For example, hfnetchk -fh computers.txt opens a text file named Computers.txt, looks for one computer name on each line of the file, and scans those computers for security updates.

Other Hfnetchk options include

• -I ipaddress, ipaddress? This option specifies IP addresses rather than hostnames and attempts to scan the computer using each IP address provided.

• -fip? Works similarly to the -fh option, pointing to a text file of IP addresses rather than computer names.

• -r? Specifies a range of IP addresses to scan and can be useful when you want to scan an entire subnet.

• -d? Specifies an entire Active Directory or Windows NT domain to scan.

• -n? Scans all computers on the network. Both this switch and the -d switch rely on the Network Neighborhood to obtain a computer list. Unfortunately, Network Neighborhood isn't the most reliable directory of your network, so you might have greater success using an IP address range of a file of computer names.

• -x? Specifies the XML database to use during the scan. This can be an XML filename, a compressed XML in a cab file, or a URL. If not specified, Hfnetchk defaults to using the Mssecure.cab file located on the Microsoft Web site.

• -s? Suppresses specific messages. -s 1 suppresses "Note" messages, whereas -s 2 suppresses both "Note" and "Warning" messages.

• -v? Lists the reason a particular update was not considered installed, which can help you find out exactly how to go about installing it.

• -f? Outputs Hfnetchk's results to a file, which may be easier to review than scrolling through the command-line output.

• -u and -p? Allow you to specify an alternate username and password to use during the scan. For example, you may want to specify a domain user account that has local Administrator privileges on all computers that will be scanned. Don't include this switch if you're using Hfnetchk in a batch file; doing so would expose a powerful user account's password to anyone with access to the batch file.

Microsoft contends that SMS is the ideal method to inventory and manage software updates, including security updates. We feel that this position is unreasonable; asking customers to purchase an entirely separate product to support their base operating systems is asking too much. SUS is a huge step in the right direction, providing in-house automatic updates for service packs and other critical updates. Some equivalent for inventorying updates?and automatically deploying missing ones, perhaps?is necessary, and we hope that Microsoft will provide such a tool in the future at no additional charge.