Exchange Massenmove

Da betreiben Sie viele Jahre ihren Exchange Server mit einer DAG, vielen Festplatten und Datenbanken und dann richten Sie den Exchange Hybrid Mode mit einem Office 365 Tenant ein und migrieren einen Großteil der Konten in die Cloud. Einige Postfächer bleiben On-Premises aber die vorhandenen Server sind immer noch in Vollausstattung vorhanden und auch die Datenbanken wurden durch die Migration ja kein Stück kleiner sondern nur leerer. Diese Seite beschreibt die Situation und wie ein Rückbau erfolgen kann.

Beachte dazu auch Postfach Statistiken bei Migrationen - Get-Mailboxdatabase, MailboxStatistik u.a. liefern nicht immer aussagekräftige Daten

Ist-Aufnahme und Ziel

Ich gehe mal davon aus, dass Sie ein oder mehrere Exchange 2016-Server haben, die sich mit den verbliebenen 5-10% Restpostfächer, so sie überhaupt noch vorhanden sind, langweilen. Es gibt ja durchaus Kunden mit großen DAG-Umgebungen mit vielen Servern und noch mehr lokalem Storage. Da kommen schnell ein paar Terabyte Festplatten, und ausreichend RAM und CPU zusammen und der Wunsch, die Umgebung zu reduzieren. Ganz abschalten können Sie den letzten Exchange Server natürlich nicht, denn solange ADSync installiert ist, müssen Sie noch lokal die Empfänger provisionieren und vielleicht gibt es lokal ja auch noch Faxserver und andere SMTP-Dienste, die über den Hybrid Connector Server arbeiten. Aus meiner Skriptsammlung die ich immer wieder weiter entwickle, gibt es das Skript Get-MailboxDatabaseInfo, welches sich alle Datenbanken ihrer Topologie holt und zu jeder Datenbank sich die Größe, Whitespace, Anzahl der Postfächer und die Verteilung auf die Server holt.

get-mailboxdatabaseinfo.ps1

Der Aufruf erfolgt einfach in einer Exchange PowerShell.

.\get-mailboxdatabaseinfo.ps1 | Export-Csv -NoTypeInformation .\mailboxdatabaseinfo.csv

Die Ausgabe kann sehr einfach in eine CSV-Datei exportiert und in Excel hübsch formatiert werden, z.B. indem der "FreePercent" als Balken und die Aktivierungsreihenfolge als Farbe koloriert wird.

Es ist schon hier gut zu sehen, dass auf dieser DAG aus sechs Server die meisten Datenbanken zwar ca. 500GB groß sind aber nur noch wenige Postfächer dort gehostet werden. Aber auf den ersten Blick ist zu sehen, dass der freie Platz eher bei 80-95% ist. Das Backup sichert also jeden Tag viele Terabyte an Datenbanken.

Konsolidierung

Die Umgebung ist deutlich zu groß und mehrere Aufgabenstellungen sind zu beleuchten:

  • Weniger Server
    Vielleicht reicht eine DAG aus 2 Servern. Aber auch wenn man 4 Server behält, könnte man einfach die Replikate von E13 und EX14 auf die anderen Server verteilen. Jede Datenbank hat 4 Replikate und das würde auch auf 4 verbleibende Server passen. Selbst mit zwei Servern könnte man dies unter Verlust von zwei Kopien zusammenlegen. Allerdings müsste man auf den verbleibenden Servern dann weitere LUNs einhängen, damit die Pfade passen.
  • Datenbankplatz
    Aber die Größe der Datenbanken ändert sich bei der Umlagerung der Replikate nicht. Ein "Offline Defrag" scheidet aber aus. Es wäre nur mit einer Offline-Zeit" und Reseeding möglich. Man könnte aber die Postfächer mehrerer Datenbanken "zusammenlegen" und die leeren Datenbanken dann entfernen.
  • Mailbox Move und Datenbankknamen
    Wie sieht das aber am Ende aus, wenn die Namen der Datenbanken dann nicht mehr durchnummeriert sind? auch stellt sich die Frage wie "balanciert" dies ist. Datenbanken können generell und erst recht in einer DAG nicht umbenannt werden, da Felder wie "HomeMDB" bei den Benutzern darauf verweisen.

