Migrating passwords with the Active Directory Migration Tool

This content is 16 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I’ve spent most of this month working with a customer who is consolidating various Active Directory forests into a single domain. We didn’t use any third party tools – just the standard Microsoft utilities, i.e. Active Directory Migration Tool (ADMT) v3 and Exchange Migration Wizard (one of the Exchange Server 2003 deployment tools) – but they seem to do the job.

As migrating several hundred users to new accounts (with new passwords) would cause a huge number of support calls, I wanted to get the ADMT password migration DLL working. This took some time, but with the help of my enterprise support colleagues (effectively a PSS call), we found a way through. This is what was required:

(For reference, both the source and target domains were in Windows Server 2003 domain and forest functional mode, running Windows Server 2003 with a mixture of service packs 1 and 2.)

  1. Make sure that there is a trust in place between the source and target domains.
  2. Install ADMT by running admtsetup.exe and follow the installation wizard on the computer that will be used for the migration (I used a domain controller in the source domain but ideally you would have dedicated computers for migration activities and it seems logical that this should be in the target domain).
  3. If not already created by ADMT, create a new domain local group called domainname$$$. This group must be empty, and is required in order to migrate the sIDHistory information between source and target accounts.
  4. On the domain controller that will be used to export the account information (usually the DC holding the PDC Emulator operations master role for the source domain), create/set a value of 1 for a DWORD registry key called TcpipClientSupport in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\.
  5. In both the source and target domains, ensure that success and failure auditing is enabled for account management.
  6. On a computer with ADMT installed, create a password encryption key for each source domain, by shelling out to a command prompt and entering the following commands:
    cd %systemroot%\ADMT
    admt key /option:create /sourcedomain:domainname /keyfile:filename.pes

    (the domainname can be specified in NetBIOS or DNS format.)
  7. On the domain controller in the source domain that holds the PDC Emulator operations master role, connect to the computer with ADMT installed (e.g. via the c$ administration share) and access the %systemroot%\ADMT\PES folder.
  8. Run pwdmig.exe to install the ADMT Password Migration DLL and follow the installation wizard. During the installation, supply the password encryption (.PES) file that was created earlier.
  9. This is the step that’s not in the instructions – even though the password encyption file was supplied during the installation of the ADMT Password Migration DLL, it still needs to be imported manually on the PDC Emulator, by shelling out to a command prompt and entering the following commands:
    cd %systemroot%\ADMT
    admt key /option:import /sourcedomain:domainname /keyfile:filename.pes
  10. On the domain controller that will be used to export the account information, create/set a value of 1 for a DWORD registry key called AllowPasswordExport in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\. Note that this key constitutes a security risk and should only be enabled during the period of migration.
  11. Restart the computer with the ADMT Password Migrator DLL installed.
  12. Start the Password Export Server service.

Most of this is exactly as per the documentation – the main difference is the need to manually import the password encryption file. Without this, I was receiving the following message:

Unable to establish a session with the password export server. The source password export server and the target server do not have the same encryption key for the source domain.

Finally, what permissions are required? I used Local System for the Password Export Server service. For everything else, I used an account which had been created in both forests with identical passwords and which was a member of the Domain Admins group. That’s a little excessive, and best practice would involve using an account with the minimum required permissions. Basically, an account is required that is:

  • Domain administrator in the source domain.
  • Local administrator on the computer on which ADMT is installed.
  • Delegated permissions on OUs that are targets for resource migration in the target domain, including the extended right to Migrate SID History (visible in the Security for an object using the Advanced Features view in Active Directory Users and Computers).

Further advice can be found in the ADMT v3 Migration Guide.

6 thoughts on “Migrating passwords with the Active Directory Migration Tool

  1. Thank you for this as I was running into same error and had forgotten to do the import (well I guess forgotten might be the wrong word since the instructions never said to do that!). Saved me a ton of troubleshooting time!


  2. Great write-up. In my particular situation, step 9 was not necessary. Microsoft may have fixed this? I am using ADMT 3.0 (5.3.3790.2113)

  3. I was trying to migrate from 2003 to 2003 in different forest.. with admt v3 tool … there was an error Password Export Service is not running.. ..
    I install new Password Export Service 3 from microsoft rather using windows CD2003 .. It resolve the issue while migrating passwords, SID

  4. Mark ,

    Good article. During a mailbox migration process there will be users who have moved and those who have not , how did you go about configuring the SMTP address space so that mail from the legacy system gets delivered to the new mailserver mailboxes that have been migrated ?



  5. That takes me a back a while Brian, but I’m not sure we were migrating email at that time, probably just Active Directory domain membership, so the mailboxes would have been associated with the new accounts post-migration. Honestly can’t remember the details though!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.