Create Active Directory Central Store

原文：Create Active Directory Central Store — theDXT (Daniel Keer)

The default setup of Windows Active Directory is no central store. A central store is a central place to store your group policy definitions. If you only have one domain controller and make all your GPOs (Group Policy Objects) on that domain controller this likely wouldn’t be much of a problem.

The limitations start to show their faces when you have a second domain controller or you use a different system to make your GPOs. They also show up if you import GPOs that were build using newer group policy definitions. If you want to know how to import GPOs from another system I detailed the full process in a post called GPO Export and Import.

When you create or edit a GPO with the Group Policy Management Editor it checks to see if it can find a central store, if it can’t find one or if none exist it uses the group policy definitions from your computer which are stored in C:\Windows\PolicyDefinitions.

GPO not using the central store

Here’s how to create an Active Directory Central Store for all your group policy definitions on your domain.

• Create a PolicyDefinitions folder in SYSVOL Policies. In my example my domain is called testing.local so the path I need to create the PolicyDefinitions folder in is \\testing.local\SYSVOL\testing.local\Policies

Creating PolicyDefinitions in SYSVOL

• Copy the contents of C:\Windows\PolicyDefinitions into the PolicyDefinitions folder we just created.

In my example I am copying C:\Windows\PolicyDefinitions to \\testing.local\SYSVOL\testing.local\Policies\PolicyDefinitions

copying C:\Windows\PolicyDefinitions into SYSVOL PolicyDefinitions

• Now when we create or edit a GPO it will use the central store to get the group policy definitions.

GPO using the central store

Now all systems on the domain will be using the same set of policy definitions.

That is all it takes to make an Active Directory Central Store.

If you want to read more about the Central Store you can do so by reading Microsoft’s documentation about it.

What a Central Store Actually Contains

The folder you create is not a single file — it is a copy of the two things the Group Policy Management Editor reads when it renders a policy tree:

• ADMX files — the language-neutral policy definitions. Each file describes one Windows component or feature area (for example WindowsUpdate.admx) and contains registry keys, value types, supported operating systems and presentation references.
• ADML files — the language-specific strings. They live in a subfolder named for the locale (usually en-US) and supply every human-readable label, description and error message. Delete the language folder and the editor either shows GUIDs or fails outright.

Both C:\Windows\PolicyDefinitions (the local copy on your administration machine or domain controller) and the SYSVOL copy have exactly the same internal shape. That is what makes the switch transparent: Group Policy tools simply prefer the SYSVOL path when it exists, and fall back to the local one when it does not.

C:\Windows\PolicyDefinitions\
├── *.admx                              (language-neutral)
└── en-US\
    └── *.adml                          (localized strings)

\\<domain>\SYSVOL\<domain>\Policies\PolicyDefinitions\
├── *.admx
└── en-US\
    └── *.adml

Why the Central Store Matters

Without it, every administrator's workstation supplies its own template set. Three consequences follow, and all three are painful in exactly the way that is hard to debug:

• Inconsistent policy views. An administrator on Windows Server 2019 sees different settings from a colleague on Windows 11 24H2. The same GPO appears to contain different options depending on who opens it.
• "Extra Registry Settings". When a GPO was created with newer ADMX files than the machine now editing it, the editor cannot render those settings and dumps them into the dead-end Extra Registry Settings node. The policy still applies — Group Policy is registry-driven at the client — but nobody can see or edit it, and a careless cleanup pass can delete it by accident.
• Silent template drift. Templates change between Windows releases as Microsoft deprecates settings and adds new ones. Without a single source of truth, the effective policy surface of your domain depends on which machine made which GPO.

A Central Store collapses all of that into one replicated folder: one set of definitions, edited by anyone, seen identically everywhere.

Prerequisites and Planning

• Permissions. Creating the folder requires rights on the SYSVOL share — effectively Domain Admins or Enterprise Admins, or a delegated group with modify permission on Policies. Reading the finished store only needs the default Authenticated Users read access, which is already in place on SYSVOL.
• SYSVOL health. Confirm replication is happy before you write. Check with dcdiag /test:sysvolcheck or, for DFSR, dfsrdiag ReplicationState /member:<DC>. Writing a large folder onto a domain controller that is not replicating creates a divergence you will be unwinding for weeks.
• Template source. Download the current Administrative Templates (.admx) package for your primary Windows client version from the Microsoft Download Center — the Windows 11 or Windows Server template package. Superset beats in-place upgrade: newer ADMX files understand older settings, but older files do not understand newer ones.
• Timing. Do it during a maintenance window. It is reversible and safe, but an incorrect or partial copy produces confusing editor behaviour for everyone until it is fixed.

Step by Step: Building the Store

Connect to any domain controller (or a management machine with RSAT and the SYSVOL share mounted) and run the following from an elevated prompt. Replace testing.local with your domain.

:: Confirm SYSVOL replication first
dcdiag /test:sysvolcheck

:: Create the Central Store folder in SYSVOL
mkdir "\\testing.local\SYSVOL\testing.local\Policies\PolicyDefinitions"

