ADLDS AdamSync WILL_NOT_PERFORM 1317

Question

I have a user that just will not sync from an AD User Object to an ADLDS UserProxy object. There is nothing unusual about the user's AD object. It was syncronized before, but was having problems, and one of the later troubleshooting steps we have for ADLDS is to delete the ADLDS userProxy object and resync. This is the only object that is giving us this trouble, all else seems to be working fine.

I have to clean up the log a little.

Processing Entry: Page 119, Frame 1, Entry 48, Count 1, USN 0
Processing source entry <guid=361fd2...d29959>
Processing in-scope entry 361fd2...d29959.
Adding target object CN=Last\, First - Department XXX CTR,OU=OU=OrganizationalUnit,ou=baseOU,dc=adlds,dc=Domain,dc=TLD.
Adding attributes: sourceobjectguid, sn, telephoneNumber, givenName, instanceType, displayName, department, objectSid, sAMAccountName, userPrincipalName, mail, msExchArchiveStatus, lastagedchange, objectclass,
Ldap error occured. ldap_add_sW: Unwilling To Perform.
Extended Info: 000020E7: SvcErr: DSID-0315324B, problem 5003 (WILL_NOT_PERFORM), data 1317
.
Ldap error occured. ldap_add_sW: Unwilling To Perform.
Extended Info: 000020E7: SvcErr: DSID-0315324B, problem 5003 (WILL_NOT_PERFORM), data 1317
.

---

---

************ A fatal error occured in the program, while processing entry
************ <GUID=361fd2...d29959>.
************ We will ingore this and continue anyways....

I've reviewed this forum post a couple of times:
https://social.msdn.microsoft.com/Forums/en-US/a2a34e0b-108c-49f3-9f50-16eb0be7ddad/the-extended-server-error-is-000020e7-svcerr-dsid03152db9-problem-5003-willnotperform-data?forum=winserverDS

Don't think that is it, however, the linked KB article: https://support.microsoft.com/en-us/kb/276382 no longer works.

Answer 1

Thanks again for the responses. The userprincipalname was a clue, but not the problem. It was a clue that it was our AD domain consolidation process that may be to blame. It turns out that the account was migrated to a new domain, but returned to the original domain for some reason. This is done with a series of renaming attributes between the two domains, as the target domain has a staged account already. The problem, sIDHistory. The target domain account had the sIDHistory attribute value with the SID from the source account. While we considered a duplicate SID problem, searching for and comparing objectSid values didn't yield any duplicates. Only a closer inspection of the target domain account reveled the sIDHistory attributes existed for the accounts that had also had their userprincipalname attributes changed and were giving us the 1317 errors.

Answer 2

Hello,

Thank you so much for posting here.

According to our description, there is only one user cannot be synchronized, what’s the difference between the problematic one and others? Is the user account disabled or deleted?

Hope something here might be helpful.
https://social.technet.microsoft.com/Forums/en-US/61791376-9bfe-49a6-976b-b052f137572d/unable-to-sync-ad-lds?forum=winserverDS

https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/adamsync-101/ba-p/400165#:~:text=I'll%20include%20links%20at%20the%20end%20for%20userproxy.),)%2C%20and%20attributes%20to%20synchronize.

Best regards,
Hannah Xiong

============================================

If the Answer is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 3

Hello,

You are welcome. Thank you so much for your kindly reply.

Frankly speaking, I had not experienced this issue, thus so sorry that I'm at the end of what help I can offer. Maybe someone else has ran into something similar before and can share their experience or knowledge here.

As mentioned in the article, "Initially, you may even want to remove userPrincipalName, just to verify that you can get a sync to complete successfully. Synchronization issues caused by the userPrincipalName attribute are among the most common ADAMSync issues I see. Active Directory allows multiple accounts to have the same userPrincipalName, but ADAMSync will not sync an object if it has the same userPrincipalName of an object that already exists in the AD LDS database."

Maybe we could check whether there are any duplicate UPNs.

Thank you so much for your understanding and support.

Best regards,
Hannah Xiong

============================================

If the Answer is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.