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

[玩转系统] Exchange 混合环境中的自动发现流程 |第 2#3 部分 |第 33 部分#36

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

Exchange 混合环境中的自动发现流程 |第 2#3 部分 |第 33 部分#36


本文和下一篇文章将专门详细介绍通过使用 Microsoft 基于 Web 的工具 Microsoft 远程连接分析器 (ExRCA) 在 Exchange 混合环境中实现的自动发现流程。

Exchange 混合环境中的自动发现流程 |文章系列

当前文章是三篇文章系列中的第二篇文章。
该系列中的其他文章是:

  • Exchange 混合环境中的自动发现流程 |第 1#3 部分 |第 32 部分#36
  • Exchange 混合环境中的自动发现流程 |第 3 部分#3 |第 34 部分#36

混合环境中的用户的邮箱正在迁移到云,获得一个新桌面,双击 Outlook 图标,Outlook 咳嗽并颤抖,几秒钟后,用户连接到他的邮箱。

听起来很简单,不是吗?

事实上,这个“简单的过程”是用户创建一个新的 Outlook 邮件配置文件并自动连接到他的“云邮箱”,基于一个非常智能和复杂的自动发现过程。

将 Exchange 混合自动发现流程描述为“复杂”的原因是,对于其邮箱托管在 Exchange Online 基础结构上的 Exchange 收件人来说,Exchange 混合环境中的自动发现流程实施了两次:

第一次使用 Exchange 本地基础结构,第二次在 Exchange 客户端收到重定向消息后,自动发现流程针对 Exchange Online 基础结构执行。

Exchange 混合环境中自动发现之旅的魔力

