microsoft.com Home  
Microsoft
http://www.microsoft.com/office/ork  
Managing a Successive Deployment of Office Premium and Related Products

Staging Your Deployment of Office Premium

When you deploy Microsoft Office 2000 Premium, the simplest method is to deploy all the Office applications together. However, in some circumstances, you might find it necessary to deploy different Office applications or features at different times or by using different methods.

For example, you might have one group in your organization that deploys desktop applications, such as Microsoft Word and Microsoft Excel, and another group that deploys mail applications, such as Microsoft Outlook. The desktop applications group might be ready to deploy Word and Excel immediately, but the mail applications group might need to wait until other mail-related services are ready. In this scenario, you can deploy most Office applications together at one time, and then deploy Outlook later.

Note   This discussion assumes that you are deploying Office by creating an administrative installation point and installing Office on users' computers over the network. When you run Setup with the /a command-line option, Setup creates a hierarchical folder structure into which it copies all the product files. Users run Setup from the administrative installation point to install Office on their computers.

There are three methods that you can use to deploy Office applications in stages.

Deploy Office applications from separate administrative installation points   Install Office Premium on one administrative installation point, and install each separate application on its own administrative installation point. You can deploy some applications from the Office administrative installation point, and then deploy the rest as standalone products.

This method is the most straightforward, and it gives you the most flexibility in configuring the individual applications. However, it uses the greatest amount of disk space on the server computers.

Deploy Office applications from a single administrative installation point   Install Office Premium and each standalone application on a single administrative installation point. You can deploy some applications by using Office Setup from the administrative installation point, and then deploy the rest by using the Setup program specific to the individual application.

This method takes a little more planning to prevent overwriting of duplicate files, but it gives you flexibility in configuring the individual applications and reduces disk space usage considerably on the server computers.

Deploy all Office applications from Office Premium, but use installation options to delay installation of some applications   Install Office Premium on one administrative installation point but set certain features to Not Available. Later, using Setup properties, change the installation state of these features to make them available to users.

This method requires more detailed knowledge of how to customize the installation process, and there are limitations on how you can customize the applications installed later. But with this method you do not have to worry about file duplication issues, and you can manage your applications more efficiently.

Tip   If you use the Profile Wizard to preconfigure Office application settings on users' computers when you install Office, then you need to preconfigure these settings in stages as well. For more information about how to customize the Profile Wizard when you deploy Office in stages, see Customizing the Profile Wizard.

Top

Deploying Office applications from separate administrative installation points

To deploy Office and selected Office applications separately, you can purchase Microsoft Office 2000 Premium plus the individual products you need, such as Microsoft Outlook 2000. Then you can create multiple administrative installation points – one for Office and one for each individual application.

These administrative installation points can be in different folders on one network server, or they can be on separate servers. Files that are common among all Office applications are duplicated on each administrative installation point.

You install Office on users' computers by running Setup from the Office administrative installation point. Using the Office Custom Installation Wizard, create a transform in which you set those applications that you are installing separately to Not Available and Hide. Later you can install the individual applications from their own administrative installation points.

To create separate administrative installation points for Office and individual applications

  1. Run Setup from Office Premium Disc 1with the /a command-line option; when prompted for the server location, enter a folder on a network server. For example:

    \\server1\software\office

  2. Using the Office Custom Installation Wizard, create a transform in which you set the installation state for any application that you want to deploy separately to Not Available and Hide.

    For example, if you are deploying Outlook separately, click the Microsoft Outlook for Windows feature in the Set Feature Installation States panel and select Not Available. Right-click the same feature and select Hide.

  3. Edit the Setup settings file (Setup.ini) to specify the transform that you created.

    For example, if the name of your custom transform is Officemain.mst, add the following line under the [MST] section of Setup.ini:

    MST1=Officemain.mst

  4. Run Setup with the /a command-line option from the CD-ROM for each standalone application that you want to deploy; when prompted for the server location, enter a unique folder for each product. For example:

    \\server1\software\outlook

    You can install each product in a separate folder, or you can create a single network share and designate a subfolder for each application.

