Skip to content

Basic concepts of Outlook connectivity in Exchange 2013 coexistence | Part 1/2 |13#23

Before we dive into the subject of “Outlook client protocol connectivity flow in an Exchange 2013 coexistence environment, it’s important to understand some of the basic concepts of Outlook connectivity and only then, understand the requirements and the individual charters of Outlook connectivity in an Exchange 2013 coexistence environment.

The infrastructure of Outlook client protocol connectivity flow

The standard “Outlook client protocol connectivity flow” is implemented in the following way:

  1. The outlook looks for an “Exchange server” that can connect him to the mailbox. In an Exchange environment, this “element” described as “RPC Endpoint”.
  2. When the Exchange CAS server accepts the Outlook client connection requests, he will look for information about the Exchange mailbox server which hosts the particular user mailbox (by query the Active Directory) and proxy the Outlook client requests to the Exchange mailbox server.

Note: This description describes a very simple scenario, later we will learn that in reality, the client protocol connectivity flow can be much more complicated and involved additional Exchange servers in the process.

Finding the RPC Endpoint and multiple Active Directory sites

In a scenario of multiple Active Directory sites, in case that each of the Active Directory sites includes a “local Exchange CAS server”, Outlook clients try to address the local “RPC Endpoint” (the local Exchange CAS server).

For example – the green outlook user from site 3, will connect the local Exchange CAS server: EXCAS02, the Yellow Outlook user forum site 1, will connect the local Exchange CAS server: EXCAS01 and so on.

Outlook client protocol connectivity flow - internal environment 02

The four things that Outlook needs!

The relationship of Outlook and Exchange CAS server is based on “four thing that Outlook needs” from the Exchange CAS server.

  1. Access to mailbox – the only way that the Outlook mail client has to access the user mailbox is – via the Exchange CAS server.
  2. Outlook profile configuration settings – In theory, there is an option for configuring the Outlook mail profile manually, but in reality, and particularly in an Exchange 2013 environment, the only way of configuring a new Outlook mail profile is by using the “automatic configuration process” that implemented by using the Exchange Autodiscover infrastructure. The Autodiscover process enables Outlook client to locate + connect Exchange CAS server, get the required Autodiscover information and use the Autodiscover information for the necessary configuration settings that needed for creating a new Outlook mail profile.
  3. Exchange web services – the element the “deliver” the Exchange web services to the Outlook client is the Exchange CAS server. In the Exchange 2013 environment, the Exchange Mailbox server is the element the “generate” the Exchange web services and the Exchange CAS 2013 server only “deliver” the information to the Outlook client.
  4. Autodiscover service – the Autodiscover information is the infrastructure for all the “parts” which comprise the relationships between Outlook and Exchange CAS server. Outlook client “consume” the Autodiscover information for building the Outlook mail profile, for getting the required communication setting with Exchange server, for getting information about the available Exchange web services and so on.

Exchange 2013, Outlook client and RPC over HTTP

Exchange 2013 architecture includes revolutionary changes relating to the relationships of Exchange server and his Outlook clients.

In the Exchange 2013 environment, the only way that Outlook client can use for communicating with the Exchange CAS 2013 server is by – using the communication protocol that describes as – Outlook Anywhere (RPC over HTTP). In other words, the use of the Outlook Anywhere (RPC over HTTP) protocol is mandatory!

Since the begging of Exchange, the primary communication protocol between the Outlook client and Exchange server was based on the RPC (Remote Procedure Call) protocol.

Later on, a new standard of communication was developed: RPC over HTTP.
The purpose of this “new standard” was to enable external Outlook client to communicate with the Exchange server from a public network. The new standard (RPC over HTTP), let the Outlook client to “hide” the RPC protocol “inside” the HTTP protocol (if we want to be more precise, HTTPS protocol) because the RPC protocol was not created to function in an optimal way in a public network environment.

Up to now, the “native” communication protocol between the Outlook client and Exchange server was: RPC and the Outlook Anywhere (RPC over HTTP) consider as optional.

The need for using Outlook Anywhere (RPC\HTTP) was a mandatory requirement, only in a scenario of external Outlook client that addresses the Exchange server from a public network.

In the following diagram, we can see that in previous Exchange server versions, the default communication protocol between internal Outlook and Exchange was: Direct RPC.
The option of: “Outlook Anywhere”, was not configured automatically and, in a scenario in which only internal Outlook needs to communicate the Exchange CAS server, there was no need for setting or adding the option of: Outlook Anywhere.

Outlook communication channel with Exchange CAS legacy versions

In the Exchange 2013 environment, the significant architecture change regarding the subject of Outlook connectivity is that the default communication protocol for internal and external Outlook is the Outlook Anywhere protocol.

