MSXFAQ RealTracking - Poor Administratoren Messagtracking

Dieses Projekt ist noch lange nicht "Fertig".

Mit der Funktion des Messagetracking im ECP (OWA) ist ein Teil der hier  beschriebenen Funktionen bereits erfüllt

Mit Exchange 2007 ist das Messagetracking aus meiner Sicht sehr viel schlechter geworden. Während man in Exchange 2000/2003 noch einfach eine Mail "nachverfolgen" konnte, führt dies mit Exchange 2007 zu einer wilden Klickorgie mit dem Message Tracking Center oder PowerShell Befehle. Dabei bleiben weitere große Probleme bestehen:

  • Tracking nicht über Systemgrenzen hinweg
    Das betrifft sogar Exchange 2003/2000, d.h. Mails die von Exchange 2007 nach Exchange 2003 gesendet wurden, könne nicht im gleichen Tool analysiert werden.
  • Kein Ende zu Ende Tracking
    So ist es auch auch nicht möglich, Auswertungen zu fahren, welche Mails wie lange unterwegs waren oder gar nicht erst angekommen sind, z.B.: weil Sie in einer Queue "stecken" oder in Poison gelandet sind.
  • Kein user-SelfTracking
    Schön wäre es natürlich auch, wenn die Anwender "ihre Mails" auch selbst nachverfolgen könnten, z.B.: über eine Weboberfläche.
  • Exchange GUI mit Problemen
    Ich konnte schon mehrfach sehen, dass ich eine Zeile markiert habe, aber beim weiter "Tracken" eine andere Mail in das Formular übernommen wurde. Wollte ich dann mit "zurück" wieder an die alten Daten, hat die MMC nur ein leeres Fenster angezeigt, dass die Daten ungültig sind. Also musste ich noch einen Schritt zurück und die Daten erneut abfragen.

All das ist nicht nur unschön, sondern besonders in größeren Firmen ein echtes Problem. RealTracking soll dies lösen, indem die Protokolldateien der verschiedenen Servern eingesammelt und in eine SQL-Datenbank importiert werden. Eine Auswerteschnittstelle erlaubt dann eine "AdHoc"-Suche nach bestimmten Mails.(Für Administratoren) oder die Anzeige der eigenen Korrespondenten. Je nach Ausbaustufe können auch Fremdsysteme (z.B.: das Relay in der DMZ oder anderer Mailserverserver im unternehmen ebenfalls eingebunden werden).

Aufgabenstellung

Mein Ziel war es daher, das Messagetracking mit Exchange 2007 aber auch anderen Systemen einfacher und effektiver zu gestalten. Da ich eher in der Microsoft Welt zuhause bin, bietet sich natürlich SQL dafür an. Ein Collector-Prozess sammelt dazu die Message Tracking Logs ein und schreibt diese in die Datenbank, welche dann mit SQL-Reporting Services ausgewertet werden kann. Technisch ist das System so ausgelegt, dass auch die Logdateien von anderen Systemen mit in die Datenbank eingebracht werden können. Das System hat drei Aufgabenstellungen

  • Admintracking
    Das erste Ziel ist dem Administrator ein Werkzeug an die Hand zu geben, um den Weg einer Mail durch das System zweifelsfrei nachvollziehen zu können.
  • Usertracking
    Den gleichen Report könnte natürlich auch ein Benutzer selbst ausführen, wenn er dies will.
  • Statistik
    Wenn die Daten schon in der Datenbank sind, dann kann man natürlich auch Statistiken darauf extrahieren, z.B.
    • Laufzeit von Mails (End2End Monitoring)
    • Top Sender und Empfänger
    • letzte gesehene Mail nach Absender (ungenutzte Postfächer)
    • letzte gesehene Mail nach Empfänger (tote Postfächer, welche mailaktiven PublicFolder werden genutzt.)
    • Turn Around: Wann kommt die "Gelesen/Zugestellt"-Quittung auf eine Mail wieder herein ?, wenn dies ausgelesen werden kann.
    • Suche nach Public Folder Replication Messages und Probleme
  • Fehlersuche
    Wenn die Daten alle erfasst werde, dann kann man natürlich aus den Daten auch Fehler extrahieren: , z.B.
    • Liste der unzustellbaren nach Empfänger
    • Liste der unzustellbaren Mail nach Absender
    • Mails in Transit
      z.B. gibt es zu jeder Mail auch den Zustellpunkt oder ist sie "verschwunden" oder noch in einer Queue

