Page 1 of 21 | Part 07#23 | Exchange web services in an Exchange 2013 coexistence

environment | Part 2/2

EXCHANGE WEB SERVICES IN AN EXCHANGE

2013 COEXISTENCE ENVIRONMENT | PART
2/2 | 7#23

In the former article Exchange web services in an Exchange 2013 coexistence

environment | Part 1/2, we have already reviewed the concept and the logic of the
Exchange web service in Exchange 2013 coexistence environment but in this article,
I would like to get a closer look at the client protocol connectivity flow that is

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

Page 2 of 21 | Part 07#23 | Exchange web services in an Exchange 2013 coexistence

environment | Part 2/2

implemented in the legacy Exchange web service client: Exchange 2007 client and
Exchange 2010 client.

Article Table of content Exchange web services in an Exchange 2013

coexistence environment | Part 2/2

Exchange web services connectivity flow in

Exchange 2013/2007 coexistence environment
| Internal Exchange 2007 client
In an Exchange 2013/2007 coexistence environment, the Exchange web service for
Exchange 2007 client will be provided by the Exchange CAS 2007 server.
Its important to emphasize that the Exchange 2007 client doesnt know that they
need to address the Exchange CAS 2007 for Exchange web service. Instead, the
Exchange 2007 client gets the information from the Exchange CAS 2013 or if we
want to be more accurate: from the Autodiscover information that is provided by
the Exchange CAS 2013.

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

Page 3 of 21 | Part 07#23 | Exchange web services in an Exchange 2013 coexistence

environment | Part 2/2

The referral to the Exchange CAS 2007 will be implemented by using the Exchange
CAS 2007 URL address that is based on the legacy namespace.
Note in the current article we will be based upon a scenario in which the
Exchange CAS 2007 legacy namespace is: legacy.mail.o365info.com
In the following diagram, we can see an example of the Exchange web services flow
in Exchange 2013/2007 coexistence environment.
Phase 1 in this phase the Exchange 2007 client is related to the Exchange 2013
CAS as an Autodiscover Endpoint. Exchange 2007 client address Exchange 2013 CAS
and ask for Autodiscover information.
Phase 2 Exchange 2013 CAS provides the required Autodiscover information that
includes the URL address of the Exchange 2007 legacy namespace Exchange web
services.
In our scenario, the URL address that Exchange 2013 CAS provides is:
https://legacy.mail.o365info.com/EWS/Exchange.asmx

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

Page 4 of 21 | Part 07#23 | Exchange web services in an Exchange 2013 coexistence

environment | Part 2/2

Phase 3 when the Exchange 2007 client needs to get a specific Exchange web
service such as: Availability Service (Free/Busy time) he will use the Autodiscover
information that he got in the former phase. In our scenario, the Exchange web
service URL address is: https://legacy.mail.o365info.com/EWS/Exchange.asmx
The Exchange 2007 client will look for the IP address of the host named:
legacy.mail.o365info.com and address this host (the Exchange CAS 2007) request the
specific Exchange web service.

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

Page 5 of 21 | Part 07#23 | Exchange web services in an Exchange 2013 coexistence

environment | Part 2/2

Exchange web services connectivity flow in

Exchange 2013/2007 coexistence environment
| External Exchange 2007 client
The client protocol connectivity flow of External Exchange 2007 client that needs to
get an Exchange web service is very similar to the logic of internal Exchange 2007
client that was described in the former section.
The only thing thats worth mention is that in a scenario of External Exchange 2007
client that needs Exchange web service, the Autodiscover information will be
provided by the Public facing Exchange 2013 CAS server and includes information
about the legacy namespace that represent the Exchange CAS 2007.
The Exchange CAS 2007 will need to be configured also as a Public facing Exchange
CAS server because the External Exchange 2007 client will address him whenever
they need Exchange web services.

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

Page 6 of 21 | Part 07#23 | Exchange web services in an Exchange 2013 coexistence

environment | Part 2/2

