Executive Summary: Microsoft Office 2007 system makes it easy to manage your deployments with Group Policy by providing new Administrative Templates as well as 2007 Microsoft Office Security Guide and GPOAccelerator. You'll use the ADMX template files for Windows Vista or Windows Server 2008 or the ADM files for any older Windows OS. Administrative Templates can be used to lock down specific functions within each of the Office 2007 applications. The 2007 Microsoft Office Security Guide gives you a good head start on knowing what security settings are important as well as creating the policies to achieve the right protection.

If you’ve been administering Windows environments for very long, you’re probably familiar with Administrative Template (ADM) files. Since the days of Office 97, Microsoft has provided ADM files that let you customize the behavior of your Office applications using Group Policy (or its predecessor, system policy). With the release of the Microsoft Office 2007 system, Microsoft has continued this tradition and put considerable effort into making Office 2007 a full citizen within the world of Group Policy. Microsoft has also provided tools such as the GPOAccelerator for optimizing Office 2007 security configurations. To take advantage of these management capabilities in your Office 2007 deployments, you’ll need to know how to install the templates and how to use the templates and other tools to create the appropriate policy settings for your environment.

Administrative Templates and Office
Group Policy Administrative Templates are the usual means of managing Office configurations after Office is deployed to your desktops. The Office Administrative Templates let you customize the options that are enabled and disabled within each of the Office 2007 applications.

Deploying Office versions earlier than Office 2007 often involved using the Group Policy Software Installation (GPSI) feature, along with custom transform (.mst) files that modified the default configuration according to your requirements. However, as Dan Holme noted in “Customizing and Deploying Office 2007,” May 2007, InstantDoc ID 95433, customizing deployments of Office 2007 using Group Policy has changed radically.

Office 2007 uses something called the Office Customization Tool (OCT) to create custom Windows Installer patch (.msp) files that you use to customize Office configurations. Therefore, you might wonder how the post-deployment configuration of Office 2007 using Administrative Template files has changed. The good news is that it has only gotten better: You now have more capabilities for configuring and locking down your Office 2007 deployments than you’ve ever had.

Getting the Administrative Templates
You can dowload the Administrative Template files from the Microsoft Download Center at www.microsoft.com/downloads/details.aspx?FamilyID=92d8519a-e143-4aee-8f7a-e4bbaeba13e7. Microsoft provides both ADM files and the new file format, ADMX, which you need with Windows Vista and Windows Server 2008.

After you’ve downloaded AdminTemplates .exe and extracted the files, you’ll see an ADM folder and an ADMX folder. (You’ll also see a folder called Admin, which contains OCT files for customizing Office at deployment time; I won’t discuss those files in this article.) Within the ADM folder, you’ll see a number of folders named by language code (e.g., de-de for Germany, en-us for US English, es-es for Spanish). These are the language-specific versions of the ADM files; when configuring Office 2007, you’ll pick the language folder that matches the version of Windows you’re running.

The ADMX folder includes language-specific folders in addition to the ADMX files. The folders contain the language resource files (ADMLs) that work with the language-neutral ADMX files. If you’re managing Office 2007 from a Vista or Server 2008 system, these are the files you’ll need to use.

Implementing the ADM Office Templates
For any version of Windows earlier than Windows Vista, you’ll use the ADM files. Note that in pre-Vista versions of Windows, ADM files are stored individually within each Group Policy Object (GPO), so you’ll need to perform these steps within each GPO that you want to implement Office 2007 policies.

The first thing you need to do to load the ADM files for use in Group Policy is open the Microsoft Management Console (MMC) Group Policy Editor (GPE) snap-in, focused on the GPO you want to manage. You can choose either a GPO that’s part of an Active Directory (AD) domain or a local GPO. Right-click the Administrative Templates node under either Computer Configuration or User Configuration (it doesn’t matter which one you use when you’re adding templates to a GPO), select Add/ Remove Templates from the context menu, then click Add to browse to the folder of ADM files for your language of Office 2007. Note that you can select all the ADM files in a folder at the same time to load into your GPO, as Figure 1 shows. When you click Open in the Policy Templates dialog box, the ADM files are copied into the GPO and they’ll appear under the Administrative Templates node of GPE, as Figure 2 shows.

