Bulk Import of Group Policy Objects between Different Domains with PowerShell
I’ve often worked with administrators who needed to duplicate an existing environment’s set of Group Policy Objects (GPO’s) to either a lab or other production domain. The challenge with that task is the source domain GPO’s typically have domain-specific values included in them such as users and groups identified in the User Rights Assignment section of multiple GPO’s and WMI filters linked to various GPO’s. Typically, none of those values exist in the destination domain, so administrators are forced to either modify every GPO, as a post-import process, or re-create respective users, groups, and WMI filters in the destination domain and manually update a Migration Table. An example of how to use a Migration Table can be found at https://technet.microsoft.com/en-us/library/cc781458(WS.10).aspx. This blog is going to provides examples of how to use PowerShell to automate the Migration Table mapping process and perform a bulk import of GPO’s along with their WMI filters.
As with any other import process of GPO’s and WMI filters into a new or existing Active Directory domain, we must first begin with an export from the source domain. PowerShell scripts to perform bulk exporting and importing WMI filters are available in an earlier blog of mine called Exporting and Importing WMI Filters with PowerShell. Exporting GPO’s is already automated within the Group Policy Management Console (GPMC), so I won’t cover those steps. If you need a review of exporting GPO’s with GPMC, you can find it on TechNet at https://technet.microsoft.com/en-us/library/cc781458(WS.10).aspx). When performing a backup of all GPO’s from the source domain, ensure the destination is set to an empty folder, so there is only one version of each GPO from the source domain in the backup folder. The last piece of the puzzle needed before the scripts come into play is a Migration Table file. The Migration Table file editor is described https://technet.microsoft.com/en-us/library/cc779961(WS.10).aspx. The option we’ll need as output can be created using the “Tools | Populate from Backup” feature from the menu bar of the Migration Table editor (mtedit.exe). Once a copy of the source GPO’s, a Migration Table XML file, and the WMI filters is available, they need to be moved over to the destination domain.
In the destination domain, it’s time for PowerShell to get to work. The PowerShell scripts described below can be found as attachments to this blog. Each script will perform a single step of the import process. The three steps from a high level are as follows:
- Create objects in the destination domain and update the Migration Table XML file.
- Import the GPO’s into the destination domain
- Link WMI filters to the new GPO’s previously joined to the source domain GPO’s
Step 1 is handled by the script called “CreateObjectsFromMigrationTable.ps1.” This script does exactly what its name indicates and more. When running the script, there is only one required parameter: $MigrationTable. That parameter specifies the location of the Migration Table that will be used during the GPO import. Right about now, I can hear some of you asking, “Do I still have to update that Migration Table file? It’s such a pain!” The answer is, “No!” When the “CreateObjectsFromMigrationTable.ps1” is run, it automatically updates the destination elements in the Migration Table file while creating domain objects identified from the source domain in the target domain. For example, if a group named “%source_domain%\Auditors” was used for the User Rights Assignment called “Manage auditing and security log,” the script would create an identically-named group in the destination domain called “%destination_domain%\Auditors” and update the Migration Table XML file with the new value. The scripts can handle users, groups of any type (e.g. Universal, Global, Domain Local), and computer objects. Finally, the script creates a log file that can be reviewed for objects created and other values the script does not currently handle (e.g. UNC paths used in the source GPO’s). The updated Migration Table file can now be used by a GPO import.
Step 2 is handled by a second script called “ImportAllGPOsFromBackup.ps1.” This script requires two parameters: $MigrationTable and $BackupLocation. The $MigrationTable parameter should be set to the new Migration Table XML file created by the first script. The $BackupLocation parameter should be set to the folder location containing the GPO backups. When this script runs, it uses the $MIgrationTable file to import all the GPO’s from the $BackupLocation. It does have limited error checking, so if a GPO already exists in the destination domain with the same name as a GPO being imported, the imported GPO name is prepended with the string “DuplicateGPOOnImport –“ making the duplicate-named GPO’s easy to identify after the import is complete. This script also creates a log file of its activity.
Step 3, the final script, is called “Set-WMIFilterLinks.ps1” and automatically links any WMI filter that was previously linked to the GPO in the source domain to the new GPO in the destination domain. For example if a GPO from the source domain had a WMI filter linked to it called “Windows Server 2008” the new GPO in the destination domain will have the same WMI filter linked to it. In order for this script to work, WMI filters with the same name as the source domain filters must exist in the destination domain. You can achieve that configuration using the scripts from my earlier blog: called Exporting and Importing WMI Filters with PowerShell. This script also creates a log file of its activity.
That does it for the bulk import of GPO’s from one domain to another. The scripts could also be used to perform a recovery of GPO’s and WMI filters, but that situation is probably not as commonly needed. Also, please note that none of the actually GPO links to Sites, Domain, or Organizational Units (OU’s) will be persevered. A tool that does that would require quite of bit of code unless the Sites and OU structures were already in sync or made to be in sync between the source and destination domains.
Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use .