Active Directory Migration Considerations (Part 7)

If you would like to read the other parts in this article series please go to:

• Active Directory Migration Considerations (Part 1)
• Active Directory Migration Considerations (Part 2)
• Active Directory Migration Considerations (Part 3)
• Active Directory Migration Considerations (Part 4)
• Active Directory Migration Considerations (Part 5)
• Active Directory Migration Considerations (Part 6)
• Active Directory Migration Considerations (Part 8)

Let's start with a quick recap of the previous articles in this series in case you've jumped into it at this point:

• The first three articles in this series listed general considerations concerning Active Directory restructuring projects and highlighted some of the limitations involved when using ADMT to perform forest or domain migrations or consolidations. Key topics covered in these articles included:
• Finding the latest version of ADMT
• The cost factor and mitigating costs
• Migrating servers and applications
• Slow retirement
• Migration Rollback
• ADMT scalability
• Other ADMT limitations

• The fourth and fifth articles discussed some specific issues relating to the use of the ADMT itself and things you need to be aware of during the planning stage of your migration/consolidation project. Key topics covered in these articles included:

• Which first, consolidate or upgrade?
• SID history and ADMT
• Migrating local user accounts
• Migration and schema modifications
• Migrating without trusts

• The sixth article described some tips and gotchas that can be helpful when using ADMT for Active Directory migrations/consolidations.

• Migrating user profiles
• Various kinds of ADMT fails

This seventh article continues by listing some additional questions that can frequently arise when planning a forest or domain migration or consolidation project using ADMT and suggests some possible answers to these questions. Many of these questions (and their answers) have been passed on to me from IT colleagues who have worked on various migration projects, and I haven't been able to test most of them so their recommendations are presented "as is" in this article.

Moving some PCs to a new forest

Question: We have a bunch of PCs in forest A and the employees are moving over to a subsidiary company and they want to take their PCs along and join them to forest B. Do we need to disjoin these PCs from forest A before they take them out the door?

Answer: Wrong question! You should be asking whether there are any security risks with simply moving PCs from one company to another. For example, since the PCs are domain-joined they likely have cached passwords on them. There may also be sensitive business information in various documents in the user profile folders of the old user accounts on these machines.

If you're going to let employees walk out the door with PCs like this, you really need to wipe their hard drives first and then let the admin at the new company re-provision them.

Regardless however, you don't need to disjoin them first from forest A before joining them to forest B, you can simply delete the computer accounts for these machines in forest B's Active Directory database.

Cloning a forest

Question: We're going to be splitting our company into two completely separate companies, so we thought we'd simply split our Active Directory infrastructure by cloning it and then deleting the unnecessary portions of each company's directory. For example, say we currently have a forest root domain contoso.com with two child domains left.contoso.com and right.contoso.com. Our plan is to make an exact duplicate of this forest and then delete the unneeded domains. The result will be that Company A will have the forest root domain contoso.com and the child domain left.contoso.com while Company B will have the forest root domain contoso.com and the child domain right.contoso.com. Think it will work?

Answer: Don't do that! Splitting a forest by first cloning it is a very bad idea because there will still be sensitive information in both directories that could allow someone in Company A to hack into Company B and vice versa. Instead of following that approach, you should create a brand new forest for Company A and then migrate the necessary directory objects for Company A to this new forest. Then do the same for Company B by creating a brand new forest for that company and migrating the necessary directory objects for Company B to that forest. Now you have two new forests that don't overlap in any way, and you can decommission the original forest of your company.

And in any case, cloned or split forests are not supported by Microsoft so you're on your own if you decide to go that route...

Domain Admins SID migration

Question: We used ADMT to perform a migration. Afterwards we noticed that the SID of the Domain Admins group in the source domain wasn't added to the sidHistory of the Domain Admins group in the target domain. This caused some issues for admins trying to access resources that had permissions granted for the Domain Admins group in the source domain.

Answer: This is by design. For security reasons ADMT doesn't migrate the sidHistory for the following groups:

• Domain Admins
• Domain Users
• Domain Computers

What you need to do is modify the ACLs for the resources to grant access to them by the Domain Admins group in the source domain. Or better yet, create custom groups in the source domain for these purposes and migrate them to the new domain.

Here's some additional information that might help in this scenario.

Migrating a cluster

Question: We're migrating stuff from domain A to domain B. Domain A has a failover cluster in it. Can I use ADMT to migrate the cluster configuration to domain B?

Answer: Nope. Failover clustering is tightly integrated with Active Directory and if you need to move a cluster from domain A to domain B then you'll need to destroy the cluster in domain A and then re-create it in domain B.

Using migrated accounts

Question: I've migrated accounts from the source domain to the destination domain. Can I still use the accounts in the source domain after my migration?

Answer: Don't.

Merging accounts in a forest

Question: My current Active Directory setup has two domain accounts for each user. One is used for accessing stuff in the resource domain while the other account in a different domain is used for accessing their inbox on Microsoft Exchange. This happened for historical reasons, and now that we're migrating AD we want to change this. Can ADMT help?

Answer: Nope. You can't use ADMT to merge two accounts in the same forest. Try a third-party migration tool. On the other hand, you can use ADMT to merge two accounts if one of them is in another forest...

Migrating passwords for accounts

Question: We migrated user accounts successfully but the passwords for these accounts weren't migrated. What went wrong?

Answer: See "Enabling Migration of Passwords".

SIDs not migrated

Question: We have a very large Active Directory infrastructure and we were migrating a bunch of stuff between domains and some of the SIDs didn't get migrated. Any ideas why not?

Answer: See Knowledge Base article KB328889 "Users who are members of more than 1,015 groups may fail logon authentication",

Migrating OUs

Question: Can I use ADMT to migrate the organizational unit (OU) structure from my source domain to my destination domain?

Answer: Yes but you have to do it from the command-line, see this link.

Why can't...?

Question: Why can't ADMT do <this>?

Answer: It's a free tool so its functionality is limited. If you want something more powerful with built-in automation capabilities, reporting, etc etc then you'll need to shell out some bucks to either a vendor of AD migration tools or a consulting company that can do the migration for you. We'll look at some of these in the final article of this series.

If you would like to read the other parts in this article series please go to:

• Active Directory Migration Considerations (Part 1)
• Active Directory Migration Considerations (Part 2)
• Active Directory Migration Considerations (Part 3)
• Active Directory Migration Considerations (Part 4)
• Active Directory Migration Considerations (Part 5)
• Active Directory Migration Considerations (Part 6)
• Active Directory Migration Considerations (Part 8)