Microsoft 远程连接分析器 (ExRCA) |自动发现故障排除工具|第 2#4 部分 |第 22 部分#36

在本文中，我们将了解 ExRCA 也称为 Microsoft 远程连接分析器 (MRCA) 基于 Web 的工具，顾名思义，它用于测试和分析与不同 Exchange 客户端的“关系”相关的信息。他们的 Exchange 服务器。

Microsoft 远程连接分析器 (MRCA)

问：Microsoft 远程连接分析器 (MRCA) 的用途是什么？

答：微软远程连接分析器实际上是一个“基于Web的工具集合”，它使我们能够模拟不同Exchange客户端和不同环境之间的通信通道。例如，本地 Exchange 与 Exchange Online 以及与 Exchange 客户端没有直接实际联系的其他故障排除工具（例如消息分析器工具）。

多年来，Microsoft 远程连接分析器基于 Web 的工具已发展成为一种非常有用且“必须了解”的工具，每个 Exchange 本地或 Exchange Online 管理员都应该熟悉该工具。

在本文中，我们将学习了解和理解 Microsoft 远程连接分析器工具的接口和逻辑，但需要强调的是，我们将仅使用 Microsoft 远程连接分析器工具中的各种工具中的一个非常特殊的工具。分析仪包括。

我们的主要重点是名为 - Microsoft Office Outlook 连接测试 | 的特定测试。 Outlook 自动发现

在本文中，我们不会详细回顾 Microsoft 远程连接分析器工具测试结果中出现的自动发现流程详细信息，而是仅研究一般概念，例如 - 如何读取结果、测试结果等

Active Directory 环境中的自动发现与非 Active Directory 环境中的自动发现

对比。自动发现故障排除工具，例如 Outlook 测试电子邮件自动配置工具，它知道如何在两种不同的环境中“执行”，其名称为 Microsoft Remote Connectivity Analyzer Tool意味着（远程连接），了解如何检查和分析在非 Active Directory 环境中实现的自动发现流程。

简而言之，如果“外部邮件客户端”尝试访问面向公众的 Exchange 服务器，我们可以使用 Microsoft 远程连接分析器工具进行自动发现故障排除方案。

Exchange 本地基础设施与 Exchange Online 和 Office 365 基础设施

Microsoft 连接分析器工具可用于在用户邮箱托管在 Exchange 本地基础结构或 Exchange Online 基础结构上的情况下测试 Exchange 客户端远程访问。

在下面的屏幕截图中，我们可以看到 Microsoft Connectivity Analyzer Tool 的 Web 界面。

1.不同的 Exchange 环境

Microsoft 连接分析器工具提供的测试可以通过测试 Exchange 本地环境与 Office 365 (Exchange Online) 环境来实施。

我们可以看到测试的不同选项通过使用不同的选项卡进行“分组”。

• A - 在“Exchange Server”选项卡下，我们可以找到当我们需要测试 Exchange On-Premise 服务时可以使用的所有可用测试。
• B - 在“Office 365”选项卡下，我们可以找到需要测试 Exchange Online 基础结构时可以使用的所有可用测试。

2.不同类型的远程连接测试

在下面的屏幕截图中，我们可以看到自动发现连接测试出现在“Exchange 服务器”选项卡（Exchange 本地）下。

例如，我们可以对Outlook（RPC\HTTPS）邮件客户端、ActiveSync（移动Exchange客户端）等实现连接测试。

请注意，在“Microsoft Office Outlook 连接测试”部分下，我们有两种不同的连接测试。

例如，有两种不同类型的 Outlook 连接测试。

• Outlook 自动发现 - 测试 Outlook 客户端实现的自动发现流程和基础架构。
• Outlook 连接 - 一种“组合”测试，包括自动发现远程连接测试 + RPC\HTTPS 远程连接测试。

3. Microsoft Connectivity 远程分析器工具和 Office 365 环境

如前所述，Microsoft 连接远程分析器工具使我们能够测试 Office 365 环境和 Exchange 本地环境。

可以在 Exchange 本地环境中实施的测试也适用于 Office 365 环境，但是 Microsoft Connectivity Analyzer Tool 包括仅与 Office 365 环境相关的其他测试。

微软连接分析工具|测试不同的 Exchange 服务

如前所述，Microsoft 连接分析器工具包括多种类型的“Exchange 测试”。

例如：

• Microsoft Office Outlook 连接测试 - 检查使用 Outlook Anywhere 服务的 Outlook 客户端会话的连接测试。该测试检查基于自动发现服务的完整通信过程，然后进入“下一层”，即创建 RPC\HTTPS 通信链路的过程。
• Microsoft Exchange ActiveSync 连接测试 - 使我们能够模拟使用 ActiveSync 协议的移动客户端之间的连接会话。

在下面的屏幕截图中，我们可以看到 Office 365 环境的“界面”包括七种不同的连接测试，而 Exchange 本地选项卡则包括四种连接测试。

4.另一种类型的连接测试

Microsoft 远程连接分析器工具包括对其他 Microsoft 基础设施的测试，例如 Lync On-Premise、Lync Online 和 SSO（单点登录）服务（例如 ADFS）。

在下面的屏幕截图中，我们可以看到测试旁边还有与 Exchange 相关的附加“选项卡”。

5. “测试客户端”微软远程连接分析器工具|执行测试的“主机”

“执行测试的主机”这个主题是一个迫在眉睫的问题，而且有点令人困惑。

Microsoft 远程连接分析器工具是一个 Microsoft 公共服务器，我们可以使用它来模拟对各种交换服务（例如自动发现）的访问。

我们了解 Microsoft 远程连接分析器工具的具体章程至关重要，因为 Microsoft 远程连接分析器工具执行自动发现测试的方式不会涵盖所有可能的情况。

当我们遇到自动发现故障排除场景时，我们无法确定问题是否与以下内容有关：

1. 用户尝试从中访问自动发现端点的特定用户桌面。
2. 用户尝试访问自动发现端点的特定网络。
3. 自动发现基础设施中的一个“普遍问题”，影响所有需要访问其自动发现端点的“外部邮件客户端”。

Microsoft 远程连接分析器工具通过使用执行不同连接测试的公共 Microsoft 服务器来实现。

“公共服务器”服务器用于模拟 Exchange 客户端与 Exchange 服务器的会话。

我们应该意识到一个重要的事实，即 Microsoft 远程连接分析器工具自动发现测试只能用于测试非常特定的场景，即 Exchange 客户端（自动发现客户端）正在寻址 Exchange 服务器的“公共接口”的场景。

换句话说，Exchange 客户端位于公共网络且 Exchange 服务器配置为面向公众的 Exchange 服务器的情况。

从“外部 Exchange 客户端”测试自动发现流的选项适用于许多场景，但在某些自动发现故障排除场景中，我们需要从“不同方向”执行自动发现连接测试。

含义是 - 通过使用特定用户桌面执行自动发现测试或从特定网络（例如组织的专用网络）执行自动发现测试。

如果我们想要从内部网络或 Exchange 客户端所在的特定网络执行自动发现测试，我们可以下载并安装“Microsoft Connectivity Analyzer 客户端”。

在下面的屏幕截图中，我们可以看到可用于下载 Microsoft Connectivity Analyzer 客户端的“客户端选项卡”。

执行 - Microsoft Office Outlook 连接测试 | Outlook 自动发现

为了能够演示 Microsoft 远程连接分析器工具的使用，我们将选择执行 Outlook 自动发现测试。

场景描述

我们的场景的特征如下：

该组织的公共域名是 - o365info.com
位于外部\公共网络中的名为 John 的用户希望创建新的 Outlook 邮件配置文件。约翰的电子邮件地址是 - [email protected]

我们想要验证 Exchange On-Premise 服务器是否已正确“发布”，并且可供“外部客户端”访问和使用。

执行 Outlook 自动发现测试

要验证 Exchange On-Premise 服务器中所需的自动发现设置，我们将使用以下步骤：

1. 使用以下 URL 访问 Microsoft RCA - 远程连接分析器工具：https://testconnectivity.microsoft.com/

小提示 - 如果您无法记住“完整的 URL 地址”，您可以打开任何搜索引擎并输入单词 - ExRCA。
搜索结果中出现的第一个结果将“引导您”到 Microsoft RCA - 远程连接分析器页面。

2. 单击Exchange Server选项卡，然后在Microsoft Office Outlook 连接测试下选择选项 - Outlook 自动发现

3. 在右下角，单击下一步选项

在接下来的屏幕中，我们需要提供“用户凭据”。

ExRCA 将使用这些凭据向 Exchange 客户端“冒充自己”，尝试连接 Exchange 本地服务器，完成自动发现过程并获取所需的自动发现响应。

1. 电子邮件地址 - 输入收件人电子邮件地址。在我们的场景中，收件人电子邮件地址是 - [email protected]

2. 域 \用户名（或 UPN） - 在此框中，我们需要提供本地 Active Directory 或域用户凭据。大多数时候，“标准约定”基于以下格式：\

（更准确地说，仅是内部 Active Directory 域名的左侧部分）。

如果本地 Active Directory 用户帐户也配置了公共域名后缀，则可以使用 UPN（用户主体名称）命名约定来执行身份验证。例如 - [email protected]

在我们的场景中，我们将使用标准命名约定 - o365info\john

3. 密码——这是“域用户密码”，即用户登录企业域时使用的密码。

4. 批准自动发现测试 - 选择以下选项：

我了解我必须使用 Exchange 域中的工作帐户的凭据才能远程测试与其的连接。我还承认我负责该帐户的管理和安全。

这是强制性要求。

选择此选项时，我们同意我们“信任 Microsoft”（我们向 ExRCA 服务器提供我们的“秘密”私有域用户凭据）。

5. 验证 - 我们需要通过重新输入出现的字母来完成验证过程（这是 Microsoft 验证我们是人为因素而不是恶意代码的方式）。
要完成该过程，请单击 验证按钮

在下一个屏幕截图中，我们可以看到验证过程已成功完成。

要开始自动发现测试，请单击下一步选项

分析 Outlook 自动发现测试的结果

这就是 ExRCA “闪耀”的部分。
我知道这听起来可能很“极客”，但是，我认为 ExRCA 在以非常清晰的“人类”方式呈现“发现”方面做得非常出色。 -类似”的方式。

就我自己而言，我使用这些工具解决了许多“自动发现问题”，这些工具为我提供了有关自动发现过程的清晰且信息丰富的信息。

RCA - 远程连接分析工具结果结构和逻辑

乍一看，远程连接分析器工具提供的结果看起来有点混乱。
因此，我们了解 ExRCA 用于显示结果的方式非常重要。

自动发现过程由几个部分组成。

结果包括自动发现过程中涉及的每个“部分”或“步骤”的专用部分。

在每个“部分”的开头，我们可以看到任务和结果（成功或失败），在标题下方，我们可以看到实施的每个“子步骤”和结果（成功或失败）的详细描述。失败）。

ExRCA 结果界面

这一部分我们将回顾“如何读取”ExRCA 自动发现连接测试的显示结果，这似乎是“不必要的”，但尽管事实上每个人都知道如何使用该结果，但花一点时间来了解 ExRCA 自动发现连接测试的显示结果非常重要。显示 ExRCA 结果。

由于自动发现过程或流程可能相对简单或包含大量信息，因此 ExRCA 使用“扩展和折叠”的方法。

该逻辑基于“层次结构概念”，从“第一级”信息开始，并且能够查看（扩展）自动发现测试中实现的每个子流程或测试。

我们可以用“俄罗斯头巾”来比喻。

第一个“头巾”可以打开并放在里面，当我们打开里面的头巾时，我们可以找到另一个头巾，我们可以得到另一个头巾，依此类推。

ExRCA Autodiscover 测试结果实现了相同的逻辑。

每个步骤都可以展开，这样我们就可以看到“父步骤”中包含的附加步骤的内容等等。

为了演示 ExRCA 结果界面的“层次结构概念”，我们使用 ExRCA 自动发现测试结果示例来模拟对本地面向公众的 Exchange CAS 服务器的自动发现访问。

1级

在这个层面上，我们可以看到 ExRCA 结果的“明确答案”。在我们的示例中，测试成功完成。

