ActiveSync 和 Exchange Web 服务客户端协议连接流程在 Exchange 2013/2010 中共存4/4 | 23#23

本文是四篇文章系列的第四篇文章，主题为：“Exchange 2013/2010 共存环境和邮件客户端协议连接流程”。在本文中，我们的主要重点是回顾 Exchange 2013/2010 共存环境中两种类型的客户端协议连接流：

• ActiveSync 客户端协议连接流程
• Exchange Web 服务客户端协议连接流程

为了能够了解 Exchange 2013/2010 共存环境中不同的“Exchange 客户端”连接协议流，我们将回顾 Exchange 2010 客户端和 Exchange CAS 2013 服务器之间存在的五种类型的“关系”：

• 自动发现客户端 - 协议连接流程（第 2#4 部分）
• Outlook 客户端 - 协议连接流程（第 2#4 部分）
• OWA 客户端 - 协议连接流程（第 3#4 部分）
• ActiveSync 客户端 - 协议连接流程（第 4#4 部分）
• Exchange Web 服务客户端 - 协议连接流程（第 4#4 部分）

交流2013/2010共存| ActiveSync 客户端协议连接流程

Exchange ActiveSync 客户端（移动客户端）始终被视为“外部客户端”，因为移动客户端的网络基础结构基于公共移动网络。移动客户端（ActiveSync 客户端）始终需要寻址面向公众的 Exchange CAS 服务器，因此，接受移动 (ActiveSync) 客户端通信请求的“连接点”（Exchange CAS 服务器）必须配置为“面向公众的 Exchange CAS 服务器。 ”

注意 - 其他 Exchange 客户端（例如 Outlook 和 OWA）可以连接内部（或外部）Exchange 基础结构。

当 ActiveSync（移动）客户端连接面向公众的 Exchange CAS 服务器时，基于提供的用户凭据，面向公众的 Exchange CAS 服务器会找出用户邮箱的托管位置，并将通信请求“路由”（代理）到内部交换基础设施。

ActiveSync（移动）客户端通信请求的“内部路由”通过使用内部ActiveSync URL 地址实现。

场景1：移动(ActiveSync)客户端|用户邮箱位于纽约网站。

场景包机：Mobile（ActiveSync）客户端，需要访问他的邮箱。

• Exchange 用户类型：Exchange 2010 客户端（邮箱托管在 Exchange 2010 邮箱服务器上的 Exchange 用户）。
• Exchange 邮箱服务器位置：托管用户邮箱的 Exchange 2010 邮箱服务器位于纽约站点。

ActiveSync 客户端协议连接流程将按如下方式实现：

1. 移动 (ActiveSync) 客户端使用服务器名称连接“面向纽约公众的 Exchange CAS”：mail.o365info.com 并提供其用户凭据。
2. CAS2013 使用用户凭据并执行 Active Directory 查找。
   CAS2013 确定：

3. 用户邮箱版本为：2010

   • 托管用户邮箱的 Exchange 2010 邮箱服务器位于纽约站点
4. 站点（纽约站点）中有一个本地 Exchange CAS 2010
5. CAS2013 将使用内部 Exchange 2010 CAS ActiveSync URL 地址（.（数字 2））将 ActiveSync 客户端请求 + ActiveSync 用户凭据代理到本地站点服务器中的 CAS2010。
6. CAS2010 将接受请求并将 ActiveSync 客户端连接请求“转发”（代理）到 Exchange 2010 邮箱服务器（编号3）。
7. Exchange 2010 邮箱服务器“获取”所需的用户邮箱内容并将数据发送回 CAS2010（编号4）。
8. CAS2010代理将信息\数据返回给CAS2013（编号5）。
9. CAS2013 向外部 ActiveSync 客户端（编号6）提供所需信息。

场景 2：移动 (ActiveSync) 客户端 |位于洛杉矶网站的用户邮箱|目标站点=Intranet 站点 |没有本地 Exchange 2010 CAS

场景包机：Mobile（ActiveSync）客户端，需要访问他的邮箱。

• Exchange 用户类型：Exchange 2010 客户端（其邮箱托管在 Exchange 2010 邮箱服务器上的 Exchange 用户）。
• Exchange 邮箱服务器位置：托管用户邮箱的 Exchange 2010 邮箱服务器位于洛杉矶站点。
• 纽约站点没有“本地”Exchange 2010 CAS。

由于在我们的场景中，Exchange 2010 邮箱托管在其他站点（洛杉矶站点）的 Exchange 2010 邮箱服务器上，并且由于没有“本地 Exchange 2010 CAS”，因此 Exchange 2013 CAS 将自行代理外部移动客户端请求到位于洛杉矶站点（编号2）的“远程 Exchange 2010 CAS”。

