阶段迁移、交换和自动发现基础设施 |第 1#2 部分 |第 35 部分#36

在本文中，我们将回顾 Exchange 阶段迁移的主题以及为邮箱迁移到云的用户配置新的 Outlook 邮件配置文件的问题。

当前的文章涉及“理论部分”，其中我们将回顾 Exchange 阶段迁移的特殊特征，以及我们需要解决的“问题”，以便能够创建一个新的 Outlook 配置文件，将迁移的用户连接到他们的 Exchange Online 邮箱。

下一篇文章将介绍可以实施的建议解决方案。

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

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

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

当使用 Exchange 阶段迁移选项时，“最终目的地”是将所有现有 Exchange 本地基础设施迁移到“云邮件”基础设施，但是，顾名思义，迁移过程将分“阶段”实施。

Exchange 阶段迁移的主要特征之一是邮件迁移过程将持续较长的一段时间，例如几周甚至几个月。

在上述时间内，组织邮件基础结构将“分散”在整个 Exchange 本地基础结构和 Exchange Online 基础结构中，直到邮件迁移完成。

用户邮箱物理位置|交换阶段迁移

当我们使用 Exchange 阶段迁移来迁移特定 Exchange 本地用户邮箱时，术语“邮箱迁移”的实际含义是，用户邮箱为 复制到云 (Exchange Online)。

结果是特定用户迁移完成后；同时有两个用户邮箱。

• 托管在 Exchange 本地基础结构上的一个用户邮箱。
• 托管在 Exchange Online 基础结构上的一个用户邮箱。

在这种情况下，我们希望将其邮箱迁移（复制）到 Exchange Online 的用户“连接”，并避免将用户连接到其“之前的 Exchange
on-Premises”邮箱。

当我们使用 Exchange 阶段迁移选项时，在将用户邮箱迁移到 Exchange Online 后，我们需要创建一个新的 Outlook 邮件配置文件，它将将用户连接到他的 Exchange Online 邮箱。

创建新的 Outlook 邮件配置文件 |需要将用户重定向到他们的云邮箱

主要问题是，当我们创建新的 Outlook 邮件配置文件时，Outlook 会自动定位 Exchange on-Premises 并连接到他的 Exchange on-Premises 邮箱。

Outlook 客户端“不知道”我们在“云”（Exchange Online）中拥有用户邮箱的副本，并且现在他需要连接到他的“云邮箱”！

我们的主要挑战是 - 找到一种方法来“告诉”Outlook 客户端如何连接到他的“新的 Exchange Online 邮箱”而不是现有的 Exchange 本地邮箱。

完成此任务的“正式”方法是 - 通过使用 Exchange 内置机制，将自动发现客户端重定向到“云基础设施”（位于 Exchange Online 的用户邮箱）。

为了能够实施“重定向机制”，我们需要将 Exchange 本地用户邮箱转换为邮件联系人，其中包括收件人在 Exchange Online 基础结构中拥有的电子邮件地址。

从技术上讲，这个“对话过程”可以通过执行一组命令来手动实现，但实际上，基本假设是我们将使用某种解决方案来帮助我们自动化数十甚至数百个迁移的用户邮箱的对话过程。

这个过程的“自动化”可以通过使用一组PowerShell脚本来实现，这将帮助我们执行将Exchange本地邮箱转换为MEU（启用邮件的用户）的对话过程。

此 PowerShell 脚本的目的是：

1. 删除邮箱已迁移到云的用户的 Exchange 本地邮箱。
2. 复制收件人的电子邮件地址。
3. 创建一个新的 MEU（启用邮件的用户），其中包含其邮箱迁移到云的用户的电子邮件地址 +“onmicrosoft”电子邮件地址。

完成此步骤后，当我们创建新的 Outlook 邮件配置文件时，Outlook 将默认寻址 Exchange 本地服务器，但这一次，因为 Exchange 本地服务器不托管用户邮箱，因此 Exchange 本地服务器场所将“理解”他需要将邮件客户端重定向到他的“云邮箱”（onmicrosoft 电子邮件地址）。

作为自动发现过程的一部分，本地 Exchange 会将重定向消息发送到 Outlook 客户端，并且 Outlook 将通过解决以下问题再次启动自动发现过程： Exchange Online 邮件基础设施。

听起来有点复杂？

是的我同意。

根据我的经验，这种方法的最大障碍是“删除Exchange本地邮箱”的操作对于大多数Exchange管理员来说听起来并不“正确”，而且大多数时候，Exchange管理员觉得他们需要找到另一种方法来完成以下任务：将迁移的用户连接到他们的 Exchange Online 邮箱，而不需要删除现有的 Exchange 本地邮箱。

本篇文章和下一篇文章的重点是回顾与使用“绕过”“正式方法”的方法将 Outlook 客户端连接到 Exchange Online 邮箱的主题相关的 Exchange 阶段迁移的特殊特征。需要删除现有的 Exchange 本地邮箱。

交换阶段迁移特定章程

在我们开始描述我们可以实施的可选解决方案 - 使用 Exchange 阶段迁移时将 Outlook 邮件客户端连接到其 Exchange Online 邮箱，以免查看 Exchange 阶段迁移环境的基本字符：

1.复制而不是移动
Exchange 阶段迁移基于一个概念，即用户邮箱从 Exchange 本地服务器复制到 Exchange Online 服务器。其含义是，从技术上讲，参与迁移过程的每个用户都有两个邮箱。

一个邮箱托管在 Exchange 本地服务器上，另一个邮箱托管在 Exchange Online 服务器上。

2.自动发现“指针”
在实施 Exchange 阶段迁移时，我们不会更新现有的 DNS 基础设施。

Exchange 本地基础架构将继续为现有 Exchange 本地服务器客户端提供服务。
只要阶段迁移继续进行，自动发现基础架构将继续指向 Exchange 本地基础架构。

阶段迁移场景|迁移用户的重复身份

在下图中，我们可以看到，每个迁移到云端的用户都拥有“双重身份”+双邮箱。
例如，邮箱迁移到云端的名为Alice的用户，在本地 Active Directory + Windows Azure Active Directory 中的。
关于 Exchange 基础结构，Alice 有一个托管在 Exchange 本地服务器上的邮箱，同时还有一个托管在 Exchange Online 上的邮箱服务器。

Exchange 本地基础设施 |默认自动发现基础架构

如前所述，当我们实施 Exchange 阶段迁移时，自动发现基础架构保持不变。这意味着由 Exchange 客户端（例如 Outlook）执行的自动发现进程将“引导”Exchange 客户端到 Exchange 本地服务器。

乍一看，这个过程似乎是合乎逻辑的，但仔细一看，我们可以看到一个可能的问题。

将 Exchange 本地邮箱迁移到 Exchange Online 后，我们需要为其邮箱迁移到 Exchange Online 的用户创建新的 Outlook 邮件配置文件。

如果我们启动“新的 Outlook 邮件配置文件”过程，Outlook 客户端将使用标准的自动发现过程，但问题是自动发现过程会将自动发现客户端“引导”到现有的 Exchange 本地服务器，而不是交换基础设施。

在下图中，我们可以看到名为 Alice 的用户如何使用电子邮件地址 - [email protected] 找到她的 Exchange CAS 服务器。
如果 Alice 尝试从内部网络查找其 Exchange CAS 服务器，Alice 将使用包含 Exchange CAS 服务器内部名称的 Active Directory SCP 来查找 Exchange CAS 服务器 (exo1.o365info在我们的场景中为 .local）。

如果 Alice 尝试从外部网络定位其 Exchange CAS 服务器，Alice 将使用在非 Active Directory 环境中实现的自动发现过程通过查找主机名（例如 - autodiscover.o365info.com

在我们的场景中，对主机名的查询 - autodiscover.o365info.com 会将 Alice 引导至面向公众的本地 Exchange 服务器。

阻止 Outlook 客户端连接 Exchange 本地 CAS 服务器

本节的标题看起来有点奇怪，但这正是我们需要并且想要做的。

Exchange阶段迁移过程中最值得注意的任务之一是我们需要“强制”邮箱已经迁移到云端的用户不要连接Exchange本地CAS服务器，而是连接Exchange在线服务器。

出现Outlook客户端连接“错误的Exchange服务器”的问题，原因很简单——“迁移的用户”不知道自己的邮箱迁移到了云端。

从自动发现客户端的角度来看，自动发现基础结构仍然“将他指向”Exchange 本地 CAS 服务器。

从技术上讲，他的邮箱位于 Exchange 本地服务器上，因为如果您还记得的话，在使用阶段迁移时，Exchange 本地邮箱会复制到“云”（Exchange Online），而不是“移动”到云，例如使用混合环境时。

在下图中，我们可以看到使用阶段迁移选项时邮箱迁移过程的示例。

我们可以看到，邮件迁移编译成功后，“Alice邮箱”将存在于两个不同的地方——Exchange本地服务器+Exchange Online服务器。

注意：目前，没有“Exchange 内置”解决方案可以帮助我们通过删除“Exchange 本地部署”来“清理”Exchange 本地服务器的踪迹。服务器邮箱”并“通知”用户其邮箱已迁移到“云端”。

阶段迁移用户邮箱综合症

组织用户报告了一个奇怪的现象，发送给他的邮件没有到达他的邮箱，但他可以向外部收件人发送电子邮件。

这个问题的简单答案是——在实施阶段邮件迁移时，邮件路由会更新，因此，发送到包含“标准公共电子邮件地址”的收件人的每封邮件都会自动转发到“云端”（ Exchange Online）使用用户 onmicrosoft 电子邮件地址。

“自动转发”机制，不会留下用户 Exchange 本地邮箱的副本，而是将原始电子邮件“移动”到云端（Exchange Online 用户邮箱）。

结果是，邮箱迁移后，发送给特定用户的每封邮件都将“驻留在”Exchange Online 邮箱中。

如果我们没有实施所需的准备工作，“迁移的用户”将继续连接到其 Exchange 本地邮箱。

此 Exchange 本地邮箱是“合法邮箱”，因此，用户可以继续向收件人发送电子邮件，但发送给用户的邮件会重定向到他的“Exchange Online 邮箱”，而不是他的 Exchange本地邮箱！

Stage 迁移环境中 Outlook 客户端的可选解决方案

因此，现在，在我们意识到 Outlook 邮件客户端将继续连接到其 Exchange On-Premise 邮箱而不是 Exchange Online 邮箱这一可能的问题后，明显的问题是 - 我们可以采取哪些措施来解决此问题？

解决方案的可用选项分为两种类型：服务器端和客户端。

1.阶段迁移|服务器端解决方案

描述为“服务器端”的解决方案是通过使用以下过程来实现的。

• 删除 Exchange 本地邮箱
• 创建一个新的启用邮件的用户 (MEU)，其中包括迁移的用户主电子邮件地址，并且在“外部电子邮件地址”中，值使用其他电子邮件地址，即 Office 365 onmicrosoft 电子邮件地址。

听起来有点令人困惑？
事实上，这确实令人困惑。
如前所述，当我们使用阶段迁移时，Exchange On-Premise 邮箱会被复制到云端。

在我们验证邮箱已成功迁移（复制）到 Exchange Online 后，从技术上讲，不再需要 Exchange On-Premise 邮箱。

阶段迁移过程不会自动删除 Exchange On-Premise 邮箱。

假设我们阅读此信息后，决定实施删除 Exchange On-Premise 邮箱的过程。

知道接下来会发生什么吗？

如果我们删除用户邮箱，当我们尝试创建新的 Outlook 邮件配置文件时，Outlook 邮件向导将自动连接到 Exchange On-Premise 服务器，因为如前所述，在阶段迁移中，自动发现基础架构会保持“指向”到 Exchange 本地基础设施。

在这种情况下，Outlook 客户端将设法连接 Exchange On-Premise 服务器，但由于用户邮箱已删除，因此连接尝试将失败。

不要忘记，Exchange On-Premise 服务器不知道或“理解”用户邮箱也被复制到云（Exchange Online），因此； Exchange On-Premise 服务器不知道他需要将收件人重定向到他的“云邮箱”。

如果我们只删除 Exchange On-Premise 邮箱，而没有进行其他准备工作（例如创建新的启用邮件的用户），则会导致邮件流出现另外两个问题，因为 Exchange On-Premise 负责路由发送到用户的邮箱已迁移到他的“Office 365 电子邮件地址”。

如果我们“仅删除”Exchange On-Premise 用户邮箱，Exchange On-Premise 将不知道如何处理将发送给特定用户的邮件。

我们需要实施的第二个操作是创建一个新的启用邮件的用户 (MEU)，该用户将充当迁移邮箱的“代表”，并将“Office 365 收件人电子邮件地址”配置为- 外部电子邮件地址。

删除 Exchange On-Premise 邮箱并创建新的启用邮件的用户 (MEU) 后，每次 Outlook 客户端尝试连接到 Exchange On-Premise 服务器时，Exchange On-Premise 都会向 Outlook 客户端提供他的“新电子邮件地址”。

例如，Alice 是一位用户，她的邮箱已迁移到 Exchange Online。

当 Alice 连接 Exchange On-Premise 时，由于 Alice 不再拥有邮箱，并且 Exchange On-Premise 有一个具有 Alice 详细信息的启用邮件的用户 (MEU)，因此 Exchange On-Premise 将“理解”他需要提供Alice 她的“Office 365 电子邮件地址”。在我们的场景中 - [email protected]

注意： 这种“服务器端解决方案”可以通过使用 PowerShell 脚本来实现，我们可以从 Office 365 社区网站下载该脚本，或者附加选项是编写 PowerShell 或实现手动过程。

如果我们实施了“服务器端”解决方案，即删除 Exchange 本地用户邮箱 + 使用 Office 365 电子邮件地址创建启用电子邮件的用户，则将实施以下方案：

当外部邮件客户端尝试创建新的 Outlook 邮件配置文件时，Outlook 客户端将访问本地 Active Directory SCP 并获取可用 Exchange 服务器（本地 Exchange 本地服务器）的名称。

当 Outlook 客户端寻址本地 Exchange CAS 服务器时，Exchange 将“看到”该用户没有邮箱，而是有一个启用电子邮件的用户。

Exchange 服务器将“理解”他需要向 Outlook 客户端发送一条“重定向消息”，其中包含 Office 365 电子邮件地址（在我们的场景中 -
Alice@o365info2. onmicrosoft.com

Outlook 客户端了解，现在他需要使用从新电子邮件地址提取的域名重新启动自动发现过程。

在我们的场景中，Outlook 将尝试查找名为 - o365info2.onmicrosoft.com 的主机，如果找不到这样的主机名，他将尝试在 DNS 中查询以下主机名 - autodiscover.o365info2.onmicrosoft.com

2.阶段迁移| “客户端”解决方案

在“客户端”分类解决方案下，我们将实施使我们能够更改默认 Outlook 标准 Outlook 行为的解决方案。
我们要更改的“默认 Outlook 标准 Outlook 行为”是 - 标准自动发现流程，在哪个 Outlook 客户端将找到并连接本地 Exchange CAS 服务器。

为了演示标准阶段迁移场景，我们使用以下示例：

组织公共域是 - o365info.com
名为 Alice 的用户，其电子邮件地址为 - [email protected] ，已迁移到云端。

为了能够将 Alice 连接到他的 Exchange Online 邮箱，我们需要找到一种解决方案来阻止她的 Outlook 客户端使用“标准自动发现流程”，该流程会将 Outlook 客户端“引导”到 Exchange On-Premise 服务器。

内部自动发现流程

在下图中，我们可以看到当我们需要为邮箱迁移到“云”（Exchange Online）的用户创建新的 Outlook 邮件时所面临的“挑战”。

默认情况下，在 Active Directory 环境中，自动发现客户端将在 Active Directory 中查询本地 Exchange CAS 服务器的名称。

在我们的场景中，我们希望阻止 Outlook 客户端连接本地 Active Directory。

假设我们找到了一种“阻止”Outlook 客户端连接本地 Active Directory（编号 1）的方法。

默认情况下，Outlook（自动发现客户端）将“恢复”为从收件人电子邮件地址中提取域名并使用该域名作为自动发现端点的主机名的方法。

在我们的场景中，Outlook 客户端应该在本地 DNS 中查询名为 - o365info.com（编号2）的主机，如果没有找到IP，自动发现客户端将查找名为 - autodiscover.o365info.com 的主机

理论上，DNS 服务器将提供面向公众的 Exchange CAS 服务器的公共 IP 地址。
同样，在我们的场景中，我们希望阻止 Outlook 连接本地 Exchange CAS 服务器，因为我们希望 Outlook 启动自动发现该过程将“引导”他到“云 Exchange 服务器”（编号 3）。

外部自动发现流程

在下图中，我们可以看到组织用户 (Alice) 想要创建新的 Outlook 邮件配置文件的基础结构，但这一次；用户位于公共网络中。

不同之处在于，现在用户无法使用在 Active Directory 环境中实现的自动发现方法。

在我们的场景中，Outlook 客户端应该在公共 DNS 中查询名为 - o365info.com（编号1）的主机，如果没有找到IP，自动发现客户端将查找名为 - autodiscover.o365info.com 的主机

公共 DNS 服务器将提供面向公众的 Exchange CAS 服务器的公共 IP 地址。
同样，在我们的方案中，我们希望阻止 Outlook 连接本地 Exchange CAS 服务器，因为我们希望 Outlook 启动自动发现过程这将“引导”他到“云 Exchange 服务器”（编号2）。

“客户端”解决方案

阶段迁移环境中的“客户端”解决方案包括两个选项：

选项 1：更新本地配置文件

在此选项中，我们通过编辑操作系统组件（本地桌面注册表和本地 HOSTS 文件）来更改 Outlook 客户端的默认行为。

1. 注册表更新将包括一个新的 DWORD，它将阻止 Outlook 客户端在 Active Directory 环境中使用标准自动发现方法。
2. HOSTS 文件更新将包括一点“作弊”，其中我们将自动发现主机名映射到 Office 365 组件的 IP 地址，该组件会将自动发现客户端重定向到 Exchange Online 服务器。

选项 2：使用 onmicrosoft 电子邮件地址

每个拥有 Exchange Online 邮箱的 Office 365 用户至少有两个
电子邮件地址：

“公共电子邮件地址”，例如 - [email protected]
以及 Office 365 电子邮件地址。

Office 365 电子邮件地址基于 Office 365 宗旨名称 + 域后缀 - onmicrosoft.com

在我们的示例中，Alice 的 Office 365 电子邮件地址是 - [email protected]

在我们想要阻止用户连接到本地 Exchange 服务器的情况下，我们可以使用一个小技巧，即在创建新的 Outlook 邮件配置文件时提供 Office 365 电子邮件地址，而不是“标准电子邮件地址”。邮件地址 ”。

例如，在我们的场景中，当我们需要为用户 Alice 创建一个新的 Outlook 邮件配置文件（他的邮箱已迁移到 Exchange Online）时，如果我们将使用默认电子邮件地址 - [email protected]，自动发现过程将使用域名 - o365info.com，结果将是 - Outlook 将连接到本地 Exchange CAS 服务器。

如果我们想要“告诉”Outlook 我们想要实施不同的自动发现过程，我们将使用 Alice 拥有的“其他”电子邮件地址 -
Alice@o365info2。 onmicrosoft.com

当我们使用此电子邮件地址 ([email protected]) 创建新的 Outlook 邮件配置文件时，自动发现过程将通过以下方式实现 -

Outlook 客户端将创建一个 DNS 查询，查找名为 - o365info2.onmicrosoft.com 的自动发现端点，如果找不到此类主机的 IP 地址，则自动发现过程将“继续”进行其他 DNS 查询，寻找名为 - autodiscover.o365info2.onmicrosoft.com 的自动发现端点

主机 - autodiscover.o365info2.onmicrosoft.com 是一个 Office 365 组件，它将 Outlook 客户端重定向到其 Exchange Online 邮箱。