当前位置:网站首页 > 更多 > 玩电脑 > 正文

[玩转系统] Office 365 环境中的自动发现流程 |第 2#3 部分 |第 30 部分#36

作者:精品下载站 日期:2024-12-14 08:51:39 浏览:13 分类:玩电脑

Office 365 环境中的自动发现流程 |第 2#3 部分 |第 30 部分#36


当前文章和下一篇文章将致力于详细回顾自动发现流程;通过使用 Microsoft 基于 Web 的工具 Microsoft 远程连接分析器 (ExRCA) 在基于 Office 365 的环境中实施。

基于 Office 365 的环境中的自动发现流程 |文章系列

  • Office 365 环境中的自动发现流程 |第 1#3 部分 |第 29 部分#36
  • Office 365 环境中的自动发现流程 |第 2#3 部分 |第 30 部分#36
  • Office 365 环境中的自动发现流程 |第 3 部分#3 |第 31 部分#36

Office 365 环境中的自动发现包括许多步骤。

我尝试将每个步骤分开,并得到了 20 个不同部分的结果。

数字“20”只是一个任意数字,因为“自动发现之旅”甚至可以深入到更多或更少的部分部分。

“部分”的数量取决于许多变量,但“自动发现之旅”的重要观察结果是:

  1. 自动发现过程是一个非常“聪明”、智能的机制,它能够在复杂复杂的环境中生存下来。
  2. 自动发现之旅有许多“移动部件”和许多可用路径。
  3. 自动发现过程的一部分包括“内置故障”。这种“失败”是正常的,也是意料之中的。重要的是“最终结果”的含义——自动发现客户端是否成功完成了自动发现旅程。

自动发现之旅

在接下来的部分中,我们将深入了解“自动发现引擎”,并观察 Office 365 和 Exchange Online 环境中自动发现过程中涉及的每个步骤和过程。

在开始之前,我们先定义一下该过程中涉及的因素。

1. 自动发现客户端

客户端是需要来自自动发现端点的所需信息的实体。自动发现客户端可以是 Outlook 等邮件客户端、移动设备(ActiveSync 客户端)等。

在本文中,自动发现客户端是 ExRCA(Microsoft Web 诊断工具)。

我们利用 ExRCA 的出色功能来显示非常详细的报告,以非常清晰和精确的方式描述自动发现过程中实施的步骤。

注意:虽然ExRCA提供了非常详细的信息,但ExRCA结果报告中并未提及一些“自动发现步骤”。例如,自动发现客户端向自动发现端点提供凭据的过程不会出现在 ExRCA 报告中。

在这种情况下,我添加了我的描述\解释,尽管我们在 ExRCA 报告中看不到此自动发现过程的“证据”。

2. 自动发现端点

术语“自动发现端点”涉及自动发现过程中涉及的每个节点或主机。
很快,我们将看到自动发现客户端将遇到几个“元素”。

(自动发现客户端的默认假设是这些“元素”中的每一个都是所需的自动发现端点(潜在的自动发现端点)。

实际上,只有最后一个节点才是“真相自动发现端点”。 Office 365 环境中参与自动发现过程的所有其余主机都充当“逻辑路由器”,将引导自动发现客户端并将其重定向到他的命运。

3. 旅程的目的

自动发现之旅的唯一目的非常简单 - 获取自动发现响应,其中包括新的 Outlook 邮件配置文件和有关现有 Exchange Web 服务的基础设施所需的配置设置。

Office 365 和 Exchange Online 环境中的自动发现漫长旅程

在接下来的部分中,我们将详细介绍 Office 365 环境中自动发现过程中包含的每个步骤的具体细节。

这段旅程相当漫长,我们需要有一些耐心,才能陪伴自动发现客户端走完这段旅程。

在我们深入了解细节之前,重要的是我们将能够看到“全局”或参与 Office 365 和 Exchange Online 环境中的自动发现之旅的主要节点。

在下图中,我们可以看到自动发现客户端在其旅程中必须经过许多节点,然后才能完成自动发现旅程并到达他的“最终目的地”(图中的数字4)图表)。

