В данном разделе мы произведём переход с одного домена в другой.
Наиболее близкий официальный документ:
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/install/8_6_1/ip...
Также может возникнуть проблема с ITL Files:
http://www.cisco.com/c/en/us/support/docs/unified-communications/unified...
Как вытащить из Personal Addressbook:
https://supportforums.cisco.com/discussion/10946686/export-personal-addr...
Важные значения в старом домене:
NTP Server: 10.19.16.11
DNS Server: 10.19.65.251
Domain: corp.ciscomaster.ru
Важные значения в новом домене:
NTP Server: 10.19.0.1 10.19.0.2
DNS Server: 10.19.65.248
Domain: test2.local
Прописываем хосты в новом домене:
tst-cucm861-01.test2.local 10.19.65.211
tst-cucm861-02.test2.local 10.19.65.212
tst-uccx851-01.test2.local 10.19.65.221
tst-uccx851-02.test2.local 10.19.65.222
tst-voipgw01.test2.local 172.16.127.9
Заводим необходимых пользователей в новом домене:
cucmsync - для синхронизации, сделать членом группы Domain Admins.
omarkin
dvlasov
Сначала выполняем шаги 1-6 для нодов CUCM, затем UCCX.
Для UCCX также следует проверить статус сервисов:
CCX Admin > System > Server
Статус всех серверов кластера должен быть IN SERVICE
Также для UCCX зайдём: CUCCX Serviceability > Tools > Data control Center > Replication servers
При нормальной репликации окно должно выглядеть примерно так:
Менять на Subscriber нет нужды, тк он смотрит на Publisher
Проверяем, статус NTP:
utils ntp config utils ntp status
Ответ должен быть примерно следующим:
Тут следует отметить, что система захочет синхронизироваться, если вышестоящий сервер в свою очередь имеет свой NTP сервер.
В нашем случае вышестоящим является 10.19.0.1 который в свою очередь настроен на 10.19.176.1. Если бы 10.19.0.1 был настроен сам на себя (LOCAL), CUCM отказался бы синхриться с таким сервером.
Также синхоронизация может произойти не сразу - следует подождать минут 5.
Также необходимо поменять Phone NTP References:
CUCM Administration > System > Phone NTP Reference
На странице добавляем значения новые 10.19.0.1 10.19.0.2
Удаляем старые.
Добавить эти новые Phone NTP Reference во всех Date/Time Group:
CUCM Administration > System > Date/Time Group
Выполнять на Subscriber не требуется
utils ntp status
Смотрим текущую настройку таймзоны:
show timezone config
Смотрим доступные таймзоны:
show timezone list
Изменяем таймзону:
set timezone Etc/GMT-5
Операция потребует ребута сервера.
Когда Publisher перестанет пинговаться, выполняем то же на Subscriber
После перезагрузки обоих серверов проверяем всё ли правильно поменяли, корректно ли отображается время.
Замена
set network dns primary 10.19.65.248
После нажатия на "y" система поменяет значения, затем возможно кратковременно потеряет подключение, но затем восстановится. Перезагрузка не требуется.
Аналогичные команды выполняем на Subscriber
На этом этапе проблем с репликацией никогда не возникало.
Замена:
set network domain test2.local
После нажатия на "y" система поменяет значения, затем сама уйдёт в ребут.
Дождаться когда система уйдёт в ребут (перестанет пинговаться), и дать ту же команду на Subscriber.
Засекаем время, т.к. через 20 минут понадобится кластер ребутнуть опять.
Сразу после перезагрузки может быть такое:
Перезагрузка обоих нодов через (20-40) минут решила проблему:
utils system restart
Ребутаем Publisher, ждём 30сек, ребутаем Subscriber
Дожидаемся когда REPL.QUEUE обнулится.
При перезагрузке телефона лог должен быть примерно таким:
Проверить
С телефонам воможны следующие проблемы:
- 3905 возникает только проблема того что телефоны не могут загрузиться после перезагрузки CUCM. В этом случае их нужно ребутнуть руками, либо отключив питание.
- 6921 - ребутается долго (минут 10). У него остаются следы от старого имени домена: Admin Settings > Security Setup > Trust list > ITL file - здесь фигурируют имена CUCM со старым доменным суффиксом. Проблема лечится через ресет Admin > Reset Settings > All
Повторяем шаги 1-6 для нодов UCCX.
Для полной проверки БД CUCM помимо проверки статуса БД мы дополнительно проверим следующее:
Всё работает, только обнаружилась ошибка на телефоне:
[11:40,06/19/15] TFTP error : download CTLSEP60735C11506D.tlv fail
Время перехода на резервный CUCM - 3 минуты
Итак, на UCCX имя домена изменено. Тем не менее MGCP шлюз продолжает успешно принимать и отправлять звонки.
Менять настройки старого шлюза бесполезно, он не заведётся.
Мы будем настраивать новый шлюз по примеру старого.
Перед изменениями необходимо сохранить конфигурацию шлюза, а также сделать скриншоты настроек MGCP Gateway со стороны CUCM.
Скриншоты Route group.
В IOS шлюза мы поменяем старые значения:
ip domain name corp.ciscomaster.ru ip name-server 10.19.65.251 ntp server 10.19.16.11
На новые:
ip domain name test2.local ip name-server 10.19.65.248 ntp server 10.19.0.1 ntp server 10.19.0.2
Сохраняем, отправляем в перезагрузку.
После перезагрузки статус шлюза останется unregistered
Конфигурировать новый шлюз заново используя сохранённые скриншоты, либо конфиг старого шлюза, но с другим доменом
После конфигурирования делаем Reset и порт должен зарегаться. + ребутнуть роутер.
На край можно дёрнуть роутер или переустановить весь MGCP Gateway на CUCM.
no ccm-manager config no ccm-manager config server 10.19.65.211 ccm-manager config server 10.19.65.211 ccm-manager config
Основная проблема при переходе - это аутентификация UCCX.
Дело в том, что при переходе в новый домен потеряются старые пользователи AD и следовательно мы не смжем зайти в админку UCCX.
Здесь ситуация от версии нашего UCCX:
Этим мы и воспользуемся в нашем примере.
Если у вас UCCX 8.5.X сделайте ему апгрейд до последней версии, иначе эта команда не будет доступна.
В CUCM у нас включена интеграция с LDAP, поэтому все пользователя взяты из AD посредством синхронизации:
Пользователи ассоциированы с телефонами:
В свойствах девайса:
В свойствах линии:
В свойствах пользователя:
Под пользователем omarkin мы можем успешно зайти на страницу Cisco Unified CM User Options по адресу:
https://10.19.65.211/ccmuser
И управлять некоторыми параметрами девайса и линии.
В админку мы можем заходить под юзером uccx_admin, данную настройку можно посмотреть:
UCCX Administration > Tools > User Management > Administrator Capability View
Либо посмотреть в CLI:
show uccx appadmin administrators
Для UCCX также следует проверить статус сервисов:
CCX Admin > System > Server
Статус всех серверов кластера должен быть IN SERVICE
одноимённые пользователи замещают старых. Те юзера кто не реплицировался остались неактивными.
Забавно, в свойствах телефонов ассоциации юзеров также сохраняются, т.е. одноимённых юзер не нужно ассоциировать заново.
set uccx appadmin administrator omarkin
После привязки мы можем успешно заходить под новым пользователем из нового домена:
В результате каждый пользователь должен успешно заходить на свою страничку.
Лицензии CUCM и UCCX привязаны к нами изменяемым параметрам, т.е. как минимум слетит лицензия серверов если мы изменим параметры:
- timezone
- DNS Server
- Domain (?)
Проверить статус лицензий можно здесь:
CUCM Administration > System > Licensing > License Unit Report
CUCX Administration > System > Licence information > Display licenses
Добавить комментарий