Хочу поделиться опытом переезда CUCM с Unrestricted версии на Restricted. Мотивами переезда были прежде всего возможность передачи файлов с помощью Cisco Jabber через MRA (Mobile and Remote Access), возможность использовать функционал шифрования и прочей безопасности, а также решение проблемы двойного КПВ (контроля посылки вызова, проще говоря двойных гудков) при звонках с Cisco Jabber через MRA во ТФОП. Проблема эта возникла (согласно матрице совместимости) из-за того, что Cisco Expressway были слишком новые (версия 12.6.1) для CUCM (11.0). К слову CUCM был в полноценном боевом режиме, переезд которого был рискован для бизнеса с точки зрения нормального функционирования после переезда.
Переезжали мы вдвоём с коллегой, у которого опыта с пользовательскими фишечками и рюшечками сильно больше моего, что и сыграло ключевую роль в безболезненном переезде.
Вариантов накатывания бэкапа взятого с Unrestricted на Restricted и обновления с Unrestricted на Restricted версию у Cisco не предусмотрено, поэтому только разворачивание с нуля, только хардкор.
Итак, по пунктно и поэтапно создаём/разворачиваем:
1) DNS записи:
A-записи cucm01.example.ru, cucm02.example.ru,cups01.example.ru, cups02.example.ru
SRV-записи на внутреннем DNS сервере: _cisco-uds._tcp.example.ru, _cuplogin._tcp.example.ru
2) Разворачивание новых виртуальных машин.
В нашем случае это были версии 11.5 последних релизов CUCM и CUPS по две ноды на кластер. Версия 11.5, а не 12.5 выбрана по причине отсутствия контрактов на обновления лицензий и лицензий для версии 12.5.
Также если Alerting Name у вас на номерах телефонов не английский, то обязательно нужно накатить нужные языковые локали иначе при звонках (как внутри, так и на другие кластеры) будут отображаться только номера телефонов.
Кроме всего прочего сделали жёсткий диск не 80Гб, а 120Гб для того чтобы в будущем у нас не возникало проблем с забитыми под завязку партициями, что в свою очередь приводит к невозможности загрузить прошивки и прочие файлы обновлений.
3) Создание запросов на сертификаты, загрузка сертификатов на CUCM'ы и CUPS'ы.
Выдачу сертификатов делаем по двум шаблонам Web Client и Web Server, иначе SIP-транки между нашим новым кластером и остальной инфраструктурой (которая также на Cisco) по порту 5061 не получится.
4) Экспортируем со старого и нового кластеров сертификаты, и импортируем их друг другу.
1. На обоих кластерах указываем SFTP-сервер на который и с которого экспортируем/импортируем сертификаты.
2. На обоих кластерах делаем экспорт всех сертификатов.
3. На обоих кластерах делаем импорт всех сертификатов.
4. Нажимаем Consolidate.
5. Проверяем в Trust List сертификаты обоих кластеров
6. Перезапускаем Cisco Tomcat службу на обоих кластерах.
Экспортируем конфигурации и настройки со старых CUCM'ов и CUPS'ов.
1) Экспортируем все настройки кластера кроме раздела Advanced Features и пунктов Enterprise Parameters, Server, Cisco Unified Communications Manager, Cisco Unified Communications Manager Group и Service Parameters.
Скачиваем себе сгенерированый файл
Т.к. у нас перенос боевого сервера то если мы перенесем и эти настройки, то у нас возникнет конфликт в части ILS и пользовательской части, т.к. и там и там одни и те же пользователи будут иметь домашний кластер. Также нам не нужно чтобы некоторые параметры на новый кластер перенеслись со значениями старого кластера. Настройки же Voice Mail'а (если они есть) можно добавить и вручную снова.
Также настоятельно рекомендую проверить значения в настройках относительно количества пользователей в Ad-Hoc и Meetme конференциях, чтобы не получилось так что в утренний селектор попали не все предполагаемые участники, а только их часть.
2) Экспортируем Line Appearance.
Скачиваем себе сгенерированый файл
Line appearance отвечает за отображения статуса пользователя (On call, on meeting и прочее). Если эти настройки не перенести, то в джаббере все пользователи будут в статусе offline.
3) Экспортируем списки контактов с publisher'а CUPS'а.
Списки контактов пользователей (которые они сами себе составили) хранятся на CUPS'е, но т.к. они у нас будут новые, то при переезде пользовательских джабберов на «новые рельсы» все они пропадут поэтому нужно их экспортировать/импортировать отдельно.
Все абсолютно пользователи нас не интересуют, берем только assigned пользователей
Обратите внимание что, формат контакт листов отличается на одну позицию, в новой версии CUCM добавляется поле State.
Поэтому скачанный файл со списком контактов требуется отредактировать (например в MS Excel), добавив столбик «State» и забив его значением «1» для каждой строчки, иначе импорт этого списка контактов потерпит неудачу.
4) На новом кластере CUCM указываем имя кластера отличное от старого.
5) Меняем настройки локализации в Enterpise Parameters, если требуется.
6) На новом кластере IMP меняем схему и домен, если они не совпадают, InterCluster настройки делаем такие же, как на старом.
7) Скачиваем jabber-config.xml со старого кластера и закидываем его на новый. Перезапускаем Cisco TFTP службу. Не требуется если переезд идёт на версию 12.5 и выше, там нужно настроить этот конфиг в UC Service и прикрутить его к Service Profile.
Третий этап рекомендуется производить в нерабочее время, чтобы пользователи не отвалились от своих сервисов телефонии.
1) Импортируем все, что экспортировали на втором этапе.
2) Удаляем на Expressway'ях старые ноды UCM и IMP.
3) На старом CUCM-кластере делаем Disconnect (или переводим в режим StandAlone, если Disconnect вдруг не отрабатывает) в части настроек ILS.
4) На новом CUCM-кластере настраиваем ILS.
5) Удаляем старый CUCM-кластер с PLM, и добавляем новый CUCM-кластер.
6) Редактируем 150 (или 66, в зависимости от ваших настроек) опцию на DHCP-сервере на IP-адреса нового CUCM-кластера и отправляем в Reset и Restart все телефоны на старом кластере. Они должны все перерегистрироваться на новом CUCM-кластере.
7) Добавляем на Expressway новые кластера UCM и IMP.
8) На транках других АТС, которые смотрят на старый CUCM-кластер изменяем IP-адреса старого кластера на IP-адреса нового кластера.
Наш переезд был не так гладок, как в этой статье, но все ошибки и нужную последовательность действий я свёл верно.
На этом всё, если что-то упустил прошу дополнить в комментариях.
Переезжали мы вдвоём с коллегой, у которого опыта с пользовательскими фишечками и рюшечками сильно больше моего, что и сыграло ключевую роль в безболезненном переезде.
Вариантов накатывания бэкапа взятого с Unrestricted на Restricted и обновления с Unrestricted на Restricted версию у Cisco не предусмотрено, поэтому только разворачивание с нуля, только хардкор.
Итак, по пунктно и поэтапно создаём/разворачиваем:
Первый этап
1) DNS записи:
A-записи cucm01.example.ru, cucm02.example.ru,cups01.example.ru, cups02.example.ru
SRV-записи на внутреннем DNS сервере: _cisco-uds._tcp.example.ru, _cuplogin._tcp.example.ru
2) Разворачивание новых виртуальных машин.
В нашем случае это были версии 11.5 последних релизов CUCM и CUPS по две ноды на кластер. Версия 11.5, а не 12.5 выбрана по причине отсутствия контрактов на обновления лицензий и лицензий для версии 12.5.
Также если Alerting Name у вас на номерах телефонов не английский, то обязательно нужно накатить нужные языковые локали иначе при звонках (как внутри, так и на другие кластеры) будут отображаться только номера телефонов.
Кроме всего прочего сделали жёсткий диск не 80Гб, а 120Гб для того чтобы в будущем у нас не возникало проблем с забитыми под завязку партициями, что в свою очередь приводит к невозможности загрузить прошивки и прочие файлы обновлений.
3) Создание запросов на сертификаты, загрузка сертификатов на CUCM'ы и CUPS'ы.
Выдачу сертификатов делаем по двум шаблонам Web Client и Web Server, иначе SIP-транки между нашим новым кластером и остальной инфраструктурой (которая также на Cisco) по порту 5061 не получится.
4) Экспортируем со старого и нового кластеров сертификаты, и импортируем их друг другу.
1. На обоих кластерах указываем SFTP-сервер на который и с которого экспортируем/импортируем сертификаты.
2. На обоих кластерах делаем экспорт всех сертификатов.
3. На обоих кластерах делаем импорт всех сертификатов.
4. Нажимаем Consolidate.
5. Проверяем в Trust List сертификаты обоих кластеров
6. Перезапускаем Cisco Tomcat службу на обоих кластерах.
Второй этап
Экспортируем конфигурации и настройки со старых CUCM'ов и CUPS'ов.
1) Экспортируем все настройки кластера кроме раздела Advanced Features и пунктов Enterprise Parameters, Server, Cisco Unified Communications Manager, Cisco Unified Communications Manager Group и Service Parameters.
Скачиваем себе сгенерированый файл
Т.к. у нас перенос боевого сервера то если мы перенесем и эти настройки, то у нас возникнет конфликт в части ILS и пользовательской части, т.к. и там и там одни и те же пользователи будут иметь домашний кластер. Также нам не нужно чтобы некоторые параметры на новый кластер перенеслись со значениями старого кластера. Настройки же Voice Mail'а (если они есть) можно добавить и вручную снова.
Также настоятельно рекомендую проверить значения в настройках относительно количества пользователей в Ad-Hoc и Meetme конференциях, чтобы не получилось так что в утренний селектор попали не все предполагаемые участники, а только их часть.
2) Экспортируем Line Appearance.
Скачиваем себе сгенерированый файл
Line appearance отвечает за отображения статуса пользователя (On call, on meeting и прочее). Если эти настройки не перенести, то в джаббере все пользователи будут в статусе offline.
3) Экспортируем списки контактов с publisher'а CUPS'а.
Списки контактов пользователей (которые они сами себе составили) хранятся на CUPS'е, но т.к. они у нас будут новые, то при переезде пользовательских джабберов на «новые рельсы» все они пропадут поэтому нужно их экспортировать/импортировать отдельно.
Все абсолютно пользователи нас не интересуют, берем только assigned пользователей
Обратите внимание что, формат контакт листов отличается на одну позицию, в новой версии CUCM добавляется поле State.
Старый формат
Новый формат
Поэтому скачанный файл со списком контактов требуется отредактировать (например в MS Excel), добавив столбик «State» и забив его значением «1» для каждой строчки, иначе импорт этого списка контактов потерпит неудачу.
4) На новом кластере CUCM указываем имя кластера отличное от старого.
5) Меняем настройки локализации в Enterpise Parameters, если требуется.
6) На новом кластере IMP меняем схему и домен, если они не совпадают, InterCluster настройки делаем такие же, как на старом.
7) Скачиваем jabber-config.xml со старого кластера и закидываем его на новый. Перезапускаем Cisco TFTP службу. Не требуется если переезд идёт на версию 12.5 и выше, там нужно настроить этот конфиг в UC Service и прикрутить его к Service Profile.
Третий этап
Третий этап рекомендуется производить в нерабочее время, чтобы пользователи не отвалились от своих сервисов телефонии.
1) Импортируем все, что экспортировали на втором этапе.
2) Удаляем на Expressway'ях старые ноды UCM и IMP.
3) На старом CUCM-кластере делаем Disconnect (или переводим в режим StandAlone, если Disconnect вдруг не отрабатывает) в части настроек ILS.
4) На новом CUCM-кластере настраиваем ILS.
5) Удаляем старый CUCM-кластер с PLM, и добавляем новый CUCM-кластер.
6) Редактируем 150 (или 66, в зависимости от ваших настроек) опцию на DHCP-сервере на IP-адреса нового CUCM-кластера и отправляем в Reset и Restart все телефоны на старом кластере. Они должны все перерегистрироваться на новом CUCM-кластере.
7) Добавляем на Expressway новые кластера UCM и IMP.
8) На транках других АТС, которые смотрят на старый CUCM-кластер изменяем IP-адреса старого кластера на IP-адреса нового кластера.
Наш переезд был не так гладок, как в этой статье, но все ошибки и нужную последовательность действий я свёл верно.
На этом всё, если что-то упустил прошу дополнить в комментариях.
