UCCE PIM Failure when Added to PGs in Duplex Mode

Introduction

This document describes a failure that occurs in Cisco Unified Contact Center Enterprise (UCCE) when you attempt to add a new Peripheral Interface Manager (PIM) to a Peripheral Gateway (PG) that runs in Duplex mode before the services on both PGs are deactivated. A solution to this problem is also described.

Background Information

The creation of new PIMs is an easy task in all versions of UCCE, which requires that you simply complete a PG setup or Intelligent Contact Management (ICM) setup (dependent upon the version), and add the appropriate PIM configuration.

Since PGs usually run in Duplex mode, administrators might be tempted to minimize downtime and perform this task on one side while the other side is active and handles calls. However, this is likely to fail because it leaves the newly-installed PIMs with an invalid configuration and in an idle state on both PGs.

It is important to note that this behavior is expected and is designed for a legitimate reason. If two PGs are required to run in Duplex mode, they must be synchronized. However, in order to ensure that the PGs can be synchronized, both sides must run the exact same version and build. Also, the PGs must have certain components from the ICM registry synchronized. If there is a mismatch, the ICM registry entries are synchronized as part of the Open Peripheral Controller (OPC) state transfer process. This includes the portion of the registry hive that contains the PIM configuration settings.

Problem

You want to add a new PIM to a PG that runs in Duplex mode. In order to minimize downtime, you deactivate only one PG and attempt to add the new PIM while the other PG remains active. The attempt fails and these issues occur:

1. When you activate the PG to which you added the new PIM, it loads the updated registry configuration into the memory so that it has knowledge of the PIMs that must start.
   
   
2. The PG then tries to synchronize with the other PG in the Duplex, which currently contains the previous registry configuration in the memory. If there is a mismatch, the synchronization process effectively overwrites some of the new settings. The overwrite occurs first in the memory, and then in the registry of the modified PG. This sends the new PIM into a disabled state (at a minimum), since the PG to which the new PIM was not added has no knowledge of the new PIM.
   

   Note: There are other settings that might be overwritten as well.

3. The new PIM starts normally, but it does not attempt to activate or connect to the peripheral and remains in an idle state.

Although it might seem logical to repeat the update procedure on the PG that was kept active, it does not resolve these issues. When the second PG attempts to synchronize with the PG that was updated first, it overwrites the same part of registry because the new PIM on the first PG has an invalid configuration (due to the issues described in Steps 1 through 3).

This leaves both of the PGs with the new PIM installed and a synchronized configuration that is invalid. Neither PIM attempts to activate or connect to the peripheral, and they wait in an idle state indefinitely.

Solution

Complete these steps in order to resolve the problem:

1. Deactivate the services on both PGs in the ICM Service Control.
   
   
2. Complete the PG setup process, and take note of the PIM configuration.
   
   
3. Remove all of the newly-added PIMs.
   
   
4. Add the new PIMs to both of the PGs while the services are deactivated.
   
   
5. Activate the services on both PGs (the order of activation does not matter).
   
   
6. Verify that the PIMs are active and that they connect to the peripherals on both PGs.

Note: Any modifications that are made to the PG configuration must be performed while services are deactivated on both PGs. Other situations are not supported, and it is likely that problems might occur.