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 |
|
|
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 |
|
|
Dies ist das entsprechende Gegenstück von Lyncdiscoverinternal auf der externen Seite. Der Name darf nur extern erreichbar sein. |
%LyncWebexternal% |
A |
Anmerkung bei Split-DNS |
|
Ü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 |
|
|
Die interne URL muss nur intern auflösbar und erreichbar sein. |
%SimpleURL% |
A |
|
|
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 |
|
|
Der Name des Access-Edge muss auf die externe IP des Access-Edge des Edge Server oder Edge Pools verweisen |
%DataEdge-FQDN% |
A |
|
|
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 |
|
|
Dieser Name und die IPs werden für die STUN/TURN-Tests durch den Client genutzt. |
%interne Edge-FQDN% |
A |
|
|
Der interne FQDN des Edge Server muss intern auf die private IP verweisen. |
_sip._tls.<sipdomain> |
SRV |
|
|
Für "Legacy Clients" erforderlich, die keine Serversuche über "Lyncdiscover" unterstützen. |
_sipfederationtls._tcp.<sipdomain> |
SRV |
Anmerkung bei Split-DNS |
|
Veröffentlich
die Federation
mit anderen
Firmen. Der
Eintrag ist
nicht zwingend,
wenn die Partner
explizit die
Federation
manuell
eintragen. 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 |
|
|
Zusammen mit dem Hostnamen "xmpp.<sipdomain" ist der Eintrag für eine Federation mit XMPP erforderlich. |
xmpp.<sipdomain> |
CNAME |
|
|
Siehe xmpp-server._tcp.<sipdomain> |
_sipinternaltls._tcp.<sipdomain> |
SRV |
|
|
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 |
|
|
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 |
|
|
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
- DNS-Anforderungen (Domain
Name System)
https://technet.microsoft.com/de-de/library/gg398386(v=ocs.15).aspx - DNS summary - Single
consolidated edge with private
IP addresses using NAT in Lync
Server 2013
https://technet.microsoft.com/en-us/library/Gg412787(v=OCS.15).aspx - LyncWeb
- PRTG DNSCheck
- DNS
- Lync und DNS
-
Checklisten
Eine Übersicht aller Checklisten der MSXFAQ -
Ermitteln von DNS-Anforderungen für Lync Server 2013
https://technet.microsoft.com/de-de/library/gg398758(v=ocs.15).aspx -
DNS-Anforderungen für den Front-End-Pool in Lync Server 2013
https://technet.microsoft.com/de-de/library/Gg398082(v=OCS.15).aspx