用于定位“信息源”的自动发现算法 | 第 05#36 部分

自动发现客户端用于定位其“信息源”（Exchange CAS 服务器）的自动发现算法基于非常复杂的算法，旨在克服和绕过许多类型的“障碍”并在不同的网络环境。

在本文中，我们将回顾 Outlook 客户端用于定位自动发现端点（Exchange CAS 服务器）的自动发现算法。

信息来源

Exchange 客户端（例如 Outlook）所需的“信息”是：创建 Outlook 邮件配置文件所需的配置设置以及有关可用 Exchange Web 服务的信息。

主要问题可能是 - 谁是可以向 Exchange 客户端提供此类信息的来源？

从技术上讲，Exchange 客户端（例如 Outlook）有两种方法来获取所需信息：

• 本地配置文件
• 自动发现端点

1.本地配置文件

Exchange 客户端可以用来“获取所需信息”的一种方法是使用本地文件。
本地配置文件是一个预先配置的文件，应创建该文件并将其放置在用户桌面的特定路径中。

使用本地配置文件的方法，就是“去掉”了自动发现的本质特征之一——自动化。
使用本地文件的方法，可以说是“静态方法”，因为本地文件中的信息，如果 Exchange 环境发生变化，则不会自动更新。此外，Outlook 邮件客户端无需“发现”为其提供信息的元素（Exchange CAS 服务器）。

不推荐使用本地文件的方法，最重要的是，Office 365 和 Exchange Online 环境不支持使用本地文件的方法。

因此，我们将不会继续审查此选项或字符或此方法。

注意：在 Exchange 2013 环境中使用本地文件的方法变得多余且无用，因为在 Exchange 2013 环境中，我们不使用特定 Exchange CAS 服务器的名称。相反，Outlook 客户端会获取由可用 Exchange CAS 服务器之一动态创建的会话 ID。

2. 客户端\服务器方式

自动发现方法可以描述为“客户端\服务器方法”，它基于一种机制，其中客户端定位+寻址特定服务器（自动发现端点），该服务器将被描述为“信息源”并且能够向客户所需的信息。

自动发现客户端通过以下方式实现自动发现客户端\服务器方法：

• 定位信息源
  从技术上讲，“信息源”不一定是 Exchange CAS 服务器，但大多数时候，自动发现信息将由 Exchange CAS 服务器提供。
  自动发现客户端有两种定位“信息源”的方法 - 一种方法是通过查询 Active Directory 实现的，另一种方法是通过查询 DNS 来查找自动发现主机名提供程序（在非 Active Directory 环境中执行）。
• 发送信息请求
  鉴于自动发现客户端设法找到并连接自动发现端点，自动发现会发送信息请求。

3. 服务器的响应

来自服务器的“答案”或自动发现响应不一定是包含配置设置和有关可用 Exchange 服务的 URL 地址的信息的“最终答案”。

在某些情况下，服务器响应可以包括到其他或附加信息源的重定向。

在这种情况下，自动发现客户端会重新启动整个过程。

当自动发现过程结束时，自动发现客户端将使用配置信息来：

• 创建新的 Outlook 邮件配置文件
• 保存有关 Exchange Web 服务 URL 地址的信息以供以后使用

Exchange客户端如何定位Exchange CAS服务器？

如前所述，术语“自动发现”有多种含义（客户端、服务器端等）。

从客户端的角度来看，自动发现可以描述为对一个简单问题的回答：谁是我的 Exchange CAS 服务器？

问题的答案 - 谁是我的 Exchange CAS 服务器？或者，如何找到所需的Exchange CAS服务器，取决于网络环境和用户桌面上的配置设置。

方法 1：在 Active Directory 环境中自动发现

自动发现方法被描述为“在 Active Directory 环境中自动发现”，只能在 Active Directory 环境中实现！ （是的，我知道这完全是一句愚蠢的话）。

如前所述，自动发现客户端不知道 Exchange CAS 服务器的名称、有多少个可用的 Exchange CAS 服务器等。

如果用户桌面是域成员，并且 Active Directory 可用且可访问，则自动发现客户端将向 Active Directory 请求有关现有 Exchange CAS 服务器名称的信息。

自动发现客户端使用 LDAP 协议将查询提交到本地 Active Directory。

如果组织包含 Exchange 基础结构以及在 Active Directory（本地 Active Directory）的 SCP 分区注册的 Exchange CAS 服务器，请通过向自动发现客户端提供可用 Exchange CAS 服务器列表来回复自动发现客户端查询。

如果我们想要更准确，Active Directory 响应包括本地 Exchange CAS 服务器自动发现 Web 服务的 URL 地址。

