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 DONT 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

you have to document EVERYTHING. In my environment, the migration involved 300 users, 200 pcs, 4 Terminal Servers, 20 member servers. It would have taken me more time to follow that planning steps than to migrate the domain and document it in a TiddlyWiki, and then write it down in this blog Documentation is important, but dont overdo it. I will skip that. I will jump directly into the practical part.

Active Directory domain migration with ADMT: Part 2 Preparing the source and target domains
04Feb09 Lets begin preparing the domains before the migration. 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, we will call admin the domain administrator accounts used, source.net the source domain, and target.net the target domain. If we have a root domain, it will be called root.net, and the child will then be target.root.net. 1. 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, faster, more practical for our purpose). This is how:

Log on the source domain DC as a domain administrator. First of all, create a DNS forwarder to reach the target domain (or nothing will work): Start / Administrative Tools / DNS / Server / Forwarders / Add x.x.x.x (the IP address of a DC of the target domain) (Note: we already created a DNS forwarder the other way around, from the target domain to the source, 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.net). Do it also from the target towards the source domain. It is very important: if it fails, nothing will work. Create the trust relationship with the target domain: AD domains and trusts / Right click on the domain / Properties / Trusts

New trust / target.net / 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; we will get a warning about SID filtering being enabled. Disable SID filtering (via command line) for both sides of the trust:
netdom trust source.net /domain:target.net /quarantine:no /usero:admin /passwordo:xxx netdom trust target.net /domain:source.net /quarantine:no /usero:admin /passwordo:xxx

NOTE: sometimes the trust relationship ceases to work it actually happened to me twice. Remove the trust, reboot, recreate it again and reboot again until everything works. 2. Creating the necessary migration accounts As a security policy, we should never use the Windows default administrator account. So:

Create alternate administrator accounts in both domains (we should already have them, lets say admin) In the target domain, add the Domain Admins group of the source domain to the builtin local Administrators group, this way: - AD users and computers / Builtin / Administrators / Members / Add / Locations / select the source domain / Write Domain Admins / Check names for security / OK - Exactly in the same way, in the source domain, add the Domain Admins group in the target domain to the group builtin local Administrators group. Note: In the ADMT manual a very different way is explained, involving OUs and delegation, too complex for our purposes

3. Setting up the source and target domains for SID history migration This could be configured manually, but ADMT configures it automatically the first time it is run. So why bother? :-) 4. Creating the OU structure in the target domain

Create the necessary OUs in the target domain Create administration groups, and assign the necessary users to these groups Where needed, delegate the OU administration to these groups

These are very free steps, depending on the company organization. I will not go into this topic (we have to know what we are doing). 5. Installing ADMT in the target domain (SQL Server Desktop Edition will be installed automatically)

Download and run admtsetup.exe (ADMT 3.0). Install it on a DC of the target domain. We will always run ADMT as admin on the DC of the target domain. 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, as per default) Summary / Finish (and reboot, just to be safe)

If we wish, we could set up a PES (Password Export Server) to migrate passwords. But it is complicated, and the work is not worth the hassle. In the migration process, a random password will be automatically generated: we will just reset the passwords of the migrated users, and we will force them to change their password right after the migration (a small effort from their side). Now, 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, uncheck everything else Choose YES to the prompt Auditing is currently not enabled on the source domain, enable auditing? Choose YES to the prompt Auditing is currently not enabled on the target domain, enable auditing? Choose YES to the prompt The local group SOURCE$$$ does not exist on the source, 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, it is because some attributes are not compulsory, they are present in the source but not in the target (to check that, see the schema with the Schema Snap-In). Typically these could be Exchange attributes. If everything has worked:

In the source domain, a local group is created (i.e. SOURCE$$$, under Users). NEVER ADD USERS HERE. In the source domain, the entry DWORD TcpipClientSupport=1 is created in the registry under HKEY_LOCAL_MACHINESystemCurrentControlSetControlLsa. If it is not created, create it! (In my case, it was not created) and reboot. Account management auditing is enabled both in the source and the target. Check: - AD Users and computes / right click on the domain / View / Advanced features - Right click on Domain controllers / Properties / Group policy / Default domain controller policy / Edit - Computer configuration / Windows settings / Security settings / Local policies / Audit policy - Audit account management should have both Success and Failure selected (default is only Success) (this worked).

For some reasons, at this point the trust stopped working I removed and recreated it, repeating the SID filtering part too. 6. Identifying the service accounts These are accounts used to execute applications, for example ASPNET or SQLSERVER.

Run ADMT in the target domain, 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, and relative DCs Yes, 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, does not migrate them. On to next time!

Active Directory domain migration with ADMT: Part 3 Accounts migration

