Export (0) Print
Expand All
Expand Minimize

What Exchange Administrators Need to Know About the Active Directory Migration Tool

 

Topic Last Modified: 2007-12-28

Published: August 03, 2004

By Nino Bilic

You might wonder why Exchange administrators should learn about the Active Directory Migration Tool (ADMT), because it’s an Active Directory directory service tool instead of an Exchange tool.

In my experience, account migration is a point at which many of our customers get into trouble during migrations from Microsoft Exchange Server 5.5 to Exchange 2000 Server and Exchange Server 2003. Version 2 of the ADMT, which was released with Microsoft Windows Server 2003, has some extremely useful Exchange-related functionality that can simplify this process.

Many customers use non-Microsoft products rather than the ADMT. Using non-Microsoft products is fine as long as you know exactly what you are trying to do. I usually step in after things have gone wrong and have written this article to try to prevent them from going wrong in the first place.

I have included an overview of how Windows NT account migration is achieved with the ADMT and described its place in an Exchange migration.

Version 1 of the ADMT was released with Microsoft Windows 2000 Server. As mentioned earlier, Version 2 of the ADMT was released with Windows Server 2003. It is found on the Windows Server 2003 CD.

You can use the ADMT to migrate users, computers, and groups from one domain to another domain. This sort of migration is most often associated with a migration from a Windows NT 4.0 domain to an Active Directory domain.

One of the major improvements in the new version of the ADMT is that it can migrate users’ passwords. This can make the migration much more seamless for users because you do not necessarily need to ask them to create new passwords when their accounts are migrated. They can continue to use their old Windows NT 4.0 passwords. However, there can be situations in which the length and complexity of the old Windows NT 4.0 password does not satisfy the policy requirements of the Active Directory directory service, so you might want to require users to change their passwords when their accounts are moved.

  1. Run Setup for the Active Directory Migration Tool from the Windows Server 2003 CD (at \i386\ADMT).

  2. In Control Panel or on the Start menu, click Administrative Tools, and then click Active Directory Migration Tool.

  3. When the window opens, right-click Active Directory Migration Tool, and click User Account Migration Wizard.

    noteNote:
    Some options might be unavailable until you perform a successful migration for some accounts.
  4. Click Next on the initial page of the User Account Migration Wizard.

  5. At this point, you can select either Test the migration settings and migrate later or Migrate now. This is very helpful if you are testing your migration before changing your production environment (a recommended best practice). Select the appropriate option and click Next.

  6. Choose the domains to be used in your migration. The domains that are available are determined by your current forest and any trusts that you have in place.

importantImportant:
The Target domain must be running in Native mode to use the Active Directory Migration Tool.

If you are running the Active Directory Migration Tool for the first time, there are several tasks that the ADMT must perform to ensure that your migration is successful. These tasks include, but are not limited to:

  • Testing prerequisites

  • Modifying registry entries on the Windows NT 4.0 primary domain controller (PDC)

  • Restarting the Windows NT 4.0 PDC

  • Modifying the security policy on the Windows 2000 Server or Windows Server 2003 side

The tasks the Active Directory Migration Tool performs depend on the options and types of domains that you have chosen. A discussion of all possible options and types of domains is beyond the scope of this article. However, you will be prompted through the process.

noteNote:
Keep the Readme file included on the CD close at hand during this stage.

The Windows NT permission model is based on user security identifiers (SIDs) rather than the user name. A user’s SID is a long, unique number that uniquely identifies a user whenever he or she tries to access any resource in the domain. This makes it possible for you to rename a user’s domain account without having to reassign user permissions for the new account name. This is also why, if you delete a user, you will not be able to simply re-create the user with the same name and have access to resources for which you previously had permissions. You will need to reassign permissions for the new account. The SID of the new account will not match the SID of the old account.

SID History is frequently mentioned in relation to Windows and Exchange migrations. The sIDHistory attribute is added to the account being migrated. It is populated with the SID of the original logon account.

Assume that Domain A is your source domain and Domain B is your destination domain. If the account is migrated with SID History, the migrated account in Domain B will have an attribute that holds the SID of the original account from Domain A.

There are at least two reasons why it is necessary to use SID History:

  • The presence of the sIDHistory attribute on the migrated account in Domain B allows the account to access any resources that the original account (in Domain A) had rights on. Resource in this context means anything that you set permissions on (for example, an NTFS share or a printer).

  • The Exchange Active Directory Connector (ADC) uses the SID History when matching the Exchange 5.5 directory object to the Active Directory account.

    Example: An Exchange 5.5 server is in Domain A and the primary Windows NT account of the Exchange 5.5 mailbox is the account in Domain A. This account is migrated using the Active Directory Migration Tool and the SID History. An account is created in Domain B that has the SID of the Domain A account stamped on the sIDHistory attribute. Next, an ADC Recipient Connection Agreement is set up from the Exchange 5.5 server in Domain A to a domain controller in Domain B. When the ADC runs, it checks the primary Windows NT account of the Exchange 5.5 mailbox and reads its SID. It finds a match in Active Directory because the SID History is stamped on the migrated account. If no SID History was present on the Domain B account, the ADC could create a new disabled account and include a “-1” in its name. For more information about this issue, see Microsoft Knowledge Base article 256862, How to correct mismatched accounts after Active Directory Connector replication in Exchange 2000 Server.

