Client Connectivitiy Test

Exchange, Lync und viele andere Diensten nutzen immer mehr "Webservices" und oft ist die Fehlersuche für Administratoren und Helpdesk nicht gerade einfach. Da kommen Loadbalancer dazwischen, SSL-verschlüsselte Verbindungen und selbst das klassische "Telnet" fehlt mittlerweile auf PCs. Natürlich lässt sich durch Monitoring wie SCOM, Nagios etc. einiges lösen, aber wenn ein Anwender vor seinem Client über ein Problem stolpert und der Helpdesk erst mal nach den Fehler sucht, könnte eine HTML-Seite ein einfaches und schnelles Hilfsmittel sein.

Die Idee

Ein Anwender möchte auf verschiedene Dienste zugreifen aber warum auch immer funktioniert das ein oder andere nicht. Im Rahmen der Fehlersuche auf dem Client werden dann IP-Adressen ermittelt, NSLOOKUP-Tests befohlen, System gepingt und je umfangreicher die Umgebungen sind, desto mehr Systeme sind davon betroffen. Interessanterweise nutzen immer mehr Dienste einfach SMB oder HTTP, auch wenn es immer noch TCP-Dienste wie POP, IMAP etc. gibt.

Stellen Sie sich vor, es gibt irgendwo eine HTML-Datei, die vom Client einfach aufgerufen werden kann und einen schönen "Status" aller Services des unternehmens anzeigt. Idealerweise alles mit einem "OK" gekennzeichnet. Die Statusseite lädt dazu von allen Servern einfach ein kleinen Image, welches z.B.: einen gründen Pfeil, einen Smiley oder wegen mir auch das Logo des Produkts anzeigt. Wenn der Client das Bild schon nicht laden kann, dann gibt es schon ein generelles Verbindungsproblem zwischen dem Client und dem Service. Kann hingegen ein anderer Client den Service ansprechen, dann brauchen Sie schon nicht mehr am Service im Backend zu suchen, sondern eher auf dem Client oder dem Weg von Client zum Server.

So eine kleine Statusseite ist in wenigen Minuten erstellt. Sie müssen Sie nur auf jedem Service eine vorhandene Datei finden (oder eine kleine Datei dort platzieren), die ein Webbrowser laden und anzeigen kann. Idealerweise legt man eine kleine Datei an, die referenziert wird. (z.B.: ), die dann geladen wird. Andere Kandidaten sind z.B. die "\favicon.ico" oder eine andere Grafik aus dem Webangebot.

Beispieldatei

Und nun baue ich eine Datei, die diese verschiedenen Icons einfach in einer HTML-Datei einsammelt und dem Anwender z.B. als Tabelle anzeigt. Hier ein Beispiel, welches einen Exchange Server, Lync Server, DCs und einen Dateiserver abprüft. Teilweise nutze ich vorhandene Icons und manchmal mein eigenes OK-Icon, welches auf dem Server platziert wurde.

<html>
<head><title>Client Connectivity Test</title></head>
<body><h1>Cient Connectivity Test</h1>
<p>Bitte pr&uuml;fen Sie, dass alle Symbole sichtbar sind.</p> 

Wenn Sie sehen , wie einfach das ist, dann wäre es vielleicht eine nette Idee, wenn Provider und andere Anbieter auch ihren "Status" von Systemen einfach als Bild bereit stellen könnten, so dass der Anwender selbst gleich sieht was Probleme hat. Vor vielen Jahren habe ich mal eine Webseite des CERN in Genf gesehen, die diesen Status sogar öffentlich gemacht habe.

Anzeige

Ein Anwender sieht z.B. im Browser dann folgende Seite:

Man sieht hier die Seite, die ich aus dem Internet aufgerufen habe. Ich kann die "Icons" der MSXFAQ und Google erreichen aber die anderen Icons funktionieren nicht. In dem Fall ist das in Ordnung, da es sich um interne Ressourcen handelt, die eben nicht aus dem Internet erreichbar bin. Rufe ich die gleiche Datei aber im LAN auf, dann bekomme ich alle Icons angezeigt. Sollte aber z.B. der Proxy zum Internet nicht funktionieren, dann fehlen die Icons der externen Dienste.

Ablageplatz für die Statusdatei