注意：该过程的其余部分与我们已经在场景 1：ActiveSync 客户端 | 中查看的步骤相同。同一 Active Directory 站点上的 Exchange 用户邮箱。

场景 3：移动 (ActiveSync) 客户端 |位于马德里网站的用户邮箱 |目标站点=面向公众的交换站点 |区域命名空间

在我们开始了解“马德里 ActiveSync 用户”的具体细节之前，先简要回顾一下该特定场景的章程。

默认情况下，ActiveSync（移动）客户端将使用 Exchange 自动发现基础结构来获取将接受其请求的“服务器名称”。在“马德里 ActiveSync 用户”的情况下，应在自动发现过程中为 ActiveSync 客户端提供的 Exchange 服务器的名称是“马德里面向公众的 Exchange CAS 服务器”的名称： europe.mail.o365info.com

默认情况下，ActiveSync 客户端的首选方法是使用 Exchange 自动发现服务来获取所有必需的 ActiveSync 配置文件设置以及将充当“ActiveSync 服务器”的 Exchange 服务器的主机名，但是，在某些情况下，ActiveSync 客户端自动发现不使用服务，而是移动用户使用“手动方法”，其中他提供“Exchange 服务器名称”。

例如：当“马德里 ActiveSync 用户”想要访问他的邮箱时，他可以提供主命名空间：mail.o365info.com（选项A）图中）作为 Exchange a1 主机名，或者使用“马德里面向公众的 Exchange CAS 服务器”的主机名：europe.mail.o365info.com（选项 B）

如果“马德里 ActiveSync 用户”使用主命名空间：mail.o365info.com，则连接请求将被“面向纽约公众的 Exchange CAS 服务器”接受。 ”

“面向纽约公众的 Exchange CAS 服务器”需要知道如何“处理”此请求，因为在我们的场景中，ActiveSync 用户邮箱托管在另一个 Exchange 站点：马德里站点。

基本假设可能是，在这种情况下，“面向纽约公众的 Exchange CAS 服务器”将“将“马德里 ActiveSync 用户”重定向到其 Exchange 服务器，但 Exchange 2013 CAS 将不会使用重定向方法。

在这种情况下，“面向纽约公众的 Exchange CAS 服务器”不会重定向 ActiveSync 请求，而是将连接请求代理到“马德里 Exchange CAS 服务器”。

场景章程：移动（ActiveSync）客户端，需要访问他的邮箱。

• Exchange 用户类型：Exchange 2010 客户端（其邮箱托管在 Exchange 2010 邮箱服务器上的 Exchange 用户）。
• Exchange 邮箱服务器位置：托管用户邮箱的 Exchange 2010 邮箱服务器位于马德里站点。
• 马德里站点被视为面向公众的 Exchange 站点，并且“马德里面向公众的 Exchange CAS 服务器”使用区域命名空间发布：mail.o365info.com

该场景的特殊章程是——用户的邮箱位于不同的Exchange站点，并且目标站点是“面向公众的Exchange站点”

在以前版本的 Exchange 服务器中，在移动 (ActiveSync) 客户端连接面向公众的 Exchange CAS 服务器的情况下，并且 Exchange 服务器识别出移动 (ActiveSync) 客户端邮箱位于不同的 Exchange 站点 + “其他 Exchange”站点”被视为面向公众的 Exchange 站点，面向公众的 Exchange CAS 服务器的“响应”是：将消息重定向到移动 (ActiveSync) 客户端。

移动 (ActiveSync) 客户端应该接受“重定向消息”，并与“其他面向公众的 Exchange CAS 服务器（在我们的场景中为“马德里面向公众的 Exchange CAS 服务器”）创建新的通信通道。

重定向移动（ActiveSync）客户端的方法是通过使用描述为“451重定向消息”的消息来实现的。

“451 重定向消息”的问题在于 - 许多移动 (ActiveSync) 客户端不知道如何“处理”重定向消息，结果是：通信失败。换句话说，Mobile (ActiveSync) 客户端无法“理解”重定向消息，并且“指示”他连接“其他 ActiveSync Exchange 服务器”。

因此，Exchange CAS 2013 服务器的行为有所不同，因为 Exchange CAS 2013 服务器将不再实现任何重定向方法（451 重定向消息）适用于移动 (ActiveSync) 客户端。相反，当 Exchange 2013 CAS 识别出 ActiveSync 邮箱位于另一个 Exchange 站点上时，他会“代表”ActiveSync 将请求代理到“目标 Exchange 服务器”。 ”