The exciting news is that in an Exchange 2013 environment, we don’t need to “do nothing” on the client side (Outlook), to be able to “adapt” Outlook for this change because all of these “changes” communicated to an Outlook client via the Exchange Autodiscover process.

Outlook communication channel with Exchange CAS 2013 server

The layer structure of the Outlook and Exchange communication channel

The communication channel between Outlook and Exchange server implemented by a method which I described as: “layer structure”. The meaning of the “layer” concept is that the way the Outlook and Exchange server are communicating is not implemented by using a single protocol but instead, a “collection” or “array” of protocols.

Outlook client, use a set of command that is named: MAPI (Mail application program interface). The MAPI commands, cannot “travel by them self” to the destination (Exchange server) and for this reason, additional protocols to serve as a “transport” that can take the MAPI commands to their destination.

Outlook client can use a different type of “transportation” for getting to his destination. In other words, Outlook can choose from a variety of “Cars” that will “drive” the MAPI command:

  1. Direct RPC
    The option which described as: “direct RPC” is implemented by “packing” the MAPI command and send them over an RPC Channel. Because RPC is not a “pure transportation protocol”, the RPC is using the help of the TCP protocol that will help him to send the packets of the information, to their destination. The option of – direct RPC” is (or was) the default option for an internal Outlook client that needs to access Exchange CAS server.
  2. RPC/HTTP – Outlook Anywhere
    The second methods of communication between the Outlook client and Exchange described as – RPC/HTTP or Outlook Anywhere. “Outlook Anywhere” is the more “updated” term, but booths of the term mean the same. The Outlook Anywhere method uses an additional layer, which “added” to the Outlook communication channel, “under” the RPC layer.
    As mentioned, the RPC protocol is not optimized (to say the least) to work in a public network environment.
    The “additional layer”, is implemented as HTTP protocol and most of the time, we will use the HTTPS protocol instead, to be able to secure the communication channel.
    In previous Exchange versions (Exchange 2007, 2010) the Outlook Anywhere wasn’t configured by default. The “conventional way” for using the Outlook Anywhere was – only in case that we need to enable “external Outlook clients” to communicate with Public facing Exchange CAS server.
  3. MAPI over HTTP
    The method described as – MAPI over HTTP is a new communication channel that can be implemented only in an Exchange 2013 environment. We can relate to this communication channel as a “revolutionary change” because, in this method, there is no use of the famous RPC protocol. Yes, exactly what you hear, the RPC protocol that was “accompanied” Outlook since the begging, was entirely removed.
    The Exchange server version that supports this method is Exchange 2013 (and indeed all future Exchange releases) and, from the “client side” in the current time the only Outlook version that supports the method of: “MAPI over HTTP” is Outlook 2013.

In the following picture, we can see the concept of the “transport protocol” that helps the Outlook client to “forward” the MAPI commands to the Exchange server.

Outlook can “choose” to use different type of “mixtures” such as – Direct RPC, RPC over HTTP, RPC over HTTPS or MAPI over HTTP

The evolution of Outlook communication protocols

Exchange 2013 architecture is quite revolutionary relating the Outlook mail client. In the previous section, we mention the fact that in an Exchange 2013 environment, the mandatory requirement for the Outlook communication protocol is RPC\HTTP.

Other revolutionary changes in the Exchange 2013 architecture are the support a new Outlook communication protocol named: MAPI over HTTP. The simple meaning of this protocol is “full separation” from the good old RPC protocol.

The new Exchange 2013 environment, is marching towards a fully disengaged from the RPC protocol that was existed starting from the dawn of man. Maybe I’m exaggerating a bit, but the RPC protocol served as a key component in the Outlook and Exchange server relationships.

If we want to use a historical point of view, we can relate to the MAPI over HTTP protocol as the last part of the chain or the most advance’s protocols in the evolution of Outlook communication protocols and Exchange server.

Outlook protocol generations

Q1: Why should I care for this information?

Q2: Does the information specify here, relate in any way to the Exchange 2013 coexistence environment?

A1: Because it’s interesting! I know within my heart, that the subject of “Outlook protocol evolution in an Exchange environment” is interesting for me and, very few people in the cosmos, but I still think that this subject is fascinating and very relevant to the people that manage Exchange infrastructures.

A2: The information on the architectural changes in the Exchange CAS 2013 server (mandatory requirement of using Outlook Anywhere) is one that is relevant to Exchange 2013 coexistence environment because, in an Exchange 2013 coexistence environment, we will need to implement configuration updates in the Exchange and the Exchange legacy infrastructure that will support these architectural changes.

Regarding the standard of MAPI\HTTP, this standard is not related in any way to the Exchange 2013 coexistence environment. The purpose of this standard significantly improve the communication channel that exists between the Outlook and Exchange server, but we will not need to implement any changes or updates to the existing Exchange infrastructure.

The pre requirements changes that need to be implemented in the Exchange legacy environment

