If you’ve landed here, you’ve probably already confirmed the symptom: you grant Full Access to a security group, the permission applies correctly, users can open the mailbox manually — but it never appears in Outlook on its own.
Automapping is driven by the msExchDelegateListLink attribute on the mailbox object. Exchange populates this attribute only when Full Access is granted to an individual user. Grant the same permission to a security group and the attribute stays empty.
Outlook reads that attribute at profile startup to decide which additional mailboxes to mount. Empty attribute, no mailbox.
There’s no supported way around it. Add-MailboxPermission -AutoMapping $true against a group succeeds without error — and does nothing.
The attribute is a multi-valued link to individual user objects. Resolving group membership at profile-load time — including nested groups — would mean Outlook performing directory expansion on every startup. It’s a design decision, not an oversight, and it’s unlikely to change.
Automapping works exactly as intended. The cost is that every permission is now an individual object you maintain by hand. Every new hire generates a ticket per mailbox. Every departure generates several, and at least one gets missed. Within a few years nobody can explain why half the permissions exist.
Your permission model stays clean and auditable. The cost lands on your users and your service desk: every person who joins a team has to add the shared mailbox to Outlook themselves.
This is what most mature environments end up with. It works. It also means your effective permission model is no longer group-based. Audit trails get murky, the script needs maintenance, and it’s usually understood by exactly one person. We wrote a longer, honest comparison →
The SharedConX Manager (server component) monitors group membership and applies mailbox permissions. The SharedConX Client handles the Outlook profile, mounting and unmounting mailboxes as membership changes.
Because the client handles the profile directly, you’re not dependent on msExchDelegateListLink at all — which is why this works where native automapping can’t.
| Native Exchange | SharedConX | |
|---|---|---|
| Group-based permissions | Yes | Yes |
| Mailbox appears automatically | Only with direct permissions | Yes, via groups |
| Removal on group exit | Manual | Automatic |
| Nested group support | N/A | No |
| Audit trail | Limited | Full change log |
No, it extends it. Existing direct-permission automapping continues to function normally.
SharedConX analyses your current environment first — read-only — and reports orphaned, duplicate, and conflicting entries. You decide what gets cleaned up. Nothing changes without your approval.
Nested groups are not supported. SharedConX evaluates direct members of the security group assigned to a mailbox — members of groups nested inside it are not resolved. Use flat security groups with direct membership for mailbox permissions; this also keeps effective access transparent and auditable, since who has access is always exactly who is in the group.
No. SharedConX does not require Domain Admin rights. The service account operates with limited, purpose-specific permissions — enough to read group memberships and manage mailbox permissions, nothing more.
Nothing. All existing permissions stay exactly as they are, mapped mailboxes stay mapped, and users keep working without interruption. While the service is down, changes are simply not processed: new mailboxes and security groups are not picked up, membership changes are not applied, and manually added permissions are not cleaned up. Once the Manager/Core is running again, it resumes processing. There is no scenario in which a Manager outage removes access or unmounts mailboxes.