In the following diagram, we can see that the journey start when the External
Exchange 2007 client addresses the Public Autodiscover
Endpoint: autodiscover.o365info.com
The answer includes URL address which contain the host
name: legacy.mail.o365info.com
When the External Exchange 2007 client needs a specific Exchange web service, he
will try to get the IP address of the host name: legacy.mail.o365info.com and address
him.
The host name: legacy.mail.o365info.com, should be published as a public name and
have a public IP address.

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

Page 7 of 21 | Part 07#23 | Exchange web services in an Exchange 2013 coexistence

environment | Part 2/2

Exchange web services connectivity flow in

Exchange 2013/2010 coexistence environment
| Internal Exchange 2010 client
In a scenario of Exchange 2013/2010 coexistence environment the best practice is
that the Exchange 2010 client will address the Exchange CAS 2013 when they need
an Exchange web service.

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

Page 8 of 21 | Part 07#23 | Exchange web services in an Exchange 2013 coexistence

environment | Part 2/2

The implementation of this logic, could consider as confusing because the

realization of this scenario requires that we will use an identical namespace for the
Exchange web service of: Exchange 2013 web service and the Exchange 2010 web
service.

In a scenario of Identical namespace, we use the main or the primary

namespace for the both of the infrastructures: Exchange 2013 web services +
Exchange 2010 web services
To demonstrate the concept of Exchange web service in an Exchange 2013/2010
coexistence environment lest use the following scenario details:
The organization Exchange infrastructure includes the following Exchange CAS
servers:

Exchange CAS 2013 that is real name is: EXCAS2013.o365info.com

Exchange CAS 2010 that is real name is: EXCAS2010.o365info.com
The primary namespace that is mapped to the Exchange CAS 2013
is: mail.o365info.com
The Exchange web service URL that will be configured at both Exchange CAS servers
(the Exchange CAS 2013 and the Exchange CAS 2010) will be:
https://mail.o365info.com/EWS/Exchange.asmx

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

Page 9 of 21 | Part 07#23 | Exchange web services in an Exchange 2013 coexistence

environment | Part 2/2

As we know, the Exchange web service is based in two phases. The first phase is
could be described as the: Autodiscover phase.
1. Exchange 2010 client address the Exchange CAS 2013 as his: Autodiscover
Endpoint and asking for an Autodiscover information.
2. When the Exchange CAS 2013 gets the request for Autodiscover information, he
queries the Active Directory about the user and finds that the Exchange client is:
Exchange 2010 client. Because Exchange CAS 2013 doesnt provide by himself
Autodiscover services and, because the client is an Exchange 2010 client,
Exchange CAS 2013 will Proxy the request to Exchange CAS 2010.
3. Exchange CAS 2010 generates the required Autodiscover information which
includes the URL address of the Exchange web
service: https://mail.o365info.com/EWS/Exchange.asmx
4. Exchange CAS 2013 deliver the Autodiscover information to the Exchange 2010
client.
Pay attention to the fact that the conversation or the communication channel
between the Exchange CAS 2013 and the Exchange CAS 2010 is implemented by
using the internal or the real host names. For example, when the Exchange CAS
2013 address the Exchange CAS 2010 he looks for a host

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

Page 10 of 21 | Part 07#23 | Exchange web services in an Exchange 2013 coexistence

environment | Part 2/2

named: EXCAS2010.o365info.com and, when the Exchange CAS 2010 sends his
answer, he will refer to the Exchange CAS 2013 as: EXCAS2013.o365info.com

In the second phase of the Exchange web service client protocol connectivity flow.
The Exchange 2010 client address the URL address that he got from the former
phase of the Autodiscover response.
In our scenario, the Exchange web service URL address that the Exchange 2010
client has is: https://mail.o365info.com/EWS/Exchange.asmx
Now, the Exchange 2010 client will need to resolve the host
name: mail.o365info.com to an IP address and address the specific host for
requesting the required Exchange web service.
1. Exchange 2010 client address the host name: mail.o365info.com which is
mapped to the Exchange CAS 2013 server.
2. When the Exchange CAS 2013 gets the request for Autodiscover information, he
queries the Active Directory about the user and finds that the Exchange client is:
Exchange 2010 client. Because Exchange CAS 2013 is not provided by himself
Exchange web service and because the client is an Exchange 2010 client,
Exchange CAS 2013 will Proxy the request to Exchange CAS 2010.
3. Exchange 2010 client accepts the request, generate the required information
and send it back to the Exchange CAS 2013

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

