В данной статье предполагается, что предварительно настроены кластеры 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
Минусами же является огромная нагрузка на техническую поддержку организации(особенно если пользователей несколько тысяч), шквал заявок и недовольство пользователей.
Плавный переход с дополнительно выделенным доменом для пользователей Cisco Jabber/Cisco Webex
Во многих организациях присутствует бардак в плане доменов, бывает так, что в организации присутствуют куча доменов третьего уровня, а то и вообще просто разные домены и пользователи живут кто — где. И чтобы нивелировать это условие можно провести переход в рамках этих самых доменов(необязательно двух), но для Cisco Jabber будет ещё один свой дополнительный.
Минусами являются будущее приведение пользователей к единому домену(т.к. предполагается, что в 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
Единственным минусом является невозможность обмена сообщениями между клиентами 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, но мы не ищем лёгких путей.
Далее настраиваем:
для CMS
Для IM&P
Для Expressway
Для CMS
Для IM&P
Требуется добавить эти параметры, иначе при добавлении контакта в список контактов Cisco Jabber чат-адрес в карточке добавленного контакта будет некорректный, суффикс контакта будет содержать домен пользователя, который этот контакт себе добавляет, и как следствие не будет работать передача сообщений и статусов.
Directory URI и Phone Number в моём случае не принципиально из каких полей LDAP импортировать, сделал как на изображении выше
Передача сообщений и статусов присутствия
Передача сообщений между пользователями Cisco Jabber и S4B будет работать по так называемой IntraDomain федерации, однако, маршрут, который создаётся автоматически на серверах IM&P напрямую в сторону S4B, мы вручную изменяем в сторону Expressway.
Также для IMP&P требуется адресная схема вида Directory URI.
Далее на IM&P настраиваем:
Настройка Skype For Business
Создание пула 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
$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.2. Перейти в раздел Trusted Root Certification Authorities.
3.3. Убедиться, что сертификат корневого УЦ, выдавшего сертификат на серверы Cisco находится в данном разделе.
3.4. В случае отсутствия, импортировать недостающий корневой сертификат.
Настройки политик адресной книги рекомендуется сделать WebSearchOnly. Посмотреть текущие настройки:
Get-CsClientPolicy | ft Identity,AddressBookAvailability
Задать настройки:
Set-CsClientPolicy Global –AddressBookAvailability WebSearchOnly
4.2. Настройки поддержки шифрования медиа трафика.
Настройки шифрования медиа трафика рекомендуется сделать SupportEncryption. Посмотреть текущие настройки:
Get-CsMediaConfiguration | ft Identity,EncryptionLevel
Задать настройки:
Set-CsMediaConfiguration global -EncryptionLevel SupportEncryption
Подготовить списки 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 тоже.
Статья довольно сырая в плане оформления, за что прошу простить. По мере наличия времени и желания буду приводить её в более привлекательный вид.
ссылка на оригинал статьи https://habr.com/ru/post/652135/
Добавить комментарий