Exchange loswerden (Teil 2): Postfächer und Public Folders in die Cloud

Im ersten Teil ging es um den Mailflow: Nichts läuft mehr über den Server. Jetzt geht es um das, was noch auf ihm liegt. Microsoft ist da eindeutig: Jedes Postfach, das on-prem übrig bleibt, blockiert die Deinstallation. Das gilt nicht nur für Benutzerpostfächer, sondern auch für Archive, Public-Folder-, Arbitration- und Audit-Postfächer.

In diesem Teil geht es um alles, was Daten enthält und deshalb vor der SOA-Umstellung in Teil 3 in die Cloud muss: Benutzerpostfächer, Archive und Public Folders. Die System-Postfächer (Arbitration, Audit-Log, die leeren Public-Folder-Postfächer) räumen wir bewusst erst ganz am Ende ab, in Teil 4 (erscheint in Kürze). Dann ist die Verwaltung schon in der Cloud, und mehrere Abhängigkeiten haben sich von selbst erledigt.

Ein Hinweis vorab, der für alle Abfragen in diesem Teil gilt: Bei mehreren Domänen im Forest sehen die Get-*-Cmdlets sonst nur die lokale Domäne. Deshalb in jeder Exchange Management Shell zuerst:

Set-ADServerSettings -ViewEntireForest:$true

Die letzten Benutzerpostfächer

Zuerst die Bestandsaufnahme on-prem:

Get-Mailbox   # muss am Ende leer sein

Was noch übrig ist, geht als letzter Batch über den Migrationsendpunkt, den der Hybrid Configuration Wizard angelegt hat. Das Beispiel ist Microsofts eigenes, in Exchange Online:

$endpoint = Get-MigrationEndpoint | Select-Object -First 1
$endpoint | Format-List Identity, RemoteServer

# RemainingMailboxes.csv: eine Spalte EmailAddress
New-MigrationBatch -Name "LES-Final-Cutover" `
    -SourceEndpoint $endpoint.Identity `
    -TargetDeliveryDomain "contoso.mail.onmicrosoft.com" `
    -CSVData ([System.IO.File]::ReadAllBytes("C:\Migration\RemainingMailboxes.csv")) `
    -AutoStart -AutoComplete

Get-MigrationBatch -Identity "LES-Final-Cutover" |
    Format-List Status, TotalCount, ActiveCount, SyncedCount, FinalizedCount, FailedCount
Get-MigrationUser -BatchId "LES-Final-Cutover" | Get-MigrationUserStatistics

Wenn der Endpunkt seit Jahren nicht mehr benutzt wurde, ist das hinterlegte Kennwort oft abgelaufen. Wie du es änderst, steht in Migration Endpoint, Account credentials ändern.

Archive

Archive sind leicht zu übersehen, weil sie nicht als eigene Benutzer auftauchen. Was on-prem noch an Archiven liegt, zeigt:

Get-Mailbox -Archive | Format-Table Name, ArchiveDatabase, ArchiveStatus -AutoSize

Für jedes Archiv jetzt entscheiden, solange die Verwaltung noch on-prem ist:

• Inhalt wird gebraucht: mit dem Postfach in die Cloud verschieben. Nach der SOA-Umstellung kommen Änderungen am Benutzer aus dem AD nicht mehr in Exchange Online an. Ein späterer Archiv-Umzug würde damit unnötig heikel. Das ist meine Ableitung, nicht von Microsoft beschrieben.
• Inhalt wird nicht gebraucht: Das sind oft Reste, etwa Archive von Benutzern, die längst in der Cloud sind. Deaktiviert werden sie in Teil 4 zusammen mit den System-Postfächern. Vorher trotzdem prüfen, ob noch etwas drin ist, das jemand braucht.

Ein Archiv kann in einer anderen Datenbank liegen als das Hauptpostfach. Microsoft fragt deshalb zusätzlich das ArchiveDatabase-Attribut der Postfächer ab, und mein Prüfskript in Teil 4 findet auch diese Fälle.

Public Folders

