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

of 24 | Part 13#23 | Basic concepts of Outlook connectivity in Exchange 2013
coexistence environment | Part 1/2
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
BASIC CONCEPTS OF OUTLOOK
CONNECTIVITY IN EXCHANGE 2013
COEXISTENCE ENVIRONMENT | 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 special 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 who hosts the
specific 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.
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 is 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 required
configuration settings that are needed for creating a new Outlook mail profile.
3. Exchange web services – the element the “delver” 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 “delver” 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 main 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), enable 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 (RPCHTTP) 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 former 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 configuring or adding the option of: Outlook
Anywhere.

In the Exchange 2013 environment, the major 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 interesting 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” will be communicated to an Outlook client via the
Exchange Autodiscover process.

The layer structure of the Outlook and
Exchange communication channel
The communication channel between Outlook and Exchange server is 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 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 former 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 than 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
totally removed.
The Exchange server version that supports this method is Exchange 2013 (and
certainly 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

Additional reading
 Outlook Connectivity with MAPI over HTTP
 MAPI over HTTP
 Nothing to fear in MAPI over HTTP
 Ambiguous URLs and their effect on Exchange 2010 to Exchange 2013 Migrations
The evolution of Outlook communication
protocols
Exchange 2013 architecture is quite revolutionary relating the Outlook mail client.
In the former section, we mention the fact that in an Exchange 2013 environment,
the mandatory requirement for the Outlook communication protocol is RPCHTTP.

Other revolutionary changes in the Exchange 2013 architecture are the support is 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 was served as a key component in the
Outlook and Exchange server relationships.
If we want to use a chronological point of view, we can relate to the MAPI over HTTP
protocol as the last part in the chain or the most advance’s protocols in the
evolution of Outlook communication protocols and Exchange server.
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: MAPIHTTP, 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 be
implemented 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.

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 form Direct RPC to Outlook Anywhere (RPCHTTP)
because, 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 is implemented
when the Exchange 2013 CAS proxy the Outlook client requests to a legacy
Exchange CAS server.

As mentioned, Exchange 2013 CAS supports only RPCHTTP standard.
The problem (or if we want to use a politely correct word: the challenge) is that in a
legacy Exchange environment, the RPCHTTP 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 RPCHTTP support for
each of the existing legacy Exchange CAS servers.
Additional reading
 The Autodiscover Service and Outlook Providers – how does this stuff work?
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 20072010 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 former 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 specific
user. When we mention the term such as: Outlook 2007 client, the Outlook client
version could be Outlook 2013 but the user mailbox is 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.
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 versus
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 was required for accessing the Exchange
client mailbox content is: two.

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 be implemented 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 configure to support “Outlook Anywhere” option (the meaning is
supporting the RPC/HTTP protocol method) and 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.

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 host 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 is hosted
at the Exchange Mailbox 2010 server. The Exchange CAS 2013 server will look for
Exchange 2010 CAS an 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 configures to support Outlook Anywhere + that the
Exchange CAS 2010 server support the required authentication protocols.
Note – 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 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.
Exchange CAS 2013 server and will be a proxy by the Exchange 2013 CAS to the
Exchange 2010 CAS.
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 main focus is to review the path that the Outlook requites 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
Additional reading
 Exchange Server 2010 to 2013 Migration – Configuring Client Access Servers
 How does Outlook Anywhere work (and not work)?
 Basic vs NTLM Authentication Outlook Anywhere

 outlook anywhere basic vs NTLM authentication explained
 RPC over HTTP Authentication and Security
 Configure Authentication for Outlook Anywhere
 How to Configure Exchange Server 2010 Outlook Anywhere
 Publishing Outlook Anywhere Using NTLM Authentication With Forefront TMG or
Forefront UAG
Video links
 Microsoft Outlook Connectivity: Current and Future
 Outlook Everywhere
 Configure Outlook for Office 365: (01) Configuring Outlook for Office 365
The Exchange 2013 coexistence article series index page

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

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (11)

More from Eyal Doron

More from Eyal Doron (20)

Recently uploaded

Recently uploaded (20)

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