In November 2006, Microsoft released the latest version of its Office productivity suite, the Microsoft Office 2007 system. Office 2007 boasts an entirely redesigned and significantly improved UI, as well as a host of client- and server-side functionality changes that offer real business value to customers who are ready to invest their resources into implementing and leveraging Office 2007's new features. However, Office 2007's deployment is very different from that of previous Office versions, and many customers won't be able to use the processes and tools that they've used in the past to deploy Office. If you're considering unleashing Office 2007 in your environment, you need to know how to prepare an installation that's configured to the specifications of your organization, and what your options are for deploying Office 2007 to your client computers.
The Big Picture
Unlike previous versions of Office, which you could install by using either setup.exe or the single behemoth Microsoft Windows Installer package (.msi file), Office 2007 is installed using individual .msi files for each application, driven by an .msi file for the product (e.g., Microsoft Office Enterprise 2007, Office Professional 2007), which is driven by setup .exe. With a few exceptions, you can't install an Office 2007 application by launching the .msi file with standard Windows Installer switches. Instead, you have to launch setup.exe manually or by using an automated software-installation mechanism such as Microsoft Systems Management Server (SMS).
You can store setup.exe, the .msi files, and all other files related to the Office 2007 installation on the product's CD-ROM or DVD media, or in a shared folder on your network, which Microsoft now refers to as a network installation point. I'll refer to the product's CD-ROM or DVD media or the network installation point as your distribution source. One of the first things setup .exe does is launch the Office Source Engine (ose .exe), which copies the files from the distribution source to a cache (called the local installation source) on the disk on which you're installing Office 2007. By default, this local installation source is C:\MSOCache\All Users. Then, Setup launches Windows Installer, which uses the locally cached files to install Office 2007.
In previous Office versions, the local installation source was optional. However, to install Office 2007, you're required to have one—a nice feature because when it comes time to update or repair Office 2007, you'll need the local installation source to do so. The local cache is resilient: If it's corrupted or deleted (which is difficult to do, particularly for nonadministrative users), it will be rebuilt the next time the distribution source is available. Note that the size of the local installation source (Office Enterprise 2007 is approximately 530MB) is included in Microsoft's disk-space requirements for Office 2007 products.
You can use the Office Customization Tool (OCT) to create a Setup customization file (.msp file). During installation, setup.exe applies settings in the Setup customization file, as well as all Office 2007 patches and updates. Setup also uses an XML file, config.xml, to determine its behavior. You can use this file to customize many of Office 2007's setup properties. However, to configure these properties, you should instead use the Setup customization file, which offers greater functionality and flexibility, as you'll see as we explore the OCT, Setup customization files, patches and updates, and config.xml in more detail.
Now that I've introduced some of Office 2007's fundamental processes and terms, we can begin configuring it for deployment.
Step 1: Create a network Installation Point
In an enterprise setting, a network installation point is a desirable location for installation files because it lets you centrally manage the customization, distribution, and deployment of Office 2007. Even if you're using CD-ROMs or DVDs to deploy Office 2007, you'll want to consider creating a network installation point so that you can perform all customizations, then burn the resulting contents of the network installation point to a custom CD-ROM or DVD.
To create a network installation point, you first need to create a folder that's accessible to users who will be installing Office 2007. This folder can be a shared folder or a folder within a share. You should apply least-privilege permissions to make read access available to users. For example, you could create a security group called Office 2007 Installation with Read & Execute permissions to the distribution folder.
In large or distributed organizations, it's wise to maintain several network installation points that contain the Office 2007 distribution. You can synchronize network installation points by using a variety of replication technologies, such as File Replication Service (FRS), DFS Replication (DFSR), Robocopy, or Double-Take.
Whether you have one or multiple network installation points, I recommend configuring access to your Office distribution(s) by using Microsoft's DFS rather than server-based Universal Naming Conventions (UNCs), such as \\server\Software\Microsoft\Office2007. DFS lets you create a virtual folder hierarchy that presents network resources in a namespace that abstracts the physical location of the resources. For example, you could create a DFS namespace that would create the folder path \\domain\Software\Office2007, which is a virtual path representing one or more Office 2007 network installation points. Because DFS is integrated with Active Directory (AD) and is site aware, it's a best practice for software distribution. Clients will automatically be connected to the server that's closest to them: either within your site or in a nearby site, based on site-link costs.
Try to avoid using spaces in the UNC path to your Office 2007 network installation point. When issuing commands, such as setup.exe, spaces in paths require you to surround the path with quotation marks. So, keep the path simple, such as "\\domain\[or server\]\path\ Office2007," or spaceless.
Step 2: Copy the Contents of the office Product to the
network Installation Point
Unlike previous versions of Office, Office 2007 doesn't let you create an administrative installation point (the equivalent of Setup /a in Office 2003 or earlier). Instead, you simply copy the contents of the product's CD-ROM or DVD media directly to a folder on the network. The result is a compressed distribution.
Microsoft did a great job of simplifying the management of an Office 2007 distribution. If you're installing other Office 2007 products (e.g., Microsoft Office Visio 2007), you can copy the contents of that CD-ROM or DVD to the distribution folder. When prompted to overwrite duplicate setup files, click No. The files are shared, so it will be faster if you skip files that already exist. The resulting distribution will be smaller than the total combined size of each product's distribution.
Office 2007 has a language-neutral core, meaning that you can easily add languages by copying the Single Language Packs that you need into your distirbution. Again, if you're prompted to overwrite duplicate setup files, click No because those files are also shared. The system will copy only the language-specific files.
When setup.exe runs, it detects the locale of the computer and uses that information to determine which language to install. When ose.exe copies the distribution to the local installation source (MSOcache), it copies only the language-neutral core files and the files for the selected language—it doesn't copy the files for languages that aren't in use on the system. You don't need to do anything other than copy the Single Language Packs into your distribution to ensure that your Japanese users get the Japanese version of Office 2007 and your French users get the French version.
Step 3: add Updates
Another elegant feature of Office 2007 deployment is the Updates folder, which is located immediately underneath the root of the Office 2007 distribution. Setup will automatically apply any .msp files in the Updates folder, so you can add Office 2007 patches and updates—including security updates—to the Updates folder, and they'll be applied during product installation, resulting in an initial configuration that's as secure and up-to-date as possible. So, if your organization is deploying security updates and patches, such as the latest Microsoft Office Outlook Junk E-mail Filter or the latest fixes for the most recently discovered vulnerabilities, just add the .msp files that you've obtained (e.g., from Microsoft Update) to the Updates folder in your distribution.
Step 4: Customize office 2007
To customize previous versions of Office, you would use the Custom Installation Wizard (CIW), a tool that Microsoft distributed as part of the Microsoft Office 2003 Resource Kit (ORK). The CIW saves customizations as a transform file (.mst file). Microsoft replaced the CIW with the OCT—which is part of setup.exe—in Office 2007. Customizations are now stored in a Setup customization file.
To customize Office 2007, launch setup.exe with the /admin switch. The software will then prompt you to select which product you want to customize. The product list is generated dynamically based on the products you've copied to the distribution folder. Once you've selected the product you want to customize, the OCT will appear. The OCT, which Figure 1 shows, lets you configure most of Office 2007's common properties. For an automated deployment of Office 2007, you should consider at least the following:
• Configure the path to which Office 2007 should be installed on clients, which is \[ProgramFilesFolder\]\Microsoft Office, by default. Enter the path in the Default installation path field on the OCT's Install location and organization name page. The predefined keyword \[ProgramFilesFolder\] represents a client's Program Files path.
- Enter your organization name in the Organization name field on the OCT's Install location and organization name page.
- Input your 25-character volume license key in the Product key field on the OCT's Licensing and user interface page. You can't use retail product CD-ROMs and keys to deploy Office 2007 products to multiple machines, so retail products don't support preconfigured installations with the OCT.
- Accept the license agreement on the OCT's Licensing and user interface page by selecting the I accept the terms in the License Agreement check box. If you enter a product key and configure the Display level to Basic or None, you're implicitly agreeing to the EULA and the user won't be prompted to accept the license agreement, regardless of whether you select the I accept the terms in the License Agreement check box.
You'll also need to configure the Display level on the Licensing and user interface page, as you see in Figure 1. By default, Setup runs interactively, letting users make choices during installation. If you're deploying Office across an organization, you'll most likely want to limit or eliminate user interaction so that setup is automated and configuration is applied consistently. Your display level choices are as follows:
- Full (default)—Users will see the normal Office 2007 installation dialog boxes and will be able to make changes to the default settings you've specified in the Setup customization file. This display level is useful in environments in which you want to set defaults and let users modify them.
- Basic—Users will see the Welcome page, a progress bar, and error messages. If a product key or EULA agreement hasn't been configured in the customization file, users will be prompted accordingly. Otherwise, users won't be prompted and won't be able to make any changes to settings.
- None—Setup runs silently, meaning users won't be able to modify the configuration of Office 2007.
There are three additional options regarding the UI during installation. These options are available only in the Basic display level. (The Full and None display levels don't have these options.)
- Completion notice—A message appears when Office 2007 installation is complete.
- Suppress modal—During installation with the Full display level, all errors are reported. With display levels Basic or None, this option prevents error messages and other dialog boxes from appearing and interrupting installation, although any errors will still be logged for postmortem failure analysis.
- No cancel—This option removes the user's ability to cancel installation by clicking the X in the corner of the installation window during installation with the Full or Basic display level.
When you're done configuring Office 2007's properties, select File, Save, and save the Setup customization file with a unique name. If this Setup customization file is the only one you'll be using for the distribution, save the file in the Updates folder—setup.exe will recognize it and apply it automatically. If you want to store all updates in a folder at the root of the Office 2007 distribution other than the Updates folder, you can use the config.xml file to specify its location by configuring the SUpdateLocation attribute of the SetupUpdates element.
If your organization will have more than one Setup customization file, save the files in a folder other than the Updates folder; otherwise, Setup won't be able to determine which customization file to apply. I recommend creating a folder named Customizations in the root of the Office distribution. For example, you might have a Setup customization file—sales.msp—that installs Microsoft Excel, PowerPoint, and Word on your sales department clients, and another—finance .msp—that installs those applications, as well as Microsoft Access, on your finance department clients. Save each of these .msp files in a folder such as \Office2007\Customizations. When you launch setup.exe, use the /adminfile switch, followed by the fully qualified path to the correct Setup customization file—for example, setup.exe /adminfile \\intelliem\ softwareOffice2007\Customizations\finance .msp.
There are several additional customizations available in the OCT, including the following:
- Additional network sources—You can configure paths to each valid network installation point. When a feature is installed on demand, or if the local installation source gets corrupted and needs to be regenerated, Office 2007 will look for network installation points in the order specified in this list. Note that you typically won't use Additional network sources if you're using DFS to create a virtual namespace. Instead, the DFS path you used to install Office 2007 will simply target multiple replicas of the network installation point. The software will use that same path during the installation of new features or the regeneration of the cache.
- Remove previous installations—By default, Setup will remove previous versions of Office applications. However, Office 2007 applications—with the exception of Outlook 2007—can coexist with previous versions of Office applications on a system. You can change the configuration in this section of the OCT to preserve previous versions of Office.
- Set feature installation states—You can configure which applications are installed, which are copied to the local installation source but not installed until first use, and which aren't available for installation. The feature tree in the left pane of the Set feature installation states page behaves similarly to feature sets in earlier versions of Office.
- Modify user settings—Note that the settings in the left pane of the Modify user settings page can also be configured using Group Policy. The difference is that Group Policy settings can be enforced so that they stay consistently configured. Settings configured during installation create defaults, which users can later change. Each method of Office 2007 configuration has a role in creating a productive and consistent, yet flexible, user experience. If you're also installing Outlook 2007, the settings in this section will let you drive its configuration.
- Add installations and run programs—Setup lets you execute additional commands during installation, either before or after the Office product has been installed. To chain installations of multiple products (such as Office Enterprise 2007 followed by Visio 2007), see the Microsoft article "Sequentially install multiple products of the 2007 Office system" at http://technet2.microsoft.com/Office/en-us/library/e6536245-0f424904-b2e0-9168fd6b81d41033.mspx. Note, however, that this article recommends that you not chain installations, but rather install each product separately. (I agree with this recommendation.) I also recommend using the run programs capability after setup is complete to deploy Microsoft's Save as PDF or XPS add-in, and launching, after installation, a Web site on your intranet that introduces your users to Office 2007 and makes resources available in your organization to support your users and help them succeed.
- Add files—Finally, the OCT lets you specify which files to copy during installation. Use the Add files feature to copy your organization's custom Office templates and Windows Rights Management Services (RMS) templates to users' systems.
One nice tweak that Microsoft made to the Office deployment process is that you no longer need to launch Setup with the NOUSERNAME switch. Now, Setup instructs Windows Installer not to capture a username. Instead, Office 2007 prompts the user for his or her username the first time an Office application is launched.
Step 5: Configure config.xml
To drive its behavior, Setup uses an XML file, config.xml, which can contain several settings that customize Office 2007. By default, config .xml is stored in the folder corresponding to the Office 2007 product being installed. For example, a distribution for Office Enterprise 2007 contains a folder named Enterprise .WW. By default, setup.exe, in the root of the distribution, will use the config.xml file in the Enterprise.WW folder. If more than one product exists in the distribution, and if Setup is launched interactively, Setup will prompt you for which product you want to install and use the corresponding config.xml file.
To automate the installation of Office 2007, run setup.exe, and if there are multiple products in the distribution, use the /config switch to point to the config.xml file for the specific product you're installing—for example, \\domain\ software\Office2007\setup.exe /config\\domain\software\Office2007\Enterprise .WW\config.xml. If you have one or more custom configuration files in a location, or if the file uses a name other than config.xml in the product folder, you'll also have to use the /config switch to specify which configuration file to use. I highly recommend storing all customized config.xml files in a special folder in the root of your Office distribution.
You can use the OCT to configure the vast majority of settings in config.xml and save them in a Setup customization file. When a setting can be configured in both config.xml and the Setup customization file, it's best to configure it in the Setup customization file. You'll find that in most cases, you'll have to change config. xml only to perform the following:
- Add or remove languages. By default, setup .exe will detect the locale of the client and install the correct language from the distribution. If you want to override this behavior and install additional languages, use config. xml.
- Specify the path to the network installation point. If you customize a configuration file and store it with a name other than config .xml or in a folder other than the product folder, you'll need to use the DistributionPoint element to point to the network installation point. I recommend configuring this element for any customized configuration file.
- Instruct setup.exe to create the local installation source (MSOcache) but not to continue with the installation of Office 2007. Set the CACHEACTION element of the LIS element to CacheOnly.
- Configure the path in which Setup creates log files and the detail of the logs. By default, Setup logs many—but not all—installation actions to a log in the \%TEMP% folder. You might choose to direct logs to a central location for analysis, particularly if you're deploying Office 2007 to multiple systems. Use the Logging element of config.xml. Be sure that the central location has permissions that enable writing to the folder. You must use the /config switch to point to the configuration file; otherwise, setup.exe will ignore logging settings in the file.
- Direct setup.exe to look for updates in a folder other than Updates in the root of the distribution, using the SUpdateLocation attribute of the SetupUpdates element, as described earlier in this article.
To configure any of these settings, you can uncomment the sample lines in the default config.xml file by removing the "!<--" before the XML element and the "-->" after the element. You can then configure the attribute of the element. Also, be very careful about the case sensitivity of elements and attributes. Even some values seem to be case sensitive, despite documentation to the contrary, so it's best to just assume that everything is case sensitive.
You probably won't need to tweak config .xml. If you do, consider storing your customized configuration file in a folder dedicated to customizations, configure the DistributionPoint element, and use the /config switch on the setup.exe command to point to the file.
Step 6: Deploy office 2007
So, you've created a network installation source by copying the product's CD-ROMs or DVDs and updates to a folder; you've configured at least one Setup customization file with the OCT; and you've made any necessary changes to config.xml. To launch an Office 2007 installation from a client, simply run setup.exe from the network installation point. (You can also copy the contents of your network installation point to a custom CD-ROM or DVD.) Use the /adminfile switch to point to your Setup customization file, unless you have only one and you've stored it in the Updates folder, in which case it will be detected automatically. Use the /config switch to point to your configuration file—your tweaked config.xml file—unless you changed the default config.xml file in the product folder (e.g., Enterprise.WW).
Now, how do you push the installation out to multiple clients? According to Microsoft, you simply "run setup.exe on each client computer." But what does that entail, exactly? You need to have Windows Installer 3.1 (which has been available as a required Windows Update for quite some time) or later installed on each system, and the user who launches setup .exe must be an administrator on the local machine.
If a user is an administrator, Microsoft suggests using an automated method to execute setup.exe, such as a logon script. In another set of documents, Microsoft suggests using software-deployment mechanisms such as SMS to deploy Office 2007. For those of you with SMS, see the Microsoft article "Using Systems Management Server 2003 to deploy the 2007 Office system" at http://technet2.microsoft.com/Office/en-us/library/e3d7be86-d739-413f-8196-817899eceb771033.mspx.
Although three previous versions of Office could be deployed through Group Policy software installation, Office 2007 can't. Now, you might hear that you can use Group Policy to deploy Office 2007, and Microsoft even has documents discussing the methodology. But I can tell you from lots of testing that deploying Office 2007 with Group Policy isn't a practical option even if it's a technical option: It just doesn't support the kind of functionality and customization that organizations need. Microsoft has in fact pulled documentation detailing the Group Policy deployment of Office 2007 from its Web site, which could be a sign that Microsoft is disavowing support for that option.
So, polish up your scripting, be creative, or shell out for a commercial-grade software-deployment tool. Run setup.exe by using credentials with Administrator- or System-level capabilities. Use the /config switch to point to a custom configuration file, and the /adminfile switch to point to a custom Setup customization file (.msp file).
In a future article, I'll share some specific guidance and workarounds that will help you deploy Office 2007 without SMS. I'll even share insights into the limited circumstances under which you can deploy Office 2007 using Group Policy.
Let Microsoft Know
While you wait to read the upcoming article, contact Microsoft. Share your thoughts about the Office team disavowing an important Windows technology and creating a deployment scenario that requires administrative credentials or additional tools. Whether the lack of support for native software-deployment technologies is a showstopper for you (and it won't be once you read the future article), Microsoft needs to be reminded by its customers that it should be playing by its own rules, and fully supporting key technologies across product groups.