AD RMS Cryptographic Mode 2 and Exchange 2010 Information Rights Management

In Exchange 2010, we built the Active Directory Rights Management Services (AD RMS) integration functionality introduced in Exchange 2007 into a suite of information protection features known as Information Rights Management (IRM). IRM requires that you have an AD RMS server deployed in your on-premises organization. See Understanding Information Rights Management for more details, including functionality offered by the different IRM features and requirements for each. You can also use IRM features in your Exchange Online organization or a hybrid deployment.

When you install AD RMS, it’s in Cryptographic Mode 1. Cryptographic Mode 1 supports 1024-bit encryption keys for RSA encryption and 160-bit keys for SHA-1 hashing algorithm. To learn more about encryption in AD RMS, see RMS Encryption and Keys.

Late last year the Windows Server team released a significant update to AD RMS that supports a new mode of encryption known as Cryptographic Mode 2. Mode 2 supports stronger encryption by allowing you to use 2048-bit keys for RSA and 256-bit keys for SHA-1. Additionally, Mode 2 enables you to use the SHA-2 hashing algorithm. For more information about cryptographic modes in AD RMS, see Active Directory Rights Management Services Cryptographic Modes.

AD RMS Cryptographic Modes

This topic has not yet been rated - Rate this topic

Updated: March 2, 2012

Applies To: Windows Server 2008 R2 with SP1

There are two cryptographic modes that are available to Active Directory Rights Management Services (AD RMS) deployments with servers running on Windows Server 2008 R2 with Service Pack 1. When AD RMS is first installed Cryptographic Mode 1 is in use. In order to use the higher Cryptographic Mode 2, specific updates must be applied and administrative commands run. This document describes the cryptographic modes available to AD RMS. This document also describes the software prerequisites and administrative commands to enable Cryptographic Mode 2. The document consists of the following major sections.

• Cryptographic Modes
  
• Prerequisite Software and Updates
  
• Enabling Cryptographic Mode 2
  
• Questions and Answers
  

Cryptographic Modes

---

AD RMS supports two modes of cryptographic operation.

1. Cryptographic Mode 1 is the original AD RMS cryptographic implementation. It supports RSA 1024 for signature and encryption, and SHA-1 for signature. This mode continues to be supported by all current versions of AD RMS in release.
   
2. Cryptographic Mode 2 is an updated and enhanced AD RMS cryptographic implementation. It supports RSA 2048 for signature and encryption, and SHA-256 for signature.
   

When updated to run in Cryptographic Mode 2, AD RMS servers issue rights account certificates (RACs), client licensor certificates (CLCs) or user licenses (ULs) based on SHA-2/RSA 2048 only. Likewise, AD RMS servers updated to Cryptographic Mode 2 will accept only server licensor certificates (SLCs) and RACs based on SHA-2/RSA 2048. However, servers running in Cryptographic Mode 2 will continue to accept Publishing Licenses (PLs) previously issued using Cryptographic Mode 1 (SHA-1/RSA 1024).

Prerequisite Software and Updates

---

Only operating systems in the following list can support AD RMS Cryptographic Mode 2.

• AD RMS servers must be running Windows Server® 2008 R2 with Service Pack 1 (SP1)
  
• AD RMS client computers running one of the following operating systems
  
  
  • Windows® 7 with Service Pack 1 (SP1)
    
  • Windows Vista® with Service Pack 2 (SP2)
    
  • Windows Server® 2008 with Service Pack 2 (SP2)
    
  • Windows Server 2008 R2 with Service Pack 1 (SP1)
    

Both AD RMS client and server computers require software updates in order to be able to operate in Cryptographic Mode 2.

• AD RMS servers require update.
  
  For more information, see the following Knowledge Base (KB) article, RSA key length is increased to 2048 bits for AD RMS in Windows Server 2008 R2 and in Windows Server 2008 (Article ID 2627272).
  
• AD RMS client computers running on Windows 7 Service Pack 1 (SP1) require update.
  
  For more information, see the following Knowledge Base (KB) article, RSA key length is increased to 2048 bits for AD RMS in Windows 7 or in Windows Server 2008 R2 (Article ID 2627273).
  
• Exchange Server will require an update which is still currently under development. (For more information, see AD RMS Cryptographic Mode 2 and Exchange 2010 Information Rights Management.)
  
• Clients running Microsoft Office 2007 require update.
  
  For more information, see the following Knowledge Base (KB) article, Description of the 2007 Office system hotfix package (Mso-x-none.msp): August, 2011 (Article ID 2584040).
  
• Clients running Microsoft Office 2010 require update.
  
  For more information, see the following Knowledge Base (KB) article, Description of the Office 2010 hotfix package (Mso-x-none.msp): October 25, 2011 (Article ID 2596501).
  

Enabling Cryptographic Mode 2

---

The AD RMS administrator can use two different methods for updating to Cryptographic Mode 2, once the prerequisite software updates are implemented.

Warning
Enabling Cryptographic Mode 2 on clients and servers is a one-way upgrade. There is no supported method for reverting to the previous cryptographic mode once the higher level is enabled.

Phased Deployment

---

You should use a three phased approach transition to Cryptographic Mode 2. The recommended phases are described in the following list.

1. Preparation Phase
   
   
   1. Upgrade all Active Directory Rights Management Services client computers to support Cryptographic Mode 2. Clients could be a mixture of AD RMS client computers running different operating systems that you will need to patch to achieve the required level of support.
      
   2. Coordinate with your partners in other groups who you share AD RMS protected content with and agree on the dates of the checkpoints. Depending on your deployment the following preparations might also be required:
      
      
      1. If you have servers connected with a TUD, all servers involved must be updated and move to Cryptographic Mode 2 at the same time. See Enabling Cryptographic Mode 2 for TUDs in this document for more information.
         
      2. If you have servers connected with AD FS, the servers do not have to be updated, however, all clients in both forests must be upgraded.
         
   3. Upgrade all AD RMS servers to support Cryptographic Mode 2. If you are running server computers that operate earlier versions of RMS available prior to Windows Server 2008 R2 SP1, you should upgrade them to Windows Server 2008 R2 SP1 first to achieve the required level of support.
      
2. Transition Phase
   
   
   1. The transitioning phase can begin once all AD RMS servers and their clients are capable of Cryptographic Mode 2.
      
   2. Before your AD RMS servers are updated to use Cryptographic Mode 2, you should first create their Cryptographic Mode 2 keys so that these keys can be imported as TUDs in another forest.
      
   3. During this time, your content continues to be rights-protected using Cryptographic Mode 1.
      
3. Completing the Migration – Once all preparation is complete, the move to Cryptographic Mode 2 must be coordinated throughout the organization.
   

Enabling Cryptographic Mode 2 on Client Computers

---

