Understanding Proxying and Redirection

Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2

Topic Last Modified: 2012-12-26

In a Microsoft Exchange Server 2010 organization, a Client Access server can act as a proxy for other Client Access servers within the organization. This is useful when multiple Client Access servers exist in different Active Directory sites in an organization, and at least one of those sites isn't exposed to the Internet.

A Client Access server can also perform redirection for Microsoft Office Outlook Web App URLs and for Exchange ActiveSync devices. Redirection is useful when users connect to a Client Access server that isn't in their local Active Directory site, or if a mailbox has moved between Active Directory sites. It's also useful if users should actually be using a more effective URL. For example, users should be using a URL that's closer to the Active Directory site in which their mailbox resides.

The Client Access server's response can vary by protocol. Typically, however, a Client Access server takes the following action if it receives a request for a user whose mailbox is in an Active Directory site other than the one to which the Client Access server belongs: In this case, the server looks for the presence of an ExternalURL property on the relevant virtual directory on a Client Access server that's in the same Active Directory site as the user's mailbox. If the ExternalURL property exists, and the client type supports redirection (for example, Outlook Web App or Exchange ActiveSync), the Client Access server issues a redirect to that client. If no ExternalURL property exists, or if the client type doesn't support redirection (for example, POP3 or IMAP4), the Client Access server will try to proxy the connection to the target Active Directory site.

This topic explains proxying and redirection, the circumstances under which each is used, and how to configure your Client Access servers for each scenario.

Note:
If you don't have multiple Active Directory sites in your organization, you don't have to configure Exchange 2010 for proxying or redirection. However, you might want to configure load balancing of URLs as described later in this topic.

Note:
Client Access servers that aren't exposed to the Internet don't have to have separate Secure Sockets Layer (SSL) certificates to allow proxied traffic from another Client Access server. By default, they can use the self-signed certificate installed with Exchange 2010. However, these certificates aren't usually trusted by internal clients such as Outlook Web App or Outlook, and their use will usually result in certificate warnings. If there are internal clients in the same Active Directory sites as Client Access servers with self-signed certificates, you should replace the self-signed certificates with certificates issued by a certification authority that's trusted by the clients.

Note:

Client Access servers that aren't exposed to the Internet don't have to have separate Secure Sockets Layer (SSL) certificates to allow proxied traffic from another Client Access server. By default, they can use the self-signed certificate installed with Exchange 2010. However, these certificates aren't usually trusted by internal clients such as Outlook Web App or Outlook, and their use will usually result in certificate warnings. If there are internal clients in the same Active Directory sites as Client Access servers with self-signed certificates, you should replace the self-signed certificates with certificates issued by a certification authority that's trusted by the clients.

Contents

Overview of Proxying

Overview of Redirection

Proxying with Network Load Balancing

Summary of Client Access Methods

Proxying Performance and Scalability

Overview of Proxying

In Microsoft Exchange Server 2003, the front-end server communicates with the back-end server over HTTP. In Exchange Server 2007 and Exchange 2010, the Client Access server communicates with an Exchange Mailbox server over RPC. You must have an Exchange 2010 Client Access server in every Active Directory site that contains an Exchange 2010 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 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.
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 within one Active Directory site or between Active Directory sites enables Exchange 2010 and Exchange 2007 to coexist in the same organization. For more information about how to upgrade and coexistence, see Upgrade from Exchange 2003 Client Access and Upgrade from Exchange 2007 Client Access.

Proxying is supported for clients that use Outlook Web App, Exchange ActiveSync, the Exchange Control Panel (ECP), POP3, IMAP4, and Exchange Web Services. 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.

Warning:
When an IMAP4 client using NTLM authentication tries to connect to a Client Access server in an Active Directory site that doesn’t contain the target mailbox, the connection will fail. If you want an IMAP4 client to be proxied from one Active Directory site to another, you have to choose an alternate authentication method.

Note:
In each Exchange organization that wants to allow access from Internet-based clients, at least one Active Directory site must be Internet facing. All non-Internet-facing Active Directory sites rely on the Internet-facing Client Access server or servers to proxy all pertinent requests from external clients.

Client Access server Redirection and Proxying

