Exchange Web 服务在Exchange 2013 中共存|第 2/2 部分 | 7#23

在上一篇文章中 - Exchange 2013 共存环境中的 Exchange Web 服务 |第 1/2 部分，我们已经回顾了 Exchange 2013 共存环境中 Exchange Web 服务的概念和逻辑，但在本文中，我想进一步了解在旧版 Exchange Web 中实现的客户端协议连接流程服务客户端：Exchange 2007 客户端和Exchange 2010 客户端。

Exchange 2013/2007 共存环境中的 Exchange Web 服务连接流程 |内部 Exchange 2007 客户端

在 Exchange 2013/2007 共存环境中，Exchange 2007 客户端的 Exchange Web 服务将由 Exchange CAS 2007 服务器提供。

需要强调的是，Exchange 2007 客户端“不知道”他们需要为 Exchange Web 服务处理 Exchange CAS 2007。相反，Exchange 2007 客户端从 Exchange CAS 2013 获取信息，或者如果我们想要更准确的话：从 Exchange CAS 2013 提供的自动发现信息获取信息。

到 Exchange CAS 2007 的“引用”将通过使用基于旧命名空间的 Exchange CAS 2007 URL 地址来实现。

注意：在本文中，我们将基于以下场景：Exchange CAS 2007 旧命名空间为：legacy.mail.o365info.com

在下图中，我们可以看到 Exchange 2013/2007 共存环境中的 Exchange Web 服务流的示例。

第 1 阶段 - 在此阶段，Exchange 2007 客户端与作为自动发现端点的 Exchange 2013 CAS 相关。 Exchange 2007 客户端寻址 Exchange 2013 CAS 并请求自动发现信息。

第 2 阶段 - Exchange 2013 CAS 提供所需的自动发现信息，其中包括“Exchange 2007 旧命名空间”Exchange Web 服务的 URL 地址。
在我们的方案中，Exchange 2013 CAS 提供的 URL 地址是：
https://legacy.mail.o365info.com/EWS/Exchange.asmx

步骤 3 - 当 Exchange 2007 客户端需要获取特定的 Exchange Web 服务（例如可用性服务（空闲/忙碌时间））时，他将使用在上一阶段获取的自动发现信息。在我们的场景中，Exchange Web 服务 URL 地址为：https://legacy.mail.o365info.com/EWS/Exchange.asmx

Exchange 2007 客户端将查找名为：legacy.mail.o365info.com 的主机的 IP 地址，并向该主机（Exchange CAS 2007）请求特定的 Exchange Web 服务。

Exchange 2013/2007 共存环境中的 Exchange Web 服务连接流程 |外部 Exchange 2007 客户端

需要获取 Exchange Web 服务的外部 Exchange 2007 客户端的客户端协议连接流与上一节中描述的内部 Exchange 2007 客户端的逻辑非常相似。

唯一值得一提的是，在需要 Exchange Web 服务的外部 Exchange 2007 客户端的情况下，自动发现信息将由面向公众的 Exchange 2013 CAS 服务器提供，并包括有关“代表”Exchange 的旧命名空间的信息中国科学院 2007。

Exchange CAS 2007 还需要配置为面向公众的 Exchange CAS 服务器，因为外部 Exchange 2007 客户端只要需要 Exchange Web 服务就会向他寻址。

在下图中，我们可以看到“旅程”从外部 Exchange 2007 客户端寻址公共自动发现端点时开始：autodiscover.o365info.com

“答案”包括“包含”主机名的 URL 地址：legacy.mail.o365info.com

当外部Exchange 2007客户端需要特定的Exchange Web服务时，他会尝试获取主机名的IP地址：legacy.mail.o365info.com并对其进行寻址。

主机名：legacy.mail.o365info.com，应发布为公共名称并具有公共 IP 地址。

Exchange 2013/2010 共存环境中的 Exchange Web 服务连接流程 |内部 Exchange 2010 客户端

在 Exchange 2013/2010 共存环境中，最佳实践是 Exchange 2010 客户端在需要 Exchange Web 服务时将寻址 Exchange CAS 2013。

此逻辑的实现可能会令人困惑，因为此方案的实现要求我们为 Exchange 2013 Web 服务和 Exchange 2010 Web 服务的 Exchange Web 服务使用相同的命名空间。

在“相同命名空间”的场景中，我们对两个基础架构使用“主”或“主”命名空间：Exchange 2013 Web 服务 + Exchange 2010 Web 服务

为了演示 Exchange 2013/2010 共存环境中 Exchange Web 服务的概念，我们使用以下场景详细信息：

组织 Exchange 基础结构包括以下 Exchange CAS 服务器：

• Exchange CAS 2013 的“真实姓名”是：EXCAS2013.o365info.com
• Exchange CAS 2010 的“真实姓名”是：EXCAS2010.o365info.com
• “映射”到 Exchange CAS 2013 的主命名空间是：mail.o365info.com

将在两台 Exchange CAS 服务器（Exchange CAS 2013 和 Exchange CAS 2010）上配置的 Exchange Web 服务 URL 为：
https://mail.o365info.com/EWS /Exchange.asmx

众所周知，Exchange Web 服务分为两个阶段。第一步可以描述为 - 自动发现阶段。

1. Exchange 2010 客户端将 Exchange CAS 2013 称为“自动发现端点”，并请求自动发现信息。
2. 当Exchange CAS 2013收到自动发现信息的请求时，他查询Active Directory有关用户的信息，发现Exchange客户端是：Exchange 2010客户端。由于 Exchange CAS 2013 本身不提供自动发现服务，并且由于客户端是 Exchange 2010 客户端，因此 Exchange CAS 2013 会将请求代理给 Exchange CAS 2010。
3. Exchange CAS 2010 生成所需的自动发现信息，其中包括 Exchange Web 服务的 URL 地址：https://mail.o365info.com/EWS/Exchange.asmx
4. Exchange CAS 2013 将自动发现信息“传递”到 Exchange 2010 客户端。

请注意，Exchange CAS 2013 和 Exchange CAS 2010 之间的“对话”或通信通道是使用“内部”或“真实”主机名实现的。例如，当 Exchange CAS 2013 向 Exchange CAS 2010 寻址时，他会查找名为：EXCAS2010.o365info.com 的主机，并且当 Exchange CAS 2010 发送其答案时，他将引用 Exchange CAS 2013 年为：EXCAS2013.o365info.com

在 Exchange Web 服务客户端的第二阶段中，连接协议流。 Exchange 2010 客户端寻址他从自动发现响应的上一阶段获得的“URL 地址”。

在我们的场景中，Exchange 2010 客户端拥有的 Exchange Web 服务 URL 地址为：https://mail.o365info.com/EWS/Exchange.asmx

现在，Exchange 2010 客户端需要将主机名： mail.o365info.com 解析为 IP 地址，并寻址特定主机以请求所需的 Exchange Web 服务。

1. Exchange 2010 客户端地址主机名：mail.o365info.com，该主机名“映射”到 Exchange CAS 2013 服务器。
2. 当Exchange CAS 2013收到自动发现信息的请求时，他查询Active Directory有关用户的信息，发现Exchange客户端是：Exchange 2010客户端。由于本身 Exchange Web 服务不提供 Exchange CAS 2013 并且由于客户端是 Exchange 2010 客户端，因此 Exchange CAS 2013 会将请求代理到 Exchange CAS 2010。
3. Exchange 2010客户端接受请求，“生成”所需的信息并将其发送回Exchange CAS 2013
4. Exchange CAS 2013 向 Exchange 2010 客户端提供所需的信息。

请注意，从 Exchange 2010 客户端的角度来看，提供所需信息的元素是 Exchange CAS 2013。Exchange 2010 客户端不知道“在幕后”实施的过程。

Exchange Web 服务在 Exchange 2013/2010 共存环境中采用了“层”概念。

Exchange 2013/2010 共存环境中的 Exchange Web 服务场景中的一个重要内容是我所描述的：“层概念”

术语“层”的含义是在 Exchange Web 服务流中，我们使用两个不同的层：

逻辑层与“物理层”或 CAS 到 CAS 通信层。

在“逻辑层主机名”中，我们使用主命名空间来表示 Exchange CAS 2013 的主机名。Exchange CAS 2010 将以主机名作为可以提供所需 Exchange Web 服务的元素。

在我们的场景中，Exchange Web 客户端将使用以下名称来寻址 Exchange CAS 2013：mail.o365info.com

实际上，Exchange CAS 2013 并不真正提供 Exchange Web 服务，而是充当 Exchange 2010 客户端与生成和管理 Exchange Web 服务的 Exchange CAS 2010 之间的“信使”或“中介”。

当 Exchange CAS 2013 寻址 Exchange CAS 2010 时，Exchange CAS 2013 将使用 Exchange CAS 2010 的“真实姓名”。在我们的场景中：EXCAS2010.o365info.com

当 Exchange CAS 2010 回复 Exchange CAS 2013 请求时，他将使用以下名称对 Exchange CAS 2013 服务器进行寻址：EXCAS2013.o365info.com

这是用于 CAS 到 CAS 通信（Exchange CAS 2013 和 Exchange CAS 2010 之间的通信）过程的“物理层”。

Exchange 2010 客户端不知道此基础架构，我们可以将此基础架构称为幕后基础架构

外部与内部 Exchange 客户端和 Exchange Web 服务

