client protocol flow in exchange 2013/2007 coexistence | introduction and basic concepts 16#23

of 34 | Part 16#23 | Client protocol connectivity flow in Exchange 2013/2007

coexistence environment | Introduction and basic concepts| 1/4

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

CLIENT PROTOCOL CONNECTIVITY FLOW IN

EXCHANGE 2013/2007 COEXISTENCE

ENVIRONMENT | INTRODUCTION AND BASIC

CONCEPTS| 1/4 | 16#23

The current article, is the first article in a series of four articles, which will dedicate

to a detailed review of the client protocol connectivity flow in

Exchange 2013/2007coexistence environment.

So… get ready to dive in the wonderful world of Exchange 2013 and Exchange 2007

coexistence!

http://o365info.com/client-protocol-connectivity-flow-in-exchange-2013-2007-coexistence-environment-introduction-and-basic-concepts-14


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

http://o365info.com/




To be able to understand the different “Exchange clients” protocol connectivity flow

in Exchange 2013/2007 coexistence environment, we will review five types of

“relationships” that exist between Exchange 2007 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)

General terms that we will be used along the current article series.





http://o365info.com/autodiscover-and-outlook-client-protocol-connectivity-flow-in-exchange-2013-2007-coexistence-environment-24

http://o365info.com/autodiscover-and-outlook-client-protocol-connectivity-flow-in-exchange-2013-2007-coexistence-environment-24

http://o365info.com/owa-client-protocol-connectivity-flow-in-exchange-2013-2007-coexistence-environment-34

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

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




1. Exchange 2007 client – when we mention the term: Exchange 2007 client, the

meaning is: Exchange client that his mailbox is hosted on the Exchange 2007

mailbox server.

2. Exchange CAS 2013, CAS2013 or “New York Public facing Exchange CAS” – When

we mention one of this “names,” we relate to the Exchange 2013 CAS in the

company headquarter site in New York. The Exchange 2013 CAS will serve as a

focal point or starting point in many of the client protocol connectivity flow

scenarios.

Exchange 2013/2007 coexistence environment

& the term legacy namespace

One of the most mysterious concepts in Exchange 2013/2007 coexistence

environment is the term: Legacy namespace.








The term “legacy namespace”, is just a fancy way of describing an additional or

different namespace from the “primary namespace”, which will be assigned to the

existing Exchange 2007 infrastructure, or if we want to be more specific: attached

to the Exchange 2007 CAS.

Only Exchange 2007 client (an Exchange client that their mailbox is hosted on an

Exchange Mailbox server) will use the legacy namespace and only in specific

scenarios.

From the Exchange CAS 2013 server point of view, the “legacy namespace” is just a

way for “referencing” the Exchange 2007 CAS.

The scenarios in which the Exchange 2013 CAS “reference” the Exchange 2007

infrastructure are:

1. Exchange 2007 OWA client

When Exchange OWA 2007 client address Exchange 2013 CAS requests access to

his mailbox (the mailbox which hosted on Exchange 2007 Mailbox server), the

Exchange CAS 2013, doesn’t have the ability to proxy the Exchange 2007 OWA client








requests to the Exchange 2007 CAS. Instead of “forward” (Proxy) the Exchange 2007

OWA client requests, Exchange CAS 2013 sends to the Exchange 2007 OWA client a

– “silent redirect command”, which will redirect the Exchange 2007 OWA client

browser to existing Exchange 2007 CAS. The redirection to the destination

Exchange 2007 CAS, is implemented by using the legacy namespace of the

Exchange 2007 CAS such as: legacy.mail.o365info.com

2. Exchange 2007 web services clients

The second scenario, in which Exchange 2013 CAS uses the Exchange 2007 legacy

namespace is related to the Exchange web services of Exchange 2007 clients.

When Exchange 2007 clients get the Autodiscover information from the Exchange

CAS 2013, the information about the Exchange web services that is provided to the

Exchange 2007 clients, includes URL address that points the Exchange clients, in the

Exchange 2007 CAS infrastructure.

The Exchange web service’s URL address is based on the legacy namespace of the

Exchange 2007 infrastructure.








For example:

Exchange CAS 2013 server provides to Exchange 2007 clients Autodiscover

information that include a URL address such as:

https://legacy.mail.o365info.com/owa

https://legacy.mail.o365info.com/EWS/Exchange.asmx

In the following diagram, we can see that when the Exchange 2007 client asks for

Autodiscover information, the “answer” includes the Exchange web services URL

that “point” to the Exchange 2007 CAS using the FQDN: legacy.mail.o365info.com

When the Exchange 2007 client needs a specific Exchange web service, he will

address directly the Exchange 2007 CAS (“bypass” the Exchange CAS 2013 server).








Exchange 2013/2007 coexistence recap

We can use the next diagram, as a recap for the subject of: Exchange 2013/2007

coexistence and the legacy namespace infrastructure.

Because the Exchange CAS 2013 server doesn’t “know” how to handle Exchange

2007 OWA clients, he will redirect this client to Exchange 2007 CAS, by using the

legacy namespace.

Exchange CAS 2013 server provides Autodiscover information to the Exchange

2007 exchange web service’s client such as: Outlook, which includes the

Exchange web service’s URL of the Exchange 2007 CAS.

In a scenario of Exchange 2013/2007 coexistence, we will need to publish two

Exchange serves: the Exchange CAS 2013 server + Exchange 2007 CAS.








Exchange 2007 client protocol connectivity

flow road map

One of the main charters of Exchange environment, is the “abundance” of a

different mail client protocol, different Exchange services and so on.

To be able to “digest” this complex infrastructure, we need to use some logical

structure that will help us arrange all the different parts.

To clarify the essence of the “relationships”, between the Exchange 2013 CAS server

and his Exchange 2007 clients, we can define three major responsibilities of

Exchange 2013 CAS server to his Exchange 2007 clients (and Exchange 2013 clients).

Note – the “classification” of the relationships between the Exchange 2013 CAS and

“his Exchange 2007 client” is also suitable for describing the relationships of

Exchange 2013 client with other versions of Exchange client such as: Exchange 2013

client, etc.

We can classify the responsibilities of Exchange CAS to his Exchange client into two

major sections:








Section 1: providing access to a user’s mailbox

The most basic and essential service that Exchange 2013 CAS provides to his

Exchange clients (legacy or non-legacy Exchange client) is the ability to get access to

the content of their mailbox.

In an Exchange environment, the only way that Exchange client can use for access

Exchange mailbox content is, by addressing the Exchange CAS server, which will

“handle his request” and “mediate” between the Exchange mail client and his

Exchange Mailbox server (in our scenario, the mailbox that is hosted by Exchange

2007 Mailbox server).

To be more specific about the term: “providing mailbox access”, in an Exchange

2013 coexistence environment, the Exchange CAS server is responsible for

providing mailbox access to three different types of mail clients:

1. Web mail client (OWA)

2. ActiveSync mail client (Mobile)

3. Outlook mail client

Section 2: Autodiscover services

The Autodiscover services

Point Exchange client (provide information) to existing Exchange web services

such as: Free\Busy time and so on.

Provide Outlook client the required configuration setting needed for creating a

new mail profile and for the ongoing communication with Exchange server.

Section 3: Exchange web services

In Exchange 2013/2007 coexistence environment, the element that provides

Exchange web services to Exchange 2007 clients is the Exchange 2007 CAS server.

Exchange 2007 client will “know how to reach” the Exchange 2007 client from the

Autodiscover information that is provided by the Exchange 2013 CAS.








1. Exchange CAS server | Providing Exchange mail client access to their

mailboxes.

Each of the Exchange mail clients, have a unique and specific charter. For this

reason, each of these “mail clients” has different relationships with the Exchange

CAS 2013 or in other words: the client protocol connectivity flow for each of these

Exchange mail clients is implemented differently.








In Exchange 2013/2007 coexistence environment, the “task” of enabling Exchange

2007 client’s access to their mailboxes will be implemented in the following ways:

Outlook + ActiveSync Exchange 2007 clients – in this scenario, Exchange CAS 2013

server will proxy the connection requests to the Exchange 2007 CAS.

OWA Exchange 2007 client – in this scenario, Exchange CAS 2013 will send to the

OWA Exchange 2007 client redirection command, which includes the URL

address of the Exchange 2007 CAS (the URL address based on the legacy

namespace).

OWA Exchange 2007 client

As mentioned, in a scenario of the Exchange 2007 OWA client, Exchange CAS 2013

server will not proxy the requests to Exchange 2007 CAS but instead, silently

redirect the Exchange 2007 OWA client to the Exchange 2007 CAS + sent the

Exchange 2007 OWA user credentials, to the Exchange 2007 CAS. This process

described as: silent redirection + SSO.

Other scenarios in which Exchange CAS 2013 server will redirect the Exchange OWA

client to “other Exchange CAS”, described as: Exchange OWA client and a multiple

Public facing Exchange site environment.

We will review this scenario in more details in the section: OWA client protocol

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










Note – the method of redirecting the OWA client in a scenario of “multiple Public

facing Exchange site environment” is not related only to “Exchange 2007 OWA

client” but to any external Exchange OWA client.

In the following diagram, we can see a summary of the Exchange client protocol

connectivity flow that is implemented in Exchange 2013/2007 coexistence

environment when the Exchange 2007 client requests access to their “Exchange

2007 mailbox”.

Outlook + ActiveSync Exchange 2007 clients will access their mailboxes that are

hosted on the Exchange 2007 mailbox server via the “mediation” of Exchange

CAS 2013 server. In other words, Exchange 2013 CAS will proxy all of the

Exchange 2007 client to the “legacy Exchange infrastructure” (Exchange CAS

2007).

OWA Exchange 2007 clients will access their mailboxes that are hosted on the

Exchange 2007 mailbox server via the “mediation” of Exchange 2007 client. The

Exchange CAS 2013 will redirect OWA Exchange 2007 clients to Exchange CAS

2007, and the “rest of the process” will be maintained by the Exchange CAS 2007.








2. Exchange server as an Autodiscover provider

In an Exchange 2013/2007 coexistence environment, the Exchange CAS 2013 server

act as an “Autodiscover focal point” for all the types of Exchange clients: native

Exchange clients (Exchange 2013) and legacy Exchange (Exchange 2007) clients.

When Exchange 2007 clients address Exchange 2013 CAS, requesting for

Autodiscover information, the Exchange 2013 CAS handles the request by “forward”

(Proxy) the Autodiscover requests, to the Exchange 2013 Mailbox server.

The element that generates the Autodiscover information is the Exchange 2013

Mailbox server.

The element the “physically” provide the Autodiscover information to the

Exchange 2007 clients is, the Exchange 2013 CAS.








To recap:

Exchange 2007 clients will address the Exchange CAS 2013 server when they

need Autodiscover information. In other words, Exchange 2007 clients relate to

the Exchange 2013 CAS as: Autodiscover Endpoint.

Exchange CAS server proxy the requests to Exchange 2013 Mailbox server.

The Exchange 2013 Mailbox server generates the Autodiscover response.

The information (the Autodiscover response) includes URL address that points to

the Exchange 2007 CAS infrastructure (the legacy namespace).

3. Exchange server and Exchange web services

The third part relates to the Exchange web services.

In Exchange 2013/2007 coexistence environment, the Exchange 2013 CAS will not

provide Exchange web services to Exchange 2007 clients, but instead, the Exchange

2007 CAS is the responsibility for providing Exchange web services to Exchange

2007 clients.

Exchange 2007 CAS, will need to provide Exchange web services for:

Internal Exchange 2007 clients.

External Exchange 2007 clients.

Because that Exchange 2007 CAS will need to provide Exchange web services to

External Exchange 2007 clients, we will need to configure the Exchange 2007 CAS as

a: Public facing Exchange CAS server.








In an Exchange 2013/2007 coexistence scenario, we will need to implement an

infrastructure that is based on two Public facing Exchange CAS servers: the

Exchange CAS 2013 + the Exchange 2007 CAS.

Exchange coexistence environment | Scenario

infrastructure description

In the next three articles, we will review a couple of passable scenarios of: Exchange

2007 client protocol connectivity flows in Exchange 2013/2007 coexistence

environment.

The organizational infrastructure that will use for demonstrating the passable

protocol connectivity flow, has the following characters:

Geographical infrastructure

o365info, is a global company that has three sites:

Two sites in the USA and one site in Europe.

1. Public facing Exchange site

The company headquarters site is located in New York, and the additional sites are:

Los Angles and the Madrid site.

New York and the Madrid site are: “Internet facing sites”.








The New York site includes two Public facing Exchange CAS servers: Exchange

2013 Public facing server + Exchange 2007 Public facing server

The Madrid site includes Exchange 2007 Public facing server.

2. Non-Public facing Exchange site

The Los Angles site configured as: intranet site. The meaning is that the “Los Angles

internal Exchange infrastructure is not “exposed” for public Exchange clients.

The Los angles Exchange user does not have the ability the “direct access” their

Exchange infrastructure, but instead, they will need to use the “New York Public

facing Exchange CAS” as a “Mediator” or a “Broker” that will help them to access the

“internal Los Angles” Exchange infrastructure.

In a scenario, in which an “external Los Angles Exchange users” need to access his

mailbox, the user will address the “New York Public facing Exchange CAS” and use

“his help” to get to his mailbox.

The “New York Public facing Exchange CAS” will accept the Los Angles external

Exchange clients and, Proxy these requests to the internal Los Angles Exchange

infrastructure.

Public Exchange infrastructure | The concept

of main\primary Public facing Exchange site |

Autodiscover Endpoint

Although Exchange public infrastructure can be distributed between many Public

facing Exchange sites and use many different namespaces, the “logical

infrastructure” of the Exchange public environment will be based most of the time,

on a model which can be described as a “centralized model”.

The meaning of this “centralized model” concept is that all the Exchange clients, will

start their “journey” by connecting or addressing a specific “focal point” and this

“focal point” will decide how to “promote” the Exchange client request.

In a public Exchange environment, the meaning of “focal point” translates into the

concept of: public Autodiscover Endpoint.

As mentioned, even in a scenario in which the organization infrastructure consists

of multiple Public facing Exchange sites, the Autodiscover Endpoint will point only








to one “element” and the client protocol connectivity flow, will be “determined”,

based upon the information that will be provided by this “primary Autodiscover

Endpoint”.

Note – the descriptive concept of: “primary Public Autodiscover Endpoint” is

implemented most of the time, but, there are other alternatives to this method. For

example, in a modern network environment, there is an option for using GeoDNS

which enable to implement a different that could be described as a “distributed

model” (versus the “standard centralized model).

In a solution that is based on GeoDNS, the AutoDiscover public record such as:

autodiscover.o365info.com, will be pointed to a couple of Public facing Exchange site

at the same time. The element that will “direct” client to the “right Autodiscover

Endpoint” is the GeoDNS server.








To demonstrate the concept of: “primary Public facing Exchange site”, that holds

the role of public Autodiscover Endpoint, let’s use the following scenario:

The “primary Public facing Exchange CAS” and Autodiscover services

An organization that has four Public facing Exchange sites. Although there are four

Exchange sites with “Public availability “and, although each site has a: Public facing

Exchange CAS server, only one site will be considered a “primary Public facing

Exchange site”. In our scenario the Autodiscover








record: autodiscover.o365info.com is pointing to the Public facing Exchange CAS

server in site 1.

In the following diagram, we can see that external Exchange clients from all the

different Exchange sites, start the communication process with the Public facing

Exchange CAS server in site 1. Because the public Autodiscover record is “mapped”

to the IP address of the Public facing Exchange CAS server from site 1.

In case that the external Exchange client “belong” to site 1, the Public facing

Exchange CAS server sends Autodiscover information that includes information

about public Exchange resources from site 1.

In case that the external Exchange client “belong” to site 2, the Public facing

Exchange CAS server sends Autodiscover information that includes information

about public Exchange resources from site 2 and so on.

The “primary Public facing Exchange CAS” and access to mailbox data services

In a scenario that the external Exchange client needs access to his mailbox, the

Public facing Exchange CAS server from site 1 that serves until now, as: “public

Autodiscover Endpoint”, start to act as a “Smart Router” that handles the Exchange

client requests for mailbox access.

Scenario 1: in case that the “Exchange client from site 2” is an: Outlook client, the

external Outlook client will contact the “public representative” of “his site” such as

the Public facing Exchange CAS server of site 2 (based upon the Autodiscover

information that he got in the former phase).

Scenario 2:: In case that the external Exchange client “belong” to site 1 + In case

that the external Exchange client is Exchange 2007 OWA client, the Public facing

Exchange CAS server will redirect the Exchange 2007 OWA client to the Public facing

Exchange 2007 CAS server.

In case that the external Exchange client “belong” to site 2, there are a couple of

passable scenarios.

Scenario 1: in case that the “Exchange client form site 2” is an Outlook client, the

external Exchange client will connect himself with the “public representative” of “his








site” such as the Public facing Exchange CAS server of site 2 (based upon the

Autodiscover information that he got in the former phase).

Scenario 2: in case that the “Exchange client form site 2” is ActiveSync client, the

“New York Public facing Exchange CAS” will Proxy the client request to the “Madrid

Public facing Exchange CAS”

Scenario 3: in case that the “Exchange client form site 2” is OWA client, the “New

York Public facing Exchange CAS” will send a redirection command to the OWA

client that will redirect the OWA client browser to the “Madrid Public facing

Exchange CAS”.

In the following diagram, we can see the process in which the “New York Public

facing

Exchange CAS” accepts the external Exchange client communication request and,

based upon the type and the Exchange CAS server location, decide how to handle

the request.








Organization Namespace and legacy Exchange

CAS 2007 infrastructure

In an Exchange 2013/2007 coexistence environment, we can relate to a couple of

“namespace infrastructures”:








1. External\Public namespace infrastructure – this is the namespace that will be

used for publishing Exchange hosts who have Public availability (can be accessed

by external Exchange clients)

2. Primary namespace infrastructure – the “translation” of the “primary concept” is

the Exchange CAS server who will serve as a “focal Autodiscover Endpoint”

3. Internal namespace infrastructure – this is the namespace infrastructure that is

“not exposed” to the public network and can be used only by the internal

Exchange client. The internal Exchange namespace could be different from the

external namespace this scenario described as: disjoint namespace.

In our specific scenario, the internal and the external namespaces are identical.

4. Legacy namespace infrastructure – the namespace that is “allocated” to the

legacy Exchange CAS 2007 infrastructure.

5. Regional namespace infrastructure – a dedicated namespace that will be

allocated to each of the Public facing Exchange CAS server who serves as a

“representative” of a specific Public facing Exchange site.

In our scenario, we will be based on three namespaces:

Primary namespace – the primary namespace points to the “Exchange 2013 New

York Public facing Exchange CAS server”








Legacy namespace – the legacy namespace points to the “Exchange 2007 New

York Public facing Exchange CAS server”

Regional namespace – the regional namespace, points to the “Exchange 2007

Madrid Public facing Exchange CAS server”

Before the implementation of the Exchange 2013 coexistence environment, the

representative of the “New York Public facing Exchange site” was Exchange CAS

2007. After the implementation of the Exchange 2013 coexistence environment,

which includes: adding Exchange 2013 servers to the company headquarter site

(New York site), the Exchange CAS 2013, will replace the “former” Exchange CAS

2007 that was configured as the Public facing Exchange CAS server.

In our scenario, the primary namespace will be “attached” to the “New York Public

facing Exchange 2013 CAS server”

The Exchange public infrastructure will include the following public DNS records:

1. Primary namespace that includes two DNS records that point to the “New York

Public facing Exchange CAS server”:

2. Autodiscover record: autodiscover.o365info.com

3. FQDN name for all the rest of the Exchange services: mail.o365info.com

4. Legacy namespace that includes one record that will point to the “Exchange

2007 Public facing Exchange CAS server”

5. FQDN name for all the rest of the Exchange services: legacy.mail.o365info.com

6. Regional namespace – The Madrid Public facing Exchange site will continue to

use Exchange CAS 2007 as a Public facing Exchange CAS server. The “Madrid

Public facing Exchange 20007 CAS server” published by using the public DNS

records:

7. Regional namespace record: europe.mail.o365info.com








Exchange 2013 CAS as a starting point and as

a “Smart router” for external Exchange clients

In an Exchange public environment, the Public facing Exchange CAS server who acts

as the Autodiscover Endpoint for an external Exchange client, holds a very essential

part in the Exchange client protocol connectivity flow.








Phase 1: Exchange 2013 CAS as central Autodiscover Endpoint

Because the Exchange 2013 CAS configured as the Autodiscover Endpoint, all the

“Exchange client flows” will start from this specific Exchange server,

All the external Exchange clients, will start their Initial communication process with

the “New York Public facing Exchange CAS” by relating to the “New York Public

facing Exchange CAS” as the source of information or in more technical words:

Autodiscover Endpoint.

The same “Autodiscover logic” is implemented also to toward internal Exchange

client and two different types of Exchange client such as: Exchange 2007 clients and

Exchange 2013 clients.

The information that the “New York Public facing Exchange CAS” will provide to the

external Exchange client and the continuation of the client protocol connectivity

flow, will depend on the physical location of the external Exchange client mailbox.

Phase 2: Exchange 2013 as a “Smart Router”

The second “Title” of the Exchange 2013 CAS after he fulfils his job as a “central

Autodiscover Endpoint” is to serve as a “Smart Router”, that will handle the external

Exchange mail client requests and, based on the unique charters of the scenario,

choose the best “next step”.








In the following diagram, we can see an example of the different methods, which

the Exchange 2013 CAS can choose when he gets a “connection\service requests”

from external and internal Exchange 2007 clients.

The Exchange 2013 CAS can choose one of the following methods for serving the

Exchange clients:

1. Exchange 2013 CAS can choose to proxy the request to: a local Exchange 2007

CAS such as in a scenario that Exchange client 2007 Outlook and ActiveSync

need access to their mailbox (Number1).

2. Exchange 2013 CAS can choose the proxy to the request to: “remote Exchange

2007 CAS” that is located on a different Active Directory site. This operation

described as: cross site proxy (Number2 + 3).

3. Exchange 2013 CAS can choose a combination” of methods such as: send a

redirection command to the external OWA client + Proxy the user credentials to

Exchange 2007 CAS, in a scenario of an OWA client and regional namespace

(Number 4).

4. Exchange 2013 CAS can choose to proxy the request to Exchange 2013 Mailbox

server in a scenario of Exchange 2007 client Autodiscover request (Number 5).

5. Exchange 2013 CAS can choose a combination” of methods such as: send a

redirection command to the Exchange client 2007 OWA client + Proxy the user

credentials to Exchange 2007 CAS by using a legacy namespace (Number 6).








Client protocol connectivity flow | Scenario’s

matrix

One of the most confusing subjects of Exchange 2013/2007 coexistence

environment, is something that I describe as: “client protocol connectivity flows the

scenario’s matrix infrastructure”








I use the term: ”matrix” because, in a complex Exchange environment, the number

of the client protocol connectivity flow scenarios could be huge.

To be able to make it more “digestible”, we can reduce the optional client protocol

connectivity flow scenario, into to six major scenarios.

The “six major scenarios” can be divided into two groups:

1. External Exchange 2007 client’s passable scenarios

In the following diagram, we can see the three major optional scenarios, for

External Exchange 2007 client’s in an Exchange 2013/2007 coexistence

environment.

The common denominator for all the different scenarios, is that the “journey” of the

Exchange 2007 clients, begins at the Public facing Exchange CAS server of New York

site.








The rest of the flow, depends upon the location of the Exchange 2007 Mailbox

server who hosts the user mailbox.








Scenario 1 – Exchange 2007 user, which his mailbox is hosted on Exchange 2007

Mailbox server at the New York site.

The “New York Public facing Exchange CAS server” will handle the external

Exchange 2007 client’s request, based upon the protocol that they use.

Outlook and ActiveSync external Exchange 2007 client requests will be proxy to

the internal Exchange 2007 CAS.

OWA external Exchange 2007 client requests will be redirected to the Exchange

2007 CAS Public facing Exchange CAS server.









Mailbox server in Los Angles site (non-Public facing Exchange site).

Because there is no option for a “direct connection” to the Exchange server in Los

Angles site, the Public facing Exchange CAS server from the New York site, will

accept the Exchange 2007 client request and forward (Proxy) the request to the

“nearest Exchange 2007 CAS server”.

In our scenario, the “nearest Exchange 2007 CAS server” is located in the same

Active Directory as the Exchange CAS 2013 server.


Mailbox server in the Madrid site (a Public facing Exchange site).

At a first glance, this scenario looks a little strange because it’s not obvious why the

“Madrid Exchange 2007 client” connects the Public facing Exchange 2013 CAS server

in New York site, instead of connecting “his Madrid Exchange CAS server”.

The answer is that the “New York Public facing Exchange CAS” act as a public

Autodiscover Endpoint.

The Exchange clients are not “aware” to their physical location. The element that

will enable them access to their mailbox or provide them an “instruction” how to

get to their destination, meaning the Public facing Exchange CAS server who could

serve them is the “New York Public facing Exchange CAS”.

When a “Madrid external Exchange client” address the “New York Public facing

Exchange CAS” as an Autodiscover Endpoint, the “New York Public facing Exchange

CAS” recognizes that the user mailbox is hosted on Madrid site and sends him

Autodiscover response that includes the public name of the Madrid Public facing

Exchange CAS server: europe.mail.o365info.com

2. Internal Exchange 2007 clients

In the following table, we can see the three major optional scenarios, for internal

Exchange 2007 client’s in an Exchange 2013/2007 coexistence environment.








In the following diagram, we can see the three major optional scenarios, for internal

Exchange 2007 client’s in an Exchange 2013/2007 coexistence environment.


Mailbox server at the Madrid site.

The charter of this scenario is a company site that uses the Exchange 2007 legacy

infrastructure and doesn’t include Exchange 2013 servers.








For the “Madrid Exchange 2007 clients”, the client protocol connectivity flow is

implemented as a “combination” of the Exchange 2013 infrastructure and the local

Exchange 2007 infrastructure.

The Autodiscover service will be provided by the Exchange 2013 CAS (the

Exchange 2013 CAS in the New York headquarter site).

Exchange 2007 mail clients: Outlook and ActiveSync, will access their “Exchange

2007 mailboxes” via local Madrid Exchange 2007 CAS.

Web services for Exchange 2007 clients, such as Outlook, will be provided by the

local Madrid Exchange 2007 CAS.


Mailbox server at the New York site.

The Autodiscover service will be provided by the Exchange 2013 CAS.

New York Exchange 2007 mail client such as: Outlook, ActiveSync and OWA will

access their “Exchange 2007 mailboxes” via local Exchange 2013 CAS that will

proxy their requests to the local Exchange CAS 2007.

Web services for Exchange 2007 clients, such as Outlook, will be provided by the

local New York Exchange 2013 CAS.


Mailbox server at the Madrid site.

This scenario looks identical to “Scenario 4” but the main difference is that the

Exchange 2007 client is physically located at the New York site.

When the Exchange 2007 client connects the Exchange CAS 2013 server in New

York site, the Exchange CAS 2013 server recognizes that the user is an Exchange

2007 client and that his Exchange 2007 Mailbox server is located on the Madrid site.

The Exchange CAS 2013 server will proxy the Exchange 2007 client to the “nearest

Exchange 2007 CAS”. In our scenario, the Exchange 2007 CAS that is located in New

York site and the “New York Exchange 2007 CAS”, will proxy the request to the

“Madrid Exchange 2007 CAS”








The Exchange 2013 coexistence article series index page





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

client protocol flow in exchange 2013/2007 coexistence | introduction and basic concepts 16#23

Documents