支持 HTTP 访问

上一次修改主题： 2007-02-01

来自客户端计算机的 HTTP 请求无论是由浏览器生成还是由专用客户端生成，均将发送到前端服务器。前端服务器使用 ActiveDirectory 来确定将请求代理到的后端服务器。

确定相应的后端服务器后，前端服务器将请求转发到该后端服务器。除了特定头信息指示请求通过前端服务器传递之外，该请求与从客户端发送的原始请求几乎相同。特别是，HTTP 主机头保持不变，与将请求发送到的前端服务器的名称（即用户在浏览器中输入的主机名或完全限定域名）匹配。前端服务器使用后端服务器的主机名（例如 backend1）与后端服务器联系，但是在请求的 HTTP 头中，前端服务器发送客户端所使用的主机头，例如 www.adatum.com。该主机头设置可以确保由相应的后端 Exchange 虚拟服务器处理请求。有关在后端服务器上配置虚拟服务器的详细信息，请参阅配置后端服务器。

对于 HTTP 请求，无论客户端通过端口 80 还是 443（SSL 端口）与前端服务器联系，前端服务器始终通过 TCP 端口 80（默认 HTTP 端口）与后端服务器联系。这意味着：

• Exchange 前端服务器上的 HTTP 虚拟服务器只能侦听端口 80 (HTTP) 或 443 (HTTPS)。

  注意：
  端口 80 和端口 443 以外的任何其他端口均不能用于 Exchange 前端服务器上的 HTTP 虚拟服务器。

• 尽管客户端应使用 SSL 加密来与前端服务器进行通信，但是在前端服务器与后端服务器之间永远不会使用 SSL 加密。

• 前端/后端拓扑中不支持仅通过端口号与其他服务器区分的 HTTP 虚拟服务器。例如，如果后端服务器拥有侦听端口 8080 的 HTTP 虚拟服务器，则只有客户端直接指向后端服务器（例如 http://backend1:8080/data），才可以访问该后端服务器。连接到前端服务器的客户端无法访问此数据。

后端服务器正常地处理来自前端服务器的 HTTP 请求，并通过前端服务器将响应原封不动地发送回客户端。整个过程对于客户端是透明的，客户端只与前端服务器交互。客户端不知道如何在内部处理请求。

查找用户邮箱

要通过 HTTP 访问邮箱文件夹，Exchange 前端服务器和后端服务器上必须均存在指向邮箱的虚拟目录。

注意：
用户邮箱不能存储在前端服务器上。

在安装 Exchange 时，会在默认虚拟服务器中创建一个名为“Exchange”的虚拟目录。此目录指向 Exchange 组织的默认 SMTP 域。通过 Exchange 系统管理器在前端服务器上配置其他虚拟目录时，可以选择该 SMTP 域名。在 Exchange 2000 Server SP3 和 Exchange Server 2003 中，连接到该虚拟服务器的用户在 Active Directory 中包含同一个域的对象的 SMTP 代理地址列表中必须有电子邮件地址。在 Exchange Server 2003 SP1 中，用户可以通过在 URL 中指定 SMTP 地址来覆盖该 SMTP 域（对于显式登录），也可以只使用隐式登录。有关详细信息，请参阅本主题后面的“登录到 Outlook Web Access”。

在选择 SMTP 域的对话框中，域列表是存在收件人策略的所有域的列表。因此，在列表中可能会看到重复的域；选择哪个域无关紧要。

前端服务器（根据虚拟服务器或虚拟目录的设置）检测到对邮箱存储中的某个位置的请求后，将使用轻型目录访问协议 (LDAP) 与域中的某个 Active Directory 全局编录服务器联系，确定包含用户邮箱的后端服务器。

登录到 Outlook Web Access

用户可以使用隐式登录或显式登录登录到 Outlook Web Access。

隐式登录

如果将前端服务器配置为对用户进行身份验证，则用户可以通过省略请求中的用户名并将浏览器指向其邮箱虚拟目录来访问其邮箱。常用的 URL 为 https://*<服务器>/*exchange/。对用户进行身份验证之后，将使用身份验证信息来查找 Active Directory 中与该用户关联的邮箱以及该邮箱所处的后端服务器。使用用户名更新 URL 并将其发送到相应的后端服务器。此方法称为隐式登录。隐式登录仅适用于登录到 Outlook Web Access；专用 HTTP 客户端通常不使用隐式登录。

