The three grants, precisely
| Grant | What it allows | What it does NOT |
|---|---|---|
| FullAccess | Open the mailbox and everything in it | Send anything — reading rights only |
| SendAs | Send AS the mailbox (From: shared@) — indistinguishable from the mailbox itself | Open it |
| SendOnBehalf | Send with "user on behalf of mailbox" visible | Impersonate cleanly; recipients see the delegation |
They compose: the classic shared-mailbox setup is FullAccess + SendAs. The classic confusion ticket is a user with FullAccess wondering why sending fails — nobody granted the send half.
Automapping: the glue and its failure modes
Granting FullAccess (by default) stamps the mailbox into the user's Autodiscover response; Outlook then auto-opens it in the folder list. The mechanics explain the mysteries:
- "I removed the permission but it's still in Outlook" — the autodiscover/licensing caches lag; it drains on the next profile refresh cycle, not instantly.
- "It never appeared" — automapping only applies to DIRECT user grants; permission via a GROUP does not automap, ever. Group-based access = users add the mailbox manually (or you script per-user grants).
- The 500-mailbox hoarder — automapped mailboxes all sync; users with
dozens accumulate cache bloat and 'Outlook is slow' tickets. Grant with
-AutoMapping $falsefor occasional-access cases.
Sent items and the eternal question
By default, mail sent AS a shared mailbox lands in the SENDER'S Sent
Items. The shared-mailbox sent-items settings
(Set-Mailbox -MessageCopyForSentAsEnabled / ...SendOnBehalfEnabled)
copy it to the shared mailbox too — the setting every team asks for and
few know exists.
Propagation timers (write these on the whiteboard)
Permission grants: minutes-to-an-hour to bite in all access paths. Removals: same, PLUS client caches. Group-membership-driven access: group propagation on top. The operational rule: grant, wait, THEN test — 'it doesn't work' 90 seconds after the cmdlet is not a failure, it's a timer.
What to watch (proofs)
- The truth per mailbox:
Get-MailboxPermission,Get-RecipientPermission(SendAs) andGet-Mailbox | fl GrantSendOnBehalfTo— the three grants live in three places; audit scripts must read all three. - Automapping state: the permission's AutoMapping flag isn't directly readable — govern by convention (script grants) and verify in a test profile.
- Sent-copy behaviour:
Get-Mailbox <shared> | fl MessageCopyFor*— the two switches, per mailbox. - Who sent 'as' the mailbox: mailbox audit log SendAs events name the ACTUAL actor — the accountability layer that makes SendAs safe to grant.