Using SMS 2.0 to Deploy Microsoft Office XP

  • Article
Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Scalable Management for Windows Based Systems

Abstract

A systematic approach for deploying Microsoft Office XP with Systems Management Server 2.0.

On This Page

Introduction
Important Concepts and Issues
Deploying Office XP in an Enterprise
Maintaining and Updating Your Office XP Installation
Appendix A: Using Resilient Sources
Appendix B: How to Inventory Office XP
Appendix C: Frequently Asked Questions

Introduction

Microsoft Office XP is a suite of business products that includes word processing, spreadsheets, presentation software, and other programs that are useful in a business setting. Microsoft Systems Management Server (SMS) version 2.0 is an enterprise management tool that you can use to deploy and maintain Office XP in your organization. There is a question and answer section for deployment details and related material at the end of this white paper.

This white paper supplements the Office XP documentation and the SMS 2.0 software distribution documentation by providing information specifically targeted at deploying Office XP to SMS 2.0 clients in your organization.

This white paper describes:

  • Advantages of using SMS 2.0 to deploy Office XP.

  • Issues to consider before deploying Office XP.

  • Planning considerations and security issues, such as permissions required to properly install Office XP.

  • Guidelines for using SMS 2.0 to deploy Office XP in an enterprise environment.

  • Customizing your Office XP installation.

Advantages

SMS can be used to reduce the cost and the time required to deploy Office XP. Some reasons you might want to use SMS 2.0 to deploy Office XP in your organization are:

  • To scale successful deployments from your test lab, to pilot users, through verification and finally throughout your enterprise.

  • To deliver and complete the installation during off hours to reduce the effect on your users.

  • To coordinate upgrades across multiple sites.

  • To manage slow links between sites.

    • SMS 2.0 provides administrators with the ability to compress package sizes, which minimizes the bandwidth usage.

    • SMS 2.0 allows administrators to throttle and schedule bandwidth usage so that SMS reduces its concurrent network usage.

  • To deploy Office XP to a large number of clients.

  • To force the installation of Office XP on client computers.

  • To take advantage of status reporting and troubleshooting tools.

  • To deploy Office XP to different types of clients that are running Windows operating systems, such as Microsoft Windows XP Professional, Microsoft Windows 98, Microsoft Windows Millennium Edition, Microsoft Windows NT® Workstation 4.0, and Microsoft Windows 2000 Professional.

Other advantages of using SMS 2.0 are:

  • SMS administrators can verify a pilot deployment of Office XP, and then expand the collection targeted with Office XP to effectively scale a deployment that meets corporate requirements.

  • You can use the SMS administrative context to deploy Office XP to computers where users do not have administrative rights on the local computer.

  • You can use SMS reporting through the status message system on delivery and execution.

  • You can create SMS collections in order to install Office XP only to computers that meet your corporate standards, and then install to the remaining computers when they meet the requirements. For example, a corporation might determine that only systems with at least 64 MB of RAM should upgrade to Office XP. As RAM is upgraded, these computers become part of the dynamic collection of computers with 64 MB of RAM, and then they install Office XP.

Assumptions

This white paper is targeted at SMS administrators. Before you attempt to use SMS 2.0 to deploy Office XP, verify that:

  • You are familiar with Office XP and SMS 2.0.

  • You are familiar with SMS 2.0 administration and software deployment. If not, see the Microsoft Systems Management Server 2.0 Administrators Guide and other SMS 2.0 documentation.

  • SMS 2.0 Service Pack 2 (SP2) or later is deployed in your organization. SMS 2.0 SP2 is required to deploy Office XP. Microsoft does not support the use of SMS version 1.2 to install Office XP. For information about upgrading SMS, refer to the Systems Management Server Web site at https://www.microsoft.com/smserver/default.asp

  • You are familiar with the Microsoft Office XP Resource Kit. The administrator should be very familiar with the Office Profile Wizard and the Custom Installation Wizard in Office XP. These topics and others are covered in the Microsoft Office XP Resource Kit at https://www.microsoft.com/office/ork/xp/default.htm

  • You have a test organization or test lab that verifies the results prior to deploying Office XP in your production environment.

Office XP Operating System Requirements

The following table lists operating system support for Office XP.

Operating System

Supports Office XP

Windows XP Professional

Yes

Windows 2000 Server

Yes

Windows 2000 Professional

Yes

Windows Millennium Edition

Yes

Windows 98

Yes

Windows NT Server 4.0 SP6a or later

Yes

Windows NT Workstation 4.0 SP6a or later

Yes

Windows NT Server 4.0 SP6 or earlier

No

Windows NT Workstation 4.0 SP6 or earlier

No

Windows 3.1

No

Windows NT Server 3.51

No

Windows NT Workstation 3.51

No

Windows 95

No

If your clients are currently running any unsupported operating systems, you must upgrade the client to a supported operating system before installing Office XP. Alternatively, you can exclude from your Office XP deployment the computers that are running unsupported operating systems.

The approximate minimum hardware requirements for Office XP are:

  • Pentium 133 or higher, PIII recommended

  • 32 MB RAM, plus 8 MB additional per open application (128 MB is recommended), and 128 MB required for speech functionality

  • 280 MB disk space for a restricted, minimum installation, but at least 600 MB is recommended

For detailed information about system and disk requirements, refer to the system requirements at

https://www.microsoft.com/office/previous/xp/sysreqs.asp

Where to Go for More Help

For complete information about Office XP or about SMS 2.0, see the following sources:

Important Concepts and Issues

This section is an overview of the technology issues related to Office XP deployment with SMS, including:

  • Package definition files

  • System Files Update (SFU)

  • Multilingual User Interface Packs

  • Windows Installer versions

  • Windows Installer transform files (.mst)

  • Windows Installer patches

  • How Office XP uses patches

  • Using the Windows Installer Install on Demand feature

  • Windows NT Workstation 4.0 Low Rights installation issues

  • Using the SMS administrative rights installation context

  • Office Resource Kit Tools

Package Definition Files

A package definition file (.sms) is a template that contains the SMS components necessary to create and distribute software. SMS 2.0 uses SMS packages to distribute software such as Office XP.

Office 2000 included a unique package definition file for every Office 2000 suite. Now, Office XP includes two main package definition files that you can use as a template to install any combination of Office XP suites. These files are updated as improvements are made. You can obtain the most recent package definition files from

https://www.microsoft.com/Office/ORK/xp/JOURN/PDFWinXP.htm

In Office XP, package definition file files have .sms extensions, and contain one .sms file for Office XP and one .sms file for Office XP multi-language deployments.

File name

Description

Off2002.sms

For all Office XP product suites

Lpk2002.sms

For the Office XP Multilingual User Interface Packs.

The package definition file files are included in the Ork.cab file in the Office XP CD. To access the package definition file files, install the Office XP Resource Kit, which is included in the ORK folder of the Office XP CD. You can also download the most recent package definition file files from the Office XP Resource Kit Toolbox on the Microsoft Office Web site at

https://www.microsoft.com/office/ork/xp/default.htm

System Files Update

Office XP requires a specific version level of a set of dynamic-link library (.dll) files and other shared and system files. Before installing Office XP on computers running Windows NT Server 4.0 SP6a, Windows NT Workstation 4.0 SP6a, and Windows 98, Setup verifies that these key system files are current. If they are not, Setup updates the necessary files by running the System Files Update (SFU).

Key system files and components in the SFU include the following:

  • Internet Explorer 5.01

  • HTML Help

  • Microsoft Data Access Components 2.5

  • Microsoft Visual Basic for Applications Runtime

  • Microsoft Visual C Runtime

  • Microsoft Foundation Class 4.2

By default, SFU installs Internet Explorer 5.01 on clients running Windows 98, Windows NT Server 4.0 SP6a, or Windows NT Workstation 4.0 SP6a. If you do not want to install Internet Explorer 5.01 on these clients, you can turn off the default Internet Explorer installation by using the Custom Installation Wizard. For information about the Custom Installation Wizard, see Customizing Your Office XP Installation later in this white paper, or see the Office XP Resource Kit at

https://www.microsoft.com/office/ork/xp/default.htm

Note the following:

  • Whenever SFU is run on a computer, a restart is required, even if no files were updated.

  • Office XP does not install Internet Explorer on clients that are running Windows 2000 Professional, Windows 2000 Server, Windows Millennium Edition, or later operating system versions, because Internet Explorer 5.01 is already included with these operating systems.

  • Office 2000 Public Update 1 (and above) includes SFU, and therefore upgrades from this version to Office XP do not have SFU issues.

Multilingual User Interface Packs

The Multilingual User Interface Pack (MUI Pack) provides plug-in language capability in Office XP and flexibility in customizing and installing the language files your organization needs. For example, you can customize Office XP to install with MUI Pack files by chaining your installation, or you can customize and install language files after deploying Office XP.

For additional information about Office XP MUI Packs files, see the section on deploying Office XP internationally in the Office XP Resource Kit.

Windows Installer Versions

Several different versions of Microsoft Installer are currently in use. The following is a list of the different versions and their delivery vehicles.

Windows Installer Version

Availability

Windows Installer 1.0

Included with Office 2000

Windows Installer 1.1

Included with Windows 2000 Server and Windows 2000 Professional

Windows Installer version 2.0

Included with Windows XP Professional. Also provided as a separate installable component from Microsoft.com for earlier versions of the operating systems.

