GPO Export and Import

原文：GPO Export and Import — theDXT (Daniel Keer)

You’ve spent many hours perfecting your GPO (Group Policy Object) and you have it perfect and you want to import it to another location and well you could look at manually comparing all the settings but no one has time for that. There’s an easier way.

A Group Policy Object is not a single file, it is a small database split between Active Directory and the SYSVOL share, plus a set of linked security principals, WMI filters and inheritance rules. Recreating a mature policy by hand — Drive Maps, Folder Redirection, BitLocker settings, firewall rules, dozens of registry values — is slow, and it is also where mistakes get made. GPMC has shipped with a backup and import mechanism for the better part of two decades precisely because of this, and once you understand what the wizard is doing under the hood, the whole process takes about a minute per GPO.

This post walks through exporting a GPO, importing it on a second server, doing the same job in PowerShell so it can be scripted and scheduled, and the details that trip people up when the source and destination are in different domains.

Why Back Up and Import Instead of Rebuilding a GPO

There are four realistic reasons to move a GPO between machines, and they all benefit from the backup format rather than a screenshot-and-retype approach:

• Building a second site or a new domain. A test domain that mirrors production needs the same baseline, and the fastest way to get there is a restore of the production policy set rather than a rebuild.
• Disaster recovery documentation. A GPO backup folder on a file share is the only human-readable copy of the policy set that survives losing the domain controller completely. The SYSVOL copy that replicates between domain controllers is not a backup — delete the GPO and it replicates the deletion.
• Change control. Taking a backup before a change means you have a rollback that takes seconds. `Restore-GPO` puts it back exactly as it was, including permissions.
• Troubleshooting. Comparing a working GPO against a broken one is a diff of two backups, not a click-through of two consoles.

The backup format also captures things that a manual rebuild will miss: the GPO's security filtering and delegation, the GUIDs behind preference items, and any client-side extension data that has no friendly UI at all.

What a GPO Backup Actually Contains

When you back up a GPO, GPMC writes a folder named with a GUID, plus a `bkupInfo.xml` manifest that ties the folder back to the original GPO by name and GUID. Inside the GUID folder you get:

• Backup.xml — the manifest describing which parts of the GPO are present and the domain the backup came from.
• DomainSysvol\GPO\Machine and ...\User — the same SYSVOL structure you would see in the live policy, including registry.pol, scripts, and preference XML.
• Security descriptor data, which is what allows a restore to put the ACLs back exactly as they were.

Because it is just a folder tree, the backup is portable. You can zip it, copy it to a USB stick or a DFS share, and hand it to a colleague — which is what makes the workflow below work between servers that have no trust relationship at all.

Exporting a GPO with Group Policy Management (GUI)

Open Group Policy Management (gpmc.msc) on the server that holds the GPO you want to export, expand the forest and domain until you see the Group Policy Objects container, then follow the steps below.

1. Right-click the GPO you want to export and select Back Up.

   

2. Give it a location to put the backup, add a comment if you are keeping more than one version, and click Back Up. A UNC path such as \\fileserver\GPOBackups is a better long-term home than a local folder, because the backup then survives the rebuild of the machine you took it from.

   

3. Wait for it to back up your GPO. The status column reports Succeeded with the timestamp and comment of the new backup.

   

After that I zip up the folder but you don’t need to do that — it just keeps the manifest and the GUID folders together when you copy them around, which matters if you use email or a chat client to move the backup.

4. Copy the backup to the destination server, or to a share the destination server can read.

Exporting a GPO with PowerShell

Anything GPMC can do, the GroupPolicy module can do from a script — and this is the version worth putting in your runbook, because it can back up every GPO in the domain in one line:

# One GPO, with a comment
Backup-GPO -Name "Workstation Baseline" -Path "D:\GpoBackup" -Comment "Pre-change snapshot"

# Every GPO in the domain, stamped with today's date
$stamp = Get-Date -Format "yyyy-MM-dd_HHmm"
Backup-GPO -All -Path "D:\GpoBackup\$stamp"

A few practical notes on those two commands:

• -Path must already exist on the machine running the cmdlet. Backup-GPO -All creates one GUID folder per GPO inside it, so a dated parent folder is what you want.
• The cmdlet writes to the local filesystem, so if your long-term store is a share, copy the folder afterwards with Copy-Item or use robocopy /MIR.
• Run it from an elevated prompt on a machine with RSAT, or from a domain controller. The account needs the Back up all GPOs permission, which the Domain Admins group has by default.
• Scheduling the -All line as a daily task gives you a rolling set of dated snapshots and costs almost nothing in disk space.

To see what is in a backup folder before importing it, list the GUID folders and read the manifests:

Get-ChildItem "D:\GpoBackup\2026-09-14" -Directory |
  ForEach-Object {
    [xml]$m = Get-Content (Join-Path $_.FullName "bkupInfo.xml")
    [pscustomobject]@{
      Folder  = $_.Name
      GPO     = $m.BackupInst.GPOInfo.GPODisplayName
      Domain  = $m.BackupInst.GPOInfo.GPODomain
      Time    = $m.BackupInst.TimeStamp
    }
  }

That one-liner is worth keeping: it tells you the original GPO name and the domain it came from, which is exactly what you need to know before running an import.

Importing a GPO with Group Policy Management (GUI)

1. Open Group Policy Management (gpmc.msc) on the server you want to import the GPO to.

2. Make a new GPO and name it what you want (this is the GPO that we will import the backed up GPO into).

3. Right-click your new GPO and select Import Settings.

   

4. Click Next on the welcome page.

   

5. Click on Next again to let the wizard scan for available backups.

   

6. Select the location where you put the exported GPO, then pick the backup and the source GPO from the list. Verify the timestamp so you import the version you meant to.

   

7. Click Next and accept the migration table prompt. If the source and destination are in the same domain you can skip it entirely; cross-domain it is the page where you map old principals to new ones.

   

8. Review the summary and click Next.

   

9. Click Finish.

   

10. Group Policy Management reports the import status and the new settings in the destination GPO.

    

You have now imported the exported GPO into your new GPO. Note what the wizard did not copy across: the original GPO's name, its links to OUs and sites, its WMI filters, and its item-level targeting. Those are separate objects that live in the source domain.

Importing and Restoring a GPO with PowerShell

The scripted equivalent has two flavours, and choosing the wrong one is the most common mistake in this whole workflow:

# Import: copy settings FROM a backup INTO a GPO (existing or new)
Import-GPO -BackupGpoName "Workstation Baseline" `
           -TargetName "Workstation Baseline - Site B" `
           -Path "D:\GpoBackup" `
           -CreateIfNeeded

# Import across domains, using a migration table
Import-GPO -BackupGpoName "Workstation Baseline" `
           -TargetName "Workstation Baseline" `
           -Path "D:\GpoBackup" `
           -MigrationTable "D:\MigTables\CrossDomain.migtable" `
           -CreateIfNeeded

# Restore: put THIS GPO back the way it was, in place
Restore-GPO -Name "Workstation Baseline" -Path "D:\GpoBackup"

Import-GPO -CreateIfNeeded is the useful one for building a lab: name a target GPO that does not exist yet and the cmdlet creates it. If the target already exists, the import overwrites its settings with the ones from the backup.

Import vs Restore — They Are Not the Same Thing

• Import copies settings into a GPO in the current domain. The destination keeps its own GUID, its own name, and its own links, and any importable settings already in it are replaced. Use it to roll a policy template out to a second domain or a second GPO.
• Restore writes a backup over the GPO it originally came from, matching on name and GUID. It also restores the security descriptor, so delegation and security filtering come back too. It refuses to run if the GPO is missing or has been renamed — that is a safety feature, not a bug.
• Neither one restores links. After an import, the GPO sits unlinked in the Group Policy Objects container until you drag it onto the OU or site you want, or run New-GPLink.

So the practical rule: same domain, want it back the way it was — Restore-GPO. Different domain, or want the settings in a differently named policy — Import-GPO.

Cross-Domain Imports and the Migration Table

Policy settings rarely reference a user directly, but they very often reference a group. The classic case is a GPO whose security filtering or a preference item grants access to CONTOSO\Helpdesk; imported verbatim into another forest, that entry points at a group that does not exist, and the setting silently applies to nobody. The migration table is the fix.

A migration table is an XML file that maps source principals (users, groups, computers, and even well-known UNC paths) to their equivalents in the destination domain. In the Import Settings Wizard it is the Migrating References page; standalone, the Migration Table Editor opens as an MMC snap-in on a machine with GPMC installed. Workflow:

1. Start the editor and choose New, but leave it empty rather than pre-populating from a domain, so the wizard fills in only what the backup actually references.
2. Run the import and stop on the Migrating References page; it lists every unresolved reference found in the backup and offers to save them into your table.
3. Fill in the destination column for each row, save the .migtable, and re-run the import with that table. Every reference that does not resolve stays as the original string, which is the behaviour you want to catch in a test pass before touching production.

Two more cross-domain traps worth knowing: built-in principals such as Authenticated Users and Domain Computers always resolve, because they exist in every domain with the same well-known SID; and WMI filters are domain objects, so a GPO that used one arrives with an empty filter and will apply to everything on the other side unless you recreate it and re-link it.

ADMX Templates Do Not Travel With a GPO

A GPO stores only the values you set, keyed by registry path. The friendly labels you clicked come from ADMX/ADML template files installed on the machine you edit policy from. If the destination domain has older templates than the source, a “not configured” looking policy may actually be an unreadable one in the editor, and a handful of newer settings can appear as bare registry values. Keep both sides on the same template version — the practical fix is a Central Store, which replicates the ADMX files through SYSVOL so every admin in the domain edits against the same definitions. We cover that setup step by step in Create Active Directory Central Store.

Version Numbers, SYSVOL and Verification

After the import, verify before you walk away, and verify in the right order:

# Confirm the settings landed
Get-GPO -Name "Workstation Baseline - Site B" |
  Select-Object DisplayName, Id, ModificationTime, UserVersion, ComputerVersion

# Force the client to re-read policy, then produce a report
gpupdate /force
gpresult /h C:\Temp\gpresult.html

Version numbers are the useful part of that first command. A GPO's version is incremented in AD the moment you change it, but the policy files themselves replicate through SYSVOL using DFS Replication, which is not instant. On a multi-domain-controller network you can sit for a few minutes with an updated GPO whose files have not arrived on the DC the client happened to authenticate against, which shows up as settings that apply on one machine and not another. If you suspect that, check replication state with dfsrdiag ReplicationStatus before you start debugging the policy itself.

Troubleshooting Common Failures

• “The backup location does not contain any backups.” You pointed the wizard at the parent folder or the zip. It needs the folder that contains the {GUID} directories and bkupInfo.xml.
• “Access is denied.” The account running the import needs Create GPO and Link GPOs rights in the destination domain, plus read access to the backup share.
• Import succeeds, nothing applies. Check the obvious things in this order: is the GPO linked, is the link enforced or blocked by inheritance, does security filtering still allow the group, and did the WMI filter survive.
• Prefs referencing a missing group. Re-run the import with a migration table rather than editing each item by hand.
• Restore fails on a renamed GPO. Rename it back, or import the settings into a new GPO instead of restoring.

The Short Version

Export with Backup-GPO -All -Path D:\GpoBackup\2026-09-14, copy the dated folder to the destination, then Import-GPO -CreateIfNeeded with a migration table when you cross a domain boundary. Remember that links, WMI filters and ADMX templates are not part of the backup, and that on the same domain a restore is cleaner than an import because it brings the security descriptor back with it.

If your GPOs are managing more than one site, the same techniques scale up — see how templates are used to standardise a virtual desktop fleet in VMware Horizon GPO Templates, and what happens when those policies drift in Deploying Windows LAPS.