Migrate AAD Connect to new onsite AD domain with existing O365 tenancy

[psumner1992]

Wondered if I could get some advice/reassurances on this please?

 

We currently have an onsite AD domain syncing our users to Office365 with Azure AD Connect, but over the summer we are creating a brand new AD domain which we plan to sync to the existing Office365 tenancy, the o365 domain name is staying unchanged.

 

I am looking for a way to keep existing AD users passwords the same and to ensure their existing O365 accounts don’t get deleted but sync up with the new AD domain.

 

After a lot of research this is what I am planning to do:

 

1) Disable directory syncing in O365

2) Run the following PS script to clear ImmutableId for all users in office 365 to ensure soft matching takes place

 

Get-MsolUser -All | Set-MsolUser -ImmutableId $null

 

3) Decommission old AAD connect server

4) Use ADMT to migrate existing accounts from old domain to new domain, ensuring UPN and proxy addresses get migrated over

5) Install AAD Connect on server in new domain

6) Test with a small batch of users in the syncing OU’s

7) Re-enable directory syncing in O365

8) Check accounts change from in cloud to synced, then continue with other users

 

If any of you have completed this task before, have I missed any steps out or would you do anything differently?

 

I have a call raised with Microsoft just to confirm the correct procedure but thought someone on here may have already been through this process in the past.

 

Thank you in advance for any advice or support.

[chaplic]

Looks good, I've done similar things.

 

I would also be taking a dump of immtuableIDs before you clear them, and also extracting MsDSConsitencyGuid from AD and be aware of how to translate between the two.

 

Furthermore I'd repro the whole thing with two test tennants and a few VMs - this is a death-or-glory moment

 

The alternative would be not tear down sync, but also to sync the new domain via the same AzureADconnect server. As you migrate a user from source, move it to a OU not in sync and ensure whatever attribute you are using in destination is the same. Outcome is similar, but you can do it per user.

[psumner1992]

Looks good, I've done similar things.

 

I would also be taking a dump of immtuableIDs before you clear them, and also extracting MsDSConsitencyGuid from AD and be aware of how to translate between the two.

 

Furthermore I'd repro the whole thing with two test tennants and a few VMs - this is a death-or-glory moment

 

The alternative would be not tear down sync, but also to sync the new domain via the same AzureADconnect server. As you migrate a user from source, move it to a OU not in sync and ensure whatever attribute you are using in destination is the same. Outcome is similar, but you can do it per user.

 

Thank you, I’ve got a test tenancy to test with so I’ll try with that first, take a copy of the ID’s and then try again with another VM and match if necessary before going with live system, it definitely is a death or glory moment.

 

Can’t use the old sync server as this is currently on 2012 and we are upgrading everything to be 2019 on the new network.

[Roberto]

What’s your current source anchor? If it’s msds-consistencyguid*, you could probably (as in: I’m sure this would work but you need to test first) copy the current user values for that attribute to the new user and it will do a hard match just fine. Though soft match is fine too if you prefer.

 

If it’s objectGUID you can upgrade to msds-consistencyguid in the old domain first, then proceed.

Edited July 18, 2020 by Roberto

[psumner1992]

What’s your current source anchor? If it’s msds-consistencyguid*, you could probably (as in: I’m sure this would work but you need to test first) copy the current user values for that attribute to the new user and it will do a hard match just fine. Though soft match is fine too if you prefer.

 

If it’s objectGUID you can upgrade to msds-consistencyguid in the old domain first, then proceed.

 

I have a feeling it’s objectGUID as it was set up a few years ago before the move to msds-consistencyguid, but will check Monday to see, if it is that’ll make things easier.

[psumner1992]

Just to keep everyone informed I attempted this and due to the fact the old sync ID was based on ObjectGUID and not MSConsistency the ID’s didn’t migrate over with ADMT.

 

The ability to set immutable ID to null has now been removed by Microsoft so at the minute I am having to force each one to match by logging into AzureAD and confirming both accounts are the same.

 

Microsoft are looking at alternatives for me at the moment to see what they can do to rectify the fault.

 

Think it might be a case of converting the online MSConsistency values and setting them manually in AD rather than trying to set the ID in AzureAD.

 

Annoyingly it worked on my test tenancy.

 

If I had changed the source anchor to MSConsistencyID prior then I probably wouldn’t have had this issue as ADMT probably would have migrated the value.

Edited August 8, 2020 by psumner1992

[Roberto]

Just to keep everyone informed I attempted this and due to the fact the old sync ID was based on ObjectGUID and not MSConsistency the ID’s didn’t migrate over with ADMT.

 

The ability to set immutable ID to null has now been removed by Microsoft so at the minute I am having to force each one to match by logging into AzureAD and confirming both accounts are the same.

 

Microsoft are looking at alternatives for me at the moment to see what they can do to rectify the fault.

 

Think it might be a case of converting the online MSConsistency values and setting them manually in AD rather than trying to set the ID in AzureAD.

 

Annoyingly it worked on my test tenancy.

 

If I had changed the source anchor to MSConsistencyID prior then I probably wouldn’t have had this issue as ADMT probably would have migrated the value.

 

ADMT will migrate msds-consistencyGuid. I should have been more explicit in why I suggested it. Sorry. Obviously, objectGuid is uniquely generated each time an AD object is created so this value isn’t going to survive a migration.

 

Assuming you’re now using msds-consistencyguid on the new accounts/directory, you can export the O365 immutableID and UPN (something like get-msoluser | select userprincipalname, immutableID | export-csv o365users.csv should do it from an o365 powershell session) to a file then input the immutableID into msds-consistencyguid. You may need to experiment with converting it to base64, I can’t remember offhand if that’s necessary, but it should work (again with appropriate testing)

Edited August 9, 2020 by Roberto

[psumner1992]

ADMT will migrate msds-consistencyGuid. I should have been more explicit in why I suggested it. Sorry. Obviously, objectGuid is uniquely generated each time an AD object is created so this value isn’t going to survive a migration.

 

Assuming you’re now using msds-consistencyguid on the new accounts/directory, you can export the O365 immutableID and UPN (something like get-msoluser | select userprincipalname, immutableID | export-csv o365users.csv should do it from an o365 powershell session) to a file then input the immutableID into msds-consistencyguid. You may need to experiment with converting it to base64, I can’t remember offhand if that’s necessary, but it should work (again with appropriate testing)

 

No apologies needed at all, every bit of advice I am extremely grateful of, I didn’t want to make any changes to the old sync just so I had an option of rolling back, although in the future I definitely would change it now to avoid these problems.

 

We have made progress with Microsoft now, we’ve got it working by manually editing the MSConsistency ID in AD now and resyncing, we had an issue where we weren’t editing on the primary DC and the ID wasn’t replicating back quick enough so thought it wasn’t working.

 

They are hopefully coming back to me early next week to see why we can’t get soft match working as I suggested could we calculate and update the IDs on bulk for the other 900 users but they suggested against it as it could be prone to errors, plus we need the soft match for groups as immutable ID doesn’t work with groups their only suggestion for groups currently is to delete them and start again, little bit troublesome when these groups are being used for Sharepoint site permissions.

[Roberto]

plus we need the soft match for groups as immutable ID doesn’t work with groups their only suggestion for groups currently is to delete them and start again, little bit troublesome when these groups are being used for Sharepoint site permissions.

 

Did you look at https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-migrate-groups for groups? Have to watch o365 support: Sometimes I’ve opened a case and ended up peer-programming a workaround to a bug in a feature with one of its developers (seriously!j and sometimes I’ve ended up with someone who is quite clearly typing the call details into Google...