在我们的场景中，纽约面向公众的 Exchange CAS 服务器“知道”用户邮箱位于马德里站点，并且马德里将其视为面向公众的 Exchange 站点（具有面向公众的 Exchange CAS 服务器）。

理论上，面向纽约公众的 Exchange CAS 服务器可以向 Mobile (ActiveSync) 客户端发送重定向命令，但纽约 Exchange 2013 CAS 将选择使用代理方法。

很明显，从“面向纽约公众的 Exchange 2013 CAS 服务器”的角度来看，这种方法效率不高，因为从理论上讲，“面向马德里公众的 Exchange CAS 服务器”应该为“马德里 ActiveSync（移动）客户端提供服务，但使用“代理方法”，将确保移动（ActiveSync）客户端通信能够成功完成。

ActiveSync 客户端协议连接流程将按如下方式实现：

1. 马德里移动 (ActiveSync) 客户端使用服务器名称连接“面向纽约公众的 Exchange CAS”：mail.o365info.com 并提供其用户凭据。

2. CAS2013 使用用户凭据并执行 Active Directory 查找。
   CAS2013 确定：

   • 用户邮箱版本为：2010
3. 托管用户邮箱的 Exchange 2010 邮箱服务器位于马德里站点
4. CAS2013 不会向马德里 ActiveSync 客户端发送重定向请求，而是通过使用外部“面向马德里公众的 Exchange CAS 服务器”ActiveSync URL 将 ActiveSync 客户端请求 + ActiveSync 用户凭据代理到“面向马德里公众的 Exchange CAS 服务器”地址（数字2）。
5. “面向马德里公众的 Exchange CAS 服务器”将接受请求并将 ActiveSync 客户端连接请求“转发”（代理）到“内部马德里 Exchange 2010 邮箱服务器”（编号 3）。
6. “内部马德里 Exchange 2010 邮箱服务器”“获取”所需的用户邮箱内容并将数据发送回“面向马德里公众的 Exchange CAS 服务器”（编号4）。
7. “马德里面向公众的 Exchange CAS 服务器”将信息\数据代理返回到“纽约面向公众的 Exchange CAS 服务器”（编号5）。
8. “面向纽约公众的 Exchange CAS 服务器”向外部 ActiveSync 客户端（编号6）提供所需信息。

交流2013/2010共存| Exchange Web 服务客户端协议连接流程

Exchange Web 服务连接流的主题 在 Exchange 2013/2010 共存环境中可能有点令人困惑，因为不清楚谁是向 Exchange 2010 客户端提供 Exchange Web 服务的“元素”。

该元素是实现标准代理代理机制的 Exchange 2013 CAS，Exchange 2010 客户端向 Exchange 2010 CAS 发出请求，还是 Exchange 2010 客户端直接连接到 Exchange 2010 CAS 并请求特定 Exchange Web 服务的另一种方案。

一般性说明：最“重要的 Exchange Web 服务客户端”是 Outlook 客户端。确实，还有其他 Exchange Web 服务客户端，但最依赖 Exchange Web 服务的 Exchange 客户端是 Outlook、邮件客户端。

因此，当我们提到“Exchange Web 服务和客户端协议连接流程”这个主题时，大多数时候我们指的客户端是 Outlook。

从技术上讲，向 Exchange 2010 客户端提供 Exchange Web 服务的“元素”可以是基于 Exchange CAS 2010 的服务器，也可以是基于 Exchange CAS 2013 的服务器。

问题的答案：谁是向 Exchange 2010 客户端提供 Exchange Web 服务的元素，取决于命名空间基础结构的特定实现。

• 如果 Exchange 2010 Web 服务的 URL 地址命名空间与 Exchange 2013 Web 服务的 URL 地址命名空间相同，则为 Exchange 2010 客户端提供服务的 Exchange Web 服务的元素是 Exchange 2013 CAS。
• 如果 Exchange 2010 Web 服务的 URL 地址命名空间与 Exchange 2013 Web 服务的 URL 地址命名空间不相同，则将为 Exchange 提供服务的 Exchange Web 服务元素2010 客户端是 Exchange 2010 CAS。

注意 - 在当前的文章中，我们不会详细解释这个概念，如果您想要更彻底的回顾，请阅读以下文章：

• Exchange 2013 共存环境中的 Exchange Web 服务 |第 1/2 部分
• Exchange 2013 共存环境中的 Exchange Web 服务 |第 2/2 部分

为了简化 Exchange Web 服务客户端协议连接流程的描述，我们将使用“最佳实践”配置场景，其中“元素”将充当请求 Exchange Web 服务的 Exchange 2010 客户端的“焦点”将是 Exchange 2013 CAS。

此方案的章程是 Exchange 2013 CAS 和 Exchange 2010 CAS 将使用 Exchange Web 服务的相同命名空间。

