UCCX 8.0.2. HA unable to manualy sinchronize directory Services

Robin Lamarre · ‎07-13-2011

Good morning,

We have an agent that exists as a Call Manager user with an IPCC extension, the same user shows up in RMCM under de UCCX 8.0.2, but he is unable to log in to CAD with error "ID introuvable" (ID NOT FOUND). When we look in the Desktop administrator, we notice the user is missing. When we try to initiate a manual directory services synck, we instantly get the error "CDAUI2082 At least one error has occured during the manual synchronization of directory services. Contact Technical Support"

We found BUG ID CSCtd94036 , no luck after increasing the timeout value to even 120s.We restarted both UCCX with no change in behavior. IF you remove the IPCC extension in the end users of CUCM, the user becomes a unactive agent instantly and if you go give the IPCC extension he is back in RMCM, but never shows up in Desktop administrator.

Anybody knows of a fix, or necessary debugs to gather before we go to TAC on this ?

Thanks.

Robin Lamarre · ‎07-15-2011

here are some few interesting debug I gathered. means anything to anyone?

2011-07-14 15:50:42:958 DEBUG [0x29b4ba0] ManualSync.cpp[76] DASynchronize: BEGIN.

2011-07-14 15:50:42:959 DEBUG [0x29b4ba0] LCLDAP.cpp[454] Get: First entry is NULL.

2011-07-14 15:50:42:959 DEBUG [0x29b4ba0] LCServerType.cpp[310] Get: End false.

2011-07-14 15:50:42:959 DEBUG [0x29b4ba0] ManualSync.cpp[167] GetServerIOR: Error getting Server Type Profile from LDAP.

2011-07-14 15:50:42:959 ERROR [0x29b4ba0] WAL2237 DASynchronize: Error getting GetServerIOR for Sync Server.

2011-07-14 15:50:42:959 DEBUG [0x29b4ba0] ManualSync.cpp[80] DASynchronize: Could not connect to Directory Services Synchronize Server.

2011-07-14 15:50:42:959 ERROR [0x29b4ba0] WAL2223 write: Error synchronizing directory services.

2010-12-01 12:50:26:376 ERROR SPLKTSSP2038 Network communication error (TRANSIENT).

2010-12-01 12:51:23:406 ERROR SPLKTSSP2038 Network communication error (TRANSIENT).

2010-12-01 12:52:13:550 ERROR SPLKTSSP2038 Network communication error (TRANSIENT).

2010-12-02 16:25:52:194 INFO STD0005 Client disconnected from service at <192.168.8.16>.

2010-12-02 16:25:52:209 INFO LC0012 Failed to bind to Calabrio LDAP service on <192.168.8.16>: <-1>

2010-12-02 16:25:53:017 WARN SOCKET3000 Received an invalid event from SocketLRMClient socket service. Recovery initiated. Error < unable="" to="" read="" from="" ="" attempting="" to="" read="" when="" the="" connection="" has="" been="" closed.=""> nested com.spanlink.util.socket.SplkClosedChannelException: Attempting to read when the connection has been closed.>.

ontact LDAP server>

kre8or3 · ‎07-15-2011

I would open a TAC case; when we had this issue, it was because of either the two PG's weren't replicating or there were "glue nodes". Glue nodes, we were told, could cause some database corruption.

Robin Lamarre · ‎07-15-2011

Thanks for the advise,

Second dilemma:

system is not latest release, would upgrading to 8.0.2SU3 be dangerous in this situation or it would be best before opening a TAC ?

kre8or3 · ‎07-15-2011

I would open the TAC case first. The glue nodes had to be removed manually from our system. I believe the replication issue was also a bug. Most of our issues were resolved by applying the 8.0(1A) patch.

Our system is enterprise but I believe the same type of problems existed in express.

Robin Lamarre · ‎08-22-2011

TAC was open,

After suffering trough 1 month of time wasting operations required by the first engineer, case was escalated to competent staff and resolved in 2 days. And yes, the problem was plenty of "glue nodes" introduced somehow in the replication process (or lack of at one point).

Glue was removed from the DB and tables rebuilt, all is now fine.

Thanks