Recently I’ve been working to get a full O365 implementation setup to roll-out to our students, and while we’re not doing student e-mail just yet, I wanted to make sure everything is working so when we are ready, we just have to add the Exchange licenses. One of the quirks I ran into is a few users were not listed in the Office 365 address book. We do not have a hybrid Exchange deployment, but because our AD is sync’d to O365, we should have a full GAL in the cloud accessible to be searched by any Office 365 user.

After going through the usual online search and not turning up anything too helpful, I decided to compare O365 data for two users: one who was showing up in the GAL, and another that was not. I piped the output from Get-MSOLUser to a separate text file for each user, then used WinMerge to compare them.

Get-MSOLUser –UserPrincipalName UPN1 | fl > user1.txt

Get-MSOLUser –UserPrincipalName UPN2 | fl > user2.txt

The one attribute that stood out as different was CloudExchangeRecipientDisplayType, which was set to “-2147483642” for the user that was in the GAL, and “1073741824” for the user that was not. I started researching that attribute and found this very helpful post. The poster of that Article, Declan Conroy, was trying to trick O365 in such a way as to facilitate an easier migration from on-premise Exchange to the cloud. It wasn’t an exact fit for my situation, but it did make clear that “CloudExchangeRecipientDisplayType is not available as an attribute in AD, [but] is exported…with the value from the incoming msExchRecipientDisplayType attribute.”

That led me to look for more info on msExchRecipientDisplayType, and I found this page listing the meaning of the various values for both that attribute and msExchRecipientTypeDetails.

At this point it still wasn’t clear to me if the discrepancy in CloudExchangeRecipientDisplayType was causing the missing GAL entry, and because the only way to change that attribute in the cloud was to change msExchangeRecipientDisplayType in my local AD, I wanted to investigate more.

I decided to search for other users with 1073741824 as their CloudExchangeRecipientDisplayType:

    Get-MSOLUser | Where-Object {$_.CloudExchangeRecipientDisplayType -eq 1073741824}

The results from this search seem to confirm that this is the expected value for users who do not have on-premise mailboxes.

Some more digging turned up another disparity between accounts in the GAL and those that were not. I ran this command:

    Get-User –Identity displayname | select RecipientType, RecipientTypeDetails

I found three distinct results:

This provided further evidence that the incorrect CloudExchangeRecipientDisplayType, which was controlled by the on-premise msExchRecipientDisplayType attribute, was the source of the problem. So now to fix it…fortunately I had already found the answer in a post I linked earlier.

Using the attribute editor in Active Directory Users & Computers I made three changes to each affected AD account:

Note that to access the attribute editor you must have advanced features enabled, and for some reason that tab does not show if you perform a search for the user. You’ll need to manually find them in AD and pull up their properties there instead.

You then need to perform a sync of your on-premise AD to the cloud. After doing so, RecipientType and RecipientTypeDetails both showed “MailUser,” and CloudExchangeRecipientDisplayType showed “-2147483642,” both of which were expected values for a working on-premise mailbox. A quick check of the address book showed the users were now listed in the O365 GAL.

You’re still not done though. If you leave the settings like this you will break your on-premise mailbox. (Why is it you only discover this stuff late on a Friday night, when you’re trying to relax?) You must change msExchRecipientDisplayType, msExchRecipientTypeDetails, and most importantly targetAddress back to their original values (1073741824, 1, and not set, respectively) in your on-premise AD. This will keep your mailbox working but the change to the cloud user type will remain. All set!

In speaking with a colleague recently I remarked that 90% of what you do in Office 365 is easy and works well, but the other 10% is a real source of pain. As we’ve seen here, much of that 10% comes from the fact that it’s not clear what many O365 attributes represent, and even when it is, those attributes are often not directly editable by administrators. Hopefully that situation will improve in time.