Office XP requires Windows Installer 1.1 or later. If Windows Installer 1.0 is present on the computer, Office XP Setup automatically updates the program. If Windows Installer is not present on the computer, Office XP Setup calls Instmsi.exe (Windows 98) or Instmsiw.exe (Windows NT 4.0) to install it. Both the Microsoft Windows 2000 and Microsoft Windows Millennium Edition (Windows Me) operating systems include Windows Installer 1.1. If you are installing Office XP on one of these operating systems, no Windows Installer update is required.

Windows Installer version 2.0 fixes a number of problems in prior versions (including the ability to read source from an uncompressed source if installed from a compressed source, or vice versa). Therefore, it is highly recommended that client computers are upgraded to this version prior to deployment of Office XP.

Windows Installer Transform Files (.mst)

A Windows Installer transform file (.mst) provides configuration settings for a customized Office XP installation. A transform file contains information about components, features, setup properties, and changes that you can use to customize your Office XP installation. For example, if there are groups of computers in your organization that all require Microsoft Word and Microsoft Excel to be installed locally, but Microsoft Access and Microsoft PowerPoint are set to install on demand, you can use a single transform file (.mst) to configure the installation state you want for that entire collection.

The Office Resource Kit includes a utility called the Custom Installation Wizard that lets you change particular Office XP installation settings and create an .mst file. This file is then distributed with the source files for Office XP, so that the modified settings override the default values in Windows Installer when the installation is initiated on the client.

Windows Installer Patches

Windows Installer patch files allow the binary content of a Windows Installer installation to be changed without having to distribute an entirely new Windows Installer file. Office XP QFEs and service packs use Windows Installer patch files.

Windows Installer uses a patch package to modify local or administrative installations. A patch package is a file with an .msp extension that can contain a modified version of any component in the original .msi file. A patch can contain just a portion of the binary information for a particular component. Therefore, in most cases, the patch relies on the original installation .msi file to be available when the patch is applied.

There are two types of Windows Installer patches that Office XP can use:

  • Administrative patches

  • Client patches (also called standard patches)

Any particular fix encapsulated into a Windows Installer patch file has two different versions of the patch specific to each of these types; an administrative patch cannot be applied to a client installation and vice versa. The following sections describe these patches in more detail.

Administrative Patches

Administrative patches apply the Windows Installer patch to the original Windows Installer source (the source on the SMS distribution points or, for most deployments, Windows Installer source servers). An advantage of this method is that it permits new client installations of Office to install the latest patch components without needing separate distributions of patches. A disadvantage of this method is that clients that have not been instructed to install the new patch cannot use this source for maintenance operations such as adding, removing, or repairing an installation until they have synchronized with the latest source. This is because the original Windows Installer source is changed (the package code of Windows Installer is changed). As a result, there is a risk that clients with Office installations can become orphaned, unable to run repair operations from the source, until they are instructed to apply the patch. However, correct deployment of patches using SMS can mitigate this risk considerably.

Client Patches

A client patch, also called a standard patch, is a distribution of the actual .msp file to individual client computers without changing the original source on the server. One advantage of this is that the server Windows Installer source remains valid for both patched and non-patched clients for maintenance operations. As a result, users do not experience problems using Office XP. One disadvantage of this method is that new client installations receive only the original non-patched Office version. They still need to receive the specific patch distributions to upgrade to the required Office component level. However, if the patches are being targeted using SMS software inventory information, then the upgrade occurs with no administrator intervention. However, additional client programs must run and a delay occurs in upgrading the client Office installation to its required state. As a result, client patching requires more SMS administrator overhead than administrative patching.

In most situations, the original Windows Installer source is required when you are applying a patch. Therefore, for reliable patching, the original source should always be available when applying a client patch.

How Office XP Uses Patches

An Office update file is a packaged executable file that contains the .msp files for the update. Client patches also include the OHotFix patching program and .ini file. An Office update that is downloaded from the Office Web site is an executable file, which contains one or more Windows Installer patch files and an executable file (ohotfix.exe) to apply them. The update file can be for an administrative update or a client update. The correct type of patch must be used for the appropriate installation. For more information about these issues, see: https://www.microsoft.com/Office/ORK/xp/JOURN/Cliupdt.htm

Windows Installer patches are used for distributing both Office XP Public Updates and service pack components. In fact, an Office XP service pack includes all previously released Public Update patches, in addition to new fixes. However, service packs are particularly important for patch management because they apply a new baseline for the installed components against which future Public Updates (individual patches) are applied. Therefore, to apply an individual Office public update, the appropriate service pack for the patch must already be applied to the original Office source.

Using the Windows Installer Install on Demand Feature

Windows Installer Install on Demand allows Office XP features to be installed when they are selected by the user. Install on Demand is configured in the Custom Installation Wizard by selecting the Install on first use option for the specific applications.

The following are advantages of using Install on Demand:

  • Less disk space is required initially on the client computer.

  • Peak network bandwidth utilization is potentially decreased because Windows Installer components are copied over a longer period of time instead of simultaneously.

A disadvantage of using Install on Demand is that the original Windows Installer source must be accessible at the time that the Office XP feature is selected. Therefore, Install on Demand is not a good choice for laptop computers when the Windows Installer source is not stored locally on the computer.

Important: Install on Demand applications generate status messages when SMS runs the Office XP installation for the first time. However, SMS does not generate status messages when the user initiates the Install on Demand installation (after the initial installation) because later Office XP component installations are not initiated via the SMS client.

To create desktop icons, the Install on Demand method requires Active Desktop to be installed on the client; however, it is not mandatory that Active Desktop be turned on. If Active Desktop is not installed, the Windows Installer shortcuts might not be installed, and therefore, install-on-demand functionality is not available. Also, all clients must be running Microsoft Internet Explorer 4.01 or later. Clients running Windows 98, Windows Millennium Edition, Windows 2000 Server, Windows 2000 Professional, or Windows XP have this functionality built in.

You can customize and extend the basic methods of installing Office XP on clients to help support your specific deployment needs. After you run Install on Demand Setup, you can send additional Office XP Setup command lines to clients to trigger the installation of a specific Office XP program. This can be helpful if you want to stage your Office XP deployment.

For example, you might want to install the full version of Word and Excel on clients, but make PowerPoint and Access available for installation on first use. By setting some of the programs to install on first use, the network bandwidth required at initial deployment time is reduced, and setup time for users is faster. Later, if you want complete versions of PowerPoint and Access installed on all clients, you can send an additional setup command line program to accomplish this using SMS.

For additional information about Office XP features and Install on Demand, see the Office XP Resource Kit at

https://www.microsoft.com/office/ork/xp/default.htm

Windows NT 4.0 Low Rights Installation Issues

Low rights installation refers to the situation where the logged-on user does not have sufficient rights to complete an installation of Office XP. This is particularly problematic for SMS when the installation requires a restart (in the case of SFU installations) where the security context of the installation is lost during the restart. This scenario occurs for Windows NT 4.0 computers installing Office XP if both of the following are true:

  • The logged-on user is not an administrator on the computer

  • The Office XP installation is a clean install or an upgrade from a version of Office prior to Office 2000 Public Update 1 (because Office 2000 Public Update 1 includes SFU).

You can use the Elevated Rights Deployment Wrapper (Run_once.exe) to install Office XP in this scenario. The Elevated Rights Deployment Wrapper is typically used to deploy Office XP to a locked-down computer that is running Windows NT Workstation 4.0. You can use the Elevated Rights Deployment Wrapper with applications that require a restart during installation and elevated user rights following the restart. With this tool, the post-restart work can be integrated with SMS for both elevated rights and status reporting. Check the Systems Management Server Downloads Web site at https://www.microsoft.com/smserver/downloads/20/default.asp for this new tool and the Deploying Office XP with SMS 2.0 to a Locked-Down Windows NT Workstation 4.0 white paper.

Using the SMS Administrative Rights Installation Context

The Run with administrative rights option on the Environment tab of the SMS Program Properties dialog box grants the Administrative right to the logged-on user even if the user is a low rights user. This option ensures that low rights users can complete Office XP installations. The Administrative context is maintained until the computer restarts. Therefore, special procedures are required for installing the SFU components in a low-rights scenario because a system restart is required.

Office Resource Kit Tools

This section discusses the following tools for deploying Office XP with SMS that are included in the Office XP Resource Kit.

  • Custom Installation Wizard

  • Office Profile Wizard

Custom Installation Wizard

You can use the Custom Installation Wizard to make changes to the master installation in an .mst file without altering or resending the original Office XP source files. Because the original package is never altered, you can create a different transform file for every installation scenario you have. When you run setup with both the package and the transform file, Windows Installer applies the transform file to the original package, and setup uses your .mst file to obtain the configuration for the installation. All of this can be done without building a new package, which minimizes bandwidth usage.

The Custom Installation Wizard is automatically installed on your computer when you install the Office XP Resource Kit. You can use the Custom Installation Wizard to visually build your transform files.

Office Profile Wizard

You can use the Microsoft Office Profile Wizard to save configuration settings for Office XP applications. These settings are saved in a profile settings file (.ops), which is a snapshot of registry settings and related files for an Office user configuration. Using the Profile Wizard, deployment experts can further configure the deployment of Office XP to include a wide range of settings. These settings are more detailed than the Custom Installation Wizard. For example, the Profile Wizard allows an administrator to configure a test system. The Profile Wizard then collects the registry information as the administrator configured it, and the resulting .ops file is embedded in an .mst file.

