Beruflich Dokumente
Kultur Dokumente
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 main focus is reviewing two types of client
protocol connectivity flow in Exchange 2013/2010 coexistence environment:
Page 2 of 21 | Part 23#23 | ActiveSync and Exchange web service client protocol
connectivity flow in Exchange 2013/2010 coexistence environment | 4/4
Page 3 of 21 | Part 23#23 | ActiveSync and Exchange web service client protocol
connectivity flow in Exchange 2013/2010 coexistence environment | 4/4
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: 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:
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 There is a local Exchange CAS 2010 in the site (the New York site)
3. 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).
4. The CAS2010 will accept the request and forward (Proxy) the ActiveSync client
connection request to the Exchange 2010 Mailbox server (Number 3).
5. Exchange 2010 mailbox server fetch the required user mailbox content and
send back the data to the CAS2010 (Number 4).
6. CAS2010 proxy back the information\data to CAS2013 (Number 5).
Page 4 of 21 | Part 23#23 | ActiveSync and Exchange web service client protocol
connectivity flow in Exchange 2013/2010 coexistence environment | 4/4
Page 5 of 21 | Part 23#23 | ActiveSync and Exchange web service client protocol
connectivity flow in Exchange 2013/2010 coexistence environment | 4/4
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 Los Angles site.
The New York site, doesnt 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).
Note the rest of the process is identical to the steps that we have already
reviewed in Scenario 1: ActiveSync client | Exchange user mailbox on the same
Active Directory site.
Page 6 of 21 | Part 23#23 | ActiveSync and Exchange web service client protocol
connectivity flow in Exchange 2013/2010 coexistence environment | 4/4
Page 7 of 21 | Part 23#23 | ActiveSync and Exchange web service client protocol
connectivity flow in Exchange 2013/2010 coexistence environment | 4/4
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.
Page 8 of 21 | Part 23#23 | ActiveSync and Exchange web service client protocol
connectivity flow in Exchange 2013/2010 coexistence environment | 4/4
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 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
Page 9 of 21 | Part 23#23 | ActiveSync and Exchange web service client protocol
connectivity flow in Exchange 2013/2010 coexistence environment | 4/4
The special charter of this scenario is that the users mailbox, is located on a
different Exchange site and additionally, the destination site is a Public facing
Exchange site
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 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 didnt
understand the redirection message, and that he was instructed to connect
other ActiveSync Exchange servers.
Page 10 of 21 | Part 23#23 | ActiveSync and Exchange web service client protocol
connectivity flow in Exchange 2013/2010 coexistence environment | 4/4
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 is 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.
Its 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.
Page 11 of 21 | Part 23#23 | ActiveSync and Exchange web service client protocol
connectivity flow in Exchange 2013/2010 coexistence environment | 4/4
Page 12 of 21 | Part 23#23 | ActiveSync and Exchange web service client protocol
connectivity flow in Exchange 2013/2010 coexistence environment | 4/4
Additional reading
Page 13 of 21 | Part 23#23 | ActiveSync and Exchange web service client protocol
connectivity flow in Exchange 2013/2010 coexistence environment | 4/4
Page 14 of 21 | Part 23#23 | ActiveSync and Exchange web service client protocol
connectivity flow in Exchange 2013/2010 coexistence environment | 4/4
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 for the question: who is the element the provide Exchange web service
to Exchange 2010 clients, depend on the specific implementation of the namespace
infrastructure.
In case that the Exchange 2010 web services URL address namespace is identical
to the Exchange 2013 web services URL address namespace, the Exchange web
services element that will serve Exchange 2010 clients is the Exchange 2013 CAS.
In case that the Exchange 2010 web services URL address namespace is not
identical to the Exchange 2013 web services URL address namespace, the
Exchange web services element that will serve Exchange 2010 clients is the
Exchange 2010 CAS.
Page 15 of 21 | Part 23#23 | ActiveSync and Exchange web service client protocol
connectivity flow in Exchange 2013/2010 coexistence environment | 4/4
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:
Page 16 of 21 | Part 23#23 | ActiveSync and Exchange web service client protocol
connectivity flow in Exchange 2013/2010 coexistence environment | 4/4
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 is configured in 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, its 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 host name: mail.o365info.com. This host name 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
Page 17 of 21 | Part 23#23 | ActiveSync and Exchange web service client protocol
connectivity flow in Exchange 2013/2010 coexistence environment | 4/4
Page 18 of 21 | Part 23#23 | ActiveSync and Exchange web service client protocol
connectivity flow in Exchange 2013/2010 coexistence environment | 4/4
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 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.
Page 19 of 21 | Part 23#23 | ActiveSync and Exchange web service client protocol
connectivity flow in Exchange 2013/2010 coexistence environment | 4/4
Page 20 of 21 | Part 23#23 | ActiveSync and Exchange web service client protocol
connectivity flow in Exchange 2013/2010 coexistence environment | 4/4
Additional reading
Page 21 of 21 | Part 23#23 | ActiveSync and Exchange web service client protocol
connectivity flow in Exchange 2013/2010 coexistence environment | 4/4