Active Directory domain migration with ADMT: Part 1 – General concepts

OK, we have installed our new domain(s) and domain controllers. Now, on with the tricky part: migrating “objects” (users , groups, computers, servers) to the newly installed domain. We will perform a migration from a Windows 2003 domain to another 2003 (see my previous posts for details about domain installation). It will be an “interforest” migration. That means, objects are “cloned”, not “moved” to the target domain, and it is a good thing… I will not go into the “theory” of it (you can find a lot of documentation about this), but I will only list the practical steps of the process. Of course, some concept will emerge every now and then to make myself clear… I used Active Directory Migration Tool (ADMT 3.0) to accomplish the job. NOTE: ADMT 3.1 can only be installed on Windows Server 2008! On Windows 2003, use ADMT 3.0 instead. Preventive checks:
  

Make a regular backup of both source and target domains DCs, and of file servers Do not use Encrypted File System (EFS) Be sure that the time is the same in both domains!

Roughly, we need to follow these steps:
 

 

Create a test domain and DC first Create a test account, migrate it and verify its access to the resources before and after the migration. Always be prepared for a rollback! (You never know… It happened to me a couple of times – details later) Set up a test machine (a virtual one will do) and migrate it from the source to the target domain. (It will be useful for getting comfortable with the process and its problems.) Once it works and all the issues are solved, we will start migrating the “real” domain.

A lot of issues emerge in this phase, so do not underestimate it. In the actual domain, we will create (copy) a “difficult” account, one which uses all the peculiar programs and all the web applications you have in your company, has access to “forgotten” file shares, and so on. You know what I mean. The process of account migration is described in the ADMT manual. Read it, and DON’T FOLLOW IT. It is confusing and IT DOES NOT WORK. Just read it to grab the concepts of migration, but the practical steps described there did not work for me. At the very least, they will take you a lot of time (if they ever work). This is what this post is all about. Moreover, in that document there is a lot of discussion about planning, communication and formalities, which only can be useful if you are part of a BIG TEAM in a HUGE company and

If we have a root domain. nothing will work. from the target domain to the have to document EVERYTHING. create a “DNS forwarder” to reach the target domain (or nothing will work): Start / Administrative Tools / DNS / Server / Forwarders / Add x. These are the steps that we are going to discuss:       Creating the trust relationships between the two domains/forests Creating the necessary “migration accounts” Setting up source and target domain for SID history migration Creating the OU structure in the target domain Installing ADMT in the target domain Identifying the “service accounts” IMPORTANT: in the next examples. I will jump directly into the practical part. Creating the trust relationship between the two domains/forests It is better to create a “two-way” trust between the source and the target (it is simpler. 4 Terminal Servers. In my environment. It would have taken me more time to follow that planning steps than to migrate the domain and document it in a TiddlyWiki. “” the source domain. but don’t overdo it. and “target. we will call “admin” the domain administrator accounts used. This is how:      Log on the source domain DC as a domain administrator.root.x.x (the IP address of a DC of the target domain) (Note: we already created a DNS forwarder the other way around. in order to connect to the Internet (via the default proxy server in the source domain). Restart the “DNS” and “Net logon” services to make the change effective (Start / Administrative Tools / Services) Use “nslookup” to check that the names are resolved (command prompt / nslookup target. Active Directory domain migration with ADMT: Part 2 – Preparing the source and target domains 04Feb09 Let’s begin preparing the domains before the migration. more practical for our purpose). It is very important: if it fails. Do it also from the target towards the source domain. I will skip that. it will be called “” the target“. and the child will then be “target. 20 member servers.x. First of all. 1. and then write it down in this blog… Documentation is“. Create the trust relationship with the target domain: AD domains and trusts / Right click on the domain / Properties / Trusts . 200 pcs. the migration involved 300 users.

Setting up the source and target domains for SID history migration This could be configured manually. / Two-way / Both this domain and the specified domain We need “Enterprise Admin” credentials of the target domain: (if we have a root domain we will use something like “ROOTenterpriseadmin” – password) Go on until the end. depending on the company /domain:source. this way: . we should never use the Windows default “administrator” account.AD users and computers / Builtin / Administrators / Members / Add / Locations / select the source domain / Write “Domain Admins” / “Check names” for security / OK . 5.Exactly in the same /domain:target. but ADMT configures it automatically the first time it is run. and assign the necessary users to these groups Where needed. I will not go into this topic (we have to know what we are doing). So why bother? :-) 4. recreate it again and reboot again until everything works.  New trust / target. 2. in the source domain. Creating the OU structure in the target domain    Create the necessary OUs in the target domain Create administration groups. So:   Create alternate administrator accounts in both domains (we should already have them. involving OUs and /quarantine:no /usero:admin /passwordo:xxx NOTE: sometimes the trust relationship ceases to work… it actually happened to me twice. Note: In the ADMT manual a very different way is explained. Disable SID filtering (via command line) for both sides of the trust: netdom trust source. add the “Domain Admins” group of the source domain to the builtin local “Administrators” group. delegate the OU administration to these groups These are very “free” steps. we will get a warning about SID filtering being enabled. Creating the necessary “migration accounts” As a security policy. add the “Domain Admins” group in the target domain to the group builtin local “Administrators” group. Installing ADMT in the target domain (“SQL Server Desktop Edition” will be installed automatically) . too complex for our purposes… 3. Remove the /quarantine:no /usero:admin /passwordo:xxx netdom trust target. let’s say “admin”) In the target domain.

as per default) Summary / Finish (and reboot. We will always run ADMT as “admin” on the DC of the target domain. Typically these could be Exchange attributes. they are present in the source but not in the target (to check that. Install it on a DC of the target domain. it is because some attributes are not compulsory. see the schema with the Schema Snap-In). But it is complicated. enable auditing?” Choose YES to the prompt “Auditing is currently not enabled on the target domain. we will perform a test migration to prepare the environment:               Log on as “admin” in the target domain (otherwise it will not work) Run Administrative Tools / ADMT Actions / Group account migration wizard Domain selection / Select the source and target domain and the relative DCs Group selection / Select groups from domain / Add / Select group/ (type an existing group name) Organizational Unit selection / Select the OU of the target where the migrated group will go Group Options / Select ONLY “Migrate Group SIDs to target domain”.     Download and run “admtsetup. create it?” Provide admin credentials of the source domain “Exclude specific object properties”: leave it as it is Conflict management / “Do not migrate source object if a conflict is detected in the target” Wait some time in the “Migration progress” window If you get this warning: “ADMT could not migrate some properties for this object type (group) due to schema mismatches”. we could set up a PES (Password Export Server) to migrate passwords.0). a random password will be automatically generated: we will just reset the passwords of the migrated users. just to be safe) If we wish. uncheck everything else Choose YES to the prompt “Auditing is currently not enabled on the source domain. If everything has worked: . and the work is not worth the hassle. enable auditing?” Choose YES to the prompt “The local group SOURCE$$$ does not exist on the source. Now.exe” (ADMT 3. and we will force them to change their password right after the migration (a small effort from their side). Configuring components (a SQL server “MS_ADMT” database instance will be created) Database selection (choose “Use SQL Server Desktop / Express”) ADMT Database import (leave “No”. In the migration process.

does not migrate them. “SOURCE$$$”. and relative DCs Yes. in this order: 1. Account management auditing is enabled both in the source and the target. In the source domain.   In the source domain. Service accounts . For some reasons.Computer configuration / Windows settings / Security settings / Local policies / Audit policy . the entry DWORD “TcpipClientSupport=1” is created in the registry under “HKEY_LOCAL_MACHINESystemCurrentControlSetControlLsa“.AD Users and computes / right click on the domain / View / Advanced features . create it! (In my case.“Audit account management” should have both “Success” and “Failure” selected (default is only “Success”) (this worked). update information / Select computers from domain / Add Choose your application servers (include all servers you have) Agent actions / Run pre-check and agent operation / Start (it will run an agent on the machines to find the service accounts) Once the “Agent actions” window is closed. we will have the list of the service accounts “Skip / Include” selects the accounts to be included from the migration Summary / Finish NOTE: this operation only identifies the service accounts. If it is not created. we now have to migrate objects. NEVER ADD USERS HERE. Check: . a “local group” is created (i. under “Users”). repeating the “SID filtering” part too. after logging in as source domain admin (otherwise for some reasons we have no access rights to the servers) Action / Service Account Migration Wizard Domain selection / Select source domain and target domains. at this point the trust stopped working… I removed and recreated it. Identifying the “service accounts” These are accounts used to execute applications.          Run ADMT in the target domain.e.Right click on “Domain controllers” / Properties / Group policy / Default domain controller policy / Edit . for example ASPNET or SQLSERVER. 6. On to next time! Active Directory domain migration with ADMT: Part 3 – Accounts migration 05Feb09 Once we have performed the “domains preparation” phase. it was not created) and reboot.

some problems arise:    “normal” accounts are used as service accounts services are run under the default administrator account (bad!) the password of the service accounts is unknown (it might have been forgotten and not documented anywhere). and THEN migrate the accounts. Migrating service accounts We already identified them in the previous step. Enable target accounts / Migrate user SIDs to target domains Insert the credentials of the source domain administrator (“admin”. we can’t always “isolate” service accounts to migrate them. Users accounts (keeping SID history) 1. if several services are run by the same account) Migrate all service accounts and update SCM for items marked include Check that:    The log does not contain errors The service accounts have been created in the target OU The applications based on these accounts are still working correctly IMPORTANT: we will face some problems migrating users (both service accounts and “regular” accounts):  If we are migrating to a child domain (like “target. looking at the properties of the migrated user (AD Users and computers / right click on the user / Properties / . Global groups 3. The process would be the following:              Run ADMT (as we have already seen before.txt”. Therefore. now we need to migrate them. We should FIRST fix the inconsistencies we find. We will force them later”). as “admin” on the target) Action / User Account Migration Wizard Domain selection / Select source and target domains and relative DCs User Selection / Select users from domain / Add / Select the accounts from the source domain Organizational Unit selection / Select the target OU Generate complex passwords: they are saved in the file “C:WINDOWSADMTLogspasswords.2. Sometimes.root. in our case) Select ONLY “Update user rights” Exclude specific objects: skip it Do not migrate source object if a conflict is detected in the target Select the accounts to be migrated (they could appear more than once.

but easy to solve: just open the dropdown list and select the right domain. we can repeat the process to migrate all the other users in batches. we have to remember to change the “domain” field of the migrated users. This is very strange. 3. or a single test account first. This will work almost exactly like the migration of the service accounts. The migration of user accounts will happen in three phases: . and reset their passwords to a default. (This can also be done on multiple users. and then one PC: after all issues are solved. We will tell the“.Phase one: account migration  ADMT / Action / User Account Migration Wizard .) The “Change password at next logon” option is active (this option can be changed for all users too) Therefore. We will migrate all groups. The ideal way is to do the next steps for one user.root. Migrate a batch of user accounts. Account tab) we can see that the “domain” field is “@root. at will. Migrating global groups We must migrate global groups BEFORE migrating the users! (Warning: do not migrate the groups in peak hours because a lot of network traffic is generated). and use a much simpler way.          Run ADMT / Action / Group Account Migration Wizard Domain selection / Select source and target domains / DCs (they should be already saved since the first migration) Select groups from domain / Add / Add the group(s) to migrate. immediately after the migration. and that the migrated groups are in the right OUs. (You should have “Security groups” separated from “Application groups” for better management: but this is another topic…) Select the target OU (having separate Security/Application OUs is better) Select ONLY “Migrate Group SIDs to target domain” User Account (provide source domain admin credentials – now it’s becoming repetitive) Object exclusion (leave to defaults) Do not migrate source object if a conflict is detected in the target Check the log for” and NOT “@target. (If something goes wrong. we can easily roll back: more about rollback in a future post). Migrating user accounts (maintaining SID history) Here we will completely ignore the instructions of the ADMT manual. selecting them all and then changing the property. 2. and ask them to change it immediately after their first logon.

net).Phase three: Computer migration This will be discussed in the next post… . a trust relationship must be in place between the Add the target domain to the console: right click on “Group policy management” / Add forest / write the domain’s name (target. Of course.root.    Open the console “gpmc.msc” on source domain (source. we will have to make some modifications to policies:    Copy the logon/logoff scripts from the source domain to the “domaincontrollerNETLOGON” directory of the target Modify the policies in order to specify the new position of the scripts Change the scripts in order to account for the new environment (drive mappings.             Select source / target domains and DCs (you should already be familiar with that) Select users from domain / Add / Select (type) the source domain user account to migrate Select the OU of the target domain where the users will be migrated Do not update passwords for existing users / Generate complex passwords (you will later reset them to a default) Enable target accounts / 90 days until source accounts expire (to be safe) / Migrate user SIDs to target domain Provide source domain admin credentials Select “Translate roaming profiles” and “Fix users’ group memberships” / uncheck “Update user rights” and “Migrate associated user groups” Uncheck “Exclude specific object properties from migration” Do not migrate source object if a conflict is detected in the target Check the log for errors. Of course. etc. It is much like copy and” to “@target. we have to migrate the policies (GPOs) from the source to the target domain. . We have to insure that they work before migrating all the users. Very easy. Obviously. so we need to test them thoroughly with the first migrated test user.Phase two: policy migration Now. change the domain of the migrated users from “@root. Simply duplicate GPOs from one part to” (see above). this step will only be performed once: when the policies are in place we will not need to touch them. in order to apply them to the users (and to the PCs we will migrate later).root. and that the users have been created in the right OU Check if the users have retained their groups Force the password of the migrated users to some default (something like “password” will be OK) If your target is a child domain.) .

we will close the wizard window. we get the following error message: “The Active Directory Migration Tool cannot look up the SID for domain”. and we need to destroy it and create it again from scratch. of course). we must check that the following share: “computer.Phase three: workstations (i. the actual migration process takes place on the target domain DC:           Run ADMT / Action / Computer migration wizard Domain selection / Select the source domain and the target domain and the relative DCs Computer Selection / Select computers from domain / Add / select the computers to be migrated Organizational Unit selection / Select the OU of destination Translate objects / Select ALL Security translation options / Add If .netADMIN$” is reachable (“computer” is the name of the workstation we are about to migrate. though. Computer options / select “1 minute before restart after wizard completion” (it is crucial that the computers performs an immediate reboot after the migration process!) Object property exclusion / (nothing) Conflict management / Do not migrate source object if a conflict is detected in the target. When the migration has completed and we close this window.source. If you do it.Active Directory domain migration with ADMT: Part 4 – Computer migration 06Feb09 . If it does not work. It is not a good thing.e. the “ADMT Agent Dialog”: Call the (human) user to ensure that he stops working and closes all open applications. a new window will open automatically. The process is shown in a “Migration progress” window. sleep and such things (we don’t want to have the PC turned off in the middle of the migration process) Disable firewall and antivirus on the PC (remember to enable them again after the migration!) From the target DC. PCs) migration In order to migrate a PC. we will have to perform the following steps:      Add the “TARGETadmin” user to the the local “Administrators” group of the PC: right click on My Computer / Manage / Users and local groups / Groups / Double click on Administrators / Add / Select the target domain and type “admin” / OK Check that the “Remote Registry” service is running on the PC Deactivate hybernation. it will only work if we enable “File and printer sharing” in the network connection properties of the PC. Now. God forbid. and warn him that the computer will reboot shortly and his password will be reset to a default value (see . it means that the trust relationship has become corrupted. After the process completes. check the previous steps again. In extreme cases. disable it again after the migration.

default forced password). etc. This operation will last a while. If the pre-check passes. typically 10-15 minutes. make sure you reach an agreement with him before you start… I will write another post about user interaction. check again the above mentioned pre-requirements). After the check. proxy access to the Internet.above the “Account Migration” paragraph). The selected computer will be restarted automatically after the preset lapse of time (1 minute after completion. counting down the time to reboot. After the reboot. Do not log on the source domain again. Of course. select “Run pre-check and agent operation” and then “Start” to “translate” the PC ACLs. Check DNS configuration also: sometimes “ipconfig /flushdns” or a reboot is enough) other applications work correctly: email.     Select “Run pre-check” (default) / Start (we expect to see “Passed” after the check: if it does not work. we have to check that everything is working properly:     the user has access to all his network shares printers are working correctly internal Web applications are working correctly (there could be authentication problems: check the web applications authentication method. A message window will warn the user. and log on immediately to the new domain. etc. I repeat. IMPORTANT: reboot the machine. in our case. and LOGON TO THE NEW DOMAIN (old user name. single sign-on procedures. we will SELECT THE NEW DOMAIN from the dropdown of the password dialog. or you will encounter problems. tell the user to change his password immediately. . Once logged on.