旧版 Exchange 环境与现代 Exchange 环境第 02 部分#36

在本文中，我们将回顾自动发现如何满足现代 Exchange 环境的需求。

为了能够了解 Exchange 自动发现基础结构的巨大重要性，我们将了解一下没有自动发现服务的旧版或以前版本的 Exchange 体系结构。

为了能够理解 Exchange 现代环境的章程是什么，我们需要退后几步，简要浏览一下“Exchange 历史”。

问题1：我为什么要费心去了解 Exchange 基础设施的历史？

A1：“忽视历史的一代人没有过去，也没有未来”。 [拉扎勒斯·朗，来自罗伯特·海因莱因的作品]

简单来说，为了能够真正理解 Exchange 自动发现基础架构，我们需要弄清楚现代 Exchange 环境的“业务需求”是什么，这也是 Exchange 自动发现基础架构诞生的原因。

旧的交换环境

让我们从技术术语的定义开始——“旧 Exchange 环境”和“现代 Exchange 环境”。

Exchange 服务器有多种形式。在下图中，我们可以看到 Exchange Server 版本的列表以及旧 Exchange 环境的分类，以及我们所描述的“Exchange 现代架构”。

1.旧的Exchange环境

我们可以将其视为“旧 Exchange 服务器架构”的 Exchange 服务器版本是以下 Exchange Server 版本：

• 交易所5.5
• 交换2000
• 交换2003

注意 - 我在 Exchange 5.5 和 Exchange 2000 之间划了一条界线，因为在当时，Exchange 2000 的诞生是一场革命。 Exchange 2000 体系结构已完全改变，并经过定制以在现代 Active Directory 环境中运行。

2.现代化的交流环境

事实上，并不存在“现代Exchange环境”这样的正式术语。
我用这个术语来描述新一代的Exchange服务器，从Exchange 2007开始，到Exchange 2013服务器结束。

在下图中，我们可以看到“旧版 Exchange 环境”和“现代 Exchange 服务器环境”之间的主要差异总结。 ”

现代 Exchange 环境与旧 Exchange 环境的特点

在下一节中，我们将回顾现代 Exchange 架构与“旧 Exchange 架构”的主要章程。

查找 Exchange CAS 服务器

为了能够理解自动发现过程的一个方面，让我们看一下下图，它代表了标准 Exchange 客户端（例如 Outlook）的“想法”-

现代 Exchange 环境最有趣的特征之一是 Exchange 客户端永远不需要提前知道：

1. 托管其邮箱的 Exchange 服务器是谁（名称是什么）

Exchange 客户端不需要知道托管其邮箱的 Exchange 服务器的名称，因为他无法直接寻址到托管其邮箱的 Exchange 邮箱服务器。

Exchange 客户端需要找到他的 Exchange CAS 服务器； Exchange CAS服务器将接受Exchange客户端请求并找到“持有”Exchange客户端邮箱的Exchange邮箱服务器。每个 Exchange 客户端应用程序都将由 Exchange CAS 服务器代理到 Exchange 邮箱服务器，反之亦然。

换句话说，Exchange CAS 服务器需要知道：托管其邮箱而不是 Exchange 客户端本身的 Exchange 服务器的名称是什么。

2. 他需要寻址的 Exchange CAS 服务器是谁（名称是什么）。

“查找所需的Exchange CAS服务器”的任务是由自动发现进程实现的。

自动发现机制或协议使 Exchange 客户端能够定位并查找其 Exchange CAS 服务器。
同样，默认情况下，Exchange 客户端不知道 Exchange CAS 服务器的名称或可用的 Exchange CAS 服务器。
相反，每次 Exchange 客户端需要“定位”Exchange CAS 服务器时，Exchange 客户端都会使用自动发现机制来查找所需的 Exchange CAS 服务器。

现代 Exchange 环境与旧 Exchange 架构的主要特征

1.“Exchange服务器角色”的概念。 ”

较旧的 Exchange 环境

“旧的Exchange架构”，没有使用“Exchange服务器角色”的概念。 Exchange 2003 体系结构包括一些“服务器角色”定义，描述为前端与后端，但 Exchange 体系结构的基本思想并不是基于角色分离的概念。

