There are a couple of MAPI CDO update that now work with E2013. The most recent is the May 2013 update which can be found here: Microsoft Exchange Server MAPI Client and Collaboration Data Objects 1.2.1 May 2013 Update As Dmitry mentioned, you will need to use ROH though.
As you probably already know, Microsoft reduced the number of server roles in Exchange 2013 to just two in order to “increase simplicity of scale, hardware utilization and failure isolation”:
- Mailbox Server role: which includes the Client Access protocols, Hub Transport service, Mailbox databases and Unified Messaging, and also handles all activity for a given mailbox;
- Client Access Server role: which provides authentication, redirection and proxy services (it doesn't do any data rendering). The Client Access server is a thin and stateless server and there is never anything queued or stored on it. The Client Access server offers the usual client access protocols: HTTP (Outlook Anywhere, ActiveSync and Web Services), POP, IMAP and SMTP, but not MAPI (all MAPI connections are encapsulated using RPC-over-HTTPS)!
Note that the Edge Server is not present in Exchange 2013. This is because its services are now provided by the Client Access Server (although you can still use an Exchange 2007/2010 Edge server as a gateway with your Exchange 2013 environment).
In this new architecture, the Client Access server and the Mailbox server roles are not as dependent on one another as in previous version of Exchange because all processing and activity for mailboxes occurs on the Mailbox server where the active database copy of a mailbox resides. All data rendering and data transformation is performed local to the active database copy, eliminating concerns of version compatibility between the Client Access server and the Mailbox server.
This architecture change brings many other benefits, but in this article we are going to focus solely on how it affects the flow of e-mail messages.
Transport Pipeline
Mail flow takes place through the Transport Pipeline which is a collection of services, connections, components and queues that work together to route messages. With Exchange 2013, the transport pipeline is now made up of 3 different services:
- Front End Transport service, which runs on all Client Access servers, acts as a stateless proxy for all inbound and outbound external SMTP traffic. This service does not inspect message content but it can perform basic e-mail filtering based on connections, domains, senders and recipients. It only communicates with the Transport service on a Mailbox server and does not queue any messages locally;
- Transport service runs on all Mailbox servers and is almost identical to the Hub Transport server role in previous versions of Exchange. It handles all SMTP mail flow for the organization, performs message categorization and content inspection. Unlike previous versions of Exchange, the Transport service never communicates directly with a mailbox database, which is now handled by the Mailbox Transport service. The Transport service routes messages between the Mailbox Transport service, the Transport service and the Front End Transport service. This service does queue messages locally.
- Mailbox Transport service also runs on all Mailbox servers and is made of two separate services:
- The Mailbox Transport Delivery service receives SMTP messages from the Transport service and connects to the mailbox database using an Exchange Remote Procedure Call [RPC] to deliver the message.
- The Mailbox Transport Submission service connects to the mailbox database using RPC to retrieve messages and submits them over SMTP to the Transport service. The Mailbox Transport service also does not queue any messages locally.
As Exchange 2013 no longer has an Edge Server role, e-mail messages from the Internet are received and sent to Exchange using a third-party e-mail gateway, an Exchange 2007/2010 Edge server or through the Exchange 2013 Client Access server as Microsoft intends it to be. In this last scenario, these e-mails enter the Exchange organization through a Receive connector in the Front End Transport service and are then routed to the Transport service on a Mailbox server.
While Exchange 2007/2010 Hub Transport servers were not configured out of the box to accept e-mails from the internet, the new Client Access server comes with a Receive Connector named “Default Frontend <server_name>” that is already configured to allow “Anonymous Users” to connect to it:
Figure 1.1: Default Frontend Receive Connector
As to messages within the organization, they enter the Transport service on a Mailbox server through one of four ways:
- Through the Pickup and Replay directories;
- Through agent submission.
Before putting everything together in a nice diagram, we just need to have a deeper look into the Transport Service, which consists of the following components and processes:
- SMTP Receive: when e-mails are received by the Transport service, content inspection is performed, transport rules are applied and anti-spam/anti-malware inspection is performed (if enabled). If the e-mail is not rejected after passing through SMTP Receive, it is put in the Submission queue;
- Submission is the process of putting e-mails into the actual Submission queue and can happen in three different ways:
- Through the Pickup and Replay directories which now reside on Mailbox servers;
- Categorizer picks up a message at a time from the Submission queue and completes the following steps:
- Recipient Resolution: the recipient's e-mail address is resolved to determine whether the recipient has a mailbox in the Exchange organization or an external e-mail address;
- Routing Resolution: after information regarding the recipient is resolved, the ultimate destination for the message, the route to that destination and the next hop are determined;
- Content Conversion: occurs so that the message is sent in a format that is readable by the recipient by transforming e-mail messages from one format to another format such as MAPI to MIME, UUENCODE to base64 encoded, or for appropriate rendering that is specific to an e-mail client like HTML, rich text format or plain text.
Additionally, mail flow rules are applied. After messages have been categorized, they are put into a delivery queue that is based on the destination of the message (mailbox database, Database Availability Group [DAG], Active Directory [AD] site, AD forest or external domain).
- SMTP Send: depending on the location of the message recipient, the message is routed to:
- the Mailbox Transport service on the same Mailbox server;
- the Mailbox Transport service on a different Mailbox server that is part of the same DAG;
- the Transport service on a Mailbox server in a different DAG, AD site, or AD forest; or
- the Front End Transport service on a Client Access server for delivery to the Internet.
As a picture is worth a thousand words, the following diagram (taken from TechNet) puts everything we talked so far together and shows the relationships between the components in the Exchange 2013 transport pipeline:
Figure 1.2: Exchange 2013 Transport Pipeline
In the next article, we will analyze the flow of an e-mail message and trace its path using the diagram above!
Transport Agents
Twice now we mentioned Transport Agents without going into detail on what these are. Transport Agents, as with previous versions of Exchange, allows administrators to install custom software on an Exchange server in order to process e-mail messages that pass through the transport pipeline. This software might be created by Microsoft, by third-party vendors or by your organization.
Once more Exchange provides extensibility through the Exchange Transport Agents SDK. This SDK is .NET based and allows third-parties to implement the classes SmtpReceiveAgent, RoutingAgent and DeliveryAgent. When compiled against libraries in the SDK, the resulting assemblies are registered with Exchange 2013, which loads the agents and invokes their event handlers during specific stages of SMTP sessions or message processing.
The Transport service fully supports all the predefined classes in the SDK, which means that any transport agents written for Hub Transport server role in Exchange 2010 should work in the Transport service in Exchange 2013. On the other hand, the Front End Transport service only supports the SmtpReceiveAgent class while the Mailbox Transport service does not support the SDK at all, so you can't use any agents in the Mailbox Transport service.
Exchange 2013 comes with built-in transport agents, with most of them invisible and unmanageable by the transport agent cmdlets. However, a few of the built-in transport agents in the Transport service are visible using the Get-TransportAgent cmdlet:
Figure 1.3: Exchange 2013 Transport Agents
Conclusion
So far we looked at how the new design of Exchange 2013 changed the Mail Flow in general.
In the second article of this series, we will see how message routing happens in the new version of Exchange and in the third and final article, we will finish by exploring how each service routes messages and we will track an e-mail to see its exact flow across all the different services.
Let’s take a deeper look into the Exchange 2013 Client Access Server Role through this article.
Even though the client access server roles where very much present in the exchange 2010 and exchange 2007, it has been transformed a lot in the latest exchange release. Exchange 2013 CAS role consists of Client Access front end role (CAFE) and the Front-End Transport (FET). The functions of CAS role has evolved from authentication, proxy/redirection logic, and performed data rendering for various Internet protocol clients in exchange 2007 to an additional data rendering for MAPI in exchange 2010. However, in exchange 2013, CAS does not have any data rendering capability any more. The functions of CAS role is now limited to authenticating and proxy redirection logic, supporting
In Exchange 2013, the Client Access server (CAS) role no longer performs any data rendering functionality. The Client Access server role now only provides authentication and proxy/redirection logic, supporting the client Internet protocols, transport, and Unified Messaging.
Session Affinity
Exchange 2013 does not require session affinity at the load balancer end any more. Taking a closer look at the CAS 2013 functioning will help us understand this better. The following steps happen:
- The namespace to the load balanced virtual IP address is resolved by the client.
- The session is assigned to a particular member of the CAS in the load balancer pool by the load balancer.
- The request is authenticated by the CAS. it then access the Active directory to do a service discovery so that the following information can be furnished:
- The version of the Mailbox
- The location information about the Mailbox like database information, External URL values, etc.
- The version of the Mailbox
- Now a decision is made on if the request is to be redirected to another CAS or proxy the request by itself.
- The CAS now determines which mailbox server is hosting the active copy by initiating an active manager instance.
- Finally, the request is proxied to the active copy mailbox server by the CAS proxies the request to the Mailbox server hosting the active copy.
The CAS proxies the request to the mailbox server hosting the active copy using the same protocol as the one used to connect to the CAS. For example if it is HTTP that is being used by the cllient, then the CAS also utilises HTTP (via SSL).
There is an exception for 6 in case of Telephony requests. Since the telephony device requires establishing its RTP and SIP sessions with the Unified Messaging components directly, instead of proxying the request, the request is redirected to the mailbox server that hosts the active user database copy.
The fact that session affinity is no longer required by the load balancer is mainly facilitated by the step 5. During any session, CAS can now maintain an equal ratio relation with the user’s Mailbox server. Whenever the location of the active database copy changes, the CAS terminates the present session to establish a new session with the server to which the active database copy is moved. All these result in the fact that all sessions running shall be at the Mailbox server hosting the active database copy.
If the incoming request is HTTP, POP or IMAP then the request for authentication is passed through the HTTP payload. If the authentication is Forms-Based Authentication (FBA) then the encryption decryption process becomes complex. FBA cookies use a different key for different servers while encrypting. So when another server receives a request, it cannot decrypt the session. The per server decryption key is no longer used in exchange 2013. The key is now obtained from the certificates installed on the CAS. If same certificates are deployed throughout the CAS, then the decryption is possible.
Proxy vs. Redirection
Now the step 4 we discussed earlier deals with the decision whether the request is to be proxied or redirected. Now the redirection of requests is performed under the following circumstances:
- If the Client is a Telephony Client.
- When the mailbox location for an OWA request is in a distant active directory site and an ExternalURL is associated with the CAS in that particular active directory site then the request is redirected. However if the ExternalURL has the same value as that of the CAS to which the request was originally received then the request is proxied.
- If the mailbox version of OWA is 2007 then the request is redirected.
Outlook Connectivity
In order to increase the stability and the connectivity reliability, exchange 2013 houses an important architectural change. RPC/TCP is no longer an available connectivity solution. Instead, exchange now uses RPC/HTTP (Outlook Anywhere).
To understand this clearly, keep these points in mind
- The CAS role in exchange 2013 is restricted to just authentication and proxy/redirection. The data is no longer processed by the CAS. It only manages the proxying or redirection part using a specific protocol.
- CAS2013 and MBX2013 are not inter dependant on the affinity front nor are they co-located geographically. CAS can perform authentication and proxying from a particular location to a MBX2013 server located in any datacenter. For this reason the communication protocols have been modified from RPC to the protocols that offer tolerance of throughput & latency over the WAN/Internet connections – HTTPS.
- The protocol by which the request is processed is now the protocol which is being used by the mailbox server which is being used by the user’s mailbox as the active directory. This hence eliminates the need to deploy CAS2010, HT2010, and MBX2010 together to avail functionalities. And because of this shift in protocol use, FQDN is no longer required for the RPC endpoint. This is substituted by the mailbox GUID which is unique for an organization. Hence CAS can now detect the location and proxy the request to the correct MBX2013 server not considering of where the database is enabled and stored.
With these architectural changes comes an improved reliability in the connection model. During any session, CAS can now maintain an equal ratio relation with the user’s Mailbox server. The job of decrypting the RPC from HTTP now is rested within the mailbox server responsible for the user’s database.
Further the architectural changes now facilitate internal and external namespaces for Outlook Anywhere, hence avoiding the need to use the external firewall or load balancer to deploy split-brain DNS or deal with all Outlook clients during MAPI connectivity.
Third-Party MAPI Products
With all the architectural changes, third party MAPI products suffer some blows. They now have to leverage RPC/HTTP to connect to CAS in exchange 2013. Users can download MAPI/CDO which support for RPC/HTTP connectivity to facilitate third party MAPI products. However, your third-party vendor should now support RPC/HTTP.
Having said that, it is to be noted that custom MAPI/CDO solutions are supported by the exchange 2013 which may, in future require the third-party products to move to Exchange Web Services (EWS) to access Exchange data.
Namespace Simplification
Another distinct advantage of the improved architecture is the simplification offered to the namespace model. The previous version of exchange (Exchange 2010) used as many as 9 namespaces, namely:
- Primary datacenter Internet protocol namespace
- Secondary datacenter Internet protocol namespace
- Primary datacenter Outlook Web App failback namespace
- Secondary datacenter Outlook Web App failback namespace
- Primary datacenter RPC Client Access namespace
- Secondary datacenter RPC Client Access namespace
- Autodiscover namespace
- Legacy namespace
- Transport namespace (if doing ad-hoc encryption or partner-to-partner encryption)
Since exchange 2013 no longer utilises RPC, the 5th and 6th namespaces are eliminated. Now, since the request is proxied to the active database copy’s mailbox server, the proxy logic spans beyond the active directory site borders. CAS can now proxy requests across multiple mailbox servers and AD sites. This in turn results in the elimination of 3 more namespaces- 2nd, 3rd and 4th.
Transport
All SMTP sessions in the exchange 2013 is handled by the Front-End Transport service. Besides managing the incoming and outgoing SMTP traffic for the organization, it act as a client endpoint for SMTP traffic. It act as a layer 7 proxy and has full access to the protocol conversation. It is stateless, cannot perform message bifurcation and does not have a message queue.
With the front end transport service, the exchange avails a centralized and load balanced egress or ingress terminal, a network protected system, regardless of the kind of client accessing it – sharepoint, POP/IMAP Clients, third-party or even external SMTP systems.
Front end transport service act as a proxy for outgoing messages if the FrontEndProxyEnabled property is set for Send Connecters located on the mailbox server. These messages will look like they are coming from a CAS of exchange 2013 system.
If there is an incoming message to the front end transport service, it should reach an unoccupied transport service on a mailbox service so as to receive the incoming message without considering the type of recipients:
- If the message is to a single recipient, a mailbox server in the delivery group is selected and the one closest in proximity to the active directory site is preferred.
- If there are more than one recipients, the first twenty recipients are used to select the closest to the active directory site.
- The message is transferred to a random mailbox server if the recipient is not specified.
Conclusion
Through this article we have seen that the CAS role in Exchange 2013 removes the requirement of session affinity at load balancer, simplifies the network layer and also achieve namespace simplification and hence deployment flexibility.
Ratish Nair
Microsoft MVP | Exchange Server
Team @MSExchangeGuru