Share via

Windows 7, Windows Server 2008 R2 and the Group Policy Central Store

  • Article

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.

ADMX Files and the Group Policy Central Store

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.

The Central Store

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.

So what’s the Problem?

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.

A Central Store and Windows 7

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

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.

image

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.

image

Removing the Group Policy Central Store

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.

An Alternative to the Central Store

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:

  • The concept of a central store
  • A single point of Group Policy management
  • Easy to audit and maintain

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

Comments

  • Anonymous
    December 14, 2009
    Thank you for making clear that the "Central Store" is not the solution for all the problems of the past. In fact, it adds some new. I'd like to add this sample scenario: Central Store is established. GPO Management is performed by many people. One person receives a bunch of ADMX files (e.g. taking part in a beta program for a MS Product). The person wants to test and use the beta ADMX files on a domain integrated machine. The problem: This is only possible if the files are copied to Central Store which in turn makes them available for all GPMC users. Very annoying situation… You suggest using a Terminal Server and no Central Store. OK, that would solve some situations, but again not all, e.g. what if Terminal Services are based on a server farm and you don’t know which physical server you are going to logon on? You would have to synchronize all local directories… What about this idea: Create a new Policy which gives free control over an alternative ADMX source path. In other words: If a Central Store is defined, it shall be used just as today. But if on a specific machine an “ADMX Redirection” Policy is set, the default behaviour changes and the specified path (local or UNC based) is used within GPMC and GPEdit. Maybe that needs some additional security means to avoid situations when users change that path locally though it is not desired, but I think it would be a good option. Don’t get me wrong, I really like the idea behind “Central Store”, but it needs some small improvements… Patrick

  • Anonymous
    December 14, 2009
    This statement is incorrect "You suggest using a Terminal Server and no Central Store. OK, that would solve some situations, but again not all, e.g. what if Terminal Services are based on a server farm and you don’t know which physical server you are going to logon on? You would have to synchronize all local directories…" This is not the case as long as all members of the Terminal Server farm are running Windows Server 2008 R2 (without a Central Store). The policydefinitions folder on the local computer is the same and does not need any sychnoization. That said, I'd question why GPMC would need to be run from a TS farm. The idea is to lower the amount of people that can run and use GPMC. There would really need to be a strong business case to support a TS farm for GPMC. If the idea is to reuse an existing TS farm, then don'g go through the farm when using GPMC, have a dedicate server so you know the loction from where GPMC can run and you know who is running it. Of course, I agree that implementing a Group Policy setting to override the central store behavior back to the local store is a simple solution, that solves many problems.

  • Anonymous
    December 15, 2009
    Thanks for your comment. Just to clarify: Business aspects (company policies, costs, etc.) might force you to reuse an existing farm. And how many GPO admins there are depends on many factors (the size of the company, the OU and delegation model with e.g. local responsbilities). So saying "lower the amount of people that can run and use GPMC" is not always an option. I agree that in an initial situation when starting with 2008 R2 in a TS farm all local directories are identical. But as soon as there is the first ADMX Update (MS, custom, 3rd party or whatever) you will have to deploy them to each server to have identical local stores, don't you? I'm glad you agree with me that a special Policy Setting could help to solve many situations. It would be great to see this being implemented in Windows 2008.

  • Anonymous
    January 03, 2010
    Just another note: Central Store is not only used by GPEdit, but also by tools like RSOP snap in and gpresult (e.g. when using /H parameter for HTML export). That means if you have custom templates used for editing GPOs and you don't use Central Store concept, these tools will only show unresolved "Additional Registry Settings" when being executed on a client machine (which usually does not have additional templates present locally). Having established Central Store inclusing custom ADMX templates, these tools resolve all the settings and are good helpers in troubleshooting...

  • Anonymous
    January 23, 2010
    > 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. Hi! Where can we find more information on this and the like? The whole microsoft.com knows nothing about “multiTextBox”. And I'm sure there some other pretty things that are worth knowing. I mean ADMX syntax reference is still v.1 (for Vista and Server 2008) and was never updated.

  • Anonymous
    June 25, 2014
    The comment has been removed