2级

当选择测试步骤下的“扩展”选项时，我们可以看到“附加级别”的信息。

在我们的示例中，我们可以看到自动发现测试是通过查找名为 o365info.com 的主机启动的，结果是 - 失败。

下一个自动发现测试是使用名为
autodiscover.o365info.com 的主机执行的，结果是 - 成功

3级

下一个级别（“级别 3”）是我们可以查看自动发现流程中包含的所有步骤的级别。

在下图中，我们可以看到显示结果的逻辑。

在下面的屏幕截图中，我们可以看到自动发现过程中包含的每个步骤的简短描述。

第 1 步：描述为 - 尝试在 DNS 中解析主机名 autodiscover.o365info.com。

步骤 2：描述为 - 测试主机 autodiscover.o365info.com 上的 TCP 端口 443 以确保其监听并打开”。

第 3 步：描述为 - 测试 SSL 证书以确保其有效。

步骤 4：描述为 - 检查客户端证书身份验证的 IIS 配置。

第 5 步：描述为 - 尝试向潜在的自动发现 URL 发送自动发现 POST 请求。

4级

这是“最深层”的信息，使我们能够更深入地了解特定的自动发现步骤。

在以下示例中，我们扩展了“名称解析”步骤，其中自动发现客户端访问 DNS 服务器并询问自动发现端点的 IP 地址。

在我们的场景中，我们可以看到返回到客户端的 IP 地址是：212.25.80.239，完成该过程所需的“往返”时间是：221 毫秒

自动发现流程 - 成功和失败事件的混合 |揭开谜底

标准自动发现流程中最令人困惑的问题之一可以描述为 - 成功和失败事件的混合。

另一个令人困惑的问题是 - ExRCA 结果可以描述为 - “连接测试成功，但有警告。 ”

“困惑”在于，不清楚测试是否成功完成。换句话说，无法获得清晰的白\黑答案。

查看屏幕截图时，我们可以看到测试结果的图标是绿色的，但同时我们可以看到一个带有感叹号的黄色图标。

因此，最明显的问题是 - 它是好还是坏？
我们能否理解我们的自动发现基础设施配置正确，或者我们需要解决一些问题？

简单的答案是 - “是的，这很好”。
通知 - “测试成功但有警告”的原因是自动发现过程基于反复试验的概念。

在寻找“最终结果”时，自动发现客户端被编程为执行几种方法，99% 的情况下，其中一些“方法”或测试会失败。

重要的是回答问题的“结果”——客户是否能够找到“答案”，即自动发现响应。

黄色图标带感叹号的原因如下：

1.根域

结果最常见的原因 - “测试成功，但有警告”是，默认情况下，自动发现客户端被编程为通过从接收者 E 中“提取”域名来查找自动发现端点邮件地址（“右侧部分”，包括收件人 SMTP 域名），并使用“域名”作为主机名创建 DNS 查询。

例如，如果收件人姓名为 - [email protected]，自动发现客户端（例如 Outlook）将创建一个 DNS 查询来查找主机名 - o365info.com

大多数情况下，此方法会失败，因为组织公共域名在 DNS 中“映射”为 Exchange 服务器的 IP 地址的情况非常罕见。

结果是大多数时候自动发现过程中的第一步将显示为“失败”。

一般来说，“使用根域名查找自动发现端点的主机名”的方法甚至可能会导致或大或小的问题。

如果该组织使用公共网站并另外映射该网站的域名地址，自动发现客户端将从 DNS 获得有关根域名 IP 地址的“肯定答案”。当他尝试使用 HTTPS 与“明显自动发现端点”通信时，通信将失败。

因此，除了花费时间来实现此方法外，没有什么坏处。

在少数好的情况下，如果“目标主机”（网站）的证书有问题，例如日期已过期的证书等，自动发现客户端将停止自动发现过程，因为自动发现客户端“理解”自动发现端点有问题。

老实说，我认为应该删除“使用根域名查找自动发现端点的主机名”的自动发现方法，因为就我自己而言，我看不到使用此方法有任何优势。

使用根域名查找自动发现端点的主机名的示例

