Exchange web services in an Exchange 2013 coexistence | Part 2/2 | 7#23

In the previous 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 implemented in the legacy Exchange web service client: Exchange 2007 client and Exchange 2010 client.

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.

It’s important to emphasize that the Exchange 2007 client “doesn’t 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.

The “referral” to the Exchange CAS 2007 will implement by using the Exchange CAS 2007 URL address that based on the legacy namespace.

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

Step 3 – when the Exchange 2007 client needs to get a particular Exchange web service such as – Availability Service (Free/Busy time) he will use the Autodiscover information that he got in the previous 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.

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 previous section.

The only thing that’s worth a 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 also need to configure as a Public facing Exchange CAS server because the External Exchange 2007 client will address him whenever they need Exchange web services.

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

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.

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 scene 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 lets 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

As we know, the Exchange web service is based in two phases. The first step could describe 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 doesn’t 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 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 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, connectivity protocol flow. The Exchange 2010 client address the “URL address” that he got from the previous 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 particular 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 himself Exchange web service does not provide exchange CAS 2013 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
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 vs. the “physical layer” or the CAS to CAS communication layer.

In the “logic layer hostname” we use the primary namespace for representing the host name of the Exchange CAS 2013. Exchange CAS 2010 will be a hostname 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 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

External vs. internal Exchange clients and Exchange web services

In the following section, I would like to briefly review the concept of external vs. 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 patience and we have done!

Let’s make it simple; technically there is no significant difference between external vs. 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 previous section is implemented in the same way for external and internal Exchange 2010 clients that need Exchange web service.

The first phase 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).

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 provided in the Autodiscover information.

The URL address includes the host name: mail.o365info.com

• 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 vs. internal Exchange 2007 clients.

The Autodiscover information that 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

When the Exchange 2007 client (external or internal) needs to get a particular web service, the Exchange 2007 client will use the URL that 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 unique 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.
• 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”.

An external Exchange client, which is his mailbox 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 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 doesn’t 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.