Force LWA

Lync ist eine leistungsfähige Plattform für Meetings und funktioniert in den meisten Fällen problemlos mit unterschiedlichen Clients. Selbst externe Clients, die keine Lync-Clientinstallation haben, können über Lync Web App an einer Konferenz mit wenigen Einschränkungen teilnehmen. Er sieht Präsenz, kann chatten und natürlich die PowerPoint betrachten. Wer ein passendes AddIn installiert, kann im Browser sogar Audio und Video verwenden.

Meeting Join geht nicht, wenn...

Es gibt aber einen Fall, bei dem das schöne Modell nicht funktioniert:

  • Die Konferenz wird auf Lync gehostet
  • Diese Lync Plattform hat keinen Federation-Eintrag
  • Der Teilnehmer ist "extern", d.h. kein Lync User auf der Konferenzplattform
  • Der Teilnehmer hat einen Lync Client installiert.

Das Problem ist Microsoft schon länger bekannt, weil anscheinend auf vielen Endgeräten über Office auch der Lync Client installiert aber nie genutzt wird. Der Client ist also "nicht konfiguriert" und vielleicht hat der Benutzer auch gar kein Lync Konto.

Der Lync Web App-Code prüft auf dem Client, ob der Communicator installiert ist und wenn dies der Fall ist, dann leitet der Browser die Einladung an den Lync Communicator weiter. Der kann aber natürlich nichts machen, wenn er keinen Lync Server zur Anmeldung hat. Wer in diesem Fall den Anmeldeversuch mit dem Lync Client abbricht, landet dann doch wieder in Lync Web App. Dies ist aber nur der Fall, wenn Sie einen halbwegs aktuellen Client (Version 15.0.4623.1001 oder neuer) haben.

Allerdings ist dies keine "Lösung" für den Fall, wenn die Firma, welche die Lync Konferenz anbietet, keinen Federation-Record veröffentlicht hat. Das ist durchaus möglich, wenn eine Firma nur mit benannten Partnern eine Federation eingeht und diese explizit in der Konfiguration hinterlegt.

Seit April 2015 geht aber Anonym auch noch besser, wenn nämlich der Meeting Provider zumindest die DNS-Einträge und Remote Access erlaubt hat

Fragen Sie mich bitte nicht, warum Microsoft so einen Fallback nicht im vollen Client eingebaut hat, da es ohne den Fallback immer noch Clients in internen Netzwerken gibt, die nicht an Meetings anderer Firmen oder Office 365 per "Klick" teilnehmen können. Durch eine manuelle Eingabe einer angepassten URL aber doch.

Alternative Anmeldungen anzeigen

Wer dem Anwender die Wahl geben möchte, kann diese auf der Webseite auch einstellen.

set-CsWebServiceConfiguration `
   -ShowAlternateJoinOptionsExpanded:$true

Office 365 zeigt die mit Skype für Business z. b. schon an:

LWA als Default

Nun wissen Sie sicher, dass ein Meeting-Teilnehmer durch eine kleine Ergänzung der URL um ein "?sl=1" die automatische Auswertung umgehen kann.

https://<SimpleURL-meet>/<Meetingpath>?sl=1

Damit wird der Client immer zum Lync Web App geleitet, auch wenn lokal ein vollwertiger Communicator installiert ist. Allerdings kann man als Lync Administrator das nicht einfache als "Default" hinterlegen. Aber da es sich beim ersten Zugriff einfach um einen HTTP-Zugriff handelt, kann man diesen durchaus abfangen und umleiten.

Dies ist insbesondere interessant für Firmen, die keine Federation anbieten und daher die Teilnehmer mit einer eigenen Lync-Installation den DNS-Eintrag "_sipfederationtls._tcp.<sipdomain>" des Konferenzbetreibers nicht finden können. Mir fallen drei Optionen ein, alle Clients per Default auf diese URL zu verweisen

  • Eigener Websever
    Sie können mit einem eigenen Namen die MeetingURL einfach zu einem anderen Server, der die Anfrage annimmt und um das "?sl=1" ergänzt als Redirect an den Client sendet. Entsprechend
  • Reverse Proxy
    Die meisten Firmen werden ihren "LyncWeb"-Zugang aus dem Internet nicht direkt per NAT erreichbar machen, sondern über einen ReverseProxy veröffentlichen. Die meisten dieses Systeme können URL erkennen und umschreiben. Entsprechend könnte dieser ReverseProxy den Request auf dem Weg vom Client zum Lync WebServer um ein "?sl=1" ergänzen. Der Client würde davon überhaupt nichts sehen und der Lync Server schon immer denken, dass der Client die URL angepasst hat
  • Lync WebServer
    Die dritte Option besteht darin, die Webseite des IIS selbst zu verändern. Lync installiert selbst schon die URLRewrite-Erweiterung und macht intensiv gebrauch davon. Hier eine Regel zum umschreiben oder Redirect ist schnell gemacht. Allerdings wird ein "Bootstrapper" die Regel wieder rauswerfen. Achten Sie daher darauf

Auf Lync mit URLRewrite den SL=1 addieren

Wenn man keinen Zugriff auf den Proxy hat und eine eigene Webseite mangels Zertifikat oder IP-Adresse nicht zur Verfügung steht, dann bleibt nur das umschreiben auf dem Lync Server. Hier hat man die Wahl, ob man die URL "verändert" ehe Sie an weitere Prozesse des IIS geht oder ob die Anfrage mit einem "Redirect" und der passenden URL an den Client gegeben wird. Ich habe einige Zeit mit dem Rewrite versucht eine Lösung zu schaffen aber bin letztlich beim Redirect gelandet. Der lässt sich zudem wunderbar auch dem Client auch beobachten.

Ganz generell sollten Sie bei solchen Aktionen vorher in einem Testfeld üben und gut dokumentieren, was Sie getan haben. Ein "Zurück auf Anfang" ist durch den Aufruf des Lync Bootstrappers aber schnell wieder möglich. Sie sollten auch wissen, wie sie mit FREB die Funktion überprüfen können.

Nach der HTTPS-Redirect und vor der Meet Rule kann man eine neue eingehende Regel einrichten.

Hier die Parameter im Stenogrammstiel

New Inbound Rule
Name: Add Missing SL=1
MatchURL:
Requested URL: MatchPattern
using: Regex
Patterns: (.*)
IgnoreCase
Conditions
MatchAll
"{REQUEST_FILENAME} is not a file NA 
"{HTTP_HOST}" matches the Pattern "meet.msxfaq.net"
"{QuERY_STRING} Does not match "sl=1"
"{QuERY_STRING} Does not match "Full"
"{PATH_INFO} does not match "/meet/.*"
Server Variables: none
Action
ActionType: Redirect
RedirectURL: "https://{HTTP_HOST}{PATH_INFO}?sl=1"
( ) Append query String
RedirectType: 307 Temporary

So sieht das dann im Bild aus

 

Jede Anfrange an die Meet-URL ohne angehängtes "SL=1" wird durch einen Redirect so verändert, dass nun alle Clients immer LyncWebApp nutzen

Weitere Links