Exchange 2013/2010 共存中的客户端协议连接流程简介及基本概念| 1/4 | 1/4 20#23

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

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

我们将在当前文章系列中使用的一般术语。

1. Exchange 2010 客户端 - 当我们提到术语：Exchange 2010 客户端时，其含义是其邮箱托管在 Exchange 2010 邮箱服务器上的 Exchange 客户端。
2. Exchange CAS 2013 或 CAS2013 或“纽约面向公众的 Exchange CAS” - 在我们的场景中，Exchange 2013 共存环境是通过将 Exchange CAS 2013 基础结构添加到总部公司：纽约站点来实现的。 “New York Exchange 2013 CAS 服务器”将作为外部 Exchange 客户端和内部 Exchange 客户端的主要点或焦点，作为： 自动发现端点。

Exchange 2010 客户端协议连接流程路线图

Exchange 2013共存环境的主要章程之一是不同邮件客户端协议、不同Exchange服务等的“丰富性”。

为了能够“消化”这个复杂的基础设施，我们需要使用一些逻辑结构来帮助我们安排所有不同的部分。

为了阐明 Exchange 2013 CAS 服务器与其 Exchange 2010 客户端之间“关系”的本质，我们可以定义 Exchange 2013 CAS 服务器对其 Exchange 2010 客户端（以及 Exchange 2013 客户端）的三个主要职责。

我们可以将 Exchange CAS 对他的 Exchange 客户端的职责分为两个主要部分：

第 1 部分：提供对用户邮箱的访问

Exchange 2013 CAS 为其 Exchange 客户端（旧版或非旧版 Exchange 客户端）提供的最基本、最重要的服务是访问其邮箱内容的能力。

在 Exchange 环境中，Exchange 客户端访问 Exchange 邮箱内容的唯一方法是通过对 Exchange CAS 服务器进行寻址，该服务器将“处理其请求”并在 Exchange 邮件客户端与其 Exchange 邮箱服务器（在在我们的场景中，由 Exchange 2010 邮箱服务器托管的邮箱）。

更具体地说，“提供邮箱访问”这个术语，在 Exchange 2013 共存环境中，Exchange CAS 服务器负责为三种不同类型的邮件客户端提供邮箱访问：

1. 网络邮件客户端 (OWA)
2. ActiveSync 邮件客户端（移动）
3. Outlook 邮件客户端

第 2 部分：自动发现服务

自动发现服务

• 将 Exchange 客户端（提供信息）指向现有的 Exchange Web 服务，例如：空闲\忙碌时间等。
• 为 Outlook 客户端提供创建新邮件配置文件以及与 Exchange 服务器持续通信所需的配置设置。

第 3 部分：Exchange Web 服务

在 Exchange 2013/2010 共存环境中，向 Exchange 2010 客户端提供 Exchange Web 服务的元素是 Exchange 2013 CAS 服务器。

默认情况下，Exchange 2010 客户端将联系 Exchange CAS 2013，并且在“幕后”，Exchange CAS 2013 将从 Exchange CAS 2010 服务器“获取”自动发现信息。

1.交换CAS服务器|提供 Exchange 邮件客户端对其邮箱的访问。

每个 Exchange 邮件客户端都有独特且特定的章程。因此，每个“邮件客户端”与 Exchange CAS 2013 具有不同的关系，或者换句话说：每个 Exchange 邮件客户端的客户端协议连接流的实现方式都不同。

在 Exchange 2013/2010 共存环境中，启用 Exchange 2010 客户端访问其邮箱的“任务”将默认使用“代理”方法来实现。
当 Exchange 2010 客户端（例如 Outlook、ActiveSync 或 OWA）地址时当 Exchange 2013 CAS 请求访问其邮箱时，Exchange 2013 CAS 会将其请求代理给 Exchange 2010 CAS。

“默认代理”规则的一个例外是在以下场景中实现：“Exchange OWA 客户端和多个面向公众的 Exchange 站点环境。在这种情况下，Exchange CAS 2013 将使用重定向的方法而不是“代理”。您可以在文章中阅读有关此方案的更多信息：Exchange 2013/2010 共存环境中的 OWA 客户端协议连接流 | 3/4

注意： 在“多个面向公众的 Exchange 站点环境”场景中重定向 OWA 客户端的方法不仅与“Exchange 2010 OWA 客户端”相关，而且与任何外部 Exchange OWA 客户端相关。

在下图中，我们可以看到当 Exchange 2010 客户端请求访问其“Exchange 2010 邮箱”时，在 Exchange 2013/2010 共存环境中实现的 Exchange 客户端协议连接流的摘要。 ”

Exchange 2010 客户端将通过 Exchange CAS 2013 服务器的“中介”访问托管在 Exchange 2010 邮箱服务器上的邮箱。换句话说，Exchange 2013 CAS 会将所有 Exchange 2010 客户端代理到“旧版 Exchange 基础结构”(Exchange CAS 2010)。

2. Exchange 服务器作为自动发现提供程序

在 Exchange 2013/2010 共存环境中，Exchange CAS 2013 服务器充当所有类型的 Exchange 客户端的“自动发现焦点”：本机 Exchange 客户端 (Exchange 2013) 和旧版 Exchange (Exchange 2010) 客户端。

当 Exchange 2010 客户端寻址 Exchange 2013 CAS 并请求自动发现信息时，Exchange 2013 CAS 通过将自动发现请求“转发”（代理）到 Exchange 2010 CAS 来处理该请求。

生成自动发现信息的元素是 Exchange 2010 CAS，“物理”向 Exchange 2010 客户端提供自动发现信息的元素是 Exchange 2013 CAS。

回顾一下：

• Exchange 2010 客户端在需要自动发现信息时将寻址 Exchange CAS 2013 服务器。换句话说，Exchange 2010 客户端与 Exchange 2013 CAS 相关：自动发现端点。
• Exchange CAS 服务器将请求代理到 Exchange 2010 CAS。
• Exchange 2010 CAS 生成自动发现响应。

3. Exchange 服务器和 Exchange Web 服务

第三部分涉及 Exchange Web 服务。
在 Exchange 2013/2010 共存环境中，首选方法或最佳实践是：Exchange 2013 CAS 将向 Exchange 2010 客户端提供 Exchange Web 服务。

交换共存环境|场景基础设施和章程描述

在接下来的三篇文章中，我们将回顾以下几种可能的场景： Exchange 2013/2010 共存环境中的 Exchange 2010 客户端协议连接流。

将用于演示可能的协议连接流的组织基础设施具有以下特征：

地理基础设施中断

o365info 是一家全球性公司，拥有三个站点：
两个站点位于美国，一个站点位于欧洲。

1. 面向公众的交易所网站

公司总部站点位于纽约，其他站点是洛杉矶和马德里站点。

纽约和马德里站点是：“面向互联网的站点”。

• 纽约站点包括面向公众的 Exchange 2013 服务器。
• 马德里站点包括面向公众的 Exchange 2010 服务器。

2. 非面向公众的交换站点

洛杉矶站点配置为 Intranet 站点。意思是“洛杉矶内部 Exchange 基础设施不会“暴露”给公共 Exchange 客户端。
洛杉矶 Exchange 用户没有能力“直接访问”其 Exchange 基础设施，但相反，他们需要使用“纽约面向公众的交易所 CAS”作为“调解者”或“经纪人”，帮助他们访问“内部洛杉矶”交易所基础设施。
在一个场景中，“外部洛杉矶交易所”用户”需要访问他的邮箱，用户将发送“纽约面向公众的 Exchange CAS”并使用“他的帮助”访问他的邮箱。
“纽约面向公众的 Exchange CAS”将接受洛杉矶外部 Exchange 客户端，并将这些请求代理到内部 Los Angles Exchange 基础设施。

公共交换基础设施|主要\主要面向公众的交换站点的概念|自动发现端点

尽管 Exchange 公共基础设施可以分布在许多面向公众的 Exchange 站点之间，并使用许多不同的命名空间，但 Exchange 公共环境的“逻辑基础设施”在大多数情况下将基于可描述为“集中式模型”的模型。 。

这种“集中模式”概念的含义是，所有的 Exchange 客户端，都将通过连接或解决特定的“焦点”来开始他们的“旅程”，而这个“焦点”将决定如何“促进”Exchange 客户端的请求。

在公共 Exchange 环境中，“焦点”的含义转化为公共自动发现端点的概念。

如前所述，即使在组织基础设施由多个面向公众的 Exchange 站点组成的情况下，自动发现端点也将仅指向一个“元素”，并且客户端协议连接流将根据以下信息“确定”：由该“主要自动发现端点”提供。 ”

注意：描述性概念：“主要公共自动发现端点”在大多数情况下都会实现，但是，此方法还有其他替代方法。例如，在现代网络环境中，可以选择使用 GeoDNS，它可以实现不同的“分布式模型”（相对于“标准集中式模型”）。

在基于 GeoDNS 的解决方案中，自动发现公共记录（例如：autodiscover.o365info.com）将同时指向几个面向公众的 Exchange 站点。将客户端“引导”到“正确的自动发现端点”的元素是 GeoDNS 服务器。

为了演示“主要面向公众的交换站点”的概念，它扮演公共自动发现端点的角色，让我们使用以下场景：

“主要面向公众的交易所 CAS”和自动发现服务

具有四个面向公众的 Exchange 站点的组织。尽管有四个具有“公共可用性”的 Exchange 站点，并且每个站点都有一个： 面向公众的 Exchange CAS 服务器，但只有一个站点将被视为“主要面向公众的 Exchange 站点”。在我们的场景中，自动发现记录：autodiscover.o365info.com 指向站点 1 中面向公众的 Exchange CAS 服务器。

在下图中，我们可以看到来自所有不同 Exchange 站点的外部 Exchange 客户端开始与站点 1 中面向公众的 Exchange CAS 服务器进行通信过程。因为公共自动发现记录已“映射”到公共的 IP 地址面向站点 1 的 Exchange CAS 服务器。

• 如果外部 Exchange 客户端“属于”站点 1，面向公众的 Exchange CAS 服务器将发送自动发现信息，其中包括有关站点 1 中的公共 Exchange 资源的信息。
• 如果外部 Exchange 客户端“属于”站点 2，面向公众的 Exchange CAS 服务器将发送自动发现信息，其中包括有关站点 2 中的公共 Exchange 资源的信息等。

“主要面向公众的 Exchange CAS”和对邮箱数据服务的访问

在外部 Exchange 客户端需要访问其邮箱的情况下，站点一中面向公众的 Exchange CAS 服务器到目前为止一直充当：“公共自动发现端点”，开始充当处理 Exchange 客户端的“智能路由器”邮箱访问请求。

场景 1：如果外部 Exchange 客户端“属于”站点 1，则面向公众的 Exchange CAS 服务器会将外部 Exchange 客户端请求代理到“内部 Exchange 基础结构”。 ”

如果外部 Exchange 客户端“属于”站点 2，则有几种可能的情况。

场景 1：如果“站点 2 的 Exchange 客户端”是 Outlook 客户端，则外部 Outlook 客户端将联系“其站点”的“公共代表”，例如面向公众的 Exchange CAS 服务器站点 2 的位置（基于他在上一阶段获得的自动发现信息）。

场景 2：如果“站点 2 的 Exchange 客户端”是 ActiveSync 客户端，则“面向纽约公众的 Exchange CAS”将把客户端请求代理到“面向马德里公众的 Exchange CAS”。 ”

场景 3：如果“站点 2 的 Exchange 客户端”是 OWA 客户端，“面向纽约公众的 Exchange CAS”将向 OWA 客户端发送重定向命令，该命令将 OWA 客户端浏览器重定向到“马德里面向公众的交易所 CAS”。

在下图中，我们可以看到“纽约公众
Exchange CAS”接受外部Exchange客户端通信请求，并根据类型和Exchange CAS服务器位置决定如何处理该请求的过程。

组织命名空间和交换基础设施

在 Exchange 2013/2010 共存环境中，我们可以涉及几个“命名空间基础设施”：

1. 外部\公共命名空间基础结构 - 这是用于发布具有公共可用性的 Exchange 主机（可由外部 Exchange 客户端访问）的命名空间
2. 主命名空间基础设施——“中心概念”的“翻译”是 Exchange CAS 服务器，它将充当“焦点自动发现端点”
3. 内部命名空间基础结构 - 这是“不暴露”到公共网络的命名空间基础结构，只能由内部 Exchange 客户端使用。内部 Exchange 命名空间可能与外部命名空间不同，此方案描述为不相交的命名空间。在我们的特定情况下，内部和外部名称空间是相同的。

在我们的场景中，我们将基于两个命名空间：

1. 主命名空间 - 主命名空间指向“面向 Exchange 2013 纽约公众的 Exchange CAS 服务器”
2. 区域命名空间 - 区域命名空间，指向“面向 Exchange 2010 马德里公众的 Exchange CAS 服务器”

在实施 Exchange 2013 共存环境之前，“面向纽约公众的 Exchange 站点”的代表是 Exchange CAS 2010。在实施 Exchange 2013 共存环境之后，其中包括：将 Exchange 2013 服务器添加到公司总部站点（纽约站点），Exchange CAS 2013 将取代之前配置为面向公众的 Exchange CAS 服务器的 Exchange CAS 2010。