Page 11 of 21 | Part 07#23 | Exchange web services in an Exchange 2013 coexistence

environment | Part 2/2

4. Exchange CAS 2013 provides the required information to the Exchange 2010
client.
Note that from the Exchange 2010 client point of view the element that provides
the required information is the Exchange CAS 2013. The Exchange 2010 client is not
aware of the process that was implemented behind the scenes

Exchange web service in Exchange 2013/2010

coexistence environment the layer concept.
An important in the scenario of Exchange web service in Exchange 2013/2010
coexistence environment is something which I described as: the Layer concept
The meaning of the term layers is that in the Exchange web service flow, we are
using two different layers:
The logic layer versus the physical layer or the CAS to CAS communication layer.

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

Page 12 of 21 | Part 07#23 | Exchange web services in an Exchange 2013 coexistence

environment | Part 2/2

In the logic layer we use the primary namespace for representing the host name
of the Exchange CAS 2013. Exchange CAS 2010 will refer this host name as the
element that can provide the required Exchange web service.
In our scenario, the Exchange web client will address the Exchange CAS 2013 using
the name: mail.o365info.com
In reality, the Exchange CAS 2013 not really provide the Exchange web service but
serve as a messenger or an Intermediary between the Exchange 2010 client and
the Exchange CAS 2010 that is generating and managing the Exchange web service.
When the Exchange CAS 2013 address the Exchange CAS 2010, Exchange CAS 2013
will use the real name of the Exchange CAS 2010. In our
scenario: EXCAS2010.o365info.com
When the Exchange CAS 2010 reply to the Exchange CAS 2013 request, he will
address the Exchange CAS 2013 server using the name: EXCAS2013.o365info.com
This is the physical layer that is used for the process of the CAS to CAS
communication (the communication between Exchange CAS 2013 and the
Exchange CAS 2010).
The Exchange 2010 clients are not aware of this infrastructure, and we can refer to
this infrastructure as a behind-the-scenes infrastructure.

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

Page 13 of 21 | Part 07#23 | Exchange web services in an Exchange 2013 coexistence

environment | Part 2/2

External versus internal Exchange clients and

Exchange web services
In the following section, I would like to briefly review the concept of external versus
internal Exchange web service client.
In this stage, you must be a little tired from the grinding of the different aspects of:
Exchange web services in an Exchange 2013 coexistence environment so a little

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

Page 14 of 21 | Part 07#23 | Exchange web services in an Exchange 2013 coexistence

environment | Part 2/2

patience and we have done!

Lets make it simple, technically there is no major difference between external

versus internal Exchange clients that need Exchange web services.

Exchange 2010 external and internal web

service clients
In the following diagram, we can see that the same logic that we have a review in
the former section is implemented in the same way for external and internal
Exchange 2010 clients that need Exchange web service.
The first phase is implemented when the Exchange 2010 client, asks from the
Exchange 2013 CAS for Autodiscover information. The difference between external
and internal Exchange 2010 clients is the way that they use for locating the
Autodiscover Endpoint (the Exchange 2013 CAS).

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

Page 15 of 21 | Part 07#23 | Exchange web services in an Exchange 2013 coexistence

environment | Part 2/2

Internal Exchange 2010 client will query the local Active Directory for the name of
available Autodiscover Endpoint\s and external 2010 client will query DNS server
for the public IP address of the host: autodiscover.o365info.com
The Autodiscover information that is sent to the external and internal Exchange
2010 clients, will include the URL address of the Exchange web services such as:
https://mail.o365info.com/EWS/Exchange.asmx

