Tag Archives: adsiedit

Azure AD Connect mail-enabled public folder synchronization issues – The cause of the error is not clear

Leave a reply

We recently went through some Exchange Online Protection (EOP) cleanup and part of that involved turning on Directory Based Edge Blocking. We already went through the exercise of syncing all objects (especially ones part of Exchange), but the only ones that weren’t being synced were mail-enabled public folders. After turning on Directory Based Edge Blocking we realized there were a few public folders that needed to receive mail from the Internet. After syncing mail-enabled public folders (this is a newer feature in AD Connect) we received synchronization errors for four objects. The only thing these objects had in common was that they referenced a mail-enabled public folder by either having that object as a group member or having it as a forwarding object on a mailbox.

The errors we receiving were:

  • The cause of the error is not clear. This operation will be retried during the next synchronization. If the issue persists, contact Technical Support.
  • IdentityDataValidationFailed

The workaround is to create a mail contact object that has the same targetAddress as the mail-enabled public folder object and use that object in place of the public folder object in something like a group membership. The issue with this is that by design a mail contact’s targetAddress is also part of its proxyAddresses attribute and the mail-enabled public folder object of course already has the email address as part of its proxyAddresses attribute. This duplicate is not allowed. The way around this is to modify the mail contact object so that the targetAddress is not part of proxyAddresses. To create this special mail contact you do the following:

  • Create a mail contact in Exchange with a fake external address
  • Disable e-mail address policy for the object
  • Use ADSIEdit to:
    • Change the targetAddress to the email address of the mail-enabled public folder
    • Remove the fake external address you specified earlier from proxyAddresses

After the object has been created you can now use it in lieu of the mail-enabled public folder in group memberships and other attributes.

The replication operation failed because of a schema mismatch between the servers involved

Leave a reply

Last week I had deploy a new domain controller to the root domain in a forest (it happened to be an RODC for a unique use case, but that is irrelevant). The domain only partially replicated before failing and showing errors on the new DC.

The errors were:

Log Name:      Directory Service
 Source:        Microsoft-Windows-ActiveDirectory_DomainService
 Date:          1/4/2019 11:19:18 AM
 Event ID:      1791
 Task Category: Replication
 Level:         Error
 Keywords:      Classic
 User:          ANONYMOUS LOGON
 Computer:      rodc1.domain.com
 Description:
Replication of application directory partition DC=domain,DC=com from source 24c77a2c-6da0-41a1-95cf-e0542bca5b89 (dc1.domain.com) has been aborted. Replication requires consistent schema but last attempt to synchronize the schema had failed. It is crucial that schema replication functions properly. See previous errors for more diagnostics. If this issue persists, please contact Microsoft Product Support Services for assistance. Error 8418: The replication operation failed because of a schema mismatch between the servers involved..
Log Name:      Directory Service
 Source:        Microsoft-Windows-ActiveDirectory_DomainService
 Date:          1/4/2019 11:19:31 AM
 Event ID:      1203
 Task Category: Replication
 Level:         Warning
 Keywords:      Classic
 User:          ANONYMOUS LOGON
 Computer:      rodc1.domain.com
 Description:
 The directory service could not replicate the following object from the source directory service at the following network address because of an Active Directory Domain Services schema mismatch. 
 Object:
 CN=Bob Smith,OU=Users,OU=All Users,DC=domain,DC=com 
 Network address:
 24c77a2c-6da0-41a1-95cf-e0542bca5b89._msdcs.domain.com

It was obvious that the object referenced in the second event was causing the issue, but this object was in use and I couldn’t just remove it. When looking for related errors on the source DC I found this:

Log Name:      Directory Service
 Source:        Microsoft-Windows-ActiveDirectory_DomainService
 Date:          1/4/2019 11:04:33 AM
 Event ID:      1450
 Task Category: Internal Processing
 Level:         Error
 Keywords:      Classic
 User:          ANONYMOUS LOGON
 Computer:      dc1.domain.com
 Description:
 The security descriptor propagation task could not calculate a new security descriptor for the following object. 
 Object:
 CN=Bob Smith,OU=Users,OU=All Users,DC=domain,DC=com 
 This operation will be tried again later. 
 User Action 
 If this condition continues, attempt to view the status of this object and manually change the security descriptor. 

Additional Data 
 Error value:
 1340 The inherited access control list (ACL) or access control entry (ACE) could not be built.

This was much more specific and showed there was an issue with the ACL of the object. I tried making one small change to the security ACL on the object to verify there was an issue and received an error. This ACL was either corrupt or too large. I decided to try repairing the ACL on the object by using ADSI Edit (adsiedit.msc) to remove everything from the ACL, add only ‘Domain Admins’ and ‘SYSTEM’ with Full Control, and then resetting it using DSACLS. I also had to do this for the ‘ExchangeActiveSyncDevices’ child object and the leaf objects under that since this user had Exchange ActiveSync devices. I verified the child and leaf objects were inheriting from the user object and proceeded to reset the ACL using the DSACLS:

dsacls "CN=Bob Smith,OU=Users,OU=All Users,DC=domain,DC=com" /S /T

After resetting the ACL replication to this domain controller completed with this event:

Log Name:      Directory Service
 Source:        Microsoft-Windows-ActiveDirectory_DomainService
 Date:          1/4/2019 11:49:51 AM
 Event ID:      1394
 Task Category: Service Control
 Level:         Information
 Keywords:      Classic
 User:          ANONYMOUS LOGON
 Computer:      rodc1.domain.com
 Description:
 All problems preventing updates to the Active Directory Domain Services database have been cleared. New updates to the Active Directory Domain Services database are succeeding. The Net Logon service has restarted.