AD RMS client computers running on the supported operating systems require only the software updates applied in order to support Cryptographic Mode 2. Upgraded AD RMS client computers can continue to function with AD RMS servers that have not yet been upgraded Cryptographic Mode 2.

Enabling Cryptographic Mode 2 on AD RMS Servers

---

To update AD RMS servers to Cryptographic Mode 2, you can use the AD RMS management console or Windows PowerShell.

• Using the AD RMS management console, you can choose to update existing AD RMS servers from Cryptographic Mode 1 to Cryptographic Mode 2 by doing the following:
  
  
  1. In the navigation pane, select the AD RMS server you want to upgrade.
     
  2. From the Action menu (or in the Actions pane), select the Update Crypto to Mode 2 option.
     
• Using Windows PowerShell, you can also choose to update an existing AD RMS server from Cryptographic Mode 1 to Cryptographic Mode 2.
  
  To update to Cryptographic Mode 2 using Windows PowerShell, you can use the following syntax:
  
  
  Update-ADRMS –UpdateCryptographicModeOnly –ServiceAccount <account> -force –NewCSPName <”Mode2 Supported CSP”> -Regen
  
  

  The following items apply to the parameters is the syntax
  
  
  • UpdateCryptographicModeOnly is the parameter that indicates that Cryptographic Mode 2 should be enabled. This is a one-way operation. Once complete, you cannot return the AD RMS server to Cryptographic Mode 1.
    
  • force is optional, which overrides the user prompt for confirmation.
    
  • NewCSPName indicates the cryptographic provider that you want to use for encryption. This is an optional setting and not needed if you are using password based protection. This can be any Cryptographic Mode 2 enabled cryptographic provider.
    
    As an example, if the AD RMS service account is named ADRMSSvc, you would open a Windows PowerShell prompt and run the following command to update the AD RMS server to Cryptographic Mode 2:
    
    
    Update-ADRMS –UpdateCryptographicModeOnly –ServiceAccount ADRMSSvc –NewCSPName “Microsoft Enhanced RSA and AES Cryptographic Provider”
    

Enabling Cryptographic Mode 2 for TUDs

---

If you are using a trusted user domain (TUD) between two AD RMS servers they both must be using the same cryptographic mode. For example, communication in support of a TUD relationship between a Cryptographic Mode 2 AD RMS server in one forest and a Cryptographic Mode 1 AD RMS server in another forest will not be possible. In order to keep the TUD relationship, administrators of both forests should communicate and coordinate the upgrade of the cryptographic mode.

1. Before either forest can move to Cryptographic Mode 2, all clients (or at least all clients that will exchange information), should be updated to support Cryptographic Mode 2.
   
2. Before an administrator moves one forest to Cryptographic Mode 2, they should generate the new SLC and export it.
   
3. The administrator in the partner forest should then import the updated Cryptographic Mode 2 SLC, which allows for the TUD to remain intact.
   
4. Once the decision is made to move to Cryptographic Mode 2, administrators in both forests should move AD RMS servers to Cryptographic Mode 2 at the same time. TUDs are unavailable for client information exchange until all the AD RMS servers in the forest are upgraded to Cryptographic Mode 2.
   

The command syntax to generate and export a new SLC is as follows:

Initialize-RmsCryptoMode2 -FilePath <filepath> -Regen

The following items apply to the parameters in the command syntax:

• Filepath can be any file location. The last name in the path becomes the file name.
  
• Regen is only used when the command has been run previously and you want to revise the key from the AD RMS database.
  

For example, to generate a new SLC that will be produced in the C:\certs\slcfabrikam, you would run the following command from a Windows PowerShell prompt:

Initialize-RmsCryptoMode2 –Filepath c:\certs\slcfabrikam.bin

To import an SLC, you can use the following syntax:

Import-RmsTUD -Path <AdRmsAdmin drive> -DisplayName <name> -SourceFile <SLCfile>

The following points apply to the parameters in the command syntax:

