By now, many of you have seen the articles that discussed Address Book Policies, hosting changes, and the Hybrid Configuration Wizard, but deep down I know you all have been hoping that we would discuss the most sought after feature that we decided to include in Exchange 2010 SP2.

What’s that you say?  Yes, I know, Tony said that the “new features in SP2 are unlikely to cause much of a fuss” and that there are not that many new features in SP2 (I believe his exact words were “relative paucity”) in his SP2 announcement article over at Windows IT Pro.

Well, I'm here to set the record straight. There's one killer feature in Exchange 2010 SP2, that's often not mentioned. That's right – it's time to discuss Cross-Site Silent Redirection for Outlook Web App!


First, let’s go over some definitions to make sure we are all on the same page.

  • 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

In order to understand the various proxy and redirection scenarios, it's important to understand the mechanics behind what happens when a user authenticates against a CAS to access OWA as it happens today 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:
    1. If mailbox is Exchange 2010 and local, CAS performs direct connect.
    2. 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.
    3. If mailbox is Exchange 2003, CAS retrieves Exchange2003URL and silently redirects.
    4. 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, we changed things 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 are CAS closer to the user’s mailbox.

Manual redirections are performed when 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. Your users see the following manual redirection message and the ExternalURL of the CAS in the other Active Directory site:

Figure1: Manual redirection when mailbox is located in another Active Directory site


Temporary Manual Redirection

In SP1, we added another redirection type 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 Ative 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, 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.

    Figure 2: Temporary manual redirection upon datacenter activation switchback
  2. The second scenario is where 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 CAS issues a temporary redirect with the ExternalURLof the CAS in the site hosting the mounted database.

    Figure 3: Temporary manual redirection when mailbox is mounted in another Active Directory site

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?

At first glance, you might think, “hey, manual redirection is great, Microsoft” and to some extent you are correct. It is a great 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 that he 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 (Greg refers to this as a crappy experience, by the way), we've provided a fourth redirection experience for OWA 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 "Contoso\owa (Default Web site)" -CrossSiteRedirectType Silent

We've updated the OWA connection process 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.
    1. If CrossSiteRedirectType=Manual, we issue a manual redirect.
    2. If CrossSiteRedirectType=Silent, we issue a silent redirect.
      1. 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.
      2. 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 we refer 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. For those of you that have been using OWA Manual Redirection up to now, I hope you will enable Cross-Site Silent Redirection when you deploy Exchange 2010 SP2!

Ross Smith IV
Principal Program Manager
Exchange Customer Experience

Not applicable

This video plays in Adobe Flash Player & has HD quality BUT has absolutely no way to view it in full screen, which renders it USELESS! Please fix that! Why don't you guys use your own YouTube Channel? [www.youtube.com/.../MSExchangeTeam] Upload video there, embed it here in blog post, how frickin' difficult is that for you? Do I really have to point this out to you, the team behind the number 1 messaging server out there??!!!

[Thanks Ross for the detailed blog post, my comment is directed towards the useless video embedding, though you should have made sure its done right or at least make it right now - cos I don't think you wanted it to go to waste & not be useful to your readers!]

Not applicable

@ExchangeMaster - Thanks for the feedback. This appears to be an issue that we are looking into.


Not applicable

@ExchangeMaster The embedded player has been updated. You can now play the video in HQ and HD in full-screen.

Not applicable


i always learn new things about people and how frustrated they are with who knows what:)

please fix that!!!!  :)

freakin....    :)

do I(special attention to I, yes we know you the greatest , thanks..) :)

relax dude

its only a video :)

i wonder how you handle exchange disasters if you get so excited and frustrated from a freakin video posted not in full screen:)

Not applicable

@Ross - this is excellent progression and information for Exchange. This update is MUCH appreciated and not to be belittled, so please keep up the great work.

@Turbomcp - go troll another forum please.

Not applicable

Hi. Great to have finally silent cross site redirect, thanks!!

Now please try to think about something more - Internal redirect. Why I am asking for it. Imagine company that wants single global URL for OWA hooked to the largest datacenter. However there are lots of small sites, with or without internet connectivity, connected by limited WAN to the central site. What happens i.e. if user from non-internet facing site hits the global OWA now?

