This document provides information to troubleshoot the Lightweight Directory Access Protocol (LDAP) in a Cisco Unified Contact Center Express. Although this document contains some information about common problems with Cisco Customer Response Solution (CRS) and Cisco CallManager, this document makes no attempt to completely describe these components. Rather, this document concentrates on the symptoms and methods in order to identify the source of problems that can occur. The problems can relate to software or configuration.
Cisco recommends that you have knowledge of these topics:
The information in this document is based on these software and hardware versions:
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Refer to Cisco Technical Tips Conventions for more information on document conventions.
If the Node manager did not start and you see many LDAP connectivity exceptions in the MCVD logs, then there can be some problems in the ccndir.ini file. The ccndir.ini contains the bootstrap information, for example, it contains the information of the LDAP server and its credentials where CRS stores its configuration.
When you start the CRS Serviceability tool and if there was something wrong with the information in the ccndir.ini file, the Failed to connect to LDAP error message is received.
It also shows the CRS Bootstrap dialog dialog box in which you can correct the ccndir.ini file. You can enter the correct values in the CRS Bootstrap dialog box, and choose SYNC.
If it appears again in the next alert, then your information is still wrong. You receive this alert until the issue with the connection to the specified LDAP server is solved.
If the given information was right, you receive these messages. Click OK on both the messages and the serviceability window appears.
After you complete this, restart the CRS Node Manager service in order for the changes to take effect.
Cisco CRS Appadmin does not allow any user to login or to see any agents in the Resources page in the Subsystems > RmCm menu. This can be due to the wrong Cisco CallManager LDAP server information, where Cisco CallManager stores its user information.
This can be resolved if you use the Cisco CRS Serviceability tool. In the Cisco CRS Serviceability tool, choose the Cisco CallManager LDAP Information tab, type the correct values and click Update. The User Base location, the Cisco CallManager Base Context or the Directory Manager credentials are possibly incorrect.
If you are sure about the information, click Yes for this alert:
Click OK in order to continue.
Restart the CRS Node Manager service in order for the changes to take effect.
Complete these steps in order to delete all existing licenses:
In CCN Apps > clusters OU, choose your cluster profile OU and choose ClusterSpecific > License > Flexlm OU, which contains all the licenses uploaded.
In the right pane, you can see the licenses listed. In order to delete the license, right-click on each of them and choose Delete.
In order to upload new licenses, go to the CRS Appadmin and use the License Information Link in System > Control Center. Choose Add license(s) in order to upload new licenses.
Refer to IPCC: Troubleshoot Mutex Lock Errors for more information on how to troubleshoot the mutex lock errors.
Refer to "Error While Handling The Input Request" Error Message When Configuring CRS for more information on how to clear the archive flags.
In situations where you want to redo the Cluster Setup, there is a flag called setup found at CCN Apps > clusters > <profile> > appadminsetup. This contains the value DONE when the Cluster Setup is completed successfully. In order to redo the Cluster Setup, change its value to FRESH_INSTALL. After you change this, refresh the CRS Appadmin in order to see the screens for Cluster Setup. If you redo the cluster setup, this takes you through the windows where you choose your administrator for Appadmin.
Note: Only complete these steps if necessary since it can harm the regular functioning. This can be used in the case where the user has forgotten the admin user ID.
In order to repeat the server setup for a node, there is a setup flag for each node located at CCN Apps > clusters > <profile> > Nodes > <node_id> > appadminsetup. It has DONE as its value if the server setup was completed for the corresponding node. In order to redo the server setup for that node, change its value to FRESH_INSTALL. After you change this, refresh the CRS Appadmin in order to see the screens of server setup.
With the MADM LIB_CFG debug turned on, this logs print information about the duplicate GUIDs, and you need to find out which one is the correct entry. Then, you can delete the incorrect one.
5635: May 14 15:55:13.075 GMT+530 %MADM-LIB_CFG-3-CONFIG_FAIL:Fail to load ldap configuration file:
Exception=ICD LDAP: Duplicate guids in users agenty and agentx
5636: May 14 15:55:13.075 GMT+530 %MADM-LIB_CFG-3-EXCEPTION:java.lang.IllegalStateException: duplicate guid
5637: May 14 15:55:13.075 GMT+530 %MADM-LIB_CFG-3-EXCEPTION:
5638: May 14 15:55:13.075 GMT+530 %MADM-LIB_CFG-3-EXCEPTION:
5639: May 14 15:55:13.075 GMT+530 %MADM-LIB_CFG-3-EXCEPTION:
5640: May 14 15:55:13.075 GMT+530 %MADM-LIB_CFG-3-EXCEPTION:
Also in the DC Directory, make sure you delete only the duplicate user entries in these three locations:
Under the OU Cisco.com > CCN > profiles > user-profile
Under the OU Cisco.com > CCN > profiles > user-CCN profile
Under the OU Cisco.com > Users, then double-click on the duplicate username, choose the AVVID Information tab and make sure the GUID matches the duplicate GUID.
During an upgrade from Cisco CRS 3.X to 4.0(X), the installer creates a new 4.0 profile and it does not disturb the 3.X profile. So, if an upgrade fails, you can delete the 4.0 profile. The 4.0 Installer can create a new OU called clusters in CCN Apps OU where you find the new 4.0 profile, which is previously mentioned for the 4.0 installer.
Under the configurations, applications and the workflow OUs, in order to differentiate with the 3.X profile that already exists, the installer creates profile names appended with ._$$CRS40$$_. You have to delete the profiles in these four OUs:
For example, IPCC is the profile name you gave. You then have to delete:
CCN Apps > clusters > IPCC
CCN Apps > configurations > IPCC._$$CRS40$$_
CCN Apps > applications > IPCC._$$CRS40$$_
CCN Apps > workflows > IPCC._$$CRS40$$_
Note: Be careful not to delete anything that does not have a $$ as previously mentioned, which can corrupt the 3.x system.
The CRS upgrade from 4.0(X) to 4.0(Y) fails with this error message in the install logs:
CSCO:Wed Mar 08 19:57:52 2006:csco_eftn::DialogDisplayMessageBox() in:
hMsi=1606, sText=This server belongs to a different cluster.
You must uninstall Cisco CRS to remove this server from its current cluster
before installing it in a new cluster. Do you want to uninstall
Cisco CRS now?, sCaption=Cisco Customer Response Solutions, nType=36
In this situation, LDAP is left with junk uncleaned temporarily created profiles in the form of profilename.xxxxxxxxxxxx. This issue is documented in the Cisco bug ID CSCsd61447 (registered customers only)
Remove all of the profiles with the profilename.xxxxxx in order to resolve this issue and only leave the base profilename that does not have the .xxxxxxx appended to it before you retry the upgrade process.
Mostly for LDAP connectivity issues, the default tracing is enough to analyze. If there is a problem with the users retrieved from LDAP, you can turn on the LIB_LDAP with the Appadmin, Engine, or Editor component in which the issue occurs. Refer to CRS Quick Tracing Guide for Version 3.x and 4.0.x for more information on CRS tracing.