autodiscover and outlook client protocol flow in exchange 2013/2010 coexistence | 21#23

of 16 | Part 21#23 | Autodiscover and Outlook client protocol connectivity flow in

Exchange 2013/2010 coexistence environment | 2/4

Written by Eyal Doron | o365info.com | Copyright © 2012-2015

AUTODISCOVER AND OUTLOOK CLIENT

PROTOCOL CONNECTIVITY FLOW IN

EXCHANGE 2013/2010 COEXISTENCE

ENVIRONMENT | 2/4 | 21#23

The current article is the second article in a series of three articles, which will

dedicate to a detailed review of the client protocol connectivity flow in Exchange

2013/2010 coexistence environment.

http://o365info.com/autodiscover-and-outlook-client-protocol-connectivity-flow-in-exchange-2013-2010-coexistence-environment-24


https://il.linkedin.com/in/eyaldoron1

http://o365info.com/




The second article deals with the following type of client protocol connectivity flow

in Exchange 2013/2010 coexistence environment:

Autodiscover client protocol connectivity flow

Outlook client protocol connectivity flow

Exchange 2013/2010 coexistence |

Autodiscover client protocol connectivity flow

Just a brief review about the Autodiscover infrastructure in an Exchange 2013

coexistence environment and in our specific scenario:

The New York Exchange CAS 2013 will be configured as the Autodiscover Endpoint

for internal + external Exchange clients.

The “Exchange clients” could be: Native Exchange clients (Exchange 2013 clients) or

legacy Exchange clients (Exchange 2010 clients).

All the Exchange clients: New York, Madrid and Los Angles, will start the

Autodiscover process by addressing the “New York Exchange CAS 2013”.

Autodiscover flow in Exchange 2013/2010 CAS coexistence environment |

Highlights

Exchange 2013 CAS server doesn’t “generate” Autodiscover information, but

instead, “delegate” another Exchange CAS server\s to “fulfill” this task. In a

scenario of Exchange client 2010 client that requests Autodiscover information,

the Exchange 2013 CAS will “forward” (Proxy) the request to Exchange 2010 CAS.

In an Exchange 2013/2010 coexistence environment, the element that “deliver”

the Autodiscover information to the Exchange 2010 mail client is the Exchange

2013 CAS.








The element that “generate” the Autodiscover information from the Exchange

2010 client is the Exchange 2010 CAS.

Note – You can read more information about Autodiscover in Exchange 2013

coexistence environment in the following articles:

Exchange 2013 coexistence environment | Autodiscover infrastructure | Part 1/2

Exchange 2013 coexistence environment | Autodiscover infrastructure | Part 2/2

In the next section, we will review three passable Autodiscover scenarios.

Two Autodiscover scenarios of external Exchange 2010 Autodiscover clients and

one scenario of “internal Autodiscover Exchange 2010 client”.

Autodiscover connectivity flow – External client

Scenario 1: Autodiscover client | User mailbox located on New York site.

Scenario charters: an external Exchange 2010 client, need to get Autodiscover

information.

Exchange user type: Exchange 2010 client (Exchange user whom his mailbox is

hosted on the Exchange 2010 mailbox server).

Exchange mailbox server location: the Exchange 2010 Mailbox server who hosts

the user mailbox, is located on the New York site.

The Autodiscover protocol connectivity flow, will be implemented as follows:

1. External Exchange 2010 Autodiscover client, query DNS for an IP address of an

Autodiscover Endpoint by looking for a host named: autodiscover.o365info.com,

Which will be resolved to the IP address of the Public facing Exchange 2013 CAS

server at the New York site.

2. The external Exchange 2010 Autodiscover client, provide his user credentials.

3. CAS2013 uses the user credentials and performs an Active Directory lookup.

4. CAS2013 determines that:

o The user mailbox version is: 2010

o the Exchange 2010 mailbox server that host the user mailbox is located at the

New York site

o The New York site includes a local Exchange CAS 2010

5. CAS2013 will proxy the Autodiscover request to the local Exchange 2010 CAS

(Number 2).





http://o365info.com/exchange-2013-coexistence-environment-autodiscover-infrastructure-part-12

http://o365info.com/exchange-2013-coexistence-environment-autodiscover-infrastructure-part-22




6. CAS2010, will generate the Autodiscover response and send it back to the

CAS2013 server (Number 3).

7. CAS2013 “provide” the Autodiscover response to the External Exchange 2010

Autodiscover client (Number 4).

Scenario 2: Autodiscover client | User mailbox located on Los Angles site |

Destination site = Intranet site | No local Exchange 2010 CAS

Scenario charters: an external Exchange 2010 client, need to get Autodiscover

information.




the user mailbox, is located on the Los Angles site.








The New York site, doesn’t have a “local” Exchange 2010 CAS.

The “New York Public facing Exchange CAS server” will need to forward the

Autodiscover requests to the “Los angles Exchange CAS 2010”, because that in the

current scenario, there is no local Exchange CAS 2010 in the New York site.

The Exchange CAS 2013 will need to “locate” the “Los Angles Exchange CAS 2010”

and proxy for him the Autodiscover request.


1. CAS2013 will proxy the Autodiscover request to the Los Angles Exchange CAS

2010 (Number 2).

2. Los Angles Exchange CAS 2010, will generate the Autodiscover response and

send it back to the New York CAS2013 server (Number 3).








Scenario 3: internal Autodiscover client | User mailbox located on New York

site.

Generally speaking, the “internal Autodiscover protocol connectivity flow” is based

on the same logic, as the logic that was reviewed in the former section, in which we

have reviewed the Autodiscover flow of external Exchange 2010 Autodiscover

clients.

The main differences between the “Autodiscover protocol connectivity flow” in the

internal Exchange infrastructure are:

1. The method which internal Autodiscover client, use for locating the Autodiscover

Endpoint in the internal network, is implemented by query the local Active

Directory for information about available “Autodiscover Endpoints” (Exchange

CAS server\s).

2. Internal versus external Autodiscover Endpoint hostname – in some scenarios,

the host name of the “internal Autodiscover Endpoint” (Exchange 2013 CAS in

our scenario) is different from the host name of the external Autodiscover

Endpoint name (the public name) this configuration described as: disjoint

namespace.

In such a scenario:

o The internal Exchange 2010 client will refer to the “internal Autodiscover

Endpoint” name.

o The Autodiscover information that is provided to the internal Exchange

clients, will include the “internal URL address”, meaning URL address that

includes the “non-public FQDN names” of the Exchange servers and Exchange

web service.

In the following diagram, we can see a standard “internal Autodiscover protocol

connectivity flow” of Exchange 2010 client.

The Exchange 2010 will query the Active Directory (Lookup SCP records in Active

Directory),

Get the name of the available Autodiscover Endpoint (the Exchange 2013 CAS)

Address the Exchange 2013 CAS and ask for Autodiscover information.








Outlook client protocol connectivity flow |

Exchange 2013/2010 coexistence

Before we begin with the description of the Outlook connectivity flow in an

Exchange 2013/2010 coexistence environment, I would like to briefly review the

communication charters of Outlook client and Exchange server.

The client protocol connectivity flow of the Outlook client is based on the concept in

which the Outlook client, needs to locate an Exchange server who configures as

RPC Endpoint.








The information as the host name of the RPC Endpoint and the specific parameters

that are required in the communication with the RPC Endpoint will be provided as

part of the Autodiscover process.

The method in which Outlook client “get the name” of the Exchange CAS

server who will “serve him”.

In the context of “Outlook client communication session”, Outlook client, relates to

Exchange CAS server as an: RPC Endpoint.








Theoretically, we can manually provide Outlook client the name of his “RPC

Endpoint” but in reality, the Outlook client gets the required name of “his RPC

Endpoint” by using the Exchange Autodiscover services.

In the following diagram, we can see that the first step in the communication

channel between Outlook and the Exchange server is the step in which Outlook

addresses the Exchange server as an: Autodiscover Endpoint.

In our scenario, the external Outlook client, “communicates” with the Exchange

server using the host name: autodiscover.o365info.com (Number 1).

After the successful completion of the authentication process, the Exchange server

(the Public facing Exchange 2013 CAS server in our scenario) will provide Outlook

the Autodiscover information, which includes the name (the public FQDN name) of

the “RPC Endpoint” (Number2). For example: mail.o365info.com

In our scenario, the Public facing Exchange 2013 CAS server holds the rule of

Autodiscover Endpoint + “RPC Endpoint”.








In step 2, the external Outlook client, addresses the “RPC Endpoint” by using the

public FQDN: mail.o365info.com (Number 3).

You can read more information about the subject of Outlook connectivity in

Exchange 2013 coexistence environment in the following articles:

Basic concepts of Outlook connectivity in Exchange 2013 coexistence

environment | Part 1/2

Exchange 2013 coexistence environment and Outlook infrastructure | Part 2/2

Outlook flow in Exchange 2013/2010 CAS coexistence environment |

Highlights





http://o365info.com/basic-concepts-of-outlook-connectivity-in-exchange-2013-coexistence-environment-part-12

http://o365info.com/basic-concepts-of-outlook-connectivity-in-exchange-2013-coexistence-environment-part-12

http://o365info.com/exchange-2013-coexistence-environment-and-outlook-infrastructure-part-22




New York and Los Angles external Exchange 2010 Outlook client: locating the

“Public RPC Endpoint” server.

The “New York Public facing Exchange CAS” act as “Public RPC Endpoint” for New

York and Los Angles external Outlook clients

The “Madrid Public facing Exchange CAS” act as “Public RPC Endpoint” for Madrid

Outlook clients

Madrid external Outlook clients, will get the host name of the “Madrid Public RPC

Endpoint” from the Autodiscover information provided by the “New York Public

facing Exchange CAS”.

New York and Los Angles external Exchange 2010 Outlook client: access to the

mailbox

Exchange 2013 CAS will proxy the Exchange 2010 Outlook client requests to the

Exchange 2010 infrastructure (Exchange 2010 CAS). New York Outlook user’s

requests, will be proxy the local Exchange CAS 2010 in New York.

Los Angles Outlook user’s requests, will be proxy the local Exchange CAS 2010 (if

exists) and then, the New York Exchange CAS 2010 will proxy the Outlook client

requests to the “Los Angles Exchange CAS 2010”

Communication channel between “New York Public facing Exchange CAS” and

internal Exchange CAS 2010

Exchange 2013 CAS doesn’t support any more “direct RPC” but instead, only

Outlook Anywhere (RPC over HTTP). The communication channel between the

Outlook client and the Exchange 2013 CAS must be implemented using

RPC\HTTP. The communication channel between Exchange 2013 CAS other

Exchange CAS server, servers, must be implemented using RPC\HTTP.

To enable the “communication channel” between Exchange CAS 2013 server and

Exchange 2010 CAS server, we will need to implement the following steps:

*Enable the Outlook Anywhere service on each of the existing Exchange 2010

CAS servers

*configure the IIS authentication method to use NTLM.

Outlook Anywhere connectivity flow | internal + external Outlook

clients

The “New York Public facing Exchange CAS”, serves as a “focal point” for two types

of “Outlook clients”: external + internal Outlook clients.








To simplify the client protocol connectivity flow description, we will relate only to

the “external Outlook client” but the same logic and protocol flow, is implemented

also to the “internal Outlook client.”

Scenario 1: Outlook client | User mailbox located on New York site.

Scenario charters: an external Exchange 2010 Outlook client, need to get access to

his mailbox






1. Based on the Autodiscover information that he has, the External Exchange 2010

Outlook client looks for an RPC Endpoint server named: mail.o365info.com

(address the “New York Public facing Exchange CAS”).

2. The external Exchange 2010 Outlook client, provide his user credentials.

3. CAS2013 uses the user credentials and performs the Active Directory lookup.

4. CAS2013 determines that:

o The user mailbox version is: 2010

o The Exchange 2010 mailbox server that host the user mailbox is located at the

New York site

o The New York site includes a local Exchange CAS 2010

5. CAS2013 will proxy the Outlook connection request to an Exchange 2010 CAS

(Number 2).

6. The CAS2010 will accept the request and “forward” (Proxy) the Outlook

connection request to the Exchange 2010 Mailbox server (Number 3).

7. Exchange 2010 mailbox server, provides the required user mailbox content to

the CAS2010 (Number 4).

8. CAS2010 proxy back the information to CAS2013 (Number 5).

9. CAS2013 provides the required information to the external Outlook client

(Number 6).








Scenario 2: Outlook client | User mailbox located on Los Angles site |

Destination site = Intranet site | Local Exchange 2010 CAS

Scenario charters: an external Exchange 2010 Outlook client, need to get access to

his mailbox.












The New York site, have a “local” Exchange 2010 CAS.

Since in our scenario, the Exchange 2010 user mailbox, is hosted on Exchange 2010

Mailbox server on other sites (Los Angeles site) and since the local Active Directory

site (New York site) includes a “local Exchange 2010 CAS”, Exchange 2013 CAS will

proxy the request to the local Exchange 2010 CAS (Number 2) which in his turn, will

proxy the request to the “remote Exchange 2010 CAS” that is located at the Los

Angles site (Number 3).

Note – the rest of the process is identical with the steps that we have already

reviewed in -Scenario 1: Outlook client | user mailbox located on New York site.








Additional reading

Enable the Outlook Anywhere service and configure NTLM authentication

Configure Client Access Server Properties

Set-OutlookAnywhere

How to Configure Exchange Server 2010 Outlook Anywhere





http://technet.microsoft.com/en-us/library/bb124503(v=exchg.141).aspx

http://technet.microsoft.com/en-us/library/bb123545(v=exchg.150).aspx

http://exchangeserverpro.com/how-to-configure-exchange-server-2010-outlook-anywhere/




The Exchange 2013 coexistence article series index page





http://o365info.com/the-exchange-2013-coexistence-article-series-index-page

http://o365info.com/exchange-2013-coexistence-environment-and-client-protocol-connectivity-flow-the-prefix

autodiscover and outlook client protocol flow in exchange 2013/2010 coexistence | 21#23

Documents