OWA Client Protocol Connectivity Flow in Exchange 2013/2010 Coexistence - 3/4 - 22#23

Page 1 of 16 | Part 22#23 | OWA client protocol connectivity flow in Exchange 2013/2010
coexistence environment | 3/4
OWA CLIENT PROTOCOL CONNECTIVITY

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

coexistence OWA connectivity flow
The general concept of the Exchange 2010 OWA client protocol connectivity flow in
Exchange 2013/2010 coexistence environment is based on a similar flow concept of
other Exchange 2010 clients such as Outlook and ActiveSync clients.
The client protocol connectivity flow logic will be based on the following flow:
1. Exchange 2010 OWA client addresses the Exchange CAS 2013
2. Exchange CAS 2013 recognizes that the OWA client is an Exchange 2010 client.
3. Exchange CAS 2013 Proxy the Exchange 2010 OWA client to Exchange CAS 2010
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 conventions 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 2010 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 external OWA scenarios

In the current article, we will demonstrate the client protocol connectivity flow of
two OWA users: New York OWA user (user that his mailbox is hosted at the New
York site) and OWA Madrid user (user whom his mailbox is hosted at Madrid site).
Booth of this OWA client 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 addresses.
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 1: external 2010 OWA client | User mailbox located at the New York
site.
Scenario charters: an external Exchange 2010 OWA client, need to get access to his
mailbox.
Exchange user type: Exchange 2010 client (Exchange user whom his mailbox is
hosted on the Exchange 2010 mailbox server).
Exchange mailbox server location: the Exchange 2010 Mailbox server who hosts
the user mailbox, is located on the New York site.
The OWA protocol connectivity flow, will be implemented as follows:
1. The New York Exchange 2010 OWA client, type the following URL addresses:
The URL address that the OWA client use, includes the
FQDN: https://mail.o365info.com/owa 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: 2010
o the Exchange 2010 mailbox server that host the user mailbox is located at the
New York site
o The New York site includes a local Exchange CAS 2010
4. CAS2013 will proxy the OWA client connectivity request to an Exchange 2010
CAS (Number 2).
5. CAS2010, proxy the OWA client connectivity request to the Exchange 2010
mailbox server who hosts the user mailbox (Number 3).
6. Exchange 2010 mailbox server, provides the required user mailbox content to
the CAS2010.
7. CAS2010 provides the required user mailbox content to the CAS2013.
8. CAS2013 provide the required user mailbox content to the External OWA
client (Number 4).
OWA client protocol connectivity flows 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 (mail.o365info.com), 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 2010 OWA client, but, to any other type of external OWA client such as
Exchange 2013 OWA clients.
The concept of silent redirection and SSO
In the former sections, we have a review scenario in which the Exchange 2013 CAS
will redirect Exchange 2010 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, its 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 users 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 of: 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 2010 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 2010 OWA browser, that
will redirect the OWA session to the new URL address (the legacy URL address
of the Exchange 2010 CAS server).
SSO Exchange 2013 CAS server knows how to transfer or forward (Proxy) the
OWA user credentials to the destination Exchange 2010 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 to the OWA login page from
the destination Exchange server).
The Exchange 2010 OWA client is not aware of the complicated redirection
process. From the Exchange 2010 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 2010 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
Scenario 2: OWA client | User mailbox located on the Madrid site | Regional
namespace |Destination site = Public facing
To simplify the OWA flow steps description, we will relate only to the external OWA
client but the same logic and flow are implemented also to the internal OWA
client.
Note you can read more information about the concept of silent redirection and
SSO in the article: Exchange CAS server | Proxy versus redirection
Scenario charters: an external Exchange 2010 OWA client, need to get access to his
mailbox.
Exchange user type: Exchange 2010 client (Exchange user whom his mailbox is
hosted on the Exchange 2010 mailbox server).
Exchange mailbox server location: the Exchange 2010 Mailbox server who hosts
the user mailbox, is located on the Madrid site.
The Madrid Exchange site considers as: Public facing Exchange 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 2010 OWA client, type the following URL addresses:
The FQDN: mail.o365info.com points to the New York Public facing Exchange
CAS server (Number1).
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: 2010
o the Exchange 2010 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 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 2010 OWA client
browser that includes the FQDN of the Madrid Exchange 2010 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 2010
OWA user credentials, to the Europe Exchange 2010 Public facing Exchange
CAS (Number 8).
5. The Madrid Exchange 2010 OWA mail client browser, gets the redirection
command from the CAS2013 and starts a new HTTPS session with the Madrid
Exchange 2010 Public facing Exchange CAS (Number 3).
6. The Madrid Exchange 2010 Public facing Exchange CAS
(europe.mail.o365info.com) will then facilitate the request and retrieve the
necessary data from the Exchange 2010 Mailbox server (Number 5).
7. The Madrid Exchange 2010 Mailbox server, provides the required user mailbox
content to the Madrid CAS2010 (Number 6).
8. The Madrid CAS2010 sends the information to the external Exchange 2010 OWA
client (Number7).
Additional reading
Client Connectivity in an Exchange 2013 Coexistence Environment

Understanding Client Access Protocol Connectivity Flow Microsoft Exchange
Server 2013
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 2010 SP2

Enabling Silent OWA Redirection for Office 365 Hybrid
Upgrading Outlook Web App to Exchange 2010
Overview of Exchange Server 2010 CAS Proxying and Redirection
Outlook Web Access and Exchange 2010, 2003 and 2000 coexistence
General
Microsoft Exchange Server 2013 Deployment and Coexistence
The Exchange 2013 coexistence article series index page

OWA Client Protocol Connectivity Flow in Exchange 2013/2010 Coexistence - 3/4 - 22#23

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

OWA Client Protocol Connectivity Flow in Exchange 2013/2010 Coexistence - 3/4 - 22#23

Încărcat de

Drepturi de autor:

Formate disponibile

Page 1 of 16 | Part 22#23 | OWA client protocol connectivity flow in Exchange 2013/2010

coexistence environment | 3/4

OWA CLIENT PROTOCOL CONNECTIVITY

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

Exchange 2013 and Exchange 2010

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

The external OWA scenarios

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

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

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

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

OWA client protocol connectivity flows in a

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

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

The OWA redirection was implemented by displaying a message window, which

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

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

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

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

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

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

Client Connectivity in an Exchange 2013 Coexistence Environment

Understanding Proxying and Redirection

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

OWA Cross-Site Silent Redirection

OWA Cross-Site Silent Redirection in Exchange 2010 SP2

Microsoft Exchange Server 2013 Deployment and Coexistence

The Exchange 2013 coexistence article series index page

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

S-ar putea să vă placă și