Tip   In the Setup settings file, the [MST] section is included by default, but the line is commented out. When you specify a transform, be sure to remove the semicolon (;) from the beginning of the [MST] section.

After you create the administrative installation point for Office, users can install Office by running Office Setup from that administrative installation point. Users can then install each individual application by running Setup from that application's administrative installation point.

When you maintain separate administrative installation points, keep in mind the following.

Common Office application files duplicated on the server

Because Office applications are highly integrated, they share a number of files in common. For example, all Office applications use the same set of Office Assistant files. When you create an administrative installation point for Office, Office Setup copies all of these common files to a single location on the server where the applications can share them.

When you create a separate administrative installation point for an Office application, the Setup program for that application copies many of the same files to a different location, duplicating the files on the server.

Duplicate copies of Mso9.dll loaded into memory

All Office applications share the dynamic-link library (DLL) Mso9.dll. When you run an Office application, it loads Mso9.dll into memory. When you run an Office application from the network server, the application attempts to load Mso9.dll from the administrative installation point.

When you run two Office applications simultaneously, they each attempt to load Mso9.dll into memory. If they load the DLL file from the same folder, Windows detects that they are loading the same file and only loads it once.

When you run two Office applications from separate administrative installation points, however, the applications attempt to load Mso9.dll from different folders. In this case, Windows assumes that they are requesting different files and it loads both copies of Mso9.dll into memory. Because Mso9.dll uses approximately 5 MB of memory when loaded, running more than one Office application in this configuration uses memory needlessly.

Note   When you install the Office applications locally to the same location on the user’s computer, then the Setup program for each application installs Mso9.dll to the same folder. When you run two applications simultaneously, Windows loads only one copy of Mso9.dll into memory, even if the applications were installed from different locations on the server.

Top

Deploying Office applications from a single administrative installation point

A more advanced method for deploying some Office applications separately is to create a single administrative installation point on a network server that includes both Office and the separate Office applications. You create the initial administrative installation point using Office Setup, and then you install each individual application into the same folder structure.

This method saves disk space because files that are common among all Office applications are shared on the single administrative installation point. However, Office and each individual application use the same names for Setup files - namely, Setup.exe, Setup.ini, Setup.hlp, Data1.msi, and Autorun.inf. So you must take steps to avoid overwriting Setup files when you install the individual applications after installing Office on the administrative installation point.

Creating an initial administrative installation point for Office

You begin by creating an administrative installation point for Office on a network share and providing unique names for the Setup files.

To create an initial administrative installation point for Office

  1. Run Setup from Office Disc 1with the /a command-line option; when prompted for the server location, enter a folder on a network server. For example:

    \\server1\software\office

  2. Using the Office Custom Installation Wizard, create a transform in which you set the installation state for any application you want to deploy separately to Not Available and Hide.

    For example, if you are deploying Outlook separately, click the Microsoft Outlook for Windows feature in the Set Feature Installation States panel and select Not Available. Right-click the same feature and select Hide.

  3. In the root folder of the administrative installation point, rename Setup.exe, Setup.ini, Data1.msi, and Autorun.inf to prevent these files from being overwritten when you install the separate applications.

    Use similar file names and include the appropriate file name extensions. For example:

    OffSetup.exe, OffSetup.ini, OffInst.msi, and OffAuto.inf.

  4. Edit the Setup settings file (Setup.ini) to specify the transform that you created plus the new names for the MSI and Autorun.inf files.

    For example, add or edit the following lines in the settings file to indicate the new file names:

    [MSI]
    MSI=OffInst.msi
    [MST]
    MST1=Officemain.mst
    [Autorun]
    autorun.inf=OffAuto.inf

To install Office from this administrative installation point, run Office Setup by using the Setup program file name you created. Setup automatically searches for the Setup settings file with the same file name as the Setup program. For example, if you renamed Setup.exe to OffSetup.exe, Setup looks for OffSetup.ini. Setup uses this settings file to find the correct MSI, MST, and Autorun.inf files.

Installing individual applications on the Office administrative installation point

When you are ready to deploy an individual Office application separately, you can install the application on the same administrative installation point that you created for Office.

