内部网络环境中的 Outlook 客户端协议连接流程 |第 12 部分#36

在本文中，我们将回顾由内部 Outlook 客户端实现的自动发现流程的基本概念。
术语“内部”与具有本地 Active Directory 的专用网络环境相关。

获取自动发现信息

自动发现过程的第一部分由自动发现客户端定位可用的自动发现端点的阶段实现，该端点可以为其提供所需的自动发现信息。

关于自动发现协议最有趣的事情之一是，查找可用自动发现端点的阶段由位于专用组织网络中的内部 Outlook 客户端以完全不同的方式执行，并且必须使用本地 Active Directory 与外部 Active Directory无法访问本地 Active Directory 的 Outlook 客户端。

在下一篇文章中 - Exchange 客户端及其面向公众的 Exchange 服务器 |第 13#36 部分将描述由外部 Outlook 客户端实现的自动发现过程。

场景人物描述

为了能够演示基于 Active Directory 的环境的自动发现流，我们将使用具有以下特征的场景：

我们场景中的Exchange环境的章程如下：

• Active Directory 内部域名 - o365info.local
• 公共域名 - o365info.com
• 组织用户的电子邮件地址基于邮件后缀 -o365info.com
• Exchange\Active Directory 站点 - 该组织有两个 Exchange\Active Directory 站点：纽约站点和洛杉矶站点（纽约站点，是公司的总部）。
• 纽约站点的 Exchange CAS 服务器的名称是 - exo1.o365info.local
• 洛杉矶站点中的 Exchange CAS 服务器的名称是 - exo2.o365info.local
• 约翰是一个组织的用户，他的邮箱托管在纽约交易所网站上。
• Alice 是一个组织的用户，他的邮箱托管在洛杉矶交换站点上。

一般注意事项

在接下来的场景中将提供的内部网络中的 Exchange 工作流程的描述是“简化的解释”或真实的流程。
我已经删除了一些“客户端\服务器进程”以使信息更易于理解，因为我想重点讨论“交换内部 FQDN 和 URL 地址”的主题。

场景1：邮件客户端需要访问他的邮箱。

约翰的邮箱托管在纽约站点。
约翰位于公司内部网络上，需要访问他的邮箱。

第 0 步 - 在本地 Active Directory 中注册可用的自动发现端点

默认情况下，每个 Exchange CAS 服务器将使用其内部主机名自动在 Active Directory SCP 中注册自己。
在某些情况下，我们需要更改此默认行为。

在我们的特定场景中，组织使用两个 Exchange CAS 服务器，它们自动在 Active Directory SCP（编号 0）中注册。

第 1 步：邮件客户端自动发现过程
在本地 Active Directory 环境中，自动发现过程的第一阶段是通过对本地 Active Directory 的查询（LDAP 查询）来实现的。
来自 Active Directory 的“答案”将包括 Exchange CAS 服务器的“内部 FQDN 名称” - exo1.o365info.local（数字 1 ）。

请注意，Active Directory 包含有关两个可用 Exchange CAS 服务器的信息。如果我们没有更新本地 Active Directory SCP 中有关 Exchange CAS 服务器“物理位置”（Active Directory 站点名称）的信息，则获取服务器列表的自动发现客户端不会特定的偏好。

自动发现将随机选择列表中出现的主机名之一。

在我们的场景中，邮件客户端将尝试主机名的地址 - exo1.o365info.local

第 2 步：寻址内部 Exchange CAS 服务器

自动发现客户端使用 HTTPS 协议发起与内部 Exchange CAS 服务器 (exo1.o365info.local) 的连接尝试。
自动发现客户端将要求服务器通过提供公共证书（编号2）来证明其身份。

第 3 步 - 验证 Exchange 服务器公共证书

自动发现客户端将验证服务器证书是否包含 FQDN - exo1.o365info.local

第 4 步 - 自动发现客户端提供用户凭据

如果邮件自动发现验证 Exchange 证书“正常”，则自动发现客户端将需要向自动发现端点（即 Exchange CAS 服务器）（编号4）提供用户凭据。

第 5 步 - 请求 Exchange 服务器提供 autodiscover.xml 文件

邮件客户端将要求 Exchange 服务器提供所需的 autodiscover.xml 文件。交易所向自动发现客户端提供 autodiscover.xml 文件，表示自动发现响应（编号5）。

在下面的屏幕截图中，我们可以看到 autodiscover.xml 文件内容的一个小示例。

Exchange EWS服务 - 我们可以看到使用主机名提供的Exchange EWS服务的URL地址 - exo1.o365info.local

Exchange ECP - Exchange 控制面板的 URL 地址（网络邮件客户端用于配置用户设置的 Web 地址）包括主机名 - exo1.o365info.local

场景 2：需要访问托管在不同 Exchange\Active Directory 站点上的邮箱数据的内部邮件客户端。

以下方案描述了包含两个不同的 Exchange\Active Directory 站点的 Exchange 环境。

在我们的场景中，John（来自纽约站点的邮件客户端）需要获取有关 Alice 的忙/闲时间的信息，Alice 是物理上位于不同 Exchange\Active Directory 站点（洛杉矶站点）的邮件收件人。

第 1 步 - 内部邮件客户端提交忙/闲信息请求。

