E2K7 OWA Redirect Bug Introduced with Exchange 2010 SP1

I just deployed Exchange 2010 SP1 to an enterprise customer that has a mix of Exchange 2007 and Exchange 2010 users.  It seems that SP1 has introduced a rather aggravating and obvious bug.  Before I get into that, I'll give some background on how Exchange 2010 coexists with previous versions of Exchange.

When you have a mix of Exchange 2010 and older versions in your environment, you have to do a bit of work to make the two work together for your external users.  In a nutshell, you use Exchange 2010 Client Access Server (CAS) as your primary entry point for all external users. 

Say you use owa.company.com as your externally accessible URL.  If an Exchange 2010 user logs in from the Internet, the Exchange 2010 CAS will do its thing and the user will get a nice Outlook Web App screen.

If an Exchange 2007 user logs in using owa.company.com, the Exchange 2010 CAS will redirect the user to an externally accessible Exchange 2007 CAS using a different URL (like legacy.company.com).  The redirection is silent, but the user may notice their browser changed to legacy.company.com. 

How the redirect is handled is managed by the LegacyRedirectType setting in the Exchange 2010 OWA virtual directory.  In most cases, LegacyRedirectType is set to Silent.  To see what the setting is in your environment, run:

Get-OWAVirtualDirectory -Server <CASservername> | FL Identity, LegacyRedirectType

In SP1, this redirection is no longer silent.  When your Exchange 2007 user logs in via owa.company.com, they are presented with this screen:

The text reads:

A temporary change has occurred that requires you to connect to a different server.  To connect, click the button below.  For security reasons, you'll be asked to enter your user name and password again.

Sure enough, when you click Connect, you are redirected to legacy.company.com, where you have to re-enter your user information.

Thankfully, the same sort of thing doesn't seem to happen with Outlook Anywhere or ActiveSync clients.

I checked the LegacyRedirectType value on my 2010 SP1 CAS boxes and they are all still set to Silent.  I've read the issue occurs because the OWA virtual directory value for LegacyRedirectType is being ignored.  Apparently, this bug was to be addressed in Exchange 2010 SP1 RU1, but that wasn't the case.  Hopefully, Rollup 2 will fix the issue.

This is an extraordinarily unfortunate thing to have been introduced with SP1.   If you have a mixed Exchange 2007/2010 environment, I suggest you wait before deploying SP1.

UPDATE (01-Dec-2010):  Thanks to an anonymous commenter below, there is a workaround for the OWA redirect issue.  Navigate to C:\Program Files\Microsoft\Exchange\v14\ClientAccess\Owa (or whereever you installed Exchange) and edit the casredirect.aspx with Notepad.

Add the following line just under the existing meta-tag that starts with <meta http-equiv...:

<meta http-equiv="refresh" content="0;URL=https://legacy.domain.com/owa">

Replace legacy.domain.com with whatever you are using for your redirect URL.  Save the file and issue an IISRESET from the command line.  When your legacy users logon to OWA, they will still see the redirect page, but users will not have to press the button to continue.  It should automatically switch them to the legacy URL. 

It's not perfect, but at least its something.  Thanks again to the anonomous user who brought this to my attention!

FINAL UPDATE (14-Dec-2010): The redirect issue has finally been fixed in Exchange 2010 SP1 Rollup 2!  Read more about it here.