A shared mailbox or delegate access is missing, read-only, or will not send

The mailbox is not appearing. Confirm the grant is actually there before touching the client.

1. Connect to Exchange Online and read the permission as it currently stands.

   PowerShellCopy

   Connect-ExchangeOnlineGet-MailboxPermission -Identity shared@example.com | Where-Object { $_.User -notlike 'NT AUTHORITY*' } | Select-Object User, AccessRights, IsInherited

2. Wait before doing anything else. A newly granted permission can take up to an hour to reach the client, and automapping only takes effect when Outlook next starts.

   This is the step that gets skipped and it is the answer most of the time. A great deal of effort goes into fixing mailboxes that were going to appear on their own within the hour.

3. Restart Outlook completely — not just close the window.

   PowerShellCopy

   Get-Process OUTLOOK -ErrorAction SilentlyContinue | Stop-Process -Force

4. If it still has not appeared, check whether automapping was disabled when the permission was granted.

   PowerShellCopy

   Get-MailboxPermission -Identity shared@example.com | Format-List User, AccessRights, *auto*

5. To change automapping, the permission has to be removed and re-added — there is no switch to toggle it in place.

   PowerShellCopy

   Remove-MailboxPermission -Identity shared@example.com -User person@example.com -AccessRights FullAccess -Confirm:$falseAdd-MailboxPermission -Identity shared@example.com -User person@example.com -AccessRights FullAccess -AutoMapping:$true

Automapping is deliberately off, or the mailbox is large enough that automapping is a bad idea.

1. Understand why automapping is often turned off deliberately. An automapped mailbox is downloaded into the user's OST, so a large shared mailbox mapped to twenty people is downloaded twenty times.

   If someone has deliberately disabled automapping on a big mailbox, turning it back on will bloat every one of those users' OST files and can make Outlook slow for all of them. Add it manually instead.

2. File → Account Settings → Account Settings → the account → Change → More Settings → Advanced → Add, and enter the shared mailbox address.

3. Alternatively add it as a separate account, which keeps it in its own data file and out of the primary OST.

4. Restart Outlook and confirm it appears.

"Cannot expand the folder", or folders that are visible but empty.

1. Confirm the permission is Full Access on the mailbox itself and not just folder-level permission on the inbox. Folder permissions grant a view of one folder and produce exactly this symptom on everything else.

   PowerShellCopy

   Get-MailboxPermission -Identity shared@example.com -User person@example.com | Select-Object AccessRights

2. Check the cached mode setting for shared folders. File → Account Settings → Account Settings → Change → "Download shared folders".

   With this ticked, shared folders come from the local cache; if the cache is damaged the folders appear but cannot be expanded. Unticking it makes Outlook read them from the server directly, which both proves where the problem is and often resolves it outright.

3. Untick it, restart Outlook, and test. If the mailbox now opens, the local cache was the problem.

4. To clear the cache properly, close Outlook and remove the OST — it is a cache and is rebuilt from the server.

   PowerShellCopy

   Get-ChildItem "$env:LOCALAPPDATA\Microsoft\Outlook" -Filter *.ost | Select-Object FullName, @{n='GB';e={[math]::Round($_.Length/1GB,2)}}, LastWriteTime

5. Rename rather than delete the OST, start Outlook, and let it rebuild. Delete the old file only once the rebuild is confirmed complete.

   An OST rebuild on a large mailbox can take hours and saturate the connection. Renaming means you can put the old one back if the rebuild goes wrong, and it costs nothing but disk space until you are sure.

Reading works and sending is refused.

1. Decide which of the two is wanted. Send As makes the message appear to come from the shared mailbox alone. Send on Behalf shows "Person on behalf of Shared Mailbox" in the recipient's client.

   This is a business decision rather than a technical one, and getting it wrong is visible to every external recipient. Ask before granting.

2. Check what is currently granted. They are stored in two different places, which is why one can be present and the other missing.

   PowerShellCopy

   Get-RecipientPermission -Identity shared@example.com | Select-Object Trustee, AccessRightsGet-Mailbox -Identity shared@example.com | Select-Object -ExpandProperty GrantSendOnBehalfTo

3. Grant Send As if that is what is wanted.

   PowerShellCopy

   Add-RecipientPermission -Identity shared@example.com -Trustee person@example.com -AccessRights SendAs -Confirm:$false

4. Or grant Send on Behalf instead. Note this replaces the whole list rather than adding to it, so include everyone who should have it.

   PowerShellCopy

   Set-Mailbox -Identity shared@example.com -GrantSendOnBehalfTo @{Add='person@example.com'}

   Using @{Add=...} rather than a plain assignment is what stops this quietly removing everyone else who already had the right.

5. Allow up to an hour, then have the user restart Outlook and send a test message. They must set the From field to the shared mailbox — it does not switch on its own.