假设 John 已成功连接他的 Exchange CAS 服务器。该过程从 John 将忙/闲信息“提交请求”到他的 Exchange CAS 服务器（编号 1）的阶段开始。

第 2 步 - Exchange 验证目标收件人的位置。

John Exchange CAS 服务器 (exo1.o365info.local) 接受 John 的请求并启动一个进程，他将找到托管目标收件人邮箱的 Exchange 服务器。

“John Exchange CAS 服务器”不知道 Alice 的邮箱位于何处。
为了能够找到此信息，“New York Exchange CAS 服务器”会查询本地 Active Directory 以获取有关 Alice 邮箱位置的信息。来自 Active Directory 的答案包括主机名 - exo2.o365info.local（数字2）。

第 3 步 - 纽约交易所 CAS 服务器提交忙/闲信息请求。

exo1.o365info.local 创建到“Los Angles Exchange CAS 服务器 (exo2.o365info.local) 的通信通道并询问有关 Alice 空闲/忙碌时间信息（编号 3）的信息。

第 4 步 - Los Angles Exchange CAS 服务器发送所需信息。

洛杉矶交易所 CAS 服务器将必要的信息发送回纽约交易所 CAS 服务器（编号4）。

第 5 步 - John 的 Exchange CAS 服务器向 John 提供所需的信息。

John 的 Exchange CAS 服务器，填充 John 日历中的“结果”（数字5）。

场景3：实现Exchange CAS服务器的负载均衡和高可用性

第三种场景适合使用多个Exchange CAS服务器的中型和企业公司，为Exchange CAS服务器之间的负载平衡业务需求提供解决方案。

本节的目的不是提供有关用于在 Exchange CAS 服务器之间实现负载平衡的 Exchange 体系结构的详细说明，而只是在 Active Directory 中注册自动发现端点的上下文中提供此主题的简要介绍。

• 在基于 Exchange 2010 的环境中，大多数情况下需要使用 RPC 客户端访问阵列的概念来实现 Exchange CAS 服务器的负载平衡和高可用性解决方案；硬件负载平衡器。
• 在基于 Exchange 2013 的环境中，需要以更简单的方式实现 Exchange CAS 服务器的负载平衡和高可用性解决方案，而无需构建 RPC 客户端访问阵列。

当我们实现 Exchange CAS 服务器的负载平衡和高可用性时，要点是这些信息对 Exchange 客户端“隐藏”。

Exchange 客户端应该“看到”一个由逻辑名称表示的实体。

逻辑名称被“翻译”为两个或多个 Exchange CAS 服务器的主机名和 IP 地址。

注意：术语“Exchange CAS 数组”是一个广义术语，我们可以对此说很多，但此时，我们主要关心的是使用此选项时 Exchange FQDN 和 URL 地址是否正确。

为了演示使用负载平衡和 Exchange CAS 服务器高可用性的 Exchange 环境中的自动发现特性，我们将描述基于 Exchange 2010 的环境。

有多种方法可以实现 Exchange CAS 阵列的解决方案。
在我们的场景中，我们使用一个负载平衡器来“代表”两个 Exchange CAS 服务器。

从邮件客户端的角度来看，“只有一个 Exchange CAS 服务器”，并且邮件客户端不知道它们正在与负载平衡器而不是 Exchange CAS 服务器“对话”。

场景描述
组织决定向纽约 Exchange\Active Directory 站点添加额外的 Exchange CAS 服务器，以解决现有 Exchange CAS 服务器的负载和性能问题 - exo1.o365info.local

“新的 Exchange CAS 服务器”的主机名是 - exo2.o365info.local

为了能够优化 Exchange CAS 服务器的服务级别，将两个独立的 Exchange CAS 服务器配置为 Exchange CAS 阵列中的成员。

将分配给 Exchange CAS 数组的逻辑名称是 - cas.o365info.local

为了能够使用负载均衡器的附加组件实施 Exchange CAS 阵列配置，我们需要执行以下操作：

1. 从 Active Directory SCP 中删除有关 New York Exchange CAS 服务器的信息。

我们需要从 Active Directory SCP 中“删除\删除”有关现有两台 Exchange CAS 服务器“真实姓名”的信息（exo1.o365info.local 和 exo2.o365info.local）。此步骤的目的是防止 Exchange CAS 服务器客户端“了解”每个现有 Exchange CAS 服务器（编号1）的“真实姓名”。

2. 注册负载均衡器的“逻辑名称”。

Exchange CAS 阵列通过使用将“附加”到负载均衡器的“逻辑名称”“公开”给邮件客户端。
在我们的示例中，负载均衡器 FQDN 将是 - cas.o365info.local（数字2）。

3. 内部邮件客户端请求有关其 Exchange CAS 服务器的信息。

从今天开始，每次邮件客户端（自动发现客户端）向 Active Directory 查询现有 Exchange CAS 服务器的信息时，Active Directory“答案”将包含“Exchange CAS 服务器”的名称 - cas.o365info.local（数字3）。

4. 内部邮件客户端访问其 Exchange CAS 服务器

内部邮件客户端将尝试使用 FQDN - cas.o365info.local（编号4）连接“Exchange CAS 服务器”。

5. 负载平衡器将请求转发到 Exchange CAS 阵列成员。

负载平衡器 (cas.o365info.local) 将接受邮件客户端请求并将邮件客户端请求“转发”到“真实 Exchange CAS 服务器”之一。