HelpSpot Help Desk Software | HelpSpot Blog | HelpSpot Support

Live Lookup slow (since upgrading DCs)


#1

We are using the live_lookup_ad_and_ldap.php script for quite a while now without issues. A week ago it starting to get very slow on results; it is still working, but the lookup now takes 20 seconds, which seems a bit to much for a simple AD query. The only differes I can think of we have now compared to a few weeks ago is the fact, that we upgraded our Domain Controllers from 2008 R2 to 2012 R2 and that seems to be the time around it started to be that slow. It is not super critical but a tad annoying to wait that long for an answer on the lookup, so I was wondering if anyone has an idea what could be the cause of the problem. Is there any form of debugging I could switch on in order to see what the script does in all these 20 seconds? Because I have a hard time believing the AD realy only puts out the answer of that question after 20s as using standard ldap query tools get me the answer as they should.

We are currently using HelpSpot 3.2.12 on a Windows Server 2008 R2 machine.

On another sidenote, we are also using the blackbox mechanics to auth. ourselfs for login into helpspot (against the same DC) and that doesnt take 20s before I am in. That is just like it always has been.


#2

Hmm. What you can do it get the URL for your Live Lookup script and put it in your browser and add ?last_name=smith (or whatever) to make it search for Smith. By doing this direct in your browser you take HelpSpot out of the equation. If it’s slow there it’s something to do with the script.

Maybe something in the script needed to be updated for the new domain controller, like a hostname that’s taking a long time to resolve or something like that?


#3

Already tried that. The time it takes to resolve the query is the same, so per your conclusion it should be in the script. I changed the the name of the DC in the script of course. What I do not get is, why it takes roughly 20s for every query, because if it is the name which doesnt work, it should either always give an error (for not resolving it) or be cached after the 1st query somewhere down in windows. Having it always take a break for 20s is very odd.


#4

ok, here is another try, just got an error by trying the same url which worked yesterday.

XML Parsing Error: no element found
Location: http://[fqn-servername]/helpspot/custom_code/live_lookup_ad_and_ldap.php?email=[emailaddress]
Line Number 1, Column 1:

which implies the ldap query returned an empty string, but I am absolutly sure that I am still present in it, otherwise I would have trouble writing this :smile:

I really dont get it.


#5

found it!

ldap_set_option($ad, LDAP_OPT_PROTOCOL_VERSION, 3)

changed the protocol version to 2 and now I get an instant reply! Which is very weird because it implies that a newer windows server can only use a lower version of the ldap protocol?

Anyway, it works, I am happy, case closed :smile:

curious as I am, I googled a bit and found a vbscript which when executed against my AD tells my that our DCs are indead LDAP 2 and LDAP3 capable. But somehow I get the feeling something is missing, because now this sounds like the script tries in v3 first, gets into a timeout and then falls (sometimes) back to 2 and gets an answer (after these 20s). From the MS websites I found an article explaining the difference between 2 and 3, one of them using utf-8 charset as return, which I need, because here in germany we have our infamous “Umlauts” which gets me a horrible parsing error, whenever for instance a last name has one (just tried it while typing this) (last name here should be Weiß).

XML Parsing Error: not well-formed
Line Number 5, Column 31: <last_name>Wei</last_name>
------------------------------^

So it seems I need to find away to get that script talk properly to our new DCs in v3 LDAP, so I am back to square one… :frowning:

Any pointers would be much appreciated.


#6

Interesting!

OK so something seems off perhaps in the new configuration of your AD since the time to query isn’t related to HelpSpot, so that probably still needs looking into.

On the character issue. I assume in Live Lookup settings you have it set for the results to be UTF8? If not that may fix it, though it sounds like you’ll still need to get the v3 protocol working (I assume v3 gives utf8 feedback, not v2).

One other consideration is HelpSpot v3 is not utf8 compatible in general. Though you had things mostly working it sounds like up until this change. HelpSpot version 4 which is in beta and you can download from logging into our store is entirely utf8. It’s hard to say if that will really fix your issue though since this has all been working. So, for right now, it may be best to get the v3 ldap protocol working to get things back where they were and then proceed from there.


#7

I doubt v4 will help me in any way, because the problems are just in the lookup script itself. It has nothing todo with helpspot whatsoever (besides the fact of course I got the script from your faq websites). All the errors I posted and timers I logged can be validated without even using any part of helpspot by just calling the script and let it search for any email address with adding ?email=emailaddress@I.look.for to the end.

I am clueless about php on windows machines, so I was hoping someone could give me a pointer to ramp up some debug levels for the php interpreter, so I can have a look at a debug.log somewhere in the hopes to get anything out of it.


#8

Errors should output in your browser, but if they’re not you may need to turn on display_errors in the php.ini (you can search for it, should be in program files (x86)/helpspot/php I believe).

Though, as you mention above the delay seems to be on the server. I doubt it’s the script, it’s waiting for something to resolve most likely. Might be interesting to look at the AD server, not sure what kind of logs it has.

Nothing has changed with the script so it seems like it’s a setting that needs to be adjusted on the AD side.


#9

your right. The fact that using v2 ldap gives me instant (but useless) results means, the script is working. Hell why not, it worked fine last month. But something has to have changed while moving to Windows 2012 R2 on the DCs and it seems only have changed in the v3 Part of the LDAP implementation, as the v2 gives still instant results. If a firewall where in between the two I would have suggested some kind of throttle mechanism, because thats how it looks from my end.


#10

Yeah, unfortunately the intricacies of AD/LDAP setup aren’t my speciality. Perhaps something with the user authenticating and access to the different protocols?