Microsoft Exchange 2010 – Using Proxying and Redirection (Part 1)
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 are present 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 a user connects 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 the user should be using a better URL, for example, one that’s closer to the Active Directory site their mailbox resides in.
Although the Client Access server’s response can vary by protocol, when a Client Access server receives a request for a user whose mailbox is in an Active Directory site other than the one the Client Access server belongs to, it 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 will issue a redirect to that client. If there’s no ExternalURL property present, 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, when each is used, and how to configure your Client Access servers for each scenario.
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.
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.
Client Access 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.
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.
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.
Redirection for Exchange ActiveSync and Outlook Web App in Exchange 2010
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.
-Jacob Eker, PEI