多站点情况使用proxy登陆owa

问题：多个站点中，其中只有一个站点有owa，面向internet，现在访问这个owa登陆了另外一个点的用户报错

解决：将owa的验证方式修改为集成身份验证和basic验证即可。

原因：

Microsoft Exchange 2010 – Using Proxying and Redirection

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.

Cross-Site Silent Redirection

Exchange 2010 SP2 lets administrators configure cross-site silent redirection. When this feature is enabled, a user with a mailbox in Active Directory site A who accesses the Outlook Web App URL in Active Directory site B will be silently redirected to the Outlook Web App URL for Active Directory A.

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. If you’re using forms-based authentication, SSL is required. 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.

Cross-site silent redirection prevents users from having to learn a secondary Outlook Web App URL. If the authentication method for the Outlook Web App virtual directory on both the source and target Client Access servers is set to forms-based authentication, the user will only have to enter their credentials once. If the authentication methods differ on the source and target Client Access severs, the users may have to enter their credentials a second time. When using forms-based authentication, you must require SSL on both the source and target Outlook Web App virtual directories.

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.

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.

2. 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.

3. 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.

4. 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.

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.

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.

2. 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.

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 the Exchange 2007 Mailbox server is in the same Active Directory site as CAS-01, one of four possible actions will result.

o 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 forms-based authentication is enabled, this will result in a single sign-on redirection, which is transparent to the user.

o 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.

o 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.

o 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 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 property isn’t 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:

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.

4. 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.

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.

1. 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.

2. 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.

3. 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.

4. 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.

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.

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.

1. 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.

2. 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.

3. 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.

4. 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.

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

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.

参考链接：

http://pei.com/2012/01/microsoft-exchange-2010-%E2%80%93-using-proxying-and-redirection-part-1/

http://pei.com/2012/03/microsoft-exchange-2010-%E2%80%93-using-proxying-and-redirection-part-2/