在当前文章和下一篇文章(Exchange 混合环境中的自动发现流程 | 第 3#3 部分 | 第 34#36 部分)中,我们将详细回顾混合环境中的自动发现过程中包含的每个步骤。

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

数字“30”只是一个任意数字,因为“自动发现旅程”可以是甚至潜入更多或更少的部分。 “零件”的数量取决于许多变量。

因此,如果您有所需的勇气,请加入我们在 Exchange 混合环境中恢复自动发现流程的漫长而迷人的旅程!

这是你最后的机会。此后,就没有回头路了。你服下蓝色药丸——故事结束;你在床上醒来,相信你想相信的一切。你服下红色药丸——你就留在仙境里,我会告诉你兔子洞有多深。请记住:我提供的只是事实,仅此而已。

引自矩阵部分 1#3

场景描述

为了能够在混合环境中演示自动发现过程,我们将使用以下场景:

名为 o365info.com 的组织使用混合 Exchange 配置,其中包括 Exchange 本地邮箱和云(Exchange Online)邮箱的混合。

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

Alice的邮箱迁移到云端(Exchange Online)。

[玩转系统] Exchange 混合环境中的自动发现流程 |第 2#3 部分 |第 33 部分#36

混合环境中的自动发现漫长旅程

在混合环境中,本地 Exchange 继续充当自动发现服务的“焦点”。

尽管 Alice 邮箱物理存储在 Exchange Online 中,但自动发现过程将从 Exchange On-Premise 环境开始。

Exchange 客户端(在我们的场景中为 Alice)将尝试连接其 Exchange On-Premise 服务器,如果用户邮箱位于“云中”,则 Exchange On-Premise 是将邮件客户端重定向到他的“云邮箱”,向他提供他的“云电子邮件地址”。

在我们深入了解细节之前,重要的是我们能够看到混合环境中自动发现旅程中出现的“大局”或主要节点。

在下图中,我们可以看到自动发现客户端在其自动发现旅程中需要经过许多节点,直到到达最终目的地,即自动发现端点,该端点将为他提供所需的自动发现信息。

[玩转系统] Exchange 混合环境中的自动发现流程 |第 2#3 部分 |第 33 部分#36

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

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

在我们的场景中,我们将使用名为 - Microsoft Office Outlook 连接测试 的 ExRCA 测试,并选择 Outlook 自动发现 > 测试。

1.交易所“环境”|本地交换

在我们的场景中,我们检查收件人的自动发现流,该收件人的邮箱托管在 Exchange Online 基础结构上。

从理论上讲,我们应该选择 ExRCA“Office 365 选项卡”,因为收件人邮箱实际上位于 Exchange Online 基础设施中。

在 Exchange 混合环境中,本地 Exchange 充当“自动发现焦点”。自动发现流程应首先对 Exchange 本地服务器进行寻址,并根据将提供给自动发现客户端的“重定向消息”,通过对 Exchange Online 基础结构进行寻址来继续自动发现流程。

因此,我们将选择 Exchange Server 选项卡。

[玩转系统] Exchange 混合环境中的自动发现流程 |第 2#3 部分 |第 33 部分#36

2.登录凭据

在我们想要测试自动发现过程的场景中,对于 Exchange Online 中托管的用户邮箱,我们将必须使用 UPN(用户主体名称)命名约定。尽管该过程从 Exchange On-Premise 开始,它允许使用标准 Active Directory 登录命名约定,例如 - o365info\Alice

原因是——在第一个自动发现阶段;用户在 Exchange On-Premise 之前标识自己的身份,但在接下来的步骤中,自动发现客户端将需要向使用 Office 365 UPN 命名约定的 Exchange Online 服务器标识自己的身份,例如 - Alice @o365info.com

[玩转系统] Exchange 混合环境中的自动发现流程 |第 2#3 部分 |第 33 部分#36

3.两种不同的 Exchange 基础设施

在我们深入探讨在 Exchange 混合环境中实施的特定自动发现步骤之前,让我们从最后开始,查看已完成的 ExRCA 测试示例。

在下面的屏幕截图中,我们可以看到自动发现测试已成功完成。

摘要报告显示有关两个不同 Exchange 环境的信息:

  • Exchange 本地环境
  • 交换在线环境

[玩转系统] Exchange 混合环境中的自动发现流程 |第 2#3 部分 |第 33 部分#36

使用 Microsoft 远程连接分析器 - 详细说明

在下一节和下一篇文章中,我们将详细回顾在 Exchange 混合环境中的自动发现流中实施的“30 个步骤”中的每一个步骤。

步骤1/30:尝试解析主机名o365info.com

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

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

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

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

[玩转系统] Exchange 混合环境中的自动发现流程 |第 2#3 部分 |第 33 部分#36

步骤 1/30:分析 ExRCA 连接测试的数据

在Microsoft Remote Connectivity Analyzer结果页面中,我们可以看到以下信息:

DNS 名称解析步骤(自动发现向 DNS 服务器查询主机的 IP 地址 - o365info.com)已成功完成。

DNS 服务器回复公共 IP 地址列表。

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

[玩转系统] Exchange 混合环境中的自动发现流程 |第 2#3 部分 |第 33 部分#36

步骤2/30:测试主机o365info.com上的TCP端口443

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

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

在我们的场景中,HTTPS 通信测试成功。 “服务器”批准他可以使用 HTTPS 进行通信。

只是一个快速提醒

  • 情况 1 - “目标主机”支持 HTTPS 协议,并不一定意味着该主机是可以提供所需自动发现服务的 Exchange 服务器。
  • 情况2 - 即使“目标主机”支持HTTPS协议+“目标主机”是有效的Exchange服务器;这并不意味着他可以向自动发现客户端提供自动发现信息。

[玩转系统] Exchange 混合环境中的自动发现流程 |第 2#3 部分 |第 33 部分#36

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

在Microsoft Remote Connectivity Analyzer结果页面中,我们可以看到以下信息:

自动发现客户端尝试验证“目标主机”是否支持 HTTPS 协议,答案为“是”。

测试主机 o365info.com 上的 TCP 端口 443,以确保其正在监听并打开。端口打开成功。

[玩转系统] Exchange 混合环境中的自动发现流程 |第 2#3 部分 |第 33 部分#36

步骤3/30:尝试从远程服务器o365info.com获取SSL证书

自动发现客户端和自动发现端点之间的自动发现“关系”建立在“信任概念”之上。

在第一阶段,自动发现客户端需要信任自动发现端点,在第二阶段,自动发现端点还需要“信任”自动发现客户端。

“信任”始于自动发现端点需要证明其身份的步骤。

为了能够验证自动发现端点身份,自动发现客户端将要求自动发现端点向其发送公共证书。

[玩转系统] Exchange 混合环境中的自动发现流程 |第 2#3 部分 |第 33 部分#36

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

在Microsoft Remote Connectivity Analyzer结果页面中,我们可以看到以下信息:

  • 自动发现客户端请求自动发现端点向其发送证书。
  • 自动发现端点发送他的证书。
  • 自动发现客户端已成功接受证书。

Microsoft 连接分析器正在尝试从端口 443 上的远程服务器 o365info.com 获取 SSL 证书。
Microsoft 连接分析器已成功获取远程 SSL 证书。

额外细节

在下一节中,我们可以看到发送到自动发现客户端的服务器公共证书的内容。

远程证书主题:CN=ssl2000.cloudflare.com、O=“CloudFlare, Inc.”、L=旧金山、S=CA、C=US、颁发者:CN=GlobalSign 组织验证 CA - G2、O= GlobalSign nv-sa,C=BE。

[玩转系统] Exchange 混合环境中的自动发现流程 |第 2#3 部分 |第 33 部分#36

步骤 4/30:测试 o365info.com SSL 证书以确保其有效。

自动发现客户端需要实施三种不同的验证测试,才能“批准”服务器证书。
(如果三种不同的测试之一失败,则证书将不会被视为有效)。

第一个测试,现实的——“主机名”。自动发现客户端将检查证书是否包含自动发现端点的主机名。
在我们的场景中,自动发现客户端将尝试查找主机名 - o365info.com

在我们的示例中,结果是“失败”,因为服务器提供的证书不包含主机名 - o365info.com

[玩转系统] Exchange 混合环境中的自动发现流程 |第 2#3 部分 |第 33 部分#36

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

在Microsoft远程连接分析器结果页面中,我们可以看到有关服务器证书不包含所需主机名的信息。

主机名 o365info.com 与服务器证书 CN=ssl2000.cloudflare.com、O=”CloudFlare, Inc.”、L=旧金山、S=CA、C=US 上找到的任何名称都不匹配。

[玩转系统] Exchange 混合环境中的自动发现流程 |第 2#3 部分 |第 33 部分#36

步骤 5/30:尝试解析主机名 autodiscover.o365info.com

由于使用主机名与潜在自动发现端点的通信尝试失败,因此自动发现客户端将传递到下一个方法,其中自动发现客户端将使用以下命名方案查找潜在的自动发现端点 - 自动发现 +
在我们的场景中,收件人电子邮件地址是 - [email protected]
基于该特定电子邮件地址;自动发现客户端将创建一个 DNS 查询,查找名为 - o365info.com 的主机的 IP 地址

在我们的场景中,主机名 autodiscover.o365info.com 被映射到 Exchange 本地服务器。

注意:不要忘记,在混合环境中,即使收件人邮箱托管在 Exchange Online 上,焦点也是 Exchange 本地基础结构。
自动发现客户端将通过寻址 Exchange 来启动自动发现流程
On-Premise 在稍后阶段将被“重定向”到他的“云邮件基础设施”(Exchange Online)。

[玩转系统] Exchange 混合环境中的自动发现流程 |第 2#3 部分 |第 33 部分#36

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

在Microsoft Remote Connectivity Analyzer结果页面中,我们可以看到以下信息:

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

[玩转系统] Exchange 混合环境中的自动发现流程 |第 2#3 部分 |第 33 部分#36

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

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

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

在我们的场景中,HTTPS 通信测试成功。 “服务器”批准他可以使用 HTTPS 进行通信。

[玩转系统] Exchange 混合环境中的自动发现流程 |第 2#3 部分 |第 33 部分#36

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

在Microsoft Remote Connectivity Analyzer结果页面中,我们可以看到以下信息:

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

[玩转系统] Exchange 混合环境中的自动发现流程 |第 2#3 部分 |第 33 部分#36

步骤7/30:尝试从远程服务器autodiscover.o365info.com获取SSL证书

为了能够验证自动发现端点身份,自动发现客户端将要求自动发现端点向其发送公共证书。

[玩转系统] Exchange 混合环境中的自动发现流程 |第 2#3 部分 |第 33 部分#36

步骤 7/30:分析 ExRCA 连接测试的数据

在Microsoft Remote Connectivity Analyzer结果页面中,我们可以看到以下信息:

  • 自动发现客户端请求自动发现端点向其发送证书。
  • 自动发现端点发送他的证书。
  • 自动发现客户端已成功接受证书。

Microsoft 连接分析器正在尝试从端口 443 上的远程服务器 autodiscover.o365info.com 获取 SSL 证书。
Microsoft 连接分析器已成功获取远程 SSL 证书。

在下一节中,我们可以看到发送到自动发现客户端的服务器公共证书的内容。

远程证书主题:CN=mail.o365info.com、OU=域控制验证、O=mail.o365info.com、颁发者:SERIALNUMBER=07969287、CN=Go Daddy 安全证书颁发机构、OU=http://certificates .godaddy.com/repository,O=”GoDaddy.com, Inc.”,L=斯科茨代尔,S=亚利桑那州,C=美国。

在我们的场景中,我们可以看到服务器证书是由 GoDaddy.com 提供的

[玩转系统] Exchange 混合环境中的自动发现流程 |第 2#3 部分 |第 33 部分#36

步骤 8/30:测试 autodiscover.o365info.com SSL 证书以确保其有效。

自动发现客户端执行的证书验证测试包括三个不同的部分。

1. 验证证书名称
自动发现客户端,使用主机名寻址潜在的自动发现端点 - autodiscover.o365info.com

为了能够知道这是有效或可靠的信息源,自动发现客户端将检查证书是否包含指定的主机名 -
autodiscover.o365info.com 或通配符证书场景中的域名 - *.o365info.com

2. 验证证书信任
服务器提供的公共证书是由 CA(证书颁发机构)提供的。自动发现客户端还需要验证向服务器(自动发现端点)提供其证书的 CA 证书。

3. 验证证书日期是否有效。
自动发现客户端需要验证服务器证书日期是否有效。

如果您想阅读有关自动发现、安全机制和证书主题的更多详细信息,请阅读文章:自动发现过程和 Exchange 安全基础结构 |第 20 部分#36

[玩转系统] Exchange 混合环境中的自动发现流程 |第 2#3 部分 |第 33 部分#36

步骤 8/30:分析 ExRCA 连接测试的数据

在Microsoft Remote Connectivity Analyzer结果页面中,我们可以看到以下信息:

1. 验证证书名称
自动发现客户端,验证服务器证书是否包含服务器 FQDN 或服务器域名。

正在验证证书名称。证书名称已成功验证。在证书使用者备用名称条目中找到主机名 autodiscover.o365info.com。

[玩转系统] Exchange 混合环境中的自动发现流程 |第 2#3 部分 |第 33 部分#36

2. 验证证书信任

  • 自动发现客户端验证服务器证书中显示的信任链。
  • 自动发现客户端成功地验证了信任链。

Microsoft 连接分析器正在尝试为证书 CN=mail.o365info.com、OU=Domain Control Validated、O=mail.o365info.com 构建证书链。一条或多条证书链构建成功。

[玩转系统] Exchange 混合环境中的自动发现流程 |第 2#3 部分 |第 33 部分#36

3. 验证证书日期是否有效。

自动发现客户端验证服务器证书是否仍然有效且未过期。
在我们的示例中,测试成功完成意味着服务器证书有效。

日期验证已通过。证书还没有过期。证书有效。 NotBefore=1/26/2013 11:22:11 PM,NotAfter=1/26/2015 11:22:11 PM

[玩转系统] Exchange 混合环境中的自动发现流程 |第 2#3 部分 |第 33 部分#36

步骤 9/30:检查客户端证书身份验证的 IIS 配置

自动发现客户端和自动发现端点之间的“信任通道”建立在各方证明其身份的能力之上。

在上一节中,自动发现客户端成功验证了服务器的身份。
现在,我们进入第二部分,其中自动发现客户端需要向服务器证明其身份,以获取所需的自动发现信息。

自动发现客户端,验证目标主机(自动发现端点)是否需要客户端证书。 (客户端证书是客户端证明其身份的一种方法)。

客户端证书的使用非常罕见,大多数时候,客户端用于“证明其身份”的方式是提供用户的凭据。

[玩转系统] Exchange 混合环境中的自动发现流程 |第 2#3 部分 |第 33 部分#36

步骤 9/30:分析 ExRCA 连接测试的数据

在Microsoft远程连接分析器结果页面中,我们可以看到

  • 自动发现客户端询问服务器是否需要客户端证书。
  • 服务器回复说他不需要客户端证书。

检查客户端证书身份验证的 IIS 配置。未检测到客户端证书身份验证。未配置接受/要求客户端证书。

[玩转系统] Exchange 混合环境中的自动发现流程 |第 2#3 部分 |第 33 部分#36

步骤 10/30:向自动发现端点提供用户凭据

证书验证、测试成功完成并且自动发现客户端可以“信任”目标主机后,自动发现客户端还需要证明其身份。
自动发现客户端将通过提供用户的凭据来识别自己的身份。 ”
(用户名+密码)。

[玩转系统] Exchange 混合环境中的自动发现流程 |第 2#3 部分 |第 33 部分#36

步骤 10/30:分析 ExRCA 连接测试的数据

注意:“提供用户凭据”部分不会出现在 Microsoft Remote Connectivity Analyzer 结果页面中。

步骤 11/30:尝试将自动发现 POST 请求发送到潜在的自动发现 URL:https://autodiscover.o365info.com/autodiscover/autodiscover.xml

自动发现客户端将尝试向自动发现端点发送自动发现 POST 请求,以获取所需的自动发现信息。

在我们的场景中,自动发现端点是 Exchange 本地面向公众的服务器。

如果您还记得,Alice 的邮箱托管在 Exchange Online 服务器上。
本地 Exchange 将 Alice 的邮箱视为“远程邮箱”。

由于 Exchange 本地部署是 Alice 邮箱的“所有者”,因此 Exchange 本地部署答案将包括到托管 Alice 邮箱的“真实”Exchange 基础设施(即 Exchange Online 基础设施)的重定向。

Exchange 本地“通知”用户 (Alice) 她应该使用新的或更新的电子邮件地址执行自动发现过程。

在我们的场景中,Exchange On-Premise 通知 Alice 她的“真实电子邮件地址”是 - [email protected]

混合环境和 Office 365“混合域名”

在我们继续描述自动发现过程之前,了解混合环境中电子邮件地址的概念非常重要。

在我们的特定场景中,用于“代表”Exchange Online 收件人的 SMTP 域名空间是 - o365info2.mail.onmicrosoft.com

此“域名”并不是用于自动发现过程的真实域名,而只是一个“逻辑指针”,它将“引导”Exchange Online 收件人到 Exchange Online 自动发现基础结构。

当自动发现客户端尝试查找名为 - o365info2.onmicrosoft.com 的主机时,该过程将失败,因为不应发布主机名。

在下图中,我们可以看到 Exchange 本地自动发现响应包含重定向消息。

本地 Exchange 通知 Alice,她的“真实”电子邮件地址是 -
[email protected]

[玩转系统] Exchange 混合环境中的自动发现流程 |第 2#3 部分 |第 33 部分#36

步骤 11/30:分析 ExRCA 连接测试的数据

在Microsoft Remote Connectivity Analyzer结果页面中,我们可以看到以下信息:

  • 自动发现客户端向自动发现端点发出请求,请求自动发现信息。
  • 自动发现端点响应包括一条重定向消息,其中包含“另一个”电子邮件地址。

Microsoft 连接分析器正在尝试从用户 [email protected] 的 URL https://autodiscover.o365info.com:443/Autodiscover/Autodiscover.xml 检索 XML 自动发现响应。已成功检索自动发现 XML 响应。
自动发现域重定向
redirectAddr
[email protected]

[玩转系统] Exchange 混合环境中的自动发现流程 |第 2#3 部分 |第 33 部分#36

步骤 12/30:尝试解析主机名 o365info2.mail.onmicrosoft.com

现在,自动发现流程已从 Exchange 本地环境“移动”到“云环境”(Office 365 和 Exchange Online)。

自动发现客户端“理解”他需要重新启动自动发现过程。自动发现过程将基于发送给 Alice 的“新电子邮件地址” - [email protected]

我们已经知道,自动发现客户端将“提取”收件人
电子邮件地址的“正确部分”,并尝试启动 DNS 查询来查找该主机名。

自动发现客户端将寻址 DNS 服务器,查找名为 - o365info2.mail.onmicrosoft.com 的主机的 IP 地址

信息请求将会失败,因为实际上不存在这样的主机。

[玩转系统] Exchange 混合环境中的自动发现流程 |第 2#3 部分 |第 33 部分#36

步骤 12/30:分析 ExRCA 连接测试的数据

在Microsoft Remote Connectivity Analyzer结果页面中,我们可以看到以下信息:

  • 自动发现客户端向 DNS 服务器发送地址,查找主机的 IP 地址 - mail.onmicrosoft.com
  • DNS的回答是他没有任何关于具体主机名的信息。

尝试在 DNS 中解析主机名 o365info2.mail.onmicrosoft.com。无法解析主机名。无法在 DNS InfoNoRecords 中解析主机 o365info2.mail.onmicrosoft.com。

[玩转系统] Exchange 混合环境中的自动发现流程 |第 2#3 部分 |第 33 部分#36

步骤 13/30:尝试解析主机名 autodiscover.o365info2.mail.onmicrosoft.com

如果自动发现客户端无法使用“域命名约定”找到其自动发现端点,自动发现客户端将尝试使用以下命名方案使用 FQDN 查找自动发现端点 - 自动发现 +

在我们的场景中,这个“公式”的结果是一个命名主机 -
autodiscover.o365info2.mail.onmicrosoft.com

自动发现客户端将寻址 DNS 服务器,查找名为 -autodiscover.o365info2.mail.onmicrosoft.com 的主机的 IP 地址

DNS 服务器“应答”,包括 IP 地址列表。 “多个 IP 地址”的原因是,在 Office 365 中,我们使用“逻辑主机名”,实际上可以“映射到”许多物理服务器。

[玩转系统] Exchange 混合环境中的自动发现流程 |第 2#3 部分 |第 33 部分#36

步骤 13/30:分析 ExRCA 连接测试的数据

在Microsoft Remote Connectivity Analyzer结果页面中,我们可以看到以下信息:

DNS 回复包括“映射”到名为 - autodiscover.o365info2.mail.onmicrosoft.com 的主机的 IP 地址列表

尝试在 DNS 中解析主机名 autodiscover.o365info2.mail.onmicrosoft.com。主机名解析成功。返回的IP地址:157.56.244.217、157.56.236.89、157.56.232.9、157.56.234.137

[玩转系统] Exchange 混合环境中的自动发现流程 |第 2#3 部分 |第 33 部分#36

步骤 14/30:测试主机 autodiscover.o365info2.mail.onmicrosoft.com 上的 TCP 端口 443,以确保其正在侦听并打开

自动发现客户端,尝试通过检查目标主机是否可以使用 HTTPS 协议进行通信来验证他是否可以继续与主机 - autodiscover.o365info2.mail.onmicrosoft.com 进行自动发现过程。

“HTTPS 测试”的结果是 -failure。
这是预期结果,因为主机 autodiscover.o365info2.mail.onmicrosoft.com 不是“真正的”Exchange 服务器。

[玩转系统] Exchange 混合环境中的自动发现流程 |第 2#3 部分 |第 33 部分#36

步骤 14/30:分析 ExRCA 连接测试的数据

在Microsoft Remote Connectivity Analyzer结果页面中,我们可以看到以下信息:

自动发现客户端尝试检查主机 - autodiscover.o365info2.mail.onmicrosoft.com 是否可以使用 HTTPS 协议进行通信。结果是特定主机不监听端口 443(默认 HTTPS 协议)。

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

[玩转系统] Exchange 混合环境中的自动发现流程 |第 2#3 部分 |第 33 部分#36

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

自动发现客户端算法基于以下概念:如果潜在自动发现端点无法响应 HTTPS 请求,自动发现客户端不会愿意“投降”,而是会放弃;自动发现客户端将尝试另一种方法,其中使用 HTTP 协议寻址潜在自动发现端点,请求“如何到达其自动发现端点”的说明。

自动发现客户端检查主机 autodiscover.o365info2.mail.onmicrosoft.com 是否可以使用 HTTP 协议进行通信。

[玩转系统] Exchange 混合环境中的自动发现流程 |第 2#3 部分 |第 33 部分#36

步骤 15/30:分析 ExRCA 连接测试的数据

在Microsoft Remote Connectivity Analyzer结果页面中,我们可以看到以下信息:

自动发现客户端尝试检查主机 - autodiscover.o365info2.mail.onmicrosoft.com 是否可以使用 HTTP 协议进行通信。结果是特定主机侦听端口 80(默认 HTTP 协议)。

正在主机 autodiscover.o365info2.mail.onmicrosoft.com 上测试 TCP 端口 80,以确保其正在侦听并打开。端口打开成功。

[玩转系统] Exchange 混合环境中的自动发现流程 |第 2#3 部分 |第 33 部分#36

Exchange 混合环境中自动发现流程的延续将出现在下一篇文章中 - Exchange 混合环境中的自动发现流程 |第 3 部分#3 |第 34 部分#36

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

取消回复欢迎 发表评论:

关灯