8
PublicFolder-Migration von Exchange 2016 zu Exchange 2019 dauert sehr lange
Guten Morgen Mitstreiter,
ich wünsche allen Forenteilnehmern ein gesundes und erfolgreiches neues Jahr.
Ich habe eine Frage zur Migration von Ex2016 zu Ex2019.
Wir befinden uns aktuell in einem Migrationsprojekt von Ex2010 über Ex2016 zu Ex2019.
Die Migration von Ex2010 zu Ex2016 verlief reibungslos.
Unser Kunde nutzt sehr stark die öffentlichen Ordner, welche eine Größe von ~1TB haben – Laut PublicFolder-MoveRequest.
Um den Kunden arbeitsfähig zu halten, haben wir uns entschieden, alle PF in eine Mailbox zu integrieren. Diese Mailbox wird seit 30.12.2019 ~11.30 Uhr nun auf den Ex2019 migriert. In meinen Augen dauert dieser Vorgang ziemlich lange – die Migration von Ex2010 zu Ex2016 hat im Vergleich etwa 37h benötigt.
Auffällig ist, dass der MoveRequest regelmäßig „zurückgesetzt“ wird und beispielsweise von 89% auf 25% zurück fällt. Das BadIdem-Limit habe ich mit „50“ angegeben.
Die Festplatte für die PublicFolder-Database ist bereits 2,7TB groß und uns geht langsam die Festplattenkapazität zur Neige.
Macht es an dieser Stelle Sinn, den MoveRequest abzubrechen und erneut zu starten oder sollen wir einfach abwarten?
Für Rückfragen stehe ich gerne zur Verfügung.
Grüße und frohes Schaffen
Manuel
ich wünsche allen Forenteilnehmern ein gesundes und erfolgreiches neues Jahr.
Ich habe eine Frage zur Migration von Ex2016 zu Ex2019.
Wir befinden uns aktuell in einem Migrationsprojekt von Ex2010 über Ex2016 zu Ex2019.
Die Migration von Ex2010 zu Ex2016 verlief reibungslos.
Unser Kunde nutzt sehr stark die öffentlichen Ordner, welche eine Größe von ~1TB haben – Laut PublicFolder-MoveRequest.
Um den Kunden arbeitsfähig zu halten, haben wir uns entschieden, alle PF in eine Mailbox zu integrieren. Diese Mailbox wird seit 30.12.2019 ~11.30 Uhr nun auf den Ex2019 migriert. In meinen Augen dauert dieser Vorgang ziemlich lange – die Migration von Ex2010 zu Ex2016 hat im Vergleich etwa 37h benötigt.
Auffällig ist, dass der MoveRequest regelmäßig „zurückgesetzt“ wird und beispielsweise von 89% auf 25% zurück fällt. Das BadIdem-Limit habe ich mit „50“ angegeben.
Die Festplatte für die PublicFolder-Database ist bereits 2,7TB groß und uns geht langsam die Festplattenkapazität zur Neige.
Macht es an dieser Stelle Sinn, den MoveRequest abzubrechen und erneut zu starten oder sollen wir einfach abwarten?
Für Rückfragen stehe ich gerne zur Verfügung.
Grüße und frohes Schaffen
Manuel
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 532159
Url: https://administrator.de/contentid/532159
Printed on: April 23, 2024 at 10:04 o'clock
8 Comments
Latest comment
Hallo Manuel,
Exchange 2019 braucht wesentlich mehr Ressourcen ab einem gewissen Umfang. 1tb würde ich dazu zählen. Befürchte die Hw ist zu schwach.
Vg
Exchange 2019 braucht wesentlich mehr Ressourcen ab einem gewissen Umfang. 1tb würde ich dazu zählen. Befürchte die Hw ist zu schwach.
Vg
Fehler nach langer Suche gefunden:
Der MoveRequest stoppt mangels Ressourcen und startet irgendwann wieder. Er stellt dann fest, dass sich die Quelldaten geändert haben und beginnt von vorn.
Siehe Protokollauszug:
06.01.2020 16:00:03 [Ex2019] Die Verschiebungsanforderung wurde erneut gestartet, da die Signatur des Quellpostfachs geändert wurde.
06.01.2020 16:00:03 [Ex2019] Der Synchronisierungsstatus für die Anforderung "ab45a696-46d1-4cac-be77-d4e3fb91d815" wurde wegen "MailboxSignatureChange" gelöscht.
06.01.2020 16:00:03 [Ex2019] Vorübergehender Fehler 'MailboxSignatureChangedTransientException'. Erneuter Versuch (4/20240).
06.01.2020 16:00:33 [Ex2019] Der Microsoft Exchange-Postfachreplikationsdienst 'Ex2019.domain.endung' (15.2.529.5 caps:3FFFFF) überprüft die Anforderung.
06.01.2020 16:00:33 [Ex2019] Verbunden mit Zielpostfach 'ab45a696-46d1-4cac-be77-d4e3fb91d815 (Primär)', Datenbank 'DB--PF', Postfachserver 'Ex2019.domain.endung' Version 15.2 (Build 529.0).
06.01.2020 16:00:33 [Ex2019] Verbunden mit Quellpostfach 'ab45a696-46d1-4cac-be77-d4e3fb91d815 (Primär)', Datenbank 'DB-Ex2016', Postfaschserver 'Ex2016.domain.endung' Version 15.1 (Build 1847.0), Proxyserver 'Ex2016.domain.endung' 15.1.1847.5 caps:0FFD6FFFBF5FFFFFCB07FFFF.
06.01.2020 16:00:33 [Ex2019] Die Anforderungsverarbeitung wurde gestartet.
06.01.2020 16:00:33 [Ex2019] Quellpostfachinformationen: Reguläre Elemente: 1276399, 986.2 GB (1,058,882,804,805 bytes) Regulär gelöschte Elemente: 84, 22.52 MB (23,612,557 bytes) FAI-Elemente: 237, 911.2 KB (933,034 bytes) Gelöschte FAI-Elemente: 0, 0 B (0 bytes)
06.01.2020 16:00:34 [Ex2019] Der Synchronisierungsstatus für die Anforderung "ab45a696-46d1-4cac-be77-d4e3fb91d815" wurde wegen "CleanupOrphanedMailbox" gelöscht.
06.01.2020 16:00:34 [Ex2019] Eine alte Kopie des Postfachs wurde aus der Zieldatenbank entfernt. Der Vorgang wird in 30 Sekunden wiederholt.
06.01.2020 16:01:04 [Ex2019] Phase: CreatingFolderHierarchy. Prozent abgeschlossen: 10.
06.01.2020 16:01:06 [Ex2019] Die Ordnerhierarchie aus Postfach 'ab45a696-46d1-4cac-be77-d4e3fb91d815 (Primär)' wird initialisiert: 8927 Ordner gesamt.
Ich habe den MoveRequest nun abgebrochen und gebe der Maschine heute Abend (deutlich) mehr RAM. Die Datenbank für die PublicFolder-Mailbox werde ich nach einem Backup bereinigen, entfernen und neu anlegen und dann schauen, was passiert.
Der MoveRequest stoppt mangels Ressourcen und startet irgendwann wieder. Er stellt dann fest, dass sich die Quelldaten geändert haben und beginnt von vorn.
Siehe Protokollauszug:
06.01.2020 16:00:03 [Ex2019] Die Verschiebungsanforderung wurde erneut gestartet, da die Signatur des Quellpostfachs geändert wurde.
06.01.2020 16:00:03 [Ex2019] Der Synchronisierungsstatus für die Anforderung "ab45a696-46d1-4cac-be77-d4e3fb91d815" wurde wegen "MailboxSignatureChange" gelöscht.
06.01.2020 16:00:03 [Ex2019] Vorübergehender Fehler 'MailboxSignatureChangedTransientException'. Erneuter Versuch (4/20240).
06.01.2020 16:00:33 [Ex2019] Der Microsoft Exchange-Postfachreplikationsdienst 'Ex2019.domain.endung' (15.2.529.5 caps:3FFFFF) überprüft die Anforderung.
06.01.2020 16:00:33 [Ex2019] Verbunden mit Zielpostfach 'ab45a696-46d1-4cac-be77-d4e3fb91d815 (Primär)', Datenbank 'DB--PF', Postfachserver 'Ex2019.domain.endung' Version 15.2 (Build 529.0).
06.01.2020 16:00:33 [Ex2019] Verbunden mit Quellpostfach 'ab45a696-46d1-4cac-be77-d4e3fb91d815 (Primär)', Datenbank 'DB-Ex2016', Postfaschserver 'Ex2016.domain.endung' Version 15.1 (Build 1847.0), Proxyserver 'Ex2016.domain.endung' 15.1.1847.5 caps:0FFD6FFFBF5FFFFFCB07FFFF.
06.01.2020 16:00:33 [Ex2019] Die Anforderungsverarbeitung wurde gestartet.
06.01.2020 16:00:33 [Ex2019] Quellpostfachinformationen: Reguläre Elemente: 1276399, 986.2 GB (1,058,882,804,805 bytes) Regulär gelöschte Elemente: 84, 22.52 MB (23,612,557 bytes) FAI-Elemente: 237, 911.2 KB (933,034 bytes) Gelöschte FAI-Elemente: 0, 0 B (0 bytes)
06.01.2020 16:00:34 [Ex2019] Der Synchronisierungsstatus für die Anforderung "ab45a696-46d1-4cac-be77-d4e3fb91d815" wurde wegen "CleanupOrphanedMailbox" gelöscht.
06.01.2020 16:00:34 [Ex2019] Eine alte Kopie des Postfachs wurde aus der Zieldatenbank entfernt. Der Vorgang wird in 30 Sekunden wiederholt.
06.01.2020 16:01:04 [Ex2019] Phase: CreatingFolderHierarchy. Prozent abgeschlossen: 10.
06.01.2020 16:01:06 [Ex2019] Die Ordnerhierarchie aus Postfach 'ab45a696-46d1-4cac-be77-d4e3fb91d815 (Primär)' wird initialisiert: 8927 Ordner gesamt.
Ich habe den MoveRequest nun abgebrochen und gebe der Maschine heute Abend (deutlich) mehr RAM. Die Datenbank für die PublicFolder-Mailbox werde ich nach einem Backup bereinigen, entfernen und neu anlegen und dann schauen, was passiert.
Hey Manuel,
Ohne jetzt zu wissen, ob dieses Wissen auch auf Public Folder anzuwenden ist, schau doch mal ob du Logs dafür findest.
Bei einem Move einer normalen Mailbox wäre das:
Get-MoveRequestStatistics <mailboxidentity> -includereport | FL MoveReport
https://docs.microsoft.com/en-us/powershell/module/exchange/move-and-mig ...
Ja, das liegt daran, dass die Daten nicht wirklich bewegt werden wie im herkömmlichen Sinne wie in einem Dateisystem, sondern zuerst alle Daten kopiert werden und dann am alten Platz die Zuordnungsinformationen gelöscht werden. Das heißt, wenn deine Daten (ohne Overhead) 1TB groß sind und du bei 99% abbrichst und wieder bei 0 beginnst wird die neue Datenbank 2TB groß sein (+Overhead).
Das Problem kann an vielen Dingen liegen, wenn ich Mailboxen bewegt oder importiert hatte war das Problem in 95% aller Fälle ein Kalendereintrag, der sich einfach nicht bewegen lassen konnte (aus diversen Gründen).
Wenn ich in der Situation wäre würde ich folgendes tun:
1.) Herausfinden ob und wie ich Statistiken/Logs für einen PublicFolderMoveRequest sehen / bekommen kann (mit einer kleinen TestDB, die man hin und her bewegen kann)
2.) Die zu bewegende DB extern (Tape, externe HDD, SMB Share,...) sichern und/oder ein PST generieren
3.) Den eigentlichen Move mit
durchführen.
Ich würde für den nächsten versuchten Move eine neue Datenbank anlegen, die Aktuelle ist durch fehlgeschlagenen Versuche anscheinend bereits deutlich aufgeblasener als notewendig.
lG
Areanod
EDIT: Du hattest bereits geantwortet bevor ich meine Antwort gepostet habe... Ich lasse diese trotzdem stehen, falls es doch jemandem nützlich sein könnte.
Ohne jetzt zu wissen, ob dieses Wissen auch auf Public Folder anzuwenden ist, schau doch mal ob du Logs dafür findest.
Bei einem Move einer normalen Mailbox wäre das:
Get-MoveRequestStatistics <mailboxidentity> -includereport | FL MoveReport
https://docs.microsoft.com/en-us/powershell/module/exchange/move-and-mig ...
Die Festplatte für die PublicFolder-Database ist bereits 2,7TB groß und uns geht langsam die Festplattenkapazität zur Neige.
Ja, das liegt daran, dass die Daten nicht wirklich bewegt werden wie im herkömmlichen Sinne wie in einem Dateisystem, sondern zuerst alle Daten kopiert werden und dann am alten Platz die Zuordnungsinformationen gelöscht werden. Das heißt, wenn deine Daten (ohne Overhead) 1TB groß sind und du bei 99% abbrichst und wieder bei 0 beginnst wird die neue Datenbank 2TB groß sein (+Overhead).
Das Problem kann an vielen Dingen liegen, wenn ich Mailboxen bewegt oder importiert hatte war das Problem in 95% aller Fälle ein Kalendereintrag, der sich einfach nicht bewegen lassen konnte (aus diversen Gründen).
Wenn ich in der Situation wäre würde ich folgendes tun:
1.) Herausfinden ob und wie ich Statistiken/Logs für einen PublicFolderMoveRequest sehen / bekommen kann (mit einer kleinen TestDB, die man hin und her bewegen kann)
2.) Die zu bewegende DB extern (Tape, externe HDD, SMB Share,...) sichern und/oder ein PST generieren
3.) Den eigentlichen Move mit
- BadItemlimit unlimited
- AcceptLargeDataLoss $true
- AllowLargeItems unlimited
durchführen.
Ich würde für den nächsten versuchten Move eine neue Datenbank anlegen, die Aktuelle ist durch fehlgeschlagenen Versuche anscheinend bereits deutlich aufgeblasener als notewendig.
lG
Areanod
EDIT: Du hattest bereits geantwortet bevor ich meine Antwort gepostet habe... Ich lasse diese trotzdem stehen, falls es doch jemandem nützlich sein könnte.
Und dann überleg Mal ob 1tb nicht besser in einem anderen Speicher zu hinterlegen sind.
Vielen Dank für eure Einschätzungen.
Ich habe den MoveRequest nun in den Status "Suspended" gesetzt und entfernt:
Suspend-MoveRequest -Identity PublicFolderMailbox01
Get-MoveRequest | where {$_.status -match "Suspended"} | Remove-MoveRequest
Aktuell sind keine MoveRequests vorhanden.
Ich lasse heute Abend erst einmal ein Vollbackup der beiden Server laufen und setze dann morgen früh die PF-Database neu auf.
Außerdem überlege ich, den neuen MoveRequest am Freitagabend zu starten, in der Hoffnung, dass weniger Benutzer in die Aktion "hereingrätschen" können.
@certifiedit.net: Diese Überlegung habe ich bereits Ende letzten Jahres an den Endkunden weitergeleitet. Hier greift der Klassiker: "Das haben wir schon immer so gemacht"...
Ich habe den MoveRequest nun in den Status "Suspended" gesetzt und entfernt:
Suspend-MoveRequest -Identity PublicFolderMailbox01
Get-MoveRequest | where {$_.status -match "Suspended"} | Remove-MoveRequest
Aktuell sind keine MoveRequests vorhanden.
Ich lasse heute Abend erst einmal ein Vollbackup der beiden Server laufen und setze dann morgen früh die PF-Database neu auf.
Außerdem überlege ich, den neuen MoveRequest am Freitagabend zu starten, in der Hoffnung, dass weniger Benutzer in die Aktion "hereingrätschen" können.
@certifiedit.net: Diese Überlegung habe ich bereits Ende letzten Jahres an den Endkunden weitergeleitet. Hier greift der Klassiker: "Das haben wir schon immer so gemacht"...
Dann musst du als Fachmann hier eben anderweitige Wege vorschlagen. Taugt ja nichts, Befehlsnotstand gibt es heute auch nicht mehr ;)
1
Ist ja nicht so, als hat der Kunde kein Dokumentenmanagementsystem, benutzt es nur nicht...
Macht es nicht besser, nein
