Export (0) Print
Expand All

White Paper: Using Outlook Web App in Environments Where Exchange Server 2010 Coexists with Legacy Versions of Exchange

 

Topic Last Modified: 2011-05-21

Timothy Heeney, SR Support Escalation Engineer; Ross Smith IV, Principal Program Manager, Exchange CXP Svc

April 2010

This white paper discusses how to use Outlook Web App (OWA) in an environment in which Microsoft Exchange Server 2010 coexists with Microsoft Exchange Server 2007 or with Microsoft Exchange Server 2003.

Typically, the environment in which Exchange 2010 is implemented will already have an older (legacy) version of Exchange Server running. This document discusses how Exchange 2010, Exchange 2007, and Exchange 2003 work together when they are used together with Outlook Web App (OWA). If the servers are implemented correctly, they will provide a single namespace for user access to OWA, regardless of the location of the user’s mailbox.

noteNote:
Because customer environments can vary greatly, the steps in this white paper may not work for every implementation. Steps are provided for many typical environments. However, the actual steps that must be used to configure your environment for this solution may vary.

The following list describes some of the general planning guidelines that are required for coexistence of Exchange 2010 and an earlier version of Exchange.

Make sure that the Exchange 2003 servers are running Service Pack 2 (SP2) or a later version.

Make sure that the Exchange 2007 servers are running Service Pack 2 (SP2) or a later version.

Make sure that a server that is running Exchange 2010, the Client Access server (CAS), a Hub Transport role (HUB) and a Mailbox role (MBX) exists in the Internet-facing site.

Update the main OWA URL to point to the Exchange 2010 Client Access servers.

Consider changing your public DNS records so that the public OWA URL (for example, mail.contoso.com) points to the new IP address of the Exchange 2010 CAS, or the virtual IP address of your load-balanced CAS Array.

Create a legacy URL to point to the Exchange 2007 CAS or Microsoft Exchange Server 2003 FE servers, if they exist, and make a DNS entry externally to point to the legacy server.

Create a certificate for the Exchange 2010 CAS servers to include the OWA URL, the Legacy URL, and Auto discover URLs. Note that other names may be needed for protocols such as IMAP and SMTP.

Change the External URL setting on the Exchange 2007 CAS to the legacy URL, if applicable.

Update the rules on the firewall (ISA) server to point to the correct locations for Exchange Web traffic.

Most of our small-sized to mid-sized customers have a coexistence environment that includes a single Active Directory site that has an Exchange 2010 server and an Exchange 2007 server. Typically, these customers have one Active Directory site, and the addition of Exchange 2010 into their environment will not change that. If the following steps are followed, users can continue to use their existing URL for OWA. They can also expect to have a single sign-on process for their OWA users, even if they are on Legacy versions of Exchange.

This is a very clean experience for the users, and it should help make the migration painless because users will not have to learn a new way to complete tasks.

