在进行了Office 365 的基础AD同步之后，某天突然发现O365的AD同步不正常，如下图，默认本地AD和Office365 AD同步时间为三小时，下图中这种情况明显是有状况的。
在对上述这种情况进行Troubleshooting的时候，我在客户端要么重新安装同步工具 Azure AD Connect，要么就手动运行Azure AD 同步命令。但是这样只是一次性的触发一次同步，没有彻底的解决问题。
但是这样不是一个长久的解决办法，那就从问题的根源开始找原因。
其实Azure AD的同步也是一次从Local AD 主动向O365 推送的一次同步，我们可以在计划任务中找到这个计划。
我们点进去详细看一看
在这里我看到一个非常奇怪的账号，这个账号从字面上理解应该是Office365 AD同步系统自动生成的一个账号，结果最终问题就出在这里，我们继续往下看。
在这个计划任务的历史记录里面，我找到了相关的报错，一看多半就是账号的问题。
这个时候既然这个自动生成的账号有问题，那么自然而然会联想到我的服务器中负责 AD 同步的某一个 service是否也在跑这个账号呢？
果然被我们不幸言中，就是他，不对，是很眼熟，但是貌似又不是！而且和上面一个账号都是本机的一个本地账号。
继续，我们再打开本机的账号管理，终于找到了这两个账号！！
我确定问题肯定是出在这里。
通过微软Office365KB的查找，结果发现，Office 365 在安装AD同步工具的时候，会在本机自动创建一个叫做 AAD_ 的账号，这个账号是专门授权用来跑AD同步计划的，并主导 Microsoft Azure AD Sync服务的。
但是我不清楚我这里为什么有两个，难道和我重装多次同步工具有关？ 后续再来研究吧
以下是微软资料中的截图
唯一的 AAD_ 账号
且这里运行该计划任务的账号应该具有域管理员的权限，不然无法上传AD属性。我这里的Author是我自己，是因为我在解决问题的时候修改过这个计划任务，理论上应该是AAD_ 这个账号哈，无所谓，但是下面的running账号就非常重要了。
BTW：这里大家不要学我用自己的管理员账号，我还是强烈建议可以创建一个单独的服务账号，或者就利用这个AAD_账号，保证密码永不过期即可。
修改完成之后，手动disable再enable一下这个计划任务，run一下，可以发现同步成功，且Office365 AD也能成功同步。
