Lync 2010 Mobility

2012-01-16, 03:00 / Argon

В данной заметке я расскажу, с какими интересными особенностями мне пришлось встретиться при неспешном развертывании Lync Mobility в своей тестовой среде.

Использование сторонних SSL-сертификатов

Выполнив все шаги по развертыванию Lync Mobility, которые описаны в неприлично подробном официальном руководстве Microsoft Lync Server 2010 Mobility Guide, пришло время проверить работоспособность системы.

Клиент Lync 2010 на Windows Phone 7.5 при попытке подключении к моей тестовой среде выдавал следующее сообщение:

Unable to sign in.

Can't connect to the server. It might be unavailable. Also please check your network connection, sign-in address, and server addresses.

Не самое информативное сообщение, надо сказать. Хорошо, что в Lync Mobile есть возможность посмотреть журнал процесса подключения, для этого нужно

  • в Settings включить Diagnostic Logging
  • выполнить попытку подключения
  • выслать лог к себе на почту

Реализация последнего действия дважды удивляет: кнопка send diagnostic logs находится на экране About, а сам лог зашивается в картинку, которую нужно отправить себе на почту в качестве вложения. Вот такие костыли, вот такая консьюмеризация ;)

Из полученного лога можно понять следующие важные вещи…

Lync Mobile сначала попробовал постучаться по внутренним именам autodiscover, потерпел неудачу и понял, что находится снаружи:

Info : 499526106 : ConfigurationResolver : Internal autodiscovery requests failed. Trying external.

Получил ответ от autodiscover по протоколу HTTP:

Info : 499526106 : DiscoverySession : Uri for request ExtDisc_http is http://lyncdiscover.lab.argon.pro/?sipuri=nospam@lab.argon.pro.

Info : 440722650 : HttpRequestPump : Completed request ExtDisc_http.

Autodiscover сделал перенаправление на опубликованный по HTTPS Lync Web Services, и клиент пошел по этому пути:

Info : 499526106 : ConfigurationResolver : Redirect to https://lws.lab.argon.pro:18801/Autodiscover/AutodiscoverService.svc/root?sipuri=nospam@lab.argon.pro requires a trust decision.

Info : 499526106 : TrustManager : Trust of https://lws.lab.argon.pro:18801/Autodiscover/AutodiscoverService.svc/root?sipuri=nospam@lab.argon.pro for Autodiscovery is inherited through lab.argon.pro.

TrustManager : Redirection to https://lws.lab.argon.pro:18801/Autodiscover/AutodiscoverService.svc/root?sipuri=nospam@lab.argon.pro is trusted for Autodiscovery.

Info : 499526106 : ConfigurationResolver : Redirecting discovery query for nospam@lab.argon.pro to https://lws.lab.argon.pro:18801/Autodiscover/AutodiscoverService.svc/root?sipuri=nospam@lab.argon.pro.

Info : 499526106 : DiscoverySession : Uri for request RedirectDisc is https://lws.lab.argon.pro:18801/Autodiscover/AutodiscoverService.svc/root?sipuri=nospam@lab.argon.pro.

Info : 499526106 : ConfigurationResolver : Sending unauthenticated discovery request for nospam@lab.argon.pro to https://lws.lab.argon.pro:18801/Autodiscover/AutodiscoverService.svc/root?sipuri=nospam@lab.argon.pro.

И здесь случилась непонятная сетевая ошибка:

Warning : 440722650 : HttpRequestPump : Got a WebException while reading the response for RedirectDisc.

Error : 440722650 : HttpRequestPump : Request RedirectDisc failed due to an unidentified network error.

Error : 440722650 : HttpRequestPump : Calling back RedirectDisc with error ConnectionError [Error, Transport, TransportFramework].

Info : 499526106 : RequestRetryQueue : RedirectDisc ConnectionError [Error, Transport, TransportFramework] retry=True

После нескольких повторных попыток клиент сдался:

Info : 499526106 : InternalExternalSelector : Checking whether to switch from EXTERNAL because of ConnectionError [Error, Transport, TransportFramework]

Info : 499526106 : InternalExternalSelector : Not signed in

Error : 499526106 : ConfigurationResolver : Autodiscovery for nospam@lab.argon.pro failed with status DiscoveryFailedPastRoot [Error, Application, Discovery].

Если из браузера пройти по пути, которую Lync Mobile получает в качестве редиректа:

https://lws.lab.argon.pro:18801/Autodiscover/AutodiscoverService.svc/root?sipuri=nospam@lab.argon.pro

то мы получим ответ сервера, содержащий служебную информацию для Lync Mobile. К счастью, мне уже приходилось развертывать Lync Mobility, и сравнение ответа сервера между работающей и исследуемой средой не выявило проблем. Однако, моя тестовая среда отличалась SSL-сертификатами.

Я использовал бесплатные публичные сертификаты от StartSSL. Данному CA доверяют многие: современные браузеры, клиент Lync на Windows, без проблем работает федерация между моей средой, Microsoft и его партнёрами, проходит тест в Remote Connectivity Analyzer. Но данный CA неспроста отсутствует в списке рекомендуемых поставщиков SSL-сертификатов для Microsoft Unified Communications.

Именно отсутствием доверия к CA StartSSL объясняется «неизвестная сетевая ошибка» в журнале подключения Lync Mobile.

Не беда, Windows Phone 7 позволяет устанавливать свои сертификаты в хранилище доверенных корневых CA. Установка доверенных корневых CA делается следующим user-friendly способом (сравнимым по элегантности с получением логов):

  • сохранить в формате .cer сертификат Root CA (в моём случае StartCom Certification Authority)
  • отправить сертификат к себе на телефон по электропочте в качестве вложения
  • получить на телефоне письмо, открыть вложение, установить сертификат

После проделанных действий подключение мобильного клиента Lync 2010 к моей тестовой среде заработало как следует.

Из данного случая можно сделать следующие выводы:

  • В отличие от Windows клиента, мобильный клиент не сообщает об ошибках доверия к сертификату SSL.
  • На Windows Phone 7 имеется возможность установить произвольный сертификат корневого CA.
  • Если подключенный (по WiFi) во внутреннюю сеть предприятия Lync Mobile не работает, но работает из внешней сети, то происходит это вероятнее всего потому, что внутренние службы Lync Server используют SSL-сертификаты, выпущенные корневым CA предприятия. Чтобы Lync Mobile начал подключаться из внутренней сети, достаточно сотрудникам разослать e-mail с сертификатом корпоративного CA и инструкцией по его установке.

О том, как избежать установки SSL-сертификатов на мобильные клиенты при подключении как из внешней, так и из внутренней сети, читайте мою заметку Доступ к Lync Mobility из внутренних сетей WiFi.

Назначение портов MCX

В документации к развертыванию Lync Mobility есть интересная часть, а именно конфигурирование дополнительных портов следующими командами:

Set-CsWebServer –Identity FQDN –McxSipPrimaryListeningPort 5086
Set-CsWebServer –Identity FQDN –McxSipExternalListeningPort 5087

В интернетах я встречал много вопросов и предположений, зачем они нужны, нужно ли их открывать между front end и edge, либо же на reverse proxy или на внешнем интерфейсе edge…

Исследование данного вопроса показало:

C:\Users\admin>netstat -ano |findstr ":5087"
Proto Local Address Foreign Address State
TCP 0.0.0.0:5087 0.0.0.0:0 LISTENING 6312
TCP 10.18.1.131:5087 10.18.1.131:52038 ESTABLISHED 6312
TCP 10.18.1.131:52038 10.18.1.131:5087 ESTABLISHED 2876
C:\Users\admin>tasklist |findstr "6312 2876"
Image Name PID Session Name Session# Mem Usage
w3wp.exe 6312 Services 0 155 420 K
RTCSrv.exe 2876 Services 0 31 308 K

Из чего можно сделать вывод, что данные порты используются для взаимодействия служб Lync Server в пределах компьютера. Анализ сетевой активности на внешнем шлюзе подтверждает, что не происходит соединений со внешним миром с участием данных портов.



