DNS Checkliste (Lync/Skype für Business)

Mit der Installation eine Unified Communication Server -Lösung sind eine ganze Menge DNS-Einträge erforderlich. Aus verschiedenen Quellen, eigenen Erfahrungen und Unterlagen habe ich mir eine Checkliste erstellt.

  • Checklisten
    Eine Übersicht aller Checklisten der MSXFAQ

Beachten sie die drei Unterschiede.

  • Ein einzelner Standard Server
    Wenn man einen Enterprise Pool hat, dann ändert sich die LyncWeb-Url meist auf einen eigenen Namen, der über einen Loadbalancer die Zugriffe auf die Poolmitglieder verteilt.
  • Ein Edge Server
    Wer mehrere Edge Server als HA-Lösung implementiert, muss sich über DNS-RR oder Loadbalancer Gedanken machen
  • Single Pool
    Die Liste nicht nicht vollständig, wenn sie mehrere Pools und mehrere Edge-Server installieren wollen. Dann kommen die zusätzlichen Server und deren Services natürlich noch dazu.

Die Liste ist für mich dennoch eine einfache und schnelle Möglichkeit den Überblick zu behalten und auch selbst immer mal wieder nachzuschauen.

Wenn in einer Zelle ein "NEIN" steht, dann bedeutet dies, dass der Namen nicht auflösbar sein darf! Wer also z.B. intern neben LyncDiscoverinternal auch noch Lyncdiscover einträgt, kann Probleme bekommen. Ich habe das z.B.: gemerkt, wenn mein Notebook zuhause (Extern) in den Schlafmode geht und dann in der Firma wieder aufwacht. Da er weiterhin den externen Edge auflösen und auch erreichen konnte, hat er weiter "wie extern" gearbeitet. Wenn Intern aber korrekt bestimmte Daten nicht publiziert sind (z.B.. DataEdge), dann funktionieren Teile in Konferenzen nicht.

Name Typ Intern Extern Bedeutung

lyncdiscoverinternal.<sipdomain>

CNAME oder A

Ja,
Interne IP

Nein

Neuere Windows Clients und alle Mobilclients versuchen zuerst diesen Namen aufzulösen, um einen Webservice zu erreichen, der den passenden Homeserver mitliefert. Dieser Name darf NUR von intern erreichbar sein.

lyncdiscover.<sipdomain>

CNAME oder A

Nein

Ja, Public-IP des ReverseProxy

Dies ist das entsprechende Gegenstück von Lyncdiscoverinternal auf der externen Seite. Der Name darf nur extern erreichbar sein.

%LyncWebexternal%

A

Nein

Anmerkung bei Split-DNS

Ja, Public-IP des ReverseProxy

Über diesen Namen greifen Lync Clients auf die Lync Webdienste (LyncWeb) zu. In der Regel erfolgt dies über einen Reverse Proxy, die die Zugriffe dann auf den Pool oder den einzelnen Server weiter gibt. Jeder Lync Standard Server bzw. Lync Enterprise Pool hat einen eigenen Namen und muss separat erreichbar gemacht werden.

Die External-URL muss bei Spilt-DNS-Konfigurationen auch intern auflösbar sein, d.h. muss in der internen Zone addiert werden, aber verweist auf die öffentliche IP, damit Clients immer über den gleichen Weg beim Pool ankommen. Die Firewall bzw. der Proxy muss diese "Hairpinning" unterstützen.

%LyncWebinternal%

A

Ja, Interne IP

Nein

Die interne URL muss nur intern auflösbar und erreichbar sein.

%SimpleURL%

A

Ja

Ja, Public-IP des ReverseProxy

Die Simple-URLS (Meet, Join, Lyncadmin bzw. wie Sie diese genannt haben) müssen intern auf den internen WebService der Pools verweisen und aus dem Internet auf einen Reverse-Proxy, der die Anfragen auf die externe WebService-Seite (Port 4443) weiter gibt.

%AccessEdge-FQDN%

A

Nein

Ja, Public-IP

Der Name des Access-Edge muss auf die externe IP des Access-Edge des Edge Server oder Edge Pools verweisen

%DataEdge-FQDN%

A

Nein

Ja, Public-IP

Der Name des Data-Edge muss auf die externe IP des DataEdge-Dienstes auf dem Edge Server oder dem Edge Pools verweisen

%AVEdge-FQDN%

A

Nein

Ja, Public-IP

Dieser Name und die IPs werden für die STUN/TURN-Tests durch den Client genutzt.

%interne Edge-FQDN%

A

Ja,
Interne IP

Nein

Der interne FQDN des Edge Server muss intern auf die private IP verweisen.

_sip._tls.<sipdomain>

SRV

Nein

Ja

Für "Legacy Clients" erforderlich, die keine Serversuche über "Lyncdiscover" unterstützen.

_sipfederationtls._tcp.<sipdomain>

SRV

Nein

Anmerkung bei Split-DNS

Ja,
sip.<sipdomain>
%accessEdge%:5061

Veröffentlich die Federation mit anderen Firmen. Der Eintrag ist nicht zwingend, wenn die Partner explizit die Federation manuell eintragen.
Er ist aber erforderlich mit "Mobility" für Apple und Windows Phone.

Achtung: Der Edge muss diesen Eintrag auch auflösen können. Wenn ihr Edge "nach intern" fragt und sie "Split-DNS" nutzen, dann müssen Sie den Eintrag intern setzen.

xmpp-server._tcp.<sipdomain>

SRV

Nein

Ja,
xmpp.<sipdomain>:5269

Zusammen mit dem Hostnamen "xmpp.<sipdomain" ist der Eintrag für eine Federation mit XMPP erforderlich.

xmpp.<sipdomain>

CNAME

Nein

Ja,
%accessEdge-FQDN%

Siehe xmpp-server._tcp.<sipdomain>

_sipinternaltls._tcp.<sipdomain>

SRV

Ja,
Interne IP:5061

Nein

Für "Legacy Clients" erforderlich, die keine Serversuche über "Lyncdiscoverinternal" unterstützen. Diese fragen nach diesem Namen und erwarten den Pool oder Server Lync 2010 Clients und neuer können mit DNS Round Robin mit mehreren IP-Adressen umgehen.

sip.<sipdomain>

A

Nein

Ja,
%accessEdge-IP%

Ein Eintrag mit dem Namen "SIP" ist für die Federation mit MSN, AOL, Yahoo (Also PIC MSN/Skype) erforderlich und kann natürlich auch als Name für den AccessEdge genutzt werden.

%Webapp%

A

Ja,
Interne IP

Ja,
Public-IP des ReverseProxy

Diese URL wird nur zur Freigabe von Powerpoint-Folien in Meeting genutzt und verweist auf einen Office Web App Server oder Pool, welcher diese Daten vom Lync Pool bezieht und an die Clients als HTTPS-Antwort ausliefert.

Wenn Sie Fehler oder Unstimmigkeiten finden, dann bin ich für einen Hinweis dankbar.

DNS-Check

Wer so viele DNS-Einträge anlegt, sollte sich vielleicht überlegen, ob diese Einträge auch vorhanden und aktuell sind. Ich habe noch kein PowerShell-Skript fertig, welches alle Einträge für eine Domäne entsprechend prüft.

Einige der DNS-Einträge sind nur von der SIP-Domain abhängig und über Lyncdiscover ist es zumindest nicht schwer, die LyncWeb-URL zu ermitteln und ebenfalls zu prüfen. Aber nur mit Zugriff auf die Communication Server PowerShell könnte man die Namen aller Dienste aus der Topologie ermitteln. Da dies etwas umfangreich und zeitaufwändig ist, wird das Skript die Namen aus einer Konfigurationsdatei ziehen, die Sie als Administrator entsprechend zu füllen haben.

Service Checks

Wenn Sie noch eine Stufe weiter gehen wollen, dann können Sie natürlich auch die dahinter liegenden Dienste prüfen. Bei SIP-Diensten muss zumindest der TLS-Handshake erfolgreich sein und ein SIP OPTIONS PING wird der Server sicher auch beantworten.

Die Web Services können Sie über einen einfachen HTTPS-GET ohne einen "accept-"Header an folgender URL testen:

GET HTTPS:/Pool2ExternalWebFQDN.contoso.com/autodiscover/autodiscoverservice.svc/root

Das Zertifikat muss gültig sein und als Antwort kommt eine XML-Datei mit einem 200OK.

Weitere Links