例如，在 Exchange 2013 CAS 中为 Exchange Web 服务配置的 URL 地址为：https://mail.o365info.com/EWS/Exchange.asmx 并且，在 Exchange 2010 CAS 服务器上为 Exchange Web 服务的 URL 地址配置相同的 URL 地址。

在这种情况下，Exchange 2010 客户端将向 Exchange 2013 CAS 发送 Exchange Web 服务，并且 Exchange 2013 CAS 将其请求代理到 Exchange 2010 CAS。

Exchange Web 服务和自动发现服务

为了能够更好地了解 Exchange 2013 共存环境中 Exchange Web 服务的实施，了解 Exchange 自动发现基础结构和 Exchange Web 服务基础结构之间存在的关系非常重要。

Exchange Web 服务“构建”于 Exchange CAS 服务器提供的自动发现信息之上。
当 Exchange 2010 客户端向 Exchange 2013 CAS 发送地址并请求自动发现信息时，Exchange 2013 CAS 将提供自动发现信息，其中包括Exchange Web 服务的 URL 地址。例如：https://mail.o365info.com/EWS/Exchange.asmx

Exchange 2010 客户端使用此信息来定位 Exchange CAS 服务器，该服务器将为他提供所需的 Exchange Web 服务。在我们的场景中，URL 地址包含主机名 - mail.o365info.com。此主机名会将 Exchange 2010 客户端指向 Exchange 2013 CAS 服务器。

在下图中，我们可以看到一个客户端协议连接流程示例，它描述了 Exchange 2010 客户端的“完整流程”。

第 1/2 阶段 - 自动发现服务

1. Exchange 2010 客户端，将 Exchange 2013 CAS 作为自动发现端点。
2. 自动发现响应 CAS2013“提供”包括 Exchange Web 服务的 URL 地址 URL 地址：https://mail.o365info.com/EWS/Exchange.asmx

第 2/2 阶段 - Exchange Web 服务

当 Exchange 2010 客户端需要特定的 Web 服务（例如可用性服务）
（空闲/忙碌时间）时，他将使用从自动发现响应中获取的 URL 地址：https:// mail.o365info.com/EWS/Exchange.asmx
此 URL 包含主机名：mail.o365info.com，该主机名将被“翻译”为Exchange 2013 CAS 的 IP 地址。

当 Exchange 2013 CAS 收到 Exchange 2010 对 Exchange Web 服务的请求时，他“了解”Exchange 邮件客户端是 Exchange 2010 客户端，因此，他会将请求“转发”（代理）到 Exchange 2010 CAS 。 Exchange 2013 CAS 解决了需要使用 Exchange 2010 CAS FQDN 向 Exchange 2010 客户端提供所需 Exchange Web 服务的 Exchange 2010 CAS 的问题。在我们的场景中：Excas2010.o365info.com

场景 1：内部/外部 Exchange Web 服务的客户端 |用户邮箱位于纽约网站。

场景章程： Exchange Web 服务客户端，需要获取特定的 Exchange Web 服务。

• Exchange 用户类型：Exchange 2010 客户端（其邮箱托管在 Exchange 2010 邮箱服务器上的 Exchange 用户）。
• Exchange 邮箱服务器位置：托管用户邮箱的 Exchange 2010 邮箱服务器位于纽约站点。

Exchange Web 服务客户端、协议连接流程将按如下方式实现：

Exchange Web 服务的初步过程是自动发现过程，其中外部 Exchange 2010 客户端获取包括 Exchange Web 服务的 URL 地址的自动发现信息。

1. Exchange Web 服务客户端使用以下 URL 地址：https://mail.o365info.com/EWS/Exchange.asmx，连接“纽约公众面向 Exchange CAS”并提供他的用户凭据。

2. CAS2013 使用用户凭据并执行 Active Directory 查找。 CAS2013 确定：

   • 用户邮箱版本为：2010
3. 托管用户邮箱的 Exchange 2010 邮箱服务器位于纽约站点
4. 站点（纽约站点）中有一个本地 Exchange CAS 2010
5. CAS2013 将 Exchange Web 服务客户端请求代理到本地站点中的 CAS2010。 “代理”进程包括 Exchange Web 服务用户（编号 2）提供的用户凭据。
6. CAS2010 将接受请求并将 Exchange Web 服务请求“转发”（代理）到 Exchange 2010 邮箱服务器（编号3）。
7. Exchange 2010邮箱服务器“回复”并将所需信息发送到CAS2010（编号4）。
8. CAS2010代理将信息返回给CAS2013（编号5）。
9. CAS2013 向外部 Exchange Web 服务客户端（编号 6）提供所需信息。