OWA Cross-Site Silent Redirection in Exchange 2010 SP2


OWA Cross-Site Silent Redirection in Exchange 2010 SP2

Exchange 2010 SP2 offers many new features, such as Address Book Policies, Hosting Changes, and the Hybrid Configuration Wizard, just to name a few, but one of the most sought after and applauded is OWA Cross-Site Silent Redirection.
First, some definitions:

Internet-facing Active Directory Site An Active Directory site that contains CAS that have an ExternalURL populated for the associated service (like OWA). Typically this is the primary datacenter/site where Exchange 2010 is deployed.

Regional Internet-facing Active Directory Site An Active Directory site that contains CAS that have an ExternalURL populated for the associated service (like OWA).
Non-Internet-facing Active Directory Site An Active Directory site that contains CAS that do not have an ExternalURL populated for the associated service.

Direct Connect The process where CAS establishes an RPC session with the Mailbox server hosting the mailbox data.

Proxy The process where a CAS in an Internet-facing Active Directory site proxies incoming requests to a CAS in a Non-Internet-facing Active Directory site (that’s located in the same site as the Mailbox server being accessed).

Redirection The process where an Internet-facing CAS in one Active Directory site redirects the end user to another Internet-facing CAS that resides in the same site as the Mailbox server being accessed.

Silent Redirection The process by which CAS issues a silent redirect back to the user’s browser, telling the browser to establish a connection to a specified URL.

Single Sign-On (SSO) Redirection The process by which CAS issues a silent redirect back to the user’s browser, telling the browser to submit the request and authentication credentials to a target CAS so that the login experience is seamless.

OWA Connection Process
To understand the various proxy and redirection scenarios, one must understand what happens when a user authenticates against a CAS to access OWA as it occurred with Exchange 2010 pre-SP2:
1. User accesses OWA URL using web browser.
2. User enters credentials.
3. CAS authenticates user and retrieves the following information via service discovery request:

1. User’s mailbox version
2. User’s mailbox location (Active Directory site), if known

4. CAS gathers additional information based on mailbox information so that it can perform the correct operation:

a. If mailbox is Exchange 2010 and local, CAS performs direct connect.
b. If mailbox is Exchange 2007 and local, CAS retrieves the ExternalURL of an Exchange 2007 CAS (if one isn’t defined it’ll use the InternalURL) and silently redirects.
c. If mailbox is Exchange 2003, CAS retrieves Exchange2003URL and silently redirects.
d. If mailbox is not local, CAS retrieves target ExternalURL (if defined) and redirects or proxies if no OWA ExternalURLs are defined in the target Active Directory site.
SP1 OWA Redirection Types

In Exchange 2010 SP1 things changed slightly which resulted in three types of redirection experience for OWA in the on-premises product:

*Manual Redirection
*Temporary Manual Redirection
*Legacy Silent Redirection

Manual Redirection
Manual redirection enables customers to not have to funnel and proxy all traffic from a central location when there is a CAS closer to the user’s mailbox.

Manual redirections are performed when the CAS must redirect an OWA request to Exchange 2007 or Exchange 2010 CAS infrastructure that’s located in a different Active Directory site. As mentioned previously, in order for a manual redirection to be performed, the target OWA virtual directory must have an ExternalURL.

Temporary Manual Redirection
In SP1, another redirection type was added for OWA, known as Temporary Manual Redirection. There are two scenarios where Temporary Manual Redirection comes into play:

1. During a datacenter activation switchback event, there exists the possibility that the user’s web browser still has the incorrect DNS entry cached and thus is pointing to the CAS infrastructure in the Active Directory site that no longer hosts the mailbox. As a result, the CAS will issue a manual redirect to the correct Active Directory site, but the redirection is to the same URL that the user is currently using. To prevent a ping-pong effect where the user cannot access his mail, the CAS will detect if the same session cookie is being returned and if so, will check to see if the target CAS has a FailbackURL value for the OWA virtual directory. If a FailbackURLis specified, then CAS issues a temporary manual redirection page providing the FailbackURL link. If a FailbackURL is not specified, CAS issues an error page asking the user to close all browser sessions and to try again.

2. The second scenario is where the CAS will issue the temporary manual redirection page when it detects that the local CAS’s site matches that of the Mailbox databases’s RpcClientAccessServer value, but the database is actually mounted in a different Active Directory site, so the CAS issues a temporary redirect with the ExternalURLof the CAS in the site hosting the mounted database.

Legacy Silent Redirection
For Outlook Web Access, Exchange 2010 CAS does not support rendering mailbox data from legacy versions of Exchange. Exchange 2010 CAS does one of four scenarios depending on the target mailbox’s version and/or location:

*If the Exchange 2007 mailbox is in the same Active Directory Site as CAS2010, CAS2010 will silently redirect the session to the Exchange 2007 CAS.

*If the Exchange 2007 mailbox is in another Internet-facing Active Directory Site, CAS2010 will manually redirect the user to the Exchange 2007 CAS.

*If the Exchange 2007 mailbox is in a non-Internet-facing Active Directory site, CAS2010 will proxy the connection to the Exchange 2007 CAS.

*If the mailbox is on an Exchange 2003 server, CAS2010 will silently redirect the session to a pre-defined URL.

