Shared mailboxes automapping broke and cannot be removed after hybrid migration

Brass Contributor

We migrated a user from Exchange to Office 365. The shared mailbox is still on premises in Exchange. The full access is working and i can see that the user can still open the mailbox via OWA (open another mailbox). 


This user had the mailbox automapped to his Outlook and after migrating him, his Outlook will no longer open the automapped mailbox.


When we try and remove the full access permissions and the automapping from the mailbox on prem it will not remove from Outlook. (We need to delete his Outlook profile and recreate to get rid of it)


Since it thinks it is automapped, we cannot remove the mailbox from his Outlook. Even after removing it via powershell on prem. 


Since the mailbox is already added to his Outlook. We cannot go to account settings and force the mailbox to be added to the profile again. 


Thoughts? We will eventually move the shared mailbox to Office 365. But there are a lot of users accessing this mailbox. We cannot migrate it until we are ready for the rest of the users? 

5 Replies

Automapping is NOT supported cross-premises, it's clearly mentioned in the documentation and you should have planned around it. Anyway, apart from recreating the Outlook profile for any of the affected users, you can try to manually edit the automapping attributes as detailed for example here:


Another thing to try is to "reset" automapping via the –ClearAutoMapping switch for Remove-MailboxPermission. I'm not sure however whether this cmdlet made it to on-premises, so it might not be available for you. If it is, be aware that running it will clear the automapping for all users that currently have access to said mailbox, you cannot designate a single delegate with it.

It should work just fine with the auto mapping, are you syncing the shared mailboxes OU location to Office 365?

@Vasil Michev - Understood and we have and are taking into account automapping as part of full end user migrations. Currently our issue is that we have migrated a select user group that are ok with losing automapping. The issue now is that after the user was migrated the mailbox is still "stuck" as automapped to the Outlook client. We cannot delete or remove it, I have tried everything on prem in powershell and AD, etc. Since it broken in a "stuck" automapped stated, we cannot add a secondary mailbox to Outlook. 


@Deleted - Automapping is working fine for remaining Exchange on prem users to Exchange and Office 365 to Office 365. 

Hi guys this is my first response in the community but I was able to resolve this with in our environment.
First the hard way, if it's really stuck!
Delete all profiles in Control Panel > Mail > (I took all of the non folder contents out of the user appdata files, all minus the original folders including: xml/ost/PST/nst... pretty much any thing listed, into a new file on the desk top)

Create another profile in Control Panel > Mail >Data Files > Email > Add > Manual Setup > office 365 option> input the email> allow to connect....
Once Outlook open and it's updating the mailboxes right click the original Auto mapped Group mailbox and select remove or delete.

Outlook seems to go crazy for a second and only the new secondary email will pop up.

Close outlook go back to Control Panel > Mail > remove the profile and add it back with the same steps as above.

This seems to sync the permissions with o365 and the auto mapped mail box should be gone.

Depending on the permissions they should have the options to send from the mailbox as themselves or from the mailbox at this point.

The east way that worked a few times was to just add the account from file > "Add account" > allow to populate> close outlook > open Outlook> delete the profiles listed in Control Panel> Mail > close outlook > go to control panel > mail > add profile name if you get the traditional mail set up use the manual set up with the same steps as above if you get the auto 365 set up just add the email back from file > add account... Upon opening it should be good to go.
As in not supported either way e.g. user mailbox on-prem with shared mailbox in cloud and/or user mailbox in cloud and shared mailbox on-prem ?