Office 365 中的混合部署 |清单和先决条件|第 2/3 部分

以下文章是混合配置清单和先决条件文章系列的第 2 部分。在下面的文章中，我们回顾了涉及混合环境并与之相关的其他“组件”：

• Exchange 本地服务器 EWS 服务
• Exchange 本地服务器自动发现服务
• Exchange 本地服务器和公共证书

混合部署 Office 365 - 文章系列

该系列文章包括以下文章：

• Office 365 中的混合部署 |清单和先决条件|第 1/3 部分
• Office 365 中的混合部署 |清单和先决条件|第 2/3 部分
• Office 365 中的混合部署 |清单和先决条件|第 3/3 部分

7. Exchange 本地混合服务器 |自动发现服务

自动发现服务充当 Exchange On-Premise 和 Exchange Online 之间“混合关系”的“基础”，反之亦然。

自动发现服务将用于混合环境的首次配置（使用 HCW 时）以及本地部署和云环境之间的持续通信。
因此，验证和检查混合环境至关重要以下与自动发现服务相关的部分：

1.自动发现记录和公共网络

我们需要验证组织公共域的自动发现记录是否已发布并指向 Exchange 本地服务器。
基于保留命名约定的自动发现记录通过以下方式实现：自动发现

例如，公共域 o365info.com 的自动发现记录为： Autodiscover.o365info.com

我们需要检查并验证自动发现记录是否正确发布以及自动发现记录是否指向 Exchange 本地服务器

在下图中，我们可以看到自动发现过程的描述。
在我们的示例中，Exchange Online 需要获取有关 o365info.com 组织的信息。

要获取所需信息，Exchange Online 访问公共 DNS 并查询 Autodiscover.o365info.com 记录。
如果自动发现 DNS 记录配置正确，则 DNS提供公共 IP，并且 Exchange Online 使用此 IP 来联系 Exchange 本地自动发现服务。

注意：在本节中，我们仅涉及自动发现服务的 DNS 设置，在本节的其余部分中，我们将回顾需要验证和检查的自动发现服务的其他方面。

自动发现 DNS 记录 |一个记录

在混合环境中，自动发现应作为通过公共 DNS 服务器发布的 A 记录来实现。

在某些情况下，Exchange 本地自动发现配置基于 SRV 记录。混合环境不支持此方案。

换句话说：如果当前的 Exchange 本地自动发现基于 SRV DNS 记录，您需要将此配置更改/更新为使用指向公共的 A 记录实现的“标准自动发现配置” Exchange 本地服务器的 IP 地址。

您还需要将这些记录包含在 SAN 证书中。您可以使用 CNAME 记录进行自动发现重定向，但这不会改变您必须将所有自动发现记录添加到 SAN 证书的事实。此外，Exchange 混合部署不支持基于 SRV 的自动发现重定向。

验证 Exchange 本地自动发现过程是否成功运行

自动发现服务记录和公共 IP 的发布只是所需设置的第一部分。下一步，我们需要验证是否可以访问 Exchange On-Premise 自动发现服务 + 获取所需信息（Exchange On-Premise 将使用 XML 文件提供所需信息）。

在下图中，我们可以看到外部主机（例如 Exchange Online）尝试连接本地 Exchange On-Premise（Exchange 本地服务器的自动发现服务）。
如果 Exchange 本地服务器“响应”，Exchange Online 需要进行识别，成功验证后，Exchange On-Premise 使用名为 - autodiscover.xml 的文件提供所需的信息

验证 Exchange 本地自动发现服务的可用性

Exchange On-Premise Autodiscover 服务的验证可以通过使用一个非常强大且推荐的工具 Microsoft Remote Connectivity Analyzer (MRCA) 来实现。

在下一节中，我们将回顾验证 Exchange 本地自动发现服务的可用性所需实施的所需步骤的示例。

1. 选择 Exchange 服务器选项卡，然后在“Microsoft Office Outlook 连接测试”下选择选项：Outlook 自动发现

1. 提供 Exchange On-Premise 用户凭据。
   为了能够获取所需信息，我们需要提供拥有 Exchange On-Premise 邮箱的用户的用户凭据。
   在我们的示例中，我们使用用户的凭据名为：用户2

1. 在结果屏幕中，我们可以看到标题为：“连接测试成功，但有警告。”
   这是“所需的结果”，尽管结果包括“黄色感叹号”。默认情况下，自动发现测试将包括一些小错误，这些错误是由自动发现过程的“试错”机制引起的。
   我们获得“绿色图标”的事实表明自动发现过程成功实施。

1. 如果我们想获得更详细的信息，我们可以单击“测试步骤”。
   在下面的屏幕截图中，我们可以看到自动发现 XML 文件的内容。

3. 自动发现和 Exchange On-Premise 服务器版本

在包含多个 Exchange On-Premise 版本的混合 Exchange On-Premise 环境中，我们必须验证自动发现记录是否“指向”最新更新的 Exchange On-Premise 服务器版本。

从技术上讲，自 Exchange 2007 版以来的每个 Exchange 服务器都可以提供自动发现服务，但是为什么 Exchange 服务器“准备”所需的数据（XML 文件）以及“自动发现文件”的内容是在一个每个 Exchange 服务器版本中的方式都不同。

在混合 Exchange 环境中，实现了“向后可计算性”概念。
“最新”Exchange 服务器版本可以获取对自动发现信息的查询，并“理解”如何格式化所需答案。

例如，如果我们将自动发现记录指向 Exchange 2013 服务器，并且外部客户端询问托管在 Exchange 2007 服务器上的收件人（可用性服务）的忙/闲时间，则 Exchange 2013 “知道”如何以正确的方式格式化从 Exchange 2007 服务器发送的请求和应答。

4。自动发现指向 Exchange 本地服务器的记录

与自动发现记录和混合实现相关的最常见错误之一是：更新自动发现记录以指向“云”(autodiscover.outlook.com)。
这个假设似乎符合逻辑，但此更新应该未实现。
在混合配置中，“代表”公共域名的自动发现记录应指向 Exchange 本地服务器。

注意 - 我们不需要配置或更新任何与“云”相关的自动发现设置，因为在 Office 365 中，自动发现服务的所有必需配置都是使用“服务域”或 Tenet Office 自动配置的365 域，例如 o365info.mail.onmicrosoft.com

8. Exchange 本地混合服务器 |电子预警服务服务

混合环境基于两个独立的 Exchange 组织作为一个实体运行的概念。例如，使 Exchange 本地用户能够查看有关 Exchange Online 收件人的忙/闲时间信息、获取外出消息等等。
用于 Exchange 本地服务器和 Exchange Online 之间“协作”的基础结构基于Exchange EWS（Exchange Web Services）服务。
含义是：

• Exchange On-Premise 必须可以从公共网络访问。
• 必须正确配置 Exchange 本地 EWS 服务。

注意 - 混合配置基于“双向关系”，其中 Exchange On-Premise 还需要访问 Exchange Online EWS，但基本假设是“云基础设施”(Exchange Online) 已正确配置并且除了极少数事件外，我们假设云端允许可用且配置正确。

验证 - 检查以下内容的可用性：Exchange 本地混合服务器 EWS 服务

我们可以使用以下选项之一检查或验证 Exchange 本地部署和 EWS 服务的可用性：
选项 1：使用 EWS URL 验证\检查 Exchange 本地部署和 EWS 服务的可用性
在此选项中，我们可以简单地尝试访问 Exchange 本地 Web 服务 (EWS) 的 URL。

默认 URL 基于以下命名对话：https://ews/exchange.asmx

在我们的场景中，本地 Exchange 的公共名称为：mail.o3655info.com
我们将打开 Web 浏览器并使用以下 URL 地址：https://mail.o365info.com/ews/exchange.asmx

在下面的屏幕截图中，我们可以看到我们可以成功连接 Exchange On-Premise 的 EWS 服务。
作为响应，Exchange On-Premises 服务器发送身份验证要求。
此外，我们可以看到服务器证书是“正确的”，因为锁定图标没有错误。
我们需要提供的凭据只是在 Exchange On-Premise 服务器上拥有邮箱的任何收件人的简单用户凭据。

Exchange On-Premise“答案”是一个 XML 文件，其中包含有关 Exchange On-Premise Web 服务的所需信息或描述。

对我们来说没有任何实际意义。唯一的意义是我们可以访问 Exchange On-Premise EWS 服务并获取 Exchange 服务器响应。

选项 2：使用 Microsoft 远程连接分析器验证/检查 Exchange On-Premise 和 EWS 服务的可用性

Exchange On-Premise EWS 服务的验证可以通过使用一个非常强大且推荐的工具 Microsoft Remote Connectivity Analyzer (MRCA) 来实现。

在下面的屏幕截图中，我们可以看到验证 Exchange On-Premise EWS 服务的可用性所需执行的所需步骤的示例。

1. 选择Exchange 服务器选项卡，然后在“Microsoft Exchange Web 服务连接测试”下选择选项：同步、通知、可用性和自动回复

2. 提供 Exchange On-Premise 用户凭据
为了能够获取所需信息，我们需要提供拥有 Exchange On-Premise 邮箱的用户的用户凭据。
在我们的示例中，我们使用以下凭据用户名为：User2

3. 在结果屏幕中，我们可以看到标题为：“连接测试成功，但有警告。”
尽管结果包含“黄色感叹号”。

默认情况下，Exchange 本地 Web 服务测试将包括一些由自动发现过程的“试错”机制引起的小错误。

我们获得“绿色图标”这一事实表明 Exchange 本地 Web 服务流程已成功实施。

4. 如果我们想获得更详细的信息，我们可以点击“测试步骤”。
在下面的屏幕截图中，我们可以看到内容自动发现 XML 文件的。

9. Exchange 本地混合服务器 |公共证书

Exchange Online 和 Exchange On-Premise 之间的通信通道基于通信通道“安全”的基本假设。需要保护通信通道，因为两个端点之间的信息是通过公共网络传输的。

通过使用 HTTPS 和 SMTP\TLS 等安全协议以及用于创建数据加密的组件来实现安全通信通道的创建。数据完整性、相互身份验证等基于双方（Exchange Online 和 Exchange On-Premise）使用的公共证书。

基本假设是 Exchange Online 公共证书配置正确且可用。

在我们的场景中，我们需要在“Exchange 本地服务器端”验证公共证书的主题。

注意 - 我们不会详细介绍如何创建证书请求、在 Exchange On-Premise 上安装公共证书等。
基本假设是 Exchange On-Premise 包含公共证书的隔离，并且我们只想验证公共证书是否已安装并包含所需的信息。

Exchange 内部部署公共证书将用作自动发现服务的一部分，实际上用于加密 Exchange 内部部署服务器和 Exchange Online 服务器之间的邮件流 (SMTP/TLS)。

在下图中，我们可以看到需要包含在 Exchange 本地公共证书中的“主机名称”示例。

在我们的场景中，Exchange 本地公共证书应包含自动发现服务的主机名：Autodiacover.o3655info.com 和其他主机名 - mail.o3655info.com
这是 Exchange Online 服务器用于寻址 Exchange On-Premise 服务器（创建到 Exchange On-Premise 服务器的安全通信通道）的主机名。

公共证书类型

有几种公共证书类型。最常见的类型是：
通配符证书和 SAN（主题备用名称）证书。
这两种类型之间的主要区别是：通配符证书不包含有关特定主机名称与 SAN 的信息证书需要包含允许使用该证书的“主机”的特定名称。

公共证书要求

为了能够检查\验证 Exchange 本地部署中的公共证书设置，请使用 Exchange MMC、服务器配置，通过查看 Exchange 证书选项卡选择混合服务器名称（在我们的场景中为 EX01）。

注意：这些说明与 Exchange 2010 界面相关。

与 Exchange On-Premise 证书相关的三个主要要求：

1。公共证书

术语“公共证书”的含义是由公共 CA（证书颁发机构）创建的证书。
在下面的屏幕截图中，我们使用 Exchange 2010 本地 MMC 界面来获取有关公共证书的信息。我们可以看到，在“self-Signed”部分下，证书的值为：False（屏幕截图中的数字 1）。
意思是该证书不是由 Exchange 本地服务器创建（自签名，但由公共证书提供商创建。

2。证书分配

应将公共证书分配给以下 Exchange 服务：IIS 和 SMTP（屏幕截图中的数字 2）。

3。 SAN 公共证书

SAN（主题备用名称）证书包含“允许”使用该证书的主机的名称。术语“主题”描述了可以实现为简单主机名（例如 SRV1）或 FQDN（例如 mail.o3655info.com）的主机名。

