Consideration for multi-forest synchronisation with a resource Exchange forest

Azure AD Connect has come a long way from the early days of DirSync, and multi-forest directory synchronisation is a great step forward, with the ability to synchronise an account forest and Exchange resource forest to Office 365 meeting the needs of many organisations.

Joining linked mailboxes

To provide synchronisation of an account forest and an Exchange resource forest AAD Connect matches accounts across forests using the same attribute used by Exchange, matching the linked mailbox account’s msExchMasterAccount attribute value with the objectSID value of the account in the other forest to join them. I’ve represented this flow here:

This joining process is great for ensuring a single identity is synchronised to Azure AD where you have linked mailboxes going on and this works for most organisations out there.

Houston, we have a problem.

I’m going to draw out a scenario:

AAD Connect is installed and configured to synchronise two AD domains as shown above, and Exchange hybrid is configured with the on-premises Exchange Organisation in the resource forest. All the on-premises mailboxes have been moved to Exchange Online, and an Exchange 2013 server remains on-premises to provide administrative capability(when an account in Azure AD is synchronised from on-premises, the on-premises user object is the source of authority and so it is not possible to update values such proxy addresses in Azure AD).

Now. A new starry-eyed employee joins the organisation, at which point an account is created in the account forest, let’s call it newEmployee@account.local. As part of the on-boarding process, a linked mailbox would have been traditionally created in the resource domain as newEmployee@resource.local.

However, with Exchange Online in place, it doesn’t make sense to create a linked mailbox on-premises, only to move it to the cloud once it’s created. So the account in the resource domain is created as a remote mailbox, either through the Exchange 2013 control panel, or using the Exchange PowerShell cmdlet New-RemoteMailbox.

Then we wait for AAD Connect to work its magic…

…and two accounts appear in Office 365. One with a mailbox, and the other without. The new employee is also unable to connect to their new Exchange Online mailbox as access is denied. This obviously is not a good place to have arrived at!

Looking at the linked mailbox joining process in AAD Connect I discussed earlier, you may be able to see why this is occurring. A remote mailbox is not the same as a linked mailbox. As a result,  Azure AD Connect does not join the accounts newEmployee@account.local and newEmployee@resource.local with the result that two accounts are created in Azure AD.

What are the options?

There are two ways forward for you from here:

1. Continue to create a linked mailbox on-premises and then move the on-premises linked mailbox to Exchange Online as a second step
2. Modify the newEmployee@resource.local account through some ADSIEdit jiggery-pokery.

Now I’m going to stop here and recommend you stick with the first approach here. It requires an extra step, but so does the second option. Option 1 is also a solution which allows for account and mailbox creation using your existing administrative tools. Getting at AD object attributes, which used to be hidden in your management tools, is a lot easier these days. That doesn’t make it any safer to do without a good understanding of what it is you’re planning to do.

I was presented with an additional complication recently, where a customer had an incumbent vendor providing a managed service for email and charged extra for every mailbox created in the on-premises Exchange environment. Not wanting to give away more money than they needed to, the customer did not want to create a linked mailbox first when on-boarding new users.

Luckily the customer I was working with has FIM in place allowing them to populate AD user object attributes consistently and correctly (this ain’t something I’d be wanting to do manually).

Given AAD Connect matches accounts with the msExchMasterAccountSID and objectSID values, you can manually update newEmployee@resource.local so that it’s msExchMasterAccountSID equals the objectSID for newEmployee@account.local and all will be good right?

Well, the answer is no…

It turns out that AAD Connect checks that the AD object is a linked mailbox before it attempts to match its msExchMasterAccountSID value. This is done using the recipientTypeDetails attribute (a value of 2 designates a linked mailbox).

So, there are two attributes which need to be updated on the resource forest account, they are:

1. msExchangeMasterAccountSID with the objectSID of the authentication account
2. recipientTypeDetails with a value of 2

Once you’ve got these being updated you should be set.

Jason.