现代交换环境

Exchange 服务器角色的想法在 Exchange 2007 版本中得到了体现，从那时起，这个概念就一直是现代 Exchange 体系结构的主要章程之一。

使用“服务器角色”可以实现职责分离。每个 Exchange 服务器角色代表不同的“职责”或定义为“角色”的一组 Exchange 服务器任务。

Exchange 2007、2010 体系结构与 Exchange 2013 体系结构

如果我们想要准确的话，“Exchange 服务器角色”的概念在 Exchange 2013 架构与 Exchange 2007、2010 架构中正在经历重大变化。

Exchange 2007、2010 体系结构基于五个 Exchange 服务器角色。

Exchange 2013 体系结构基于两个 Exchange 服务器角色。

在我们的 Exchange 自动发现基础架构环境中，最重要的 Exchange 服务器角色是 - Exchange CAS（客户端访问服务器）角色。
在 Exchange 现代环境中，担任“CAS 角色”的 Exchange 服务器是所有其他 Exchange 基础设施的“门”。

注意：所有其他 Exchange 服务器角色（例如 Exchange 邮箱角色和 Exchange 集线器传输角色）在 Exchange 环境中也是“重要角色”。由于 Exchange 客户端不直接与这些角色交互，因此我们不会涉及 Exchange 体系结构的这些“其他部分”。

逻辑和物理分离或 Exchange 角色
Exchange 角色概念的实现可以通过使用两个（或多个）Exchange 服务器或使用“拥有”两个角色的单个 Exchange 服务器来实现，或者同时职位（CAS服务器角色+邮箱角色）。

实现角色分配的方式并不重要，因为 Exchange 客户端使用 Exchange CAS 服务器所需的对邮箱的“间接访问”概念保持不变。

Exchange 角色分离的概念。
Exchange 2007、2010 体系结构中的建议或最佳实践是 - 实施一种配置，其中每个 Exchange 服务器角色都由专用 Exchange 服务器代表。

在 Exchange 2013 体系结构中，服务器角色的概念仍然是 Exchange 服务器体系结构的基础。

主要区别在于，在 Exchange 2013 体系结构中，只有两种 Exchange 服务器角色，而 Exchange 2007、2010 体系结构定义了五种不同的服务器角色。此外，Exchange 2013 体系结构中的最佳实践不是对每个服务器角色使用“专用 Exchange 服务器”的概念，而是实施一种配置，其中每个 Exchange 2013 服务器将担任两个最重要的角色。

从技术上讲，在 Exchange 2007、2010 环境中，单个 Exchange 服务器可以“容纳”所有这五个角色，或者 Exchange 角色可以“分布”在许多 Exchange 服务器之间。

例如，一台 Exchange 服务器是否承担 CAS、邮箱和集线器传输这三个角色并不重要。虽然这三个角色“托管”在一台物理服务器上，但问题在于角色之间的“逻辑分离”。

例如，Exchange 客户端需要与“Exchange CAS 层”通信才能访问其邮箱内容。

2. Exchange客户端和“他的邮箱”之间没有直接连接。 ”

Exchange 现代环境的一个主要附加功能可以描述为 - Exchange 邮件客户端和 Exchange 邮箱服务器之间没有直接连接。

在现代 Exchange 环境中，Exchange 客户端连接到其邮箱的唯一方法是通过 Exchange CAS 服务器。

Exchange 客户端必须找到可用的 Exchange CAS 服务器。只有成功完成相互身份验证过程后，Exchange CAS 服务器才会（代表 Exchange 客户端）找到托管用户邮箱的 Exchange 邮箱服务器。 CAS 服务器将 Exchange 客户端请求代理到邮箱服务器，并将 Exchange 邮箱服务器的信息发送回 Exchange 客户端。

注意：Exchange 客户端使用自动发现机制“定位”Exchange CAS 服务器。

如前所述，在现代 Exchange 环境中（自 Exchange 2007 起），Exchange 邮件客户端无法直接连接到其邮箱。

Exchange 客户端访问其邮箱的唯一方法是通过 Exchange 服务器，该服务器担任 Exchange CAS（客户端访问服务器）角色。