Nun wollen wir so eine Seite natürlich nicht auf alle Clients verteilen, sondern ebenfalls "zentral" bereit stellen. Das birgt natürlich das Risiko, dass ein Clients nicht mal diese Seite erreicht und damit die Tests gar nicht ausführen kann. Das ist aber nicht sonderlich schlimm, weil ein Support dann einfach erst mal dieses auch vorhandene Problem löst und in vielen Fällen dann auch die Ursache für das eigentliche Problem gefunden hat. Hier ein paar Ideen

  • Intranet (http Zugriff)
    Jeder PC hat einen Browser und wenn nicht alles richtig durcheinander ist, sollte der Zugriff auf einen Webserver, sei er nun intern oder aus dem Internet, möglich sein. Funktioniert dies schon nicht, dann kann auch per Telefon recht schnell eine Fehlersuche erfolgreich sein, z.B. "IPConfig /Displaydns", "Ping server", "Telnet server 80" etc.
  • Dateiserver (z.B. netlogon)
    Alternativ bietet sich intern z.B.: die Ablage auf einem Dateiserver an. Der Client kann dann einfach per UNC-Pfad die Datei laden.
  • Gruppenrichtlinien
    Wer es mag kann natürlich auch die Datei auf den lokalen PC "verteilen", z.B.: per Gruppenrichtlinie, Softwareverteilung o.ä.. Sie sollten dann nur sicherstellen, dass die Datei auch nach einer Änderung wieder verteilt wird.

Je nach dem auf welchem Ort sie die Testdatei nun abgelegt haben, kann der Benutzer die Datei per Doppelklick im Windows Explorer oder Startmenü oder per Browser starten.

Weiterentwicklung

Ich habe absichtlich die Zusammenführung der Checks auf dem Client gemacht. Wenn ich nämlich per Browser auf einen Server gehe und dieser dann die "Erreichbarkeit" von diensten prüft, die Ergebnisse aufbereitet und mir zusendet, dann habe ich nur die Information dass dieser Server die Dienste erreichen bzw. testen kann. Ich bin aber nicht schlauer, ob auch ich diese Dienste erreichen kann.

Natürlich sind das alles nur sehr einfache Tests, zumindest solange ich per HTTP, FTP, FILE-URLs Bilddateien beziehe und anzeige. Wir haben aber nun ja alle gelernt, dass ein Browser schon lange mehr kann, als nur statischen HTML-Content mit Bildern anzuzeigen. Es gibt also viele Optionen, diese "Client Checks" entsprechend mit JavaScript, HTML5 o.ä. auszubauen. Denkbar sein.

  • Antworten vom Server
    Ein Server könnte die IP-Adresse des Clients, die Information ob er über einen Proxy gekommen  ist und andere Daten des Clients entsprechend aufbereiten und mit an den Client senden. In ASP., ASP.NET oder PHP sind solche Rückantworten sehr schnell programmiert und der Anwender kann dem Helpdesk entsprechende Hinweise geben. Überlegen Sie selbst was für einen Anwender einfacher ist: Eine Webseite anzusurfen oder in einer CMD-Box mit IPCONFIG seine IP-Adresse zu ermitteln ?
  • Authentifizierung
    Die "integrierte Authentifizierung lässt sich ganz einfach dadurch prüfen, dass eines der Bilder nicht "anonym" sondern erst nach Anmeldung erreichbar ist. Bei funktionierender Anmeldung (Kerberos, Integrated, o.a.) siehst der Anwender das Bild, ansonsten eben nicht
  • JavaScript, Silverlight u.a.
    Es dürfte für einen pfiffigen Entwickler sicher einfach sein, die "Tests" noch um andere Komponenten zu erweitern. Es muss ja nicht gleich ein JavaApplet sein, Auch HTML5, Silverlight etc. lassen vielleicht noch umfangreichere Tests zu, z.B.: einen TCP-Connect oder ICMP-Ping mit einer Anzeige des Ergebnisses. Das Skript müsste nach dem Test ja einfach nur per DOM die Ausgabe modifizieren.

Ich denke nicht, dass ich diese weiteren Tests addieren kann aber würde mich freuen, wenn andere Personen vielleicht ihren Anwendern (und ihrem Helpdesk) zusätzliche halbwegs automatisierte Prüfungen erlauben. Denn die meisten Clients können zumindest einen Webserver per IP-Adresse im gleichen Verbundnetz erreichen. Daher bietet es sich gerade zu an auch Firmenintern etwas wie "FixIt" anzubieten. Und wenn es keine HTML-Datei mehr ist, sondern eine ausführbare EXE, die dem Client eine Hilfestellung bietet, dann ist das auch in Ordnung.

Weitere Links