Patch Management Using Systems Management Server 2003

On This Page

	Overview
	Assess
	Identify
	Evaluate and Plan
	Deploy
	Conclusion

Overview

The Microsoft® Office suite of desktop applications has made a great impact on modern business practice. Improvements to productivity, workflow, communication, and standardization have benefited organizations, groups, and individuals ranging from multinational companies to voluntary associations to freelancers.

To maintain the effective combination of Office features, performance, and flexibility, Microsoft must occasionally issue updates for the Office suite. These updates can include changes that address security issues resulting either from research by Microsoft or from independent analysis. Updates may also improve performance, increase stability, or add new features.

Microsoft Systems Management Server (SMS) 2003 is the premier management tool for enterprise networks, typically for environments of more than 500 clients. SMS 2003 gives administrators extensive facilities for managing Office in large, distributed networks.

This appendix focuses on how to use the software inventory and software distribution features in SMS 2003 Service Pack 1 (SP1) to ensure that all copies of Office within an enterprise have the latest updates.

Documentation Scope

This document covers using SMS 2003 to update the following versions of Office:

This appendix also covers updating components of Office, including:

For this document, Microsoft Office and its components are supported running on the following Microsoft operating systems:

Prerequisites

This appendix should be read in conjunction with the Patch Management Using Systems Management Server 2003 Core Guidance document. Additionally, readers should:

Who Should Read This Appendix

This appendix is intended for readers who are responsible for:

Additionally, anyone interested in understanding how the software update management process applies to Office should find this document useful.

Identifying Key Challenges

To manage software updates to Office, you will use the following four phases of the Microsoft patch management process:

Table 1 summarizes the key challenges for each phase of the software update management process.

Table 1.

The remainder of this document addresses these challenges.

Top of page

Assess

The Assess phase covers determining which computers run Office and whether they require updates. The purpose of the Assess phase is to enable organizations to obtain a better understanding of the Office installations within their environment. The information obtained during the Assess phase becomes the source of consistent and reliable information to be used in all aspects of software update management of Office installations on both desktops and servers. . This phase includes the following activities:

Assessing Microsoft Office Installations

The majority of computers running Office are desktop computers or laptops. However, some servers can also run Office components, such as the Outlook e-mail client for use with Microsoft SQL Server™ e-mail profiles. Each version of Office needs the appropriate updates to stay current, but each version brings a different set of challenges and success criteria. Hence, managing software updates for all the possible implementations requires a complete assessment and a detailed understanding of the Office operating environment.

Discovering Managed Office Installations

The software inventory feature of the SMS 2003 client is key to updating Office and its components. The Office data that the software inventory scan collects is stored in the SMS database. SMS 2003 uses the data in the SMS database to build queries, collections, and reports.

The SMS Administrator console displays all discovered systems on the network. However, these systems may not currently have the SMS client software installed. If there is a business requirement not to install the client, SMS can still scan the systems for software versions, allowing SMS to build software inventories for all discovered systems.

For more information about configuring software inventories on SMS 2003, read the Systems Management Server 2003 Operations Guide at http://www.microsoft.com/technet/prodtechnol/sms/sms2003/opsguide/default.mspx.

Using the Office Inventory Tool for Updates in SMS

The SMS 2003 software update scanning process enables an administrator to add the Office Inventory Tool for Updates and the Security Update Inventory Tool into SMS. The scanning tools can be downloaded from the Systems Management Server 2003 Software Update Scanning Tools Web site at http://www.microsoft.com/smserver/downloads/
2003/featurepacks/suspack/default.asp.

Figure 1 shows the SMS 2003 software updates report for a specific computer. This example report shows all Office software updates that this particular computer requires. The report is built by using the output from the Microsoft Office Inventory Tool for Updates and the Security Update Inventory Tool. Using these reports, an administrator can determine which Office systems require the software update and create collections for these Office systems.

Figure 1. The SMS 2003 Software Update Scanning Tool provides a range of useful information.
See full-sized image

Note   The report in Figure 1 shows updates for multiple versions of Office. This is because Office has been upgraded on this computer, but the registry still records the presence of earlier updates.

