After the Cisco Customer Response Solutions (CRS) server is installed on a high-availability cluster, the SQLUtility installation process runs indefinitely. Whenever you try to log in to either CRS server in the cluster, the installation process for SQLUtility begins. Once you complete the process, installation begins again until you cancel the process.
Cisco recommends that you have knowledge of these topics:
Cisco Unified Contact Center Express
SQL 2000
Active Directory (AD)
DC Directory Administration
The information in this document is based on these software and hardware versions:
Cisco Unified Contact Center Express 4.0(x)
Note: This issue is applicable to only Cisco Unified Contact Center Express 4.0(x); it is not applicable to Cisco Unified Contact Center Express 4.5 and higher.
SQL 2000
Note: This issue is not applicable to IP IVR or IP QM.
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.
After Cisco Unified Contact Center Express 4.x server is installed on a high-availability cluster, the SQLUtility installation process runs indefinitely. This issue is documented by the Cisco Bug ID CSCsc72942 (registered customers only) .
If you install SQL 2000 in a high-availability cluster, either coresident with CRS or on expansion servers, you must complete server setup on the first server that has SQL 2000 installed and activate the datastore components before you install SQL 2000 on the second server. If you do not follow this procedure, the SQLUtility program runs repeatedly.
In order to resolve this issue, complete these steps:
Choose Remove Server from Appadmin Control Center in order to remove the second database server from the cluster.
Complete the SQLUtility installation on the first CRS server.
Run the CRS installer on the second database server in order to add back that node to the cluster.
Run the server setup on the second database server.
If you did not complete the CRS server setup as described in the Problem section, this procedure resolves this issue in a DC Directory environment and does not require you to reinstall CRS on the second node.
Note: This procedure is not applicable for an Active Directory integrated system.
Open the LDAP (AD or DC Directory) in the second CRS Datastore server and drill down to ou=clusters, ou=<profile_name>, ou=Nodes, ou=<nodeid_secondserver>, ou=<NodeSpecific>, ou= Components, ou= <CRS Repository Datastore.XXXXXXXXXXXX>
Note: profile_name refers to the cluster profile name, nodeid_secondserver refers to the node-id of the second CRS datastore server, and CRS Repository Datastore.XXXXXXXXXXXX refers to the LDAP field name that consists of the CRS Repository Datastore string.
Right-click CRS Repository Datastore.XXXXXXXXXXXX, and select Properties.
Choose Modify, and rename CRS Repository Datastore.XXXXXXXXXXXX to CRS Repository Datastore.XXXXXXXXXXXX.bak
Continue the SQLUtility installation on the first CRS node.
Once the SQLUtility installation of the current database server is complete, rename the LDAP property field of the second CRS datastore server back to the original name: CRS Repository Datastore.XXXXXXXXXXXX
After the SQL Database upgrade on the first CRS node completes, run the SQLUtility on the second server.