PST Capture Tool

Ende Januar 2012 hat Microsoft ein Tool veröffentlicht, welches schon im Sommer 2011 (http://blogs.technet.com/b/exchange/archive/2011/07/05/coming-soon-pst-capture-tool.aspx) angekündigt war. Es sammelt mit einem Agenten von Clients lokal liegende PST-Dateien ein und importiert diese auf dem Server in das Postfach oder das Exchange 2010 Archivpostfach des Mitarbeiters.

Microsoft Exchange PST Capture 2.0
http://www.microsoft.com/en-us/download/details.aspx?id=36789
Download des Servers (ca. 11MB und der Agenten für 32/64bit (ca. 600 kb)

Funktionsweise

Dazu installieren sie auf einem Windows 7 PC oder Windows 2008 Server das Tool, welches dann über einen TCP-Port Verbindungen der ebenfalls zu verteilenden Agenten annimmt. Die Agenten "pollen" (Default jede Minute) quasi den Server nach Aufträgen ab. Der Server steuert also die Client indirekt und spricht nicht selbst die Clients aktiv an.

Der Client sucht lokal nach PST-Dateien (anhand der Erweiterung) und meldet diese an den Server. Der Administrator kann dann auf dem Server die gefundenen PST-Dateien zum Import auswählen. Sobald der Client diesen Auftrag gefunden hat, dann kopiert er die Datei über die TCP-Verbindung (mit Kompression) auf den Server, der die Daten annimmt und wieder lokal ablegt.

Der Client sprich mit dem Server über einen definierten Port (Default: 6674, änderbar). Bei der Installation des Client muss der Server als IP-Adresse oder Name und der Port angegeben werden. Es gibt keinen SPN oder eine andere Funktion, damit die Client "alleine" einen Server für den Import findet. Trotzdem muss der Client Mitglied der Domäne sein. Planung bei der Benennung (z.B. DNS-Alias) ist ratsam. Auch der Port muss eventuell in Firewalls zugelassen werden. Die Installation auf dem Client kann unattended erfolgen. die Parameter für den Server und Port sind dann anzugeben:

msiexec /i PSTCaptureAgent.msi /q CENTRALSERVICEHOST= SERVICEPORT=

Nach der Übertragung des PST an den Server entfernt der Client diese PST aber nicht. Es wird nicht verhindert, dass der Anwender weiterhin die PST verwendet. Sie sollten daher z.B. per Gruppenrichtlinien sicherstellen, dass die Anwender keine PST mehr anlegen oder verwenden können.

Alternativ kann eine PST-Datei auch von einem UNC-Pfad importiert werden. Ideal, wenn z.B. PST-Dateien entfernter Standorte per USB-Festplatte in die Zentrale transportiert werden.

Im letzten Schritt nutzt der Service das ebenfalls installierte Outlook 2010 (64bit !), um die PST-Datei in das Postfach oder Archivpostfach des Anwender zu importieren. Sollte Microsoft mit Outlook 64bit das "Supported Statement" geändert haben ?

"Outlook Object Model simply automates the Outlook.EXE process and is not supported to run from a service application (Windows Services and ASP.NET applications should not use OOM)"
Quelle: http://blogs.msdn.com/b/mstehle/archive/2007/10/03/fyi-why-are-mapi-and-cdo-1-21-not-supported-in-managed-net-code.aspx

Soweit ist das alles kein Hexenwerk und es gibt eine ganze Menge von Blog-Artikeln beschreiben mehr oder weniger ausführlich die Installation mit umfangreichen Bildern. Die folgende Link-Liste liefert einen Ausschnitt:

Debugging

Aber als ich selbst PSTCapture einsetzen musste, galt es natürlich erst mal den Fehler zu finden, wenn das Programm nicht funktioniert wie erwartet, dann muss man doch hinter die Kulissen schauen.

Schaut man in das Programmverzeichnis, dann finden sich dort u.a. DLLs und Programm, die mit den Namen "RedGate" verknüpft sind. Sehr schnell wird offenbar, dass Microsoft diese Software nicht selbst entwickelt, sondern anscheinend aufgekauft hat. RedGate hatte aber auch im Mail 2012 immer noch eine Knowledgebase, die ein paar Hinweise enthält.

Als Datenbank nutzt das Programm eine "SQLite"-Datenbank, was sicher auch so nicht bei Microsoft passieren würde. Die Datenbank liegt in "C:\ProgramData\Microsoft\Exchange\PST Capture\data.db". Dort musste aber bislang noch nie rein schauen.

Gute Dienste leitet auch das Programm "Process Monitor" (Sysinternals), weil es damit auch verrät, wo das Programm eine ausführliche Protokolldatei hinterlegt.

C:\ProgramData\Microsoft\Exchange\PST Capture\Logs\PST Capture Service

Der Inhalt sieht u.a. wie folgt aus.

11:29:28.169|Verbose|PstPasswordGenerator|4  |Bypassing password
11:29:28.169|Trace  |DBImportFile        |4  |Saving 7 False Importing C:\Archiv.pst
11:29:28.185|Debug  |ImportListImporter  |7  |Importing C:\Archiv.pst from C:\PST-Capture\PSTstaging\<guid>.pst
11:29:28.185|Info   |PstToolImporting    |7  |Import of PST file C:\PST-Capture\PSTstaging\<guid>.pst starting
11:29:28.185|Debug  |PstExImporter       |7  |Opening /o=msxfaq/ou=paderborn/cn=recipients/cn=User/guid=2fa6bafe-cec9-43ee-a990-261d9e1c4992 on server srv01.msxfaq.com'
11:29:28.185|Debug  |PstToolImporting    |7  |Logging onto mapi with User msxfaq\svc-pstcapture
11:29:28.185|Error  |PstToolImporting    |7  |Import of 'C:\PST-Capture\PSTstaging\<guid>.pst' did not complete
System.Exception: Error opening mailbox User@msxfaq.de 
---> System.Exception: Central service User (msxfaq\svc-pstcapture) doesn't have a mailbox so we can't logon to exchange
   at RedGate.PSTImporterForExchange.ImportEngine.PstExchangeImporter.GetMapiProvider(IActiveDirectoryService activeDirectory)
   at RedGate.PSTImporterForExchange.ImportEngine.PstExchangeImporter.OpenMailbox(ImportOptions options, Boolean& usingArchive)
   --- End of inner exception stack trace ---

Sollte der Import also nicht wie erwartet funktionieren und die GUI-Ausgabe nicht viel Details offerieren, dann ist der Blick in das Logfile die erste Stelle, um den Fehler genauer einzukreisen. Vor allem wenn Sie wissen, dass die GUI letztlich nur die Datenbank befragt, in welche der Dienst seinen Status hinterlegt.

Häufige Fehler

Da der Importprozess letztlich mit Outlook die PST-Datei öffnet und importiert und dazu eine Dienstkonto benötigt, sollten sie die gängigen Fehler können.

  • Dienstkonto ist ein administratives Konto
    Bedenken Sie, dass ein Administrator manchmal sogar weniger darf als ein normaler User. Denn ACLs können auch ein "DENY" und genau das ist bei Exchange z.B. für Domänen Administratoren angewendet.
  • Dienstkonto fehlen Rechte
    Aber ganz als "normaler User" kann das Dienstkonto natürlich nicht agieren. Es muss schon die Vollzugriffs-Rechte auf die Postfächer haben, auf denen letztlich importiert wird.
  • Dienstkonto hat kein Postfach oder Postfächer sind verborgen
    PSTCapture verwendet Outlook und Outlook kann Postfächer oft nur finden, wenn das Konto nicht "versteckt" ist. Das sollte normal aber kein Problem sein, da PSTCapture sich mit dem "LegacyExchangeDN" verbindet und das der einzige offizielle Weg ist, auch auf ein verstecktes Postfach zuzugreifen.
  • GPO unterbindet PST-Verwendung
    Viele Firmen möchten die PST-Dateien "los" werden und starten dabei mit einer Gruppenrichtlinie, die den Einsatz von PSTs verhindert. Das ist für die Desktops der Mitarbeiter durchaus sinnvoll, um Zugriffe auf die PST-Dateien zu unterbinden, die demnächst importiert werden sollen. Allerdings sollte diese GPO nicht auf den Benutzer oder Computer wirken, auf dem Sie mit dem PSTCapture-Tool die eingesammelten PST-Dateien importieren wollen.
  • Zielpostfach hat kein Archiv
    Eigentlich logisch aber wenn Sie PST-Dateien in das Archivpostfach eines Benutzers importieren wollen, dann sollte der Anwender natürlich auch ein Archivpostfach haben.

Weitere "Probleme" und Hinweise füge ich hinzu, wenn ich über diese gestolpert bin. Oder Sie senden mit ihre Erfahrungen.

Weitere Links