{"id":5986,"date":"2015-09-11T12:00:09","date_gmt":"2015-09-11T11:00:09","guid":{"rendered":"http:\/\/www.markwilson.co.uk\/blog\/?p=5986"},"modified":"2015-09-11T00:08:34","modified_gmt":"2015-09-10T23:08:34","slug":"troubleshooting-missing-objects-azure-ad-sync","status":"publish","type":"post","link":"https:\/\/www.markwilson.co.uk\/blog\/2015\/09\/troubleshooting-missing-objects-azure-ad-sync.htm","title":{"rendered":"Troubleshooting missing objects in Azure AD sync"},"content":{"rendered":"

I have a half-written blog post about Microsoft Azure Active Directory (AAD) Connect – the latest incarnation of the directory synchronisation engine used to populate a cloud directory for Office 365 and other online services. That post will stay half-written for a while longer as\u00a0it needs a bit more work but, yesterday, I was working with a customer whose AAD sync was missing some users. I’d set it up a couple of months previously and it had been working well, but clearly something had gone awry.<\/p>\n

Microsoft knowledge base article 2643629<\/a> describes why one or more objects don’t sync when using the Azure Active Directory Sync tool but my problem turned out to be a lot more fundamental.<\/p>\n

I checked the Synchronisation Service Manager (miisclient.exe<\/code>) and found that there hadn’t been a sync for over\u00a0three weeks. Then I looked in the Task Scheduler on the AAD Sync server; the Scheduled Task was still there and it had last run a couple of hours previously. Digging a little deeper and looking at the history though, showed that the task had been failing for a few weeks (every 3 hours), because a previous task was still running.<\/p>\n

So, I restarted the server (to clear out long-running processes) and ran the sync, then watched in the Synchronisation Service Manager to check that it started logging the synchronisation events again. Once the sync was completed (with lots of changes, as expected), I changed the timeout on the scheduled task to 2 hours so it should always end before the next begins.<\/p>\n

A delta sync sorted most of the issues, but I did need to force a full sync to get all of the missing users up to the cloud, by running directorysyncclientcmd.exe initial<\/code>.<\/p>\n

Incidentally, we’re all used to running idfix.exe<\/code> before implementing directory synchronisation but occasionally admins create problem objects afterwards too… somehow an account had crept into scope that had a space in the username and no UPN. Predictably, AAD sync didn’t like that and my customer was being emailed after each sync with a notification that AAD Sync was:<\/p>\n

Unable to update this object in Azure Active Directory, because the attribute [Username], is not valid. Update the value in your local directory services.<\/p><\/blockquote>\n

As Joran Markx explains, you can control who the identity synchronisation error reports are sent to<\/a> by editing the technical contact for the tenant.<\/p>\n

Resources<\/h3>\n