• Path is a mandatory parameter that will take an AD RMS Admin drive as described in Using Windows PowerShell to Administer AD RMS (http://technet.microsoft.com/library/ee221079.aspx). If you change directory to the AD RMS drive, then you can use a period (.) for <ADRmsAdmin drive>.
  
• SourceFile is the SLC file that was generated using the Initialize-RmsCryptoMode2 command.
  
• DisplayName is the display name for the TUD relationship.
  

For example, if you want to import an SLC file named slcfabrikam.xml that is located on an AD RMS drive named FabrikamRMSCluster in the folder TrustPolicy and the trusted user domain display name is Fabrikam, you would run the following command at a Windows PowerShell prompt:

Import-RmsTUD -Path FabrikamRMSCluster:\TrustPolicy -DisplayName Fabrikam -SourceFile slcfabrikam.bin

Cryptographic Mode 2 for TPDs

---

Trusted publishing domains (TPDs) are used to verify publishing licenses (PLs) for previously published content. No changes are required for TPDs in Cryptographic Mode 2. Cryptographic Mode 1 TPDs will continue to be honored for previously published content.

Questions and Answers

---

The following section contains anticipated questions and answers for administrators preparing to perform the upgrade from Cryptographic Mode 1 to Cryptographic Mode 2. The following sections cover each question and answer.

Why would I want to enable Cryptographic Mode 2?

---

National Institute of Standards and Technology (NIST) issued Special Publication 800-57 recommends the use of 2048-bit RSA keys starting January 1, 2011. United States Federal agencies are required to comply with NIST recommendations and many private enterprises and other countries may choose to implement this recommendation. To learn more, see NIST Special Publications (http://csrc.nist.gov/publications/PubsSPs.html).

What does this update look like for users?

---

The experience for users varies depending on if the conditions that are present:

• If the user is running an unpatched client device and receives Cryptographic Mode 2 content, they will receive an error. The error from the server will indicate that the cryptographic mode is erroneous. The exact message text displayed at the client depends upon the application returning the error. If this occurs, the client automatically restarts its boot strap process with the AD RMS server.
  
• If the user has existing Cryptographic Mode 1 end user licenses (EULs), the client must contact the server to get a Cryptographic Mode 2 EUL for that content. As long as the user is online and able to reach the AD RMS server, this operation should occur automatically and not require user input.
  

I have both AD RMS and RMS clients. How does this change look different depending on the operating system of the client involved?

---

Patches are available for AD RMS client computers only. RMS clients running Windows XP are not supported and must be replaced or upgraded to at least Windows Vista SP2 or later to be able to support the use of Cryptographic Mode 2. Specific patches to apply will depend on which version of the operating system is in use.

I have both AD RMS and RMS server. How does this change look different depending on the operating system of the server involved?

---

To support Cryptographic Mode 2 directly, you will need to update all AD RMS servers to Windows Server 2008 R2 SP1. You can choose to update servers to Cryptographic Mode 2 after you have completed operating system upgrades for all servers. Note that all clients must be updated before moving to Cryptographic Mode 2 and where multiple AD RMS servers are involved, all must move to Cryptographic Mode 2 at the same time. Otherwise, any servers that do not move to Cryptographic Mode 2 will be unable to participate until they are in the same mode.

How is this change managed differently if I am using AD FS with AD RMS?

---

In some situations, the purpose of TUDs can be replaced with a deployment of Active Directory Federation Services (AD FS), which will allow partners to continue to interoperate in different cryptographic modes. Under these circumstances, clients are able to use AD FS servers to access the updated AD RMS servers and changes in an AD FS supported trust are less involved.

If you are running a federated trust between forests using AD FS and have servers operating in two different cryptographic modes, the following considerations should help you to make appropriate planning decisions and understand the differences.

• Before either forest in a federated trust relationship supported by AD FS can move to Cryptographic Mode 2, all clients (or at least clients that will exchange information) need to be updated to support Cryptographic Mode 2.
  
• The AD RMS and AD FS servers in the second forest will not need to be patched or upgraded.
  
• The AD RMS servers moving to Cryptographic Mode 2 do not need to share SLCs with the other forest.
  
• Clients will get RACs from the publishing server, so this means that for cross-forest publishing, each client will get two independent RACs one from the publishing server in each forest.
  

How does this change affect existing Cryptographic Mode 1 licensed content or impact the pre-licensing agent?

---

Once a server is updated to Cryptographic Mode 2, all of the Cryptographic Mode 1 end user licenses (EULs) that each AD RMS client has licensed (either directly or via Exchange pre-licensing) will no longer be valid. In this situation, client devices will need to go back to the AD RMS server with the publishing license (PL), to obtain a Cryptographic Mode 2 EUL. As long as the user is online and able to reach the AD RMS server, this operation should occur automatically and not require user input.

How does this change affect AD RMS-aware applications such as Microsoft Office, Microsoft Exchange or Microsoft Office SharePoint Server?

---

All computers using AD RMS that run Microsoft Office 2007 and Microsoft Office 2010 installations must be updated. Cryptographic Mode 2 is not supported for versions of Microsoft Office prior to Microsoft Office 2007. If Microsoft Office installations are not updated they will continue to operate once computers are updated to Cryptographic Mode 2, however, ease of access to licensed content within Microsoft Office might be reduced by the additional inconvenience of error messages or dialog boxes that report on the client computer.

Exchange Server 2010 must be updated to support Cryptographic Mode 2. Exchange Server 2007 does not require updates in order to support Cryptographic Mode 2.

Microsoft Office SharePoint Server 2007 updating to Cryptographic Mode 2 should have no impact, although there might be a need to restart SharePoint services after updating your AD RMS deployment to use Cryptographic Mode 2.

How do these changes impact mobile devices such as those running Windows Mobile 6.x or Windows Phone 7?

---

Cryptographic Mode 2 is not supported for Windows Mobile 6.x. Devices running Windows Phone 7 should work seamlessly in Cryptographic Mode 2 without requiring additional updates.

Is there backwards compatibility for clients that have not been updated to mode 2?

---

No. To enable backwards compatibility for clients that have not been updated to support mode 2 cryptography would allow users with weaker keys to access content, introducing a weak link in the security chain and potentially defeating the benefits of the enhanced cryptographic strength that mode 2 provides for AD RMS.

Is there backwards compatibility for content that was originally protected using mode 1 cryptography?

---

Yes. A mode 1 trusted publishing domain (TPD) is automatically imported during the mode 2 update process. This enables all existing content that was originally published under mode 1 to continue to be accessible after update to mode 2. }

Cryptographic Mode 2 fulfills cryptography requirements of United States federal government agencies, as recommended by the National Institute of Standards and Technology (NIST). See NIST publication SP 800-57 for details. Many other government and private organizations across the world also follow NIST recommendations. In Windows Server "8" Beta, Cryptographic Mode 2 is the default AD RMS cryptography mode.

Enabling Cryptographic Mode 2 on clients and servers is a one-way upgrade. There is no supported method for reverting to the previous cryptographic mode once the higher level is enabled.

Exchange 2010 IRM features are not compatible with Cryptographic Mode 2 at this time. Switching to this mode may result in loss of IRM functionality. If Exchange 2010’s IRM features are critical for your organization, we recommend that you not switch your AD RMS clusters to Cryptographic Mode 2.

IMPORTANT: Cryptographic Mode 2 support is not planned for Exchange Online. Exchange Online customers using on-premises AD RMS servers for IRM should not enable Cryptographic Mode 2.

We’re working on an update for Exchange 2010 that’ll enable the use of Cryptographic Mode 2 on AD RMS.

Read More

ISA 2006 SP1 Configuration with Exchange 2010

While ISA 2006 SP1 includes a Client Access Web Publishing Wizard for both Exchange 2003 and Exchange 2007, the wizard does not have any knowledge of Exchange 2010. Exchange 2010 includes the following changes with respect to its URLs and virtual directories:

• Exchange 2010 Client Access Servers (CAS) no longer utilize the /exchweb virtual directory.

• Exchange 2010 CAS no longer utilizes the /unifiedmessaging virtual directory.

• Exchange 2010 CAS provides a new solution for managing end user configuration (e.g. Unified Messaging settings), end user self-service (e.g. message tracking), and organization-specific activities (e.g. records discovery), known as the Exchange Control Panel. This service is provided via the /ecp virtual directory and is accessible directly or through Outlook Web App.

• Exchange 2010 CAS does not render data from legacy mailboxes. Instead, depending on the protocol and/or client, Exchange 2010 CAS will either proxy, redirect, or provide direct access to the appropriate version of Exchange (Exchange 2003 Front-End, Exchange 2007 CAS, or Exchange 2003/2007 Mailbox). Redirected clients access their information via a new namespace, legacy.contoso.com. For more information, please see the post entitled, Transitioning Client Access to Exchange 2010.

Enabling External Access when Upgrading an Exchange 2003 Environment to Exchange 2010 via ISA

• On the Authentication tab:

• For ISA Pre-Authentication, the Client Authentication Method is configured as "HTML Form Authentication" and the authentication validation method is configured either with Windows (if ISA is domain-joined), LDAP, or RADIUS.

• For scenarios without ISA Pre-Authentication, the Client Authentication Method is set to "No Authentication".

• On the certificates tab, a certificate is selected that has a principal name of mail.contoso.com

• On the Web Farm tab, requests are forwarded to the "Exchange 2003 Front-End Web Farm" and the internal site name is "mail.contoso.com", utilizing cookie-based load balancing affinity.

• The Public name is defined as "mail.contoso.com", which must resolve to a valid internal IP address.

• The Authentication Delegation is set to

• For scenarios leveraging ISA Pre-Authentication, one of the following is set: "Basic Authentication", "Negotiate (Kerberos/NTLM)", or "Kerberos Constrained Delegation". Please note that the authentication method you select may require additional configuration; please see your ISA documentation for more information.

• For scenarios without ISA Pre-Authentication: "No delegation, but client may authenticate directly".

• The Paths are defined as:

• /public/*

• /exchange/*

• /exchweb/*

• On the Web Farm tab, requests are forwarded to the "Exchange 2003 Front-End Web Farm" and the internal site name is "mail.contoso.com", utilizing IP-based load balancing affinity.

• The Public name is defined as "mail.contoso.com", which must resolve to a valid internal IP address.

• The Authentication Delegation is set to

• For scenarios leveraging ISA Pre-Authentication, one of the following is set: "Basic Authentication", "Negotiate (Kerberos/NTLM)", or "Kerberos Constrained Delegation". Please note that the authentication method you select may require additional configuration; please see your ISA documentation for more information.

• For scenarios without ISA Pre-Authentication: "No delegation, but client may authenticate directly".

• The Paths are defined as:

• /rpc/*

• /Microsoft-Server-ActiveSync/*

1. The /exchange OWA virtual directory has been configured with Basic Authentication and/or Windows Integrated Authentication and not Forms Based Authentication.

1. SSL is required.

As a result of these changes, certain modifications must be made to the rules created by the Client Access Web Publishing Wizard to support Exchange 2010. This article, the final one in my upgrade series, will discuss how to configure ISA 2006 SP1 as part of your deployment of Exchange 2010 in your existing Exchange 2003 or Exchange 2007 environments so that you may successfully allow your clients to connect to both Exchange versions.

Note: For more information on the detailed steps required to support coexistence process see my first blog article in the series, within the Deployment Assistant.

While this article will not cover every scenario possible (e.g. specifics on each authentication solution), it will provide basic steps that you can follow to ensure you have a successful deployment.

Prior to implementing Exchange 2010, it is assumed that you have two ISA2006 web publishing rules for your Exchange 2003 environment that allow OWA, Outlook Anywhere, and ActiveSync. ISA is configured as follows:

1. A web listener configured as follows:

2. A web farm configured for the Exchange 2003 Front-End server exists.

3. The Exchange 2003 OWA web publishing rule (henceforth known as E2003 OWA) is configured through the ISA Server Exchange Web Client Access Publishing wizard with the following settings:

4. The Exchange 2003 Outlook Anywhere (OA) / ActiveSync web publishing rule(henceforth known as E2003 OA-EAS) is configured through the ISA Server Exchange Web Client Access Publishing wizard with the following settings:

In addition if utilizing ISA Pre-Authentication, the Exchange 2003 Front-End Servers are configured as follows:

For the purposes of this discussion, assume that you deploy Exchange 2010 into an Exchange 2003 environment that resembles the following:

Note: The environment depicted above assumes that a split-brain DNS infrastructure has been implemented. This is also known as split-horizon DNS, split-view DNS or split DNS. In short, split-brain DNS is about setting up separate "DNS Zones" so that DNS requests which come from intranet clients will get different DNS hostname->IP lookup answers than requests coming from Internet clients. In other words, if a client within the internal network attempts to resolve mail.contoso.com, the client will get the IP address associated with the CAS2010 array or the internal interface of ISA; whereas, if an external client attempts to resolve mail.contoso.com, the client will get the IP address associated with external interface of the ISA2006 server.

The following steps need to be performed in order to allow clients to connect either to legacy.contoso.com or mail.contoso.com:

Note: The below steps correspond with the Exchange 2003 Upgrade Steps 8-12 in the article http://msexchangeteam.com/archive/2009/11/20/453272.aspx.

1. Either export the certificate that is installed on CAS2010 or obtain a new certificate from a commercial certificate authority for ISA2006.

• To export the certificate from CAS2010, execute the following cmdlet (note: In order to export the certificate, during the certificate creation, the must have been set to $true): Export-ExchangeCertificate <thumbprint> -path c:\cascert.pfx -password (Get-Credential).password
• If you are obtaining a new commercial certificate for ISA2006, as a best practice, Microsoft recommends utilizing a certificate that supports Subject Alternative Names; however, you can utilize a wildcard certificate as well. If you choose to use a wildcard certificate there are some additional complexities to consider: For example, Windows Mobile 5.0 devices do not support wildcard certificates, and Outlook Anywhere requires special additional configuration as detailed inhttp://technet.microsoft.com/en-us/library/cc535023.aspx.

This commercial certificate that will be leveraged by external clients will contain at a minimum three SAN values (note that other scenarios may require you to add additional values):

•  
  • mail.contoso.com (your primary OWA/EAS/OA access URL)
  • autodiscover.contoso.com
  • legacy.contoso.com (your OWA/EAS namespace for legacy mailbox access)

Prior to Windows Vista SP1, the Windows RPC/HTTP client-side component required that the Subject Name (aka Common Name) on the certificate match the "Certificate Principal Name" configured for the Outlook Anywhere connection in the Outlook profile. Therefore, as a best practice, you should ensure that mail.contoso.com is listed as the Subject Name in your certificate unless you plan on changing the configuration which can be achieved by using the Set-OutlookProvider cmdlet with the EXPR parameter as described in http://msexchangeteam.com/archive/2008/09/29/449921.aspx.

2. Import the certificate into the ISA2006 by following the steps at http://technet.microsoft.com/en-us/library/bb794751.aspx#import.

3. Update the web listener (henceforth known as the CAS web listener) that is used to publish your Exchange 2003 Front-End infrastructure to utilize the new certificate:

• Open the ISA 2006 Management Console.
• Navigate to your Firewall Policy settings.
• From within the Toolbox pane, expand Web Listeners and double-click on the listener responsible for your Exchange 2003 Front-End infrastructure.
  • Click on the Certificates tab and click Select Certificates.
    • Verify the certificate you recently imported is listed and its validity is "Valid". Select it and click Select.
  • If leveraging ISA Pre-Authentication, click on the SSO tab.
    • Click on the check box to "Enable Single Sign On".
    • Click Add and enter ".contoso.com" (please note the leading period).
  • Click OK.
• Apply the changes to ISA2006.

4. Create the legacy host record (legacy.contoso.com) in your external DNS infrastructure and assign it an IP address that is bound to the ISA2006 external NIC.

5. Create the Autodiscover host record (autodiscover.contoso.com) in your external DNS infrastructure and assign it an IP address that is bound to the ISA2006 external NIC.

6. On ISA2006, you will create the CAS2010 web farm.

• Open the ISA 2006 Management Console.
• Navigate to your Firewall Policy settings.
• From within the Toolbox pane, click New and select Server Farm.
  • Label the server farm accordingly and click Next.
  • Add the CAS2010 servers either by server FQDN (if name resolution is available) or by IP address (cannot be used with Kerberos Constrained Delegation) and click Next.
  • For server farm connectivity monitoring, utilize the preferred default method, or choose a method that is appropriate for your environment and click Next.
  • Click Finish.

7. If leveraging ISA Pre-Authentication, on Exchange 2010 CAS within the "Internet Facing AD Site", you will disable forms-based authentication by executing the following cmdlets:

• Set-OWAVirtualDirectory cas2010\OWA* -BasicAuthentication $true -WindowsAuthentication $true
• Set-ECPVirtualDirectory cas2010\ECP* -BasicAuthentication $true -WindowsAuthentication $true

8. On ISA2006, you will create the OWA and Autodiscover web publishing rules that will be leveraged by Outlook Anywhere, ActiveSync and Web Services clients utilizing the mail.contoso.com namespace.

• Open the ISA 2006 Management Console.
• Navigate to your Firewall Policy settings.
• From within the Tasks pane, click Publish Exchange Web Client Access.
  • Enter a name like "E2010 OWA" and click Next.
  • For Exchange version, select "Exchange Server 2007" and select "Outlook Web Access" and click Next.
  • Select "Publish a server farm of load balanced Web servers" and click Next.
  • Select "Use SSL to connect to the published Web server or server farm" and click Next.
  • For internal site name, enter "mail.contoso.com" and click Next.
  • Select the Exchange 2010 server farm and click Next.
  • For the public name, enter "mail.contoso.com" and click Next.
  • Select the CAS web listener and click Next.
  • For authentication delegation:
    • For scenarios leveraging ISA Pre-Authentication select one of the following: "Basic Authentication", "Negotiate (Kerberos/NTLM)", or "Kerberos Constrained Delegation". Please note that the authentication method you select may require additional configuration; please see your ISA documentation for more information.
    • For scenarios without ISA Pre-Authentication select, "No delegation, but client may authenticate directly" and click Next.
  • Choose the appropriate users and click Next.
  • Click Finish.
• From within the Tasks pane, click Publish Exchange Web Client Access.
  • Enter a name like "E2010 EAS" and click Next.
  • For Exchange version, select "Exchange Server 2007" and select "Exchange ActiveSync" and click Next.
  • Select "Publish a server farm of load balanced Web servers" and click Next.
  • Select "Use SSL to connect to the published Web server or server farm" and click Next.
  • For internal site name, enter "mail.contoso.com" and click Next.
  • Select the Exchange 2010 server farm and click Next.
  • For the public name, enter "mail.contoso.com" and click Next.
  • Select the CAS web listener and click Next.
  • For authentication delegation:
    • For scenarios leveraging ISA Pre-Authentication select one of the following: "Basic Authentication", "Negotiate (Kerberos/NTLM)", or "Kerberos Constrained Delegation". Please note that the authentication method you select may require additional configuration; please see your ISA documentation for more information.
    • For scenarios without ISA Pre-Authentication select, "No delegation, but client may authenticate directly" and click Next.
  • Choose the appropriate users and click Next.
  • Click Finish.
• From within the Tasks pane, click Publish Exchange Web Client Access.
  • Enter a name like "Autodiscover-OA" and click Next.
  • For Exchange version, select "Exchange Server 2007" and select "Outlook Anywhere (RPC/HTTP(s))" and select "Publish additional folders on the Exchange Server for Outlook 2007 clients" and click Next.
  • Select "Publish a server farm of load balanced Web servers" and click Next.
  • Select "Use SSL to connect to the published Web server or server farm" and click Next.
  • For internal site name, enter "mail.contoso.com" and click Next.
  • Select the Exchange 2010 server farm and click Next.
  • For the public name, enter "Autodiscover.contoso.com" and click Next.
  • Select the CAS web listener and click Next.
  • For authentication delegation:
    • For scenarios leveraging ISA Pre-Authentication select one of the following: "Basic Authentication", "Negotiate (Kerberos/NTLM)", or "Kerberos Constrained Delegation". Please note that the authentication method you select may require additional configuration; please see your ISA documentation for more information.
    • For scenarios without ISA Pre-Authentication select, "No delegation, but client may authenticate directly" and click Next.
  • Choose the appropriate users and click Next.
  • Click Finish.
• Open the Autodiscover-OA web publishing rule you just created.
  • On the General tab, uncheck the "Enable" setting. That way this rule will not go into effect until you change the external DNS mappings.
  • Click on the Public Name tab and add "mail.contoso.com" as another web site entry.
  • Click on the Paths tab and add the following:
    • /ecp/*
  • Click OK.
• Open the E2010 EAS web publishing rule you just created.
• On the General tab, uncheck the "Enable" setting. That way this rule will not go into effect until you change the external DNS mappings.
• Open the E2010 OWA web publishing rule you just created.
• On the General tab, uncheck the "Enable" setting. That way this rule will not go into effect until you change the external DNS mappings.
  • Click on the Paths tab:
    • Add: /ecp/*
    • Remove: /exchweb/*
  • Click OK.
• Apply the changes to ISA.

9. On ISA2006, you will create the legacy web publishing rules that will be leveraged by Outlook Web Access, Outlook Anywhere, and ActiveSync clients utilizing the legacy.contoso.com namespace.

• Open the ISA 2006 Management Console.
• Navigate to your Firewall Policy settings.
• From within the Tasks pane, click Publish Exchange Web Client Access.
  • Enter a name like "Legacy OWA" and click Next.
  • For Exchange version, select "Exchange Server 2003" and select "Outlook Web Access" and click Next.
  • Select "Publish a server farm of load balanced Web servers" and click Next.
  • Select "Use SSL to connect to the published Web server or server farm" and click Next.
  • For internal site name, enter "legacy.contoso.com" and click Next.
  • Select the Exchange 2003 server farm and click Next.
  • For the public name, enter "legacy.contoso.com" and click Next.
  • Select the CAS web listener and click Next.
  • For authentication delegation:
    • For scenarios leveraging ISA Pre-Authentication select one of the following: "Basic Authentication", "Negotiate (Kerberos/NTLM)", or "Kerberos Constrained Delegation". Please note that the authentication method you select may require additional configuration; please see your ISA documentation for more information.
    • For scenarios without ISA Pre-Authentication select, "No delegation, but client may authenticate directly" and click Next.
  • Choose the appropriate users and click Next.
  • Click Finish.
• From within the Tasks pane, click Publish Exchange Web Client Access.
  • Enter a name like "Legacy OA-EAS" and click Next.
  • For Exchange version, select "Exchange Server 2003" and select "Outlook RPC/HTTP(s)" and "Exchange ActiveSync" and click Next.
  • Select "Publish a server farm of load balanced Web servers" and click Next.
  • Select "Use SSL to connect to the published Web server or server farm" and click Next.
  • For internal site name, enter "legacy.contoso.com" and click Next.
  • Select the Exchange 2003 server farm and click Next.
  • For the public name, enter "legacy.contoso.com" and click Next.
  • Select the CAS web listener and click Next.
  • For authentication delegation:
    • For scenarios leveraging ISA Pre-Authentication select one of the following: "Basic Authentication", "Negotiate (Kerberos/NTLM)", or "Kerberos Constrained Delegation". Please note that the authentication method you select may require additional configuration; please see your ISA documentation for more information.
    • For scenarios without ISA Pre-Authentication select, "No delegation, but client may authenticate directly" and click Next.
  • Choose the appropriate users and click Next.
  • Click Finish.
• Open the web publishing rules you just created and uncheck the "Enable" setting on the General tab. That way these rules will not go into effect until you change the external DNS mappings.
• Apply the changes to ISA.

10. Schedule downtime for your Internet clients (this will be a small outage window).

• Open the ISA 2006 Management Console.
• Navigate to your Firewall Policy settings.
• For the following web publishing rules, enable them by checking the "Enable" setting on the General tab:
  • Legacy OA-EAS
  • Legacy OWA
  • E2010 Autodiscover-OA
  • E2010 OWA
  • E2010 EAS
• For the following web publishing rules, disable them by un-checking the "Enable" setting on the General tab:
  • E2003 OWA
  • E2003 OA-EAS
• Apply the changes to ISA (note: might want to restart the Microsoft Firewall service so that the changes are immediate and potentially flush the DNS cache).
• Test with Internet clients and ensure they can still access their mailboxes.

Enabling External Access when Upgrading an Exchange 2007 Environment to Exchange 2010 via ISA

Prior to implementing Exchange 2010, it is assumed that you have two ISA2006 web publishing rules for your Exchange 2007 environment that allow OWA, Outlook Anywhere, and ActiveSync. ISA is configured as follows:

1. A web listener configured as follows:

• On the Authentication tab:
  • For ISA Pre-Authentication, the Client Authentication Method is configured as "HTML Form Authentication" and the authentication validation method is configured either with Windows (if ISA is domain-joined), LDAP, or RADIUS.
  • For scenarios without ISA Pre-Authentication, the Client Authentication Method is set to "No Authentication".
• On the certificates tab, a certificate is selected that has a principal name of mail.contoso.com.

2. A web farm configured for the Exchange 2007 CAS exists.

3. The Exchange 2007 OWA web publishing rule (henceforth known as E2007 OWA) is configured through the ISA Server Exchange Web Client Access Publishing wizard with the following settings:

• On the Web Farm tab, requests are forwarded to the "Exchange 2007 CAS Web Farm" and the internal site name is "mail.contoso.com", utilizing cookie-based load balancing affinity.
• The Public name is defined as "mail.contoso.com", which must resolve to a valid internal IP address.
• The Authentication Delegation is set to:
  • For scenarios leveraging ISA Pre-Authentication, one of the following is set: "Basic Authentication", "Negotiate (Kerberos/NTLM)", or "Kerberos Constrained Delegation". Please note that the authentication method you select may require additional configuration; please see your ISA documentation for more information.
  • For scenarios without ISA Pre-Authentication: "No delegation, but client may authenticate directly".
• The Paths are defined as:
  • /public/*
  • /exchange/*
  • /exchweb/*
  • /owa/*

4. The Exchange 2007 EAS web publishing rule (henceforth known as E2007 EAS) is configured through the ISA Server Exchange Web Client Access Publishing wizard with the following settings:

• On the Web Farm tab, requests are forwarded to the "Exchange 2007 CAS Web Farm" and the internal site name is "mail.contoso.com", utilizing IP-bsaed load balancing affinity.
• The Public name is defined as "mail.contoso.com", which must resolve to a valid internal IP address.
• The Authentication Delegation is set to:
  • For scenarios leveraging ISA Pre-Authentication, one of the following is set: "Basic Authentication", "Negotiate (Kerberos/NTLM)", or "Kerberos Constrained Delegation". Please note that the authentication method you select may require additional configuration; please see your ISA documentation for more information.
  • For scenarios without ISA Pre-Authentication: "No delegation, but client may authenticate directly".
• The Paths are defined as:
  • /Microsoft-Server-Activesync/*

5. The Exchange 2007 Outlook Anywhere (OA web publishing rule (henceforth known as E2007 OA) is configured through the ISA Server Exchange Web Client Access Publishing wizard with the following settings:

• On the Web Farm tab, requests are forwarded to the "Exchange 2007 CAS Web Farm" and the internal site name is "mail.contoso.com", utilizing IP-based load balancing affinity.
• The Public name is defined with "Autodiscover.contoso.com" and "mail.contoso.com
• The Authentication Delegation is set to:
  • For scenarios leveraging ISA Pre-Authentication, one of the following is set: "Basic Authentication", "Negotiate (Kerberos/NTLM)", or "Kerberos Constrained Delegation". Please note that the authentication method you select may require additional configuration; please see your ISA documentation for more information.
  • For scenarios without ISA Pre-Authentication: "No delegation, but client may authenticate directly".
• The Paths are defined as:
  • /rpc/*
  • /OAB/*
  • /UnifiedMessaging/*
  • /Autodiscover/*
  • /EWS/*

In addition if utilizing ISA Pre-Authentication, Exchange 2007 CAS array members are configured as follows:

1. The /owa virtual directory has been configured with Basic Authentication and not Forms Based Authentication.
2. SSL is required.

For the purposes of this discussion, assume that you deploy Exchange 2010 into an Exchange 2007 environment that resembles the following:

Note: The environment depicted above assumes that a split-brain DNS infrastructure has been implemented. This is also known as split-horizon DNS, split-view DNS or split DNS. In short, split-brain DNS is about setting up separate "DNS Zones" so that DNS requests which come from intranet clients will get different DNS hostname->IP lookup answers than requests coming from Internet clients. In other words, if a client within the internal network attempts to resolve mail.contoso.com, the client will get the IP address associated with the CAS2010 array or the internal interface of ISA; whereas, if an external client attempts to resolve mail.contoso.com, the client will get the IP address associated with external interface of the ISA2006 server.

The following steps need to be performed in order to allow clients to connect either to legacy.contoso.com or mail.contoso.com:

Note: The below steps correspond with the Exchange 2007 Upgrade Steps 9-12 in the article http://msexchangeteam.com/archive/2009/11/20/453272.aspx.

1. Either export the certificate that is installed on CAS2010 or obtain a new certificate from a commercial certificate authority for ISA2006.

• To export the certificate from CAS2010, execute the following cmdlet (note: In order to export the certificate, during the certificate creation, the must have been set to $true): Export-ExchangeCertificate <thumbprint> -path c:\cascert.pfx -password (Get-Credential).password
• If you are obtaining a new commercial certificate for ISA2006, as a best practice, Microsoft recommends utilizing a certificate that supports Subject Alternative Names; however, you can utilize a wildcard certificate as well. If you choose to use a wildcard certificate there are some additional complexities to consider: For example, Windows Mobile 5.0 devices do not support wildcard certificates, and Outlook Anywhere requires special additional configuration as detailed inhttp://technet.microsoft.com/en-us/library/cc535023.aspx.

This commercial certificate that will be leveraged by external clients will contain at a minimum three SAN values (note that other scenarios may require you to add additional values):

•  
  • mail.contoso.com (your primary OWA/EAS/OA access URL)
  • autodiscover.contoso.com
  • legacy.contoso.com (your OWA/EAS namespace for legacy mailbox access)

Prior to Windows Vista SP1, the Windows RPC/HTTP client-side component required that the Subject Name (aka Common Name) on the certificate match the "Certificate Principal Name" configured for the Outlook Anywhere connection in the Outlook profile. Therefore, as a best practice, you should ensure that mail.contoso.com is listed as the Subject Name in your certificate unless you plan on changing the configuration which can be achieved by using the Set-OutlookProvider cmdlet with the EXPR parameter as described in http://msexchangeteam.com/archive/2008/09/29/449921.aspx.

2. Import the certificate into the ISA2006 by following the steps at http://technet.microsoft.com/en-us/library/bb794751.aspx#import.

3. Update the web listener (henceforth known as the CAS web listener) that is used to publish your Exchange 2007 CAS infrastructure to utilize the new certificate:

• Open the ISA 2006 Management Console.
• Navigate to your Firewall Policy settings.
• From within the Toolbox pane, expand Web Listeners and double-click on the listener responsible for your Exchange 2007 CAS infrastructure.
  • Click on the Certificates tab and click Select Certificates.
    • Verify the certificate you recently imported is listed and its validity is "Valid". Select it and click Select.
  • If leveraging ISA Pre-Authentication, click on the SSO tab.
    • Click on the check box to "Enable Single Sign On".
    • Click Add and enter ".contoso.com" (please note the leading period).
  • Click OK.
• d. Apply the changes to ISA2006.

4. Create the legacy host record (legacy.contoso.com) in your external DNS infrastructure and assign it an IP address that is bound to the ISA2006 external NIC.

5. On ISA2006, you will create the CAS2010 web farm.

• Open the ISA 2006 Management Console.
• Navigate to your Firewall Policy settings.
• From within the Toolbox pane, click New and select Server Farm.
  • Label the server farm accordingly and click Next.
  • Add the CAS2010 servers either by server FQDN (if name resolution is available) or by IP address (cannot be used with Kerberos Constrained Delegation) and click Next.
  • For server farm connectivity monitoring, utilize the preferred default method, or choose a method that is appropriate for your environment and click Next.
  • Click Finish.

6. If leveraging ISA Pre-Authentication, on Exchange 2010 CAS within the "Internet Facing AD Site", you will disable forms-based authentication by executing the following cmdlets:

• Set-OWAVirtualDirectory cas2010\OWA* -BasicAuthentication $true -WindowsAuthentication $true
• Set-ECPVirtualDirectory cas2010\ECP* -BasicAuthentication $true -WindowsAuthentication $true

7. On ISA2006, you will create the Exchange 2010 OWA and Autodiscover web publishing rules that will be leveraged by Outlook Anywhere, ActiveSync and Web Services clients utilizing the mail.contoso.com namespace.

• Open the ISA 2006 Management Console.
• Navigate to your Firewall Policy settings.
• From within the Tasks pane, click Publish Exchange Web Client Access.
  • Enter a name like "E2010 OWA" and click Next.
  • For Exchange version, select "Exchange Server 2007" and select "Outlook Web Access" and click Next.
  • Select "Publish a server farm of load balanced Web servers" and click Next.
  • Select "Use SSL to connect to the published Web server or server farm" and click Next.
  • For internal site name, enter "mail.contoso.com" and click Next.
  • Select the Exchange 2010 server farm and click Next.
  • For the public name, enter "mail.contoso.com" and click Next.
  • Select the CAS web listener and click Next.
  • For authentication delegation:
    • For scenarios leveraging ISA Pre-Authentication select one of the following: "Basic Authentication", "Negotiate (Kerberos/NTLM)", or "Kerberos Constrained Delegation". Please note that the authentication method you select may require additional configuration; please see your ISA documentation for more information.
    • For scenarios without ISA Pre-Authentication select, "No delegation, but client may authenticate directly" and click Next.
  • Choose the appropriate users and click Next.
  • Click Finish.
  • Click Finish.
• From within the Tasks pane, click Publish Exchange Web Client Access.
  • Enter a name like "E2010 EAS" and click Next.
  • For Exchange version, select "Exchange Server 2007" and select "Exchange ActiveSync" and click Next.
  • Select "Publish a server farm of load balanced Web servers" and click Next.
  • Select "Use SSL to connect to the published Web server or server farm" and click Next.
  • For internal site name, enter "mail.contoso.com" and click Next.
  • Select the Exchange 2010 server farm and click Next.
  • For the public name, enter "mail.contoso.com" and click Next.
  • Select the CAS web listener and click Next.
  • For authentication delegation:
    • For scenarios leveraging ISA Pre-Authentication select one of the following: "Basic Authentication", "Negotiate (Kerberos/NTLM)", or "Kerberos Constrained Delegation". Please note that the authentication method you select may require additional configuration; please see your ISA documentation for more information.
    • For scenarios without ISA Pre-Authentication select, "No delegation, but client may authenticate directly" and click Next.
  • Choose the appropriate users and click Next.
  • Click Finish.
• From within the Tasks pane, click Publish Exchange Web Client Access.
  • Enter a name like "E2010 Autodiscover-OA" and click Next.
  • For Exchange version, select "Exchange Server 2007" and select "Outlook Anywhere (RPC/HTTP(s))" and select "Publish additional folders on the Exchange Server for Outlook 2007 clients" and click Next.
  • Select "Publish a server farm of load balanced Web servers" and click Next.
  • Select "Use SSL to connect to the published Web server or server farm" and click Next.
  • For internal site name, enter "mail.contoso.com" and click Next.
  • Select the Exchange 2010 server farm and click Next.
  • For the public name, enter "Autodiscover.contoso.com" and click Next.
  • Select the CAS web listener and click Next.
  • For authentication delegation:
    • For scenarios leveraging ISA Pre-Authentication select one of the following: "Basic Authentication", "Negotiate (Kerberos/NTLM)", or "Kerberos Constrained Delegation". Please note that the authentication method you select may require additional configuration; please see your ISA documentation for more information.
    • For scenarios without ISA Pre-Authentication select, "No delegation, but client may authenticate directly" and click Next.
  • Choose the appropriate users and click Next.
  • Click Finish.
• Open the "E2010 Autodiscover-OA" web publishing rule you just created.
  • On the General tab, uncheck the "Enable" setting. That way this rule will not go into effect until you change the external DNS mappings.
  • Click on the Public Name tab and add "mail.contoso.com" as another web site entry.
  • Click on the Paths tab and add the following:
    • /ecp/*
  • Click OK.
• Open the "E2010 EAS" web publishing rule you just created.
  • On the General tab, uncheck the "Enable" setting. That way this rule will not go into effect until you change the external DNS mappings.
• Open the "E2010 OWA" web publishing rule you just created.
  • On the General tab, uncheck the "Enable" setting. That way this rule will not go into effect until you change the external DNS mappings.
  • Click on the Paths tab:
    • Add: /ecp/*
    • Remove: /exchweb/*
  • Click OK.
• Apply the changes to ISA.

8. On ISA2006, you will create the legacy web publishing rules that will be leveraged by Outlook Web Access, Outlook Anywhere, and ActiveSync clients utilizing the legacy.contoso.com namespace.

• Open the ISA 2006 Management Console.
• Navigate to your Firewall Policy settings.
• From within the Tasks pane, click Publish Exchange Web Client Access.
  • Enter a name like "Legacy OWA" and click Next.
  • For Exchange version, select "Exchange Server 2007" and select "Outlook Web Access" and click Next.
  • Select "Publish a server farm of load balanced Web servers" and click Next.
  • Select "Use SSL to connect to the published Web server or server farm" and click Next.
  • For internal site name, enter "legacy.contoso.com" and click Next.
  • Select the Exchange 2007 CAS server farm and click Next.
  • For the public name, enter "legacy.contoso.com" and click Next.
  • Select the CAS web listener and click Next.
  • For authentication delegation:
    • For scenarios leveraging ISA Pre-Authentication select one of the following: "Basic Authentication", "Negotiate (Kerberos/NTLM)", or "Kerberos Constrained Delegation". Please note that the authentication method you select may require additional configuration; please see your ISA documentation for more information.
    • For scenarios without ISA Pre-Authentication select, "No delegation, but client may authenticate directly" and click Next.
  • Choose the appropriate users and click Next.
  • Click Finish.
• From within the Tasks pane, click Publish Exchange Web Client Access.
  • Enter a name like "Legacy EAS" and click Next.
  • For Exchange version, select "Exchange Server 2007" and select "Exchange ActiveSync" and click Next.
  • Select "Publish a server farm of load balanced Web servers" and click Next.
  • Select "Use SSL to connect to the published Web server or server farm" and click Next.
  • For internal site name, enter "legacy.contoso.com" and click Next.
  • Select the Exchange 2007 CAS server farm and click Next.
  • For the public name, enter "legacy.contoso.com" and click Next.
  • Select the CAS web listener and click Next.
  • For authentication delegation:
    • For scenarios leveraging ISA Pre-Authentication select one of the following: "Basic Authentication", "Negotiate (Kerberos/NTLM)", or "Kerberos Constrained Delegation". Please note that the authentication method you select may require additional configuration; please see your ISA documentation for more information.
    • For scenarios without ISA Pre-Authentication select, "No delegation, but client may authenticate directly" and click Next.
  • Choose the appropriate users and click Next.
  • Click Finish.
• From within the Tasks pane, click Publish Exchange Web Client Access.
  • Enter a name like "Legacy OA" and click Next.
  • For Exchange version, select "Exchange Server 2007" and select "Outlook Anywhere (RPC/HTTP(s))" and select "Publish additional folders on the Exchange Server for Outlook 2007 clients" and click Next.
  • Select "Publish a server farm of load balanced Web servers" and click Next.
  • Select "Use SSL to connect to the published Web server or server farm" and click Next.
  • For internal site name, enter "legacy.contoso.com" and click Next.
  • Select the Exchange 2007 CAS server farm and click Next.
  • For the public name, enter "legacy.contoso.com" and click Next.
  • Select the CAS web listener and click Next.
  • For authentication delegation:
    • For scenarios leveraging ISA Pre-Authentication select one of the following: "Basic Authentication", "Negotiate (Kerberos/NTLM)", or "Kerberos Constrained Delegation". Please note that the authentication method you select may require additional configuration; please see your ISA documentation for more information.
    • For scenarios without ISA Pre-Authentication select, "No delegation, but client may authenticate directly" and click Next.
  • Choose the appropriate users and click Next.
  • Click Finish.
• Open the "Legacy OA" web publishing rule you just created.
  • On the General tab, uncheck the "Enable" setting. That way this rule will not go into effect until you change the external DNS mappings.
  • Click on the Paths tab:
    • Remove: /Autodiscover/*
  • Click OK.
• Open the "Legacy OWA" web publishing rule you just created and uncheck the "Enable" setting on the General tab. That way this rule will not go into effect until you change the external DNS mappings.
• Open the "Legacy EAS" web publishing rule you just created and uncheck the "Enable" setting on the General tab. That way this rule will not go into effect until you change the external DNS mappings.
  • Apply the changes to ISA.

9. Schedule downtime for your Internet clients (this will be a small outage window).

• Open the ISA 2006 Management Console.
• Navigate to your Firewall Policy settings.
• For the following web publishing rules, enable them by checking the "Enable" setting on the General tab:
  • Legacy OA
  • Legacy OWA
  • Legacy EAS
  • E2010 Autodiscover-OA
  • E2010 OWA
  • E2010 EAS
• For the following web publishing rules, disable them by un-checking the "Enable" setting on the General tab:
  • E2007 OWA
  • E2007 EAS
  • E2007 OA
• Apply the changes to ISA (note: might want to restart the Microsoft Firewall service so that the changes are immediate and potentially flush the DNS cache).
• Test with Internet clients and ensure they can still access their mailboxes.

Q&A

Does the configuration you described above leverage the OWA Single-Sign-On (SSO) redirection experience?

For the scenario where you are not leveraging ISA Pre-Authentication, yes, this configuration supports the OWA single-sign on experience by using a single web listener for all of the web publishing rules.

For the scenario where you are leveraging ISA Pre-Authentication, no, as this configuration utilizes the ISA single-sign on experience for Outlook Web Access. The Outlook Web Access SSO redirection only occurs when you utilize Forms Based Authentication at the Exchange layer on both E2010 and legacy Exchange.

Conclusion

Hopefully this information improves your understanding of external client access coexistence with legacy versions of Exchange while upgrading to Exchange Server 2010 in conjunction with ISA 2006.  Please let us know if you have any questions.

Read More