Introduction
This document describes how to troubleshoot issues related to this error : » Database Communication Error » while CUCM page is accessed.
Prerequisites
Requirements
Cisco recommends that you have knowledge of this topic:
- Cisco Unified Communications Manager (CUCM) version 11.5
Components Used
The information in this document is based on CCM version 11.5
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.
Background information
This document helps you to understand the scneario and TAC techniques to troubleshoot when you get Database Communication error while the CUCM GUI page is accessed. This message indicates that there is a problem with the A Cisco DB service, or it could be related to the ODBC driver, but, this document deals with all what the user can check and a little of what TAC checks when the A Cisco DB service does not work as expected.
One of the biggest causes of this can be an unexpected shutdown of the system. Ungraceful shutdown on Linux OS can result in corruption of files which get closed abruptly when the system shuts down. When this happens, there is a series of files that needs to be closed gracefully. These files might then be needed by the system to complete the boot up process later.
Other causes can be a change in the FQDN, A change from IP address to FQDN or vice-versa without the proper procedure.
When the above issues arise, there are some action items that should be followed in a bid to save the system. Saving the System is mentioned because more often than not, if any particular service in Linux is not starting properly (stuck in starting or stopped state), then it might be a problem in the daemon/process responsible to start that particular service. It can only be corrected as the server is rebuild.
Procedure to Troubleshoot
Step 1. Sanity Check of the System.
Make use of utils diagnose test and show status command outputs to see if there are any other errors being thrown up so that further actions can be planned accordingly. For example, ensure that the active partition is not 100% filled through show status. If this is not true, then it needs to troubleshot before you resolve other problems.
admin:show status
Host Name : CUCM11
Date : Wed Jul 25, 2018 00:10:07
Time Zone : India Standard Time (Asia/Kolkata)
Locale : en_US.UTF-8
Product Ver : 11.0.1.22045-1
Unified OS Version : 6.0.0.0-2
Uptime:
00:10:09 up 48 days, 10:56, 1 user, load average: 0.17, 0.29, 0.27
CPU Idle: 97.74% System: 01.26% User: 01.00%
IOWAIT: 00.00% IRQ: 00.00% Soft: 00.00%
Memory Total: 3925432K
Free: 188156K
Used: 3737276K
Cached: 610140K
Shared: 203520K
Buffers: 27696K
Total Free Used
Disk/active 14154228K 1154116K 12854984K (92%)
Disk/inactive 14154228K 1195212K 12813888K (92%)
Disk/logging 49573612K 3454524K 43594160K (93%)
Step 2. Restart the Service.
utils service restart A Cisco DB — restart the service through CLI.
admin:utils service restart A Cisco DB Do not press Ctrl+C while the service is restarting. If the service has not restarted properly, execute the same command again. Service Manager is running A Cisco DB[STOPPING] A Cisco DB[STARTING] A Cisco DB[STARTED] admin:
Step 3. Check hosts, rhosts and sqlhosts Files.
Although only hosts files can be matched through normal CLI of the server (remember, GUI is not accessible for you to go to the reporting page), make use of show tech network hosts command to match the entries in all servers of the cluster. If there is a mismatch in any server, you can restart the Cluster Manager service once it tries correct them.
admin:show tech network hosts -------------------- show platform network -------------------- /etc/hosts File: #This file was generated by the /etc/hosts cluster manager. #It is automatically updated as nodes are added, changed, removed from the cluster. 127.0.0.1 localhost ::1 localhost 10.106.112.122 cucmsub.emea.lab cucmsub 10.106.112.123 imnp10.emea.lab imnp10 10.106.112.126 CUCM-10.emea.lab CUCM-10 admin:
Step 4. Check the Files from Root.
This and the steps after it are only followed by TAC after getting root account access to your system. controlcentre.sh script is used in order to restart the service once from the shell.
From the locations /home/informix/.rhosts and $INFORMIXDIR/etc/sqlhosts, then the files are manually to match in all servers. After this, restart the Cluster Manager service to update the details in any file that might be needed during bootup.
Step 5. Check Informix.
Informix is the process responsible for the A Cisco DB service and it should show as on-line when the root user switches as informix and checks the status.
Note: All these steps, once checked, can help to bring the service back up if and only if the issue was either because of a mismatch in the host/rhosts file or informix stuck temporarily. As mentioned earlier, there can be many other reasons that could have caused these mismatches. The document above highlights the steps that be checked one by one just to narrow down where the problem might be.
In most of the stuation we need to rebuild the nodes if we are not able to restart the service from root of if the system files are corrupt.
Ref link to rebuild Publisher :https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/116946-technote-product-00.html
To rebuild Subscriber : Fresh Subscriber is installed with system configuration same as the old Subscriber
Introduction
This document describes most of the reasons that the Cisco Unified Communications Manager (CUCM) web pages or CUCM User page is not displayed or gives an error.
Prerequisites
Requirements
Cisco recommends that you have knowledge of CUCM.
Components Used
The information in this document is based on CUCM versions 7.x/8.x/9.x/10.x.
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.
Flow Diagram
The flow diagram for web access on CUCM is shown here:
Problem 1: Database Communication Error
When you try to log in to the CUCM Admin web page from Publisher, the ‘Database communication error’ error is received.
You are able to log in to the CUCM Admin web page from Subscriber, but any changes on CUCM cause one of these errors: ‘Error occurred while retrieving information from database. java.sql.SQLException: No DELETE permission.’ or ‘Add failed. The Insert privilege is required for this operation.’.
This issue can occur when you try to log in to the server after changes are made in the Publisher server, such as when the hostname or IP address is changed either through the CLI or the Operating System (OS) Admin page. In this case, revert the changes made back to the old configuration in order to let you log in.
If no changes were made to CUCM Publisher and you still receive the Database Communications Error message, then check these items:
- Enter the utils dbreplication runtimestate command in order to check the DBreplication Status. Confirm that the status of replication is 2 on all nodes without any errors or mismatches.
- Determine whether a Cisco database (DB) service currently runs. A Cisco DB not started on Publisher could also cause this issue. The error/symptom on Subscriber is different because Subscriber uses its own A Cisco DB process which runs fine. However when you try to update the configuration, Subscriber contacts A Cisco DB on Publisher which does not work and causes an error on Subscriber as well.
Also, the inability to access the CUCM page of Publisher might be because of a database communication error where Informix does not accept any more connections.
The utils dbreplication runtimestate command does not work:
admin:utils dbreplication runtimestate
File "/usr/local/cm/bin/DbReplRTstate.py", line 578, in ?
fin = open(tfile, 'r')
IOError: [Errno 2] No such file or directory:
'/var/log/active/cm/trace/dbl/sdi/getNodes'
This issue is also documented by Cisco bug ID CSCtl74037. The workaround for this is to enter these commands from the CLI:
utils service stop A Cisco DB
utils service start A Cisco DB
and stop the Cisco Express Forwarding (CEF) service from the serviceability page.
Enter the utils service start A Cisco DB command in order to start the A Cisco DB service. If the service does not start, then call the Cisco Technical Assistance Center (TAC) in order to start the service from root. The TAC verifies the issue with root access. In few cases, if the DB is corrupted then a rebuild of CUCM is necessary.
Problem 2: Connection to the Server Cannot Be Established (Unable to Access the Remote Node)
You are unable to access the other CUCM nodes from the Serviceability page of the CUCM that you are currently logged in. Choose Cisco Unified Serviceability > Tools > Control Center Feature/Network Services > Select Server > Go.
The error message displayed is ‘Connection to the Server cannot be established (Unable to access remote node)’.
Workaround
Log in to each CUCM node separately in order to access Serviceability and Activate/Deactivate services.
Solution
- Check whether the Tomcat certificate is expired. (Choose Cisco OS Administration > Security > Certificate Management > tomcat.pem). If expired, regenerate the Tomcat certificate and restart the Tomcat service.
- If you use a Certificate Authority (CA) signed certificate, get the Tomcat Certificate Signing Request (CSR) re-signed by the CA, re-upload it back, and restart the Cisco Tomcat service with the utils service restart Cisco Tomcat command.
- If you use a self-signed certificate on the affected server, regenerate the Tomcat certificate with the set cert regen tomcat command from the CLI or from OS Admin and then restart the Cisco Tomcat service with the utils service restart Cisco Tomcat command.
This known defect is documented in Cisco bug ID CSCth44399.
- Confirm the validity of Tomcat certificates. Check whether the Tomcat trust certificate of the problematic node is on the other node. If it is not on the node, download the Tomcat trust certificate of the problematic node and upload it to the other node as Tomcat trust. Then, regenerate the Tomcat certificate on the problematic node and restart the Tomcat service on both nodes.
Problem 3: Connection to the Server Cannot Be Established (Unknown Error)
You are unable to access the other CUCM nodes from the Serviceability page of the CUCM that you are currently logged in. Choose Cisco Unified Serviceability > Tools > Service Activation/Control Center Feature/Network Services > Select Server > Go.
The error message displayed is ‘Connection to the Server cannot be established (Unknown Error)’.
Workaround
Log in to each CUCM node separately in order to access Serviceability and Activate/Deactivate services.
Solution
- Enter the utils dbreplication runtimestate command in order to check for any dbreplication issues in the CUCM cluster.
- Restart the Tomcat Service with the utils service restart Cisco Tomcat command.
- Check for any Tomcat certificate (tomcat-trust) serial number mismatches on the nodes.
- Choose Cisco OS Administration > Security > Certificate Management > tomcat.pem and check whether the Tomcat certificate is expired. If expired, regenerate the Tomcat certificate and restart the Tomcat service.
- If you use a CA signed certificate, get the Tomcat CSR re-signed by the CA, re-upload it back, and restart the Cisco Tomcat service with the utils service restart Cisco Tomcat command.
- If you use a self-signed certificate on the affected server, regenerate the Tomcat certificate with the set cert regen tomcat command from the CLI or from OS Admin and then restart the Cisco Tomcat service with the utils service restart Cisco Tomcat command.
These known defects are documented in Cisco bug IDs CSCui29232 and CSCud67438.
Problem 4: Connection to the Server Cannot Be Established (Certificate Exception)
You are unable to access the other CUCM nodes from the Serviceability page of the CUCM that you are currently logged in. Choose Cisco Unified Serviceability > Tools > Service Activation/Control Center Feature/Network Services > Select Server > Go.
The error message displayed is ‘Connection to the Server cannot be established (Certificate Exception)’.
Workaround
Log in to each CUCM node separately in order to access Serviceability and Activate/Deactivate services.
Solution
- Enter the utils dbreplication runtimestate command in order to check for any dbreplication issues in the CUCM cluster.
- Restart the Tomcat Service with the utils service restart Cisco Tomcat command.
- Check for any Tomcat certificate (tomcat-trust) serial number mismatches on the nodes.
- Choose Cisco OS Administration > Security > Certificate Management > tomcat.pem and check whether the Tomcat certificate is expired. If expired, regenerate the Tomcat certificate and restart the Tomcat service.
- If you use a CA signed certificate, get the Tomcat CSR re-signed by the CA, re-upload it back, and restart the Cisco Tomcat service with the utils service restart Cisco Tomcat command.
- If you use a self-signed certificate on the affected server, regenerate the Tomcat certificate with the set cert regen tomcat command from the CLI or from OS Admin and then restart Cisco the Tomcat service with the utils service restart Cisco Tomcat command.
This known defect is documented in Cisco bug ID CSCup10995.
Problem 5: GUI Access Very Slow
CUCM Web/GUI access on Publisher and Subscriber is very slow.
Solution
- Note that CUCM Admin always queries the database of the publisher when available. See the diagram in the Flow Diagram section.
- Check for any network issues/network delays. This might happen if the clustering is done over a Wide Area Network (WAN).
- Restart the Cisco Tomcat Service from the CLI/Secure Shell (SSH) with the utils service restart Cisco Tomcat command.
- Schedule a maintenance window and reboot the CUCM nodes.
- If the problem occurs again, contact the TAC with these logs:
- Call Manager (Detailed) Traces
- Tomcat Logs (logs from output of the file get activelog tomcat/logs/* command from the CLI)
- Event Viewer Application Log
- Event Viewer System Logs
- Cisco Real-Time Information Server (RIS) DataCollector Perfmon Logs
- Service Manager Logs
- Output of these commands from the CLI of CUCM:
utils diagnose test
utils ntp status
show process load cpu
show process load memory
show process using-most cpu
show process using-most memory
utils core active list
- Cisco Integrated Management Controller (CIMC) Logs (From VM — Visual Guide to collect Tech Support files (B and C series))
These known defects are documented in Cisco bug IDs CSCub02337 and CSCui86571.
Problem 6: Unable to Copy/Paste the Password in the End User Login Page
Copy/paste to the Password field in the CUCM End user login page does not work. The paste operation of the password into the Password field in CUCM End user login page is not supported. This will not work with Internet Explorer (IE), Firefox, or Chrome.
Copy/paste of the password is not allowed on end user pages because of the security risk. This is added as part of CUCM Version 9.1.2 and later. However, it has been noticed that the copy/paste function still works with a few versions of CUCM 10.x, which is documented in Cisco bug IDs CSCus84153 and CSCus84152.
Problem 7: Unable to Access ELM with Firefox and Chrome
You are unable to access Enterprise License Manager (ELM) with Firefox and Chrome, but this works fine with IE. When you log in to ELM with Firefox or Chrome, none of the options are available.
This known defect is documented in Cisco bug ID CSCul30396.
This issue has been fixed in versions of CUCM 9.1.2.11900-10 and later. ELM can be accessed with Firefox, IE, and Chrome.
Problem 8: Web Page Logs Out Automatically
The CUCM web page logs out automatically after its idle timeout expires.
You can set the web page timeout with these commands from the CLI of CUCM.
show webapp session timeout
set webapp session timeout
admin:set webapp session timeout ?
Syntax
set webapp session timeout minutes
Minutes is mandatory and is the number of minutes after which sessions are declared to be invalid. The range is 5 to 99999.
admin:set webapp session timeout 5
If you continue with this operation, it sets the session-timeout for web sessions to 5 minutes after the Cisco Tomcat service has been restarted or after the server has been rebooted.
Continue (y/n)?y
Tomcat session-timeout updated to 5 minutes.
The Cisco Tomcat service needs to be restarted for the changes to take effect immediately. This disconnects active web sessions.
Continue (y/n)?y
Do not press Ctrl-C while the service RESTARTS. If the service has not restarted properly, enter the same command again.
Service Manager is runningCisco Tomcat[STOPPING]
Cisco Tomcat[STOPPING]
Cisco Tomcat[STOPPING]
Cisco Tomcat[STOPPING]
Commanded Out of Service
Cisco Tomcat[NOTRUNNING]
Service Manager is running
Cisco Tomcat[STARTING]
Cisco Tomcat[STARTING]
Cisco Tomcat[STARTED]
The Cisco Tomcat service restarted successfully. New web sessions time out after 5 minutes. The current session-timeout used for web sessions and applications is 5 minutes.
Problem 9: Unable to Access the Admin/User Web Page of CUCM
You are unable to access the Admin/User web page of CUCM.
- Verify whether the user credentials are correct. If you have entered the wrong credentials, you receive this error.
- Verify whether the User has correct permissions (Roles and User Groups) configured. If they are not correctly configured, the web page prompts the login page again without any error messages.
See the Cisco Unified Communications Manager System Guide for details in regards to Roles and User Groups.
Problem 10: Local Agent Does Not Respond, the Master or Local Agent Might Be Down
You are unable to access any options from the Disaster Recovery System (DRF) page of CUCM after you log in. You might get this message:
‘Local Agent is not responding. This may be due to Master or Local Agent being down’
- Check the IPsec certificate and confirm the validity. If it is expired, regenerate the IPsec certificate. See CallManager Certificate Expiration and Deletion for information on how to regenerate the certificate.
- Restart the Cisco DRF Master and DRF Local service.
Related Information
- Cisco CallManager Administration Web Page Can’t Be Displayed
- Cisco Unified Communications Manager 5.x/6.x/7.x/8.x: Unable to Login to the Administration Page or User Page
- Technical Support & Documentation — Cisco Systems
В большинстве инсталляций CUCM ставится в виде кластера. Кластер — это набор совместно функционирующих сетевых сервисов. Кластер CUCM состоит из одного Publisher и одного или более Subscriber.
Кластер дает несколько преимуществ, главные из которых:
- Распределение нагрузки между нодами кластера
- Обеспечивает Redundancy в случае сбоя сети или какого либо из нодов
Для нормальной работы кластера чрезвычайно важны вопросы успешной репликации.
Все настройки CUCM, необходимые для нормальной обработки звонков, хранятся в Базе Данных IBM Informix Dynamic Server.
Репликация БД между нодами является ключевой функцией внутри кластера CUCM, при этом у нодом могут быть следующие роли:
- Publisher — Это сервер обладающий master copy of the database. Этот сервер в единственном числе.
- Subscriber — Это сервер обладающий копией (репликой) БД от Publisher. Таких серверов может быть несколько
Почти вся информация в БД в кластере CUCM реплицируется по топологии star topology (один Publisher и несколько Subscriber).
Но для данных типа Dynamic Information используется репликация с топологией mesh topology (каждый с каждым).
Dynamic Information это данные такие как: regustered phones, gateway, ресурсы DSP, — т.е. та информация которая изменяется гораздо чаще и требует немедленной репликации между нодами.
Сама по себе IBM IDS достаточно надёжна, но проблемы с синхронизацией всё же могут возникнуть по следующим причинам:
- Сбой в сетевом подключении между нодами
- Репликация требует достаточной bandwidth
- Проблемы с DNS
- Недостаточное количество ресурсов CPU и Memory
Типичные проблемы с репликацией
Администратор меняет настройки телефона, далее после перезагрузки телефона, IP phone подключается к primary subscriber. Но после перезагрузки никаких изменений на телефоне не происходит.
Другой причиной проблем с репликацией может быть несоответствие конфигураций между Publisher и Subscriber, — при этом в CUCM logs мы будем видеть ошибку: Database Communication Error.
Возможные причины:
— Сеть. Проверьте пинг между серверами.
— Name resolution
— Недостаточно сетевых ресурсов. Как минимум Round-trip delay between two replication peer servers должен быть минимум 80ms
Также, с ошибкой в Database Replication можно попробовать побороться через Recreate Databes Relationship между Publisher и Subscriber.
Диагностика проблем с репликацией
Проверить репликацию мы можем через использование CLI, Cisco Unified Reporting или Cisco Unified Real-Time Monitoring Tool (RTMT).
Все эти инструменты отображают главный показатель: Replicate_State, который может иметь следующие значения:
- 0 — Репликация не запущена. Либо нет ни одного Subscriber, либо остановлен сервис Cisco Databes Layer Monitor
- 1 — replicates have been created, but their count isincorrect.
- 2 — replication is good.
- 3 — replication is bad in the cluster.
- 4 — replication setup did not succeed.
CUCM Unified Reporting
Unified Reporting > System Reports > Unified CM Database Status > Generate new Report
Если все нормально мы должны там:
— Найти фразу All servers have a good replication status
— Значение Replicate_State = 2
— У всех нодов значения Number of Replicates Created должны быть одинаковыми.
RTMT
RTMT (Real Time Monitoring Tool) — очень полезный инструмент не только для проверки репликации но и многих других задач.
На левой панели выбираем Call Manager, затем Database summary.
— Значение Replicate_State = 2 должно быть для всех нодов.
— Значение Replicates Created должно быть одинаковым для всех нодов.
Также эти значения получить и в виде графика:
System > Perfomance > Open Perfomance Monitoring > First Node > Number of Replicates Created and State of Replication
CUCM OS Admin CLI
Подробнее по CLI см. CUCM CLI
Здесь для проверки мы можем использовать команды из консоли Publisher:
utils dbreplication status
utils dbreplication runtimestate
Главная команда utils dbreplication status не может быть выполнена мгновенно. Через некоторое время следует выполнить
utils dbreplication runtimestate
Replication status command COMPLETED — типа проверка завершена
Нас интересуют значения в столбце REPLICATION SETUP (RTMT) & details, если видим значение (2) значит всё нормально.
Более подробные детали по БД можно посмотреть командой:
file view activelog cm/trace/dbl/sdi/ReplicationStatus.2014_01_24_04_42_57.out
Методы решения проблем с Database Replication
- Repair Databases Replication — можно производить со стороны Publisher:
utils dbreplication repair all
Процесс восстановления запустится в background, его прогресс можно посмотреть командой:
utils dbreplication runtimestate
После окончания проверьте статус репликации еще раз. Если не помогло, переходим к следующему пункту.
- Resetting Database Replication — Перед началом проверим общее состояние системы:
Cisco Unified Reporting > Unified CM Cluster Overview
Удостоверьтесь что у нодов:
— одинаковы Unified CM Version
— проверьте CM Server Connectivity
— проверьте Unified CM Time and Delay- Для всех Subscriber выполняем команду:
utils dbreplication stop
- На Publisher выполняем:
utils dbreplication stop
Выполнение команды может занять время: дождаться окончания выполнения.
- На Publisher выполняем для всех subscriber:
utils dbreplication reset all
- Проверяем статус командой:
utils dbreplication runtimestate
Дожидаемся пока статус не будет SYNC COMPLETED
- Проверяем статус репликации:
utils dbreplication status
- Для всех Subscriber выполняем команду:
- Resetting the cluster — данную процедуру следует проводить только если не помогло reset replication.
- Для всех Subscriber выполняем команду:
utils dbreplication stop
- На Publisher выполняем:
utils dbreplication stop
Выполнение команды может занять время: дождаться окончания выполнения.
- На Publisher выполняем:
utils dbreplication clusterreset - На Publisher выполняем для всех subscriber:
utils dbreplication reset all
- Проверяем статус репликации командой:
utils dbreplication status
Если статус =2 ребутаем все Subsribers
- Для всех Subscriber выполняем команду:
Если команда utils dbreplication reset all не проканала, попробовать utils dbreplication clusterreset
Также см.
https://community.cisco.com/t5/collaboration-voice-and-video/troubleshoo…
Troubleshooting Database Replication
В большинстве инсталляций CUCM ставится в виде кластера. Кластер — это набор совместно функционирующих сетевых сервисов. Кластер CUCM состоит из одного Publisher и одного или более Subscriber.
Кластер дает несколько преимуществ, главные из которых:
- Распределение нагрузки между нодами кластера
- Обеспечивает Redundancy в случае сбоя сети или какого либо из нодов
Для нормальной работы кластера чрезвычайно важны вопросы успешной репликации.
Все настройки CUCM, необходимые для нормальной обработки звонков, хранятся в Базе Данных IBM Informix Dynamic Server.
Репликация БД между нодами является ключевой функцией внутри кластера CUCM, при этом у нодом могут быть следующие роли:
- Publisher — Это сервер обладающий master copy of the database. Этот сервер в единственном числе.
- Subscriber — Это сервер обладающий копией (репликой) БД от Publisher. Таких серверов может быть несколько
Почти вся информация в БД в кластере CUCM реплицируется по топологии star topology (один Publisher и несколько Subscriber).
Но для данных типа Dynamic Information используется репликация с топологией mesh topology (каждый с каждым).
Dynamic Information это данные такие как: regustered phones, gateway, ресурсы DSP, — т.е. та информация которая изменяется гораздо чаще и требует немедленной репликации между нодами.
Сама по себе IBM IDS достаточно надёжна, но проблемы с синхронизацией всё же могут возникнуть по следующим причинам:
- Сбой в сетевом подключении между нодами
- Репликация требует достаточной bandwidth
- Проблемы с DNS
- Недостаточное количество ресурсов CPU и Memory
Типичные проблемы с репликацией
Администратор меняет настройки телефона, далее после перезагрузки телефона, IP phone подключается к primary subscriber. Но после перезагрузки никаких изменений на телефоне не происходит.
Другой причиной проблем с репликацией может быть несоответствие конфигураций между Publisher и Subscriber, — при этом в CUCM logs мы будем видеть ошибку: Database Communication Error.
Возможные причины:
— Сеть. Проверьте пинг между серверами.
— Name resolution
— Недостаточно сетевых ресурсов. Как минимум Round-trip delay between two replication peer servers должен быть минимум 80ms
Также, с ошибкой в Database Replication можно попробовать побороться через Recreate Databes Relationship между Publisher и Subscriber.
Диагностика проблем с репликацией
Проверить репликацию мы можем через использование CLI, Cisco Unified Reporting или Cisco Unified Real-Time Monitoring Tool (RTMT).
Все эти инструменты отображают главный показатель: Replicate_State, который может иметь следующие значения:
- — Репликация не запущена. Либо нет ни одного Subscriber, либо остановлен сервис Cisco Databes Layer Monitor
- 1 — replicates have been created, but their count isincorrect.
- 2 — replication is good.
- 3 — replication is bad in the cluster.
- 4 — replication setup did not succeed.
CUCM Unified Reporting
Unified Reporting > System Reports > Unified CM Database Status > Generate new Report
Если все нормально мы должны там:
— Найти фразу All servers have a good replication status
— Значение Replicate_State = 2
— У всех нодов значения Number of Replicates Created должны быть одинаковыми.
RTMT
RTMT (Real Time Monitoring Tool) — очень полезный инструмент не только для проверки репликации но и многих других задач.
На левой панели выбираем Call Manager, затем Database summary.
— Значение Replicate_State = 2 должно быть для всех нодов.
— Значение Replicates Created должно быть одинаковым для всех нодов.
Также эти значения получить и в виде графика:
System > Perfomance > Open Perfomance Monitoring > First Node > Number of Replicates Created and State of Replication
CUCM OS Admin CLI
Подробнее по CLI см. CUCM CLI
Здесь для проверки мы можем использовать команды из консоли Publisher:
utils dbreplication status
utils dbreplication runtimestate
Главная команда utils dbreplication status не может быть выполнена мгновенно. Через некоторое время следует выполнить
utils dbreplication runtimestate
Replication status command COMPLETED — типа проверка завершена
Нас интересуют значения в столбце REPLICATION SETUP (RTMT) & details, если видим значение (2) значит всё нормально.
Более подробные детали по БД можно посмотреть командой:
file view activelog cm/trace/dbl/sdi/ReplicationStatus.2014_01_24_04_42_57.out
Методы решения проблем с Database Replication
- Repair Databases Replication — можно производить со стороны Publisher:
Процесс восстановления запустится в background, его прогресс можно посмотреть командой:
После окончания проверьте статус репликации еще раз. Если не помогло, переходим к следующему пункту.
Cisco Unified Reporting > Unified CM Cluster Overview
Удостоверьтесь что у нодов:
— одинаковы Unified CM Version
— проверьте CM Server Connectivity
— проверьте Unified CM Time and Delay
- Для всех Subscriber выполняем команду:
- На Publisher выполняем:
Выполнение команды может занять время: дождаться окончания выполнения.
Дожидаемся пока статус не будет SYNC COMPLETED
Если команда utils dbreplication reset all не проканала, попробовать utils dbreplication clusterreset
- Для всех Subscriber выполняем команду:
- На Publisher выполняем:
Выполнение команды может занять время: дождаться окончания выполнения.
utils dbreplication clusterreset
utils dbreplication status
Если статус =2 ребутаем все Subsribers
Источник
How to Perform a Health Check of CUCM Database Replication
Available Languages
Download Options
Bias-Free Language
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Contents
Introduction
This document describes the details in order to verify the current status of Cisco Unified Communications Manager (CUCM) database replication; and the expected outputs for each of the parameters.
Prerequisites
Requirements
Cisco recommends that you have knowledge of these topics:
- Cisco Unified Communications Manager
Components Used
The information in this document is based on these software versions:
- Cisco Unified Communications Manager version 10.5.2.15900-8
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.
Background Information
Database in CUCM is a fully meshed topology which means that publisher and each subscriber connect logically to every server in the cluster; and all of them have the ability to update the data between them.
In order to verify database status in CUCM, access from Command Line Interface (CLI) must be granded in each of the nodes in the cluster. If Graphic User Interface (GUI) is available, a Database Status Report must be generated.
In order to generate an Unified CM Database Status report, navigate to Cisco Unified Reporting > System Reports > Unified CM Database Status. Select Generate a new report.
Connectivity Verification
For database replication, connectivity between servers must be established properly in each of the nodes involved in the cluster. These commands allow you to know the status of each of them.
show network cluster
Use show network cluster command in order to confirm that nodes are authenticated between each other. The output from the publisher contains processnode table entries. However, all of the nodes must be authenticated (ensure that the security password is same on all of the nodes).
run sql select * from processnode
Processnode table must list all nodes in the cluster.
utils network connectivity
Publisher must be able to reach all subscribers and network connectivity result must be completed successfully.
Each subscriber must reach Publisher and other subscribers included in the cluster network connectivity result must be completed successfully.
From the Unified CM Database Status Report, Connectivity must be displayed as 1=Success to each node as shown in the image
utils diagnose test
It checks all the components and returns passed/failed value. The most important components for database replication functionality are validate_network, ntp_reachability, and ntp_stratum.
utils ntp status
Cisco highly recommends to configure a Network Time Protocol (NTP) server with Stratum-1, Stratum-2, or Stratum-3 in CUCM publisher, in order to ensure that the cluster time is synchronized with an external time source.
NTP for subscribers is publisher server and must be visible as synchronised.
Services Verification
CUCM services involved for database replication are Cluster Manager, A Cisco DB and Cisco Database Layer Monitor.
utils service list
Command utils service list displays the services and its status in CUCM node. These services must be displayed as STARTED.
- Cluster Manager [STARTED]
- A Cisco DB [STARTED]
- A Cisco DB Replicator [STARTED]
- Cisco Database Layer Monitor [STARTED]
Database Commands
Database replication commands must be run from the publisher.
utils dbreplication status
This command only triggers the check of the dabatase status. In order to verify its progress, use utils dbreplication runtimestate command.
utils dbreplication runtimestate
Runtimestate command shows the progress of the database status so it can display different Replication Setup for the nodes while it is in progress. Once that command is COMPLETED, outputs can be verified and it shows the current database status.
Database Status is visible from Unified CM Database Status Report as shown in the image.
Hosts/Rhosts/Sqlhosts Files
There are three important files associated to the database and they must be the same in each of the nodes involved. In order to verify them from CLI, root access is required. However, Unified CM Database Status Report also displays this information as shown in the image.
System History Log File
Database replication can be damaged due to ungraceful shutdowns and they are visible in System-history log.
Ungraceful shutdown example:
Graceful shutdown example:
Rebuild of the server is suggested when system suffered an ungraceful shutdown and it is documented in defect CSCth53322
.
Verify
In case errors are visible when these parameters are validated, it is suggested to contact Cisco Technical Assistance Center (TAC) and provide the collected information from each node in the cluster for further assistance.
Источник
Troubleshoot CUCM Web (GUI) Issues
Available Languages
Download Options
Bias-Free Language
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Contents
Introduction
This document describes most of the reasons that the Cisco Unified Communications Manager (CUCM) web pages or CUCM User page is not displayed or gives an error.
Prerequisites
Requirements
Cisco recommends that you have knowledge of CUCM.
Components Used
The information in this document is based on CUCM versions 7.x/8.x/9.x/10.x.
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.
Flow Diagram
The flow diagram for web access on CUCM is shown here:
Problem 1: Database Communication Error
When you try to log in to the CUCM Admin web page from Publisher, the ‘Database communication error’ error is received.
You are able to log in to the CUCM Admin web page from Subscriber, but any changes on CUCM cause one of these errors: ‘Error occurred while retrieving information from database. java.sql.SQLException: No DELETE permission.’ or ‘Add failed. The Insert privilege is required for this operation.’.
This issue can occur when you try to log in to the server after changes are made in the Publisher server, such as when the hostname or IP address is changed either through the CLI or the Operating System (OS) Admin page. In this case, revert the changes made back to the old configuration in order to let you log in.
If no changes were made to CUCM Publisher and you still receive the Database Communications Error message, then check these items:
- Enter the utils dbreplication runtimestate command in order to check the DBreplication Status. Confirm that the status of replication is 2 on all nodes without any errors or mismatches.
- Determine whether a Cisco database (DB) service currently runs. A Cisco DB not started on Publisher could also cause this issue. The error/symptom on Subscriber is different because Subscriber uses its own A Cisco DB process which runs fine. However when you try to update the configuration, Subscriber contacts A Cisco DB on Publisher which does not work and causes an error on Subscriber as well.
Also, the inability to access the CUCM page of Publisher might be because of a database communication error where Informix does not accept any more connections.
The utils dbreplication runtimestate command does not work:
This issue is also documented by Cisco bug ID CSCtl74037. The workaround for this is to enter these commands from the CLI:
and stop the Cisco Express Forwarding (CEF) service from the serviceability page.
Enter the utils service start A Cisco DB command in order to start the A Cisco DB service. If the service does not start, then call the Cisco Technical Assistance Center (TAC) in order to start the service from root. The TAC verifies the issue with root access. In few cases, if the DB is corrupted then a rebuild of CUCM is necessary.
Problem 2: Connection to the Server Cannot Be Established (Unable to Access the Remote Node)
You are unable to access the other CUCM nodes from the Serviceability page of the CUCM that you are currently logged in. Choose Cisco Unified Serviceability > Tools > Control Center Feature/Network Services > Select Server > Go.
The error message displayed is ‘Connection to the Server cannot be established (Unable to access remote node)’.
Workaround
Log in to each CUCM node separately in order to access Serviceability and Activate/Deactivate services.
Solution
- Check whether the Tomcat certificate is expired. (Choose Cisco OS Administration > Security > Certificate Management > tomcat.pem). If expired, regenerate the Tomcat certificate and restart the Tomcat service.
- If you use a Certificate Authority (CA) signed certificate, get the Tomcat Certificate Signing Request (CSR) re-signed by the CA, re-upload it back, and restart the Cisco Tomcat service with the utils service restart Cisco Tomcat command.
- If you use a self-signed certificate on the affected server, regenerate the Tomcat certificate with the set cert regen tomcat command from the CLI or from OS Admin and then restart the Cisco Tomcat service with the utils service restart Cisco Tomcat command.
This known defect is documented in Cisco bug ID CSCth44399.
Problem 3: Connection to the Server Cannot Be Established (Unknown Error)
You are unable to access the other CUCM nodes from the Serviceability page of the CUCM that you are currently logged in. Choose Cisco Unified Serviceability > Tools > Service Activation/Control Center Feature/Network Services > Select Server > Go.
The error message displayed is ‘Connection to the Server cannot be established (Unknown Error)’.
Workaround
Log in to each CUCM node separately in order to access Serviceability and Activate/Deactivate services.
Solution
- Enter the utils dbreplication runtimestate command in order to check for any dbreplication issues in the CUCM cluster.
- Restart the Tomcat Service with the utils service restart Cisco Tomcat command.
- Check for any Tomcat certificate (tomcat-trust) serial number mismatches on the nodes.
- Choose Cisco OS Administration > Security > Certificate Management > tomcat.pem and check whether the Tomcat certificate is expired. If expired, regenerate the Tomcat certificate and restart the Tomcat service.
- If you use a CA signed certificate, get the Tomcat CSR re-signed by the CA, re-upload it back, and restart the Cisco Tomcat service with the utils service restart Cisco Tomcat command.
- If you use a self-signed certificate on the affected server, regenerate the Tomcat certificate with the set cert regen tomcat command from the CLI or from OS Admin and then restart the Cisco Tomcat service with the utils service restart Cisco Tomcat command.
These known defects are documented in Cisco bug IDs CSCui29232 and CSCud67438.
Problem 4: Connection to the Server Cannot Be Established (Certificate Exception)
You are unable to access the other CUCM nodes from the Serviceability page of the CUCM that you are currently logged in. Choose Cisco Unified Serviceability > Tools > Service Activation/Control Center Feature/Network Services > Select Server > Go.
The error message displayed is ‘Connection to the Server cannot be established (Certificate Exception)’.
Workaround
Log in to each CUCM node separately in order to access Serviceability and Activate/Deactivate services.
Solution
- Enter the utils dbreplication runtimestate command in order to check for any dbreplication issues in the CUCM cluster.
- Restart the Tomcat Service with the utils service restart Cisco Tomcat command.
- Check for any Tomcat certificate (tomcat-trust) serial number mismatches on the nodes.
- Choose Cisco OS Administration > Security > Certificate Management > tomcat.pem and check whether the Tomcat certificate is expired. If expired, regenerate the Tomcat certificate and restart the Tomcat service.
- If you use a CA signed certificate, get the Tomcat CSR re-signed by the CA, re-upload it back, and restart the Cisco Tomcat service with the utils service restart Cisco Tomcat command.
- If you use a self-signed certificate on the affected server, regenerate the Tomcat certificate with the set cert regen tomcat command from the CLI or from OS Admin and then restart Cisco the Tomcat service with the utils service restart Cisco Tomcat command.
This known defect is documented in Cisco bug ID CSCup10995.
Problem 5: GUI Access Very Slow
CUCM Web/GUI access on Publisher and Subscriber is very slow.
Solution
- Note that CUCM Admin always queries the database of the publisher when available. See the diagram in the Flow Diagram section.
- Check for any network issues/network delays. This might happen if the clustering is done over a Wide Area Network (WAN).
- Restart the Cisco Tomcat Service from the CLI/Secure Shell (SSH) with the utils service restart Cisco Tomcat command.
- Schedule a maintenance window and reboot the CUCM nodes.
- If the problem occurs again, contact the TAC with these logs:
- Call Manager (Detailed) Traces
- Tomcat Logs (logs from output of the file get activelog tomcat/logs/* command from the CLI)
- Event Viewer Application Log
- Event Viewer System Logs
- Cisco Real-Time Information Server (RIS) DataCollector Perfmon Logs
- Service Manager Logs
- Output of these commands from the CLI of CUCM:
- Cisco Integrated Management Controller (CIMC) Logs (From VM — Visual Guide to collect Tech Support files (B and C series))
These known defects are documented in Cisco bug IDs CSCub02337 and CSCui86571.
Problem 6: Unable to Copy/Paste the Password in the End User Login Page
Copy/paste to the Password field in the CUCM End user login page does not work. The paste operation of the password into the Password field in CUCM End user login page is not supported. This will not work with Internet Explorer (IE), Firefox, or Chrome.
Copy/paste of the password is not allowed on end user pages because of the security risk. This is added as part of CUCM Version 9.1.2 and later. However, it has been noticed that the copy/paste function still works with a few versions of CUCM 10.x, which is documented in Cisco bug IDs CSCus84153 and CSCus84152.
Problem 7: Unable to Access ELM with Firefox and Chrome
You are unable to access Enterprise License Manager (ELM) with Firefox and Chrome, but this works fine with IE. When you log in to ELM with Firefox or Chrome, none of the options are available.
This known defect is documented in Cisco bug ID CSCul30396.
This issue has been fixed in versions of CUCM 9.1.2.11900-10 and later. ELM can be accessed with Firefox, IE, and Chrome.
Problem 8: Web Page Logs Out Automatically
The CUCM web page logs out automatically after its idle timeout expires.
You can set the web page timeout with these commands from the CLI of CUCM.
Syntax
Minutes is mandatory and is the number of minutes after which sessions are declared to be invalid. The range is 5 to 99999.
If you continue with this operation, it sets the session-timeout for web sessions to 5 minutes after the Cisco Tomcat service has been restarted or after the server has been rebooted.
The Cisco Tomcat service needs to be restarted for the changes to take effect immediately. This disconnects active web sessions.
Do not press Ctrl-C while the service RESTARTS. If the service has not restarted properly, enter the same command again.
The Cisco Tomcat service restarted successfully. New web sessions time out after 5 minutes. The current session-timeout used for web sessions and applications is 5 minutes.
Problem 9: Unable to Access the Admin/User Web Page of CUCM
You are unable to access the Admin/User web page of CUCM.
- Verify whether the user credentials are correct. If you have entered the wrong credentials, you receive this error.
See the Cisco Unified Communications Manager System Guide for details in regards to Roles and User Groups.
Problem 10: Local Agent Does Not Respond, the Master or Local Agent Might Be Down
You are unable to access any options from the Disaster Recovery System (DRF) page of CUCM after you log in. You might get this message:
‘Local Agent is not responding. This may be due to Master or Local Agent being down’
- Check the IPsec certificate and confirm the validity. If it is expired, regenerate the IPsec certificate. See CallManager Certificate Expiration and Deletion for information on how to regenerate the certificate.
- Restart the Cisco DRF Master and DRF Local service.
Источник
In a couple months ago I was asked to bring VOIP topic to the Locked Shields 2014. It was a great challenge for me as July 2011 was the last month I touched Cisco VOIP configuration. Nevertheless I decided to accept this offer and brush up my VOIP knowledges.
Previously known as the Cisco Unified Communications Manager administrator it seemed more than logical that I chose Cisco VOIP solution to support this job. Luckily, Cisco Unified Communications Manager 8.5.1 proved itself to be a good choice except those 3 dark days of my life that I spent troubleshooting «Database Communication Error» message. The message appeared as soon as CUCM booted up with changed IPv4 address. Seems that it wasn’t only me who noticed this issue.
https://tools.cisco.com/bugsearch/bug/CSCtn29923
Finally, I was able to find a workaround once I realized that CUCM 8.5.1Su2 was affected by the bug only when we changed IPv4 address for CUCM that had configured IPv6 address. Vrrrr.
Workaround consists from changing the IPv4 address first and afterwards change IPv6 address could be done without doing any harm to CUCM database.
So how VOIP infrastructure looked like and how we deployed CUCMs to support the game?
One central CUCM was installed on WMvare ESXi virtual machine and represented Central Office. It was entirely under Green team administration with no access given to Blue teams. That’s why it was called Green CUCM. We installed twelve CUCMs that represented PBXs. The Blue were responsible for these CUCMs and their task was to defend them against Red team attacks.
Each Blue CUCM was connected to the Green team via SIP trunk. Routing plan installed on Green and Blue CUCMs allowed to make phone calls between Blue and Green extensions. However they were no route patterns configured on Blue CUCMs that routed calls between different Blue teams directly or using Green CUCM as a next-hop.
1. Green VOIP Systems
The Green CUCM database contained only one hardware Cisco IP phone 7962G with the following extension numbers configured on phone lines.
- 8[0-4]xx — Green Team Internal Range
- 06xxxxxx — Land Lines
- 0112 — Emergency Number
- 0999 — Paid service Number
Note: Character x represents any digit.
Blue team task was to ensure that the calls to GT internal range, Land Lines and Emergency number could be made from Blue team extensions. White team members made regular availability check by dialing the numbers from one of Blue extensions. They visually checked statistic such as Rx, Tx packets and negotiated codecs on telephone screen during the phone call.
2. Blue VOIP Systems
They were twelve Blue teams together. Each Blue team was responsible for their VOIP systems that consists of one CUCM and three software phones registered as SIP endpoints. The extension numbers were the first three numbers assigned from following Blue team ranges:
Blue1: 1[0-4]xx
Blue2: 1[5-9]xx
Blue3: 2[0-4]xx
Blue4: 2[5-9]xx
Blue5: 3[0-4]xx
Blue6: 3[5-9]xx
Blue7: 4[0-4]xx
Blue8: 4[5-9]xx
Blue9: 5[0-4]xx
Blue10: 5[5-9]xx
Blue11: 6[0-4]xx
Blue12: 6[5-9]xx
The ranges were created as Route patterns on Green CUCM and pointed to particular Blue SIP trunks.
3. Blue SIP Endpoints
SIP endpoints were represented by Cisco IP Communicators (CIPCs) 8.6.2 installed on VMware ESXi virtual machine with 32 bit OS Windows 7. Auto-registration option was enabled in CUCM configuration to avoid manual soft phones registration. We noticed the following issues and challenges connected with using CIPCs in the game.
a) Auto-registration of SIP endpoints
To allow CIPC auto-register on CUCM as SIP endpoint, CIPC had to be installed using the msiexec command with SIP option enabled:
msiexec /i CISCOIPC.MSI /qb SIP=1
Note: If CIPC was installed without SIP option enabled, CIPC remained registered as a SCCP endpoint even SIP protocol was selected as Auto Registration Phone Protocol in Enterprise parameters.
The Cisco IP Communicator deployment and updates guide is available for downloaded here.
We also created CICP communicator9.exe shortcut and added it to Startup directory to allow CIPC to start automatically after login.
b) CIPC compatibility mode
In order to get rid off the message «There are no compatible sound devices installed on this computer» we had to run CIPC in compatibility mode with Windows XP. We applied changes to applications «Cisco IP Communicator» and «Audio Tuning Wizard» by right clicking on the icon -> Properties -> Compatibility tab -> Change settings for all users -> «Run this program in compatibility mode» and selected «Windows XP (Service Pack 3)«.
c) Missing audio device
VMware vCenter client doesn’t support adding a sound card to the virtual machine configuration. For this reason we had to install Virtual Audio Cable 4.0.9 to create a virtual sound card. If VAC wasn’t installed, CIPC was complaining about missing audio device. Virtual Audio Cable application made a good job with emulation of sound card and I recommend to install when no sound card is presented in guest OS.
d) Audio tunning wizard
Although setting audio parameters for a sound card, microphone and speakerphone is not a real issue as it is required by CIPC during its first time start, this extra step confused some Blue teams.
e) Virtual sound card is not detected when RDP client is used to connect to VM
A virtual sound card wasn’t detected when BT connected to Windows using RDP client that was not configured to play Audio on a remote computer. For the this reason we provided a guide that explains all the finesses behind RDP connection to remote workstations with installed CIPC.
4. Blue CUCMs Deployment
Below are the steps we created to deploy 12 Blue CUCM.
a) Blue79 CUCM installation on virtual machine and configuration
We installed CUCM on a virtual machine for non-existing Blue team 79. In general, Blue79 systems were developed for configuration testing thus not used during the game execution. Blue79 CUCM contained configuration such as IPv4, SNMP trap destination, DNS, NTP, hostname and IPv6 that differed among Blue CUCMs. Later we run a customization script that changed configuration based on the selected team number.
Some Blue79 CUCM parameters were common for all Blue CUCMs and we didn’t have changed. These are them:
a) Unified CM
b) Region
c) Location
d) Media resources — Annunciator, Conference Bridge, MTP, MoH server, MRGP, MRGL
e) Device Pool,
f) SIP trunk
e) Route Group, Route List and Route pattern
f) Application and End-users Accounts
g) Enable Services — CUCM, TFTP, IP Media Streaming App
h) Setting root password
b) Cloning Blue CUCM from Blue79 Template
Once we finished configuration of Blue79 CUCM we cloned it to Blue79 template. Then we cloned a particular Blue CUCM virtual machine from this template. The customization script was run on the CUCM in order to change parameters that were specific for each Blue CUCM. Mostly, these were the parameters connected with underlying RedHat 4 Linux systems such as IPv4, SNMP trap destination, DNS, NTP, hostname and IPv6 configuration. In order to run the script, we had to gain root access for CUCM. The steps are described here.
The script is available for download here. Login to CUCM CLI as root user and copy the script to /root/ directory. When you start the script it asks you to choose the team number. Then it checks IPv4 configuration. If it is related to Blue79 it will change it based on the team number you entered. But first it instructs you to change IPv4 address in CUCM database. It also adds the hash to /etc/ directory needed for capture the flag challenge. The script also suggests you to change SNMP trap destination in CUCM database.
Once you confirm that you finished IPv4 configuration, the script displays the name of NIC that you have to change under virtual machine configuration. Then it shutdown the VM as the CUCM requires reboot after each change of IPv4 address.
After reboot you have to run the script again and select the team number. CUCM IPv4 address should be different now so the script skips IPv4 configuration and continues with changing DNS and NTP settings. After that it displays particular Blue CUCM hostname based on team number and suggest you to change it in CUCM CLI configuration. You must log of and log to CLI with CUCM administrator account you had created during the Blue79 CUCM installation. Then change the hostname manually, entering the CUCM CLI command «system hostname«. Again, CUCM asks for reboot.
When CUCM boots up, start the script once more for IPv6 address change. Enter the team number and CUCM changes IPv6 address for you. Then it suggest you to change IPv6 address in CUCM database. Once you’re done, it deletes all logs and reboots. Customization is finished at this point and no other action is required.
Note: The script must be started 3 in all and three CUCM reboots are required. We tried to minimize the number of reboots connecting configuration the steps together but CUCM didn’t survive the changes. In this case, it displayed the error message «Database Communication Error«.
c) Creating template from particular Blue CUCM virtual machine
This was the final step in CUCM deployment. After we have customized CUCM, we cloned it to template.
End.