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

[Rehayem, Anthony]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://puck.nether.net/pipermail/cisco-voip/attachments/20050418/fdddee8d/attachment.html