Lync Director

Diese Seite habe ich explizit denen gewidmet, die, warum auch immer, in ihrer Umgebung einen Lync Director einplanen, obwohl es weder erforderlich noch sinnvoll, ja sogar kontraproduktiv ist. Es zeigt mir, dass viele entweder die Dokumentationen zu Lync nicht lesen und vor allem nicht verstehen, was ein Director macht. Ein paar kurze Sätze:

  • Directoren sind Weichensteller
    Ein Director ist wie ein Frontend Server anzusehen, nur dass er kein eigener Registrar ist und dass er keine "User Services" (Buddyliste,Provisioning etc.) bereit stellt. Er hat aber durchaus Webservices, authentifiziert, stellt Zertifikate aus und leitet den Anwender an "seinen Homeserver" weiter.
  • Verfügbarkeit erfordert mehrere Director Server
    Wer also einen Director einsetzt, sollte mindestens 2 oder mehr Server haben. Wer nur einen Server hat (und der fällt aus), hat keine Lync Funktion mehr, selbst wenn alle anderen Dienste laufen. Damit scheidet ein Director schon aus, wenn die Umgebung nicht eine gewisse Größe erreicht
  • Director sind in Lync 2013 nicht mehr so wichtig
    Warum auch immer waren Director-Server bei Lync 2010 fast in jedem Bild enthalten und das hat wohl den Eindruck erweckt sie wären erforderlich. Das waren Sie aber nicht und in Lync 2013 ist die Rolle weiter zurück gedrängt worden.
  • Director mit Single Pool oder Standard Server
    Wer nur eine Lync Site mit einem Pool oder gar nur einen Standard Server vorgesehen hat, kommt problemlos ohne Director aus. Ich versteife mich sogar auf die Aussage dass in so einer Konfiguration ein Director fast immer eine Fehlplanung und Fehlkonfiguration darstellt.

Und nun schauen wir uns erst mal an, in welchen Umgebungen ein Director wirklich Sinn macht und wie man selbst in diesen Umgebungen ohne Direktor auskommt

Die große Lync Umgebung

Wir brauchen eigentlich zwei oder mehr Pools und viele Anwender, um überhaupt einen Director in Betracht zu ziehen. Also malen wird mal eine "große Umgebung" auf:


Beispiel ist nicht als Referenz zu nutzen. Niemand verbietet ihnen den Einsatz weiterer Edge- und Director-Server, z.B. in EMEA

Diese virtuelle Firma hat drei große Pools in den drei geografischen Regionen Amerika, Europa und Asien/Pazifik. So eine Aufteilung ist für internationale unternehmen durchaus praktikabel, da die meisten Anwender ja in einer Region arbeiten und damit Laufzeiten über Netzwerke reduziert werden. Die Laufzeit über mehrere Router und Provider ist durchaus nicht zu unterschätzen, vor allem wenn mehrere Router das Paket immer erst komplett empfangen müssen, ehe Sie es auf der anderen Seite wieder los senden können und eine "langsame" WAN-Leitung weitere Verzögerung addieren.. So kommen schnell einige Millisekunden zusammen.

