交换CAS服务器|代理与重定向| 4#23

---

让我们从头开始 - Exchange CAS 服务器的唯一目的是什么？
答案是：向其客户端“传递”信息或特定服务（通过代理Exchange 客户端请求）到其他 Exchange 服务器），或者通过将 Exchange 客户端“指向”（重定向）到可以为其提供所需信息或服务的“元素”。

Exchange 2013 CAS 服务器不考虑“数据所有者”或“生成”或产生数据的元素。
因此，显而易见的问题是：谁是被视为“数据所有者”或元素的部分“生成”或“产生”数据？
简单的答案：在旧版 Exchange 环境（Exchange 2007 和 Exchange 2010）中，该元素可能是：

• Exchange 旧 CAS 服务器 (Exchange 2007/2010)
• Exchange 旧邮箱服务器 (Exchange 2007/2010)
• Exchange 2013 邮箱服务器

如果我们想简化 Exchange CAS 2013 服务器用途的定义，我们可以将 Exchange CAS 2013 服务器视为将“食物”（信息）带到顾客餐桌上的服务员。如果我们想更准确，在某些情况下，请他的顾客选择另一家餐厅（重定向）。

Exchange CAS 为其 Exchange 客户端提供服务的可用选项

为了完成“服务”客户端的任务，Exchange CAS 服务器有两种选择：

1. 代理 - 当 Exchange 2013 CAS 服务器联系“其他来源”（其他 Exchange 服务器）代表其 Exchange 客户端检索数据或信息时，我们将此过程描述为代理
2. 重定向 - 当 Exchange CAS 2013 服务器“通知”他的客户，他无法帮助他们，并且他需要将他们指向“其他 Exchange 服务器”时，我们将此过程描述为“重定向”

默认情况下，Exchange CAS 2013 服务器更喜欢使用“代理”选项，而不是“重定向”选项，因为代理进程对 Exchange 客户端是透明的。

实际上，代理过程可以被认为是一个复杂或复杂的过程，但是，从“Exchange客户端”的角度来看，这个过程是透明的。
Exchange客户端唯一需要知道的是他需要找到并联系 Exchange CAS 2013 服务器，仅此而已！
Exchange 客户端所需要做的就是 - 询问，Exchange CAS 2013 服务器将满足他的愿望！

Exchange CAS 2013 服务器 |决策表

Exchange CAS服务器有一个非常精确的“决策表”，他用它来选择最合适的“路由决策”。
“决策表”将帮助Exchange CAS服务器决定是否代理该服务器。 Exchange 客户端请求或发送重定向响应到 Exchange 客户端。

如果 Exchange 2013 CAS 决定代理 Exchange 客户端请求，他将需要规划特定流程的精确章程。

例如，如果 Exchange CAS 服务器决定代理 Exchange 客户端请求，他会将请求代理到哪个 Exchange 服务器。

Exchange 2013 CAS 将实施的客户端协议连接流取决于其运行的特定环境。

1. 本机 Exchange 2013 环境

在仅包含 Exchange CAS 2013 服务器和 Exchange 2013 邮箱服务器的本机 Exchange 2013 环境中，Exchange CAS 2013 服务器将所有内容代理到 Exchange 2013 邮箱服务器。Exchange CAS 2013 服务器将代理所有不同类型的 Exchange 2013 客户端“请求”：

• 需要访问其邮箱的 Exchange 2013 客户端。
• Exchange 2013 客户端请求自动发现信息。
• 用于 Exchange Web 服务的 Exchange 2013 客户端。

1. Exchange 2013 共存环境

在被描述为 Exchange 2013 共存环境的环境中，Exchange CAS 2013 服务器将根据具体情况使用混合“响应”：代理或重定向 Exchange 客户端请求。

Exchange 2013/2007共存环境

在 Exchange 2013/2007 共存环境中，Exchange CAS 2013 将实现以下方法：

Exchange 2007 clientOutlook + ActiveSync (mobile) client that request access to mailbox content.
The result: Exchange CAS 2013 server will proxy these requests to the Exchange 2007 CASOWA client that request access to mailbox content.
The result: Exchange CAS 2013 server will respond to a redirection command (silent redirection + SSO) that will “point” Exchange 2007 OWA clients to Exchange 2007 CAS.Autodiscover client that requests Autodiscover information.
The result: Exchange CAS 2013 server will proxy the requests to Exchange 2013 mailbox serverExchange 2007 web services client - the Exchange 2007 connects directly to Exchange CAS 2007 server

Exchange 2013/2010共存环境

在 Exchange 2013/2010 共存环境中，Exchange CAS 2013 将实现以下方法：

Exchange 2010 clientOutlook + ActiveSync (mobile) and OWA client that require access to mailbox content.
The result: Exchange CAS 2013 server will proxy these requests to the Exchange 2010 CASAutodiscover client that requests Autodiscover information.
The result: Exchange CAS 2013 server will proxy the requests to Exchange 2010 CASExchange 2010 web services client
The result: Exchange CAS 2013 server will proxy the requests to Exchange 2010 CAS

Exchange CAS 2013 服务器 |代理场景

术语代理的正式定义：在计算机网络中，代理服务器是一种服务器应用程序，充当请求资源的客户端和提供该资源的服务器之间的中介。

此定义描述了 Exchange CAS 服务器用于为其客户端提供服务的方式。

术语“代理”描述了一种操作，其中 Exchange CAS 服务器接受 Exchange 客户端请求，并“执行所需操作”以获取客户端所需的信息。

换句话说：Exchange CAS 服务器代表其客户端访问其他资源，获取必要的信息并为其客户端“交付回”此基础结构。

Exchange 客户端无法知道或无法“看到”幕后的内容，也不需要了解复杂的 Exchange 基础架构和逻辑。为客户端“努力工作”的元素是Exchange CAS服务器。

为了能够演示“代理过程”，让我们回顾几个可选场景：

场景 1：Exchange 2013 客户端需要访问其邮箱。

该场景的章程如下：

内部 Outlook 客户端是托管在 Exchange 2013 邮箱服务器上的邮箱，需要访问其邮箱内容。 Exchange 基础设施是“Native Exchange 2013”。

Exchange 2013用户访问邮箱的过程如下：

1. Exchange 2013 客户端连接 Exchange 2013 CAS 服务器。
2. CAS2013 将验证用户身份并执行 Active Directory 查找。
3. CAS2013判断：邮箱版本为2013+用户Exchange。邮箱服务器（和CAS2013服务器）位于同一AD站点上。
4. CAS2013 将 Exchange 客户端请求代理到 Exchange 2013 邮箱服务器。

注意：在这个场景中，在接下来的场景中，我只描述一半的流程 - “一半”描述 Exchange CAS 2013 服务器到“目的地”（Exchange 上的用户邮箱）的方向2013 邮箱服务器）。

场景 2：共存环境中的 Exchange 2013 |同一 Active Directory 站点中的旧版 Exchange CAS 服务器

当前方案和下一个方案描述了共存环境中的 Exchange CAS 2013。
在 Exchange 2013 共存环境中，旧版 Exchange 用户邮箱托管在“旧版 Exchange 基础结构”（Exchange 2007 邮箱服务器或 Exchange 2010 邮箱服务器）上。

该场景的章程如下：

内部 Exchange 2010 Outlook 客户端（作为 Exchange 2010 邮箱服务器上托管的邮箱的 Exchange 客户端）需要访问其邮箱。

注意：我们在 Exchange 2013/2010 共存环境中描述的过程与 Exchange 2013/2007 共存环境相同。

Exchange 2010客户端访问其邮箱的过程如下：

1. Exchange 2010 客户端连接 Exchange 2013 CAS 服务器。
2. CAS2013 将验证用户身份并执行 Active Directory 查找。
3. CAS2013确定：用户邮箱版本为2010+同一AD站点上有Exchange 2010 CAS服务器。
4. CAS2013 将“Exchange 2010 客户端”的请求代理到 Exchange 2010 CAS 服务器（图中的步骤2）。
5. Exchange 2010 CAS 服务器会将请求代理到 Exchange 2010 邮箱服务器（图中的步骤3）。

场景 3：共存环境中的 Exchange 2013 |同一 Active Directory 站点中的旧版 Exchange CAS 服务器 |不同 Active Directory 站点中的用户邮箱

在当前场景中，我们添加了额外的因素。
用户邮箱托管在旧版 Exchange 2010 基础结构中，但托管用户邮箱的 Exchange 2010 邮箱服务器位于不同的 Active Directory 站点（站点 2） 。

该场景的章程如下：

内部 Outlook 客户端是托管在马德里站点的 Exchange 2010 邮箱服务器上的邮箱，正在公司纽约站点中进行访问。 Outlook 客户端需要访问他的邮箱。

纽约站点包括以下 Exchange 服务器基础结构：一台包含 Exchange CAS 服务器 + Exchange 邮箱角色的 Exchange 2013 服务器、Exchange 2010 CAS 服务器和 Exchange 2010 邮箱服务器。

马德里站点包括以下 Exchange 服务器基础结构：Exchange 2010 CAS 服务器和 Exchange 2010 邮箱服务器。

Exchange 2010 用户访问邮箱的过程如下：

1. Exchange 2010 客户端连接 Exchange 2013 CAS 服务器。
2. CAS2013 将验证用户身份并执行 Active Directory 查找。

3. CAS2013 确定：

   • 用户邮箱版本为：2010
4. 本地站点包括本地 Exchange 2010 CAS
5. CAS2013 将 Exchange 2010 客户端请求代理到 Exchange 2010 CAS 服务器（图中的步骤2）。
6. CAS2010将进行服务发现。

7. CAS2010 确定：

   • 用户邮箱版本为：2010
8. 用户邮箱托管在不同 AD 站点（马德里站点）的 Exchange 2010 邮箱服务器上。
9. 来自纽约站点的 Exchange 2010 CAS 服务器会将请求代理（跨站点代理）到马德里站点的 Exchange 2010 CAS 服务器（图中的步骤 3）。
10. 来自马德里站点的 Exchange 2010 CAS 服务器会将请求代理到 Exchange 2010 邮箱服务器（图中的步骤4）。

注意：图表的标题出现在吉尼斯世界纪录的“宇宙中最长的文章标题！”部分下。 ”

场景 4：共存环境中的 Exchange 2013 |同一 Active Directory 站点中没有旧版 Exchange CAS 服务器 |不同 Active Directory 站点中的用户邮箱

此方案的主要特点是 Exchange 2010 所在的站点没有 Exchange 2010 旧基础结构。

该场景的章程如下：

内部 Outlook 客户端是托管在马德里站点的 Exchange 2010 邮箱服务器上的邮箱，正在公司纽约站点进行访问。
Outlook 客户端需要访问其邮箱。
纽约站点包括以下 Exchange 服务器基础结构：一台拥有 Exchange CAS 服务器 + Exchange 邮箱角色的 Exchange 2013 服务器

马德里站点包括以下 Exchange 服务器基础结构：Exchange 2010 CAS 服务器和 Exchange 2010 邮箱服务器。

Exchange 2010 用户访问邮箱的过程如下：

1. Exchange 2010 客户端连接 Exchange 2013 CAS 服务器。
2. CAS2013 将验证用户身份并执行 Active Directory 查找。
3. CAS2013确定：用户邮箱版本为2010+同一AD站点上没有Exchange 2010 CAS服务器。
4. CAS2013 将需要找到位于马德里站点（托管用户邮箱的 Exchange 2010 邮箱服务器的 Active Directory 站点）的 Exchange 2010 CAS 服务器。
5. CAS2013 代理（跨站点代理）将 Exchange 客户端请求发送到马德里站点的 Exchange 2010 CAS 服务器（图中的步骤2）。
6. 马德里站点的 Exchange 2010 CAS 服务器会将请求代理到 Exchange 2010 邮箱服务器（图中的步骤3）。

Exchange CAS 2013 服务器 |重定向场景

Exchange 环境中的重定向与代理的主题可能会非常令人困惑，原因如下：

1. 能够理解“重定向过程”与“代理过程”中发生的情况
2. 能够了解 Exchange CAS 服务器在哪种情况下使用重定向而不是代理选项。
3. 能够了解 Exchange CAS 服务器使用的不同“重定向类型”

那么，让我们开始吧。如果我们想在 Exchange 2013 共存环境中简化术语“重定向”的解释，我们可以说术语“重定向”描述了一种操作，其中 Exchange CAS 服务器无法向 Exchange 客户端提供特定信息或服务。相反，Exchange CAS 服务器将 Exchange 客户端指向（重定向）到可能提供所需服务的“其他 Exchange 服务器”。

“重定向”过程是通过向 Exchange 客户端提供不同的 URL 地址来实现的，其中包括“其他 Exchange 服务器”的主机名 (FQDN)。

Exchange CAS 服务器何时使用重定向选项？

Exchange CAS 2013 服务器将仅针对 Web 邮件客户端（OWA 客户端）且仅在以下两种特定情况下实施重定向选项，而不是“代理”选项：

1. Exchange 2013/2007 共存环境和 Exchange 2007 OWA 客户端
2. 多个面向公众的 Exchange 站点和区域命名空间

下图强调了 Exchange 2013 CAS 将针对不同类型的 Exchange 客户端实施的操作。

在 Outlook 或 ActiveSync（移动客户端）Exchange 2013 的场景中，CAS 将始终实现代理方法。

重定向过程仅在 Exchange 2007 OWA 客户端场景或多个 Exchange 站点和区域命名空间的场景中执行。

将为 Exchange 2007 OWA 客户端实现重定向过程，因为 Exchange CAS 2013 服务器不知道如何实现 Exchange 2007 OWA 客户端到 Exchange 2007 CAS 的代理过程。

Exchange CAS 2013 服务器将使用重定向选项的另一个场景是在包含非常具体的章程的特定场景中。

使用“重定向方法”的第二种选择是在具有以下章程的情况下实现的：

Exchange 公共基础结构，基于多个面向公众的 Exchange 站点的结构。
当来自 B 站点的外部 OWA 客户端对代表站点 A 的面向公众的 Exchange CAS 服务器进行寻址时，面向公众的 Exchange CAS 服务器将识别出用户“属于”
站点 B。

在这种情况下，站点 A 中面向公众的 Exchange CAS 服务器将向外部 OWA 客户端发送一条重定向消息，其中包括站点 B 中面向公众的 Exchange CAS 服务器的 URL 地址。

您可以在文章中阅读有关此 OWA 重定向和静默重定向 + SSO 方案的更多详细信息：Exchange 2013/2010 共存环境中的 OWA 客户端协议连接流 | 3/4

Exchange 重定向类型分类

在Exchange 2013共存环境中，当我们提到术语“Exchange CAS服务器重定向”时，更准确的术语是：静默重定向+SSO。

Exchange CAS 2013 实施的“静默重定向 + SSO”过程是先前不太复杂的 Exchange 重定向方法的演变。

Exchange 重定向过程的演变可以描述为三个“代”。

1.标准 Exchange CAS 服务器重定向

我将其描述为“标准 Exchange CAS 服务器重定向”的重定向类型是由早期版本的 Exchange 服务器以及 Exchange CAS 2013 版本 CU2 之前的 Exchange 2013 CAS 服务器实现的方法。

“标准Exchange CAS服务器重定向”可以描述为“被动方法”，因为提供“重定向”信息的Exchange CAS服务器除了向Exchange客户端提供数据之外，不做任何事情。换句话说，期望 Exchange 客户端将“重定向自己”。

一个简单的重定向过程的章程实现如下：

1. OWA 邮件客户端连接 Exchange CAS 服务器，请求访问其邮箱。
2. 用户将提供他的凭据（用户名+密码）。
3. Exchange CAS 服务器处理该请求并“理解”：他需要通知 OWA 邮件客户端他需要联系“其他 Exchange CAS 服务器”。 ”
4. Exchange CAS 服务器向 OWA 邮件客户端发送一条“通知消息”，其中包含目标 Exchange CAS 服务器的 URL 地址。
5. 用户需要单击通知消息中显示的链接。
6. 当 OWA 客户端到达目标 Exchange 服务器时，他将需要通过重新输入用户凭据来重新进行身份验证。

2.重定向方式：静默重定向。

这种类型的 Exchange 重定向（被描述为静默重定向）是比上一节中评论的“标准重定向”更“智能”的重定向类型。

静默重定向方法的优点是我们避免了“手动操作”，即用户需要使用鼠标双击重定向通知消息上出现的链接。

Exchange CAS 服务器不是“要求用户单击链接”，而是向客户端浏览器发送重定向消息。

该操作被描述为“无声”，因为重定向命令“在幕后发生”（无声地）。用户不知道重定向过程，但相反，他会注意到“短暂的闪烁”，并且他的浏览器将显示“目标 Exchange CAS 服务器的欢迎身份验证页面”。 ”

请注意，用户仍然需要在“目标 Exchange CAS 服务器”之前重新进行身份验证（重新输入其凭据）。 ”

3.静默重定向 + SSO（单点登录）

此方法是最先进且“复杂”的 Exchange CAS 服务器重定向过程。术语 SSO（单点登录）描述了一种用户不需要进行两次身份验证（提供两次用户凭据）的方法。

在标准重定向过程中，用户需要向他连接的“第一个 Exchange CAS 服务器”提供其凭据，并且在用户“重定向”到“目标 Exchange CAS 服务器”后，用户需要再次提供其凭据。

用户将需要再次提供其凭据，因为“目标 Exchange CAS 服务器”不知道用户必须向链中的“第一台 Exchange CAS 服务器”提供其凭据。

换句话说，静默重定向+单点登录（SSO）的过程是为了防止“双重登录体验”而创建的，以及OWA邮件客户端在以前版本的Exchange服务器中遇到的“第二登录页面”，它不支持静默重定向+单点登录（SSO）。

我们可以形容这种方法是“完全透明的”，因为Exchange OWA客户端不知道这个过程。用户“知道”的唯一一件事是成功访问了他的邮箱。

Exchange 2013 CAS 服务器何时实施重定向过程？

Exchange 环境中的重定向方案的描述，尤其是共存环境中的 Exchange 2013 中的重定向方案可能会非常混乱。

造成这种“混乱”的原因是因为Exchange 2013 CAS服务器会选择仅针对特定邮件客户端且仅在特定场景下实施重定向方法。

为了能够按逻辑顺序排列事物，让我们使用以下“角色”：

1. Exchange 2013 CAS 服务器将始终对 Exchange 2007 OWA 邮件客户端使用重定向方法。
2. Exchange 2013 CAS 服务器将在具有以下章程的方案中对“其他外部 OWA Exchange 客户端”使用重定向方法：其邮箱托管在站点 B 上的外部 OWA 客户端，并且站点 B 视为面向公众的 Exchange 站点。外部 OWA 客户端寻址面向公众的 Exchange CAS 服务器。在这种情况下，站点 A 的面向公众的 Exchange CAS 服务器将重定向到 OWA 邮件客户端“他的面向公众的 Exchange 站点”（站点 B）。

场景 1：Exchange 2013 与 Exchange 2007 共存 | Exchange 2007 OWA 邮件客户端

在 Exchange 2013/2007 共存环境中，Exchange CAS 服务器知道如何代理 Exchange 2007 客户端的请求，除了以下情况：“Exchange 2007 OWA 客户端。 ” Exchange 2013 CAS 服务器不知道如何代理 Exchange 2007 OWA 邮件客户端。

Exchange 2013 CAS 服务器可以用于“帮助”Exchange 2007 OWA 邮件客户端的唯一方法是将它们重定向到“旧版 Exchange 2007 基础结构”（到 Exchange 2007 CAS 服务器）。

重定向过程通过使用“代表”Exchange 2007 CAS 服务器的旧命名空间来实现。

Exchange 2013 CAS 服务器（自 CU2 起）应用的重定向方法是静默重定向 + SSO（单点登录）。

注意 - 我们需要使用旧的命名空间，因为“新的 Exchange 2013 基础设施”使用组织的主命名空间，并且需要“另一个命名空间”来引用 Exchange 2007 CAS。

