activesync and exchange web service client protocol flow in exchange 2013/2007 coexistence 19#23

of 18 | Part 19#23 | ActiveSync and Exchange web service client protocol

connectivity flow in Exchange 2013/2007 coexistence environment | 4/4

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

ACTIVESYNC AND EXCHANGE WEB SERVICE

CLIENT PROTOCOL CONNECTIVITY FLOW IN

EXCHANGE 2013/2007 COEXISTENCE

ENVIRONMENT | 4/4 |PART 19#23

The current article, is the fourth article of four articles series, on the subject of:

“Exchange 2013/2007 coexistence environment and mail client protocol

connectivity flow”.

http://o365info.com/activesync-and-exchange-web-service-client-protocol-connectivity-flow-in-exchange-2013-2007-coexistence-environment-44


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

http://o365info.com/




In this article, our main focus is reviewing two types of client protocol connectivity

flow in Exchange 2013/2007 coexistence environment:

ActiveSync client protocol connectivity flow

Exchange web services client protocol connectivity flow

Exchange 2013/2007 coexistence | ActiveSync

client protocol connectivity flow

Exchange ActiveSync clients (Mobile clients) are always considered as “external

client” because, the network infrastructure of mobile client is based on a public

mobile network. Mobile client (ActiveSync client) will always need to address the

Public facing Exchange CAS server and for this reason, the “connection point”

(Exchange CAS server) that will accept the mobile (ActiveSync) client communication

requests, must be configured as: a “Public facing Exchange CAS server”.








Note – other Exchange clients such as Outlook and OWA, that can connect the

internal (or to the external) Exchange infrastructure.

When the ActiveSync (Mobile) client connects the Public facing Exchange CAS

server, based on the provided user credentials, the Public facing Exchange CAS

server finds out where is the user mailbox is hosted and “route” (Proxy) the

communication request to the internal Exchange infrastructure.

The “internal routing” of the ActiveSync (mobile) client communication request is

implemented by using the internal ActiveSync URL address.

Scenario 1: mobile (ActiveSync) client | User mailbox located on New York

site.

Scenario charters: an ActiveSync Exchange 2007 client, need to access his mailbox.

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

hosted on the Exchange 2007 mailbox server).

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

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





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-19/Exchange-2007-mobile-clients.jpg




Note – the special charter of mobile Exchange 2007 clients in an Exchange 2013

coexistence environment is that the Exchange 2013 CAS will not directly connect

the Exchange 2007 CAS but instead, proxy the Exchange 2007 ActiveSync client

request to Exchange 2013 Mailbox server.

The ActiveSync client protocol connectivity flow, will be implemented as follows:

1. Mobile (ActiveSync) client, connects the “New York Public facing Exchange CAS”

by using the server name: mail.o365info.com and, provides his user credentials.

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

CAS2013 determines that:

o The user mailbox version is: 2007

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

the New York site

o There is a local Exchange CAS 2007 in the site (the New York site)

3. CAS2013 will proxy the ActiveSync client request + the ActiveSync user

credentials to the local Exchange 2013 Mailbox server.

4. Exchange 2013 Mailbox server proxy the ActiveSync client to the local CAS2007

by using the internal Exchange 2007 CAS ActiveSync URL address (Number 3).

5. The CAS2007 will accept the request and “forward” (Proxy) the ActiveSync client

connection request to the Exchange 2007 Mailbox server (Number 4).

6. Exchange 2007 mailbox server “fetch” the required user mailbox content and

send back the data to the CAS2007 (Number 5).

7. CAS2007 proxy back the information\data to Exchange 2013 Mailbox server

(Number 6).

8. Exchange 2013 Mailbox server proxy back the information\data to CAS2013

(Number 7).

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

(Number 8).








Scenario 2: mobile (ActiveSync) client | User mailbox located on Los Angles

site | Destination site = Intranet site





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-19/Exchange-2013-2007-coexistence-ActiveSync-client-Scenario-1-of-3.jpg




Scenario charters: an ActiveSync Exchange 2007 client, need to access his mailbox.




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

The Los Angles site is an Intranet site (non-Public facing Exchange site)