Using the Sample Solution to Extend SMS for Discovering Office Installations

The goal of the custom solution accompanying this document is to extend your existing SMS Hardware Inventory (HINV) to enable you to assess your IT environment for various Microsoft Office components installed on Microsoft desktop and server operating systems. The scripts assess the Office components, their installation source paths, the component versions, and installation dates. This information is then reported via the SMS HINV into the SMS database on the site servers. The information collected within the SMS site server databases can then be used to create query-based collections and reports on Office installations at the component level. The collections can then enable customers to target specific Office updates to only the required Office installations, thus improving the overall performance of your updates by reducing the target space.

Some of the key benefits of using the custom solution and the scripts are listed below:

The custom solution extends the SMS 2003 Hardware Inventory by extending the SMS_Def.mof to enable the capture of Office component-level details from SMS-managed client computers via SMS 2003 Hardware Inventory (HINV). The solution links to the SMS 2003 database and schema using custom scripts that collect and report accurately on all Office components installed on the target computer.

For more information on how to use the sample solution, please refer to the User Guide for Sample Scripts to Assess Microsoft Office Installations accompanying this solution accelerator.

For more information about SMS_Def.mof or how to customize hardware inventory collection, see the Configuring Hardware Inventory Rules section in Chapter 2 of the Microsoft Systems Management Server (SMS) 2003 Operations Guide, available at http://www.microsoft.com/technet/prodtechnol/sms/sms2003/opsguide/default.mspx.

After the sample scripts have extended the SMS_Def.mof and the sample solution has been installed, all systems report back information about installations of Office and its components using the SMS 2003 Hardware Inventory. Figure 2 shows SMS Resource Explorer displaying information about the currently installed versions, installation date, source path, and language for Office components.

Figure 2. SMS Resource Explorer showing custom reporting on Office components
See full-sized image

The sample scripts come with a set of Managed Object Format (MOF) files that help you create query-based collections to target deployment of Office updates to specific sets of computers and to create reports within SMS 2003. Figure 3 shows a query that creates a collection for all computers running Microsoft Office 2000 components.

Figure 3. Example of custom query that creates a collection for Office 2000 components

In addition to reporting the Office component-level details via Hardware Inventory, the custom solution also creates a Consolidated Office Installation Compliance report on the SMS Site server, as shown in Figure 4.

Figure 4. The Consolidated Office Installation Compliance report is added by the custom solution accompanying this document.
See full-sized image

The Consolidated Office Installation Compliance report produces a report for all computers running Office components and provides details on the components installed, installation date, versions, installation source path, and so on, as shown in Figure 5.

Figure 5. The Consolidated Office Installation Compliance report provides details about all computers running Office components.
See full-sized image

In addition to the sample MOF files that can be used with the Hardware Inventory data, the custom solution accompanying this document also includes sample MOFs that can be used with SMS 2003 Software Inventory for Office components. For more information on how to use the sample solution, please refer to the User Guide for Sample Scripts to Assess Microsoft Office Installations accompanying this solution accelerator.

Assessing SMS 2003 Unmanaged Computers

Unmanaged computers are those systems that do not have the SMS client installed. There are two approaches for assessing unmanaged systems:

Assessing Software Update Sources

Software updates are released in two forms:

Software updates in the Office environment should ideally come from SMS 2003 distribution points. However, there are certain cases where this is not a viable solution, for example:

Whatever the situation, it is important that the installation source be assessed and identified so that the software update is deployed using the appropriate source and method.

Microsoft Office 2003 provides the ability to locally cache Office source files, thus reducing the need for the source installation media. When users install Office 2003 from the CD or from a compressed CD image on the network, Setup uses a system service named Office Source Engine (Ose.exe) to copy the required installation files to a hidden folder on the local computer. Windows Installer uses this local installation source to install Office, and the local source remains available for repairing, reinstalling, or updating Office later on. Users can install features on demand or run Setup in maintenance mode to add new features.

