• Active Directory Migration Considerations (Part 7)

    Mitch Tulloch Posted On January 14, 2015
    2
    1 Views
    0


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

    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:

    Post Views: 1,409

    Read Next



    Home » Articles » Active Directory Migration Considerations (Part 7)

    Author

    Mitch Tulloch

    Mitch Tulloch is a widely recognized expert on Windows Server and cloud technologies who has written more than a thousand articles and has authored or been series editor for over 50 books for Microsoft Press. He is a twelve-time recipient of the Microsoft Most Valuable Professional (MVP) award in the technical category of Cloud and Datacenter Management.




    2 Comments

    Ioannis
    March 28, 2018 at 1:19 pm
    Reply

    The scenario we are interested in is a migration of ~1000 VMs (an MS Active Directory/Domain Controller and hundreds of Windows & Linux VMs with Java applications and their databases, with strong dependencies between several of the applications, i.e. an application may consume a number of REST API services offered by other applications and/or connect directly to some of the databases of these applications; all applications use the MS Active Directory for authentication) from Data Center A to Data Center B. The distance between the 2 Data Centers is ~3000 kilometers. Migration has to be performed in an active-active manner, meaning that both Data Centers will be offering services during the migration which is anticipated to last 6-9 months. Another requirement is that the IP addresses of the VMs remain the same. In order to cope with these requirements we plan to have some gateway at each site that will do NAT. We also plan to migrate the VMs in waves, trying to group as much as possible in each wave VMs that depend strongly between each other. Special handling will be needed for the MS Active Directory server which will have to be “duplicated” (multi-master replication) to Data Center B (say AD2) and remain in sync with that in Data Center A (say AD1), so that throughout the migration process, applications/services already migrated to Data Center B use AD2, while applications/services still in Data Center A continue using AD1. Keeping in mind that both AD1 and AD2 will have the same IP address, we are not sure how to handle routing in this case, as MS Active Directory is reported to have problems with NAT. Any ideas are welcome.


    Leave a Reply

    Your email address will not be published. Required fields are marked *

    • Featured Product

    • Join Our Newsletter

      Learn about the latest security threats, system optimization tricks, and the hottest new technologies in the industry.

      Over 1,000,000 fellow IT Pros are already on-board, don't be left out!

    • Latest Podcast

    • Featured Freeware

    • Recommended

    • Follow Us


    You are reading
    Active Directory Migration Considerations (Part 7)
    Share 2 Comments