DataMCU / DataEdge / Port 8057

Der Skype for Business Edge Server bietet nach extern neben Ports für Signalsierung (SIP über "AccessEdge") und einen Service für Audio/Video (AVEdge für STUN und TURN) mit dem DataEdge einen weiteren Service an, dessen genauere Funktion oft nicht bekannt ist. Diese Seite behandelt die Funktion von Web Konferenzen.

Was macht der Port ?

Allen Administratoren sollten einige Ports bekannt sein. Einer ist z.B.: 5061 für die SIP-Signalisierung und natürlich kennen Sie 443 als universeller Tunnelport, um Webabfragen aber notfalls auch SIP oder sogar Audio in HTTPS einzupacken und zu tunneln. Daneben gibt es noch 3478/UDP als Relay-Port für Audio/Video. 8057 hingegen ist ein TCP-Port, der per TLS abgesichert die Web Konferenz-Dienste über einen Edge-Server nach extern erreichbar macht. Wenn diese Verbindung nicht möglich ist, dann sind folgende Funktionen von Skype for Business gestört.

  • Whiteboard
  • Umfragen
  • PowerPoint Steuerung

Über den Port werden Daten nach dem "PSOM (Persistent Shared Object Model) Protokoll bei Konferenzen ausgetauscht. PSOM ist also eine der drei Verbindungen, die ein Client neben der Signalisierung (SIP) und Audio/Video (RTP) in einem Meeting nutzt.


Quelle: Microsoft

Ein Client sendet seine Daten dazu an die DataMCU, die diese Daten dann an die anderen Teilnehmer weiter sendet.


Quelle: Microsoft

Wenn Client aus dem Internet der Konferenz beiwohnen, dann werden die Daten über den "DataEdge" als Relay weiter gegeben. Dazu hält die Frontend-Rolle eine permanente Verbindung zu den konfigurierten Edge-Servern aufrecht.

RTCDATAMCU auf Frontend Pool

Der Prozess DataMCUSvc.exe hat auf dem Frontend einige Ports geöffnet. Es ist gut zu sehen, dass der Server auch "mit sich selbst" spricht. Das hier hier der Fall, das es nur genau ein Frontend-Server ist. Wenn Sie mehrere Frontend Server in einem Pool betreiben, dann kann es durchaus sein, dass eine Konferenzen Ressourcen auf verschiedenen Servern nutzt.

Sie können weiterhin sehen, dass der Server vier Verbindungen zum Edge Webconference Server aufgebaut hat. Dies ist auch der Fall, wenn gar keine Konferenz aktiv ist. Das geht natürlich auch per Commandozeile

So lässt sich die Verbindung sogar per Skript überwachen.

PS C:\> Get-CsWindowsService RTCDATAMCU | fl *

Name                           : RTCDATAMCU
RequiredServices               : {KeyIso}
IsInstalled                    : True
Mode                           : Automatic
ServiceSidInfo                 : Unrestricted
DelayedStart                   : True
BinaryPath                     : C:\Program Files\Skype for Business Server
                                 2015\Web Conferencing\DataMCUSvc.exe
ActivityLevel                  : Active Conferences=0
ServiceStatus                  : Running
RoleName                       : {ConferencingServer}
ComponentName                  : DataConf
EnableActionOnNonCrashFailures : True
LocalPath                      : WinNT://NT Service/RTCDATAMCU
LocalClass                     : service
ActionDetails                  : RTCDATAMCU
CanPauseAndContinue            : True
CanShutdown                    : True
CanStop                        : True
DisplayName                    : Skype for Business Server Web Conferencing
DependentServices              : {}
MachineName                    : nawlync002.netatwork.de
ServiceName                    : RTCDATAMCU
ServicesDependedOn             : {KeyIso}
ServiceHandle                  : SafeServiceHandle
Status                         : Running
ServiceType                    : Win32OwnProcess
StartType                      : Automatic
Site                           :
Container                      :

RTCDataProxy auf dem Edge

Umgekehrt gibt es auf dem Edge-Server den entsprechenden DataEdge, der interne Name ist dabei RTCDATAPROXY. Hier sehen Sie auch die 4 aktiven Verbindungen durch den Frontend.

Sie können quasi indirekt über diesen Counter überwachen, wie viele Frontend Server eine aktive Verbindung zum Edge Server habe.

Verbindungsaufbau über Port 8057

Eine Besonderheit bei der Verbindung von Frontend zum Edge ist, dass die Verbindung zwar vom Frontend-Server initiiert wird aber der SSL-Handshake durch den Edge Server gestartet wird. Normalerweise verbindet sich ein Client mit einem Server und sendet ein "Client Hello" zum Server. Der Server kann seinerseits dann mit einem "Server Hello" reagieren, indem z.B. das SSL-Zertifikat enthalten ist und dann geht der SSL-Handshake weiter. Sie können das einfach mit einem "Telnet www.msxfaq.de 443" ausprobieren. Das Fenster bleibt schwarz, weil der Webserver auf ein Lebenszeichen des Clients wartet.

Bei der Verbindung über Port 8057 aber wird der TCP-Kanal zwar vom Frontend zum Edge gestartet aber dann dreht sich die Richtung. Der Edge Server ist nicht der "Server" sondern der Client und nutzt die aufgebaute Verbindung dazu, an den Frontend ein Client HELLO zu senden, wie im Netzwerktrace gut sichtbar ist. (192.168.100.102 ist der Frontend und 192.168.77.21 die interne Netzwerkkarte des Edge Servers)

DataEdge-Zertifikate (NET- Update Mai 2017)

