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.
End of Article
Register
