Active Directory User Migration in Hybrid Exchange Environment Using ADMT – Part1

An Introduction and high-level migration approach

Over the past few months I have been working on developing a strategy for migrating users from one domain in a forest to another domain in a separate forest. Sounds quite simple at the first read of it, right? Just use ADMT and migrate the groups, user accounts and profiles, job done? Well that’s what I had thought when I started working on it.

As I started digging more and more into the details, the complexities involved started unfolding. The first one of many of those challenges was the fact that this is a hybrid exchange environment, and this posed the concerns around maintaining mailbox data for the user. Which exchange attribute to migrate and which one to drop during user migration? Also, because ADMT doesn’t migrate any of the exchange attribute, this had to be scripted.

Another big challenge that we encountered was that a single AADConnect server instance was being used to sync up the 2 domains into a single O365 tenant. Also, there were many distribution groups and mail enabled security groups being managed via on-prem exchange server. And this presented another challenge in terms of maintaining group membership for the users during migration until all the users are migrated over to target domain.

There are a lot of articles that can be found on internet discussing how to migrate users using ADMT but very few that discuss about user migration in a hybrid exchange environment and that too when both domains are syncing up to a single tenant.

After having successfully tested and migrated users from source domain to target domain, I thought of writing this down explaining the actual migration steps that I followed. I’ll be covering below items in this series:

Part 1. Introduction and high-level migration approach

Part 2. Configuring source and target domains for SID history and accepted-domains

Part 3. Installation and configuration of ADMT tool and Password Export Server

Part 4. Groups Migration

Part 5. Users Migration

Part 6. Security Translation Wizard – Local Profiles and things to consider for end user experience

In this case I was migrating users from source domain to a target domain with active users. Also, the 2 domains have a very different active directory structure, so merging the users into one structure was not possible unless we did an AD restructuring. So, the users were migrated to a new OU under the target AD structure.

On a high level below are the steps that needed to be performed for migrating users from source domain to target domain in a hybrid environment:

• Identify/create a root level OU in target domain to migrate the users to. Migration to proceed in “like for like” fashion from source domain to identified OU in target domain.
• Create admin level ADMT accounts in both source and target domains
• Install Active Directory Migration Tool (ADMT) on a machine in target domain from which source domain controllers and user machines can be reached.
• Install Password Export Service (PES) on a writable DC in source domain.
• Assign ADMT Migration Account used to migrate local profiles local administrator rights in the source domain. This is required for user profile translation.
• Add sub-domains (if any) from source domain as internal relay accepted domains in target domain so that all the alias addresses that user might have in source domain continue working when they are migrated to target domain
• Migration of existing security groups (Global and Universal) within source domain into target domain
• In my scenario, there were quite a few built-in groups that were used to assign membership to users for fileshares. So, I had to create corresponding universal groups in target domain for built-in groups and assign the permissions of file shares that source built-in groups have access to the corresponding universal groups created in target domain
•  OU folders added to AAD Connect Sync configuration in target domain.
• Migrate users in a disabled state to target
• Disable mail capability of mail-enabled security and distribution groups in source domain
• Modify attributes for Distribution Groups and mail-enabled Security Groups to sync them to O365
• Enable mail capability of mail-enabled security and distribution groups in target domain with appropriate attributes (will provide more details later around which attribute needs to be configured to sync up to the cloud.)
• Disable the user accounts in source domain and move them to an OU that’s not syncing up to O365.
• Migrated users in target domain given new UPN. Custom Attribute 3 remains as it is the key for Azure AD.
• Change below exchange related attributes using powershell script
  • Mailnickname
  • Proxy addresses
  • legacyDN as X500 under proxy addresses
• Enable-remote mailbox for migrated users, otherwise they will not show up in on-prem exchange admin portal
• Add the users to previously created universal groups in target domain corresponding to built-in groups in source domain
• Modify file share permissions for user share on fileserver in source domain to include the Universal groups in step above
• Manual sync to Azure AD using AADConnect
• Test and verification of migrated users, groups in target domain

I’ll be explaining the detailed implementation steps for the approach above in my following blogs of the series.