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

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

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

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

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

交流2013/2007共存| 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) 客户端 |用户邮箱位于纽约网站。

场景章程：一个ActiveSync Exchange 2007客户端，需要访问他的邮箱。

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

注意：在 Exchange 2013 共存环境中移动 Exchange 2007 客户端的特殊章程是 Exchange 2013 CAS 不会直接连接 Exchange 2007 CAS，而是将 Exchange 2007 ActiveSync 客户端请求代理到 Exchange 2013邮箱服务器。

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

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

3. 用户邮箱版本为：2007

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

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

场景章程：一个ActiveSync Exchange 2007客户端，需要访问他的邮箱。

• Exchange 用户类型：Exchange 2007 客户端（邮箱托管在 Exchange 2007 邮箱服务器上的 Exchange 用户）。
• Exchange 邮箱服务器位置：托管用户邮箱的 Exchange 2007 邮箱服务器位于洛杉矶站点。
• 洛杉矶站点是一个 Intranet 站点（非面向公众的 Exchange 站点）

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

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

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

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

场景 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 主机名。另一种选择是使用“面向马德里公众的 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 服务器”。

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

• Exchange 用户类型：Exchange 2007 客户端（其邮箱托管在 Exchange 2007 邮箱服务器上的 Exchange 用户）。
• Exchange 邮箱服务器位置：托管用户邮箱的 Exchange 2007 邮箱服务器位于马德里站点。
• 马德里站点被视为面向公众的 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 客户端（移动客户端）不知道如何“消化”重定向消息，结果是 - 通信ActiveSync 客户端失败。

因此，Exchange CAS 2013 服务器的行为有所不同，因为 Exchange CAS 2013 服务器将不再为 ActiveSync 客户端实现重定向方法（451 重定向消息）。

在我们的场景中，面向纽约公众的 Exchange CAS 服务器“知道”用户邮箱位于马德里站点，此外，马德里站点还有面向公众的 Exchange CAS 服务器。
理论上，面向纽约公众的 Exchange CAS 服务器“知道”用户邮箱位于马德里站点，并且马德里站点有面向公众的 Exchange CAS 服务器。 Exchange CAS 服务器可以将 Exchange ActiveSync 重定向到此服务器，但 New York Exchange 2013 CAS 将选择使用代理方法。

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

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

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

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

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

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

Exchange Web 服务连接流的主题 在 Exchange 2013/2007 共存环境中可能有点令人困惑，因为不清楚谁是向 Exchange 2007 客户端提供 Exchange Web 服务的“元素”。
该元素是 - Exchange 2013 CAS 实现代理的标准代理机制、Exchange 2007 客户端向 Exchange 2007 CAS 发出请求，还是 Exchange 2007 客户端直接连接到 Exchange 2007 CAS 并请求特定交换 Web 服务的其他方案？

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

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

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

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

我们可以从一个基本规则开始：在 Exchange 2013/2007 共存环境中，Exchange 2007 CAS 是向 Exchange 2007 客户端提供 Exchange Web 服务的元素。

Exchange 2013/2007 共存环境中 Exchange Web 服务的实现是通过使用 Exchange 2013 CAS 自动发现服务 + Exchange 2007 CAS Web 服务的组合来实现的。

在 Exchange 2013/2007 共存环境中，Exchange 2007 客户端将根据 Exchange 2013 CAS 向其提供的自动发现信息，使用旧命名空间连接 Exchange 2007 CAS。

场景 1：内部 Exchange 2007 客户端 | Exchange 2007 用户邮箱位于纽约站点。

场景章程：一个内部Exchange 2007客户端，需要获取Exchange web服务。

• Exchange 2007 用户邮箱托管在纽约站点上（Exchange 2007 邮箱服务器位于纽约站点）。

场景章程：外部Exchange 2007客户端，需要获取Exchange web服务。

1. 内部 Exchange 客户端连接 Exchange 2013 CAS 服务器并请求自动发现信息。
2. CAS2013 使用用户凭据并执行 Active Directory 查找。 CAS2013判定：用户邮箱版本为：2007
3. CAS2013 发送到 Exchange 2007 自动发现信息，其中包括有关 Exchange Web 服务 URL 地址的信息。 URL 地址基于 Exchange 2007 旧命名空间。
4. Exchange 2007 客户端获取自动发现信息并将其保存以供以后使用。
5. 当 Exchange 2007 需要特定的 Exchange Web 服务时，例如可用性服务（空闲\忙碌时间），他将使用 Exchange 2007 CAS 旧命名空间（编号3）联系 Exchange 2007 CAS 服务器。

场景 2：外部 Exchange Web 服务的客户端 |同一 Active Directory 站点上的 Exchange 2007 用户邮箱

场景章程：外部Exchange 2007客户端，需要获取Exchange web服务。

• Exchange 2007 用户邮箱托管在纽约站点上（Exchange 2007 邮箱服务器位于纽约站点）。
• 纽约包括两个面向公众的 Exchange CAS 服务器：使用公共名称发布的“Exchange 2007 CAS 面向公众的 Exchange CAS 服务器”：legacy.mail.o365info.com 和使用公共名称发布的“Exchange 2013 CAS 面向公众的 Exchange CAS 服务器”：mail.o365info.com

Exchange Web 服务连接流程实施如下：

1. 外部Exchange 2007客户端，连接CAS2013服务器并提供用户凭据。
2. CAS2013 将验证用户身份并执行 Active Directory 查找。
3. CAS2013 确定：用户邮箱版本为 2007 + 位于同一 AD 站点的用户 Exchange 邮箱服务器（和 CAS2007 服务器）。
4. CAS2013 将把 Exchange Web 服务请求代理到本地站点（编号 2）中的 CAS2007。
5. CAS2007将生成所需的信息并将其发送回CAS2013服务器（编号3）。
6. CAS2013 向外部 Exchange 2007 客户端“提供”Exchange Web 服务信息（编号4）。