Longhorn Group Policy Architecture

Now that Longhorn technology (in the dual garb of Windows Vista and the Longhorn Server) has arrived on the scene, many network planners are taking a closer look at some of the architectural changes that Microsoft has made to the Group Policy structure.
The underlying concept of Group Policy hasn't changed – it's still fundamentally a Great Big Network RegistryEditor. Make a setting, and Group Policy enforces it for you from that point forward. The implementation of Group Policy has evolved in several useful and interesting ways:

• New status as an operating system Service
• Network Location Awareness
• Improved log file viewing
• New source file format (ADMX)
• New migration/editing utility
• Central-store management
• Dynamic source file loading
• Multi-language support
• Multiple local Group Policy Objects (GPOs)

Now lets take a look at these nine structural changes.

New Status as a Service

Under previous versions of Windows, Group Policy ran in the context of the Winlogon process. In Vista and Longhorn, Group Policy is its own operating system service, running under SVCHOST. OK, but that sounds a bit academic. Just what are the implications of Group Policy's newfound status?
For one thing, Group Policy security is enhanced. The service requires administrative rights to stop (even if you're logged in as a local admin, you'll see an elevation prompt). For another, like all services, you can configure how you would like Group Policy to behave in a failure scenario. For example, you can specify that the service should automatically restart.

Finally, shutdowns should be smoother. Windows' Service Control Manager (SCM) provides certain services (including Group Policy) with a "pre-shutdown notification" so they can finish up whatever housekeeping chores they need to do before Windows shuts down. As long as such services remain responsive, the SCM will wait until they finish – even if it takes well over the old 20-second time limit.

Network Location Awareness
In Windows XP/2003/2000, the Group Policy agent on the client didn't pay a whole lot of attention to whether the computer on which it was running was connected to the network or not. If a policy refresh cycle failed, for example, because the laptop was disconnected or no domain controller was available, Windows would simply wait another cycle (90 minutes plus a random value from 0 to 30 minutes) and try again. Furthermore, when it did try to pay attention to network conditions, it sometimes did so clumsily. For example, Group Policy would attempt to detect slow links using ping (ICMP), which many organizations block at the firewall or router level.
Longhorn/Vista is now more network-aware when it comes to policy processing. If a policy refresh cycle fails when a computer is offline, and the computer (or domain controller) goes online, Vista doesn't wait around, but instead it attempts to perform a policy refresh as soon as it can. It also uses a different mechanism than ping to determine the speed of the network connection. These enhancements fall under (of course) a new acronym: NLA, for Network Location Awareness.

Improved Log File Viewing
Before Vista and Longhorn, if you wanted to perform detailed logging of Group Policy events beyond what you could get in the RSOP console (Resultant Set of Policy), you had to turn on the debug feature within the USERENV.DLL module, which would generate a file USERENV.LOG in the \windows\debug\usermode folder.
With the new Longhorn operating systems, the System event log contains "actionable" Group Policy events, which is certainly more convenient. (This is one more side effect of the shift to Group Policy being implemented as a service.) These events are now more English-like and more informative. The source is "Group Policy Service" and Microsoft promises to keep making the logs better, for example, with links to online knowledge base articles.
The Operational event logs (you have to dig down further in the Event Viewer to see these) contain a lot of the detail that the old USERENV.LOG file would provide. These log entries provide details that you could use to examine policy processing performance from the speed standpoint, for example. (If you still want to view the USERENV trace log, you can, but the Registry key is now HKLM\Software\Microsoft\Windows NT\CurrentVersion\Diagnostics, the DWORD value is GpSvcDebugLevel, and you can set it to 10002. Oh, and the filename is now named GPSVCLOG.LOG instead of USERENV.LOG.)


A downloadable tool from Microsoft (search on GPLogView.MSI) is handy for collecting Group Policy related events from the event logs and exporting those events into TXT, HTML, or XML formats. (This tool requires that your system participate in the Genuine Windows program before you can download it.)
Finally, if you want to view Group Policy events from multiple computers in one place (e.g., on your own Vista workstation), you can do it, as long as you and those other systems are running Vista or Longhorn Server. I don't have room to go through all the details here, but in a nutshell, you activate the Windows Remote Management service on all the relevant machines, and then you set up a "subscription" in the Event Viewer console (EVENTVWR.MSC). Note that when you do this, you must provide administrative credentials with which to authenticate to the remote systems.

New Source File Format (ADMX/ADML)
Those who remember Windows NT may recall that .ADM files were present way back then, as part of the old System Policy (POLEDIT) architecture which represented the klutzy beginnings of today's Group Policy design. Even though Group Policy in Windows XP/2003/2000 is much more sophisticated than it was in the NT days, the .ADM file format persisted, providing text-based files that acted as the "source code" feeding the Group Policy console. In other words, the ADM files laid out which Registry keys and values to modify, and they provided the user-interface information ("explain" text, data entry format, minimum supported OS revision, etc.) that the console needs in order to present appropriate options to GP administrators.