In the previous figure, the mailbox of User 1 is located on Mailbox server 1. The mailbox of User 2 is located on Mailbox server 2, and the mailbox of User 3 is located on Mailbox server 3. Each Mailbox server is in a different Active Directory site. User 1 can access their mailbox through Client Access server 1 without using proxying, and User 2 can access their mailbox through Client Access server 2. If User 3 tries to access their mailbox through Client Access server 1 or 2, either server will proxy their request to Client Access server 3. Client Access server 3 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), but Client Access servers don't check the status of the certificate that's used by default. The certificate is used only for encryption, not authentication, and so name mismatches, expiration dates, and trust status are ignored.

Return to top

Overview of Redirection

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. This is known as manual redirection. In Exchange 2010 SP2, administrators can configure cross-site silent redirection to enable this redirection process to happen without the user’s knowledge. For more information, see Cross-Site Silent Redirection later in this topic.

Note:
You cannot use cross-site silent redirection in a hybrid environment that uses an on-premises Exchange Server together with Office 365.

Exchange ActiveSync 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 and if the client mobile phone or device has correctly implemented the redirection logic built in to the protocol that's used when communicating with Exchange 2007 and Exchange 2010. The redirection for Exchange ActiveSync users is achieved by sending the device an HTTP 451 error code that contains the URL the device should be using. The device then reconfigures itself to use the new URL.

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

In the previous figure, User 1 usually accesses their mailbox in Active Directory site 1 using their mobile phone. The administrator then moves their mailbox to Mailbox server 2 in Active Directory site 2. The next time the device tries to synchronize, the server responds with an HTTP 451 status error. This contains the URL the device should now use for that user. In step 3 of the sequence, the device reconfigures itself and connects to the specified URL. User 2, whose mailbox is in Active Directory site 2, tries to open their mailbox using Outlook Web App by connecting to Client Access server 1 over the Internet. With manual redirection, as soon as the user authenticates, Client Access server 1 presents a page to the user, with a link to the Outlook Web App URL for the Client Access server in Active Directory site 2. The user clicks the link, is taken to Active Directory site 2, and signs in again to access their mailbox.With silent redirection, when the user authenticates, they’re silently redirected to the Outlook Web App URL for the Client Access server in Active Directory site 2.

Cross-Site Silent Redirection

Note:
You cannot use cross-site silent redirection in a hybrid environment that uses an on-premises Exchange Server together with Office 365.

Exchange 2010 SP2 lets administrators configure cross-site silent redirection. Cross-site silent redirection performs silent redirection for client requests that are destined for a CAS that is located in a different Active Directory site in the same Exchange organization. For example, a user with a mailbox in Active Directory SiteA who accesses the Outlook Web App URL in Active Directory SiteB will be silently redirected to the Outlook Web App URL for Active Directory in SiteA.

To configure cross-site silent redirection, the administrator must use the new CrossSiteRedirectType parameter that’s been added to the Set-OWAVirtualDirectory cmdlet. The parameter has two possible settings. The default setting is Manual.

Silent When this setting is configured, a user’s web browser is automatically redirected whenever a Client Access server must redirect an Outlook Web App request to Client Access server or server array located in another Active Directory site. When forms-based authentication is configured on the source and target CAS OWA virtual directories (SSL is required), then the silent redirection is also a single sign-on event. For redirection to occur, the target Client Access server Outlook Web App virtual directory must have an ExternalURL value configured.
Manual When this setting is configured, users will receive a notification that they’re accessing the wrong URL and that they must click a link to access the correct Outlook Web App URL for their mailbox. This notification only occurs when a Client Access server determines that it must redirect an Outlook Web App request to Client Access server or server array located in another Active Directory site. For redirection to occur, the target Client Access server Outlook Web App virtual directory must have an ExternalURL value configured.

For example:

Set-OWAVirtualDirectory -Identity "Contoso\owa (Default Web site)" -CrossSiteRedirectType Silent

For more information about the Set-OwaVirtualDirectory cmdlet, see: Set-OwaVirtualDirectory

Proxying and Redirection for Exchange ActiveSync

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

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 2003 server, the incoming request is proxied directly 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. The Active Directory site of the user's mailbox isn't applicable in this case because Exchange 2003 doesn't use Active Directory sites to determine location. The connection is always made directly from the Exchange 2010 Client Access server to the Exchange 2003 mailbox 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. Integrated Windows authentication enables the Exchange 2010 Client Access server and the Exchange 2003 back-end server to communicate.

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. Integrated Windows authentication enables the Exchange 2010 Client Access server and the Exchange 2003 back-end server to communicate.

If the user’s mailbox is on an Exchange 2007 Mailbox server, CAS-01 locates an Exchange 2007 Client Access server in the same Active Directory site as the user's Mailbox server. This may be the same Active Directory site as CAS-01. CAS-01 determines whether the Exchange 2007 Client Access server has the ExternalURL property configured on the Exchange ActiveSync virtual directory. If so, CAS-01 issues the client an HTTP error code 451 that contains the ExternalURL value and instructs the client to redirect to the location specified in the ExternalURL property. If no ExternalURL value is set, the connection will be proxied to the Client Access server using the FQDN specified by the InternalURL property, specifically to the /Proxy virtual directory, This virtual directory is located beneath the Exchange ActiveSync virtual directory in IIS and, by default, has Integrated Windows authentication enabled on it.

If the user's mailbox is on an Exchange 2010 Mailbox server in the same Active Directory site as CAS-01, CAS-01 provides access to the mailbox. If the user's mailbox is on an Exchange 2010 Mailbox server in a different Active Directory site, CAS-01 locates a Client Access server in the same Active Directory site as the user's Mailbox server. CAS-01 determines whether any Exchange 2010 Client Access server in that Active Directory site has the ExternalURL property configured on the Exchange ActiveSync virtual directory. If so, CAS-01 issues the client an HTTP error code 451 that contains the ExternalURL value and instructs the client to redirect to that location. If no ExternalURL value is set, the connection will be proxied to the Client Access server using the FQDN specified by the InternalURL property, specifically to the /Proxy virtual directory. This virtual directory is located beneath the Exchange ActiveSync virtual directory in IIS and, by default, has Integrated Windows authentication enabled on it.

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

Return to top

Proxying and Redirection for Outlook Web App

The following series of steps 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.

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 2003 server and the user tries to access Outlook Web App using https://domain name/owa, they'll receive an error because an Exchange 2010 Client Access server can't directly provide Outlook Web App access to an Exchange 2003 mailbox. However, if the administrator configured redirection from Exchange 2010 to Exchange 2003, which would be usual during a migration from Exchange 2003 to Exchange 2010, the Exchange2003URL property of the Outlook Web App virtual directory was set to the value of an Exchange 2003 server facing the Internet.

If the user's mailbox is on an Exchange 2007 mailbox server, CAS-01 locates a Client Access server in the same Active Directory site as the user's mailbox server. If the Exchange 2007 Mailbox server is in the same Active Directory site as CAS-01, one of four possible actions will result.

CAS-01 will look for an Exchange 2007 ExternalURL property that has an ExternalAuthenticationMethods setting that's identical to the InternalAuthenticationMethods setting on the Exchange 2010 Client Access server. If the settings match, CAS-01 will redirect to this external URL. If source and target CAS have Forms Based Authentication (FBA) enabled, the source CAS issues a hidden form back to the browser that contains the user’s credentials and FBA settings, along with the redirect URL. This is transparent to the user.
If a matching ExternalURL setting isn't found, CAS-01 will look for an Exchange 2007 Client Access server that has the ExternalURL property configured, regardless of matching. If one is found, CAS-01 will redirect to this external URL. This will result in the user being prompted for authentication.
If no matching ExternalURL setting is found, CAS-01 will look for an Exchange 2007 Client Access server with an InternalURL property that has an InternalAuthenticationMethods setting identical to the InternalAuthenticationMethods setting on the Exchange 2010 Client Access server. If one is found, CAS-01 will redirect to this InternalURL. If forms-based authentication is enabled, this will result in a single sign-on redirection.
If no matching InternalURL is found, CAS-01 will look for an Exchange 2007 Client Access server with an InternalURL configured, regardless of matching. If one is found, CAS-01 will redirect to this InternalURL. This will result in the user being prompted for authentication.

If the Exchange 2007 Mailbox server is in a different Active Directory site, CAS-01 determines whether the ExternalURL property is set in that Active Directory site. If it is, and cross-site silent redirection is not enabled, the CrossSiteRedirectType value is set to Manual, and a manual redirect is issued. In this scenario, the user is provided with a clickable link that redirects them to the specified URL.

If cross-site silent redirection has been enabled, the CrossSiteRedirectType value is set to Silent and the user is automatically redirected to the specified URL. If the ExternalURL property is not present, and the authentication method on the /OWA virtual directory is set to Integrated Windows authentication, CAS-01 will proxy the user's request to the Client Access server that's specified by the InternalURL property.

Important:
To allow an Exchange 2010 Client Access server to proxy Outlook Web App requests to an Exchange 2007 Client Access server in another Active Directory site, you must copy the highest-versioned folder from an Exchange 2007 Client Access server in the destination Active Directory site from the %installpath%\ClientAccess\OWA\ folder to the same path on the Exchange 2010 Client Access server that's making the proxy request.

Important:

To allow an Exchange 2010 Client Access server to proxy Outlook Web App requests to an Exchange 2007 Client Access server in another Active Directory site, you must copy the highest-versioned folder from an Exchange 2007 Client Access server in the destination Active Directory site from the %installpath%\ClientAccess\OWA\ folder to the same path on the Exchange 2010 Client Access server that's making the proxy request.

Important:
An Exchange 2010 Client Access server will never proxy Outlook Web App requests to an Exchange 2007 Client Access server in the same Active Directory site. All requests within the same Active Directory site are redirected to an Exchange 2007 Client Access server, using either the InternalURL or ExternalURL properties for Client Access server, depending on which properties are configured.

If the user's mailbox is on an Exchange 2010 Mailbox server in the same Active Directory site as CAS-01, CAS-01 provides access to the mailbox. If the user's mailbox is on an Exchange 2010 Mailbox server in a different Active Directory site, 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 ExternalURL property set in that Active Directory site. If it is, and cross-site silent redirection hasn’t been enabled, the user is provided with a clickable link that redirects them to the specified URL. If cross-site silent redirection has been enabled, the user will be automatically redirected to the specified URL. If the ExternalURL isn't set and the authentication method on the virtual directory is set to Integrated Windows authentication, CAS-01 will proxy the user's request to the Client Access server that's specified by the InternalURL property.

Proxying for the Exchange Control Panel

Exchange 2010 provides a Web-based interface for both users and organization administrators to configure settings for their mailbox or for the organization. The Exchange Control Panel (ECP) is accessed either through the Options menu in Outlook Web App or, in Outlook 2010, by choosing the Voice Mail options, requesting message tracking information, or configuring mobile notifications. Selecting any of these options within Outlook launches a Web browser session.

The destination of the session depends on the current connection state of the Outlook client. If the Outlook client is connected using RPC over TCP, the client connects to the InternalURL value of the ECP virtual directory. If the client is connected using Outlook Anywhere, the Outlook client will launch a browser session. The browser session will try to connect to the ExternalURL value of the ECP virtual directory. The URLs are provided to the Outlook client via the Autodiscover service.

When an internal client is connected through TCP, the ECP session will always connect to a Client Access server in the same Active Directory site as the user's mailbox. Proxying isn't used in this scenario. When a client outside the corporate network uses Outlook Anywhere to connect, the client opens a browser session to the external URL of the ECP virtual directory or to the external URL of an Internet-facing Active Directory site if the user's mailbox is located in a non-Internet-facing site.

The proxying logic for the ECP is the same as for Outlook Web App. If the user's mailbox is on an Exchange 2010 Mailbox server in the same Active Directory site as the Client Access server receiving the request, that Client Access server provides access to the mailbox. If the user's mailbox is on an Exchange 2010 Mailbox server in a different Active Directory site, the Client Access server locates a Client Access server in the same Active Directory site as the user's Mailbox server. The original Client Access server will proxy the user's request to that Client Access server.

The ECP does perform redirection, but unless the user explicitly enters the URL to access the ECP, it's rarely performed. If a user accesses the ECP from Outlook Web App, Outlook Web App is responsible for making sure the user is using the correct URL. If the user is using Outlook 2010, Outlook and the Autodiscover service are responsible for making sure the user uses the correct URL for the ECP.

Return to top

Proxying for Exchange Web Services

Exchange Web Services provides an XML messaging interface that enables you to manage Exchange store items and access Exchange server functionality from client applications. From a proxy, redirection, and client perspective this functionality is usually used in the context of one of the following:

Availability service requests
Autodiscover requests
Setting and checking Automatic Replies (OOF) status

An application written using Exchange Web Services can use proxying behavior for such tasks as setting an automatic-reply (Out of Office) message, which will be proxied between Active Directory sites, if required.

The following steps show how incoming requests are handled for a user who makes an Availability service request to an Exchange 2010 Client Access server named CAS-01. The user is using Outlook Web App to check the availability of another user in the same Exchange organization.

CAS-01 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 2003 server, Outlook Web App makes an HTTP connection to the /Public virtual directory of the Exchange 2003 server and retrieves the requested information from the Free/Busy system folder.
If the user’s mailbox is on an Exchange 2007 Mailbox server, an error is returned to the user. In any Exchange organization that contains mailboxes on an Exchange 2007 Mailbox server, there must be an externally accessible Exchange 2007 Client Access server. The Autodiscover service is responsible for returning the correct Exchange Web Services URL to the client. This URL must match the version of the Mailbox server that the user’s mailbox is on.

If the user's mailbox is on an Exchange 2010 Mailbox server in the same Active Directory site as CAS-01, CAS-01 accesses the mailbox itself to retrieve the requested information. If the user's mailbox is on an Exchange 2010 Mailbox server in a different Active Directory site, CAS-01 proxies to a Client Access server in that Active Directory site by using the FQDN specified by the InternalURL property of the /EWS virtual directory.

Important:
An Exchange Client Access server will proxy Availability service requests from one server to another whether the ExternalURL property is set or not.

Important:
Some Exchange Web Services applications use Web methods such as GetEvents and Unsubscribe, which have very strong Client Access server affinity. When one Client Access server must proxy one of these requests to another Active Directory site, it can use the InternalNLBBypassURL property of the Client Access server, which should always be set to the FQDN of the host server itself. This ensures the Client Access server making the request can maintain affinity with a specific Client Access server in the target Active Directory site.

Important:

Some Exchange Web Services applications use Web methods such as GetEvents and Unsubscribe, which have very strong Client Access server affinity. When one Client Access server must proxy one of these requests to another Active Directory site, it can use the InternalNLBBypassURL property of the Client Access server, which should always be set to the FQDN of the host server itself. This ensures the Client Access server making the request can maintain affinity with a specific Client Access server in the target Active Directory site.

Exchange Web Services itself doesn't provide redirection functionality, because the Autodiscover service, which is used to provide URLs to an application, provides the URLs required to access a specific mailbox. For example, when a mailbox is moved between Active Directory sites, Outlook receives the updated Active Directory site-specific URLs from the Autodiscover service when it next issues a query. This can sometimes result in a client making Availability service requests to a Client Access server in an Active Directory site other than the one that their mailbox is in. But, because the Availability service will still process the requests and proxy them as necessary, there's no impact on the user.

Important:
In any Exchange organization that contains mailboxes on an Exchange 2007 Mailbox server, there must be an externally accessible Exchange 2007 Client Access server. When the Autodiscover service returns the correct Exchange Web Services URL to a requesting client, this URL matches the version of server that the user’s mailbox is on. For any Exchange organization that contains mailboxes on both Exchange 2007 Mailbox servers and Exchange 2010 Mailbox servers, two external URL’s must be configured for Exchange Web Services, one for each installed version of Exchange.

Important:

In any Exchange organization that contains mailboxes on an Exchange 2007 Mailbox server, there must be an externally accessible Exchange 2007 Client Access server. When the Autodiscover service returns the correct Exchange Web Services URL to a requesting client, this URL matches the version of server that the user’s mailbox is on. For any Exchange organization that contains mailboxes on both Exchange 2007 Mailbox servers and Exchange 2010 Mailbox servers, two external URL’s must be configured for Exchange Web Services, one for each installed version of Exchange.

Proxying for POP3 and IMAP4

Exchange 2010 can proxy POP3 and IMAP4 sessions between Client Access servers and Active Directory sites.

The following steps show how incoming requests are handled for a user who makes a request to an Exchange 2010 Client Access server named CAS-01 using a POP3 client.

CAS-01 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 2003 server, CAS-01 proxies the connection to the POP3 service running on the Exchange 2003 server that's hosting the user’s mailbox.
If the user’s mailbox is on an Exchange 2007 Mailbox server, CAS-01 locates an Exchange 2007 Client Access server in the same Active Directory site as the user's Mailbox server, which may be in the same Active Directory site as CAS-01. CAS-01 proxies the request to the Client Access server.

If the user's mailbox is on an Exchange 2010 Mailbox server in the same Active Directory site as CAS-01, CAS-01 accesses the mailbox itself. If the user's mailbox is on an Exchange 2010 Mailbox server in a different Active Directory site, CAS-01 proxies to a Client Access server using the FQDN specified by the InternalConnectionSettings property of the POP configuration for that server.

Important:
There are no InternalURL or ExternalURL settings for the POP3 or IMAP4 services and an Exchange 2010 Client Access server will proxy POP3 and IMAP4 service requests from one server to another when it's needed.

Important:
Client Access servers trying to proxy to another Active Directory site don't check whether the POP3 or IMAP4 service is actually running on the remote Client Access server. It's important, therefore, to not only ensure that the services are running on every Client Access server in the remote Active Directory site, but to consider using a load balancer for the service. Load balances will be discussed later in this topic.

Important:

Client Access servers trying to proxy to another Active Directory site don't check whether the POP3 or IMAP4 service is actually running on the remote Client Access server. It's important, therefore, to not only ensure that the services are running on every Client Access server in the remote Active Directory site, but to consider using a load balancer for the service. Load balances will be discussed later in this topic.

Return to top

Proxying Configuration

If your Client Access server is Internet facing, set the ExternalURL property on the /Microsoft-Server-ActiveSync, /OWA, /ECP, and /EWS virtual directories using the Exchange Management Console (EMC) or the Exchange Management Shell (Shell). The EWS virtual directory can only be configured using the Shell. The InternalURL property is configured automatically during the initial setup of Exchange 2010 and should only be changed if you want to use a load balancing solution. The ExternalURL property should contain the FQDN 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 an Exchange organization that accesses Outlook Web App by using the URL https://mail.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 the same organization. You must ensure that the authentication method for all these virtual directories is set to Integrated Windows authentication. Proxying isn't supported for virtual directories that use other authentication methods except for POP3 and IMAP4, which use SSL/TLS and proxy the user's Basic authentication credentials.

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

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

Exchange 2010 service	InternalURL setting	ExternalURL setting
Outlook Web App	https://fullyqualifiedcomputername/OWA	https://mail.contoso.com/OWA
Exchange ActiveSync	https://fullyqualifiedcomputername/Microsoft-Server-ActiveSync	https://mail.contoso.com/Microsoft-Server-ActiveSync
Exchange Web Services	https://fullyqualifiedcomputername/EWS/Exchange.asmx	https://mail.contoso.com/EWS/Exchange.asmx
Exchange Control Panel	https://fullyqualifiedcomputername/ECP	https://mail.contoso.com/ECP

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

Exchange 2010 service	InternalURL setting	ExternalURL setting
Outlook Web App	https://fullyqualifiedcomputername/OWA	`$Null`
Exchange ActiveSync	https://fullyqualifiedcomputername/Microsoft-Server-ActiveSync	`$Null`
Exchange Web Services	https://fullyqualifiedcomputername/EWS/Exchange.asmx	`$Null`
Exchange Control Panel	https://fullyqualifiedcomputername/ECP	`$Null`

Configuring Redirection

If more than one of your Active Directory sites are Internet facing, set the ExternalURL property on the /OWA and /Microsoft-Server-ActiveSync virtual directories using the EMC or the Shell to allow redirection between them. The InternalURL property is configured automatically during the initial setup of Exchange 2010 and should only be changed if you want to use a load balancing solution. The following two tables list the ExternalURL and InternalURL settings for Client Access servers in two Active Directory sites for a company named Contoso. The two sites are usa.contoso.com and europe.contoso.com.

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

InternalURL and ExternalURL property 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://fullyqualifiedcomputername/OWA	https://usa.contoso.com/OWA
Exchange Control Panel	https://fullyqualifiedcomputername/ECP	https://usa.contoso.com/ECP
Exchange ActiveSync	https://fullyqualifiedcomputername /Microsoft-Server-ActiveSync	https://usa.contoso.com/Microsoft-Server-ActiveSync
Exchange Web Services	https://fullyqualifiedcomputername /EWS/Exchange.asmx	https://usa.contoso.com/EWS/Exchange.asmx