You’ll find Office configuration options under both the Computer Configuration and User Configuration nodes; options under Computer Configuration apply to all users on a computer where that GPO is applied, whereas the ones under User Configuration apply to any user object in AD that receives the GPO. A potentially confusing circumstance is that these ADM files (and the ADMX files as well) ship with both true policies, which can be fully managed by administrators, and preferences, which are settings made outside of the designed policy keys within the registry. Preferences aren’t shown by default in GPE. To see all of the policy settings provided by the Office templates, you’ll need to select View, Filtering in GPE, then clear the Only show policy settings that can be fully managed check box so that all preferences will appear along with the policy settings. Unfortunately, this filter doesn’t persist, so you’ll have to reset it every time you launch GPE.

Implementing the ADMX Office Templates
Vista introduced a major improvement in Administrative Template management with the ADMX file format, which essentially replaces the ADM files with an XML-based format for defining new registry-based policy settings. One advantage ADMX files provide is that GPE no longer requires them to be stored in the SYSVOL portion of every GPO in a domain, saving space and network bandwidth on your domain controllers (DCs) by not having to replicate these files within every GPO that uses them to every DC.

To get access to the Office 2007 ADMX files on your Vista administrative workstation, you can choose from two methods. The first and easiest method is simply to copy the ADMX files within the ADMX folder to your local workstation, placing them in the folder called c:\Windows\PolicyDefinitions. Make sure you copy only the ADMX files into this folder at this point—not all the sub-folders that contain the language-specific ADML files, which is the next step. Choose the language of ADML files you need and copy them into the language-specific folder under C:\Windows\PolicyDefinitions. For example, if you’re using a German-language version of Windows, you would copy the ADML files within the de-de folder in the Administrative Templates installation into C:\Windows PolicyDefinitions\de-de. After the files are copied to the appropriate folders, you’ll see them underneath Administrative Templates within the Computer Configuration and User Configuration nodes when you launch GPE.

The other option for getting the Office 2007 ADMX files into GPE is to leverage the central store. Vista and Server 2008 support looking in a central file share for ADMX and ADML files. You don’t have to copy these files to every administrator’s local workstation to make them available; if you copy them to a single central location in the SYSVOL folder on your DCs, they’ll be available to all administrators that start GPE in your domain.

If you don’t already have the central store in place, you’ll need to create it and populate it with all the default ADMX and ADML files before you copy the Office 2007 files into it. Note that when the central store exists in a domain, the GPE ignores the contents of C:\Windows PolicyDefinitions and looks only in the central store for ADMX files. If you copy only the Office ADMX files into the central store, you’ll no longer see any of the other Windows ADMX files in any of your GPOs! The central store is easy to create; the steps are described in the Microsoft article “How to create a Central Store for Group Policy Administrative Templates in Window Vista” at support.microsoft.com/kb/929841. However, I’ve created a free utility that you can use to create the central store via a GUI if you don’t want to perform the task manually. You can download the utility at www.gpoguy.com/ cssu.htm.

Using the Templates to Lock Down Office
The Administrative Templates in Office 2007 provide close to 3,500 different configurable settings, which is significantly more settings than are available in Office 2003. Having so many choices can be bewildering at times. In addition, the Explain text that accompanies Administrative Templates is notoriously sparse in Office templates, meaning you might go through a lot of trial and error to find the correct policy for your needs.

As a further complication, the Office templates don’t always behave the same as other Administrative Templates. For example, if you enable a policy in Explorer to lock down a certain function, that function—be it a button or check box—is usually grayed out so the user can’t modify it. However, this isn’t the case in Office. For instance, if you disable background saves in Microsoft Office Word 2007, the check box for background saves isn’t selected when you start Word, but it’s available for a user to select. However, when you next start Word, sure enough the option isn’t selected—as the policy dictates. This behavior can be frustrating if you don’t know to expect it.

The other unfortunate behavior I’ve noticed is that Office applications, unlike many Windows components that are controlled by policy, don’t dynamically detect changes to policies while the application is running. For example, in my scenario about managing the background save feature in Word, if I set this policy and a user processes the policy while Word is running, Word won’t immediately make the change, as “policy-friendly” applications are supposed to. Word won’t pick up that change until the next time the user starts the application.

