七大自动发现流程场景 |第 25 部分#36

在下一篇文章中，我们将回顾不同环境中的七种主要常见自动发现流程。
该回顾是高级回顾，而不是处理所涉及的每个具体步骤和过程的详细检查。

目的 - 在当前系列文章的续篇（第 29 篇至第 34 篇）中，我们将通过使用不同的工具（例如 ExRCA、Outlook 连接测试等）深入了解自动发现流程的非常具体的细节。

在深入了解细节之前，重要的是我们能够“从上方查看”不同的自动发现流程及其主要特征。

自动发现流程的基本逻辑

自动发现机制包括三个主要部分：

1. 找到自动发现端点
2. 获取所需的自动发现信息
3. 使用自动发现信息

在本文中，我们涉及前两个部分：

1. 找到自动发现端点

2. 获取自动发现信息\数据。

自动发现流程基于自动发现客户端的能力。

• 找到潜在的自动发现端点。
• 解决这个潜在的自动发现端点。
• 完成自动发现过程中涉及的所有必需步骤，例如相互身份验证等。
• 从自动发现端点获取所需的自动发现信息。

自动发现是关于自动发现客户端（A 点）到达 B 点（自动发现端点）所需经过的“路径”。

当我们处理与自动发现相关的故障排除过程时，我们需要做的第一件事是 - 清楚地了解自动发现路径。

此外，我们需要知道自动发现路径中涉及的每个组件的“角色”是什么，并验证每个涉及的组件是否已使用所需设置正确配置。

只有知道了自动发现客户端应该“经过”的“自动发现路径”是什么，以及这个过程中涉及到哪些组件或节点，我们才能“查明”自动发现的具体原因。问题或启动自动发现流程中涉及的不同组件的消除过程。

自动发现流程涉及组件和章程。

在下面的部分中，我们将回顾“自动发现流程”的七个不同场景，并指出每个场景的具体章程。

场景一：Active Directory 环境 |单个 Exchange 本地服务器

具有 CAS 角色的 Exchange On-Premise 服务器自动在 On-Premise Active Directory 的 SCP 中注册（其他可选场景是我们使用不同的主机名在 Active Directory SCP 中注册 Exchange CAS 服务器的场景） ）。

需要查找自动发现端点（Exchange 服务器）的自动发现客户端使用 LDAP 查询寻址 Active Directory，并询问他在处理所需自动发现端点时需要使用的特定 URL（自动发现 URL 将“引导他”到内部 Exchange CAS 服务器）。

Active Directory“回答”自动发现客户端查询并向其发送所需的自动发现 URL 地址。

自动发现客户端使用获得的 URL 地址来寻址 Exchange CAS 服务器。

注意：从技术上讲，此方案还涉及一个附加组件，例如本地 DNS 服务器。

场景 2：Active Directory 环境 |多个 Exchange 本地服务器

此方案仍然与本地或专用组织网络中的自动发现过程相关。

根据客户端查询本地 Active Directory 并获取可用自动发现端点（本地 Exchange CAS 服务器）列表的能力查找所需自动发现端点的过程。

当 Active Directory 回复可用自动发现端点列表时，自动发现客户端将需要从列表中随机选择自动发现端点，或者使用描述为 - 站点亲和性的过程>.
术语“站点关联性”描述了一个过程，在该过程中，自动发现客户端会优先选择与他具有相同自动发现站点名称值的 Exchange 服务器。

场景 3：自动发现客户端 |外部网络访问

在以下场景中，外部邮件客户端需要访问其组织邮箱，并且为了获得所需的访问权限，他需要找到并连接面向公众的 Exchange CAS 服务器。

自动发现客户端无法使用 LDAP 查询，因为组织 Active Directory 服务器不会“暴露”给公共网络中的主机。

因此，自动发现客户端需要查询公共 DNS 服务器，寻找提供自动发现服务的可选主机（自动发现端点）。

基本假设是所需的 DNS 记录已在公共 DNS 服务器中创建并更新，该服务器可供位于公共网络上的客户端使用。

另一个显着的区别是需要为外部 Exchange 客户端提供服务的 Exchange 服务器的“公共可用性”。

Exchange 服务器需要配置公共名称、公共 IP 和公共证书。

组织防火墙或代理服务器需要配置所需的设置，以使外部客户端能够“访问”充当外部客户端自动发现端点的 Exchange 服务器。

场景 4：Exchange Online 基础架构 |仅云 |外部邮件客户端

这是一个典型的“Office 365 云”场景。

