Клиент Windows Phone Lync 2013 года - Не могущий войти в систему. Запрос перестал работать с WININET errorCode (UcwaAutoDiscoveryRequest)
Сводка:
Windows Phone клиент Lync 2013 года, не могущий входить в Lync Server 2013. Но другая iOS устройства, Android, настольный клиент Windows весь штраф.
Подробно:
- У нас есть клиент с развернутым Lync Server 2013.
- Мы используем полную функциональность Enterprise Voice с мобильностью.
- У нас есть Прокси Реверса R2 ARR IIS Сервера 2012 года на месте.
- Нам развернули Lync Servr 2013 на экземплярах Windows Server 2012 R2.
- Внешний SSL купил у GeoTrust.
Существует Windows Phone влияния проблемы мобильности Lync 2 013 пользователей клиента. Пользователи WP клиентского приложения 4. X Lync 2013 года и больше не могут регистрироваться с ошибкой:
ОШИБОЧНЫЕ УТИЛИТЫ, CHttpConnection.cpp/1117:Request, перестали работать с WININET errorCode (UcwaAutoDiscoveryRequest):-2146697211
Когда мы завершаем Анализатор Возможности соединения Lync через https://testconnectivity.microsoft.com/, мы становимся полностью зелеными, и все работает.
Любая справка в правильном направлении ценилась бы.
Единственной вещью, которую я должен все же попробовать, является экспорт SSL от пула FE, и вручную установите на клиенте WP.
(извините за несвоевременный ответ)
После устранения неполадок мы обнаружили, что следующие два пункта внесли свой вклад в решение проблемы. Когда оба этих пункта были решены, Windows Phone и Android Phone Lync 2013 клиент смог войти в систему.
Решили проблему 1: SSL сертификат
.
SSL сертификат, который использовался на Reverse Proxy, был подстановочным сертификатом с шифрованием SHA1. Недавно еще одна память IT команды клиентов изменила SSL на более новый сертификат с шифрованием SHA256. Поскольку SSL использовался для веб-служб, в дополнение к Lync, об этом изменении мне не сообщили. Сам SSL был отозван и, таким образом, не позволял выполнять аутентификацию. Обновление SSL с помощью правильного и действительного нового шаблона частично решило проблему.
Решена проблема 2: Ошибка конфигурации порта
.
Хотя это напрямую не влияет на удаленное подключение, так как пользователи аутентифицируются по HTTPS/443, порт HTTP/80 был перенаправлен с обратного прокси. Мы обнаружили, что это также было сделано без надлежащего управления изменениями через простую пользовательскую ошибку.
SSL был главным виновником, поэтому всегда проверяйте правильность и действительность SSL-сертификатов!