首先让我解释一下我们的环境。
我们有一个 AD 域 - de***.co.uk
无论用户属于哪个部门,每个用户都会使用其域帐户 (user@de***.co.uk) 或 (de***\user) 与所有系统 (inc exchange) 进行身份验证,即使他们的电子邮件地址是[电子邮件保护](我知道这很常见)
我们计划逐步迁移到 Office 365 E3,一次一个部门我们有大约 300 名员工、47 个接受的电子邮件域和 600 多个邮箱(其中一些可能只是在本地存档到 pst)。我们 IT 部门已经使用我们拥有的域名 de***s****.co.uk 测试了 365 E3,并手动设置了用户/邮箱
我们现在准备将一个部门迁移到试用版 365(20 个用户),但是我们希望将其链接到我们的本地 AD。这部分用户将拥有电子邮件地址域 @le************.com
根据我所收集的信息,我相信这些是我必须执行的步骤(如果我错了,请纠正我)
- 设置 ADFS
- 将@le************.com 域名添加到我们的 365 帐户 ********(不确定它将如何获取用户)********
- 将 le***********.com 的 DNS 记录更改为指向 Office 365
- 将每个用户的 pst 导入他们的 365 帐户或任何其他方法?
造成混乱的是 ADFS 部分,到目前为止,我已经阅读了几个教程,它们的内容不同(一个说在 DC 上安装 ADFS,另一个说设置 3 个新服务器 - 一个 ADFS 代理,一个 ADFS 服务器和一个 DirSync 服务器) - 哪个最好?
在设置 ADFS 期间,据说需要在 IIS 上安装 SSL 证书 - 该证书是 hostname.de***.co.uk 还是 hostname@le********.com,并且每个其他接受的电子邮件域是否都需要自己的 SSL?
驻留在本地交换机上的其他用户是否会受到此过程的影响?
问候
答案1
根据您提供的信息,以下是继续进行的最佳方案。
用户认证:这里有 3 种模型可供您使用,分别是:
- Office 365 中的用户(云帐户):用户管理将完全在云中进行。您可以使用 Office 365 门户创建用户、禁用、重置密码并配置所有设置,您不需要本地 AD,显然此选项不适用于您的环境,因为您已经有一个带有 Exchange 的本地 AD,并且您希望在 AD 中本地控制用户管理。
- AD 中的用户,与 Office 365 单向同步(半联合帐户):此模块将允许您在内部 AD 服务器上创建帐户并进行整个用户管理,您将安装一个名为“DirSync”或较新版本“ADD Sync”的工具来创建从本地 AD 到云的用户副本,该工具还可以选择将用户帐户密码从本地 AD 同步到云,这将允许您的用户使用相同的用户凭据登录域中的本地资源和 Office 365,创建半 SSO 体验,用户在访问 Office 365 上的资源时需要提供他们的用户名和密码,并且用户身份验证/验证将在云端进行。此模块的要求是在您本地网络中的任何服务器上安装前面提到的工具,不需要 ADFS 或 ADFS 代理,您应该选择此选项,因为它最容易实现和支持。
- AD 中的用户,与 Office 365 双向同步(完全联合帐户):这是三个选项中最先进的选项,该选项利用了上一个选项“AD 中的用户与 Office 365 单向同步”的所有设置,此外还增加了强制用户身份验证/验证的功能,该功能将使用 ADFS 和 ADFS 代理服务器在您的本地 AD 服务器上进行,您需要在本地网络或 Azure 混合网络上部署 ADFS/ADFS 代理和 AAD 同步,您将通过此选项获得完整的 SSO 体验,因为域中的用户无需提供用户名和密码即可访问 Office 365,我不建议采用此选项,因为安装、配置和支持它是一个 IT 恐怖故事。
您可以在此处阅读大量信息以供进一步参考:https://blogs.office.com/2014/05/13/choosing-a-sign-in-model-for-office-365/
电子邮件迁移:由于您的网络中有 Exchange 2010,因此支持以下方式迁移您的电子邮件:
- 切换电子邮件迁移:使用 Office 365 门户,您可以创建一个迁移批处理作业,该作业将使用 Exchange 自动发现搜索用户邮箱,它将访问本地 Exchange 服务器上的用户邮箱并开始将邮箱内容复制到云,所有这些都可以在用户仍在使用本地服务器上的邮箱时发生。一旦所有电子邮件都成功复制到云,您将停止迁移批处理并更改 DNS 记录,以便新电子邮件/自动发现指向云邮件服务器而不是本地网络中的服务器,用户需要重新配置才能访问新服务器,并且您可以从本地服务器中删除用户邮箱,因为它不再使用。我个人更喜欢您使用此选项。
- 代表用户批量导出/导入 .pst 文件:您将使用工具将用户邮箱导出为 .pst 文件,您可以将这些文件保存到磁盘并将其发送给 Microsoft 进行导入,或者将 .pst 文件保存到本地文件夹然后使用 Office 365 中的迁移向导自行将它们导入到 Office 365,除非您的邮箱相对较小,否则我不会选择此选项。
- 要求您的用户执行 .pst 导入/导出:在理想的世界中,您可能会要求用户将他们的邮箱导出到 .pst 文件中,将文件保存在他们的机器本地,配置 Outlook 以使用云上的新邮箱,将 .pst 文件从他们的机器导入到新邮箱,我会不惜一切代价避免使用此选项,因为...嗯...最终用户。
您可以在这里找到有关电子邮件迁移的更多信息:https://support.office.com/en-us/article/Ways-to-migrate-multiple-email-accounts-to-Office-365-0a4913fe-60fb-498f-9155-a86516418842
如果您选择选项 2 进行身份验证并选择选项 1 进行电子邮件处理,则不需要 ADFS 或证书来完成迁移,最终用户只会在切换迁移的最后阶段受到影响。
希望这可以帮助。
编辑:
您的迁移步骤应该很简单,请遵循以下提示:
- 将所有接受域添加到 Office 365 门户并验证它们。
- 使用 Microsoft IDFix 工具确保您的本地帐户格式和数据与 Office 365 兼容。
- 创建 ADFS 集成(我仍然会选择 DirSync,因为您可以在任何地方安装它,而且不需要硬件,它仍然可以像 ADFS 一样运行,即使没有 SSO 自动登录,但似乎 ADFS 是您的情况所必需的)
- 在本地邮件服务器和 Office 365 之间创建联合信任。
- (可选)首先将传入的电子邮件重定向到云端,以便更好地处理防病毒/垃圾邮件。
- 向您想要迁移到 Office 365 的用户分配许可证。
- 按照您认为合适的方式开始移动每个部门的用户。
- 将所有用户帐户移至云端后,删除 Office 365 与本地邮件服务器之间的联合信任,保留 ADFS 或 DirSync,尽管您始终需要它们存在。
- 根据需要删除本地邮件服务器,虚拟化并保持其关闭状态,您可以选择。