Mailflow

Dieses Skript ist noch nicht fertig zur Veröffentlichung - Sorry

Für Exchange 2007/2010 hat Microsoft selbst ein sehr umfangreiches VBScript namens "ProcessTrackingLog.vbs" veröffentlicht

DE http://blogs.technet.com/b/exchange_de/archive/2011/12/07/updated-process-tracking-log-ptl-tool-for-use-with-exchange-2007-and-exchange-2010.aspx
US: http://blogs.technet.com/b/exchange/archive/2011/12/07/updated-process-tracking-log-ptl-tool-for-use-with-exchange-2007-and-exchange-2010.aspx

Das Skript Mailflow ist auf Exchange 5.5, 2000 und 2003 Message Tracking Logs spezialisiert und ermittelt bezogen auf den Server das Volume der übertragenen Mails. Dabei wird zwischen "gleicher Server", "Innerhalb der Organisation" und Internet unterschieden. Es hilft mir dabei, Konsolidierungsüberlegungen mit Daten zu untermauern. Exchange 2003 und noch mehr 2007 sind in Verbindung mit dem Cached Mode ja geradezu prädestiniert, weniger gut verfügbare Server an zentralen Orten aufzustellen und Niederlassungen entsprechend der Bandbreite ohne lokalen Exchange Server zu betreiben. Das spart nicht nur Hardware (Server, Bandlaufwerke, Switchports, uSV) sondern auch Lizenzen (Windows, Exchange, Backup, Antivirus) und Kosten für Betrieb, Überwachung, Pflege. Zudem lohnen sich bei wenigen Servern weitere Anstrengungen bezüglich Verfügbarkeit.

Datenerhebung

Für eine seriöse Aussage zum Zentralisierungspotential muss man Daten beisteuern, die die Verwendung durch die Anwender belegen. Wenn in einer Niederlassung Gigabytes von Schreibtisch zu Schreibtisch per Mail übertragen werden, dann ist dies sicher kein guter Ausgangspunkt für einen Betrieb ohne lokalen Exchange Server. Viele dezentrale Server erzeugen aber auch Zusatzverkehr für die Replikation von öffentlichen Ordnern und bei Exchange 5.5 kommt der Verzeichnisabgleich dazu.

Stellen Sie daher sicher, dass das Nachrichtentracking auf ihren Servern aktiv ist, um die folgenden Auswertungen zu fahren. Exchange protokolliert dann jede Mail  (nicht den Inhalt, nur die Routinginformationen) in Textdateien. Anhand dieser Daten kann man aber sehr einfach den Mailfluss ermitteln

  • Welche Mails werden „lokal“ zugestellt
    d.h. werden bei einem Server vor Ort nicht über das WAN übertragen und bei einem zentralen Ansatz mindestens zweimal übertragen
  • Welche Mails bleiben „in der Firma“
    Diese Mails werden eventuell mehrfach zu anderen Servern gesendet und sparen Bandbreite, wenn Postfächer auf dem gleichen zentralen Server sind
  • Internet
    Diese Mails gehen quasi immer über die Leitungen zum Gateway und dann zum Internet

Auch wenn keine 100%tige Abschätzung damit möglich ist, so kann man anhand der Menge der „lokalen Mails“ ermessen, welches Volumen bei einem zentralen Ansatz hinzu kommen würde. Gesondert kann man dabei die Mails für öffentliche Ordner und den Exchange 5.5 Verzeichnisabgleich behandeln.

Grenzen und Möglichkeiten

