谁是 Exchange 自动发现客户端？ |第 03 部分#36

在当前的文章系列中，术语“自动发现客户端”将被提及数十次甚至数百次。
明显的问题可能是 - 这些“自动发现客户端”是谁或是什么？

自动发现客户端/服务器模型与服务器到服务器模型

从技术上讲，每个 Exchange 客户端或另一个“知道”如何定位 Exchange CAS 服务器、如何请求自动发现信息以及如何处理自动发现信息的客户端都可以被视为 - 自动发现客户端。

如果我们想更具体一些，在基于 Exchange 的环境中，术语“自动发现客户端”涉及以下类型的 Exchange 客户端：

• Outlook 客户端 (RPC/HTTP/S)
• 移动邮件客户端（ActiveSync 客户端）
• 基于 Web 的客户端 (HTTP/HTTPS)
• 其他 Exchange 服务器

我们可以用来对不同类型的自动发现客户端进行分类的一种方法是使用“客户端到服务器”或“服务器到服务器”分类。

1.客户端到服务器

“标准”Exchange 自动发现客户端的示例可以是：
Outlook 客户端。

Outlook 客户端使用自动发现服务来执行以下操作：
定位允许其访问其邮箱的 Exchange CAS 服务器、创建新的 Outlook 邮件配置文件、获取有关不同 Exchange 服务的信息，例如 - 脱机通讯簿、空闲\忙碌时间等等。

2. 服务器到服务器模型

很少有人知道自动发现服务的角度是一种可以描述为“服务器到服务器”的关系。

在这种情况下，“客户端”不是标准客户端（例如 Outlook），而是需要来自另一台 Exchange 服务器的信息的 Exchange 服务器。

“客户端”（源 Exchange 服务器）查找或定位可为他提供所需信息的“目标 Exchange 服务器”的能力基于使用自动发现服务。

自动发现“服务器到服务器模型”的示例可以是

Office 365 环境下的邮件迁移 | Exchange 服务器作为自动发现客户端

在 Office 365 环境中，诸如直接转换迁移、阶段迁移或混合迁移等迁移是依靠 Exchange On-Premise 自动发现服务来实现的。

我们从 Office 365 管理中心创建的迁移批次将使用我们提供的用于定位 Exchange 本地服务器的用户名凭据中的域名后缀。

注意 - 稍后我们将更详细地回顾这种自动发现机制，其中“客户端”使用域名后缀的一部分来定位自动发现端点。

Office 365 混合环境 | Exchange 服务器作为自动发现客户端

术语“混合环境”是描述两个不同 Exchange 组织（Exchange Online 和 Exchange 本地服务器）之间的关系的术语，这两个组织可以作为一个实体运行并在它们之间共享不同类型的信息和服务。

在云基础设施 (Exchange Online) 和 Exchange 本地基础设施之间共享信息的能力，例如 - 可用性服务（空闲/忙碌时间），基于每个环境（云和本地）的自动发现基础设施。

当“云”中的用户需要查看本地用户的忙/闲时间时，Exchange Online 服务器将使用自动发现过程来定位 Exchange 本地服务器。

Exchange 邮件客户端有哪些？

在当前的文章系列中经常使用的另一个术语是“Exchange 客户端”。

Exchange 环境可以为多种类型的不同邮件客户端提供服务。
一种邮件客户端与另一种邮件客户端的主要区别在于客户端使用的协议。

尽管所有“邮件协议”都有相同的目的——使用户能够查看其邮箱的内容，但每个邮件协议的行为不同，使用其他“语言”并与 Exchange 基础结构进行不同的交互。

Exchange 服务器支持四种类型的邮件客户端。

• Outlook 邮件客户端 - Outlook 邮件客户端有时被描述为 MAPI 客户端，因为该客户端使用名为 - MAPI
  （邮件应用程序编程接口）的专用邮件协议。
  MAPI 协议不是传输协议，因此，Outlook 邮件客户端使用协议的“组合”。例如 - MAPI over RPC（远程过程调用）或其他类型的组合，例如使用使用以下组合的 Outlook Anywhere 设置时 - MAPI over RPC over HTTPS。Exchange 2013 将支持新的“组合”，其中 RPC协议将从等式中“删除”。