12 комментариев

iadmin
# Комментарий от 2012-01-16, 12:06

Спасибо, познавательно.
Про StartSSL, да, он есть только на некоторых клиентских системах, в том числе поэтому не подходит для организации федераций.

Argon
# Комментарий от 2012-01-16, 20:08

Про StartSSL.

Вот накопал KB931125, из нее следует, что сертификат CA StartSSL устанавливается вместе с обновлениями даже на стрые ОС типа XP, на которых его изначально не было.

Изначально присутствует в Win7/Server2008R2.

Для федерации с дугими Lync-ами вполне пригоден (в том числе проходит тест Remote Connectivity Analyzer), а вот OCS, поставленый на Win2003 и не обновляемый, вполне может и не доверять.

Alexander Donin
# Комментарий от 2012-01-17, 13:47

Если подключенный (по WiFi) во внутреннюю сеть предприятия Lync Mobile не работает, но работает из внешней сети, то происходит это вероятнее всего потому, что внутренние службы Lync Server используют SSL-сертификаты, выпущенные корневым CA предприятия. Чтобы Lync Mobile начал подключаться из внутренней сети, достаточно сотрудникам разослать e-mail с сертификатом корпоративного CA и инструкцией по его установке.

Есть другой, более элегантный способ:
НЕ создаем запись lyncdiscoverinternal
Даем клиентам из WiFi сети доступ к lyncdiscover на reverse proxy, где у нас стоит публичный сертификат.

Argon
# Комментарий от 2012-01-17, 19:22

Да, вполне элегантно! Только нужно учитывать, что и все остальные адреса (edge, reverse proxy) должны разрешаться на наружные интерфейсы (что проблема для split brain DNS), и через них пойдёт трафик пользователей. А не непрямую на front-end, что приятно.

Alexander Donin
# Комментарий от 2012-01-17, 20:30

A Edge тут причем?

Только lyncdisсover и внешнее имя веб-сервера должны указавать на внешнее имя reverse Proxy.

Другие клиенты, кроме мобильных, lyncdiscover не используют.

Alexander Donin
# Комментарий от 2012-01-17, 20:33

бррр… не на внешнее имя, а на IP для которого настроено правило публикации Lync FE 443-> 4443 :))

Argon
# Комментарий от 2012-01-17, 21:53

Кстати, проверил, мобильный клиент действительно использует Edge чуть менее, чем никак.

Видимо потому он так куц на функционал, что SIP-а в нем нёт в принципе…

Evgeniy Protopopov
# Комментарий от 2012-02-02, 19:06

Игорь, добрый день!
А можете рассказать немного подробней про StartSSL? Есть ли там возможность создавать SAN-сертификаты для Lync Edge? Действительно ли они бесплатные? И для чего еще вы их используете?

Argon
# Комментарий от 2012-02-09, 17:11

Привет. StartSSL бесплатно SAN не дают. Если нужен именно SAN, то я бы не рекомендовал StartSSL, так как пусть даже платный сертификат от этого CA признаётся не всеми клиентами, в отличае от, например, Comodo.

Для чего использую — Lync Edge, Lync Web, Exchange OWS, Remote Desktop Gateway, SSTP VPN…

Evgeniy Protopopov
# Комментарий от 2012-02-14, 18:36

Игорь, а как вы используете обычный single-name сертификат на Lync Edge? Там же должен быть SAN сертификат…

Argon
# Комментарий от 2012-02-14, 19:01

У меня даже есть статья про это.

Zuz666
# Комментарий от 2012-03-11, 22:09

1. Поддержка StartSSL сертификатов на WP7 по сведениям из StartCom должна появится, только это тянется непонятно сколько, как они указали M$ должны сделать соответвующий патч, но почему не делают сведений нет. Со стороны StartCom, как они сообщают, всё сделано.
2. Сертификат не обязательно должен быть один со всеми SAN. Можно сделать 3 сертификата для соответсвующих «сервисов» и привязать каждый из них отдельно. Правда делать это лучше из повершела.

Добавить комментарий