Das Skript wertet das vorhandene Messagetracking des lokalen Servers aus, um Daten für die Menge der direkt lokal zugestellten Mails und Ziele auf anderen Servern oder dem Internet zu erhalten. Aus Vereinfachungsgründen wurde das Skript nur auf den lokalen Server bezogen, was zu Einschränkungen führt, die Sie können sollten:

  • Mehrere Server in einer Site
    Diese Mails werden als "Intra-Org" gewertet, obwohl sie ja "Same-Site" sind. Die Aussagen des Skripts sind also schlechter als bei der Auswertung eines einzelnen Servers einer Niederlassung. Denkbar wäre eine Erweiterung um anhand des Empfängers den "Homeserver" bzw. die Home-Site zu finden.
  • Erkennung "SameOrg"
    Das Skript muss auswerten, welche Mails die Organisation verlassen. Denkbar wäre eine Suche im Active Directory, was aber mit Exchange 5.5 nicht immer möglich ist. Zudem gibt es oft Kontakte oder User mit Weiterleitungen, die eine zusätzliche Erkennung erforderlich machen. Das Skript vereinfacht die Erkennung, in dem Sie eine Liste der internen SMTP-Domains im Skript hinterlegen müssen und Empfänger dieser Domains oder mit einer X.400-Adresse als "SameOrg" angesehen werden. Nebenbei kann ich so Logs von Kunden ohne Verbindung zum Server offline auswerten.
  • Keine Clientzugriffe und Verweise
    Das Skript wertet nur das Messagetracking aus. Man kann damit also nicht den Zugriff von Clients auf Postfächer oder öffentliche Ordner sehen. Das bringt eine unschärfe mit herein, da andere Postfächer nicht über den Cached Mode auf dem Client vorgehalten werden und nur öffentliche Ordner als Favoriten im Cached Mode enthalten sind. Andererseits entlastet ein eingesparter Server die Verbindung durch den Wegfall der Public Folder Replikation.
  • Single Instance
    Wenn ein Mitarbeiter eine Mail an mehrere Personen sendet, so wurde die Mail von Exchange mittels "bifurcation" aufgeteilt. Mit einem zentralen Server wird die Mail einmal vom Client an den Server übertragen und dort erst aufgeteilt, was zu Einsparungen führt. Andererseits werden lokale Mails eventuell mehrfach im Log gezählt, obwohl sie nur einmal im Store liegen, was die Zahlen verfälscht.
  • Public Folder Replikation nicht separat
    Anhand des Messagetracking kann man nur anhand der Absender, Empfänger und eventuell dem Betreff Rückschlüsse auf öffentliche Ordner und deren Replikation machen. Eine getrennte Aufschlüsselung findet nicht statt.
  • Kein Exchange 2007/2010
    Das Skript kann nur Exchange 5.5-2003 Logs auswerten, da das Messagetracking sich bei Exchange 2007/2010 geändert hat.
  • Single Server
    Die Auswertung bezieht sich genau auf den einen betrachteten Server. Das Skript klappert also nicht alle Messagetrackings aller Server ab. Bei den meisten Projekten zur Konsolidierung von Exchange geht es aber meist auch nur um die im Feld einzeln aufgestellten alten Exchange 2003 Server, deren Postfächer konsolidiert werden sollen.

Die Auswertung kann natürlich nur die Messagetrackinglogs nutzen, die noch vorhanden sind. Wenn man längere Aussagen benötigt, dann könnte man z.B. MBReport derart erweitern, dass damit die Bestandsmails im Postfach selbst auf ihre Absender, Empfänger, Datum und Größe ermittelt und berichtet. Hier käme dann aber die ungenauigkeit hinzu, dass Quittungen und Mails gelöscht werden.

Messagetracking Events und Partner

Exchange 5.5-2003 hat entgegen Exchange 2007 lokale Mails noch direkt zugestellt, so dass es auch einen eigenen Event dafür gibt. Das macht das Skript etwas einfacher. Genau genommen sind nur drei Events im Messagetracking relevant.

  • Event 1000: Sender und Empfänger auf gleichem Server
  • Event 0: Eingehend von Server, Connector oder Gateway
  • Event 7: Ausgehend von Server, Connector oder Gateway

Siehe dazu auch "821905 Ereignis-IDs in Exchange Server 2003 für die Nachrichtenverfolgung"

Lokale Mails sind also sehr einfach von Nachrichten für und von anderen Servern zu unterscheiden. Das Skript muss also nur noch auswerten, ob der Empfänger innerhalb der Organisation oder extern (Internet) ist. Um nun nicht für jeden Empfänger oder Absender einer Mail das Active Directory oder den Exchange 5.5 Verzeichnisdienst fragen zu müssen (CPU-Last), nutze ich die Liste der SMTP-Domains, die im Skript hinterlegt wird.

Im Message Tracking Log sind folgende Felder interessant:

Feld Exchange 5.5 Exchange 2000/2003

Even-tID

2

9

Mailgröße in Bytes

9

13

Empfänger durch LF getrennt

14

8

Datum/Zeit

3

1/2

Funktion

Ehe Sie das Skript starten, müssen Sie daher im Skript selbst die lokalen Domänen hinterlegen, damit das Skript korrekt zwischen externen und internen Absendern und Empfängern unterscheiden kann.

 

 

 

 

Ausgabe

Primäres Ziel des Skripts ist die Ermittlung der Verkehrslasten. Trotzdem kann es natürlich auch interessant sein, welche Datenvolumen in der Summe und nach Zeiten übertragen werden. Auch wenn es möglich wäre habe ich aber gezielt auf Auswertungen auf Benutzerlevel oder Partnerrelationen o.ä. verzichtet, da Sie für eine Konsolidierung nicht relevant sind. Folgende Daten werden ausgegeben.

  • Lokale Mails (Anzahl und Summe)
  • Remote eingehende Mails (Anzahl und Summe)
  • Remote ausgehende Mails (Anzahl und Summe)

 

 

 

 

Weiterentwicklung

Die aktuelle Version ist auf Exchange 2003 und einen Server beschränkt. Natürlich würde ich liebend gerne beim Start erst eine Liste der Datenbanken mit der Zuordnung zur Routinggruppe oder AD-Site generieren und dann die Empfänger einsammeln und ebenfalls einer Routinggruppe bzw. AD-Site zuordnen. Dann könnte Das Script noch genauer erkennen, welche Verkehre nicht nur lokal auf dem Server und Remote sind, sondern sogar zwischen der gleichen Routinggruppe/AD-Site, der Organisation und dem Internet unterscheiden.

Weitere Links