在我们的场景中，主命名空间将“附加”到“面向纽约公众的 Exchange 2013 CAS 服务器”。 ”

Exchange 公共基础设施将包括以下公共 DNS 记录：

1. 主命名空间，包含两条指向“面向纽约公众的 Exchange CAS 服务器”的 DNS 记录：

   • 自动发现记录：autodiscover.o365info.com
2. 所有其余 Exchange 服务的 FQDN 名称：mail.o365info.com
3. 区域命名空间 - 马德里面向公众的 Exchange 站点将继续使用 Exchange CAS 2010 作为面向公众的 Exchange CAS 服务器。 “马德里面向公众的 Exchange 20007 CAS 服务器”通过使用区域命名空间的公共 DNS 记录发布：europe.mail.o365info.com

Exchange 2013 CAS 作为起点并作为外部 Exchange 客户端的“智能路由器”

在 Exchange 公共环境中，面向公众的 Exchange CAS 服务器充当外部 Exchange 客户端的自动发现端点，在 Exchange 客户端协议连接流中占有非常重要的部分，因为所有“流”都将从特定点开始 -公共自动发现端点。

第 1 阶段：Exchange 2013 CAS 作为中央自动发现端点

由于 Exchange 2013 CAS 配置为自动发现端点，因此所有“Exchange 客户端流”都将从该特定 Exchange 服务器开始，

所有外部 Exchange 客户将通过将“面向纽约公众的 Exchange CAS”作为信息源或更专业的术语：自动发现端点，开始与“面向纽约公众的 Exchange CAS”的初始通信流程。

相同的“自动发现逻辑”也适用于内部 Exchange 客户端和两种不同类型的 Exchange 客户端（例如 Exchange 2010 客户端和 Exchange 2013 客户端）。

“面向纽约公众的 Exchange CAS”将向外部 Exchange 客户端提供的信息以及客户端协议连接流的继续将取决于外部 Exchange 客户端邮箱的物理位置。

第 2 阶段：Exchange 2013 作为“智能路由器”

Exchange 2013 CAS 在完成“中央自动发现端点”的工作后的第二个“头衔”是充当“智能路由器”，它将处理外部 Exchange 邮件客户端请求，并基于独特的章程场景，选择最好的“下一步”。

在下图中，我们可以看到不同方法的示例，Exchange 2013 CAS 在从外部和内部 Exchange 2010 客户端获取“连接\服务请求”时可以选择这些方法。

在下图中，我们可以看到不同方法的示例，Exchange 2013 CAS 在从外部和内部 Exchange 2010 客户端获取“连接\服务请求”时可以选择这些方法。

Exchange 2013 CAS 可以选择以下方法之一来为 Exchange 客户端提供服务：

1. Exchange 2013 CAS 可以选择将请求代理到： 本地 Exchange 2010 CAS，例如在 Exchange 客户端 2010 Outlook 和 ActiveSync 需要访问其邮箱（编号 1）的情况下。
2. Exchange 2013 CAS 可以选择请求的代理：位于不同 Active Directory 站点上的“远程 Exchange 2010 CAS”。此操作描述为：跨站代理（数量2+3）。
3. Exchange 2013 CAS 可以选择多种方法的组合，例如：在 OWA 客户端和区域命名空间（编号4）。
4. 在 Exchange 2013 客户端需要访问其邮箱（编号5）的情况下，Exchange 2013 CAS 可以选择将请求代理到 Exchange 2013 邮箱服务器。

客户端协议连接流程|场景矩阵

Exchange 2013/2010 共存环境中最令人困惑的主题之一，我将其描述为：“客户端协议连接流 - 场景的矩阵基础设施”

我使用“矩阵”这个术语是因为，在复杂的 Exchange 环境中，客户端协议连接流场景的数量可能非常巨大。

为了能够使其更“易于消化”，我们可以将可选的客户端协议连接流情况减少为上述六种情况。

“六大场景”可分为两组：

1.外部 Exchange 2010 客户端的可能情况

在下图中，我们可以看到 Exchange 2013/2010 共存环境中外部 Exchange 2010 客户端的三个主要可选方案。

所有不同场景的共同点是 Exchange 2010 客户端的“旅程”从纽约站点面向公众的 Exchange CAS 服务器开始。

流程的其余部分取决于托管用户邮箱的 Exchange 2010 邮箱服务器的位置。

场景 1 - Exchange 2010 用户，其邮箱托管在纽约站点的 Exchange 2010 邮箱服务器上。

