Exchange 本地环境中的自动发现流程 |非Active Directory环境|第 1#3 部分 |第 26 部分#36

自动发现客户端在基于本地 Active Directory 的环境中与非 Active Directory 环境中使用不同的自动发现方法来定位自动发现端点。自动发现客户端验证其是否位于 Active Directory 环境中。如果他确定自己位于非 Active Directory 环境中，自动发现客户端将开始激活验证复杂的算法，该算法是为查找和连接所需的自动发现端点而创建的。

当前的文章和接下来的两篇文章致力于回顾在非 Active Directory 环境中实现的自动发现过程。

术语“非 Active Directory 环境”

术语“非 Active Directory 环境”描述以下场景之一：
1.未加入域的用户桌面。
2.不位于内部组织网络上的用户桌面。

当自动发现客户端认识到他在“非 Active Directory 环境”中运行时，自动发现客户端会“跳过”处理本地 Active Directory 的阶段，并开始执行自动发现过程，查找自动发现端点主机名，该主机名被视为电子邮件地址的派生词。

定位自动发现端点主机 | Active Directory 与无 Active Directory 环境

在我们详细了解在非 Active Directory 环境中实现的自动发现过程之前，了解在每个环境中执行的自动发现方法的显着差异非常重要。

在 Active Directory 环境中，自动发现客户端不知道自动发现端点的名称，而是将 Active Directory 关联为受信任的基础架构源，该基础架构可以为其提供可用自动发现端点（Exchange CAS 服务器）的“名称” 。

在非 Active Directory 环境中，“缺失的部分”是 Active Directory。

自动发现客户端需要使用另一种方法，而不是向 Active Directory 寻址以获取有关自动发现端点名称的信息。

自动发现客户端使用的自动发现方法基于以下流程：

1. 自动发现端点根据从收件人电子邮件地址获取的 SMTP 域“猜测”或“生成”潜在自动发现端点的 URL 地址。

2. 如果自动发现客户端设法找到“潜在自动发现端点”并与其通信，但“目标主机”无法向其提供所需信息，则自动发现客户端将请求重定向到另一个潜在自动发现端点。

注意：我们使用术语“潜在自动发现端点”，因为当自动发现客户端将特定主机寻址为“自动发现端点”时，他假定目标主机是自动发现端点。自动发现客户端无法确定目标主机确实是自动发现端点。

3. 如果“步骤 1”中的潜在自动发现端点无法提供所需的自动发现信息 + 无法提供到潜在自动发现端点的重定向，自动发现客户端将尝试查询 DNS 来查找 SRV 记录，其中包括潜在自动发现端点的主机名。

请注意在非 Active Directory 环境中；自动发现客户端可以被视为“盲客户端”，因为没有“正式信息源”可以向他提供潜在自动发现端点的特定主机名（如果我们想要更准确，则为 URL）。

自动发现客户端无法使用 Active Directory 自动发现方法的可能情况。

客户端无法使用基于 LDAP 查询和本地 Active Directory 的自动发现方法的四种可能情况是：

1.桌面未加入域
顾名思义，此场景可能与以下选项之一相关：

• 未配置为域成员（已加入域）的用户桌面
• 设置为域成员（已加入域）的用户桌面，但用户本地登录到其桌面，而不是“域配置文件”。

2.桌面已加入域，但没有与 Active Directory 通信的选项

例如，某个用户的笔记本被视为加入了域，但该组织用户正在家庭或公共网络中工作。

在这种情况下，尽管桌面已“加入域”，但与 Active Directory 的通信尝试将会失败，因为默认情况下，Active Directory 被视为受保护或内部资源，并且不会暴露给主机访问来自公共网络。

3.桌面已加入域；有一个与 Active Directory 通信的选项，但客户端查找的 SMTP 域不“属于”Exchange 本地服务器（Exchange 对特定域名没有权威）。

哇！！这是一个很长的场景标题名称！

这种情况的一个示例是用户想要使用收件人电子邮件地址创建新的 Outlook 邮件配置文件。

收件人电子邮件地址的 SMTP 域部分不“属于”组织域（Exchange 认为自己对其具有权威的域）。

在这种情况下，虽然域不是本地 Exchange 基础结构的一部分，但自动发现客户端将从 Active Directory 请求可用 Exchange CAS 服务器的列表，并尝试与列表中的每个 Exchange CAS 服务器进行通信，以查找所需的 Exchange CAS 服务器。自动发现信息。

只有在自动发现客户端耗尽所有可能的“内部自动发现端点”后，自动发现客户端才会“投降”并开始使用额外的自动发现方法。

4. Exchange 本地服务器不可用。

该场景的章程是：