05Feb09 Once we have performed the domains preparation phase, we now have to migrate objects, in this order: 1. Service accounts

2. Global groups 3. Users accounts (keeping SID history) 1. Migrating service accounts We already identified them in the previous step, now we need to migrate them. Sometimes, 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).

Therefore, we cant always isolate service accounts to migrate them. We should FIRST fix the inconsistencies we find, and THEN migrate the accounts. The process would be the following:

Run ADMT (as we have already seen before, 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.txt. We will force them later on. Enable target accounts / Migrate user SIDs to target domains Insert the credentials of the source domain administrator (admin, 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, 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.root.net), looking at the properties of the migrated user (AD Users and computers / right click on the user / Properties /

Account tab) we can see that the domain field is @root.net and NOT @target.root.net. This is very strange, but easy to solve: just open the dropdown list and select the right domain. (This can also be done on multiple users, selecting them all and then changing the property.) The Change password at next logon option is active (this option can be changed for all users too)

Therefore, immediately after the migration, we have to remember to change the domain field of the migrated users, and reset their passwords to a default. We will tell the users, and ask them to change it immediately after their first logon. 2. 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).

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. (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 its becoming repetitive) Object exclusion (leave to defaults) Do not migrate source object if a conflict is detected in the target Check the log for errors, and that the migrated groups are in the right OUs.

We will migrate all groups. 3. Migrating user accounts (maintaining SID history) Here we will completely ignore the instructions of the ADMT manual, and use a much simpler way. Migrate a batch of user accounts, or a single test account first. This will work almost exactly like the migration of the service accounts. The ideal way is to do the next steps for one user, and then one PC: after all issues are solved, we can repeat the process to migrate all the other users in batches, at will. (If something goes wrong, we can easily roll back: more about rollback in a future post). The migration of user accounts will happen in three phases: - Phase one: account migration

ADMT / Action / User Account Migration Wizard

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, 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, change the domain of the migrated users from @root.net to @target.root.net (see above).

- Phase two: policy migration Now, we have to migrate the policies (GPOs) from the source to the target domain, in order to apply them to the users (and to the PCs we will migrate later). Of course, this step will only be performed once: when the policies are in place we will not need to touch them. We have to insure that they work before migrating all the users, so we need to test them thoroughly with the first migrated test user.

Open the console gpmc.msc on source domain (source.net) Add the target domain to the console: right click on Group policy management / Add forest / write the domains name (target.root.net). Obviously, a trust relationship must be in place between the two. Simply duplicate GPOs from one part to another. It is much like copy and paste.

Very easy. Of course, 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, etc.)

- Phase three: Computer migration This will be discussed in the next post

Active Directory domain migration with ADMT: Part 4 Computer migration

06Feb09 - Phase three: workstations (i.e. 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, sleep and such things (we dont 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, we must check that the following share: computer.source.netADMIN$ is reachable (computer is the name of the workstation we are about to migrate, of course). If it does not work, check the previous steps again. In extreme cases, it will only work if we enable File and printer sharing in the network connection properties of the PC. It is not a good thing, though. If you do it, disable it again after the migration.

Now, 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 , God forbid, we get the following error message: The Active Directory Migration Tool cannot look up the SID for domain, it means that the trust relationship has become corrupted, and we need to destroy it and create it again from scratch. 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.

After the process completes, we will close the wizard window. The process is shown in a Migration progress window. When the migration has completed and we close this window, a new window will open automatically, the ADMT Agent Dialog: Call the (human) user to ensure that he stops working and closes all open applications, and warn him that the computer will reboot shortly and his password will be reset to a default value (see

above the Account Migration paragraph). Of course, make sure you reach an agreement with him before you start I will write another post about user interaction.

Select Run pre-check (default) / Start (we expect to see Passed after the check: if it does not work, check again the above mentioned pre-requirements). If the pre-check passes, select Run pre-check and agent operation and then Start to translate the PC ACLs, etc. This operation will last a while, typically 10-15 minutes. The selected computer will be restarted automatically after the preset lapse of time (1 minute after completion, in our case. A message window will warn the user, counting down the time to reboot.

After the reboot, we will SELECT THE NEW DOMAIN from the dropdown of the password dialog, and LOGON TO THE NEW DOMAIN (old user name, default forced password). I repeat. IMPORTANT: reboot the machine, and log on immediately to the new domain. Do not log on the source domain again, or you will encounter problems. Once logged on, 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. Check DNS configuration also: sometimes ipconfig /flushdns or a reboot is enough) other applications work correctly: email, single sign-on procedures, proxy access to the Internet, etc.

After the check, tell the user to change his password immediately.