Exchange Online does not create a mailbox when we assign licenses

I rarely onboard customers to Office 365 without deploying DirSync or a similar tool, because it is and always have been best practice keeping Active Directory as Identity Source.

This challenge often came when a customer has Exchange in their Active Directory, and when we synchronize users to Azure Active Directory (AAD) they will bring attributes telling Exchange Online the user already has a mailbox.

And at this point it is working as intended, because Microsoft assumes we are using either Staged or Hybrid Migration.

But that requires Outlook Anywhere (OA) to be working, instead of using Outlook Web Access (OWA). Which is much more often in place for Exchange customers.


Therefore, we have two scenarios I wanne address. First is how we do not go into this mistake and it is easy when you know it.

It is only one attribute in Active Directory that Exchange Online read, so what we can do is to modify the attributes synchronized to AAD. Keeping Exchange Online from knowing the user has a mailbox already.

The attribute we need to exclude from the Synchronization is ‘msExchMailboxGuid’ and we can exclude it from the Synchronization with these steps:



After you tick off that attribute we og down to Configure Attribute Filter. First we expand the Object Type User, scroll Down to the msExchMailboxGuid and delete them.


If we try to Close the Windows we will get an error saying it excists under Object Type InetOrgPerson, so expand that and scroll Down to msExchMailboxGuid. Mark it and Delete it.


Second scenario is when you are already deep in it, maybe you also tried the workaround where you deactivate Directory Synchronization, delete all users and import users with a CSV file.

Now Exchange Online will create mailboxes and the migration will work, but we often want to activate Directory Synchronization again. Maybe for Password Hash Synchronization, but when we do it, DirSync will fail to synchronize the SMTP Addresses. Because they are already associated with a different user.

The error message is not very clear, but it is right. When we deleted the earlier synchronized users, they remain for a grace period and are the objects that already have the SMTP Addresses. So we need to clean up the grace folder, or Recycle bin, before we can soft-match the users and DirSync work again. We can recover deleted users from the Office 365 Admin Center, but in order to delete them from the Recycle bin we need to use PowerShell with the Azure Active Directory Cmdlets.

Start PowerShell With Administrator rights to run: Set-ExecutionPolicy Unrestricted

Get-MsolUser –ReturnDeletedUsers | Remove-MsolUser –RemoveFromRecycleBin

This will forever delete all users we have deleted, so incase you only want a couple of user we need to target them one by one or within a placeholder.

If we already have configured and had DirSync synchronize before, it will seem to work again at his point. Except from the Password Hash Sync, so in order to have it working again, we need to kick start the Sync Engine for Password Hash Sync again.

Which you can be familiar with already, because it was also necessary when going from Federation Services to Password Hash Sync.

Import-Module DirSync Set-FullPassSync

Open Services and restart the Windows Azure Active Directory Synchronization Service.

We can see the Sync engine for Password Hash by refreshing the Application log in Event Viewer. It runs every 3 Seconds.


I am Roy Apalnes, a Microsoft Cloud Evangelist working av Sopra Steria. Main focus in Microsoft Security and Endpoint Management, with a bigger picture in mind.

Featured Posts