• 用户桌面已加入域。
• 自动发现客户端设法查询本地 Active Directory 并获取潜在自动发现端点的列表。
• 自动发现客户端尝试与自动发现端点（Exchange CAS 服务器）进行通信，但 Exchange CAS 服务器不可用（未响应等）。

在这种情况下，自动发现客户端将“投降”并开始使用附加的自动发现方法。

失落宝藏之旅 - Autodiscover.xml 文件

为了简化自动发现过程的概念，我们使用以下比喻：

自动发现的过程与“寻找失落的宝藏”非常相似。

我们从某人那里听说了非常珍贵的宝藏。
我们非常想要这个宝藏，并且我们知道“某个地方”有人持有这个珍贵的宝藏。

我们所需要的只是一张“地图”，它可以引导我们找到拥有我们珍贵宝藏的人！

让我们回到“现实世界”，尝试理解每个虚构人物代表的过程。

1. “搜索者。 ”

“搜索者”可以是任何自动发现客户端。在我们的场景中，自动发现客户端是 Outlook，需要配置设置来创建新的 Outlook 邮件配置文件。

2.失落的宝藏 - 自动发现信息

“自动发现之旅”的攀登非常简单——找到自动发现信息（丢失的宝藏）。

3.来源。 ”

拥有我们宝贵财富的“元素”是 Exchange CAS 服务器，或者如果我们想使用正式术语 - 潜在的自动发现端点。

从技术上讲，我们使用术语“潜在”，因为实际上，当自动发现客户端寻址特定主机时，他不知道主机（潜在的自动发现端点）是否回复他的通信请求。如果主机响应，我们无法确定特定主机是“正确的”。

因此，我们使用“潜力”一词。自动发现客户端地址的主机有可能成为“正确的自动发现端点”，但同时，自动发现客户端需要知道如何处理主机不是“正确的自动发现端点”的情况。 ”

4.地图。 ”

在我们的故事中，“地图”应该引导我们找到拥有我们想要的宝藏的人。
在自动发现世界中，“地图”以网址 (URL) 的形式实现。

如果我们想更精确的话，客户端（Outlook）已经拥有了大部分地图，“地图”中唯一缺少的部分是自动发现端点的名称，它“保存”了信息（保留我们的宝贵财富）。

自动发现 URL（失落宝藏的地图）

继续我们的比喻，丢失宝藏的“地图”（地址），又名自动发现信息，是通过使用 URL 地址来实现的。

让我们看一下自动发现 URL 地址的结构，以便我们可以更好地了解自动发现客户端在非 Active Directory 环境中使用的自动发现方法。

自动发现URL地址，包括以下部分：

• 协议名称（HTTPS 或 HTTP）
• 自动发现端点的主机名
• 包含文件夹名称（自动发现）和所需文件名称（autodiscover.xml 或 autodiscover.svc）的路径

自动发现客户端知道他应该使用什么 URL 地址结构来寻址自动发现端点。

默认通信协议是 HTTPS（在重定向请求的情况下，另一个选项是 HTTP）。

请注意，自动发现客户端不知道自动发现端点的 FQDN 名称！

在下一节中，我们将了解自动发现客户端如何解决此问题，但需要强调的是，在非 Active Directory 环境中，自动发现客户端无法“提前”知道自动发现端点的主机名。

自动发现 URL 的默认路径基于以下命名约定。

自动发现服务的默认路径是：

/Autodiscover/autodiscover.xml

在下图中，我们可以看到“众所周知的自动发现URL地址”概念的呈现。

自动发现客户端“知道”自动发现 URL 地址的大部分“部分”。
唯一的“缺失部分”是自动发现端点的主机名。

伟大的谜团揭晓了！生成自动发现端点主机名

当自动发现客户端使用“Active Directory 自动发现方法”时，自动发现客户端信任或依赖 Active Directory 作为有关可用自动发现端点的信息源。

但是，如果自动发现客户端无法使用 Active Directory 作为“信息源”，那么自动发现客户端如何知道自动发现端点的名称是什么？是否有多个潜在的自动发现端点？

我很兴奋！

今天我们就来揭开这个全世界只有少数人知道的大秘密！

自动发现客户端用于“查找”自动发现端点主机名的方式可能不是“全世界只有少数人知道的大秘密！”然而，这仍然是一个令人兴奋的过程，我们中的一些人并不熟悉。

• 任务是 - 创建新的 Outlook 邮件配置文件。
• 代理人姓名是 - 鲍勃
• 位置 - Bob 位于公共网络上，因此他无法访问组织 Active Directory。
• 障碍 - 如何找到 Exchange CAS 服务器（自动发现端点），使 Bob 能够连接到他的邮箱 + 提供创建 Outlook Anywhere 邮件配置文件所需的所有信息。

自动发现客户端使用的秘密方法基于一个小技巧。
如前所述，自动发现端点的 URL 地址取决于预定义的命名约定。
对于需要找到其自动发现端点的自动发现客户端，唯一缺少的部分是自动发现端点的主机名。