The following list contains the basic instructions for the setup of the single sign-on program and a brief explanation of what will occur when a user accesses OWA.

  1. Change the current owa.domain.com address to point to the Exchange 2010 Internet facing Client Access Server (CAS) server. Exchange 2010 CAS server is designed to correctly handle legacy mailbox requests. Exchange 2007 can handle requests for Exchange 2007 and for Exchange 2003, but not for Exchange 2010. If you want a uniform URL, you must configure the Exchange 2010 CAS as the Internet facing CAS.

  2. Create a Legacy.domain.com Host record to point to the Exchange 2007 CAS. This Host record can be used by the Exchange 2010 CAS to obtain the location of the Exchange 2007 CAS that can handle the legacy requests.

  3. Make sure that the ExternalURL value is populated and that the InternalURL value is set to $NULL for the OWA virtual directory on the Exchange 2007 CAS that is the target of the redirect effort. If necessary, set this value by using the following command:

    Set-OwaVirtualDirectory -Identity "CAS_Server_Name\OWA (Default Web Site)" -ExternalURL Https://Legacy.domain.com/OWA -InternalURL $NULL

  4. Create a Subject Alternative Name (SAN) certificate that contains either the wildcard entry (that is, *.contoso.com), or the subject name entries for OWA.contoso.com, Legacy.contoso.com, and autodiscover.contoso.com (other names may be needed for protocols such as IMAP and SMTP).

  5. Assign the SAN certificate to the CAS servers. This certificate should be assigned to the Exchange 2007 and Exchange 2010 Client Access servers to prevent any name mismatch certificate warnings. The Exchange 2007 Client Access servers require the certificate because the name that the Exchange 2010 Client Access servers use to access the Exchange 2007 Client Access servers will be the new legacy name. The new name will not be on the certificate unless a wildcard certificate was previously used.

  6. On the Exchange 2007 CAS, run the following command to turn on Forms-based authentication, to turn on Basic Authentication, and to set the External URL:

    Set-OwaVirtualDirectory -Identity "CAS_Server_Name\OWA (Default Web Site)" -ExternalURL Https://Legacy.domain.com/OWA -FormsAuthentication $True -BasicAuthentication $True. Run this command to make sure that the Exchange 2007 and Exchange 2010 CAS servers have the same Authentication settings, and that the new External URL is added so that the Exchange 2010 CAS knows where to match the legacy requests.

    Run this command to make sure that the Exchange 2007 and Exchange 2010 CAS servers have the same Authentication settings, and that the new External URL is added so that the Exchange 2010 CAS knows where to match the legacy requests.

    On the Exchange 2010 CAS, run the following command to turn on form based authentication, to turn on Basic Authentication, and to set the External URL to match the URL currently used by the users:

    Set-OwaVirtualDirectory -Identity "CAS_Server_Name\OWA (Default Web Site)" -ExternalURL Https://owa.domain.com/OWA -FormsAuthentication $True -BasicAuthentication $True

    On the Exchange 2010 CAS server, run the following command to set the Exchange Control Panel to match OWA: Set-ECPVirtualDirectory -Identity "CAS_Server_Name\ECP (Default Web Site)" -ExternalURL Https://owa.domain.com/OWA -FormsAuthentication $True -BasicAuthentication $True

    This enables the single sign-on to continue to work when an Exchange 2010 user clicks the options in OWA.

When a user logs in to OWA, the following actions occur:

  1. A user connects to https://OWA.contoso.com/owa, and then authenticates in the Forms-based authentication page that is presented by the Exchange 2010 External facing CAS.

  2. The Exchange 2010 CAS verifies the users AD site, their Mailbox Version, and the External URL set on the exExchange2k7 Client Access servers in that site. In this example, this is https://legacy.cotoso.com/owa.

  3. The Exchange 2010 CAS silently redirects the user’s browser session to https://legacy.contoso.com/owa by using a hidden Forms-based authentication form that has the fields populated. OWA returns a small Web page that contains a hidden form that has the same information that the user had originally submitted to CAS2010 Forms-based authentication page (username, password, public/private selector, the URL to which to redirect after logon), a submit URL synthesized from the URL obtained in step 2, and a target Exchange-specific path and query string. The Web page also contains scripts to automatically submit the form as soon as it is loaded. This is the last part of the logon process that the Exchange 2010 CAS has a role in.

  4. The Exchange 2007 CAS consumes the hidden form’s data, authenticates the user, and then finishes one of the following tasks:

    • Retrieve and display the user’s mailbox data from the Exchange 2007 mailbox server, and return the data view to the user. The response will contain a Forms-based authentication cookie for the legacy namespace. From that point on, all user activity in the session connects only to the legacy CAS.

    • Proxy the request to the Exchange 2003 mailbox server, and return the data view to the user. The response contains a Forms-based authentication cookie for the legacy namespace. From this point, all user activity in the session connects to the legacy CAS only.

noteNote:
Usually, in an environment that includes two Internet-facing sites, the users in the Internet-facing sites would type the name that correlates to the site in which they are located. However, for this example, we will assume that they did not.