Exchange 2000 Server SP3 和 Exchange Server 2003

隐式登录使用为 HTTP 虚拟目录指定的 SMTP 域来标识用户。因此，连接到该虚拟服务器的用户在 Active Directory 中包含同一个域的对象的 SMTP 代理地址列表中必须有电子邮件地址。

Exchange Server 2003 SP1

隐式登录不再专门依赖于指定的 SMTP 域。可以从其登录收集所有用户信息。用户可以使用任何邮箱的 Exchange 虚拟目录来访问其电子邮件。

显式登录

用户可以使用几个 URL 连接到 Outlook Web Access。常用的 URL 为 https*://<服务器>/exchange/<用户名*>/。使用此 URL 访问 Outlook Web Access 称为显式登录。

没有将前端服务器配置为对用户进行身份验证时（有关身份验证的详细信息，请参阅 HTTP 的身份验证机制），或用户尝试访问不属于自己的、但是有权访问的邮箱时（例如在委派用户的情况下），必须使用显式登录。

Exchange 2000 Server SP3 和 Exchange Server 2003

前端服务器收到来自客户端的显式登录请求时，将从 URL 提取用户名并将其与虚拟目录或虚拟服务器关联的 SMTP 域名组合在一起，构成完全限定 SMTP 地址。前端服务器在 Active Directory 中查找此地址并确定包含与该地址关联的邮箱的后端服务器。然后，前端服务器将请求转发到该后端服务器，由该后端服务器处理请求并通过前端服务器将其返回到客户端。

Exchange Server 2003 SP1

用户可以选择通过在 URL 中指定 SMTP 地址，覆盖为邮箱虚拟目录配置的 SMTP 域。例如，https://<服务器>/exchange/username@domain.com。如果未指定任何 SMTP 域，则将使用来自虚拟目录的 SMTP 域。

可以禁止特定的用户访问 Outlook Web Access，方法是对这些用户禁用 HTTP 协议。要更改用户的协议设置，在“Active Directory 用户和计算机”中，使用用户属性中的“Exchange 高级”选项卡。

简化 Outlook Web Access URL

用户通常希望可以使用更简单的 URL 访问其邮箱。有关简化 Outlook Web Access URL 的详细说明，请参阅如何简化 Outlook Web Access URL。

启用“更改密码”功能

如果使用 Outlook Web Access，则可以在 IIS 中启用更改密码功能，以实现以下功能：

• 密码过期时通知用户。
• 使用户能够使用 Outlook Web Access 中的“选项”按钮来更改其密码。

请记住，如果希望使用更改密码功能，还必须在客户端与前端服务器之间使用 SSL，以便在传输期间保护密码。此外，还必须在前端服务器和后端服务器上创建一个名为 IISAdmPwd 的虚拟目录，用于处理更改密码请求。

注意：
只有希望用户能够直接连接到后端服务器时，后端服务器上才必须要求使用 SSL。但是，请记住，前端服务器在连接到后端服务器时无法使用 SSL。因此，如果后端服务器上要求使用 SSL，请确保在下列目录上不要求使用 SSL，以便前端服务器仍可以连接到这些目录上：Exchange、Public、ExchWeb、Exadmin 和任何邮箱或公用文件夹虚拟根目录。

有关如何配置更改密码功能的详细信息，请参阅使用 Outlook Web Access 实现更改密码功能。

有关如何配置 SSL 的详细信息，请参阅帮助保护客户端到前端服务器的通信。

查找公用文件夹

就像必须为邮箱配置虚拟目录一样，也必须为将可以通过前端服务器进行 HTTP 访问的每个公用文件夹树配置虚拟目录。

安装 Exchange 时，将在默认的 Exchange HTTP 虚拟服务器下创建一个名为“public”的虚拟目录，以允许访问默认（可通过 MAPI 访问）公用文件夹树。创建其他公用文件夹树时（例如用于承载应用程序），还必须在 Exchange 系统管理器中创建虚拟目录，以通过 HTTP 公开这些树。每台前端服务器上与承载公用文件夹树的所有后端服务器上必须存在相同的虚拟目录。

在访问默认（即可通过 MAPI 访问）公用文件夹树时处理对公用文件夹树中的某个 URL 的请求，与在访问通用公用文件夹（也称为应用顶级层次结构 [TLH] 或非 MAPI TLH）时会有所不同。

在这两种情况下，访问公用文件夹有双重目标：

• 为了可用性   如果数据位于 Exchange 组织的某个 Exchange 2000 Server 或 Exchange Server 2003 公用文件夹中，并且可以通过 HTTP 进行访问，则可供该用户使用。
• 为了一致性   只要服务器可用并且用户已进行身份验证，将由同一台公用文件夹服务器处理来自该用户的每个请求。对于经过身份验证的用户，确保转到同一台公用文件夹服务器则意味着，这些用户在每次通过前端服务器访问公用文件夹树时可以看到相同的数据（包括已读邮件和未读邮件的状态，这些状态存储在各个服务器上并且不会在公用文件夹服务器之间进行复制）。对于维护会话状态的服务器应用程序（例如某些使用 Active Server Pages (ASP) 生成的应用程序），用户始终转到同一台后端服务器也非常重要。

公用文件夹引用

在 Exchange 中，可以按文件夹配置公用文件夹复制。实际的公用文件夹树层次结构可以从组织中的所有 Exchange 公用文件夹服务器上获得，但是不一定能获得每个文件夹的内容。此信息未存储在 Active Directory 中，而是作为属性在公用文件夹存储的每个文件夹上维护。因此，由前端服务器选择的后端服务器不包含客户端所请求的文件夹的内容时，需要进行特殊处理。

下图说明了公用文件夹引用如何通过前端服务器。

1. HTTP 客户端根据前端服务器进行身份验证，并请求 /public/PublicFolder2。

2. 前端服务器根据 Active Directory 对用户进行身份验证，并请求用户的默认公用文件夹存储的位置。

3. Active Directory 向前端服务器表明，用户的默认公用文件夹存储位于 Server1 上。

4. 前端服务器将客户端请求发送到 Server1。

5. Server1 通知前端服务器自己没有 /public/PublicFolder2 的内容，但是 Server2 和 Server3 上有。

6. 前端服务器根据包含内容的服务器（在此例中为 Server2 和 Server3）列表执行哈希算法。在此例中，哈希运算的结果为 Server2，所以，前端服务器将请求转发到 Server2。

   注意：
   哈希算法应用给定的数字（在此例中为用户的安全令牌）并用其生成列表中的某个位置，以便所有可能的输入均匀分散到列表中。

7. Server2 将 /public/PublicFolder2 的内容返回到前端服务器，然后由前端服务器将内容发送到 HTTP 客户端。

默认 (MAPI) 公用文件夹树

客户端访问 Outlook Web Access 中的默认公用文件夹树时，将尝试保持与 MAPI 客户端（例如 Outlook）对等。每个邮箱存储与组织中的某个特定公用文件夹存储（有时与邮箱存储在同一台服务器上，有时在专用的公用文件夹服务器上）关联。与用户的邮箱存储关联的公用文件夹存储是 Outlook 中显示公用文件夹层次结构（树）的公用文件夹存储。

用户通过 HTTP 请求默认公用文件夹树中的某个公用文件夹时，前端服务器将对用户进行身份验证，并在 Active Directory 中查找该用户，以确定与该用户的邮箱存储关联的公用存储。然后，前端服务器将请求转发到用户的公用文件夹服务器。

注意，如果前端服务器未配置为对用户进行身份验证，则不会平衡公用文件夹请求的负载。

通用公用文件夹树

因为具有 MAPI 继承性，所以默认公用文件夹树服务器与邮箱存储关联；通用公用文件夹树没有此类关联。因此，对通用公用文件夹树中的文件夹的请求的处理与对默认公用文件夹树中的文件夹的请求略有不同。

客户端请求访问通用公用文件夹树时，前端服务器首先与 Active Directory 联系，以查找组织中运行 Exchange 2000 Server 或 Exchange Server 2003 并且包含客户端尝试访问的特定通用公用文件夹树副本的所有服务器的列表。