自动发现客户端根据收件人的电子邮件地址使用的技巧。每个官方电子邮件地址都由两部分组成：

1. “左边部分”这是收件人别名或收件人姓名。
2. “左边部分”，该部分代表用户所属公司组织的域名或SMTP域名。

自动发现客户端知道如何通过“获取”SMTP 域名来使用电子邮件地址的“正确部分”，并且它是否用于“填补拼图中缺失的部分”。 ”

在我们的场景中，当 Bob 启动 Outlook 向导时，Bob 必须提供他的电子邮件地址 - [email protected]

自动发现客户端 (Outlook) 从电子邮件地址中获取域名，并将名称“放入自动发现 URL”中。

在我们的示例中，Outlook 将通过连接 DNS 服务器并询问名为 - o365info.com 的主机的 IP 地址来开始旅程

如果 DNS 服务器可以提供 IP 地址，Outlook（自动发现客户端）将把主机作为潜在的自动发现端点进行关联。

主要的 Outlook 假设是该主机 - o365info.com 是一个潜在的自动发现端点，意味着可以为其提供创建 Outlook Anywhere 邮件所需的自动发现信息的 Exchange CAS 服务器或元素轮廓。

大多数时候，自动发现与 SMTP 域名相关的方法是潜在自动发现端点的主机名，不会产生所需的结果，因为在现代环境中，“根域名”有效地映射到上市公司网站。

如今，我们可以“访问”大多数公共网站，而无需使用正式的命名约定，例如 - www.，而是仅使用域名。

假设在我们的场景中，Outlook 设法找到名为 - o365info.com 的主机的 IP 地址，但“此主机”不是所需的自动发现端点（Exchange CAS 服务器） ）但只是一个简单的网站。

在这种情况下，自动发现客户端使用新的命名约定，但这一次； Outlook 将尝试使用以下主机名来寻址自动发现端点 - autodiscover.o365info.com

主机名 - 自动发现 是一个保留的名称。

每个想要将自动发现客户端指向其自动发现端点的组织都需要在 DNS 区域中的域名下创建一条 A 记录，其中包括主机名 - 自动发现并映射到作为自动发现端点运行的 Exchange CAS 服务器的 IP 地址。

问：自动发现之旅就结束了吗？我们能假设这个故事有一个好的结局吗？

A：是和否

如果主机 - autodiscover.o365info.com 是“真正的交易”并且这是“正确的 Exchange CAS 服务器”，则这可能是自动发现之旅的结束启用 Outlook 连接到用户邮箱 + 提供构建新的 Outlook Anywhere 邮件配置文件所需的所有配置设置。

其他可能的情况是 Outlook 视为“潜在自动发现端点”的主机不是可以“结束进程”的主机。 ”
例如，有一个选项让 Outlook 找到名为 - autodiscover.o365info.com 的主机的 IP 地址，但该“主机”没有响应Outlook 发送的 HTTPS 请求。 （基于HTTPS协议的自动发现过程）。

在这种情况下，Outlook“理解”这不是他的自动发现之旅的“最后一站”。

如果自动发现端点没有响应 HTTPS 通信请求，自动发现客户端仍然“有些相信”主机仍然可以通过另一种方式帮助他。

HTTP 重定向

由于目的地主机不支持 HTTPS 通信，自动发现客户端“理解”这不是可以为其提供所需自动发现信息的元素。

Outlook 客户端不会“屈服”，而是会询问不支持 HTTPS 的主机，并询问他是否知道潜在的自动发现端点。

自动发现端点使用 HTTP 协议而不是 HTTPS 来寻址主机。

如果主机响应 HTTP 请求，自动发现客户端就会认为他可以请求帮助。

自动发现客户端将尝试从主机请求有关自动发现端点名称的信息。

那么……这就是结局了吗？

答案不是它！

如果自动发现客户端地址的主机不支持 HTTP 或无法提供潜在自动发现端点的名称，自动发现客户端将使用“最后一种方法，他带着他的麻袋”。 ”

这种自动发现方法基于名为 SRV 记录的特殊 DNS 记录。

DNS SRV 记录的独特性在于，此类记录使 DNS 客户端能够向 DNS 查询主机名，以便为需要知道主机名的 Outlook 提供特定服务。换句话说，当使用 SRV 查询查找特定服务时，DNS 会回复提供特定服务的主机名。

如果组织在 DNS 中发布包含可提供自动发现服务的 Exchange CAS 服务器（自动发现端点）的主机名的 SRV 记录，则自动发现客户端将使用该名称并将该主机作为潜在的自动发现端点进行关联。

注意：值得注意的是，Office 365 和 Exchange Online 环境不支持 SRV 自动发现方法。