ActiveSync and Exchange web service client protocol connectivity flow in Exchange 2013/2010 coexistence | 4/4 | 23#23

The current article is the fourth article of four articles series, on the subject of: “Exchange 2013/2010 coexistence environment and mail client protocol connectivity flow”. In this article, our primary focus is reviewing two types of client protocol connectivity flow in Exchange 2013/2010 coexistence environment:

• ActiveSync client protocol connectivity flow
• Exchange web services client protocol connectivity flow

To be able to understand the different “Exchange clients” connectivity protocol flow in Exchange 2013/2010 coexistence environment, we will review five types of “relationships” that exist between Exchange 2010 client and the Exchange CAS 2013 server:

• Autodiscover client – protocol connectivity flow (Part 2#4)
• Outlook client – protocol connectivity flow (Part 2#4)
• OWA client – protocol connectivity flow (Part 3#4)
• ActiveSync client – protocol connectivity flow (Part 4#4)
• Exchange web service client – protocol connectivity flow (Part 4#4)

Exchange 2013/2010 coexistence | ActiveSync client protocol connectivity flow

Exchange ActiveSync clients (Mobile clients) are always considered as “external client” because the network infrastructure of the mobile client 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 implemented by using the internal ActiveSync URL address.

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

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

• 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 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:
3. The user mailbox version is: 2010
   • The Exchange 2010 mailbox server that host the user mailbox is located at the New York site
   • There is a local Exchange CAS 2010 in the site (the New York site)
4. CAS2013 will proxy the ActiveSync client request + the ActiveSync user credentials to the CAS2010 in the local site server by using the internal Exchange 2010 CAS ActiveSync URL address (. (Number 2).
5. The CAS2010 will accept the request and “forward” (Proxy) the ActiveSync client connection request to the Exchange 2010 Mailbox server (Number 3).
6. Exchange 2010 mailbox server “fetch” the required user mailbox content and send back the data to the CAS2010 (Number 4).
7. CAS2010 proxy back the information\data to CAS2013 (Number 5).
8. CAS2013 provides the required information to the external ActiveSync client (Number 6).

Scenario 2: mobile (ActiveSync) client | User mailbox located on Los Angles site | Destination site = Intranet site | No local Exchange 2010 CAS

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

• Exchange user type: Exchange 2010 client (Exchange user whom his mailbox hosted on the Exchange 2010 mailbox server).
• Exchange mailbox server location: the Exchange 2010 Mailbox server which hosts the user mailbox, is located on the Los Angles site.
• The New York site, doesn’t have a “local” Exchange 2010 CAS.

Since in our scenario, the Exchange 2010 mailbox is hosted on Exchange 2010 Mailbox server on other sites (Los Angles site) and, since there is no “local Exchange 2010 CAS”, Exchange 2013 CAS will proxy by himself the external mobile client request to the “remote Exchange 2010 CAS” that is located on Los Angles site (Number 2).

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 particular scenario.

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 which should provide 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 hostname 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 underlying 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.

• Exchange user type: Exchange 2010 client (Exchange user whom his mailbox hosted on the Exchange 2010 mailbox server).
• Exchange mailbox server location: the Exchange 2010 Mailbox server which hosts 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”

In previous 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 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 redirects message”.

The problem with the ”451 redirects message” was that – many Mobile (ActiveSync) clients, did not know how to “handle” the redirection message, and the result were: communication failure. In other words, the Mobile (ActiveSync) client didn’t “understand” the redirection message, and that he was “instructed” to connect “other ActiveSync Exchange servers.

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 Mobile (ActiveSync) clients. Instead, when Exchange 2013 CAS recognizes that the ActiveSync mailbox located on another Exchange site, he will Proxy the request “on behalf” of the ActiveSync to the “destination Exchange server.”

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 considers as a Public facing Exchange site (has a Public facing Exchange CAS server).

Theoretically, the New York Public facing Exchange CAS server can send a redirection command to the Mobile (ActiveSync) client, but instead, the New York Exchange 2013 CAS will choose to use the Proxy method.

It’s clear that this approach 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.

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

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.
2. CAS2013 uses the user credentials and performs the Active Directory lookup.
   CAS2013 determines that:
   • The user mailbox version is: 2010
   • The Exchange 2010 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 2010 Mailbox server” (Number 3).
5. The “internal Madrid Exchange 2010 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).

Exchange 2013/2010 coexistence | Exchange web service client protocol connectivity flow

The subject of Exchange web services connectivity flow In Exchange 2013/2010 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 2010 clients.

Is the element is Exchange 2013 CAS that implements the standard Proxy mechanism of proxy, Exchange 2010 clients request to the Exchange 2010 CAS or another scenario in which the Exchange 2010 client connects directly to the Exchange 2010 CAS and asks for a particular Exchange web service.

Just a general note: the most “important Exchange web service client” is the Outlook client. It’s truth that there is 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.

Technically, the “element” that provides the Exchange web service to the Exchange 2010 clients can be Exchange CAS 2010 based server or, Exchange CAS 2013 based server.

The answer to the question: who is the element the provide Exchange web service to Exchange 2010 clients, depend on the particular implementation of the namespace infrastructure.

• In case that the Exchange 2010 web service’s URL address namespace is identical to the Exchange 2013 web service’s URL address namespace, the Exchange web service’s element that will serve Exchange 2010 clients is the Exchange 2013 CAS.
• In case that the Exchange 2010 web service’s URL address namespace is not identical to the Exchange 2013 web service’s URL address namespace, the Exchange web service’s element that will serve Exchange 2010 clients is the Exchange 2010 CAS.

Note – In the current article, we will not get into 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

To simplify the description of the Exchange web services client protocol connectivity flow, we will use the scenario of the “best practice” configuration in which the “element” that will serve as a “focal point” for Exchange 2010 client that requests Exchange web services will be the Exchange 2013 CAS.

The charter of this scenario is that the Exchange 2013 CAS and the Exchange 2010 CAS will use an identical namespace of the Exchange web services.

For example, the URL address that was configured in Exchange 2013 CAS for the Exchange web services is: https://mail.o365info.com/EWS/Exchange.asmx and, the same URL address configured on the Exchange 2010 CAS server for the URL address for Exchange web services.

In this scenario, Exchange 2010 client will address the Exchange 2013 CAS for Exchange web services and the Exchange 2013 CAS will Proxy their request to the Exchange 2010 CAS.

Exchange web service and Autodiscover services

To be able to understand better the implementation of the Exchange web services in an Exchange 2013 coexistence environment, it’s important that we will know of the relationships that exist between the Exchange Autodiscover infrastructure and the Exchange web services infrastructure.

The Exchange web service is “build on” the Autodiscover information that is provided by the Exchange CAS server.
When the Exchange 2010 client address Exchange 2013 CAS and asks for Autodiscover information, the Exchange 2013 CAS will provide the Autodiscover information that includes the URL address of the Exchange web services. For example: https://mail.o365info.com/EWS/Exchange.asmx

The Exchange 2010 client uses this information for locating the Exchange CAS server who will provide him the required Exchange web services. In our scenario, the URL address includes the hostname – mail.o365info.com. This hostname will point the Exchange 2010 client to the Exchange 2013 CAS server.

In the following diagram, we can see an example for the client protocol connectivity flow that described the “full flow” of Exchange 2010 clients.

Phase 1/2 – Autodiscover services

1. Exchange 2010 client, address the Exchange 2013 CAS as an Autodiscover Endpoint.
2. The Autodiscover responds that the CAS2013 “provide” includes the URL address URL address of the Exchange web services: https://mail.o365info.com/EWS/Exchange.asmx

Phase 2/2 – Exchange web services

When the Exchange 2010 client needs a specific web service such as availability service
(Free/Busy time), he will use the URL address that he got from the Autodiscover response: https://mail.o365info.com/EWS/Exchange.asmx
This URL includes the host name: mail.o365info.com that will be “translated” to the IP address of Exchange 2013 CAS.

When the Exchange 2013 CAS gets the Exchange 2010 request for an Exchange web service, he “understands” that the Exchange mail client is Exchange 2010 client and, for this reason, he will “forward” (Proxy) the requires to the Exchange 2010 CAS. The Exchange 2013 CAS addresses the Exchange 2010 CAS that will need to provide the required Exchange web services to the Exchange 2010 client by using the Exchange 2010 CAS FQDN. In our scenario: Excas2010.o365info.com

Scenario 1: Internal/External Exchange web service’s client | User mailbox located on New York site.

Scenario charters: Exchange web service client, need to get a particular Exchange web service.

• Exchange user type: Exchange 2010 client (Exchange user whom his mailbox hosted on the Exchange 2010 mailbox server).
• Exchange mailbox server location: the Exchange 2010 Mailbox server which hosts the user mailbox, is located at the New York site.

The Exchange web service client, protocol connectivity flow, will be implemented as follows:

The preliminary process for the Exchange web services is the Autodiscover process, in which the external Exchange 2010 client gets the Autodiscover information that includes the URL address of the Exchange web service.

1. Exchange web service clients use the following URL address: https://mail.o365info.com/EWS/Exchange.asmx, connect the “New York Public facing Exchange CAS” and provides his user credentials.
2. CAS2013 uses the user credentials and performs the Active Directory lookup. CAS2013 determines that:
   • The user mailbox version is: 2010
   • The Exchange 2010 mailbox server that host the user mailbox is located at the New York site
   • There is a local Exchange CAS 2010 in the site (the New York site)
3. CAS2013 will proxy the Exchange web service client request to the CAS2010 in the local site. The “proxy “process, includes the user credentials that were provided by the Exchange web service user (Number 2).
4. The CAS2010 will accept the request and “forward” (Proxy) the Exchange web service request to the Exchange 2010 Mailbox server (Number 3).
5. Exchange 2010 Mailbox server “reply back” and send the required information to CAS2010 (Number 4).
6. CAS2010 proxy backs the information to CAS2013 (Number 5).
7. CAS2013 provides the required information to the external Exchange web service client (Number 6).