The Cloud Legacy Issue Simplified
When Azure AD Connect merges objects between forests such as a mail contact or a mailbox, only one value is sent to Azure AD. For example, the legacyExchangeDN attribute will only be sourced from one forest. The impact? For users who have been utilizing the object in the other forest, they will encounter issues when their mailbox is migrated to Office 365.
The Hijacking of Cloud Legacy
Exchange Online does a great job at making sure that it’s Cloud legacyExchangeDN value is populated as an x500 address on all matched objects in all forests. This article explains how we can leverage these features to resolve issues typically found in multi-forest topology.
The Multi-Forest Sync to a Single Tenant Topology
We all strive for simple and elegant solutions with minimal user input. The same is true for Microsoft products like Office 365. Seemingly straightforward choices can have a profound impact on your workflow so understanding how these choices affect your environment is key to mitigate any unexpected problems.
Enter the multi-forest sync to a single tenant topology. Conceptually easy to understand yet difficult to implement well. Simple choices about source anchor, username, password sync, group & device write back, password write back and public folders quickly become complicated.
Here’s a common issue and clean solution for those considering migrating from multiple hybrid forests. It’s good to note, if you have objects that overlap from one forest to another, additional steps to prevent bounce back messages for your users are needed.
It’s important to first understand what and how the legacyExchangeDN attribute operates. So, let’s address that briefly. Yes, it is ‘legacy’ and yes, the paradox is that it plays an important role in everyday email communication. Each recipient in an Exchange organization is assigned a unique value as it’s legacyExchangeDN when the object is created. At times IT administrators needed to transfer association between objects which were possible by utilizing an x500 address. Should you require further information please have a look at this blog post.
The Scenario
In the Luxembourg forest an On-Premise mailbox user, called Jane, regularly emails David in Australia which utilizes the contact object in her forest. On the other side of the world in the forest in Australia, David also has Jane as a mail-enabled contact. Both contacts are members of several local forest distribution lists.
What happens when the synchronization for the second forest completes? The good news is that the contact object and the mailbox user is automatically matched and joins the member of information from both forests. The mailbox user is added to the distribution lists that the contact was in. Awesome! Totally stoked about that. But… here comes the catch.
The proxyaddresses and legacyExchangeDN attributes are sourced from the enabled mailbox user and contact object from the source forest has a lower precedence and is overlooked. So, what is the problem with that?
Well nothing, until you migrate them to Exchange Online. Afterward, you will find that these mailboxes will start receiving NDR’s when sending emails to any of these matched contact objects. When David or Jane attempts to send or reply to an email, Outlook will still reference the contact object in the local forest.
So, what needs to be done?
It is true that when Jane calls IT support they could add David’s contact legacyExchangeDN as an x500 to the proxyaddresses in the first forest. But this is a one-time change and consider the snowball effect of adding 5, 6, 7 or 8 forests and the inevitable support chaos.
Let’s consider a cleaner solution:
First, create a new multi-value indexable attribute named onPremiseCustomAddresses in the metaverse. Second, populate this new attribute with x500 addresses from each of the forests by transforming the LegacyExchangeDN and striping the ProxyAddresses. Finally, we push these values back to all forests replicating the cloudLegacyDN writeback feature we all know and love.
And so, all synchronized objects in each forest, regardless of the source of the proxy addresses will automatically have the required x500 address by default. All issues are resolved in one workflow, without resorting to compromising the Default Rules and complicating the next AD connect upgrade. Clean and simple. Happy users. Happy IT Engineers.
In the second part of this series, we’ll explain how to take this idea from concept to implementation.