Wer die Clients nicht statisch auf "ihren Pool" konfiguriert, sondern die automatische Konfiguration per DNS verwendet, der wird zwei DNS-Einträge besonders gut können:

  • _sipinternaltls._tcp.<sipdomain>
    Dieser Eintrag wird von den Clients zuerst abgefragt und sofern dieser auflösbar ist, dann geht der Client davon aus, dass er "intern" ist und keine Edge-Server nutzen muss. Der Eintrag verweist auf einen Servername, der per Loadbalancer oder DNS-RR auf mehrere Server verteilt wird, so dass eine Verfügbarkeit gewährleistet ist. Sie können den Client zu jedem Server verweisen, denn der erste Lync Server authentifiziert den Client aber leitet ihn dann zu seinem "HomeServer" weiter.
    Dieser Eintrag kann also auf beliebige Server verweisen, solange diese nur funktionieren und den Client bediene oder eben weiter leiten.
  • _sip._tls.<sipdomain>
    Für Clients, die nicht intern sind und die automatische Konfiguration nutzen, darf die Anfrage nach "_sipinternaltls._tcp.<sipdomain>" nicht funktionieren, damit sie auf "_sip._tls.<sipdomain>" zurück fallen. Dieser Eintrag verweist normalerweise auf die IP-Adresse der AccessEdge-Server, die die Anfragen dann nach innen weiter geben. Solange es nur einen Edge-Pool gibt, ist diese Einstellung einfach, aber wer mehrere Edge-Pools verweist, möchte vielleicht die Clients zu dem Edge lenken, der geografisch am nächsten steht.
    Und zu jedem Edge Pool gibt es einen "Next Hop", an den der Edge die Anfragen weiter gibt. Das gilt insbesondere für Federation und anonyme Zugriffe, die in Form von SIP-DDOS-Attacken schon nerven können. Schade, wenn diese Anfragen einen internen Frontend "belasten", der damit auch die internen Anwender nur noch eingeschränkt bedienen könnte. Das ist dann wirklich ein Thema für einen Director

Der Client verbindet sich also mit einem per DNS (oder manueller Konfiguration) aufgelösten Frontend Server, der nicht unbedingt der eigentliche Homeserver sein muss und wird dann von diesem Server zu seinem korrekten Pool unter Nutzung des Pool-FQDN weiter geleitet.

Ein Director kann hier helfen, damit nicht ein Benutzerpool auch die Erstanfragen anderer "poolfremder" Clients bedienen muss. Mit einem einzelnen Director ist es aber nicht getan. Aus Gründen der Verfügbarkeit sollten Sie also schon mehrere Server als Director-Pool konfigurieren und selbst die sind natürlich erst mal geografisch an einem Ort zentriert und Clients starten ihren ersten Zugriff eventuell über ein WAN.

Director-Server sind also nicht allein die Lösung für eine höhere Verfügbarkeit sondern primär eine Weg die Last der ersten Verbindung und die Angriffsflächen über Edge-Server zu reduzieren.

Der richtige Pool und der richtige Edge

Es dreht sich also vieles über die Möglichkeiten, um interne Client am besten gleich zum richtigen Pool zu lenken und externe Clients den passenden Edge zu verpassen. Wenn Sie nun etwas über DNS, HOSTS, DHCP und Gruppenrichtlinien wissen, dann gibt es sehr wohl Möglichkeiten, die Clients entsprechend zu steuern.

  • DNS-Tricks
    Die großen Provider machen es mit Geo-DNS vor, d.h. DNS-Server die abhängig von der Client-IP den "naheliegenden" Service zurück liefern. Das macht sogar der Windows DNS-Server, aber leider nur in einer ganz besonderen Konstellation.
  • Gruppenrichtlinien
    Neben der automatischen Konfiguration können Sie den Lync Client auch statisch konfigurieren und so z.B.: über Windows Gruppen eine bestimmen Benutzergruppe auch bestimmte Pools vorgeben. Knifflig wird nur, wenn sich den Pool ändern oder abbauen wollen, dass Sie dann sicher sein müssen, dass alle früheren Clients schon umgezogen sind.
  • DHCP-Optionen
    Leider unterstützt der Lync Communicator keine DHCP-Optionen, wie dies die Lync Telefone machen. Allerdings können die Lync Telefone ja auch zur Vereinfachung nur Rufnummer + Extension zur Anmeldung nutzen und wissen daher noch keine "SIP-Domäne" für die erste Verbindung. Daher bekommen diese Telefone die URL zum Lync Webservice per DHCP und wissen erst nach der Anmeldung per Extension/Pin, welcher Benutzer sich da tatsächlich anmeldet.

Für den Communicator müssen wir also die klassischen Ansätze bemühen um mit oder ohne Director diese zum besten Frontend Pool bzw. Edge-Pool zu leiten.

DNS-Tricks zum richtigen Pool (Intern)

Es gibt heute schon DNS-Server, die anhand der ankommenden IP-Adresse der Anfrage, was idealerweise der Client oder der Provider des Client ist, den Ort ermitteln. Aber so kompliziert muss man gar nicht denken. Zumindest wenn man erst mal die interne Aufgabenstellung lösen möchte. Angenommen es gibt mehrere Pools wie oben skizziert und sie möchten gerne die Clients einer geografischen Region auf den Pool in der Region lenken, dann geht das auch über DNS-Pinpoint-Zonen. Normalerweise betreiben Sie nämlich auch in den lokalen Umgebungen einen eigenen DNS-Server je Niederlassung und das ist der Trick. Niemand sagt, dass die DNS-Einträge für _sipinternaltls._tcp.<sipdomain> auch in der DNS-Zone der Domäne <sipdomain.de> direkt enthalten sein müssen. Sie können natürlich auch eine eigene Subzone "_sipinternaltls._tcp.<sipdomain>" anlegen, in der es genau einen SRV-Record gibt. Dazu sollten Sie die Zone natürlich nicht AD-Integriert machen, da sie sonst auf alle DCs der Domäne repliziert wird.

Also klassische primäre Zone wird sie erst mal nur auf dem einen DNS-Server gehostet und muss von ihnen auf anderen DNS-Servern der Umgebung als sekundäre Zone addiert werden. Als Namen nutzen Sie nun eben den SRV-namen:

Und lassen den DNS-Server die Zone als Datei ablegen

Dynamische Updates habe ich dann nicht zugelassen. Nach der Anlage der Zone können Sie dann in der Zone selbst einen passenden SRV-Record anlegen. Beachten Sie, dass hier die Felder Service und Protocol leer bleiben, da der DNS-Domänenname diese schon enthält:

Leider erlaubt Windows nicht die Anlage eines SRV-Records ohne Namen. Geben Sie dann einfach einen beliebigen Namen ein und editieren Sie dann die Zonendatei (Default:  c:\windows\system32\dns\_sipinternaltls.tcp.<sipdomain>" ) mit Notepad um den Namen durch ein "@" zu ersetzen:

;
;  Database file _sipinternaltls._tcp.msxfaq.de.dns für _sipinternaltls._tcp.msxfaq.de zone.
;      Zone version:  2
;

@                       IN  SOA nawdc003.netatwork.de. hostmaster.netatwork.de. (
                        	2            ; serial number
                        	900          ; refresh
                        	600          ; retry
                        	86400        ; expire
                        	3600       ) ; default TTL

;
;  Zone NS records
;

@                       NS	nawdc003.netatwork.de.

;
;  Zone records
;

@                   SRV	0 0 5061	pool.msxfaq.de.

In der letzten Zeile wurde das "@" an den Anfang geschrieben. Nachdem die Zone dann neu geladen wurde, sind die Änderungen auch in der GUI sichtbar:

So könne Sie auf jedem DNS-Server  der jeweiligen Niederlassung eine "eigene" Version der Zone anlegen. Die Clients bekommen dann abhängig von dem Subnetz, über dessen DHCP-Optionen den lokalen DNS-Server zugewiesen und finden dann auch nur den dort hinterlegten Pool.

Damit ist zumindest "intern" schon einmal eine Konfiguration gefunden, wie Clients ohne Director bei der ersten Verbindung per SIP auf dem lokalen Lync-Pool aufschlagen. In den meisten Fällen sind die Benutzer da dann schon zuhause und nur die Weltreisenden landen eventuell auf dem falschen Pool, der Sie dann aber wieder an den richtigen Server verweist.

DNS-Tricks für Edge

Für Anwender im Internet ist die Konfiguration natürlich nicht ganz so einfach. Eigene Zonen nach Region sind hier nicht so einfach, da die Client in der Regel ihren DNS-Server vom eigenen DSL-Router oder direkt vom Provider bekommen (z.B. GSM/UMTS). Hier kommt aber noch dazu, dass der Zugriff auf den richtigen Edge-Server natürlich auch vom Homepools des Anwenders abhängt, da jedem Pool ein Edge-Server zugeordnet ist und der Client idealerweise über seinen Edge-Server ankommt.

Für die Autokonfiguration wird aber _sip._tls.<sipdomain> genutzt, womit eine unterscheidung nach Pools nicht möglich ist. Ohne eine Optimierung wird der Client aber dennoch funktionieren, da er dann den aufgelösten Edge Server nutzt, der dann den Client zum eventuell falschen Frontend gibt. Dieser wir dann aber über das Provisioning dem Client schon den richtigen Edge für Audio/Video zuteilen.

Wer hier erreichen möchte, dass der Client gleich den richtigen Server nutzt, kommt nicht umhin, den Eintrag "_sip._tls.<sipdomain>" auf einen Hostnamen laufen zu lassen, der dann z.B.: über eine lokale HOSTS-Datei auf die IP-Adresse des gewünschten Edge verweist.

  • PinpointDNS
    Ausgewählte Adressen unterschiedlich auflösbar machen

Konfiguration per GPO

Wenn der Client Mitglied ihres Forest ist und Sie die Einstellungen von Lync auch per Gruppenrichtlinien beeinflussen können, dann können Sie natürlich direkt hier den Weg über eine statische Konfiguration gehen. Lync kann sowohl den FQDN für den internen als auch den externen Hostnamen statisch per Gruppenrichtlinie erhalten.

Sie sparen sich damit dann die ganzen Aktionen mit Pinpoint-DNS-Zonen, lokalen Hosts-Dateien etc.

Pool2Group

Um die Umsetzung der Einstellungen über Gruppenrichtlinien zu optimieren, ist es z.B. ein Weg, wenn alle Benutzer eines bestimmten Pools und damit Edge-Servers die gleiche statische Konfiguration bekommen. Dazu eignen sich Gruppenrichtlinien, die anhand von Gruppenmitgliedschaften angewendet werden. Sie könnten als je Lync-Pool eine Windowsgruppe anlegen, die als Filter bei den Gruppenrichtlinien genutzt wird. Hier ein Codeschnipsel, der eine gegebene Gruppe nimmt, alle Mitglieder entfernt und dann die Anwender zum Pool addiert.

$group = [adsi]("LDAP://cn=pool1User,cn=Users,dc=msxfaq,dc=de)
$group.member,clear()

Get-CsUser -Filter {registrarpool -eq "pool1.msxfa.de"} | foreach { 
    $group.add("LDAP://"+$_.identity) 
}
$group.SetInfo()

Natürlich gibt es auch Lösungen ganz ohne die Lync Add-ons

Was bleibt ?

Letztlich bleibt ein Director übrig um z.B. den eingehenden SIP-Traffic von "untrusted "Quellen" von den produktiven Frontend Servern abzuhalten. Wer also eine sehr große Umgebung betreibt und z.B. viele ungewünschte Zugriffe über einen Edge auf den "next hop" erwartet, der kann den Edge auf einen Director leiten, der die Voranmeldung durchführt und nur authentifizierte Clients dann zu den richtigen Frontend Servern weiter leitet. Sicher hat jede Firma ein eigenes Bedrohungsszenario aber wir sprechen hier schon von einigen tausend Clients, ab denen dies ein Stück weit interessant werden kann.

Und dann gibt es noch den zweiten Aspekt bei sehr sehr großen Umgebungen, bei denen aktuell der Client nur den Redirect des Director auf einen anderen Pool aktuell wohl lokal speichert und damit Folgeverbindungen direkt beim Pool landen, während dein Client, der den falschen Frontend erreicht nur temporär umgeleitet wird aber beim nächsten Start wieder den lokal konfigurierten (GPO, DNS, Hosts) Pool nutzt.

Weitere Links