Using the Profile Wizard, the administrator can create a virtual image of the Office XP installation as it should be configured when it is deployed. With the Profile Wizard, the administrator captures all settings that represent a combination of registry settings and files providing a specific user with a customized working environment. Typical customizations are the use and alignment of toolbars, common menu options, and language or tool visibility. Many customizations are set in the Tools, Options or Tools, Customize menu option of most Office applications.

Office XP CD and Administrative Installation Source Issues

The type of Windows Installer source used for an Office XP installation depends on how you install Office XP. When Office XP is installed using Setup from the CD or a network share, it uses the Windows Installer compressed source. When Office XP is installed from an administrative installation point created by running setup /a, it uses an uncompressed source.

The Office Windows Installer source from these two types of sources are not compatible with each other. As a result, if you use a different source type after installation, your installation either fails or Office XP is uninstalled and then reinstalled from the new source type. This problem typically occurs when Office XP has been installed directly from an Office XP CD, but then an update to the Office XP installation is distributed that references an administrative installation point source. This issue is fixed with Windows Installer version 2.0.

You can avoid this incompatible source problem by enforcing the use of one type of Office XP source in the enterprise. For example, if an administrative installation of Office XP is being used within an environment managed by SMS, then give users CDs of the image that they can install manually. For more information, see the Office deployment section in the Microsoft Office Resource Kit. Users should then be discouraged from using retail versions of Office XP installations. In addition, computers with the retail version of Office XP (for example, vendor or non-corporate owned computers) should not be deployed in the SMS hierarchy.

It is technically possibly to maintain both a standard non-compressed and an administrative compressed version of Office XP on the installation points (SMS distribution points), and then direct clients to the appropriate source based on the installed Office source type. However, this is difficult to enforce reliably and is beyond the scope of this white paper. A better approach is to periodically distribute a command for the client to synchronize the installed Office XP source with that on the installation point. This procedure is the same as that described for synchronizing following the patching of the installation point source with a Windows Installer patch:

  1. Create a program for each site called Office Synchronization Program.

  2. Add the command line:

    setup.exe /fvm

    For setup command-line options, see https://www.microsoft.com/office/ork/xp/appndx/setopt.htm

  3. Create an advertisement for each site to advertise this program

Deploying Office XP in an Enterprise

Sample Deployment Scenario

This section describes how to use SMS 2.0 to deploy Office XP in a large, diverse corporate enterprise containing multiple primary and secondary SMS sites.

This scenario assumes that you, as the administrator, are familiar with the Custom Installation Wizard and issues regarding Office XP deployments and supported installation methods. For technical background on relevant issues, see the Important Concepts and Issues section earlier in this white paper. You should also be familiar with SMS software distribution, collections, queries, and reporting.

Business Requirements

The scenarios and instructions outlined in this white paper for using SMS 2.0 to deploy Office XP assume that the following business requirements, site, and client configurations are present. These requirements are a superset of the most common requirements for any particular enterprise.

The SMS administrator in the sample scenario must be able to:

  • Perform a full installation of Office XP on local computers.

  • Perform a partial installation of Office XP on local computers, with Install on First Use available for other Office XP programs.

  • Use customized and additional templates.

  • Use specific pre-configured options in some of the Office XP programs.

  • Install Office XP on all new computers that connect to the network.

  • Install Office XP at multiple sites.

  • Upgrade Office XP installations without user intervention.

  • Minimize the overall administrative requirements for Office XP deployment.

  • Report the distribution results, and present an ongoing management report of computers that do and do not have Office XP installed.

  • Maintain the Windows Installer support for repairing Office XP core files to reduce support costs.

  • Reduce drive space usage by reducing the number of Office XP distribution points after Office XP deployment.

Enterprise Configuration

SMS 2.0 is configured in this sample scenario as follows:

  • One central site has ten primary sites.

  • Each of the primary sites has 40 secondary sites attached.

  • Each secondary site is separated from its respective parent site by a WAN link.

  • Client and site traffic is minimized architecturally. Each SMS site is contained within one continuous fast link. Slow links are managed by separating sites, and none of the sites span a slow link. Throttling and sending times are controlled to prevent SMS from using significant bandwidth during prime operating hours.

  • SMS 2.0 Service Pack 3 is deployed in the enterprise.

Corporate migration to the Active Directory structure for the corporation is completed.

Client Configuration

The company in this scenario has a mix of client operating systems configured as follows:

  • Clients running Windows 95, Windows 98, Windows Millennium Edition, Windows NT Workstation 4.0 SP4 and SP6a, and Windows 2000 Professional.

  • Users at some of the sites do not have local administrator rights on their clients that are running Windows NT Workstation 4.0 SP6a and Windows 2000 Professional.

  • The majority of users are upgrading from Office 2000 Public Update 1, but some users are upgrading from Office 97.

Planning the Deployment

This section assumes that you have successfully tested your deployment in a lab using hardware and software identical to your enterprise. After you have tested your deployment in a lab environment, you are ready to begin the Office XP deployment in the first production-pilot environment. This first deployment should be a small pilot group, which you can carefully monitor and adjust plans according to findings.

Before deploying Office XP in a production environment, you need to:

  • Consider basic planning issues.

  • Determine the systems and sites that will be upgraded.

  • Determine SFU requirements.

  • Plan for clients without administrative rights.

  • Determine which clients require software upgrades prior to installing Office XP (through software inventory and queries).

  • Plan installation options.

  • Plan the strategy for collections and program advertisements.

  • Prepare and customize the Office XP installation.

Basic Planning Considerations

  • Verify that the clients have the hardware and software required to run Office XP. See Office XP Operating System Requirements earlier in this white paper.

  • Know the terminology and processes of SMS 2.0 software distribution, the Office XP Custom Installation Wizard, and the Office Profile Wizard.

  • Review the features and options available with Office XP. Ensure that you properly implemented the configuration (.mst file) you built using the Office XP Custom Installation Wizard and Office Profile Wizard.

  • Determine which Office XP features you want to install, and which systems you want to receive each group of features. Each group will receive its own transform file.

  • Decide whether to do an attended or unattended installation, so that you can properly configure the program and advertisement properties.

  • Decide if your installation is going to be mandatory or optional. If the installation is mandatory, you can allow users to install it before the scheduled time. If users do not install the program early, the program automatically runs at the scheduled time.

  • Unattended mandatory deployments offer potentially increased benefits to the enterprise, because users are not present or needed during installation. Mandatory installation also ensures standardization within the business unit.

Determine the Systems and Sites That Will Be Upgraded

In this example scenario, you have decided to deploy Office XP to the central site (CTL) and the remote site (RMT) across a WAN link, using two different custom configurations of Office XP. The CTL site is the parent site of RMT. Productivity needs at both sites have determined the requirement for the upgrade to Office XP.

Determine SFU Requirements

Office XP Setup installs the SFU by default. If you do not want the SFU installed, select a program for your Office XP package that has /nosp in the command line. For example, the Custom (quiet) program specifies /nosp in the command line and does not install SFU.

Important: After installing the SFU, the client is restarted to complete the SFU installation.

A typical scenario for using SFU might be as follows. You have two computers. One runs Windows 98, and the other runs Windows 2000 Professional. Both have Office 2000 installed. The computer running Windows 98 must receive the SFU to install Office XP, but the computer running Windows 2000 Professional does not require the SFU. If you run a command line on both computers that does not exclude the SFU routine, the Windows 98 computer receives the SFU, but the SFU is not reinstalled on the computer running Windows 2000 Professional. However, at the end of the first phase of the SFU, a restart is included in the command line, and this affects both computers.

Clients that require the SFU

The program must include the setup command line to install the SFU on the following clients:

  • Clients running Windows 98 on which neither Office 2000 Public Update 1 (Public Update 1) nor Office XP was installed.

  • Clients running Windows NT Workstation 4.0 SP6a, or later, on which neither Office 2000 Public Update 1 nor Office XP was installed.

Important: If you have clients running Windows NT Workstation 4.0 SP6a with users who do not have administrative rights on the local computer, use the Elevated Rights Deployment Wrapper (Run_once.exe) to install Office XP. To download this tool, you must download the SMS Administration Feature Pack, and then read the Deploying Office XP with SMS 2.0 to a Locked-Down Windows NT Workstation 4.0 white paper.

Clients that do not need the SFU

Setup does not install the SFU on clients running the following operating systems, because these operating systems already have the required versions of key system files:

  • Windows 2000 Server, Windows 2000 Professional, or Windows XP Professional

  • Windows Millennium Edition

  • Any clients running Windows NT Server 4.0 SP6a, or later, or Windows NT Workstation 4.0 SP6a, or later, on which Office 2000 Public Update 1 or Office XP has been previously installed.

  • Any clients running Windows 98 on which Office 2000 Public Update 1 or Office XP has been previously installed.

Plan for Clients Without Administrative Rights

The SFU and restart phases of the Office XP installation require that the logged-on user have administrative rights on the local computer before and after the computer restarts. This might or might not be an issue, depending on your client install base. This section explains the requirements for each operating system supported by Office XP.

Clients running Windows 2000 and Windows XP