InternalURL and ExternalURL property 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://fullyqualifiedcomputername/OWA	https://europe.contoso.com/OWA
Exchange Control Panel	https://fullyqualifiedcomputername/ECP	https://europe.contoso.com/ECP
Exchange ActiveSync	https://fullyqualifiedcomputername /Microsoft-Server-ActiveSync	https://europe.contoso.com/Microsoft-Server-ActiveSync
Exchange Web Services	https://fullyqualifiedcomputername /EWS/Exchange.asmx	https://europe.contoso.com/EWS/Exchange.asmx

Note:
If the ExternalURL property isn't set on the Exchange ActiveSync virtual directory in at least one Active Directory site, the Autodiscover service will fail when it configures mobile phones because the value set on the ExternalURL property is passed to the mobile phones during the Autodiscover process.

Return to top

Proxying with Network Load Balancing

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 load balance traffic proxied between the Client Access servers in each site and for users directly accessing those servers. Just deploying a load balancer isn't enough to ensure traffic is balanced effectively. You must also perform some additional configuration of the InternalURL and ExternalURL properties. 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 table lists the settings you should configure for the virtual directories on the Client Access servers in both Internet-facing and non-Internet-facing sites. The FQDN of the NLB should be configured in DNS to resolve to the load balancing device or service. The load balancing solution will then be responsible for forwarding the traffic to the appropriate Client Access servers.

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

Virtual directory /service	InternalURL	ExternalURL (Internet-facing Active Directory site)	ExternalURL (non-Internet-facing Active Directory site)
/OWA	NLB FQDN (see the following guidelines)	NLB FQDN	$null
/ECP	NLB FQDN (see the following guidelines)	NLB FQDN	$null
/Microsoft-Server-ActiveSync	NLB FQDN	NLB FQDN	$null
/OAB	NLB FQDN	NLB FQDN	$null
/EWS	NLB FQDN	NLB FQDN	$null
POP/IMAP	(InternalConnectionsSettings) NLB FQDN	Not applicable	Not applicable

We recommend that you use the following guidelines to set the InternalURL property:

The InternalURL property for the /OWA and /ECP virtual directories on all Client Access servers in an Active Directory site can be set to the NLB FQDN of the servers in that site if there are internal Outlook 2010 users.
If a Client Access server in an Active Directory site is the target of an Outlook Web App or ECP proxy request from a Client Access server in any other Active Directory site, make sure that you configure your load balancer to ensure affinity is maintained. This is because the Client Access server in the Internet-facing site cannot select a server for each individual request and maintain its own affinity

The following table lists the various authentication settings that are needed on virtual directories in an organization that uses network load balancing (NLB). In an organization that uses NLB, the NLB URL is used in place of a specific Client Access server URL for client connectivity.

Virtual directory authentication settings for Client Access servers in an organization that uses NLB URLs for fault tolerance and load balancing

Virtual directory /service	Internet-facing Active Directory site	Non-Internet-facing Active Directory site
/OWA	If Microsoft Forefront Threat Management Gateway 2010 (Forefront TMG) or Microsoft Forefront Unified Access Gateway 2010 (Forefront UAG) are being used, and forms-based authentication is enabled, use Basic or Integrated Windows authentication, depending on firewall rule delegation settings. If traffic from the Internet passes to the Client Access server with no pre-authentication, then use forms-based authentication. The same authentication method should be enabled on the /OWA and /ECP virtual directories.	Integrated Windows authentication
/ECP	If Forefront TMG or Forefront UAFG are being used, and forms-based authentication is enabled, use Basic or Integrated Windows authentication, depending on firewall rule delegation settings. If traffic from the Internet passes to the Client Access server with no pre-authentication, then use forms-based authentication. The same authentication method should be enabled on the /OWA and /ECP virtual directories.	Integrated Windows authentication
/Microsoft-Server-ActiveSync	Basic authentication.	Basic authentication (Proxying is performed using the /Proxy sub virtual directory.)
/OAB	Basic or Integrated Windows authentication, depending on firewall rule delegation settings.	Basic or Integrated Windows authentication, depending on firewall rule delegation settings (OAB requests are never proxied between Active Directory sites. This virtual directory is only used by Outlook clients.)
/EWS	Basic (optional - depending on firewall rule delegation settings). Integrated Windows authentication required.	Integrated Windows authentication
POP/IMAP	As required by client connection method.	As required by client connection method

Return to top

Load Balancing Logic Used by Client Access Servers When Proxying Between Active Directory Sites

When multiple Client Access servers exist in the site that will be the target of a proxy attempt, and the server on which the user’s mailbox is located is a combined Client Access server and Mailbox server, the Client Access server in the source Active Directory site will always choose that combined Client Access server and Mailbox server as the target of the proxy attempt.

Outlook Web App, the ECP, and Exchange Web Services handle load balancing differently than the Availability service and Exchange ActiveSync do. Outlook Web App, the ECP, 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://mail.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, This will happen even if CAS-02 has fewer concurrent connections. This is done to ensure long-running transactions can be completed without reauthentication or requesting data again. This is known as Affinity. If CAS-01 is unavailable, the user will be proxied to CAS-02 and the user may be required to reauthenticate.

Exchange Web Services can maintain affinity when proxied between Active Directory sites despite the InternalURL property of the target server being configured with an NLB URL. This is because the Client Access server making the proxy request for an application that requires affinity uses the InternalNLBBypassURL property on the target server. The InternalNLBBypassURL property is configured with the FQDN of the target server and uses Windows authentication by default.

Note:
For Outlook Web App, the ECP, and Exchange Web Services, your firewall should be configured for cookie-based or IP-based affinity. This ensures that a particular client application connects to the same server every time. This is required so that the SSL negotiation isn't performed repeatedly for each request. It's important to maintain affinity from the client application through to the final Client Access server involved in the transaction.

Note:

For Outlook Web App, the ECP, and Exchange Web Services, your firewall should be configured for cookie-based or IP-based affinity. This ensures that a particular client application connects to the same server every time. This is required so that the SSL negotiation isn't performed repeatedly for each request. It's important to maintain affinity from the client application through to the final Client Access server involved in the transaction.

Note:
You shouldn't change the value of theInternalNLBBypassURL property on a Client Access server. If you change it, you'll break proxied Exchange Web Services requests.

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 requesting Client Access server looks for a Client Access server in the target site and tries to connect to it using the value configured in the InternalURL property. If the server doesn't respond, the request will fail and an error will be returned to the client. We recommend implementing round-robin load balancing within an NLB array and setting the InternalURL property to a load-balanced value.

We also recommend load balancing for the Availability service. 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 performance being affected, and there are no authentication issues if the InternalURL property is set to be a load balanced value. In addition, setting the InternalURL property to a load-balanced value benefits any Outlook 2007 and Outlook 2010 clients internally, because the Autodiscover service provides those clients with the load-balanced value set in the InternalURL property to allow them to complete their Availability service requests.

For more information about network load balancing, see Understanding Load Balancing in Exchange 2010.

Note:
In many deployments, the Client Access server role and the Hub Transport server role are installed 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.

Note:

In many deployments, the Client Access server role and the Hub Transport server role are installed 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.

Return to top

Summary of Client Access Methods

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

Protocol/Application	Redirection supported between Client Access servers	Proxying supported between Client Access servers	Comments
Outlook Web App	Yes	Yes	Must have a Client Access server in each Active Directory site to use Outlook Web App.
Exchange Control Panel	Yes	Yes	Must have a Client Access server in each Active Directory site to use the ECP.
Exchange ActiveSync	Yes	Yes	Must have a Client Access server in each Active Directory site to use Exchange ActiveSync.
Exchange Web Services	No (The Autodiscover service provides the application with the correct ExternalURL value)	Yes	Must have a Client Access server in each Active Directory site to use Exchange Web Services.
Availability service	No (The Autodiscover service provides the application with the correct ExternalURL value)	Yes	Must have a Client Access server in each Active Directory site to use the Availability service.
POP3 and IMAP4	No	Yes	Must have a Client Access server in each Active Directory site to use POP3 and IMAP4.

Proxying Performance and Scalability

In an Exchange 2010 proxying environment, poor performance often results 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 servers 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 servers. 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 Knowledge Base article 821268 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 2,000.

For more information about server performance, see Managing the .NET Framework on Windows Server 2003.