“面向纽约公众的 Exchange CAS 服务器”将通过以下方式处理外部 Exchange 2010： 将其请求代理到内部 Exchange CAS 2010。

方案 2 - Exchange 2010 用户，其邮箱托管在洛杉矶站点（非面向公众的 Exchange 站点）的 Exchange 2010 邮箱服务器上。

由于没有“直接连接”到洛杉矶站点的 Exchange 服务器的选项，来自纽约站点的面向公众的 Exchange CAS 服务器将接受 Exchange 2010 客户端请求并将请求转发（代理）到“最近的” Exchange 2010 CAS 服务器。 ”

在我们的场景中，“最近的 Exchange 2010 CAS 服务器”与 Exchange CAS 2013 服务器位于同一 Active Directory 中。

场景 3 - Exchange 2010 用户，其邮箱托管在马德里站点（面向公众的 Exchange 站点）的 Exchange 2010 邮箱服务器上。

乍一看，这种情况看起来有点奇怪，因为不清楚为什么“马德里 Exchange 2010 客户端”连接纽约站点面向公众的 Exchange 2013 CAS 服务器，而不是连接“他的马德里 Exchange CAS 服务器”。

答案是“面向纽约公众的 Exchange CAS”充当公共自动发现端点。

Exchange 客户端“不知道”他们的物理位置。该元素使他们能够访问自己的邮箱或向他们提供如何到达目的地的“说明”，这意味着可以为他们提供服务的面向公众的 Exchange CAS 服务器是“面向纽约公众的 Exchange CAS”。 ”

当“马德里外部 Exchange 客户端”将“面向纽约公众的 Exchange CAS”作为自动发现端点进行寻址时，“面向纽约公众的 Exchange CAS”会识别出用户邮箱托管在马德里站点上，并向他发送自动发现响应，其中包括马德里面向公众的 Exchange CAS 服务器的公共名称：europe.mail.o365info.com

2.内部 Exchange 2010 客户端的可能情况

在下表中，我们可以看到 Exchange 2013/2010 共存环境中内部 Exchange 2010 客户端的三个主要可选方案。

在下图中，我们可以看到可以在内部（非公共）Exchange 环境中实现的不同“内部客户端协议连接流”的表示。

场景 4 - Exchange 2010 用户，其邮箱托管在马德里站点的 Exchange 2010 邮箱服务器上。

此方案的章程是使用 Exchange 2010 旧基础结构且不包括 Exchange 2013 服务器的公司站点。

对于“马德里 Exchange 2010 客户端”，客户端协议连接流作为 Exchange 2013 基础结构和本地 Exchange 2010 基础结构的“组合”来实现。

• 自动发现服务将由 Exchange 2013 CAS（纽约总部站点的 Exchange 2013 CAS）提供。
• 马德里 Exchange 2010 邮件客户端（例如 Outlook、ActiveSync 和 OWA）将通过本地 Exchange 2010 CAS 访问其“Exchange 2010 邮箱”。
• Exchange 2010 客户端的 Web 服务（例如 Outlook）将由当地马德里 Exchange 2010 CAS 提供。

场景 5 - Exchange 2010 用户，其邮箱托管在纽约站点的 Exchange 2010 邮箱服务器上。

• 自动发现服务将由 Exchange 2013 CAS 提供。
• New York Exchange 2010 邮件客户端（例如 Outlook、ActiveSync 和 OWA）将通过本地 Exchange 2013 CAS 访问其“Exchange 2010 邮箱”，后者会将其请求代理到本地 Exchange CAS 2010。
• Exchange 2010 客户端（例如 Outlook）的 Web 服务将由当地的纽约 Exchange 2013 CAS 提供。

场景 6 - Exchange 2010 用户，其邮箱托管在马德里站点的 Exchange 2010 邮箱服务器上。
此场景看起来与“场景 4”相同，但主要区别在于 Exchange 2010 客户端物理位置位于纽约站点。

当 Exchange 2010 客户端连接纽约站点的 Exchange CAS 2013 服务器时，Exchange CAS 2013 服务器会识别出用户是 Exchange 2010 客户端，并且其 Exchange 2010 邮箱服务器位于马德里站点。

Exchange CAS 2013 服务器会将 Exchange 2010 客户端代理到“最近的 Exchange 2010 CAS”。在我们的场景中，位于纽约站点的 Exchange 2010 CAS 和“纽约 Exchange 2010 CAS”将把请求代理到“马德里 Exchange 2010 CAS”。 ”