当 Exchange 本地服务器向 Exchange Online“出示”其公共证书时，Exchange Online 将需要检查 Exchange Online 接收连接器中配置的邮件服务器名称是否包含在 Exchange 本地服务器提供的公共证书中。
（在我们的场景中：Exchange 本地服务器提供商需要包含主机名的公共证书：mail.o3655info.com。

我们建议您使用支持“使用者备用名称”字段的统一通信证书在同一证书中提供所有必要的 DNS 名称。使用统一通信证书可降低配置和管理自动发现服务和 Exchange 服务 URL 的复杂性。但是，使用统一通信证书可能会增加成本，因为这种证书可能比您已经拥有的单一名称证书更昂贵。

证书 - 用于本地和 Exchange Online 组织之间安全邮件传输的数字证书必须安装在所有本地客户端访问服务器上，必须由第三方证书颁发机构 (CA) 颁发，不得已过期，并且必须分配 IIS 和 SMTP 服务。如果不满足这些证书要求，从 Exchange Online 组织到本地组织的安全邮件传输将无法正常运行。

了解更多：混合部署故障排除。

验证 - 检查 Exchange 本地服务器公共证书的内容

选项 1：使用 Exchange MMC 获取有关公共证书的信息
为了能够验证公共证书中包含的指定主机，请双击公共证书和详细信息选项卡查找字段 - 主题备用名称

在下面的屏幕截图中，我们可以看到公共证书包含所有所需的主机名称。

注意：当我们使用通配符证书时，在公共证书中包含主机名的主题并不相关，因为在这种情况下，证书与特定域下的“所有主机”相关。

选项 2：通过访问 OWA URL 检查 Exchange 内部部署公共证书
检查 Exchange 内部部署公共证书的另一个选项是访问用于OWA 访问。

在我们的场景中，OWA URL 为：https://mail.o365info.com/owa

在下面的屏幕截图中，我们可以看到我们使用的URL，在URL栏的右上角，我们可以看到锁形图标，代表该网站提供了证书。

当我们双击锁形图标时，我们将能够看到Exchange本地服务器提供的公共证书的“内容”。

10. Microsoft MFG服务器和所有权证明过程

当我们需要创建混合配置时，第一步是 Exchange On-Premise 服务器与 Microsoft 联合网关 (MFG) 创建信任关系。
这种信任关系描述为联合信任

注意 - 使用混合配置时，双方（本地 Exchange 和在线 Exchange）都需要“信任”MFG。 Office 365 云基础设施设置为自动信任 MFG 服务器，因此唯一的要求是在 Exchange On-Premise 和 MFG 之间“建立”新的信任。

与 Microsoft MFG 服务器的联合信任的“创建”是通过为我们使用的公共域实施“所有权证明”流程来创建的。

例如：如果我们想要使用公共域名来配置混合配置：o3655info.com，我们需要证明我们拥有该域名。

“所有权证明”过程通过以下方式实现：使用 HCW 时，Exchange On-Premise 会联系 Microsoft MFG 服务器。
MFG 服务器会回复“TXT 字符串”。

我们需要复制此文本字符串，转到我们的公共 DNS 服务器，添加一个新的 TXT 记录，其中包含 MFG 服务器提供的值，并且只有在我们创建“证明”之后，MFG 服务器才会访问我们的公共 DNS服务器正在寻找此 TXT 字符串。

在下图中，我们可以看到与 Microsoft MFG 服务器建立信任所需的流程或步骤的描述。

使用 HCW（Exchange 混合配置向导）时，从 MFG 服务器发送的所需 TXT 字符串将显示在屏幕上。

如果由于某种原因未显示所需的 TXT 字符串，我们可以使用 PowerShell 命令来显示 TXT 字符串（TXT 域证明）。

我们使用的 PowerShell 基于以下语法：

Get-FederatedDomainProof -DomainName "<Domain name>"

在下面的屏幕截图中，我们可以看到域证明文本字符串。

选项 1：也使用 Nslookup 命令验证公共 DNS 中的 TXT 记录配置是否正确

如果我们想要验证 TXT 记录（TXT 域证明）是否在公共 DNS 中正确配置，我们可以为 TXT 记录创建查询。
要验证 TXT 记录（TXT 域证明）在公共 DNS 中配置是否正确公共DNS，可以使用NSLOOKUP命令查看信息。

