Too Many Shared Mailboxes in Outlook? When to Disable AutoMapping
AutoMapping is convenient until one user has Full Access to a dozen shared mailboxes. Microsoft publishes real performance guidance for this — here's what it actually says.
Why AutoMapping is useful
When a delegate is granted Full Access to a shared mailbox with AutoMapping enabled, Exchange writes that grant to the mailbox's msExchDelegateListLink attribute and Outlook's Autodiscover process picks it up automatically — the mailbox appears in the delegate's folder pane with no manual "add account" step. This is controlled by the -AutoMapping parameter on Add-MailboxPermission, which defaults to $true.
What happens with a lot of them
AutoMapping doesn't have a hard mailbox-count limit, but it isn't free — every AutoMapped mailbox is a folder tree Outlook keeps open. Microsoft's own troubleshooting documentation gives a real, if approximate, range: a computer with slower hardware, a large primary mailbox, and a slow network connection "may not be able to open more than five shared folders or mailboxes," while a faster machine "may be able to open 10 or more." The exact number depends on hardware, mailbox and shared-mailbox size, folder and item counts, and network speed — Microsoft doesn't give a single fixed cutoff, and neither do we. Source: Slow performance if many shared folders or mailboxes are open.
Past that range, admins typically see slow folder switching, delayed search, and longer Outlook startup for the affected user — not an outright failure, just a degraded experience that gets worse the more mailboxes stack up.
Full Access and AutoMapping are separate decisions
A delegate can have Full Access without AutoMapping. The mailbox simply won't appear automatically — the delegate adds it manually as an additional mailbox in their Outlook profile instead, and only when they choose to. This is the right trade for a user who needs occasional access to many mailboxes but shouldn't have all of them loaded by default every time Outlook starts.
How to actually turn it off
AutoMapping isn't a setting you flip on an existing grant — Microsoft's documented procedure is to remove the Full Access permission and re-add it with AutoMapping disabled:
Remove-MailboxPermission -Identity [email protected] `
-User [email protected] -AccessRights FullAccess -Confirm:$false
Add-MailboxPermission -Identity [email protected] `
-User [email protected] -AccessRights FullAccess -AutoMapping:$falseSource: Remove automapping for a shared mailbox. There's no separate toggle command — the permission is recreated with the new setting.
Classic Outlook vs. New Outlook
Microsoft's official troubleshooter for the performance issue above explicitly does not work in New Outlook for Windows, which points to a different underlying architecture for shared mailboxes there rather than the same caching model with a different number. We couldn't find Microsoft documentation stating whether New Outlook has a higher, lower, or materially different practical ceiling for AutoMapped mailboxes — so we won't claim one. What is documented is that New Outlook handles AutoMapped mailboxes differently at a structural level; see New Outlook Shared Mailboxes: AutoMapping, Sync and Notifications Explained for what's actually confirmed.
Where Tenvero fits
Tenvero sets AutoMapping per mailbox mapping at grant time — the same-AutoMapping decision above, applied consistently every time delegation is reconciled from an AD security group, instead of a one-off manual choice per user. That's deliberate permission configuration, not an Outlook performance fix: if a user is already past a comfortable mailbox count, disabling AutoMapping for some of their grants addresses the client load, not the underlying access decision.
Tenvero reconciles Full Access and AutoMapping from your AD security groups, consistently, every time. 30-day trial, no credit card.
Start 30-day trial