In Microsoft Exchange Server 2003, the front-end server communicates with the back-end server over HTTP. In Exchange 2010, the Client Access server communicates with the Mailbox server over RPC. You must have an Exchange 2010 Client Access server in every Active Directory site that contains a Mailbox server. Proxying occurs when one Client Access server sends traffic to another Client Access server. An Exchange 2010 Client Access server can proxy requests in the following two situations:

• Between Exchange 2010 Client Access servers   Proxying requests between two Exchange 2010 Client Access servers enables organizations that have multiple Active Directory sites to designate one Client Access server as an Internet-facing server and have that server proxy requests to Client Access servers in sites that have no Internet presence. The Internet-facing Client Access server then proxies the request to the Client Access server closest to the user's mailbox. This is known as CAS-CAS proxying.
  
• Between an Exchange 2010 Client Access server and Exchange 2007 Client Access servers   Proxying requests between an Exchange 2010 Client Access server and an Exchange 2007 Client Access server enables Exchange 2010 and Exchange 2007 to coexist in the same organization.
  

Proxying is supported for clients that use Outlook Web App, Exchange ActiveSync, and Exchange Web Services. Although the Availability service supports proxying, it has its own built-in logic for handling proxying and doesn't require explicit configuration. Proxying is supported from one Client Access server to another Client Access server when the destination Client Access server is running the same version of Microsoft Exchange as, or an earlier version of Microsoft Exchange than, the source Client Access server. The following figure shows how proxying works in an organization that has multiple Client Access servers and multiple Mailbox servers.

Note:
In each Exchange organization, only one Client Access server must be Internet-facing. A Client Access server that has no Internet presence doesn't have to have its own Internet host name. It relies on the Internet-facing Client Access server to proxy all pertinent requests from external clients.

Note:
Proxying won't work for Post Office Protocol version 3 (POP3) or Internet Message Access Protocol version 4rev1 (IMAP4) clients. A client who's using POP3 or IMAP4 must connect to a Client Access server in the same Active Directory site as their Mailbox server.

Client Access proxying

In the previous figure, the mailbox of User 1 is located on Mailbox server 01. The mailbox of User 2 is located on Mailbox server 02, and the mailbox of User 3 is located on Mailbox server 03. User 1 can access their mailbox through Client Access server 01 without using proxying. If User 1 tries to access Client Access server 02 using Exchange ActiveSync, they'll receive an error because Client Access server 01 is the appropriate Client Access server for their mailbox. If they try to access Client Access server 02 using Outlook Web App, their browser displays a message that includes the correct URL for their Client Access server. This process is known as redirection. If User 3 tries to access Client Access server 02, that server will proxy their request to Client Access server 03. Client Access server 03 isn't Internet-facing but can receive requests from other servers inside the firewall. Proxying isn't visible to the user.

Note:
Communications between Client Access servers in different sites occur over Secure HTTP (HTTPS).

 Proxying for Exchange ActiveSync

The following scenario shows how incoming requests are handled for a user who connects to an Exchange 2010 Client Access server named CAS-01 using a mobile device.

1. The Client Access server queries the Active Directory to determine the location of the user's mailbox and the version of Microsoft Exchange installed on the Mailbox server. If the user's mailbox is on an Exchange 2010 computer that has the Mailbox server role installed, go to step 3.
   
2. If the user's mailbox is on an Exchange 2003 server, the incoming request is proxied to the Exchange 2003 server that hosts the user's mailbox and the Exchange ActiveSync virtual directory. By default, in Exchange 2003, the Exchange ActiveSync virtual directory was installed on all mailbox servers. If the incoming request is to an Exchange 2010 Client Access server that's in a different Active Directory site than the destination back-end server, the request will be proxied directly to the destination back-end server, even if there is an Exchange 2010 Client Access server within the destination Active Directory site. If the incoming request is to an Exchange 2010 Client Access server within the same Active Directory site as the destination back-end server, the request will be proxied directly to the destination back-end server.
   

   Note:

   Users who have mailboxes on an Exchange 2003 server who try to use Exchange ActiveSync through an Exchange 2010 Client Access server will receive an error and be unable to synchronize unless Integrated Windows authentication is enabled on the Microsoft-Server-ActiveSync virtual directory on the Exchange 2003 server. This enables the Exchange 2010 Client Access server and the Exchange 2003 back-end server to communicate using Kerberos authentication.