Typically, this scenario is found in a medium-to-large-size company that has many Active Directory sites that are not well connected. In this case, you would not want the traffic from a CAS to return mailbox data from a server in an Active Directory site in which the connection is not optimized.

In this scenario, if a user goes to a site in which the mailbox is not located, and then authenticates, the Exchange 2010 CAS would provide a page informing the user to click a link to take them to the CAS for the site in which the mailbox is located. When the link is selected, the user is prompted for authentication again, this time from their local CAS (local relative to the Mailbox server). This will not be a single sign-on scenario unless the user accesses the correct link for the site in which their mailbox is located.

An explanation of what the user will see follows the instructions to configure the solution.

  1. Change the current owa.domain.com address to point to the Exchange 2010 Internet-facing CAS. You must do this because the Exchange 2010 CAS is designed to correctly handle requests for legacy mailbox requests. Exchange 2007 can handle requests for Exchange 2007 and Exchange 2003 but not for Exchange 2010. Therefore, if you want a uniform URL, you must have the Exchange 2010 CAS as the Internet-facing CAS.

  2. The opposing regional site should already have a unique URL, such as regional.domain.com. If this is an existing configuration, the naming should still be configured, and there would be no need to change this.

  3. Create a SAN certificate that will contain either the wildcard entry (that is, *.contoso.com) or subject name entries for OWA.contoso.com, Legacy.contoso.com, and autodiscover.contoso.com. (Other names may be included if they are required for protocols such as IMAP and SMTP.)

  4. Run the following command to make sure that the OWA in the regional site is set for Basic Authentication with Forms-based authentication for OWA and that the external URL value is set correctly:

    Set-OwaVirtualDirectory -Identity "CAS_Server_Name\OWA (Default Web Site)" -ExternalURL Https://Regional.domain.com/OWA -FormsAuthentication $True -BasicAuthentication $True

  5. On the Exchange 2010 CAS, run the following command to turn on Forms-based authentication, to turn on Basic Authentication, and to set the External URL:Set-OwaVirtualDirectory -Identity "CAS_Server_Name\OWA (Default Web Site)" -ExternalURL Https://owa.domain.com/OWA -FormsAuthentication $True -BasicAuthentication $True

    Run the following command to set the Exchange Control Panel to match OWA so that the single sign-on continues to work when an Exchange 2010 user clicks the options in OWA:

    Set-ECPVirtualDirectory -Identity "CAS_Server_Name\ECP (Default Web Site)" -ExternalURL Https://owa.domain.com/OWA -FormsAuthentication $True -BasicAuthentication $True

In this scenario, when a user logs on, the following actions occur:

  1. The user connects to https://mail.contoso.com/owa, and then authenticates in the Forms-based authentication page that is presented by Exchange 2010.

  2. The Exchange 2010 CAS verifies the user’s Active Directory site, Mailbox Version, and external URL that is set on the Exchange 2007 Client Access servers in that site. In our example, the external URL is https://regional.coontoso.com/owa.

  3. The Exchange 2010 CAS provides a redirection page on which the user selects a link for https://Regional.contoso.com/. This occurs because users are located in a different AD site and have external-facing Client Access servers in that site. This process is the same regardless of whether the other site has Exchange 2010 or Exchange 2007 Client Access servers in the Internet-facing site.

  4. After the link is selected, the user receives another authentication prompt from the CAS on which the mailbox is located. All traffic will then use the user’s local Client Access servers.

This scenario could apply in a medium-to-large-size company that has many Active Directory sites that are well connected. This provides a single namespace to which users can connect to gain OWA access, and it minimizes user confusion.

In this scenario, if a user goes to the published OWA URL and authenticates, the Exchange 2010 CAS silently sends a proxy request to the CAS that is local to their Mailbox server. The user would not be prompted again or redirected to another site for action.