在此方案中，组织邮件基础结构不是“内部”或本地托管，而是基于 Office 365 订阅并使用 Exchange Online 基础结构作为邮件服务。

对“云邮件基础设施”的访问可以通过位于公共网络上的邮件客户端或位于私人\内部组织网络上的客户端来实现。

在下图中，我们可以看到邮件客户端自动发现流程的描述，该客户端位于公共网络中并查找位于“云中”（Exchange Online）的自动发现端点。

自动发现客户端将尝试通过寻址公共 DNS 服务器来查找有关自动发现端点的信息，并向他询问特定的自动发现主机名。
基本假设是将客户端指向“云自动发现”的所需 DNS 记录端点”已配置。

自动发现客户端获取必要的 IP（映射到云自动发现端点的 IP）后，该自动发现客户端将尝试连接云自动发现端点。

注意：所提供的图表简化了“真实流程”，只是为了让我们能够对自动发现流程逻辑有一个大致的了解。

实际上，该过程稍微复杂一些，因为在 Office 365 环境中，自动发现客户端将被重定向到其他自动发现端点，直到到达所需的目的地。

场景 5：Exchange Online 基础设施 |仅云 |内部邮件客户端

以下方案与上一方案类似，但有一个主要区别 - 邮件客户端（自动发现客户端）位于组织的网络内部，需要连接到其 Exchange Online 邮箱。

在我们的特定场景中，组织不使用 Exchange On-Premise 基础设施。

当用户的桌面配置为“加入域”并且用户（及其桌面）位于内部\专用网络时，自动发现客户端（例如 Outlook“程序”）将通过连接本地 On-使用 LDAP 查询的本地 Active Directory。

由于没有“Exchange On-Premise 基础结构”，因此 On-Premise Active Directory 中没有信息，并且 On-Premise Active Directory 无法向自动发现客户端提供“答案”。

在这种情况下，客户端将开始使用第二种自动发现方法，该方法基于查找自动发现端点 IP 地址的 DNS 查询（客户端“知道”自动发现端点的名称是什么）。

由于自动发现客户端位于内部\专用网络上，自动发现客户端将尝试连接到本地 DNS 服务器。

基本假设是“本地 DNS”服务器可以访问公共网络，并且他可以为自动发现客户端“获取”“云自动发现端点”所需的 IP 地址。

当内部自动发现客户端获得必要的IP地址时，他将尝试连接“云自动发现端点”。

场景6：内网客户端| Exchange 本地基础设施 |交换在线邮箱

更复杂的“云场景”是这样一种场景，其中

• 客户端有一个 Exchange Online 邮箱
• 邮件客户端位于内部\专用网络上
• 该组织使用 Exchange On-Premise 基础架构

在我们的场景中，位于内部组织网络上的邮件客户端不希望连接到“Exchange 本地邮箱”，而是希望连接到位于组织“外部”的 Exchange Online 邮箱。内部网络。

尽管“最终节点”位于组织网络之外，并且逻辑假设是自动发现客户端将直接访问“云自动发现端点”，但实际情况有所不同。

当用户的桌面配置为“加入域”并且用户（及其桌面）位于内部\专用网络时，自动发现客户端（例如 Outlook）或“编程”以通过连接本地 On 来开始搜索所需的自动发现端点- 使用 LDAP 查询的前提 Active Directory。

Active Directory“回答”自动发现客户端查询并向其发送所需的自动发现 URL 地址。

自动发现客户端使用获得的 URL 地址对 Exchange CAS 服务器进行寻址。
由于 Exchange 本地服务器不“负责”在云（Exchange Online 基础结构）中注册的域，因此 Exchange 本地服务器场所服务器回复否定响应。

自动发现客户端“理解”现在他需要使用额外的自动发现方法。

在这种情况下，客户端将开始使用第二种自动发现方法，该方法基于查找自动发现端点 IP 地址的 DNS 查询（客户端“知道”自动发现端点的名称是什么）。

由于自动发现客户端位于内部\专用网络，因此客户端将尝试连接到本地 DNS 服务器。

基本假设是“本地 DNS”服务器可以访问公共网络，并且可以为客户端“获取”“云自动发现端点”所需的 IP 地址。

当内部客户端获得所需的IP地址时，他将尝试连接“云自动发现端点”。

场景 7：混合配置

混合环境中的自动发现过程可以说是复杂的，因为自动发现客户端找到其“所需的自动发现端点”的“方式”。

在我们的场景中，组织的用户希望连接到他的邮箱，但他的邮箱迁移到“云”（Exchange Online）。

Exchange On-Premise 服务器将用户迁移的邮箱“视为”远程邮箱。