By default, Setup creates a local installation source in Office 2003, but only when you install Office from the CD or a compressed CD image. If sufficient hard disk space exists on the local computer, Setup caches the entire installation source by default. Maintaining this local installation source after Office 2003 is installed offers a number of benefits to users in large organizations:

A local installation source gives Office 2003 source resiliency. Users can perform maintenance tasks, such as install on demand or detect and repair, without being prompted for their Office CD or a network source. They can also apply binary (client) patches without being prompted for another source—the source is already available locally.

Office 2003 client patches are also resilient. Even if a user runs Detect and Repair to reinstall Office, Windows Installer automatically reapplies any patches, just as it does for users who install Office from an uncompressed administrative image. Patches (.msp files) are not included in the local installation source (/msocache). Instead, Windows Installer renames them and stores them alphanumerically in another location on the local computer.

Note   If a user completely uninstalls and then reinstalls Office, the user must also reapply any patches. This scenario is analogous to a new client installation.

Information on how to create a compressed CD image on the network is available at http://www.microsoft.com/office/ork/
2003/two/ch3/DepC06.htm#sub_1.

Detailed information on how to take advantage of a local installation source in Office 2003 is available at the following link: http://www.microsoft.com/office/ork/2003/two/ch3/DepC06.htm.

Information on all Office updates is available at the Office Admin Update Center at http://www.microsoft.com/office/ork/updates/default.htm.

Assessing Operational Effectiveness

It is essential to assess the operational environment’s ability to deploy software updates in both standard and emergency scenarios. The Core Guidance presents this process in detail, whereas this section covers the specific considerations for Office operating environments.

An Office baseline is a current, documented and tested configuration consisting of the operating system and, the version of Office and its components, together with any programs that communicate with the Office components. An organization can have more than one baseline, but it is vital to keep baseline information current and accurately documented. Without established baselines, it is impossible to predict:

The importance of consistent baselines cannot be overstated. It is difficult to plan, test, or deploy software updates with any level of confidence if server configurations are not consistent.

The assessment process for Office baselines involves verifying that the service baseline process is in place. The change management process should incorporate any alterations to this baseline.

Establishing a Baseline Version

Another key part of keeping all clients up-to-date is to maintain a consistent baseline image of Office throughout the organization, regardless of the particular update strategy you follow. The release version of Office is a baseline, and each successive service pack represents a new baseline because it includes a new version of the product. The baseline image serves as the source for all users: users who are running Setup in maintenance mode, as well as new users who are installing Office for the first time.

To date, Microsoft has released the following baseline versions of Office XP:

These major updates, as well as any future service packs, are cumulative; they include all previous patches plus additional updates and fixes. To avoid creating synchronization problems between the client and the source, you must distribute service pack updates in one of the following ways:

Assessing Vulnerabilities and Security Threats

Security threats and vulnerabilities to Office can cover a range of concerns, such as exposure of confidential information, reductions in productivity, loss of business advantage, loss of data records, or possible regulatory action. As with all key services, there should be a concentrated effort to secure an organization's desktop productivity tools from attackers. Using the Microsoft Solutions Architecture (MSA) defense in-depth strategy is a good way to provide suitable security. For more information on MSA, see the “Introduction to MSA” at http://www.microsoft.com/resources/documentation/msa/edc/
all/solution/en-us/intromsa.mspx.

Vulnerabilities

All complex software products (such as operating systems and applications) exhibit vulnerabilities, which may allow an attacker to gain elevated privileges on a computer, install unauthorized software or perform a denial of service attack. The more popular a software application or operating system becomes, the more likely it is to be the target of an attack, the more effort hackers will expend to discover vulnerabilities, and the more likely it is that an attack will propagate to other computers.

Vulnerability Assessments

A vulnerability assessment must be performed for each system identified in the Assess phase. Although vulnerability assessments for application performance or feature updates may not pose security exposures, they do expose possible vulnerabilities such as the inability to scale or add additional components to Office.

Microsoft has a continuing program that identifies vulnerabilities and releases updates to address these problems. The software update process provides the steps that are necessary to assess vulnerabilities in Office and to identify and deploy the necessary software updates.

Note   Vulnerabilities in the operating system or other applications on the computer may also affect Office functionality.

When performing a vulnerability assessment for a Microsoft Office environment, the following items require consideration:

Security Threats

Security threats can come from a number of sources, including:

This document concentrates mainly on the first two of these threats, because the others are not specific to the Office environment.

Software agents (also called malware) are generally self-replicating programs that seek to damage or hijack computers, operating systems, applications, or data. These agents include:

Many of these agents appear in direct response to published vulnerabilities. Malware components that target databases either destroy data within the database (virus), siphon off information for unauthorized purposes (Trojans), or implement denial of service attacks (worms). Countermeasures for these (and other) threats include timely software updates to Office, locking down servers, controlling Web site access, blocking message attachments at the firewall, and implementing enterprise-wide virus scanning.

Threats can also arise from non-standard configurations, particularly if computers have different versions of Office installed and updates were applied to a later version and not the earlier one. To minimize the threat to an organization’s data, it is therefore critical to have:  

There must be processes in place for monitoring and checking the status of all Office installations on the network and updating security guidance and tools. SMS 2003 SP1 is the main tool to assist in carrying out these checks.

The security threats and vulnerabilities assessment process for Office includes the following guidance sources and tools:

For general security information, see the Microsoft Security Web site at http://www.microsoft.com/security/.

For information about Microsoft Office security, see the Security: Overview Web site at http://www.microsoft.com/office/ork/2003/seven/default.htm.

Top of page

Identify

Successful software updating of Office and its components requires a process that:

Discovering New Updates

Administrators need to know when new updates for Office become available. This process varies and depends on whether the computers running Office are managed by SMS.

Discovering Updates for Managed Systems

On managed systems, there are a number of ways that administrators can receive notification of new Office updates. In addition to the ones described under the Identify section of the Core Guidance document, these include using:

Software Update Scanning Tools in SMS

For managed Office installations, the best way to discover new updates is by using the software update scanning tools (Security Update Inventory Tool and the Microsoft Office Inventory Tool for Updates) to run scheduled security scans and create regular reports in SMS. These tools use the Office Update database to check computers for compliance and automatically download updates to the update database.

For more information about the Office Update database and the update scanning tool, see the Systems Management Server 2003 Software Update Scanning Tools Web site at

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

The operating system can run reports as scheduled tasks or scheduling can be set up as part of SMS Report Viewer. Administrators can use the SMS Web interface to create custom reports based on any attribute and any wildcard value in the SMS inventory database.

For more information about building and scheduling reports in SMS, see Chapter 11, “Creating Reports,” in the Systems Management Server 2003 Operations Guide at

http://www.microsoft.com/resources/documentation/sms/
2003/all/opsguide/en-us/default.mspx.

Microsoft Security Bulletin Web Site

The Microsoft Security Bulletin Web site has a number of tools and resources to assist in implementing effective security on Microsoft products, including the most recent alerts and security updates available from Microsoft.

One of the main tools is a bulletin search service that can locate information about updates to specific products. Figure 6 shows a listing for all issues that affect Microsoft Office.

Figure 6. Listing from the Microsoft Security Bulletin Web site, filtered by product
See full-sized image

For more information, see the Microsoft Security Bulletin Search Web site at http://www.microsoft.com/technet/security/current.aspx.

Obtaining and Verifying Updates

The necessary files for applying updates to Office will need to be obtained from an authoritative source and verified. Microsoft and SMS 2003 are the main sources for such files, but additional sources may be required.

Using Systems Management Server

The SMS 2003 installation includes an option to enable Setup to create SMS SQL Server database devices automatically. This default SMS database includes a database of verified Office updates that should be the authoritative source for updates wherever possible.

Note   If SMS Setup does not create the SLQ Server database devices automatically, note the location of the SQL Server database devices in the CMDB.

There are also cases in which source files are not directly downloaded into SMS. Running the SMS Distribute Software Updates Wizard identifies the unavailable files and provides the opportunity to add them.

There should also be a process in place for obtaining the files manually and then adding the files to an advertised package. You can find software updates from the following locations:

Using Additional Sources

A process should be in place for obtaining verified source files for Office components that are not included in the SMS database. Updates such as Service Pack 1 for Microsoft Office can be obtained from the Microsoft Download Center. Updates from third parties should come only from the original vendor and should be imported into a package only after extensive testing and verification.  

Top of page

Evaluate and Plan

Evaluate and Plan is the third phase in the software update process. This phase covers:

The Evaluate and Plan process increases stakeholder and service owner confidence levels when deploying software updates. The process involves determining the appropriate software updates for the particular version of Office, and planning and testing for business continuity.

Determining Appropriate Responses

Microsoft releases several types of software updates:

Based on the relevance of the software update (as determined by the Identify process) and the software update deployment tools available, the strategies used for updating software vary according to the specific Office component being targeted for patching.

Strategies for Updating Office 2003 Installations

New deployment features in Office 2003 have simplified the process of choosing a patching strategy to two primary options:

Determining which method is best for your organization depends on several factors:

Caching Installation Files Locally and Distributing Binary Updates

When users install Office 2003 from the CD or a compressed CD image, Setup copies installation files to a hidden folder on the local computer. Windows Installer uses this local installation source both to install Office initially and to repair and update Office later on. You can confidently distribute binary client patches because users have the necessary access to the source on their own computers.

Microsoft recommends this update strategy in most cases, particularly if you:

This update strategy has the following requirements:

Installing from a CD Image

To create a compressed CD image, you copy the contents of the Office 2003 CD (including all hidden folders) to a network share; you do not run Setup to create the installation image. After that, the process of customizing a compressed CD image is similar to the process of customizing an administrative installation point. Creation of the local installation source is enabled by default, and you do not need to set any additional local installation source options.

Note   When you create the CD image, the Office 2003 cabinet (CAB) files remain in their compressed state. By contrast, when you create an administrative installation point, Setup extracts compressed CAB files from the Office 2003 CD. Once the files are extracted, Setup can no longer create a local installation source on users’ computers; they must rely on the uncompressed administrative image as a source.

Unlike deploying from an administrative installation point—where the Microsoft Software License Terms and Volume License Key are handled as part of the administrative Setup–you must accept the license terms and enter a valid Volume License Key before users can install Office from the compressed CD image. New functionality has been added to the Custom Installation Wizard to handle these settings by means of a transform (.mst file) applied during the client installation. For more information, click Help on the Configure Local Installation Source page of the Custom Installation Wizard.

Updating Existing Installations

The compressed CD image on the network represents the Office 2003 baseline for your organization, and it remains at the original release (RTM) level. Once you have established this baseline, you can deploy binary updates to individual computers as needed.

You can use a variety of methods to distribute the patches to users, such as the following:

Creating New Installations

When a new client computer installs Office from the compressed image, you must include all current patches to ensure that the user has all the latest updates. Although you can chain as many client patches as necessary to the core Office installation, Office 2003 patches are cumulative, so you only need to install the latest patches related to a particular application to get all the fixes included in earlier patches. The most recent Office 2003 service pack, for example, includes all previously released updates.

You chain client updates to the core Office 2003 installation by adding the appropriate files to the [ChainedInstall_n] sections of the Setup settings file (Setup.ini). You can either chain the .exe file for each individual patch, or you can chain the OHotFix utility to the Office installation and customize OHotFix to include as many patches as you need.

To use the OHotFix utility to chain client patches

To use Windows Installer to chain client patches

What About Full-File Client Updates?

Full-file updates, like binary updates, can be applied directly to client computers. Because full-file updates completely replace all the files affected by the update, they may be the better choice in some scenarios. For example, if a user’s local installation source is corrupted or deleted, and the user does not have access to a source on the network, you can send the full-file update. In most cases, users can apply the patch even if they do not have access to the source and without putting themselves out of sync with the source.

For example, you might be deploying a patch released after Office 2003 Service Pack 2 (SP2) to users who have never updated to Service Pack 1. Because binary patches require the most recent baseline, these users cannot apply the binary version of the update. They can, however, apply the full-file version. Full-file patches support the two most recent baselines.

The methods you use to deploy the full-file and binary forms of client patches to users are the same: an e-mail message, logon script, Microsoft Systems Management Server, or other methods used by your organization. Users simply double-click the .exe file to apply the patch to their local computer. Note that applying a full-file patch to a client computer does not change the product version in the .msi file, as it does when applied to an administrative image. Users can apply full-file patches and binary patches interchangeably.

Updating Clients from a Patched Administrative Image

For organizations that deploy Office 2003 from an administrative installation point, patching the administrative image and recaching and reinstalling Office on clients is usually the most efficient patching strategy. Recaching and reinstalling replaces the previously cached .msi file on users’ computers and overwrites any old files with the newer versions. New clients that install from the patched administrative image automatically get the updated version; you do not need to chain patches to the core installation.

When there is a delay between updating the administrative image and reinstalling Office on clients, however, client computers can become out of sync with the administrative image. Operations that rely on the source—such as install on demand or detect and repair—fail because the client does not recognize the updated administrative image, which has a new product version in the Office .msi file. Relying on this method of updating clients may require you to set up two administrative images: the patched image for updated clients and an unpatched baseline image for everyone else.

Microsoft recommends this updating strategy only if you:

This update strategy has the following requirements:

Patching an Administrative Installation Point

You must install administrative updates (.msp files) from the command line. On the command line, run Windows Installer with options to specify the path to the .msi file and the name and path of the .msp file.

The .msi file is the Windows Installer package file from your original administrative image. The .msp file is the Office administrative update file that contains information about the changes in the upgrade. The update instructs Windows Installer to add, update, or remove files in the administrative image.

Note   Before you update an administrative installation point, make sure that no client computers are using the share. If a file on the share is in use during the upgrade process, a newer version of that file is not copied to the administrative installation point.

To apply an update to an Office administrative installation point

If an update contains multiple .msp files, you must run the command line separately for each .msp file that you apply to the administrative installation point. You cannot reference multiple .msp files on the same command line. Table 2 describes the command-line options.

Table 2.

Updating Client Computers

After you update your administrative installation point, you need to perform a recache and reinstallation on all client computers that use the administrative image as a source. Any new client installations from the administrative installation point automatically include the updated version of Office.

To update an existing client installation from an administrative installation point, users need only rerun Setup.exe on the administrative installation point. If the administrative image has been patched, Setup automatically triggers the recache and reinstallation of all Office 2003 applications and features. Unless Setup is set to run in quiet mode, users are prompted to update.

Alternatively, you can distribute the following command line to the clients:

setup.exe REINSTALL=[list of features

modified by the update] /qb

In this case, Setup.exe calls Windows Installer to perform the installation and automatically generates log files. You can run this command line by creating a logon script, distributing it as a batch file, deploying it by using SMS, or using other means according to your practice. The options for this command line are described in Table 3.

Table 3.

Each update that Microsoft releases includes Knowledge Base documentation listing all the features affected by the update. You can minimize the time and network bandwidth needed to update users’ computers by setting the REINSTALL property to reinstall only the features modified by the update. Note that the values for REINSTALL shown in the feature list are case sensitive.

Applying Client Updates Between Service Packs

As an efficient alternative to recaching and reinstalling Office with every new release of a critical update or security update, you can distribute these interim updates directly to clients, even if they rely on an administrative image as a source. You must first have established all users on the most recent baseline of Office 2003.

For example, you may have updated your administrative image to Office 2003 Service Pack 1 (SP1) and reinstalled Office throughout the organization. Shortly thereafter, Microsoft releases a security update in response to a new virus. You can download the patch and run the .exe file directly on client computers. In this scenario, you would not patch your administrative image—that would put clients out of sync with the patched source. You can continue with this strategy until the next service pack is released.

Note that you cannot use the same tactic to deploy service packs themselves. The client versions of service packs require a source at the original release level—such as an unpatched administrative image or a local installation source.

Strategies for Updating Office XP

The goal of an update strategy for updating Office XP is to ensure that all users have the most up-to-date software, including critical security patches, while keeping them synchronized with the source for installing on demand or repairing or updating the applications. The strategy you choose for updating Office XP on users’ computers depends on a number of factors, including the current state of your administrative installation point, your network resources, and the amount of control you have over users’ desktop configurations.

Note   Some Office XP updates are released as Internet Express (IExpress) packages. Unlike most Office XP software updates, these .exe files do not contain .msp files and are not released in an administrative form. They must be run directly on client computers. For more information, see the Installing Internet Express Software Update Packages white paper at http://www.microsoft.com/office/ork/updates/nonmsp.htm.

Table 4 summarizes the recommended patching strategies for Office XP.

Table 4.

You can find detailed instructions for maintaining an administrative image and distributing client updates directly to users in the Distributing Office XP Client Updates to Users white paper at http://www.microsoft.com/office/ork/updates/oxpclientup.htm.

If you plan to manage software updates centrally from an updated administrative image, you can find more information in the Updating Clients from a Patched Administrative Image white paper at http://www.microsoft.com/office/ork/
updates/oxppatchadmin.htm.

Strategies for Updating Office 2000

A key part of keeping all clients up-to-date is to maintain a consistent baseline image of Office throughout the organization, regardless of the particular update strategy you follow. In most cases, a new service pack represents a new baseline because it includes a new product version in the Office .msi file. The baseline image serves as the source for all users—users who are running Setup in maintenance mode, as well as new users who are installing Office for the first time.

Microsoft has released the following baseline versions of Office 2000:

These major updates are cumulative: they include all previous patches plus additional updates and fixes. To avoid creating synchronization problems between the client and the source, you must distribute service pack updates in one of the following ways:

The strategy you choose for updating Office 2000 on users’ computers depends on a number of factors, including the current state of your administrative installation point, your network resources, and the amount of control you have over users’ desktop configurations.

Table 5 summarizes the recommended patching strategies for Office 2000.

Table 5.

You can find detailed instructions for maintaining an administrative image and distributing client updates directly to users in the Distributing Office 2000 Client Updates to Users white paper at http://www.microsoft.com/office/ork/updates/o2kclientup.htm.

If you plan to manage software updates centrally from an updated administrative image, you can find more information in the Updating Office 2000 Clients from a Patched Administrative Image white paper at http://www.microsoft.com/office/ork/updates/o2kpatchadmin.htm.

Considerations for Creating SMS Collections

SMS 2003 collections are useful for assigning computers running Office to the correct deployment group. After SMS 2003 collections have been created and the computers running Office assigned to the correct collections, packages containing the correct software updates can be assigned to each collection by using advertisements. Some examples of collection criteria include:

For more information about using SMS 2003 as the release mechanism and creating SMS 2003 Collections, see the Core Guidance accompanying this solution accelerator.

Planning and Testing for Business Continuity

Microsoft Office and its components provide a core business service to many organizations. Hence, it is imperative to reduce all risks to the minimum possible level when implementing a software update. It is neither economical nor feasible to duplicate every variable of a production environment in a test laboratory. Therefore, complete testing of all software update outcomes is not realistic. However, it is possible to achieve complete confidence that Office data is protected during the update and that service interruptions will be minimal. Table 6 lists items for consideration when planning and testing business continuity.

Table 6.

Although rollbacks of Office present issues due to product limitations, there still needs to be a clear path back to the last known good state. The recommended procedure is to:

Top of page

Deploy

The Deploy phase is the fourth and final phase of the software update process and includes the following activities:

Preparing for Deployment

The Deploy phase starts after all stakeholders have accepted the deployment plan, which was created during the Evaluate and Plan phase. (See the Core Guidance for information about creating the deployment plan.) This plan must now be followed without improvisation or changes to deployment processes or procedures. The plan should also include risk mitigation strategies for any issues that may arise during deployment. The deployment plan should include the steps to prepare the environment for software update deployments and should include detailed information that is specific to the software update being deployed, such as:

In addition to the notice given to key stakeholders and service owners, it is necessary to inform users, administrators, and connected services owners if a service interruption is expected. These groups should be identified in the CMDB or through a distribution list that the service owners or key stakeholders create.

To prepare for rolling out the updates into the production environment:

After all these issues are successfully resolved, the deployment can start.

Using SMS to Deploy Updates

SMS is the preferred method for deploying updates to Microsoft Office. The deployment should follow the developed software update deployment plan. Specific processes and steps will differ, depending on the characteristics of the Office operational environment.

Deploying to Managed Systems

Deployments using SMS 2003 will target the collections that were created in the Assess phase. If a phased approach is required, the deployment plan should use SMS 2003 collections and specify the order in which the software update will be deployed.

Refer to the Core Guidance and the Systems Management Server 2003 Operations Guide for detailed procedures on using SMS 2003 collections, assigning SMS 2003 packages and advertisements to collections, and strategies for deploying software updates using SMS 2003. The Systems Management Server 2003 Operations Guide is available at http://www.microsoft.com/resources/documentation/sms/
2003/all/opsguide/en-us/default.mspx.

Creating SMS Collections

The SMS Collections feature enables the creation of groups that contain all computers running any version of the Office or its components. Collections provide the administrator with logically sorted groups and sub-groups of computers in which members of the collection all comply with specified criteria.

SMS collections might include:

SMS collections can use other criteria, such as mapping the Office version to the operating system type. SMS collections can then form the basis for specific reports or assist with deploying software updates.

Creating SMS collections requires an understanding of SQL queries. Figure 7 shows the SQL query to create a collection consisting of computers running Office 2000 or its components.

Note   The solution provides custom .mof files that can be imported into SMS. These files will automatically create SMS collections based on the component version. Please see the User Guide for Sample Scripts to Assess Microsoft Office Installations for additional information.

Figure 7. A query-based collection using the MSOFFICE2000Data values to identify computers running Office 2000

For more information about creating SMS collections, see the Patch Management Using Systems Management Server 2003 Core Guidance document or the Using SMS for Change and Configuration Management section of the Microsoft Systems Management Server Operations Guide at http://www.microsoft.com/resources/documentation/sms/
2003/all/opsguide/en-us/sms_5msj.mspx.

For more information about SQL queries, see the Microsoft SQL Server 2000 Administrator's Pocket Consultant, available from Microsoft Press, at http://www.microsoft.com/mspress/books/4660.asp or any other Microsoft SQL Server resource.

Deploying to Unmanaged Systems

Because SMS 2003 cannot deploy software updates to unmanaged systems, a different approach must be followed to reach systems not managed by SMS. For successful deployments to these systems, it is imperative to create a deployment plan that accounts for such systems and then follow the deployment plan and not improvise in the middle of the deployment. If issues arise in the deployment process, there should be a quick analysis of the issues to determine if the deployment is in jeopardy or if these issues can be fixed without retesting the deployment.

Examples of technologies that can be used for custom deployments to SMS-unmanaged systems include:

Implementing Post-Deployment Checks

Verifying the successful deployment of software updates is an important part of the deployment process. If updates fail to deploy, the Office environment may be left open to security vulnerabilities. Additionally, computer baselines will not be consistent or compliant, which can lead to vulnerabilities and system instabilities.

The reporting tool in SMS 2003 is a vital part of the deployment process because the reports the tool generates help identify software update deployment issues that must be addressed. SMS 2003 reports enable administrators to identify:

For more information about verifying software update deployments using SMS 2003 reports, see the Core Guidance.

Note   The solution provides custom .mof files that can be imported into SMS. These files will automatically create custom reports that will assist with the compliance checking of Office component levels. Please see the User Guide for Sample Scripts to Assess Microsoft Office Installations for additional information.

Top of page

Conclusion

Microsoft Office and its components provide vital desktop productivity applications for many organizations, so keeping Microsoft Office patched against security vulnerabilities is a primary concern. SMS 2003 is a powerful tool for assisting in the process of implementing software updates on Office 2000, Office XP, and Office 2003. Using SMS according to the procedures in this appendix should improve efficiency, reduce risk, and help ensure the successful deployment of software updates to installations of Microsoft Office.

Top of page

8 of 8