Mike here again to help bring clarity to something we are seeing with Windows Server 2008 R2 and existing Group Policy central store. Before that discussion, let us cover some background information.
Microsoft introduced the ADMX file format with Windows Vista and Windows Server 2008. This XML-based file format replaced the token-based ADM file format used by earlier versions of Windows to define administrative templates. Group Policy uses administrative templates to represent registry-based policy settings that appear when editing Group Policy. The content included in administrative templates describes the user interface used by Group Policy editors and registry locations where Windows stores policy settings. Windows Server 2008 R2 and Windows 7 provide a new set of administrative template files in the ADMX format.
Windows 7 ADMX files now include support for two registry types: REG_MULTI_SZ and REG_QWORD. The REG_MULTI_SZ registry data type represents multi strings entries within a single registry value. The REG_QWORD registry data type represents a 64-bit number, which is twice the size of the 32-bit number stored in REG_DWORD. These new aspects of the ADMX syntax are only viewable when using the GPMC and Group Policy editors from Windows Server 2008 R2 or Windows 7 Remote Server Administration Tools (RSAT). Group Policy editors and the GPMC from Windows Vista cannot read ADMX files containing this new syntax.
Earlier versions of Group Policy that used ADM files suffered from a symptom known as SYSVOL bloat . These versions of Windows copied the set of ADM files into each Group Policy object stored on SYSVOL. Each set of ADM files required approximately 4MB of disk space. A domain can realistically have 100 Group Policy objects. One hundred Group Policy objects multiplied by 4 megabytes of disk space equates to 400MB of redundant data—what a waste. Windows Server 2008 and Vista introduced the concept of the Group Policy Central Store to overcome SYSVOL bloat. The Group Policy Central Store is a single folder on each domain controllers SYSVOL that stores one set of ADMX files for the entire domain. The central store effectively relieves the symptoms of SYSVOL bloat and reduces the amount of data transferred during SYSVOL replication when new Group Policy objects are created. Some documentation refers to the Group Policy Central Store as an alternate location to store ADMX files (the other location is the local store found in %SYSTEMROOT%\PolicyDefinitions). A more accurate description of the Central Store is the preferred location.
The Group Policy Management Console and the Group Policy Management Editor always use the Group Policy Central store, when it is present. The pro here is that all instances of the GPMC and GPME use the same set of ADMX files. The con is that servicing ADMX files is difficult. Also, GPMC cannot use the local store as long as a Group Policy Central Store exists. So adding a single ADMX set for a single computer is not possible when using a central store. So, when we released Windows 7 and Windows Server 2008 R2, we also released a new set of ADMX files (within the operating system). These new ADMX files expose new Windows 7 and Windows 2008 R2 policy settings as well as policy settings for previous operating systems. Therefore, you need these files to configure Windows 7 Group Policies. Here’s where the dilemma continues.
If you have a central store (presumably hosted with Windows Server 2008 ADMX files), then you have two choices: upgrade the ADMX files or remove the central store.
Updating the Central Store affects all users in the domain that use GPMC and its editor. It is important to understand this because newer ADMX files may not be compatible with older versions of Group Policy Tools, as in the case with Windows Server 2008 R2. The screen capture below occurs in Windows Vista and Windows Server 2008 computers attempting to read a Group Policy Central store hosted with Windows Server 2008 R2 ADMX files.
Windows Server 2008 R2 ADMX file, in this example the TerminalServer-Server.adml, contains an unknown element named <multiTextBox>. This element represents the REG_MULTI_SZ implementation that is new with Windows 7 and Windows Server 2008 R2. Newer ADMX files can contain new features, which older Group Policy Tools may not understand. This is why it is always a best practice to use the latest Group Policy Tools to manage Group Policy. Backwards compatibility is an important aspect of Group Policy; however, forward compatibility is not.
Also, you may be using Windows 7, but do not see Windows 7 policy settings. Remember, GPMC prefers the Group Policy Central Store over the local store. The Windows 7 GPMC (actually RSAT) uses the Group Policy Central Store (hosted with Windows Vista or Windows Server 2008 ADMX files) over its local store that hosts the Windows 7 ADMX. If you want to see Windows 7 policy settings, then you’ll need to upgrade your central store or remove it.
Note: I have successfully used Windows Vista RSAT with an upgraded Group Policy Central Store. However, the ADMX and ADML files were from a Windows 7 computer. Using Windows Server 2008 R2 ADMX files produces the error in the preceding image using GPMC from Windows Server 2008 or Windows Vista RSAT.
Removing the Central Store targets all Group Policy tools to use their local store for ADMX file. This allows Windows 7 RSAT and Windows Server 2008 R2 computer to use their ADMX files. Windows Vista RSAT and Windows Server 2008 use their local ADMX files. Windows Vista computers cannot manage or report on Windows 7 policy settings.
There is way for us to “have our cake and eat it too”. The answer is Terminal Services. I often suggest to customers that have many people managing Group Policy to setup a GPMC Terminal Server. Dedicating a single server as the means to manage Group Policy provides:
A dedicate Group Policy Terminal Server can provide the look and feel of a Group Policy Central Store without implementing a Central Store. ADMX files are located in one location, the terminal server. GPMC does not load the ADMX files from a network location. Domain controllers do not need to replicate the additional content of a Central Store—all the benefits of a Central Store, without creating one.
Group Policy is a critical part of the enterprise and yet it seems little is done to reduce its exposure. A dedicated Terminal Server running GPMC provide a true single point of management for the entire Group Policy experience. Terminal Services security can be implemented to reduce the number of people having access to GPMC. Auditing interactive logons can further assist with identifying changes made to Group Policy. Combine this with using Group Policy to prevent other computers from opening GPMC and you’ve effectively lowered the surface and exposure to Group Policy to only the people that actually need it.
Hopefully, this helps with understanding the pros and cons of using a Group Policy Central Store. Also, it should help with answer some of the common questions that arise regarding updating the central store or managing the latest Group Policy settings with Windows 7. And lastly, perhaps consolidating Group Policy Management to a Terminal Server will help limit access to Group Policy management to only the people that actually need it.
Mike “He’s making a left turn” Stephens
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.