Microsoft Office is a large, complicated set of applications, with lots of knobs and switches to configure. Fortunately, you can use Group Policy to take control of the suite's deployment and configuration. However, using Group Policy to manage Office can be challenging, especially if you're trying to deploy and manage the new Office 2007 system.
Perhaps you've never used Group Policy to deploy Office. If so, you've come to the right place. What follows is a primer for deploying the various versions of the product. As you'll see, the process has changed significantly—although not for the better—for Office 2007. Also, if you need to know how to use the Microsoft-provided Administrative Templates (.adm) files to lock down your Office deployments, this article might prove extra useful. I'll wrap things up with a look at what third-party vendors are doing to help add configuration capabilities for Office through Group Policy.
There are several ways you can deploy Office to your end users. For example, you might decide to "bake" Office right into your standard desktop-imaging process so that Office is automatically present when you set up a new workstation. You can also use a software-distribution package such as Microsoft Systems Management Server (SMS) to deploy it. Or, as you might guess, you can use the Group Policy Software Installation feature to deploy Office.
Using Group Policy to deploy Office has two advantages over the other two deployment methods. The first advantage is that Group Policy is included "in the box," so you don't necessarily need to buy and deploy a complicated software-distribution product if your needs are basic. Another advantage is that deploying applications via Group Policy Software Installation lets you manage the application's full life cycle—from initial deployment to updating to removal. That's something you don't get by baking Office into an image. So, what does it take to deploy Office via Group Policy?
The following deployment method for using Group Policy Software Installation for Office deployment applies to Office 2003, Office XP, and Office 2000. As we go through this process, keep in mind that Microsoft has made some significant—and not necessarily positive—changes to this process in Office 2007. I'll discuss those changes shortly. But first, I'll walk you through the prototypical Office 2003 Professional deployment.
1. The first thing you need to do is place the Office installation files on a server share where your clients can find them. Doing so isn't just a matter of copying the CD-ROM files to a server share. To perform a proper deployment, you need to run an administrative installation of Office. Open a command prompt, and change to the Office installation CD-ROM folder in which setup.exe resides. From the command prompt, type
setup /a
to begin an administrative installation.
2. In the Install Location box, enter a server share and folder where you want the Office installation files to reside. You'll also need to enter the product key here. I recommend that you use a DFS share to host your application packages. A DFS share lets you move the underlying package around between servers without having to change the path in the Group Policy Object (GPO) where the package is deployed. This functionality is important because the path is hard-coded on each client that installs an application through Group Policy Software Installation, and a change in the package path triggers a reinstallation of the deployed application.
3. After Office is deployed on the server, you need to ensure that both the share and NTFS permissions on the installation folder allow all the target computers or users to read the application setup files. To do so, grant the built-in Authenticated Users group the Read permission on the share and folders.
4. Now, you need to deploy the package in a GPO. First, decide whether you want to deploy the package per computer or per user. If you choose a per-user deployment, you'll need to determine whether you want to publish it or assign it. The differences between publishing and assigning are simple. By assigning an application, you're telling Group Policy to install the application at user-logon time. By publishing it, you're essentially saying that installation is up to the user, who must start the Control Panel Add/Remove Programs applet and explicitly choose to install Office. For most scenarios, assignment is preferable to publishing.
For the sake of this article, we'll perform a per-computer assignment of Office; the software will be installed during the next computer reboot and will be available to all users on a given computer. Open Group Policy Editor (GPE) on a GPO linked to the computer objects in Active Directory (AD) where we want to install Office and drill into the Computer Configuration\Software Settings\Software Installation node. Right-click the node, and choose New, Package. Next, enter the path to the Windows Installer setup file for Office 2003—in my example, it's the file called pro11n.msi.
Note that when you enter the path, you need to type the Universal Naming Convention (UNC) path for the .msi file, as Figure 1 shows, rather than navigating to the file directly in the file system. This requirement is necessary because the path is stored in the GPO for the package and is referenced by all clients that process the package. Therefore, the path needs to point to a relative location—in this case, the DFS share in which my packages are stored—rather than an absolute path such as D:\packages\ Office2K3\pro11n.msi.
5. After you choose the path to the package, a dialog box prompts you to decide whether you want to assign the package or select the Advanced options to set more properties on the deployment.
This is a key decision point. Choosing Advanced options in Office 2003 and earlier lets you use transforms to customize your Office deployments. A transform is a special version of an .msi file—an .mst file—that modifies the setup instructions of the original install package as it's installed and is applied when you deploy a package using Group Policy Software Installation. After the package is deployed, you can't go back and add the transform, so you must add it at initial deployment.
You create transforms for Office 2003 by using the Custom Installation Wizard in the Microsoft Office 2003 Resource Kit. You can create a transform that controls which Office applications and options are installed, which folder Office is installed in, which default options are set within each Office application, and so on. You create a transform outside of GPE—using the Custom Installation Wizard—so you should create the transform ahead of time, before you're ready to deploy your Office package. After creating a transform file, you copy it to the folder in which your Office setup files reside.
At this point in the package deployment, if you decide to use a transform, you must choose the Advanced option instead of Assign to add the transform to the deployment package. After choosing Advanced, make sure that the package is shown as Assigned on the Deployment tab (it should be the only option for a per-computer deployment), then select the Modifications tab, which Figure 2 shows, to add the transform file to the package. Click OK to complete the package deployment.
That's all there is to performing a per-computer deployment of Office 2003. After the computer reboots, the Office 2003 installation will commence and Office will be installed when the user goes to log on to the computer. Now, let's look at how Office 2007 changes this process.
In Office 2007, Microsoft has changed the deployment methods, especially with respect to deployment via Group Policy Software Installation. Not all of these changes are for the better, and I would say that if you're thinking about deploying Office 2007 via Group Policy Software Installation, you should consider alternative deployment options such as SMS. Here's what has changed:
- You no longer run an administrative setup to get the Office 2007 files to your deployment server share; instead, you simply copy the contents of the Office CD-ROM directly to the server share.
- Office 2007 no longer supports per-user deployments via Group Policy Software Installation—only per-computer deployments.
- Office 2007 no longer supports transforms for customizing Office deployments. A file called config. xml, which ships with the Office installation files, supports a few customizations for use with Group Policy Software Installation—but not nearly as many as you could perform with the Custom Installation Wizard in the earlier versions of Office. Office 2007 does provide such granular capability with the use of .msp files and the Office Customization Tool, but these customizations aren't available during Group Policy Software Installation deployment of Office 2007. With the config.xml file, however, you can customize such things as the product key, the deployment location of Office on the target computers, and the selection of Office applications or features that get installed. I give an example of what one such config.xml file looks like in my blog post at http://blogs.dirteam.com/blogs/gpoguy/archive/2007/01/29/what-were-they-thinking-the-office-product-team-strikes-again.aspx. This config. xml file should be customized prior to deploying Office via Group Policy Software Installation, and you'll need to create a different Office installation share for each config.xml file you wish to deploy.
- An Office 2007 installation using Group Policy Software Installation isn't entirely unattended. After the initial installation of Office, users logging on to their system for the first time could be confronted with an Office configuration utility, which performs a set of post-deployment configurations and then logs the user off to complete the tasks.
The bottom line with respect to Office 2007 deployments via Group Policy Software Installation is that the features and capabilities available with Office 2003 and earlier are no longer supported. However, you might still find Group Policy useful in customizing office 2007.
Following an Office installation, the next step is to control its configuration on your users' desktops. Group Policy can also help you in that effort. Like many other Microsoft applications and system components, all recent versions of Office come with Administrative Templates that can be imported into GPOs to customize Office configurations. The Office Administrative Templates ship for each new version of Office. You can obtain them from the Microsoft download site (http://www.microsoft.com/downloads). These .adm files ship with both per-computer and per-user settings. However, it's important to note that these settings are preferences, not policies; they will tattoo the target computer's registry until you explicitly remove them. To add the Office 2007 .adm files to a GPO, follow these simple steps:
- Open GPE and navigate to the GPO on which you want to set an Office Administrative Template policy. Right-click the Administrative Templates node under either Computer Configuration or User Configuration (it doesn't matter which) and choose Add/Remove Templates.
- Navigate to the folder in which you've saved your Office 2007 .adm files and select all the files in that folder. After they appear in the Add/Remove Templates dialog box, asFigure 3 shows, select Close to load them into the GPO.
- The Administrative Templates will now appear in the Administrative Template nodes in both Computer Configuration and User Configuration. If a setting appears as both per-computer and per-user, the per-computer setting typically takes precedence, unless otherwise stated in the Explain text for the policy setting. If you're using Windows Vista to manage Group Policy, the new Office templates will appear under the Classic Administrative Templates (ADM) node rather than in the main tree. To view the preferences, you need to tell the Microsoft Management Console (MMC) snap-in that you want to make them visible. To do so, choose View, Filtering and clear the Only show policy settings that can be fully managed check box. The Office templates will be visible and ready to be set.
Note that some aspects of the Office template settings will differ from Administrative Template settings. With many Administrative Template settings that Microsoft provides, when you enable a policy for a particular application (e.g., Windows Explorer), the setting that's controlled by that policy becomes grayed-out in the UI. The end user can't even access the option to change the policy setting. However, when you set an Office template (e.g., the default file save location for Microsoft Excel), it appears that the end user can go in and modify that option in Excel. But, the change made by the end user doesn't "stick," and the option reverts back to the one that you delivered in your GPO. This is just a subtle but important usability difference that you'll find in the Office templates.
The Office Administrative Templates let you exert much control over your Office deployments. However, not all configuration capabilities are supported. For example, the most common configuration request is to have the ability to pre-create Microsoft Outlook profiles with the email server options that you want your users to have the first time they launch Outlook. Unfortunately, this basic setup isn't supported in any versions of the Office Administrative Templates. For that reason, you have to rely on third-party vendors for help. Several vendors provide products that extend Group Policy's native capabilities to add advanced Office configuration support, including DesktopStandard's PolicyMaker Standard Edition (now part of Microsoft), Quest Software's Group Policy Extensions for Desktops, and ScriptLogic's Desktop Authority. ScriptLogic's product lets you control Outlook profiles outside of Group Policy. Both DesktopStandard's product and Quest's product are implemented as extensions to Group Policy, letting you use your existing Group Policy infrastructure to deploy the Outlook configuration I mentioned earlier as well as other configuration scenarios not supported by the Office Administrative Templates.
With Group Policy Software Installation for Office deployment and Office Administrative Templates to lock down the behavior of various Office applications for your users, you can ease the burden of managing what has historically been a large and complicated software suite. And, if you throw third-party products into the mix, there's almost nothing you can't do to manage your Office users.
