In part one of this two part series I will discuss the process of installing configuring running the Active Directory Migration Tool V3 (ADMT) with the objective of performing and Exchange Interorg migration which is what I was outline in the second part to this series.
At least once in the life of a IT Administrator you will be faced with the situation of an Active Directory and Exchange Inter-org migration, this could be because a company is taking over another company, a business unit needs to be migrated into your AD forest/Exchange Org. For someone who has not performed this type of migration before it might seem like a daunting task, but if you follow the steps outlined in my article there is not much that can go wrong
The following is high level overview of the of steps that should be taken in order, to perform a success fully inter-org AD migration.
-
Pre Migration steps
-
Check/Raise domain functional level of target domain
-
Setup trust relationship between forests
-
Install ADMT 3.0
-
Grant appropriate administrative privileges
-
Setup & configure Password Export Server (PES)
-
Perform migration
A few important notes before I get started:
-
if you are performing Migrations from an NT 4.0 domain please read The Active Directory Migration Tool’s help guide, section Configure the Source and Target Domains to migrate SID History as there are additional steps that need to be performed for migration from an NT 4.0 domain
-
Decrypt any files in the source domain that have been encrypted with EFS or access will be lost.
-
The time should be synchronized in each forest
-
Do regular backups and have a recovery plan
Check/Raise domain functional level of target domain
To perform domain migrations the target domain should be in at least Windows 2000 Native Domain functional level. You should check and change if required by following the steps below:
Open Active Directory Domains and trusts for your target domain | Right click on the domain (in my case NewDomain.Local) | select Raise Domain Functional Level, I have chosen to raise domain to Windows Server 2003 domain functional level (see figure 1)
Figure 1 “Raise Domain Functional Level: Windows Server 2003”
Setup trust relationship between forests
This involves creating a one way trust relationship in which the source domain trusts the target domain.
To begin open Active Directory Domains & Trusts for your target domain Right click properties on your target domain (in my example NewDomain.local) | Select the Trusts tab | Click New Trust (figure 2)
- At the Trust Name window enter the DNS name of the source domain, Next (figure 3)
- At the Direction of Trust window select One-way incoming, Next (figure 4)
- At the Sides of Trust window select Both this domain and the specified domain (figure 5)
Figure 2 “Domain & Trusts NewDomain.local properties”
Figure 3 ”Trust Name DNS name of source domain”
Figure 4 “Direction of Trust: One-way incoming”
Figure 5 “Sides of trust window: Both this domain and the specified domain”
Install ADMT 3.0
The ADMT 3.0 install process is fairly straight forward and you should be fairly right to go with the defaults, unless you want to import data from an Existing ADMT 2.0 database or run centralized databases with multiple ADMT consoles hosted in SQL 2000/2005, instead of the default Microsoft SQL Server Desktop Edition (WMSDE). In Figure 6 I have selected Use Microsoft SQL Server Desktop Edition (Windows) In figure 7 I have chosen not to import data from a previous ADMT V2 database
Figure 6 “ADMT V3 Install User SQL Server Desktop Edition”
Figure 7 “Import data from and ADMT v2 database”
Grant appropriate administrative privileges
To successfully perform migrations & migrate SIDHistory the account performing these migrations should be a member of at least the Builtin\Administrators group in the source domain and Domain Admins group of the target domain.For the purposes of this exercise I will run the migration as the administrator in the target domain
Password Export Server (PES)
This service needs to be installed on a DC source domain and is required if you intend on also migrating passwords with accounts into the target forest. The Servie requires an Encryption key that is generated in the target domain, to export this key from the target domain the following ADMT syntax is used, admt can be found in the following location (C:\WINDOWS\ADMT)
admt key /option:create /sourcedomain: SourceDomain /keyfile:KeyFilePath /keypassword:{password|*}
It is recommended that the PES Encryption key is created to floppy
Before you install the service on the source domain you will need to create an account that will be used for the PES Service to run under, this should be an account in the target domain, and will require the Log on as a service right in the source domain To install password Export Service in Source Domain, perform the following procedure:
Insert the floppy containing the PES Encryption key generated in the target domain into the DC in source domain that the service will be installed in .
Login to this DC/PES server, and execute the following msi C:\WINDOWS\ADMT\PES\Pwdmig.msi
You will first need to specify the path to the PES key you generated earlier (If it is anything other than the default A: ) see Figure 8 below.
Next you will need to specify the password you created on the key, figure 9
The final Window you need to enter data into is the specify a service account window, figure 10 below.
Figure 8 “The ADMT Password Migration DLL – Specify encryption file Window”
Figure 9 “ADMT Password Migration DLL – Specify encryption key password”
Figure 10 “Specify the account the ADMT Password Migration DLL service will run under”
Now that the PES service has been installed and configured in the source domain, we can move on the next task performing the migration.
Perform the migration
**Before getting started one tip for large migrations, users should be migrated in batches, each batch should contain users from the same business units, and/or users that access the same resources, this particularly important when migrating users who share Exchange resources such as delegates to mailboxes.
To begin the AD account migration process Launch the Active directory Migration tool in the target domain, in the console window that opens up right click on Active Directory Migration Tool and select User Account Migration Wizard, this will launch the User Account Migration Wizard
The first window of significance that you will see is the Domain Selection window (figure 11 below) were you specify the source domain and domain controller then the target domain and domain controller.
Figure 11 “the ADMT User Migration Wizard’s Domain Selection Window”
The next window the User Selection Option window(figure 12 below), gives you the choice of choosing users from a selection window or to read the users out of an include file, I am going to go with the first option Select users from domain.
Figure 12 “ADMT User Migration Wizard’s User Selection Option window”
In the User Selection window (figure 13 below) you will need to click add to specify the users you wish to migrate, by clicking on the advanced button you can search for as well as select multiple users in the source domain.
Figure 13 the ADMT User Migration Wizard’s User Selection window
You should now see the Organizational User Selection Window (figure 14 below), here you specify the OU you would like accounts to be migrated into.
Figure 14 “the ADMT User Migration Wizard’s Organizational Unit selection window”
The Password Options window, asks questions regarding the migration of passwords for the migration, the most obvious selections are to Migrate passwords but not for existing users as seen in figure 15 below, additionally you will need to specify the DC that has the Password Export Server Service installed on it.
Figure 15 – ADMT User Account Migration Wizard’s – Password Options Window.
The next window the Account Transition Options window (figure 16 below), is where you specify the various options in regard to the status of the source and target accounts, in most migrations the Target Account State would be set to Target same as source, there may be reasons such as migration of accounts into a resource forest where you would want accounts to be disabled, or if you wanted to control when users could login to target domain.
In the Source Account Disabling Options section of the window, you use these checkboxes if you wanted accounts to either be disabled once the account had been migrated or after a specified number of days.
Note the Migrate User SIDs to target domain checkbox, this is required to successfully migrate exchange mailboxes to a separate forest and therefore will be required.
So what is SID History
SID History is an attribute and is not normally populated, but it is populated on the target account by tools like ADMT during migration, this attribute is populated with is the SID of the source account, and allows the target account to access resources in the source domain as if it were the original account, in affect like having two SIDs. The SID History attribute is also used by the Exchange Migration Wizard to determine the account an exchange mailbox should be linked to during the Exchange mailbox migration process.
To use SID History the target domain must be in native mode!
Figure 16 “ADMT User Account Migration Wizard’s Account Transition Options Window”
Note: one little quirk with ADMT, all accounts that are migrated to the target domain are set “User must change password at next logon”, when these accounts are created in the target domain, regardless of the option you chose in figure 16 above. I am assuming this is a security measure.
The next window you see will depend if you have previously created the group that is required in the source domain to migrate SIDs, if not created this security group SourceDomainName$$$ in my case OLDDOMAIN$$$ a window (figure 17 below) will be displayed asking if I want this group to be created in order for user SIDs to be migrated to the target domain.
Figure 17 “ADMT User Migration Wizard error/prompt create group for migration of SIDs”
Next you will be prompted (figure 18 below) to enter the account for a user with appropriate rights to the source domain so that SID history will be migrated, because we have a trust relationship in place in which the source domain trusts the target domain and the administrator account from the target domain is a member of the the local admins group in the source domain, you can either specify the administrator in the target domain or the source domain.
Figure 18 “ADMT User Account Migration Wizard’s Specify User Account”
On the User Options window (figure 19 below) go with the defaults, this will ensure Profile translation is performed, groups that users are members of are migrated and permissions/group membership is retained.
Figure 19 “ADMT User Account Wizard’s User Options window”
If you want to exclude any specific user object attributes/properties from being migrated, the Object Property Exclusion window (figure 20 below) is where you would exclude them, I am sticking with the default and migrating all User Objet attributes.
Figure 20 “ADMT User Migration Wizard’s Object Property Exclusion window”
The final window with options is the Conflict Management window (figure 21 below) and gives the administrator the option not to migrate an object if a conflict is found in the target domain, or to migrate and merge conflicting objects if a conflict is found. Again I am going with the default, which is not to migrate the source object if a conflict is detected.
Figure 21 “ADMT User Migration Wizard’s Conflict Management window”
If you are happy with the options you selected then proceed with the migration by clicking on the finish button at the Completing the User Account Migration Wizard.
The migration progress window (figure 22 below) will display progress of the migration in real time and alert you of any errors.
Figure 22 “ADMT User Migration Wizard’s Migration Progress window”
Once complete click on the view log button to view any migration anomalies and follow them up before proceeding finally check your migrated accounts in the target domain.
I hope you have learnt something out of this article, my following article will wrap this series up by outlining the inter-org exchange mailbox migration process.
I encourage you to post any questions comments or suggestions, till next time.