This document describes how to Resolve Cisco Prime Collaboration Assurance Duplicate Endpoints.
Contributed by Joseph Koglin, Cisco TAC Engineer
Cisco recommends that you have knowledge of these topics:
Knowledge of the Inventory Module and it's operations within Prime Assurance
Basic Linux fundamentals regarding Prime Assurance
This document requires this configuration to be implemented:
Full Root access will be needed - If you do not have root access please refer to the Bottom Section Named Root Access
The Prime Assurance application is installed and you have duplicated endpoints in the Inventory System. Ex. Two endpoints with the same name: SEPAA11BB22CC3
Note: The operations explained in this article are database impacting, hence these steps should be carried out only in expert guidance. In PCA 12.1 specifically, since inventory functionality has been overhauled, the requirement of these steps should not happen but can be considered as a last remedy under expert supervision.
The information in this document is based on these software versions:
Prime Assurance Command Line Interface
Prime Assurance inventory Module
All software versions applicable
No hardware requirements required
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, ensure that you understand the potential impact of any command
Cisco Prime Assurance - Duplicate Phones
This document is for environments that have duplicated phones in the system or scenarios where a remove and re-add of the endpoints is applicable.
This process will remove all phones and after that the process re-add them back
Step 1. Log in into PCA via Secure Shell (SSH) as root and port 26
Step 2. Input. cd /opt/emms/emsam/bin/
Step 3.Now you will stop services with the Input. ./cpcmcontrol.sh stop
Step 4. You will now check to ensure all services are down by the Input. ./cpcmcontrol.sh status
Once all services are down go to next step
Step 5. You will now start only the Database service by the Input. ./start_db.sh
Step 6 and Step 7 will remove the phones from the Database, In step 11 you will bring them back into the system
Step 6. Input. ./refreshCDT.sh (wait till it completes)
Step 7. Input. ./refreshPhone.sh (wait till it completes)
Step 8. Now you will bring the services back up with the Input. ./cpcmcontrol.sh restart
(perform ./cpcmcontrol.sh status periodically to ensure all services come back up)
Step 9. When the gui comes back up log in as the globaladmin user and do a cluster data discovery as the next step.
Step 10. Next you will perform a Cluster data discovery: Navigateto Inventory>Inventory schedule>Cluster data discovery.
Step 11. Select Run now (This step will retrieve back the phones)
Step 12. Wait until it is finished and the phones should be back and have no duplicates.
Note: This discovery is dependant on the number of endpoints in your cluster and the time to completion may vary
For example purposes you can compare the start and end time and see this particular one only took 38 seconds to complete.
Note: For informational purposes PCA will retrieve the phones via Real-time Information Service (RIS) and Administrative Extensible Markup Language (AXL) from the Cisco Unfied Communication Manager (CUCM) Publisher
Useful logs if any issues are encountered:
If you still are encountering duplicates please refer to the logs mentioned to review
Note: Full Root access will be needed, if you do not have please refer to the section Root Access. Once full root access is enabled please use a program such as Winscp to connect and use port 26 and the root user credentials.
/var/log/refreshPhone.log <-- this will let you know if there were any issues with the scripts running
Further troubleshooting Notes and Background information:
You may also want to see if you can restart the RIS service in the Call Manager cluster as this can clear up some discrepancies or issues.
When the phones are collected in cucm it will use axl+ris, so if you have issues you may want to restart the RIS service in cucm.
There will be no business impact when you restart the RIS service in the cluster, where-as a restart of the AXL service is not recommended during business hours.
Additionally rarely will you need to restart the AXL service so before doing so I would refer to the logs to see if a restart is necessary.
Also ensure the Call Manager's are managed and in cucm under System>Server the cucm publisher hostname/ip is pingable and resolvable.
As you may run into a case where you discovered and managed the Call Manager as the ip, however in the Call manager's System>Server it is listed by hostname.
What happens is when PCA collects the phones via axl+ris it will list however it is listed under System>server so if you have it listed as the hostname and it is not resolvable by pca then you will never receive these phones even if the cucm is managed because it was managed by ip.
This scenario is fixed by two ways:
Step 1. Login into PCA through SSH root user and port 26
Step 2. Cd /etc
Step 3. Vi hosts
Step 4. press i for insert
Put in as an example (there is a space in between ip and hostname)
In this example 10.10.10.10 and testexample.csc.edu is being used.
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1 localhost.localdomain localhost
::1 localhost6.localdomain6 localhost6
Step 5. Rediscover your Call Manager afterwards. Navigate to: Inventory>Inventory Management>Infrastructure>UC Applications>Communications Server
Step one. Ensure the Domanin Name Service (DNS) reverse lookup is resolvable through dns for the affected device.
Step two. Rediscover the Call Manager Cluster. Navigate to: Inventory>Inventory Management>Infrastructure>UC Applications>Communications Server
Select the affected Call Managers and select Rediscover
This section describes how to obtain full Root Access for PCA
Step 1. Log in through SSH to PCA and use port 26 as the Admin User
Step 2. Input. root_enable
Type in the root password you want
Step 3. Input. root and type in the root password
Step 4. Once logged in as root Input. /opt/emms/emsam/bin/enableRoot.sh
Step 5. Input. passwd and re-enter in your root password
You now should be able to close the SSH session and re-log in directly as root