Lokale Public Folders blockieren die Deinstallation ebenfalls. Microsoft empfiehlt, sie nach Exchange Online zu migrieren. Ist nichts Wertvolles drin, wird die Bereitstellung entfernt.

Auch hier gilt: Die Daten müssen umziehen, solange der Server läuft. Die dann leeren Public-Folder-Postfächer on-prem räumen wir erst in Teil 4 ab.

In der Praxis ist die Frage meistens: Braucht das überhaupt noch jemand als Public Folder? Die Möglichkeiten habe ich in Migration von onprem Public Folders zu Shared Mailbox mit PowerShell ausführlich gegenübergestellt:

• 1:1 nach Exchange Online, mit Microsofts Skripten oder einem kostenpflichtigen Migrationswerkzeug. Am wenigsten Widerstand, aber die Technik lebt weiter, und mit ihr viel Datenmüll.
• Microsoft 365 Groups als Ziel. Kostenlos, aber mit Grenzen: höchstens 50 GB, nur Mail und Kalender, kaum Ordnerstruktur, keine vollwertigen Ordnerberechtigungen, keine Regeln.
• Shared Mailbox als Ziel, ohne diese Grenzen. Dafür habe ich das Werkzeug PublicFolderMigration gebaut: Es kopiert einen Ordner samt Unterordnern per EWS in eine lokale Shared Mailbox, übernimmt die Berechtigungen als FullAccess und arbeitet inkrementell, ein zweiter Lauf kopiert nur das Neue. Die Shared Mailbox wird danach ganz normal mit dem Migrations-Batch von oben nach Exchange Online verschoben.
• Kombiniert: Was sich klären lässt, wird Gruppe oder Shared Mailbox, der Rest geht 1:1.

Für die Planung heißt das: Der Weg über die Shared Mailbox braucht den lokalen Server zweimal, für das Kopieren per EWS und für den anschließenden Postfach-Umzug. Er gehört also an den Anfang, nicht ans Ende.

Hast du mail-aktivierte Public Folders, lies vorher noch Mail-enabled Public Folders: warum Microsofts Sync-Skript ein Risiko ist.

Microsofts eigene Anleitungen: Migrate to Exchange Online bzw. Remove public folder deployment.

Danach: ggf. warten (oder prüfen)

Das ist der Punkt, der in Teil 3 wichtig wird. Nach dem letzten (Mailbox-)Move, auch dem der Shared Mailboxes aus den Public Folders, erst einen kompletten Sync-Zyklus abwarten, dann noch 24 Stunden, bevor das Postfach auf Cloud-Verwaltung umgestellt wird. Microsoft begründet das so: Wird zu früh umgestellt, können veraltete Empfängertyp-Werte aus der Cloud die richtigen Remote-Mailbox-Werte im AD überschreiben, sobald der Writeback läuft. Microsofts Rechenbeispiel: Dauert der Sync 6 Stunden, sind es insgesamt 30.

Wichtig ist die Wartezeit nur, wenn der Writeback aus Teil 3 läuft oder später eingerichtet wird. Ohne Writeback schreibt nichts aus der Cloud ins AD zurück. Und wer es genau wissen will, statt nur zu warten: Das Prüfskript aus Teil 3 zeigt vor dem Einrichten des Writebacks, was er im AD ändern würde.

Fazit

Die Benutzerpostfächer sind selten das Problem, die sind nach Jahren im Hybrid meist schon in der Cloud. Public Folders (sofern noch onprem vorhanden) sind schon aufwändiger, weil hinter ihnen eine fachliche Frage steckt: Was davon braucht noch jemand, und in welcher Form?

Wenn kein Benutzerpostfach mehr on-prem liegt, die Archive entschieden und die Public Folders umgezogen sind und die 24 Stunden nach dem letzten Mailbox-Move vorbei sind, geht es weiter mit Teil 3: Die Verwaltung zieht in die Cloud. Die System-Postfächer bleiben bis Teil 4 liegen.

Feedback, Fragen und Erfahrungen gerne in die Kommentare.