Hybrid Exchange Solution Deployment Using Okta Provisioning

hybrid exchange solution

Hybrid Exchange Solution

By Ron Erlandson
Senior Systems Engineer

Background: A migration to Office 365

I’ve been working on a project for a client that is migrating from on-premise Exchange to the Exchange Online in Office 365. To get from Point A to Point B they are implementing a Hybrid Exchange Solution and doing a staged migration.

This company already has an existing Office 365 tenant which they’ve only been using for SharePoint and to assign their Office licenses. They use Okta, an excellent cloud-based tool that lets you tie together a variety of different applications under a single user ID and single sign on, to synchronize their on-premise Active Directory users with Microsoft’s Azure.

Problem: Okta Provisioning doesn’t support a Hybrid Exchange Solution

In developing the migration plan we quickly ran into a problem. Because a Hybrid Exchange Solution requires the write-back of certain attributes, Okta Provisioning does not support it. While this is something that Okta is working on for future releases, it is not available now…and our client could not wait until some unspecified point in the future to move forward with their migration project.

Solution: Disable Okta Provisioning & implement Azure AD Connect

After much research, we determined that the solution is to disable Okta Provisioning for the Exchange application, and then implement Azure Active Directory Connect instead.

Naturally, our client was concerned that doing this might disrupt existing users from accessing Office 365 resources. After consulting with the nice folks at Okta, who were not initially certain how to resolve this issue, we determined that if you follow the proper steps in the proper order, there is no disruption for the existing Office 365 users.

  • How to implement this solution
    To disable Okta Provisioning and implement Azure Active Directory Connect instead, here’s what you need to do:
  1. Open the Okta console. Under “Office 365 Provisioning,” disable (i.e. uncheck) “Deactivate Users” and then save this configuration. If you do not uncheck this box then all of the current users will automatically be deactivated when you disable Okta. Unchecking the box prevents this from happening and keeps the existing users in Office 365.
  2. Next, while still in the Okta console, uncheck the “Enable Okta Provisioning” box under “Office 365 Provisioning” and then save this configuration. Note: Be sure that “Okta Provisioning” is the only thing you disable. Do not change the sign-on methods, change user accounts or un-assign any users from any applications.

At this point Okta Provisioning will be disabled, but users will still be able to access resources in Office 365 using Okta single sign on. With the above steps completed you can now install and configure Azure Active Directory Connect.

  • What happens once Azure Active Directory Connect is installed?
    When Azure Active Directory Connect performs the initial synchronization, it will use the ImmutableID (a value that exists in Office 365) to match the on-premise Active Directory accounts to the accounts that already exist in Azure. To create the ImmutableID, Microsoft uses your specified source anchor (an on-premise property) to generate a unique number based on that source anchor’s value.In our case, we used the Object GUID as the source anchor.

Result: The solution worked great for almost all users

Overall, this solution to the problem of doing a Hybrid Exchange implementation when you’re using Okta for single sign on worked extremely well. However, we did run into a problem with three users that were configured differently than all of the other users.

As I said above, in setting up Azure Active Directory Connect we used the Object GUID as the source anchor. We did this because Okta was using the Object GUID as the source anchor.

However, in monitoring the Azure Active Directory Connect console I saw that when we did the initial synchronization, three users did not synch properly. Why not? As it turns out, the accounts for these three users were configured to use the application ID generated by Okta as the source anchor. When we ran the synch the ImmutableID didn’t match up, so Azure thought that these were duplicate users.

If you use this Hybrid Exchange solution using Okta Provisioning and happen to run into the same problem, you have two options for fixing it:

  • If you have a large number of users with this problem you would need to disable directory synchronization in Office 365, run a script to set the ImmutableID value to “null,” and then re-enable directory synchronization. At this point when you run the synch again the system will see that the ImmutableID value is blank and will regenerate it using the correct source anchor.
  • If you have a small number of users with this problem you can back up any existing data that the affected users have in Office 365, and then from the Azure PowerShell console do a hard delete of these users from Office 365. Since the users will no longer exist in Office 365, when you run the synch again the system will not think that these are duplicates, so it will recreate the user with the correct ImmutableID value. After that happens you must go back in to Office 365, reassign any services they had and restore their data.


Whether you’re migrating from on-prem solutions to Office 365 or doing any other sort of migration, quite often problems crop up that aren’t in the application’s instruction manual. This is one of the many reasons why it pays to work with migration experts such as Coyote Creek. With decades of experience under our belts, we are problem-solving ninjas! Give us a call today to discuss your next project or current challenges.