Active Directory Domain Migration With ADMT

Published on February 2017 | Categories: Documents | Downloads: 84 | Comments: 0 | Views: 970
of 10
Download PDF   Embed   Report

Comments

Content

 

Active Directory domain migration with ADMT: Part 1 –   – General General concepts  concepts  OK, we have installed our new domain(s) and domain controllers.

 Now, on with the tricky part: migrating “objects” (users , groups, computers, servers) 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 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 a nd 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

 

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 don’t do n’t overdo it.  I will skip that. I will jump directly into the practical part.

 – Preparing 2 –  Preparing the source Active Directory domain migration with ADMT: Part 2 and target domains  domains  04Feb09

Let’s 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 th e 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 th e 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  /passwordo:xxx  

 NOTE: sometimes the trust relationship 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 n ever use the Windows default “administrator” account. So:    

Create alternate administrator accounts in both domains (we should already have them, let’s say “admin”)    In the target domain, add the “Domain Admins” group of the source domain to the built -





in local “Administrators” group, this way:  - AD users and computers / Builtin / Administrators / Members / Add / Locations / select the source domain / Write “Domain Admins” / “Check “Ch eck 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” gr oup. oup. 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) d efault)  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 “Audit ing 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” con trollers” / 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 accoun accounts ts  “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 3 –   – Accounts Accounts migration  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 accou nts  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 can’t 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”. “C:WINDOWSADMTLogspasswords.t xt”. 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: manage ment: 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 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  u ncheck  “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 domain’s 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 –  4  – Computer Computer migration  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 typ e “admin” / OK   Check that the “Remote Registry” service is running on the PC   Deactivate hybernation, 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, 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 connection properties of the PC. if we enable “File and printer sharing” in the network  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 “ The Active Directory Migration Tool cannot look up the SID f or or 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.

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close