Auch wenn Microsoft schon seit Jahren die Abschaffung von öffentliche Ordner predigt kommen bei vielen Exchange Installationen weiterhin öffentliche Ordner zum Einsatz. Während die öffentliche Ordner bis Exchange 2010 in Form eigener Datenbanken mit eigenen Replikationsmechanismen existierten, hat Microsoft die öffentliche Ordner in Exchange 2013 und höher neu designed: Modern Public Folder ist hier das Stichwort. Während vorher die Inhalte verteilter Public Folder Datenbanken per SMTP zwischen den Servern repliziert wurde, sind die öffentliche Ordner jetzt in speziellen Public Folder Postfächer untergebracht. (Create Public Folder http://technet.microsoft.com/en-us/library/bb691104(v=exchg.150))
Die Public Folder Postfächer sind Teil einer DAG und können über die deutlich stabileren Replikationsmechnismen der DAG auf mehrere Server verteilt werden. Im Unterschied zu den vorherigen Public Folder Datenbanken ist der Zugriff die Public Folder Postfächer jedoch der DAG entsprechend nur auf das Postfach der aktiven Datenbank innerhalb der DAG beschränkt. Für eine geografische Verteiler der öffentliche Ordner können jedoch mehrere Public Folder Postfächer erstellt werden und einzelne Strukturen der öffentliche Ordner auf diese Postfächer aufgeteilt werden. Die Postfächer wiederum können dann auf die geografisch nahen Server in der DAG verteilt werden.
Die Umstellung der Legacy Public Folder Struktur aus Exchange 2007/2010 auf die neuen Modern Public Folder erfolgt erst nach der Migration aller Postfächer von Exchange 2007/2010 auf Exchange 2013/2016. Ein Benutzer mit einem Postfach auf Exchange 2007/2010 kann nicht auf öffentliche Ordner auf einem Exchange 2013/2016 Server zugreifen. Der umgekehrte Zugriff ist jedoch möglich. Aus diesem Grund dürfen bei einer Migration die öffentlichen Ordner erst nach Abschluss der Postfachmigration umgestellt werden.
Für die Migration der öffentlichen Ordner gibt im Wesentlichen zwei Verfahren. Ein manuelles und ein teilautomatisiertes Verfahren. Letzteres, die sogenannte „Batch Migration“, empfehle ich ausdrücklich. Diese erfordert jedoch einige Prequirements:
Batch Migration (empfohlen)
Diese neue Methode der Public Folder Migration ist teilautomatisiert und basiert auf einer Reihe von Scripten. Beschrieben wird das Verfahren auch in diesem Technetartikel.
Das Vorgehen lässt sich in folgenden Schritten zusammenfassen:
- Voraussetzungen prüfen
- Statistische Daten der alten öffentlichen Ordner Struktur sammeln
- Erstellen der Migrationsdateien
- Anlegen der Modern Public Folder Postfächer auf Exchange 2013/2016
- Initiale Übertragung der öffentlichen Ordner zu Exchange 2013/2016
Bis hier erfolgt alles ohne Unterbrechung beim Zugriff auf die öffentlichen Ordner. Erst im nächsten Schritt werden die alten öffentlichen Ordner offline genommen und es kommt zu einer Downtime.
- Finale Übertragung der öffentlichen Ordner
- Test des Zugriffs auf die öffentliche Ordner unter Exchange 2013/2016 mit einem Testbenutzer
- Überprüfen der Permissions für Mail-Enabled Public Folder
- Technischer Abschluss der Migration
- Weiterführende Tests
Voraussetzungen prüfen
Zuerst prüfen wir nochmal die Patchlevel der Exchange Server. Die oben genannten Patchlevel sind natürlich die minimal notwendigen Patchlevel. Grundsätzlich ist es empfehlenswert, die aktuellsten Patchlevel einzusetzen. Folgende legacy Exchange Server Versionen werden unterstützt:
- Microsoft Exchange 2007 SP3 RU15 und neuer
- Microsoft Exchange or 2010 SP3 RU8 und neuer
Auch wenn als Zielversion Exchange 2016 ausgeschrieben ist, kann die Migration ebenso für Exchange 2013 durchgeführt werden. Vorausgesetzt, Exchange 2013 ist bereits mit Cumulative Update 7 versorgt.
Die notwendigen Scripte sind nicht in der Exchange Installation enthalten und können hier heruntergeladen werden: http://go.microsoft.com/fwlink/?LinkId=299838.
Außerdem prüfen wir nochmal, ob wirklich alle Benutzer auf die Exchange 2013/2016 Umgebung migriert sind. Ein Zugriff auf die Modern Public Folder ist von Postfächer auf Exchange 2007/2010 nicht möglich.
Falls Mail Enabled Public Folder vorhanden sind, ist zu klären, ob diese auch externe E-Mails empfangen sollen. In dem Fall muss das Recht Create Items für den User Anonymous auf den Public Folder vergeben werden. Mit Exchange 2013 CU6 wurde ein entsprechendes Änderung eingeführt, siehe auch https://blogs.technet.microsoft.com/exchange/2014/08/26/public-folder-updates-in-exchange-2013-cu6-improving-scale-and-more/ unter dem Absatz „Mail-Enabled Public Folder Permission Changes“. Das Vorgehen für eine gescriptete Anpassung beschreibe ich weiter unten bei den Vorbereitungen.
Es kann ausserdem nicht schaden, die aktuellen Public Folder Limits gegen die eigene Infrastruktur zu prüfen. https://technet.microsoft.com/en-us/library/dn594582(v=exchg.150).aspx
Vorbereitung der Migration
Um sicherzugehen, das bisher noch keine Migration durchgeführt wurde, kann der Migrationsstatus der Exchange Organisation abgefragt werden. Dieser sollte $false zurückliefern. Falls dem nicht so ist, muss der Status manuell auf $false gesetzt werden.
|
1 |
Get-OrganizationConfig | Format-List PublicFoldersLockedforMigration, PublicFolderMigrationComplete |
Für Tests nach der Migration wir einen Testbenutzer, mit dem wir den Zugriff auf die öffentlichen Ordner testen können.
Aufräumen Verwaister MESO Objekte
Exchange erstellt für jeden E-Mail aktivierten öffentlichen Ordner ein sogenanntes MESO (Microsoft Exchange System Objekt) im MESO Container des Active Directorys. Wird die E-Mail-Aktivierung des öffentliche Ordner aufgehoben, löscht Exchange dieses MESO Objekt wieder. Es kommt jedoch vor, dass das MESO Objekt verwaist zurück bleibt. Dann muss dieses manuell bereinigt werden. Das ist jedoch nicht trivial, wenn man viele öffentliche Ordner hat. Die MESO Objekte werden nach dem Namen des E-Mail aktivierten öffentlichen Ordner benahmt . Hat man z.B. viele öffentliche Ordner mit dem selben Namen an verschiedenen Orten, kann das schon etwas schwierig werden das richtige Objekt zu finden.
Solange das MESO Objekt besteht erkennt Microsoft die hinterlegte E-Mail-Adresse als gültig an. Sie taucht in der Adressliste auf und Exchange nimmt E-Mails dafür entgegen. Wurde der zugehörige öffentliche Ordner gelöscht, kann die E-Mail natürlich nicht zugestellt werden und Exchange erzeugt ein NDR.
Um herauszufinden, welches MESO Objekt zu keinem öffentlichen Ordner gehört und damit verwaist ist, muss man alle E-Mail aktivierten Ordner und die zugehörigen MESO Objekte identifizieren und kann dann nach dem Ausschlussverfahren alle übrig gebliebenen MESO Objekte löschen. Der Teufel steckt hier aber im Detail. Ich kann dazu den Blog-Post http://bill-long.com/2014/03/08/cleaning-up-microsoft-exchange-system-objects-part-2/ von Bill Long empfehlen.
Wir wissen dass es vorkommen kann, dass ein öffentlicher Ordner zwar nicht E-Mail aktiviert ist, ein MESO Objekt dazu jedoch weiterhin vorhanden ist. Zum Beispiel weil der Ordner vorher mal E-Mail aktiviert war, der Admin ihn wieder E-Mail deaktivierte und Exchange das MESO Objekt nicht korrekt entfernte. Schickt man nun eine E-Mail an die dem MESO Objekt hinterlegte E-Mail-Adresse, wird die E-Mail trotzdem zugestellt. Unter Umständen sind somit E-Mail-Adressen „produktiv“ im Einsatz, obwohl das Objekt E-Mail disabled ist, und man merkt es nicht mal. Löscht man nun das, rein technisch, verwaiste MESO Objekt, stört man unter Umständen den produktiven Betrieb. Es ist also Vorsicht geboten.
Mit einem kleinen Script lassen sich die verwaisten MESO Objekte vom Exchange 2010 Server aus identifizieren. Das Script beinhaltet keine Löschfunktion, es ist sinnvoll das Ergebnis aus den genannten Gründen auf Plausibilität zu prüfen. Das Powershell-Script von Bill kann auf Git Hub heruntergeladen werden: Find-UnlinkedPFProxies.ps1
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 |
$gcRootDSE = [ADSI]"GC://RootDSE" $gcRoot = [ADSI]("GC://" + $gcRootDSE.dnsHostName) "Using " + $gcRoot.Path # Find all the PF proxies "Finding all public folder directory objects..." $pfProxyFinder = new-object System.DirectoryServices.DirectorySearcher($gcRoot, "(objectClass=publicFolder)") $pfProxyFinder.PageSize = 100 $allPfProxies = $pfProxyFinder.FindAll() "Found " + $allPfProxies.Count.ToString() + " public folder directory objects." # Make a dictionary with the GUID to DN mapping of each PF proxy $pfProxyDictionary = new-object 'System.Collections.Generic.Dictionary[string, string]' foreach ($pfProxy in $allPfProxies) { $guid = new-object Guid(,$pfProxy.Properties["objectguid"][0]) $pfProxyDictionary.Add($guid.ToString(), $pfProxy.Properties["distinguishedname"][0].ToString()) } # Don't need the search results anymore, so give back that memory $allPfProxies = $null # Find all the mail-enabled PFs using Exchange Management Shell "Finding all mail-enabled public folders..." $mailEnabledPFs = Get-PublicFolder -recurse -resultsize unlimited | WHERE { $_.MailEnabled -eq $true } "Found " + $mailEnabledPFs.Count.ToString() + " mail-enabled public folders." # Is this Exchange 2013? If so, we can just look at MailRecipientGuid, which is faster $pfobjectMembers = Get-PublicFolder | get-member $hasRecipientGuid = ($pfobjectMembers | WHERE { $_.Name -eq "MailRecipientGuid" }).Length -gt 0 # Now figure out which directory objects aren't being used "Determining which directory objects are not linked to a folder..." foreach ($pf in $mailEnabledPFs) { "Checking folder: " + $pf.ParentPath + $pf.Name $guidString = $null if ($hasRecipientGuid) { $guidString = $pf.MailRecipientGuid.ToString() } else { $guidString = ($pf | Get-MailPublicFolder).Guid.ToString() } $mailPF = ($pf | Get-MailPublicFolder) if ($pfProxyDictionary.ContainsKey($mailPF.Guid.ToString())) { $pfProxyDictionary.Remove($mailPF.Guid.ToString()) | Out-Null } } # The only stuff left in the dictionary at this point is unlinked directory objects "" "There are " + $pfProxyDictionary.Count.ToString() + " public folder directory objects not linked to any folder. They are:" foreach ($value in $pfProxyDictionary.Values) { $value } "Done!" |
Export der alten Public Folder Struktur und Statistiken
Nachdem die Voraussetzungen geprüft sind, ziehen wir uns aktuelle Statistiken und Daten der bestehenden öffentlichen Ordner Struktur. Diese dient uns als Referenz um später den Erfolg der Migration zu prüfen und auch um gegebenenfalls nochmal in der alten Struktur nachschauen zu können. Wir führen die Befehle auf dem Exchange Server 2010 durch.
Export der Public Folder Struktur
|
1 |
Get-PublicFolder -Recurse | Export-CliXML D:\PFMigration\Legacy_PFStructure.XML |
Export der Public Folder Item-Statistik (Anzahl, Größe, usw.)
|
1 |
Get-PublicFolderStatistics -ResultSize Unlimited | Export-CliXML D:\PFMigration\Legacy_PFStatistics.XML |
Export der Public Folder Berechtigungen
|
1 |
Get-PublicFolder -Recurse | Get-PublicFolderClientPermission | Select-Object Identity,User -ExpandProperty AccessRights | Export-CliXML D:\PFMigration\Legacy_PFPerms.XML |
Export der Mail Enabled Public Folder
|
1 |
Get-publicfolder “\” -recurse | where {$_.MailEnabled -eq “True”} | Export-CliXML D:\PFMigration\Legacy_PF-Mailenabled.XML |
Mapping zwischen Microsoft Exchange System Objekt und Mail Enabled Public Folder. Hier ist etwas mehr Powershell-Magie notwendig, aber diese Mapping ist Gold Wert, um später Mailadressen und Public Folder zu finden. Denn: dieser Befehl geht nicht mehr unter Exchange 2013
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
add-pssnapin Microsoft.Exchange.Management.PowerShell.E2010 $outputCollection = @() $mailpflist = Get-PublicFolder "\" -Recurse | where {$_.MailEnabled -eq "True"} foreach ( $pf in $mailpflist ) { # Get some additional Attributes $mpf = $pf | Get-MailPublicFolder # Create a new Object $outputObject = new-object -typeName psobject -Property @{ Name = $pf.Name DisplayName = $mpf.DisplayName Alias = $mpf.Alias Parentpath = $pf.ParentPath PrimarySmtpAddress= $mpf.PrimarySmtpAddress WindowsEmailAddress= $mpf.WindowsEmailAddress } #Add the object to the collection $outputCollection += $outputObject } $outputCollection | Export-Clixml D:\PFMigration\Legacy_MailenabledPF-Mapping.XML |
Bereinigen der alten Public Folder Namen hinsichtlich Sonderzeichen
Gerade hinsichtlich Mail Enabled Public Foldern ist es wichtig, auf verbotene Zeichen zu achten. So dürfen z.B. keine Backslashes \ im Namen eines Public Folders enthalten sein und Aliases dürfen keine Leerzeichen enthalten.
Überprüfen der Public Folder Namen auf Backslashes
|
1 |
Get-PublicFolderStatistics -ResultSize Unlimited | Where {$_.Name -like "*\*"} | Format-List Name, Identity |
Mail Enabled Public Folder Aliases auf Leerzeichen und Kommas prüfen sowie korrigieren
|
1 2 3 4 |
$pfs= Get-publicfolder “\” -recurse | where {$_.MailEnabled -eq “True”} | Get-MailPublicFolder | where {$_.alias -like ‘* *’ -or $_.alias -like ‘*,*’} foreach ($pf in $pfs) { set-mailpublicfolder $pf.Identity -Alias:($pf.alias -replace ‘\s|\,’,””) } |
Korrektur der Berechtigung auf Mail Enabled Public Foldern
Da seit Exchange 2013 CU6 die Mailzustellung an öffentliche Ordner fehlgeschlägt, wenn dem Benutzer Anonymous das Recht CreateItems fehlt, müssen wir vor der Migration sicher gehen, dass dieses Recht auf allen Mail Enabled Public Foldern gesetzt ist. Powershell hilft an der Stelle.
|
1 |
Get-PublicFolder -Identity "\" -Recurse -ResultSize unlimited | Where-Object {$_.mailenabled -like "true"} | Get-PublicFolderClientPermission -User "Anonymous" | Where-Object {$_.AccessRights -like "None"} | Add-PublicFolderClientPermission -User "Anonymous" -AccessRights CreateItems |
Erstellen der CSV Dateien
Als nächstes laden wir die angesprochenen Migrationsscripte auf unseren Exchange 2010 Server in ein Verzeichnis. In unserem Szenario D:\PFMigration\Scripts. Das sollte dann wie folgt aussehen.
Mit dem Script Export-PublicFolderStatistics.ps1 fangen wir an. Das Ergebnis dieses Scripts ist eine CSV-Datei mit einer Auflistung der öffentlichen Ordner und ihrer Größe in Bytes.
|
1 2 3 4 5 6 7 8 9 |
[PS] D:\PFMigration\Scripts>.\Export-PublicFolderStatistics.ps1 -PublicFolderServer EX2010 -ExportFile ..\PublicFolderStats.csv [28.06.2016 10:48:55] Enumerating folders under NON_IPM_SUBTREE... [28.06.2016 10:48:59] Enumerating folders under NON_IPM_SUBTREE completed...96 folders found. [28.06.2016 10:49:03] Retrieving statistics from server EX2010 [28.06.2016 10:49:03] Retrieving statistics from server EX2010 complete...99 folders found. [28.06.2016 10:49:03] Total unique folders found : 99. [28.06.2016 10:49:03] Exporting statistics for 99 folders [28.06.2016 10:49:03] Exporting folders to a CSV file [PS] D:\PFMigration\Scripts> |
Die resultierende CSV Datei sieht dann wie folgt aus:
Diese Datei dient als Quelle für das Script PublicFolderToMailboxMapGenerator.ps1. Das Ergenis dieses Scripts ist eine weitere CSV, welche die Aufteilung der öffentlichen Ordner in eine odere mehrere Public Folder Mailboxes beschreibt. Dieses ist bei größeren Public Folder Datenbanken notwendig, die einzelnen Postfächer nicht zu groß werden zu lassen. 20 Gigabyte je Public Folder Mailbox ist ein guter Wert, eine Public Folder Mailbox darf nicht größer als 100 GB werden. Es gibt noch weitere Parameter, anhand dessen eine Aufteilung der öffentlichen Ordner auf mehrere Postfächer sinnvoll ist. Dazu gehört die maximale Anzahl von Ordnern sowie die maximale Anzahl von Userlogons (seit Exchange 2013 CU 8 werden maximal 2000 gleichzeitige Anwender pro Mailbox unterstützt).
|
1 2 3 4 5 6 7 |
[PS] D:\PFMigration\Scripts>.\PublicFolderToMailboxMapGenerator.ps1 -MailboxSize (20GB) -ImportFile ..\PublicFolderStats.csv -ExportFile ..\FolderToMailbox.csv [28.06.2016 11:31:17] Reading public folder list... [28.06.2016 11:31:17] Loading folder hierarchy... [28.06.2016 11:31:17] Allocating folders to mailboxes... [28.06.2016 11:31:17] Trying to accomodate folders with their parent... [28.06.2016 11:31:17] Exporting folder mapping... [PS] D:\PFMigration\Scripts> |
Die resultierende Datei sind wie folgt aus:
In vielen Szenarien ist hier nur ein Eintrag zu finden, nämlich der Root-Folder „\“ mit einer dahinter angegebenen TargetMailbox. In größeren Umgebungen werden aber mehrere Mailboxen benötigt, wie in diesem Beispiel. Der Name der TargetMailbox wird von dem Script als Mailbox1 benannt. Den habe ich hier manuell auf PFMBX01 und PFMBX02 geändert. Die Datei kann nach den eigenen Vorstellungen angepasst oder erweitert werden. Über diesen Weg ist auch eine geografische Verteilung der Daten möglich. Es kann also beispielsweise der Europa-Stamm der öffentlichen Ordner in eine Mailbox gelegt werden, die ich im europäischen Datacenter bereitstelle, während die asiatischen öffentlichen Ordner in einer Mailbox gespeichert sind, die ich m asiatischen Datacenter bereitstelle.
Erstellen der Public Folder Postfächer in Exchange 2013/2016
Mit dem erzeugten Mappingfile FolderToMailbox.csv können jetzt die Public Folder Postfächer angelegt werden. Wir kopieren die Scripts und die FolderToMailbox.csv auf einen der Exchange 2013/2016 Server an die selbe Stelle. Nun verwenden wir das Script Create-PublicFolderMailboxesForMigration.ps1 auf dem Exchange Server 2013/2016. Als Parameter geben wir die Mapping-Datei sowie die Anzahl der zu erwarteten, gleichzeitigen Verbindungen.
|
1 |
[PS] D:\PFMigration\Scripts>.\Create-PublicFolderMailboxesForMigration.ps1 -FolderMappingCsv ..\FolderToMailbox.csv -EstimatedNumberOfConcurrentUsers:500 |
Bei meinen Migrationen führte dieser Befehl zu Fehlern, wenn ich mehr als eine Mailbox anlegen wollte.
No active public folder mailboxes were found. This happens when no public folder mailboxes are provisioned or they are provisioned in ‚HoldForMigration‘ mode. If you’re not currently performing a migration, create a public folder Mailbox.
Das Problem ist der Paramenter HoldForMigration (siehe auch https://support.microsoft.com/en-us/kb/2786607), welcher in Migrationsszenarien verwendet wird. Im Script wird das primäre Postfach mit dem Paramenter HoldForMigration:$true erstellt. Die sekundären Postfächer jedoch mit HoldForMigration:$false. Leider funktioniert das, zumindest unter Exchange 2013, nicht. Daher muss die Zeile 89 wie folgt geändert werden:
Zeile 89 in Script Create-PublicFolderMailboxesForMigration.ps1
CreateMailbox $name $isExcludedFromServingHierarchy $isMigrationTarget $false;
ändern in folgende Zeile ($false auf $true ändern):
CreateMailbox $name $isExcludedFromServingHierarchy $isMigrationTarget $true;
Danach klappt auch das Anlegen von mehr als einer Public Folder Mailbox. Auf dem Exchange Server 2013/2016 können die angelegten Postfächer mit Get-Mailbox -Publicfolder abgefragt und damit validiert werden.
Initiale Datenmigration
Alle vorbereitenden Maßnahmen sind durchgeführt und die Zielpostfächer angelegt. Wir starten mit der initialen Migration. Dabei werden die Inhalte der legacy Public Folder von Exchange 2007/2010 in die neuen Postfächer Seitens Exchange 2010/2013 kopiert, der Migrationsjob jedoch nicht abgeschlossen. So kann dieser Schritt bereits vor der geplanten Downtime durchgeführt werden. Abhängig von der Anzahl der Items kann dieser Schritt von einigen Stunden bis hin zu Tagen dauern. Auf dem Exchange 2016 Server starten wir folgendes Powershell-Cmdlet.
|
1 2 3 4 5 6 7 |
[PS] D:\PFMigration\Scripts> New-MigrationBatch -Name PFMigration -SourcePublicFolderDatabase (Get-PublicFolderDatabase -Server EX10) -CSVData (Get-Content ..\FolderToMailbox.csv -Encoding Byte) -BadItemLimit 200 -NotificationEmails status@s2-datentechnik.de Identity Status Type TotalCount -------- ------ ---- ---------- PFMigration Created PublicFolder 1 [PS] D:\PFMigration\Scripts> |
Folgende Parameter habe ich hier angegeben:
- Name: Eindeutiger Name für den Migrationsjob
- SourcePublicFolderDatabase (-Server) beschreibt die die Public Fodler Datenbank auf dem Exchange 2007/2010 Server. Servername in meinem Lab: EX10
- CSVData: Der Pfad zu unserer Mapping-Datei aus dem vorherigen Abschnitt
- AcceptLargeDataLoss: bei einem BadItemLimits von mehr als 50 muss dieser Parameter mit angegeben werden
- BadItemLimit: Tolerierte, fehlerhafte Items
- NotificationEmails: optionaler Parameter zur Notifikation, wenn der Job komplett abgeschlossen wurde
Damit wurde der Batch Job angelegt. Um ihn zu starten ist folgender Befehl notwendig.
|
1 |
[PS] D:\PFMigration\Scripts> Start-MigrationBatch PFMigration |
Ab jetzt heißt es abwarten. Der Status kann zwischenzeitig wie folgt über die Shell abgerufen werden.
|
1 |
[PS] D:\PFMigration\Scripts> Get-PublicFolderMigrationRequest | Get-PublicFolderMigrationRequestStatistics -IncludeReport | fl |
Alternativ dazu kann der Status auch über das Exchange Admin Center abgefragt werden.
Anfangs steht der Progress Status normalerweise auf Queued bevor der Job mit Abarbeitung durch Exchange startet. Während der Migration sollte der Status Syncing lauten. Sobald er mit der initialen Datenmigration fertig ist, folgt der Status AutoSuspended. Darauf müssen wir warten. Unter Umständen viele Stunden.
Abschluss der Migration
Sobald der Migrationsbatch auf AutoSuspend steht, können wir die Migration finalisieren. Dies ist der Startzeitpunkt der Downtime. Mit folgendem Befehl, ausgeführt auf dem Exchange 2007/2010 Server, sperren wir die öffentlichen Ordner für den Zugriff der Outlook Clients sowie den Mailflow. Neue E-Mails mit öffentlichen Ordnern als Empfänger bleiben n der Queue.
|
1 |
[PS] D:\> Set-OrganizationConfig –PublicFoldersLockedForMigration:$true |
Dieser Vorgang kann, abhängig von der Umgebung, ein paar Minuten bis mehrere Stunden in Anspuch nehmen. An der Stelle ist es wichtig, geduldig zu sein. Erst wenn die öffentlichen Ordner gesperrt sind, können die folgenden Befehle fehlerfrei ausgeführt werden.
Tip: Ein Neustart des Information Stores auf dem alten Exchange Server löscht den Store Cache und beschleunigt diesen Schritt.
Jetzt können wir zurück auf den Exchange 2013/2016 Server und die dortigen öffentlichen Ordner aktivieren.
|
1 |
[PS] D:\> Set-OrganizationConfig -PublicFoldersEnabled Remote |
Danach kann der Migrationsbatch abgeschlossen werden.
Final Sync
Es folgt eine finale Synchronisierung der gesperrten öffentlichen Ordner von 2007/2010 zu 2013/2016.
|
1 2 3 4 5 6 7 |
[PS] D:\> Complete-MigrationBatch PFMigration Confirm Are you sure you want to perform this action? Complete migration batch "PFMigration"? [Y] Yes [A] Yes to All [N] No [L] No to All [?] Help (default is "Y"): Y [PS] D:\> |
Der Status des Migrationsbatches ändert sich auf Completing und zuletzt auf Completed. Die Dauer dieses finalen, inkrementellen Syncs ist abhängig von der Anzahl der in der Zwischenzeit geänderter Objekte.
Hinweis: Dieser Vorgang kann mehrere Stunden dauern
Erster Test
Bevor wir die migrierten öffentlichen Ordner für alle Anwender freischalten, aktivieren wir sie nur für einen Testbenutzer.
|
1 |
[PS] D:\> Set-Mailbox -Identity sschaffranneck -DefaultPublicFolderMailbox "PFMBX01" |
Als DefaultPublicFolderMailbox wählt man hier die primäre Public Folder Mailbox, welche auch die Hierarchie hält ( Get-Mailbox -PublicFolder ). Jetzt kann der Zugriff auf die öffentlichen Ordner wahlweise mit Outlook 2010 oder höher oder aber mit Outlook WebApp geprüft werden. Zu prüfen Sind die Hierarchie, Inhalt, Berechtigungen, E-Mail-Settings und Regeln. Falls es an der Stelle zu Unerwarteten Ergebnissen kommt, empfiehlt sich ein Rollback. Die Methode dazu kann hier nachgelesen werden: https://technet.microsoft.com/en-us/library/dn912663(v=exchg.160)#RollBack
An dieser Stelle ist übrigens noch kein Mailflow aktiv, dh. E-Mails mit den Public Foldern als Ziel landen in der Queue des Exchange Servers.
Aktivierung der Modern Public Folder
Sofern der Test erfolgreich war, können die öffentlichen Ordner für alle ausgerollt werden. Dafür sind folgende Kommandos notwendig. Wir fangen auf dem Exchange 2013/2016 an. Die Hierarchie der Modern Public Folder wird veröffentlicht:
|
1 |
[PS] D:\> Get-Mailbox -PublicFolder | Set-Mailbox -PublicFolder -IsExcludedFromServingHierarchy $false |
Jetzt wird die Migration als abgeschlossen markiert. Auszuführen auf dem Exchange 2007/2010 Server.
|
1 |
[PS] D:\> Set-OrganizationConfig -PublicFolderMigrationComplete:$true |
Zuletzt werden die Modern Public Folder noch aktiviert. Auszuführen auf auf Exchange 2013/2016.
|
1 |
[PS] D:\> Set-OrganizationConfig -PublicFoldersEnabled Local |
Geschafft! Ab sofort erfolgt auch wieder die Zustellung der zwischengespeicherten Mails. Jetzt sind jedoch noch ein paar Validierungen hilfreich.
Validierung der Migration
Jede „Labor“-Migration ist jetzt bereits abgeschlossen und das Migrationsteam liegt sich euphorisch in den Armen. Nur der erfahrene Engineer weiß, wie wichtig Validierungsläufe sind.
Mail-Enabled Folder prüfen
In der Vorbereitung haben wir eine auf dem Exchange 2007/2010 Server die Datei Legacy_MailenabledPF-Mapping.XML erstellt, welche alle E-Mail-Adressen der Mail Enabled Public Folder beinhaltet. Das nutzen wir aus, um per Script eine Mail an alle Empfänger abzusetzen.
Tip: An der Stelle muss sichergestellt werden, dass damit keinen internen, auf Public Folder basierenden, Geschäftsprozesse beeinträchtigt werden.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
$sender = "valid-account@s2-datentechnik.de" $Subject = "Test E-Mail - PF-Migration" $body = "Just a test! Please delete me" $smtpserver = "exchange2013.company.local" $tmpcsv = "adressen.csv" Import-Clixml .\Legacy_MailenabledPF-Mapping.XML | Select-Object Windowsemailaddress | Export-Csv $tmpcsv Import-Csv $tmpcsv| Sort-Object WindowsEmailAddress -Unique | ForEach-Object { Write-Host "Sending mail from $sender to" $_.WindowsEmailAddress Send-MailMessage -To $_.WindowsEmailAddress -From $sender -Subject $subject -Body $body -SmtpServer $smtpserver Write-Host "...done" } Remove-Item $tmpcsv -force |
Zustellungsfehler werden dem Absender $sender zugestellt. Es empfiehlt sich auch, die Zustellung einmal von extern zu testen, um fehlende Rechte des Benutzers Anonymous auszuschließen.
Weiterführende Information
Selbst wenn man sich an alle Schritte hält und alle Weisheiten berücksichtigt, pinkelt einem Microsoft ans Bein. Ein paar pikante Erfahrungen will ich euch nicht vorenthalten.
Leerzeichen in Alias
No no no. Die Migration ermöglicht die Migration öffentlicher Ordner von Exchange 2007/2010 zu 2013 mit E-Mail Enabled Public Foldern, selbst wenn der Alias ein Leerzeichen enthält. Leider funktioniert der Mailempfang dann nicht. Man muss dann einmal den Ordner mail disablen und danach wieder enablen. Dann wird der Alias ohne Leerzeichen angelegt und der Empfang von E-Mails ist wieder möglich. Besser ist es also, vorher die Ordner entsprechend nach Leerzeichen oder Kommas zu durchsuchen (siehe „Vorbereitung der Migration“).
Empfang von E-Mails externer Absender
Mit Exchange 2013 CU6 wurde ein entsprechendes Änderung eingeführt, siehe auch https://blogs.technet.microsoft.com/exchange/2014/08/26/public-folder-updates-in-exchange-2013-cu6-improving-scale-and-more/ unter dem Absatz „Mail-Enabled Public Folder Permission Changes“. Der User Anonymous benötigt jetzt explizit das CreateItems Recht auf den einzelnen Public Foldern. Siehe auch https://technet.microsoft.com/de-de/library/aa997560(v=exchg.150).aspx.
|
1 |
Add-PublicFolderClientPermission "\Customer Feedback" -AccessRights CreateItems -User Anonymous |
Public Folder Rules
Während einige den Ordner-Assistenten nicht einmal kennen, bilden andere Firmen hierüber businesskritische Prozesse ab. Der Order-Assistent kann über Outlook auf einem öffentlichen Ordner aufgerufen werden, sofern der Anwender das Recht „Owner“ hat.
Über den Assistenten lassen sich unter anderem Weiterleitungsregeln konfigurieren.
Mir ist an der Stelle folgender Designchance von 2010 zu 2013 bekannt. Ist der Absender einer E-Mail auch als Empfänger der Weiterleitungsregel eingetragen, erhält dieser keine Kopie der Nachricht. Die Mail wird also an alle eingetragenen Empfänger weitergeleitet, außer an den Absender. Das ist an sich nicht kritisch, jedoch war dieses Verhalten bei Exchange 2010 noch anders. Da hat der auch Absender eine Kopie erhalten. Ein Workaround wäre an der Stelle eine Verteilerliste zu erstellen mit allen gewünschten Empfängern, und die Mail an an die Verteilerliste weiterzuleiten. Aber das ist natürlich umständlicher. Microsoft spricht hier davon, ein Design Change Antrag einzureichen. In wie weit das jedoch erfolgsversprechend (und sinnvoll) ist, kann jeder für sich selbst beurteilen.
I just wanted to provide you with a summary on the symptoms that we are currently seeing and how it looks to be working. You have noticed with mail enabled public folders that have rules set up to forward all incoming mail to this folder to a group of particular users and if they send a message to this folder, they do not receive the FWD message. This appears to be by design as I am able to reproduce this same scenario where the rule still works correctly, but we will just not submit a message to the user who originally sent the email to this folder, providing that they are on the Forwarding list directly. We can verify this by looking at the message tracking logs to show that the message was FWD, but it doesn’t include the user who original sent the message. However, I did try to test another scenario and you are able to get around this if you add all the users who you want to get forward messages from this folder to a Distribution Group and then replace the users on the Forwarding line with the Distribution Group then the rule will still fire and send to the Distribution Group. This will bypass the logic of not sending a message to a particular SMTP address in the Folder Assistance and just rely on the Transport Layer to deliver the message to all the correct people. This could be a valid workaround that you can implement instead of trying to request a Design Change Request (DCR) for this scenario, as I am guessing they changed it to this logic for a particular reason
Gerade mit den Rules gibt es noch andere, nicht vollständig aufklärbare oder reproduzierbare Fehler. So wurde mir berichtet, das die Zustellung von weitergeleiteten E-Mails aus einem Public Folder in einen anderen fehlschlägt – ohne eine Fehlermeldung zu hinterlassen. Das wird dann brisant, wenn in der Regel gleichzeitig das löschen der Mail beauftragt wird. Also Vorsicht bei Migrationen von Public Foldern mit Regeln. Testen, testen, testen.
Interessante Links
FAQ: Öffentliche Ordner: https://technet.microsoft.com/de-de/library/jj552408(v=exchg.150).aspx
Grenzwerte für öffentliche Ordner: https://technet.microsoft.com/de-de/library/dn594582(v=exchg.150).aspx
Sehr guter Artikel. Insbesondere die Hinweise zu Problemen hinsichtlich der Aliase. Bei der reinen Nutzung von Legacy Public Foldern war das Ganze sehr tolerant. Hier gilt es das AD vorher gründlich aufzuräumen. Hierzu gehören auch verwaiste MESO Einträge für ehemals E-Mail aktivierte Ordner.
Danke Thomas, guter Hinweis auf die verwaisten MESO Objekte. Das nehme ich gleich mal mit auf.
Super Artikel!
Sehr ausführlich und hat mir heute wirklich geholfen 🙂
Ich bin einer anderen Anleitung gefolgt (von Frankysweb) und habe am Schluss Probleme mit der Mailzustellung an Öffentliche Ordner gehabt. Aus für mich unerfindlichen Gründen, gingen Mails an die öffentlichen Ordner noch an den alten Exchange 2010 (habe auf 2016 migriert). Bin der Anleitung im letzten Schritt gefolgt, das Skript zur Validierung hat anscheinend den Knoten gelöst und alles funktionierte wieder…
Mir ist klar, dass das eigentlich nicht sein kann… vielleicht war auch das erneute Ausführen der Commands, zum aktivieren der Modern Public Folders der knackpunkt..
Wie dem auch sei, vielen Dank 🙂
Noch eine kleine Frage am Ende:
Das Skript zum finden der verwaisten MESO Objekte liefert mir einiges an Treffern.. wenn ich im ADSI Edit nachschaue finde ich diese auch. Beim Vergleichen mit einem nicht gelisteten Eintrag finde ich aber keinen Unterschied. Der öO ist auch noch valide und funktioniert vollständig.
Dennoch ein Grund sich darüber dabei Gedanken zu machen?
Hallo Felix,
es kann durchaus sein, dass der interne link zwischen dem öffentlichen Ordner und MESO Objekt korrupt ist. Wenn du dort einige findings hast, probier mal die Mailaktivierung des entsprechenden öffentlichen Ordner zu entfernen. Sollte das MESO Objekt dann nicht aufgeräumt werden, lösche es und aktivier dann den Ordner wieder.
Achtung, zwischen den Schritten ruhig ein paar Minuten warten.
Gruß Sven
Sehr feine Anleitung die fast auf Anhieb funktioniert hat.
Zwei Sachen fehlen.
auf dem Quellserver muss noch eine Postfachdatenbank vorhanden sein, ansonsten lässt sich die initiale Datenmigration nicht starten.
Die Finale Synchronisation lässt sich nur starten, wenn man auf dem Quellserver den Dienst MS-Exchange-Informationsspeicher neu gestartet hat.
Gute Anleitung,
ich habe folgendes Problem, ich kann den Migrationsbatch nicht beenden, da er in einen Fehler läuft:
„Migrierte Daten: 153.7 GB (164,987,014,244 bytes)
Migrationsrate: 0 B (0 bytes)
Fehler: MigrationPermanentException: Anforderung ’PublicFolderMailboxMigration58adb717-90bb-42cf-9293-58caf8842d47‘ hat bereits mehr als 3 große Elemente erkannt. Ein Grenzwert von 0 kann nicht festgelegt werden. –> Anforderung ’PublicFolderMailboxMigration58adb717-90bb-42cf-9293-58caf8842d47‘ hat bereits mehr als 3 große Elemente erkannt. Ein Grenzwert von 0 kann nicht festgelegt werden. Bericht: Mailbox1 Den Bericht für diesen Benutzer herunterladen“
Wenn ich den Befehl „Complete-MigrationBatch PFMigrationausführe“ bekomme ich dann folgende Meldung:
Der SyncAndComplete-Parameter ist nur zulässig, wenn es keine Benutzer im Zustand „Fehler“ oder „Beendet“ gibt.
+ CategoryInfo : NotSpecified: (:) [Complete-MigrationBatch], MigrationBatchCannotBeCompletedException
+ FullyQualifiedErrorId : [Server=EX01,RequestId=ccb6375b-2cb4-433a-a74d-4cfe98a8aebe,TimeStamp=03.01.2020 09:45:1
4] [FailureCategory=Cmdlet-MigrationBatchCannotBeCompletedException] B5F04467,Microsoft.Exchange.Management.Migrat
ion.MigrationService.Batch.CompleteMigrationBatch
+ PSComputerName : ex01.stein.local
Für eure Hilfe wäre ich dankbar.
Gruß Dawid
Hallo David,
wenn es nur wenige Elemente sind: kannst du Elemente zB per Hand migrieren (vor der Migration in eine PST ziehen und hinterher wieder in die PF schieben). Ansonsten kontrollier mal die Maxitemsize der einzelnen Ordner. Da scheinen Elemente in den Ordnern zu liegen, die größer als die Maxitemsize der Ordner sind. Auch kannst du den Migration Batch mit dem zusätzlichen Parameter -LargeItemLimit nutzen.
Gruß Sven
Hallo,
wir haben bisher alle Postfächer aus der Ex2010 Sp3 RU30 Umgebung auf die Ex2016 CU14 (+SecUpdate) übertragen sowie die Systempostfächer.
Sofern ich aber nun den Befehl „Get–PublicFolder“ auf einem Ex2010 Server eingebe erhalte ich folgende Meldung.
Vor Monaten hat das noch problemlos geklappt aber jetzt nicht mehr und mein Admin Konto hat auch kein Postfach mehr.
Hier auch meine Frage im Technet-Forum.
https://social.technet.microsoft.com/Forums/de-DE/3f68f15c-eacf-4d1b-89ac-6bf930932caf/exchange-migration-2010-gt-2016-publicfolder-migration-fehler?forum=exchange_serverde
Habe nun testweise ein Postfach für ein Adminkonto (mit Exchange Rechten) gegeben und siehe da ich erhalte wieder Ergebnisse.
Hallo,
die Anleitung ist toll, hat alles gepasst. Jedoch funktioniert der Zugriff auf die öffentlichen Ordner per OutlookAnywhere nicht. Innerhalb des LAN ist der Zugriff problemlos möglich!
Bin ich nur ungeduldig?
Der Befehl Get-MailboxDatabase auf dem Exchange 2016 zeigt mir, dass die PublicFolderDatabase noch auf die „alte“ Datenbank auf dem Exchange 2010 zeigt. Muss ich händisch eine Anpassung vornehmen?
Der Exchange 2010 ist noch nicht deinstalliert. Hat jemand einen Tipp oder Hinweis für mich?
Danke im Voraus!
Cyprian