Calendar sharing in Microsoft Outlook is a feature many users rely on daily to manage their manager or team calendars. Microsoft has recently made some big changes to calendar sharing in Outlook and there are some key differences between the old calendar sharing model (which uses MAPI) and the new calendar sharing model (which uses REST). The intent of this blog is to inform IT Messaging Admins of the key differences when considering whether to stay with the move to the new REST model or roll back to the old MAPI model.
Important The shared calendar improvements are automatically enabled for Current Channel and Monthly Enterprise Channel starting with version 2112, and for Semi-Annual Enterprise Channel starting with version 2202. To determine if you are using the new calendar sharing model, see the Microsoft Support articles Calendar sharing in Microsoft 365 and Outlook calendar sharing updates.
The MAPI Model
First, let's talk about the MAPI model. MAPI has been used for calendar sharing in Outlook for a while and has remained largely unchanged for approximately twenty years.
Typically, these are the two most common configuration issues we see with the MAPI model:
- A single manager granting editor rights to multiple delegates (only one editing delegate is supported under the MAPI model)
- Conflicting permissions granted to the delegate for a given manager (example: a delegate was granted both delegate access from the Outlook client and Full Access mailbox permissions from Exchange to their manager's calendar)
These two common configuration issues are documented in the following articles:
- Best practices for organizations when using the Outlook Calendar (microsoft.com)
- Conflicting permission sets when working with shared or delegated folders in Outlook - Microsoft Tec...
The REST Model
The new calendar sharing model based on REST is designed to avoid MAPI issues related to conflicting permissions and multiple editing delegates. This is one of the benefits of the new REST calendar sharing model and may be a reason to use the new model.
That said, there are also some things that you could do in the old calendar sharing model that you cannot do (at least not yet) in the new model, such as the following:
- Adding attachments when responding to a meeting invitation
- Saving drafts of meeting updates in order to send them out later
- Adding the same calendar to multiple calendar groups
- Rely on the offline folder item count to match the server item count. This is due to how the calendar is stored in the delegate's mailbox. For more information, see the Calendar sharing in Microsoft 365 article referenced in the first bullet point below.
For more information on other functional differences and best practices for REST-based calendar sharing, see the following articles:
The Calendar sharing in Microsoft 365 article also provides technical details regarding the architectural differences between the old and new calendar sharing models.
Understanding Some of the Key Differences Between the MAPI and REST Models
This section uses diagrams and a numbered list to supplement existing documentation, highlighting some of the key differences between the old and new calendar sharing architectures.
The numbered list shows how some of the key features differ between the old and new models. Each number correlates to a specific design difference. Numbers ❶ and ❷ appear in both the old and new diagrams to highlight how the architectural differences affect that key function. Number ❸ is completely new for REST.
Note The below diagrams assume that the Outlook client is configured to use Cached Exchange Mode with a copy of the mailbox stored locally in the Outlook Offline Data (.ost) file.
❶ In the old MAPI model, the delegate's Outlook client reads/writes (or synchronizes) directly to the principal's Calendar. As more and more delegates are granted access to the principal's Calendar, the likelihood of having the calendars contain outdated, stale, or out-of-sync data increases. In the new REST model, the service intercepts each delegate's attempt to write to the principal's Calendar. Since the service intercepts and handles all attempts to write to the principal's Calendar, the likelihood of conflicting calendars is greatly reduced.
❷ In the old MAPI model, meeting attendees may receive their meeting invitations before the principal's Calendar is updated. This results in the attendee and principal's calendars being out-of-sync. In the new REST model, only the service is responsible for processing changes to the principal's Calendar, handling and sending the meeting invitations to the attendees. This ensures that the principal's Calendar is updated before the attendees can accept the meeting invitation and add it to their own calendars.
❸ In the new REST model, a copy of the principal's Calendar is stored in the delegate's mailbox. This allows the delegate to view it from any of their Outlook mobile devices.
The two-way gold arrows in the old MAPI model diagram highlight the back and forth read/writes that increase the likelihood of conflicting or out-of-sync calendars. In the new REST model diagram, you can see how the likelihood of out-of-sync calendars is greatly reduced (if not altogether mitigated) by having a one-directional sync, as depicted by the series of gold, counterclockwise circular arrows.
Known Issues
You may see negative performance impact in both sharing models when approaching certain item and folder counts as specified in the following article:
Performance issues for too many items or folders - Outlook | Microsoft Docs
There are other known issues with REST-based calendar sharing that you should be aware of. The Outlook team is currently investigating these issues and will update the below article when more information becomes available:
Known issues with Outlook Desktop Shared Calendar Improvements (microsoft.com)
