Lync DHCP

Die meisten Lync Clients bekommen von einem DHCP-Server nur mit, dass er IP-Adressen, Gateway, DNS-Server etc. verteilt. Aber wussten Sie, dass Lync selbst auch DHCP-Server sein kann oder bestimmte Einstellungen für Lync per DHCP von ihnen bereit gestellt werden müssen?

DHCP mit Lync

Die meisten Lync Clients nutzen mittlerweile LyncDiscover, um, den Weg zu ihrem Lync Server zu finden. Selbst die SRV-Records werden damit immer weniger wichtig, aber noch nicht überflüssig. Aber es gibt Clients, denen auch die SRV-Records oder LyncDiscover nicht ausreichen und bestimmte Informationen per DHCP bekommen. Darunter fallen insbesondere die Lync:Telefone. Sie folgen keiner Gruppenrichtlinie, können kein LDAP und unterstützen die Anmeldung per Extension und Pin.

DHCP wird heute in der Regel von DHCP-Servern bereit gestellt, die neben globalen Optionen auch Optionen pro Subnet bereit stellen. So kann ein Client in eine VLAN/Segment immer eine korrekte IP-Adresse und Gateway bekommen aber insbesondere auch "naheliegende" DNS-Server. DHCP ist eine sehr gute Möglichkeit abhängig vom physikalischen Standort eines Clients die passenden Einstellungen zu verteilen.

Da DHCP aber mit Broadcasts arbeiten muss, der Client hat am Anfang ja keine IP-Adresse, ist es eine Voraussetzung, dass der DHCP-Server auch die Pakete in dem Subnetz sehen kann. Er hat dazu entweder ein Beinchen in dem Subnetz oder der Router erkennt diese Anfragen und leitet Sie an einen hinterlegten DHCP-Server weiter. Die Funktion finden Sie unter den Stichworten DHCPRelay oder BootpForwarder und nichts besonderes.

Ein DHCP-Server kann aber mehr als "nur" IP-Adressen verteilen. DHCP kommt von "Dynamic Host Configuration Protocol" und erlaubt über eigene Einträge die Verteilung beliebiger Einstellungen auf globaler Ebene oder per Subnetz oder sogar herunter bis zum einzelnen Client. Ein DHCP-Server muss sogar nicht mal IP-Adressen verteilen, sondern kann sich auf seine individuellen Einstellungen beschränken, indem er auf Anfragen nach IP-Adressen einfach stumm bleibt. So funktioniert z.B. auch WPad, die automatische Konfiguration von Proxyeinstellungen.

DHCP Optionen

Die Lync Telefone benötigen bestimmte Einstellungen um z.B.: den SIP-Server zu finden und die Lync WebServices. Dazu werden zwei DHCP-Optionen verwendet. Nicht alle Optionen sind per Default im DHCP Server schon angelegt. So kann es sein, dass Sie eine Option erst auf dem Server definieren müssen, ehe Sie diese auf dem Bereich hinzufügen können.

Option 42 NTP

Die Telefone sollten nicht nur für die Anwender eine korrekte uhrzeit anzeigen, sondern benötigen diese Information natürlich auch für die Überprüfung der verwendeten Zertifikate.

This option needs to be configured only in an intranet-only environment or a PIN authentication scenario to resolve the time server address.
Quelle: Configuring DHCP Options to Enable Sign-in für IP Phones http://technet.microsoft.com/en-us/library/gg398088(v=ocs.14).aspx

Addieren Sie also hier in diesem Feld einfach einen NTP-Server. Jeder Domain Controller ist ein NTP-Server und insofern könnten Sie sogar die interne AD-Domäne als "Name" angeben oder eben ein Alias wie ntp.<addomain>, der dann auf einen funktionierenden NTP-Server verweist.

Option 120: UCSipServer

Diese Option teilt dem Telefon die Adresse des Lync-Pools mit, mit dem es sich bei einer Anmeldung per "Extension" und "PIN" anmelden kann. Da gibt es ja keine SIP-URL, so dass das Telefon eine Domäne erhalten und den _sip._tls-Eintrag ableiten kann. In der Regel ist die Option 120 im Windows DHCP-Server gar nicht vorhanden, so dass Sie diese erst anlegen müssen. Hier die Schritte in der GUI.

Die Option kann natürlich auch per Kommandozeile addiert werden.

netsh dhcp server add optiondef 120 UCSipServer Binary 0 comment="Sip Server Fqdn"

Erst dann ist die Option auch im Bereich verfügbar und kann mit dem passenden Wert belegt werden. Der Wert muss aber als HEX-String eingetragen werden:

Option

Option Name

Wert

ASCII2HEX

120

UCSipServer

lyncpool1.msxfaq.de

6c796e63706f6f6c312e6d73786661712e6465

Die Einstellung kann auf dem Server und pro Bereich definiert werden.

Der Wer kann auch per Kommandozeile addiert werden:

netsh dhcp server set optionvalue 120 Binary 6c796e63706f6f6c312e6d73786661712e6465

In der GUI ist dies dann auch zu sehen.