[玩转系统] Office 365 环境中的自动发现流程 |第 2#3 部分 |第 30 部分#36

场景描述

为了能够在“纯云环境”中演示自动发现过程,我们使用以下场景:

名为 o365info.com 的组织使用 Office 365 和 Exchange Online 作为其邮件基础设施。所有用户的邮箱都托管在 Exchange Online 基础结构中。

在我们的场景中,名为 Bob 的用户使用以下电子邮件地址 [email protected],需要创建新的 Outlook 邮件配置文件。

自动发现客户端将通过寻找名为 - o365info.com 的自动发现端点来开始其自动发现之旅。

自动发现端点使用此特定主机名,因为自动发现算法基于自动发现客户端从收件人电子邮件地址(o365info.com )。

[玩转系统] Office 365 环境中的自动发现流程 |第 2#3 部分 |第 30 部分#36

使用 Microsoft 远程连接分析器 - 前缀

为了能够说明自动发现的每个部分,我们将结合使用图表和 Microsoft 远程连接分析器结果的屏幕截图

在我们的场景中,我们希望查看邮箱托管在 Exchange Online 上的用户的自动发现过程。因此,我们将选择 Office 365 选项卡,然后;我们将选择测试选项 - Outlook 自动发现

[玩转系统] Office 365 环境中的自动发现流程 |第 2#3 部分 |第 30 部分#36

在下面的屏幕截图中,我们可以看到托管在 Exchange Online 上的 bob 邮箱的 Outlook 自动发现过程的结果。

在自动发现测试结果的“高级”视图中,我们可以清楚地看到在 Office 365 环境中实施的自动发现流程的“结构”。

(自动发现过程的实现方式与尝试访问 Exchange 本地基础结构的外部客户端的“标准自动发现过程”不同)。

前两个步骤,自动发现客户端尝试使用主机名访问“标准自动发现端点” - o365info.com
autodiscover.o365info.com 失败(屏幕截图中的数字 1 2)。

Office 365 环境中的“真正的自动发现过程”仅在由名为 autodiscover.o365info.com 的元素实现的 HTTP 重定向阶段(编号 屏幕截图中的 3)。

[玩转系统] Office 365 环境中的自动发现流程 |第 2#3 部分 |第 30 部分#36

当我们查看 Office 365 环境中实现的自动发现流程时,我们可以看到自动发现客户端将被重定向到名为 - Autodiscover-s.outlook.com (屏幕截图中的数字 4)。

[玩转系统] Office 365 环境中的自动发现流程 |第 2#3 部分 |第 30 部分#36

当自动发现客户端到达名为 -
Autodiscover-s.outlook.com 的 Office 365 元素时,他将再次重定向到其“最终目的地”Exchange Online CAS 服务器谁将邮件客户端“连接”到他的邮箱,向他提供所需的自动发现信息等。

[玩转系统] Office 365 环境中的自动发现流程 |第 2#3 部分 |第 30 部分#36

分析自动发现过程 |详细描述步骤

步骤1/20:尝试在DNS中解析主机名o365info.com

默认情况下,自动发现客户端将尝试使用从收件人电子邮件地址“提取”的主机名来定位“潜在自动发现端点”。
自动发现客户端将使用收件人电子邮件地址的“右侧部分”包含 SMTP 域名的邮件地址。
在我们的场景中,收件人电子邮件地址是 - [email protected]

基于该特定电子邮件地址;自动发现客户端将创建一个 DNS 查询,查找名为 - o365info.com 的主机的 IP 地址

DNS 服务器的“答案”取决于特定组织的公共服务器和服务基础设施。
例如,大多数组织都有一个公共网站,并且大多数时候公共域名是“映射”的到网站的公共IP。

在我们的场景中,DNS 服务器会回复所请求主机名的公共 IP 地址。 DNS 服务器提供的 IP 并不“属于”Exchange 服务器(自动发现端点),而是将此公共 IP 地址分配给标准 Web 服务器。

[玩转系统] Office 365 环境中的自动发现流程 |第 2#3 部分 |第 30 部分#36

步骤1/20:分析ExRCA连接测试的数据
在ExRCA结果页面上,我们可以看到以下信息:

ExRCA 测试结果以一条错误消息开头,表明与主机名 - o365info.com 的连接尝试失败。

尝试测试潜在的自动发现 URL https://o365info.com:443/Autodiscover/Autodiscover.xml
此潜在的自动发现 URL 测试失败。

(我们将在下一节中详细了解失败原因)

请注意,当我们查看自动发现客户端执行的自动发现流程的详细信息时,我们可以看到某些步骤已成功完成。

例如,自动发现客户端向 DNS 服务器请求主机 o365info.com 的 IP 地址的名称解析步骤已成功完成。

尝试在 DNS 中解析主机名 o365info.com。主机名解析成功。返回的IP地址:104.28.12.85、104.28.13.85

[玩转系统] Office 365 环境中的自动发现流程 |第 2#3 部分 |第 30 部分#36

步骤 2/20:测试主机 o365info.com 上的 TCP 端口 443,以确保其正在侦听并打开。

自动发现客户端使用在上一步中获得的 IP 地址来寻址潜在的自动发现端点。

自动发现客户端将尝试验证潜在的自动发现端点是否可以使用 HTTPS 协议(端口 443)进行通信。

在我们的场景中,HTTPS 通信测试失败,因为“目标主机”不支持 HTTPS 通信。

[玩转系统] Office 365 环境中的自动发现流程 |第 2#3 部分 |第 30 部分#36

步骤 2/20:分析 ExRCA 连接测试的数据

在 ExRCA 结果页面中,我们可以看到以下有关自动发现客户端尝试验证目标主机的过程的信息
(o365info.com ) 可以使用以下方式进行通信TCP端口443

指定的端口被阻止、未侦听或未产生预期响应。与远程主机通信时发生网络错误。

[玩转系统] Office 365 环境中的自动发现流程 |第 2#3 部分 |第 30 部分#36

步骤 3/20:尝试在 DNS 中解析主机名 autodiscover.o365info.com

由于使用主机名 o365info.com 使用 HTTPS 与潜在自动发现端点的通信尝试失败,自动发现客户端将传递到下一个方法,在该方法中自动发现客户端将查找使用以下命名方案的潜在自动发现端点 - 自动发现 +

在我们的场景中,收件人电子邮件地址是 - [email protected]
基于此特定电子邮件地址;自动发现客户端将创建一个 DNS 查询,查找名为 - autodiscover.o365info.com 的主机的 IP 地址

DNS 服务器回复包括自动发现客户端可以选择的 IP 地址范围。

在我们的场景中,公共 DNS 包括所需的 CNAME 记录,该记录将自动发现客户端查询“重定向”到映射到主机名的 IP 地址范围 - Autodiscover.outlook.com

在我们的场景中,DNS 提供以下 IP 地址范围 - 157.56.236.89、157.56.232.9、157.56.234.137、157.56.244.217。
(“Office 365 实体”命名为 - autodiscover.outlook.com,充当“逻辑路由器”,将客户端重定向到自动发现旅程中的“下一跳”)。

[玩转系统] Office 365 环境中的自动发现流程 |第 2#3 部分 |第 30 部分#36

步骤 3/20:分析 ExRCA 连接测试的数据

在 ExRCA 结果页面中,我们可以看到以下有关尝试解析主机名 autodiscover.o365info.com 的信息

主机名解析成功。返回的IP地址:157.56.236.89、157.56.234.137、157.56.232.9、157.56.244.217

[玩转系统] Office 365 环境中的自动发现流程 |第 2#3 部分 |第 30 部分#36

步骤 4/20:测试主机 autodiscover.o365info.com 上的 TCP 端口 443,以确保其正在监听并打开。

自动发现客户端寻址潜在的自动发现端点,并尝试验证潜在的自动发现端点是否在端口 443 (HTTPS) 上列出。

在我们的场景中,HTTPS 通信测试失败。

尽管失败的结果显示为“问题”,但在 Office 365 环境中,这是预期结果。