Also haben wir uns dafür entschieden, einfach frische neue Datenbanken auf den verbleibenden Servern anzulegen und die verbliebenen Postfächer in diese neue Datenbanken zu migrieren. Dann ist auch deutlich sichtbar, was alt und was neu ist.

Das ist nur eine mögliche Herangehensweise. Welcher Weg des Downsizing und welche Reorganisation sie nutzen, können wir gerne besprechen.

Also haben wir uns einen Schlachtplan erstellt, in welcher Weise die Konsolidierung erfolgen soll.

Neue Datenbanken anlegen

Zuerst haben wir dafür gesorgt, dass auf allen verbliebenen drei Servern genug Platz vorhanden ist und die Pfade überall identisch ist. Dann haben wir 6 Datenbanken angelegt, da auch weiterhin eine Datenbank nicht größer als 500 GB sein sollte und die verbleibenden Postfächer ca. 1TB nutzen. Mit 50% Wachstum bis zum nächsten Update von Exchange 2016 auf Exchange vNext sollten wir hinkommen.

New-MailboxDatabase MDB01 -server ex10 -EdbFilePath c:\MNT\Disk1\EDB\MDB01\MDB1.edb -LogFolderPath c:\disks\Disk1\LOGS\MDB01
New-MailboxDatabase MDB02 -server ex11 -EdbFilePath c:\MNT\Disk2\EDB\MDB02\MDB2.edb -LogFolderPath c:\disks\Disk2\LOGS\MDB02
New-MailboxDatabase MDB03 -server ex12 -EdbFilePath c:\MNT\Disk3\EDB\MDB03\MDB3.edb -LogFolderPath c:\disks\Disk3\LOGS\MDB03
New-MailboxDatabase MDB04 -server ex10 -EdbFilePath c:\MNT\Disk4\EDB\MDB04\MDB4.edb -LogFolderPath c:\disks\Disk4\LOGS\MDB04
New-MailboxDatabase MDB05 -server ex11 -EdbFilePath c:\MNT\Disk5\EDB\MDB05\MDB5.edb -LogFolderPath c:\disks\Disk5\LOGS\MDB05
New-MailboxDatabase MDB06 -server ex12 -EdbFilePath c:\MNT\Disk6\EDB\MDB06\MDB6.edb -LogFolderPath c:\disks\Disk6\LOGS\MDB06

Exchange fordert mich hier auf, den Informationsspeicher neu zu starten, damit dieser den Speicherbedarf neu zuweisen kann. Das verzögern wir aber, denn für jede Datenbank brauchen wir noch die Replikate.

Get-MailboxDatabase -Server EX10 | where {$_.name.startswith("MDB")} | Add-MailboxDatabaseCopy -MailboxServer EX11 -ActivationPreference 2
Get-MailboxDatabase -Server EX10 | where {$_.name.startswith("MDB")} | Add-MailboxDatabaseCopy -MailboxServer EX12 -ActivationPreference 3
Get-MailboxDatabase -Server EX11 | where {$_.name.startswith("MDB")} | Add-MailboxDatabaseCopy -MailboxServer EX12 -ActivationPreference 2
Get-MailboxDatabase -Server EX11 | where {$_.name.startswith("MDB")} | Add-MailboxDatabaseCopy -MailboxServer EX10 -ActivationPreference 3
Get-MailboxDatabase -Server EX12 | where {$_.name.startswith("MDB")} | Add-MailboxDatabaseCopy -MailboxServer EX10 -ActivationPreference 2
Get-MailboxDatabase -Server EX12 | where {$_.name.startswith("MDB")} | Add-MailboxDatabaseCopy -MailboxServer EX11 -ActivationPreference 3

Bedenken Sie, dass die Datenbanken noch die Standardeinstellungen haben, u.a. Postfachquota von 2GB, was vermutlich nicht mehr passt. Wie nutzen die Werte der bestehenden Datenbanken:

Get-MailboxDatabase MDB* `
| Set-MailboxDatabase `
      -IssueWarningQuota 8GB `
      -ProhibitSendQuota 9GB `
      -ProhibitSendReceiveQuota 10GB

Dies sind nur ein paar der möglichen Einstellungen. Kontrollieren Sie die Einstellungen, da einige Umgebungen weitere Parameter abweichend konfiguriert haben. Nun sind die Datenbank schon fast fertig aber sind noch im Status "Dismounted".

Datenbanken online nehmen

Nun ist es aber an der Zeit, zuerst den Informationsspeicher auf den Knoten durchzustarten. Mehrere Schritte sind für eine geplante Bereitstellung erforderlich, die ich manuell durchführe

  • HealthCheck
    Da die Server auch produktive Datenbanken haben, schaue ich lieber erst mal nach, ob diese Replikate alle in Ordnung sind. Hier erscheinen natürlich meine neuen Datenbanken als Failed, da Sie noch nicht online sind und der Replication Service nichts prüfen kann.
Get-MailboxDatabaseCopyStatus db0* | group status
  • Je Server nacheinander: Datenbanken verschieben und IS neu starten
    Dann räume ich einen Server nach dem anderen frei, starte den Service neu und warte, dass alles wieder in Sync ist. Ein "Failback" muss ich nicht aktiv machen, denn das kann Exchange mittlerweile alleine
# Move der Datenbanken vom aktiven Servern (nacheinander je Server 10-13)
Move-ActiveMailboxDatabase -Server EX10 -MoveComment "StoreRestart fuer neue Datenbanken"

# Restart des Informationstore
Invoke-Command -ComputerName EX10 -ScriptBlock {Restart-Service msexchangeis}

# Check auf Status (kann etwas dauern, denn Failed geht erst weg, wenn ein Log repliziert wurde.
Get-MailboxDatabaseCopyStatus * | group status
  • Neue Datenbanken online schalten
    Sofern die Datenbank nicht schon durch den Neustart "online" gegangen sind, hole ich da nun nach.
# Mounten der neuen Datenbanken
Get-MailboxDatabase MDB* | Mount-Database
# Kontrolle aller Datenbanken
Get-MailboxDatabaseCopyStatus * | group status

Wir sind aber noch nicht ganz fertig. Drei Dinge sollten Sie noch umsetzen:

  • Monitoring
    Ich bin sicher, dass Sie ihre Exchange Server überwachen. Wenn ihre Software nicht dynamisch neue Datenbank mit überwacht, sollten Sie die Überwachung anpassen.
  • Backup
    Die neue Datenbank müssen natürlich in ein Backup eingebunden werden. Das ist insbesondere wichtig, um während der Migration z.B. die Protokolldateien abzuschneiden und damit nicht "Out of Diskspace" zu laufen.
  • Bestehende Datenbanken aus dem Provisioning nehmen
    Auch während der Migration können neue Benutzer anfangen und durch das Provisioning neue Postfächer bekommen. Prüfen Sie ihre Lösung, wie diese das Zielsystem (Cloud oder On-Premises) und welche Datenbank für lokale Postfächer genutzt werden. Bei einer dynamischen Zuweisung mit "Enable-Mailbox" sollten Sie die alten Datenbanken vom Provisioning ausnehmen.
Set-MailboxDatabase <alteDBName> -IsExcludedFromProvisioning:$true

Wer damals schon bei der Installation der Server die Schritte der Neueinrichtung einer Datenbank dokumentiert hat, findet dort vielleicht noch weitere Schritte.