To install an individual application on the Office administrative installation point

  1. Temporarily rename Setup.hlp to prevent it from being overwritten.

    For example, rename Setup.hlp to OffSetup.hlp.

  2. Run Setup with the /a command-line option from the standalone product CD-ROM. When prompted for the server location, enter the same folder on the server where you installed Office. For example:

    \\server1\software\office

  3. In the root folder of the administrative installation point, rename Setup.exe, Setup.ini, Setup.hlp, Data1.msi, and Autorun.inf to prevent these files from being overwritten when you install the separate applications.

    Use similar file names and include the appropriate file name extensions. For example:

    OlkSetup.exe, OlkSetup.ini, OlkSetup.hlp, OlkInst.msi, and OlkAuto.inf.

  4. Edit the Setup settings file (Setup.ini) to specify the transform that you created plus the new names of the MSI and Autorun.inf file.

    For example, add or edit the following lines in the settings file to indicate the new file names:

    [MSI]
    MSI=OlkInst.msi
    [Autorun]
    autorun.inf=OlkAuto.inf

  5. In the root folder of the administrative installation point, rename the original Office Setup.hlp file back to Setup.hlp.

    For example, rename OffSetup.hlp to Setup.hlp.

To install an application from this administrative installation point, run Setup by using the Setup program file name that you created. Setup automatically searches for the Setup settings file with the same file name as the Setup program. For example, if you renamed Outlook Setup.exe to OlkSetup.exe, Setup looks for the settings file named OlkSetup.ini. Setup uses this settings file to find the correct MSI and Autorun.inf files. (Setup uses the Office version of Setup.hlp for the Help command.)

Top

Changing installation states after Office installation

Another method for deploying Office applications separately involves creating a single Office administrative installation point, installing Office with specific features set to Not Available, and later adding those features to the user's computer by rerunning Office Setup to change the installation states.

Rerunning Setup interactively on users’ computers

After you install Office on a user's computer, you can run Setup interactively again to change the installation state of the Office features that you set to Not Available during your initial installation. When you rerun Setup after Office is installed, Setup runs in maintenance mode.

Depending on the new installation state you choose for a feature, Setup uses the source files on the original administrative installation point and copies the appropriate files to the user's computer, creates shortcuts, or prepares the feature to be installed on first use.

For example, if you set the installation state for Microsoft Outlook for Windows to Not Available in your initial Office deployment, but you have now upgraded your e-mail services and want to deploy Outlook 2000, you can rerun Setup in maintenance mode. Now you can set Microsoft Outlook for Windows to Run from My Computer, and Setup installs Outlook on users' computers.

Using the Setup command line or settings file

As an alternative to running Setup interactively on users' computers, you can also change the installation state of any feature by using Setup properties in the Setup command line or settings file (Setup.ini).

For example, to set Outlook to Run from My Computer, you can use the following command line:

setup.exe ADDLOCAL="OUTLOOKFiles"

Or you can add these lines to the Setup settings file:

[Options]
ADDLOCAL=OUTLOOKFiles

In the Setup command-line or in Setup.ini, you can use the following Setup properties to change the installation states of features after Office is installed.

Setup property Corresponding installation state
ADDLOCAL Run from My Computer
ADDSOURCE Run from CD or Run from Network (depending on the location of the source files)
ADVERTISE Installed on First Use
REMOVE Not Available

For each Setup property that you set, you must specify a list of feature IDs, separated by commas and no spaces. Each feature displayed in the Setup feature tree is defined in the MSI file with a unique feature ID. For example, the feature Microsoft Binder is defined in the MSI file as BinderFiles. You must use the feature ID and not the feature title that is displayed in Setup. (You can also use the keyword ALL, without a list of feature IDs, to specify all features.)

Feature IDs are case-sensitive and must be entered exactly as they appear in the MSI file. If you misspell a feature ID, or insert a space between feature IDs, Setup displays an error message and terminates. In this case, you can just correct the feature IDs you specified and try again.

Toolbox   The Office Resource Kit includes a workbook named FileList.xls that contains information for all Office features, including the feature ID associated with each feature. In the workbook, the Feature Title column shows the text displayed by Setup in the feature tree, and the Feature Name column shows the feature ID defined in the MSI file. For information about installing FileList.xls, see Office Information.

You can set any combination of these properties in the Setup command line or settings file. For example, you can use the following command line to change the states of Microsoft Binder and Microsoft Binder Help to Installed on First Use and Office Assistant Dot to Run from My Computer:

setup.exe ADVERTISE="BinderFiles,BinderHelpFiles" ADDLOCAL="ASSISTANTDot"

You can accomplish the same thing with the following lines in the settings file:

[Options]
ADVERTISE=BinderFiles,BinderHelpFiles
ADDLOCAL=ASSISTANTDot

Tip Use the settings file if you want to set several property values. The settings file does not have the same length restrictions as the Setup command line (which is limited to 255 characters on some systems). The settings file also allows you to organize the list of properties and feature names more easily. Remember to remove the default semicolon (;) preceding the [Options] section name.

Differences between using Setup properties and running Setup interactively

Setting a Setup property on the command line or in the Setup settings file is equivalent to running Setup interactively and selecting the corresponding installation option in the feature tree. However, there are some exceptions.

When you run Setup interactively, Setup does not allow you specify an installation state that the feature does not support. However, when you use Setup properties, you can specify a state that the feature does not support. In this case, Setup ignores your setting.

When you run Setup interactively and change the installation state of a feature, Setup usually changes the state of any child features to match. However, when you use Setup properties, Setup changes only the state of the feature. (In a few cases, when the child feature is tightly dependent on the feature that contains it, Setup does change the child feature.) To ensure that all features are installed the way you want, you must specify every feature and child feature whose state you want to change.

Example: changing installation states for selected Outlook features

Suppose you are ready to deploy Office 2000, but you want to delay your deployment of Outlook so that you can synchronize with the department that handles e-mail systems. In this scenario, you can deploy Office to users' computers without Outlook. Later, when the mail system has been upgraded and you are ready to deploy Outlook, you can rerun Setup on users' computers. At that stage, you can finetune your Outlook deployment to install a subset of Outlook features in the following installation states.

Outlook feature Installation state
Outlook Run from My Computer
Outlook Help Run from My Computer
Importers and Exporters Installed on First Use
Stationery Run from Network
Junk E-mail Installed on First Use
Net Folders Run from My Computer
All remaining features Not Available

You can run Office Setup on each user's computer to modify the installation states of these Outlook features. A more efficient alternative, however, might be to change the installation states of Outlook features by using the following procedure.

To deploy selected Outlook features after installing Office

  1. When you install Office on the user's computer, set the installation state for the Microsoft Outlook for Windows feature to Not Available.

    This step removes Outlook and all its child features from the installation.

  2. When you are ready to deploy Outlook, copy the Setup.ini file on the administrative installation point to Outlook.ini.
  3. Edit the new Outlook.ini file and add the following lines:

    [Options]
    ADDLOCAL=OUTLOOKFiles,OutlookHelpFiles,OutlookFolderPublishing
    ADDSOURCE=OutlookStationeryFiles
    ADVERTISE=OutlookImportExportFiles,AntiSpam

  4. Run Setup on the user's computer, specifying the new INI file with the /settings command-line option.

    For example,

    setup.exe /q+ /settings Outlook.ini

Setup updates the installation states of the features you specified on the user's computer. Setup copies the Outlook program files and Help files to the user's computer, configures the system to access the stationery files from the administrative installation point, and prepares the import/export files and junk e-mail files to be installed the first time they are used.

To verify that the changes occurred correctly, run Setup interactively, click Add or Remove Features, and examine installation states for these features in the feature tree.

Top

See also

Office 2000 Setup provides you with a lot of flexibility for installing Office. For more information, see How to Install Office on Client Computers.

By installing Office on an administrative installation point on a network server, you can more easily customize and manage your Office deployment. For more information, see How to Create an Administrative Installation Point.

For more information about how to distribute a customized Setup command line or settings file to your users, see Customizing How Setup Runs.

The Office Custom Installation Wizard allows you to fully customize your Office installation. For more information, see Office Custom Installation Wizard.



Top


Friday, March 5, 1999
© 1999 Microsoft Corporation. All rights reserved. Terms of use.

License