3. If the user's mailbox is on an Exchange 2010 Mailbox server, CAS-01 locates a Client Access server in the same Active Directory site as the user's Mailbox server. If there's a Client Access server closer to the user's Mailbox server, Exchange 2010 determines whether the Client Access server has the InternalURL property configured and if the authentication method is Integrated Windows authentication. If so, the user is proxied to the Client Access server specified by the InternalURL property. Otherwise, the request is rejected. An error code is returned to the mobile phone if the request is rejected. If the proxied Client Access server has the ExternalURL property configured on the Microsoft-Server-ActiveSync virtual directory, an HTTP error code 451 will be returned.
   

   Important:
   Proxying isn't supported between virtual directories that use Basic authentication. For client communications to be proxied between virtual directories on different servers, the virtual directories must use Integrated Windows authentication.

 Proxying for Outlook Web App

The following scenario shows how incoming requests are handled for a user who connects to an Exchange 2010 Client Access server named CAS-01 using Outlook Web App.

1. The Client Access server queries Active Directory to determine the location of the user's mailbox and the version of Microsoft Exchange installed on the Mailbox server. If the user's mailbox is on an Exchange 2010 Mailbox server, go to step 3.
   
2. If the user's mailbox is on an Exchange 2003 server and the user tried to access Outlook Web App using https://domain name/owa, they'll receive an error. If the user tries to access https://domain name/exchange or https://domain name/public, the incoming request is proxied to the Exchange 2003 server that hosts the user's mailbox and the Outlook Web App virtual directory. If the incoming request is to an Exchange 2010 Client Access server in a different Active Directory site than the destination back-end server, the request will be proxied to the destination back-end server directly, even if there's an Exchange 2010 Client Access server within the destination Active Directory site. If the incoming request is to an Exchange 2010 Client Access server within the same Active Directory site as the destination back-end server, the request will be proxied directly to the destination back-end server.
   
3. If the user's mailbox is on an Exchange 2010 mailbox server, CAS-01 locates a Client Access server in the same Active Directory site as the user's mailbox server. When one is found, Exchange 2010 determines whether the Client Access server has the InternalURL property configured and whether the authentication method on the virtual directory is set to Integrated Windows authentication. CAS-01 then determines whether an external URL is specified. If so, the user is redirected to the server specified by the ExternalURL property. If an external URL isn't specified, CAS-01 will proxy the user's request to the Client Access server that's specified by the InternalURL property.
   

   Note:
   An internal URL is configured automatically during Exchange 2010 Setup. For Client Access servers that don't have an Internet presence, the ExternalURL property should be set to $null.

 Proxying Configuration

If your Client Access server is Internet-facing, set the ExternalURL property on the Exchange ActiveSync and Outlook Web App virtual directories using the Exchange Management Console or the Exchange Management Shell. The InternalURL property is configured automatically during the initial setup of Exchange 2010 and should rarely have to be changed. The ExternalURL property should contain the domain name that's registered for your Exchange organization in DNS. The following table contains the appropriate values for the ExternalURL and InternalURL properties for an Internet-facing Client Access server for the Exchange organization named www.contoso.com. The second table contains the appropriate ExternalURL and InternalURL property values for a non-Internet-facing Client Access server in a second Active Directory site for www.contoso.com. You must configure the authentication method on all these virtual directories to be Integrated Windows authentication. Proxying isn't supported for virtual directories that use other authentication methods.

Note:
If new Outlook Web App virtual directories are created using the Exchange Management Shell, you must manually configure the InternalURL property on those virtual directories.

Proxying InternalURL and ExternalURL settings for an Internet-facing Client Access server

Exchange 2010 service	InternalURL setting	ExternalURL setting
Outlook Web App	https://computername/OWA	https://www.contoso.com/OWA
Exchange ActiveSync	https://computername/Microsoft-Server-ActiveSync	https://www.contoso.com/Microsoft-Server-ActiveSync
Exchange Web Services	https://computername/EWS	https://www.contoso.com/EWS
Availability service	https://computername/AS	https://www.contoso.com/AS

Proxying InternalURL and ExternalURL settings for a non-Internet-facing Client Access server

Exchange 2010 service	InternalURL setting	ExternalURL setting
Outlook Web App	https://computername/OWA	$N$Null
Exchange ActiveSync	https://computername/Microsoft-Server-ActiveSync	$N$Null
Exchange Web Services	https://computername/EWS	$Null
Availability service	https://computername/AS	$Null

