Public Folder PST-Migration

Microsoft hat einen Weg dokumentiert, wie mittels Hybrid Bereitstellung auch die ungeliebten öffentlichen Ordner von OnPremise zu Exchange Online migriert werden.

Szenario - Parallelbetrieb

Fast alle Firmen, die bisher mit einem lokalen Exchange Server und öffentlichen Ordnern gearbeitet haben, können diese mit Bordmitteln zu Exchange Online umziehen. Wir wissen aber alle, dass öffentliche Ordner früher sehr gerne genutzt wurden aber seit Teams, SharePoint oder auch Office Groups nicht mehr erste Wahl sind. Oft sind es große Strukturen, von denen die meisten Ordner nicht mehr genutzt werden oder es schon gar keine Ansprechpartner mehr gibt.

Insofern kann es durchaus gewünscht sein, nicht alle Order mit allen Altlasten wieder 1:1 mitzunehmen. Wie wäre dann folgendes?

  • OnPremises Benutzer verwenden die lokalen Ordner
    Da brauchen Sie erst einmal nichts zu ändern, da ein Benutzer mit Postfach auf dem lokalen Exchange Server als Standard die lokalen Public Folder nutzt. Erst mit einer klassischen Migration wird ganz am Ende dem lokalen Exchange Server gesagt, dass die Ordner in der Cloud liegen. Aber das lassen wir mal.
  • Cloud Benutzer verwenden die Exchange Online Ordner
    Wenn Sie wirklich noch öffentliche Ordner mit Exchange Online verwenden wollen, dann können Sie diese ja auch losgelöst von den lokalen Ordner parallel anlegen. Solange keine Benutzer migriert sind, stört dies niemanden.
  • Testbenutzer und Piloten zuerst
    Nun nutzen Sie die normalen Wege zur Postfachmigration, um die ersten Benutzer in die Cloud zu verschieben. Bei der ersten Anmeldung werden diese Benutzer aber nur noch die öffentlichen Ordner sehen, die sie in Exchange Online angelegt haben. Sie können nun in aller Ruhe mal abwarten, ob Benutzer wirklich etwas "vermissen" und sollte das der Fall sein, dann können Sie die Inhalte immer noch in der Quelle als OnPremises-Benutzer in eine PST-Datei exportieren und im Ziel durch einen Exchange Online Benutzer importieren lassen.
  • Zurück bleibt der Müll
    Wenn Sie letztlich alle Anwender nach Exchange Online verschoben haben, dann können Sie die Hybrid-Bereitstellung sogar auf "Management only" zurückbauen und warten einfach noch etwas ab, ehe Sie dann die verbliebenen und anscheinend nicht mehr nachgefragten Ordner löschen.

Ich bin selbst eigentlich kein Freund dieser Methode, da durchaus Datenverluste möglich sind. Viel lieber frage ich vorher die Anwender oder sperre erst einmal ein paar Wochen den Zugriff über die Rechte der öffentlichen Ordner um vor Vorfeld schon die Nutzung genauer zu erfahren. Sie können auch eine Test-Mail in jeden Ordner mit der Bitte zur Löschung legen. Wenn Sie nach einigen Wochen noch da ist, dürfte sich auch niemand um den Ordner kümmern. Leider gibt es in Exchange OnPremises meines Wissens keinen einfachen Weg den Zugriff von Personen auf öffentliche Ordner zu protokollieren.

Für mit ist das Szenario aber erst einmal eine Gelegenheit mich mit den Grundlagen der öffentlichen Ordner in einem Tenant zu beschäftigen.

Sie wissen ja, dass die meisten MSXFAQ-Seiten während der Arbeit mit dem Kunden oder nach Support-Fällen erstellt werden und ich damit für ich meine Änderungen und Erkenntnisse teile. In dem Projekt wurde eine klassische Migration per Hybrid schon begonnen ehe man dann sich doch dafür entschieden hat, nur ganz wenige öffentliche Ordner manuell zu migrieren. Die gewünschten Inhalte wurden schon als PST-Dateien exportiert aber nun konnte man diese nicht zu Exchange Online importieren, das der Parameter "PublicFoldersEnabled : Remote" nicht geändert werden konnte.

Ausgangssituation

Ich habe einen Tenant genommen, der noch nie mit Exchange im "Hybrid"-Zustand war und auch noch nie eine öffentliche Ordner Migration mit Microsoft Bordmitteln durchlaufen hat. Das sehen Sie auch sehr schnell in der OrganizationConfig:

PS C:\> Get-OrganizationConfig | fl PublicFolder*,RootPublicFolderMailbox,RemotePublicFolderMailboxes