在下面的屏幕截图中，我们可以看到 ExRCA 测试结果的示例：

自动发现客户端连接 DNS 服务器，查找根域名的 IP 地址（在我们的示例中为 o365info.com ），获取主机名的 IP 地址 -

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

当自动发现客户端尝试检查主机是否“列出”HTTPS 通信时，测试失败，因为目标主机无法使用 HTTPS 进行通信。
ExRCA 中的结果显示为-

测试主机 o365info.com 上的 TCP 端口 443，以确保其正在监听并打开。指定的端口被阻止、未侦听或未产生预期响应。

2.证书链

结果“测试成功但有警告”的另一个原因是描述为“测试证书链”的过程

自动发现客户端请求自动发现端点通过提供证书来证明其身份。

公共证书基础设施建立在分层概念之上。

公共服务器证书由“上级机构”提供，并且很多时候，“上级机构”是附加“上级机构”的下级。

在这种情况下，至少涉及“两个元素”——提供证书的元素（描述为 CA-证书颁发机构）和“使用证书的客户端”（例如 Exchange 服务器）。

自动发现客户端将执行的安全测试的一部分是 - 检查提供证书的“元素”，即 CA 和 CA 证书。

自动发现客户端验证 CA 证书的能力基于以下假设：CA 是“众所周知的”并且客户端（自动发现客户端）在其证书存储中拥有 CA 证书。

当我们使用 ExRCA 工具执行自动发现测试时，即使“测试证书链”阶段成功完成，ExRCA 工具也会通知我们“他”（ExRCA）设法验证证书链。这并不意味着“用户桌面”也将成功完成证书链测试，因为这些测试取决于特定的桌面证书存储。

当查看 ExRCA 测试结果时，我们可以看到此类通知：

分析证书链是否存在与 Windows 版本的兼容性问题。某些版本的 Windows 发现了潜在的兼容性问题。其他详细信息
Microsoft 连接分析器只能使用 Windows Update 中的根证书更新功能来验证证书链。如果未启用“更新根证书”功能，您的证书在 Windows 上可能不受信任。

回顾一下，尽管测试证书链的自动发现阶段出现了黄色感叹号，但这不是问题，我们无法避免此信息出现在自动发现测试结果中。

保存 ExRCA 测试结果以供进一步分析

我们使用 ExRCA 工具获得的测试结果可用于实时分析，或者将数据发送给技术支持团队（例如 Office 365 支持团队）进行持续分析。

ExRCA 工具使我们能够使用三个不同的选项保存自动发现测试的结果：

1.复制到剪贴板

此选项将使用 XML 格式将 ExRCA 测试结果复制到本地桌面剪贴板。就我个人而言，我更喜欢其他方法，例如将自动发现测试结果保存为 HTML 格式，因为结果的读取更加清晰。

2.将结果保存到 HTML 文件

这是我更喜欢的方法。保存 ExRCA 测试结果 HTML 文件的选项与屏幕上显示的结果相同。使用绿色和红色图标，无法很容易地找到“问题区域”，此外，“展开和折叠”选项使我们能够非常轻松地浏览数据。

3.将结果保存到 XML 文件

将数据保存为 XML 格式的可能性很有趣，因为当使用 XML 选项时，我们可以使用 Microsoft Excel 等工具以自定义格式“呈现”数据。

如果我们将 ExRCA Autodiscover 测试结果保存为 XML 文件格式，并使用 Excel 打开 XML 文件，则会出现以下消息 - “请选择您希望如何打开此文件。 ”

我们将选择以下选项：作为 XML 表

在下一个弹出窗口中单击确定

在下面的屏幕截图中，我们可以看到结果。

Excel“知道”如何将 XML 数据放入表格格式，并且，我们可以使用 Excel 选项（例如“过滤器”）来显示或隐藏特定“数据”。 ”

另一个选项是使用高级文本编辑器（例如 Notepad++）打开 XML 文件

在下面的屏幕截图中，我们可以看到使用 Notepad++ 打开 XML 文件的结果。我们可以看到文本编辑器“理解”特定的 XML 格式并使用颜色、XML 标签的层次结构等显示数据。