1. Mobile (ActiveSync) client, connects the “New York Public facing Exchange CAS”

by using the server name: mail.o365info.com and, provides his user credentials.




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

the Los Angles site

o There is no local Exchange CAS 2007 in the site (the New York site)

3. CAS2013 will proxy the ActiveSync client request + the ActiveSync user

credentials to the local Exchange 2013 Mailbox server.

4. Exchange 2013 Mailbox server proxy the ActiveSync client to the “Los Angles

Exchange 2007 CAS” by using the internal Los Angles Exchange 2007 ActiveSync

URL address (Number 3).

5. The Los Angles Exchange 2007 CAS will accept the request and “forward” (Proxy)

the ActiveSync client connection request to the Exchange 2007 Mailbox server

(Number 4).

6. Exchange 2007 mailbox server “fetch” the required user mailbox content and

send back the data to the Los Angles Exchange 2007 CAS (Number 5).

7. Los Angles Exchange 2007 CAS proxy back the information\data to Exchange

2013 Mailbox server (Number 6).

8. Exchange 2013 Mailbox server proxy back the information\data to CAS2013

(Number 7).

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

(Number 8).








Scenario 3: mobile (ActiveSync) client | User mailbox located on Madrid site |

Destination site = Public facing Exchange site | Regional namespace

Before we start with the specific details of the “Madrid ActiveSync user” briefly

review the charters of this specific scenario.





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-19/Exchange-2013-2007-coexistence-ActiveSync-client-Scenario-2-of-3.jpg




By default, ActiveSync (Mobile) client will use the Exchange Autodiscover

infrastructure for getting the “server name” that will accept their request. In a

scenario of a “Madrid ActiveSync user”, the name of the Exchange server who

should be provided for the ActiveSync client as part of the Autodiscover process is,

the name of “Madrid Public facing Exchange CAS server”:europe.mail.o365info.com

By default, the preferred method for ActiveSync client is to use the Exchange

Autodiscover services for getting all the required ActiveSync profile settings and the

host name of the Exchange server who will serve as: “ActiveSync server” but, In

some scenarios, ActiveSync client the Autodiscover services are not used and

instead, the mobile user uses a “manual method” in which he provides the

“Exchange server name”.

For example: when a “Madrid ActiveSync user” want to access his mailbox, he can

provide the primary namespace: mail.o365info.com (option A in the diagram) as the

Exchange a1 host name or, use the host name of the “Madrid Public facing

Exchange CAS server”:europe.mail.o365info.com (option B in the diagram)

In case that the “Madrid ActiveSync user” use the primary

namespace: mail.o365info.com, the connection request will be accepted by the “New

York Public facing Exchange CAS server”.

The “New York Public facing Exchange CAS server” will need to know how to

“handles” this request because in our scenario, the ActiveSync user mailbox is

hosted on another Exchange site: the Madrid site.

The basic assumption could be that in this case, the “New York Public facing

Exchange CAS server” will “redirect the “Madrid ActiveSync user” to his Exchange

server but Exchange 2013 CAS will not use the redirection method.

In this scenario, the “New York Public facing Exchange CAS server” will not redirect

the ActiveSync request, but instead, proxy the connection request to the “Madrid

Exchange CAS server”.








Scenario charters: mobile (ActiveSync) client, need to get access to his mailbox.




the user mailbox, is located on the Madrid site.

The Madrid site considers as Public facing Exchange site and the “Madrid Public

facing Exchange CAS server” are published with a regional

namespace: mail.o365info.com

The special charter of this scenario is – that the user’s mailbox, is located on a

different Exchange site and additionally, the destination site is a “Public facing

Exchange site”





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-19/Exchange-2013-2007-coexistence-ActiveSync-client-Scenario-a-of-3-a.jpg




In former versions of Exchange server, in a scenario in which the mobile

(ActiveSync) client connects a Public facing Exchange CAS server and the Exchange

server recognizes that the mobile (ActiveSync) client mailbox is located in a different

Exchange site + the “other Exchange site” considers as: Public facing Exchange site,