1. User logs to central OWA thorough WAN

2. Central OWA proxies request to the user`s site OWA, thorough WAN back

3. Request is returned to central proxying OWA and then again to the user, 2x thorough WAN

So the information requested has traveled four times thorough WAN, because we don’t have internal redirect. If the user`s site has internet connectivity (and ExternalURL), then user will be redirected to it. So the user will not connect internally but i.e. thorough local proxy. It’s still better than WAN ping pong but not ideal.

I understand, that there is a problem how to distinct user connecting internally requiring internal redirect. Well I hope simple IP range definition of from where external/internal connection goes can leverage that.

Thanks in advance.


Not applicable

Not a killer feature for me, as we don't use OWA. All SP2 has done for me is slow down mail processing. I installed it on a new server and it was taking minutes to process a message instead of a couple of seconds like the SP1 servers. Haven't had time to investigate but probably will just uninstall and put on SP1.

Not applicable

Great article and feature Ross!!!  Thanks!!!

Not applicable

@ Chris, do you have any AV software running on those servers? Are they validated for SP2 if so? We haven't heard of issues like this, and it sounds to me like some transport based agent is having trouble. Transport AV scanning might be a good candidate to look at if you have it.

@ David - yes, it's hard, but we have no plans to redirect to internal or external based on source IP, so your options are, use split DNS, so hte external names resolve internally, and then use the FBA feature the same inside and out - send everyone to one site/url and then redirect/SSO to wherever they need to be. Or, use DNS to try and get people to their closest CAS right from the start, tricky, but possible. You know, Windows has location aware DNS built in, it's called subnet mask ordering I think. If the clients and the CAS you want them to use are in the same subnet, windows DNS will return the IP close to the user if it has several. Take a look at that.

Not applicable

@Greg: No, I haven't put antivirus on the new server yet. We use Forefront on the other two.

Not applicable

Ok, so if you don't have any custom transport agents and there's nothing else unusual, I'd open a case and get to the bottom of it rather than revert to SP1, else you'll never really solve it, and if you can't repro it you'll be stuck. Give support a call and they can help you trace messages through transport (you can do it yourself if you know how) and see what is causing the delay.

Not applicable

I'ge got this working great with OWA.

Problem I'm having is that active sync chokes on the 451 redirect. I put a thread in the Exchange > Mobility forums but haven't gotten any feedback.

Have you been able to get Silent Redirect working on Active Sync? Doc says it works ( technet.microsoft.com/.../bb310763.aspx ) but I can't get it to function. Even Remote Connectivity Analyzer chikes on it:

          A Web exception occurred because an HTTP 451 - 451 response was received from Unknown.

Not applicable

Mike, the 451 isn't impacted by any of the changes this feature added, just to make that clear.

Do you have externalURL set on both AD sites correctly? The CAS sending the 451 should provide the correct externalURL within its stream. Have a look in the IIS logs for the CAS you are trying to be redirection from, not to, away from. That's the guy generating the 451. Also look at the app event logs too.

Not applicable

I got the slient cross-site redirection to work without users having to re-enter their credentials when OWA is first launched. That's great!

Now, I was expecting this slient cross-site redirection with single sign-on to work during cross-site failovers as well...Howerver, my tests show that the redirection does take place but the user is presented with the logon screen. Is there a way to get the single sign-on to work for cross-site failovers?

Not applicable

Sly, does the redirection take place? Does the user get sent to the CAS in the other AD site, but just not logged in? The redirection is no different, unless it's the temporary manual redirection that Ross refers to that you are seeing?

Not applicable

@Sly - Sorry for the confusion.  With the Temporary Redirection scenarios I outlined above, only silent redirection will work.  You still need to perform a second authentication.  This has to do with the process used to detect that the mailbox database is no longer located in the same AD site as the RPCClientAccessServer value (this happens after the authentication is performed and thus we can't do the hidden post back to the browser).


Not applicable

HI i have two internet facing CAS site and want to use a single owa url globally. What should i have InternalURL and ExternalURL value on both a CAS site so that if user access his mailbox his request redirect to correct and nearest CAS server.