Off Boarding and Linking User Identities From Office 365

During a recent Microsoft Office 365 migration, Now Micro’s Cloud Sherpa, Micah Linehan, encountered a tenancy migration where he had to work through reinstalling Exchange on premise. In this particular case, a vase majority of users had previously been created without Exchange. As Micah moved forward and installed Exchanges, the users were directory synchronized; however, a remote user in Exchange was not. He put together the following recommendations and best practices for working through these issues, as he found there were few technical resources (articles, blogs, etc.) out there. Hopefully this post will alleviate some of the confusion and ease any off boarding or tenancy conversion issues within Office 365.

Baseline and Information Needed

A typical path for proceeding is to work with the user objects in Office 365 as a source list and compare it against the on premise Active Directory. Most organizations are leveraging Directory Sync and should therefore export a full user list with all attributes. A common practice is to run through and clean up the empty entries; however, a selective export of the basic attributes can be done. This is really the baseline for all future steps and will probably require several more repetitions.

Enabling Remote Mailboxes

In this use case, an exchange environment was decommissioned as the users were migrated into Office 365. At this point, it’s important to migrate the mailboxes back on premise or create a hybrid environment due to tenancy merger requirements.

Once an exported CSV file of users has been created from Office 365, enable the users as a remote mailbox. Since they are not currently displaying in Exchange on premise in any fashion (either mail contact of remote mailbox), there are two components to enable this in a hybrid state. If not in a hybrid state, enable it before running this operation, as it creates more verification work on the backend rather than just running the enable and being done with it. The first component is very simple: enable the remote mailbox. If simply running the enable remote mailbox command on an identity, it will fail. This is why being in a hybrid state is recommended due to the requirement of setting the remote routing address. This is fairly simple in Office 365, because it follows a common naming convention, domain.mail.onmicrosoft.com. For all common purposes, an individual creation would look like the following:

One possibility is to use the Active Directory username as the remote routing address, but anything could be used, such as SAMaccountname. After this is enabled, the user will activate as a remote mailbox in Exchange. The Active Directory objects do need to be synchronized with Office 365 in order for this to be successful for mail routing and migrations. To prevent sync error or identity mismatches after the remote mailboxes have been enabled, set the Exchange GUID based on the GUID exported from Office 365. If referencing the user at this point, the Exchange GUID in the on premise identity is null. Even after running a Dirsync operation, this attribute will not be populated with the Office 365 Exchange GUID, because it’s not written back. The on premise objects need to be set with the Office 365 Exchange GUID.

Pairing Identities Exchange GUID

The remote mailboxes on premise have been enabled, but they have no Exchange GUID. They need to be exported from Office 365. If an exported list of Office 365 users is still needed, use the following script:

After the export, simply run the script below to compare the on premise Exchange GUID with the Exchange GUID in Office 365. The script compares the two and will overwrite the on premise when it differs and the remote mailbox is enabled. In the previous step, remote mailboxes were enabled, and in that step, they have a null value for the Exchange GUID. This will be overwritten by the proper value. This script works well as it will compare what already exists in between values and will not overwrite a matching GUID. The key is to export from Office 365, as that is here the correct attributes exist.

Users That are Directory-Synchronized But No Active Directory User Object Exists

This is typically a result of the de-provision setting in the MIIS client not being configured to remove the mailboxes. Some organizations tend to leave it this way as a method of archival and retention or have simply never configured it. In any case, the objects are in a hard pair mode and cannot be modified; they can be force deleted if the data is no longer needed. In most cases, it is ideal to retain that information. When looking to off board these or repair them with a user identity, an immutable ID reset will need to be performed.

Immutable ID Reset for Office 365

The need to reset the immutable ID is base don hard pairing versus soft pairing. The soft pair is the initial linking of an Active Directory user account to the cloud identity. After the initial pair of the object GUID for the user from the Active Directory object, it converts the base64hex into the immutable ID in Office 365. In the most recent release of Azure AD Sync, the pairing object can be converted into the immutable ID, but by default, it’s the object GUID.

Once that conversion occurs, they are hard paired or linked to each other. Depending on how the users are de-provisioned, objects may still exist in Office 365 where their Active Directory account does not. This will create a hard paired object which cannot be modified until it’s set back to a soft pair mode. The steps are very straight forward:

Disable Directory Synchronization
This is a requirement as the immutable ID is hard paired with the object GUID; while the directory synchronization is enabled, this attribute cannot be written or modified via PowerShell. The amount of time it takes to disable and re-enable is based on the amount of users in the tenancy. Many organizations are weary of this step as the Active Directory is now out of sync, and passwords cannot be reset or synchronized when leveraging password sync instead of Active Directory Federation Services (ADFS). But depending on the organization’s size, this is a minimal impact to end users; just make sure the IT staff and team are aware of the change. The only real issue is if someone moves a mailbox to the cloud or back on premise while this is either de-provisioning or disabled.

Overwrite the Immutable ID AttributeSeveral articles outlining the best way to accomplish this task exist, including how to perform the base64hex conversion internally on the immutable ID. When reviewing the immutable ID, and to ensure a proper pairing, simply clear the entry. Completing this can be done on an individual level or in bulk. Setting it with a double quotation “” clears the entry. The script looks something like the following:

Set-MsolUser –UserPrincipalName <UPN> -Immutableid “”

Enable Directory Synchronization
Re-enabling directory synchronization is the fastest and easiest part of this step. Activate it in the Office 365 portal, and wait for activation. After activating Dirsync, perform a new Full Import/Full Sync in the MIIS client for the Active Directory Connection to rebase the sync objects of Active Directory (recommended). After the sync, confirm that the users are paired. The easiest way to verify is to check that they’re synced with Active Directory. If they’re not displaying, verify that the upn and windowsemailaddress match the cloud identity.

Overall, this may seem like a very confusing process, and it can be. From experience, this process is not a once-over and all is fixed—more like a cycle of steps (in varying order) until the ultimate goal is achieved. Hopefully these steps will alleviate future confusion around off boarding or reconnecting Office 365 to an on premise environment.