the “response” of the Public facing Exchange CAS server was a: redirection message

to the mobile (ActiveSync) client.

The mobile (ActiveSync) client was supposed to accept the “redirection message”

and create a new communication channel with the “other Public facing Exchange

CAS server (the “Madrid Public facing Exchange CAS server” in our scenario).

The method of redirecting mobile (ActiveSync) client was implemented by using a

message that described as: ”451 redirect message”.

The problem with the ”451 redirect message” was that – many ActiveSync clients

(mobile client), did not know how to “digest” the redirection message and the result

were: communication failure of ActiveSync clients.

For this reason, the behavior of Exchange CAS 2013 server is different because, the

Exchange CAS 2013 server will not implement any more the redirection method

(451 redirect message) for ActiveSync clients.





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-19/Mobile-client-that-did-not-know-how-to-handle-451-redirect-message.jpg




In our scenario, the New York Public facing Exchange CAS server “know” that the

user mailbox is located at the Madrid site and additionally, that the Madrid site has

a Public facing Exchange CAS server.

Theoretically, the New York Public facing Exchange CAS server can redirect the

Exchange ActiveSync to this server, but instead, the New York Exchange 2013 CAS

will choose to use the Proxy method.

It’s clear that this method is not efficient from the point of view of the “New York

Public facing Exchange 2013 CAS server” because theoretically, the “Madrid Public

facing Exchange CAS server” should have served the “Madrid ActiveSync (mobile)

client, but using the “Proxy method”, will ensure that the mobile (ActiveSync) client

communication will be successfully completed.


1. Madrid Mobile (ActiveSync) client, connects the “New York Public facing

Exchange CAS” by using the server name: mail.o365info.com and provides his

user credentials.




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

Madrid site

3. CAS2013 will not send a redirection request to the Madrid ActiveSync client, but

instead, proxy the ActiveSync client request + the ActiveSync user credentials to

the “Madrid Public facing Exchange CAS server” by using the external “Madrid

Public facing Exchange CAS server” ActiveSync URL address (Number 2).

4. The “Madrid Public facing Exchange CAS server” will accept the request and

“forward” (Proxy) the ActiveSync client connection request to the “internal

Madrid Exchange 2007 Mailbox server” (Number 3).

5. The “internal Madrid Exchange 2007 Mailbox server” “fetch” the required user

mailbox content and send back the data to the “Madrid Public facing Exchange

CAS server” (Number 4).

6. “Madrid Public facing Exchange CAS server” proxy back the information\data to

“New York Public facing Exchange CAS server” (Number 5).

7. “New York Public facing Exchange CAS server” provides the required information

to the external ActiveSync client (Number 6).








Additional reading

Understanding Proxying and Redirection

Exchange ActiveSync Returned an HTTP 451 Error

How Exchange Server 2007 CAS Proxy & Redirection works for Exchange

ActiveSync





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

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

https://charlesgate86.wordpress.com/2012/01/30/how-exchange-server-2007-cas-proxy-redirection-works-for-exchange-activesync/

https://charlesgate86.wordpress.com/2012/01/30/how-exchange-server-2007-cas-proxy-redirection-works-for-exchange-activesync/

http://o365info.com/wp-content/gallery/exchange-2013-coexistence-19/Exchange-2013-2007-coexistence-ActiveSync-client-Scenario-a-of-3-b.jpg




Exchange 2013/2007 coexistence | Exchange

web service client protocol connectivity flow

The subject of Exchange web services connectivity flow In Exchange 2013/2007

coexistence environment could be a bit confusing because, it’s not clear who is the

“element” that provides the Exchange web services to the Exchange 2007 clients.

The element is – Exchange 2013 CAS that implements the standard Proxy

mechanism of proxy, Exchange 2007 clients request to the Exchange 2007 CAS or

another scenario in which the Exchange 2007 client connects directly to the

Exchange 2007 CAS and asks for specific exchange web services?

Note – In the current article, we will not get into a detailed explanations of this

concept, and if you want a more thorough review, please read the articles:

Exchange web services in an Exchange 2013 coexistence environment | Part 1/2

Exchange web services in an Exchange 2013 coexistence environment | Part 2/2

Just a general note: the most “important Exchange web service client” is the Outlook

client. Its truth that there are other Exchange web service clients, but the Exchange

client that is most dependent on the Exchange web service is: the Outlook mail

client.

For this reason, when we mention the subject of “Exchange web services and client

protocol connectivity flow”, most of the time, the client that we are refereeing is

Outlook.





http://o365info.com/exchange-web-services-in-an-exchange-2013-coexistence-environment-part-12

http://o365info.com/exchange-web-services-in-an-exchange-2013-coexistence-environment-part-22




We can start with a basic rule: in Exchange 2013/2007 coexistence environment

Exchange 2007 CAS is the element that provides Exchange web services to the

Exchange 2007 clients.

The implementation of Exchange web services in Exchange 2013/2007 coexistence

environment, is implemented by using a combination of the Exchange 2013 CAS

Autodiscover services + the Exchange 2007 CAS web services.





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-19/Outlook.jpg




In an Exchange 2013/2007 coexistence environment, the Exchange 2007 clients will

connect the Exchange 2007 CAS using the legacy namespace, based upon the

Autodiscover information that was provided to them by the Exchange 2013 CAS.

Scenario 1: Internal Exchange 2007 client | Exchange 2007 user mailbox

located on New York site.

Scenario charters: an internal Exchange 2007 client, need to get Exchange web

services.

The Exchange 2007 user mailbox, is hosted on the New York site (Exchange 2007

Mailbox server who is located on the New York site).

Scenario charters: an external Exchange 2007 client, need to get Exchange web

services.

1. Internal Exchange clients connect the Exchange 2013 CAS server and asking for

Autodiscover information.


CAS2013 determines that: the user mailbox version is: 2007

3. CAS2013 sent to the Exchange 2007 Autodiscover information that includes the

information on the Exchange web services URL address. The URL address is

based on the Exchange 2007 legacy namespace.

4. The Exchange 2007 client gets the Autodiscover information and saves it for

later use.

5. When the Exchange 2007 needs specific Exchange web services, such as

Availability Service (Free\Busy time) he will contact the Exchange 2007 CAS

server using the Exchange 2007 CAS legacy namespace (Number 3).








Scenario 2: External Exchange web service’s client | Exchange 2007 user

mailbox on the same Active Directory site

Scenario charters: an external Exchange 2007 client, need to get Exchange web

services.

The Exchange 2007 user mailbox, is hosted on the New York site (Exchange 2007

Mailbox server who is located on the New York site).

New York includes two Public facing Exchange CAS server: the “Exchange 2007

CAS Public facing Exchange CAS server” that is published using the public

name: legacy.mail.o365info.com and the “Exchange 2013 CAS Public facing

Exchange CAS server” that is published using the public name:mail.o365info.com





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-19/Exchange-2013-2007-coexistence-Exchange-web-services-client-serving-EWS-clients-1.jpg




The Exchange web services connectivity flow will be implemented as follows:

1. The external Exchange 2007 client, connect CAS2013 server and provide user

credentials.

2. CAS2013 will authenticate the user and perform an Active Directory lookup.

3. CAS2013 determines that: the user mailbox version is 2007 + the user Exchange

Mailbox server (and CAS2007 server) is located is on the same AD site.

4. CAS2013 will proxy the Exchange web service request to the CAS2007 in the local

site (Number 2).

5. The CAS2007 will generate the required information and send it back to the

CAS2013 server (Number 3).

6. CAS2013 “provide” the Exchange web services information to the external

Exchange 2007 client (Number 4).





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-19/Exchange-2013-2007-coexistence-Exchange-web-services-client-serving-EWS-clients-2.jpg




Additional reading

Understanding Proxying and Redirection

Exchange 2013 interoperability with legacy Exchange versions

The Exchange 2013 coexistence article series index page





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

http://vanhybrid.com/2012/10/09/exchange-2013-interoperability-with-legacy-exchange-versions

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

activesync and exchange web service client protocol flow in exchange 2013/2007 coexistence 19#23

Documents