Es hilft nichts, der Troubleshooter ist nun gefragt. Am Anfang jedes Troubleshootings steht eine umfassende Bestandsaufnahme der Problematik:

• Wie äußert sich das Problem?
• Welche Systeme oder Teilsysteme sind betroffen?
• Ist nur ein System oder sind mehrere gleichartige Systeme betroffen?
• Ist nur ein Benutzer oder sind mehrere Benutzer, die mit dem gleichen System arbeiten, betroffen?
• Gab es kürzlich Änderungen am betroffenen System?
• Wann ist das Problem zum ersten Mal aufgetreten?
• Ist das Problem beliebig reproduzierbar?
• Gibt es Fehlermeldungen oder lassen sich Informationen aus Log-Dateien ableiten?
• Hat der Benutzer weitere Informationen, bzw. kann er den Prozess, der zum Problem führte, beschreiben?
• Auf welchem Patchlevel (BIOS, Firmware, Betriebssystem, Anwendungen) befinden sich die betroffenen Systeme?

Je sorgsamer und detaillierter der Troubleshooter diese Fragen beantworten kann, um so leichter fällt ihm die Fehleranalyse. Alle gesammelten Informationen fließen beim Troubleshooter zusammen. Aufgrund seiner Erfahrung kann er sich meist einige Fragen schon selbst beantworten. Jedoch sollte er bei der kleinsten Unsicherheit eine Frage lieber zweimal stellen, als dass eine wertvolle Information verloren geht oder dass er aufgrund einer Fehlannahme nicht voran kommt.

Aus den gesammelten Informationen lassen sich Hypothesen ableiten, welche Ursache oder welche Ursachen zum Problem geführt haben könnten. Mit verschiedenen Methoden, die in Teil 2 dieses Artikels beschrieben werden, kann der Troubleshooter nun jede der aufgestellten Hypothesen entweder bestätigen oder widerlegen – so lange, bis das Problem gelöst ist.

Ganz wichtig: Bevor der Troubleshooter aktiv in laufende Systeme eingreift, ist eine Datensicherung des aktuellen Standes angesagt. Nichts ist schlimmer, als wenn sich durch ein Troubleshooting die Gesamtsituation verschlechtert oder ganz und gar Daten verloren gehen. Der Troubleshooter kann mit ruhigem Gewissen seiner Arbeit nachgehen, wenn er jederzeit bereit und dazu fähig ist, auf den Stand der letzten Datensicherung zurückzugehen.

Wird fortgesetzt…

Wie schon im Artikel Troubleshooting von Druckerproblemen beschrieben, ist es auch beim Troubleshooting von E-Mail-Problemen wichtig, die beteiligten Teilsysteme und die Wege, die eine E-Mail vom Sender zum Empfänger nimmt, genau zu kennen. Typische Teilsysteme, die beim Versenden und Empfangen von E-Mails in einer Microsoft-Umgebung zusammenspielen, sind:

• Outlook-Client
• Exchange-Server
• Mail-Gateway / SMTP-Smarthost / SMTP-Relay-Server
• Spam-Filter

Bei E-Mail-Problemen (d. h. eine Nachricht, die A abschickt, kommt nicht bei B an) hat es sich für den Administrator bewährt, sich selbst in die Lage der E-Mail zu versetzen und schrittweise die beteiligten Systeme zu durchlaufen. Dabei werden Informationen gesammelt, die anschließend analysiert werden.

Systematisches Vorgehen beim E-Mail-Troubleshooting:

• Zunächst sollte versucht werden, einem internen Teilnehmer eine E-Mail zu schicken, um eine Fehlkonfiguration des Exchange-Servers  auszuschließen.
• Gelingt der Versand einer E-Mail an einen internen Teilnehmer, kann davon ausgegangen werden, dass die Kommunikation zwischen Outlook-Client und Exchange-Server funktioniert.
• Über eine Telnet-Sitzung kann direkt über das Mail-Gateway bzw. den SMTP-Smarthost eine E-Mail verschickt werden. Funktioniert dies, sollte die Schnittstelle zwischen Exchange-Server und Mail-Gateway genauer untersucht werden.
• Schließlich kann über eine Telnetsitzung auch direkt eine E-Mail in den Mail-Server des Empfängers eingeben werden (Hostname bzw. IP-Adresse des Empfängerservers ergeben sich aus den MX-Einträgen der Empfängerdomain). Bringt diese Verfahrensweise Erfolg, hat liegt vermutlich ein Problem mit dem Mail-Gateway vor.