:: Copy the neutral ADMX files (same as copying the contents by hand)
copy "C:\Windows\PolicyDefinitions\*.admx" ^
     "\\testing.local\SYSVOL\testing.local\Policies\PolicyDefinitions\"

:: Copy the English strings into the matching language subfolder
xcopy "C:\Windows\PolicyDefinitions\en-US" ^
      "\\testing.local\SYSVOL\testing.local\Policies\PolicyDefinitions\en-US" /E /I /Y

If you are laying down the Microsoft template package rather than the local C:\Windows\PolicyDefinitions, extract the download and copy from its root instead — it contains the same *.admx files plus a locale subfolder such as en-US with the matching *.adml files:

:: Using Robocopy for a large template set (mirrors and reports)
robocopy "C:\Temp\ADMX\Windows11" ^
         "\\testing.local\SYSVOL\testing.local\Policies\PolicyDefinitions" ^
         /MIR /R:2 /W:2 /LOG:C:\Temp\admx-copy.log

robocopy "C:\Temp\ADMX\Windows11\en-US" ^
         "\\testing.local\SYSVOL\testing.local\Policies\PolicyDefinitions\en-US" ^
         /MIR /R:2 /W:2

Do not forget the language folder. The single most common failure after "building" a Central Store is a PolicyDefinitions folder full of ADMX files with no en-US directory beside them — the editor then reports errors such as "The following entry in the [strings] section is too long and has been truncated" or shows an empty Administrative Templates tree.

Verifying the Switch

There is no service to restart. Group Policy tools pick up the store on their next launch, so close and reopen the Group Policy Management Editor, then confirm three things:

• The status bar at the bottom of the editor shows the SYSVOL path with (Central Store) appended — this is the definitive indicator, and it is what the screenshots above are showing.
• A brand-new GPO created on any domain controller, from any administration machine, lists the same settings in the same order.
• The Extra Registry Settings node is empty for GPOs that previously showed it, assuming your store now carries the newer templates those settings came from.

:: Count the definitions in the store
(Get-ChildItem "\\testing.local\SYSVOL\testing.local\Policies\PolicyDefinitions" -Filter *.admx).Count
(Get-ChildItem "\\testing.local\SYSVOL\testing.local\Policies\PolicyDefinitions\en-US" -Filter *.adml).Count

:: Spot-check a few well-known templates
Test-Path "\\testing.local\SYSVOL\testing.local\Policies\PolicyDefinitions\WindowsUpdate.admx"
Test-Path "\\testing.local\SYSVOL\testing.local\Policies\PolicyDefinitions\en-US\WindowsUpdate.adml"

If the status bar still points at the local path, the cause is almost always the path itself: a typo in the domain name, a second Policies folder deeper in the tree, or the store created on a DC whose SYSVOL has not replicated to the DC your tool is talking to. Verify with dir \\testing.local\SYSVOL\testing.local\Policies from the machine running the editor.

Keeping the Store Current

An unmaintained Central Store slowly becomes the very problem it was meant to solve — the definitions freeze at whatever Windows build was current on the day you copied them, while clients move on.

• Refresh after OS releases. When a new Windows client or Server build ships, download the corresponding ADMX package and mirror it into SYSVOL. Never delete files first: copy over, then review what was removed.
• Keep the language folder in lockstep. An ADMX file without its matching ADML is worse than no file at all. Always copy both, and after any change verify the counts match — mismatches are the fastest way to spot a half-finished update.
• Version control the source. Keep the template package in a repository or a versioned file share so you can answer "which definitions were live when this GPO was authored" months later.
• Back up before you replace. A robocopy /MIR into the store will happily delete definitions that are not in your source. Take a copy of the folder first, or use /MIR only after a dry run with /L.
• Remember the client side. The Central Store only affects authoring. Clients still apply policies from the registry and read their own local templates at C:\Windows\PolicyDefinitions, so a newer ADMX never changes client behaviour — it only changes what administrators can configure.

Common Problems and Fixes

• Editor shows an empty Administrative Templates tree. The en-US folder is missing, empty, or named for a locale the machine does not match. Restore the language files.
• Errors about the [strings] section being too long. A newer ADMX file has been paired with an older ADML (or vice versa). Copy the matching pair together.
• Settings appear under Extra Registry Settings. The store's templates are older than the ones that created the GPO. Update the store.
• Nothing changed after the copy. The editor was already open. Close every instance of gpmc.msc and reopen.
• Some DCs see the store, others do not. SYSVOL replication lag or a stopped DFSR service. Check repadmin /replsummary and DFSR event logs on the affected DC.
• Access denied when a delegated admin opens a GPO. They can read SYSVOL but not the GPO itself. Central Store permissions and GPO delegation are separate; grant rights in GPMC, not on the folder.

Related Guides on This Site

Moving policy content between environments is covered in GPO Export and Import, and if you are building a fresh domain the naming details are in Distinguished Name and Active Directory Schema. For policy-driven deployment of a specific feature see Deploying Windows LAPS and VMware Horizon GPO Templates, and to control the client experience end to end pair the store with Disable Auto Windows Updates and Control Microsoft 365 Group Creation.