Exchange for Experts
Migration, Active Directory, And You: A Guide for Exchange Admins
Nino Bilic
At a Glance:
- The concept of SID history
- Migration of accounts between domains with SID
- Overview of ADMT
- Using ADMT with an Exchange migration
Exchange Server
Active Directory
Migration
Security
If you're a Microsoft Exchange Server administrator you should learn about the Active Directory Migration Tool (ADMT). It is, after all, an Active Directory service tool and not an Exchange Server utility.
In my experience, however, the account migration process has caused trouble for many mail admins. In this article, I'll look at migrations from 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 functionality that can simplify this process.
I work in Microsoft Support Services, so I step in after things have gone wrong. So my goal is to prevent mistakes in the first place. While many customers use non-Microsoft products rather than ADMT, I will focus on ADMT with an overview of its place in an Exchange Server migration and how it helps achieve Windows NT® account migration.
What is ADMT?
ADMT 1.0 was released with Windows 2000 Server; version 2.0 shipped with Windows Server 2003. You can get this latest version from the Windows Server 2003 Web site. You can use the ADMT to migrate users, computers, and groups from one domain to another. This sort of migration is associated with a migration from a Windows NT 4.0 domain to an Active Directory® domain, usually as part of a move from Exchange Server 5.5 to Exchange 2000 Server or Exchange Server 2003.
One of the major improvements in the new version of the ADMT is its ability to migrate user passwords as well as accounts, making the whole process much easier. However, there are situations in which the length and complexity of the previous password does not satisfy the policy requirements of the Active Directory service. In such cases users will have to change their passwords to meet the new requirements.
Using ADMT
Running the Active Directory Migration Tool is a six-step process:
- Run Setup for the Active Directory Mi-gration Tool (available on the Windows Server 2003 CD at \i386\ADMT).
- In Control Panel or on the Start menu, click Administrative Tools, then click the Active Directory Migration Tool.
- When the window opens, right-click ADMT, and click User Account Migration Wizard. (Some options might be unavailable until you perform a successful migration for some accounts.)
- Click Next on the initial page of the User Account Migration Wizard.
- Select either "Test the migration set-tings and migrate later" or "Migrate now." This is helpful if you are testing your migration before changing your production environment (a recommended best practice). Select the appropriate option and click Next.
- 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.
Note that the target domain must be running in Native mode to use the ADMT. If you are running the ADMT for the first time, there are several tasks that it must perform to ensure that your migration is successful. These include, but are not limited to, testing prerequisites, modifying registry entries on the Windows NT 4.0 primary domain controller (PDC) and restarting it, and modifying the security policy on Windows 2000 Server or Windows Server 2003.
The tasks that the ADMT performs depend on the options and types of domains that you have chosen. The ADMT Wizard will prompt you for all the necessary info throughout the migration process. Be sure to keep the readme file included on the CD close at hand during this stage. The documentation can answer questions about the required configuration and prerequisites.
Migration with the SID
The Windows® permission model is based on user security identifiers (SIDs) rather than user names. An SID is a long number that uniquely identifies a user whenever he 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. This is also why, if you delete a user, you can't simply recreate the user with the same name to allow access to resources for which he previously had permissions. The SID of the new account will not match the SID of the old account, and you will need to reassign permissions for the new account.
The multi-valued sIDHistory attribute is added to the target account being migrated, and is populated with the SID of the original account, from the source domain.
Assume that Domain A is your source domain and Domain B is your destination domain, as shown in Figure 1. If the account is migrated with SID, the migrated account in Domain B will have an attribute called sIDHistory that holds the SID of the original account from Domain A.
Figure 1** Migration with SID Option **
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 for which the original account (in Domain A) had rights. Here a resource is anything with permissions, such as an NTFS share or a printer.
The Exchange Active Directory Connector (ADC) uses the SID in the sIDHistory attribute when matching the Exchange Server 5.5 directory object to the Active Directory account. Let's consider the following scenario. A machine running Exchange Server 5.5 is in Domain A and the primary Windows NT account of the Exchange Server 5.5 mailbox is the account in Domain A. This account is migrated using the ADMT and the SID History. An account is created in Domain B that has the SID of the Domain A account stamped on its sIDHistory attribute. Next, an ADC Recipient Connection Agreement is set up from the machine running Exchange Server 5.5 in Domain A to a DC in Domain B. When the ADC runs, it checks the primary Windows NT account of the Exchange Server 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 append a "-1" to its name. For more about this issue, see Knowledge Base article 256862, "XADM: How to Correct Mismatched Accounts After Active Directory Connector Replication".
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 this, then the SID History is present. If the attribute is missing or marked "Not set" (if you are viewing it using ADSI Edit, for example), the SID History was not migrated for that specific account.
Note that 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.
To migrate accounts with the SID, you must select the checkbox titled "Migrate user SIDs to target domains" on the Account Transition Options page of the ADMT.
SID History and EDMW
After your accounts have been migrated from Domain A to Domain B with the SID option selected, you might want to address another issue. Exchange Server 5.5 mailboxes are set up to have Domain A's Windows NT accounts as the primary Windows NT accounts, but the ADC associated those mailboxes with the Active Directory (migrated) accounts based on the SID History.
Optionally, 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 Server 5.5, you should use the Exchange Directory Migration Wizard (EDMW) to simplify things. If you did not, later on (when you run ADC and create a Recipient Connection Agreement), the ADC will still match the Exchange Server 5.5 mailbox with the account that was migrated with ADMT using sIDHistory. If you use EDMW first, however, your permissions will be cleaner.
To switch the Exchange Server 5.5 primary Windows NT account to the new migrated Active Directory account, you must run the EDMW; this option becomes available after you migrate the accounts.
The main role of the EDMW is to switch the primary Windows NT account of the mailbox. It should then set the Access Control Lists (ACLs) on the Exchange Server 5.5 directory objects to replace/add/remove (depending on which option you choose) any mention of the Windows NT 4.0 account with the new migrated Active Directory account. Using this wizard, you replace all references to the source account with the migrated account (with the same permissions) on all objects stored in the Exchange 5.5 directory. After you run EDMW, your users will start logging into their Exchange Server 5.5 mailboxes with newly migrated accounts in Active Directory. Next time the users log onto the domain, they should choose the Active Directory domain as their logon domain and use the name and the password of their Active Directory account.
In Control Panel or on the Start menu, click Administrative Tools, then ADMT. When the window opens, right-click the ADMT, then click User Account Migration Wizard. Click Next on the initial page of the User Account Migration Wizard.
At this point, select either "Test the migration settings and migrate later" or "Migrate now." Select the appropriate option and click Next. On the Security Translation Options page, you can select the following tasks to perform using the Exchange Directory Migration Wizard: Replace, Add, and Remove. Replace causes any mention of the original source domain account to be replaced with the target domain account, with the same permissions. Add leaves the source domain account, but also adds the target domain account, with the same permissions. Remove causes the source domain account to be removed after you run the Add option discussed earlier. After making your selection, simply complete the remainder of the wizard, which will modify the Exchange Server 5.5 directory.
Migration with EDMW Only
Because the EDMW can switch the primary Windows NT account on the Exchange Server 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 on accounts. This would be helpful for organizations that have already migrated Windows NT accounts, but have not migrated them with SID, and now need to complete the migration.
There could be situations in which you need to access resources in the Windows NT domain with the Active Directory account, in which case the SID History would be necessary. Using EDMW will resolve access issues only on Exchange Server 5.5 directory objects—it will not help with any source domain NTFS permissions or other resources that the user from the target domain might need to access after the account was migrated. If you choose to use the EDMW and not migrate the SID History, take the following steps:
- Migrate the accounts using the ADMT, but without the SID History.
- Run the EDMW and in the Exchange Server 5.5 directory replace the 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 accounts of the Exchange Server 5.5 mailboxes will be changed to the new migrated accounts in the Active Directory domain.
- Replicate the Recipient Connection Agreement in the Active Directory Connector snap-in. 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.
You should note that duplicate accounts might still be created if multiple mailboxes are associated with the same Windows NT account on the Exchange Server 5.5 side. Running the EDMW does not resolve this problem. Use the ADC Tools Wizard to avoid this problem if you are using the Exchange Server 2003 ADC. If you are using the Exchange 2000 Server ADC, see the NTDSNoMatch Utility at Documentation for the NTDSNoMatch Utility.
For additional information see: ADMT docs at Windows Server 2003 Tools, Active Directory Migration Tool 2.0 Interactive Simulation, and the Support Webcast at Domain Migration Using the Microsoft Active Directory Migration Tool.
Nino Bilic is a Technical Lead for Microsoft Exchange Administration at the Las Colinas, Texas support site. He posts to the Exchange team blog at blogs.msdn.com/exchange.
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.