Livemeeting Fehlersuche

Diese Seite beschreibt eine Debug-Session zur Lösung eines Problems mit Livemeeting. Ehe Sie den Fehler an ihrem Server suchen sollten Sie einfach einmal kurz dei Live Meeting Testseite von MIcrosoft starten

Nach kurzer Zeit sollten Sie folgendes sehen:

Wenn dieses Bild nicht erscheint, dann ist die Konfiguration auf dem Client oder dessen Verbindung zum Internet nicht für Livemeeting geeignet. Manchmal passiert es, dass nach dem Ende der Sitzung sich Livemeeting mit einem Hinweis auf ein Update meldet, welches installiert werden kann.

Der erste Fehler

Sollte die Anmeldung aber funktionieren und eine LiveMeeting-Sitzung auf ihren PC nicht möglich sein, dann dürfen Sie die Fehlermeldung als ersten Anlass für die Suche heran ziehen.

Auf den ersten Blick ist eine Fehlersuche mit Livemeeting auf dem Client unmöglich. Die GUI des Livemeeting Clients liefert meist nicht viel mehr als eine wenig aussagekräftige Fehlermeldung. Das ist natürlich ungeschickt, wenn Sie selbst der Administrator sind. Also brauchen Sie Antworten. Am Beispiel einer eigenen OCS-Installation, bei der aus dem Internet kein Zugriff auf Livemeeting möglich war, (siehe Fehler), habe ich die Schritte einmal analysiert.

%TEMP%/PWConsole-debug20.txt

Wenn Sie etwas suchen, dann werden die herausfinden, dass der Livemeeting Client durchaus mit dem Namen "PlaceWare" verknüpft ist und ein Zugriff auf http://www.placeware.com/ auf die Microsoft Livemeeting Seite verweist. Und dieser Client legt immer eine Debug-Datei im Temp-Verzeichnis des Benutzers an. Suchen Sie einfach mal danach.

Livemeeting addiert immer weiter Text. Sie haben es einfacher, wenn Sie vorher diese Datei einfach löschen und dann wieder den Fehler provozieren.

Bei meinem Fehlerbild waren die folgenden Zeilen relevant:

In der Zeile 201 sieht man noch den Verbindungsaufbau des Clients zum Server "avedge.netatwork.de:443". In Zeile 209 ist aber dann zu erkennen, dass der Server die Verbindung anscheinend beendet.

Diagnose mit Netmon

Weil ich noch nicht wusste, ob dies nun vielleicht ein Firewall-Problem sein könnte, kommt wieder der Microsoft Netzwerk Monitor zum Einsatz. Hier habe ich eine Verbindung zum AVEDGE gefiltert (ipv4.address = 80.66.20.21).

Die Pakete 170,175 und 176 zeigen einen normalen TCP-Handshake an, der dann in Paket 177 mit einem SSL-Hello vom Client zum Server startet. Der Server antwortet im Paket 178 zwar noch, aber sendet im Paket 179 dann gleich ein "F" (Beenden) hinterher. Der Server baut also die Verbindung sauber ab, weil ihm irgendwas nicht gefallen hat. mit Netmon kommt man aber hier nun nicht mehr weiter.

Ein Blick in den SSL: Client Hello zeigt, welcher Hostname/Zertifikat angesprochen werden soll.

Damit ist zumindest bewiesen, dass der Client über SIP den "richtigen" AV-Edge-Server"-Namen erhalten hat, per DNS auflösen konnte und nun eine SSL-Verbindung versucht.

SSL Troubleshooting mit OpenSSL (IRRWEG !)

Wenn es um SSL-Verbindungen geht, ist natürlich OpenSSL immer ein guter Kandidat. Damit kann man fast jede SSL-Verbindung einfach mal so testen.

In dem Fall scheitert die Verbindung also am SSL-Aufbau. Wenn ich die gleiche Zeile gegen sip.netatwork.de:5061 fahre, dann sehe ich das Zertifikat. Sie können das ja gerne selbst versuchen. Also muss es auf dem avedge ein Problem mit dem Zertifikat geben.

