В данном разделе мы произведём переход с одного домена в другой.

Наиболее близкий официальный документ:
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

Подготовка

1. Делаем копии всех виртуальных машин UCCX и CUCM
2. Делаем Snapshot на каждой виртуально машине
3. Копируем конфигурации всех шлюзов IOS
4. Делаем скриншоты настроек шлюзов на CUCM
5. Делаем скриншоты настроек LDAP Directory и LDAP Authentication
6. Делаем копии скриптов UCCX, а также файлов Prompt
7. Делаем скриншоты страниц Licensing для CUCM и UCCX
8. Делаем скриншот страницы CUCM System > Server
9. Сделать список коммутаторов где живут большинство телефонов (для их перезагрузки)
10. Сделать список зареганых телефонов

Прописываем хосты в новом домене:
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. Проверяем network connectivity.
   utils diagnose module validate_network
   Эту команду ввести на Publisher CUCM и UCCX.
   

Замена значений NTP Server, DNS Server, Domain

Сначала выполняем шаги 1-6 для нодов CUCM, затем UCCX.

1. Для начала проверим статус репликации баз:
   CUCM OS Admin CLI
   Заходим на Publisher и даем команду:
   admin:utils dbreplication status
   

   Для UCCX также следует проверить статус сервисов:
   CCX Admin > System > Server
   Статус всех серверов кластера должен быть IN SERVICE

   Также для UCCX зайдём: CUCCX Serviceability > Tools > Data control Center > Replication servers
   При нормальной репликации окно должно выглядеть примерно так:
   

2. Протестируем работу телефонов и UCCX, при выключенных Publisher CUCM и UCCX
3. Меняем NTP Server
   CUCM Publisher > OS Administration > Settings > NTP Servers
   Добавляем новый 10.19.0.1 10.19.0.2
   Удаляем старый 10.19.16.11

   Менять на 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 не требуется

4. Меняем таймзону нодов
   Чтобы посмотреть текущее время на сервере и текущую таймзону:

   utils ntp status

   Смотрим текущую настройку таймзоны:

   show timezone config

   Смотрим доступные таймзоны:

   show timezone list

   Изменяем таймзону:

   set timezone Etc/GMT-5

   Операция потребует ребута сервера.
   

Когда Publisher перестанет пинговаться, выполняем то же на Subscriber

После перезагрузки обоих серверов проверяем всё ли правильно поменяли, корректно ли отображается время.

5. Меняем DNS Server
   После перезагрузки проверяем репликацию БД.
   Проверка
   show network eth0

   Замена
   set network dns primary 10.19.65.248
   
   После нажатия на "y" система поменяет значения, затем возможно кратковременно потеряет подключение, но затем восстановится. Перезагрузка не требуется.

   Аналогичные команды выполняем на Subscriber

   На этом этапе проблем с репликацией никогда не возникало.

6. Изменение имени доменного суффикса влечёт за собой перегенерацию сертификатов серверов CUCM, что может помешать некоторым телефонам нормально загрузиться из-за работы функции Security By Default (SBD).
   Для решения данной проблемы мы временно переведём кластер в режим Rollback to pre-8.0:
   - На телефоне 6921 проверяем Settings > Security > Trust List > ITL, там должен быть список серверов CUCM со старым суффиксом.
   - CUCM Admin > System > Enterprise Parameters, меняем значение Prepare Cluster for Rollback to pre 8.0 на TRUE
   - Часть телефонов возможно перегрузятся.
   - Restart Trust Verification Services and TFTP
   -Перегрузить все телефоны, после перезагрузки проверим на телефоне Settings > Security > Trust List > ITL список должен стать пустым.
   3905 могут не подняться, - их всех нужно пнуть по питанию
7. Меняем Domain:
   SSH console:
   Проверка
   show network eth0

   

   Замена:
   set network domain test2.local
   

   После нажатия на "y" система поменяет значения, затем сама уйдёт в ребут.
   Дождаться когда система уйдёт в ребут (перестанет пинговаться), и дать ту же команду на Subscriber.
   Засекаем время, т.к. через 20 минут понадобится кластер ребутнуть опять.

8. В DHCP для телефонов меняем параметр Domain suffix на новый
9. После перезагрузки проверяем репликацию

   Сразу после перезагрузки может быть такое:
   

   Перезагрузка обоих нодов через (20-40) минут решила проблему:
   utils system restart
   Ребутаем Publisher, ждём 30сек, ребутаем Subscriber
   Дожидаемся когда REPL.QUEUE обнулится.
   

10. После того как репликация проходит нормально возвращаем параметр обратно:
    - CUCM Admin > System > Enterprise Parameters, меняем значение Prepare Cluster for Rollback to pre 8.0 на FALSE
    - Часть телефонов возможно перегрузятся.
    - Restart Trust Verification Services and TFTP
    -Перегрузить все телефоны, после перезагрузки проверим на телефоне Settings > Security > Trust List > ITL список должен стать пустым.
    3905 могут не подняться, - их всех нужно пнуть по питанию

    При перезагрузке телефона лог должен быть примерно таким:
    

    Проверить

    • Проверить доступ с телефона к корпоративной адр. книге

    С телефонам воможны следующие проблемы:
    - 3905 возникает только проблема того что телефоны не могут загрузиться после перезагрузки CUCM. В этом случае их нужно ребутнуть руками, либо отключив питание.
    - 6921 - ребутается долго (минут 10). У него остаются следы от старого имени домена: Admin Settings > Security Setup > Trust list > ITL file - здесь фигурируют имена CUCM со старым доменным суффиксом. Проблема лечится через ресет Admin > Reset Settings > All

