The IT team at Harborview Medical Center created a shared mailbox called '[email protected]' and added five staff members as delegates with Full Access permissions. Three of the five users report that the shared mailbox appeared automatically in their Outlook desktop client, but two users say it did not appear. All five users have verified their Full Access permissions are correctly assigned. What is the most likely reason two users do not see the shared mailbox auto-mapped in Outlook?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Think of auto-mapping like a restaurant reservation system — if the front desk (Exchange admin center) books your table, it shows up automatically. But if someone calls in directly (PowerShell with -AutoMapping $false), it never makes it onto the display board. The three users added through the GUI got the default auto-mapping treatment; the two added via PowerShell with auto-mapping disabled were quietly left off the list.
Full explanation below image
Full Explanation
Auto-mapping is an Exchange Online feature that automatically adds a shared mailbox to a user's Outlook profile when they are granted Full Access permissions. By default, when Full Access is assigned through the Exchange admin center GUI, auto-mapping is enabled and Outlook detects the new mailbox via the Autodiscover service on the next profile refresh.
However, when administrators use the Add-MailboxPermission PowerShell cmdlet to assign Full Access, the -AutoMapping parameter defaults to $true — but it CAN be explicitly set to $false. If the two affected users had their permissions granted with '-AutoMapping $false', Outlook will never automatically add the shared mailbox to their profile, even though they have full permissions to access it. They would still be able to manually add the mailbox in Outlook.
Option A is incorrect because shared mailboxes in Exchange Online do not require an Exchange Online Plan 2 license for auto-mapping functionality. Auto-mapping is a feature tied to the permission grant mechanism, not the mailbox license level. Shared mailboxes themselves do not require a user license at all, as long as their size stays under 50 GB.
Option C is incorrect because auto-mapping is controlled server-side via the Autodiscover service. There is no 'Microsoft Exchange Autodiscover service' running on the user's local machine that needs to be restarted. Autodiscover is a cloud service, and Outlook queries it automatically. Users may need to close and reopen Outlook, but no local service restart is involved or required.
Option D is incorrect because auto-mapping has no dependency on Entra ID organizational units (OUs). Exchange Online auto-mapping works across the entire tenant regardless of where user accounts reside in the directory structure. OUs in Entra ID are not a controlling factor for this Exchange Online feature.
Exam tip: Know that Add-MailboxPermission with -AutoMapping $false is the classic gotcha for this scenario. When troubleshooting auto-mapping issues for a subset of users who all have confirmed Full Access permissions, the PowerShell AutoMapping flag is the first thing to check. To verify, run: Get-MailboxPermission -Identity <mailbox> | Where {$_.User -like 'username'} and inspect how the permission was originally granted.