Edge Server, Reverse Proxy und DNS für Skype for Business SE
Externer Zugriff, Federation und mobile Clients – das vollständige DMZ-Setup auf einer Seite.W I S S E N · S K Y P E F O R B U S I N E S S S E R V E R S E
Edge Server, Reverse Proxy und DNS für Skype for Business Server SE: das vollständige Edge-Setup
Externer Zugriff, Federation und mobile Clients auf einer Seite – mit kompletter DNS-Records-Tabelle, Reverse-Proxy-Vergleich und Trace-Tipps.
Boddenberg – IT-Beratung & Engineering · boddenberg.de · Stand: Juni 2026
|
TL;DR Die Kurzfassung für Eilige Externer Zugriff auf Skype for Business Server SE braucht zwei Komponenten in der DMZ: einen Edge Server für SIP-, Konferenz- und A/V-Verkehr und einen Reverse Proxy für die HTTPS-Webdienste (Lyncdiscover, Meet, Dialin). Microsoft liefert keinen Reverse Proxy mit – typisch sind KEMP, F5, NGINX oder ARR. Dazu kommen die richtigen DNS-Records (sip., lyncdiscover., meet., dialin., _sipfederationtls) und korrekte SAN-Zertifikate. Die häufigsten Fehler sind vergessene oder vorzeitig umgestellte DNS-Einträge. Zum Debuggen reichen oft PortQuery / Telnet auf 5061 und 443. |
|---|
Worum es hier geht
Solange alle User im Büro sitzen, ist Skype for Business Server SE entspannt. Sobald jemand von zu Hause, vom Handy oder ein Federation-Partner zugreifen will, kommt die DMZ ins Spiel – und damit Edge Server, Reverse Proxy, DNS und Zertifikate. Genau hier hängen erfahrungsgemäß die meisten Setups, weil ein einziger fehlender DNS-Record oder ein Zertifikat ohne den richtigen SAN das ganze externe Erlebnis kippt. Das große Bild liefert der Pillar „Skype for Business Server SE im Überblick“; dieser Artikel ist das integrierte Edge-Setup auf einer Seite.
Architektonisch hat sich gegenüber 2019 nichts geändert. Was diesen Artikel von Microsoft Learn unterscheidet, ist die Geschlossenheit: Edge-Rollen, Reverse-Proxy-Wahl, eine vollständige DNS-Tabelle, die Zertifikatsanforderungen und die Trace-Befehle zum Nachstellen – alles an einem Ort, in der Reihenfolge, in der du es brauchst.
Die Topologie: drei Zonen, zwei Firewalls
Externer Zugriff läuft über zwei getrennte Pfade. Webdienste (HTTPS) gehen über den Reverse Proxy, der eigentliche Echtzeit-Verkehr (SIP, Konferenz, A/V) über den Edge Server. Beide stehen in der DMZ, getrennt vom internen Netz durch Firewalls.
Skizze 1: Internet, DMZ und internes Netz. Reverse Proxy für HTTPS-Webdienste, Edge Server für SIP/Konferenz/A/V. Interne Clients gehen direkt zum Front-End, ohne Edge.
Die Edge-Rollen
Der Edge Server bündelt drei Dienste auf einer Box. Er hat zwei Netzwerkkarten (eine externe, eine interne) und wird bewusst NICHT in die Domain aufgenommen – er steht in der DMZ und vertraut der internen Welt nur über definierte Ports.
|
Edge-Dienst |
Port (extern) |
Wofür |
|---|---|---|
|
Access Edge (SIP) |
5061 / 443 |
SIP-Signalisierung, Federation, externe Anmeldung |
|
Web Conferencing Edge |
443 |
Inhaltsfreigabe in Meetings (PSOM) |
|
A/V Edge (Media) |
443 + 3478 |
Audio/Video, Desktop-Sharing, STUN/TURN/ICE |
|
ACHTUNG Der Edge gehört nicht in die Domain Edge-Server sind Workgroup-Maschinen in der DMZ – nicht domain-joined. Das ist Sicherheitsarchitektur, kein Versehen. Wer den Edge versehentlich in die Domain aufnimmt, durchlöchert die Trennung zwischen perimeter und internem Netz. Die Vertrauensbeziehung läuft über Zertifikate und definierte Ports, nicht über Kerberos. |
|---|
Reverse Proxy – Wahl und Vergleich
Den Reverse Proxy liefert Microsoft nicht mit. Er veröffentlicht die internen Webdienste nach außen: Lyncdiscover (Autodiscovery), Meet (Meeting-Join im Browser), Dialin (Einwahlkonferenzen) und die Adressbuch-/Webticket-Dienste. Vier Kandidaten sind in der Praxis verbreitet:
|
Reverse Proxy |
Stärke |
Beachten |
|---|---|---|
|
KEMP LoadMaster |
Fertige SfB-Templates, beliebt im Mittelstand |
Lizenzkosten, Appliance oder VM |
|
F5 BIG-IP |
Enterprise-Funktionsumfang, sehr flexibel |
Komplexer, teurer – lohnt bei großen Setups |
|
NGINX |
Schlank, kostenlos möglich, voll skriptbar |
Mehr Handarbeit, SfB-Templates fehlen |
|
IIS ARR |
On-board mit Windows/IIS, kostenneutral |
Mehr Konfig-Aufwand, Microsoft-Standardweg |
|
FALLE Reverse Proxy vergessen ist der Klassiker Wer beim Setup nur an den Edge denkt, hat externe SIP-Anmeldung – aber kein Meeting-Join, kein Dialin, keine mobilen Clients. Die Web-Publishing-Schicht ist eigenständig und wird gern vergessen, bis sich der erste Außendienstler beschwert, dass er Meetings nicht im Browser öffnen kann. Plane Reverse Proxy von Anfang an mit ein – inklusive seiner eigenen Zertifikate. |
|---|
Die vollständige DNS-Records-Tabelle
Das ist das Herzstück. SfB nutzt Split-Brain-DNS: Dieselben Namen zeigen extern auf Edge/Reverse-Proxy, intern auf den Front-End-Pool. Die folgende Tabelle ist die praxiserprobte Minimalmenge (Beispiel-Domäne contoso.de) – anpassen, aber keinen Record weglassen.
|
Typ |
Name |
Ziel |
Zone |
|---|---|---|---|
|
SRV |
_sip._tls.contoso.de |
sip.contoso.de:443 |
extern |
|
SRV |
_sipfederationtls._tcp |
sip.contoso.de:5061 |
extern (Federation) |
|
A |
sip.contoso.de |
Edge Access (extern) |
extern |
|
A |
lyncdiscover.contoso.de |
Reverse Proxy |
extern |
|
A |
meet.contoso.de |
Reverse Proxy |
extern |
|
A |
dialin.contoso.de |
Reverse Proxy |
extern |
|
A |
webext.contoso.de |
Reverse Proxy (ext. Webservices) |
extern |
|
SRV |
_sipinternaltls._tcp |
Front-End-Pool:5061 |
intern |
|
A |
lyncdiscoverinternal.contoso.de |
Front-End-Pool |
intern |
|
A |
admin.contoso.de (Simple URL) |
Front-End-Pool |
intern |
|
FALLE DNS ist der häufigste Fehlerort – und der Premature Switch der schlimmste Lyncdiscover, sip. und meet. entscheiden, ob ein externer Client überhaupt zum richtigen Endpunkt findet. Der Klassiker in Hybrid-Szenarien ist der Premature DNS-Switch: DNS-Records werden Richtung Microsoft 365 umgebogen, bevor die User wirklich umgezogen sind – und plötzlich landet niemand mehr beim On-Prem-Edge. Ändere DNS erst, wenn der Zielzustand wirklich steht. |
|---|
Zertifikats-Anforderungen
Edge und Reverse Proxy brauchen öffentlich vertraute Zertifikate mit den passenden Subject Alternative Names (SAN). Ein fehlender SAN ist nach dem fehlenden DNS-Record die zweithäufigste Fehlerquelle.
|
HINWEIS Eine fehlende SAN-Zeile = stundenlange Fehlersuche Zertifikatsfehler äußern sich selten als klare Meldung, sondern als „geht nicht“ bei genau einem Dienst. Wenn Meeting-Join scheitert, aber SIP-Login klappt, ist fast immer ein SAN auf dem Reverse-Proxy-Zertifikat vergessen. Prüfe die SAN-Liste, bevor du tiefer gräbst. |
|---|
Federation einrichten
Federation erlaubt Chat, Präsenz und Anrufe mit Partnerorganisationen. Sie läuft über den Access Edge und den _sipfederationtls-SRV-Record. Zwei Modi:
Praktisch steuerst du das über Set-CsAccessEdgeConfiguration und New-CsAllowedDomain. Voraussetzung ist immer: korrekter _sipfederationtls-Record, geöffneter Port 5061 und ein öffentlich vertrautes Edge-Zertifikat.
Trace und Troubleshooting
Wenn externer Zugriff nicht funktioniert, hilft kein Raten – prüf die Ports von außen und arbeite dich von der Verbindungs- zur Anwendungsebene vor. Die zwei wichtigsten Bordmittel:
PortQry -n sip.contoso.de -p TCP -e 5061 # Access Edge erreichbar?
PortQry -n meet.contoso.de -p TCP -e 443 # Reverse Proxy / Web erreichbar?
Test-NetConnection sip.contoso.de -Port 5061 # PowerShell-Alternative
|
HINWEIS Der Consulting-Hebel Edge-Probleme fühlen sich dramatisch an, sind aber fast immer eine von drei Sachen: fehlender DNS-Record, vergessener SAN, geschlossener Port. Eine systematische Schicht-für-Schicht-Prüfung (Port – DNS – Zertifikat – SfB) löst die meisten Fälle in Minuten statt Stunden. Der Wert liegt nicht im Geheimwissen, sondern in der Reihenfolge – und darin, den Premature DNS-Switch gar nicht erst zu machen. |
|---|
Häufige Fragen
Brauche ich sowohl einen Edge Server als auch einen Reverse Proxy?
Ja – sie machen Verschiedenes. Der Edge transportiert SIP, Konferenz- und A/V-Verkehr, der Reverse Proxy veröffentlicht die HTTPS-Webdienste (Lyncdiscover, Meet, Dialin, mobile Clients). Ohne Reverse Proxy hast du externe Anmeldung, aber kein Meeting-Join im Browser und keine mobilen Clients.
Welchen Reverse Proxy soll ich nehmen?
KEMP LoadMaster ist im Mittelstand beliebt (fertige SfB-Templates), F5 BIG-IP für große Enterprise-Setups, NGINX als schlanke skriptbare Lösung und IIS ARR als kostenneutraler Microsoft-Standardweg. Die Wahl hängt an Budget, vorhandenem Know-how und Größe.
Welche DNS-Records brauche ich mindestens?
Extern: _sip._tls und _sipfederationtls als SRV, dazu A-Records für sip., lyncdiscover., meet. und dialin.. Intern zusätzlich _sipinternaltls und lyncdiscoverinternal.. Split-Brain-DNS ist Pflicht.
Warum geht Meeting-Join nicht, obwohl SIP-Login klappt?
Fast immer ein Reverse-Proxy-Problem: fehlender DNS-Record für meet. oder ein fehlender SAN auf dem Reverse-Proxy-Zertifikat. SIP läuft über den Edge, Meeting-Join über den Reverse Proxy – zwei getrennte Pfade, zwei getrennte Fehlerquellen.
Muss der Edge Server in die Domain?
Nein – im Gegenteil. Edge-Server sind Workgroup-Maschinen in der DMZ und werden bewusst nicht domain-joined. Das ist Sicherheitsarchitektur: Die Trennung zwischen perimeter und internem Netz würde sonst durchlöchert.
Wie prüfe ich, ob meine Edge-Ports erreichbar sind?
Von einem externen Netz aus mit PortQry oder Test-NetConnection auf 5061 (Access Edge) und 443 (Web/A/V). Kommt keine Antwort, liegt es an Firewall oder DNS – nicht an SfB. Erst danach in die SfB-Diagnose einsteigen.
Was ist der Premature DNS-Switch und warum ist er gefährlich?
Das vorzeitige Umbiegen der DNS-Records Richtung Microsoft 365 in Hybrid-Szenarien, bevor die User wirklich umgezogen sind. Folge: Externe Clients finden den On-Prem-Edge nicht mehr, obwohl ihre Postfächer und Konten noch dort liegen. Ändere DNS immer erst, wenn der Zielzustand steht.
Weiterführende Themen
Edge greift in mehrere Nachbarthemen. Weiter geht es hier:
Fazit
Das Edge-Setup wirkt komplex, ist aber im Kern überschaubar: zwei Komponenten in der DMZ (Edge für Echtzeit, Reverse Proxy für Web), die richtigen DNS-Records im Split-Brain-Modus, korrekte SAN-Zertifikate und definierte Ports. Wer das einmal sauber aufsetzt und dokumentiert, hat dauerhaft Ruhe.
Und wenn doch etwas klemmt, gilt die Reihenfolge: Port, DNS, Zertifikat, dann erst SfB. Den Premature DNS-Switch macht man genau einmal – danach nie wieder.
Über den Autor
Ulrich B. Boddenberg ist unabhängiger IT-Berater, Software-Engineer und Fachbuchautor mit rund 30 Jahren Erfahrung in Microsoft-Enterprise-Infrastrukturen (Active Directory, ADFS, Entra ID, Exchange, SharePoint, PKI, Teams-Telefonie). Webseite: boddenberg.de.