在下面的部分中，我想简要回顾一下外部与内部 Exchange Web 服务客户端的概念。

在此阶段，您一定对 Exchange 2013 共存环境中 Exchange Web 服务的不同方面的磨练感到有点疲倦，所以......稍微耐心一点，我们已经完成了！

让我们简单一点吧；从技术上讲，需要 Exchange Web 服务的外部与内部 Exchange 客户端之间没有显着差异。

Exchange 2010 外部和内部 Web 服务客户端

在下图中，我们可以看到，对于需要 Exchange Web 服务的外部和内部 Exchange 2010 客户端，我们以相同的方式实现了上一节中查看的相同逻辑。

当 Exchange 2010 客户端向 Exchange 2013 CAS“请求”自动发现信息时实施第一阶段。外部和内部 Exchange 2010 客户端之间的区别在于它们用于定位自动发现端点（Exchange 2013 CAS）的方式。

内部 Exchange 2010 客户端将查询本地 Active Directory 以获取可用自动发现端点的名称，外部 2010 客户端将查询 DNS 服务器以获取主机的公共 IP 地址：autodiscover.o365info.com

发送到外部和内部 Exchange 2010 客户端的自动发现信息将包括 Exchange Web 服务的 URL 地址，例如：
https://mail.o365info.com/EWS /Exchange.asmx

当 Exchange 2010 客户端（外部或内部）需要获取特定 Web 服务时，Exchange 2010 客户端将使用自动发现信息中提供的 URL。

URL 地址包含主机名：mail.o365info.com

• 当外部 Exchange 2010 客户端查看主机名：mail.o365info.com 时，该名称将解析为面向公众的 Exchange 2013 CAS 服务器的公共 IP 地址。
• 当内部 Exchange 2010 客户端查找主机名：mail.o365info.com 时，该名称将解析为 Exchange 2013 CAS 的私有 IP 地址。

Exchange 2007 外部和内部客户端

Exchange 2007 客户端对 Exchange Web 服务的访问对于外部和内部 Exchange 2007 客户端的实现方式相同。

发送到外部和内部 Exchange 2007 客户端的自动发现信息将包括 Exchange Web 服务的 URL 地址，例如： https://mail.o365info.com/EWS/Exchange.asmx

当 Exchange 2007 客户端（外部或内部）需要获取特定 Web 服务时，Exchange 2007 客户端将使用自动发现信息中提供的 URL。

URL 地址包含主机名：legacy.mail.o365info.com

• 当外部 Exchange 2007 客户端查找主机名：legacy.mail.o365info.com 时，该名称将解析为面向公众的 Exchange 2007 CAS 服务器的公共 IP 地址.
  请注意，Exchange CAS 2007 除了需要实现 Exchange 2007 方案的公共可用之外，它也是独一无二的，因为在这种环境中，我们需要实现两个面向公众的 Exchange CAS 服务器的配置并发布旧版本Exchange CAS 2007 的命名空间。
• 当内部 Exchange 2010 客户端查找主机名：legacy.mail.o365info.com 时，该名称将解析为 Exchange 2007 CAS 的私有 IP 地址。

交换网络服务 |外部邮件客户端和区域命名空间的场景

到目前为止，我们还没有提到的附加场景：Exchange Web 服务是：外部 Exchange 客户端 + 区域命名空间的场景。

该场景的章程如下：

Exchange 基础设施，包括两个面向公众的 Exchange 站点：马德里站点和纽约站点。公共自动发现记录指向“面向纽约公众的 Exchange CAS”。

外部 Exchange 客户端（即托管在马德里站点的 Exchange 邮箱服务器上的邮箱）通过将“面向纽约公众的 Exchange CAS 服务器”关联为自动发现端点来开始其“旅程”。

“面向纽约公众的 Exchange CAS 服务器”将对用户进行身份验证并执行 Active Directory 查找。

“面向纽约公众的 Exchange CAS 服务器”确定：用户 Exchange 邮箱服务器位于不同的 AD 站点上，并且“其他 Active Directory 站点”具有“公共可用性”含义，“其他 Exchange 站点”表示为不同的命名空间。在我们的场景中：europe.mail.o365info.com

在这种情况下，纽约面向公众的 Exchange CAS 服务器向外部 Exchange 客户端提供的自动发现信息将包括“马德里面向公众的 Exchange CAS”的 URL 地址。

我们可以将此方法称为“逻辑重定向”，因为面向纽约公众的 Exchange CAS 服务器不会敏锐地重定向外部 Exchange 客户端，而是提供外部 Exchange 客户端将使用的自动发现信息。

如果“马德里外部 Exchange 客户端”需要使用 Exchange Web 服务，他将不会寻址面向纽约公众的 Exchange CAS 服务器，而是寻址面向马德里公众的 Exchange CAS 服务器。