[cisco-voip] Call Manager 3.3(Sr4) with Microsoft AD Integration

[Ryan Ratliff]

I would hazard a guess that your search base is the root of the domain? 
  Take a sniffer or NetMon capture from your publisher when you do an EM 
login (or global directory search).  When you search the root of the 
domain in AD you will get referrals, even if the info you are looking 
for is returned automatically.  CM will try to chase down those 
referrals to get at least some response (even if it is null).   The 
referrals you get will be different in AD2000 vs 2003.  DISCLAIMER -- 
I'm no MCSE and I won't even pretend to be an AD expert.  Below is what 
I've seen from looking at customer's sniffer traces, treat it as 
anecdotal at best.

In 2003 you will get usually 3-4 referrals, the important ones being 
domaindnszones and forestdnszones.  Any failure to search those two 
will cause major delays.   By default forestdnszones is any DC that is 
a name server in your AD (I'm not sure what domaindnszones is but I 
assume it's similar).  If you do an nslookup against those two entries 
you will most likely get a list of responses.

In 2000 I've seen that a search against the root will result in 
referrals for every DC.  One of those DCs goes down and all of your 
ldap searches get very long as CM will try to connect to the DC that is 
down and fails.

The root of the delay, regardless of what version of AD you are 
running, is referrals that CM can't parse.  Take your sniffer capture 
from the publisher while trying an EM login.  Filter it for http and 
ldap (in the view, never use a capture filter).  You'll see the phone 
request the EM login, then CM will do it's ldap thing (bind request, 
search request, etc).  In the search response you will see referrals 
and you should see CM chase down those referrals.   You may also see CM 
apparently do the same series of searches 20-30 apart.   This indicates 
that CM is failing to connect to one of the referrals.

So now that you have your list of referrals, try pinging each of them 
from the publisher.  Can't ping one?    That's your problem.

If all of them ping, then you may have a more quirky issue.  Try 
filtering for all TCP packets on port 389 (or whatever your ldap port 
if you've changed it).   Look for any SYN message from the CM that 
either gets a RST immediately OR gets no response at all.  With no 
response you should see the same source port send a TCP SYN to port 389 
on the remote server at exponentially-increasing intervals (3s, 6s, 
12s, etc).  This is what causes the big delays.

Once you've fixed whatever DNS configuration that was causing CM to 
connect to the server that was down or incorrect, you'll need to either 
restart the publisher or just bounce IIS and Tomcat.  Also don't forget 
to do a 'ipconfig /flushdns'.

Hope this helps,

-Ryan
On Apr 18, 2005, at 7:41 AM, Rehayem, Anthony wrote:

For the past 18 Months we have been running our Call Manager cluster 
integrated with Microsoft Active Directory instead of using the inbuilt 
DC-directory on the call managers. Recently due to expansion of our 
Active Directory we have been experiencing problems with Extension 
Mobility login failures.
 
When running the Customer Directory configuration plugin we specified 
the FQDN instead of specifing a particular DC Server. This then enables 
us to leverage of the builtin AD redundancy that we already have in 
place. The theory behind this is that the quickest DC server will 
respond to a new request when a user attempts Extension Mobility login.
   
What I would like to know is whether ther is a way we can monitor which 
server responds to the request when a extension mobility request is 
made. I am aware that there is a log file kept in the c:\program 
files\cisco\trace\culs but this does not show any real detail as to 
which server has responded to the request.
   
The reson behind this is that we have had on two recent occasions 
instances where a DC servers located in a our main site have gone 
offline. The AD redundancy should kick in and start to accept login 
request from ofher DC servers located in other sites. This has proven 
so far as to not be the case therefore not allowing any users to login 
to the phone using extension Mobilty and and error is presentd on the 
phone error [6] which points to a directory services error.  I need to 
confirm whether the directory integration where by specifying the full 
FQDN is working.
   
Any help will be greatly appreciated.
   
 
 
 
 
This e-mail and any attachments may contain confidential information 
that is intended solely for the use of the intended recipient and may 
be subject to copyright. If you receive this e-mail in error, please 
notify the sender immediately and delete the e-mail and its attachments 
from your system.  You must not disclose, copy or use any part of this 
e-mail if you are not the intended recipient.  Any opinion expressed in 
this e-mail and any attachments is not an opinion of RailCorp unless 
stated or apparent from its content. RailCorp is not responsible for 
any unauthorised alterations to this e-mail or any attachments. 
RailCorp will not incur any liability resulting directly or indirectly 
as a result of the recipient accessing any of the attached files that 
may contain a virus.
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip