Lync Mobile intern

Microsoft veröffentlicht sehr viele Infos, wie mittlerweile der neue Lync 2013 Client intern zu verwenden ist. Aber Microsoft hat auch klar dokumentiert, dass nur die Webseite "Lync External Web" die Mobility-Dienste anbietet und der Zugriff sowohl für interne als auch externe Clients über den Reverse Proxy gehen muss. Das macht auch Sinn, wenn die Clients tatsächlich mobil durch die Gegend laufen und dabei zwischen WIFI-Zonen und GSM wechseln. Der Reverse Proxy und ein Loadbalancer können dann über Cookies den Client immer wiedererkennen, auch wenn er mit unterschiedliche IP-Adresse ankommt.


Quelle: Technische Anforderungen für die Mobilität (http://technet.microsoft.com/de-de/library/hh690030.aspx)

Wäre das nicht der Fall, dann würde der Lync Server jedes mal den Client neu authentifizieren müssen aber vor allem wären die alten Sessions nicht abgebaut. Und das sind durchaus "Langlaufsessions". Wenn das dann mehrere hundert oder gar tausend Anwender tun, dann wird das ein echtes Problem für den Server. Und ich kann nicht sagen, wie klein eine Firma sein muss, dass man es tolerieren könnte. Ich würde es es einfach nicht machen, da es auch nicht unterstützt ist.

Mobil-Clients ohne Internet ?

Achtung: Diese Konfiguration wird so nirgends beschrieben und ist wohl nicht "supported".

Nun gibt es aber Umgebungen, in denen ein Internet Zugriff gar nicht möglich ist. Beispiele sind hier z.B. öffentliche Verwaltungen, Versicherungen, Gesundheitswesen, Energieversorgung, militärische oder andere sicherheitstechnische Anlagen. für das "Surfen" im Internet gibt es dort oft komplett getrennte Netze aber dass diese Netzwerke von "extern" erreichbar sind, ist eher selten oder gar nicht der Fall. Aber auch diese Umgebungen evaluieren und nutzen natürlich Lync z.B.: für interne Kommunikation, Konferenzen und als Telefonanlage. Externer Zugriff (ohne VPN) und Federation wird damit natürlich nicht möglich sein aber wer intern z.B. Wireless LAN anbietet, möchte zumindest über den Weg vielleicht mobile Endgeräte (Tablets und Telefone) nutzen. Der Zugang per WIFI kann ja entsprechend "sicher" gemacht werden.

Windows Phone 8 nur mit Einschränkungen
Push Benachrichtigungen erfordern hier eine GSM-Verbindung mit Lync Edge über Office 365. Android und IOS hingegen benötigen nicht mehr diesen Trigger für neue Verbindungen. Windows Phone 8 kann in dem folgend beschrieben (noch) nicht sinnvoll betrieben werden.

"privates" Internet

Nur weil das gesamte Firmennetzwerk nicht mit dem Internet verbunden werden darf oder kann, möchte man doch nicht auf die mobilen Clients verzichten. Vielleicht ist es auch nur ein "Testlab" oder ein Lync Pilot mit einem schnell installierten Standard Server ohne Edge und Reverse Proxy, in dem aber dennoch ein mobiler Client demonstriert werden soll. für diesen Sonderfall habe ich eine Variante ausgearbeitet, mit der auch ohne ReverseProxy, Edge und Firewall ein mobiler Client arbeiten kann.

Wie sie vielleicht wisse bietet nur die WebSite "Lync External Web" die Mobility-Dienste an. Diese läuft aber auf Port 4443 und wird damit vom Client bei einem HTTPS-Zugriff nicht genutzt. Auf der WebSite "Lync Internal Web" läuft zwar noch der Lyncdiscover-Service aber die Antwortdatei verweist den Client wieder auf die LyncWeb-URL.

Der Trick besteht nun darin diese externen URLs, die es auch weiterhin gibt, von intern erreichbar zu machen, ohne dass eine Firewall oder ein Reverse Proxy bemüht werden muss. Und das ist sogar recht einfach, denn eine Webseite kann durchaus auf mehreren Ports und IP-Adressen gebunden werden. Allerdings können "Lync External Web" und "Lync Internal Web" natürlich nicht beide auf dem gleichen Port laufen. Das geht aber, wenn der Server eine zweite IP-Adresse hat.

Es ist irrelevant, ob der Frontend nun eine Netzwerkkarte mit zwei IP-Adressen oder zwei Netzwerkkarten mit je einer IP-Adresse hat. Gerade bei virtuellen Umgebungen wird ja vielleicht schnell eine zweite Netzwerkkarte zum gleichen Netzwerk konfiguriert.

Das Vorgehen ist daher relativ einfach:

  • Automatische DNS-Registrierung auf der Netzwerkkarte abschalten
    Dies ist erforderlich, damit der Lync Server sich nicht auch noch mit der zweiten IP-Adresse im DNS registriert.
  • Lync Server statisch im DNS eintragen
    Tragen sie nun den FQDN des Lync Server statisch im DNS ein und verweisen den Namen auf die aktuelle IP-Adresse
  • Lync Topology und Gateway
    Per Default lauscht und nutzen auch die Lync-Dienste alle IP-Adressen des Servers. d.h. auch die Kommunikation z.B. zu einem TK-Gateway kann mit beiden Adressen erfolgen, wenn Sie auf dem TK-Gateway und Firewalls hier aber nur die primäre Adresse zugelassen haben, dann müssen Sie in der Lync Topologie nun die Adresse beim Pool und beim Mediation Server hinterlegen. Alternativ lassen Sie die zweite Adresse auf Gateways und Firewalls zu. Vergessen Sie nicht diese Einstellung zu speichern, die CMS-Replikation abzuwarten und dann das Lync Setup durchlaufen zu lassen (Bootstrapper)
  • Addieren einer zweiten IP-Adresse
    Binden Sie nun eine zweite IP-Adresse auf der Ethernet-Karte des Lync Servers. Das dürfte keinen Einfluss auf ihre Umgebung haben
  • IIS-Konfiguration WebSite "Lync External Web"
    Auf den Bindungen der WebSite "Lync External Web" addieren wir nun diese zweite IP-Adresse:443. Damit nutzt der IIS nun diese zweite Adresse nicht mehr für die WebSite "Lync Internal Web", die per Default auf "<any>:443" lauscht, sondern explizit für die WebSite "Lync External Web"
  • DNS für externe Webseiten
    Nun können Sie DNS dafür sorgen, dass die Client die Namen "lyncdiscover.<sipdomain>" und natürlich auch den Namen der externen Lync WebServices Adresse auf die zweite IP-Adresse auflösen, die idealerweise auch nur dafür genutzt wird.
    Alle anderen URLs bleiben weiterhin intern

Wenn sie eine Firewall, Reverse Proxy oder Loadblancer haben, der die Umsetzung 443->4443 nicht kann, dann kann ihnen der Trick übrigens auch helfen.

Ich kann nicht garantieren, dass diese Konfiguration permanent funktioniert oder mit dem nächsten Lync Update nicht wieder zunichte gemacht wird. Es ist sicher keine Lösung für größere Umgebungen und ist auch keine Microsoft Referenz Architektur. Support dürfte also fraglich sein. für einen Pilot oder Test mit einem Single Server kann dies erst eine temporäre Hilfe sein.

Loadbalancer ohne Internet

Wenn Sie später sowieso einen Lync Pool mit mehreren Servern nutzen, dann können Sie z.B. den vorgeschalteten Loadbalancer für die Umsetzung einer zweiten IP-Adresse:443 auf die WebSite "Lync External Web" auf Port 4443 nutzen.

So können Sie diese Konfiguration sogar für einen Lync Pool mit mehreren Servern auch sauber umsetzen, ohne dass sie eine "echte" Internetverbindung benötigen.

Audio/Video und fehlender Edge

Lync 2013 Mobile nutzt für sehr viele Dinge die Lync Mobility Webservices und UCWA aber doch nicht für alle Dienste. Da sind auf jeden Fall "Audio und Video" zu nennen. Audio und Video wird natürlich nicht in HTTP oder SIP-Paketen eingepackt sondern wie beim normalen Lync-Client bevorzugt per UDP direkt zwischen den Endpunkten übertragen. Dabei verhält sich ein Mobile Client nicht anders als ein Desktop Client und ermittelt zu erst seine eigenen Kandidaten (siehe ICE und Kandidaten), die er dann an die Gegenstelle übermittelt und versucht dann mit den Kandidaten der Gegenstelle eine Verbindung aufzubauen. Präferiert ist dabei natürlich eine direkte Verbindung per UDP aber im Notfall tut es natürlich auch der Umweg über den Edge Server, was für externe Verbindungen natürlich zwingend erforderlich ist.

Sollte in der Topologie aber kein Edge Server vorhanden sein, dann bekommt der Client natürlich keine TURN-Kandidaten und kann dieses auch nicht anbieten. Aber das stört den Client nicht. Es gibt kein Fehler und keine Warnung. Damit Audio/Video funktioniert muss ja nur ein Päärchen in jede Richtung gefunden werden. In der hier beschriebenen Konfiguration als "internes System" wird das dann eben der direkte Weg zwischen den Endpunkten sein. Da ist es für den Lync Client auch irrelevant, dass die Webservices über "lyncdiscover" und die externen Lync Services gehen.

ExposedWebURL mit Set-MCXConfiguration

Erst viel später habe ich gesehen, dass auch das Commandlet "Set-MCXConfiguration" einen Parameter "ExposedWebURL" kennt. In der Anleitung steht dazu allerdings recht dünn nur:

Gibt an, ob die vom AutoErmittlungsdienst verwendete URL Benutzern sowohl außerhalb als auch innerhalb der Firewall der Organisation (External) oder nur Benutzern innerhalb der Firewall (Internal) zur Verfügung steht. Zulässige Werte: "Internal" oder "External". Der Standardwert ist External

Indicates whether the URL used by the Autodiscovery Service is accessible to Users both inside and outside the organization firewall (External) or only accessible to Users inside the firewall (Internal). Allowed values are: Internal or External. The default value is External

Leider bin ich einige Zeit nicht dazu gekommen, eine entsprechende Konfiguration vor mir zu haben und die Wirkung dieser Einstellungen zu verifizieren. Aber Andre Müller (GAB Enterprise IT Solutions GmbH) hat das für mich nachgeholt und bestätigt. Wenn die eigene Lync/Skype for Business Umgebung nicht mit dem Internet verbunden ist, dann sollten Sie diesen Wert auf "Internal" setzen.

Set-MCXConfiguration -ExposedWebURl "internal"

Wenn der Client dann nach "LyncDiscoverinternal.<sipdomain>" fragt, bekommt er statt der externen URL die interne URL zurück.

Push-Benachrichtigungen

Nicht alle mobile Client nutzen HTTPS und hängende Verbindungen.

  • Lync2010 (IOS)
    Der Lync 2010 Client auf Apple IOS braucht z.B. Pushnachrichten, die der Client über den Port 5223 direkt zu Apple bekommt. Das funktioniert also nur, wenn die Clients diesen Port ausgehend zu Apple nutzen können.
  • Lync 20130 (IOS)
    Hier sendet der Lync Server die Meldungen per SIP über den Edge Server zum Datacenter. Ohne Edge funktioniert dies nicht.
  • Lync 20130 auf Windows Phone
    Hier sendet der Lync Server die Meldungen per SIP über den Edge Server zum Datacenter. Ohne Edge funktioniert dies nicht.

Weitere Details finden Sie hier:

Einschränkungen

Ich habe diese Lösung bei einem Piloten bislang eingesetzt und während der ersten Tests sind keine Einschränkungen sichtbar geworden. Sie sollten aber wissen, dass speziell die Konzeption mit einer zweiten IP-Adresse auf dem Frondend keine von Microsoft getestete Umgebung darstellt und zukünftige Updates darauf vermutlich keine Rücksicht nehmen. für einen Dauerbetrieb würde ich davon abraten.

Anders sieht es natürlich aus, wenn Sie einen Loadbalancer oder ReverseProxy davor stellen, der problemlos auf die Namen Lyncdiscover und die externe LyncWeb-Adresse lauschen und die Anfragen an den Frontend weiter geben kann. Hier hätte ich weniger Sorgen, dass diese Konfiguration ein Problem hat.

Weitere Links