PublicFoldersLockedForMigration              : False
PublicFolderMigrationComplete                : False
PublicFolderMailboxesLockedForNewConnections : False
PublicFolderMailboxesMigrationComplete       : False
PublicFolderShowClientControl                : False
PublicFoldersEnabled                         : Local
RootPublicFolderMailbox                      :
RemotePublicFolderMailboxes                  : {}

Das Feld "RootPublicFolderMailbox" ist leer, und auch "PublicFolderMigrationComplete" steht auf "False". Der Eintrag "PublicFoldersEnabled : Local" würde Clients auf die aus Sicht des Exchange Servers "lokale" Datenbank" verweisen. In dem .Fall wäre das dann ebenfalls Exchange Online. Das es keine öffentlichen Ordner gibt, ist mit "Get-PublicFolder" schnell zu ermitteln.

PS C:\> Get-PublicFolder

Get-PublicFolder: |Microsoft.Exchange.Data.StoreObjects.ObjectNotFoundException|Es konnten keine aktiven Postfächer für öffentliche
Ordner für Organisation fcarius.onmicrosoft.com gefunden werden. Entweder wurden keine Postfächer für öffentliche
Ordner bereitgestellt, oder sie wurden im HoldForMigration-Modus bereitgestellt. Wenn Sie aktuell keine Migration
ausführen, erstellen Sie ein Postfach für öffentliche Ordner.

Hier gibt es keine öffentlichen Ordner.

PF Hierarchie zur Migration

Wenn ich nun die öffentlichen Ordner aus der lokalen Umgebung migrieren will, dann machen die Microsoft Skripte am Ende auch nichts anderes, als eine Public Folder Struktur in der Cloud anzulegen aber die Clients auf die OnPremises-Umgebung zu verweisen. Erst am Ende wird dann umgestellt. Ich möchte zwar nicht migrieren aber den "Fehlerfall" einmal nachstellen, wenn Sie doch mitten in der Migration sich anders entscheiden. In meinem Fall gab es schon eine "versuchte Migration" und entsprechend war die Konfiguration schon abgeändert. Ich habe versucht, diese Konfiguration nachzubilden. Wenn Sie sich den Befehl "New-Mailbox" anschauen, dann finden Sie den Parameter "HoldForMigration".

PS C:\> New-Mailbox -PublicFolder -Name MasterHierarchy -HoldForMigration:$true
PS C:\> Get-OrganizationConfig | Format-List RootPublicFolderMailbox
 
RootPublicFolderMailbox : 6544fcd1-c4be-41c9-837c-40510d56e91b

Nun habe ich eine "Public Folder Hierarchie" in Exchange Online, die aber nicht von Clients erreichbar ist. Microsoft schreibt dazu auf "New-Mailbox"

The HoldForMigration switch specifies whether to prevent any client or user, except the Microsoft Exchange Mailbox Replication service (MRS) process, from logging on to a public folder mailbox.
You need to use this parameter when you create the first public folder, which is called the hierarchy mailbox, in your organization.
Use this parameter only if you plan to migrate legacy Exchange 2010 public folders to Exchange 2016. If you use this switch but don't have legacy public folders to migrate, you won't be able to create any public folders.
https://docs.microsoft.com/en-us/powershell/module/exchange/New-Mailbox?view=exchange-ps - Parameter HoldForMigration

Ich habe bislang noch kein Feld gesehen, in dem der Status von "HoldForMigration" für eine nachträgliche Anfrage abgespeichert ist.

Damit meine Labor-Umgebung noch komplett ist habe ich in Exchange Online die Client-Einstellung auf "Remote" geändert:

PS C:\> Set-OrganizationConfig -PublicFoldersEnabled Remote

Auch das hat problemlos funktioniert und nun sieht mein Tenant hoffentlich genauso "verstellt" aus, wie der Kundentenant mitten in der Migration.

Das "Rückstellen" des Tenant auf "Local" funktioniert nun natürlich nicht, denn Exchange weiß ja, dass die lokalen Public Folder nur ein Ziel für die Migration mit dem MRS sind und Clients sich nicht verbinden können. Daher darf diese Umstellung erst passieren, wenn die Migration abgeschlossen ist.

PS C:\> Set-OrganizationConfig -PublicFoldersEnabled local

Set-OrganizationConfig: |Microsoft.Exchange.Management.Tasks.RecipientTaskException|Der "PublicFoldersEnabled"-Zustand muss auf "Remote"
festgelegt bleiben, während noch öffentliche Ordner für die Migration gesperrt sind. Bevor Sie die Bereitstellung Ihrer
öffentlichen Ordner auf "Lokal" ändern können, müssen Sie zunächst die Migration der öffentlichen Ordner abschließen.
Wenn Sie Ihre öffentlichen Ordner nicht migrieren möchten, können Sie die vorhandenen Postfächer für öffentliche Ordner
entfernen und sie ohne den Parameter "-HoldForMigration" neu erstellen. Weitere Informationen finden Sie unter
https://technet.microsoft.com/en-us/library/dn874017(v=exchg.150).aspx.

Das war genau die gleiche Fehlermeldung wie im Kundentenant. Nun konnte ich also schauen, wie ich die Blockade wieder los werde. Es gibt einen Public Folder Store in der Cloud, der aber von Clients nicht genutzt wird. Client werden von Exchange Online auf die OnPremises Public Folder verwiesen.

PF Hierarchie Rückbau

Mit dem Vorwissen habe ich nun überlegt, dass die öffentlichen Ordner in der Cloud ja bislang nur Replikationsziel waren und entweder noch keine oder nur partielle Daten darin vorhanden sein konnten. "Live" war immer noch die OnPremises-Umgebung. Also stand nicht im Wege die Cloud-Konfiguration zu bereinigen. Ich habe daher einfach die PublicFolder-Mailbox entfernt.

PS C:\> get-mailbox -PublicFolder | Remove-Mailbox -PublicFolder
PS C:\> Get-OrganizationConfig | Format-List RootPublicFolderMailbox
 
RootPublicFolderMailbox : 00000000-0000-0000-0000-000000000000

Nach diesem Schritt konnte ich nun die Organisation von "Remote" auf "local" setzen:

PS C:\> Set-OrganizationConfig -PublicFoldersEnabled local

# Kein Fehlermeldung

Die Einstellungen in der Organization wie "PublicFoldersLockedForMigration", "PublicFolderMigrationComplete" oder "PublicFolderMailboxesMigrationComplete" spielen hier anscheinend gar keine Rolle

Mir kam das entgegen, da nun Exchange Online gar keine Public Folder mehr hat.

PF Hierarchie anlegen

Die bereits migrierten Anwender werden nun aber auch nicht mehr auf die OnPremises-Systeme verwiesen. Höchste Zeit also, diese Lücke zu schließen.

PS C:\> New-Mailbox -PublicFolder -Name MasterHierarchy
PS C:\> Get-OrganizationConfig | Format-List RootPublicFolderMailbox
 
RootPublicFolderMailbox : 02d801b1-77a3-4252-b5fe-5b0e137c7caa

Wenn Sie den Parameter "HoldForMigration" weglassen, dann ist er "$false". Der Parameter HoldForMigration:$true wird wohl nur bei der Anlage der Hierarchie über die Exchange Skripte genutzt.

Der Versuch eine zweite Mailbox anzulegen, wird natürlich mit einem Felder quittiert.

PS C:\> New-Mailbox -PublicFolder -Name Mig -HoldForMigration:$true
New-Mailbox: |Microsoft.Exchange.Configuration.Tasks.ThrowTerminatingErrorException|Die Standardhierarchie von öffentlichen Ordnern
für die Organisation ist bereits bereitgestellt und kann nicht geändert werden. Damit Sie die Hierarchie aktualisieren
können, müssen Sie zunächst die vorhandenen Postfächer für öffentliche Ordner mit dem Cmdlet "Remove-Mailbox" entfernen.

Das war aber auch so zu erwarten

Anlage und Import

Nach dieser Konfiguration habe ich nun die Umgebung, welche ich am Anfang beschrieben habe:

  • OnPremises Öffentliche Ordner für den Zugriff durch OnPremises Postfächer
  • Öffentliche Ordner in Exchange Online für Benutzer mit einem Exchange Online Postfach

Wenn nun ein Administrator oder Migrationsbenutzer ein Postfach in der Cloud hat, wird er erst einmal nur die Root-Hierarchie sehen. Er kann aber hier problemlos neue Ordner anlegen, Berechtigen und Inhalte z.B.: aus PST-Dateien importieren. Genau genommen könnte auch eine 3rd Party Software z.B. per EWS die gewünschten Elemente aus der Quelle lesen und ins Ziel kopieren

Ich frage mich schon länger, warum noch niemand per PowerShell und EWS ein "copy-ewsitems.ps1" geschrieben hat.

Dies ist aber durchaus eine legitime Ausgangssituation, wenn Sie mit 3rd Party Tools Inhalte synchronisieren können. Ich erinnere mich an frühe Versionen von Quest Migration Manager, die bei der Migration zwischen zwei lokalen Exchange Organisationen genau das gemacht haben.

Weitere Links