直接转换邮件迁移、本地 Exchange、先决条件 | Office 365 直接转换邮件迁移 - Exchange 本地前提要求 .com

---

我们无法启动 Office 365 直接转换邮件迁移过程的最常见原因是 - 缺乏 Exchange 本地前提要求。
本文的主要目标是：

1. 提供 Exchange 本地先决条件清单
2. 详细解释每个 Exchange 本地前提要求的原因
3. 为您提供工具，帮助您验证 Exchange 本地前提要求是否存在

Office 365 邮件迁移 群体之门。

大多数 Office 365 邮件迁移项目的共同点就是我所说的“赛马群”。

邮件迁移项目执行仓促；我们渴望“按下邮件迁移按钮”，没有任何准备，也没有任何关于“无聊主题”的先验知识，例如 - 切换邮件迁移预先要求、强制性要求、最佳实践等。

万一运气好的话，切换邮件迁移过程会成功运行，但很多时候，“幸运女士”没有来，切换邮件迁移过程没有启动！

切换邮件迁移先决条件是“小事”，它决定了顺利、高效地将邮件迁移到云的项目与我们无法满足邮件迁移到 Office 365 截止日期的情况以及内存的情况之间的差异。迁移到Office 365，却留下了苦涩的味道。

当前文章的范围

Office 365 切换邮件迁移阶段

使用直接迁移将邮件迁移到 Office 365 的项目包括三个主要阶段：

1. 迁移前任务
2. 迁移过程
3. 迁移后任务

在本文中，我们仅关注第一阶段，即为 Office 365 直接转换邮件迁移过程准备环境和邮件基础设施。

Office 365 切换邮件迁移前置要求的分类

Office 365 直接邮件迁移的“第一阶段”可以包括几个部分，例如了解直接邮件迁移的具体特征、建立实验室来测试设计的迁移过程以及验证是否满足所有预先要求。

“切换邮件迁移前置要求”阶段也可以分为不同的部分，例如：

• 用户桌面前置要求
• 网络基础设施先决条件
• Office 365 基础设施先决条件
• Exchange 本地部署前提要求

在本文中，我们将仅涉及 Exchange 本地前提要求的主题

Office 365 不同类型的邮件迁移

Office 365 提供三种内置类型的来自 Exchange 本地服务器的邮件迁移选项：

1. 直接邮件迁移
2. 阶段邮件迁移
3. Exchange 混合邮件迁移

当前文章专门讨论 Office 365 直接转换邮件迁移和 Exchange 本地服务器先决条件。
我们应该知道的重要事情是相关的“Exchange
本地服务器先决条件” Office 365 切换邮件迁移与 Office 365 邮件迁移的其余部分相关且几乎相同。

Exchange 本地公开可用性因素

所有不同类型的 Office 365 邮件迁移选项都规定了 Exchange 本地服务器需要具有“公共存在”的强制性需求，可翻译为：

1. 公共 IP 地址。
2. 公开名称。
3. 公共证书。

邮件迁移协议

关于“邮件迁移协议”的主题，Office 365 邮件迁移方法按以下方式分类：

Office 365 切换邮件迁移和 Office 365 阶段邮件迁移是通过使用 Outlook Anywhere 协议实现的。 Exchange Online 服务器将使用 RPC over HTTPS (Outlook Anywhere) 协议“获取”Exchange 本地邮箱。

Office 365 Exchange 混合邮件迁移是通过 Exchange 本地 EWS（Exchange Web 服务）界面实现的。换句话说，Exchange 混合环境不需要使用 RPC over HTTPS (Outlook Anywhere) 协议进行邮件迁移。

“邮件迁移”的确切含义是什么？

在我们继续描述 Office 365 直接转换邮件迁移之前，我们必须就术语“邮件迁移”的定义达成一致，这一点很重要。

关于“邮件迁移”一词，我们脑海中出现的第一个联想是——Exchange 邮箱的迁移。

这种关联部分正确，因为 Exchange 邮箱没有自己的生命周期。

含义是 Exchange 邮箱必须“附加”或“连接”到用户帐户。

Office 365 切换邮件迁移过程旨在实现一个迁移过程，该过程将创建两个独立的“迁移通道”。

1.用户\组账户迁移流程

一种迁移渠道是将用户和组帐户从本地 Active Directory 复制到 Windows Azure Active Directory。

2. Exchange 本地邮箱迁移流程

第二个迁移通道是 Exchange 邮箱过程，其中所有
Exchange 本地邮箱 (100%) 都将复制到 Exchange Online 基础结构。

Office 365 切换邮件迁移 - 用户和邮箱迁移

我想强调的其他细节是术语“迁移”被翻译为复制操作而不是移动操作。

当我们说 Office 365 转换邮件迁移时，“转换”一词可能会产生误导，因为实际上，我们不会“切断”Exchange 本地邮箱（移动），而是复制将 Exchange 本地邮箱内容传输到 Exchange Online 邮件服务器。

在整个 Office 365 割接邮件迁移过程中，会同时出现两个用户邮箱。

存储在本地 Exchange 中的“原始 Exchange 邮箱”以及存储在 Exchange Online 中的用户邮箱的副本。

Exchange 本地服务器有哪些强制性先决要求？

稍后，我们将详细回顾 Exchange 本地服务器在实施 Office 365 直接转换邮件迁移时需要支持的每项“前提要求”。

简而言之，最重要和强制性的 Exchange 本地前提要求是：

1. 公开可用性
2. 支持 Outlook Anywhere 选项。

为了能够简化直接邮件迁移过程，我们可以使用一个比喻，其中 Exchange Online 服务器伸出手，敲打您的组织网络并要求获取所有本地 Active Directory 用户、组和联系人的副本，以及存储在 Exchange 本地服务器中的所有用户邮箱。

与“Office 365”通信的组织代表是
Exchange 本地服务器。

为了能够在 Office 365 和您的 Exchange 本地服务器之间启用此通信通道，Exchange 本地服务器需要具有公共可用性。

术语“公共可用性”被翻译成三个不同的组成部分：

1. 公共 IP - 可供外部主机访问的公共 IP 地址。
   Exchange 本地公共 IP 地址将“映射”到 Exchange 本地公共名称。
2. 公共名称 - 更准确的术语是 FQDN（完全限定域名）。 Exchange 本地服务器将需要使用公共名称，外部主机（例如 Exchange Online）使用该公共名称来寻址我们的 Exchange 本地服务器。例如 - o365info.com
3. 公共证书 - 从技术上讲，服务器证书与 Exchange 本地服务器的通信过程没有直接关系，因为我们真正需要的只是一个公共 IP 地址。我们之所以用“公共可用性”一词“包装”公共证书，是因为需要公共有效服务器证书是 Office 365 直接转换邮件迁移的强制要求。

切换邮件迁移 | A阶段

Office 365 直接转换邮件迁移从“Office 365 端”（Exchange Online 管理门户）初始化，需要定位 Exchange 本地服务器并进行通信。

Exchange Online 和本地 Exchange 之间的通信通道必须实现为安全通信通道（使用 SSL 加密）。

建立通信通道的目的是 - 从本地 Active Directory 和 Exchange 本地服务器复制信息。

1. 找到我们的 Exchange 本地服务器

如前所述，Office 365 切换邮件迁移过程是从 Office 365 端“伸出手”并访问 Exchange 本地服务器进行初始化的。

为了使 Office 365 直接转换邮件迁移能够找到我们的 Exchange 本地服务器，我们需要向 Office 365 直接转换邮件迁移提供所需的信息。

首选\推荐的方法是 - 使用自动发现过程。
鉴于我们的 Exchange 本地服务器具有自动发现所需的设置，当我们创建转换邮件迁移批处理时，Office 365 将使用以下“域名”我们将提供用于定位“我们的”Exchange 本地服务器的电子邮件。

如果我们的 Exchange 本地服务器不支持自动发现或自动发现设置不正确，我们可以手动向 Office 365 提供有关 Exchange 本地服务器的所需信息。

2. 与 Exchange 本地服务器通信。

Office 365 转换邮件迁移找到我们的 Exchange 本地服务器后，他需要与 Exchange 本地服务器“对话”，以获取现有本地 Active Directory 用户和 Exchange 本地邮箱的副本。

Office 365 端的通信通道的强制要求是使用 HTTPS 协议（端口 443）来实现通信。

Exchange 本地服务器需要通过提供有效的公共证书来识别自己的身份。

切换邮件迁移 | B阶段

Office 365 与本地环境（Exchange on-Premises）之间的通信通道通过 SSL 协议实现。

实际的迁移过程是通过RPC协议来实现的。 RPC 协议位于 SSL 协议“之上”。