Exchange CAS 服务器是 Exchange 客户端和托管用户邮箱的 Exchange 服务器（具有邮箱角色的 Exchange 服务器）之间“站在中间”和“分隔”的因素或元素。

旧版 Exchange 环境 - 客户端可以直接访问其邮箱。

在过去的好日子里，Exchange 客户端和“他的邮箱”之间的关系是通过使用 Exchange 客户端和保存或托管用户邮箱的 Exchange 服务器之间的直接连接来实现的。

例如，为了能够完成创建新的 Outlook 邮件配置文件的任务，强制要求是：需要知道托管用户邮箱的 Exchange 服务器的确切名称。

在“过去”，组织 IT 部门应该保存一份详细的表格，其中包含每个组织用户的信息及其 Exchange 服务器的名称。

负责创建“新 Outlook 邮件配置文件”的人应该必须使用该表，这样他就能够将 Outlook 客户端“连接”到“正确的 Exchange 服务器”。

3. 从基于公用文件夹的服务迁移到基于Web 的服务。

“客户端-服务器服务器关系”的概念，即服务器为其客户端提供不同的服务，一直存在于 Exchange 环境中。
Exchange 环境的主要特征之一是客户端提供的服务的丰富性。 Exchange服务器提供给他的客户端。

在Exchange“旧环境”中，诸如忙/闲时间之类的Exchange服务基于Exchange独特的系统公用文件夹，该文件夹充当数据\信息的容器。

Exchange 客户端（例如 Outlook）通过 RPC 协议访问存储在系统公用文件夹中的信息。

所描述的机制遇到了与该过程相关的许多问题，其中需要将信息保存在公用文件夹中并复制到其他 Exchange 公用文件夹存储和其他 Exchange 站点。

交换网络服务 |现代交流环境

自Exchange 2007以来最大的变化之一就是洞察“世界通用语言协议”——HTTP协议。

利用Exchange公用文件夹存储系统数据，提供被“新邻居女孩”抛弃的Exchange服务、基于Web的服务的方法。

将基于公用文件夹的 Exchange 服务替换为基于 Web 的新方法的方法，称为 EWS（Exchange Web 服务）。

每次 Exchange 客户端（例如 Outlook）需要其他 Exchange 收件人的忙/闲时间等信息时，Outlook 客户端都需要使用 HTTP（或 HTTPS）协议来寻址拥有 Exchange CAS 角色的 Exchange 服务器，并且， Exchange CAS 服务器负责“获取”其 Exchange 客户端所需的信息。

Exchange 2007、2010 架构与 Exchange 2013 架构对比

Exchange 2007、2010 和 Exchange 2013 体系结构之间的共同点是 Exchange 客户端必须对拥有 Exchange CAS 角色的 Exchange 服务器进行寻址，才能请求特定的 Exchange Web 服务。

Exchange 2007、2010 体系结构与 Exchange 2013 体系结构之间的主要区别在于，在 Exchange 2007、2010 结构中，Exchange CAS 服务器负责“持有”或提供 Exchange Web 服务的基础结构，同时提供服务作为需要 Exchange Web 服务的 Exchange 客户端的焦点。

在 Exchange 2013 环境中，Exchange 2013 CAS 仍然充当 Exchange 客户端请求 Exchange Web 服务的“焦点”，但 Exchange 2013 CAS 本身并不是生成或“生成”Exchange Web 服务的元素。

相反，负责充当 Exchange Web 服务基础结构的元素是 Exchange 2013 邮箱服务器。

只是关于 Exchange 公用文件夹概念的一个小声明

当 Exchange 2007 服务器首次发布时，微软的正式声明是“Exchange 公用文件夹已死”或者不再需要，因为 Exchange 服务已经从公用文件夹和 RPC 协议的概念“转变”为 -网页服务。

值得一提的是，在我看来，当时宣布“Exchange 公用文件夹消亡”有点仓促。

新的 Exchange 基于 Web 的服务取代了对 Exchange 系统公用文件夹的笨拙和低效实施的需要，但被遗忘的部分是许多组织使用“标准公用文件夹基础结构”（而不是特定的系统公用文件夹）作为共享文件夹Exchange 用户之间的存储严重依赖于 Exchange 公用文件夹。

交易所网络服务

Exchange Web 服务的基础结构是 IIS 服务器。

需要特定 Exchange Web 服务的 Exchange 客户端使用 URL 地址来发送 Exchange CAS 服务器，该服务器将“帮助”Exchange 客户端获取特定的 Exchange Web 服务。

URL 地址包括 Exchange 客户端地址所在的 Exchange CAS 服务器的“名称”(FQDN) + Exchange 客户端请求的特定 Exchange Web 服务的路径（名称）。

在下图中，我们可以通过一个示例来验证 Exchange CAS 服务器向其客户端提供的 Web 服务的真实性，例如脱机通讯簿、可用性服务、自动回复（不在办公室）等等。

注意：Exchange CAS 服务器可以自己提供特定的 Web 服务，将 Exchange 客户端请求代理到其他 Exchange CAS 服务器，或者向 Exchange 客户端发送包含其他 Exchange CAS 信息的“重定向响应”服务器。

Exchange Web 服务和自动发现

我们将在当前的文章系列中多次详细回顾 Exchange Web 服务和 Exchange 自动发现服务之间的连接，但仅进行简要回顾：

Exchange 客户端“大体上知道”存在 Exchange Web 服务，但从技术上讲，他不知道“为了获取特定的 Exchange Web 服务，他需要寻址的 Exchange CAS 服务器是谁”？

负责“通知”Exchange 客户端有关现有 Exchange Web 服务的“元素”是 Exchange CAS 服务器，有关现有 Exchange Web 服务的信息作为自动发现过程的一部分“传递”到 Exchange 客户端（例如 Outlook）。

Exchange CAS 服务器作为信息源

Exchange 客户端与其 Exchange CAS 服务器之间的关系很复杂，并且由多个不同的部分组成。

Exchange 客户端通过多种方式查看 Exchange CAS 服务器。 Exchange 客户端（例如 Outlook）查看 Exchange CAS 服务器的一种方式是：“信息源”。

Exchange CAS 服务器向其客户端提供的信息包括不同部分的信息，其中之一是与有关可用 Exchange Web 服务的信息相关的部分。

Exchange 客户端从通过自动发现进程实现的 Exchange CAS 服务器请求信息的通信通道。

Exchange CAS 服务器“应答”（自动发现响应）包括两种主要类型的信息：

1. 有关可用 Exchange Web 服务的信息
2. Exchange Outlook 邮件客户端创建新的 Outlook 邮件配置文件所需的信息。

第 1 部分：自动发现响应 |提供有关 Exchange Web 服务的信息。

客户端使用 URL 地址寻址或访问的 Exchange Web 服务（与任何其他 Web 服务一样）。

Exchange CAS 服务器向其客户端提供的自动发现响应，包括有关所有可用的现有 Exchange Web 服务的信息。

使用 XML 标记提供的有关 Exchange Web 服务的信息，其中包括特定 Exchange Web 服务的 URL 地址。

XML 标签“告知”Exchange 客户端特定的 Exchange Web 服务是什么。在下图中，我们可以看到自动发现服务器响应中的“行”示例。

XML 标签是 - ASUrl，表示可用性服务 URL。
在 XML 标签内，我们可以看到可用性服务的 URL 地址。

Exchange 客户端依赖于此信息（来自 Exchange CAS 服务器的自动发现响应），因此它们将能够连接提供特定 Exchange Web 服务的所需主机。

第 2 部分：自动发现响应 |提供有关新 Outlook 邮件配置文件所需配置设置的信息。

Exchange CAS 服务器自动发现响应的主要部分与 Exchange 客户端（特别是 Outlook）所需的信息相关，该信息被视为创建新 Outlook 邮件配置文件的任务所需的强制信息（配置设置）。

Outlook 邮件配置文件和所需的配置设置

Outlook 客户端，使用 Outlook 邮件配置文件连接到 Exchange 服务器。

我们可以将 Outlook 邮件配置文件作为创建与 Exchange CAS 服务器的通信通道所需的配置设置的“容器”。

Exchange旧环境：Outlook邮件配置文件|手动设置且需要用户熟悉具体技术细节