When you view the sIDHistory attribute in Active Directory using an LDAP tool such as LDP.exe, the attribute will look something like the following:

1> sIDHistory: S-1-5-21-1619521004-1441481110-1935294565-1315;

If you see an attribute on the user account that looks like the preceding example, then the SID History is present. If the attribute is missing or is marked as “Not set” (if you are viewing it using ADSI Edit, for example), the SID History was not migrated for that specific account.

noteNote:
The SID listed on this attribute will match the SID of the original account from the original domain (the domain from which the account was migrated). The migrated Active Directory account will have its own unique SID. This is important to understand. You do not end up with two accounts in two domains that have the same SID. The Active Directory account has its own SID as well as the SID of the “original” account stored in the sIDHistory attribute.

If you want to migrate accounts using the SID History, you must specify this on the Account Transition Options page of the Active Directory Migration Tool. Select the check box titled Migrate user SIDs to target domains.

After your accounts have been migrated from Domain A to Domain B with the SID History option selected, you might want to address another issue. Exchange 5.5 mailboxes are set up to have Domain A's Windows NT accounts set as the "Primary Windows NT account" and the ADC has associated that mailbox to the Active Directory (migrated) account based on the SID History.

noteNote:
This step is optional. If you want your users to start logging on using the new migrated Active Directory accounts and access the mailboxes that were not yet moved from Exchange 5.5, you should use the Exchange Directory Migration Wizard (EDMW).

To switch the Exchange 5.5 Primary Windows NT account to the new migrated Active Directory account, you must run the EDMW. The option to run the EDMW becomes available after you migrate the accounts.

The primary role of the Exchange Directory Migration Wizard is to switch the primary Windows NT account of the mailbox and set the access control lists (ACLs) on the Exchange 5.5 directory objects to replace/add/remove (depending on which option you choose) any mentions of the Windows NT 4.0 account with the new migrated Active Directory account. Using this wizard, you can accomplish the task of replacing all mentions of the source account with the migrated account (with the same permissions) on all objects stored in the Exchange 5.5 directory.

  1. In Control Panel or on the Start menu, click Administrative Tools and then click Active Directory Migration Tool.

  2. When the window opens, right-click Active Directory Migration Tool and click User Account Migration Wizard.

  3. Click Next on the initial page of the User Account Migration Wizard.

  4. At this point you can select either Test the migration settings and migrate later or Migrate now. Select the appropriate option and click Next.

  5. On the Security Translation Options page, you can select different tasks to perform using the Exchange Directory Migration Wizard:

    • Replace   Choosing this option causes any mention of the original source domain account to be replaced with the target domain account, with the same permissions.

    • Add   Choosing this option leaves the source domain account, but also adds the target domain account, with the same permissions.

    • Remove   Choosing this option causes the source domain account to be removed after you run the Add option discussed earlier.

  6. Complete the remainder of the wizard, which will modify the Exchange 5.5 directory.

Because the EDMW can switch the primary Windows NT account on the Exchange 5.5 mailbox to be the migrated account from the target domain, you can be certain that the correct match will be found when the ADC is run.

In this situation, you might not need to migrate the SID History on accounts. This would be helpful for organizations that have already migrated Windows NT accounts, but did not migrate them with SID History, and now need to complete the migration.

noteNote:
There could be situations where you need to access resources in the Windows NT domain with the Active Directory account, in which case the SID History would be necessary

If you choose to use the EDMW and not migrate the SID History, the migration path would be as follows:

  1. Migrate accounts using the Active Directory Migration Tool but without the SID History.

  2. Run the EDMW, and replace (in the Exchange 5.5 directory) security references of the source domain account with those of the destination domain (migrated) account. As a result, among other things, the Primary Windows NT account of the Exchange 5.5 mailboxes will be the new migrated account in the Active Directory domain.

  3. Run the ADC. Because the new migrated Active Directory account is now the primary Windows NT account of the mailbox, the ADC should find the match and no duplicate objects should be created.

noteNote:
Duplicate accounts might still be created if multiple mailboxes are associated with the same Windows NT account on the Exchange 5.5 side. Running the EDMW does not resolve this problem. To avoid this problem if you are using the Exchange 2003 ADC, use the ADC Tools Wizard. If you are using the Exchange 2000 Server ADC, see Microsoft Knowledge Base article 274173, Documentation for the NTDSNoMatch utility.

Some helpful information about the Active Directory Migration Tool:

 
Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft