Outlook Sniffer - Helfer im Hintergrund

Outlook ist ein erstklassischer "Personal Information Manager". Aber auch wenn die Informationen für den Anwender "persönlich" sind, so gibt es jede Menge Informationen, die Outlook auch ohne Hilfe des Anwenders verarbeiten kann. Dazu zählen:

Voraussetzung ist dabei aber immer, dass Outlook aktiv ist.

Achtung: Einige Nachrichten, z.B. Terminanfragen können auch durch Serverprozesse verarbeitet werden, wenn dies durch den Administrator (z.B.: für Ressourcen) aktiviert wird.

Einstellungen und Anzeigen in Outlook

In Outlook verbergen sich die Einstellungen an verschiedenen Stellen:

Hintergründe, Zeiten und Registrierung

Auch wenn es über den Prozess nicht viele Dokumente gibt, so scheint er per MAPI in Outlook darauf zu warten, dass Outlook "Idle" ist. Wobei nicht genau klar ist, wann Outlook "Busy" ist. Mein Outlook hat schon Quittungen verarbeitet, wenn ich gerade eine Mail verfasst habe. Umgekehrt scheint ein Abgleich mit dem Server (Offline Mode) die Verarbeitung auszusetzen. Wenn ich jedoch eine Quittung selbst öffne, dann ist das ein Startzeichen für Outlook, diese Quittung sofort zuzuordnen.

Die Zeit, mit der der Prozess zur Arbeit geht, lässt sich über die Registrierung beeinflussen

Windows Registry Editor Version 5.00
 
[HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook\Options\General]
"AutoProcessIdleTime"=dword:000001f4
"AutoProcessIdleTimeMax"=dword:000003e8

Ändert die Standardwerte von 30 Sekunden (Ruhezeit, ehe der Sniffer wieder aktiv wird) und 10 Minuten (maximale Zeit, die der Sniffer auf Leerlauf bei Outlook wartet) auf 1 Sekunde und 1 Minute. Damit werden eingehende Bestätigungen in den meisten Fällen umgehend verarbeitet. Dies hilft auch bei der Fehlersuche, wenn die Mails nicht verarbeitet werden. Die Standardwerte greifen immer dann, wenn Sie die Schlüssel einfach wieder löschen oder umbenennen. Sehr kurze Intervalle erhöhen die Belastung auf dem System. Andere Quellen schreiben dass der MAX-Timer hingegen eine Verzögerung angeben würde, ab wann Outlook wieder schaut, ob es Idle ist.

"Es darf nur einen geben" und die Kommandozeile

Es wäre fatal, wenn ein Benutzer auf mehreren Systemen Outlook startet und durch den Cached Mode mehrere Outlook-Systeme parallel die Quittungen verarbeiten und die Nachrichten im Posteingang oder Termine im Kalender verwalten würden. Daher sorgt Outlook dafür, dass nur eine Instanz auch wirklich die eingehenden Nachrichten verarbeitet. Das kann aber manchmal aus dem Tritt kommen. Daher kennt Outlook zwei Optionen für die Kommandozeile, um hier Vorgaben zu machen oder Altlasten zu bereinigen.

Aktuell habe ich noch nicht heraus gefunden, wo genau die Information steht, welches Outlook nun der aktuelle Sniffer ist.

IPM.Microsoft.SniffData

Es hat mich einige Zeit gekostet, in einem Postfach den vermutlich entscheidenden Eintrag für die Steuerung des Sniffers zu finden. Damit es nicht zu Doppelbearbeitungen kommt, müssen sich mehrere Outlooks bei der automatischen Verarbeitung von eingehenden Nachrichten abstimmen. Nur einer sollte die Arbeit durchführen.

MFCMAPI erlaubt den Blick in die Postfachstruktur und in einem Ordner, der einen Ebene über dem eigentlichen Posteingang aufgehängt ist.

Dort finden Sie die entsprechende Nachricht mit dem Betreff "Sniffer".

Leider habe ich auch keine weiteren Quellen, aber anscheinend hinterlegt sich der gerade aktuelle Client im Feld 0x6002001e. Dort steht der Computername des Clients, der gerade als "Sniffer" agiert. Allerdings konnte ich noch keine Details in Erfahrung bringen, wann ein Client hier einen bestehenden Eintrag ersetzt oder überschreibt.

PR_PROCESSED

Mit MFCMapi können Sie aber erkennen, welches Element durch den Sniffer schon verarbeitet worden ist. In meinem Beispiel öffne ich eine verarbeitet Quittung im Ordner "Gelöschte Objekte" und betrachte das PR_PROCESSED-Attribut der Mail

Damit ist klar, dass "Etwas" diese Mail gesehen und verarbeitet hat. Leider muss das nicht immer der Outlook Client gewesen sind. Das kann auch ein Blackberry Server, CDO oder anderer Agent sein. Durch diese Feld wird einfach verhindert, dass mehrere Clients das gleiche Objekt mehrfach verarbeiten. Beachten Sie aber, dass nicht jeder Client immer "online" arbeitet. Der Cached-Mode kann solche Aktualisierungen durchaus mehrere Sekunden verzögern und Clients mit lange Netzwerkelaufzeiten können Effekte verursachen.

Hilfe durch den Server

Zuletzt kann auch der Exchange Server oder ein Dienst auf dem Server bei der Verarbeitung mithelfen. Das ist für Quittungen noch unwahrscheinlich aber für Terminanfragen und Koordination kann der "Auto Accept Agent" diese Anfragen in Ressourcen Postfächern beantworten. Seit Exchange 2010 ist diese Funktion sogar in den Server komplett gewandert und per Ressourcen Postfächern eingeschaltet. Eine automatische Terminverarbeitung kann der Administrator aber auch für normale Postfächer aktivieren. Diese Funktion ist sogar für Terminanfragen by Default aktiviert.

Und dann haben wir noch Outlook Web Access, welches schon seit Exchange 2003 z.B. auch dafür gesorgt hat, dass bei neuen Terminen auch die Frei/Belegt-Zeiten aktualisiert wurden. Dies ist bei Exchange 2007/2010 nicht mehr erforderlich, wenn Outlook 2007/2010 auf den Concierge-Service des CAS-Servers zugreift und dieser live in die Kalender schaut.

Allgemeines Troubleshooting

Die ganze Arbeit des "Outlook Sniffers" wird durch Outlook erledigt. Damit ist auch klar, dass eine Fehlersuche am besten auf dem Client erfolgt, welcher sogar die passenden Optionen dafür bereit stellt. Siehe auch "841615 Description of the Calendar logging feature in Outlook". Über entsprechende Registrierungsschlüssel können Sie Outlook anweisen, seine Aktionen in eine Datei zu protokollieren:

Zuerst können Sie einfach über "Extras- Optionen - Erweitert" eine Protokollierung aktivieren:

Die gleiche Einstellung kann über eine Systemrichtlinie oder die Registrierung umgesetzt werden:

Windows Registry Editor Version 5.00
 
[HKEY_LOCAL_MACHINE\Software\Microsoft\Office\12.0\Outlook\Options\Mail]
"EnableLogging"=dword:00000001

Diese Einstellung sollten Sie nach der Fehlersuche aber wieder abschalten, das sie Performance auf dem Client kostet und die Protokolldateien eventuell vertrauliche Informationen enthalten.

Die Ausgaben landen in einer Datei, die per Default im lokalen TEMP-Verzeichnis des Benutzers landen:

\documents and settings\<username>\local settings\temp\logcalb###

Bei jedem Start legt Outlook eine neue Datei an und zählt die Nummer im Dateinamen entsprechend weiter hoch. Leider sind die Daten binär und können so einfach nicht ausgelesen werden. Microsoft verweist selbst darauf, dass die Daten nur durch PSS gelesen werden können.

Eventuell kann es auch eine Option sein mit Programmen wie ExInsight auf dem Server die Zugriffe genau anzuschauen.

Was sie noch prüfen können

Da wir alle nicht die Tools haben, um die Trace-Datei auszuwerten, müssen anderen Dinge für die Fehlersuche herhalten bzw. Checks, die bei der Fehlersuche helfen

regsvr32 OLE32.DLL
regsvr32 INETCOMM.DLL

Sonderfall: Message Recall

Outlook erlaubt es einem Absender, eine einmal versendete Mail wieder "zurück" zu rufen. Das ist natürlich nicht im SMTP-Standard irgendwo hinterlegt, sondern auch eine Funktion von Outlook und dem Outlook Sniffer. Es funktioniert daher nur mit:

Daher gibt es sehr viele Situationen, in denen der Rückruf natürlich nicht funktioniert z.B. wenn

Da Sie als Absender dies aber nicht alles wissen können, ist ein Rückruf nur bedingt zu gebrauchen.

Weitere Links

Keywords: Outlook Sniffer Quittungen Termine Anfragen