在进行了Office 365 的基础AD同步之后,某天突然发现O365的AD同步不正常,如下图,默认本地AD和Office365 AD同步时间为三小时,下图中这种情况明显是有状况的。

clip_p_w_picpath002

在对上述这种情况进行Troubleshooting的时候,我在客户端要么重新安装同步工具 Azure AD Connect,要么就手动运行Azure AD 同步命令。但是这样只是一次性的触发一次同步,没有彻底的解决问题。

但是这样不是一个长久的解决办法,那就从问题的根源开始找原因。

其实Azure AD的同步也是一次从Local AD 主动向O365 推送的一次同步,我们可以在计划任务中找到这个计划。

p_w_picpath

我们点进去详细看一看

在这里我看到一个非常奇怪的账号,这个账号从字面上理解应该是Office365 AD同步系统自动生成的一个账号,结果最终问题就出在这里,我们继续往下看。

clip_p_w_picpath002[5]

在这个计划任务的历史记录里面,我找到了相关的报错,一看多半就是账号的问题。

clip_p_w_picpath002[7]

这个时候既然这个自动生成的账号有问题,那么自然而然会联想到我的服务器中负责 AD 同步的某一个 service是否也在跑这个账号呢?

果然被我们不幸言中,就是他,不对,是很眼熟,但是貌似又不是!而且和上面一个账号都是本机的一个本地账号。

clip_p_w_picpath002[9]

继续,我们再打开本机的账号管理,终于找到了这两个账号!!

clip_p_w_picpath002[11]

我确定问题肯定是出在这里。

通过微软Office365KB的查找,结果发现,Office 365 在安装AD同步工具的时候,会在本机自动创建一个叫做 AAD_ 的账号,这个账号是专门授权用来跑AD同步计划的,并主导 Microsoft Azure AD Sync服务的。

但是我不清楚我这里为什么有两个,难道和我重装多次同步工具有关? 后续再来研究吧

以下是微软资料中的截图

唯一的 AAD_ 账号

clip_p_w_picpath001

且这里运行该计划任务的账号应该具有域管理员的权限,不然无法上传AD属性。我这里的Author是我自己,是因为我在解决问题的时候修改过这个计划任务,理论上应该是AAD_ 这个账号哈,无所谓,但是下面的running账号就非常重要了。

BTW:这里大家不要学我用自己的管理员账号,我还是强烈建议可以创建一个单独的服务账号,或者就利用这个AAD_账号,保证密码永不过期即可。

p_w_picpath

修改完成之后,手动disable再enable一下这个计划任务,run一下,可以发现同步成功,且Office365 AD也能成功同步。

p_w_picpath

p_w_picpath

p_w_picpath

p_w_picpath

p_w_picpath