You are viewing limited content. For full access, please sign in.

Question

Question

Errors in LFDS log after AD Sync

asked on September 9, 2020

I have a customer that was having an issue with LFDS syncing to AD.  Turns out it was the problem described in this post:
https://answers.laserfiche.com/questions/171067/Directory-server-synchronization-is-failing-Violation-of-UNIQUE-KEY-constraint

Long story, short, there were two users that I cleaned out of LFDS, then the sync completed successfully.  The only issue is that now I'm getting the following error in the LFDS event log HUNDREDS of times each time LFDS syncs (successfully):

System.Runtime.InteropServices.COMException (0x80005000): Unknown error (0x80005000)
   at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)
   at System.DirectoryServices.DirectoryEntry.Bind()
   at System.DirectoryServices.DirectoryEntry.get_AdsObject()
   at System.DirectoryServices.PropertyValueCollection.PopulateList()
   at System.DirectoryServices.PropertyValueCollection..ctor(DirectoryEntry entry, String propertyName)
   at System.DirectoryServices.PropertyCollection.get_Item(String propertyName)
   at Laserfiche.LicenseManager.ADGS.ADGSModule.SynchronizeDatabase(Object data)

Type:
System.Runtime.InteropServices.COMException

Stack Trace:
   at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)
   at System.DirectoryServices.DirectoryEntry.Bind()
   at System.DirectoryServices.DirectoryEntry.get_AdsObject()
   at System.DirectoryServices.PropertyValueCollection.PopulateList()
   at System.DirectoryServices.PropertyValueCollection..ctor(DirectoryEntry entry, String propertyName)
   at System.DirectoryServices.PropertyCollection.get_Item(String propertyName)
   at Laserfiche.LicenseManager.ADGS.ADGSModule.SynchronizeDatabase(Object data)

I don't understand how it's throwing hundreds of errors, yet completing successfully.  Anybody have any idea how I can solve this puzzle?

0 0

Answer

SELECTED ANSWER
replied on September 24, 2020

We just "resolved" it.  I put resolved in quotes because the root issue is still there.  Let me explain:

We found that the errors were being caused by users that exist in LFDS, but have been removed from AD.  The setting to automatically remove users from LFDS that have been removed from AD was enabled, but it was unable to.  Over time, this led to having about 300 of these users that needed to be removed from LFDS.  The customer found and removed most of them manually, but we still got 5 errors every time the sync would run.  To identify the last few users, I created a workflow that queried the LFDS database for a list of users, then used a "find user" activity to check whether they were valid in AD or not, then it spit out a report of the bad users.  Worked pretty well.

Anyway, now that they know what to watch for, they're able to manually remove users from LFDS when they remove them from AD, but we're hoping that in the future we'll be able to find out why LFDS was unable to automatically remove them.  John, I hope that helps.

3 0

Replies

replied on September 10, 2020

Hi Paul,

This is often caused by the account querying AD lacking read permissions for the directory's rootDSE. Try identifying which account is used for querying AD (in the identity provider settings you can choose to use either the LFDS service user or a specific account) and then double check their permissions in AD.

0 0
replied on September 10, 2020

Chase, Thanks so much for the reply.  I got on the domain controller and ran LDP under the service account that LFDS uses, and it was able to pull up the rootDSE info.  As an extra test, I added the service account to the Domain Admins group, then ran the sync again.  Again, the sync completed successfully, but hundreds of instances of the same error appeared in the LFDS operational trace log.

Any other ideas as to what might cause this?

0 0
replied on September 10, 2020

Nothing else seems obvious off the top of my head. I see you opened a support case and I will be working with our Support team to get this resolved.

0 0
replied on September 21, 2020

Was this resolved? I have a customer with a similar issue.

0 0
replied on September 21, 2020

Hi John, the support case is still active. The current recommendation is to try upgrading to LFDS 10.4.5 (tentative release date is tomorrow as part of the Laserfiche 10.4.3 package) to see if it helps the issue or at least logs more information for troubleshooting.

1 0
SELECTED ANSWER
replied on September 24, 2020

We just "resolved" it.  I put resolved in quotes because the root issue is still there.  Let me explain:

We found that the errors were being caused by users that exist in LFDS, but have been removed from AD.  The setting to automatically remove users from LFDS that have been removed from AD was enabled, but it was unable to.  Over time, this led to having about 300 of these users that needed to be removed from LFDS.  The customer found and removed most of them manually, but we still got 5 errors every time the sync would run.  To identify the last few users, I created a workflow that queried the LFDS database for a list of users, then used a "find user" activity to check whether they were valid in AD or not, then it spit out a report of the bad users.  Worked pretty well.

Anyway, now that they know what to watch for, they're able to manually remove users from LFDS when they remove them from AD, but we're hoping that in the future we'll be able to find out why LFDS was unable to automatically remove them.  John, I hope that helps.

3 0
replied on October 15, 2020

Chase,

 

It looks like upgrading did not resolve the issue. The sync is still failing.

 

Paul,

 

I am going through all the users now and deleting them all, then I will allow LFDS to re-build the tables using AD sync.

0 0
replied on October 15, 2020

Is the sync failing to add users or remove them? Does it show failure in the UI or just the above errors in the logs? That is a good plan, let me know if it doesn't help things.

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.