Sammeln von Informationen:

• Nachricht selbst: Header-Informationen
• Outlook-Client: Fehlermeldungen des Clients, Windows-Eventlogs
• Exchange Server: Exchange-Logs, Message Tracking Center, Windows Eventlogs
• Mail-Gateway: Server-Logs

Oft sind vermeintliche E-Mail-Zustellungsprobleme lediglich Effekte der Spamfilterung oder des Virenschutzes. Beispielsweise können Nachrichten teilweise mehrere Stunden verzögert eintreffen, wenn das Greylisting-Verfahren zur Spamfilterung eingesetzt wird. Fehlende Anhänge sind oft im MIME-Filter des Mail-Gateways zu finden.

Über Echo-Mails (z. B. an echo@tu-berlin.de) lässt sich auf schnelle und einfache Weise prüfen, ob alle beteiligten Systeme korrekt zusammenarbeiten.

Ein Grund dafür könnte sein, dass Drucken ein Prozess ist, der sich über fünf oder mehr Systeme erstrecken kann: In einer Citrix-Umgebung mit Netzwerkdruckern beispielsweise wären das der Benutzer selbst, der Client-Computer, der Citrix-Server, der Druckserver und nicht zu vergessen der Drucker.

Beim Troubleshooting von Druckerproblemen ist deshalb die Identifizierung des fehlerhaften Systems besonders entscheidend. Durch die Ausschlussmethode kann man der Ursache schnell auf den Grund kommen. Fragen, die zur Lösung führen, sind folgende:

• Hat ein anderer Benutzer bei Anmeldung über den gleichen Client-Computer am gleichen Citrix-Server bei Benutzung des gleichen freigegebenen Druckers auch Probleme? Wenn ja, kann der Benutzer als Fehlerquelle ausgeschlossen werden. Wenn nein, handelt es sich höchstwahrscheinlich um ein Profilproblem.
• Hat der betroffene Benutzer bei Anmeldung über einen anderen Client-Computer am gleichen Citrix-Server bei Benutzung des gleichen freigegebenen Druckers auch Probleme? Wenn ja, kann der Client-Computer als Fehlerquelle ausgeschlossen werden. Wenn nein, ist der Fehler im Client-Computer zu suchen.
• Hat der betroffene Benutzer bei Anmeldung über den gleichen Client-Computer am gleichen Citrix-Server bei Benutzung eines anderen freigegebenen Druckers auch Probleme? Wenn ja, kann der Drucker bzw. die Druckerkonfiguration als Fehlerquelle ausgeschossen werden. Wenn nein, sollte der Drucker genauer untersucht werden.
• Hat der betroffene Benutzer bei Anmeldung über den gleichen Client-Computer am gleichen Citrix-Server bei Benutzung des gleichen Druckers, der aber über einen anderen Druckserver freigegeben ist, auch Probleme? Wenn ja, kann der Druckserver als Fehlerquelle ausgeschlossen werden. Wenn nein, sollte der Administrator prüfen, ob die Einstellungen auf dem Druckserver für den betroffenen Drucker korrekt sind.

Entscheidend für das Troubleshooting ist, systematisch vorzugehen, schrittweise das Problem zu isolieren und nach und nach  durch die Ausschlussmethode die funktionierenden Teilsysteme als Fehlerquelle auszuschließen. So kommt man dem Rätsel mit Sicherheit auf die Spur. Wichtig: Immer nur eine Variable ändern!

In Windows-Netzwerken haben sich zudem die folgenden Vorgehensweisen bei der Administration von Druckern und Druckservern bewährt:

• IP-Adressen in den TCP/IP-Ports auf dem Druckserver niemals mit führenden Nullen eingeben!
• Niemals einen Netzwerkdrucker einfach durch einen anderen mit gleicher IP-Adresse ersetzen! Besser ist, den freigegebenen Drucker inklusive Port auf dem Druckserver zu löschen und für den neuen Drucker neu zu erstellen.
• Die Druckertreiber, die auf dem Druckserver und auf Clientrechnern (bzw. Citrix-Servern) verwendet werden, müssen unbedingt identisch sein!