Eine Definition pro Subnet macht Sinn, wenn Sie geografisch mehrere Pools verteilt haben, damit die Clients sich zuerst mit dem nahe liegenden Server verbinden, der dann den Anwender zu seinem Homeserver weiterreicht.

Option 43

Kniffliger wird es mit der "Vendor Option 43", die zum einen bei vielen DHCP-Servern nicht vordefiniert ist und wenn man Sie denn man angelegt hat, dann muss Sie auf einen Client (MS-UC-Client) gefiltert werden. Diese "Vendor Klasse" muss man zumindest bei einem Windows DHCP-Server entsprechend definieren. Das geht per GUI aber viel schneller auch per Kommandozeile:

netsh dhcp server add class MSUCClient "UC Vendor Class Id" "MS-UC-Client" 1
netsh dhcp server add optiondef 1 UCIdentifier Binary 0 Vendor=MSUCClient comment="UC Identifier"
netsh dhcp server add optiondef 2 URLScheme Binary 0 Vendor=MSUCClient comment="URL Scheme"
netsh dhcp server add optiondef 3 WebServerFqdn Binary 0 Vendor=MSUCClient comment="Web Server Fqdn"
netsh dhcp server add optiondef 4 WebServerPort Binary 0 Vendor=MSUCClient comment="Web Server Port"
netsh dhcp server add optiondef 5 CertProvRelPath Binary 0 Vendor=MSUCClient comment="Cert Prov Relative Path"

Damit sind dann die Grundlagen geschaffen und die Werte müssen nur noch erfasst werden. Hier kommt nun aber hinzu, dass die Werte ebenfalls nicht als "String" sondern als HEX-Array hinterlegt werden. Bei mir sieht das dann so aus.

Option Number Option Name ASCII-Wert Byte Wert

001

UC Identifier

MS-UC-Client

4D532D55432D436C69656E74

002

URL Scheme

https

6874747073

003

Web Server FQDN

lyncpool1.msxfaq.de

6c796e63706f6f6c312e6d73786661712e6465

004

Web Server Port

443

343433

005

CertProvRelPath

/CertProv/CertProvisioningService.svc

2F4365727450726F762F4365727450726F766973696F6E696E67536572766963652E737663

Zusammengesetzt ergibt sich dann "https://nawlync001.netatwork.de:443/CertProv/CertProvisioningSerivce.svc". Aber natürlich das ganze als Verkettung., wobei die fünf Zeichenketten noch mit der "Länge" codiert werden.

Beim Windows DHCP-Server ist das per GUI möglich aber ich bevorzuge auch hier die Kommandozeile, mit der man die Einstellungen auch gut dokumentieren kann und so bei einem Desasterfall schnell wieder herstellen kann.

netsh dhcp server set optionvalue 1 Binary vendor=MSUCClient 4D532D55432D436C69656E74
netsh dhcp server set optionvalue 2 Binary vendor=MSUCClient 6874747073
netsh dhcp server set optionvalue 3 Binary vendor=MSUCClient 6c796e63706f6f6c312e6d73786661712e6465
netsh dhcp server set optionvalue 4 Binary vendor=MSUCClient 343433
netsh dhcp server set optionvalue 5 Binary vendor=MSUCClient 2F4365727450726F762F4365727450726F766973696F6E696E67536572766963652E737663

In der GUI sieht das dann wie folgt aus.

Bei den Details eines Eintrags sehen Sie dann in den Daten die Textpräsentation und in der Auswahl die VendorClass

Glauben Sie nicht, dass ich diese Werte durch eine Eingebung erhalten habe. Sie können sich auch die Mühe sparen, die String manuell in HEX-Strings zu verwanden und dann die Werte zu addieren. Dazu gibt es das Programm DHCPUTIL.EXE

DHCPUTIL

Microsoft installiert mit Lync auch das Programm DHCPUTIL, welche Sie einfach nutzen können um diese Werte zu erzeugen, eine Batchdatei mit den erforderlichen Zeilen anzulegen und die Funktion zu testen.

DHCPUtil liest dazu die aktuelle Konfiguration aus dem angegeben Pool und erzeigt dann eine Batchdatei, die alle erforderlichen Schritte enthält. Mit dem "RUNConfigScript" wird das Skript auch gleich gestartet.

DHCPUtil.exe -SipServer <LyncServerPoolFQDN> -WebServer <LyncServerInternalWebFQDN> -RUNConfigScript.

In der Regel wird der Lync Admin das Programm DHCPUTIL auf dem Lync Server starten und nur das Skript erzeugen. Dieses Skript führt dann der DHCP-Admin mit seinen Privilegien entsprechend aus. DhCPUtil liegt z.B. auf:

%ProgramFiles%\Common Files\Microsoft Lync Server 2010\DHCPUtil.exe

Lync Server als DHCP-Server

Die Einstellung im DHCP-Server des unternehmens sind die "richtige" Option, wenn ihr Netzwerk mehrere Subnetze enthält. Trotzdem gibt es auch in Lync die Funktion, als DHCP-Server nur diese Optionen zu veröffentlichen. Ein Lync Server kann selbst als DHCP-Server arbeiten und antwortet dann auch nur auf diese Anfragen von Telefonen auf diese Einstellungen.