Diese Seite geht nicht auf den Umzug auf neue Server ein, bei denen auch die Loadbalancer u.a. umgestellt werden müssen.

Migration der Postfächer

Nun beginnt die eigentliche Arbeit für der Server: Das Verschieben der Postfächer. Technisch ist es ein "New-MoveRequest" in der lokalen Umgebung und kann relativ schnell umgesetzt werden. Sie könnten einfach für jede Quelldatenbank ein neue Zieldatenbank festlegen und dann die Move-Requests einstellen. Zuerst habe ich das mit "Get-Mailbox" gemacht

# Wenn ihre Umgebung mehrere Domains hat, dürfen Sie diese Einstellung nicht vergessen
Set-ADServerSettings -ViewEntireForest $true

# Move-request einstellen
Get-Mailbox -Database db01 | New-MoveRequest -TargetDatabase MDB01
Get-Mailbox -Database db02 | New-MoveRequest -TargetDatabase MDB01
Get-Mailbox -Database db03 | New-MoveRequest -TargetDatabase MDB01
Get-Mailbox -Database db04 | New-MoveRequest -TargetDatabase MDB02
Get-Mailbox -Database db05 | New-MoveRequest -TargetDatabase MDB02
Get-Mailbox -Database db06 | New-MoveRequest -TargetDatabase MDB02
...

Dieser Ansatz ist nett aber kann dazu führen, dass die Datenbanken ungleich verteilt sind. Kaum jemand wird aber nun hingehen, und die Postfächer nach der Größe sortieren und gleichmäßig verteilen. Das ist durchaus möglich aber genauso gut können Sie den Zufall eine Rolle spielen lassen, z.B. mit:

# Verschieben der regulären Postfaecher mit ihrem Archiv
Get-Mailbox | New-MoveRequest -TargetDatabase "MDB$((Get-Random -Minimum 1 -Maximum 6).ToString('00'))"

# Verschieben der Systempostfächer
Get-Mailbox -Arbitration | New-MoveRequest -TargetDatabase MDB01
Get-Mailbox -AuditLog    | New-MoveRequest -TargetDatabase MDB01

# Migration der PublicFolder Datenbank. Hier gebe ich gerne die Datenbanken manuell vor
Get-Mailbox -PublicFolder | New-MoveRequest -TargetDatabase MDB01

Perfektionisten sammeln natürlich erst die Postfächer mitsamt der Größe und sortieren diese nach der Größe um dann RoundRobin diese auf die neuen Datenbanken zu verteilen. Auch das geht per PowerShell.