This scenario will generate more network traffic because the rendered mailbox data is passed between the CAS server in the site in which the mailbox is located to the External facing CAS. To configure this scenario, follow these steps:

  1. Change the owa.domain.com address to point to the Exchange 2010 Internet-facing CAS. The Exchange 2010 CAS is designed to handle requests for legacy mailbox requests. Exchange 2007 can handle requests for Exchange 2007 and for Exchange 2003 but not for Exchange 2010. If you want a uniform URL, you must have the Exchange 2010 CAS as the Internet-facing CAS server.

  2. The opposing regional site Client Access servers should not have an External URL value set for the OWA virtual directory. Instead, they have only an internal URL value. The default values typically work fine.

  3. Create a SAN certificate that will contain either the wildcard entry (that is, *.contoso.com) or subject name entries for OWA.contoso.com, Legacy.contoso.com, and autodiscover.contoso.com. (Other names may also be listed if they are required for protocols such as IMAP and SMTP.)

  4. Assign the new certificate to the Exchange 2010 Client Access servers.

  5. Make sure that the OWA in the regional site is set for integrated authentication for OWA by using a command similar to the following on the Exchange 2007 non-Internet-facing CAS:

    Set-OwaVirtualDirectory -Identity "CAS_Server_Name\OWA (Default Web Site)" –ExternalURL $Null –formsAuthentication $False –WindowsAuthentication $true. After you run this command, you can use integrated authentication for requests that are sent by proxy to this server from the Exchange 2010 CAS. This is the same process as in Exchange 2007.

  6. On the Exchange 2010 CAS, type the following command to turn on Forms-based authentication, to turn on Basic Authentication, and to set the External URL:

    Set-OwaVirtualDirectory -Identity "CAS_Server_Name\OWA (Default Web Site)" -ExternalURL Https://owa.domain.com/OWA -FormsAuthentication $True -BasicAuthentication $True

    Run the following command to set the Microsoft Exchange Control Panel to match OWA: Set-ECPVirtualDirectory -Identity "CAS_Server_Name\ECP (Default Web Site)" -ExternalURL Https://owa.domain.com/OWA -FormsAuthentication $True -BasicAuthentication $True. The single sign-on will continue to work when an Exchange 2010 user clicks the options in OWA.

  7. From the external-facing Exchange 2010 CAS, connect to the Exchange 2007 server, and then copy the latest set of binary files to the Exchange 2010 server. This process must be completed every time that a rollup is added on the Exchange 2007 Client Access servers. You do this because the External facing Exchange 2010 server has to present the rendered data to the users when a proxy is used. Since these are legacy users, we must have a compatible copy of the binary files for the Microsoft Exchange Rollup and for the legacy version of Microsoft Exchange.

    1. On the Exchange 2010 CAS, click Start, click Run, and then type the following command:

      \\CAS_Computer_Name\c$\program files\microsoft\Exchange Server\Client Access\OWA

    2. Copy the most recent version of the build files from this location, and then paste the files on the Internet-facing Exchange 2010 CAS in the following location:c:\program files\Microsoft\Exchange Server\V14\ClientAccess\OWA

    3. Restart IIS on the Exchange 2010 CAS. The proxy will now work. If the wrong files are copied, or if this step is not completed, you will see an error on the Exchange 2010 external-facing Client Access servers in the Application log that tells you to copy the files.

In this scenario, when a user logs in, the following actions occur:

  1. The user connects to https://OWA.contoso.com/owa, and then authenticates by using the Forms-based authentication page that is presented by Exchange 2010.

  2. The Exchange 2010 CAS verifies the users Active Directory site, the Mailbox Version, and the External URL set on the site on which the user is located.

  3. An external URL value is not set on the site on which the user is located. Therefore, the user will be authenticated by proxy by using integrated authentication over the internal URL.

  4. The Exchange 2007 non-Internet-facing server displays the data, and passes that data to the Exchange 2010 server to be passed to the user. In this scenario, the Exchange 2010 Internet-facing CAS is included in the process.

The following scenario is for a company that does not have Exchange 2007 installed and is migrating or coexisting with Exchange 2010 and Exchange 2003 only.

