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.
Options for Deploying Office
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?
Using Group Policy to Deploy office
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.
Prev. page
[1]
2
3
next page 
