It’s easiest to explain the new ADMX
by looking at it side-by-side with the old ADM. Table 1 compares the two technologies.
As you can see in Table 1, there are plenty
of differences between ADM and ADMX. A
major difference is storage—having a central
store for ADMX files versus storing the same
ADM files in every GPO on every DC (the socalled
“SYSVOL bloat” problem). The central
store (aka central or domain-wide repository)
is simply a folder called PolicyDefinitions that
you create manually in the \\<domainName> SYSVOL\<domainName>\Policies folder on
your DC. You then copy the contents of C: Windows\PolicyDefinitions from one of your
Vista or Server 2008 systems into this newly
created folder and, voila, you’ve created the
central store.
I’ve created a free utility at www.gpoguy.com/cssu.htm that you can use to automate
the central store creation and population
process. Once the central store
is created and populated, both
GPE and GPMC, running from
Vista or Server 2008, will recognize
its existence and reference
ADMX files from that location
instead of locally.
Another advantage to the
new ADMX format, that I
alluded to earlier, is the separation
of the language-specific
strings in new ADML files from
the portion of the template that
defines the policy settings. This
lets you use one set of ADMX
files for each supported language, and the
ADML file for your local language is used
whenever you launch GPE. So, instead of having
to maintain multiple, language-specific
ADM files as in the past, this new format lets
you easily support editing of Administrative
Template policy in multiple languages.
You can convert your custom ADM files
to ADMX files by using a free ADM to ADMX
converter that Microsoft provides. This tool,
called the ADMX Migrator, also makes creating
ADMX files from scratch a cinch. For download
information, see “ADMX Migrator” in the
Learning Path.
Interoperability
Before I look at problems arising in the mixed
environment of Vista with ADMX, and Windows XP or Windows Server 2003 with ADM,
I want to emphasize that these are problems
for administrators. For GPO application on
clients (of whatever type), the ADM or ADMX
templates aren’t relevant. The templates are
used only for the administrative view of the
GPOs and are for administrative tasks, such as
working with specific settings. The actual settings
applied via GPO are still stored in registry.
pol and related files, which didn’t change in
Vista and Server 2008. This means that a GPO
created and managed via either Vista or Server
2008 is perfectly compatible with downlevel
clients for settings they support.
Administrators need to know that XP, Server
2003, and Win2K can’t “see” ADMX files. Thus,
if you create a GPO and set some Vista-specific
Administrative Template policies from GPE
running on Vista, then try to edit that GPO
from GPE running on XP, you won’t see the
Vista-specific settings because they’re in Vista
ADMX files that the XP machine can’t read. A
further complication is that XP and Vista don’t
store their template files the same way.
Let’s take the following mixed-environment
scenario. Suppose you create a new GPO on
your Vista workstation. Let’s also suppose that
you’ve created the central store, so all GPOs
managed from Vista are referencing the ADMX
files from that central location. (Remember,
Vista no longer stores template files in the
SYSVOL portion of each GPO.) Now you edit
that new Vista GPO on your XP machine. XP
looks in the SYSVOL portion of that GPO and
notices that there aren’t any ADMs there, so it
copies its own ADMs into SYSVOL and pollutes
your brand new Vista GPO.
How can this tragic scene be avoided? I
count at least three ways. First, after you introduce
Vista into your environment; you can
make a plan to edit GPOs only from Vista systems.
This guarantees that all GPOs from that
time forward will see all settings. Second, you
can keep your environments separate. If you
have some XP and some Vista systems, manage
the GPOs that apply to XP from XP systems
and the ones that apply to Vista from Vista
systems. However, if you absolutely, positively
must manage your Vista GPOs from downlevel
systems, consider the third option, which is
to enable the following policy on users who
edit GPOs from XP, Win2K, and Server 2003
systems. This policy will prevent the downlevel
platforms from automatically updating the
SYSVOL portion of your clean Vista GPOs with
ADM files every time you edit them:
User Configuration\Administrative Templates System\Group Policy\Turn off automatic
update of ADM files
Better Logging
A big challenge of Group Policy troubleshooting
in XP and Server 2003 environments is
getting useful information out of the logs generated
during a Group Policy processing cycle.
It’s especially true if you try to make sense of
the userenv.log file, located in %WINDIR% Debug\Usermode, a cryptic text log used by
both user profiles and Group Policy to log the
details of their activities. The good news is that
Microsoft moved away from the userenv.log
file in Vista and Server 2008. GPO processing
now runs outside of Winlogon and leverages its
own service. So instead of the userenv.log file,
detailed trace information about Group Policy
processing is found in the Group Policy Operational
log. This log, shown in Figure 3, contains
step-by-step detail of
Group Policy processing
on a given system.
You can locate the Group
Policy Operational log in
the new Event Viewer by
expanding the Applications
and Services Logs
node and then clicking
Microsoft, Windows,
GroupPolicy, Operational.
Note that the new
eventing system (codenamed
Crimson) in Vista
and Server 2008 allows
you to do interesting
things such as forward
specific events to a central collection point
(called subscribing to events) or create filtered
views of specific events. In addition to the
Event Viewer, Microsoft has provided a free
command-line tool called GPLogView that
lets you output Group Policy Operational log
events to text or HTML files. For download
information, see “Group Policy Log View” in
the Learning Path. If you like writing code, you
can download the source code for GPLogView
and contribute changes and enhancements to
it at www.codeplex.com/gplogview.
New Policy Areas
In addition to all the core changes to Group Policy
in Vista and Server 2008, Microsoft has added
some new configuration capabilities. I don’t
have room to discuss them all here, so I’ll just
highlight some of the more interesting ones.
Deployed printers. In a move that’s similar
to providing the printer deployment capability
in Server 2003 R2, Microsoft has finally made
deployed printers full citizens in the Group
Policy world. Vista and Server 2008 systems
can process either per-computer or per-user
deployed printer definitions to allow you to
map printers for computers and users within
Group Policy. (Note that this capability can
also be leveraged by XP or Server 2003 systems,
but the mechanism to trigger evaluation of the
printer policies via startup/logon script is different.)
This capability requires an AD schema
update if you’re not running the R2 (or later)
version of the AD schema. The LDAP Data
Interchange Format (LDIF) schema files that
support this feature (and others) can be found
on the Vista CD-ROM in the sources\adprep
folder. If you’re running the Server 2008 AD
schema, then these additions are already
included. Deployed Printers are located within
the Group Policy namespace under Computer
(or User) Configuration\Windows Settings Deployed Printers.
Power management. Vista and Server
2008 finally let you control power management
features via Group Policy. These include
choosing the default power plan for a system
and configuring every aspect of when a system
sleeps, hibernates, or shuts down. You can
find most of the power configuration options
at Computer Configuration\Administrative
Templates\System\Power Management, but
you can also set a per-user option to require
a password when a system comes out of
hibernation or standby by setting the policy at User Configuration\Administrative Templates System\Power Management.
Continued on Page 3
Register