The good news was that ADM files provided extensibility to the Group Policy architecture.Want to use GPOs to control Microsoft Office? The ADM files were all you needed. The bad news was that ADM files had to be imported into each GPO, causing GPOs to be much bigger than we'd like them to be (remember that they have to replicate between domain controllers), and wreaking a fair amount of havoc when Microsoft provided updated ADM files (e.g., with Windows XP SP2). Plus, of course, the unique ADM syntax was just one more weird text file format that network admins had to deal with. Finally, if you needed multi-language capability, ADMs did not provide it.
The Longhorn/Vista platform retains backwards-compatibility with ADM files but provides a new file format, ADMX, with a number of important advantages, which the following sections look at more closely. But before we get to those, we should mention two things. First, the new format is (as so many things on the Longhorn platform) based on XML. If you haven't boned up on XML yet, now would be a good time to do so, because it crops up all over the place in Longhorn and Vista. And second, ADMX files now have multilingual capability. The ADMX files contain language-neutral information; their associated ADML files contain language-specific information.


New Migration/Editing Utility

Before we get into some of the good things that the new ADMX files do for us, I should point out that Longhorn and Vista can continue to use the old ADM files. For example, if your organization has created some ADM templates with custom Registry settings, you can still import them into your GPOs as always, using the Administrative Templates node in the Group Policy Object Editor (GPOE). However, you may want to consider converting your ADM templates into the newer format, to take advantage of central store management, dynamic loading/unloading, and multi-language support.
Originally, Microsoft had said that they didn't intend to provide an ADM-to-ADMX migration tool, but enough people howled and hollered that they changed their mind, and ADMXMigrator.MSI is the result. The tool is only available to those whose Windows installations are validated as part of the "genuine Microsoft Windows" program. It can handle converting multiple ADM files at one time. Just be aware that you will lose any comments in your ADM files when you convert them.
A nice side benefit to this download is the inclusion of an ADMX file editor that makes the process of tweaking ADMX files significantly easier.

Central Store Management

The old ADM files could be anywhere on the network, and if you didn't have the latest set on your system, then you might not be seeing all available Group Policy settings. Even with Vista, you get a set of ADMX files on the local hard drive.
However, for domain-based GPOs, Longhorn and Vista use a network-based central store to keep all ADMX files: it's on domain controllers, in sysvol\policies\policydefinitions. Once you set up the central store (TechNet has the details), the GPOE and Group Policy Management Console (GPMC) consoles will use it from that point forward in lieu of the local store.
Having a central store for ADMX templates is great, because it means that administrators only need to update the templates one time, and Active Directory replication will take care of propagating the updates to all the domain controllers in the network. No more asking yourself if your ADMs are the latest and greatest.

Dynamic Source File Loading
Although the option remains to manually install ADM files by right-clicking the Administrative Templates node in the GPOE, you won't be using that feature nearly as much after migrating to Longhorn/Vista. The reason is that these operating systems automatically load ADMX files from the central store when you open the GPOE.
This solves a major headache for network administrators. To prove this, you can conduct an experiment with a Vista or Longhorn Server machine. Take ownership of one of the ADMX files in the central store, and relocate it to a different folder. Then run the GPOE and look for the settings contained in that ADMX file. They will have disappeared. Finally, reinstate the ADMX file into its rightful location, and run the GPOE again. You will see the settings magically reappear.

Multi-Language Support
When you open the PolicyDefinitions folder in the central store, you will see a folder (typically named en-US for U.S. English systems) containing the relevant language-specific ADML files. In these files, you will find all the data that the Group Policy Object Editor needs in order to present the user interface to the administrator in the language of his or her choice. For example, all the "explain" text (online help for specific policy settings) is contained in these ADML files.

Multiple Local GPOs
Windows XP and 2000 offer only one local Group Policy Object. The thinking here may have been that "hey, everybody's on a domain anyway, one local GPO should be enough." However, not everybody's on a domain – and even in a predominantly Active Directory world, one has an occasional need for a non-connected PC.
Vista and Longhorn provides new flexibility for that situation. Not only can you create GPOs on a per-user basis, which is nice but not exactly practical if you have a lot of local user accounts to manage, you can create a GPO for local administrators, and another GPO for everybody else (local non-administrators). (Going in the reverse direction, a new policy setting lets you turn off all local GPO processing.)
By the way, the sequence of processing for these new GPOs is as follows: 1) machine GPO, 2) non-admins GPO, 3) admins GPO, and 4) individual-user GPO. Remember, as always in Group Policy, the default behavior is Last Write Wins.

Conclusion
In Microsoft's Longhorn technologies, both client and server, Group Policy is the same, but different. It still delivers the biggest "bang-for-your-buck" of just about any other Active Directory feature. It still lets you configure settings for your domains, organizational units, sites, and (if you like) individual computers. And it still has that convenient "set it once and let it run" character. But Microsoft has made a number of welcome evolutionary enhancements to the way that Active Directory implements Group Policy. These enhancements make the technology more stable; more secure; faster in operation; and easier to manage, maintain, and troubleshoot.