• Webmail 客户端 - 邮件 Web 客户端是使用 HTTP 或 HTTPS 协议访问用户邮箱的客户端。
• 移动邮件客户端 - 智能手机、平板电脑等移动客户端的访问协议是 ActiveSync 协议。
• Internet 邮件客户端 - 术语“内部邮件客户端”涉及使用 POP3 和 IMAP4 协议从用户邮箱检索邮件并使用 SMTP 协议发送邮件的邮件客户端。

在下图中，我们可以看到，Exchange CAS服务器，为各种邮件客户端提供服务，使用多种邮件协议，例如 - 使用RPC协议的Outlook邮件客户端，或者RPC/HTTPS（Outlook Anywhere）协议、使用 ActiveSync 协议和“基于 Web 的邮件客户端”（例如 OWA）的移动设备。

Exchange CAS 服务器“知道”如何使自己适应这些不同的协议，这些协议具有不同的章程、通信方法等。

“Exchange 自动发现”邮件客户端

对比。俗话说“人人生而平等”，交易所客户并非生而平等，每个客户都有特定的章程和要求。

关于我们最重要的主题——Exchange 自动发现基础设施，并非所有“Exchange 客户端”都需要或以相同的方式“使用”Exchange 自动发现。

例如，自动发现协议使 Exchange 客户端能够自动定位可用的 Exchange CAS 服务器，但某些 Exchange 客户端（例如 OWA 客户端）手动指定它们访问的 Exchange 服务器的名称，而不是使用“自动过程”来显示末尾是所需的 Exchange CAS 服务器名称。

最著名的 Exchange 自动发现客户端是 Outlook。 Outlook 客户端完全依赖于 Exchange 自动发现基础结构。

其他 Exchange 客户端，例如移动客户端 (ActiveSync) 和 OWA（Web 客户端）部分依赖于 Exchange 自动发现基础架构。

例如，移动客户端 (ActiveSync) 可以使用自动发现查询找到所需的 Exchange CAS 服务器，或者手动键入所需的 Exchange CAS 服务器名称。

Exchange 自动发现基础结构可用于其他目的，例如：提供创建新邮件配置文件所需的基本信息（相关，主要针对 Outlook 邮件客户端）、有关可用 Exchange Web 服务的信息以及有关 Exchange CAS 支持的身份验证协议的信息服务器等。

为了充分披露，我必须承认，我确信 Exchange 自动发现对于 Outlook 客户端来说是“强制的”，但对于其他 Exchange 客户端 - 移动 (ActiveSync) 客户端和 OWA（Web 客户端），则不太清楚此客户端如何与 Exchange 自动发现服务交互。

例如，Exchange 服务器提供的部分自动发现信息包括 Exchange Web 客户端（OWA 邮件客户端）的身份验证协议要求的特定部分，但 OWA 客户端如何以及是否使用此信息尚不清楚。

Exchange 自动发现服务表中不同 Exchange 客户端的依赖性

在下图中，我们可以看到不同 Exchange 客户端对“自动发现服务”的“使用级别”。

不同的Exchange邮件客户端以及自动定位Exchange CAS服务器的过程

默认情况下，Outlook 客户端不知道为其提供服务的 Exchange CAS 服务器的名称。 Outlook 客户端查找“其 Exchange CAS 服务器”的唯一方法是使用自动发现过程。

这些是此“规则”的一些例外情况，因为从技术上讲，我们可以手动或通过使用本地配置文件向 Outlook 客户端提供 Exchange CAS 服务器名称，但不建议使用此方法，此外，我们还会有许多其他配置设置除了 Exchange CAS 服务器的名称之外，还需要提供给 Outlook 客户端。

