UAW Process in Continuous Loop Updating Configuration [Cisco Unified Intelligent Contact Management Enterprise]

Document ID: 27712

Introduction
Prerequisites
      Requirements
      Components Used
      Conventions
Problem
Solutions
Related Information

Introduction

When the Cisco Intelligent Contact Management (ICM) Distributor service is started, the Update Admin Workstation (UAW) process verifies if the Admin Workstation (AW) configuration matches the connected ICM CallRouter. If a match is not found, the UAW process initiates a delete/rebuild of the local database of the AW (cust_awdb). The local database is rebuilt with the configuration from the ICM Logger, not the ICM CallRouter. In rare circumstances, it is possible for this delete/rebuild process to enter a continuous loop, which occurs when the ICM Logger and ICM CallRouter do not match configuration synchronization keys.

Note: This is not the only situation where the UAW process might continuously cycle. If your symptoms do not match this document, please contact the Cisco Technical Assistance Center (TAC).

Prerequisites

Requirements

Readers of this document should have knowledge of these topics:

ICM database schema.
ICM Dumplog utility.
ICM RTTest utility.
SQL queries and query utilities.

Components Used

The information in this document is based on these software and hardware versions:

Cisco ICM 4.0 and later.

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.

Conventions

For more information on document conventions, see the Cisco Technical Tips Conventions.

Problem

When a delete/rebuild local database loop exists, the first noticeable problem is related to configuration changes, which you cannot make. Configuration utilities fail to open, and an error message is displayed, as shown in figure 1.

Figure 1 – Error Message

To investigate the problem, use the Dumplog utility, and check the UAW process on the Cisco ICM Distributor. If a delete/rebuild loop exists, the following message sequence repeats at the end of every "delete" and "copy" sequence:

12:20:50 dis-uaw Trace: Starting incremental copy operation.
    12:20:50 dis-uaw Trace: Recovery keys: 269826451424.0 (in memory),
    269826451424.0 
    (local AWControl), 269826451423.0 (router AWControl).
    12:20:50 dis-uaw Trace: Recovery keys: 269826451424.0 (in memory),
    269826451424.0 
    (local AWControl), 269826451423.0 (router AWControl).
    12:20:50 dis-uaw Trace: Local database must be initialized before
    proceeding.

Note: The Recovery Key value for "router AWControl" does not match the Recovery Key value for "in memory" and "local AWControl". This indicates the Recovery Key value retrieved from the Logger is out of synchronization with the Recovery Key value held in the Router, so there is a Recovery Key mismatch at the Central Controller level.

To confirm that a Recovery Key mismatch exists between the Logger and Router, check the Router Recovery Key in RTTest, with the cfgstat command. For example:

rttest: cfgstat
  Current op:       Delay
  Seconds:          120
  
  Logger up since:  05/23 13:38:49 (5.9 hr)
  Logger last down: 05/23 13:35:33 (6.0 hr)
  LastUpdateKey:    269826451423
  Ping req:         true
  Key check req:    true

The "LastUpdateKey" value represents the Recovery Key value held in the memory of the Router. Compare this value with the Recovery Key held by the Logger. Run the following SQL command on the Logger database to view the Logger's Recovery Key:

select max(RecoveryKey) from Config_Message_Log

If the Recovery Key values for the Router and Logger still differ, a mismatch is confirmed.

Note: If a mismatch occurs between the Logger and Router on one side of the Central Controller, the same mismatch exists on BOTH sides of the Central Controller.

Solutions

There are two options to resolve a Recovery Key mismatch between the Routers and Loggers:

Run the exit_router command in RTTest on one of the Routers. You need not perform this on both Routers.
Stop both Logger and Router services, simultaneously, and bring them back up in this order:
1. Logger A
2. Router A
3. Router B
4. Logger B
It does not matter which side of the Central Controller is brought online first, but the sequence is still important (for example, Logger X, Router X, Router Y, Logger Y)

Note: Either one of these options can interrupt call routing through ICM, so it is recommended that you perform these options during a maintenance window, which may be scheduled during a low call volume time or during off-hours. It is important to correct the Recovery Key mismatch, but resolution can wait as long as configuration changes are not needed, and thereby provide a shorter or longer window of time based on business needs.

Related Information

Updated: Feb 10, 2005

Document ID: 27712

Hierarchical Navigation

Cisco Unified Intelligent Contact Management Enterprise