了解代理和重定向
适用于： Exchange Server 2010 SP2, Exchange Server 2010 SP3
上一次修改主题： 2016-11-28
在 Microsoft Exchange Server 2010 组织中，客户端访问服务器可以在组织中充当其他客户端访问服务器的代理。当一个组织中的不同 Active Directory 站点存在多个客户端访问服务器，但这些站点中至少有一个未向 Internet 公开时，这很有用。
客户端访问服务器还可以对 Microsoft Office Outlook Web App URL 和 Exchange ActiveSync 设备执行重定向。当用户连接到不在其本地 Active Directory 站点中的客户端访问服务器时，或者如果邮箱在 Active Directory 站点之间进行了移动，重定向很有用。如果用户实际上应当使用更有效的 URL，重定向也很有用。例如，用户应当使用距离其邮箱所在的 Active Directory 站点较近的 URL。
客户端访问服务器的响应可能因协议而异。不过，当客户端访问服务器收到请求时，如果用户的邮箱所在的 Active Directory 站点不是客户端访问服务器所属的站点，它通常会针对该用户采取以下措施：在这种情况下，服务器将查看在与用户的邮箱位于同一 Active Directory 站点中的客户端访问服务器上的相关虚拟目录上是否存在 ExternalURL 属性。如果存在 ExternalURL 属性，并且客户端类型支持重定向（例如，Outlook Web App 或 Exchange ActiveSync），则客户端访问服务器会发出到该客户端的重定向。如果不存在 ExternalURL 属性，或如果客户端类型不支持重定向（例如，POP3 或 IMAP4），则客户端访问服务器会尝试将连接代理到目标 Active Directory 站点。
本主题说明了代理和重定向、在什么情况下使用这两种功能以及如何针对每种方案配置客户端访问服务器。
.gif "注释") 注意： |
|---|
| 如果在组织中没有多个 Active Directory 站点，则不必配置 Exchange 2010 以实现代理和重定向。但是，您可能需要配置 URL 的负载平衡，如本主题后面所述。 |
| 注意： |
|---|
| 未向 Internet 公开的客户端访问服务器不必具有单独的安全套接字层 (SSL) 证书，即可允许从另一个客户端访问服务器代理通信。默认情况下，这些服务器可以使用随 Exchange 2010 安装的自签名证书。然而，内部客户端（如 Outlook Web App 或 Outlook）通常不信任这些证书，使用这些证书通常会导致证书警告。如果在具有自签名证书的客户端访问服务器所在的相同 Active Directory 站点中存在内部客户端，则您应将自签名证书替换为由受客户端信任的证书颁发机构颁发的证书。 |
目录
代理概述
重定向概述
使用网络负载平衡进行代理
客户端访问方法摘要
代理性能和可伸缩性
代理概述
在 Microsoft Exchange Server 2003 中，前端服务器通过 HTTP 与后端服务器进行通信。在 Exchange Server 2007 和 Exchange 2010 中，客户端访问服务器通过 RPC 与 Exchange 邮箱服务器进行通信。每个包含 Exchange 2010 邮箱服务器的 Active Directory 站点中都必须具有 Exchange 2010 客户端访问服务器。当一个客户端访问服务器向其他客户端访问服务器发送通信时就会发生代理。在以下情况下，Exchange 2010 客户端访问服务器可以代理请求：
Exchange 2010 客户端访问服务器之间 通过代理两个 Exchange 2010 客户端访问服务器之间的请求，拥有多个 Active Directory 站点的组织能够指定一个客户端访问服务器作为面向 Internet 的服务器，并使该服务器将请求代理到未连接到 Internet 的站点中的客户端访问服务器。然后，面向 Internet 的客户端访问服务器将请求代理到离用户邮箱最近的客户端访问服务器。
**Exchange 2010 客户端访问服务器与 Exchange 2007 客户端访问服务器之间：**通过在一个 Exchange 2010 站点中或 Exchange 2007 站点之间代理 Active Directory 客户端访问服务器与 Active Directory 客户端访问服务器之间的请求，Exchange 2010 和 Exchange 2007 可以在同一个组织中共存。有关如何升级和共存的详细信息，请参阅从 Exchange 2003 客户端访问升级和从 Exchange 2007 客户端访问升级。
使用 Outlook Web App、Exchange ActiveSync、Exchange 控制面板 (ECP)、POP3、IMAP4 和 Exchange Web 服务的客户端可支持代理。当目标客户端访问服务器与源客户端访问服务器运行相同的 Microsoft Exchange 版本或运行比源客户端访问服务器所运行版本更早的 Microsoft Exchange 版本时，支持从一台客户端访问服务器到另一个客户端访问服务器的代理，需要特定于版本的 URL 的情况除外。有关特定于版本的 URL 和 Exchange 2007 和 Exchange 2010 的混合环境中的旧版主机名的详细信息，请参阅从 Exchange 2007 客户端访问升级。有关特定于版本的 URL 和 Exchange 2010 和 Exchange 2013 的混合环境中的旧版主机名的详细信息，请参阅创建旧版 Exchange 主机名。
.gif "警告") 警告： |
|---|
| 当使用 NTLM 身份验证的 IMAP4 客户端尝试连接到不包含目标邮箱的 Active Directory 站点中的客户端访问服务器时，则连接会失败。如果希望 IMAP4 客户端从一个 Active Directory 站点代理到另一个站点，则必须选择备用身份验证方法。 |
| 注意： |
|---|
| 在每个需要允许从基于 Internet 的客户端进行访问的 Exchange 组织中，都至少有一个 Active Directory 站点必须面向 Internet。所有非面向 Internet 的 Active Directory 站点都依赖于面向 Internet 的客户端访问服务器，以代理来自外部客户端的所有相关请求。 |
客户端访问代理
在上图中，用户 1 的邮箱位于邮箱服务器 1 上。用户 2 的邮箱位于邮箱服务器 2 上，用户 3 的邮箱位于邮箱服务器 3 上。每个邮箱服务器都位于不同的 Active Directory 站点中。用户 1 可以在不使用代理的情况下通过客户端访问服务器 1 访问其邮箱，用户 2 可以通过客户端访问服务器 2 访问其邮箱。如果用户 3 尝试通过客户端访问服务器 1 或 2 访问其邮箱，则这两个服务器都会将其请求代理到客户端访问服务器 3。客户端访问服务器 3 不面向 Internet，但是可以从防火墙内的其他服务器接收请求。用户不会看到代理过程。
| 注意： |
|---|
| 不同站点中的客户端访问服务器之间的通信通过安全 HTTP (HTTPS) 进行，但是客户端访问服务器不检查默认使用的证书的状态。该证书仅用于加密，而不用于身份验证，因此会忽略名称不匹配、过期日期和信任状态。 |
代理概述
重定向概述
对于访问的面向 Internet 的客户端访问服务器与其邮箱位于不同 Active Directory 站点的 Outlook Web App 用户，如果该客户端访问服务器是面向 Internet，则可以将这些用户重定向到其邮箱服务器所在站点中的客户端访问服务器。如果 Outlook Web App 用户尝试连接到位于包含其邮箱服务器的 Active Directory 站点外部的客户端访问服务器，他们将看到一个网页，其中包含指向正确的邮箱客户端访问服务器的链接。这称为手动重定向。在 Exchange 2010 SP2 中，管理员可以配置跨站点无提示重定向以便使此重定向过程可以在用户不知道的情况下进行。有关详细信息，请参阅本主题后面的“跨站点无提示重定向”。
| 注意： |
|---|
| 在同时使用了本地 Exchange Server 和 Office 365 的混合环境中，无法使用跨站点无提示重定向。 |
对于访问的面向 Internet 的客户端访问服务器与其邮箱位于不同 Exchange ActiveSync 站点的 Active Directory 用户，如果该客户端访问服务器面向 Internet，并且如果客户端移动电话或设备正确实现了在与 Exchange 2007 和 Exchange 2010 通信时使用的协议中内置的重定向逻辑，则可以将这些用户重定向到其邮箱服务器所在站点中的客户端访问服务器。通过向设备发送包含设备应使用的 URL 的 HTTP 451 错误代码，来实现 Exchange ActiveSync 用户的重定向。设备随后重新配置自己以使用新 URL。
下图说明了重定向在多个 Active Directory 站点拥有多个客户端访问服务器的组织中是如何工作的。
Exchange 2010 中的 Exchange ActiveSync 和 Outlook Web App 的重定向
在上图中，用户 1 通常使用其移动电话访问 Active Directory 站点 1 中的邮箱。管理员随后将其邮箱移动至 Active Directory 站点 2 中的邮箱服务器 2。在设备下次尝试进行同步时，该服务器会通过 HTTP 451 状态错误进行响应。这包含该用户现在应使用的设备 URL。在序列的步骤 3 中，设备重新配置自己并连接到指定 URL。用户 2（其邮箱位于 Active Directory 站点 2 中）尝试通过 Internet 连接到客户端访问服务器 1，从而使用 Outlook Web App 打开其邮箱。对于手动重定向，用户进行身份验证之后，客户端访问服务器 1 便会立即向用户显示一个页面，其中包含一个链接，指向 Active Directory 站点 2 中的客户端访问服务器的 Outlook Web App URL。用户单击该链接，进入 Active Directory 站点 2，然后再次登录以访问其邮箱。对于无提示重定向，当用户进行身份验证时，会在不提示的情况下重定向到 Active Directory 站点 2 中的客户端访问服务器的 Outlook Web App URL。
跨站点无提示重定向
| 注意： |
|---|
| 在同时使用了本地 Exchange Server 和 Office 365 的混合环境中，无法使用跨站点无提示重定向。 |
Exchange 2010 SP2 使管理员可以配置跨站点无提示重定向。跨站点无提示重定向对以位于相同 Exchange 组织中不同 Active Directory 站点的 CAS 为目标的客户端请求执行无提示重定向。例如，具有 Active Directory 站点 A 中的邮箱并且访问 Active Directory 站点 B 中的 Outlook Web App URL 的用户会在不提示的情况下重定向到站点 A 中的 Active Directory 的 Outlook Web App URL。
若要配置跨站点无提示重定向，管理员必须使用已添加到 Set-OWAVirtualDirectory cmdlet 的新 CrossSiteRedirectType 参数。该参数具有两个可能设置。默认设置是 Manual。
Silent 配置此设置时，只要客户端访问服务器必须将 Outlook Web App 请求重定向到位于另一个 Active Directory 站点中的客户端访问服务器或服务器阵列，用户的 Web 浏览器便会自动进行重定向。当在源和目标 CAS OWA 虚拟目录上配置了基于表单的身份验证（需要 SSL）时，无提示重定向还是单一登录事件。若要进行重定向，目标客户端访问服务器 Outlook Web App 虚拟目录必须配置
ExternalURL值。Manual 配置了此设置时，用户会收到通知，告知其正在访问错误的 URL，并且必须单击链接才能访问其邮箱的正确 Outlook Web App URL。仅当客户端访问服务器确定它必须将 Outlook Web App 请求重定向到位于另一个 Active Directory 站点中的客户端访问服务器或服务器阵列时，才会出现此通知。若要进行重定向，目标客户端访问服务器 Outlook Web App 虚拟目录必须配置
ExternalURL值。
例如：
Set-OWAVirtualDirectory -Identity "Contoso\owa (Default Web site)" -CrossSiteRedirectType Silent
有关 Set-OwaVirtualDirectory cmdlet 的详细信息，请参阅：Set-OwaVirtualDirectory
Exchange ActiveSync 的代理和重定向
以下一系列步骤演示对于通过移动电话连接到名为 CAS-01 的 Exchange 2010 客户端访问服务器的用户，如何处理传入请求。
客户端访问服务器查询 Active Directory 以确定用户邮箱的位置以及邮箱服务器上安装的 Microsoft Exchange 版本。
如果用户邮箱位于 Exchange 2003 服务器上，则传入请求将通过代理直接发送到托管用户邮箱和 Exchange ActiveSync 虚拟目录的 Exchange 2003 服务器上。默认情况下，在 Exchange 2003 中，所有邮箱服务器上都安装了 Exchange ActiveSync 虚拟目录。用户邮箱的 Active Directory 站点在这种情况下不适用，因为 Exchange 2003 不使用 Active Directory 站点确定位置。总是直接从 Exchange 2010 客户端访问服务器到 Exchange 2003 邮箱服务器建立连接。
注意：如果在 Exchange 2003 服务器上拥有邮箱的用户尝试通过 Exchange 2010 客户端访问服务器使用 Exchange ActiveSync，除非对 Exchange 2003 服务器的 Microsoft-Server-ActiveSync 虚拟目录启用了集成 Windows 身份验证，否则，该用户将收到错误消息，并且无法进行同步。通过集成 Windows 身份验证，Exchange 2010 客户端访问服务器和 Exchange 2003 后端服务器可以进行通信。 如果用户邮箱位于 Exchange 2007 邮箱服务器上，则 CAS-01 将在用户邮箱服务器所在的 Exchange 2007 站点中查找 Active Directory 客户端访问服务器。此站点可以与 CAS-01 的 Active Directory 站点相同。CAS-01 将代理到 Exchange 2007 客户端访问服务器的 InternalURL 的 Exchange ActiveSync 请求，而无需考虑 ExternalURL 设置。请求将转至位于 IIS 中的 Microsoft 服务器 Exchange ActiveSync 虚拟目录下的 /Proxy 虚拟目录，并默认启用了集成的 Windows 身份验证。
如果用户邮箱所在的 Exchange 2010 邮箱服务器与 CAS-01 处于相同 Active Directory 站点中，则 CAS-01 会提供对邮箱的访问。如果用户邮箱位于不同 Active Directory 站点中的 Exchange 2010 邮箱服务器上，则 CAS-01 将在用户邮箱服务器所在的 Active Directory 站点中查找客户端访问服务器。CAS-01 确定该 Active Directory 站点中是否有 Exchange 2010 客户端访问服务器在 Exchange ActiveSync 虚拟目录上配置了 ExternalURL 属性。如果已配置，则 CAS-01 会向客户端发出包含 ExternalURL 值的 HTTP 错误代码 451，指示客户端重定向到该位置。如果未设置 ExternalURL 值，则会使用 InternalURL 属性（专门针对 /Proxy 虚拟目录）指定的 FQDN 将连接代理到客户端访问服务器。此虚拟目录位于 IIS 中的 Exchange ActiveSync 虚拟目录之下，默认情况下在其上已启用了集成 Windows 身份验证。
.gif "重要")
重要说明：无法在使用基本身份验证的虚拟目录之间进行代理。对于需要在不同服务器上的 Exchange ActiveSync 虚拟目录之间代理的客户端通信，/Proxy 虚拟目录必须使用集成 Windows 身份验证。
代理概述
Outlook Web App 的代理和重定向
以下一系列步骤演示对于通过 Outlook Web App 连接到名为 CAS-01 的 Exchange 2010 客户端访问服务器的用户，如何处理传入请求。
客户端访问服务器查询 Active Directory 以确定用户邮箱的位置以及邮箱服务器上安装的 Microsoft Exchange 版本。
如果用户邮箱位于 Exchange 2003 服务器上，并且用户尝试使用 https://domain name/owa 访问 Outlook Web App，则用户会接收到错误，因为 Exchange 2010 客户端访问服务器无法直接提供对 Outlook Web App 邮箱的 Exchange 2003 访问。然而，如果管理员配置了从 Exchange 2010 到 Exchange 2003 的重定向（通常在从 Exchange 2003 到 Exchange 2010 的迁移过程中会执行此配置），则 Outlook Web App 虚拟目录的 Exchange2003URL 属性设置的值为面向 Internet 的 Exchange 2003 服务器。
如果用户邮箱位于 Exchange 2007 邮箱服务器上，则 CAS-01 将在用户邮箱服务器所在的 Active Directory 站点中查找客户端访问服务器。如果 Exchange 2007 邮箱服务器位于与 CAS-01 相同的 Active Directory 站点中，则会导致四种可能操作之一。
CAS-01 会查找其 ExternalAuthenticationMethods 设置与 Exchange 2010 客户端访问服务器上的 InternalAuthenticationMethods 设置相同的 Exchange 2007 ExternalURL 属性。如果设置匹配，则 CAS 01 将重定向到此外部 URL。如果源和目标 CAS 启用了基于表单的身份验证 (FBA)，则源 CAS 会将一个包含用户凭据和 FBA 设置以及重定向 URL 的隐藏表单发回给浏览器。这对于用户是透明的。
如果未找到匹配的 ExternalURL 设置，则 CAS-01 会查找配置了 ExternalURL 属性的 Exchange 2007 客户端访问服务器（无论是否匹配）。如果找到一个这样的服务器，则 CAS 01 将重定向到此外部 URL。这将导致提示用户进行身份验证。
如果未找到匹配的 ExternalURL 设置，则 CAS-01 会查找其 InternalURL 属性的 InternalAuthenticationMethods 设置与 Exchange 2010 客户端访问服务器上的 InternalAuthenticationMethods 设置相同的 Exchange 2007 客户端访问服务器。如果找到一个这样的服务器，则 CAS 01 将重定向到此 InternalURL。如果启用了基于表单的身份验证，则这会导致单一登录重定向。
如果找不到匹配的 InternalURL，则 CAS-01 会查找配置了 InternalURL 的 Exchange 2007 客户端访问服务器（无论是否匹配）。如果找到一个这样的服务器，则 CAS 01 将重定向到此 InternalURL。这将导致提示用户进行身份验证。
如果 Exchange 2007 邮箱服务器处于不同的 Active Directory 站点中，则 CAS-01 确定是否在该 Active Directory 站点中设置了 ExternalURL 属性。如果设置该属性，并且未启用跨站点无提示重定向，则 CrossSiteRedirectType 值设置为 Manual，会发出手动重定向。在此方案中，会向用户提供一个可单击链接，该链接将用户重定向到指定 URL。
如果启用了跨站点无提示重定向，则 CrossSiteRedirectType 值设置为 Silent，用户会自动重定向到指定 URL。如果 ExternalURL 不存在，并且 /OWA 虚拟目录上的身份验证方法设置为集成 Windows 身份验证，则 CAS-01 会将用户的请求代理到 InternalURL 属性指定的客户端访问服务器。
重要说明：若要使 Exchange 2010 客户端访问服务器可以将 Outlook Web App 请求代理到另一个 Exchange 2007 站点中的 Active Directory 客户端访问服务器，您必须将目标 Exchange 2007 站点中的 Active Directory 客户端访问服务器上的最高版本文件夹从 %installpath%\ClientAccess\OWA\ 文件夹复制到进行代理请求的 Exchange 2010 客户端访问服务器上的相同路径。 重要说明：Exchange 2010 客户端访问服务器从不将 Outlook Web App 请求代理到相同 Active Directory 站点中的 Exchange 2007 客户端访问服务器。相同 Active Directory 站点中的所有请求都会使用客户端访问服务器的 InternalURL 或 ExternalURL 属性（根据所配置的属性）重定向到 Exchange 2007 客户端访问服务器。 如果用户邮箱所在的 Exchange 2010 邮箱服务器与 CAS-01 处于相同 Active Directory 站点中，则 CAS-01 会提供对邮箱的访问。如果用户邮箱位于不同 Active Directory 站点中的 Exchange 2010 邮箱服务器上，则 CAS-01 将在用户邮箱服务器所在的 Active Directory 站点中查找客户端访问服务器。如果找到这样一个服务器，则 Exchange 2010 确定在该 Active Directory 站点中，客户端访问服务器是否设置了 ExternalURL 属性。如果设置该属性，并且未启用跨站点无提示重定向，则会向用户提供一个可单击链接，该链接将用户重定向到指定 URL。如果启用了跨站点无提示重定向，则用户会自动重定向到指定 URL。如果未设置 ExternalURL，并且虚拟目录上的身份验证方法设置为集成 Windows 身份验证，则 CAS-01 会将用户的请求代理到 InternalURL 属性指定的客户端访问服务器。
Exchange 控制面板的代理
Exchange 2010 提供了一个基于 Web 的界面，使用户和组织管理员可为其邮箱或组织配置设置。Exchange 控制面板 (ECP) 可通过 Outlook Web App 中的“选项”菜单进行访问，或是在 Outlook 2010 中，通过选择“语音邮件”选项、请求邮件跟踪信息或配置移动通知来进行访问。在 Outlook 中选择这些选项中任何一项都会启动 Web 浏览器会话。
该会话的目标取决于 Outlook 客户端的当前连接状态。如果通过 TCP 使用 RPC 连接 Outlook 客户端，则客户端会连接到 ECP 虚拟目录的 InternalURL 值。如果使用 Outlook Anywhere 连接客户端，则 Outlook 客户端会启动浏览器会话。该浏览器会话会尝试连接到 ECP 虚拟目录的 ExternalURL 值。URL 通过自动发现服务向 Outlook 客户端提供。
在通过 TCP 连接内部客户端时，ECP 会话将始终连接到用户邮箱所在的 Active Directory 站点中的客户端访问服务器。此方案中不使用代理。当公司网络外部的客户端使用 Outlook Anywhere 进行连接时，客户端会打开一个浏览器会话，该会话连接至 ECP 虚拟目录的外部 URL 或面向 Internet 的 Active Directory 站点的外部 URL（如果用户邮箱位于非面向 Internet 的站点中）。
ECP 的代理逻辑与 Outlook Web App 相同。如果用户邮箱所在的 Exchange 2010 邮箱服务器与接收请求的客户端访问服务器处于相同 Active Directory 站点中，则该客户端访问服务器提供对邮箱的访问。如果用户邮箱位于不同 Active Directory 站点中的 Exchange 2010 邮箱服务器上，则客户端访问服务器将在用户邮箱服务器所在的 Active Directory 站点中查找客户端访问服务器。原始客户端访问服务器会将用户请求代理到该客户端访问服务器。
ECP 的确会执行重定向，但是除非用户显式输入用于访问 ECP 的 URL，否则很少执行。如果用户从 Outlook Web App 访问 ECP，则 Outlook Web App 负责确保用户使用的是正确 URL。如果用户使用的是 Outlook 2010，则 Outlook 和自动发现服务负责确保用户将正确的 URL 用于 ECP。
代理概述
Exchange Web 服务的代理
Exchange Web 服务提供一个 XML 邮件传输接口，使您可以从客户端应用程序管理 Exchange 存储项目并访问 Exchange 服务器功能。从代理、重定向和客户端的角度，此功能通常在以下情况之一的上下文中使用：
可用性服务请求
自动发现请求
设置和检查自动答复 (OOF) 状态
使用 Exchange Web 服务编写的应用程序可以将代理行为用于诸如设置自动答复（外出）消息（如有必要，会在 Active Directory 站点之间进行代理）之类的任务。
以下步骤演示对于某个向名为 CAS-01 的 Exchange 2010 客户端访问服务器进行可用性服务请求的用户，如何处理传入请求。该用户使用 Outlook Web App 检查 Exchange 组织中另一个用户的可用性。
CAS-01 查询 Active Directory 以确定用户邮箱的位置以及邮箱服务器上安装的 Microsoft Exchange 版本。
如果用户邮箱位于 Exchange 2003 服务器上，则 Outlook Web App 会与 Exchange 2003 服务器的 /Public 虚拟目录之间建立 HTTP 连接，并从忙/闲系统文件夹检索请求的信息。
如果用户邮箱位于 Exchange 2007 邮箱服务器上，则会向用户返回错误。在 Exchange 2007 邮箱服务器上包含邮箱的任何 Exchange 组织中，都必须存在可在外部访问的 Exchange 2007 客户端访问服务器。自动发现服务负责将正确的 Exchange Web 服务 URL 返回给客户端。此 URL 必须与用户邮箱所处的邮箱服务器的版本匹配。
如果用户邮箱所在的 Exchange 2010 邮箱服务器与 CAS-01 处于相同 Active Directory 站点中，则 CAS-01 会访问邮箱本身以检索请求的信息。如果用户邮箱处于不同 Active Directory 站点中的 Exchange 2010 邮箱服务器上，则 CAS-01 使用 /EWS 虚拟目录的 InternalURL 属性指定的 FQDN 代理到该 Active Directory 站点中的客户端访问服务器。
重要说明：无论是否设置了 ExternalURL 属性，Exchange 客户端访问服务器都会将可用性服务请求从一个服务器代理到另一个服务器。 重要说明：某些 Exchange Web 服务应用程序使用诸如 GetEvents 和 Unsubscribe 这类 Web 方法，这些方法具有非常强的客户端访问服务器关联。当一个客户端访问服务器必须将其中一个请求代理到另一个 Active Directory 站点时，它可以使用客户端访问服务器的 InternalNLBBypassURL 属性，该属性应始终设置为主机服务器本身的 FQDN。这可确保进行请求的客户端访问服务器可以维持与目标 Active Directory 站点中特定客户端访问服务器的关联。
Exchange Web 服务本身不提供重定向功能，因为自动发现服务（用于向应用程序提供 URL）会提供访问特定邮箱所需的 URL。例如，如果在 Active Directory 站点之间移动邮箱，则 Outlook 会在下次发出查询时，从自动发现服务接收更新的特定于 Active Directory 站点的 URL。这有时可能会导致客户端向其邮箱所在 Active Directory 站点之外的站点中的客户端访问服务器进行可用性服务请求。但是，因为可用性服务仍会处理请求并会根据需要进行代理，所以不会影响用户。
| 重要说明： |
|---|
| 在 Exchange 邮箱服务器上包含邮箱的任何 Exchange 2007 组织中，都必须存在可在外部访问的 Exchange 2007 客户端访问服务器。当自动发现服务将正确的 Exchange Web 服务 URL 返回给请求客户端时，此 URL 会与用户邮箱所处的服务器的版本匹配。对于在 Exchange 2007 邮箱服务器和 Exchange 2010 邮箱服务器上都包含邮箱的任何 Exchange 组织，必须为 Exchange Web 服务配置两个外部 URL，每个安装的 Exchange 版本各一个。 |
POP3 和 IMAP4 的代理
Exchange 2010 可以在客户端访问服务器与 Active Directory 站点之间代理 POP3 和 IMAP4 会话。
以下步骤演示对于使用 POP3 客户端向名为 CAS-01 的 Exchange 2010 客户端访问服务器进行请求的用户，如何处理传入请求。
CAS-01 查询 Active Directory 以确定用户邮箱的位置以及邮箱服务器上安装的 Microsoft Exchange 版本。
如果用户邮箱位于 Exchange 2003 服务器上，则 CAS-01 会将连接代理到在承载用户邮箱的 Exchange 2003 服务器上运行的 POP3 服务。
如果用户邮箱在 Exchange 2007 邮箱服务器上，则 CAS-01 会在用户邮箱服务器所在的 Exchange 2007 站点（可能与 CAS-01 相同的 Active Directory 站点）中查找 Active Directory 客户端访问服务器。CAS-01 会将请求代理到客户端访问服务器。
如果用户邮箱所在的 Exchange 2010 邮箱服务器与 CAS-01 处于相同 Active Directory 站点中，则 CAS-01 会访问邮箱本身。如果用户邮箱处于不同 Active Directory 站点中的 Exchange 2010 邮箱服务器上，则 CAS-01 使用该服务器 POP 配置的 InternalConnectionSettings 属性指定的 FQDN 代理到客户端访问服务器。
重要说明：POP3 或 IMAP4 服务没有 InternalURL 或 ExternalURL 设置，Exchange 2010 客户端访问服务器会在需要时，将 POP3 和 IMAP4 服务请求从一个服务器代理到另一个服务器。 重要说明：尝试代理到另一个 Active Directory 站点的客户端访问服务器不检查 POP3 或 IMAP4 服务是否的确在远程客户端访问服务器上运行。因此，不仅要确保服务在远程 Active Directory 站点中的每个客户端访问服务器上都运行，还要考虑将负载平衡器用于服务，这十分重要。负载平衡将在本主题后面讨论。
代理概述
代理配置
如果客户端访问服务器面向 Internet，请使用 Exchange 管理控制台 (EMC) 或 Exchange 命令行管理程序 (Shell) 在 /Microsoft-Server-ActiveSync、/OWA、/ECP 和 /EWS 虚拟目录上设置 ExternalURL 属性。EWS 虚拟目录只能使用命令行管理程序进行配置。InternalURL 属性会在 Exchange 2010 的初始设置过程中自动配置，应只在要使用负载平衡解决方案时才进行更改。ExternalURL 属性应包括在 DNS 中为 Exchange 组织注册的 FQDN。
下表包含使用 URL https://mail.contoso.com 访问 Outlook Web App 的 Exchange 组织面向 Internet 的客户端访问服务器的 ExternalURL 和 InternalURL 属性的相应值。第二个表包含同一组织的另一个 Active Directory 站点中的非面向 Internet 的客户端访问服务器的 ExternalURL 和 InternalURL 属性的相应值。必须确保所有这些虚拟目录的身份验证方法都设置为集成 Windows 身份验证。使用其他身份验证方法（除了 POP3 和 IMAP4，它们使用 SSL/TLS 并代理用户的基本身份验证凭据）的虚拟目录不支持代理。
| 注意： |
|---|
| 如果使用命令行管理程序创建新的 Outlook Web App 虚拟目录，必须手动配置这些虚拟目录上的 InternalURL 属性。 |
面向 Internet 的客户端访问服务器的 InternalURL 和 ExternalURL 设置
| Exchange 2010 服务 | InternalURL 设置 | ExternalURL 设置 |
|---|---|---|
Outlook Web App |
https://完全限定的计算机名称/OWA |
https://mail.contoso.com/OWA |
Exchange ActiveSync |
https://完全限定的计算机名称/Microsoft-Server-ActiveSync |
https://mail.contoso.com/Microsoft-Server-ActiveSync |
Exchange Web 服务 |
https://完全限定的计算机名称/EWS/Exchange.asmx |
https://mail.contoso.com/EWS/Exchange.asmx |
Exchange 控制面板 |
https://完全限定的计算机名称/ECP |
https://mail.contoso.com/ECP |
非面向 Internet 的客户端访问服务器的 InternalURL 和 ExternalURL 设置
| Exchange 2010 服务 | InternalURL 设置 | ExternalURL 设置 |
|---|---|---|
Outlook Web App |
https://完全限定的计算机名称/OWA |
|
Exchange ActiveSync |
https://完全限定的计算机名称/Microsoft-Server-ActiveSync |
|
Exchange Web 服务 |
https://完全限定的计算机名称/EWS/Exchange.asmx |
|
Exchange 控制面板 |
https://完全限定的计算机名称/ECP |
|
配置重定向
如果有多个 Active Directory 站点面向 Internet，请使用 EMC 或命令行管理程序在 /OWA 和 /Microsoft-Server-ActiveSync 虚拟目录上设置 ExternalURL 属性，以允许在这些站点之间进行重定向。InternalURL 属性会在 Exchange 2010 的初始设置过程中自动配置，应只在要使用负载平衡解决方案时才进行更改。以下两个表列出了在名为 Contoso 的公司的两个 Active Directory 站点中，客户端访问服务器的 ExternalURL 和 InternalURL 设置。这两个站点分别是 usa.contoso.com 和 europe.contoso.com。
| 注意： |
|---|
| 如果使用命令行管理程序创建新的 Outlook Web App 虚拟目录，必须手动配置这些虚拟目录上的 InternalURL 属性。 |
usa.contoso.com 站点中面向 Internet 的客户端访问服务器的 InternalURL 和 ExternalURL 属性设置
| Exchange 2010 服务 | InternalURL 设置 | ExternalURL 设置 |
|---|---|---|
Outlook Web App |
https://完全限定的计算机名称/OWA |
https://usa.contoso.com/OWA |
Exchange 控制面板 |
https://完全限定的计算机名称/ECP |
https://usa.contoso.com/ECP |
Exchange ActiveSync |
https://完全限定的计算机名称/Microsoft-Server-ActiveSync |
https://usa.contoso.com/ Microsoft-Server-ActiveSync |
Exchange Web 服务 |
https://完全限定的计算机名称/EWS/Exchange.asmx |
https://usa.contoso.com/EWS/Exchange.asmx |
europe.contoso.com 站点中面向 Internet 的客户端访问服务器的 InternalURL 和 ExternalURL 属性设置
| Exchange 2010 服务 | InternalURL 设置 | ExternalURL 设置 |
|---|---|---|
Outlook Web App |
https://完全限定的计算机名称/OWA |
https://europe.contoso.com/OWA |
Exchange 控制面板 |
https://完全限定的计算机名称/ECP |
https://europe.contoso.com/ECP |
Exchange ActiveSync |
https://完全限定的计算机名称/Microsoft-Server-ActiveSync |
https://europe.contoso.com/ Microsoft-Server-ActiveSync |
Exchange Web 服务 |
https://完全限定的计算机名称/EWS/Exchange.asmx |
https://europe.contoso.com/EWS/Exchange.asmx |
| 注意： |
|---|
| 如果在至少一个 Active Directory 站点中的 Exchange ActiveSync 虚拟目录上未设置 ExternalURL 属性，则自动发现服务在配置移动电话时会失败，因为 ExternalURL 属性上设置的值会在自动发现过程中传递给移动电话。 |
代理概述
使用网络负载平衡进行代理
如果某个组织拥有多个 Active Directory 站点并且在每个站点中拥有多个客户端访问服务器，则在该组织中可以使用网络负载平衡 (NLB) 对在每个站点中的客户端访问服务器之间代理的通信进行负载平衡，并使用户可直接访问这些服务器。仅仅部署负载平衡器不足以确保对通信进行有效平衡。您还必须执行 InternalURL 和 ExternalURL 属性的一些其他配置。建议在一个负载平衡阵列中仅包含相同 Active Directory 站点内的客户端访问服务器。可以在面向 Internet 的 Active Directory 站点中部署 NLB，也可以在非面向 Internet 的 Active Directory 站点中部署 NLB。
下表列出了在面向 Internet 和非面向 Internet 的站点中的客户端访问服务器上，应为虚拟目录配置的设置。应在 DNS 中配置 NLB 的 FQDN，以解析成负载平衡设备或服务。负载平衡解决方案随后会负责将通信转发到合适的客户端访问服务器。
在使用 NLB 的组织中的客户端访问服务器的虚拟目录设置
| 虚拟目录/服务 | InternalURL | ExternalURL （面向 Internet 的 Active Directory 站点） | ExternalURL （非面向 Internet 的 Active Directory 站点） |
|---|---|---|---|
/OWA |
NLB FQDN（请参阅下面的准则） |
NLB FQDN |
$null |
/ECP |
NLB FQDN（请参阅下面的准则） |
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 |
不适用 |
不适用 |
建议使用以下准则设置 InternalURL 属性：
如果存在内部 Outlook 2010 用户，则某个 Active Directory 站点中所有客户端访问服务器上的 /OWA 和 /ECP 虚拟目录的 InternalURL 属性都可以设置为该站点中服务器的 NLB FQDN。
如果某个 Active Directory 站点中的客户端访问服务器是来自任何其他 Active Directory 站点中客户端访问服务器的 Outlook Web App 或 ECP 代理请求的目标，请确保配置负载平衡器以确保保持关联。这是因为面向 Internet 的站点中的客户端访问服务器无法为每个请求选择服务器并保持自己的关联。
下表列出了在使用网络负载平衡 (NLB) 的组织中的虚拟目录上所需的各种身份验证设置。在使用 NLB 的组织中，NLB URL 用于代替特定客户端访问服务器 URL 来进行客户端连接。
在将 NLB URL 用于进行容错和负载平衡的组织中，客户端访问服务器的虚拟目录身份验证设置
| 虚拟目录/服务 | 面向 Internet 的 Active Directory 站点 | 非面向 Internet 的 Active Directory 站点 |
|---|---|---|
/OWA |
如果使用的是 Microsoft Forefront Threat Management Gateway 2010 (Forefront TMG) 或 Microsoft Forefront Unified Access Gateway 2010 (Forefront UAG)，并启用了基于表单的身份验证，请使用基本或集成 Windows 身份验证，具体取决于防火墙规则委派设置。 如果来自 Internet 的通信在不进行预身份验证的情况下传递给客户端访问服务器，则使用基于表单的身份验证。 应在 /OWA 和 /ECP 虚拟目录上启用相同的身份验证方法。 |
集成 Windows 身份验证 |
/ECP |
如果使用的是 Forefront TMG 或 Forefront UAFG，并启用了基于表单的身份验证，请使用基本或集成 Windows 身份验证，具体取决于防火墙规则委派设置。 如果来自 Internet 的通信在不进行预身份验证的情况下传递给客户端访问服务器，则使用基于表单的身份验证。 应在 /OWA 和 /ECP 虚拟目录上启用相同的身份验证方法。 |
集成 Windows 身份验证 |
/Microsoft-Server-ActiveSync |
基本身份验证。 |
基本身份验证（使用 /Proxy 子虚拟目录执行代理。） |
/OAB |
基本或集成 Windows 身份验证，具体取决于防火墙规则委派设置。 |
基本或集成 Windows 身份验证，具体取决于防火墙规则委派设置（OAB 请求从不在 Active Directory 站点之间进行代理。此虚拟目录仅供 Outlook 客户端使用。） |
/EWS |
基本（可选 - 具体取决于防火墙规则委派设置）。 需要集成 Windows 身份验证。 |
集成 Windows 身份验证 |
POP/IMAP |
根据客户端连接方法的需要。 |
根据客户端连接方法的需要 |
代理概述
在 Active Directory 站点之间进行代理时，由客户端访问服务器使用的负载平衡逻辑
当将成为代理尝试目标的站点中存在多个客户端访问服务器，并且用户邮箱所在的服务器为组合客户端访问服务器和邮箱服务器时，源 Active Directory 站点中的客户端访问服务器将始终选择该组合客户端访问服务器和邮箱服务器作为代理尝试的目标。
Outlook Web App、ECP 和 Exchange Web 服务处理负载平衡的方式与可用性服务和 Exchange ActiveSync 的处理方式不同。Outlook Web App、ECP 和 Exchange Web 服务在部署在相同 Active Directory 站点中的多个客户端访问服务器上时，会实现其自己的负载平衡。如果用户尝试通过 https://mail.contoso.com/owa 访问 Outlook Web App 并代理到 CAS-01，那么下次该用户尝试访问 Outlook Web App 时，将再次代理到 CAS-01，即使 CAS-02 拥有的并发连接非常少，也会发生这种情况。这样做是为了确保可以在不重新进行身份验证或再次请求数据的情况下，完成长时间运行的事务。这称为关联。如果 CAS-01 不可用，则用户会代理到 CAS-02，并可能需要重新进行身份验证。
当在 Exchange 站点之间进行代理时，无论目标服务器的 InternalURL 属性是否使用 NLB URL 进行了配置，Active Directory Web 服务都可以维持关联。这是因为为需要关联的应用程序进行代理请求的客户端访问服务器会使用目标服务器上的 InternalNLBBypassURL 属性。InternalNLBBypassURL 属性使用目标服务器的 FQDN 进行配置，在默认情况下使用 Windows 身份验证。
| 注意： |
|---|
| 对于 Outlook Web App、ECP 和 Exchange Web 服务，应该为防火墙配置基于 Cookie 的关联和基于 IP 的关联。这可确保特定客户端应用程序每次连接到相同的服务器。需要执行此过程，以便不必对每个请求都重复执行 SSL 协商。需维持从客户端应用程序直到事务中涉及的最终客户端访问服务器的关联，这十分重要。 |
| 注意： |
|---|
| 不得更改客户端访问服务器上的 InternalNLBBypassURL 属性值。如果更改该值，则将断开代理的 Exchange Web 服务请求。 |
对于 Exchange ActiveSync，此过程有所不同。当面向 Internet 的客户端访问服务器将请求代理到非面向 Internet 的客户端访问服务器时，进行请求的客户端访问服务器会使用 InternalURL 属性中配置的值在目标站点中查找客户端访问服务器并尝试与其连接。如果该服务器不响应，则请求会失败，并会向客户端返回错误。建议在 NLB 阵列中实现轮循机制负载平衡并将 InternalURL 属性设置为负载平衡值。
还建议将负载平衡用于可用性服务。可用性服务请求不必维护其连接状态。换句话说，来自相同客户端的两个连续的可用性服务请求可以代理到目标 Active Directory 站点中的不同客户端访问服务器，而不会影响性能，并且如果 InternalURL 属性设置为负载平衡值，则不会存在身份验证问题。此外，将 InternalURL 属性设置为负载平衡值会在内部有益于任何 Outlook 2007 和 Outlook 2010 客户端，因为自动发现服务会向这些客户端提供在 InternalURL 属性中设置的负载平衡值，以便使它们可以完成其可用性服务请求。
有关网络负载平衡的详细信息，请参阅了解 Exchange 2010 中的负载平衡。
| 注意： |
|---|
| 在许多部署中，客户端访问服务器角色和集线器传输服务器角色安装在相同的计算机上。在此拓扑中，可以对客户端访问服务器角色与集线器传输服务器角色分开配置 NLB。集线器传输服务器角色当前不支持 NLB。但是，客户端访问服务器角色支持 NLB。若要为客户端访问服务器角色而不是集线器传输服务器角色配置 NLB，请对客户端访问配置端口 80 和 443。集线器传输服务器角色在软件中实现自己的高可用性。 |
代理概述
客户端访问方法摘要
下表总结了用于访问 Exchange 2010 的协议以及如何使用这些协议进行代理和重定向。
用于重定向和代理的客户端访问协议
| 协议/应用程序 | 支持客户端访问服务器之间发生重定向 | 支持客户端访问服务器之间发生代理 | 注释 |
|---|---|---|---|
Outlook Web App |
是 |
是 |
在每个 Active Directory 站点中必须拥有客户端访问服务器才能使用 Outlook Web App。 |
Exchange 控制面板 |
是 |
是 |
在每个 Active Directory 站点中必须拥有客户端访问服务器才能使用 ECP。 |
Exchange ActiveSync |
是 |
是 |
在每个 Active Directory 网站中必须拥有客户端服务器才能使用 Exchange ActiveSync。 |
Exchange Web 服务 |
无（自动发现服务向应用程序提供正确的 ExternalURL 值） |
是 |
在每个 Active Directory 站点中必须拥有客户端访问服务器才能使用 Exchange Web 服务。 |
可用性服务 |
无（自动发现服务向应用程序提供正确的 ExternalURL 值） |
是 |
在每个 Active Directory 网站中必须拥有客户端访问服务器才能使用可用性服务。 |
POP3 和 IMAP4 |
否 |
是 |
在每个 Active Directory 站点中必须拥有客户端访问服务器才能使用 POP3 和 IMAP4。 |
代理性能和可伸缩性
在 Exchange 2010 代理环境中，如果客户端访问服务器接收到大量并发请求，则通常会导致性能不佳。此问题通常是由于来自 ASP.NET 的 Web 服务请求耗尽了线程和可用连接而引起的。这可能会导致客户端访问服务器拒绝请求或处理请求时出现高延迟。
若要解决这些问题，可以通过在客户端访问服务器上编辑 Machine.config 文件来配置多个 ASP.NET 参数。有关如何配置这些参数的详细信息，请参阅 Microsoft 知识库文章 821268，从 ASP.NET 应用程序发出 Web 服务请求时出现争用、性能不佳和死锁。
知识库文章 821268 中介绍的其中两个参数在 Exchange 2010 代理环境中必须设置不同的值。建议您允许每个处理器使用 36 个线程并将 maxconnections 值设置为 2,000。
有关服务器性能的详细信息，请参阅在 Windows Server 2003 上管理 .NET Framework。
© 2010 Microsoft Corporation。保留所有权利。