none
Мобильный Lync снаружи RRS feed

  • Вопрос

  • Есть инфраструктура Lync 2013 после миграции с Lync 2010(на 2010 mobility так и не захотел работать)

    Поднят FE и Edge.

    Обычные линк клиенты работают вполне неплохо с внешки.

    Мобильные работают изнутри, подключаются правда только если имя пользователя ввести в "дополнительных настройках"

    А вот снаружи никак. Что делать если честно уже не знаю инструкция много почитал, но все настроено вроде нормально. в логах клиента выдает

    09-03 12:57:44.060 18392 18392 E LYNC    : ERROR TRANSPORT .\chttpconnection.cpp/225:CHttpConnection exception: java.net.UnknownHostException

    и еще вот такую штуку 

    09-03 12:57:44.065 18392 18392 I LYNC    : INFO TRANSPORT .\chttprequestprocessor.cpp/201:Request  resulted in E_ConnectionError (E2-2-1). The retry counter is: 1

    3 сентября 2013 г. 10:00

Ответы

  • Проблема решена. 

    1. в правиле TMG не было указано что нужно заменять исходный заголовок.

    2. во внешнем ДНС не было ни слова о внешнем вэб-имени Lync.

    3. после добавления внешнего имени проблема была в том что его изменили и оно отличалось от того что было изначально в настройках топологии внешнего вэб сервиса для Lync. После того как поменяли на старое значение и указали его во внешнем DNS все заработало как снаружи так и изнутри.

    В настоящий момент не работают клиенты Windows Phone 8(Andoid и IOS работают) снаружи и не работает поиск по адресной книге. 

    • Помечено в качестве ответа rigmm 17 сентября 2013 г. 5:44
    17 сентября 2013 г. 5:44

