While Office 365 offers an ever-expanding amount of insight of logging and health information, there are still operational tasks behind the scene that organizations do not have insight into. In many situations, you don’t necessarily care either; take for instance a failure of a database or server, the service has redundancy in place such that this type of issues goes largely unnoticed.
There is, however, one situation that can be hiding in the shadows that can be disruptive and a bit difficult to diagnose. The situation I’m referencing is one where all indicators on your end show that directory synchronization is healthy yet you have recipients missing from your Exchange Online Global Address List (GAL).
Below are some details on this situation, how you can identify it and how to get resolution through Microsoft support.
Directory Sync Process
It will help to start by explaining the sync process. When you’ve implemented directory synchronization, you’re using AAD Connect or one of its predecessors to sync on-premises Active Directory objects to an “Azure Active Directory” instance in the cloud.
What you may not know is that there is an additional sync process that occurs that you cannot see; Microsoft will often refer to this as the “forward sync” process. It is the “forward sync” process that actually populates the Exchange Online GAL from the Azure AD information; this generally occurs within a couple minutes or less from the initial Azure AD provisioning.
Possible Issues You May Encounter
Although rare, there are situations where you’ll find that there is an issue with that “forward sync” process. Some of the symptoms can be user objects that appear in Azure AD (“Get-MsolUser”) but not in the Exchange Online GAL (“Get-Recipient”) or issues with group members not being consistent when looking at Azure AD (“Get-MsolGroupMember”) vs Exchange Online (“Get-DistributionGroupMember”).
I’ve worked with several hundred Office 365 tenants since the inception of the service and the number of times I’ve uncovered “forward sync” issues is probably less than 10. That said, it’s very possible that others have gone unnoticed as identifying the issue can be difficult especially in large tenants.
Identifying The Issues
I was recently working with some on-premises mailboxes that were not showing up in the Exchange Online GAL as “Mail Enabled Users” as you would expect.
Taking a closer look at the sync process and these broken objects, I determined the following:
- Upon first sync, Azure AD will set “MSExchRecipientTypeDetails” to “1” on the user object and “CloudExchangeRecipientDisplayType” to “null”
- After the “forward sync” completes and the “Mail Enabled User” appears, you will see “CloudExchangeRecipientDisplayType” in Azure AD get set to “-2147483642” for user mailboxes.
For my objects that were not appearing the in the GAL, “CloudExchangeRecipientDisplayType” on the Azure AD object remained “null”.
So with the following PowerShell command run in Azure AD, I was able to identify all of the problem objects (7 in total):
Get-MsolUser -All | where {$_.MSExchRecipientTypeDetails -eq "1" -and $_.CloudExchangeRecipientDisplayType -eq $null}
The above command is searching for on-premises user mailboxes that are not appearing the Exchange Online GAL; if you’re looking for something else such as a resource mailbox, you will need to change the value specified in “MSExchRecipientTypeDetails”. You could also likely just look for MSExchRecipientTypeDetails values greater than or equal to “1”.
Resolution
Unfortunately there doesn’t seem to be much that you can do to resolve the issue on your own. In each case, I’ve needed to escalate to Microsoft and ask them to force the “forward sync” process. It can be challenging at times trying to explain what the issue is to some of the lower tier support specialists.
However, armed with the information above, you should be able to clearly show differences between Azure AD and Exchange Online queries and some potential attributes to key in on.
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.
Brilliant post Joe, have that exact issue due to EXO licences being assigned prior to ExHybrid being configured!!. So basically I have a load of sync’d users with no MEU entry and therefore am unable to migrate. Ive just tweeted you, but did you ever get the fix from MS or is this going to be an escalation to MS support to force the forward sync to avoid having to remove the MSOL user?
Excellent Joe. How about for mail enabled objects appearing On Prem but not in the EOL?