1 2 Previous Next 18 Replies Latest reply on Nov 10, 2009 5:05 PM by jkussow

    LDAP Connector - uSNChanged question

      We're using search groups in our ldap connector. It works OK, but it takes a really long time to cycle. It's currently checking 1032 users and takes ~2 hours 15 minutes to complete.

      Once it completes composing the user list based on the search groups it begins checking each of the users. It seems to usually take 8-9 seconds per user.

      I just happened to create a user and her bindings manually today. When I setup the SbAdCon0.changes binding I set it to the same value as the user's uSNChanged attribute. I noticed that when it processed this manually created user it entered "...change attribute older than current users: Ignoring other changes" in the log and processed the user in under a second.

      The other users' SbAdCon0.changes attribute is also exactly the same as their uSNChanged attribute on the server, but were processed for changes which takes the 8-9 seconds.

      The connector would finish in a fraction of the time if it would skip over users whose .changes attribute is unchanged, and intuitively it seems like that's how it should work. The strange thing is it did work for a manually created user but not the others.
        • 1. RE: LDAP Connector - uSNChanged question
          sounds like you don't have the nameindex enabled on your db?

          (performance tuning section of the EEM Admin Guide).
          • 2. RE: LDAP Connector - uSNChanged question
            Just wanted to report back on this issue. I was searching the kb for information on dbcfg.ini and came across Endpoint Encryption Enterprise Best Practices Guide.pdf. After making some dbcfg.ini changes based on this guide, which included enabling indexing, our ldap sync time went from 4.5 hours down to about 7 minutes.

            Yeah, I'd say that was worth it. Thanks for pointing me in that direction. It didn't occur to me that indexing would help this situation.

            PS - Is there any reason the Best Practices Guide is not included in the standard set of docs?
            • 3. RE: LDAP Connector - uSNChanged question
              probably no good reason, except they are only one opinion of what the best practice is - I'd rather people sat down and thought what was best for them, rather than copying someone else.

              but, I appreciate we're all too busy to think nowadays..
              • 4. RE: LDAP Connector - uSNChanged question
                Wow...do you normally insult people that are trying to thank you?

                The EEPC Manager Administration Guide that comes with the product states "..."Name Index" ability which can be enabled to improve performance on object directories with large numbers of users (>3000)" and the Best Practices Guide states "Name indexing should be enabled on all databases especially those with over 1000 endpoints or users.

                I'm not too busy to think as you would suggest. But I am too busy to spend my time sorting out poorly written documentation.
                • 5. RE: LDAP Connector - uSNChanged question
                  you took it the wrong way, I was not trying to be insulting - I was spelling out a problem in IT security that I think everyone faces - we are constantly jumping between issues.

                  If you really have time to think, you're one of the lucky few. Most people in companies I work with are so overworked and overwhelmed, they simply and genuinely don't have the time to make their own appraisal as to what's best (for them).
                  • 6. RE: LDAP Connector - uSNChanged question
                    In that case, please accept my apology. Tone and intent are always challenges on an internet forum.
                    • 7. Re: LDAP Connector - uSNChanged question

                      I'm struggling with the same problem.  AD sync of 1000 users takes an average of 68 minutes.  We've had name indexing enabled for some time.  Is there a way to purge/drop then rebuild that index?  I've tried a number of different configs (search Groups vs LDAP query based).  Also tried whacking half the group mapping rules but it didin't change things. Our admin console responds very very slowly at all times.  Is it possible these are related?  It's all running on pretty decent hardware.  Or is it that my expectations are unrealistic?


                      Also reset the connector.chnaged back to 0 then ran a number of resyncs.  Same thing.



                      Message was edited by: jkussow on 11/4/09 9:44 PM
                      • 8. Re: LDAP Connector - uSNChanged question

                        can you describe the relationship between the sbdbserver application and the actual data? Are they on the same physical box, are they virtual, is the storage SAN/NAS etc?

                        • 9. Re: LDAP Connector - uSNChanged question

                          oh, to force a cache rebuild, just delete names.dat from one of the object class folders - it will then rebuild that object.

                          1 2 Previous Next