Outlook Web App users who access an Internet-facing Client Access server in a different Active Directory site than the site that contains their mailbox can be redirected to the Client Access server in the same site as their Mailbox server if that Client Access server is Internet-facing. When an Outlook Web App user tries to connect to a Client Access server outside the Active Directory site that contains their Mailbox server, they'll see a Web page that contains a link to the correct Client Access server for their mailbox.

The following figure shows how redirection works in an organization that has multiple Client Access servers in multiple Active Directory sites.

Redirection for Outlook Web App in Exchange 2010

In the previous figure, the mailbox of User 1 is located on Mailbox server 01. The mailbox of User 2 is located on Mailbox server 02, and the mailbox of User 3 is located on Mailbox server 03. User 1 can access their mailbox through Client Access server 01 without using redirection. If User 1 tries to access Client Access server 02, their browser will display a message that includes the correct URL for their Client Access server. The user will be prompted to click the Outlook Web App URL for their Client Access server. They won't redirected automatically. If User 3 tries to access Client Access server 02, that server will proxy their request to Client Access server 03. Client Access server 03 isn't Internet-facing, but can receive requests from other servers within the firewall. Proxying isn't visible to the user.

Note:
Redirection is supported only for clients that use Outlook Web App. Clients that use Exchange ActiveSync, Exchange Web Services, POP3, and IMAP4 can't use redirection.

Note:

When you install Exchange 2010, four virtual directories are created for Outlook Web App: owa, Exchange, Public, and ExchWeb. The owa virtual directory provides access to Exchange 2010 mailboxes. The Exchange and Public virtual directories provide Exchange 2003 mailbox access. If a user who has a mailbox on an Exchange 2003 server logs on using https://server name/owa, they'll receive an error telling them that their mailbox is on an Exchange 2003 server. They must use the Exchange virtual directory. If they log on using https://server name/Exchange, the Exchange 2010 Client Access server will proxy their request to the Exchange 2003 mailbox server. If a user who has a mailbox on Exchange 2010 accesses Outlook Web App using https://server name/owa, they'll be able to access their mailbox directly. If they log on to Outlook Web App using https://server name/Exchange, they will be redirected to https://server name/owa.

 Configuring Redirection

If your Client Access server is Internet-facing, set the ExternalURL property on the Outlook Web App virtual directories using the Exchange Management Console or the Exchange Management Shell. The InternalURL property is configured automatically during the initial setup of Exchange 2010 and should rarely have to be changed. You must also configure the authentication method on these virtual directories to be Integrated Windows authentication. Redirection isn't supported for virtual directories that use other authentication methods. The following two tables list the ExternalURL and InternalURL settings for Client Access servers in two Active Directory sites for Contoso. The two sites are www.usa.contoso.com and www.europe.contoso.com.

Note:
If new Outlook Web App virtual directories are created using the Exchange Management Shell, you must manually configure the InternalURL property on those virtual directories.

Redirection InternalURL and ExternalURL settings for an Internet-facing Client Access server in the usa.contoso.com site

Exchange 2010 service	InternalURL setting	ExternalURL setting
Outlook Web App	https://computername/OWA	https://www.usa.contoso.com/OWA

Redirection InternalURL and ExternalURL settings for an Internet-facing Client Access server in the europe.contoso.com site

Exchange 2010 service	InternalURL setting	ExternalURL setting
Outlook Web App	https://computername/OWA	https://www.europe.contoso.com/OWA

 Disabling Redirection

If your organization has multiple Internet-facing Active Directory sites and the Internet connection to one of those sites is disabled, you can temporarily disable redirection and configure Outlook Web App to use proxying instead. After the Internet connection in the site that has the problem is restored, you can reinstate redirection. You can disable redirection using the Set-OWAVirtualDirectory cmdlet with the following syntax:

set-owavirtualdirectory "owa (default web site)" -RedirectToOptimalOWAServer $false

To restore redirection, use the same cmdlet and change the RedirectToOptimalOWAServer parameter to $true.

In an organization that has multiple Active Directory sites and multiple Client Access servers in each site, you can use Network Load Balancing (NLB) to optimize traffic among the Client Access servers in each site. We recommend that you include only Client Access servers within the same Active Directory site in a load-balancing array. You can deploy NLB in an Internet-facing Active Directory site and in a non-Internet-facing Active Directory site. The following figure shows two Active Directory sites that implement NLB.