自动发现客户端知道如何从 URL 地址“提取”Exchange CAS 服务器名称 (FQDN) 以及如何寻址所需的主机。

在下图中，我们可以看到 Active Directory 环境中自动发现过程的简化描述。

自动发现连接本地 Active Directory 并获取可用 Exchange CAS 服务器的列表。

自动发现客户端使用列表中显示的名称之一尝试连接 Exchange CAS 服务器并完成自动发现过程。

在我们的场景中，自动发现过程已成功完成，并且 Exchange CAS 服务器向客户端发送自动发现响应，其中包括客户端所需的信息（Outlook 邮件配置文件所需的配置设置以及有关现有 Exchange Web 服务的信息）。

方法 2：在非 Active Directory 环境中使用自动发现。

如果 Exchange 客户端不是域成员，或者客户端无法访问本地 Active Directory，则 Exchange 客户端将使用不同的自动发现方法。
在这种情况下，自动发现客户端将需要使用不同的方法因为他无法使用 Active Directory 作为“指针”或有关现有 Exchange CAS 服务器的信息源。

在非 Active Directory 环境中，自动发现客户端将需要“猜测”Exchange CAS 服务器（自动发现端点）的名称。

由于客户端（例如 Outlook）并不真正知道 Exchange CAS 服务器的名称是什么，因此 Outlook 使用了一种被描述为“智能猜测”的方法。

Outlook 根据用户在使用 Outlook 向导创建新 Outlook 邮件配置文件时提供的电子邮件地址使用的“智能猜测”过程。

创建新的 Outlook 邮件配置文件的第一步是我们需要提供用户电子邮件地址。

Outlook 将采用收件人电子邮件地址的“正确部分”，即包含 SMTP 域名的部分，并使用该名称作为自动发现端点的主机名。

例如，如果收件人电子邮件地址是 - [email protected]

Outlook 将得出结论，自动发现端点的主机名是 - o365info.com

如果自动发现客户端无法使用此域名作为主机名（在我们的场景中为 o365info.com）找到或连接自动发现端点（Exchange CAS 服务器），自动发现客户端将尝试查找“下一个自动发现端点主机名” ，使用以下命名约定 - 自动发现 + SMTP 域名。

在我们的场景中，Outlook 将查找名为 - autodiscover.o365info.com 的自动发现端点

在下图中，我们可以看到自动发现客户端用于“生成”或“猜测”自动发现端点名称的示例。

可能的自动发现方法的逻辑

在下一节中，我们将回顾自动发现客户端使用的自动发现算法的“逻辑”。

自动发现之旅是对信息的探索。

“信息”可以是配置设置和有关 Exchange Web 服务 URL 的信息，或者“信息”可以是指向另一个可用信息源的“线索”或“指针”。

“信息来源” |自动发现服务端点。

在下一节中，我们将多次提到术语“信息源”或术语：“自动发现端点”。

创建该术语是为了描述自动发现客户端搜索和寻址以获取所需信息的“实体”或节点。

从技术上讲，自动发现服务终结点不一定需要是 Exchange CAS 服务器。

例如，在 Office 365 和 Exchange Online 环境中，自动发现客户端永远不会立即到达“他的 Exchange CAS 服务器”。
相反，自动发现客户端需要“遍历”许多节点，直到到达目的地。

这就是使用另一个术语 - 潜在自动发现端点的原因。
我们使用这个词 - “潜在”，因为自动发现客户端永远无法完全确定他尝试连接的“目标主机”正在中继自动发现端点，或者“目标主机”是否可用等等。

自动发现客户端将以他的方式“遇到”的一些“主机”只是一个“逻辑路由器”，它将把他指向其他主机等等。

在下一节中，我们将回顾几个可能的自动发现方案的“结构”或逻辑，其中自动发现客户端尝试查找“他的”Exchange CAS 服务器。

方式一：直接获取信息（信息文件）

自动发现客户端的可用选项之一是通过访问本地配置文件来查找所需的信息。

配置文件格式基于 XML 格式。
为了使 Outlook 等邮件客户端能够“查找”信息文件，我们需要这样做。

• 创建信息文件。
• 将信息文件本地保存在用户的桌面硬盘上。
• 创建并配置一个注册密钥，它将“引导” Outlook 客户端到信息文件（通过提供文件名和文件路径）。

使用本地配置文件的方法，仅在极少数情况下使用。
不推荐这种方法，因为它基于“静态信息”，需要对用户的每个桌面进行配置设置。
该方法使用 Office 365 和 Exchange Online 环境中不支持的本地配置文件。

方法二：使用“信息提供者”的主机名

我所描述的“使用信息提供者的主机名”的方法是在 Outlook 等邮件客户端对 Exchange CAS 服务器的名称有“初步了解”的情况下实现的。

