W środowisku produkcyjnym po wdrożeniu Lync Server 2013 pojawił się problem z dołączeniem się do konferencji z klienta Lync 2013 w systemie Windows 8. Problem “Cannot join the meeting due to user permissions” nie pojawia się w przypadku użytkowników łączących się z systemu Windows 7 z zainstalowanym klientem 2010 lub 2013. W momencie kiedy użytkownik Lync 2013 w systemie Windows 8 kliknie z poziomu Outlook 2013 “Join Lync Meeting” pojawia się okno błędu “Cannot join the meeting due to user permissions”.

Okazuje się, że problemem jest Internet Explorer 10 (ustawienia zabezpieczeń lub user-agent), który powoduje ten błąd – mam nadzieję, że wkrótce pojawi się hotfix i nie będzie konieczne stosowanie obejścia problemu (które ma swoje wady). Jest również workaround Microsoftu, który nie działa w moim przypadku:

Issue:

If a user has disabled both ActiveX Controls and native XMLHTTP support in Windows Internet Explorer Internet browser settings, the user will not be able to join a meeting if Internet Explorer is selected as the default browser.

Workaround:

Enable either ActiveX Controls or “native XMLHTTP support” in Internet Explorer.

Po zastosowaniu proponowanego rozwiązania, czyli włączenie XMLHTTP i wszelkie zezwolenia dla ActiveX dalej nie działa – będę eskalował :D.

Diagnozowanie problemu uwzględniało w pierwszej kolejności sprawdzenie logów z klienta Lync 2013. Tutaj zmieniła się przede wszystkim lokalizacja pliku z logami. Poprzednio w Lync 2010 był to katalog %userprofile%\Tracing, natomiast w Lync 2013 jest to %userprofile%\AppData\Local\Microsoft\Office\15.0\Lync\Tracing.

W przypadku klienta Lync 2010 podłączającego się do konferencji (Join Lync Meeting) lub Lync 2013 w systemie Windows 7 user-agent wygląda następująco – pakiet dochodzący do serwera Lync Server 2013, na który serwer odpowiada 200 OK (warto zwrócić uwagę, że default browser to IE9):

TL_INFO(TF_PROTOCOL) [1]1168.08D0::12/13/2012-10:27:02.658.00000873 (WebInfrastructure,CRequestContext::WppTraceFlush:3185.idx(1183))[2147483655] $$begin_record

Direction: incoming
Message-Type: request
Instance-Id: FB00000180000007
Peer: 192.168.0.3:46607
Start-Line: GET /Meet/Default.aspx
Connection: Keep-Alive
Content-Length: 0
Accept: text/html, application/xhtml+xml, */*
Accept-Language: pl-PL
Host: meet.firma.pl
Referer: https://zion.firma.pl/lwa/webpages/LwaClient.aspx?reachLocale=pl-pl&sr=9,00&rnj=https://meet.firma.pl/piotr.pawlik/ABCDEFG
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Reverse-Via: HADES
X-Original-URL: /piotr.pawlik/ABCDEFG

W przypadku klienta Lync 2013, którego zainstalowano w systemie Windows 8 User-Agent prezentuje się inaczej:


Host: meet.firma.pl
User-Agent: Lync/15.0 (Windows 6.2/x64, x86)
X-Original-URL: /piotr.pawlik/ABCDEFG
$$end_record

Na co serwer odpowiada 403 Forbidden – można to złapać zarówno po stronie klienta, jak i serwera za pomocą OCSTracer i Snoopera dostępnego w ramach zestawu narzędzi diagnostycznych: http://www.microsoft.com/en-us/download/details.aspx?id=35453.

Odpowiedź z serwera:

Start-Line: 403 Forbidden

Cache-Control: private
Content-Type: text/html
Server: Microsoft-IIS/7.5
X-MS-Server-Fqdn: lync.firma.pl
X-Powered-By: ASP.NET
X-Content-Type-Options: nosniff
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>
<html xmlns=”http://www.w3.org/1999/xhtml”>
<head>
<meta http-equiv=”Content-Type” content=”text/html; charset=iso-8859-1″/>
<title>403 – Forbidden: Access is denied.</title>
<style type=”text/css”>

Jakie jest obejście problemu?

Trzeba zmienić default web browser na inną niż Internet Explorer 10. W systemie Windows 8 przechodzimy do Control Panel\All Control Panel Items\Default Programs\Set Default Programs. Ustawiamy jako default na przykład Google Chrome. Po utworzeniu spotkania w Outlooku wszystko zaczyna działać, serwer zwraca 200 OK :).

Wady tego tymczasowego rozwiązania:

  • będzie wymagane Ctrl-C + V linków, które wymagają wykorzystania Internet Explorer, przykładowo SharePoint, CRM, itp.
  • w większości środowisk zmiana przeglądarki (instalacja) nie wchodzi w grę, więc pozostaje poniższe stwierdzenie.
Pozostaje zaczekać na hotfix lub doprecyzowanie przez Microsoft tego zalecenia “ActiveX Controls or native XMLHTTP support” http://technet.microsoft.com/en-us/library/jj205120.aspx#Conferencing.