Office 365 – Exchange Hybrid Issues With “Out of Sync Attributes”

For the most part, Directory Synchronization with Exchange Hybrid is fairly straight-forward. Your Active Directory is authoritative for nearly every attribute in Exchange Online with only a handful of attributes being written-back to the on-premises directory.
If you want to change an attribute such as an email address, you make the change in Active Directory and at the next sync cycle, that change is written to the directory in the cloud.
Try to modify an attribute directly in the cloud and you will be greeted with a soon to be familiar error.
Well… Usually you’ll receive an error…
Below are a few attributes that can be written in either the on-premises or cloud directory and how they can cause you some headaches.

Changing Attributes In The Cloud

If you’ve tried to change an attribute in the cloud that should be modified on-premises, you’re familiar with the error below.

This error was previously a bit more cryptic but the description has since been improved. Basically it’s telling you that you need to make the changes in your Active Directory and sync the change up to the cloud. This is one reason why keeping an Exchange server on-premises after your migration is helpful, changing some of these attributes can be a little painful without the Exchange tools.

The Exceptions

The above error is the expected behavior for all attributes in the cloud with only a few exceptions. Litigation Hold and Exchange UM, for example, are features that are enabled directly in the cloud. This works as the attributes used are in the list of “write-back” attributes.

Attributes That Can Become “Out Of Sync”

Unfortunately, there are a few other situations where you are allowed to change an attribute in the cloud when you probably shouldn’t. As a result, you’ll end up in a scenario where the on-premises directory is using a different set of values than the cloud directory and user experience will vary depending on the platform where their mailbox resides. Additionally, there’s the risk that the on-premises attribute overwrites the value in the cloud as part of the sync process.
Below are a few of these scenarios that I’ve recently observed:

Converting To Shared Mailboxes

Unleash the Potential of Power Platform With a Center of Excellence

Business innovation often comes from within. Discover how to empower innovation from non-traditional developers with the Microsoft Power Platform.

Learn More

This one left me a bit shocked when I was browsing recent KB articles related to Exchange Online. I ran across KB2710029 which basically tells you that you shouldn’t use the “Convert to Shared” button in the portal despite it being conveniently presented to the admin. While I have tested this process and have yet to see a mailbox disappear, the result is that using this button leaves the “msExchRecipientTypeDetails” and “msExchRemoteRecipientType” attributes out of sync. Jetze Mellema provides additional detail on this issue in his post titled “Do not convert synced mailboxes to shared in a hybrid environment“.

Message Size Restrictions

In April of last year, Microsoft announced support for messages as large as 150 MB. While the previous limit of 35 MB was sufficient for most people, it did cause some headaches during migrations in environments that had existing limits higher than 40 MB. The result of the change was that you could now modify the message size restriction for mailboxes on a per-mailbox basis by modifying that attribute in the cloud.
If you set a message receive size restriction on-premises before you migrate the mailbox, that attribute is never synced to the cloud and the user receives the default 35 MB limit post-migration. After migrating the mailbox, the previous restriction only applies to people on-premises trying to send to that cloud mailbox; if you now change the value in the cloud, the change is not synced back on-premises (because it’s not a “write-back attribute”). The result is that you end up with different values in the on-premises directory and cloud directory and the value applied will depend on which of the two platforms the sending user’s mailbox is on. If you try to change the attribute on-premises, the problem is that the “Set-RemoteMailbox” cmdlet does not have parameters for “MaxReceiveSize” (or “MaxSendSize”). To correct this issue, you need to modify the “delivContLength” attribute on the user object in Active Directory.

Message Delivery Restrictions

While all of the attributes for the settings on the “Message Delivery Restrictions” tab are synchronized to the cloud from on-premises, you can also modify these in the cloud. Modifying these attributes in the cloud creates two separate experiences depending on where messages are originating. Since these attributes are not written-back to on-premises, any change in the on-premises directory to these attributes will overwrite the values in the cloud.
The settings include:

• Accept Messages From
• Reject Messages From
• Require that all senders are authenticated

Mail Tips

If you’ve set a “Mail Tip” on an individual mailbox, that attribute is synchronized to the cloud. Like the above settings, you can change it in the cloud even though the on-premises attribute remains authoritative. This is another setting where changing the on-premises value will overwrite the cloud one.

Attributes Lost Post-Migration

There are a couple attributes that you’ll see are lost after a mailbox is moved. In this situation, the attribute remains populated on-premises but may not impact any functionality. One attribute is the “Recipient Limit” which can be set on-premises but in the cloud is set to 500 and cannot be changed. Another item to note is if you have a forwarder setup on your mailbox, that item is lost post-migration and needs to be reconfigured in the cloud even though the on-premises Active Directory will still show the forwarder.

Summary

While the admin tools can at times lead you astray, you should always modify synchronized attributes by making the change in the on-premises Active Directory. If the attribute is not in the set of synchronized set (such as “Message Size Restrictions”), you can see an inconsistent experience between on-premises and cloud mailboxes.

Did you find this article helpful?
Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.
Looking to do some more reading on Office 365?
Catch up on my past articles here: Joe Palarchio.