Wie bei Skype for Business und Lync üblich ist alles verschlüsselt. Dazu dienen Computerzertifikate, die sowohl die Frontend Server als auch die Edge-Server haben. Da der Edge Server bei der Verbindung aus SSL-Sicht der "Client" ist und der Frontend Server der "Server", muss der Edge natürlich zuerst einmal verifizieren können, ob das Zertifikat des Frontend auch vertrauenswürdig ist. Da die meisten Firmen intern auch Zertifikate einer internen CA nutzen, müssen Sie gewährleisten, dass auch der EdgeServer in der DMZ die CRL erreichen kann. Die CRL in den internen Zertifikaten sollte also neben dem LDAP-Eintrag auch immer eine HTTP-URL enthalten, die auch aus der DMZ per DNS (oder notfalls HOSTS-Datei) auflösbar und erreichbar ist.

Aber auch der Edge Server als Client muss sich gegenüber dem Frontend als solcher ausweisen. Dazu ist es aber erforderlich, dass das interne Zertifikat des Edge-Server nicht nur für die "Server Authentifizierung" zugelassen ist, sondern als Extended Key Usage (EKU)" auch die Client Authentifizierung eingetragen wurde. Das ist leider nicht immer der Fall, insbesondere wenn das Template "WebServer" statt "Computer" genutzt wurde. Sie können dies im Zertifikatsspeicher recht einfach kontrollieren:

Hier müssen beide Einträge vorhanden sind. Wenn Sie hier nur die "Server Authentication (1.3.6.1.5.5.7.3.1) haben, dann hat das lange Zeit dennoch funktioniert bis mit einem Windows Update im Mai 2017 die Überprüfung von Zertifikaten verstärkt wurde. Als Ergebnis gab es einige Skype for Business Server, bei denen die drei oben genannten Funktionen nicht mehr nutzbar waren.

Der korrekte Weg zur Lösung des Problems ist die Ausstellung von neuen Zertifikaten auf dem internen Interface der Edge-Server mit korrekter EKU. Wenn der Prozess aber länger dauert, dann können Sie auf dem Frontend Server die strenge Überprüfung der EKU wieder abschalten. Das sollte aber nur ein temporärer Schritt sein, denn die Sicherheit der Verschlüsselung ist direkt abhängig davon, dass die Endpunkte auch die Zertifikate genau prüfen.

Eventlog

Eine sehr gute Quelle bei Problemen ist das Lync Eventlog. Hier fallen Probleme bei der Verbindung zwischen der DataMCU auf dem Frontend und der DataEdge auf dem Edge sehr schnell auf:

Die Fehlermeldungen der LS Data MCU auf dem Frontend Server sollten nicht zu übersehen sein. Im Detail sieht das dann so aus:

Log Name: Lync Server 
Source: LS Data MCU 
Event ID: 41026 
Task Category: (1018) 
Level: Error 
Keywords: Classic 
Computer: sfb01.msxfaq.net
Description: 
No connectivity with any of Web Conferencing Edge Servers. External Skype 
for Business clients cannot use Web Conferencing modality. 
Cause: Service may be unavailable or Network connectivity may have been compromised. 
Resolution: Verify all Web Conferencing Edge Services in the topology are running, and network connectivity is available.

Der Fehler sagt nur, dass keine Verbindung mit dem Edge aufgebaut werden kann. Die Ursache, dass es ein Problem mit Zertifikaten sein könnte, ist hier nicht zu sehen. Das können Sie dann aber über ein CAPI2-Debugging ermitteln.

Ein weiterer Fehler meldet, dass die Verbindung verloren geht.

Log Name:      Lync Server
Source:        LS Web Conferencing Edge Server
Event ID:      42001
Task Category: (1023)
Level:         Warning
Keywords:      Classic User:          N/A
Computer:      sfb01edge.msxfaq.net
Description:
Web Conferencing Server disconnected
Connection from Web Conferencing Server from sfb01.msxfaq.net disconnected.
This event is reported only once in 30 minutes even if other Web Conferencing Servers
will disconnect during said period. Cause: This can happen if the Web Conferencing
Server was unavailable or taken down for maintenance
Resolution: Make sure that the Web Conferencing Server is up and running

8057 und Firewalls

Es muss aber nicht immer ein Problem mit den Microsoft Produkten oder Zertifikaten sein. Die Verbindung zwischen der DataMCU und dem DataEdge ist auf "Bestand" aufgelegt. Zwischen dem internen Frontend Service und dem Edge Server steht aber in der Regel auch eine Firewall. Wenn hier bei der Konfiguration nicht aufgepasst wird, dann betrachtet die Firewall diese Verbindung eher kritisch und kann schon einmal auch eine bestehende Verbindung unterbrechen. Das ist häufiger der Fall je schlauer die Firewall sein will und als "Next Generation Firewall" vorgibt zu verstehen, was die Server machen.

Dazu müssen sie wissen, dass der DataEdge alle 300 Sekunden (5Min) einen Art "Heartbeat" ausführt, damit die Verbindung bestehen bleibt.

Wenn Sie aber dann plötzlich viele "ReTransmit" gefolgt von "RESET"-Paketen sehen und dann ein Reconnect erfolgt, dann ist etwas "im Weg"

Die Verbindung ist per SSL verschlüsselt aber einige Firewalls unterscheiden sehr wohl zwischen einer "SSL-Aktivität" und einem reinen TCP-Handshake. Da der Payload hier 0 ist, ist das für einige Firewalls ein Grund die Session als "inaktiv" nach einiger Zeit abzubauen. Skype for Business erkennt das natürlich und baut diese umgehend wieder auf. Aber der Eventlog-Eintrag weist darauf hin.

Aber auch hier ist das Eventlog eine wichtige Ressource

Weitere Link