As indicated above, legacy silent redirection is only used for same-site redirection events between an Exchange 2010 CAS and the legacy infrastructure. When performing the legacy silent redirection, CAS2010 issues a silent redirect back to the user’s browser, telling the browser to establish a connection to legacy CAS2007/FE2003 infrastructure. In order to successfully redirect to the legacy infrastructure, the following must be configured:

*To redirect Exchange 2003 mailboxes, the Exchange 2010 OWA virtual directory must have the Exchange2003URL populated.

*To redirect to an Exchange 2007 CAS, the target Exchange 2007 OWA virtual directory must have the ExternalURL.

Legacy Silent Redirection can also provide a single sign-on experience when Forms-Based Authentication (FBA) is used on the source and destination OWA virtual directories by issuing back to the web browser a hidden FBA form with the fields populated. This hidden form contains the same information as what the user had originally submitted to CAS2010 FBA page (username, password, public/private selector) as well as, a redirect to the target Exchange specific path and query string. As soon as this form is loaded it is immediately submitted to the target URL. The result is the user is automatically authenticated and can access the mailbox data.

What’s wrong with Manual Redirection?
Manual redirection is an acceptable feature for the IT organization to control where users access their data (and thus forcing users to utilize the correct network links). But in reality, the experience is not optimal for the end user. In the scenario where the user uses the wrong OWA URL, the user performs the following actions:

1. User enters into the web browser the wrong URL.
2. User enters credentials and authenticates against CAS (wrong site).
3. CAS (wrong site) performs service discovery and determines that it can redirect user to the correct CAS.
4. CAS (wrong site) provides the user with a page that contains a link to CAS (correct site).
5. User clicks link to access OWA from the correct site.
6. User enters credentials and authenticates against CAS (correct site).

It’s this experience where the user is told they used the wrong URL and has to enter his credentials twice that are the sub-optimal experiences with manual redirection.

Cross-Site Silent Redirection in Exchange 2010 SP2
To remove this sub-optimal experience a fourth redirection experience for OWA has been provided in Exchange 2010 SP2, known as Cross-Site Silent Redirection. As its name implies, Cross-Site Silent Redirection only performs silent redirection for requests that are destined to CAS located in another Active Directory site (within the same Exchange organization) that have an OWA ExternalURL.

A new parameter has been created to support Cross-Site Silent Redirection, CrossSiteRedirectType. This parameter is available on the Set-OWAVirtualDirectory cmdlet and supports two values, Manual and Silent. Cross-Site Silent Redirection is disabled by default (the default value is Manual), meaning that if you currently perform manual redirection between CAS in different Active Directory sites, it will continue after you deploy SP2.

If you want to enable Cross-Site Silent Redirection, set the CrossSiteRedirectType to Silent on the Internet-facing CAS OWA virtual directories:
Set-OWAVirtualDirectory -Identity “Contosoowa (Default Web site)” -CrossSiteRedirectType Silent

The OWA connection process has been updated to support Cross-Site Silent Redirection. The CAS performs the following steps during service discovery:

1. Evaluate the mailbox version (either Exchange 2007 or Exchange 2010).
2. Check the mailbox’s location.
3. Obtain the ExternalURL of target CAS.
4. Obtain the redirection type on the source CAS.

a. If CrossSiteRedirectType=Manual, we issue a manual redirect.
b. If CrossSiteRedirectType=Silent, we issue a silent redirect.

i. If source and target CAS have FBA enabled, then the source CAS issues a hidden form back to the browser that contains the user’s credentials and FBA settings, along with the redirect URL.
ii. If FBA is not enabled on source and target, source CAS simply issues a 302 redirect.
That’s right; Cross-Site Silent Redirection can be a SSO experience when the source and target OWA virtual directories leverage Forms-Based Authentication. Customers that only deploy OWA internally can also achieve a SSO experience when the OWA virtual directory authentication mechanism is Windows Integrated Authentication and the OWA namespaces are added to the “Local Intranet” security zone.

When can I not obtain a SSO Experience?
These are the few scenarios where you can’t obtain a SSO experience when redirecting between Active Directory sites:

1. You use Basic Authentication on the source and target OWA virtual directories.
2. You leverage different authentication settings on the source and target OWA virtual directories.
3. You leverage a two-factor authentication solution on the source and target OWA virtual directories.
4. You leverage a pre-authentication solution (like Microsoft Threat Management Gateway 2010) that uses different web listeners for the source and target OWA namespaces.
5. When the local CAS issues a temporary redirection to another CAS in another Active Directory site.

Keep in mind, that while the SSO experience will be unavailable for these scenarios, a 302 redirection (what is referred to as a silent redirection) will still occur.

Cross-Site Silent Redirection reduces the end user dissatisfaction around having to click a link to get to the correct OWA infrastructure, and may in fact remove the need to enter credentials a second time.

(Information provided by http://blogs.technet.com/b/exchange/archive/2011/12/12/owa-cross-site-silent-redirection-in-exchange-2010-sp2.aspx)

To receive hands-on experience and learn more about Microsoft Exchange Server 2010, check out the links below to our upcoming schedule for Exchanges Server 2010 courses

MS10135 Configuring, Managing and Troubleshooting Microsoft Exchange Server 2010


MS10165 Updating Your Skills from Microsoft Exchange Server 2003 or Exchange Server 2007 to Exchange Server 2010


MS10233 Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010