A colleague came to me the other day with an interesting O365 sync issue. A customer was trying to hide a user from the O365 global address list (GAL) but it was not working. I asked if the affected account was being synchronized to O365 from on-prem via Azure AD Connect and my colleague confirmed that this was, in fact, the case.
After determining the account was being synchronized from on-prem, I asked if the customer was using an on-prem Exchange server to manage Exchange attributes. When the customer replied that they did not have an on-prem Exchange server, I told my colleague to make sure the affected account's "Hide from address lists" property box was checked and he confirmed that it was. We forced a sync to O365 and determined that the account was STILL not hidden from the GAL in O365. To verify replication was actually working as expected, we changed the Office attribute for the account and forced a manual synchronization. The change was synchronized, meaning the actual sync process was not our problem.
At this point, we looked at the Synchronization Rules Editor on the Azure AD Connect server and noticed that there was no transformation listed for the msExchHideFromAddressLists attribute. What this told us was that this user (nor any other synced user) would never be hidden from the GAL - the "hide from GAL" attribute was not synchronizing to O365. Further investigation was required.
We went back to the customer and asked if there was ever an Exchange server on premises. We suspected there was since there were Exchange attributes in AD but I wanted to hear the customer say as much. The customer confirmed that there had, in fact, been an Exchange server on-prem at one time. The fact that Exchange had once existed led to some suspicions on our end.
My colleague did a bit more research and determined that it was likely that the Active Directory schema had actually been extended with the Exchange attributes AFTER the deployment of Azure AD Connect. This would explain why sync worked but did not include the msExchHideFromAddressLists attribute, which is a default attribute that is synchronized to O365. My colleague went ahead, refreshed the directory schema in Azure AD Connect, and then force another sync.
Voila! The msExchHideFromAddressLists attribute showed up in the config and the "hide from address lists" box finally showed up checked in O365 for the affected user. Problem solved.
Essentially, the customer (who had no on-prem Exchange server) deployed Azure AD Connect and then synchronized his users to O365. Sometime after, Exchange was deployed on-prem (probably to manage Exchange attributes). Because Exchange was deployed AFTER Azure AD Connect, the Azure AD Connect did not know about the new Exchange attributes. As such, it could not synchronize them to O365. By refreshing the directory schema in Azure AD Connect, we were able to make the tool aware of the new attributes and it then began synchronizing them - allowing the affected user to be successfully hidden from the GAL in O365.
It wasn't a terribly difficult problem to solve - but interesting nonetheless!
About the author