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 в пределах компьютера. Анализ сетевой активности на внешнем шлюзе подтверждает, что не происходит соединений со внешним миром с участием данных портов.
Рубрика | Unified Communications |
---|---|
Метки | lync server, office communications server, ocs, pki, public key infrastructure, active directory certificate services, службы сертификатов, устранение ошибок |
Опубликовано | 2012-01-16, 3:00; обновлено 2012-03-29, 16:55 |
Комментарии | 12 комментариев » | Лента комментариев RSS |
Ссылки | Постоянная ссылка | Обратная ссылка |
12 комментариев
Спасибо, познавательно.
Про StartSSL, да, он есть только на некоторых клиентских системах, в том числе поэтому не подходит для организации федераций.
Про StartSSL.
Вот накопал KB931125, из нее следует, что сертификат CA StartSSL устанавливается вместе с обновлениями даже на стрые ОС типа XP, на которых его изначально не было.
Изначально присутствует в Win7/Server2008R2.
Для федерации с дугими Lync-ами вполне пригоден (в том числе проходит тест Remote Connectivity Analyzer), а вот OCS, поставленый на Win2003 и не обновляемый, вполне может и не доверять.
Если подключенный (по WiFi) во внутреннюю сеть предприятия Lync Mobile не работает, но работает из внешней сети, то происходит это вероятнее всего потому, что внутренние службы Lync Server используют SSL-сертификаты, выпущенные корневым CA предприятия. Чтобы Lync Mobile начал подключаться из внутренней сети, достаточно сотрудникам разослать e-mail с сертификатом корпоративного CA и инструкцией по его установке.
Есть другой, более элегантный способ:
НЕ создаем запись lyncdiscoverinternal
Даем клиентам из WiFi сети доступ к lyncdiscover на reverse proxy, где у нас стоит публичный сертификат.
Да, вполне элегантно! Только нужно учитывать, что и все остальные адреса (edge, reverse proxy) должны разрешаться на наружные интерфейсы (что проблема для split brain DNS), и через них пойдёт трафик пользователей. А не непрямую на front-end, что приятно.
A Edge тут причем?
Только lyncdisсover и внешнее имя веб-сервера должны указавать на внешнее имя reverse Proxy.
Другие клиенты, кроме мобильных, lyncdiscover не используют.
бррр… не на внешнее имя, а на IP для которого настроено правило публикации Lync FE 443-> 4443 :))
Кстати, проверил, мобильный клиент действительно использует Edge чуть менее, чем никак.
Видимо потому он так куц на функционал, что SIP-а в нем нёт в принципе…
Игорь, добрый день!
А можете рассказать немного подробней про StartSSL? Есть ли там возможность создавать SAN-сертификаты для Lync Edge? Действительно ли они бесплатные? И для чего еще вы их используете?
Привет. StartSSL бесплатно SAN не дают. Если нужен именно SAN, то я бы не рекомендовал StartSSL, так как пусть даже платный сертификат от этого CA признаётся не всеми клиентами, в отличае от, например, Comodo.
Для чего использую — Lync Edge, Lync Web, Exchange OWS, Remote Desktop Gateway, SSTP VPN…
Игорь, а как вы используете обычный single-name сертификат на Lync Edge? Там же должен быть SAN сертификат…
1. Поддержка StartSSL сертификатов на WP7 по сведениям из StartCom должна появится, только это тянется непонятно сколько, как они указали M$ должны сделать соответвующий патч, но почему не делают сведений нет. Со стороны StartCom, как они сообщают, всё сделано.
2. Сертификат не обязательно должен быть один со всеми SAN. Можно сделать 3 сертификата для соответсвующих «сервисов» и привязать каждый из них отдельно. Правда делать это лучше из повершела.