O365邮箱迁移中的那些坑 -- 活动目录同步

摘要：本文通过客户碰到的实际案例探讨Office 365 邮箱迁移混合部署场景中，活动目录迁移环节遇到的坑，给出对应解决方案以及建议的最佳实践。
适用读者：Office 365 合作伙伴，Office 365 管理员
阅读时间：15分钟
掌握难度：3颗星

正文：

       各位看官，这次是小弟我在此发表的第一篇博客，以后还请多多指教。

       在一个风雨交加的周六出门可能本身就是件值得商榷的事情，果不其然，刚出门15分钟，就接到partner的电话，说给客户做邮箱上云迁移的过程中，把两百多个用户密码同步丢了，我就赶紧折返回家打开电脑follow up。

        路上听partner详细讲讲了整个经过，确实也挺奇怪的，客户是把本地的整个AD域用Azure AD Connector同步到O365的Azure AD域中，可问题是一千多个AD域中的用户，没有做额外的设置，所有外部命令和环境相同，其中却两百多个的云上用户被本地的用户的用户名和密码给替换了。原则上使用AAD Connector做同步的过程中，由于两个AD的域名不相同，原则上即使显示名称相同的用户，只要UPN不相同，那在O365端还是将其视为两个不同的用户，并不会出现覆盖的现象。所以partner在考虑到了可能会存在云端AD和本地AD有相同名字用户的情况之后，由于后缀不同，也不会出现覆盖的情况，才采用AAD Connector进行同步，那等到看到一堆的警告时，就已经来不及了。

       跟各位看官一样，到这里我也是听的云里雾里，只能拉着partner和客户先把情况捋一捋，再去找找问题所在：   

       客户这边的使用情况呢目前是采用的国际版本的Office365,给1000个左右的用户分配了Exchange Online和 Skype for business Online的license，所有用户都采用的是@global.XXJJ.com的自定义域名。本地部署了Exchange 2013 cu12的环境，本地AD环境用的域名为XXJJ.com，并且用户登录名和电子邮件地址簿做了统一，员工的登录名为工号@XXJJ.com，其电子邮件地址为[email protected]。现在想把本地的环境与Office 365做混合部署。那在部署的过程中，客户首先给Office 365添加了自定义域名XXJJ.com，接着安装了Azure AD同步工具，修改同步了OU目录，同步了大概10000+邮件；然后开始做Exchange的混合部署，等到混合部署配置完成后，就看到了上述的一系列警告，客户这边就采取了取消混合部署以及取消AD同步的方式来希望将整个环境回退到做混合部署前的样子。但在做了一系列回退的操作后，云端部分用户的密码仍旧无法回退到云端登录时使用的密码，给这部分用户的登录造成了影响。

       但由于问题发生在周末，并且用户这边使用的是Global的Office 365，所以整个服务请求的标准流程没法满足客户当下的紧急情况，于是联系到微软的技术团队，我们也及时参与到客户的情况中，先了解整体的情况，找到对应解决该问题的相关部门，帮助客户在拿到Case ID的半个小时内将该问题direct给对应的技术工程师，来对目前情况进行分析并给出补救措施。

       客户的需求是想要恢复这些受影响客户的密码，但鉴于密码在整个过程中都没有明文文本做记录，一旦覆盖就无法找回原有的密码，只能通过批量恢复Office 365云端用户的后缀名，再让终端用户或IT管理员对密码进行重置。具体参考步骤以Powershell命令如下:

       新建一个txt 文件:

 

      保存user.csv 在D 盘

 

       运行 Windows AzurePowerShell，如下:

Connect-MsolService

Import-csvD:\user.csv | %{Set-MsolUserPrincipalName -UserPrincipalName$_.UserPrincipalName -NewUserPrincipalName $_.NewUserPrincipalName}

         客户这边在理清事件目前的情况及评估其严重程度后采取对比较紧急的受影响终端用户进行手工设置恢复，再对其他用户进行批量修改的措施，并最终在事件发生的12小时内解决该事件。

         事后，客户这边对事情发生的原因做了调查，才发现是有部分OU的IT管理员在得知该OU下用户将使用Global Office 365并使用不同的域名作为邮箱后缀，就在本地的AD环境中，给该部分用户添加了global.XXJJ.com的后缀的邮件地址属性，导致在使用AAD Connector过程中，本地AD域中的该部分用户将云端的用户作为重复项进行了覆盖，导致使用云端用户名密码的用户因为不清楚本地AD中用户名对应的密码，无法在portal上进行登录。

         其实像这样，因为一个小小环节的信息交流不充分，导致在混合部署过程中发生这些较为费解的状况，也并不罕见。像在这样的情况下，第一要素就在于及时找到能够对状况进行分析以及给出解决方案的技术人员及团队，先帮客户解决问题，以免影响公司的正常运营，再去从内部找问题发生的导火索。

       总结：1.对于存在不同OU对应不同管理员的AD环境的情况，需要首先对所有OU的AD设置方式在做ADD Connect或者ADFS前进行充分沟通，了解潜在的风险再采取下一步措施；2.针对邮件迁移这样通常选在在周末进行的情况，可以提前找到充分的技术支持，例如购买premier service或告知微软这边对应的技术工程师，即使发生状况也可以及时提供各方面的支持。

       另外对于一次性批量同步所有活动用户至云端的案例，建议把活动用户的各个情况先做排查，之后挑选一些具有代表性的账户放到一个测试的OU中，然后将这个OU的少数用户同步到Office365，来对情况做个测试和预估。如下图的测试环境中：Offline Line作为离线OU, 加入两个测试用户：

      具体使用AAD Connector 做部分单元的同步的设置步骤，详见参考链接：

https://docs.microsoft.com/zh-cn/azure/active-directory/connect/active-directory-aadconnectsync-configure-filtering

 

      最后，需要感谢整个过程中微软CSS同事以及合作伙伴的大力支持，用技术的力量解决客户问题，消除客户的疑虑。