In this situation, you use the new Exchange2003URL parameter that is configured by using the Microsoft Exchange Management Shell and the set-OWAVirtualDirectory cmdlet that is explained later in this section.

Use Active Directory Service Interfaces (ADSI) Edit to locate the Exchange2003URL value in Active Directory at the following location: Configuration ( Domain_Name.Domain.Com)\CN=Configuration,DC=Domain,DC=Com\CN=Services\CN=Microsoft Exchange\CN=Administrative Groups\CN=Exchange Administrative Group\CN=Servers\CN=CAS_Server_Name\CN=Protocols\CN=HTTP\CN=owa(Default Web Site)

Using this parameter enables the Exchange 2010 server to know where to direct the legacy Microsoft Exchange users so that they can access OWA by using the Exchange 2010 CAS URL. This parameter was added because the /exchange virtual directory does not exist in Exchange 2010. This differs from Exchange 2007.

importantImportant:
It is important to understand that Exchange 2010 cannot proxy to Exchange 2003 Mailbox role servers. Exchange 2010 must redirect this traffic.
  1. Change the current owa.domain.com address to point to the Exchange 2010 Internet-facing CAS. You do this because the Exchange 2010 CAS is designed to correctly handle requests for legacy mailbox requests. Exchange 2003 can handle requests for Exchange 2003 only. If you want a uniform URL, you must designate the Exchange 2010 CAS as the Internet-facing CAS server.

  2. Create a Legacy URL such as Legacy.domainy.com to point to the Exchange 2003 front-end server. This is required so that a URL is available to provide the correct configuration to the Exchange 2010 CAS, which can then use that information to locate the Exchange 2003 front-end server.

  3. On the Exchange 2010 CAS, run the following command to turn on Forms-based authentication, to turn on Basic Authentication, and to set the External URL:

    Set-OwaVirtualDirectory -Identity "CAS_Server_Name\OWA (Default Web Site)" -ExternalURL Https://owa.domain.com/OWA -FormsAuthentication $True -BasicAuthentication $True

    Run the following command to set the Microsoft Exchange Control Panel (ECP) to match OWA. The single sign-on will continue to work when an Exchange 2010 user clicks the options in OWA:

    Set-ECPVirtualDirectory -Identity "CAS_Server_Name\ECP (Default Web Site)" -ExternalURL Https://owa.domain.com/OWA -FormsAuthentication $True -BasicAuthentication $True

  4. Configure the Exchange2003URL parameter on the Exchange 2010 CAS to point to the new Legacy URL. The new Exchange2003URL parameter was added to Exchange 2010 as a configurable attribute for the OWA virtual directory to enable Exchange 2010 to know the location to which to send the Exchange 2003 users. In earlier versions of Exchange, we used DAVEX for this task. But because DAVEX was removed, we now rely on this parameter. Run a command that resembles the following example command to set this property:

    set-owavirtualdirectory “2010_CAS_Server_Name\owa (default web site)” -exchange2003url https://Legacy.domain.com/Exchange

  5. Forms-based authentication must be enabled on the Exchange 2003 Front End server. You must do this because the credentials from the Exchange 2010 CAS server are passed to the Exchange 2003 Front End server by using a hidden form. This is designed to prevent the user from having to authenticate again.

In this scenario, when a user logs on, the following actions occur:

  1. The user connects to https://OWA.contoso.com/owa, and then authenticates by using the Forms-based authentication page that is presented by Exchange 2010.

  2. The Exchange 2010 CAS verifies the user’s Active Directory site, their Mailbox Version, the External URL. And. in this case, the Exchange 2003 URL value.

  3. The Exchange 2010 CAS then silently redirects the user to the legacy URL, and auto-populates the credentials that are provided in step 1 by using a hidden forms-based authentication page.

  4. The Exchange 2003 server authenticates the user silently, and provides the data to the user. This process permits a single sign-on process for the legacy users. In this scenario, the Exchange 2010 server is not a part of the process.

 
Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft