将用户连接到他们的 Exchange Online 邮箱 - 阶段迁移 - 解开谜团第 2 部分#2 |第 36 部分#36

当前文章是第二篇文章，我们在其中回顾了为使用 Exchange 阶段迁移将其邮箱迁移到 Exchange Online 的用户创建新的 Outlook 邮件配置文件的任务所面临的挑战和可选解决方案的主题。

Exchange Stage 迁移和自动发现基础架构 |文章系列

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

• 阶段迁移、交换和自动发现基础设施 |第 1#2 部分 |第 35 部分#36
• 将用户连接到他们的 Exchange Online 邮箱 - 阶段迁移 - 解开谜团 |第 2 部分#2 |第 36 部分#36

阶段迁移的“障碍”概念，其中自动发现基础设施指向本地 Exchange。

我们可以使用可选的解决方案来“绕过”这个障碍。

当前的文章致力于“如何做”部分或我称之为“客户端解决方案”的方法的技术描述。

如果我们无法实施“服务器端解决方案”（即删除 Exchange 本地用户邮箱并创建新的 MEU（启用邮件的用户）），我们将需要使用“客户端”解决方案，其中我们使用特定的解决方案为迁移的用户创建新的 Outlook 邮件配置文件。

正如上一篇文章中提到的，在实施 Exchange 阶段迁移时，有两种类型的解决方案用于创建新的 Outlook 邮件配置文件的任务 - 客户端和服务器端。

每种方法都有优点和缺点。

例如，“服务器端”解决方案，其中我们删除现有的 Exchange 本地用户邮箱并创建一个包含电子邮件地址搜索引擎的 MEU（启用邮件的用户）。理论上，可以手动实施，但实际上，“手动”解决方案是无效且笨拙的。

为了能够有效地执行所需的过程，我们需要使用 PowerShell 脚本自动执行此过程。

目前，我们可以使用 Microsoft 提供的一组 PowerShell 脚本，但是……

我在使用所提供的 PowerShell 脚本时遇到了许多问题，并且编写自定义 PowerShell 脚本的选项仅适合我们这些知道如何编写所需 PowerShell 语法的人。

“客户端解决方案”基于相对简单的配置设置，但需要为每个用户的桌面单独实施此配置。

可以实施的可用“客户端”解决方案有：

1. 更新本地注册表+ HOSTS 文件。
2. 使用 onmicrosoft 电子邮件地址创建新的 Outlook 邮件配置文件。

快速提醒

在 Exchange 阶段迁移场景中，我们希望找到一种方法来更改邮件客户端 (Outlook) 的默认“自动发现行为”，这样，自动发现过程将不会通过本地 Exchange CAS 服务器实现，而是通过 Office 实现365 自动发现基础结构 (Exchange Online)。

场景描述

在我们开始解释“如何做”之前，示例将基于以下场景：

• Alice 是一个用户，他的邮箱已迁移到 Exchange Online（从 Exchange On-Premise 服务器）。
• Alice 的电子邮件地址是 - [email protected]
• Alice 拥有的其他 Office 365 电子邮件地址是 - [email protected]

在 Alice 的邮箱迁移成功完成后，我们希望实现两个目标：
1.阻止 Alice 连接到她的 Exchange On-Premise 邮箱。
2.使 Alice 能够连接到她的 Exchange Online 邮箱。

注意：在分阶段迁移环境中，迁移的用户将同时拥有两个邮箱，因为分阶段迁移过程是将邮箱内容从 Exchange On-Premise 服务器“复制”到 Exchange Online，而不是“移动” ” 到 Exchange Online 的邮箱。

选项 1：允许用户使用 onmicrosoft 电子邮件地址连接 Exchange Online 邮箱

在下一节中，我们将回顾针对 Exchange 阶段迁移环境中遇到的挑战的“首选解决方案”。

我将此解决方案描述为“首选解决方案”，因为与我们将在下一节中介绍的需要编辑注册表和 HOSTS 文件的其他选项相比；目前的方法比较简单。

当使用创建新的 Outlook 邮件配置文件并提供 onmicrosoft 用户电子邮件地址的方法时，我们不需要编辑本地操作系统配置文件。

以下方法基于我们可以在 Office 365 环境中使用的一个小技巧。

默认情况下，在 Office 365 中，用户 UPN（登录名）也是他的主要电子邮件地址。

例如，Alice UPN 名称是 - [email protected] ，她的主要电子邮件地址也相同。
当 Alice 需要创建新的 Outlook 邮件配置文件时，她需要提供她的电子邮件地址 - [email protected] ，最后，Alice 将通过提供她的 Office 365 登录名向 Exchange Online 服务器表明自己的身份- [email protected]

Outlook 将使用 Alice 电子邮件地址来查找自动发现端点。 Outlook 将从 Alice 电子邮件地址中“提取”“正确部分”，并开始寻找名为 - o365info.com 或 autodiscover.o365info.com

由于自动发现基础结构指向本地 Exchange，因此 Outlook 将找到、寻址并连接到本地 Exchange 本地服务器。

在我们的场景中，我们希望避免发生这种默认行为，因为我们不希望 Outlook 寻找本地 Exchange CAS 服务器。

我们可以通过使用 Alice“Office 365 电子邮件地址”而不是她的标准电子邮件地址来调整此默认行为，以配置新的 Outlook 邮件配置文件。

在使用公共域名的 Office 365 环境中，每个 Exchange Online 收件人至少有两个电子邮件地址 -

• 使用在 Office 365 中注册的组织的自定义域名的电子邮件地址，在我们的示例中 - o365info.com
• 基于 Office 365 租户名称的附加电子邮件地址。在我们的示例中 - [email protected]

为了能够绕过查找本地 Exchange CAS 服务器的“标准自动发现过程”，我们将使用 Alice 拥有的“其他电子邮件地址”来创建 Outlook 邮件配置文件。

在我们的示例中，当 Alice 创建新的 Outlook 邮件配置文件时，Alice 将提供的电子邮件地址是 - [email protected]

当 Outlook 启动自动发现过程时，Outlook 将查找名为 - o365info2.onmicrosoft.com 的自动发现端点

此搜索将引导他到“Office 365 元素”，将他重定向到所需的目的地，即 Exchange Online 服务器。

在“新 Outlook 邮件配置文件”的最后部分，Alice 将需要提供她的凭据。在此部分中，Alice 必须提供她的 Office 365 登录名 - [email protected]

这是“令人困惑的部分”，因为我们习惯了用户
电子邮件地址和登录用户名相同的场景。

解释是，我们可以“玩”Office 365 用户电子邮件地址并提供“其他电子邮件地址”，但不能使用 Office 365 登录名。

每个 Office 365 用户只有一个登录名，但拥有多个电子邮件地址。

使用 onmicrosoft 电子邮件地址创建新的 Outlook 邮件配置文件

在以下部分中，我们将演示使用 onmicrosoft 电子邮件地址创建新 Outlook 邮件配置文件的分步过程。

注意：屏幕截图取自 Windows 8 桌面版和 Office 2013，但说明与以前版本的 Office 几乎相同。

1. 打开控制面板，找到搜索框

1. 在搜索框中输入 - 邮件

1. 在出现的 Outlook 新邮件配置文件窗口中，单击添加按钮。

1. 在配置文件名称窗口中，添加配置文件名称（在我们的示例中为 Alice）。

在电子邮件地址框中，添加“Office 365 租户”电子邮件地址，而不是“标准用户电子邮件地址”。
在我们的示例中，我们将添加以下电子邮件地址 - [email protected]

自动发现过程自动启动。
请注意，Outlook 将使用 Alice“Office 365 电子邮件地址”作为该过程的基础，其中自动发现客户端 (Outlook) 将查找名为 -
o365info2.onmicrosoft.com

如果他找不到该主机名的 IP，Outlook 将创建一个新的 DNS 查询来查找名为 - autodiscover.o365info2.onmicrosoft.com 的主机

在下面的屏幕截图中，我们可以看到一条警告消息，通知我们重定向过程。

自动发现客户端 (Outlook) 地址主机名为 - autodiscover.o365info2.onmicrosoft.com，并且该主机尝试将其“指向”另一个名为 - autodiscover-s.outlook.com

注意 - 这是 Office 365 环境中的正常过程。如果您想了解有关此过程的更多信息，请阅读文章 - Office 365 环境中的自动发现流程|第 1#3 部分 |第 29 部分#36

单击允许按钮，然后单击下一步按钮

在 Windows 安全窗口中，我们可以看到 Outlook 使用电子邮件地址 - [email protected] 作为用户名，因为 Outlook 假定电子邮件地址和用户名是相同的。

在我们的场景中，这种假设是错误的，因为在这种情况下，我们需要使用与电子邮件地址不同的用户名（Office 365 登录名）。

在我们的示例中，Office 365 用户 UPN 是 - [email protected]

创建新的 Outlook 邮件配置文件的任务已完成。

单击完成按钮。

当我们打开新的 Outlook 邮件配置文件时，我们可以看到该邮箱包含“标准 Alice 电子邮件地址”。

当查看Alice的属性时，我们可以看到“标准电子邮件地址”。默认情况下，Office 365 电子邮件地址（onmicrosoft 电子邮件地址）处于隐藏状态。

我们用于创建新的 Outlook 邮件配置文件的 Office 365 电子邮件地址不会“影响”用户邮箱的标准设置。

选项 2：通过更新本地注册表 + HOSTS 文件使用户能够连接 Exchange Online 邮箱

以下选项基于我们需要通过添加新注册表 DWORD 并将主机名和 IP 添加到 HOSTS 文件来实现的更新。

这个选项不太受欢迎，因为它更复杂，而且我们中的一些人对编辑本地注册表感到不舒服。

如果您希望或需要通过使用组策略而不是使用手动设置来实现此注册表设置，您可以阅读文章中的说明 - Outlook 自动发现决策过程 |选择正确的自动发现方法 |第 14 部分#36

在下一节中，我们将继续使用相同的场景，其中我们需要为名为 Alice 的用户创建新的 Outlook 邮件配置文件，她的电子邮件地址为 -
Alice@ o365info.com

只是一个快速提醒 -

我们的任务是为使用 Exchange 阶段迁移将其邮箱迁移到云的用户创建新的 Outlook 邮件配置文件。

为了能够将 Outlook 连接到“云邮箱”，而不是 Outlook 客户端定位和寻址本地 Exchange 的默认过程，我们希望阻止以下操作：

1. 我们想要“禁用”该选项，在该选项中，Outlook 客户端将尝试使用自动发现方法，在该方法中，他连接本地 Active Directory 环境并请求 Exchange 服务器列表。
2. 我们希望阻止 Outlook 客户端连接到 DNS 服务器来查找主机名 - autodiscover.o365info.com ，因为在我们的场景中，该主机名为“映射”到Exchange 本地服务器的 IP 地址。

我们将通过向本地 HOSTS 文件添加信息（此选项将“取代”连接 DNS 服务器的需要）并向注册表添加一个 DWORD 来实现这一“魔法”，这将禁用 Active Directory 自动发现方法。

1.编辑本地 HOSTS 文件。

在此步骤中，将 Outlook 客户端“指向”Office 365 自动发现端点，而不是指 Exchange 本地服务器的“标准自动发现端点”。

更具体地说，我们将自动发现端点 FQDN 名称映射到名为 - autodiscover.outlook.com 的 Office 365 组件的 IP 地址

听起来有点混乱？

是的，这有点令人困惑！

Office 365 和 Exchange Online 环境中的自动发现

在开始之前，先简要说明一下在 Office 365 (Exchange Online) 环境中实现自动发现服务的方式。

Office 365 提供名为 autodiscover.outlook.com 的“组件”或元素，充当 Office 365 环境中自动发现客户端的“逻辑路由器”。
能够将自动发现客户端“重定向”到此“元素”（autodiscover.outlook.com），我们在 DNS 中使用专用的 CNAME 记录，其目的是重定向自动发现客户端向名为 - autodiscover.outlook.com 的 Office 365 主机发出请求

当使用 Exchange 阶段迁移选项时，只有在所有 Exchange On-Premise 邮箱都迁移到云 (Exchange Online) 且停用现有 Exchange On-Premise 基础设施后，我们才会实施此配置。

只要 Exchange 阶段迁移继续进行，我们就无法实施此步骤。

在我们的特定场景中，我们需要为在整个迁移过程中邮箱将迁移的所有用户提供解决方案。

由于指向 Office 365 基础设施的 Outlook 等自动发现客户端的 CNAME 记录并不存在，并且当前自动发现记录指向 Exchange 本地服务器，因此我们需要找到一种方法来“阻止”以下用户的 Outlook 客户端：他们的邮箱不再使用“标准”自动发现基础设施，而是使用 Office 365 自动发现基础设施。

为 Outlook 客户端提供诱饵

在下一节中，我们将了解如何防止 Outlook 默认自动发现，其中加入域的桌面会为自动发现服务寻址本地 Active Directory。

当我们从 Outlook 客户端“拒绝”使用 Active Directory 选项来获取可用自动发现端点（本地 Exchange CAS 服务器）的名称时，Outlook 将创建一个 DNS 查询，查找名为 - o365info.com 并且，如果找不到此主机名，Outlook 将创建一个新的 DNS 查询来查找主机名 -
autodiscover.o365info.com

在我们的场景中，Exchange 服务器是

• 面向公众的 Exchange 服务器 - 意思是为外部邮件客户端提供服务。
• DNS 服务器包含一条 A 记录，该记录将主机名 o365info.com“映射”到 Exchange 本地服务器的 IP 地址。

现在，我们面临着一个两难的境地——

一方面，我们希望使 Outlook 客户端能够使用自动发现服务，通过 Office 365 自动发现基础结构来连接邮箱已迁移到 Exchange Online 的用户。

另一方面，我们无法更改公共 DNS 中的信息，因为您还记得，Exchange On-Premise 仍然为许多其他未迁移到 Exchange Online 的 Exchange
On-Premise 收件人提供服务。

听起来像是死胡同？
好消息是有一个解决方案！
通过使用一个小技巧实现的解决方案。

第 1 步 - 我们获取名为 - autodiscover.outlook.com 的 Office 365 元素的公共 IP 地址

步骤 2 - 我们使用本地 HOSTS 文件 - 将此 IP 地址（autodiscover.outlook.com 的 IP）映射到“标准自动发现端点”名称。

在我们的场景中，Outlook 客户端将使用主机名 autodiscover.o365info.com 查找自动发现端点（在我们的场景中；主机名 o365info.com 由公司公共网站使用，而不是用作 Exchange Online 自动发现服务的主机名。

更新HOSTS文件中信息的“公式”将按如下方式实现：

autodiscover.outlook.com 的 IP 地址=autodiscover.o365info.com

例如：

157.56.252.185=autodiscover.o365info.com

直到现在我们还没有回答的另一个问题是 - 什么会导致 Outlook 客户端查看 HOSTS 文件中存储的信息而不是创建标准 DNS 查询？

答案是 Windows 操作系统被编程为在创建 DNS 查询之前使用 HOSTS 文件中存储的信息。

更新本地 HOSTS 文件 - 分步说明

1. 获取主机的IP地址 - autodiscover.outlook.com

打开命令提示符

键入命令 - ping autodiscover.outlook.com

在下面的截图中，我们可以看到主机的IP地址autodiscover.outlook.com/span>

显示的 IP 地址受地理位置等几个参数的影响。

从技术上讲，您获得的 IP 地址很有可能与本示例中显示的 IP 地址不同。

此外，使用 IP 地址的静态映射并不被认为是最佳实践，但我们假设此解决方法只是阶段迁移结束之前的临时解决方案。

在开始之前，我想演示一下 Outlook 在我们进行更改之前“看到”的信息。

第 1 步 - Exchange 本地自动发现基础设施 |更新前

在我们的场景中，Alice 电子邮件地址是 - [email protected]

Outlook 客户端将尝试查找名为 - autodiscover.o365info.com 的自动发现端点

在我们的示例中，我们可以看到面向公众的 Exchange CAS 服务器的公共 IP 地址 - 212.25.80.239

在接下来的步骤中，我们将更新本地 HOSTS 文件，以便 Outlook 客户端在尝试查找此主机名时会找到不同的 IP 地址。

第 2 步 - Office 365 自动发现基础架构 |更新HOSTS文件后

在 Windows 7 和 Windows 8 中，您需要以管理员身份打开 HOSTS 文件。

要以管理员身份打开 HOSTS 文件，我们将使用操作系统文本编辑器 - 记事本。

在 Windows 8 中启动搜索菜单并输入 - 记事本，右键单击记事本图标并选择选项 - 以管理员身份运行

在记事本中，选择文件菜单和打开菜单

HOSTS 文件位于以下路径：

C:\windows\system32\drivers\etc

etc 文件夹看起来是空的，但事实并非如此。

记事本默认显示的是TXT文件，HOSTS是没有扩展名的文件。

为了能够查看 HOSTS 文件，请在文件后缀部分中选择选项 - 所有文件

选择此选项后，我们将能够查看文件列表。
选择名为 - HOSTS 的文件

注意：快速提醒一下，Alice Outlook 客户端将在 HOSTS 文件中查找主机名 - autodiscover.o365info.com

在我们的场景中，我们将获取上一步中的 IP 地址并添加主机名 - autodiscover.o365info.com

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

157.56.252.185 autodiscover.o365info.com

在文件菜单上选择保存选项或关闭 HOSTS 文件。

为了验证信息是否已成功更新，我们将进行以下测试：

Ping 主机名 - autodiscover.o365info.com

在下面的屏幕截图中，我们可以看到，现在结果就是我们输入的IP地址。

第 2 部分 - 添加新注册表 DWORD

为了能够防止 Outlook 客户端通过访问本地 Active Directory 来启动自动发现过程，并询问存储在 Active Directory SCP 中的本地 Exchange 服务器的名称，我们需要添加一个注册表项。

我们需要将一个名为 - ExcludeScpLookup 且值为“1”的新 DWORD 添加到以下注册表路径：

HKEY_CURRENT_- USER\Software\Microsoft\Office\X\Outlook\Autodiscover

请注意，值“X”代表安装在本地用户桌面上的 Microsoft Office 版本。

我们需要将“X”值替换为以下选项之一：

• 微软 Office 2007=12.0
• 微软 Office 2010=14.0
• 微软 Office 2013=15.0

添加所需的 DWORD (ExcludeScpLookup) 后，将阻止 Outlook 通过尝试访问本地 Active Directory SCP 来启动自动发现过程。

在下面的示例中，我们将在注册表中手动添加所需的 DWORD。在特定情况下，我们将为 Outlook 2013 创建必要的设置。

1. 打开运行菜单并输入 RegEdit

2. 查找自动发现密钥

在注册表中查找以下路径

HKEY_CURRENT_- USER\Software\Microsoft\Office\15.0\Outlook\Autodiscover

在自动发现“文件夹”中，右键单击白色区域，选择新选项，然后选择选项：DWORD（32 位）值。

使用名称 - ExcludeScpLookup 作为新的 DWORD

双击新的 ExcludeScpLookup，然后在值数据框中键入“1”（不带引号）

使用批处理文件更新注册表

为了您的方便，我准备了一个批处理文件，它可以更新注册表。
使用批处理文件的好处是我们可以添加额外的配置设置，例如 - 添加所有 Microsoft Office 版本所需的配置，例如如 - Office 2007、2010 和 2013。

添加与自动发现进程相关的其他注册表值。

使用批处理文件的优点的另一个示例是能够添加其他配置设置，例如禁用查找根域的自动发现步骤。

自动发现客户端（例如 Outlook）将始终在非 Active Directory 环境中通过使用电子邮件地址 SMTP 域名搜索自动发现端点来启动自动发现进程。

