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.
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.
Unleash the Potential of Power Platform With a Center of Excellence
Business innovation often comes from within. Discover how to empower innovation from non-traditional developers with the Microsoft Power Platform.
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.
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.
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.