Table of Contents
The Wonders of AutoMapping
Automapping is the process by which Exchange “tags” a mailbox after a user receives full access permission to the mailbox. Outlook automapping happens when the client learns about the new access. The mechanism goes back to Exchange 2010 SP1. In some old Exchange server documentation, Microsoft explains automapping as follows:
“Exchange populates the msExchDelegateListLink attribute in Active Directory to locate mailboxes for which the user has Full Access permission, and then provides this information to the Autodiscover service. Autodiscover then populates the AlternateMailbox attribute with the information necessary for Outlook to open the full access mailboxes.”
Details are essentially the same for Exchange Online. Outlook uses the information received from Autodiscover to add the mailbox to its resource list. Resources include the user’s primary mailbox, their archive mailbox (if enabled), public folders, group mailboxes, and shared and other user mailboxes to which they have access. When Outlook starts, it opens all its resources.
Outlook automapping means that the client automatically opens mailboxes without user intervention. Fifteen minutes or so after gaining access to a mailbox, Outlook reacts to the tag and the mailbox appears in its resource list.
Mostly, Outlook automapping is a very valuable and worthwhile feature, which is why it’s the default when granting mailbox access through the Microsoft 365 admin center, Exchange admin center (EAC), or PowerShell. Figure 1 shows how to add full access permission through the Microsoft 365 admin center (left) and EAC (right). It would be nice if Microsoft rationalized the words used to describe the action.
In all cases, full access only grants permission to manage all folders in a mailbox. Users need to receive a separate permission to send as the mailbox or send on behalf of the mailbox.
Outlook mobile has its own delegate permission model while OWA opens other mailboxes as shared folders. It’s also possible to assign folder-level permissions to selected folders instead of the entire mailbox.
Synchronization Concerns
Outlook synchronizes the contents of automapped mailboxes into the OST for the user’s primary mailbox. Because of more generous quotas, Exchange Online mailboxes tend to be larger than on-premises mailboxes, so the OST files for cloud mailboxes are also larger. The size of the OST depends on the offline synchronization period set for Outlook (from one week to all). Obviously, if the user decides to synchronize their entire mailbox, the OST is larger than if they synchronize for the last year.
When Outlook 2003 introduced “drizzle-mode synchronization” and other network smarts (like an express thread to synchronize outgoing messages), the hard disks available for PCS were not as large or fast as those available today. In those days, Outlook started to experience performance problems after an OST file approached 8-10 GB in size.
The advent of solid-state drives, especially in laptops, has mostly cured this problem and users generally don’t meet performance issues due to the OST. That is, unless Outlook synchronizes multiple mailboxes into the primary OST. Depending on the mailbox sizes, the OST can grow to 50 GB or more. Solid state drives deliver great I/O performance, but even the fastest drive has its limits.
An efficient OST is important to Outlook. Having content for all mailboxes in local storage allows Outlook to switch between mailboxes and folders very quickly without the need to contact the server.
Mailbox Access Without Outlook Automapping
If users need access to multiple large mailboxes, it might be a better idea to grant them access without using Outlook automapping. To do this, you must:
- Grant full access to the mailbox using the PowerShell Add-MailboxPermission cmdlet. For example:
Add-MailboxPermission -AccessRights FullAccess -User Kim.Akers@office365itpros.com -Owner Customer.Services@Office365itpros.com -Automapping $False
- Manually add the mailbox to Outlook’s profile so that Outlook knows it must open the mailbox. Mailboxes added in this way do not synchronize to the primary OST. Instead, Outlook uses a separate OST for each mailbox.
As explained in Microsoft’s documentation, if a mailbox is automapped and you want to manually add it, you must remove the full access permission and then add it again without automapping.
Using separate OSTs means that each file is smaller and should perform better. The downside of manually adding a mailbox to the Outlook profile is that this action is PC-specific. If you move to a new PC, you must add the mailbox to the Outlook profile on that PC. By comparison, because Autodiscover provides Outlook with information about automapped mailboxes, Outlook learns about these mailboxes automatically no matter what PC it runs on.
OSTs and NSTs
After manually adding a mailbox to Outlook, you should have the following files in the Microsoft\Outlook folder of %LocalAppData%:
- An OST (offline slave table) file for the primary mailbox. This file stores the offline (slave) copies of items from the server copy of the user’s mailbox. Outlook names the OST file after the account’s user principal name (UPN), so it will be something like Kim.Akers@office365itpros.com.ost.
- An NST (network slave table) file for the primary mailbox. Amongst other data, this file stored offline content (messages and calendar items) for Outlook groups the user belongs to. Outlook groups are Microsoft 365 groups that use email conversations for collaboration. Outlook names the NST using the mailbox’s primary SMTP address, which could differ from the UPN.
- An OST for each mailbox added manually to Outlook.
- An NST for each mailbox added manually to Outlook.
The size of each file reflects the amount of data in the relevant mailboxes and Outlook’s offline synchronization setting. Windows Explorer doesn’t differentiate between OST and NST files and calls them all Outlook Data Files (Figure 2). To see the file type, you must examine file properties.
The information described above is what I see with Outlook for Windows click-to-run (Microsoft 365 apps for enterprise version 2208). The details might vary for different versions, but the concept remains valid.
Making Things Better
There’s no doubt that Microsoft could smoothen how automapping works. They could:
- Alter the portals GUI to allow administrators to choose whether to use automapping when assigning mailbox permissions.
- Add an option to allow an administrator to turn automapping off without forcing removal and reinstatement of the permission (this would probably happen behind the scenes, but a one-click option would be better).
I’m sure Microsoft would argue that the current scheme works well in most cases and that the number of people who don’t want Outlook automapping for mailboxes is minimal. If that’s the case, then the current manual process is acceptable, once you understand how automapping works, its effect on the OST file, and the alternative.
Keep up with the changing world of the Microsoft 365 ecosystem by subscribing to the Office 365 for IT Pros eBook. Monthly updates mean that our subscribers learn about new developments as they happen.