These clients do not need the SFU. Office XP installation requires administrative privileges, therefore, you must specify administrative privileges in the SMS program for low-rights users. This setting is included in the package definition files.

Clients running Windows 98

If Office XP Setup determines that a client requires the SFU, the SFU is installed, a restart is initiated, and then Office XP is installed.

Clients running Windows NT 4.0

Office XP installs without special consideration on clients running Windows NT Workstation 4.0 or Windows NT Server 4.0 if either of the following is true:

  • The client does not need the SFU.

  • The client needs the SFU, but the logged-on user has administrative rights on the local computer to allow SFU to complete.

If the computer running Windows NT 4.0 requires the SFU, and the account used for installation does not have administrative rights on the local computer, then Office XP installation fails.

Important:

  • You can use the Elevated Rights Deployment Wrapper (Run_once.exe) described earlier in this paper, to deploy Office XP to low-rights Windows NT 4.0 clients that require the SFU. The Elevated Rights Deployment Wrapper will be available in Q3 2002. Watch the Systems Management Server Downloads Web site at https://www.microsoft.com/smserver/downloads/20/default.asp for this new tool.

  • For computers running Windows NT 4.0 with low-rights users, it is recommended that you upgrade the client to Windows 2000 or later before installing Office XP.

  • Office 2000 includes a script that was intended to help install Office 2000 on computers where users did not have local administrative rights. This script has had several problems with supportability. The script is not supported in Office XP.

Determine Which Clients Require Upgrades Prior to Installing Office XP

In the sample scenario, the administrator and the corporate decision-maker decided to upgrade the operating systems that are not supported by Office XP as follows:

Client environment

Action

Windows 95

Upgrade clients to Windows 2000 or Windows XP. Office XP does not run on Windows 95.

Windows NT 4.0 SP4 users with or without local administrative rights

If the user is a local administrator on the client computer, use SMS to deliver Windows NT 4.0 SP6a to clients, and then follow the process to deploy Office XP for clients running Windows NT4.0 SP6a. If the user is not a local administrator, it is recommended that you upgrade the operating system to Windows 2000 or Windows XP, and then install Office XP.

Windows NT 4.0 SP6a users without local administrative rights (Office 2000 Public Update 1 is not already installed)

Upgrade clients that do not already have Office 2000 Public Update 1 installed to Windows 2000 Professional or Windows XP Professional.

Windows NT 4.0 SP6a without local administrative rights (Office 2000 Public Update 1 is already installed)

Clients with low rights running Windows NT 4.0 SP6a that are upgrading from Office 2000 Public Update 1 do not need the SFU, and thus Office XP can be directly deployed.

Windows XP, Windows 2000 Professional, and Windows Millennium Edition

No action needed. Clients running Windows XP Professional, Windows 2000 Professional, and Windows Millennium Edition already have the proper files and do not require the SFU.

Windows 98

No action needed. Clients running Windows 98 allow the SFU installation to complete successfully after the restart.

Plan Installation Options

You have the following options when installing Office XP:

  • Use the SMS administrative context with the programs included in the package definition file

  • Use the SMS administrative context with Install on Demand

Plan the Strategy for Collections and Program Advertisements

The Office XP package definition file creates the Microsoft Office XP Applications 10.0 English package, a package that contains eight previously created programs. These programs are templates to deliver Office XP to different clients or under different situations. With SMS 2.0, you can create collections based on whether or not clients need the SFU, and advertise the appropriate programs to each collection. For example, you might want to create the following collections:

Collection

Client operating system

Comments

No SFU Collection

Windows Millennium Edition, Windows 2000, and Windows XP

These computers do not require the SFU and, therefore, do not require a restart.

SFU Collection