大多数时候，域名不会映射到 Exchange 基础结构，并且此默认自动发现阶段，只需为自动发现过程添加不需要的时间。

为了能够取消对根域名的默认自动发现搜索，我们可以使用 DWORD 值 - ExcludeHtppsRootDomain

我创建的批处理文件 - Add-Outlook-reg-All-Office-versions.bat 将通过添加以下内容来更新注册表所有可用 Office 版本所需的密钥，例如 Microsoft Office 2007 的 12.0 密钥、Microsoft Office 2010 的 14.0 密钥等。

批处理文件包含一个注册表命令，该命令将添加到注册表项 (DWORD) - ExcludeScpLookup 和 ExcludeHtppsRootDomain
如下截图中，我们可以看到
Add-Outlook-reg-All-Office-versions.bat文件的内容。

要激活 Add-Outlook-reg-All-Office-versions.bat 文件，您可以打开命令提示符并拖动 Add-Outlook-reg-All-Office-versions.bat文件进入命令行窗口并按 Enter。

在下面的屏幕截图中，我们可以看到有关 Add-Outlook-reg-All-Office-versions 添加的每个值的信息。 bat 文件。

为了能够查看添加到注册表中的“新值”，请从“运行”菜单中打开注册表编辑器并键入 - RegEdit

在下面的屏幕截图中，我们可以看到运行Add-Outlook-reg-All-Office-versions.bat的结果强>文件

我们可以看到 Add-Outlook-reg-All-Office-versions.bat 批处理文件添加了所有可用 Microsoft Office 版本（12.0、14.0、15.0）的密钥

查看注册表路径时：

HKEY_CURRENT_- USER\Software\Microsoft\Office\15.0\Outlook\Autodiscover

我们可以看到有两个“新 DWORD”值 - ExcludeScpLookup 和 ExcludeHtppsRootDomain

我们可以看到数据值为：“1”
值“1”的意思是：启用或激活。

将现有 Exchange 本地服务器邮箱转换为 MEU

从技术上讲，大多数时候我更喜欢“服务器端解决方案”而不是“客户端解决方案”，因为在一个中央位置（Exchange 本地服务器）创建所需的配置设置的概念，而不是在每个位置实施配置设置迁移后的用户桌面更加有效。

“服务器端解决方案”的概念是，在阶段迁移过程中邮箱已迁移到 Exchange Online 的 Exchange 用户的信息将继续存在于 Exchange 本地服务器中。

主要问题是 Exchange 本地用户邮箱将不再作为标准用户邮箱存在，而是作为 MEU 存在。

当邮箱迁移到 Exchange Online 的组织用户连接 Exchange 本地服务器（即 Exchange 本地 CAS 服务器）时，会向收件人发送重定向通知，并将其指向他的“云邮箱”（他的 Exchange Online 邮箱）。

“重定向”机制应按以下方式实现：

1. 我们需要将信息从“迁移的用户邮箱”复制到临时位置。
2. 删除 Exchange 本地邮箱 - 在分阶段迁移中，Exchange 本地邮箱内容将被复制而不是移动（Exchange 本地邮箱不会被删除）。
   为了能够避免用户出现以下情况：同时有两个邮箱，我们需要删除“Exchange on-Premises 邮箱”
3. 创建新的 MEU - Exchange 本地服务器需要“知道”如何处理邮箱已迁移到 Exchange Online 的用户的请求。这些用户“不知道”他们的邮箱已迁移。我们需要实施一个程序，使 Exchange 能够“识别”这些用户，然后向他们的 Exchange Online 邮箱提供所需的重定向消息。
   Exchange 本地服务器通过为邮箱已迁移到 Exchange Online 的每个用户创建邮件用户 (MEU) 来实现“识别”此用户的方式。
4. 将信息从“已删除的邮箱”复制到新的 MEU - MEU 对象需要填充“Office 365 收件人电子邮件地址”。
   每次用户将其邮箱迁移到 Exchange Online 时将连接 Exchange 本地服务器，服务器将使用收件人“365 电子邮件地址”（onmicrosoft 电子邮件地址）响应重定向消息）。