Before we can answer the question: What are the required changes that need to implement in the Exchange legacy environment?

Let’s briefly review the basic flow concepts of the Outlook and Exchange communication path.

In the Exchange 2013 coexistence environment, Outlook client protocol connectivity flow, consists of two “interfaces”:

  1. Exchange CAS 2013 server and Outlook interface – this is the communication channel between the Outlook client that connects the Exchange 2013 CAS asking him to get access to the user mailbox content.
  2. Exchange CAS 2013 server and legacy Exchange CAS server interface – in an Exchange 2013 coexistence environment, the legacy Exchange client will address the Exchange 2013 CAS which will proxy their requests to the Exchange CAS legacy server such as – Exchange 2007 CAS or Exchange 2010 CAS.
Outlook client protocol connectivity flow consists of two interfaces

1. Exchange CAS 2013 server and Outlook interface | The required adjustments

The good news is that we don’t need to make any changes or updates to the “Outlook client infrastructure” that will “convert” the Outlook standard communications protocols from Direct RPC to Outlook Anywhere (RPC\HTTP). In an Exchange environment, the Exchange CAS server who “serve” Outlook clients use the “Autodiscover mechanism” for: “informing” Outlook clients about the required update.

2. Exchange CAS 2013 server and legacy Exchange CAS server infrastructure | The required adjustments

This is the “tricky” part that will be discussed in more details in the article: Exchange 2013 coexistence environment and the Exchange legacy infrastructure

The second part of the: Outlook client protocol connectivity flow implemented when the Exchange 2013 CAS proxy the Outlook client requests to a legacy Exchange CAS server.

As mentioned, Exchange 2013 CAS supports only RPC\HTTP standard.

The problem (or if we want to use a politely correct word: the challenge) is that in a legacy Exchange environment, the RPC\HTTP is not configured by default on each of the existing Exchange CAS servers.

To be able to enable the communication path between the Exchange 2013 CAS and the legacy Exchange CAS servers, we will need to add the RPC\HTTP support for each of the existing legacy Exchange CAS servers.

Exchange CAS 2013 as a focal point for Outlook clients

In this section, we will focus upon the concept which I described as: Exchange CAS 2013 server, as a focal point for Outlook clients.

In the Exchange 2013 coexistence environment, the Exchange 2013 CAS will take over the responsibility for serving Outlook client requests. The meaning of – Outlook client is: “Native Outlook client” such an Exchange 2013 Outlook client (users whom their mailbox is hosted on Exchange 2013 Mailbox server) and legacy Outlook clients such as – Exchange 2007\2010 Outlook clients.

The meaning of – Exchange CAS 2013 server, as a focal point for Outlook clients, is implemented by “attaching” the primary namespace to the Exchange 2013 CAS.

For example, in case that in the previous Exchange environment, the Exchange CAS 2010 was “published” as the RPC Endpoint using the host name: mail.o365info.com, after we add the Exchange CAS 2013, the host name: mail.o365info.com will be “taken” from the Exchange CAS 2010 and reassigned or “attached” to the “ new Exchange CAS 2013”.

Each of the Outlook client’s communication requests, from all the different Exchange clients (Exchange 2013 or Exchange legacy client such as Outlook 2007, 2010) will be “pointed” to the “new Exchange CAS 2013 server”.

Note: It’s important to emphasize that when we use terms such as: “Outlook legacy client” or Outlook 2007, 2010 client, we don’t relate to the Outlook software version, but instead, to the Exchange Mailbox server who host the mailbox of a particular user.
When we mention the term such as Outlook 2007 client, the Outlook client version could be Outlook 2013, but the user mailbox hosted on Exchange 2007 Mailbox server.

In the following diagram, we can see the concept of – Exchange CAS 2013 serving as a focal point for Outlook clients. We can see that the Exchange CAS 2013 server, “serve” different version of Outlook Exchange clients such as – Exchange 2007, 2010 and 2013 clients. The Outlook client relates to the Exchange CAS 2013 server as a: RPC endpoint.

Exchange 2013 CAS server as RPC Proxy focal point

Outlook client protocol connectivity flow before Exchange 2013 coexistence and after

To be able to understand the essence of the changes in the “Outlook Architecture” in an Exchange 2013 coexistence environment lets briefly review the client protocol connectivity flow changes in a non-Exchange 2013 coexistence environment vs. the flow changes after the implementation of the Exchange 2013 coexistence environment.

For example, in a “native Exchange 2010” environment, the Outlook client protocol connectivity flow is implanted as follows:

Exchange 2010 Outlook clients connect his “RPC Endpoint” (Exchange 2010 CAS) and the Exchange 2010 CAS proxy the Outlook client request to Exchange 2010 Mailbox server.

We can say that the number of “hops” that required for accessing the Exchange client mailbox content is: two.

Exchange 2010 Outlook client - Before Exchange 2013 coexistence environment

In the Exchange 2013 coexistence environment, the same scenario in which Exchange 2010 Outlook client needs to access his mailbox, the client protocol connectivity flow includes additional “hope”.

The Exchange 2010 Outlook client will address his “RPC Endpoint” (Exchange 2013 CAS), the Exchange 2013 CAS will “forward” (Proxy) the request to the Exchange 2010 CAS server, and the Exchange 2010 CAS, will “forward” (Proxy) the request to the Exchange 2010 Mailbox server.

The “additional hope” (number of 2 in the diagram) is the reason for the updates that we will need to implement in an Exchange 2013 coexistence environment.

On the Exchange 2013 coexistence environment, the Outlook client protocol connectivity flow is based on the additional part, which described as – CAS to CAS communication.

To be able to complete the communication path (CAS to CAS communication) between the Exchange 2013 CAS and the Exchange 2010 CAS, the Exchange 2010 CAS will need to be configured to support “Outlook Anywhere” option (the meaning is supporting the RPC/HTTP protocol method). Additionally, both of the parties (Exchange 2010 CAS and Exchange 2010 CAS) will need to support the NTLM authentication protocol that will enable Exchange 2013 CAS to “Proxy” the Outlook user credentials.

Exchange 2010 Outlook client - After Exchange 2013 coexistence environment

Outlook client protocol connectivity flow in an Exchange 2013 coexistence environment | The proxy process

In the Exchange 2013 coexistence environment, requests from “legacy Outlook Exchange clients”, will be accepted by the Exchange CAS 2013 server and then, proxy by the Exchange CAS 2013 server to “legacy Exchange CAS.” The legacy Exchange CAS that will be selected by the Exchange 2013 CAS is an Exchange CAS server from the same version, as the Exchange Mailbox server version that hosts the Outlook client mailbox.

To be able to simplify the Outlook protocol flow description we will relate to an Exchange 2010 Outlook client that needs to access his mailbox, but the same logic will be implemented identically for Exchange 2007 Outlook clients.

For example: when Exchange 2010 Outlook client connects the Exchange CAS 2013 server, the Exchange CAS 2013 server “understand” that the user mailbox hosted on the Exchange Mailbox 2010 server. The Exchange CAS 2013 server will look for Exchange 2010 CAS and when he finds one, proxy the request to the Exchange 2010 CAS server.

To be able to successfully complete the Outlook client protocol connectivity flow that relates to the “CAS to CAS communication channel” between the Exchange CAS 2013 server and the Exchange CAS 2010 server, we will need to verify that the Exchange CAS 2010 server is configured to support Outlook Anywhere + that the Exchange CAS 2010 server support the required authentication protocols.

In the next article Exchange 2013 coexistence environment and Outlook infrastructure | Part 2/2 we will get into more details about the required configuration settings in the Exchange CAS legacy servers.

Exchange CAS 2013 server proxy the Outlook client requests to a legacy Exchange CAS server

Exchange 2013 CAS and Outlook legacy client

In an Exchange 2013 coexistence environment, the Exchange CAS 2013 server, serve as a “smart router” for native + legacy Outlook client’s communication requests. In the following diagram, we can see that the Exchange CAS 2013 server, treat differently, each of the Outlook client type communication requests.

  • Communication requests from Exchange 2013 Outlook users (users whom their mailbox is hosted on Exchange 2013 Mailbox server) will be accepted by the Exchange CAS 2013 server and will be proxy by the Exchange 2013 CAS to the Exchange 2013 Mailbox server.
  • Communication requests from Exchange 2010 Outlook users (users whom their mailbox is hosted on Exchange 2010 Mailbox server) will be accepted by the Exchange CAS 2013 server and will be a proxy by the Exchange 2013 CAS to the Exchange 2010 CAS.
  • Communication requests from Exchange 2007 Outlook users (users whom their mailbox is hosted on Exchange 2007 Mailbox server) will be accepted by the Exchange CAS 2013 server and will be the proxy by the Exchange 2013 CAS to the Exchange 2007 CAS.

Note – the diagram display only “half” of Outlook client protocol connectivity flow because our primary focus is to review the path that the Outlook request need to “go through” until the flow gets to the required user mailbox.
The “full path” includes additional steps such as -the communication path between the legacy Exchange CAS server and the legacy Exchange Mailbox server, the “answer” of the legacy Exchange Mailbox server to the legacy Exchange CAS server and so on.

o365info Team

o365info Team

This article was written by our team of experienced IT architects, consultants, and engineers.

This Post Has 3 Comments

  1. In Exchange 2007 environment, outlook 2007 will use RPC/TCP from internal network and RPC/HTTPS from external networks?

    if yes , then the same for outlook 2010 client in Ex2010 environment?

Leave a Reply

Your email address will not be published. Required fields are marked *