Во многих организациях стоит задача переезда с умирающего 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, но мы не ищем лёгких путей.
Далее настраиваем:
1. Создаем SIP Trunk Security Profile's
Для Expressway
для CMS
Для IM&P
для CMS
Для IM&P
2. Создаем SIP Trunk'и.
Для Expressway
Для CMS
Для IM&P
Для Expressway
Для CMS
Для IM&P
3. Создаем SIP Route Pattern'ы на CUCM.
4. Создаем CMS Conference Bridge.
5. Заполняем Organization Top Level Domain в Enterprise.
6. Создаём UC Services и Service Profile.
7. Настраиваем конфигурационный файл Cisco Jabber.
Требуется добавить эти параметры, иначе при добавлении контакта в список контактов Cisco Jabber чат-адрес в карточке добавленного контакта будет некорректный, суффикс контакта будет содержать домен пользователя, который этот контакт себе добавляет, и как следствие не будет работать передача сообщений и статусов.
Требуется добавить эти параметры, иначе при добавлении контакта в список контактов Cisco Jabber чат-адрес в карточке добавленного контакта будет некорректный, суффикс контакта будет содержать домен пользователя, который этот контакт себе добавляет, и как следствие не будет работать передача сообщений и статусов.
8. Импортируем пользователей из MS AD в CUCM.
Directory URI и Phone Number в моём случае не принципиально из каких полей LDAP импортировать, сделал как на изображении выше
Directory URI и Phone Number в моём случае не принципиально из каких полей LDAP импортировать, сделал как на изображении выше
9. Создаём правила входящих звонков и правила переадресации на CMS.
10. Создаём правила исходящих звонков с соответствующими приоритетами.
11. Настраиваем Microsoft Interoperability на Expressway.
12. Создаём зоны на Expressway.
13. Создаем правила поиска на Expressway.
Передача сообщений и статусов присутствия
Передача сообщений между пользователями Cisco Jabber и S4B будет работать по так называемой IntraDomain федерации, однако, маршрут, который создаётся автоматически на серверах IM&P напрямую в сторону S4B, мы вручную изменяем в сторону Expressway.
Также для IMP&P требуется адресная схема вида Directory URI.
Далее на IM&P настраиваем:
1. Security Settings
2. Incoming ACL
3. Outcoming ACL
4. Application listeners
5. Routing Settings
6. Static Routes
7. TLS Context Configuration
8. TLS Peer Subjects
Настройка 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 тоже.
Статья довольно сырая в плане оформления, за что прошу простить. По мере наличия времени и желания буду приводить её в более привлекательный вид.
