The last week I stumbled upon a really interesting new and shiny User Profile Synchronization issue - one of these things that just make your day! We had to manually initialize a full synchronization, after doing some updates to one of the user profile properties, and the user profile synchronization would not just start…
Everything looked fine (on the surface) and we tried the incremental sync, which also looked like it was starting but nothing happened. The sync service was up and running and the FIM services was started, the MIISClient showed no activity. We took a look at the timer jobs, which are responsible for kicking of the synchronizations and saw that they all failed with the error message Access Denied.
No more than this simple error message. Since the timer jobs are executed using the Farm Account this sounded very peculiar. Oh, and you who still have your Farm Account in the local administrators group would probably never see this error, you’ll be aware of this in a minute!
Next resort was to dig in to the trace logs (ULS), using my favorite SharePoint tool: ULSViewer. And there we had a Critical and an Unexpected entry, related to this Access Denied error message. 
The accompanying stack trace showed me that it was some problems getting the instance of the Management Agents.
Time to fire up my second best SharePoint tool: Reflector! Peeking into the failing method in the User Profile assembly revealed that the Access Denied was thrown while trying to retrieve the MA’s using WMI. Now, this sounds really weird. As usual nothing has been changed in the farm (and this time I knew it for a fact) - but you should always check with the admins, which I did and no new policies or similar had been applied to any machines recently.
On the machine that hosted the sync service/FIM Services I started a Management Console and added the WMI snap-in and took a look at the Security tab for the local machine. And this is what I found:
The security settings for the MicrosoftIdentityIntegrationServer looked not just right, it more or less looked liked the default WMI security settings. (And as you can see the Administrators group is there - so that’s why you who still have the farm account in the administrators group, probably never see this error…). A quick comparison with the identical staging environment showed a whole lot more permissions.
To be exact the following permissions did not exist for the environment that showed the Access Denied:
- WSS_ADMIN_WPG group - Execute Methods, Provider Write, Enable Account, Remote Enable
- FIMSyncOperators group - Execute Methods, Provider Write, Enable Account, Remote Enable
- FIMSyncBrowse group - Execute Methods, Provider Write, Enable Account, Remote Enable
- FIMSyncPasswordSet group - Execute Methods, Provider Write, Enable Account, Remote Enable
I fixed the permissions using the WMI management console, went back to Central Admin and started the synchronization manually and within a minute the synchronization was running beautifully!
I do not know about any supportability on this one - and you should NOT be doing this unless you really have to. A safer way might be to unprovision and reprovision the User Profile Synchronization Service - this should correctly set this permissions.
So, what caused this then? I’ve not yet found the actual source of the problem (which is frustrating to me at least), but I now how to fix it if it appears. Safe sources tell me that this might happen when you’re doing a backup of the UPSS (and this is done in the correct way, which stops and starts the UPSS so no ongoing syncs are interfering with the backup). Question remains open…
Happy Christmas everyone!