OWA client protocol connectivity flow in Exchange 2013/2007 coexistence | 3/4 |18#23

of 21 | Part 18#23 |OWA client protocol connectivity flow in Exchange 2013/2007
coexistence environment | 3/4
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
OWA CLIENT PROTOCOL CONNECTIVITY
FLOW IN EXCHANGE 2013/2007
COEXISTENCE ENVIRONMENT | 3/4 | PART
18#23
The current article, is the third article of four articles series, on the subject of:
“Exchange 2013/2007 coexistence environment and mail client protocol
connectivity flow”.
In this article, we will review the client protocol connectivity flow of:
OWA Exchange 2007 clients in an Exchange 2013/2007 coexistence environment.

The current section, is dedicated to the description of the OWA client protocol
connectivity flow in Exchange 2013/2007 coexistence environment.
When reading the description of the different OWA client protocol connectivity
scenarios and the details of each scenario, you might experience a slight headache.
It’s ok, despite the risk of the “slight headache”, I think that it’s worth putting in the
effort, to be able to understand the concept and the logic of the OWA client
protocol connectivity flow in Exchange 2013/2007 coexistence environment.

Two main characteristics of the OWA mail
client that Differentiate him from other
Exchange clients
The client protocol connectivity flow of OWA mail client has two main
characteristics that are different from another mail client such as: Outlook or
ActiveSync mail clients.
1. Exchange 2013/2007 coexistence environment
Compared to most of the client protocol connectivity flow in which the Exchange
CAS 2013 Proxy mail client request to their “legacy Exchange CAS server”, in a
scenario of the Exchange 2007 OWA client, Exchange CAS 2013 will not Proxy the
2007 OWA client connection request but instead, send a redirection command
to the 2007 OWA client.

2. Specifying manually the host name of the Exchange server
Mail clients such as Outlook and ActiveSync, will use the Exchange Autodiscover
services for locating the Exchange server name who will serve them. Regarding
OWA mail client, the difference is that the user will need to manually type the
URL address that includes the FQDN of the Exchange server name. In a scenario
of multiple Public faces Exchange site, OWA mail clients from regional Public
facing Exchange site can choose to use the “primary namespace” as the
Exchange server name or the “regional namespace” as the Exchange server
name. We will discuss this scenario in more details in the section OWA client
protocol connectivity flow in a multiple Public facing Exchange site environment
OWA Mail client – Specifying manually the
host name of the Exchange server
The main difference between the OWA client versus another Exchange mail client
such as Outlook or Mobile (ActiveSync) client is that, most of the time, OWA client
will manually type the URL address of the Exchange server instead getting the
name of the “Exchange server” from the Autodiscover process. In other words, the
OWA client needs to know their Exchange server name versus other Exchange
clients that use the Autodiscover process for “locating for them” the required
Exchange server name.
In case of that “regional OWA user” such as: OWA user whom his mailbox is located
on a “regional Exchange site” (Madrid site in our scenario), OWA user who needs to
access their mailbox, can use one of the following naming convention’s options for
the Exchange server host name:
1. Using the primary namespace – in our scenario, the “primary namespace” that
represents the “New York Public facing Exchange CAS” is: mail.o365info.com
In case that a “Madrid OWA user” use the primary namespace as the Exchange
server name (OWA URL), the “New York Public facing Exchange CAS” recognizes
that the user is a “Madrid OWA users” and redirect him to the “Madrid Public
facing Exchange CAS”.
2. Using the regional namespace – in a scenario of “Madrid OWA user”, the OWA
user can use the regional namespace as the Exchange server name (OWA URL).

For example: europe.mail.o365info.com. In this scenario, the OWA Madrid user
will access ”his Exchange server” directly.
Note – the scenario of: “regional OWA mail client” and the redirection process is not
unique or related only to Exchange 2007 OWA client, but instead, to any Exchange
OWA client that is involved in a scenario of multiple Public facing Exchange site and
regional namespace.
The special charters of Exchange 2007 OWA
Mail client in Exchange 2013/2007 coexistence
environment
The process of serving Exchange 2007 OWA mail clients (Exchange users whom
their mailbox is hosted on Exchange 2007 Mailbox server), is different from the
“other mail protocols” because, Exchange 2013 “doesn’t know” how to proxy the
OWA mail client requests.
Instead, the Exchange CAS 2013 will redirect the “Exchange 2007 OWA mail clients”
to their Exchange 2007 CAS server.
This is the main reason for the using the “legacy namespace”. The “redirection
message”, that the Exchange 2013 CAS server will send to the “Exchange 2007 OWA
mail clients browser” includes the URL address of the Exchange 2007 CAS server
who will be able to “serve” the Exchange 2007 OWA mail client requests.
The URL that the Exchange 2013 CAS server provide includes the FQDN (the “legacy
namespace) that points to the Exchange 2007 CAS server.

The concept of silent redirection and SSO
In the former sections, we have a review two different scenarios in which the
Exchange 2013 CAS will redirect Exchange 2007 clients to their “destination
Exchange CAS server”.
The redirection method that is used by the Exchange 2013 CAS CU2, include two
major improvements that are related to the process of: redirecting OWA mail client.
The 2013 CAS CU2 Improvements are:
1. Silent redirect
2. SSO

Former version of Exchange CAS server and the OWA redirection method
Although the Exchange 2013 CU2 server version implements the “OWA redirection”
process in an improved way, it’s important to emphasize that the “OWA redirection
method”, is not a new Exchange method and that the OWA redirection method was
included in former versions of Exchange server (as far as I know since the Exchange
2007 server version).
In a former version of Exchange server, the OWA redirection method that was
implemented by the Exchange server for “redirecting OWA client” to their Exchange
server, could be described as “passive”.
The “OWA redirection” was implemented by displaying a “message window”, which
was sent by the Exchange server to the OWA client.
The “redirection information” was presented to the OWA user as a “click able link”.
I describe this method as: “passive redirection”, because the only responsibility of
the Exchange server was to display a message with the link to the OWA client.
The user’s responsibility is to:
 “Understand” that the link that was presented in the message, is the link to the
“right Exchange server”
 That he needs to click on the link that will redirect him to his Exchange CAS
server.
Additionally to the user requirement to “understand” that he needs to click on the
link, OWA users, had an experience that can be described as: ”double login”.

The meaning is that: OWA users, had to re provide their user credentials again, to
the “new destination Exchange server“ (the “destination” Exchange 2007 CAS).
Exchange 2013 CAS server version CU2 and the OWA redirection method
Exchange 2013 CAS server version CU2, includes two major features that
significantly improve the “Exchange OWA client” experience:
 A silent redirection (active redirection) – The Exchange 2013 CAS server knows
how to send a redirection “command” to the Exchange 2007 OWA browser, that
will redirect the OWA session to the “new URL address” (the legacy URL address
of the Exchange 2007 CAS server).
 SSO – Exchange 2013 CAS server knows how to “transfer” or “forward” (Proxy) the
OWA user credentials to the “destination” Exchange 2007 CAS server.

The method which Exchange CAS 2013 use for redirecting OWA client described as:
“silent” because, the OWA user is not involved throughout the process. The only
thing that the OWA user “see” is a short flush on his browsers (the redirection
process from the Exchange 2013 CAS OWA login page in the OWA login page from
the destination Exchange server).
The “Exchange 2007 OWA client” is not aware of the complicated redirection
process. From the “Exchange 2007 OWA client” point of view, this process is
transparent.
Note – although we mention the Exchange 2013 CAS method of: silent redirection +
SSO in the context of the Exchange 2007 OWA client, this method is implemented in
any type of Exchange OWA client in a scenario of multiple Public facing Exchange
sites.

Q1: How actually the OWA client silent redirection process is implemented?
A1: The “OWA redirection process”, is implemented by “cooperation” of the
Exchange CAS 2013 and the client browser. Exchange CAS 2013 sends an HTTP
redirection command that includes the “new URL address”. The client browser
accepts the redirection command and addresses the “destination URL address”

OWA connectivity flow | Exchange 2007 client
| Scenarios
Scenario 1: External 2007 OWA client | User mailbox located at the New York
site.
Scenario charters: an external Exchange 2007 OWA client, need to get access to his
mailbox.
 Exchange user type: Exchange 2007 client (Exchange user whom his mailbox is
hosted on the Exchange 2007 mailbox server).
 Exchange mailbox server location: the Exchange 2007 Mailbox server who hosts
the user mailbox, is located on the New York site.
 The New York site includes two public Exchange CAS servers: Exchange 2013 CAS
and Exchange 2007 CAS.

The OWA protocol connectivity flow, will be implemented as follows:
1. The “New York Exchange 2007 OWA client”, type the following URL
addresseshttps://mail.o365info.com/owa
The URL address that the OWA client use, includes the FQDN: mail.o365info.com
which points to the Public facing CAS2013 server in New York site (Number 1).
2. The external OWA client, provide his user credentials.
3. CAS2013 uses the user credentials and performs the Active Directory lookup.
CAS2013 determines that:
o The user mailbox version is: 2007
o That the local site include a Public facing Exchange 2007CAS server
o That the URL address of the Public facing Exchange 2007 CAS server is:
https://legacy.mail.o365info.com/owa
4. The Exchange CAS2013 will implement two different procedures:
1. Initiate silent redirect process – the “New York Public facing Exchange 2013”
sends a redirection command to the “external Exchange 2007 OWA client
browser” that includes the FQDN of the “Public facing Exchange 2007 CAS
server”: legacy.mail.o365info.com (Number 2).
2. Initiate SSO process – the “New York Public facing Exchange 2013”
implements the process of SSO, by forwarding (proxy) the Exchange 2007
OWA user credentials, to the “Public facing Exchange 2007 CAS server”
(Number 8).
5. The “external Exchange 2007 OWA mail client browser, “gets” the redirection
command from the CAS2013 and, starts a new HTTPS session with the ” Public
facing Exchange 2007 CAS server” (Number 3).
6. The Public facing Exchange 2007 CAS server (legacy.mail.o365info.com) will then
facilitate the request and retrieve the necessary data from the Exchange 2007
Mailbox server (Number 5).
7. The Exchange 2007 Mailbox server, provides the required user mailbox content
to the CAS2007 (Number 6).
8. The CAS2007 sends the information to the “external Exchange 2007 OWA client”
(Number 7).

Scenario 2: Exchange 2007 OWA client | User mailbox located at the Los
Angles site.
Scenario charters: an external Exchange 2007 Outlook client, need to access his
mailbox.
Note – To simplify the step’s description, we will relate only to the “external OWA
2007 client” but the same logic and flow are implemented also to the “internal OWA
client”.
 Exchange user type: Exchange 2007 client (Exchange user whom his mailbox is
hosted on the Exchange 2007 mailbox server).

 The Exchange 2007 user mailbox, is hosted on the Los Angles site (the Exchange
2007 Mailbox server located on the Los Angles site).
 The Exchange 2007 Mailbox server who hosts the user mailbox and the Public
facing Exchange 2013 CAS server are not at the same Active Directory site.
 The New York site, have a “local” Exchange 2007 CAS.
In this scenario, the same logic will be maintained. Exchange CAS 2013 server
redirects the Exchange 2007 OWA client to the Public facing Exchange 2007 CAS
server.
The “New York Public facing Exchange 2007 CAS server” authenticates the user,
performs an Active Directory lookup and determines that the user mailbox is
located at the Los Angles site.
 The “New York Public facing Exchange 2007 CAS server” will proxy the request to
the “internal Los Angles Exchange 2007 CAS server” (Number 3).
 Los Angles Exchange 2007 CAS server” will proxy the request to the “Los Angles
Exchange 2007 Mailbox server” (Number 4).

OWA client protocol connectivity flow in a
multiple Public facing Exchange site
environment
In the following section, we will review the OWA client protocol connectivity flow of
an external OWA Madrid user who tries to access his mailbox and use the primary
namespace as the URL address.

When the OWA Madrid user uses the primary namespace
(https://mail.o365info.com/owa), the Host name will be resolved to the IP address of
the “New York Public facing Exchange CAS server”.
When the “New York Public facing Exchange CAS server” recognizes that the user
considers as a “Madrid user” and that – this OWA client should access “his Public
facing Exchange CAS server”, the “New York Public facing Exchange CAS” will
implement a method which described as: silent redirection + SSO.
Note – the method of silent redirection and SSO is not related only to a scenario of
Exchange 2007 OWA client, but, to any other type of external OWA client such as
Exchange 2013 OWA clients.
The external OWA scenarios
In the next section, we will demonstrate OWA flow scenarios in which “OWA Madrid
user” (user that his mailbox is hosted at Madrid site will use the primary namespace
as the URL address: https://mail.o365info.com/owa
In the following diagram, we can see that the Exchange public infrastructure
includes two Public facing Exchange sites: the New York site and the Madrid site.
Each of the Exchange site has a Public facing Exchange CAS server.
 The public name of the “New York Public facing Exchange CAS”
is: mail.o365info.com
 The public name of the “Madrid Public facing Exchange CAS”
is: europe.mail.o365info.com

“Regional OWA users” (Madrid user in our scenario) can choose to use one of the
optional URL address.
The Madrid Public facing Exchange CAS server is represented by a dedicated
namespace (regional namespace): europe.mail.o365info.com
In case that external OWA Madrid user is familiar with the “Madrid regional
namespace”, he can use the URL address: https://europe.mail.o365info.com/owa
The additional option that the OWA Madrid user can use is: using the primary
namespace which will “lead him” to the “New York Public facing Exchange CAS”.
In this case the OWA Madrid user can use the URL
address: https://mail.o365info.com/owa

When the “New York Public facing Exchange CAS” gets the connection request from
the “OWA Madrid user”, he will implement a method was described as: “silent
redirection” which will redirect the OWA Madrid user, to “his Madrid Public facing
Exchange CAS server”.
Scenario 3: OWA client | User mailbox located on the Madrid site | Regional
namespace |destination site = Public facing
Scenario charters: an external Exchange OWA 2007 client, need to access his
mailbox.

 The Exchange 2007 user mailbox, is hosted on the Madrid site (the Exchange
2007 Mailbox server located on the Madrid site).
 The “Madrid Exchange site” considers as: Public facing Exchange site.
 The external OWA user uses the primary namespace as the URL address of the
Exchange server (https://mail.o365info.com/owa).
 The regional namespace that was “allocated” to the Madrid site
is: europe.mail.o365info.com
In the current scenario, an “OWA Madrid user” use the URL address:
https://mail.o365info.com/owa for access his mailbox.
The OWA protocol connectivity flow will be implemented as follows:
1. Madrid Exchange 2007 OWA client, type the following URL
addresseshttps://mail.o365info.com/owa
The FQDN: mail.o365info.com points to the “New York Public facing Exchange
CAS server” (Number 1).
2. The external OWA client, provide his user credentials.
3. CAS2013 uses the user credentials and performs the Active Directory lookup.
CAS2013 determines that:
o The user mailbox version is: 2007
o The Exchange 2007 mailbox server that host the user mailbox, is located at
the Madrid site
o The remote site (Madrid site) is a Public facing Exchange site
o That the “OWA address” of the “Madrid Public facing Exchange CAS server” is:
https://europe.mail.o365info.com/owa
4. The Exchange CAS2013 will implement two different procedures:
1. Initiate silent redirect process – the “New York Public facing Exchange 2013”
sends a redirection command to the “Madrid Exchange 2007 OWA client
browser” that includes the FQDN of the “Europe Exchange 2007 Public facing
Exchange CAS”: europe.mail.o365info.com (Number 2).
2. Initiate SSO process – the “New York Public facing Exchange 2013”
implements the process of SSO, by forwarding (proxy) the Exchange 2007
user credentials, to the “Europe Exchange 2007 Public facing Exchange CAS”
(Number 8).
5. The “Madrid Exchange 2007 OWA mail client browser, “gets” the redirection
command from the CAS2013 and, starts a new HTTPS session with the “Madrid
Exchange 2007 Public facing Exchange CAS” (Number 3).

6. The Madrid Exchange 2007 Public facing Exchange CAS
(europe.mail.o365info.com) will then facilitate the request and retrieve the
necessary data from the Exchange 2007 Mailbox server (Number 5).
7. The Madrid Exchange 2007 Mailbox server, provides the required user mailbox
content to the Madrid CAS2007 (Number 6).
8. The Madrid CAS2007 sends the information to the “external Exchange 2007 OWA
client” (Number7).
Additional reading
Proxying and Redirection

 Understanding Proxying and Redirection
 Exchange 2013 interoperability with legacy Exchange versions
OWA Cross-Site Silent Redirection
 OWA Cross-Site Silent Redirection in Exchange 2007 SP2
 Enabling Silent OWA Redirection for Office 365 Hybrid
 Enabling Silent OWA Redirection for Office 365 Hybrid
 Overview of Exchange Server 2007 CAS Proxying and Redirection
 Outlook Web Access and Exchange 2007, 2003 and 2000 coexistence
 Client Connectivity in an Exchange 2013 Coexistence Environment
 Microsoft Exchange Server 2013 Deployment and Coexistence
The Exchange 2013 coexistence article series index page

OWA client protocol connectivity flow in Exchange 2013/2007 coexistence | 3/4 |18#23

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (18)

Similar to OWA client protocol connectivity flow in Exchange 2013/2007 coexistence | 3/4 |18#23

Similar to OWA client protocol connectivity flow in Exchange 2013/2007 coexistence | 3/4 |18#23 (20)

More from Eyal Doron

More from Eyal Doron (20)

Recently uploaded

Recently uploaded (20)

OWA client protocol connectivity flow in Exchange 2013/2007 coexistence | 3/4 |18#23