Changes around handling of mail users in Exchange Online

​Over an year ago, a blogged about the need to reconfigure mail users addresses due to directory sync only allowing for aliases from verified/accepted domains. Well, Office 365 is a constantly evolving system, and things have now changed. Synced objects will now preserve all their aliases, even external ones, and will also have the primary SMTP address and the external address correctly configured out of the box via the corresponding AD attributes. If you apply a license to the corresponding user in Office 365 however, the regular rules apply and all non-verified domains will be replaced with the one.

In addition, another important change has been made. Previously, there was no way to convert a mailbox-enabled user to mail-enabled one in Exchange Online. In EO, we don’t actually have access to the relevant cmdlets, Disable-Mailbox and Enable-MailUser (well we do have access to Disable-Mailbox, but only the Archive parameter is accepted). The only way to provision a mailbox for the user is to grant him a valid EO license, which triggers the corresponding workflows at the back end. Similarly, removing the EO license for a user results in ‘disable mailbox’ behavior, with all the relevant attributes stripped and no recipient remaining after. And there is nothing you can do about it either. On the bright side, this means that any addresses configured for the user could be used for another object, etc.

Currently, we still get the same behavior for objects authored in the cloud, both ‘plain’ users and mail user objects. If the mail user object is initially provisioned via dirsync however, granting and removing EO license results in ‘convert to MEU’ behavior – the mailbox goes poof, but the user object keeps its attributes and recipient type is changed back to mail user. In effect, we have a method to convert a mailbox to mail-enabled user in Exchange Online! ExternalEmailAddress will be preserved and even set as primary if this was configured originally. Same goes for are any additional ‘external’ aliases. Even the mailbox GUID is replaced back (if the synced object corresponds to an on-prem mailbox). And that’s even before any dirsync run, so EO is doing everything on its own. Sort of a snapshot-like behavior.

For example, here’s how the addresses looked like before applying a license:

EmailAddresses                : {,, X500:/o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=464a12962286478ab48eeb614745a4d9-mailb}
ExternalEmailAddress          :
PrimarySmtpAddress            :

The workflow responsible for the ‘provision a mailbox’ steps changed this to:

EmailAddresses                : {,, X500:/o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=464a12962286478ab48eeb614745a4d9-mailb}
ExternalEmailAddress          :
PrimarySmtpAddress            :

And removing the license triggered the ‘roll-back’ workflow:

EmailAddresses                : {,, X500:/o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=464a12962286478ab48eeb614745a4d9-mailb}
ExternalEmailAddress          :
PrimarySmtpAddress            :

There are some oddities with this however. As mentioned above, ALL the attributes seem to be taken from an earlier snapshot. And this causes problems if you have modified the addresses in the meantime, by adding new aliases or removing existing ones. So not a very good snapshot. Another funny thing happens if you apply a license to an object with MsExchMailboxGuid populated. As there is already a corresponding mailbox for this object on-prem, EO will not provision a new mailbox. But it does trigger some of the ‘provision mailbox’ workflows! The object will get all it’s proxy addresses replaced to meet the requirements for the same in the case of creating a mailbox. At the same time, the object remains a MEU, should be allowed to have external aliases, and one can indeed add new ones if needed. Seems like they are triggering the ‘make it a mailbox’ workflow without checking if the end result will actually be a mailbox…

I’m actually quite happy that it works like that, but there are some issues with the current implementation. And an obvious discrepancy in how this affects cloud vs synced users, would have been nice if that information was posted somewhere.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.