Da mein Edge-Server hinter einem ISA-Server installiert ist und per NAT veröffentlicht wird. kann es ja auch die Firewall sein. Also starte ich den gleichen Test von "hinter der Firewall":

Ehe ich nun weiter hier suche, habe ich mir dann gesagt: "Versuch doch mal einen AV Edge-Server einer Firma, bei der es gehen sollte. Nachdem ich aber auch bei den AV-Edge-Rollen anderen Firmen das gleiche Problem hatte, kann man OpenSSL hier wohl nicht verwenden.

OCS Konfiguration

Mit etwas Glück habe ich aber den echten Fehler gefunden. Es war einfach nur ein Konfigurationsfehler auf dem OCS-Pool, auf dem ja die internen und externen FQDNs des Web Conference Servers anzugeben waren. Warum auch immer hatte ich dort den Namen des AV-Edge statt des Web Conference Edge hinterlegt.

Es sind oft die kleinen versteckten Einstellungen, die über SIP per TLS-verschlüsselt übertragen werden und den Empfänger in die falsche Spur schicken. Kaum war das korrigiert, war das Fehlerbild ein anderes.

Zertifikatfehler debuggen

Auch hier hilft natürlich der Server Administrator nicht weiter. Auch hier ist wieder ein Blick in die PWConsole*.log relevant.

[MC] 12:22:20:979 GMT [PID 6124] [THREAD 7316]  [I] [X-PSOM] SSLTunnelStream:	Establishing SSL Tunnel Stream to gate.netatwork.de...
..
[MC] 12:22:31:642 GMT [PID 6124] [THREAD 7316]  [E] [X-PSOM]  caught std::exception: InitializeSecurityContext returned SEC_E_UNTRUSTED_ROOT

Oder als Screen-Capture:

Hier hilft aber dann wieder OpenSSL weiter.

openssl s_client -connect gate.netatwork.de:443

OpenSSL ruft das Zertifikat ab und diese ist anscheinend von "Startcom" ausgestellt. Einer CA, die erst im Jahre 2009 in verschiedenen Systemen als "Trusted" addiert wurde.

Das ist hier aber nicht das Problem. Das Zertifikat hier ist auf den Namen "test.netatwork.de" ausgestellt. Da ich das Zertifikat nicht auf dem Edge-Server installiert hatte, kann es ja nur eine Altlast im ISA-Server sein. Dem war dann auch so; ein alter WebListener hatte noch auf der IP-Adresse:443 gelauscht und die Weitergabe der entsprechenden NAT-Regel unterbunden. Kaum ist dieses Problem gefixt, meldet sich per OpenSSL auch das richtige Zertifikate des per NAT veröffentlichten EDGE-Servers.

Federation Debugging

In der gleichen Debug-Session konnte ich auch noch das "Problem" lösen, dass ich zwar sehr wohl Nachrichten an Kontakte einer per Federation verbundenen Firma senden konnte aber keine Antworten angekommen sind. Die gegenüberliegende Seite bekam immer ein "Server antwortete" nicht.

Wurde die Verbindung von extern aufgebaut, dann kam die Kurzmitteilung bei mir an, aber wenn ich diese geöffnet hatte, dann war mein Fenster leer. Ein deutliches Zeichen, dass der SIP-INVITE von extern ankommt aber die dann aufgebaute SIP-Verbindung selbst nicht mehr hergestellt werden kann. In Verbindung mit Thomas Wenzel haben wir dann ein "seltsames" Verhalten in Verbindung mit SAN Zertifikaten als vermutliche Ursache eingekreist. Der Eintrag "_sipfederationtls._tcp.netatwork.de" verweist zwar auf den Eintrag sip.netatwork.de, welcher so auch funktioniert, aber das Zertifikat dahinter ist ein SAN-Zertifikat, dessen erster Name nicht "sip.netatwork.de" lautet. Anscheinend bekommt beim Handshake aber der Partner dieses Zertifikat und nutzt nur den ersten Namen. welcher natürlich auf einen ganz anderen Dienst verweist. Das ist so aber noch nicht bestätigt.

Weitere Links