MSXFAQ RealTracking - Poor Admins 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:

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

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

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:

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.

 

 

Weitere Links

Keywords:Tracking RealTracking Messagetracking