Interesting case where Exchange is not installed on-premises
I’ve recently been working on projects as opposed to cases, and so I haven’t had anything too exciting to write about lately. However, I recently worked a case that I found quite interesting and wanted to share it here. I believe this is an edge case, but makes for an interesting problem none the less. Names has been changed to protect the innocent.
Environment
Contoso’s on-premises environment contains an Active Directory, but does not contain Exchange Servers. Azure AD Connect is used to synchronize the on-premises Active Directory objects with Office 365. The on-premises user objects that have been synchronized to Office 365 are all assigned Exchange Online licences, and thus have cloud mailboxes.
The Problem
Contoso would like to hide one of the mailboxes from the Exchange online GAL. There are two ways to accomplish this in Exchange Online.
First, Contoso goes into the mailbox in the Office 365 Admin Centre and checks the Hide from address lists box.
When Save is clicked, the following error dialog is presented.
The error is fairly self explanatory. We can’t make changes to this object in Office 365 because it is being synchronized from the on-premises Active directory. The error dialog here gives us the solution; we are required to make this change on-premises.
For those that are curious, attempting to make this same change in Office 365 through PowerShell results in the same error.
To make changes to office 365 objects that have been synchronized from on-premises, the change must be made on-premises. The change will then synchronize up to Office 365.
For this particular case, the on-premises Active Directory attribute msExchHideFromAddressLists for the user object needs to be set to True. The problem, is that this attribute does not exist in the local Active Directory because an Exchange Server is not installed on-premises, and so the AD schema was never extended with Exchange attributes.
Possible Solutions
There are really only two possible solutions here.
Using the Exchange Server install media, extend the local Active Directory schema. I don’t recommend this and so will not go into details here. From a high level, this would add Exchange attributes to the local Active Directory. These attributes could then be set, and Azure AD Sync would then be configured to sync these attributes to Office 365.
This option requires much testing, and there is always risk associated with AD schema changes.
The second option is to break the connection between the Office 365 user and their object in the Local Active Directory. One way of accomplishing this is to move the user object in the local Active Directory to an OU that does not synchronize to Office 365. Once the connection is broken, the cloud user can be modified in Office 365 as they are not tied to the local AD anymore.
This method may or may not be feasible, depending on how permissions are setup and what Contoso’s security policies are. Something else to note is that breaking this connection will also break password synchronization from on-premises to Office 365.
In the end Contoso decided to go with neither of the above options. Instead they opted not to hide this user from the Exchange Online GAL.