Повторяем шаги 1-6 для нодов UCCX.

Окончательная проверка репликации

Для полной проверки БД CUCM помимо проверки статуса БД мы дополнительно проверим следующее:

• Меняем Description у телефона со стороны Publisher, смотри чтобы изменения были видны если зайти на Subscriber.
  Тоже самое должно отрабатывать если изменения делать со стороны Subscriber.
• Закрыть доступ к Publisher. Телефон должен зарегаться на Subsciber. Если зайти на Publisher регистрация должна указывать что телефон зарегался на Subscriber. При восстановлении доступа телефон должен вернуться на Publisher.

Всё работает, только обнаружилась ошибка на телефоне:
[11:40,06/19/15] TFTP error : download CTLSEP60735C11506D.tlv fail

Время перехода на резервный CUCM - 3 минуты

Итак, на UCCX имя домена изменено. Тем не менее MGCP шлюз продолжает успешно принимать и отправлять звонки.

Перевод настроек 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

Перевод настроек LDAP на CUCM на новый домен

Основная проблема при переходе - это аутентификация UCCX.
Дело в том, что при переходе в новый домен потеряются старые пользователи AD и следовательно мы не смжем зайти в админку UCCX.
Здесь ситуация от версии нашего UCCX:

• Prior to UCCX 8.5.1su3
  Единственный выход - обратиться в Cisco TAC, они делают пару вещей позволяющую привести UCCX к состоянию "Fresh_Install".
• 8.5.1su3 and later +
  Здесь мы сможем назначить админом UCCX существующего пользователя CUCM используя команду UCCX:
  admin:set uccx appadmin administrator

  Этим мы и воспользуемся в нашем примере.
  Если у вас UCCX 8.5.X сделайте ему апгрейд до последней версии, иначе эта команда не будет доступна.

• 9.x +
  Здесь добавлена возможность заходить в UCCX используя application username. Впрочем и CUCM версий 9.x + позволяет держать одновременно локальных и доменных пользователей.

Исходное состояние CUCM

В CUCM у нас включена интеграция с LDAP, поэтому все пользователя взяты из AD посредством синхронизации:

Пользователи ассоциированы с телефонами:

В свойствах девайса:

В свойствах линии:

В свойствах пользователя:

Под пользователем omarkin мы можем успешно зайти на страницу Cisco Unified CM User Options по адресу:
https://10.19.65.211/ccmuser
И управлять некоторыми параметрами девайса и линии.

Исходное состояние UCCX

В админку мы можем заходить под юзером uccx_admin, данную настройку можно посмотреть:
UCCX Administration > Tools > User Management > Administrator Capability View

Либо посмотреть в CLI:

show uccx appadmin administrators

1. Для начала проверим статус репликации баз:
   CUCM OS Admin CLI
   Заходим на Publisher и даем команду:
   admin:utils dbreplication status
   

   Для UCCX также следует проверить статус сервисов:
   CCX Admin > System > Server
   Статус всех серверов кластера должен быть IN SERVICE

2. Сохраняем скриншотами LDAP Directory и LDAP Authentication:
   CUCM Administration > System > LDAP > LDAP Directory
   CUCM Administration > System > LDAP > LDAP Authentication
   

   

3. Выключаем LDAP Authentication:
   CUCM Administration > System > LDAP > LDAP Authentication
   Убираем галку Use LDAP Authentication for End Users, жмём Save.
4. Удаляем старую LDAP Configuration
   После удаления Пользователи будут находиться в состоянии inactive:
   
   При попытке зайти под каким-нибудь юзером, система выдаст что-то типа:
   Сбой входа в систему - недопустимый идентификатор пользователя или пароль
5. Настройки LDAP System Information оставляем без изменений:
   
6. Настраиваем на новый домен LDAP Directory:
   
   После сохранения проведём полную синхронизацию.
   После синхронизации пользователи будут отображаться следующим образом:
   

   одноимённые пользователи замещают старых. Те юзера кто не реплицировался остались неактивными.
   Забавно, в свойствах телефонов ассоциации юзеров также сохраняются, т.е. одноимённых юзер не нужно ассоциировать заново.

7. Включаем LDAP Authentication:
   
8. UCCX продолжает работать, только зайти в админку под uccx_admin уже нельзя.
   Привязать можно только активного пользователя.
   Привяжем нового пользователя к админке uccx:

   set uccx appadmin administrator omarkin

   

   

   

   После привязки мы можем успешно заходить под новым пользователем из нового домена:
   

9. Перед этим этапом желательно дождаться пока не исчезнут старые пользователи (inactive)
   Ассоциируем новых пользователей с их телефонами:
   В свойствах девайса:
   В свойствах линии:
   В свойствах пользователя:

   В результате каждый пользователь должен успешно заходить на свою страничку.

Вопросы с лицензиями

Лицензии CUCM и UCCX привязаны к нами изменяемым параметрам, т.е. как минимум слетит лицензия серверов если мы изменим параметры:
- timezone
- DNS Server
- Domain (?)

Проверить статус лицензий можно здесь:
CUCM Administration > System > Licensing > License Unit Report

CUCX Administration > System > Licence information > Display licenses