On Windows PowerShell and other admin-related topics

Automate Active Directory Migration Tool using Windows PowerShell

Active Directory Migration Tool (ADMT) provides the ability to restructure Active Directory domain structures. It allows you to migrate users, groups and computers between domains, both intra-forest and inter-forest. Features includes password migration, SID migration and security translation among several others.
ADMT was recently released in version 3.2, adding support for Windows Server 2008 R2 and Managed Service Accounts. You can find the download here, and the ADMT migration guide here.

ADMT provides three options on how to use it, where the first and maybe most used is the GUI:


It`s wizard driven and pretty straightforward to use.
The second option is the admt.exe command line utility:


In my opinion this is a pretty good example on how inconsistent various command line tools are compared to PowerShell. Although ADMT is a great tool, hopefully the next version will be rebuilt based on PowerShell.

The third option is scripting. There is a COM-object called ADMT.Migration, and there is a sample VB-script (templatescript.vbs) in the ADMT installation directory (by default C:\Windows\ADMT). This sample script is a good place to start to explore how the COM-object works.

Based on this I`ve written a sample PowerShell script, Invoke-ADMTUserMigration, to migrate user accounts and passwords using Windows PowerShell. This script uses the “ADMTDomain” option, which means that all users from the source OU will be migrated to the target OU. To see other available options, see the ADMT documentation and the sample VBScript. Migrating other objects, like groups and computers, the same way should be pretty easy when comparing Invoke-ADMTUserMigration to templatescript.vbs.

Note that since ADMT is a 32-bit application the script must be run from an x86 instance of Windows PowerShell. It also requires elevated privileges (Run as Administrator). Trying to run it in an x64-bit PowerShell instance or without elevated privileges will result in the following error:
New-Object : Retrieving the COM class factory for component with CLSID {285029CC-5048-4D90-8B38-22D304F513DC} failed du
e to the following error: 80040154.

Before trying to run the script I would recommend that you read the ADMT migration guide and ensures that migration works as expected by running a few test migrations from the GUI.

When this is done, I also would recommend to split the migration in batches as recommended in the migration guide. A maximum of 100 objects at a time might be appropriate. Before moving on to the next batch, check the migration logs (by default in C:\Windows\ADMT\Logs) to see that everything went OK before proceeding.

To take this a step further, I`ve created a function, Migrate-ADMTUser, that migrates a single user object. This would allow you to easily do things like this:
Get-ADUser -Filter {Company -like “Oslo”} | Migrate-ADMTUser

This example combines the Active Directory module for PowerShell with ADMT, allowing us to more fine grained control on what objects to migrate.
Note that both the sample script and sample function I`ve created is meant as a guidance on how to use PowerShell to automate ADMT. The optimal way as I see it would be creating an ADMT PowerShell module with functions for migrate other objects like computers and groups in addition to users and passwords.


ADMT 3.2: Common Installation Issues

ADMT Guide: Migrating and Restructuring Active Directory Domains (TechNet-version)


August 4, 2010 - Posted by | Active Directory management, Migration, Scripting, Windows PowerShell | , , ,


  1. Thanks for this, really good to have an example. Unfortunately the Migrate-admtuser cmdlet\function only works at about 50% for me, it migrates the user but disables the object (even though specified not to) and doesn’t migrate all of the attributes. There’s nothing obvious missing from the script so I’m curious if you have seen similar behaviour? Going through the GUI wizard it works without an issue.


    Comment by CJStrong | August 10, 2010 | Reply

  2. Thanks.
    You could try to set $UserMigration.DisableOption to $admtEnableTarget, although $admtTargetSameAsSource should do the same as long as the source objects are enabled.
    However, if other attributes are missing too, the operation doesn`t seem to have completed successfully.

    Do you see any errors in the migration logs located in C:\Windows\ADMT\Logs?

    Comment by Jan Egil Ring | August 10, 2010 | Reply

  3. Looks like it’s an issue with the ‘Do Not migrate source object if a conflict is detected in the target domain’. We’ve got ILM between the domains so I think that is somehow effecting it. Thanks anyway.

    Comment by CJStrong | August 13, 2010 | Reply

  4. Just want to add my thanks as well for this script. I was wondering, how do you add into the Invoke-ADMTUserMigration script for it to recurse through all the OU’s. I have modified the script to only sync the passwords but at the moment I can only sync a single OU. Reading the ADMT doco it mentions you need to use ADMTRecurse. Any help would be greatly appreciated.

    Comment by Steve | October 27, 2010 | Reply

  5. Great article . however my question is how can we use the event handler (progress and status) using powershell

    Comment by | May 23, 2011 | Reply

  6. Thanks for the script. I tried your script but the user is getting migrated as a disabled account in target, so I ignored the script and went for admt GUI. But now after testing this script, after running the prepare-moverequest & ADMT GUI in the cross forest scenario (2003 to 2010), the users is not shown in 2010 EMC as a mail enabled user (MEU). Because of this the New-MoveRequest is getting failed.

    The script seems to modify some target domain schema and as well as include some exclusion list in ADMT. Please provide your thought on this.

    It would be helpful , if you could provide some points on how to revert the ADMT to its default excluded list and as well as the schema changes in target domain.

    Comment by Abilashak | March 25, 2012 | Reply

  7. Very great article.. could you please suggest how to revert the target domain schema changes and as well as ADMT exclusion list changes made by these script.

    Comment by abilash | March 25, 2012 | Reply

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: