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