Windows 98 and Windows NT 4.0 SP6a (with administrator rights on which Office 2000 Public Update 1 is not already installed

These computers require the SFU and, therefore, require a restart.

Then you can advertise the appropriate programs to each collection:

Installation program

Target collection

Custom (unattended)

Advertise this program to the No SFU Collection.

Custom including SFU (unattended)

Advertise this program to the SFU Collection. The command line includes a restart to the systems after running the SFU program.

Note: The Office Setup command line with the SFU runs successfully on computers that do not require the SFU. SFU installation does not occur, but those computers still restart. To make the deployment simpler, you can target all computers by using the SFU and restart instructions in the program. Installation is successful on all clients that can install Office XP. However, clients that did not require the SFU are restarted, even though a restart was not required.

The following table describes how each SMS program included in the package definition file installs the SFU on the supported operating systems, where:

Targeted indicates that the client receives the program advertisement.

Not Targeted indicates that the client does not receive the program advertisement.

Fails indicates that the Office XP installation fails.

Table 1 Office XP Programs to Use with Each Supported Operating System

Cc723678.smsoxp01(en-us,TechNet.10).gif

1 User logging on after the SFU restart does not have local Administrator rights on the client.

2 User logging on after the SFU restart has local Administrator rights on the client.

Prepare and Customize the Office Source

The next step in the deployment process is to prepare the office source files for use by SMS and create any customization files that are required. If you are deploying a typical Office installation, then it is not necessary to create your own customization files (.mst and .opw files). These customization files are referenced by the SMS program objects, covered in the next section Step 4: Create SMS Software Distribution Objects.

Deploying Office XP

The following is a summary of the steps for deploying Office XP, each of which are fully discussed in subsequent sections. Some steps, such as Office XP source customization, might not be necessary in your deployment, but most deployments follow this basic pattern.

  1. Create the administrative installation point.

  2. Create the transform file using the Office Custom Installation Wizard

  3. Create an .ops customization file using the Office Profile Wizard

  4. Create SMS software distribution objects.

    • Import the package definition file, and create the Office XP package.

    • Create programs for Office XP Install on Demand.

    • Create the collections.

    • Assign distribution points to the Office XP package.

  5. Check the progress of your installation.

    • Monitor the installation.

    • Conduct inventory and reporting of the Office XP installations.

    • Run a query to confirm that Office XP was successfully deployed.

Step 1: Create the Administrative Installation Point

An administrative installation point is a server share that contains all the expanded files you need to install Office XP by using SMS 2.0. When SMS 2.0 packages are distributed, the files in the administrative installation point are copied to distribution points. Restrict access to these source files through share permissions or NTFS privileges.

Important: Office XP Enterprise Edition is required to create an administrative installation point.

Using the administrative installation point can eliminate interactions at the client, such as prompting for a product key. Valid licensing is required, and all licensing requirements apply when you deploy Office XP.

The following steps describe how to create an administrative installation point. For more detailed steps, see the section on creating administrative installation points in the Office XP Resource Kit.

  1. Create a share on a network server for the administrative installation point. This share will be the source file location for the Office XP package. To avoid a package source update spanning a WAN, you should create the share on each site server that will send the package. The transform files created by the Custom Installation Wizard should also be placed in the root of this share, along with the .ops file created in the Office Profile Wizard used to further customize Office XP programs.

    Important: The network share must have at least 700 MB of available disk space. Increased space requirements might arise during the process, depending on configuration.

  2. Connect to the server share using an account that has write access to the share. The computer must be running a supported operating system, such as Windows XP Professional, Windows 2000 Professional, Windows NT Workstation 4.0 Service Pack 6a, Windows 98, or Windows Millennium Edition.

  3. On the Start menu, click Run, and then run setup /a from the root of the Office XP CD.

  4. Enter the organization name that you want to define for all users who install Office XP.

  5. Enter the server and folder you created as the installation location. The SMS administrator selected a local path, to avoid unnecessary network traffic. If a remote path is selected, then the administrative installation is copied on the network. In our scenario, the path is C:\OfficeXP.

  6. Enter the 25-character Enterprise product key, and click Next. You must enter a valid, purchased product key when you create the administrative installation point. Users who install Office XP from this administrative image do not have to enter the product key when they install Office XP or start an Office XP program for the first time.

  7. Accept the end-user license agreement and then click Install. By accepting the agreement, you are accepting on behalf of all users who install Office XP from this administrative installation or any SMS distribution point the SMS administrator creates from this administrative installation.

Setup expands and copies the files from the Office XP CD to the administrative installation point, extracts the compressed cabinet (.cab) files, and creates a hierarchy of folders in the root folder of the share. The SFU files are automatically included during an administrative installation.

By creating multiple transform files, you can also install different Office XP configurations to different groups of users from the same Office XP source file location (also called an administrative installation point).

You can use a transform file to create any kind of customization in an Office XP command-line by using the Custom Installation Wizard. You can create transform files for:

  • Adding resilient sources (see "Appendix A: Using Resilient Sources" later in this paper).

  • Creating customized programs or configurations for different sets of users.

  • Selecting the Office XP features that you want to install.

  • Modifying shortcuts.

  • Customizing options for Microsoft Outlook.

  • Adding custom files to the installation.

  • Customizing the SFU settings, including Internet Explorer 5 settings, as needed.

  • Customizing Office XP Multilingual User Interface Packs

Step 2: Create the Transform File by Using the Office CIW

Transform files (.mst files) contain instructions for customizing Office XP. To customize the Office XP installation, you can create a custom transform file by using the CIW.

The following screen shot shows an example of some feature states that you can configure by using the Custom Installation Wizard:

Cc723678.smsoxp02(en-us,TechNet.10).gif

The following table describes the settings in the screenshot.

Program

Feature states

Microsoft Access, Microsoft Excel, Microsoft PowerPoint, Office Shared Features, and Office Tools

Set to Install on Demand, as shown in the following screenshot. This is indicated by the 1 next to the component name, meaning the component is installed on first use.

Microsoft Word

Set to install to the client hard disk during the initial installation.

Microsoft FrontPage and Microsoft Outlook

Set to Not Available, which means they are not installed to clients.

In the example scenario, you decide that there will be one transform file per site, because all the distribution points within a site will be local. As a result, any distribution points will be local, and traffic associated with repairs and install-on-demand applications will not cross WAN links in the future. You also create a hidden custom share for the Office XP source called OfficeXP$.

To distribute the package properly, you must record key information for each site. The following table contains information about the CTL site.

Distribution point name

Is this a permanent distribution point?

Network path that SMS uses to access and install Proplus.msi, .mst files, .ops files, and installation files

Site1dpa

Yes

\\site1dpa\OfficeXP$

Site1dpb

Yes

\\site1dpb\OfficeXP$

Site1dpc

No

\\site1dpc\OfficeXP$

You have now determined the location, administrative installation point, and share for the installation files of Office XP. Next, you must build the files to configure the installation.

You create the transform file using the Custom Installation Wizard. You must repeat the following steps for each transform file.

  1. Run the Custom Installation Wizard by clicking Start, pointing to Programs, pointing to Microsoft Office Tools, pointing to Microsoft Office XP Resource Kit Tools, and then clicking Custom Installation Wizard. The administrator runs the Custom Installation Wizard on a computer that has access to both the administrative share (where the .mst files are copied) and the Proplus.msi file that installs Office XP.

  2. Specify the path of the .msi file to open (for example, D:proplus.msi), and click Next.

  3. Create a new transform file by selecting Create a new MST file, and then click Next.

  4. Specify the path of the new transform file (for example, C:Documents and Settings\user1\my documents\ new custom setup file for CTL Site.mst), and then click Next. Long filenames are allowed, so give the transform file a descriptive name (including the site name and configurations). This provides an easy way to reference the file later.

  5. Specify the installation location (<ProgramFiles>\Microsoft Office) and the company name, and then click Next.

  6. Set the feature installation states and verify that the Office XP installation meets the needs of the users. The Installed on First Use option in the Set Feature Installation States page helps minimize setup time for the user, and balances the traffic associated with installation. For example, in the following screen shot, the traffic associated with Access is deferred until a user on the system runs Access, or until the user runs an Access file. When applications that are set to Installed on First Use are first activated, there is a delay while the installation runs.

    Cc723678.smsoxp03(en-us,TechNet.10).gif

  7. Using the table that was completed when creating the transform file for the clients, enter the paths of the installation points. The Custom Installation Wizard does not validate the paths. These paths are entered so that the resilient sources are displayed at the top of the list. The administrator does this so that when the resilient sources are removed from \\site1dpc, clients seeking to install or repair from this transform file will go to the existing site first, instead of failing against \\site1dpc and then succeed in reaching the resilient sources (\\site1pda and \\site1dpb).

    For detailed information about using resilient sources with SMS, see Appendix A: Using Resilient Sources.

    Cc723678.smsoxp04(en-us,TechNet.10).gif

  8. Accept the changes and create the .mst file for the Office XP installation that installs Office XP with Word and Excel locally and installs the other applications and tools on first use.

  9. Include any additional configurations you made with the Profile Wizard. These are embedded in the .mst file. You can use the Profile Wizard to configure the options contained within the Tools menu, in addition to other options to customize Office XP to your requirements. For more information, see the Office Resource Kit.

  10. Review the summary, displayed as follows.

    Cc723678.smsoxp05(en-us,TechNet.10).gif

  11. Copy the transform file (.mst) into the root of the administrative installation source (which was created by running setup /a). In the example above, the transform files are copied into the root of C:\OfficeXP.

    Important: All transform files should be included in the root of the administrative share prior to assigning the SMS package to any distribution points. This prevents repeated replication of files to all designated sites and distribution points.

Step 3: Create an .ops Customization File by Using the Office OPW

You can further customize an Office installation using the Office Profile Wizard (OPW) in Office Resource Kit. The OPW takes a snapshot of the registry settings for an existing Office XP installation and saving the settings to an .ops file. This file is then saved in the root of the Office source files in the same location as the .mst file.

Step 4: Create SMS Software Distribution Objects

If you need customized SMS programs that are different from the ones included in the Office XP package definition file (.sms file), you can modify the programs created by the .sms file after you create the package.

Note: The Custom programs within SMS might reference a transform file to allow those installations to be highly configured by the transform file. There is also an SMS program created by the .sms file named Typical. The Typical program does not use transform files.

To create the software distribution objects, do the following:

  1. Import the package definition file (.sms file), and create the Office XP package.

  2. Create programs for Office XP Install on Demand.

  3. Create the collections.

  4. Assign distribution points to the Office XP package.

Step A: Import the package definition file, and create the Office XP package.

To create a package from a package definition file, you can use the Create Package from Definition Wizard or the Distribute Software Wizard. Both wizards create a package by importing a package definition file, but the Distribute Software Wizard includes the following additional functionality:

  • Enabling and disabling distribution points for the package

  • Creating an advertisement for the package

To create a package using the Package Definition Wizard:

  1. Expand the Ork.cab file that is included in the ORK folder of the Office XP CD to access the package definition file. Click the Ork.cab file, click Extract, and then choose a destination folder.

  2. Start the SMS Administrator console, and then double-click Site Database.

  3. Right-click Packages, point to New, and then click Package from Definition.

  4. On the Create Package from Definition Wizard page, click Next.

  5. The Package Definition page is displayed; however, the Off2002.sms file does not appear in the list because it has not been imported into the SMS Administrator console. Click Browse.

  6. In the folder that contains the .sms file you extracted, click Off2002.sms, and then click Open.

  7. Click Office XP Applications, and then click Next.

  8. On the Source Files page, select the Always obtain files from a source directory check box, and then click Next.

  9. On the Source Directory page, specify the location of your administrative installation point. You must specify a local path on the site server or a network path to the administrative installation.

  10. Click Browse to locate the source location for the Office XP administrative installation (**C:\**OfficeXP in the example), and then click Next.

Verify that the information is correct, and then click Finish to create the package named Microsoft Office XP applications 10.0 English.

Note: Updated package definition files for Office XP are available in the Microsoft Office XP Resource Kit at https://www.microsoft.com/Office/ORK/xp/JOURN/PDFWinXP.htm.

Step B: Configure programs for Office XP Install on Demand

By importing the Off2002.sms file and creating the package from it, you now have eight default programs created under the package named Microsoft Office XP applications 10.0 English. You can use these different programs in the collections that target the separate installation requirements for systems receiving Office XP.

There are two programs the SMS administrator uses in this phase of the deployment. Both programs are unattended, so that the installation can be fully managed by the SMS administrator, and users are not prompted for installation input.

Custom (Quiet)

This program is used on all clients that do not require the SFU and the associated restart, including computers running the following:

  • Windows XP Professional

  • Windows 2000 Professional

  • Windows 2000 Server

  • Windows 2000 Advanced Server

  • Windows Millennium Edition

  • Windows NT Workstation 4.0 SP6a computers with Office 2000 Public Update 1.

  • Windows 98 with Office 2000 Public Update 1. Computers that use this program to install Office XP do not require a restart.

Custom including System Files Update (Quiet)

This program is used to install Office XP on all clients that require the SFU. Completing the SFU installation requires a restart. The computers that use this program in their advertisement can include computers running:

  • Windows 98 without Office 2000 Public Update 1 installed.

  • Windows NT Workstation 4.0 SP6a without Office 2000 Public Update 1 installed. (Users must have local Administrator permissions to complete the SFU before Office XP installs.)

The administrator must decide Install on Demand options for clients in each site.

Installation states

Issues to consider

For clients at the CTL (central) site

You can create a separate transform file for each different installation state of Office XP that is required. You might edit existing transform files and save them under separate, descriptive names. These new transform files should be placed in the root of the source directory (C:\OfficeXP in the example), along with any accompanying Office profile files (.ops) created in the Office Profile Wizard. Complete this prior to creating the packages distribution points, because it minimizes traffic associated with the package source files.

For clients at the RMT (remote) site

Use the Custom Installation Wizard to efficiently edit the existing transform (.mst) files to match the installation states of the CTL sites requirements. The resilient sources, which appear in the Custom Installation Wizard on the Additional Servers page, should be changed to point to the distribution points that are local for the clients at the RMT site. This ensures that the RMT clients both repair and install on demand from the share of the local distribution point within the RMT site.

The administrator must perform the following tasks for each transform file:

  1. In the Custom Installation Wizard, on the General page, enter the transform (.mst) file name in the command line.

  2. Specify a descriptive name for the transform (.mst) file, such as Word and Excel Local Access and Powerpoint IOD.mst.

  3. Specify the transform file name in both Custom (quiet) and Custom including System Files Update (quiet) programs.

Step C: Create the collections

Creating collections within the enterprise is the first step toward deployment. A collection is created in SMS by running a query, which includes systems based on their compliance with the query rules. For example, your query should contain a minimum RAM requirement that you have tested and verified to be successful for your users. If you make the RAM requirement part of the query rules for the collection, only systems with sufficient RAM are targeted for the Office XP installation. The Office XP package, with the related program and correct transform file, are distributed based on the following criteria:

  • The Office XP configuration (.mst file) the computer requires. Those computers with common configurations receive the same .mst file in the command line of the SMS program.

  • The requirements of the computers before Office XP is installed, for example, whether those computers require the SFU and restart to be a part of the installation routine.

Determine which computers in your sites should receive Office XP. These computers are grouped into SMS collections. You can use several methods, depending on the business rules your organization has in place. In the example, it is assumed that all clients currently running Office 2000 Public Update 1 are upgraded, and computers running Windows NT 4.0 and Windows 95 are excluded. Computers with less than 64 MB of RAM and less than 500 MB of free disk space are also excluded.

Create dynamic collections that encompass all systems that you want to receive Office XP. All computers in this collection require Office XP with Word and Excel installed locally, while Access and PowerPoint are installed on first use. When new systems come online or meet these criteria, the Office XP package is also assigned to them. This way, the SMS administrator adheres to the companys corporate policy to have new systems install Office XP.

The query can be written to create collections based on the following criteria:

Collection

Site Name

Operating system

Current Office Version

At least 64 MB RAM

At least 500 MB disk space

C1

CTL

Windows XP Professional

Any

Yes

Yes

C1

CTL

Windows 2000 Professional

Any

Yes

Yes

C1

CTL

Windows Millennium Edition

Any

Yes

Yes

C1

CTL

Windows 98

Office 2000 Public Update 1

Yes

Yes

C2

CTL

Windows 98

Any except Office 2000 Public Update 1

Yes

Yes

When creating the query, it is important to use your knowledge of the separate setup routines discussed earlier in this paper. Computers running Windows 98 without Office 2000 Public Update 1 require the SFU and have a different command line than your other clients. Therefore, separate the systems needing different programs.

These dynamic collections are targeted for different advertisements that point to two separate program command lines. The transform file you use is the same, because both the systems in the collections C1 and C2 require the same Office XP configurations. However, because the systems in collection C2 require the SFU and associated restart, the SMS administrator in the example separated the collections. That way, all clients running Windows XP Professional, Windows 2000, Windows Millennium Edition, and Windows 98 with Office 2000 Public Update 1 do not require a restart.

Step D: Assign distribution points to the Office XP package

Planning for the distribution points is essential to providing local distribution points for the Office XP package. Also, if you intend to use resilient sources, you should know both the distribution points and the custom share name that SMS uses for the package. This is the path that you should have entered on the Additional Servers page in the Custom Installation Wizard. For detailed information about the use of resilient sources with SMS, see Appendix A: Using Resilient Sources.

You can assign distribution points and create an advertisement by using one of the following:

  • The SMS Administrator console

  • The Distribute Software Wizard. When you are ready to deploy Office XP to your clients, you can run the Distribute Software Wizard to create the distribution points and the advertisement targeted at all systems in your enterprise.

After Office XP deployment, you might plan to reduce the number of distribution points. At least one distribution point remains locally at each site so that Office XP Windows Installer can automatically repair a corrupt core file by accessing a local distribution point. Also, application installations occurring on first use continue to have access to these distribution points.

Note: By design, SMS clients receive only information regarding distribution points in their own site.

Each of these location-specific transform files is then included in a new program created within the Microsoft Office XP applications 10.0 English package. The command line entry on the programs General tab includes the direction to the newly created, location-specific transform files.

All of this planning should be done in advance, because these new .mst files must be placed in the root of the source location (C:\OfficeXP in the example). You can change the list of additional servers using the Custom Maintenance Wizard and use SMS to distribute the update after installing Office XP. If you deploy this package to distribution points, and then add the new .mst files to the source, the entire source directory must be sent to the distribution points during the next package refresh of the distribution points. Sending the entire source directory produces considerable network traffic, because the Office XP installation files, which are approximately 625 MB, would be redeployed to each distribution point.

Assign the distribution points for the Microsoft Office XP applications 10.0 English package. For example, all of the previously determined distribution points could be used:

  • Site1dpa

  • Site1dpb

  • Site1dpc

Note: These distribution points should be within the site, which is defined within a continuous fast link. If a distribution point is separated from the systems that install or repair Office XP, then a second location-specific transform (.mst) file should be created that lists only the distribution points connected by a fast link to the clients. Architecturally, SMS is designed to support this model, where each distribution point for a site resides on the same fast link as the clients it serves.

To create an advertisement and assign SMS distribution points using the Distribute Software Wizard

  1. In the SMS Administrator console, navigate to Packages, right-click your package**,** point to All Tasks, and then click Distribute Software.

  2. On the Distribute Software Wizard page, click Next.

  3. The Package page is displayed. Select the Distribute an existing package check box, click Office XP Applications, and then click Next.

  4. On the Distribution Points page, select the distribution points you want for the Office XP distribution, and then click Next.

  5. On the Advertise a Program page, click Yes, and then click Next.

  6. On Select a Program to Advertise page, click the program that you want to include in this advertisement, and then click Next.

  7. On the Advertisement Target page, select the Advertise the program to an existing collection option, click Browse to select a collection, click OK, and then click Next.

  8. On the Advertisement Name page, click Next.

  9. On the Advertise to Subcollections page, select the appropriate option, and then click Next.

  10. On the Advertisement Schedule page, select the appropriate schedule, and determine whether you want the advertisement to expire. If you are using the distribution points as resilient sources, select the No. This advertisement never expires check box, and then click Next.

  11. On the Assign Program page, select the appropriate option, and then click Next.

  12. On the Completing the Distribute Software Wizard page, verify the information under Details, and then click Finish to start the distribution.

  13. Following the standard method for advertising to a collection, the SMS administrator creates the following two advertisements.

    Name

    Package

    Program

    Collection

    Mandatory

    Schedule

    Note

    Office1

    Office XP

    Custom (quiet)

    C1

    Yes

    Weekly, at midnight on Fridays

    Office XP installs from local distribution points, with local resilient resources. Also, the corporate policy to install Office XP on new systems is met.

    Office1a

    Office XP

    Custom including System Files Update (quiet)

    C2

    Yes

    Weekly, at midnight on Saturdays

    Office XP installs from local distribution points, with local resilient resources. The restart occurs during non-business hours. Also, the corporate policy to install Office XP on new systems is met.

Step 5: Check the Progress of the Installation

To check the progress of your installation:

  1. Monitor the installation.

  2. Conduct inventory and reporting of the Office XP installations.

  3. Run a query to confirm that Office XP was successfully deployed.

Step A: Monitoring the Installation

After distribution starts, you can use the SMS 2.0 status system to monitor the status of your distribution, packages, and advertisements. In SMS 2.0, you can get detailed package status and advertisement status.

For detailed information about using the status system, the steps for distributing an installation package, the files that are created, and troubleshooting tips, see the Microsoft Systems Management Server 2.0 Administrators Guide. The flowcharts in this administrators guide can be used with diagnostic tools, such as SMS Trace, to follow the distribution as it is completed.

Step B: Conducting Inventory and Reporting of the Office XP Installations

The SMS administrator uses the software inventory system to collect and report on the finalized installation of the Office XP installation.

For detailed information about using the reporting features of software inventory, flowcharts, and query support for the software inventory function, see the Microsoft Systems Management Server 2.0 Administrators Guide.

A convenient way to inventory the installed properties of Office XP is to collect information from Windows Add/Remove Programs registry details. Appendix B How to inventory Office XP discusses how this can be done using SMS hardware inventory.

Step C: Running a Query to Confirm That Office XP Was Successfully Deployed

To ensure that Office XP has been successfully deployed to your clients, the SMS administrator runs a query by mapping the Select statement to Managed Object Format (MOF) properties.

Maintaining and Updating Your Office XP Installation

When Office XP is deployed in your organization, you can maintain and update it as follows:

  • Distribute an Office XP public update

  • Distribute an Office XP service pack

  • Update Office XP installation settings

Distributing an Office XP Public Update

For important background information about this issue, see the section about Windows Installer patching earlier in this white paper.

There are two options for the deployment of public updates:

Administrative patching

This is recommended, if the instructions below in Performing Administrative Patching of an Office XP Public Update are followed.

Client (standard) patching

Client patching might be more appropriate in some scenarios than in other scenarios. Instructions are provided for this approach in Client Patching of an Office Public Update below.

Performing Administrative Patching of an Office XP Public Update

When you perform administrative patching, you apply the public update patch to the Office source in the package source directory, which is then replicated to the distribution points.

You can apply patches to the original source or to a new source.

Applying a patch to the original source

With this option, you apply the public update to the original package source, which is then replicated to the distribution points to update the Office source. If the clients are required to initiate a repair or installation-on-demand operation that requires the original source, then a Windows Installer error appears on the client computer. However, if the synchronization advertisement is received by most clients within a few hours of the distribution point update (which is reasonable for most SMS configurations), then it is unlikely that problems will occur on the clients. Therefore, as soon as the patch has reached all distribution points in a site, an advertisement should be distributed with the program update to the clients, so the Windows Installer source can be synchronized.

To apply a public update to the administrative source

  1. Download the self-extracting executable file for the update from the Office Resource Kit Web site (https://www.microsoft.com/office/ork/xp/default.htm) and double-click the file name to extract the MSP file.

  2. Connect to the server share for your administrative installation point (the SMS package source directory).

  3. On the Start menu, click Run and then type the command line for Windows Installer with the appropriate options for your installation. Use the following syntax:

[start] msiexec /p [path\name of update MSP file]/a
[path\name of MSI file] SHORTFILENAMES=TRUE /qb  /L* [path\name of log file]

To create and distribute the program update for clients

  1. Create a program for each site called Office Synchronization Program.

  2. Add the command line:

    3. 



setup.exe /fvm



For setup command-line options, see <https://www.microsoft.com/office/ork/xp/appndx/setopt.htm>



    

  1. Create an advertisement for each site to advertise this program
    2. 



Applying a patch to a new source


To avoid the potential for errors on the client due to an incorrect Windows Installer source on the distribution points, an alternative method is to create a new SMS package share specifically for the newly patched Office source and then direct clients to the share using a program advertisement. The clients that have not received the advertisement are still working from the original Windows Installer source and, therefore, all clients are always referencing a valid Windows Installer source for repair operations. This method is more complex particularly if resilient resources are being used in the transform file.


To apply a patch to a new source:


    

  1. Create a new directory and place an administrative installation of Office XP in this directory.
    

    2. 

  2. Configure the source as described in the Deploying Office XP section earlier in this white paper. The new source directory should be identical to the one currently in use.
    

    3. 

  3. Apply the Office XP public update to the new source as described in Applying a Public Update to the Administrative Source in the previous section of this white paper.
    

    4. 

  4. Create a package with this source, and distribute the package to the clients following the steps described in the deployment section earlier in this paper.
    

    5. 



Client Patching of an Office Public Update


Client patching involves distributing the public update bundle to each client computer and running it using SMS software distribution. There are two options for distributing update files:


    

  • Distribute the client update executable file that is downloaded from the Office Web site. You can do this by typing the name of the .exe file in the command line of an SMS program and including the file in the source directory for the package.
    

    • 

  • Extract the executable file to obtain the raw Windows Installer patch files (.msp). You can extract the .msp files from the client update as follows
    

    C:\path to update file\MyUpdate.exe /c /t:C:/folder for extracted files
    

    • 



Distributing an Office XP Service Pack


Refer to the section about Windows Installer patching earlier in this white paper for important background on this issue.


The processes for distributing Office XP service packs and public updates are similar. However, distributing a service pack provides a new baseline Windows Installer source for future Office public updates. As a result, a public update released after Office XP SP 1 can be applied only to an Office XP source that has already been patched with the Office XP SP1 update. This is an issue for client (standard) patches only.


The procedure for administrative patching of the Office source is the same as that for a public update described in the previous section.


Updating Office XP Installation Settings


To update your Office XP installation settings, you must:


    

  1. Create updates using the Custom Maintenance Wizard
    

    2. 

  2. Apply the .cmw file to the client
    

    3. 



Creating Updates Using the Custom Maintenance Wizard


After an Office XP installation has been deployed, it is not possible to change the installation settings using an Windows Installer transform file without reinstalling Office XP. However, you can update these settings dynamically on the client by using a configuration maintenance file (.cmw) produced by using the Custom Maintenance Wizard.


The Custom Maintenance Wizard is a tool that allows administrators to maintain existing Office XP installations on clients, and it works with Windows Installer version 1.1 and later. Office XP Setup installs Windows Installer version 1.1.


Using the Custom Maintenance Wizard, you can modify features that you set in the Custom Installation Wizard, including default user settings, security levels, Outlook settings, and registry keys.


The Custom Maintenance Wizard creates a .cmw file based on the Windows Installer package (.msi file) used in the Office XP installation.


Applying the .cmw File to the Client


To apply the changes to a client, run the Custom Maintenance Wizard from a command line on the client specifying the customization file that contains the changes you want to apply.


As described in the Office XP Resource Kit, you might want to deploy Maintwiz.exe to your clients as part of the Office XP package, so that updates made through the Custom Maintenance Wizard can be more easily deployed to clients. See the Office XP Resource Kit for more information. The Custom Maintenance Wizard is automatically installed on your computer when you install the Office XP Resource Kit.


Appendix A: Using Resilient Sources


Depending on your environment, you can take advantage of an advanced installation option called resilient sources.


Resilient sources are created when multiple sources of Office XP (administrative installation points on a distribution point) are made available to the clients. By default, Office XP returns to the share point from which Office XP was installed. If you choose to use resilient sources, clients use those sources whenever the original distribution point is unavailable


Creating resilient sources is valuable because:


    

  • They provide fault tolerance.
    

    • 

  • They enable the number of SMS distribution points with Office XP sources to be reduced after deployment.
    

    • 



These share points can be located on many different SMS distribution points. The resilient sources do not have to be SMS distribution points, because network share points of any type can be used to provide self-healing and sources for resilient installations of Office XP. However, over time you might choose to reduce the number of distribution points. Typically, the path to the distribution point you use for installation servers is stored by default as a source. But, if servers are unavailable, then its role as a distribution point path is no longer valid. Alternatively, administrators might want to have several sources during initial rollout but then reduce the number of sources, for example, to save disk space. Establishing resilient sources allows administrators to reduce the number of distribution points, while continuing to allow install on first use and repairs to take place. The clients would use their list of resilient sources, and when the primary source was unavailable, they could use a second or third resilient source. If no resilient resources are available, the user is instructed to provide a path to the Office XP source files.


Windows Installer requires users to retain access to the source files throughout the life of the programs, so that advanced features, such as program repair and Install on Demand, can return to a share point other than the originating distribution point. Office XP provides the option of establishing a valid universal naming convention (UNC) path (for example, \\<server>\<share>), or a list of valid UNC paths or mapped drives for the source files.


Using the Custom Installation Wizard, you can set up a list of sources for Office XP to use when it requires source files. The resilient source list remains available for as long as Office XP is installed on the clients.


You must have the name of each server you want to use for resilient sources in order to populate a property called SOURCELIST. To configure the Windows Installer SOURCELIST parameter for the Office XP installation, use the Custom Installation Wizard. In the Identify Additional Servers page of the Custom Installation Wizard, enter the server names you want to use as resilient sources.


When you create resilient sources, keep in mind the following.


    

  • In the Custom Installation Wizard, you must enter the server name and the share name. To use resilient sources, you must use a customized name in the SMS package creation process. This is located in Share Distribution Folder on the Data Access page in the SMS Administrator console. Knowing the share name in advance is necessary when creating the .mst file in the Additional Servers phase of the Custom Installation Wizard.
    

    • 

  • It is important to define a share distribution folder in the Data Access tab of the Package Properties in the SMS Administrator console. If you do not provide a name for this folder, SMS uses a default name, which is the package ID, or the drive ID, which is not always known. For large enterprises, the package ID is not predictable in advance, so it is difficult to anticipate the complete path to the distribution point share, unless it is set specifically in Share Distribution Folder.
    

    • 

  • If you use resilient sources, and you have more than one site in your hierarchy, you might need to create a separate customization file (transform file) to reflect the different resilient sources. Then, use a separate SMS program within your package that points to each .mst file. You might have one for each site. Configuring separate transform files for each individual site allows each sites clients to carry a local list of resilient resources, which are most likely the distribution points for that site. This avoids unnecessary WAN traffic.
    

    The enumeration of the resilient sources should include the planned network share points for Office XP, whether they are SMS distribution points or not. As a result, you will have a program that is specific to each site which references the Windows Installer transform file containing the resilient sources specific to that site with all other options identical.
    

    When you use SMS 2.0 to distribute Office XP, SMS randomly selects the distribution point to which specific clients connect to for installations. This effectively distributes the load on the available distribution points. In some ways, the administrator can also control load balancing by selecting collections and distribution points for an installation. For example, if you choose to install Office XP to 10,000 users simultaneously, you will probably create stress on your network. SMS 2.0 provides tools for simulating your network traffic and estimating the results of such actions. For more information, see Chapter 11, Configuring and Populating Pilot Sites, in the Microsoft Systems Management Server 2.0 Resource Guide, part of the Microsoft BackOffice® 4.5 Resource Kit.
    

    • 



After you install Office XP, there is additional stress to the system when installations are repaired and Install on Demand features install. You can provide more load balancing by configuring additional resilient sources for installing these components rather than just the installation distribution point.


For more information about resilient sources, see the Office XP Resource Kit Web site at


https://www.microsoft.com/office/ork/xp/default.htm


Appendix B: How to Inventory Office XP


Use the following sample Managed Object Format (MOF) file to configure the registry provider to collect Windows Add/Remove Programs registry details and expose them through the WMI registry provider. The last class in the section instructs SMS hardware inventory to query for this class and store it in the site database. This entire MOF section should be added to the end of the existing SMS_def.mof on the site server.


#pragma namespace("\\\\.\\root\\cimv2")
instance of __Win32Provider as $Instprov
{
      Name  ="RegProv" ;
      ClsID = "{fe9af5c0-d3b6-11ce-a5b6-00aa00680c3f}" ;
};
instance of __InstanceProviderRegistration
{
      Provider    =$InstProv;
      SupportsPut =TRUE;
      SupportsGet =TRUE;
      SupportsDelete    =FALSE;
      SupportsEnumeration = TRUE;
};
[dynamic, provider("RegProv"),
ClassContext("local|HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Uninstall")
]
class AddRemovePrograms
{
      [key]
      string      ProdID;
      [PropertyContext("DisplayName")]
      string DisplayName;
      [PropertyContext("Publisher")]
      string Publisher;
      [PropertyContext("DisplayVersion")]
      string Version;
};
#pragma namespace("\\\\.\\root\\cimv2\\sms")
[SMS_Report(TRUE),
      SMS_Group_Name("Add or Remove Programs"),
      SMS_Class_ID("MICROSOFT|ADDREMPROGS|1.0")]
class AddRemovePrograms : SMS_Class_Template
{
      [SMS_Report(TRUE),key]
      string ProdID;
      [SMS_Report(TRUE)]
      string DisplayName;
      [SMS_Report(TRUE)]
      string Publisher;
      [SMS_Report(TRUE)]
      string Version;
};



Note: Additional fields exist in the registry which might be useful. For example, InstallSource provides the path to the server source, InstallDate provides the date the application was installed. These fields can be added to the above MOF file in the same manner as the existing properties.


A WMI query on the site server (that is run as a collection or conventional query in the SMS Administrator console) that searches for computers with Office XP and reports the version would look as follows :


Select sys.Name, off.Version from SMS_R_System as sys


Inner join SMS_G_System_ADDREMPROGS as Off on sys.ResourceID = off.ResourceID


Where off.DisplayName like %Microsoft Office XP%


Appendix C: Frequently Asked Questions


How does the System Files Update relate to the installation of Office XP?


Office XP requires minimum versions of a set of dynamic-link library (DLL) files and other shared and system files. Before installing Office XP on Windows NT Workstation 4.0, Windows NT Server 4.0 and Windows 98, setup verifies that these key system files are current, and, if they are not, updates them automatically from the System Files Update before proceeding with the rest of the installation.


The release versions of Windows 2000 Professional, Windows 2000 Server and Windows Millennium Edition include an equivalent or later level of the key system files required for Office XP. You cannot install the System Files Update or run Internet Explorer Setup from the System Files Update, because the /spforce command-line option has no effect on these operating systems.


If you are upgrading from Office 2000 Public Update 1 under Windows 98 or Windows NT Server 4.0, or Windows NT Workstation 4.0, and you have Internet Explorer 5.01 or later, then your system files are also current. In these situations, you can install Office XP without installing the System Files Update.


Can I send a command line that installs the SFU to clients that already have updated system files (Windows 2000 Professional, Windows 2000 Server, Windows Millennium Edition, Office 2000 Public Update 1)?


Yes. Sending a command line will be successful; however, the program will only detect, not install, the SFU. The Office XP installation will proceed without the SFU, because it is unnecessary to install the SFU again. A restart will occur. For example, if an enterprise upgrading to Office XP has systems that require the SFU and systems that do not require the SFU, then it is possible to use one advertisement, one .mst file, and one command line in the SMS program. This command line (created by the .sms file) must include the SFU portion of the command line. All systems will restart and upgrade to Office XP, including the computers that do not require the SFU. The computers that do not need the SFU will restart unnecessarily, however, this might be an acceptable tradeoff for simplicity in the right conditions.


Why is there a delay when running Office XP advertisements?


A delay occurs because SMS is designed for large enterprises. For scalability reasons, it is not designed to run advertisements immediately. For example, because the SMS client is poll-based, it is important to ensure that delays are not due to a delay in the polling cycle. To understand polling cycles and other built-in delays, see the SMS documentation.


Also, SMS does not run an advertisement until the package is available on the distribution point, and this can take time with large packages. You can check on the availability of the SMS package by viewing the contents of the packages share name, as specified by the administrator creating a custom share name. You can also verify the package state in the SMS Administrator console.


If the administrator specifies a custom share name for the package, the share is placed on the root of the drive with the most available space. If the administrator uses the default share name, the files are created under the Smspkg<drive letter> share. The share size depends on your configuration. The default size has typically been around 625 MB.


Can I suppress all screen display for Office XP distributions?


Yes. The .sms file creates packages that include different command lines. Quiet programs do not require any user interaction. However, the Windows Installer informational dialog box does appear on the screen. If the SMS administrator wants to suppress the Windows Installer screen, this can be accomplished in the command line by substituting /qn for /qb- For complete command-line control details, see 283686, OFFXP: Setup Command-Line Switches, at


https://support.microsoft.com/default.aspx?scid=kb;en-us;283686&sd=tech


Does Microsoft provide application-specific installation and setup information for the applications within Office XP?


Yes. This information is available at


https://support.microsoft.com/default.aspx?scid=kb;en-us;293303&sd=tech


How large is the administrative installation share I create for Office XP?


It is approximately 630 MB; however, this might vary, depending on your environment.


Where are the Office XP Setup log files located?


By default, Office XP log files are located in the %temp% directory on the clients. This can be redirected for reporting or file collection purposes. The log file names reflect the version installed; for example, Office XP Professional with FrontPage setup(0001)_task(0001).txt. The name increments the file name on multiple attempts, so that setup is incremented.


Should I install the retail or enterprise edition of Office XP?


The decision points for this issue are discussed in detail at


https://www.microsoft.com/office/ork/xp/journ/Q&A_0001.htm


How large is the compressed source file (.pkg) that SMS replicates between sites?


It is approximately 350 MB; however, this might vary in your environment.


How much disk space does the SMS site server require, if all Office XP deployment storage is located on the site server?


The administrative installation is approximately 630 MB. The package that is created is slightly smaller. The site server can also store a compressed copy for replication to other sites. This compressed copy is approximately 350 MB. There are also temp files that are associated with the compression activity. It is recommended that the SMS site server have more than 2 GB of free disk space.


What is the size of the transform (.mst) files I create for Office XP?


The size varies with the specific customizations involved, but sizes between 70 KB and 1 MB have been used in some early deployments. All transform files should be included before delivering the SMS package, to minimize the amount network bandwidth that is used with a change in the package source files (and accompanying replication between sites).


Where do I put the .mst and .ops files that the Custom Installation Wizard and Office Profile Wizard install?


Both files go in the root of the administrative share, before the Office XP package is created. Putting all source files in this share before creating the package ensures that when the SMS administrator creates the Office XP package, the files are only replicated once.


How can I stagger installations and decrease network bandwidth usage?


By using the Custom Installation Wizard and selecting less frequently used applications to be installed on first use, you can reduce concurrent network usage for installation of Office XP and reduce the time it takes to install Office XP.


Can I provide a highly customized Office XP deployment that configures tools, templates, and default behaviors?


The Office Profile Wizard provides this support for Office XP Setup. It creates an .ops file, which further customizes Office XP Setup. For information about the Office Profile Wizard and how to easily configure applications with it, see the Office XP Resource Kit.


How do I configure Office XP to be installed locally with certain applications?


Use the Custom Installation Wizard, which sets up and creates the transform file. You can further customize the options within the application.


Where can I learn about the configuration details that are possible for each application in the Office XP suite?


For information about customizing individual applications, see the Office XP Resource Kit.


Is it possible to deploy to one large collection? For example, can I use the Office XP package with the Custom with System Files Update (quiet) program, and advertise the package to the all systems collection?


Yes, this is possible. However, there are several drawbacks. First, computers that are not running Office XP-supported platforms will fail. Also, the administrator would be using the command line that is only necessary where the SFU is required on systems, such as Windows NT Workstation 4.0 and Windows 98, which are not upgrading from Office 2000 Public Update 1. It is easier to deploy all the systems together, and then target one program to run on each system. However, the SFU program incorporates a restart to allow SFU to run. This restart is unnecessary on any client that is running Windows XP Professional, Windows 2000 Server, Windows 2000 Professional, Windows Millennium Edition, or Office 2000 Public Update 1.


What is the relationship between collections and installing Office XP?


Each collection should have a single instance of Office XP installation created by a single Office XP transform (.mst) file. The .mst provides the configuration information for all Office XP installations which use that .mst to guide the installation. Also, the whole collection runs the same program, which must match the SFU and restart requirements for all the clients.


How do I upgrade Office and Internet Explorer as one package, or as a pair of linked packages?


If you want to upgrade your clients version of Internet Explorer, then you must upgrade Internet Explorer separately from your Office XP deployment. You should not chain the installation of these two products together. You can deploy Internet Explorer either before or after you deploy Office XP. Office XP automatically installs Internet Explorer 5.01 during SFU. Installing Office XP does not downgrade Internet Explorer versions that are later than 5.01.


Is Windows Installer required before the installation of Office XP?


No. However, Office XP operation requires Windows Installer 1.1, which is automatically installed during the SFU. Windows Installer 1.1 contains a number of improvements to Windows Installer 1.0, including better upgrade support.


For more information about Windows Installer and SMS, see the following documents:



Where can I get the Office Resource Kit tools?


You can download the Custom Installation Wizard from the Toolbox in the Office XP Resource Kit at


https://www.microsoft.com/office/ork/xp/default.htm


Can I deploy to clients that are running Terminal Services?


You can use SMS 2.0 to deploy Office XP to clients that are running Windows 2000 Terminal Services. For additional information about using Terminal Services with SMS, see the Using SMS 1.2 and SMS 2.0 with Windows 2000 white paper at


https://www.microsoft.com/smserver/techinfo/deployment/20/deploysms/wincompat.asp