Create Office 365 mailboxes while On Premise mailbox still exists
There are situations in which you want to create a office 365 mailbox on a AD synchronized account that still has an on premises mailbox. For instance when using 3rd party migration tools that require the office 365 mailbox to exist. Normally when assigning a office 365 exchange license to a user a mailbox is automatically created. When this user still has an on premises mailbox office 365 will not create a mailbox. A mailbox will only be created when the microsoft migration tools are used. Office 365 checks the existence of the msExchMailboxGuid attribute to determine whether an on premise mailbox exists.
PERFORM THESE STEPS AT YOUR OWN RISK!
We can alter the directory sychronisation so that the msExchMailboxGuid is no longer synchronised to Office 365. This can be done by performing the following:
- On the computer thats running the directory synchronisation tool.
- Navigate to C:\Program Files\Microsoft Online Directory Sync\SYNCBUS\UIShell
- Launch the application miisclient.exe
- Click on the management agents tab
- Open the properties of the Active Directory Connector
- Go to Configure Attribute Flow
- Expand Object Type: user in the Configure Attribute Flow section
- Scroll down to msExchMailboxGuid
- Click the Delete button to remove the mapping
- Click Ok to save the changes
If you already have synchronized objects in Office 365 these will still have the msExchMailboxGUID populated in Office 365. Since there is no way to use ADSIEdit on Office 365 objects we will have to do this with the directory synchronization tool.
The Azure Directory Synchronization tool is actually an installation of FIM (Forefront Identity Manager). I will not go into the specifics of how FIM works in this article but I will explain how to remove the msExchMailboxGUID value. FIM uses a metaverse to store the objects and attributes that are synchronized to Office 365. The metaverse is stored in a SQL database. We have removed the msExchMailboxGUID from the Active Directory Connector so it no longer populates the metaverse however for existing objects the value is still populated and will need to be removed. To do so follow these steps on the computer that’s running FIM:
- Install the SQL Express admin studio.
- Perform the following query:SELECT userPrincipalName, msExchMailboxGuid
FROM mms_metaverse
WHERE (msExchMailboxGuid IS NOT NULL)This should return the user objects that still have the msExchMailboxGUI attribute populated. - Perform the following Query to remove the msExchMailboxGUI from all users:
UPDATE mms_metaverse SET msExchMailboxGuid = NULL WHERE (msExchMailboxGuid IS NOT NULL) - Now that this is done we need to synchronize the changes to Office 365.
- Navigate to C:\Program Files\Microsoft Online Directory Sync\SYNCBUS\UIShell
- Launch the application miisclient.exe
- Click on the management agents tab
- Right-click on the Windows Azure Active Directory Connector and click Run.
- Perform a Full Import Full Sync.
- When the Full Import is finished perform an Export.
- Assign licenses to the accounts in Office 365. This should create the mailboxes.
This completes the procedure. Make sure that if you have to reinstall the Directory Sync tool onto another system to apply step 1 to 10 before running it.
Hi, I have read and shared this article which Microsoft sent me to, you obviously have gotten deep into it! I am looking to establish a FIM hybrid with empty 365 mailboxes and to preserve Outlook 2010 OST’s which do not synch apart from new mail by setting up the msExchMailboxGUID to match on AD/Azure/365. I do not know what attribute ensures that mailbox content is in step. Do you?
[…] If so, I will presumably need to remove my o365 users and re-sync, as this attribute will exist for the users created previously and will not remove the attribute for me. Just not sync it. When deleting users on o365, it moves them into "deleted users" and I cant see a permanent delete option? I don't really want to have to wait 30 days before they completely disappear before re-syncing. If you delete and resync it will just make the accounts active again and won't do what you want. This guide is pretty good for doing what you want – Create Office 365 mailboxes while On Premise mailbox still exists […]
Thanks! Great Article! Looks like Microsoft Changes some names around. The dirsync for me was in C:\Program Files\Windows Azure Active Directory Sync. I used The 2012 SQL management studio.
I had the same error with the msExchMailboxGuid – in my case we had synced using DirSync but had no intention of utilizing a Cutover/Stage/Hybrid migration due to no published Outlook Anywhere. When you run the initial sync, the msExchMailboxGuid attribute is populated in the cloud and as you say expects the on-premise environment to execute the migration of the mailbox, as you would do in any of the above 3 examples.
A call with MS Support tonight advised the following, which seems to be a simplified version of your solution, thought i’d share here:
1. Open ADSIEDIT
2. Clear the msExchMailboxGuid attribute on each object already in sync via DirSync to cloud
3. Rerun a sync of both DirSync via PowerShell and GUI
4. Login to O365 portal and verify the update has taken place
5. Assign license to users.
We didn’t have to make any changes to the FIm connector, but i did manually have to clear the attribute on each object already in sync. It was only 200 objects, but could be a pain in the ass if it were alot more…
Nowhere is there any warnings when configuring DirSync for such a scenario, as all MS documentation assumes you are running one of thee three main migration types.
MS Support have had many cases they tell me.
Thanks, this saved my … Had this problem for a while, fortunately smart people like you share real goodies to tackle the unexpected.
Thanks again.
MF
Is there a way to reverse this if removing the setting has negative effects?
Where is the database in which to edit?
@joe
thanks for your guide, worked!
I was wondering the same. Did you ever get an answer?
I was wondering the same. Did you ever get an answer?
The database is called MSONLINE.
Fantastic article – thank you! 10/10
Nice article but is it the same procedure if we are using AAD Connect..? as we are using AAD connect and we would like to disable the attribute MSExchMailboxGuid.We already have users in office 365
Hi,
I haven’t tested this on AAD Connect but it will most likely be the same procedure.
It seams that the MSONLINE instance goes obsolete after upgrading to AD-Connect?
I have no ide where AD-Connect keeps its data?