Microsoft 365 Shared Mailbox AutoMapping with AD Security Groups

Why security-group mailbox permissions are attractive

Almost every Microsoft 365 tenant ends up with the same shared mailbox problem: a finance mailbox, a support alias, an accounts-payable inbox, each one needing access for a rotating cast of employees. Granting Full Access directly to individual users works at first, but it doesn't survive contact with a real joiner-mover-leaver process. Someone joins the team and needs access today. Someone transfers departments and should lose access without a ticket. Someone leaves the company and every mailbox they touched needs to be checked by hand.

Modelling shared mailbox access as an Active Directory security group instead of a list of individual grants fixes the process problem in one move. Access becomes a side effect of group membership, which is already the mechanism your onboarding and offboarding scripts, your HR system sync, and your helpdesk runbooks are built around. Add a user to SG-Mbx-Finance-FullAccess and they should have the mailbox. Remove them and they shouldn't. The group becomes the single auditable source of truth, and Exchange permissions become a downstream artifact of a process you already trust.

This is exactly the right instinct. The problem shows up one layer down, in Outlook.

Why Outlook AutoMapping becomes a problem

When Exchange grants Full Access to a mailbox with AutoMapping enabled, it doesn't just authorize access — it writes the grantee's SID into the mailbox's msExchDelegateListLink attribute. Outlook's Autodiscover response reads that attribute back and adds the shared mailbox to the user's profile automatically, with no manual "Add another mailbox" step. That's the entire value of AutoMapping: the access and the visibility arrive together.

That attribute is written per individual mailbox object, at the moment the permission is granted. When you grant Full Access to a security group rather than a user, Exchange Online resolves group membership correctly for the purposes of authorizing access — anyone in the group really can open the mailbox — but it does not expand that membership into per-user AutoMapping entries. Nothing gets written to msExchDelegateListLink for the individual members. The permission is real. The mailbox is silently missing from Outlook.

The result is a predictable support pattern: a new group member has correct, verifiable access — OWA opens the mailbox fine, EWS clients work, PowerShell confirms the permission — but their Outlook desktop and mobile clients never show it. They open a ticket. The admin checks permissions, finds them correct, and is left explaining that the fix is a manual "Add shared folder" step the whole point of AutoMapping was supposed to remove.

Direct user permissions vs group permissions

This leaves every admin choosing between two models, each with a real cost:

The way out isn't picking one column — it's keeping the group as the desired-state source of truth for who should have access, while still granting Full Access directly to each individual member so AutoMapping actually fires. The group stops being an Exchange permission and becomes an input to a reconciliation process that maintains individual grants on its behalf.

The manual PowerShell approach

Done by hand, this means resolving group membership and applying a direct, AutoMapping-enabled grant per member. An admin pulls every user in the group — recursively, so nested groups are flattened into individual accounts — and then loops over that list, granting Full Access to each member directly on the mailbox with AutoMapping turned on. Get-ADGroupMember supplies the membership; Add-MailboxPermissionapplies the grant, one call per user.

This works for the first pass. It does not, on its own, keep working. Run it again next month and it will happily re-grant permissions that already exist and do nothing about the ones that shouldn't exist anymore — because nothing in this script ever looks at who currently has access versus who is supposed to.

Using the AD group as the desired state

A reconciliation script needs two snapshots to compare, not one: the AD group tells you the desired state, and the mailbox's current permissions tell you the actual state. The desired list comes from the same recursive group-membership read as before. The actual list comes from reading the mailbox's current permissions and keeping only the direct, non-inherited Full Access grants — filtering out the system and service-account entries Exchange adds on its own, which aren't part of anyone's delegation model.

With both lists resolved to a common identity (SamAccountName, UPN, or SID — pick one and normalize both sides to it), the reconciliation itself is a set difference: anyone in the desired list but missing from the actual list needs a grant, and anyone in the actual list but no longer in the desired list needs a revoke.

Reconciling additions AND removals

This is the step most manual scripts skip, because additions are what someone actually asked for and removals are easy to forget when there's no immediate complaint driving them. But a shared mailbox permission model that only ever adds is not a security model — it's an access list that grows forever. A correct reconciliation pass computes both sides of that difference and acts on both: Add-MailboxPermission for every user who's newly in the group, and Remove-MailboxPermission for every user who no longer is — in the same run, not as a separate cleanup someone remembers to do later.

Removing the permission also clears the AutoMapping entry, so the mailbox drops out of the user's Outlook profile — though in practice that update rides on the next Autodiscover refresh, and users sometimes need an Outlook restart before the mailbox actually disappears from the folder list. Worth setting that expectation with staff: access is revoked immediately, the client catching up can lag by a few hours.

Run this on a schedule — a scheduled task calling a script per mailbox, or a single script iterating every mapped mailbox — and the AD group becomes a real desired-state source: add someone, they gain access and see the mailbox in Outlook by the next cycle; remove someone, they lose both, with no separate offboarding step for Exchange at all.

Auditing permission drift

Reconciliation only protects the mailboxes it's actually reconciling. Two failure modes show up in every tenant that runs this for more than a few months:

• Unmanaged direct access. A helpdesk admin grants Full Access directly to a user during an urgent request and never documents it. The grant isn't in the AD group, so the next reconciliation run treats it as drift and — depending on how the script is written — either silently revokes it or, worse, silently leaves it alone forever because the script only ever looks at group members, not at permissions outside its own bookkeeping.
• Disabled or orphaned accounts. A user is disabled in AD after leaving, but if they were removed from the group late, or added to the mailbox directly and never captured by the reconciliation, the permission survives their account long after it should have been cleaned up.

A separate, read-only audit pass — one that never writes anything — should periodically answer three questions for every shared mailbox: who currently has direct access, are they still an enabled account, and does that access trace back to a group membership the reconciliation script actually manages. Anything that doesn't is drift, and drift is exactly the kind of thing that turns up in a security review at the worst possible time.

How Tenvero automates the workflow

This entire model — group as desired state, direct per-user AutoMapping grants, scheduled reconciliation of both additions and removals, and a separate drift audit — is what the Tenvero Manager runs on every mapped mailbox, without hand-maintained scripts or scheduled tasks to babysit.

• Each shared mailbox is mapped to separate or shared AD security groups for Full Access, Send As and Send on Behalf, with AutoMapping enabled per mapping.
• The Tenvero Mailbox Sync task reads AD group membership and applies only Tenvero-owned grants and revokes on a schedule, protected by a global sync mutex so overlapping runs can't race each other.
• A read-only Delegation Audit scans every mapping and flags disabled accounts, orphaned trustees, missing groups and unmanaged direct access — without ever changing AD membership or Exchange permissions itself.
• An existing-access import can discover current direct Exchange delegates before you turn reconciliation on, and adopt safe matches into Tenvero-owned groups without revoking anyone's access in the process.

The AD group stays exactly what it already was in your process — the place access decisions get made — while Outlook AutoMapping keeps working for every member, and every addition or removal is reconciled and auditable without a script someone has to remember to re-run.