注意：
通用公用文件夹树在 Exchange Server 5.5 中不可用。

然后，前端服务器根据服务器列表在哈希算法中使用用户的身份验证令牌，以确保：

• 用户跨可用服务器进行负载平衡。
• 单个用户的请求始终由同一台后端服务器处理，与所使用的 HTTP 客户端无关。

注意：
如果添加或删除后端服务器，哈希算法的输出将更改，之后，可能会将用户重定向到其他服务器。有关详细信息，请参阅本主题后面的“添加或删除后端服务器”。还应注意的是，此内容适用于 MAPI。

内容在后端服务器上不可用时

后端服务器收到对后端服务器上没有副本的公用文件夹的请求时，前端/后端拓扑会进行特殊处理。对默认公用文件夹存储中的文件夹以及通用公用文件夹树中的文件夹进行此处理。

后端服务器收到此类请求时，将返回包含所请求的文件夹的内容的服务器列表。前端服务器不会将此信息传递回客户端，而是根据新的服务器列表重新运行相同的哈希算法，以确保负载平衡和视图一致。因此，在使用公用文件夹树的部分副本的组织中，前端服务器可能必须执行两个 HTTP 请求才能满足客户端的一个请求。但是，在处理客户端请求时，前端服务器将缓存包含相应内容的服务器的有关信息，这样，以后在访问同一个文件夹中的数据时，前端服务器可以避免额外的请求。

前端服务器维护的缓存可以显著减少为访问公用文件夹和专用文件夹发送到 Active Directory 和后端服务器的查询数。缓存信息在十分钟之后过期，并且在检测到服务器配置更改时也会重置。

注意：
不能选择 Exchange 5.5 服务器，因为这些服务器不支持所需的 HTTP WebDAV 扩展。

后端服务器停机时间

如果后端服务器为了进行维护而停机，或无法通过 HTTP 访问，则前端服务器将无法与其连接。前端服务器将在 10 分钟内将该服务器标记为“不可用”，如果有其他服务器可用，则将请求发送到其他服务器；如果没有其他服务器可用，则请求失败。后端服务器不可用时，前端服务器会自动将请求转到其他服务器。因此，后端服务器恢复运行之后，可能在长达 10 分钟的时间内无法通过前端服务器进行访问，因为前端服务器可能仍将该后端服务器标记为不可用。

此过程可以显著提高公用文件夹访问的可靠性。前端服务器将尝试与多台后端服务器联系以获取数据，而直接连接到后端服务器的客户端则无法这样做。

添加或删除后端服务器

哈希算法的目标是平衡负载；但是，该算法的条件是用户在服务器上的分布取决于服务器数。因此，如果因为添加或删除了服务器而造成承载公用文件夹内容的服务器列表更改，则哈希算法的结果可能会将用户转到新服务器来处理以后的请求。通常，处理用户请求的服务器更改时，用户无法判断任何实际的更改，下列情况除外：

• 用户可能会观察到邮件的已读或未读状态已重置。
• 维护会话状态的 Web 应用程序（在通用公用文件夹树中运行）的用户如果在过渡期间使用该应用程序，则可能需要重新启动应用程序会话。

因此，建议管理员在公用文件夹服务器中添加或删除文件夹内容之前通知用户。

在高级别，哈希算法的运算如下所述：编号为 1 和 2 的两台后端服务器保存公用文件夹的内容。然后，如果六个不同用户 A、 B、 C、 D、 E 和 F 尝试访问此文件夹中的数据，前端服务器将如下所述在两台服务器上分布请求：

• 用户 A、B 和 C 从服务器 1 获取数据。
• 用户 D、E 和 F 从服务器 2 获取数据。

注意：
此负载平衡透明地完成 — 用户不知道实际处理请求的后端服务器。

然后添加另一台服务器“服务器 3”，文件夹的内容也将复制到此服务器。现在，用户的分布如下：

• 用户 A 和 B 从服务器 1 获取数据。
• 用户 C 和 D 从服务器 2 获取数据。
• 用户 E 和 F 从服务器 3 获取数据。

在此例中，用户 A、B 和 D 未更改服务器，但是用户 C、E 和 F 更改了服务器。