In our previous post we explored the backend of Azure AD Connect and what happens in multi-forest scenarios. In this post we will be looking into the ADMT migration and the effects on the cloud accounts.
The FORESTROOT domain has a user (email@example.com) which has been assigned a full E5 license to Office 365. The user is able to login and has a mailbox as well as some other things configured.
We continue to build on our previous installation, but in order to support the migration, we will be switching the Azure AD Connect instance to the stand-by instance and disabling the Azure AD Connect on the FORESTROOT domain.
Ensuring all users are there
But prior to doing this, let’s make sure the details will be the same when switching over. On the FORESTROOT AADConnect server, open the MIISClient (“C:\Program Files\Microsoft Azure AD Sync\UIShell\miisclient.exe”) and select the metaverse tab and search for the user:
Now most-importantly is the sourceAnchor. As indicated, its f8ys/….
On the TARGET Azure AD Connect server, open the MIIS client, and if not already available in the MetaVerse, run an import and sync job.
If you notice that the user is not in the metaverse, then this is because you left the mail attribute field empty. As this is the unique identifier for the users in each forest in our scenario, you need to ensure all users have the “cross-forest anchor” attribute (mail) populated.
When opening the properties of the user, you should see the same sourceAnchor:
Prior to disabling the FORESTROOT or SOURCE AADConnect, make sure the TARGET AADConnect can see and read all existing objects.
Switching Azure AD Connect’s
Open Azure AD Connect on FORESTROOT, and click configure on the main page. Then select Configure staging modeOpen Azure AD Connect on FORESTROOT, and click configure on the main page. Then select Configure staging mode
Login to the tenant, and then select enable staging mode and de-select the start synchronization process when the configuration completes. This basically disables the AAD on the FORESTROOT.
Now we can do the same on the TARGET Azure AD Connect, but here we want to disable the staging mode and there remove the checkbox. On this system we can initiate the sync process.
ADMT – Migrating a user
Let’s suppose we perform a standard ADMT without setting any option for the migration. To ensure the Azure AD Connect does not run (as I want to have control over it), I open up Azure AD Connect (from the Desktop).
I start ADMT with my special ADMT user and perform the migration of firstname.lastname@example.org
Given I still want to use the source account, I leave it enabled, but will also migrate the user’s SID (for other purposes outside the scope of this post).
As you can see, I did not exclude any attribute from the migration.
After the migration we take a look at what would happen with the account in Azure AD, we do this by opening the MIIS Client and performing an import on TARGET and FORESTROOT followed by a synchronization on FORESTROOT and TARGET. You will notice nothing has changed. The object in Azure AD Connect is still the FORESTROOT object and the TARGET object is ignored. Why? Let’s checkout the migrated object in TARGET in the ADUC console:
As you can see, the default ADMT migration does not include the mail attribute. Which is strange, given we did not exclude any attribute by default.
By default, ADMT has a set of attributes it will migrate. This set does not include the “Exchange” attributes such as proxy-addresses and the mail field. (https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc974331(v=ws.10)) In order to enable the migration of these attributes we need to run a script:
Perform the following:
- Create a directory called C:\Scripts
- Open an Administrative DOS prompt
- Notepad c:\scripts\ADMT.vbs
- Create a new file and fill it with
Set o = CreateObject("ADMT.Migration")
- On the prompt, go to C:\Windows\SysWow64
- Execute cscript c:\scripts\admt.vbs
The output will show all the excluded properties of the system, and as you will see, it contains the mail, proxyaddresses, and a whole lot more. The output will show all the excluded properties of the system, and as you will see, it contains the mail, proxyaddresses, and a whole lot more.
Next what we need to do is ensure we include the properties that we want in our migrations. For this, execute the following on the same command prompt
- Copy the attribute list as shown above
- Notepad c:\scripts\newADMT.vbs
- Create a new file
- Paste the following information:
Set o = CreateObject("ADMT.Migration")
o.SystemPropertiesToExclude = "msDS-PSOApplied,msDS-HostS………"
- Where the SystemPropertiesToExclude is the list
you actually want to exclude
I removed, mail and proxyAddresses, DepartmentNumber, EmployeeNumber, employeeType, homePostalAddress and some other properties..
- Run c:\windows\syswow64\cscript.exe c:\scripts\newADMT.vbs
- Run the first script to validate the inclusion of the attributes
Now we can re-do the ADMT migration by deleting the object in TARGET, or update the ADMT migration by running it again and allowing conflicts.
I just deleted the object and re-did the entire ADMT. Now in ADUC we actually see that the mail attribute was copied too. What is the effect on our object in AAD Connect, now that the mail field was populated too?
You will notice that the Contributing MA has been switched to TARGET.local for our user. But as you can see the cloud anchor is still set to f8ys/…. Which means, this user’s mailbox, login and all is still safe.
Now we can close the still opened Azure AD Connect configuration page that was pausing our synchronization and execute a delta sync through powershell
Start-ADSyncCycle -PolicyType Delta
Changes in Azure AD
In later versions of Azure AD a new attribute is used to replicate an immutable attribute from the cloud back to AD itself (ImmutableID – mS-DS-ConsistencyGuid – ADConnect – final part (azureinfra.com)). In short, the by Azure created CloudAnchor attribute (not CloudSourceAnchor) is replicated to msDS-ExternalDirectoryObjectID in AD which can also be used to link objects in the AAD Connect Metaverse.
How come we don’t have a problem with this user compared to our previous post where a change in the sourceAnchor was detected?
When Azure AD Connect synchronizes users, it will take the ObjectGUID from a user and copy it into the ms-DS-ConsistencyGuid attribute field (or any other field you have specified as the immutableID field and that is capable of hosting the same data type). When performing an inter-forest migration using ADMT, the process actually copies the ms-DS-ConsistencyGuid attribute to the migrated object.
Given the uniqueness of ObjectGuid for every forest/domain, you cannot copy the ObjectGuid from source to target. That is why the migrated user will have a unique ObjectGuid. If ms-DS-ConsistencyGuid was not populated yet (because it was a brand new user), or another attribute that is excluded from ADMT is used as the ImmutableID, the new Azure AD Connect will create a new ImmutableID. In our example, the migrated user Smith, has an ObjectID of :
While his ms-DS-ConsistencyGuid (copied from FORESTROOT) looks like:
In the next blog-post we will see what happened to the authentication of the migrated user. Cause as some readers may have noticed, we still do not have implemented the azureinfra.com UPN on the TARGET domain…….