这种实现被描述为封装（使用附加协议的协议的方法），在基于 Exchange 的环境中，这种方法被描述为 RPC over HTTPS。

此方法的友好名称是 - Outlook Anywhere。

1. Exchange on-Premise 和 Outlook Anywhere

为了能够实现直接邮件迁移，Exchange 本地部署需要支持 Outlook Anywhere。

注意： Outlook Anywhere 选项依赖于本地 Exchange 的“公共可用性”以及对服务器证书的需求。

Outlook Anywhere 并不规定需要公共证书，但 Office 365 直接转换邮件迁移却规定了这一点。

2. 在线交流|所需的用户凭据

Office 365 直接转换邮件迁移基于以下假设：我们将能够复制所有本地 Active Directory 内容（不是所有内容，而是大部分内容）和所有 Exchange 本地邮箱。

当我们定义 Office 365 直接转换邮件迁移设置（迁移终结点）时，我们需要提供用户名 + 用户凭据，当 Office 365 直接转换邮件迁移连接我们的 Exchange 本地服务器时，将使用该用户名和用户凭据。

我们将为 Office 365 直接转换邮件迁移提供的“用户”的技术术语是 -迁移管理员。

对于直接迁移，迁移管理员帐户必须是：

本地组织中 Active Directory 中的 Domain Admins 组的成员。

或者

为每个本地邮箱分配FullAccess 权限。

或者

已分配对存储用户邮箱的本地邮箱数据库的接收为权限。

交换本地证书

Office 365 直接转换邮件迁移的强制要求是 Exchange 本地服务器需要使用公共有效证书。

在许多情况下，这种强制性需求会让负责 Office 365 直接转换邮件迁移过程的人员感到烦恼，因为并非所有组织都使用有效的公共证书。另一种可能的情况是组织使用 Exchange 本地证书，但使用公共证书（不是由公共证书颁发机构注册的证书）。

问题1：是否有办法在不使用 Exchange 本地公共有效证书的情况下实施 Office 365 直接转换邮件迁移？

A1：不，这是强制性要求

Q2：“公开有效证书”是什么意思？

A2：

• “公共证书”的含义是——从知名公共CA（证书颁发机构）购买的证书。
• “有效证书”的含义是：具有有效有效期的证书+有效的主机名或有效的域名。

Q4：为什么割接邮件迁移“坚持”使用公共证书？

A4：Office 365 直接转换邮件迁移需要验证 Exchange 本地服务器是否具有公共证书，主要原因有两个：

1. 数据隐私和数据完整性

Office 365 切换邮件迁移是在被视为非私有或非安全环境的公共网络基础设施上实施的。为了能够满足最基本的数据隐私和数据完整性的安全需求，Office 365 割接邮件迁移是通过 SSL 协议来实现的。 SSL协议的实现需要服务器证书。

注意：从技术上讲，SSL 并没有对公共证书提出强制要求，甚至私有证书也“可以”。

2. 认证和识别的需要

尽管我们使用术语“我们的 Exchange 本地服务器”，但 Office 365 并不真正了解或信任我们的 Exchange 本地服务器。

使用 SSL 时，我们用于满足验证特定实体身份的需求的机制是使用由公共 CA 注册的公共证书。

当 Office 365 直接转换邮件迁移连接 Exchange 本地服务器时，Office 365 将需要毫无疑问地确保代表特定域的 Exchange 本地服务器确实是他所声称的服务器。

当本地 Exchange 显示由 Office 365 信任的 CA 提供的有效公共证书时，即可实现证明 Exchange 本地服务器身份的功能。

问题5：Exchange 本地服务器可以使用什么类型的公共证书？

A5：有效的服务器证书可以是

SAN（主题备用名称）证书或通配符证书。

案例 1 - 使用 SAN 证书

SAN 证书包含有关有权使用该证书的主机的信息。有关该主机的信息显示为 FQDN（完全限定域名）。

在基于 Exchange 的环境中，该 SAN 证书需要包含至少两个主机 (FQDN) 名称：

1. Exchange 本地服务器公共名称。
2. 代表特定域名的自动发现主机名。

例如：在我们的具体场景中，组织域名为 o365info.com

• Exchange 本地服务器公共名称是 - mail.o365info.com
• 自动发现主机名是 - autodiscover.o365info.com

情况 2 - 使用通配符证书

如果我们使用通配符证书，则该证书“覆盖”特定域名中的所有主机。

例如 - 域名的通配符证书将包含以下信息 - *.o365info.com

出现在该域名“下方”的所有主机名（例如“mail”（我们的 Exchange 本地服务器的主机名）或自动发现）均被视为有权使用该证书的有效主机名。

验证我的 Exchange 本地服务器证书

如前所述，Office 365 直接转换邮件迁移的强制要求是 Exchange 本地服务器将使用公共有效证书。

在下面的部分中，我将简要回顾一下“标准”SAN 公共证书并显示我们需要检查的证书部分。

证书日期验证

服务器证书需要验证的最基本参数是证书验证日期的主题。

当我们选择常规选项卡时，我们可以看到名为 - 有效期自的部分，即特定证书的有效期截至2018年2月2日

证书和名为的主机

在我们的具体场景中，组织域名是 - o365info.com

Exchange 本地服务器公共主机名是 - mail.o365info.com
o365info.com 域的自动发现记录是 - autodiscover .o365info.com
当我们选择详细信息选项卡时，我们可以看到名为 - 主题备用名称的部分，即包含在SAN 证书。

在我们的场景中，我们寻找

• 有效的自动发现主机名

• 有效的 Exchange 本地公共名称 - 主机名

证书和公共 CA（证书颁发机构）。

如前所述，使用 Office 365 直接转换邮件迁移时，Exchange 本地服务器证书必须是公共 CA 提供的“公共证书”。

当我们选择证书路径选项卡时，我们可以看到名为 - 证书路径的部分，我们可以看到有关提供证书的公共 CA 的信息。在我们的具体场景中，公共 CA 是
- Go Daddy。

问题6：如果我的Exchange本地服务器不包含服务器证书，您能否指导如何购买和安装所需的服务器证书？

A6：“如何在 Exchange 本地服务器上安装服务器证书”主题超出了我们当前文章的范围。

Exchange Online 和 Exchange 本地服务器之间的通信通道

我想添加到 Office 365 直接转换邮件迁移清单中的另一个“部分”是 - 强制需要启用 Office 365 和 Exchange Online 等外部主机通过端口 443 (SSL) 访问 Exchange 本地服务器。

实际上，Exchange 本地服务器也不会中继“暴露”到外部网络，而是直接与外部主机（例如 Exchange Online）进行通信。

通过防火墙或代理服务器（代表我们的内部主机）的中介实现对 Exchange 本地服务器的访问。

来自外部主机的任何通信请求都将到达防火墙，并将“转发”到“内部 Exchange 本地服务器”。

底线 - 为了能够启动 Office 365 直接转换邮件迁移，Exchange Online 将需要使用端口 443 访问 Exchange 本地服务器。

Exchange 本地服务器版本

问题7：支持 Office 365 直接转换邮件迁移的 Exchange 本地服务器版本是什么？

A7：从
Exchange on-Premises 2003 开始的所有现有 Exchange 本地服务器版本。
从技术上讲，不再支持 Exchange 2003 本地服务器，但实际上它并不支持。这意味着您不能尝试使用 Office 365 直接转换邮件迁移，并且大多数情况下，如果 Exchange 2003 包含所有前提要求，则 Office 365 直接转换邮件迁移将成功完成。

问题8：Exchange 本地服务器是否需要包含特定的服务包、特定的汇总或特定的累积更新？

A8：关于实施 Office 365 直接转换邮件迁移的 Exchange 本地服务器最低系统要求这一主题，有趣的是，据我所知，没有正式的文章来定义此 Exchange本地软件要求。

我对这个问题的回答是——一般规则是——更新的版本越好。

例如，如果您的 Exchange 本地服务器是 Exchange 2010 服务器，则建议的软件版本是 Exchange service pack 3 + Exchange 2010 Rollup 32。

这并不意味着较低的汇总不起作用，但如果我们希望最大限度地提高成功实施 Office 365 直接转换邮件迁移过程的机会，则更高级的 Exchange 2010 汇总会增加成功邮件迁移过程的可能性。

Exchange 本地服务器和 Outlook Anywhere 协议

如前所述，实施 Office 365 直接转换邮件迁移的强制性要求是本地 Exchange 将支持 Outlook Anywhere 功能。

如果您的 Exchange 本地不支持 Outlook Anywhere 选项，或者您不熟悉 Outlook Anywhere 选项，下面是对 Exchange 2010 和 Exchange 中出现的 Outlook Anywhere 配置设置的非常简短的回顾2013年。

Exchange 2010

在 Exchange 2010 中，我们使用以下路径激活 Outlook Anywhere 功能：

服务器配置 => 客户端访问 => 启用 Outlook Anywhere

在下面的屏幕截图中，我们可以看到 Outlook Anywhere 已经启用。

如果我们想要查看 Outlook Anywhere 设置，可以选择属性菜单。

在下面的屏幕截图中，我们可以看到 Outlook Anywhere 设置的示例。

“外部主机名”部分中显示的主机名是 Outlook 将寻址的主机名。

Exchange 2013

在 Exchange 2013 中，我们使用以下路径激活 Outlook Anywhere 功能：

服务器 => 服务器 =>

在下面的屏幕截图中，我们可以看到 Outlook Anywhere 已经启用。

在下表中，您可以找到文章的链接，其中包含有关在不同 Exchange 服务器版本中“激活”Outlook Anywhere 功能所需执行的步骤的指南：

Exchange server Outlook Anywhere Exchange 2003How to Configure Outlook Anywhere with Exchange 2003Exchange 2007How to Enable Outlook Anywhere Exchange 2007Exchange 2010Enable Outlook Anywhere Exchange Server 2010Exchange 2013Outlook AnywhereExchange 2016Configure Outlook Anywhere

使用远程连接分析器验证 Outlook Anywhere 服务。

在开始 Office 365 直接转换邮件迁移过程之前，最佳实践是测试并验证我们的本地 Exchange 是否支持 Outlook Anywhere 选项，以及我们是否可以与本地 Exchange 成功实施 Outlook Anywhere 会话。

好消息是，我们有一个非常方便的基于网络的工具用于此目的
名为 - 远程连接分析器。

远程连接分析器是 Microsoft 基于 Web 的工具，非常有用且功能强大，可用于测试许多不同的 Exchange 本地和 Exchange Online 服务。

远程连接分析器工具最强大的功能是能够提供有关特定通信协议“幕后发生的情况”的详细报告。

当通讯过程失败时，我们可以通过报告信息来查找通讯失败的可能原因

在我们的场景中，在开始 Office 365 直接转换邮件迁移之前，我们希望验证：

1. Outlook Anywhere 功能在我们的 Exchange 本地服务器上启用。
2. 该外部客户端可以使用 Outlook Anywhere (RPC\HTTPS) 协议连接本地 Exchange。

在下一节中，我们将演示使用远程连接分析器工具验证 Outlook Anywhere 连接所需实施的步骤。

要访问远程连接分析器工具，我们将使用以下 URL 地址：https://testconnectivity.microsoft.com

• 我们将选择交换选项卡
• 在名为 - Microsoft Office Outlook 连接测试 的部分下，我们将选择选项 - Outlook 连接。

在下一个屏幕中，我们需要提供代表需要访问其邮箱的 Exchange 本地收件人的用户凭据。

• 在电子邮件地址部分，我们将提供收件人的电子邮件地址 - [email protected]（数字 1）。
• 在域\用户名（或 UPN）部分，我们将以基于 UNC 的格式键入用户凭据 -o365info\david （数字 2）。
• 我们将提供用户密码（数字 3）。

默认情况下，Outlook 连接测试将尝试使用自动发现选项（使用自动发现来检测服务器设置）。

• 我们需要选中我们批准远程连接分析器工具有权使用我们的凭据的复选框（编号 1）。
• 我们需要写下验证码亮片并选择验证

要初始化 Microsoft Office Outlook 连接测试，我们将选择执行测试

在下面的屏幕截图中，我们可以看到 Microsoft Office Outlook 连接测试正在运行（远程连接分析器工具正在尝试访问我们的 Exchange 本地服务器并使用 Outlook Anywhere 协议连接到 David 的邮箱）。

在下面的屏幕截图中，我们可以看到Microsoft Office Outlook 连接测试已成功完成。
这意味着本地 Exchange 支持 Outlook Anywhere 服务，并且我们能够访问收件人邮箱。

请注意结果左侧出现的白色小箭头。
默认显示的信息只是测试结果的摘要。如果我们想要获取有关模拟中包含的每个步骤的详细信息，我们可以单击白色小箭头，信息将展开。

在下面的屏幕截图中，我们可以看到我们单击了小箭头。

测试结果已扩展，现在我们可以看到 Microsoft Office Outlook 连接测试由两个不同的部分组成：

自动发现测试用于定位和连接 Exchange 本地服务器，第二部分是 Outlook Anywhere 通信通道。