Welcome  |  Sign In
 | 
Click to Rate and Give Feedback
TechNet
TechNet Library
Exchange Server
Server Roles
Client Access
 Understanding Proxying and Redirect...
Exchange 2007
Understanding Proxying and Redirection

Applies to: Exchange Server 2007, Exchange Server 2007 SP1 Topic Last Modified: 2008-03-14

In a Microsoft Exchange Server 2007 organization, a computer that is running Exchange 2007 that has the Client Access server role installed can act as a proxy for other Client Access servers within the organization. This is useful when multiple Client Access servers are present in different Active Directory sites in an organization and not all Active Directory sites are exposed to the Internet.

A Client Access server can also perform redirection for Microsoft Office Outlook Web Access URLs. Redirection is useful when a user is connecting to an Internet-facing Client Access server that is not in the same Active Directory site as their Mailbox server.

Note:
If you do not have multiple Active Directory sites in your organization, you do not have to configure Exchange 2007 for proxying or redirection.
Note:
Client Access servers that are not exposed to the Internet do not have to have separate Secure Sockets Layer (SSL) certificates. They can use the self-signed certificate that is installed by default with Exchange 2007. For more information, see Understanding the Self-Signed Certificate in Exchange 2007.

To configure your Client Access server for proxying and redirection, you must modify two properties on the virtual directories that are used to access the various Client Access protocols. These two properties are as follows:

  • InternalURL   This property contains the Intranet URL for the virtual directory. It is configured automatically during Setup. In most installations, the InternalURL value does not have to be changed.
  • ExternalURL   This property contains the Internet URL for the virtual directory. This value is published in DNS and must be manually configured depending on your configuration.

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

In Microsoft Exchange Server 2003, the front-end server communicates with the back-end server over HTTP. In Exchange 2007, the Client Access server communicates with the Mailbox server over RPC. You must have an Exchange 2007 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 2007 Client Access server can proxy requests in the following two situations:

  • Between Exchange 2007 Client Access servers   Proxying requests between two Exchange 2007 Client Access servers enables organizations that have multiple Active Directory sites to designate one or more Client Access servers as Internet-facing servers and have those servers proxy requests to Client Access servers in sites that have no Internet presence. An Internet-facing Client Access server will proxy an incoming request to the Client Access server in the same site as the recipient's mailbox. This is known as CAS-CAS proxying.
  • Between an Exchange 2007 Client Access server and an Exchange 2003 server    External clients that connect to Outlook Web Access by using the \Exchange virtual directory or that connect to Microsoft Exchange ActiveSync by using the \Microsoft-Server-ActiveSync virtual directory will have their requests proxied to the appropriate Exchange 2003 back-end server.

Proxying is supported for clients that use Outlook Web Access, Exchange ActiveSync, 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 Exchange Server or an earlier version as the source Client Access server. However, Exchange Web Services cannot proxy from a server that is running Exchange Server 2007 SP1 to a server that is running the original release (RTM) version of Exchange 2007 because the RTM version of Exchange 2007 did not support proxying for Exchange Web Services. The following figure illustrates how proxying works in an organization that has multiple Client Access servers and multiple Mailbox servers.

Note:
In each Exchange organization, at least one Client Access server must be Internet-facing. A Client Access server that has no Internet presence does not 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 will not work for Post Office Protocol version 3 (POP3) or Internet Message Access Protocol version 4rev1 (IMAP4) clients. A client that is using POP3 or IMAP4 must connect to a Client Access server in the same Active Directory site as its Mailbox server.

Client Access proxying


Client Access server Redirection and 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 by using Exchange ActiveSync, they will 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 by using Outlook Web Access, their browser will display a message that includes the URL for Client Access Server 01, the Client Access server that is located in the same site as their Mailbox 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 is not Internet-facing but can receive requests from other servers inside the firewall. Proxying is not 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 illustrates how incoming requests are handled for a user who connects to an Exchange 2007 Client Access server named CAS-01 by using a mobile device.

  1. The Client Access server queries the Active Directory directory service to determine the location of the user's mailbox and the version of Microsoft Exchange that is installed on the Mailbox server. If the user's mailbox is on an Exchange 2007 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 2007 Client Access server that is 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 2007 Client Access server within the destination Active Directory site. If the incoming request is to an Exchange 2007 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 2007 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 2007 Client Access server and the Exchange 2003 back-end server to communicate by using Kerberos authentication.
  3. 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 there is a Client Access server that is closer to the user's Mailbox server, Exchange 2007 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 device 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 is not 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 Access

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

  1. The Client Access server queries Active Directory to determine the location of the user's mailbox and the version of Microsoft Exchange that is installed on the Mailbox server. If the user's mailbox is on an Exchange 2007 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 Access by using https://domain name/owa, they will 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 Access virtual directory. If the incoming request is to an Exchange 2007 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 is an Exchange 2007 Client Access server within the destination Active Directory site. If the incoming request is to an Exchange 2007 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. In this case, skip step 3.
  3. If the user's mailbox is on an Exchange 2007 mailbox server, CAS-01 locates a Client Access server that is in the same Active Directory site as the user's mailbox server. When one is found, Exchange 2007 determines whether the Client Access server has the InternalURL property configured and if 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 that is specified by the ExternalURL property. If an external URL is not specified, CAS-01 will proxy the user's request to the Client Access server that is specified by the InternalURL property.
    Note:
    An internal URL is configured automatically during Exchange 2007 Setup. The default value of the ExternalURL property is $null. For Internet-facing Client Access servers, the ExternalURL property should be set to the value published in DNS for that Active Directory site. For Client Access servers that do not have an Internet presence, the ExternalURL property does not need to be configured.

Proxying for Web Services

The following scenario illustrates how incoming requests are handled for a user who connects to an Exchange 2007 Client Access server named CAS-01 by using Exchange Web Services.

  1. The Client Access server queries Active Directory to determine the location of the user's mailbox and the version of Microsoft Exchange that is installed on the Mailbox server. If the user's mailbox is located on a server that is running Microsoft Exchange Server 2003, proxying cannot be performed and the request will fail. If the user's mailbox is on a server that is running Exchange 2007 Service Pack 1 (SP1), continue to step 2. If the user's mailbox is located on a server that is running the RTM version of Exchange 2007, the request will fail.
  2. When the Exchange Web Services request reaches CAS-01, Exchange Web Services will process the request and proxy it to the site that contains the user's Mailbox server. Exchange Web Services can support a single request for more than one user. If the incoming request contains multiple users, these users' mailboxes must be in the same Active Directory site. A single request for multiple users in different Active Directory sites is not supported for any web services other than the Availability Service. If the user's mailbox is located on an Exchange 2007 Mailbox server in a site that includes an Exchange 2007 SP1 Client Access server, CAS-01 proxies the request to the destination Active Directory site.
    Note:
    The InternalURL and NLBByPassURL properties are configured automatically during Exchange 2007 Setup. For Client Access servers that do not 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 Access virtual directories by using the Exchange Management Console or the Exchange Management Shell. The InternalURL property is configured automatically during the initial setup of Exchange 2007 and should rarely have to be changed. The ExternalURL property should contain the URL that is registered for your Exchange organization in DNS, for example, http://www.contoso.com/owa for Outlook Web Access. The following table contains the appropriate values for the ExternalURL and InternalURL properties for an Internet-facing Client Access server for the Exchange organization that is 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 is not supported for virtual directories that use other authentication methods.

Note:
If new Outlook Web Access virtual directories are created by 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 2007 service InternalURL setting ExternalURL setting

Outlook Web Access

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/exchange.asmx

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

Exchange 2007 service InternalURL setting ExternalURL setting

Outlook Web Access

https://computername/OWA

$N$Null

Exchange ActiveSync

https://computername/Microsoft-Server-ActiveSync

$N$Null

Exchange Web Services

https://computername/EWS

$Null

For more information about how to configure virtual directories, see the following topics:

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

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

Redirection for Outlook Web Access in Exchange 2007


Redirection for Outlook Web Access

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 Access URL for their Client Access server. They will not be 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 is not Internet-facing, but can receive requests from other servers within the firewall. Proxying is not visible to the user.

Note:
Redirection is supported only for clients that use Outlook Web Access. Clients that use Exchange ActiveSync, POP3, and IMAP4 cannot use redirection. Clients that use Web Services will use the Autodiscover service to determine the correct Client Access server settings.
Note:
When you install Exchange 2007, four virtual directories are created for Outlook Web Access: owa, Exchange, Public, and ExchWeb. The owa virtual directory provides access to Exchange 2007 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 by using https://server name/owa, they will 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 by using https://server name/Exchange, the Exchange 2007 Client Access server will proxy their request to the Exchange 2003 mailbox server. If a user who has a mailbox on Exchange 2007 accesses Outlook Web Access by using https://server name/owa, they will be able to access their mailbox directly. If they log on to Outlook Web Access by 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 Access virtual directories by using the Exchange Management Console or the Exchange Management Shell. The InternalURL property is configured automatically during the initial setup of Exchange 2007 and should rarely have to be changed. 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 Access virtual directories are created by using the Exchange Management Shell, you must manually configure the InternalURL property on those virtual directories.

For more information about how to manage Outlook Web Access virtual directories, see Managing Outlook Web Access Virtual Directories in Exchange 2007.

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

Exchange 2007 service InternalURL setting ExternalURL setting

Outlook Web Access 

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 2007 service InternalURL setting ExternalURL setting

Outlook Web Access 

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 Access 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 by 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 distribute traffic among the Client Access servers in each site for failover redundancy. We do not support including Client Access servers from different Active Directory sites within the same 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 illustrates two Active Directory sites that implement NLB.

Proxying in an organization that uses NLB


Proxying With Network Load Balancing

The following table lists the settings for the virtual directories that are 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

Virtual directory InternalURL setting ExternalURL setting Authentication method

/OWA

https://computername/OWA

https://www.contoso.com/OWA

If the Internet Security and Acceleration (ISA) Server computer is using forms-based authentication, Outlook Web Access should use Integrated Windows authentication. If authentication is not being handled on the ISA Server computer, Outlook Web Access should be configured with forms-based authentication.

/OAB

https://computername/OAB

https://www.contoso.com /OAB

Integrated Windows authentication

/UnifiedMessaging

https://computername/UnifiedMessaging

https://www.contoso.com /UnifiedMessaging

Integrated Windows authentication

/Microsoft-Server-ActiveSync

https://computername/Microsoft-Server-ActiveSync

https://www.contoso.com /Microsoft-Server-ActiveSync

Integrated Windows authentication

/EWS

https://computername/EWS

https://www.contoso.com /EWS

Integrated Windows authentication

Note   When you configure your firewall, you must configure IP Affinity for proxying to succeed for Exchange Web Services and Outlook Web Access. 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

Virtual directory InternalURL setting ExternalURL setting NLBBypassURL setting Authentication method

/OWA

https://computername/OWA

$Null

$Null

Integrated Windows authentication

/OAB

https://NLBname/OAB

$Null

$Null

Integrated Windows authentication

/UnifiedMessaging

https://NLBname/UnifiedMessaging

$Null

$Null

Integrated Windows authentication

/Microsoft-Server-ActiveSync

https://NLBname/Microsoft-Server-ActiveSync

$Null

$Null

Integrated Windows authentication

/EWS

https://NLBname/EWS

$Null

https://computername/EWS

Integrated Windows authentication
Note:
For Outlook Web Access and Exchange Web Services, you must also have Kerberos authentication enabled.

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 are exposed to the Internet, and will prevent clients from successfully connecting to these servers or being redirected to these servers.

Outlook Web Access and Exchange Web Services handle load balancing differently than the Availability service and Exchange ActiveSync. Outlook Web Access and Exchange Web Services implement their own load balancing when proxying to a site with multiple Client Access servers. If a user tries to access Outlook Web Access through https://www.contoso.com/owa and is proxied to a non-Internet facing Active Directory site that contains CAS-01, CAS-02, and CAS-03, a user who is proxied to CAS-01 the first time will always be proxied to CAS-01, even if CAS-02 has fewer concurrent connections. If CAS-01 is unavailable, the user will be proxied to CAS-02.

Note:
For both Outlook Web Access and Exchange Web Services, your firewall should be configured for IP Affinity or cookie-based 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 is not 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 by using information that is stored in the local Administrator account. This connection can then be used by other user requests. In a Network Load Balancing 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 Network Load Balancing in both the Internet-facing and non-Internet facing Active Directory sites. In a non-Internet facing Active Directory site that does not have Network Load Balancing, 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. Therefore, if a client is proxied to CAS-02 the first time that they connect, they will be proxied to CAS-02 every time that they connect.

For more information about Network Load Balancing, 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 Network Load Balancing for the Client Access server role separately from the Hub Transport server role. Network Load Balancing is currently not supported on the Hub Transport server role. However, it is supported for the Client Access server role. To configure Network Load Balancing 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 that are used to access Exchange 2007 and how they are used for proxying and redirection.

Client Access protocols for redirection and proxying

Protocol Client Access server to Mailbox server communication supported between Active Directory sites Redirection supported between Client Access servers Proxying supported between Client Access servers Comments

Outlook Web Access 

No

Yes

Yes

Must have a Client Access server in each Active Directory site that contains a Mailbox server and in each Internet-facing Active Directory site to use Outlook Web Access.

Exchange ActiveSync 

No

Use the Autodiscover service to determine the correct Client Access server end point.

Yes

Must have a Client Access server in each Active Directory site to use Exchange ActiveSync.

Exchange Web Services

Yes in RTM, No in SP1

Use the Autodiscover service to determine the correct Client Access server end point.

No for RTM, Yes for SP1

Must have a Client Access server in each Active Directory site to use Exchange Web Services.

Availability service (used by Office Outlook 2007)

No

Use the Autodiscover service to determine the correct Client Access server end point.

Yes

Must have a Client Access server in each Active Directory site to use the Availability service.

Outlook Anywhere (RPC over HTTP)

Yes, with RPC

No

Not applicable

Not applicable

WebDAV and Exchange 2000 Server or Exchange 2003 

Yes, over HTTP

No

Not applicable

Not applicable

POP3 and IMAP4

No

No

No

POP3 and IMAP4 clients must access a Client Access server in the same Active Directory site as their mailbox.

In an Exchange 2007 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 that are explained in the previous Knowledge Base article must be set differently in an Exchange 2007 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:

© 2008 Microsoft Corporation. All rights reserved. Terms of Use  |  Trademarks  |  Privacy Statement
Page view tracker