Во многих организациях стоит задача переезда с умирающего Skype for Bussiness на Cisco Jabber и/или Cisco Webex, но сделать это нужно плавно, не перегружая техническую поддержку организации и не вызывая большого недовольства переезжающих пользователей. В этом выпуске расскажу про свой опыт. Моей задачей стояло реализовать схему звонков, конференций всех типов, передачу сообщений и совместный доступ к экрану между пользователями Cisco Jabber/Cisco Webex и S4B по SIP URI, цифровая нумерация была не важна.
В данной статье предполагается, что предварительно настроены кластеры CUCM, IM&P, Expressway-C и CMS.
CUCM 12.5 SU6
IM&P 12.5 SU6
Expressway 14.0.6
CMS 3.3.2
S4B FE Standart
S4B Edge
Во многих организациях присутствует бардак в плане доменов, бывает так, что в организации присутствуют куча доменов третьего уровня, а то и вообще просто разные домены и пользователи живут кто — где. И чтобы нивелировать это условие можно провести переход в рамках этих самых доменов(необязательно двух), но для Cisco Jabber будет ещё один свой дополнительный.
В этом выпуске расскажу о варианте без дополнительного домена, выбран домен inline.su в качестве теста.
Сигнализация звонков будет работать согласно схеме ниже.
Звонок от Cisco Jabber/Cisco Webex поступает с CUCM на CMS в формате стандартного SIP, там он «превращается» в звонок стандарта Microsoft и отправляется на Expressway-C, далее на Skype for Business. Обозначил синими стрелками на схеме.
Звонок со Skype for Business в формате Microsoft SIP отправляется на Expressway, далее на CMS, CMS в свою очередь отправляет звонок обратно на Expressway, Expressway далее опять в S4B. S4B не находит адресата и вновь отправляет его на Expressway, а тот на CMS. CMS понимает, что это петля и обрывая её, отправляет звонок по второму правилу в формате Standart SIP на Expressway, а уже Expressway отправляет звонок на CUCM. Обозначил красными стрелками на схеме.
Такая запутанная схема сделана потому, что другого способа разрулить Standart и Microsoft SIP звонки, при условии что пользователи с одним и тем же доменом могут находиться, как в S4B так и на CUCM, я не нашёл.
Логика такова, что если у профиля Cisco Jabber на CUCM отсутствует заполненный Directory URI, значит пользователь с нужным SIP URI находится в S4B. В данном варианте не может быть такого, что пользователь с одним и тем же SIP URI одновременно работает и в S4B и в CUCM.
Вообще ещё можно сделать прямой SIP Trunk между CUCM и S4B и пускать звонки по SIP URI через него, а Dual-Home конференции через CMS. Это упростило бы маршрутизацию потому, что Dual-Home конференции это всегда вызов по номеру, т.е. достаточно одного Route Pattern'a в сторону CMS и одного SIP Route Pattern'a в сторону S4B, но мы не ищем лёгких путей.
Далее настраиваем:
Передача сообщений между пользователями Cisco Jabber и S4B будет работать по так называемой IntraDomain федерации, однако, маршрут, который создаётся автоматически на серверах IM&P напрямую в сторону S4B, мы вручную изменяем в сторону Expressway.
Также для IMP&P требуется адресная схема вида Directory URI.
Далее на IM&P настраиваем:
В данной статье предполагается, что предварительно настроены кластеры CUCM, IM&P, Expressway-C и CMS.
CUCM 12.5 SU6
IM&P 12.5 SU6
Expressway 14.0.6
CMS 3.3.2
S4B FE Standart
S4B Edge
Варианты перехода
Моментальное отключение S4B у пользователей и мгновенный переход на Cisco Jabber/Webex
Плюсы и минусы
Плюсы такого подхода заключаются в том, что не нужно проводить работ по настройке интеграции S4B и Cisco Jabber и соответственно тратить время и ресурсы.
Минусами же является огромная нагрузка на техническую поддержку организации(особенно если пользователей несколько тысяч), шквал заявок и недовольство пользователей.
Минусами же является огромная нагрузка на техническую поддержку организации(особенно если пользователей несколько тысяч), шквал заявок и недовольство пользователей.
Плавный переход с дополнительно выделенным доменом для пользователей Cisco Jabber/Cisco Webex
Во многих организациях присутствует бардак в плане доменов, бывает так, что в организации присутствуют куча доменов третьего уровня, а то и вообще просто разные домены и пользователи живут кто — где. И чтобы нивелировать это условие можно провести переход в рамках этих самых доменов(необязательно двух), но для Cisco Jabber будет ещё один свой дополнительный.
Плюсы и минусы
Плюсами такого подхода являются простота переезда, работать у одного пользователя могут оба клиента(и Cisco Jabber/Cisco Webex и S4B), нет шквала заявок от пользователей, низкая нагрузка на техническую поддержку организации.
Минусами являются будущее приведение пользователей к единому домену(т.к. предполагается, что в Cisco Jabber изначально будет домен второго уровня) с затратами ресурсов на перенастройку и отказ сервисов на время этого приведения, что критично само по себе. Также огромным минусом является то, что невозможно в карточку клиента на S4B добавить дополнительный контакт пользователя, что ведет к практическому отказу от звонков со стороны пользователей S4B, вручную набирать никто ничего не захочет. Однако, можно просто «выключать» пользователя из S4B и «включать» на Cisco Jabber/Cisco Webex при этом меняя нужное поле(MSRTCSIP или IPPHONE например) в учетной записи пользователя в Active Directory по которому формируется Directory URI в CUCM(задаётся в LDAP настройках) на новое значение для Cisco Jabber/Cisco Webex, по которому формируется SIP URI.
Минусами являются будущее приведение пользователей к единому домену(т.к. предполагается, что в Cisco Jabber изначально будет домен второго уровня) с затратами ресурсов на перенастройку и отказ сервисов на время этого приведения, что критично само по себе. Также огромным минусом является то, что невозможно в карточку клиента на S4B добавить дополнительный контакт пользователя, что ведет к практическому отказу от звонков со стороны пользователей S4B, вручную набирать никто ничего не захочет. Однако, можно просто «выключать» пользователя из S4B и «включать» на Cisco Jabber/Cisco Webex при этом меняя нужное поле(MSRTCSIP или IPPHONE например) в учетной записи пользователя в Active Directory по которому формируется Directory URI в CUCM(задаётся в LDAP настройках) на новое значение для Cisco Jabber/Cisco Webex, по которому формируется SIP URI.
Плавный переход без дополнительно выделенного домена для пользователей Cisco Jabber/Cisco Webex
Плюсы и минусы
Плюсами такого подхода являются простота перехода. Выключил у пользователя S4B, включил Cisco Jabber/Cisco Webex. И даже менять в учётных записях пользователей в Active Directory ничего не надо.
Единственным минусом является невозможность обмена сообщениями между клиентами Cisco Webex и S4B в виду архитектурной особенности, включение сервиса гибридных сообщений проблему не решает, а настройка SIP Федерации невозможна из-за того, что домен один и тот же везде. Между клиентами Cisco Jabber и S4B всё работает прекрасно.
Единственным минусом является невозможность обмена сообщениями между клиентами Cisco Webex и S4B в виду архитектурной особенности, включение сервиса гибридных сообщений проблему не решает, а настройка SIP Федерации невозможна из-за того, что домен один и тот же везде. Между клиентами Cisco Jabber и S4B всё работает прекрасно.
В этом выпуске расскажу о варианте без дополнительного домена, выбран домен inline.su в качестве теста.
Звонки
Сигнализация звонков будет работать согласно схеме ниже.
Звонок от Cisco Jabber/Cisco Webex поступает с CUCM на CMS в формате стандартного SIP, там он «превращается» в звонок стандарта Microsoft и отправляется на Expressway-C, далее на Skype for Business. Обозначил синими стрелками на схеме.
Звонок со Skype for Business в формате Microsoft SIP отправляется на Expressway, далее на CMS, CMS в свою очередь отправляет звонок обратно на Expressway, Expressway далее опять в S4B. S4B не находит адресата и вновь отправляет его на Expressway, а тот на CMS. CMS понимает, что это петля и обрывая её, отправляет звонок по второму правилу в формате Standart SIP на Expressway, а уже Expressway отправляет звонок на CUCM. Обозначил красными стрелками на схеме.
Такая запутанная схема сделана потому, что другого способа разрулить Standart и Microsoft SIP звонки, при условии что пользователи с одним и тем же доменом могут находиться, как в S4B так и на CUCM, я не нашёл.
Логика такова, что если у профиля Cisco Jabber на CUCM отсутствует заполненный Directory URI, значит пользователь с нужным SIP URI находится в S4B. В данном варианте не может быть такого, что пользователь с одним и тем же SIP URI одновременно работает и в S4B и в CUCM.
Вообще ещё можно сделать прямой SIP Trunk между CUCM и S4B и пускать звонки по SIP URI через него, а Dual-Home конференции через CMS. Это упростило бы маршрутизацию потому, что Dual-Home конференции это всегда вызов по номеру, т.е. достаточно одного Route Pattern'a в сторону CMS и одного SIP Route Pattern'a в сторону S4B, но мы не ищем лёгких путей.
Далее настраиваем:
7. Настраиваем конфигурационный файл Cisco Jabber.
Требуется добавить эти параметры, иначе при добавлении контакта в список контактов Cisco Jabber чат-адрес в карточке добавленного контакта будет некорректный, суффикс контакта будет содержать домен пользователя, который этот контакт себе добавляет, и как следствие не будет работать передача сообщений и статусов.
Требуется добавить эти параметры, иначе при добавлении контакта в список контактов Cisco Jabber чат-адрес в карточке добавленного контакта будет некорректный, суффикс контакта будет содержать домен пользователя, который этот контакт себе добавляет, и как следствие не будет работать передача сообщений и статусов.
8. Импортируем пользователей из MS AD в CUCM.
Передача сообщений и статусов присутствия
Передача сообщений между пользователями Cisco Jabber и S4B будет работать по так называемой IntraDomain федерации, однако, маршрут, который создаётся автоматически на серверах IM&P напрямую в сторону S4B, мы вручную изменяем в сторону Expressway.
Также для IMP&P требуется адресная схема вида Directory URI.
Далее на IM&P настраиваем:
Настройка Skype For Business
Настройка доверительных отношений с серверами Cisco
1.1. Настройка доверия с CMS.
Создание пула CMS:
New-CsTrustedApplicationPool -Identity cms.inline.su -Registrar sfbfe01.inline.su -Site 1 -RequiresReplication $false -ThrottleAsServer $true -TreatAsAuthenticated $true -ComputerFqdn cms01.inline.su
Добавление серверов CMS в пул:
New-CsTrustedApplicationComputer -Identity cms02.inline.su -Pool cms.inline.su
New-CsTrustedApplicationComputer -Identity cms03.inline.su -Pool cms.inline.su
Создание приложения CMS:
New-CsTrustedApplication -ApplicationId CiscoCMS -TrustedApplicationPoolFqdn cms.inline.su -Port 5061
1.2. Настройка доверия с CUPS.
Создание пула CUPS:
New-CsTrustedApplicationPool -Identity cups.inline.su -Registrar sfbfe01.inline.su -Site 1 -RequiresReplication $false -ThrottleAsServer $true -TreatAsAuthenticated $true -ComputerFqdn cups01.inline.su
Добавление серверов CUPS в пул:
New-CsTrustedApplicationComputer -Identity cups02.inline.su -Pool cups.inline.su
Создание приложения CUPS:
New-CsTrustedApplication -ApplicationId CiscoImPres -TrustedApplicationPoolFqdn cups.inline.su -Port 5061
1.3. Настройка доверия с Expressway-C.
Создание пула Expressway-C:
New-CsTrustedApplicationPool -Identity expc.inline.su -Registrar sfbfe01.inline.su -Site 1 -RequiresReplication $false -ThrottleAsServer $true -TreatAsAuthenticated $true -ComputerFqdn expc01.inline.su
Добавление серверов Expressway-C в пул:
New-CsTrustedApplicationComputer -Identity expc02.inline.su -Pool expc.inline.su
Создание приложения Expressway-C:
New-CsTrustedApplication -ApplicationId CiscoExpWay -TrustedApplicationPoolFqdn expc.inline.su -Port 5061
1.4. Применение настроек.
Сохранение настроек топологии:
Enable-CsTopology
Перезапуск сервисов на Front End серверах:
Stop-CsWindowsService
Start-CsWindowsService
Создание пула CMS:
New-CsTrustedApplicationPool -Identity cms.inline.su -Registrar sfbfe01.inline.su -Site 1 -RequiresReplication $false -ThrottleAsServer $true -TreatAsAuthenticated $true -ComputerFqdn cms01.inline.su
Добавление серверов CMS в пул:
New-CsTrustedApplicationComputer -Identity cms02.inline.su -Pool cms.inline.su
New-CsTrustedApplicationComputer -Identity cms03.inline.su -Pool cms.inline.su
Создание приложения CMS:
New-CsTrustedApplication -ApplicationId CiscoCMS -TrustedApplicationPoolFqdn cms.inline.su -Port 5061
1.2. Настройка доверия с CUPS.
Создание пула CUPS:
New-CsTrustedApplicationPool -Identity cups.inline.su -Registrar sfbfe01.inline.su -Site 1 -RequiresReplication $false -ThrottleAsServer $true -TreatAsAuthenticated $true -ComputerFqdn cups01.inline.su
Добавление серверов CUPS в пул:
New-CsTrustedApplicationComputer -Identity cups02.inline.su -Pool cups.inline.su
Создание приложения CUPS:
New-CsTrustedApplication -ApplicationId CiscoImPres -TrustedApplicationPoolFqdn cups.inline.su -Port 5061
1.3. Настройка доверия с Expressway-C.
Создание пула Expressway-C:
New-CsTrustedApplicationPool -Identity expc.inline.su -Registrar sfbfe01.inline.su -Site 1 -RequiresReplication $false -ThrottleAsServer $true -TreatAsAuthenticated $true -ComputerFqdn expc01.inline.su
Добавление серверов Expressway-C в пул:
New-CsTrustedApplicationComputer -Identity expc02.inline.su -Pool expc.inline.su
Создание приложения Expressway-C:
New-CsTrustedApplication -ApplicationId CiscoExpWay -TrustedApplicationPoolFqdn expc.inline.su -Port 5061
1.4. Применение настроек.
Сохранение настроек топологии:
Enable-CsTopology
Перезапуск сервисов на Front End серверах:
Stop-CsWindowsService
Start-CsWindowsService
Настройка маршрутов
2.1. Настройка корневого домена.
$x1 = New-CsStaticRoute -TLSRoute -Destination 'expc.inline.su' -MatchUri 'uc.inline.su' -Port 5061 -UseDefaultCertificate $true
Set-CsStaticRoutingConfiguration -Identity Global -Route @{Add=$x1}
2.2. Настройка дополнительных доменов.
В случае необходимости добавления маршрутов на дополнительные домены, изменить поле MatchUri на соответствующие значение:
$x2 = New-CsStaticRoute -TLSRoute -Destination 'expc.inline.su' -MatchUri '' -Port 5061 -UseDefaultCertificate $true
Set-CsStaticRoutingConfiguration -Identity Global -Route @{Add=$x2}
2.3. Применение настроек.
Сохранение настроек топологии:
Enable-CsTopology
Перезапуск сервисов на Front End серверах:
Stop-CsWindowsService
Start-CsWindowsService
На этом все настройки закончены. Во второй части расскажу о настройках для планового перехода на Cisco Jabber с выделенным для него отдельным доменом и SIP Федерацию с внешними организациями, при таком сценарии работает полноценно и Cisco Webex тоже.
Статья довольно сырая в плане оформления, за что прошу простить. По мере наличия времени и желания буду приводить её в более привлекательный вид.
$x1 = New-CsStaticRoute -TLSRoute -Destination 'expc.inline.su' -MatchUri 'uc.inline.su' -Port 5061 -UseDefaultCertificate $true
Set-CsStaticRoutingConfiguration -Identity Global -Route @{Add=$x1}
2.2. Настройка дополнительных доменов.
В случае необходимости добавления маршрутов на дополнительные домены, изменить поле MatchUri на соответствующие значение:
$x2 = New-CsStaticRoute -TLSRoute -Destination 'expc.inline.su' -MatchUri '' -Port 5061 -UseDefaultCertificate $true
Set-CsStaticRoutingConfiguration -Identity Global -Route @{Add=$x2}
2.3. Применение настроек.
Сохранение настроек топологии:
Enable-CsTopology
Перезапуск сервисов на Front End серверах:
Stop-CsWindowsService
Start-CsWindowsService
Настройка доверия сертификатам
3.1. На Front End серверах открыть MMC оснастку Certificates (Computer).
3.2. Перейти в раздел Trusted Root Certification Authorities.
3.3. Убедиться, что сертификат корневого УЦ, выдавшего сертификат на серверы Cisco находится в данном разделе.
3.4. В случае отсутствия, импортировать недостающий корневой сертификат.
3.2. Перейти в раздел Trusted Root Certification Authorities.
3.3. Убедиться, что сертификат корневого УЦ, выдавшего сертификат на серверы Cisco находится в данном разделе.
3.4. В случае отсутствия, импортировать недостающий корневой сертификат.
Проверка настроек SFB сервера
4.1. Настройки адресной книги.
Настройки политик адресной книги рекомендуется сделать WebSearchOnly. Посмотреть текущие настройки:
Get-CsClientPolicy | ft Identity,AddressBookAvailability
Задать настройки:
Set-CsClientPolicy Global –AddressBookAvailability WebSearchOnly
4.2. Настройки поддержки шифрования медиа трафика.
Настройки шифрования медиа трафика рекомендуется сделать SupportEncryption. Посмотреть текущие настройки:
Get-CsMediaConfiguration | ft Identity,EncryptionLevel
Задать настройки:
Set-CsMediaConfiguration global -EncryptionLevel SupportEncryption
Настройки политик адресной книги рекомендуется сделать WebSearchOnly. Посмотреть текущие настройки:
Get-CsClientPolicy | ft Identity,AddressBookAvailability
Задать настройки:
Set-CsClientPolicy Global –AddressBookAvailability WebSearchOnly
4.2. Настройки поддержки шифрования медиа трафика.
Настройки шифрования медиа трафика рекомендуется сделать SupportEncryption. Посмотреть текущие настройки:
Get-CsMediaConfiguration | ft Identity,EncryptionLevel
Задать настройки:
Set-CsMediaConfiguration global -EncryptionLevel SupportEncryption
Переключение пользователя на другую систему UC
5.1. Отключение пользователя на SFB.
Подготовить списки ID пользователей через PowerShell или любым другим способом. В качестве ID может выступать UPN, SIP Address, sAMAccountName, Display Name:
$SfbUsers = Get-CsUser –ResultSize Unlimited | ?{$_.SipAddress –like "*@uc.inline.su" –and $_.Enabled –like «True»} | select sAMAccountName,SipAddress,Enabled
Отключение пользователей из списка SFB:
foreach($UcUser in $SfbUsers) {Disable-CsUser –Identity $UcUser.sAMAccountName –Confirm:$false}
5.2. Включение атрибута msRTCSIP-PrimaryUserAddress.
После отключения пользователей на серверах SFB им необходимо заполнить атрибут msRTCSIP-PrimaryUserAddress соответствующим адресом, использующимся на серверах Cisco:
foreach($UcUser in $SfbUsers) {Set-AdUser –Identity $UcUser.sAMAccountName –Replace @{«msRTCSIP-PrimaryUserAddress»='sip:'+$($UcUser.sAMAccountName)+'@uc.inline.su'}}
Подготовить списки ID пользователей через PowerShell или любым другим способом. В качестве ID может выступать UPN, SIP Address, sAMAccountName, Display Name:
$SfbUsers = Get-CsUser –ResultSize Unlimited | ?{$_.SipAddress –like "*@uc.inline.su" –and $_.Enabled –like «True»} | select sAMAccountName,SipAddress,Enabled
Отключение пользователей из списка SFB:
foreach($UcUser in $SfbUsers) {Disable-CsUser –Identity $UcUser.sAMAccountName –Confirm:$false}
5.2. Включение атрибута msRTCSIP-PrimaryUserAddress.
После отключения пользователей на серверах SFB им необходимо заполнить атрибут msRTCSIP-PrimaryUserAddress соответствующим адресом, использующимся на серверах Cisco:
foreach($UcUser in $SfbUsers) {Set-AdUser –Identity $UcUser.sAMAccountName –Replace @{«msRTCSIP-PrimaryUserAddress»='sip:'+$($UcUser.sAMAccountName)+'@uc.inline.su'}}
На этом все настройки закончены. Во второй части расскажу о настройках для планового перехода на Cisco Jabber с выделенным для него отдельным доменом и SIP Федерацию с внешними организациями, при таком сценарии работает полноценно и Cisco Webex тоже.
Статья довольно сырая в плане оформления, за что прошу простить. По мере наличия времени и желания буду приводить её в более привлекательный вид.
Комментарии (8)
DadeMurphyZC
18.04.2022 09:03+2У нас сейчас в компании из-за забаненного Cisco Webex, резкий откат назад к S4B, ну а потом переход куда-то еще. Так что соглашусь с предидущем постом, по поводу актуальности статьи.
s_dubinin Автор
18.04.2022 09:04Так, а откат с Cisco Webex на Cisco Jabber у вас почему невозможен? Просто Microsoft то точно также ушел, как и Cisco из РФ.
AstorS1
18.04.2022 20:20Предположу, что компании использовавшие S4B скорее переедут на MS Teams. Пользователям и админам будет проще.
Статья интересна своей практической направленностью.
s_dubinin Автор
18.04.2022 20:48Не переедут, увы, MS Teams в РФ больше не продаётся, а текущие подписки больше не продляются.
AlessandroS
Большой плюс статьи - своевременность ;)).
Как большой поклонник Циски и обладатель её же заблокированных аккаунтов везде, включая Вебекс, оценил.
Ну а по существу, описан самый банальный и распространённый кейс, настройки транка между s4b и кукумом :), сродни Hello World у программистов. К слову Cisco Meeting Server, который вы хотите предустановленным, тоже скорее уже не жилец, и особого смысла переходить на него нет.
s_dubinin Автор
Статья начинала писаться за долго до последних событий. Не знаю, что вы подразумеваете под банальным транком, но о SIP транке между S4B и CUCM тут речи не идет, это совершенно другая песня, вы видимо невнимательно читали. А про CMS я такие комментарии который год читаю уже, но он жив и вроде развивается даже. Другое дело, что достойные конкуренты у него есть это правда.
AlessandroS
Ну окей, не транк (у нас этот жаргонизм из связи сохранился), называйте это интеграцией между s4b и циской - суть от этого не меняется. Это один из самых распространённых кейсов :).
По оценке московской циски - продукт плавно хоронят. Хотя, это конечно некоторая спекуляция, так как официальных заявлений из-за океана я не видел. В общем, как онпрем решение он довольно неплох (но дороговат). Приложение для него убили уже давно, перевели все в джаббер и выглядет там конференц функционал бледновато по сравнению с тем же вебексом.
AlessandroS
PS И конечно, статья хорошая и цикл у вас получается очень неплохой. В отличие от привет мир для разрабов, в телекоме довольно мало подробных статей на русском языке по данной тематике. Так что не воспринимайте как критику, наоборот всячески поддерживаю.
Иногда напишешь ответ через призму личного опыта, не задумавшись о том, насколько полезно это может оказаться для большого количества инженеров, да даже и качестве краткой памятки. И постфактум понимаешь, что сам ни черта не написал, да ещё и других задел :). Так что абзац выше.