Carve-out migration guide part 4: Pre-migration account staging

Here, I'll cover the first stage of migration, which I refer to as "pre-migration account staging."

Rather than waiting for phased migrations to migrate all Active Directory (AD) groups and users, these objects should be migrated (copied, not moved) to the target domain before the first site migration. There are several reasons to take this approach:

• In general, you should try and minimize the number of steps required for each site migration.

• Mail-Enabled Users (MEUs) for each user must be created in the Target domain in order to facilitate mailflow coexistence.

• Assuming that Domain Admin access to the Source Domain is not granted, migrating Security Identifier (SID) history will require scheduling a screen sharing session with a Source Domain Admin, so it's much more efficient to migrate it all at once.

• Migrating Users and Groups has no effect on the AD objects in the Source environment, so the operation is entirely non-impactful.

However, this approach also has some special considerations:

1. When having AD accounts in both the Source and Target domains and having a trust in place, users could potentially log on to their machine with their Target account before their migration date, causing a new local profile to be created and major confusion to occur ("all the files that were on my desktop are gone!!"). This is prevented by not migrating user passwords and not telling the users what their new password is until they've been migrated. This is also a good approach from a user experience standpoint, helping to drive the point that this is a new company with a new network and a new password.

2. Once all users are migrated with SID History, any new hires created on the Source side will need to be migrated to the Target side before their migration date. This is a hassle because it requires a screen sharing session with a Source Domain Admin. Alternatively, you could also shift the onboarding process over to the Target domain directly after the pre-staging migration and ensure that new users are instructed to log on to the Target domain. Keep in mind that in addition to creating an AD object and Mailbox, a MEU will also need to be created for each new user on the Source domain.

3. Once Groups have all been migrated, any changes to Group memberships (including Distribution Groups) on the Source domain will not be reflected in the Target domain. This can be resolved easily by re-migrating all of the groups with the Active Directory Migration Tool (ADMT) with the merge option. This does not re-migrate SID history and therefore does not require a Source Domain Admin to be involved.

With these considerations taken into account, the pre-migration account staging is executed as follows:

STEP 1: Migrate Groups and Users with DirSync Although Groups and Users will also be migrated with ADMT, it's important to use DirSync in order to bring over Exchange Attributes for Users and Mail-Enabled Universal Groups. DirSync will automatically create an MEU for each migrated user. Migrate the users and groups to a temporary staging Organizational Unit (OU), I called mine "Group Staging." This will help you find any groups whose SID history was not migrated successfully.

Special Notes on Using DirSync

Although the tool is relatively straightforward to configure and use, there are some special considerations to keep in mind. Once the settings are saved and the migration is ready to begin, you can start the tool with the "CMT Coexistence for Exchange" Service. However, this will cause the migration to occur over and over again on a set time frame. This is a feature to supposedly allow for constant syncing between domains, but there are a couple of bugs which make this feature impossible to use. The first is that any SMTP addresses added to MEUs in the Target domain will be erased every time that DirSync runs. This is a major issue because you want to add Target.net to all users in order to enable mailflow coexistence. The second issue is that any Users with a "Manager" attribute will fail to migrate due to a big in the software. The workaround is to do the following:

On the BinaryTree Server, open a command prompt and navigate to the CMT Coexistence folder.

Run Binarytree.coexistance.dirsync.exchange.exe /repush

This will pull all of the Users from the Source domain and place them in the DirSync SQL Database

On the SQL Database, open the DirSync database and run the following command update BT_Person set Manager = null

This will clear all manager attributes for all users.

Then, back on the BinaryTree server, run Binarytree.coexistance.dirsync.exchange.exe /repull This will push all of the Users from SQL to the Target domain

STEP 2: Migrate Groups and Users with ADMT

ADMT is used with the merge option to migrate SID History. Please see the following guide for step-by-step instructions: http://portal.sivarajan.com/2011/05/user-account-migration-and-merging-part.html

If you'd like to keep the same password for every user as set by DirSync, make sure that "Do not update passwords for existing users" is checked. The option to move merged groups to the target OU should also be selected, with the final OU for groups and users targeted. This will allow you to check the staging OU for any Groups or Users whose SID history was not successfully migrated.

Special Notes on Using ADMT When SID history is selected for migrating, ADMT performs two pre-checks on the Source domain to ensure that the SID history can be migrated. It checks for and (if necessary) creates a group called SOURCE$$$ (where SOURCE is the name of the Source domain) and checks for the two auditing settings. In order to perform these checks, the account running ADMT must be a user of the Builtin/Administrators group in the Source domain. Source domain admins will likely be unwilling to provide you with this level of access. Therefore, ADMT must be run with the account of a Source Domain admin. In my case, this was achieved by scheduling a screen-sharing session with an admin in order for him to input his password when prompted and supervise the use of his credentials. In order for that to work, the Source admin also had to be added to the local administrators group on the ADMT server, the Builtin/Administrators group in the Target domain (only temporarily, for migrations) and also a member of the dbowner group on the ADMT SQL Database. With all of those permissions in place, the Source domain admin should be able to successfully Migrate SID history for all Users and Groups. The last issue to watch out for is that having the Source Admin input his password via screenshare caused some issues for me. The shift key did not work properly, so the Admin had to temporarily change his password to something all lowercase.

STEP 3: Sync Public Folders and Free/Busy information Using InterOrg Replication (IORepl) At the time of this project, the public folder syncing feature of BinaryTree E2E required Source Domain Admin credentials in order to function properly. This was not allowed by the Source Domain admins, so IORepl had to be used as a substitute. This was not ideal, as it required significant efforts on the part of the Source Domain Admins and the process of troubleshooting the system was left almost entirely to them. It did eventually work, however. IORepl was configured according to this guide: http://www.msexchange.org/articles-tutorials/exchange-server-2010/migration-deployment/deep-dive-into-rich-coexistence-between-exchange-forests-part12.html

STEP 4: Prepare Mail Enabled Users (MEUs) for Migration All MEUs must have a @Target.net SMTP address in order for the email migration to work successfully. This can be added pretty easily with Powershell:

Get-MailUser -Resultsize Unlimited| foreach { $NewSMTP = $_.PrimarySMTPAddress.Local + "@target.net" Set-MailUser -EmailAddresses @{add=$NewSMTP} }

With those four steps successfully completed, phased site migrations can begin which will be covered in part 5 of this series.