Konsolidierung

Exchange ist eines der wenigen Produkte, die nicht "serverzentriert" sind, d.h. im Gegensatz zu den klassischen Mailservern, bei denen alle Benutzer ihre Nachrichten von einem zentralen Server (in der Regel POP3/IMAP4) abholen, kann Exchange von Hause aus schon mehrere Server an verschiedenen Standorten unterstützen. Die Konfiguration wurde schon seit Exchange 4.0-5.5 durch den Verzeichnisdienst repliziert und seit Exchange 2000 ist das Active Directory dafür zuständig. Notes hat einen ähnlichen Mechanismus und das frühere GroupWise hat ebenfalls ähnlich gearbeitet. Nur die ganzen POP3/IMAP4-Server sind meist nur auf einen Server ausgelegt. Der Betrieb mehrerer Server muss man aufwändig zusammenschalten (Aliasliste, Weiterleitungen etc.)

Aus dieser Infrastruktur gibt es aber zwei Tätigkeiten, die viele Exchange Administratoren erst mal aufschrecken lassen:

  • Benutzer zieht um
    Wenn ein Anwender innerhalb der Firma den Arbeitsplatz wechselt, dann kann es sinnvoll sein, auch das Postfach in die "Nähe" des aktuellen Arbeitsplatzes zu verlagern. Zumindest wenn die Server dezentral stehen.
  • Standorte wird aufgelöst
    Das zweite Szenario ist die Auflösung eines Exchange Standorts. Durch den Preisverfall und die Verfügbarkeit breitbandiger Verbindungen macht es immer weniger Sinn, Server dezentral vorzuhalten.

In beiden Fällen geht es natürlich darum, Benutzer aber auch Verteiler etc. in andere Exchange 5.5 "Sites" bzw. andere Exchange 200x "Administrative Gruppen" zu verlagern. Das hat natürlich umfangreiche Veränderungen zur Folge. Denn allein mit dem Verschieben des Postfachs und der Inhalte ist es nicht getan. Was passiert z.B. mit:

  • Verteilermitgliedschaften
    Wird ein Postfach verschoben, dann ist das faktisch unter Exchange 5.5 ein "löschen" des Benutzers in einer Site und ein Anlegen im Ziel. Damit verschwindet das alte Konto natürlich auch aus den Verteilern. Das muss korrigiert werden. Bei Exchange 200x hingegen bleibt bei einer Verschiebung des Postfachs das Benutzerkonto in der OU ja unverändert.
  • Stellvertreter auf anderen Postfächer
    Das "Löschen" des alten Benutzers entfernt das Konto zwar bei Exchange 5.5 nicht aus der Liste der berechtigten Benutzern, aber kann natürlich nicht mehr genutzt werden. Mit Exchange 200x wird die SID genutzt, welche bei einer Migration mit ADMT (SIDHistory) erhalten bleibt.
  • persönliche Berechtigungen auf öffentliche Ordner
    Wurde ein Benutzer statt einer Gruppe auf einem Exchange 5.5 öffentlichen Ordner berechtigt, dann ist auch dieses Recht erst mal verwaist.
  • Kontakte und persönliche Verteiler bei anderen Benutzern
    Kritischer sind hier auch die Kontakte, die jeder Benutzer selbst mit Outlook anlegen kann. Er kann nämlich auch Empfänger aus der globalen Adressliste "kopieren". Wird dieses Postfach nun verschoben, dann müssen Vorkehrungen getroffen werden. Dass Mails an diese Adressen weiterhin ankommen (Stichwort X.500-Adressen und LegacyExchangeDN)
  • Rückläufer
    Zudem müssen Sie beachten, dass Antworten oder Rückläufer auf Nachrichten, welche von diesem Postfach vor der Migration versendet wurden, erst nach der Migration zurück kommen können. Auch diese müssen ja "zustellbar" sein
  • Free/Busy-Zeiten
    Outlook veröffentlicht die Frei/Belegt-Zeiten in einem speziellen öffentlichen Ordner. Dazu nutzt er seine "Site-Information" um den passenden Ordner zu finden. Je nach Version und Betriebsart von Exchange ändert sich dieser Name oder nicht. Entsprechend befindet sich die zukünftige Information über die Frei/Belegt-Zeiten auf dem Exchange Server vor Ort oder Outlooks versucht remote auf den anderen Server die Daten abzulegen.
  • Regeln bei anderen Benutzern
    Und natürlich dürfen die Clientregeln in Outlook bei anderen Postfächern oder öffentlichen Ordnern nicht vergessen werden, die Mails anhand bestimmter Kriterien auch an das zu verschiebende Postfach senden können. Auch diese Regeln sollten danach ja weiter funktionieren.

Natürlich könnten Sie nun einwerfen: "Die Mailadressen und besonders die SMTP-Adresse wird man natürlich beibehalten". Aber das ist leider nur die halbe Wahrheit, da Exchange 5.5 und älter intern nicht auf SMTP basiert und auch bei Exchange 2000 und neuer als auch Outlook viele internen Funktionen nicht die SMTP-Adresse nutzen, sondern eben die alte X.400 Adresse bzw. den LegacyExchangeDN

Und dann gibt es ja noch die Objekte im jeweiligen Verzeichnisdienst, die z.B. Verteiler, Kontakte und öffentliche Ordner repräsentieren. Auch diese müssen z.B.: bei der Auflösung einer Site "berücksichtigt" bzw. verlagert werden. Zwar muss man hier keine Postfachinhalte "verschieben" aber mit einem einfachen "Löschen in der Quelle" und "Neuanlegen" im Ziel ist es nicht getan. Denken Sie mal an

  • Berechtigungen auf öffentlichen Ordnern und Postfächern
    Verteiler werden sehr gerne genutzt, um Berechtigungen zu vergeben. Wird ein Verteiler verschoben (In der Exchange 5.5 Sprache also gelöscht und in der Ziel-Site wieder angelegt), dann muss man hier nacharbeiten.
  • Weiterleitungsziele in Regeln
    Auch hier gibt es Regeln, die einen Verteiler als Ziel haben
  • Mitgliedschaften in Verteilern
    Und zuletzt müssen Sie natürlich auch alle Mitglieder der Verteiler im Zielobjekt mit anlegen

Aber für all diese Fälle gibt es natürlich Lösungen. Allerdings waren diese bei Exchange 4.0 noch lange nicht möglich und erst nach und nach sind die verschiedenen Konsolidierungswege hinzu gekommen. Es ist daher abhängig vom jeweiligen Servicepack Stand der Server und Komponenten (Auch der ADC !), ob eine Konsolidierung ��berhaupt "erlaubt" ist.

Exchange 200x Mixed oder ADC - Retter, Helfer oder Störer

Gerade der ADC ist hier manchmal Retter, Helfer oder Störer in einer Person. Würden Sie ein Postfach in Exchange 5.5 einfach in eine andere Site verschieben und dabei den user "löschen", dann würde die entsprechende Verbindungsvereinbarung ein "Löschen erkennen und im Active Directory bei dem Benutzer die Exchange Eigenschaften entfernen. Verschiebt man den Benutzer aber "richtig", dann hat das Konto im Ziel nun die gleichen ADCGlobalNames und sind nicht gelöscht. Allerdings müssen Sie nun weiterhin über entsprechende CAs dafür sorgen, dass die im AD nicht verschobenen Benutzer nun auf die richtige Zielsite in der Exchange 5.5-Welt verweisen.

Bei Verteilen könnten Sie den ADC sogar aktiv zu Hilfe nehmen, indem ein Löschbefehl in Exchange 5.5 die Eigenschaften im Active Directory (z.B. die Mitglieder) nicht löscht. Die Mitglieder sind ja alle weiterhin im Active Directory vorhanden. Triggert man nun eine geeignete Rückreplikation an, dann könnte der ADC den Verteiler in der Exchange 5.5 einfach neu anlegen und die Daten aus dem Active Directory eintragen. Soweit muss es aber nicht kommen. Auch hierfür gibt es bessere Programme.

Ich hoffe ich konnte ihnen einen Eindruck geben, dass eine Konsolidierung möglich ist aber Vorbedingungen erfüllt sein müssen. Es ist vor allem keine "Plug and Play" Umstellung und selbst mit Assistenten ist es in einer gemischten Umgebung (Exchange 5.5 und Exchange 200x) nicht ohne Risiken.

Exchange 200x Native

Wenn Sie aber schon Exchange 200x "Native" sind, dann gibt es kein Exchange 5.5 und keinen ADC mehr. Dann gibt es auch keine Verteiler die von einer Site in die andere zu verschieben sind, sondern es gibt nur Inhalte in Mailboxen, die von Server zu Server zu verlagern sind und Einträge im Active Directory, die an die geänderten Speicherorte anzupassen sind.

Auch wenn sich das einfacher anhört, dann ist das trotzdem nicht ganz ohne Tücke, da je nach Betriebsart der LegacyExchangeDN verändert wird oder nicht und sich entsprechend interne Strukturen auswirken. Also auch hier Augen auf und Dokumentation lesen oder helfen lassen.

Die Werkzeuge

Microsoft unterstützt die Konsolidierung mit verschiedenen Werkzeugen, die in Kürze aufgezählt sind:

  •  Move Mailbox Wizard in Exchange 2003 SP1
    Erst mit dem Exchange 2003 SP1 kann der "Move Mailbox Wizard" korrekt mit der Verschiebung von Postfächern aus einer Administrativen Gruppe in eine andere administrative Gruppe umgehen. Auch für die Konsolidierung von Exchange 5.5 Postfächern auf einen Exchange 2003 Server in einer eigenen (zentralen) Administrativen Gruppe " ist diese Version (oder neuer) erforderlich.
  •  Exchange Profile Update Tool (Exprofre.exe Profile Tools)
    Wird ein Postfach zwischen Sites verschoben, dann funktioniert natürlich auch das lokale Outlook Profil nicht mehr. Das Hilfsprogramm ExPROFRE hilft hier, indem es bestehende Profile anpasst, damit diese Verschiebung auf auf dem Client ohne manuelle Eingriffe erfolgreich verläuft.
  • Public Folder Migration Tool (PFMigrate)
    Diese VBScript erlaubt NUR mit Exchange 2003 die automatische Änderung von öffentlichen Ordnern Replikaten per Kommandozeile. Seit Exchange 2003 SP2 ist diese Funktion auch über die GUI im Exchange System Manager bedingt möglich. Das Skript erspart aber besonders in größeren Strukturen viel Maus Klickarbeit
  • Object Rehome Tool
    Dieses Werkzeug ist in den Exchange 2003 Deployment Tools enthalten und dient dazu, Verteiler und Kontakte aus einer Exchange 5.5 Site in eine andere Exchange 5.5 (oder 2003) Site zu verschieben und berücksichtigt dabei auch die Besonderheiten einer bestehenden Active Directory Verbindungsvereinbarung

Für alle anderen Fälle gibt es natürlich auch jede Menge Dritthersteller, die mit eigenen Werkzeugen die Migration "einfacher" machen wollen. So kann es durchaus ein Problem sein, wenn eine Mailbox während des "Move" einige Stunden nicht erreichbar ist oder Verteilermitgliedschaften nicht vollständig sind. Das kann man natürlich mindern, wenn die Mails erst in ein neues Postfach kopiert, dann die Einträge im Routing angepasst und nach der Umstellung dann alle bis dahin im alten Postfach aufgelaufenen Änderungen vor dem Löschen noch übertragen werden.

EX55 nach Ex200x Site Konsolidierung

Auch wenn ich hier nicht auf jedes Detail eingehen kann, so soll ihnen die kurze Anleitung helfen, die einzelnen Schritte und deren Auswirkungen zu verstehen. Es geht um die Konsolidierung eines Exchange 5.5 Standortes in eine zentrale Exchange 2003 Site

  1. ADC repliziert Benutzer und Verteiler
    Voraussetzung für die Koexistenz ist natürlich der korrekte Betrieb der Verbindungsvereinbarungen. Dies müssen bidirektionale CAs sein.
  2. Active Directory Einträge optional verschieben
    Oft ist eine Konsolidierung auch damit verbunden, die Active Directory Konten und Gruppen in eine andere Domäne zu verschieben. Das kann vor oder nach der Mailkonsolidierung erfolgen. Nutzen Sie am besten ADMT dazu, damit die SID als SIDHistory und die Exchange Attribute mit genommen werden. Achten Sie dabei aber auch auf ADC-Verbindungsvereinbarungen, dass nach dem Verlagern ein bidirektionales CA die Daten weiter abgleichen kann
  3. Mailbox wird "verschoben"
    Der ESM öffnet eine leere Mailbox auf dem Zielserver, kopiert alle Daten auf den Zielserver und ändert am Ende unter anderem die Einträge des msExchangeHomeServer, HomeMTA und HomeMDB auf die neuen Daten, welche dann auch in Exchange 5.5 gesetzt werden.
  4. Altes EX55 Konto zum Stub-Objekt konvertieren
    Der ESM macht aber noch mehr. Das alte Exchange 5.5 Konto wird nun nicht einfach gelöscht, da damit ja auch die Mitgliedschaften in Verteilern gelöscht werden würde. Der ESM entfernt daher beim alten EX55 Konto alle Mailadressen (ProxyAddresses), verbirgt es im Adressbuch und setzt zwei besondere ProxyAddresses: "X500:ADCDeleteWhenUnlinked" und "X500:ADCDoNotreplicate".
  5. ADC Abgleich
    Der ADC wird nun aber den aus Exchange 5.5 Sicht migrierten Benutzer in der neuen Exchange 5.5 Site als neuen Benutzer anlegen. Zudem wird dieser user nun auch in die Verteiler des alten Postfachs aufgenommen.
  6.  ADC Cleanup
    Im gleichen Zuge wird aber auch das Stub-Postfach aus den Verteilern entfernt und letztlich ist das "MemberOf"-Attribute des Stub-Objekts "leer". Der ADC macht nun alle 12h einen Test auf eben solche Objekte mit einer ProxyAddresses "X500:ADCDeleteWhenUnlinked" und löscht dieses Objekt, wenn es in keinen Verteilern mehr drin ist.

Prüfen Sie doch mal ihre Exchange 5.5. GAL auf Objekte mit einer ProxyAddresse "X500:ADCDeleteWhenUnlinked". Sie sollten nur wenige Stunden existieren.

Insofern ist für die Site-Konsolidierung nicht nur der Move der Postfachinhalte wichtig, sondern die Verzeichnisdienste und die ADC Verbindungsvereinbarungen spielen eine nicht minder schwere Rolle.

Unterstützung durch Net at Work:
Profitieren Sie von unserer Erfahrung bei Exchange 5.5 nach Exchange 200x Konsolidierungen. Besonders, wenn sie mehr als eine Site haben, sind die Fallen tückisch.

Exchange 2007

Vielleicht haben Sie schon gehört und gelesen, dass Exchange 2007 immer eine neue Administrative Gruppe anlegt und alle Exchange 2007 Server in dieser Gruppe zu finden sind. Das bedeutet aber auch, dass jede Migration nach Exchange 2007 immer auch eine Verschiebung von Postfächern über die Grenzen von Administrativen Gruppen hinweg erfolgt. Das mag auch der Grund sein, warum Exchange 2007 nur in einer reinen Exchange 2000/2003 Umgebung installiert werden kann. Die Exchange Organisation muss also "native" sein. Der Kniff dabei ist nämlich, dass damit auch der LegacyExchangeDN nicht mehr geändert werden muss und auch die Frei/Belegt-Zeiten zumindest in Verbindung mit Outlook 2007 und dem "Concierce-Service" von Exchange 2007 nicht mehr auf die öffentlichen Ordner angewiesen sind. Insofern gibt es bei der Migration von Exchange 2000/2003 nach Exchange 2007 kaum noch Beschränkungen bei der Konsolidierung oder umstrukturierung von Standorten.

Weitere Links