Postfach nach der fehlg. Migration doppelt vorhanden

[susedv 0]

Hallo,

 

ich hatte in MS Exchange 2019 ein Postfach von einer fehlerhaften Datenbank A in eine neue Datenbank B migriert und dabei ist leider das Ziellaufwerk vollgelaufen, wodurch das Postfach in Datenbank B nicht vollständig angekommen ist und in Quarantäne gesetzt wurde.

Weil ich nicht genau wusste, wie ich die Migration richtig abschließen kann, habe ich den fehlg. Migrationsauftrag gelöscht und einen neuen Migrationsauftrag für dieses Postfach ausgeführt, jedoch wieder mit einer neuen Zieldatenbank C,
weil es mit der Datenbank B nicht mehr funktionierte. Diese Migration ist dann erfolgreich gelaufen. Die fehlerhafte Quelldatenbank A ist inzwischen gelöscht.

 

Nun habe ich jedoch das gleiche Postfach einmal in der Datenbank B (unvollständig übertragen, Quarantäne) und einmal in Datenbank C (vollständig übertragen, OK).
Am liebsten würde ich nun das unvollständige Postfach in Datenbank B löschen.
Ist das probemlos möglich und was ist zu beachten, z.B. damit wichtige Eigenschaften dieses Posfachs wie die E-Mail-Adresse u.a. nicht aus der AD verschwinden,
denn es ist ja quasi ein Duplikat vom richtigen Postfach?

 

Danke.

 

Gruß
Arthur.

[mikro 68]

Moin, wenn es nicht das aktive ist, ist es auch mir keinem AD Objekt verbunden.... Das sollte es doch eh softdeleted und bald weg sein. 

Mikro

[Nobbyaushb 1.479]

vor einer Stunde schrieb susedv:

 

ich hatte in MS Exchange 2019 ein Postfach von einer fehlerhaften Datenbank A in eine neue Datenbank B migriert und dabei ist leider das Ziellaufwerk vollgelaufen,

Wie kann das - hat es dir das Volumen mit Logs vollgeschrieben?

Das umgeht man, wenn während der Migration die Umlaufprokokollierung aktivieren, dann werden die Logs nahezu sofort in die DB geschrieben

Falls nein schlechtes Design...

Und immer an die magischen 20% denken...

[susedv 0]

Zitat

Wie kann das - hat es dir das Volumen mit Logs vollgeschrieben?

Ja, die Umlaufprokokollierung war leider nicht aktiviert.

 

Zitat

Moin, wenn es nicht das aktive ist, ist es auch mir keinem AD Objekt verbunden.... Das sollte es doch eh softdeleted und bald weg sein.

Sprich, wenn die Quarantäne autom. endet bleibt das halbübertragene Postfach in dieser Datenbank trotzdem inaktiv und kann manuell gelöscht werden, wenn beim 2-en Migrationsversuch das ursprüngliche Postfach erfolgreich in eine andere Datenbank übertragen wurde?

 

Oder was ist genau mit dem halbübertragenen Postfach zu tun, ich nehme an Disable-Mailbox, nicht Remove-Mailbox, und als Parameter nicht nur das Mailbox-Id sondern auch die Datenbank angeben, weil die Mailbox-Id ja gleich ist? Muss evtl. vorher die Quarantäne beendet werden?

 

Danke.

[susedv 0]

Update: nachdem die Quarantäne abgelaufen ist, ist das halbübertragene Postfach einfach verschwunden. Nun ist alles gut.

[Nobbyaushb 1.479]

vor 10 Stunden schrieb susedv:

Update: nachdem die Quarantäne abgelaufen ist, ist das halbübertragene Postfach einfach verschwunden. Nun ist alles gut.

Danke für das Update - und beim nächsten mal dran denken!
Bringt mich übrigens zu der Frage, wo die Transport-Daten liegen

Machen die meisten "falsch" weil Exchange auf "C" installiert wurde, die Datenbanken zwar verschoben aber nicht die das Transport

Weiterhin viel Erfolg!

[NilsK 2.958]

Moin,

 

nur der Vollständigkeit halber:

Am 13.7.2023 um 18:48 schrieb Nobbyaushb:

die Umlaufprokokollierung aktivieren, dann werden die Logs nahezu sofort in die DB geschrieben

das Circular Logging ändert nicht die Schreibvorgänge in die Datenbank. Wie praktisch jede relationale Datenbank macht auch die ESE "Lazy Writing", was zu einem parallelen Logging zwingt. Dieser Vorgang ist immer derselbe. Das Circular Logging sorgt nur dafür, dass die Log-Dateien, deren Transaktionen schon in die Datenbank geschrieben worden sind, gelöscht werden. Damit stehen sie nicht mehr für Recovery-Zwecke zur Verfügung, belegen aber auch keinen Platz mehr.

 

Gruß, Nils

 

[Nobbyaushb 1.479]

vor 1 Stunde schrieb NilsK:

Moin,

 

nur der Vollständigkeit halber:

das Circular Logging ändert nicht die Schreibvorgänge in die Datenbank. Wie praktisch jede relationale Datenbank macht auch die ESE "Lazy Writing", was zu einem parallelen Logging zwingt. Dieser Vorgang ist immer derselbe. Das Circular Logging sorgt nur dafür, dass die Log-Dateien, deren Transaktionen schon in die Datenbank geschrieben worden sind, gelöscht werden. Damit stehen sie nicht mehr für Recovery-Zwecke zur Verfügung, belegen aber auch keinen Platz mehr.

 

Gruß, Nils

 

Danke für die ausführliche und völlig korrekte Beschreibung!