Just came across this simple diagram of MS Exchange client-server protocols and figured I’d share it here. These days there is a bit of a confusion on where each protocol used in Exchange so I decided to try and fill this gap. I will also put it in the context of QMM migrations and describe how it evolved over the years plus point out a difference in permissions assignment model.
I will be trying to keep it simple and not getting deep into Exchange architecture. Basically as far as any client app talking to Exchange, these days it’s mainly either MAPI or EWS (multitude kinds of EWS services!) Of course it could also be SMTP or other type of traffic, or some POP/IMAP connections (if enabled on Exchange server) but in most cases MAPI or EWS is what we will be working with from the migration standpoint.
MAPI
MAPI is core Exchange protocol which was around since the very early days of Exchange and it still here in Exchange 2016 and Outlook 2016, but very different from the way it was designed originally.
- Initial MAPI protocol implementation worked over RPC/TCP calls so probably better way to call it MAPI/RPC over TCP. This protocol is removed starting with Exchange 2013 and it’s where many are confused thinking it means a departure of MAPI protocol itself which is of course far from being true.
- Another very popular MAPI implementation is Outlook Anywhere or MAPI/RPC over HTTP(s) (wrapped into RPC and then into HTTP(s)) which was supported all along by Exchange 2003/2007/2010/2016. The latter (and also the latest!) Exchange version started to deemphasize this protocol (although it still supports it) because yet another one – MAPI/HTTP(s) gained popularity starting with Exchange 2013.
- So MAPI over HTTP(s) just dropped RPC which was in the middle of it and therefore carried some legacy components that dragged its development behind. Now flexible and robust, MAPI over HTTP(s) can work efficiently over any kind of connections – slow or fast.
And finally little bit about permissions. Any client connecting to Exchange via MAPI protocol has to satisfy certain permissions criteria to perform operations inside other mailboxes. And this is where “Full Mailbox Access”, “Receive-As” and “Send-As” permissions come in, providing different level of mailbox access. Here “Full Mailbox Access” and “Receive-As” provide somewhat similar level of rights except “Receive-As” can be set on the entire Mailbox Database and inherited by all the mailboxes on this database which is therefore very often utilized by various application service accounts including migrations. “Full Mailbox Access” is more of the individual level access, mainly because Outlook will automatically map / open all the other mailboxes where user has “Full Mailbox Access” (configurable behaviour and can be disabled). On the top of all that, “Send-As” allows sending Emails from within the mailbox which appear as if the mailbox owner itself sent them and not the account who’s currently logged in.
And finally how this all fits into migration world. All legacy QMM mail migration components prior to Exchange 2013 relied on MAPI calls to migrate mail items. Mail / Calendar sync agents were using MAPI/CDO library (therefore a requirement to install it on each Agent Host and back in the days even had to install directly on Exchange servers) support for which is now fully discontinued starting with Exchange 2016.
EWS
Original MAPI was always a very complex / network “heavy” protocol of interacting with the low level Exchange storage via ROPs (Remote Operations) and therefore was not very network and developer friendly. And while the networking portion was addressed through the evolution of MAPI to the latest implementation of MAPI/HTTP(s), there was still a need for a better protocol to expose/advertise various rich Exchange services to the clients (like Autodiscover / Availability / OWA / Out of Office and more) which is where EWS came to the rescue! Over time it was evolving, providing more and more capabilities which can be used by custom applications including just client level functionalities like composing Email / looking for messages in mailbox, working with the appointments and more of an enterprise level applications like Quest Migration Manager (QMM). From the start it was developed being programmer friendly, cross platform (hence Outlook for MAC is using it per the diagram above). You will probably ask me why Outlook for Windows clients still relies on MAPI when EWS can do the job? Good question 🙂 In fact Outlook does utilize some EWS based services like Availability, OOO and some more, but I think historically in order not to disappoint its clients Microsoft kept MAPI there for variety of Outlook features which I think many of us don’t even know exist and which otherwise would not be available with the first introduction of EWS. Now looking at Outlook client for MAC fully relying on EWS I will not be surprised that there are some long term plans to eventually deemphasize and drop MAPI, but probably not so soon.
Here is list of all EWS types of operations, where for some of them there is a dedicated URL “advertised” to a client by means of Autodiscover service, for example Availability information, OOO and more:
- Availability
- Bulk Transfer (streaming mail items in and out = migrations!)
- Conversations
- Delegate Management
- Exchange Store Search
- Exchange Search
- Federated Sharing
- Folder
- Inbox Rules
- Item
- Mail Tips
- Messaging Records Management
- Message Tracking
- Notification
- Service Configuration
- Synchronization
- Unified Messaging
- User Configuration
- Utility (resolving recipients, DL membership etc.)
What’s important here from the migration standpoint, is that access on EWS level (unlike MAPI with “Receive-As” etc.) is managed by “Application Impersonation” permission which flows through IIS OS component and “plugs” into Exchange architecture on the level different from MAPI. I already blogged about Impersonation earlier but basically it’s a combination of permissions which 1) Allows to connect to specific EWS endpoint 2) Allows to impersonate specific user(s) where impersonate literally means any operation which mailbox owner can perform. Pretty scary right? 🙂
And in terms of QMM the newer MaGE agents were introduced to work with Exchange 2013/2016 Servers via EWS. Therefore service account now needs impersonation permissions although “Receive-As” requirement is still there for Outlook updating component CPUU (Client Profile Updating Utility). And while prior to QMM 8.13 it was still using MAPI Legacy Agents logic for Exchange 2010 access, please take a note of the following change with the version 8.13:
“Since this version by default Exchange Web Services (EWS) protocol is used instead of MAPI for migrations from Exchange 2010 and 2013 using MAgE. That requires changes in account permissions and different throttling policies. See the corresponding Exchange preparation documents for more information.“
