Discovering a users Auto-Mapped and Shared Mailboxes and Autodiscover discussion
Back in 2007 two of new features on the block that where released along side Exchange 2007 where Autodiscover and Exchange Web Services. Autodiscover at the time was a great leap forward (along with Outlook 2007) in allowing automatic configuration of email clients. So much so that a song was written about it https://techcommunity.microsoft.com/blog/exchange/the-autodiscover-song/585066. Autodiscover also played a role in a lot of EWS application in helping you discover what the url to use for the EWS endpoint which is especially important when dealing with onPrem Exchange.
What are Auto mapped mailboxes and why they are important
When a user has full access to a mailbox that has automapping enabled (note you can have full access to a mailbox without automapping enabled), that mailbox automatically appears in their mail client. This gives the user seamless access without any manual steps, which makes it easy to work with shared mailboxes and other types of mailboxes like user, room, or equipment mailboxes.
This automatic access makes a user's workflow more efficient and collaborative. In the age of AI, where we rely more on agents and third-party models, it's increasingly important that these systems can easily discover and understand the purpose of these mailboxes.
Where is the Automapping configuration for a mailbox stored
In OnPrem environment it’s stored in the msExchDelegateListBL and msExchDelegateListLink Active Directory properties eg.
The mailbox that is permissioned: msExchDelegateListLink - If I’m looking at a Shared mailbox this property would tell me who are auto mapped delegates on this mailbox
The user who is being granted permissions: msExchDelegateListBL - If your looking at a mailbox this would tell me what mailboxes are going to be auto mapped for this user.
In Microsoft 365 hybrid environments these properties get synced in Entra. In Entra itself these properties aren’t exposed in the Graph API.
Autodiscover
Autodiscover provides information on auto-mapped mailboxes to Outlook classic and EAS clients via the AlternateMailbox node in the Autodiscover response. eg
So Outlook Classic when it does an Autodiscover for the current profile will use this Alternate Mailbox result to AutoMap the returned mailboxes.
What about New Outlook ? no new Outlook uses a private API request eg
GET https://outlook.office.com/ows/beta/accounts/automappedmailboxes?api-version=2.0&n=16&cv=aPtMtCIYoqrvxv6veaTDiu.16 HTTP/1.1
What about the Graph API ? Currently there is no way of returning auto mapped mailboxes using the Graph API.
I’m migrating an EWS Application that uses Autodiscover to Graph what should I do with the Autodiscover part
EWS and Autodiscover are two separate webservices so the depreciation of EWS in 2026 doesn’t mean Autodiscover will also go in 2026. There is no official word on the fate of Autodiscover in the short or long term as its use goes far beyond just its use in EWS and it doesn’t suffer the same security limitations of EWS. The only tricky thing is AFAIK the only oauth grants that are useable in Autodiscover are the EWS and EAS Accessasuser.all. This means for developers they may get the question from security people as to why you would still need these permissions if your application now has been migrated to Graph but you still need to use Autodiscover for specific things. If you a third party ISV selling to customers this can be a significate friction point but if you need these alternate mailbox information there is no alternate at the moment (or on the horizon).
Other issues I have with this and New Outlook is a good example
This is how new Outlook shows a room mailbox that is auto mapped in my profile and if I mouse over it Outlook tells me its a shared mailbox. An any mailbox I have that is auto mapped whether it a SharedMailbox, or another usermailbox or room mailbox is according to new Outlook a shared mailbox. The problem here is that there is no API endpoint that can be used by a delegate to work this out. If your using client credentials then you could use the userpurpose to determine if a Mailbox is Shared Mailbox vs a Room mailbox but that isn’t something that a app or agent running under a delegate credential can do.
Some Exceptions
One exception is archive mailboxes which Autodiscover will tell you that a Mailbox is an Archive or Delegate. The other exception is you can use the people api in the Graph to at least knock out any mailboxes that are room mailboxes. eg
What challenges lie ahead for Agents and AI
Discovery back in 2007 was about solving a useability problem eg if you make creating a mail profile easier and adding alternate mailboxes automatically your saving an end user and business a lot of time and support issues and friction. In 2025 when your going to task an AI Agent with something based on a prompt it now has the same problem. What logic and learning can it use to achieve its task and fulfil the request arcuately for the end user. I’m find it frustrating these days that a lot of feature remain hidden behind private API e.g. flexible work hours, roaming signatures and discovery like this. With discovery in an OnPrem environment where you have full access to all the underlying AD properties these type of things are actually easily solvable using LDAP (from the 90’s).
Engineering your own solution - A Core WebAPI Service
As a proposed solution to this problem you can use a simple Core WebAPI REST service. This service will act as a central hub for agents and automations to interact with mailboxes.
Key Features of the API
Authentication: The service will run using App Credentials (Client Credential flow). This ensures secure, non-interactive access to Microsoft Graph without requiring a specific user's login.
Autodiscover: The primary function will be to perform an Autodiscover of a specified email address. The service will return a list of any associated alternate mailboxes.
Purpose Discovery: Using the client credentials flow, the API will leverage Microsoft Graph to retrieve the purpose of each mailbox from its settings. This provides context, allowing agents to understand what each mailbox is for (e.g., a room, equipment, or shared mailbox) and act accordingly.
This API endpoint provides a scalable and repeatable way for any client or agent to programmatically find and understand the context of alternative mailboxes.
An automation can then use this information to make its logic choices. The code from the micro-service is located https://github.com/gscales/Powershell-Scripts/blob/master/Graph101/GraphSDK/AutoAlternate.cs