When the Exchange 2010 client (external or internal) needs to get a specific web
service, the Exchange 2010 client will use the URL that was provided in the
Autodiscover information.
The URL address includes the host name: mail.o365info.com

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

Page 16 of 21 | Part 07#23 | Exchange web services in an Exchange 2013 coexistence

environment | Part 2/2

When the external Exchange 2010 client looks at the host

name: mail.o365info.com, the name will be resolved to the public IP address of
the Public facing Exchange 2013 CAS server.
When the internal Exchange 2010 client looks for the host
name: mail.o365info.com, the name will be resolved to the private IP address of
the Exchange 2013 CAS.

Exchange 2007 external and internal client

The access to Exchange web service by Exchange 2007 clients, is implemented in
the same way for external versus internal Exchange 2007 clients.
The Autodiscover information that is sent to the external and internal Exchange
2007 clients, will include the URL address of the Exchange web services such as:
https://mail.o365info.com/EWS/Exchange.asmx

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

Page 17 of 21 | Part 07#23 | Exchange web services in an Exchange 2013 coexistence

environment | Part 2/2

When the Exchange 2007 client (external or internal) needs to get a specific web
service, the Exchange 2007 client will use the URL that was provided in the
Autodiscover information.
The URL address includes the host name: legacy.mail.o365info.com

When the external Exchange 2007 client looks for the host
name: legacy.mail.o365info.com, the name will be resolved to the public IP
address of the Public facing Exchange 2007 CAS server.
Note that the Exchange CAS 2007 in addition to the need for implementing public
available for the Exchange 2007 scenario is special because in this environment,
we will need to implement a configuration of two Public facing Exchange CAS
servers and publish the legacy namespace of the Exchange CAS 2007.

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

Page 18 of 21 | Part 07#23 | Exchange web services in an Exchange 2013 coexistence

environment | Part 2/2

When the internal Exchange 2010 client looks for the host
name: legacy.mail.o365info.com, the name will be resolved to the private IP
address of the Exchange 2007 CAS.

Exchange web service | The scenario of

external mail client and regional namespace
The additional scenario of: Exchange web service, that we did not mention, up until
now, is: a scenario of external Exchange client + regional namespace.
The charters of this scenario are as follows:
An Exchange infrastructure that includes two Public facing Exchange sites: Madrid
site and New York site. The public Autodiscover record is pointing to the New York
Public facing Exchange CAS.

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

Page 19 of 21 | Part 07#23 | Exchange web services in an Exchange 2013 coexistence

environment | Part 2/2

An external Exchange client, which is his mailbox is hosted on the Exchange

mailbox server in Madrid site start his journey by relating to the New York Public
facing Exchange CAS server as the Autodiscover Endpoint.
The New York Public facing Exchange CAS server will authenticate the user and
perform an Active Directory lookup.
The New York Public facing Exchange CAS server determines that: the user
Exchange Mailbox server is located on a different AD site and that the other Active
Directory site has a Public availability meaning, the other Exchange site is
represented by a different namespace. In our scenario: europe.mail.o365info.com
In this case, the Autodiscover information that the New York Public facing Exchange
CAS server provides, to the external Exchange client, will include the URL address of
the Madrid Public facing Exchange CAS.
We can refer to this method as logic redirection because the New York Public
facing Exchange CAS server doesnt acutely redirect the external Exchange client,
but instead, provide Autodiscover information that will be used by the external
Exchange client.
In case that the Madrid external Exchange client will need to use Exchange web
service, he will not address the New York Public facing Exchange CAS server, but
instead, he will address the Madrid Public facing Exchange CAS server.

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

Page 20 of 21 | Part 07#23 | Exchange web services in an Exchange 2013 coexistence

environment | Part 2/2

The Exchange 2013 coexistence article series index page

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

Page 21 of 21 | Part 07#23 | Exchange web services in an Exchange 2013 coexistence

environment | Part 2/2

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