从技术上讲，Exchange On-Premise 是用户邮箱的“所有者”。当用户尝试连接到其物理上位于“云”中的邮箱 (Exchange Online) 时，Exchange On-Premise 可以合理地将收件人“重定向”到其云邮箱。
通过向收件人提供以下信息来实现重定向：他拥有的使用混合环境中使用的共享空间域名的其他电子邮件地址 - .mail.onmicrosoft.com

“混合环境”的概念基于一种逻辑结构，其中
“本地基础设施”充当 Exchange 客户端的焦点或“起点”。

如果用户邮箱位于 Exchange On-Premise 上，则自动发现过程（以及自动发现过程的所有其余部分）的实施方式与任何标准 Exchange On-Premise 客户端\服务器方案完全相同。

如果客户端邮箱位于“云”（Exchange Online）中，则自动发现过程非常不同。

自动发现客户端将通过寻址本地 Exchange On-Premise 服务器来启动该过程，但自动发现客户端将被“重定向”或“指向”其在云 (Exchange Online) 中的电子邮件地址，从那时起，自动发现客户端将流程的实现类似于“标准云自动发现流程”，其中自动发现客户端尝试定位并连接其“云自动发现端点”。

为了演示在混合环境中实现的“自动发现路径”，让我们使用以下场景。

• 本地本地 Active Directory 域名是 - o365info.local
• 公共组织域名是 - o365info.com
• Office 365 混合域名是 - mail.o365info.com
• 用户\收件人电子邮件地址 - [email protected]

Bob的邮箱位于“云”（Exchange Online）中。技术术语是“远程邮箱”。

Bob 的邮箱被“移动”到云邮件基础设施（Exchange Online）和 Exchange On-Premise 服务器，将 Bob 的邮箱称为“远程邮箱”。

“远程邮箱”对象作为Bob云邮箱的“指针”。

任务 - Bob 希望配置一个新的 Outlook 邮件配置文件，使他能够连接到他的“云”邮箱。

第 1 步 - Outlook 连接本地 Active Directory 并请求潜在自动发现端点（Exchange CAS 服务器）的列表。

第 2 步 - Active Directory 使用可用 Exchange 服务器（自动发现端点）列表进行“回复”。
在我们的示例中，Active Directory 向客户端提供以下 URL 地址：

https://ex01.o365info.local/Autodiscover/Autodiscover.xml
注意 - 从技术上讲，还有一个额外步骤，其中 Outlook 连接本地 DNS 服务器以查找主机的 IP 地址 - ex01.o365info.local

在我们的示例中，我们假设此步骤成功完成，并且 Outlook“知道”如何到达内部自动发现端点 (ex01.o365info.local)。

第 3 步 - 自动发现客户端 (Bob) 将尝试与 ex01.o365info.local Exchange CAS 服务器进行通信，假设这是“他的 Exchange CAS”服务器 ”。

第 4 步 - Exchange 本地服务器查找 Bob 的邮箱并“查看”该 Bob 的邮箱配置为“远程邮箱”。
Exchange 服务器查找存储在名为“远程邮箱”的收件人属性中的值-
路由电子邮件地址，并且“看到”Bob 的“云”（Exchange Online）电子邮件地址是 - Bob @o365info.mail.onmicrosoft.com

Exchange 服务器“通知”Bob 他应该使用“新电子邮件地址” - [email protected]

第 5 步 - Outlook 客户端访问本地 DNS 服务器并询问“远程自动发现端点”的 IP 地址。 Outlook 将首先尝试获取根域名的 IP 地址（在我们的示例中 o365info.mail.onmicrosoft.com），如果 DNS 不包含所需的 IP， Outlook 将尝试查找以下名称约定 Autodiscover.
（在我们的示例中 Autodiscover.o365info.mail。 onmicrosoft.com）。

第 6 步 - 本地 DNS 访问“他的资源”并为其自动发现客户端查找所需的 IP 地址。
（“映射”到呈现 Exchange 的自动发现端点的公共 IP 地址在线服务）。

第 7 步 - Outlook 将尝试检查“远程自动发现端点”是否使用端口 443 侦听或打开，如果答案为“是”，Outlook 将发送所需 Autodiscover.xml 文件的要求。

注意：此工作流程描述只是一个非常笼统的描述。实际上，“第一个云自动发现端点”只是一个逻辑“黑匣子”，它将通过 HTTP 重定向回复 Outlook 请求。

Outlook 客户端将尝试从“附加自动发现端点”请求 Autodiscover.xml，将再次重定向，直到到达“最终自动发现端点”。