Die Funktion können Sie mit folgendem PowerShell-Befehle aktivieren und deaktivieren. Per Default ist die Funktion deaktiviert:

set-CsRegistrarConfiguration -EnableDHCPServer $true

Allerdings ist diese Funktion sehr stark beschränk, da der Lync Server nur die DHCP-Anfragen im gleichen Subnetz sieht und damit keine Telefone in anderen Subnetzen bedienen kann. Ich vermute nicht, dass Sie im nächsten Schritt dann auf allen Routern einen BootpForwarder-Eintrag auf den Lync Server setzen wollen.

Dass ein Lync Server als DHCP-Server für die Telefoneinstellungen fungiert ist nett aber nur dort sinnvoll nutzbar, wo alle Endgeräte und die Server im gleichen Subnetz sind. Ansonsten sollten Sie die Optionen besser auf dem Enterprise-DHCP-Server setzen.

DHCP unter Unix

Die Konfiguration der DHCP-Services unter Unix erfolgt meist über Textdateien. hier mal eine Beispielkonfiguration. Abweichen von Windows sind hier die Binary-Werte durch Doppelpunkte zu trennen. Weiterhin sind die fünf Felder für Option 43 nicht getrennt sondern als ein String einzugeben.

Die Konfiguration erfolgt in der Regel in der Datei "/etc/dhcp/dhcpd.conf". Achtung: Zeilenumbruch zur Lesbarkeit addiert:

option domain-name "msxfaq.de"; 
option domain-name-servers 192.168.100.10;
option routers 192.168.100.1; 

class "SNOM" {
        option ntp-servers 192.168.100.1;
        option domain-name "msxfaq.de";
        option sipserver 6c:79:6e:63:70:6f:6f:6c:31:2e:6d:73:78:66:61:71:2e:64:65; # lyncpool1.msxfaq.de
        option vendor-encapsulated-options 01:0c:4d:53:2d:55:43:2d:43:6c:69:65:6e:74:02:05:68:74:74:70:73:
                                           03:13:6c:79:6e:63:70:6f:6f:6c:31:2e:6d:73:78:66:61:71:2e:64:65:
                                           04:03:34:34:33:05:25:2f:43:65:72:74:50:72:6f:76:2f:43:65:72:74:
                                           50:72:6f:76:69:73:69:6f:6e:69:6e:67:53:65:72:76:69:63:65:2e:73:
                                           76:63;
        match if (
                ( substring (hardware, 1, 3) = 00:04:13 )
        );
}

Wenn Sie dies lange HEX-Zeichenkette z.B. in http://www.dolcevie.com/js/converter.html einwerfen, dann sehen Sie den Klartext:

Lassen Sie sich nicht von den "??"-Zeichen oder dem "?%" irritieren. Sie trennen die Optionen von einander und enthalten einmal die Nummer 01-05 und dann die Länge des Strings. Zur Lesbarkeit habe ich die Stellen rot umrandet.

DHCP-Daten verifizieren

Ich nutze in der Regel eine der drei Optionen, um die korrekte Antwort der DHCP-Server zu überprüfen

  • Test-csphonebootstrap
    Wenn auch das Subnetz mit dem Lync Server per DHCP diese Optionen erhält, dann können Sie direkt auf dem Lync Server einen "Telefon-Client" per PowerShell simulieren.
  • Telefon mit WireShark mitschneiden
    DHCP arbeitet generell "unverschlüsselt". Wenn Sie z.B. einem Subnetz ein Telefon nicht zum Laufen bekommen, dann können Sie mit einem Hub oder einem Switch mit Mirroring den Datenverkehr des Telefons mitschneiden und darin die DHCP-Anfragen und Antworten sehen. Wenn Sie als Lync Administrator sich den PrivateKey des Lync Pools besorgen, können Sie mit WireShark oder Netmon auch den SSL-Verkehr aufbrechen.
  • DHCPUTIL -emulateclient
    Das Progamm DHCPUTIL selbst enthält auch eine Funktion, um einen Client zu emulieren. Allerdings machen ihnen dabei die Windows Firewall meist einen Strich durch die Rechnung. Auf dem DHCP-Server selbst funktioniert dies auch nicht.

DHCPUTIL ist im Prinzip das einfachste und eleganteste Programm, um solche Tests mit einem Notebook in den verschiedenen Subnetzen durchzuführen. Hier die Befehle um zuerst die Firewall zu öffnen:

netsh advfirewall firewall add rule name="DHCPClientIn" dir=in action=allow localport=68 protocol=udp
netsh advfirewall firewall add rule name="DHCPClientOut" dir=out action=allow localport=68 protocol=udp

Erst dann können sie den Aufruf wagen:

DHCPUTIL -emulateclient

Vergessen Sie aber nicht danach die Regeln wieder zu löschen.

netsh advfirewall firewall delete rule name="DHCPClientIn"
netsh advfirewall firewall delete rule name="DHCPClientOut"

Weitere Links