[cisco-voip] Does the IPCC Express CAD login process require LDAP write access?

[Baumgartner, Matthew]

Does the CAD login process require LDAP write access (i.e. CUCM
Publisher Access)? 

NOTE: IPCC is using DCD as its LDAP server.

 

As we can specify more that one LDAP server in IPCC 4.X even when using
DC Directory, would you agree the only thing that we would loose (from
an IPCX perspective) if we could not access the Publisher (and could
still access DC Directory on a Subscriber) is the ability for an Agent
to login to EM on an IP Phone????

 

"You can also specify one or more LDAP servers to be used if the primary
LDAP server fails. To do so, enter the host name, IP address, or
Microsoft AD domain of each backup server in the order that they should
be used if a failover occurs. Separate each entry with a comma (,), a
semicolon (;), or a space."

 

>From page 85 of 91 in the IPCC 4.0 SRND (IPCC Express Integration with
LDAP Server)

 

"Since user authentication requires access to user database in LDAP
server, if LDAP server is down or unavailable, you cannot access CRS
Administration web interface and agents cannot login. Thus, you should
install a redundant LDAP server to provide high availability."

 

________________________________

From: cisco-voip-bounces at puck.nether.net
[mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Baumgartner,
Matthew
Sent: Monday, 18 February 2008 2:08 PM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] IPCX Login if Publisher is down

 

Hi All,

 

I have a question regarding IPCC and CCM Split Clustering...

 

*         CCM 4.2(3) sr2b

*         IPCC 4.0(5) Build 042 

 

In IPCC version 4.X can Agents login when the publisher is not
available?

 

The below is and excerpt from the IPCC 3.5 SRND and it clearly states
that this is not possible. 

However I can't seem to find clarification if this was fixed in IPCC
version 4 or not.

 

 

>From the IPCC SRND page 37:

 

If the failed Cisco CallManager is the DCD server authenticating the
IPCC Express (the Directory Host Name defined in IPCC Express
Configuration and Repository, Directory Setup parameters), there is no
IP application redundancy because the failure of a Cisco CallManager
hosting DCD is a single point of failure for IP IPCC Express. The
following behaviour can occur:

 

*         LDAP authentication errors will occur in IPCC Express
Application Administration. 

*         All incoming calls to the IPCC Express route point will return
reorder tone (fast busy). 

*         Agents will not be able to log in again. 

 

For this reason, the subscriber server should be configured as the
primary CTIM and Cisco CallManager.

An option for reducing the downtime is to install a DCD on a standalone
Cisco CallManager server in the cluster or on an external corporate
directory server.

 

 

Any help would be greatly appreciated...

 

Thanks,

Matt Baumgartner
Senior Technical Consultant 
Communication Services 
CCIE #14535 Voice

Getronics Australia Pty Limited 
Getronics combines the service capabilities of the original Dutch
company with those of Wang Global, acquired in 1999, and of the Olivetti
systems and services division. We are ranked second worldwide in network
and desktop outsourcing and fourth in network consulting and integration
(Source: IDC 2002-2003).

2 Minna Close 
Belrose NSW 2085 
Australia 
T: +61 2 9847 7662 
F: +61 2 9847 7157 
M: + 61 411 126 709 
Email: matthew.baumgartner at getronics.com

Communication Services | ICT Security | Network Integration Services |
Network & Desktop Outsourcing | Application Integration & Management
www.getronics.com.au <http://www.getronics.com.au/> 

Please note that whilst we take all care, neither Getronics nor the
sender accepts any responsibility for viruses and it is your
responsibility to scan for viruses. The contents are intended only for
use by the addressee and may contain confidential and/or privileged
material and any use by other than the intended recipient is prohibited.
If you received this in error, please inform the sender and/or addressee
immediately and delete the material.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://puck.nether.net/pipermail/cisco-voip/attachments/20080218/a7c45f68/attachment-0001.html