Cisco Unified Intelligent Contact Management Enterprise

Why Does Cisco ICM Logger Fail to Synchronize?

Document ID: 45340

Updated: Feb 03, 2005



This document explains two reasons why Synchronization and State Transfer on one side of the Cisco Intelligent Contact Management (ICM) Logger database fails to synchronize with the other side of the Cisco ICM Logger database(s) and a possible workaround using the Synchronize function of ICMDBA to synchronize the data of two Logger databases.



Readers of this document should be knowledgeable of these topics:

  • Cisco ICM

  • Microsoft SQL Database

Components Used

The information in this document is based on the software and hardware versions below.

  • Cisco ICM version 5 and later

  • Microsoft SQL Server 2000 Standard or Enterprise Edition with Service Pack 2

The information presented in this document was created from devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If you are working in a live network, ensure that you understand the potential impact of any command before using it.


For more information on document conventions, refer to Cisco Technical Tips Conventions.


In synchronized execution, duplicated processes are always processing identical input and generating identical output. If one process fails, the other continues to operate without interrupting system operation. Once the failed process returns, it is immediately updated with the current state of ICM processes running on its peer.

In order to synchronize one peer with another, the system performs a state transfer. The state transfer facility allows a synchronized process (for example, a Logger) to copy the variables in its memory to its peer. In the event that one side fails, the recovering system receives the variables from the currently executing system and is able to restart with a copy of the current state of ICM processes. For example, as soon as a failure is detected on the Side A Logger, ICM software uses only Side B. When the Side A Logger is restarted, ICM software invokes a state transfer to immediately update the Logger database Side A components with the current state of the counterparts on Side B.

There are two known instances where the state transfer fails. In the following example, the direction is to synchronize the Side A Logger database with the Side B Logger database. The lgr process trace on the Side A Logger (the receiving, failing side) is shown below.

23:26:58 Trace: Release 5.0 service pack 0+, Build 09778
23:26:58 Initializing Event Management System (EMS) Library.
23:26:58 Trace: EMS Server pipe <cust_inst>\LoggerA\lgrEMSPipe enabled for 
23:26:58 Trace: Logger Type is 1
23:26:58 Initializing Node Manager Library.
23:26:58 Trace: NodeManagerHandler: Logger Initializing
23:26:58 Trace: DB-Library version 7.00.839.
23:26:58 Trace: SQL Server version 8.0.760
23:26:58 Trace: Connect to <cust_inst>_sideA database.
23:26:58 Trace: Connected to <cust_inst>_sideA database.
23:26:58 Trace: Setting the maximum number of DB-Lib connections to 101
23:26:59 Trace: Starting config checksum, updateKey = 310473991055
23:27:03 Trace: Checksum config complete: Rows = 23442, bytes = 13409511, 
  checksum = 783166570, updateKey = 310473991055
23:27:03 Trace: SQL Server sort order is Latin1_General_BIN
23:27:03 Trace: Database uses Major Version 77, CC Minor Version 4 of the Schema
23:27:03 Trace: Logger Compatible with Major Version 77, CC Minor Version 4 of 
  the Schema
23:27:03 Trace: Partitioning is not enabled!
23:27:03 Trace: EMT I/O completion ports: max threads=4, concurent threads=0
23:27:03 Connection to MDS process established.
23:27:03 Trace: The Logger is registered with MDS; handle = 36
23:27:03 Trace: GetInSync: Serialization Disabled.
23:27:03 Trace: GetInSync: Synchronization holdoff disabled.
23:27:03 Trace: The Logger is NOW Starting MDS Client Message Processing
23:27:03 MDS is in service.
23:27:04 Initiating state transfer RECEIVE operation.
23:27:08 Trace: NodeManagerHandler: Logger Waiting for MDS Messages
23:27:18 Trace: NodeManagerHandler: Logger Waiting for MDS Messages

Note: The above example is displayed over multiple lines due to space limitations.

The lgr process shows Initiating state transfer RECEIVE operation. After repeating the waiting messages (bold) for three minutes, the lgr process window on the Side A Logger asserts and restarts.


The key to solving Logger synchronization problems is to review the lgr process trace on the Logger that sends the state.

The lgr process trace on the Side B Logger (the sending, operational side) is shown below.

16:47:39 Trace: Thread[2536]: Commit Config Transaction 2000000598
16:47:39 Trace: PrepareToSendState
16:47:39 Trace: Synchronizing Configuration Data
16:47:39 Trace: LastUpdateKey for B Configuration is 310466685004.0
16:47:39 Trace: LastUpdateKey for A Configuration is 309975091099.0
16:47:39 The Logger has completed Database Synchronization, 200 Config Message Log 
  Entries Sent.Seed = 11088734
16:47:39 Trace: Unable to GetTempFileName for temporary state transfer file.  
  Last API Error [5]: Access is denied.
16:47:39 Trace: Unable to setup to use file in sending state.
16:47:39 Trace: CleanupPreparedState

Note: The above example is displayed over multiple lines due to space limitations.

Solution 1

The drive where ICM is installed is full or the %temp% directory for the ICM Node Manager process is full. There is no space for the temp files to be stored during the state transfer.

After freeing up disk space on the Logger, the next state transfer attempt succeeds without a problem. ICM 5.0 is not supported on Microsoft Windows NT, as noted in the Bill of Materials (BOM).

Solution 2

The ICM Node Manager (NM) process user does not have access to its own %temp% directory located in C:\Documents and Settings\<user_name>\Local Settings\Temp.

Note: The user_name is the Domain User of the machine the Logger is installed on.

Grant Full Control of that folder to the Domain Users group of which the user is a member, and the next state transfer attempt succeeds without a problem.

Related Information

Updated: Feb 03, 2005
Document ID: 45340