在“美好的过去”，创建新的 Outlook 邮件配置文件等主要任务是通过手动配置来实现的。
在内部\专用网络中配置 Outlook 邮件配置文件的任务可以被认为是一个简单的任务任务，因为所有用户都需要知道其 Exchange 邮箱服务器的名称，并且该过程的所有其余部分将使用用户域缓存凭据自动执行。

对比。在内部网络中配置新的 Outlook 邮件配置文件的任务 为需要使用 Outlook Anywhere 设置配置 Outlook 的外部用户创建新的 Outlook 邮件配置文件的任务（当时，外部 Outlook 客户端被描述为 RPC） \HTTPS），并不是一个简单的任务。

原因是，创建新 Outlook 邮件配置文件的用户必须提前准备一份技术详细信息列表，其中包括以下详细信息：充当 RPC 代理的 Exchange 服务器的名称、内部名称（如果Exchange 邮箱服务器、身份验证协议等等。

不用说，除了需要用户了解许多技术细节的不便之外，很多时候，由于人为错误、错误信息等，该过程无法完成。

注意：在旧的 Exchange 环境中，有一些选项可以实现“自动创建 Outlook 邮件配置文件”的任务，但是，“自动化”的实现基于使用 ORK（Office Resource Kit）和 PRF 文件，将脚本分发到每个域用户的桌面等等。

在现代 Exchange 环境中创建新的 Outlook 邮件配置文件

与这个复杂的过程相比，在现代 Exchange 环境中创建新邮件配置文件的任务对于 Exchange 用户来说只是小菜一碟。

例如，在Active Directory环境中，用户唯一需要“激发”的操作就是双击Outlook图标。
“双击操作”，将激活一系列操作，其中Outlook将自动检测并连接本地 Exchange CAS 服务器，实施相互身份验证过程，并从 Exchange CAS 服务器获取编译新 Outlook 邮件配置文件任务所需的所有设置。

在非 Active Directory 中创建新的 Outlook 邮件配置文件的任务也非常简单，从客户端的角度来看，唯一的区别是除了电子邮件地址之外还需要提供用户凭据。

注意：从技术上讲，可以手动配置 Exchange 客户端（例如 Outlook）以连接其 Exchange CAS 服务器。

尽管理论上可以选择实施“手动方法”，而不使用自动发现来“查找”或定位 Exchange CAS 服务器，但在大多数情况下不支持此方法。

经验法则是：如果我们必须使用手动设置选项，大多数情况下我们的 Exchange 基础结构配置不正确，或者 Exchange 客户端存在许多其他问题，导致无法使用自动发现服务。

总结和回顾

正如我们在当前文章中所示，在现代 Exchange 环境中，Exchange 客户端完全依赖于 Exchange CAS 服务器。

Exchange CAS 服务器的作用是：将 Exchange 客户端“连接”到他们的邮箱，为他们提供 Exchange Web 服务（或在 Exchange 2013 中向 Exchange 邮箱服务器提供 Exchange 客户端请求），并为其客户端（特别是 Outlook 客户端）提供有关以下信息的信息：创建新邮件配置文件所需的配置设置以及有关现有 Exchange Web 服务的信息。

1. 将 Exchange 客户端“连接”到他们的邮箱，为他们提供 Exchange Web 服务（或在 Exchange 2013 中向 Exchange 邮箱服务器提供 Exchange 客户端请求），并向他的客户端（特别是 Outlook 客户端）提供有关创建新邮件所需的配置设置的信息有关现有 Exchange Web 服务的配置文件和信息。
2. 向他们提供 Exchange Web 服务（或在 Exchange 2013 中向 Exchange 邮箱服务器提供 Exchange 客户端请求），并向他的客户端（特别是 Outlook 客户端）提供有关创建新邮件配置文件所需的配置设置的信息以及有关现有 Exchange Web 服务的信息。
3. 向他的客户端（特别是 Outlook 客户端）提供有关创建新邮件配置文件所需的配置设置的信息以及有关现有 Exchange Web 服务的信息。

客户端查找所需的 Exchange CAS 服务器的过程以及 Exchange CAS 服务器向 Exchange 客户端提供所需信息的步骤是通过自动发现过程实现的。