Exchange Server 2010: Umzug auf neue Hardware
Hallo zusammen,
aufgrund von Performanceproblemen haben wir uns entschlossen, unseren Exchange-Server auf eine neue leistungsfähigere Maschine zu portieren. Wir sind ein kleineres Unternehmen mit ca. 30 Mitarbeitern und der entsprechenden Zahl an Clients. Ziel ist es, alle Daten auf den neuen Server zu verschieben, um den alten Server später komplett abzuschalten. Der alte Server läuft als virtuelle Maschine auf einem Server 2008 R2, die neue Maschine läuft native als Server 2012 R2. Die Exchange-Server Version haben wir nicht geändert: In beiden Fällen Exchange Server 2010.
Nachdem wir den neuen Server auf einem "sauberen" System neu aufgesetzt und in die Domäne / ins AD eingebunden haben, habe ich zunächst eine neue Postfachdatenbank erstellt und alle Postfächer per Verschiebungsanforderung auf den neuen Server verschoben. Keine Probleme, soweit so gut.
Probleme bereiten mir nun die Öffentlichen Ordner, die bei uns recht intensiv genutzt werden. Wir nutzen diese v.a. als projektbezogene Ablage für Emails, aber auch Kalender, Belegungspläne, Adressen etc. Im Ganzen haben wir mittlerweile einige hundert Subfolder angesammelt, ist also recht umfangreich (Gesamtumfang knapp 30GB).
Zunächst habe ich dazu auch hier auf dem neuen Server eine neue Public Folder Database angelegt. Leider ist das "Verschieben" nun aber nicht so leicht, eine Verschiebungsanforderung wie bei den Postfächern gibt es nicht. Nach meiner Recherche muss statt dessen die Replikation angestoßen werden, das habe ich über das Skript MoveAllReplicas (.\MoveAllReplicas.ps1 -Server <alter Server> -NewServer <neuer Server>) gemacht - und hier vermutlich den entscheidenden Fehler gemacht und dabei festgestellt, wie wertvoll ein funktionierendes Backup ist! Statt die Ordner zu verschieben wurden nämlich die Inhalte gelöscht!!! Deshalb habe ich das Skript auch abgebrochen - und damit vielleicht den 2. Fehler gemacht?!
Nun ergibt sich folgende Situation: Die ÖO habe ich auf dem alten Server wieder hergestellt, die Einbindung der PF-DB auf dem neuen Server wieder aufgehoben. Nun sind alle ÖO wieder sichtbar, es läuft wie zuvor über den alten Server. Nun wollte ich den neuen Server zunächst als Replikat-Server einsetzen und habe dazu das Skript AddReplicaToPFRecursive eingesetzt. Auch das gelingt mir nicht: Weil offensichtlich beim 1. Versuch Teile unserer Struktur bereits in die neue DB übertragen wurden, hagelt es nun Konfliktnachrichten, weil die Versionsstände zwischen den DBs nicht übereinstimmmen. Leider bekomme ich die neue PF-DB auch nicht mehr gelöscht - dazu müsste ich sie wieder einbinden. Da beißt sich die Katze in den ###! Wie komme ich raus aus dieser Zwickmühle? Gibt es eine einfache Lösung wieder bei Null anzufangen (die DB zu löschen)? Wie gehe ich am besten vor?
Bin für hilfreiche Tipps sehr dankbar.
Viele Grüße von der Erdbeermaus
aufgrund von Performanceproblemen haben wir uns entschlossen, unseren Exchange-Server auf eine neue leistungsfähigere Maschine zu portieren. Wir sind ein kleineres Unternehmen mit ca. 30 Mitarbeitern und der entsprechenden Zahl an Clients. Ziel ist es, alle Daten auf den neuen Server zu verschieben, um den alten Server später komplett abzuschalten. Der alte Server läuft als virtuelle Maschine auf einem Server 2008 R2, die neue Maschine läuft native als Server 2012 R2. Die Exchange-Server Version haben wir nicht geändert: In beiden Fällen Exchange Server 2010.
Nachdem wir den neuen Server auf einem "sauberen" System neu aufgesetzt und in die Domäne / ins AD eingebunden haben, habe ich zunächst eine neue Postfachdatenbank erstellt und alle Postfächer per Verschiebungsanforderung auf den neuen Server verschoben. Keine Probleme, soweit so gut.
Probleme bereiten mir nun die Öffentlichen Ordner, die bei uns recht intensiv genutzt werden. Wir nutzen diese v.a. als projektbezogene Ablage für Emails, aber auch Kalender, Belegungspläne, Adressen etc. Im Ganzen haben wir mittlerweile einige hundert Subfolder angesammelt, ist also recht umfangreich (Gesamtumfang knapp 30GB).
Zunächst habe ich dazu auch hier auf dem neuen Server eine neue Public Folder Database angelegt. Leider ist das "Verschieben" nun aber nicht so leicht, eine Verschiebungsanforderung wie bei den Postfächern gibt es nicht. Nach meiner Recherche muss statt dessen die Replikation angestoßen werden, das habe ich über das Skript MoveAllReplicas (.\MoveAllReplicas.ps1 -Server <alter Server> -NewServer <neuer Server>) gemacht - und hier vermutlich den entscheidenden Fehler gemacht und dabei festgestellt, wie wertvoll ein funktionierendes Backup ist! Statt die Ordner zu verschieben wurden nämlich die Inhalte gelöscht!!! Deshalb habe ich das Skript auch abgebrochen - und damit vielleicht den 2. Fehler gemacht?!
Nun ergibt sich folgende Situation: Die ÖO habe ich auf dem alten Server wieder hergestellt, die Einbindung der PF-DB auf dem neuen Server wieder aufgehoben. Nun sind alle ÖO wieder sichtbar, es läuft wie zuvor über den alten Server. Nun wollte ich den neuen Server zunächst als Replikat-Server einsetzen und habe dazu das Skript AddReplicaToPFRecursive eingesetzt. Auch das gelingt mir nicht: Weil offensichtlich beim 1. Versuch Teile unserer Struktur bereits in die neue DB übertragen wurden, hagelt es nun Konfliktnachrichten, weil die Versionsstände zwischen den DBs nicht übereinstimmmen. Leider bekomme ich die neue PF-DB auch nicht mehr gelöscht - dazu müsste ich sie wieder einbinden. Da beißt sich die Katze in den ###! Wie komme ich raus aus dieser Zwickmühle? Gibt es eine einfache Lösung wieder bei Null anzufangen (die DB zu löschen)? Wie gehe ich am besten vor?
Bin für hilfreiche Tipps sehr dankbar.
Viele Grüße von der Erdbeermaus
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 265888
Url: https://administrator.de/forum/exchange-server-2010-umzug-auf-neue-hardware-265888.html
Ausgedruckt am: 06.05.2025 um 18:05 Uhr
6 Kommentare
Neuester Kommentar
Hi,
warum Scripte, wenn es doch mit ein paar Mausklicks geht?
Der Weg war schon richtig. Auf dem neuen Server eine weiter Datenbank für Öfos erstellen. Dann mit der EMC Console für die Öfos öffnen (Toolbox).
Für alle Standard- und Systemordner (nur die Basisordner) im Detailfenster(!) das Kontextmenü rufen
--> Eigenschaften --> Replikation --> Hinzufügen
Dann nochmal das Kontextmenü
Einstellungen verwalten ... --> Einstellungen überschreiben --> Replikate
Abwarten, bis Replikation abgeschlossen. Jetzt den Weg oben, bloß umgekehrt: Erst den alten Server entfernen. Dann nach unten durchreichen.
E.
warum Scripte, wenn es doch mit ein paar Mausklicks geht?
Der Weg war schon richtig. Auf dem neuen Server eine weiter Datenbank für Öfos erstellen. Dann mit der EMC Console für die Öfos öffnen (Toolbox).
Für alle Standard- und Systemordner (nur die Basisordner) im Detailfenster(!) das Kontextmenü rufen
--> Eigenschaften --> Replikation --> Hinzufügen
Dann nochmal das Kontextmenü
Einstellungen verwalten ... --> Einstellungen überschreiben --> Replikate
Abwarten, bis Replikation abgeschlossen. Jetzt den Weg oben, bloß umgekehrt: Erst den alten Server entfernen. Dann nach unten durchreichen.
E.
Hallo emeriks,
erstmal vielen Dank für Deine Hilfe.
Skripte deshalb, weil ich im Glauben war, dass das per GUI nicht rekursiv geht (und dann wäre es ziemlich viel Arbeit geworden). Zudem verwiesen alle (fast) Anleitungen, die ich zu dem Thema im Netz gefunden habe, auf diese Skripte.
Zu Deiner Lösung: Das Problem dabei ist die aktuelle PF-DB des neuen Servers, weil sich darin bereits Teile der Ordnerstruktur befinden. Sobald ich diese einbinde - und das muss ich doch sicherlich um die Replikation in Gang zu bringen - werden wieder Teile der Inhalte der ÖO überschrieben bzw. gelöscht. Deshalb würde ich am liebsten die DB löschen und neu erstellen - aber auch das geht nicht, weil eben noch Inhalte drin sind. Irgendwie drehe ich mich im Kreis.
Noch etwas: Du schreibst, warten bis die Replikation abgeschlossen ist. Wie erkenne ich das?
erstmal vielen Dank für Deine Hilfe.
Skripte deshalb, weil ich im Glauben war, dass das per GUI nicht rekursiv geht (und dann wäre es ziemlich viel Arbeit geworden). Zudem verwiesen alle (fast) Anleitungen, die ich zu dem Thema im Netz gefunden habe, auf diese Skripte.
Zu Deiner Lösung: Das Problem dabei ist die aktuelle PF-DB des neuen Servers, weil sich darin bereits Teile der Ordnerstruktur befinden. Sobald ich diese einbinde - und das muss ich doch sicherlich um die Replikation in Gang zu bringen - werden wieder Teile der Inhalte der ÖO überschrieben bzw. gelöscht. Deshalb würde ich am liebsten die DB löschen und neu erstellen - aber auch das geht nicht, weil eben noch Inhalte drin sind. Irgendwie drehe ich mich im Kreis.
Noch etwas: Du schreibst, warten bis die Replikation abgeschlossen ist. Wie erkenne ich das?
Backup hast Du und Wiederherstellung hat offenbar auch funktioniert.
Also 2. DB online nehmen. Warten was passiert. Am besten abend/nachts, wenn keiner arbeitet. Wenn er wieder alles leert, dann die Replikate des 2. Server wieder entfernen. Erst dann die DB auf dem 1. Server nochmal wiederherstellen. Jetzt wieder replikate auf dem 2. Server erstellen. Wenn alles OK, dann die Replikate des 1. Servers löschen.
E.
Also 2. DB online nehmen. Warten was passiert. Am besten abend/nachts, wenn keiner arbeitet. Wenn er wieder alles leert, dann die Replikate des 2. Server wieder entfernen. Erst dann die DB auf dem 1. Server nochmal wiederherstellen. Jetzt wieder replikate auf dem 2. Server erstellen. Wenn alles OK, dann die Replikate des 1. Servers löschen.
E.
Zitat von @emeriks:
Backup hast Du und Wiederherstellung hat offenbar auch funktioniert.
Also 2. DB online nehmen. Warten was passiert.
Backup hast Du und Wiederherstellung hat offenbar auch funktioniert.
Also 2. DB online nehmen. Warten was passiert.
Das kann ich Dir sagen: Die Inhalte werden "kaputt" geschrieben und die Verwalter der ÖO werden mit Hunderten von Konfliktnachrichten überschüttet. DAS würde ich gerne vermeiden. Gibt es keinen einfacheren Weg um die DB wieder zurückzusetzen?
Am besten abend/nachts, wenn keiner arbeitet. Wenn er wieder alles leert, dann die
Replikate des 2. Server wieder entfernen. Erst dann die DB auf dem 1. Server nochmal wiederherstellen. Jetzt wieder replikate auf
dem 2. Server erstellen. Wenn alles OK, dann die Replikate des 1. Servers löschen.
Replikate des 2. Server wieder entfernen. Erst dann die DB auf dem 1. Server nochmal wiederherstellen. Jetzt wieder replikate auf
dem 2. Server erstellen. Wenn alles OK, dann die Replikate des 1. Servers löschen.
Seltsam ist auch, ich habe in den Einstellungen der einzelnen Ordner mittlerweile den Replikationsserver (also den neuen Server) herausgenommen, um dann die DB wieder ohne Nebeneffekte einbinden zu können. Das hab ich jedenfalls gedacht. Doch das Einbinden verlief wieder nach dem o.g. Szenario.
Was würde eigentlich passieren, wenn ich dem Exchange die DB sozusagen "unter dem Hintern wegziehe" - sprich: sie auf Dateiebene lösche/verschiebe? Mit Sicherheit keine saubere Lösung, aber hat man dann nicht vielleicht eine Chance, diese neu (= leer) zu erstellen?
Ohne Gewähr:
Man kann die DB hart entfernen. Dazu im ADSIedit unter
CN=Databases,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=xxxxxxxx,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=xxxxx,DC=xxxx
das entsprechende Objekt löschen. Dann "kennt" Exchange diese DB nicht mehr. Theoretisch. Habe ich zuletzt unter Exchange 2003 so gemacht. Keine Ahnung, wie sich Exchange 2010 da verhält.
Aber wenn Du diesen Weg gehst, dann entferne vorher in den Ordner-Eigenschaften die Replikate dieses Servers. Backup des AD erstellen. Und die DB-Datei nicht gleich löschen, sondern erstmal nur umbenennen.
Man kann die DB hart entfernen. Dazu im ADSIedit unter
CN=Databases,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=xxxxxxxx,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=xxxxx,DC=xxxx
das entsprechende Objekt löschen. Dann "kennt" Exchange diese DB nicht mehr. Theoretisch. Habe ich zuletzt unter Exchange 2003 so gemacht. Keine Ahnung, wie sich Exchange 2010 da verhält.
Aber wenn Du diesen Weg gehst, dann entferne vorher in den Ordner-Eigenschaften die Replikate dieses Servers. Backup des AD erstellen. Und die DB-Datei nicht gleich löschen, sondern erstmal nur umbenennen.
Hmm, klingt gefährlich... Aber scheinbar gibt es keine einfache Lösung für das Problem. Muss mal sehen, für welche Lösung ich mich entscheiden werde.
Eine Frage bleibt aber: Wie kann es überhaupt sein, wenn ich die Replikate auf dem neuen Server bei ALLEN Ordnern entferne und die DB dann wieder einbinde, dann sollten die Inhalte doch eigentlich unangetastet bleiben? Oder habe ich da einen Denkfehler?
Eine Frage bleibt aber: Wie kann es überhaupt sein, wenn ich die Replikate auf dem neuen Server bei ALLEN Ordnern entferne und die DB dann wieder einbinde, dann sollten die Inhalte doch eigentlich unangetastet bleiben? Oder habe ich da einen Denkfehler?