Все ответы

  • День добрый.

    1. Для подключения внешних пользователей существует лист проверки. Проверьте настройки и выполненные этапы.

    Deployment Checklist for External User Access

    2. Протестируйте подключение используя Lync Server Remote Connectivity Analyzer https://www.testocsconnectivity.com


    MCITP, PSLP. Знание - не уменьшает нашей глупости.

    4 сентября 2013 г. 8:30
    Модератор
  • аналайзер выдает вот такую ошибку, что это означает?

    "Не удалось войти. Ошибка: Сообщение об ошибке: The certificate chain was issued by an authority that is not trusted.
    Тип ошибки: TlsFailureException."

    В каком месте цепочка то недоверенная? Сертификат Root CA есть в доверенных корневых на Edge, FE и TMG

    4 сентября 2013 г. 9:13
  • Если у вас используется сертификат из локального центра сертификации, то установите галку (Пропустить доверие для SSL).

    Повторно проведите тест.


    MCITP, PSLP. Знание - не уменьшает нашей глупости.

    4 сентября 2013 г. 9:40
    Модератор
  • Возможно чуть дополню коллегу.

    • Пройдите тест мобильного доступа ещё при помощи http://go.microsoft.com/fwlink/?LinkId=277056
    • Сертификат какой используете на внешнем интерфейсе Edge? Выдан public ca?
    • На Edge сервере запустите. Приведите вывод команды.

    Get-CsCertificate| Select -ExpandProperty AlternativeNames 


    Roman Levchenko, MCITP, MCTS http://www.rlevchenko.com



    4 сентября 2013 г. 10:18
  • Если у вас используется сертификат из локального центра сертификации, то установите галку (Пропустить доверие для SSL).

    Повторно проведите тест.


    MCITP, PSLP. Знание - не уменьшает нашей глупости.

    Это тест с галочкой про доверие ssl я проводил. Сертификат из локального.
    4 сентября 2013 г. 12:23
  • Сертификат не может быть самоподписным.

    Какой результат, теста с галочкой?

    В мобильном клиенте включите логирование, отправте лог себе на почту. После опубликуйте ошибки подключения. 


    MCITP, PSLP. Знание - не уменьшает нашей глупости.

    4 сентября 2013 г. 13:24
    Модератор
  • Возможно чуть дополню коллегу.

    • Пройдите тест мобильного доступа ещё при помощи http://go.microsoft.com/fwlink/?LinkId=277056
    • Сертификат какой используете на внешнем интерфейсе Edge? Выдан public ca?
    • На Edge сервере запустите. Приведите вывод команды.

    Get-CsCertificate| Select -ExpandProperty AlternativeNames 


    Roman Levchenko, MCITP, MCTS http://www.rlevchenko.com



    1. Запустил тест выдает на внешке - Server discovery failed for secured external channel against https://lyncdiscover.domain.ru/

    На тмг увидел что правило отработало и на внутренний интерфейс FE переправило на 4443 порт

    2. Сертификат выдал на внешнем интерфейсе локальным CA что клиент принципе и говорит, но я его одобряю

    3. Вывод команды:

    sip.domain.ru

    av.domain.ru

    lyncdiscover.domain.ru

    conf.domain.ru

    sip.domain.ru

    av.domain.ru

    lyncdiscover.domain.ru

    conf.domain.ru

    sip.domain.ru

    av.domain.ru

    lyncdiscover.domain.ru

    conf.domain.ru

    Именно столько и в таком порядке

    4 сентября 2013 г. 13:30
  • http://technet.microsoft.com/en-us/library/gg398920.aspx

    • The certificate must be issued by an approved public CA that supports subject alternative name. For details, see Microsoft Knowledge Base article 929395, "Unified Communications Certificate Partners for Exchange Server and for Communications Server," at http://go.microsoft.com/fwlink/p/?linkId=202834.

    Почему не делаете публичный сертификат на внешнем интерфейсе? 



    Roman Levchenko, MCITP, MCTS http://www.rlevchenko.com

    4 сентября 2013 г. 18:28
  • http://technet.microsoft.com/en-us/library/gg398920.aspx

    • The certificate must be issued by an approved public CA that supports subject alternative name. For details, see Microsoft Knowledge Base article 929395, "Unified Communications Certificate Partners for Exchange Server and for Communications Server," at http://go.microsoft.com/fwlink/p/?linkId=202834.

    Почему не делаете публичный сертификат на внешнем интерфейсе? 



    Roman Levchenko, MCITP, MCTS http://www.rlevchenko.com

    Да как то в голову даже не приходило такое сделать при наличии своего локального CA. А в чем разница между сертификатом выданным через локальный CA(при условии доверенности Root CA во всех точках как то: FE, Edge, TMG и мобильное устройство) и сертификатом выданым public CA?
    5 сентября 2013 г. 4:01
  • Да как то в голову даже не приходило такое сделать при наличии своего локального CA. А в чем разница между сертификатом выданным через локальный CA(при условии доверенности Root CA во всех точках как то: FE, Edge, TMG и мобильное устройство) и сертификатом выданым public CA?

    1. Это требование Microsoft для организации правильной архитектуры

    2. https://lyncdiscover.domain.ru в браузере открывается?

    3. Каким образом внешний клиент будет проверять валидность Вашего сертификата? Доступа к вашему CA нет извне, как правило (из темы я не понял..публиковали ли вы CA или нет, но опять же этого делать не нужно), проверить , к примеру, CDP/AIA (Certificate revocation list distribution point/authority information access) параметры сертификата системе не удастся,  поэтому и проверку SSL у Вас он не проходит (цепочку помечает как недоверенную), а следовательно установить соединение через https не получается. Public CA он на то и публичный, чтобы не создавать себе лишних проблем при конфигурации внешних клиентов. Выданный сертификат любым партнером Microsoft , по умолчанию находится в списке доверенных, и все необходимые точки проверки сертификата на валидность доступны с любого устройства. Я бы порекомендовал приобретение публичного сертификата для всех внешних служб Lync. В вашем случае, нужен сертификат выданные для sip.domain.ru с дополнительными именами: sip.domain.ru, av.domain.ru, lyncdiscover.domain.ru, conf.domain.ru . Simple URL не публикуете? (учтите, что имя admin.domain.ru никогда не публикуется)


    Roman Levchenko, MCITP, MCTS http://www.rlevchenko.com

    5 сентября 2013 г. 5:12
  • 2.  https://lyncdiscover.domain.ru сертификат защищенный и валидный в браузере показвается. открывается пустая страница как на компьютере так и на .мобильном устройстве.

    3. CRL публикуются уже давно в связи с тем что в организации для VPN использует протокол SSTP. Так что все три параметра валидности 1. срок действия 2. отсутствие в CRL 3. Доверенный корневой центр - выполняются. 

    Я бы с удоволствием приобрел публичный сертификат, но боюсь не в нем проблема.

    5 сентября 2013 г. 6:00
  • Пустая страница не должна открываться. Должен быть запрос на сохранение файла с информацией для подключения. ничего такого не наблюдаете? IIS посмотрите на наличие каталогов Mcx, Autodiscovery, ucwa на внешнем сайте. Если проблема не наблюдается с самого начала, то попробуйте сделать iisreset /noforce и попробовать заново. 

    Roman Levchenko, MCITP, MCTS http://www.rlevchenko.com

    5 сентября 2013 г. 6:12
  • Пустая страница не должна открываться. Должен быть запрос на сохранение файла с информацией для подключения. ничего такого не наблюдаете? IIS посмотрите на наличие каталогов Mcx, Autodiscovery, ucwa на внешнем сайте. Если проблема не наблюдается с самого начала, то попробуйте сделать iisreset /noforce и попробовать заново. 

    Roman Levchenko, MCITP, MCTS http://www.rlevchenko.com

    На внешнем сайте Lync Server External Web Site есть все 3 каталога Mcx, Autodiscover, ucwa.

    И кстати вопрос по IIS - обычные то клиенты с внешки конектятся успешно, только мобильные не работают.

    • Изменено rigmm 5 сентября 2013 г. 8:03
    5 сентября 2013 г. 7:48
  • Вот теория по Lync Mobile Services. Как это было в Lync 2010. Deploying the Lync 2010 Mobility Service

    Намного интересней и не так просто, как в Lync 2013. :) Те кто проклацал все на Lync 2010, представляют себе, как это работает в Lync 2013.


    MCITP, PSLP. Знание - не уменьшает нашей глупости.

    5 сентября 2013 г. 9:20
    Модератор
  • Вот теория по Lync Mobile Services. Как это было в Lync 2010. Deploying the Lync 2010 Mobility Service

    Намного интересней и не так просто, как в Lync 2013. :) Те кто проклацал все на Lync 2010, представляют себе, как это работает в Lync 2013.


    MCITP, PSLP. Знание - не уменьшает нашей глупости.

    Теорию читал. Все то же самое что и в остальных мануалах
    5 сентября 2013 г. 11:45
  • Добился вот такой строчки при запросе lyncdiscover.domain.ru

    {"_links":{"self":{"href":"https://lync13.domain.ru/Autodiscover/AutodiscoverService.svc/root?originalDomain=domain.ru"},"user":{"href":"https://lync13.domain.ru/Autodiscover/AutodiscoverService.svc/root/oauth/user?originalDomain=domain.ru"},"xframe":{"href":"https://lync13.domain.ru/Autodiscover/XFrame/XFrame.html"}}}


    lync13 - имя FE сервера


    • Изменено rigmm 7 сентября 2013 г. 6:17
    7 сентября 2013 г. 6:17
  • Уважаемые специлисты помогите немного разобратся. каким образом мобильный клиент подключается к серверу, что ему для этого необходимо?

    Я насколько раньше думал есть адрес на внешнем DNS lyncdiscover.domain.ru - по этому адресу стучится мобильный клиент. Прокси(в моем случае TMG) пропускает этот запрос перенаправляя на сервер FE. FE говорит что необходимо связываться с Edge по адресу sip.domain.ru и все.

    НО судя по всему я ошибаюсь, подскажите как на самом деле все обстоит? Насколько я понимял по адресу Lyncdiscover.domain.ru мобильный клиент получает адрес Внешней вэб службы(указанной в построителе топологии). на что должен указывать этот адрес - на TMG(если да то по какому правило и куда пропускает трафик)? на Edge?

    12 сентября 2013 г. 11:23
  • Вы не единственные в данном вопросе. :)

    Understanding Lync Discover and It’s Problems

    Lync 2013 autodiscover


    MCITP, PSLP. Знание - не уменьшает нашей глупости.

    12 сентября 2013 г. 12:08
    Модератор
  • Проблема решена. 

    1. в правиле TMG не было указано что нужно заменять исходный заголовок.

    2. во внешнем ДНС не было ни слова о внешнем вэб-имени Lync.

    3. после добавления внешнего имени проблема была в том что его изменили и оно отличалось от того что было изначально в настройках топологии внешнего вэб сервиса для Lync. После того как поменяли на старое значение и указали его во внешнем DNS все заработало как снаружи так и изнутри.

    В настоящий момент не работают клиенты Windows Phone 8(Andoid и IOS работают) снаружи и не работает поиск по адресной книге. 

    • Помечено в качестве ответа rigmm 17 сентября 2013 г. 5:44
    17 сентября 2013 г. 5:44