Sicher kann man aus den Daten noch andere Informationen extrahieren. Aber primär ist das "Message Tracking" wichtig und hier möchte ich mich gerne an den "Tracking-Seiten" der Paketzusteller orientieren. Die machen sehr gut vor, wie ein Paket verfolgt werden kann. Hier mal ein Status von DHL uSA und DHL Deutschland.

DHL Tracking

Und auch FedEx kann schöne Berichte erstellen:

Fedex Tracking

Etwas kompakter aber nicht weniger anschaulich sind die DPD-Berichte:

Details zum Mails tracken

Als ich über Realtracking nachgedacht habe, habe ich mir die Funktion sehr einfach vorgestellt. Aber wie so oft steckt der Teufel im Details, denn es reicht nicht, einfach nur die Message Tracking Logs von allen Servern zusammen zu kopieren. Das wäre schnell eine große kaum zu nutzende Datenmenge geworden. Im Gegensatz zu einem Postpaket kann eine Mail auch mehrere Empfänger haben, d.h. wird unterwegs "aufgespittet" und kann dann natürlich auch unterschiedliche Wege laufen. Wenn Connectoren und Server nicht erreichbar sind, kann sogar ein Rerouting auftreten, so dass die gleiche Mail im Extremfall sogar ein zweites Mal über den gleichen Server laufen könnte (Nicht mehr bei Exchange 2007). Im Messagetracking sind aber auch Mails an BCC-Empfänger vorhanden. Auch kann eine Mail an einen Verteiler im Messagetracking anders ausgegeben werden.

Funktionsprinzip

Dreh und Angelpunkt der Lösung ist eine zentrale SQL-Datenbank, in welche die verschiedenen Quellen ihre Daten ablegen. Da es hier leider keinen Standard gibt, ist es Aufgabe des Sammelprozesses, der idealerweise auf dem Quellserver selbst läuft, die lokalen Daten einzusammeln, von Ballast zu befreien und die Ergebnisse an den SQL-Server zu melden. Es gibt daher Sammelprozess für Exchange 2000/2003 und Exchange 2007. Weitere Prozesse sind denkbar. Die Sammeldienste lesen einfach ähnlich einem "TAIL" das Ende der Protokolldateien und schreiben Änderungen im passenden Format an die Datenbank melden. Eine Konvertierung auf dem SQL-Server wäre zwar als zentraler Ansatz interessant, aber dabei würden dann mehr Daten übertragen. So kann man sich auf die einzelnen Server und Connectoren beschränken. Voraussetzung ist, dass alle Agenten immer die MessageID, Absender und Empfänger mitliefern und diese unverändert bleiben.

Für die Nachverfolgung ist es wichtig den Start und Endepunkt jeder Mail zu ermitteln. Leider ist es nicht immer so, dass die Logeinträge in der zeitlich korrekten Reihenfolge in der Datenbank landen.

Datenimport

Ein Sammelprozess liest die Trackinglogs des Servers ein. Dabei wird pro Verbindung ein Record generiert. Wenn die Quelle mehrere Empfänger in einem Datensatz zusammenfasst, dass ist es Aufgabe des Prozesses daraus mehrere eigenständige Datensätze zu machen. Um später die Wege verfolgen zu können, muss ein eindeutiges Kennzeichen gefunden werden und die Quelle und das Ziel. Die MessageID ist hierfür prädestiniert. Da diese aber mehrfach vorkommen kann, muss bei späteren Auswertungen zumindest auch der Zielempfänger enthalten sein. Die zu speichernden Daten sind neben dem Zeitstempel und dem Server, auf dem der Eintrag angelegt wurde auch die Quelle und oder das Ziel bei einer weiteren Übertragung. Dann gibt es noch Einträge die lokale Aktionen (z.B. Routing, Namensauflösung etc.) wiedergeben.

Für die Suche ist es natürlich auch wichtig, eine Art Steckbrief für jede Mail anzulegen, in dem Absender und Empfänger, Startzeit und Endezeit, Größe und Betreff und andere verfügbare Details vorhanden sind. So ist eine schnelle Suche möglich.

Allerdings muss die Logik hier berücksichtigen, dass die Daten am Anfang noch nicht komplett ist.

Eine Schlüsselfunktion ist daher die Bestimmung des Entry und Exit-Punkts. Und hier hilft dann die Suche nach dem Homeserver des Benutzers oder den Empfang oder Versand über einen Connector. Zudem muss hier sichergestellt werden, dass eine Mail an einen Verteiler entsprechend aufgeschlüsselt wird.

Anzeige

Um den Aufwand einer Softwareinstallation auf den Clients zu ersparen, ist eine webbasierte Auswertung effektiver, bei der der Anwender "seine" Mails suchen und entsprechend nachtracken kann. Über eine gewöhnliche Suche können Mails gefiltert werden und dann über die Kombination aus MessageID und Empfänger der Weg verfolgt werden. Besonders berücksichtigt werden müssen Mails mit BCC Einträgen, die so bekannt werden könnten. Eine Mail an einen Verteiler kann nur über die Einzelempfänger aufgelöst werden.

Bilder (?)

 

 

 

 

 

SQL-Design

Die Daten werden in mehreren SQL-Tabellen gehalten:

  • Inventory
    Enthält alle Kopfdaten der Mail wie Absender, Empfänger, Betreff, Größe, MessageID
  • Bewegungsdaten
    Enthält zur MessageID die Events auf den verschiedenen Servern.
    Datum/Zeit, Server, Event, Target (Local, remoteservername,Postfach)

Es kann durchaus ein, dass ein Server die Mail überträgt und Bewegungsdaten meldet, ehe der Server, bei dem die Mail zuerst ankommt, schon das Inventory angelegt hat. Daher muss jeder Agent zuerst prüfen, ob es schon eine Mail mit der MessageID gibt und notfalls die Daten eben eintragen. Allerdings kann das auch bedeutet, dann dass die Empfängerlist nicht komplett ist, da die Mail schon "aufgeteilt" wurde. Entsprechen muss hier der Inventory Datensatz erweitert werden. Letztlich stehen in dem Datensatz dann alle Empfänger aufgeschlüsselt drin.

Weitere Ideen

"SelfTracking". E2003/2007 TrackingLogs in SQL und ASPX für user zum selbst auslesen
SQL realTracking ? als reporting/Basis-Plattform
- Abrechnung auf Traffic
- Alarmierung bei Overtraffic
- Tracking der Datenflüsse
- Optional TransportAgent für Details
Selftracking
- Mit Anzeige der "Laufzeit und Größe der Mails"
Von, Nach, MessageID, Subject, Größe, Verweilzeit

Exchange 2010 "Message Latency" mit auswerten.

  • Mail"Datenblatt"
    Alle Empfänger (sowohl direkte (VL) als auch indirekte (BCC/CC) aufschlüsseln.
    VL nur "zur Info"
    Hinter jedem Empfänger steht dann DELIVERED, QUEUED, NDR
    Status eventuell ermitteln statt in DB speichern.
    Endstatus, Laufzeit
  • Queues Mails
    Wenn eine Mail in einer Warteschlange noch auf die Zustellung oder Weiterleitung wartet. dann wäre es wünschenswert den letzen Zustellversuch zu ermitteln und den dazu gehörigen Status anzuzeigen.

 

 

Weitere Links