$MBList = Get-Mailbox -ResultSize Unlimited `
           | Get-MailboxStatistics `
           | Select-Object DisplayName,TotalItemSize `
           | Sort-Object TotalItemSize -Descending
$DBList = get-mailboxdatabase db*

foreach ($mbcount in (0..(($mblist.count)-1))) {
   Write-Host "Move $($mblist[$mbcount].Displayname) to Database DB$((($mbcount%($dblist.count))+1).tostring("000"))"
   New-Moverequest `
      -Identity $mblist[$mbcount] `
      -Targetdatabase "DB$((($mbcount%($dblist.count))+1).tostring("000"))" -Whatif
}

Das funktioniert natürlich nur, wenn noch keine Postfächer auf den neuen Datenbanken sind. Sie können ja das oben genannte Skript "Get-Mailboxinfo" nutzen, um die Verteilung in den Datenbanken zu ermitteln und dann manuell geeignete Ziele zu ermitteln.

Achtung: Get-Mailbox mit dem Parameter "-database" findet keine neu angelegten Benutzer, die sich noch nie angemeldet haben!

Hinweis: Wenn ein Postfach per "Moverequest" gelockt ist, können Sie keinen weiteren MoveRequest für das Postfach einrichten.

Mischen Sie nicht Migrationen in die Cloud mit lokalen Migrationen. Die lokale Migration verhindert scheinbar nicht, dass Exchange Online sich den Benutzer abzieht und zu einer Remote Mailbox konvertiert.

MoveRequest überwachen

Wenn Sie sicher sind, dass die Ziel-Festplatten genug Platz haben, dann können Sie alle Postfächer als Move-Requests einstellen und ein paar Stunden oder Tage später wieder kommen. In der Realität sollten Sie aber schon ihre Verschiebe-Aktionen überwachen. Der MRS schaut schon schon genau an, wie die Quell-und Zielserver performen und drosselt die Migration. Aber wenn eine Datenbank ein Volume vollschreibt, dann ist nichts gewonnen..

Mein Ziel ist es ja, aus der 6-Server-Dag die Server EX13,EX14,EX15 zu entfernen. Damit muss ich sicherstellen, dass die Datenbanken auf dem jeweiligen Server wirklich keine Inhalte mehr haben. Für einen Server kann ich das wie folgt machen:

# Anzeige aller aktiven und passiven Datenbanken auf einem Server mit der Anzahl der Postfächer
Get-Mailboxdatabase -Server EX14 | %{"$($_.name) $((Get-Recipient -Database $_).count)"} | sort

Ein weiter Weg ist die Auswertung aller Postfächer eines Servers oder Datenbank hinsichtlich der Migration:

Get-Mailboxdatabase -Server EX13 `
| %{Get-Recipient -Database $_} `
| Get-MoveRequestStatistics `
| ft Displayname,Statusdetail,PercentComplete

Wenn Sie den Fokus auf alle Migrationen legen, dann ist folgende Ausgabe interessant:

Get-MoveRequest -ResultSize unlimited | group status -NoElement

Count Name
----- ----
   99 Queued
  421 InProgress
   18 Completed

Manchmal sind auch mehr Details gewünscht. Die Abfrage kann ja erweitert werden:

Get-MoveRequest `
   -ResultSize unlimited `
| Get-MoveRequestStatistics `
| group statusdetail -NoElement `
| ft -AutoSize

Count Name
----- ----
   12 StalledDueToTarget_MdbCapacityExceeded
  268 StalledDueToTarget_DiskLatency
    7 CopyingMessages
   73 StalledDueToTarget_ContentIndexing
   21 StalledDueToSource_DiskLatency
    1 StalledDueToSource_Processor
    2 StalledDueToTarget_DataGuaranteeWait
   10 StalledDueToTarget_MdbReplication
    3 Completed

Auch wenn der MRS bei der Migration die Zielserver hinsichtlich Disk-IOs, Festplattenplatz, CPU-Last etc. überwacht und sie vielleicht auch ein Monitoring der Volumes haben, schaue ich gerne auch noch mal daraus.

# Kontrolle der LUN Free
Invoke-Command `
   -ComputerName EX10,EX11,EX12 `
   -ScriptBlock { Get-Volume | ft FileSystemLabel,SizeRemaining,Size,HealthStatus}

Ich habe mich hier erst einmal auf "Postfächer" fokussiert. Dies beinhaltet auch PublicFolder-Postfächer, Räume und Shared-Postfächer. Mailuser, MailContacts, Verteilergruppen haben kein Postfach.

Anscheinend "blockt" der lokale MoveRequest nicht eine parallele Migration mit einem Remote-MoveRequest in die Cloud. Es fällt vermutlich nur bei solchen Massenumstellungen auf, wenn eine lokale Migration plötzlich auf "Failed" geht und eine Analyse noch eine SourceDatabase im MoveRequest anzeigt aber das Postfach mittlerweile eine RemoteMailbox ist.

Nun drücke ich ihnen die Daumen, dass ihre Konsolidierung reibungslos erfolgreich gelingt.

Datenbank entfernen