The templates let you disable menu elements within Office applications. You typically have two ways to do this for each application. The first way is to choose one of the predefined menu options that the policies provide. The second, and more obscure, way is to use custom menu identifiers to restrict a particular menu choice. Let’s take a look at both methods for locking down an Excel menu option. For the first method, navigate the console tree in GPE to User Configuration Administrative Templates Microsoft Office Excel 2007 Disable Items in User Interface Predefined, then select the Disable Commands policy in the right pane. Click Properties to display the Disable commands Properties dialog box where you’ll find options to disable specific menu items, as Figure 3 shows.

Now, if you choose the Custom container under Disable Items in User Interface, you can define custom commands (menu items) and shortcut keys that you want to control. When you open the policy setting by double-clicking it, it asks for the command bar ID of the command you want to control. Where do you get the ID? The answer isn’t altogether straightforward. All that I’ve found are Visual Basic macros that you can run within a given Office application to query for particular command bar IDs. For example, the Microsoft article “WD2000: How to Generate a List of Command Bar Names, Captions, and ID Numbers” at support.microsoft .com/kb/243988 describes how you can do this for Word 2000, and I’ve used the macro from that article successfully in Office 2003. I haven’t seen any documentation for using it in Office 2007, which has the new ribbon menus, but I ran the macro in Word 2007 and it worked as expected, so that’s a good sign!

Securing Office 2007 with Group Policy
In addition to the Administrative Templates for configuring features within Office 2007, Microsoft has also provided two Group Policy–related tools for ensuring that your Office 2007 deployments are configured securely. The first of these is the 2007 Microsoft Office Security Guide, available on Microsoft’s Web site. The guide includes a spreadsheet and set of documents that describe in detail the security-related settings within the Office 2007 Administrative Templates and how you can use them to securely configure your Office deployments.

The other aid for easing the creation of Group Policies for securing your Office deployments is the GPOAccelerator. This tool, which you can download from Microsoft, is a Windows Installer (.msi) file that you install on your administrative workstation. It includes a set of predefined GPOs that you can install into an AD domain (probably a test domain initially); they provide recommended Office 2007 security settings for a variety of scenarios. GPOAccelerator installs a script called GPOAccelerator. wsf that creates an organizational unit (OU) in the AD domain you run the script from, then creates GPOs according to a number of switches that you specify. I ran the GPOAccelerator script with the /Enterprise, /Lab, and /Vista options and, as Figure 4 shows, the resulting OU structure, including the GPOs, was created under Vista Security Guide EC Client OU in my test domain.

In addition to specifying best practices for Office-related Administrative Template settings, GPOAccelerator’s GPOs include best practices for general security settings, including areas such as audit, user rights, and eventlog settings. These GPOs are a good starting point for designing your own GPOs to manage Office users. You can tweak and modify the settings within these GPOs to meet the needs of your particular environment. The key point is that Microsoft has done a lot of the hard work up front to figure out what security settings you need to be concerned with, and that makes getting up to speed with your Office 2007 configurations much easier.

What’s Missing?
Although the Office 2007 Administrative Templates include a dizzying array of options for managing Office through Group Policy, you’ll find a few obvious things are absent. For example, you can’t set up Microsoft Office Outlook profiles using Administrative Template settings, but you can configure how a Microsoft Exchange server behaves after an Outlook profile is defined in the user’s profile. Any settings that aren’t stored in the registry as types supported by Administrative Templates are missing—types such as REG_BINARY fall into this category.

Perhaps some of these missing Office capabilities will show up when Microsoft makes the DesktopStandard PolicyMaker extensions, which it acquired in 2006, available to its general customers. Those extensions include features such as creating Outlook profiles and specifying options in Office that the Administrative Templates don’t cover. Let’s keep our fingers crossed that Microsoft releases them sooner rather than later.

Unprecedented Control of Office
With the release of the Office 2007 Administrative Templates and the 2007 Microsoft Office Security Guide and GPOAccelerator, Microsoft has added an unprecedented number of Group Policy–based configuration options for your Office deployments, which you can use whether you’re running Windows Vista or Windows XP. Although you won’t find every option you might want, with these tools Microsoft is getting much closer to providing full control of every aspect of Office through Group Policy. This is a good thing! More and more users are discovering the power of Group Policy for configuring their systems, and it makes sense for Microsoft to ensure that as many of its products and components are Group Policy–enabled as possible to reduce the number of places you have to go to manage your desktops.