Home » Exchange Server » Removing an Auto-Mapped Mailbox from Outlook

Removing an Auto-Mapped Mailbox from Outlook

A customer asked about a situation in which they're unable to remove mailboxes from users' Outlook profiles. In this case they were shared mailboxes and appeared in the left pane of Outlook. Although this case was for shared mailboxes, the cause and solution apply equally to user mailboxes. This can occur for on-premises Exchange Server and cloud-hosted mailboxes in Exchange Online.

In the Outlook account settings for the user, the shared mailbox does not appear as an additional mailbox.

The reason that the shared mailbox appears in Outlook, but does not appear in the Outlook account settings, is that auto-mapping is enabled by default when a user is granted access to a shared mailbox or to another user's mailbox. When auto-mapping is enabled, Outlook receives extra information in the Autodiscover response that tells it to open the additional mailbox.

The auto-mapping option can only be configured at the time the permissions are granted. If you want to remove auto-mapping for a user's access to a shared mailbox, then you must remove their mailbox permissions and then re-add the permissions again. Also, this will need to be performed using PowerShell, because the Exchange Admin Center doesn't expose the option to enable or disable auto-mapping when configuring mailbox permissions.

To remove and re-add a user's mailbox permissions using PowerShell, we can use the following steps. First, for an on-premises mailbox open the Exchange Management Shell, or for a cloud mailbox connect to Exchange Online.

Using the example from the screenshot above, the user in question is Adam Wally, and the shared mailbox is named ShareOnPremMailbox. Use Get-MailboxPermission to check that the permissions have been granted as mailbox permissions.

Next, use Remove-MailboxPermission to remove the mailbox permission for the user.

Finally, re-add the mailbox permission by running Add-MailboxPermission, this time using the -AutoMapping parameter to disable auto-mapping.

The change will not immediately be obvious to the end user, because there is a delay before their Outlook client picks up the change via Autodiscover. When Outlook receives the updated Autodiscover response, it will remove the auto-mapped mailbox from the user's Outlook profile. If the user needs to access the mailbox for anything, they must add it to their profile, or open it via the Outlook File menu.

As a side note, there's nothing in the Get-MailboxPermission output that will tell you whether a user who has access to a mailbox will be auto-mapped. However, for on-premises mailboxes you can query the Active Directory user object properties to determine who will be auto-mapped to a mailbox. The property that stores this information is named msExchDelegateListLink, and it can be queried using Get-ADUser. For example, to view the list of auto-mapped users for a mailbox named Payroll, we can run the following command.

Paul is a Microsoft MVP for Office Servers and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul is a co-author of Office 365 for IT Pros and several other books, and is also a Pluralsight author.
Category: Exchange Online, Exchange Server


  1. Ryan W says:

    Hi Paul, I always advise admins against automapping as it adds an Additional Mailbox in Outlook which then gets cached in the default mailboxes OST. We have seen sync issues when this files contains over 500 folders for Additional Mailboxes and want to avoid this.

    Instead we add mailboxes as Additional Accounts which use their own OST files. This has some other user experience benefits (and drawbacks) in Outlook but mainly seems to deliver more reliable syncing to Exchange Online.

    If you have a moment to reply, my question is do you ever advise clients to use Additional Accounts instead of Additional Mailboxes and are you aware of the 500 folder issue?

    Many thanks, Ryan.

    • I’m aware of the limit.

      Adding the mailboxes as additional accounts requires that you know the password, which isn’t practical for shared mailboxes or when granting Person A access to Person B’s mailbox.

      • Joe F. says:

        Hi Paul,

        this is actually incorrect. When you add the second account, leave the password blank. Autodiscover will proceed and then the authentication box will appear. Change the authentication from the mailbox email address to the user trying to access it and use their password, it will give you access to the mailbox.

        I almost always use additional accounts. It allows you to select how long you want to cache each mailbox as well.

Leave a Reply

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