在我们的场景中,自动发现客户端“认为”他正在与名为 - autodiscover.o365info.com 的主机进行通信,并且该主机应该能够通过呈现来启动 HTTPS 会话他的公开证书。

实际上,自动发现客户端地址是 autodiscover.outlook.com 的主机,它是为了充当逻辑路由器而创建的,它将把自动发现客户端重定向到下一跳。

此“Office 365 组件”(autodiscover.outlook.com) 的目的只是向自动发现客户端发送“路由消息”。

自动发现客户端被“编程”为使用 HTTP 重定向请求,以防潜在自动发现端点无法使用 HTTPS 进行通信。

在我们的示例中,由于潜在自动发现端点无法使用 HTTPS 进行通信,因此自动发现客户端将“退缩”并尝试使用 HTTP 协议与自动发现端点进行通信,尝试向自动发现端点请求包含“地址”的重定向。其他自动发现端点”。

[玩转系统] Office 365 环境中的自动发现流程 |第 2#3 部分 |第 30 部分#36

步骤 4/20:分析 ExRCA 连接测试的数据

在 ExRCA 结果页面中,我们可以看到与“目标 Autodiscover Endpoint”(autodiscover.outlook.com)的 HTTPS 通信测试失败。

正在主机 autodiscover.o365info.com 上测试 TCP 端口 443,以确保其正在监听并打开。指定的端口被阻止、未侦听或未产生预期响应。与远程主机通信时发生网络错误。

[玩转系统] Office 365 环境中的自动发现流程 |第 2#3 部分 |第 30 部分#36

步骤 5/20:尝试使用 HTTP 重定向方法联系自动发现服务。

由于目标主机未响应 HTTPS 通信请求,自动发现客户端会尝试其他自动发现查询方法,描述为 -
HTTP 重定向请求

目标主机的自动发现客户端检查列出为通过 HTTP(端口 80)进行通信。
在我们的场景中,目标主机响应 HTTP 通信请求。

来自目标主机的“肯定”响应是“告诉”自动发现客户端,这可能是一个可以通过提供充当自动发现端点的附加主机的名称来帮助他的元素。

在下一步中,我们将了解自动发现客户端如何发送 HTTP 查询,其中包括对可提供所需自动发现服务的“备用主机名和 URL”的请求。

[玩转系统] Office 365 环境中的自动发现流程 |第 2#3 部分 |第 30 部分#36

步骤 5/20:分析 ExRCA 连接测试的数据

在 ExRCA 结果页面中,我们可以看到以下有关尝试使用 HTTP 重定向方法联系自动发现服务的信息:
已成功使用 HTTP 联系自动发现服务重定向方法。

[玩转系统] Office 365 环境中的自动发现流程 |第 2#3 部分 |第 30 部分#36

步骤 6/20:检查主机 autodiscover.o365info.com 是否有到自动发现服务的 HTTP 重定向。

如前所述,主机 - autodiscover.outlook.com 充当“逻辑路由器”,将 Office 365 环境中的自动发现客户端重定向到自动发现中的“下一跃”流动。

自动发现客户端发送 HTTP 重定向请求,自动发现端点 (autodiscover.outlook.com) 进行响应并应答,其中包含“目标主机”的自动发现 URL。

在我们的场景中,HTTP 重定向响应包含以下 URL 地址 - https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml

[玩转系统] Office 365 环境中的自动发现流程 |第 2#3 部分 |第 30 部分#36

步骤 6/20:分析 ExRCA 连接测试的数据

在ExRCA结果页面上,我们可以看到以下信息

已成功接收重定向(HTTP 301/302)响应。重定向网址:https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml

[玩转系统] Office 365 环境中的自动发现流程 |第 2#3 部分 |第 30 部分#36

我们将在下一篇文章中继续回顾基于 Office 365 的环境中的自动发现流程 - Office 365 环境中的自动发现流程 |第 3 部分#3 |第 31 部分#36

您需要 登录账户 后才能发表评论

取消回复欢迎 发表评论:

关灯