To those are newbie to GPO (Group Policy Objects) or Group policy management, your mentor sure told you to not configure default domain policy and instead they will tell you to create a new GPO.
Here is something you should know, “Not all policy settings are workable under newly create GPO”. This means that there are still dependencies with Default GPOs. Even you’ve try to enable “Enforce” or “Block Inheritance”, the Default GPO will always there running. Thus, always research and understand in-dept of GPO.
Below is the supporting article is the answer to you.
When do we need to do hard matching? During a migration of users (which already in Office 365) from old domain(AD) to a new domain(AD), and from old AADC to a new AADC.
Why do we need to configure the immutable ID? When a user object is replicated or migrated using ADMT from old domain to new domain, their objectGUID will change and the immutable ID in Office 365 is the old immutable ID from the old domain’s user’s objectGUID. The only impact if you don’t configure the immutable ID, is when you provision the new AADC it will give you an error: “AttributeMustBeUnique”, and will not allow you to sync up to Office 365, until the error has resolved (this part make sure your dirsync duplication feature is true).
What is Immutable ID? Immutable ID is a unique identity(primary key) attribute for Office 365. At the Active Directory, it is called objectGUID. Basically, immutable ID is retrieve from objectGUID. The difference between this ID is their value, objectGUID is converted to a Base64 value for immutable ID.
*To perform hard matching make sure you have Azure module Power Shell installed to your computer. The script given below can be modify if needed.
Here are the steps to successfully complete hard matching;
Disable the directory sync in Office 365
Open Azure Power Shell
Connect-MsolService
Set-MsolDirSyncEnabled -EnableDirsync $false
Wait for all users in Office 365 their status change to “in cloud”
This takes up 48 hours to 72 hours for the disable to complete
*Note: If the specific user’s status is already “in cloud”, don’t have to disable the dirsync.
While waiting for the dirsync to disable, do a ADMT to migrate the user from old domain to the new domain in a target OU.
Next, export csv file with list of users from Office 365 and new domain (user objects): Total csv file: 2
Included attributes to export are: User principal name and the object guid (on premise).
For O365, just export the user principal name.
#Run this script in the new domain (AD, Windows Power Shell)
#This script is to show user principal name and objectGUID of a user object based on a specific OU