Somebody has been given access to a shared mailbox, the permission is visibly there in the admin centre, and Outlook is not showing it. The usual advice is to rebuild the Outlook profile. That does fix one of the three things this can be, and it is a slow way to find out that you had one of the other two.
Which of the three failures do you have
These are genuinely different faults with different fixes, and two minutes of checking saves the profile rebuild. Work down them in order.
- Permission granted through a group. Check whether the user got Full Access directly or by being put in a security group that holds it. If it came through a group, automapping was never going to work, and no amount of client-side repair will change that.
- Automapping explicitly off. Check the permission itself for
AutoMapping $false. Somebody may have set it deliberately, possibly years ago, possibly to stop a large mailbox loading on every profile in the building. - The client has not caught up. Only if the permission is direct and automapping is on is this a client problem, and only then is the profile worth touching.
Full Access through a group will never automap
This is the one that wastes the most time, because everything looks right. Automapping works off Autodiscover, and Autodiscover does not enumerate security groups that have been granted Full Access to the mailbox. The permission is real, the user can open the mailbox by hand, and the automatic add simply never happens. There is no error to find because nothing failed.
Group-based permission is usually the right administrative choice, so the answer is not always to undo it. If you want the mailbox to appear on its own, the permission has to be assigned to the user directly. If you would rather keep the group, then adding the mailbox by hand is the supported outcome rather than a workaround, and it is worth telling the service desk that so the ticket stops coming back.
The profile shows the mailbox but none of its folders
A different symptom that gets treated as the same problem. The mailbox is listed, it expands, and there is nothing underneath it. That is the shared folder download setting on the account rather than a permission or an automapping fault.
- In Outlook, open File, then Account Settings, then Account Settings again.
- Double click the user's own account in the list.
- Choose More Settings, then the Advanced tab.
- Confirm Download shared folders is ticked, then restart Outlook.
On a mailbox with a large amount of mail this can take a while to populate, and it will look broken while it is working.
Removing an automapped mailbox you no longer want
The reverse problem, and the reason a mailbox sometimes cannot be got rid of. An automapped mailbox cannot be removed from the profile by the user, because Autodiscover puts it straight back. The permission has to be removed and re-added with automapping turned off.
Remove-MailboxPermission -Identity "Accounts" -User "jane@example.com" -AccessRights FullAccess -InheritanceType All
Add-MailboxPermission -Identity "Accounts" -User "jane@example.com" -AccessRights FullAccess -InheritanceType All -AutoMapping $falseRemoving and re-adding in a single sitting is the documented approach. The change is not instant in the client, so expect the mailbox to keep appearing until the profile next picks up the Autodiscover response.
Questions that come up afterwards
How long should automapping take to appear?
It follows Autodiscover rather than a fixed timer, so restarting Outlook is a more reliable test than waiting. If it has not appeared after a restart and the permission is direct, the delay is not the problem.
Does removing automapping remove the access?
No. Automapping controls whether Outlook adds the mailbox to the profile on its own. The user keeps Full Access and can still open the mailbox by hand.
Why can the user open it on the web but not in the desktop client?
Because the web does not use automapping. That split is the most useful diagnostic here: it tells you the permission is fine and the fault is in how the profile is built.