如果较早实施了“标准自动发现流程”，并且 Outlook 客户端设法获取 Exchange CAS 服务器的名称、连接 Exchange CAS 服务器并验证其身份，则此场景成为可能。

在两种可能的情况下，Outlook 使用其名称来寻址 Exchange CAS 服务器，而不是启动标准自动发现进程：

场景 1：现有 Outlook 邮件配置文件

如果我们已经配置了 Outlook 邮件配置文件，只要 Outlook 客户端处于活动状态，Outlook 就会尝试每小时
（每小时）访问 Exchange CAS 服务器，以与 Exchange 服务器进行检查有关 Exchange CAS 服务器先前提供的信息的可用更新或更改。

在这种情况下，Outlook 将使用缓存中保存的 Exchange CAS 服务器名称或会话 ID（在基于 Exchange 2013 架构的 Exchange 环境的场景中）。

这种方法被 Outlook 等客户端用于“刷新目的”。
Outlook 客户端找到所需的服务器并获取所需信息后，Outlook 会保存服务器名称（Exchange CAS 服务器名称），并定期连接 Exchange 服务器询问信息的现有更改或更新。

场景 2：Outlook 2013 客户端和 Outlook 配置文件中的缓存 URL 功能

Outlook 配置文件中的“缓存 URL”选项仅在使用 Outlook 2013 版本时可用。

有趣的是，几乎没有关于 Outlook 2013 这个功能的信息。
据我所知，“Outlook 配置文件中的缓存 URL”之父使 Outlook 客户端能够“重用”一个名称Exchange CAS 服务器，以防自动发现进程无法找到所需的 Exchange 服务器名称。

“缓存 URL”选项仅在过去 Outlook 成功完成自动发现过程的情况下才能实现。含义是 Outlook 将 Exchange CAS 服务器的名称或会话 ID 保存在注册表中。

如果 Outlook 客户端无法找到所需的 Exchange CAS 服务器，Outlook 2013 客户端将从注册表中“获取”Exchange CAS 服务器的名称。

注意：我们可以通过创建一个名为 ExcludeLastKnownGoodURL 的新注册表项来禁用此选项

方法三：寻址可信主机，获取“信息提供者”列表

这种自动发现方法在 Active Directory 环境中实现。
此自动发现过程的概念是解决“可信元素”，它将引导我们到达所需的目的地，与我们访问一个伟大的场景的场景非常相似。购物中心，里面有很多商店。

我们寻找一家著名的牛仔裤店，但是，我们不知道如何到达那里。
在这种情况下，我们可以使用目录或向邮件信息办公室询问该牛仔裤店的方向。

回到我们的 Exchange 环境，这种方法由 Outlook 等客户端使用，当客户端工作站是域的一部分并且客户端可以连接本地 Active Directory 时。

为了能够获取可用 Exchange CAS 服务器的主机名，邮件客户端会寻址包含有关可用 Exchange CAS 服务器信息的“元素”。

该“元素”是本地本地 Active Directory。

邮件客户端向 Active Directory 提交 LDAP 查询并请求有关可用 Exchange CAS 服务器名称的信息。

方法四：生成“信息提供者”的NAME

在非 Active Directory 环境中，Exchange 邮件客户端（例如 Outlook）没有任何“元素”可以为其提供有关可用 Exchange CAS 服务器（自动发现端点）的信息。

因此，Exchange 客户端将需要使用另一种方法来查找可用的 Exchange CAS 服务器。

Exchange 客户端使用的自动发现过程基于一个有趣的概念。
Exchange 客户端在非 Active Directory 环境中使用的自动发现过程基于客户端“猜测”Exchange CAS 可选名称的方法服务器（自动发现端点）。

当用户提供其电子邮件地址时（例如，创建新的 Outlook 邮件配置文件时），Outlook“获取”SMTP 域名并创建 DNS 查询以查找 SMTP 域名的 IP 地址。

换句话说，在用户提供其电子邮件地址之前，自动发现客户端并不知道“信息提供者”（Exchange 服务器）的名称。

方法5：重定向或指向另一个“信息提供者”

如前所述，自动发现过程并不总是作为“一对一”过程实现。在企业环境中，或者在Office 365和Exchange Online环境中，Exchange CAS服务器的结构相当复杂。

在这些环境中，自动发现客户端将需要在几个节点之间“跳转”，直到到达目的地。

例如，在基于 Office 365 的环境中，大多数“自动发现之旅”都建立在自动发现客户端定位并连接到自动发现端点的概念上，但该主机的“答案”将不包含所需的配置设置，而是包含，附加潜在自动发现端点的名称（FQDN 或 URL）。