您可以在 Exchange 2013 共存环境和 Exchange 旧基础结构一文中阅读有关主题旧命名空间的更多信息

Exchange 2007 OWA 客户端的重定向方法将针对内部和外部 Exchange 2007 OWA 客户端实施。

为了能够更好地理解 Exchange 2013 CAS 服务器与 Exchange 2007 OWA 邮件客户端执行的重定向过程，让我们使用以下场景：

场景 2：外部 2007 OWA 客户端 |用户邮箱位于纽约站点。

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

• Exchange 用户类型：Exchange 2007 客户端（邮箱托管在 Exchange 2007 邮箱服务器上的 Exchange 用户）。
• Exchange 邮箱服务器位置：托管用户邮箱的 Exchange 2007 邮箱服务器位于纽约站点。
• 纽约站点包括两个公共 Exchange CAS 服务器：Exchange 2013 CAS 和 Exchange 2007 CAS。

OWA协议连接流程，将实现如下：

1. 在“New York Exchange 2007 OWA 客户端”中，键入以下 URL 地址 https://mail.o365info.com/owaOWA 客户端使用的 URL 地址，包括 FQDN ： mail.o365info.com 指向纽约站点面向公众的 CAS2013 服务器（编号 1）。
2. 外部 OWA 客户端提供其用户凭据。

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

   • 用户邮箱版本为：2007
4. 本地站点包括面向公众的 Exchange 2007CAS 服务器
5. 面向公众的 Exchange 2007 CAS 服务器的 URL 地址是：https://legacy.mail.o365info.com/owa

6. Exchange CAS2013 将实施两种不同的程序：

   1. 启动静默重定向过程 - “面向公众的 Exchange 2013 纽约”将重定向命令发送到“外部 Exchange 2007 OWA 客户端浏览器”，其中包括“面向公众的 Exchange 2007 CAS 服务器”的 FQDN：legacy.mail.o365info.com（编号2）。
7. 启动 SSO 流程 - “纽约面向公众的 Exchange 2013”通过将 Exchange 2007 OWA 用户凭据转发（代理）到“面向公众的 Exchange 2007 CAS 服务器”（编号8 ）来实现 SSO 流程）。

“外部 Exchange 2007 OWA 邮件客户端浏览器”从 CAS2013 获取重定向命令，并启动与“面向公众的 Exchange 2007 CAS 服务器”（编号 3）的新 HTTPS 会话。

然后，面向公众的 Exchange 2007 CAS 服务器 (legacy.mail.o365info.com) 将促进请求并从 Exchange 2007 邮箱服务器（编号 5 ）。

Exchange 2007 邮箱服务器向 CAS2007（编号6）提供所需的用户邮箱内容。

CAS2007 将信息发送到“外部 Exchange 2007 OWA 客户端”（编号7）。

有关此方案的更详细描述，请参阅文章“Exchange 2013/2007 共存环境中的 OWA 客户端协议连接流”| 3/4

场景 3：外部 OWA 客户端 |多个面向公众的 Exchange CAS 服务器 |区域命名空间。

Exchange 2013 CAS 服务器与 Exchange 2010、2013 OWA 邮件客户端的关系不同于 Exchange 2013 CAS 服务器与 Exchange 2007 OWA 邮件客户端的关系。

Exchange 2013 CAS 服务器将使用代理方法为内部 Exchange 2010、2013 OWA 邮件客户端提供服务。例如：

• 当内部 Exchange 2010 OWA 邮件客户端联系 Exchange 2013 CAS 服务器，请求访问其邮箱时，Exchange 2013 CAS 服务器会将请求代理给 Exchange 2010 CAS。
• 当内部 Exchange 2013 OWA 邮件客户端联系 Exchange 2013 CAS 服务器，请求访问其邮箱时，Exchange 2013 CAS 服务器会将请求代理到 Exchange 2013 邮箱服务器。

为外部OWA邮件客户端提供服务

Exchange 2013 CAS 服务器为“外部”Exchange 2010、2013 OWA 邮件客户端实现的“逻辑”是不同的。

在基于单个面向公众的 Exchange 站点的场景中，当 Exchange 2013\2010 OWA 邮件客户端连接面向公众的 Exchange CAS 服务器时，Exchange CAS 服务器会将其请求代理到内部 Exchange 服务器（Exchange CAS 服务器或 Exchange 邮箱服务器） ）。

例外的情况是，Exchange 基础设施基于多个面向公众的 Exchange 站点，并且每个 Exchange 站点都由唯一或专用的命名空间“表示”（在我们的文章系列中，我们将此单个命名空间称为：“区域命名空间”） 。

在这种情况下，如果面向公众的 Exchange CAS 服务器识别出位于其他 Exchange 站点的外部 OWA 邮件客户端邮箱 + 该 Exchange 站点是面向公众的 Exchange 站点，则 Exchange CAS 服务器“选择”重定向外部 OWA 客户端请求而不是代理请求。

场景章程

为了能够更好地理解 Exchange 2013 CAS 服务器在多个面向公众的 Exchange 站点环境中实现的重定向过程，让我们使用以下场景：

• 该组织，公共域名为：o365info.com
• 该公司有两个面向公众的交换站点：纽约站点和欧洲站点（马德里站点）。
• 纽约站点中面向公众的 Exchange CAS 服务器使用名称空间发布： mail.o365info.com
• 欧洲站点中面向公众的 Exchange CAS 服务器使用名称空间发布：europe.mail.o365info.com

场景3：OWA客户端|用户邮箱位于马德里网站|区域命名空间 | 目标站点=面向公众

场景包机：一个外部的Exchange OWA客户端，需要访问他的邮箱。

• Exchange 用户邮箱托管在马德里站点上（Exchange 2013 邮箱服务器位于马德里站点）。
• “马德里交换站点”被视为： 面向公众的交换站点。
• 外部 OWA 用户使用主命名空间作为 Exchange 服务器的 URL 地址 (https://mail.o365info.com/owa)。
• “分配”给马德里站点的区域命名空间是： europe.mail.o365info.com

在当前场景中，“OWA 马德里用户”使用 URL 地址： https://mail.o365info.com/owa 访问他的邮箱。

OWA协议连接流程实现如下：

1. 马德里 Exchange OWA 客户端，输入以下 URL 地址：https://mail.o365info.com/owa
   FQDN：邮件。 o365info.com 指向“面向纽约公众的 Exchange CAS 服务器”（编号1）。
2. 外部 OWA 客户端提供其用户凭据。

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

   • 用户邮箱版本为：2013
4. 托管用户邮箱的 Exchange 2013 邮箱服务器位于马德里站点
5. 远程站点（马德里站点）是面向公众的 Exchange 站点
6. “面向马德里公众的 Exchange CAS 服务器”的“OWA 地址”为：https://europe.mail.o365info.com/owa

7. Exchange CAS2013 将实施两种不同的程序：

   1. 启动静默重定向过程 - “纽约面向公众的 Exchange 2013”向“马德里 Exchange OWA 客户端浏览器”发送重定向命令，其中包括“欧洲 Exchange 2013 面向公众的 Exchange CAS”的 FQDN：europe.mail.o365info.com（编号2）。
8. 启动 SSO 流程 - “纽约面向公众的 Exchange 2013”通过将 Exchange 2013 用户凭据转发（代理）到“欧洲 Exchange 2013 面向公众的 Exchange CAS”（编号8 ）来实施 SSO 流程）。

“Madrid Exchange 2007 OWA 邮件客户端浏览器”从 CAS2013 获取重定向命令，并与“Madrid Exchange 2007 面向公众的 Exchange CAS”（编号 3）启动新的 HTTPS 会话。

然后，马德里 Exchange 2007 面向公众的 Exchange CAS (europe.mail.o365info.com) 将促进请求并从 Exchange 2007 邮箱服务器（编号 5）。

马德里 Exchange 2007 邮箱服务器向马德里 CAS2013（编号6）提供所需的用户邮箱内容。

马德里 CAS2013 将信息发送到“外部 Exchange OWA 客户端”（编号7）。