移动 (ActiveSync) 客户端将尝试使用自动发现过程来定位其 Exchange CAS 服务器，这是“推荐方式”。

在自动发现过程失败的情况下，或者在某些旧移动设备中，移动客户端（ActiveSync）不支持自动发现；我们可以手动提供面向公众的 Exchange CAS 服务器的名称，该服务器将接受移动 (ActiveSync) 客户端的通信请求。

对于 OWA 等 Web 邮件客户端，OWA 邮件客户端不使用自动发现协议来“定位”将“引导他”到其邮箱的“元素”，因为在使用 Web 邮件客户端时，基本假设是用户必须提前知道使他能够访问其邮箱的 Exchange 邮件服务器的名称。

获取有关可用 Exchange Web 服务的信息

“通知”Outlook 客户端有关 Exchange Web 服务可用性的唯一方法是通过自动发现过程，其中 Exchange CAS 服务器向 Outlook 客户端发送现有 Exchange Web 服务的 URL 地址。

关于“其他 Exchange 客户端”——移动 (ActiveSync) 客户端和 OWA（Web 客户端），目前还不清楚该客户端如何获取有关可用 Exchange Web 服务的信息。

据我所知，OWA这样的客户端不需要了解可用的Exchange Web服务，OWA客户端只需要申请信息，Exchange服务器负责定位所需的资源（Exchange Web服务）并获取 OWA 客户端所需的信息。

再说一遍，我不确定这个理论是否 100% 准确。

获取创建新邮件配置文件所需的信息。

Outlook 客户端必须配置一个“邮件配置文件”，该配置文件充当 Outlook 客户端和 Exchange CAS 服务器之间通信通道所需的所有通信设置的“逻辑容器”。

Outlook 邮件客户端获取邮件配置文件所需的配置设置的唯一可选方法是使用自动发现服务。

Exchange CAS 服务器将接受 Outlook 客户端自动发现信息请求，并根据 Exchange 客户端的特定字符（例如托管收件人邮箱的 Exchange 邮箱服务器、客户端的地理位置等）提供自定义答案。

其他

在“其他”部分中，我们可以涉及可作为自动发现过程的一部分提供给 Exchange 客户端的任何配置设置或服务。

例如，如上所述，Exchange 提供的部分自动发现信息包括与 OWA 邮件客户端相关的特定部分。

因为我不确定OWA邮件客户端如何使用这些信息，所以我将在其他部分对这些信息进行分类。

自动发现一次性程序还是持续的沟通渠道？

在上一节中，我们必须回顾一下 Exchange 客户端及其 Exchange CAS 服务器之间存在的关系的性质，以及自动发现基础结构如何帮助客户端找到其“目标 Exchange CAS 服务器”并帮助 Exchange CAS 服务器为其客户提供必要的信息。

现在可能出现的问题是——自动发现是否可以被视为“一次性事件”？或者自动发现是 Exchange CAS 服务器与其客户端之间的“持续”通信通道？

这些问题的答案是自动发现过程不是静态的！

自动发现过程不是“一次性过程”。
我们可以将 Exchange 客户端与其 Exchange CAS 服务器之间的自动发现关系场景分为两大类：

1. 首次自动发现流程
2. 正在进行的自动发现过程

客户端和服务器之间的自动发现过程从自动发现客户端和自动发现端点之间的“第一次握手”开始。

在这个“初步过程”中，自动发现端点将信息提供给他的客户端，但这并不意味着从今天开始，自动发现客户端将永远使用这些信息！

对于自动发现客户端和自动发现端点之间存在的自动发现关系，更合适的术语是“对话”。

例如，Exchange 客户端（例如 Outlook）每小时访问自动发现端点，以检查与 Exchange 基础结构相关的“新信息”或更新。

另一个例子是，每次“重新启动”Outlook 等邮件客户端时，客户端都会尝试访问自动发现端点，寻找新信息或验证是否拥有所需信息。