例如，我们可以使用 NSLOOKUP 工具获取有关在域中配置的 TXT 记录的信息：o3655info.com
从命令提示符中键入：

Nslookup
Set type=txt
接下来我们输入要查询的域名名称。
o365info.com

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

选项 2：使用 Web 工具验证公共 DNS 中的 TXT 记录是否配置正确。
有许多免费的 Web 工具可以帮助我们查询 DNS 服务器。
如下例如，我们将使用网站 MxToolbox。

1. 选择更多菜单

1. 选择 TXT 选项并输入您要查询的域名。

在我们的示例中，我们希望获取 o365info.com 域中所有 TXT 记录的信息
在下面的屏幕截图中，我们可以看到查询结果。 o365info.com 域下有两条 TXT 记录。
其中一条 TXT 记录是 Microsoft MFG 服务器提供的文本字符串，并在 o365info.com 域中更新为 TXT 记录。

11.直接沟通渠道| Exchange 本地服务器到 Exchange Online

混合配置中的邮件流主题涉及传入邮件流和传出邮件流的许多场景。

例如 -

• 从“云基础设施”发送到公共网络的邮件。
• 从“云基础设施”发送到 Exchange 本地收件人的邮件。
• 从本地 Exchange 发送到公共网络的邮件。
• 从本地 Exchange 发送到 Office 365 收件人的邮件。

我们不会详细介绍所有可用的邮件流方案，但我只想强调 Exchange 本地服务器和 Exchange Online 之间的邮件流，反之亦然。

如前所述，在混合配置中，Exchange 本地服务器和 Exchange Online 充当一个单元或一个实体。

通过在 Exchange 本地服务器和 Exchange Online 之间创建基于 SMTP\TLS 和 HTTPS 协议的直接通信路径来实现的配置。

Exchange 本地服务器和 Exchange Online 之间的所有邮件流都通过此安全通信通道传递。

例如，如果 Bob 的邮箱位于 Exchange 本地服务器上，并且 Bob 向 Alice 发送邮件，而她的邮箱位于 Exchange Online 服务器上，则邮件将由 Exchange 本地服务器使用 Exchange 本地服务器和 Exchange Online 之间存在的“直接安全通信链接”“传输”到 Exchange Online（此“安全通道”由 HCW - Exchange 混合创建）配置向导）

在下图中，我们可以看到 Exchange On-Premise 和 Exchange Online 服务器之间的安全通信链路所需配置的示例。
在我们的场景中，共享域是 - o365info.com
Each从 Exchange 本地收件人发送到“云收件人”(Exchange Online) 的邮件（包括域名：o365info.com）将通过现有的直接安全通信通道进行路由，反之亦然。

注意：“直接安全通信通道”由一组四个连接器实现：
在 Exchange 本地混合服务器上创建的 1 个发送连接器和 1 个接收连接器，在 Exchange 内部部署混合服务器上创建相同的连接器。 “Exchange Online 端”。

另一种受支持的方案可能是 Exchange 本地环境包括边缘传输服务器的方案。在这种情况下，将通过使用边缘传输服务器作为本地端的“端点”或网关来创建直接安全通信通道。

不支持的场景 |使用非 Exchange 服务器作为“本地端点”

我们需要避免的不支持的场景是：我们在本地环境中使用“非 Exchange 服务器”作为端点的场景。
例如：在下图中，我们可以看到一个场景其中在邮件安全网关（“非 Exchange 服务器”）和 Exchange Online 之间创建的直接安全通信通道。

从技术上讲，我们可以实现这种情况，但不支持这种配置，并且您有可能（如果不是一定的机会）会遇到多种类型的问题。

不支持此场景的原因是，混合环境中的“直接安全通信通道”不仅仅是两个独立邮件服务器之间的简单连接器，而是包含许多与邮件直接相关的配置设置和参数的通信通道。 “交换服务器。”

本地 Exchange 2013 客户端访问服务器或 Exchange 2013/2010 SP3 边缘传输服务器与 EOP 之间不能有其他 SMTP 主机或服务。当邮件通过非 Exchange 2013 服务器、Exchange 2010 SP3 之前的服务器或 SMTP 主机时，添加到启用混合传输功能的邮件的信息将被删除。

了解更多信息：Exchange 混合部署中的传输选项。