Postfächer importieren und exportieren unter Exchange 2011 SP1
4. Mai 2011
Mit dem SP1 für Exchange Server 2010 hat Microsoft durch das Einführen des neuen Modells für das Im- und Exportieren einen sehr großen Schritt nach vorne geschafft. Ein Zyniker könnte auch sagen, das war auch nicht schwierig.
Denn der Einsatz von Outlook und Exmerge für ein Importieren oder Exporteiern, war kein Ruhmesblatt. Umso eleganter ist die neue Funktionalität für das Importieren und Exportieren von Postfächern. Hier sind neue Powershell-Cmdlets mit ins Spiel gekommen, die das Arbeiten mit der neuen Funktionalität für den Administrator recht einfach machen.
Hier wird der Start dieses Beitrags publiziert. Der komplette Beitrag ist in der Printausgabe Mai 2011 von NT4ADMINS zu finden. Wer Tony Redmond persönlich treffen möchte, der hat dazu eine Möglichkeit auf der IT&DevConnections 2011 von 8. bis 10. Juni 2011 in Karlsruhe.
Hier wird der unabhängige Exchange-Top-Experte mehrere Vorträge, unter anderem eine Keynote am Freitag zu Exchange /Titel: „Six Critical Issues for Successful Exchange 2010 Deployments“) halten. Hier geht es zur Anmeldung.
Wenn es darum geht, Daten in einen Exchange Server zu laden oder Daten aus diesem Server zu exportieren, hat sich Microsoft nicht mit Ruhm bekleckert. Anwendungen, die wie der Exchange Server ein (oder mehrere) persistentes Daten-Repository benötigen, verfügen üblicherweise über einen speziellen Mechanismus. Er sollte es einem Administrator ermöglichen, Daten in das Repository zu laden oder welche daraus zu exportieren.
Doch bei Exchange ist das nicht der Fall. Das Importieren von Daten bezieht sich zum Beispiel auf das laden von Benutzerdaten in die Postfächer – das kommt etwa beim Migrieren von einem Mail-System auf ein anderes zum Einsatz. Der umgekehrte Weg, das Exportieren ist genauso wichtig, etwa wenn man die Daten für eine spätere Untersuchung oder Bearbeitung benötigt. Das ist der Fall in Szenarien wie einer rechtlichen Untersuchung von Mail-Inhalten oder aber wenn man Kopien von Daten aus rechtlichen Gründen aufbewahren muss.
Seitdem Microsoft die erste Version von Exchange vorgestellt hat – das sind etwa 15 Jahre – müssen Administratoren mit Tools auf der Client-Seite hantieren, um Daten in Postfächer zu laden oder sie aus ihnen zu exportieren. Dabei sind recht umfangreiche Tools entstanden – wie zum Beispiel die Utility Exmerge (siehe dazu den Blog) beweist.
Dieses Werkzeug startete als eine einfache Lösung, die beim Verschieben von Postfachdaten von anderen Mail-Systemen in Exchange helfen sollte. Mittlerweile deckt es eine Vielzahl von Aktionen ab und gehört in der Regel zum Standardarsenal eines jeden Exchange-Administrators.
Outlook dagegen erweist sich als keine passende Lösung für diese Problemstellung. Es eignet sich für das schnelle Durchsuchen eines Postfachs und um die Einträge in eine PST-Datei zu exportieren.
Doch es macht keinen Sinn, auf diese Art mehrere GByte an Daten zu importieren. Des Weiteren lässt sich dabei kein Skripting einsetzen oder gar von einem „durchschnittlichen Administrator“ etwas programmieren, der lediglich Benutzerdaten extrahieren möchte, weil ein gewisser Informationsbedarf in diesem Kontext besteht.
Tools wie Exmerge retten
Ausgebildete Programmierer können zwar das OOM (Outlook Object Model) verwenden, um Programme für das Extrahieren von Daten zu schreiben, doch meist hat man dieses Wissen dann nicht verfügbar und derartige Programme sind auch nicht vorhanden. Daher „retten“ sich viele Administratoren mit Lösungen wie Exmerge.
Die Client-Applikationen setzen auf dem MAPI-Bibliotheken auf, um auf die Inhalte der Exchange-Datenbanken zuzugreifen. Dabei ist eine Vielzahl von MAPI-Bibliotheken gut in Bezug auf ihre API (Application Programming Interface) dokumentiert, vor allem die zu Outlook gehören. Der Administrator muss daher zuerst Outlook auf einem Exchange-Server installieren. Erst dann ist er in der Lage, einen Client zu starten, der auf die MAPI-Bibliotheken zugreifen kann. Diese Abhängigkeit trifft auch für die Cmdlets Import-Mailbox und Export-Mailbox (die es für Exchange Server 2010 und Exchange Server 2007 gibt) zu.
Als Microsoft im Oktober 2009 Exchange 2010 freigab, musste man eine 64-Bit-Version von Outlook auf seinen Exchange-2010-Postfachservern installieren. Erst dann konnte man mit den Powershell-Cmdlets die Daten importieren beziehungsweise exportieren. Doch eine formal freigegeben Version des 64-Bit-Outlooks war noch nicht verfügbar.
Erst im April kam Outlook 2010 – das allein zeigt schon die Probleme, die auftreten, wenn ein Produkt von den Entwicklungszeitplänen eines anderen abhängt, die oftmals nicht zueinander synchron laufen. In der harten Realität bleibt daher nur eine Bewertung: Die Fähigkeiten zum Importieren und Exportieren von Daten bei Exchange sind seit Jahren sehr schlecht und brauchen unbedingt einen neuen Ansatz.
Mit dem Servicepack 1 (SP1) von Exchange Server 2010 wurden die früheren Ansätze zum Im-/Export von Daten daher verworfen. Es kam ein komplett neues Modell ins Spiel, wie Import- und Export-Requests vom MRS, Microsofts Exchange Mailbox Replication Service, abgehandelt werden.
Die Daten gehen beim Importieren und Exportieren nun über einen neuen Data Provider, der in die Client-Access-Serverrolle integriert wurde – und der nun von keinem anderen Produkt mehr abhängt.
Die alten Cmdlets, Import-Mailbox und Export-Mailbox, sind mit dem SP1 sozusagen ausgemerzt. Das bedeutet aber auch, das Administratoren, die mit diesen alten Cmdlets Powershell-Skripts geschrieben haben, nun ihre Skripts umstellen müssen. Dazu bringt SP1 einen neuen Satz von Cmdlets, um Import und Export-Requests für Postfächer zu erzeugen, um den Status von Postfächern abzufragen und weitere Informationen bereitzustellen.
Dieser neue Ansatz für das Importieren/Exportieren von Daten aus/in Postfächern ähnelt dem „Mailbox Move Modell“ von Exchange Server 2010.
Im weiteren Verlauf des Beitrags )in der Print-Ausgabe) zeigt Tony Redmond die Vorbereitungen für die Import- und Export-Operationen, widmet sich dem neuem Vorgehen beim Importieren von Postfachdaten (inklusiver des Einsatzes der neuen Cmdlets aus der Powershell), zeigt das Exportieren von Postfach-Daten und erläutert, wie sich das alles im täglichen Betrieb darstellt.
Wer den kompletten Beitrag beziehen möchte, der kann eine Mail an rhh@oberland.net (mit dem Betreff: PDF-Beitrag Redmond) senden und bekommt dann ein PDF mit diesem Beitrag zugemailt. Noch besser aber ist der Abschluss eines Print- und Online-Abonnements.
