Beruflich Dokumente
Kultur Dokumente
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!
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.
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, doesnt 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 services 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).
Because the Exchange CAS 2013 server doesnt 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 services client such as: Outlook, which includes the
Exchange web services 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.
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:
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.
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).
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.
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.
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, lets use the following scenario:
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.
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
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).
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 clients passable scenarios
In the following diagram, we can see the three major optional scenarios, for
External Exchange 2007 clients 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 clients 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.
Scenario 2 Exchange 2007 user, which his mailbox is hosted on Exchange 2007
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.
Scenario 3 Exchange 2007 user, which his mailbox is hosted on Exchange 2007
Mailbox server in the Madrid site (a Public facing Exchange site).
At a first glance, this scenario looks a little strange because its 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 clients in an Exchange 2013/2007 coexistence environment.
In the following diagram, we can see the three major optional scenarios, for internal
Exchange 2007 clients in an Exchange 2013/2007 coexistence environment.
Scenario 4 Exchange 2007 user, which his mailbox is hosted on Exchange 2007
Mailbox server at the Madrid site.
The charter of this scenario is a company site that uses the Exchange 2007 legacy
infrastructure and doesnt 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.
Scenario 5 Exchange 2007 user, which his mailbox is hosted on Exchange 2007
Mailbox server at the New York site.