Follow us on Twitter
Follow us on YouTube
Would you like to suggest a topic for the Exchange team to blog about? Send suggestions to us.
Many of you have been asking how you can transition your existing Exchange environment to Exchange 2010 from a client access perspective. For most of you, this will also mean coexisting with legacy Exchange and Exchange 2010 for a period of time. My previous blog article discussed the overall steps in how to upgrade your environment from a client access perspective. This article will discuss how Outlook Web App will function in an Exchange 2003 or 2007 environment that has Exchange 2010 deployed.
In order to introduce Exchange 2010 into your environment and support your Exchange 2003/2007 mailboxes, you will move the primary OWA namespace that is associated with the legacy Exchange server environment and associate it with the Exchange 2010 CAS array. In addition, if you have Exchange 2003 mailboxes you will set the Exchange2003URL property on the CAS2010 OWA Virtual directory. For more information on the detailed steps required to support coexistence process see my previous blog article, TechNet, or within the Deployment Assistant.
Essentially, 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:
Note: For the purposes of this discussion it is assumed you are utilizing Forms Based Authentication for Outlook Web App authentication.
Some of you may have environments that have Internet facing AD sites and non-Internet facing AD sites and currently only have Exchange 2003 deployed. As part of our transition process, you will be following a model where you:
In other words, it would look something like this:
With this configuration there are typically a few questions that are asked:
The Exchange2003URL parameter is a new property that is exposed on the Exchange 2010 CAS OWA virtual directory. In other words, this is not a global property, but a property assigned on a per-OWA virtual directory basis. As to why we need to set this property when interacting with Exchange 2003 is that Exchange 2003 is not AD site aware, nor does it have settings published in Active Directory (like ExternalURL) that allow CAS2010 to determine the best front-end server for which a client should be redirected. That is why we leverage the Exchange2003URL property on the CAS2010 OWA virtual directory - it tells CAS2010 where Exchange 2003 OWA users should be redirected.
No, during the installation of CAS2010 setup will create an /exchange and /public virtual directories and they will be configured to redirect users to /owa. Note that those /exchange and /public virtual directories are only created in IIS. They aren't created as "Exchange OWA" virtual directories and won't show up when using the Get-OWAVirtualDirectory task. These virtual directories do nothing but simple IIS 302 redirection. Currently, if you open IIS Manager, the /exchange and /public virtual directories are not visible (the reason is because they are web directories); we are evaluating whether to change this behavior (by making them into virtual directories).
Regardless of the user's mailbox version, users will utilize a single URL for accessing OWA, https://mail.contoso.com/owa. For Exchange 2010 mailboxes the process is:
Again, regardless of the user's mailbox version, users will utilize a single URL for accessing OWA: https://mail.contoso.com/owa. For those Exchange 2003 mailboxes in the "Internet Facing AD Site" the following process will happen:
Typically the users in the "Regional Internet Facing AD Site" will continue to access their mailboxes using their regional OWA namespace, https://mail.regional.contoso.com/exchange.
However, for the sake of argument, let's assume that the user whose Exchange 2003 mailbox is located in the "Regional Internet Facing AD Site" uses the https://mail.contoso.com/owa URL. In this case, the steps are exactly the same as in the "How do my Exchange 2003 users that are located in the "Internet Facing AD Site" access their mailboxes?" question's answer, with the distinction that in step 5, the FE2003 server that is located in the "Internet Facing AD Site" is proxying the request to the 2003 mailbox server that is located in the "Regional Internet Facing AD Site" utilizing the HTTP protocol.
In this case, the steps are exactly the same as in the "How do my Exchange 2003 users that are located in the "Internet Facing AD Site" access their mailboxes?" question's answer, with the distinction that in step 5, the FE2003 server that is located in the "Internet Facing AD Site" is proxying the request to the 2003 mailbox server that is located in the "Non-Internet Facing AD Site" utilizing the HTTP protocol.
Some of you may have environments that have Internet facing AD sites and non-Internet facing AD sites. As part of our transition process, you will be following a model where:
You upgrade all CAS servers in the organization to Exchange 2007 SP2.
Regardless of the user's mailbox version, users will utilize a single URL for accessing OWA: https://mail.contoso.com/owa. For Exchange 2010 mailboxes the process is:
How do my Exchange 2007/2003 users that are located in the "Internet Facing AD Site" access their mailboxes?
Again, regardless of the user's mailbox version, users will utilize a single URL for accessing OWA: https://mail.contoso.com/owa. For those Exchange 2007 mailboxes in the "Internet Facing AD Site" the following process will happen:
How do my Exchange 2007/2003 users in the "Regional Internet Facing AD Site" access their mailboxes?
Typically the users in the "Regional Internet Facing AD Site" will access their mailboxes using their regional OWA namespace, https://mail.regional.contoso.com/owa.
However, for the sake of argument, let's assume that the user whose Exchange 2007 mailbox is located in the "Regional Internet Facing AD Site" uses the https://mail.contoso.com/owa URL:
Now what if my Exchange 2003 mailbox that is located in the "Regional Internet Facing AD Site" and the user uses the https://mail.contoso.com/owa URL?
Note: If you replace the Exchange 2007/2003 infrastructure in the "Regional Internet Facing AD Site" with Exchange 2010, this same behavior would apply.
As you may know, Exchange 2010 does not include any support for legacy OWA (thus why we have the aforementioned redirection scenarios), but we do support proxying OWA requests between Active Directory sites. The basic process is as follows:
But in order to ensure that Step 4 happens, you must make an additional configuration change on your CAS2010 infrastructure in the "Internet Facing AD Site" before you can enable the CAS 2010 infrastructure to be the primary endpoint for https://mail.contoso.com/owa.
Additional configuration you say; what are the steps?
Important: Please keep in mind that every time you deploy a new Exchange 2007 rollup or service pack in the non-Internet Facing AD site, you will have to update the CAS2010 OWA binary directory with the new Exchange 2007 OWA binaries.
What if I don't copy the binaries; what happens then?
Well to answer that let's look at how the environment is configured at this point in time:
Now a user whose mailbox resides in the "Non-Internet Facing AD Site" attempts to access his mailbox via OWA from an Internet kiosk:
Log Name: Application Source: MSExchange OWA Task Category: Proxy Level: Error Keywords: Classic Description: Client Access server "https://mail.contoso.com/owa", running Exchange version "14.0.639.21", is proxying Outlook Web App traffic to Client Access server "cas2007nonIFAD.contoso.com", which runs Exchange version "8.2.176.2". To ensure reliable interoperability, the proxying Client Access server needs to be running a newer version of Exchange than the Client Access server it is proxying to. If the proxying Client Access server is running a newer version of Exchange than the Client Access server it is proxying to, the proxying Client Access server needs to have an Outlook Web App resource folder (for example, "<Exchange Server installation path>)\ClientAccess\owa\8.0.639.21" that contains all the same versioned resource files as the Client Access server it is proxying to. If you will be running Outlook Web App proxying with mismatched server versions, you can manually copy this resource folder to the proxying Client Access server.
Log Name: Application
Source: MSExchange OWA
Task Category: Proxy
Level: Error
Keywords: Classic
Description:
Client Access server "https://mail.contoso.com/owa", running Exchange version "14.0.639.21", is proxying Outlook Web App traffic to Client Access server "cas2007nonIFAD.contoso.com", which runs Exchange version "8.2.176.2". To ensure reliable interoperability, the proxying Client Access server needs to be running a newer version of Exchange than the Client Access server it is proxying to. If the proxying Client Access server is running a newer version of Exchange than the Client Access server it is proxying to, the proxying Client Access server needs to have an Outlook Web App resource folder (for example, "<Exchange Server installation path>)\ClientAccess\owa\8.0.639.21" that contains all the same versioned resource files as the Client Access server it is proxying to. If you will be running Outlook Web App proxying with mismatched server versions, you can manually copy this resource folder to the proxying Client Access server.
Hopefully this information dispels some of the myths around proxying and redirection logic for Outlook Web App in Exchange Server 2010. Please let us know if you have any questions.
-- Ross Smith IV