Sobald eine alte Postfachdatenbank leer ist, kann ich sie entfernen. Auch hier muss ich mehrere Schritte durchlaufen, denn

  • Move-Request entfernen
    Solange noch ein Move-Request mit der Datenbank verbunden ist, kann sie nicht gelöscht werden. Auch ein "Completed"-Request zählt dazu:
# Versuch die Datenbank mit MoveRequest zu entfernen
Remove-MailboxDatabase DB03
This mailbox database is associated with one or more move requests. To get a list of all move requests associated with
this database, run Get-MoveRequest -SourceDatabase <Database ID> and Get-MoveRequest -TargetDatabase <Database ID>. To
remove a move request, run Remove-MoveRequest <Recipient ID>.

#Entfernen der erfolgreichen Requests
Get-MoveRequest -MoveStatus completed | Remove-MoveRequest -confirm:$false
  • Replikate entfernen
    Ehe Sie die eigentliche Datenbank entfernen können, müssen erst alle Replikate entfernt werden. Das geht erstaunlich schnell mit der WebUI (ECP) aber auch per PowerShell.

Hinweis: Durch das Entfernen der Replikate in der Konfiguration werden die Dateien und Protokolldateien auf dem jeweiligen Server NICHT entfernt!
Es kann sein, dass der Store, Replication oder Index-Dienst die Dateien noch blockt. Dann einfach etwas warten, bis die Dienste den Change bemerkt haben. Der Index-Dienst löscht seine Dateien auch alleine.

# Versuch die Datenbank mit Replikaten zu entfernen
[PS] C:\>Remove-MailboxDatabase DB03
Database "DB03" has multiple copies on other servers. To remove an active database you must first remove all copies
from other servers.

# Entfernen aller Replikate außer der ersten Instanz.
(Get-MailboxDatabase DB03).DatabaseCopies `
| sort ActivationPreference `
| select -Skip 1 `
| Remove-MailboxDatabaseCopy -Confirm:$false
  • Datenbank entfernen (Rücksprache mit Backup!)
    Sie müssen Sie Datenbank nicht erst dismounten um sie zu entfernen. Wenn Sie aber noch ein Postfach "vergessen" haben, dann wird es aber Zeit oder sie richten die Replikate noch einmal schnell ein. Da auf den anderen Server die Dateien noch da sind, muss der Server in der Regel auch kein Reseeding machen.

Es könnte sein, dass Sie die Datenbanken "nur offline" nehmen und die Dateien entfernen wollen aber noch nicht in der Konfiguration löschen.
Eventuell braucht ihre Datensicherung diese Information noch, um z.B. ältere Stände in eine RecoveryStorageGroup zu restaurieren.

Hinweis: Durch das Entfernen der Replikate in der Konfiguration werden die Dateien und Protokolldateien auf dem jeweiligen Server NICHT entfernt!

# Entfernen der Datenbank
Remove-MailboxDatabase db03 -Confirm:$false
  • Backup und Monitoring anpassen
    Wenn Sie nicht schon durch die Alarme und Fehlermeldungen auf die neuen Fakten hingewiesen wurden, sollten Sie dennoch ihre Überwachungssysteme entsprechend anpassen. Auch die Datensicherung wird diese Datenbanken nicht mehr finden.

Nun sind die Datenbank auch in der Konfiguration weg.

Server Cleanup

Allein durch das Löschen der Datenbanken und Replikate aus der Konfiguration wird der Festplattenplatz noch nicht freigegeben. Sie müssen diese manuell löschen. Das ist aber gar nicht so einfach, da die Dateien meist immer noch "geblockt" sind. Teils hat der Information-Store noch seine Finger dran aber meist ist der der Content-Index, der die Veränderung noch nicht mitbekommen hat.

Ein Neustart des Informationsspeichers ist aber sowieso angeraten, damit Exchange sich auf die veränderte Anzahl der Datenbanken auf dem Server einstellen und das Speichermanagement optimieren kann. Sie kennen das ja schon von der Einrichtung der Datenbanken.

Für die verbleibenden Server EX10, EX11 und EX12 müssen wir aber nach dem kompletten Löschen der Datenbanken den Store einmal durchstarten.

Wenn es sich in dem Beispiel um die eh wegfallenden Server EX13, EX14 und EX15 handelt, die am Ende eh formatiert werden, dann können wir direkt mit der Deinstallation fortfahren.

# Move der Datenbanken vom aktiven Servern (nacheinander je Server 10-13)
Move-ActiveMailboxDatabase `
   -Server EX10 `
   -MoveComment "StoreRestart fuer neue Datenbanken"

# Restart des Informationstore
Invoke-Command `
   -ComputerName EX10 `
   -ScriptBlock {Restart-Service msexchangeis}

# Check auf Status (kann etwas dauern, denn Failed geht erst weg, wenn ein Log repliziert wurde.
Get-MailboxDatabaseCopyStatus * `
   | group status

Danach sollten die alten Datenbanken "frei" sein und können gelöscht werden.

Nachdem die obsoleten Server keine Funktion mehr haben, dürfen Sie diese aber nicht einfach abschalten sondern sollten "geplant" deinstalliert werden. Dazu habe ich eigens eine eigene Seite auf Exchange Server Deinstallation und anderen bereitgestellt. Einfach Abschalten ist ja keine Lösung, denn die Server haben vielleicht noch SMTP-Connectoren, sind im Edge-Server eingetragen und werden vom Loadbalancer bedient.

Schlussanalyse

Kontrolle ist während der Migration aber auch nach der Migration wichtig. Aus den sechs Servern wurden vier und aus den vielen Datenbanken gerade mal zwölf übrig gelassen, die zudem viel kleiner sind..

Es wird sicher noch einige Tage dauern, bis die Datenbanken sich wieder Aufgebaut haben. Sie sind aber deutlich weniger und kleiner, was auch auf die Optimierung des "WhiteSpace" zurückzuführen ist. Sie werden natürlich die nächsten Wochen weiter wachsen und mit ein paar weiteren Move-Operationen kann man die Belastung auch etwas besser verteilen. Wobei ich hier erst einmal die DiskIO-Raten und Latenzzeit der Festplatten mit anschauen würde. Alleine eine große Datenbank bedeutet ja noch nicht viel Last, wenn die Clients nicht besonders aktiv sind.

Einschätzung

Wie so oft, unterschützt man den Aufwand. Das hier beschriebene Szenario habe ich aus einer realen Kundensituation abgeleitet und die On-Premises verbliebenen Postfächer haben von dem Umzug nichts mitbekommen. Was war auch zu erwarten. 99,9 Prozent der Postfächer wurden mit 0 Fehlern migriert. Allerdings hat der Umzug doch länger gedauert, da aufgrund der SourceDiskLatency und TargetDiskLatency die Migration vom MRS gedrosselt wurde und wenige XXL-Postfächer >100 GB natürlich sehr lange gedauert haben. Wenn man die dann mit "priority highest" zwingt, dann kommt vielleicht der ein oder andere Server mit dem Replay der Logs in der DAG nicht hinterher. Ein "Get-MailboxDatabaseCopyStatus" zeigt das frühzeitig an, wenn die Datenbanken noch nicht im Monitoring überwacht werden. Zudem wurden durch das alte Provisioning während der Migration munter weiter neue Postfächer On-Premises angelegt und dann in die Cloud verschoben. So waren als "leer" geglaubte Datenbanken doch wieder belegt oder laufende Migrationsjobs wurden durch einen RemoteMoveRequest aus der Cloud ihrer Grundlage beraubt. Nachdem die Datenbanken endlich leer und gelöscht waren, konnten die Server deinstalliert werden. Damit hat sich das von der "Dauer" her dann doch über einige Tage hingezogen, während man in der Wartezeit dann dokumentieren und protokollieren sollte.

Weitere Links