CCM and AD - Slowness

[mloraditch]

I integrated my CCM with AD over the weekend and it is quite slow. I've got two guesses as to the reason. 1)That's just the way it is or 2) It's because I'm going across my vlans from my voice to my regular network. If it's the latter, what does anyone think of this. Install a second nic in my server put it on my network and then route traffic to my ad server through that nic. Is this a good idea, bad idea or???

Thanks for your help

[Jason Hamlett]

What exactly is working slow? When we did our initial conversion, directory look ups were extremely slow, but we had pointed the user dir to our entire tree so it was trying to do lookups on all of our trusts as well.

You could add a second nic, but really what the CCM is looking for out of AD is fairly neglible. I think something else may be going on.

[mloraditch]

for search base I have it pointed to our entire domain, dc=domain,dc=com as we have our users sorted in OUs by location. I can't move the users around and while it seemed odd to me, the docs read as if it would only search for users in the users folder of ad if i had the cn=users in front of the domain, this seemed wrong, but i'm not a complete expert in ldap syntax

[simon.draper]

Hi - not sure if you're still having issues but we had similar problems. In the end I did a packet trace on the CCM and found that it resolved the domain name to any DC on the network.

Sometimes this was local and sometimes it was a DC on the other side of the globe. When it was local all was good otherwise it was very slow or just didn't work. After much work with the TAC the recommended solution was to enter a host file entry of' ' - this works great for performance - but is obvioulsy not ideal in terms of redundancy.

I'm sure there must be a better way to do this, but I'm not a MS person and anyone I ask does not have any better ideas - other than to migrate away from AD integration.

[mloraditch]

that makes a whole lot of sense, I will have to check that out, there are probably ways of fixing that for redudancy with load balancing or clustering but we're a smaller company and don't have to worry about that

[simon.draper]

good thinking, why didn't anyone mention a cluster to me!!

It's reasonably easy to test if this is likely to be the problem even without a sniffer (though a sniffer trace is more conclusive - make sure you're sniffing on the Callmanager port). The way the plugin appears to work is lookup an IP for the domain name and then perform an LDAP query on the resolved IP

So ping your domain name from the callmanager (or workstation if DNS config is the same) and note the returned address, then do an 'ipconfig /flushdns' and do another, if you get boxes that are remote or unreachable then you most likely have the same issue.

We have given up on the plugin, other than this issue we've had too many occassions where AD admins have essentially broken the plugin, performing AD tasks they didn't think would impact CallManager.

[adhernan]

I wouldnt think the problem would source from your ip phone being on a different vlan. If you search for a user from the user search page in CCM is the query still slow? YOu would likely have to span the port query and review with a sniffer to get a better idea .. Likely check the call manager side and where the AD box is too. -Adam

[gogasca]

Hi sir,

Remember this very good post from Kevin:

http://forum.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Archive&topic=Voice%20and%20Video&CommCmd=MB%3Fcmd%3Dpass_through%26location%3Doutline%40%5E1%40%40.1dd914b1/4#selected_message

As Adam stated, sniffer trace is your friend.

//G