Partilhar via

Dude - why isn't a mailbox being provisioned/created in Exchange Online after licensing?

  • Artigo

I've run into this scenario several times, and I wanted to share a common cause for this situation (as well as how to fix it!).

Consider the following scenario:

You previously migrated a user mailbox from On-Premises to Exchange Online. Sometime later, the Exchange Online license was removed and the license was left off the user for more than 30 days.

or

You previously migrated a user mailbox from On-Premises to Exchange Online and never applied a license. No license was applied for more than 60 days.

Both of these scenarios result in the mailbox being disconnected. In the first case, the mailbox is disconnected immediately, but the mailbox remains in a special hidden state in the database for 30 days. After 30 days, the mailbox is purged from the database, and is no longer recoverable. In the second case, the mailbox remains active for 30 days, during the "grace period". After 30 days with no license, the mailbox is disconnected by a process called "License Reconciliation". This is just a fancy term for Azure running a process against unlicensed users and signaling each service to take the appropriate steps. For Exchange Online, License Reconciliation means we have an unlicensed mailbox, and the action taken is to disconnect the mailbox.

In any event, the net result is a mailbox that gets disconnected and later purged.

Where the problem rears its ugly head is if you end up deciding to apply an Exchange Online license later on. You are probably thinking "Hey, if I apply an Exchange Online license, I'll get a new mailbox no problem!" That would seem to be logical, but unfortunately logic doesn't always prevail and in this case, no mailbox is provisioned.

You see, when a mailbox is migrated from On-Premise to Exchange Online, the value of the attribute msExchRemoteRecipientType gets updated to reflect that the mailbox was migrated. You can see this with the Get-RemoteMailbox output from On-Premises Exchange Management Shell.

Name RecipientTypeDetails RemoteRecipientType
UserNoMailbox RemoteUserMailbox Migrated

 

A RemoteRecipientType of Migrated equates to a value of 4. The AD attribute is msExchRemoteRecipientType.

Anyways, back to our story. When the RemoteRecipientType value is set to Migrated, Exchange Online will never provision a *New* mailbox, no matter how hard you try. You could say that is a failing on the part of Exchange Online. After all, the service should do what you tell it, right? :-)

So how do we fix this? And before you ask, NO it isn't as easy as just editing the msExchRemoteRecipientType attribute value in AD (I tried! It doesn't work!)

I put together the following steps to get you out of this situation.

  1. Set the Powershell Format enumeration limit to unlimited (to ensure no attribute values are cut off)
    $formatenumerationlimit = -1
    For those not familiar, the Exchange Management Shell has an enumeration limit which can result in some values being cut off, which is evidenced by the trailing …) at the end of a value.
  2. Get-RemoteMailbox “user identity” | fl
    This is so you have a record of all current attributes. If you want to save it to a text file or CSV or something else, knock yourself out.
  3. Disable-RemoteMailbox
    This will remove all Exchange attributes (including Archive guid)
  4. Run Dirsync delta sync from your AAD Connect server
    Start-ADSyncSyncCycle -PolicyType delta
    This will sync and remove the Exchange Online Mailuser
  5. Enable-RemoteMailbox “user identity” -RemoteRoutingAddress user@contoso.mail.onmicrosoft.com
    This will set the remote recipient flags to "ProvisionMailbox" and the Exchange Guid will be blank (all 0's)
  6. Run Dirsync delta sync.
    Start-ADSyncSyncCycle -PolicyType delta
    Since the Exchange guid is no longer populated, as long as the Exchange Online license is assigned a new mailbox will be provisioned. HALLELUJAH!
  7. Optionally, provision an Archive mailbox
    Enable-RemoteMailbox "user identity" -Archive
    *Note* - if a previous archive guid was present, and the archive mailbox still somehow exists, you may see a provisioning error referencing not being able to disable the old archive guid. If you encounter this error, you can try setting the archive guid on the remote mailbox to the old one.
    The validation error can be exposed to you in PowerShell by running the following command from MSOL PowerShell
    (Get-MsolUser -UserPrincipalName upnofuser).errors.errordetail.objecterrors.errorrecord.errordescription
    If there is a validation error, and it is the archive, it will show you the new archive guid and the old one.
  8. Set-RemoteMailbox “user identity” -ArchiveGuid “old archive guid”After confirming that the Exchange Online mailbox is successfully provisioned, you can stamp the Exchange Guid on the on-premises Remote mailbox object. This is really only required if you think you might have to Offboard the mailbox back to On-Premises, but I like to set it for the sake of being consistent.
  9. Set-RemoteMailbox “user identity” -ExchangeGuid “Exchange guid value from new Exchange Online mailbox”
  10. Re-stamp any attributes that were previously stamped, such as custom attributes, or additional email addresses (compare with the Get-RemoteMailbox from step 2)

It is entirely possible that the logic of Exchange Online will at some point change, and render this guidance useless. Until then, I hope this helps with you to understand why this happens, and how to fix this condition.

Comments

  • Anonymous
    September 19, 2018
    Awesome information... Keep it up