Default checks when implementing Hybrid Identity, Part 3: Linked Mailboxes

Microsoft has introduced an impressive array of technologies and an awesome vision on Hybrid Identity:

Hybrid Identity

One of the parts of your organization’s journey in implementing Hybrid Identity, might be to migrate from DirSync to Azure AD Connect with Azure AD Sync.

After you export and import the configuration,  you might expect to see the same amount of person objects in Azure AD Sync’s metaverse, but it might not match. This feels utterly strange, because this process is the supported way for Microsoft in environment with over fifty thousand objects. (unless you have custom extension DLLs or other unsupported settings)

Furthermore, IdFix does not report any issues with objects. Azure AD Connect’s Sync Services won’t report on issues either, because this situation simply falls out of scope of the default sync rules in Azure AD Connect’s Sync Services.

The difference is caused by the multi-domain and multi-forest support in Azure AD Sync. In DirSync, user objects with linked mailboxes. would synchronize into Azure Active Directory. In Azure AD Sync these objects don’t sync up.

From a project management point of view, you’ll want to check for user objects with linked mailboxes, report on them and remediate the situation before you (attempt to) go live with Azure AD Connect as part of your Hybrid Identity solution.

 

About linked mailboxes

A linked mailbox is a mailbox that’s associated with an external account.

 

Causes for linked mailboxes

The resource forest scenario is the prime example of a situation in which you would want to associate a mailbox with an external account. In a resource forest scenario, user objects in the Exchange forest have mailboxes, but the user objects are disabled for logon. You must associate these mailbox objects in the Exchange forest with enabled user objects in the external accounts forest(s).

While the resource forest scenario is one of the most obvious reasons for linked mailboxes, linked mailboxes can also be remnants of botched and/or incomplete Active Directory migrations using the Active Directory Migration Tool (ADMT) or any 3rd party migration solution(s).

A linked mailbox can also come to life when you orphan and then reattach an Exchange mailbox to another user, for instance a recreated user in case of an accidental deletion.

 

Checking for linked mailboxes

Since linked mailboxes are an Exchange affair, you would get the list (and count if you want) of user objects with linked mailboxes via the Exchange PowerShell Module:

Get-Mailbox -RecipientTypeDetails LinkedMailbox

This will produce a list of all the user objects.

To simply get the number of user objects use:

(Get-Mailbox -RecipientTypeDetails LinkedMailbox).Count

 

Getting user objects synchronized

There are two ways to fix the situation:

 

Azure AD Sync’s Builtin Multi-Forest synchronization

The first and most straightforward method is to changing the scope of Azure AD Sync. Include the disabled accounts that reside in the Exchange resource forest.

You won’t necessarily need to exclude the accounts with linked mailboxes that won’t synchronize, because Azure AD Sync considers these out of scope and therefor won’t cause duplicates in the Connector Space towards Azure Active Directory.

This method is best to tackle the resource forest scenario, as long as the admins of the resource forest are OK with the security, load and connectivity implications that Azure AD Connect imposes on their environment.

 

Fixing linked mailboxes

Linked mailboxes that are incorrectly handled as such, can be fixed through the Exchange PowerShell Module, fairly easy. The below PowerShell one-liner is an example of fixing up the situation for a user named Jos Haarbos with the DOMAIN\JosH logon credentials:

Set-User -Identity DOMAIN\JosH -LinkedMasterAccount $null

Afterwards, the user object will no longer be out of scope for Azure AD Sync and it will synchronize up to Azure Active Directory.

A solution is also available using AdsiEdit.msc:

  1. Run ADSIEdit.msc.
  2. Find the user account to be modified.
  3. Clear the msExchMasterAccountSID attribute.
  4. Change the msExchRecipientTypeDetails from 2 to 1.
  5. Close AdsiEdit.msc.

This method is best to tackle botched user-mailbox relationships and/or previously reattached mailboxes.

 

Concluding

Linked mailboxes may ruin your organization’s Hybrid Identity dreams in the Azure AD Connect era. You’ll want to check for them, report on them and remediate the situation before you (attempt to) go live with Azure AD Connect as part of your Hybrid Identity solution.

Further reading

Create a Linked Mailbox in Exchange 2010
Manage linked mailboxes in Exchange 2013
Linked mailbox vs. user mailbox
Converting a Linked Mailbox to a User Mailbox
Linked Mailbox in Exchange Server 2013 – Part 1
Linked Mailbox in Exchange Server 2013 – Part 2
The “Link” Used by a Linked Mailbox
Convert Linked Mailboxes to User Mailboxes in Bulk

Series Navigation

<< Default checks when implementing Hybrid Identity, Part 2: Orphaned UPN SuffixesDefault checks to perform when implementing Hybrid Identity, Part 4: Groups with large memberships >>

leave your comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.