Proxying in an organization that uses NLB

The following table lists the settings for the virtual directories on the Client Access servers CAS-01 and CAS-02 for the Internet-facing Active Directory site www.contoso.com.

Virtual directory settings for Internet-facing Client Access servers in an organization that uses NLB

Note   When you configure your firewall, you must configure IP Affinity for proxying to succeed for Exchange Web Services. IP Affinity allows a request that originates from one computer to always be proxied to the same destination computer.

The non-Internet-facing Active Directory site has three servers: CAS-03, CAS-04, and CAS-05. The following table lists the settings for the virtual directories for all three servers.

Virtual directory settings for non-Internet-facing Client Access servers in an organization that uses NLB

The ExternalURL property for all the virtual directories should be set to $Null. If the ExternalURL property is set to anything other than $Null, the non-Internet-facing Client Access servers will operate as if they're exposed to the Internet and will prevent clients from successfully connecting to these servers.

Outlook Web App and Exchange Web Services handle load balancing differently than the Availability service and Exchange ActiveSync. Outlook Web App and Exchange Web Services implement their own load balancing when they're deployed on multiple Client Access servers within the same Active Directory site. If a user tries to access Outlook Web App through https://www.contoso.com/OWA and is proxied to CAS-01, the next time that user tries to access Outlook Web App, they'll again be proxied to CAS-01, even if CAS-02 has fewer concurrent connections. This occurs because of cookie-based load balancing (also known as Client IP Affinity). If CAS-01 is unavailable, the user will be proxied to CAS-02.

Note:
For both Outlook Web App and Exchange Web Services, your firewall should be configured for IP Affinity. This is the process by which a particular client application connects to the same IP address every time. This is required so that the SSL negotiation isn't performed repeatedly for each request.

The process is different for Exchange ActiveSync. When an Internet-facing Client Access server proxies a request to a non-Internet-facing Client Access server, the connection is maintained using information stored in the local Administrator account. This connection can then be used by other user requests. In an NLB situation, the Client Access servers in the Internet-facing NLB will establish connections to the Client Access servers in the non-Internet-facing NLB. The number of connections will be equal to the number of Client Access servers in the destination Active Directory site. We recommend implementing round-robin load balancing within the NLB array.

Note:

We recommend that you implement NLB in both the Internet-facing and non-Internet facing Active Directory sites. In a non-Internet facing Active Directory site that doesn't have NLB, if one of the Client Access servers in the site is unavailable, any Exchange ActiveSync clients that have previously been proxied to that Client Access server will fail until the Client Access server becomes available again. The synchronization state for Exchange ActiveSync is stored in the mailbox for the client. So if a client is proxied to CAS-02 the first time they connect, they'll be proxied to CAS-02 every time they connect.

For the Availability service, we also recommend round-robin load balancing. Availability service requests don't have to maintain their connection state. In other words, two consecutive Availability service requests from the same client can be proxied to different Client Access servers in the destination Active Directory site without affecting performance.

For more information about NLB, see the Windows Server 2003 documentation.

Note:

In many deployments, the installation of the Client Access server role and the Hub Transport server role are on the same computer. In this topology, you can configure NLB for the Client Access server role separately from the Hub Transport server role. Currently NLB isn't supported on the Hub Transport server role. However, it's supported for the Client Access server role. To configure NLB for the Client Access server role and not the Hub Transport server role, configure ports 80 and 443 for client access. The Hub Transport server role implements its own high availability within the software.

The following table summarizes the protocols used to access Exchange 2010 and how they're used for proxying and redirection.

Client Access protocols for redirection and proxying

In an Exchange 2010 proxying environment, poor performance can frequently result when the Client Access servers receive lots of concurrent requests. This problem is frequently caused by the exhaustion of threads and available connections because of Web service requests from ASP.NET. This can cause the Client Access server to deny requests or exhibit high latency when the requests are being processed.

To resolve these issues, you can configure several ASP.NET parameters by editing the Machine.config file on the Client Access server computers. For more information about how to configure these parameters, see Microsoft Knowledge Base article 821268, Contention, poor performance, and deadlocks when you make Web service requests from ASP.NET applications.

Two of the parameters explained in the previous Knowledge Base article must be set differently in an Exchange 2010 proxying environment. We recommend that you allow for 36 threads per processor and that you set the maxconnections value to 2000.

For more information about server performance, see the following topic:

• Managing the .NET Framework on Windows Server 2003