Just a quick little script in this post that might save you some time when cleaning up DirSync sync errors.
For several years, my primary focus as a consultant was on Active
Directory and one thing I learned is just when you thought you knew of all the ways to accomplish a task, you’d walk into an environment where someone was doing it a “new way”. In many instances, that “new way” would be far from the most efficient way or would completely ignore what many believed to be “best practices”. These “best practices”, however, have certainly changed over the years; in the early days we saw a number of “dedicated/empty forest root” and “.local” domains, we’ve since moved on from these concepts.
DirSync, like any Identity Management tool, is only as good as the source data which in this case is your on-premises Active Directory environment. During DirSync implementation, it’s not uncommon to uncover some interesting “new ways” you or your predecessors may have configured your organization’s Active Directory.
Background
In an Exchange Hybrid configuration, DirSync needs to be able to “write-back” a limited number of attributes from the cloud to your on-premises AD. The permissions for this operation are assigned during the DirSync installation and applied at the root level of Active Directory. The expectation is that the permissions will flow down to the necessary objects, unless of course you have inheritance disabled on an object or its parent.
Error
If DirSync is unable to write to an object, you’ll likely see the following error:
If the list of errors are contained within a common set of OUs, there’s a good chance inheritance is disabled on that OU.
Resolution
Some might be quick to check the box to enable inheritance. While this would likely resolve your DirSync errors, there’s also a very good chance you created another mess for yourself. As an alternative, I would advise to assign the appropriate DirSync permissions explicitly on that OU so that you can perform the write-back operation but will have not changed any other permissions.
Script
The script below looks at the permissions currently assigned to “MSOL_AD_Sync_RichCoexistence” at the root and applies them to the OU or object you specify. You’ll want to run it from your Exchange 2010 or later EMS with an account that has permissions to modify the ACL on the target object. In the script you’ll specify the DN for the domain where the “MSOL_AD_Sync_RichCoexistence” group resides and the DN for the object you want to add the permissions to.
If while running the script, you receive an error stating “INSUFF_ACCESS_RIGHTS”, you may need to execute the steps in Microsoft KB2983209 before running the script.
The script for this post can be found in the Microsoft Script Center at the following link: Set-DirSyncWriteBackAcl.ps1
Did you find this article helpful?
Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.
Joe, this was very helpful. Thank you!!
Ken T
Thank you Joe !
Ward G
Your article is a bit confusing to me. You state ‘specify the DN for the domain where the “MSOL_AD_Sync_RichCoexistence” group resides and the DN for the object you want to add the permissions to.’ I’ve looked everywhere and I do not see an MSOL_AD_Sync_RichCoexistence account/group in our On-premise AD. Where should this account exist?
James-
This article (from 2014) is for the old version of DirSync; since then we’ve had AAD Sync and now AAD Connect. I believe the “MSOL_AD_Sync_RichCoexistence” resided in the “Users” container in that version of the product.
Thanks
Joe