This script is fairly straightforward and uses the Active Directory module for PowerShell. Here are some gotchas I came across during the creation and testing of this script:

1. The OU structure and Site names must be the same between the source and destination domains. By default, the script logs an error at C:\GPOLinksLog.txt if a particular OU or Site does not exist. There are probably plenty of scripts in Internet land that can be used to duplicate OU structures and sites, so happy searching!

2. The script overwrites the "gPLink" attribute during the Import process. That means any already existing links on the particular OU or Site will be overwritten. For more information about the gPLink attribute and gpLinkOptions, see https://msdn.microsoft.com/en-us/library/cc232505.aspx

3. By now, you should have already completed the steps in my previous blog post: Bulk Import of Group Policy Objects between Different Domains with PowerShell. If GPO's with the same name between the source and destination domain do not exist, the script will not be very effective. You may also want the old WMI filters linked. Scripts for that process are located here (for Exporting) and here (for Importing).

4. If the Input option is used and a particular GPO does not exist, an error is logged in the LogFile location, but the script still links the other GPO's that do exist on particular object. If none of the GPO's linked to an object exist, no action is taken on that object, and an error is logged.

Now, let's see how easy the script is to use. There are three switches:

-OutputFile: This switch is used to export GPO Links from the source domain. The full path to the desired file should be specified (e.g. -OutputFile C:\temp\migratelinks.txt) otherwise a relative path to the file specified is used.

-InputFile: This switch is used to import GPO Links to the destination domain. The full path to the desired file should be specified (e.g. -InputFile C:\temp\migratelinks.txt) otherwise a relative path to the file specified is used.

-LogFile: This optional switch is used to specify a log file (e.g. -LogFile C:\temp\LogFile.txt). The default value is C:\GPOLinksLog.txt.

When specifying OutputFile or InputFile, at least one and only one of the two switches must be specified. Helpful reminders of this rule will be displayed if both or neither value is specified.

Here's an example of how to use the script as a defined process:

1. On a source Domain Controller, run "Import-and-Export_GPO_Links.ps1 -OutputFile C:\temp\migration.txt"

2. Move "migration.txt" to a destination Domain Controller and put it into the "C:\temp" folder.

3. On the destination Domain Controller, run "Import-and-Export_GPO_Links.ps1 -InputFile C:\temp\migration.txt"

4. Review the log file for any errors.

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.

Import-and-Export_GPO_Links_Final.zip

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:

1. Create objects in the destination domain and update the Migration Table XML file.
2. Import the GPO’s into the destination domain
3. 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.

Bulk_Import_of_GPOs_Between_Domains_PowerShell_Scripts.zip

The backup file can be imported into Excel for easy modification of any particular field or the removal of filters by deleting the corresponding row in the backup file. The following script uses the backup file to create new WMI filters in the destination domain (the script is also attached as Import_All_WMI_Filters.ps1):

Let's take a closer look at what is going on in this script.

It starts by requiring the administrator to provide the $BackupFile parameter. If the parameter is not provided, the script exits and notifies the administrator.

Next, we import the Active Directory Modules for PowerShell and populate the $WMIFilters variable with a full collection of WMI filters from the source domain along with the Name, Description, and Query for each filter described earlier. The headers are also inserted to allow for easy identification later in the script.

Now we enter a for loop processing each row in the $BackupFile. In order to create the new WMI filter object (msWMI-Som objectClass), we'll need a new Globally Unique Identifier (GUID) stored in $WMIGUID. Using the GUID, we store the Distinguished Name (DN) in the $WMIDN variable. We'll also need the Container Name ($WMICN). The Container for WMI filters in Active Directory is represented by the GUID. The DN of the new WMI filter is then stored for later use in $WMIdistinguishedname. Finally, the GUID is stored for later use in $WMIID.

The next section prepares more variables for use later in the script. $now stores the current date/time (UTC). $msWMICreationDate stores the date/time in a converted format for storage in the msWMI-CreationDate attribute of the WMI filter. Finally, the Name, Description, and Query of the WMI filter are stored in $msWMIName, $msWMIParm1, and $msWMIParm2 variables, respectively.

The last two variables we'll need to create the WMI filter are $Attr and $WMIPath. $Attr represents all the attributes required for creating a WMI filter object in Active Directory. $WMIPath identifies the DN of the location where WMI filters are stored in Active Directory.

The final line in the script is what creates the new WMI filter object. The parameters passed to the "New-ADObject" command are as follows:

• -name: The Container Name of the WMI filter in Active Directory (not the friendly name)
• -type: The objectClass for WMI filters (msWMI-Som)
• -Path: The DN of the location where WMI filters are stored in Active Directory
• -OtherAttributes: The attributes required to create the new WMI filter object

That does it for the import script. There is one special note to be made during the import process: There is no error checking. Also, if you have existing WMI filters in your domain with names that conflict with the names of the WMI filter you are importing using this script, new WMI filters with the same friendly name will be created (your existing ones will not be updated or impacted in any way). Still, I recommend working out those conflicts before running the import script or the conflicting names can eventually lead to confusion when administering WMI filter links and filters.

My next series of scripts will provide administrators with a way, using PowerShell, to perform bulk imports of Group Policy Object and perform automated linking of previously-linked WMI filters to those GPO's. Sounds exciting, right?

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.

Import_All_WMI_Filters.ps1

Since I'll be writing about WMI filters, it's only appropriate for me to give a shout out to Mike Stephens. Mike, without knowing it, helped push me to write this blog based on a post of his back in 2008 on the Directory Services Team Blog: bulk-exporting-and-importing-wmi-filters-for-group-policy. I decided to put PowerShell to the test and come up with another method of exporting and importing WMI filters in Active Directory. Before you keep reading this post, take a second to visit this site if you're just looking for a way to create a ton of boxed WMI filters for your environment. My post is directed at those administrators who want to duplicate an existing environment. I will, however, admit that a large piece of the import script you see in "Exporting and Importing WMI Filters with PowerShell: Part 2, Import" came directly from that site (that does it for my anti-plagiarism plug).

Anyone who has worked with Group Policy has undoubtedly used Group Policy Management Console (GPMC). With GPMC, creating, linking, and deleting Group Policy Objects (GPO's) and WMI filters is a snap. The biggest challenge with GPMC, as Mike mentioned back in 2008, is still how to export and import WMI filters. The painstaking process of individually exporting and importing the filters can take good chunk out of your workday. In my experience, this process itself ends up being repeated multiple times since there is always someone asking for a "dump" of production GPO's and WMI filters for their lab (or even for some other production system they happen to be building without you - nothing personal).

Welcome, PowerShell. Since the introduction of Active Directory modules for PowerShell, administrators have had a new tool in their arsenal. Rejoice, and take advantage of it! When it comes to managing Active Directory objects, PowerShell is quite "PowerFull." WMI filters, of course, fall into that category. Since WMI filters are all from an objectClass called "msWMI-Som," we can collect all WMI filters in a domain using the following command:

$WMIFilters = Get-ADObject -Filter 'objectClass -eq "msWMI-Som"' -Properties "msWMI-Name","msWMI-Parm1","msWMI-Parm2"

What doe all that mean? Here's a quick breakdown:

$WMIFilters: This value is just an object we are creating to store our WMI Filters

Get-ADObject: This cmdlet allows us to populate our object with a collection object AD objects matching the -Filter parameter

-Filter: This parameter allows us to filter on what objects will be returned from the query. Since we know WMI filters are of objectClass "msWMI-Som" the filter is pretty straightforward.

-Properties: This parameters allows us to specify which AD attributes should be collected for the objects returned by the query. With WMI filters, we really only care about three attributes for WMI filters:

• msWMI-Name: The friendly name of the WMI filter
• msWMI-Parm1: The description of the WMI filter
• msWMI-Parm2: The query and other related data of the WMI filter

The following script is also attached to this post as Backup_All_WMI_Filters.ps1.

So what does this script do? Let's check it out.

It starts by allow the person running the script to provide just one parameter called $BackupLocation. If that parameter is not specified, it defaults to C:\WMI_Full_Backup.csv. Either way, the file content is set to $NULL.

Next, we import the Active Directory Modules for PowerShell and "dump" a full collection of WMI filters from the domain along with the Name, Description, and Query for each filter described earlier.

Now comes the actually export process. We'll run through a loop for each WMI filter in our $WMIFilters collection and do two things: Structure a tab-delimited string that will be added to our $BackupFile and append that string to our $BackupFile.

The last two commands in the script just present a clean output the console to notify the administrator the script is complete. Notice there was not a ton of error-checking in this script. Who has time for that?

By now, you have noticed we don't have actual WMI filters at all. In fact, we only have exactly what we need. The Name, Description, and Query will work fine for the import process. The backup file can be imported using the script provided in Exporting and Importing WMI Filters with PowerShell: Part 2, Import.

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.

Backup_All_WMI_Filters.ps1