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