3
Karteileichen im Exchange
Hallo,
bei einem Restore eines PublicFolder-Elements per Veeam ist aufgefallen, dass dort PFMailboxen angezeigt werden, die laut Exchange gar nicht dort sein dürften.
Hintergrundinfos: Wir haben vor ca 2 Jahren eine 2 Knoten Exchange 2010 DAG auf eine 3 Knoten Exchange 2016 DAG migrieren lassen. Die Migration verliefen ein wenig holprig, das System läuft aber seither stabil und ohne Probleme. Teil der Migration war auch die Übernahme eines 3 TB PublicFolders.
Da sich ja das interne Handling der PFs ein wenig geändert hat, wurde dies in insgesamt 6 PF-DBs und ca 60 PFMailboxes aufgeteilt.
Dies ist auch der aktuelle Stand laut PowerShell und GUI.
Im Veeam-Browser ist nun aufgefallen, dass laut Nummerierung mindestens 140 PFMailboxen vorhanden sind und sogar einige mit identischem Namen in der gleichen DB.
Der Inhalt aller Exchange-Unbekannten PFMailboxen scheint alt zu sein.
Hat sowas schon mal jemand gesehen? Google findet auch leider nichts passendes.
Bevor ich nun an den damaligen Dienstleister trete, würde ich gerne die Lage etwas besser einschätzen können…
Gruß
bei einem Restore eines PublicFolder-Elements per Veeam ist aufgefallen, dass dort PFMailboxen angezeigt werden, die laut Exchange gar nicht dort sein dürften.
Hintergrundinfos: Wir haben vor ca 2 Jahren eine 2 Knoten Exchange 2010 DAG auf eine 3 Knoten Exchange 2016 DAG migrieren lassen. Die Migration verliefen ein wenig holprig, das System läuft aber seither stabil und ohne Probleme. Teil der Migration war auch die Übernahme eines 3 TB PublicFolders.
Da sich ja das interne Handling der PFs ein wenig geändert hat, wurde dies in insgesamt 6 PF-DBs und ca 60 PFMailboxes aufgeteilt.
Dies ist auch der aktuelle Stand laut PowerShell und GUI.
Im Veeam-Browser ist nun aufgefallen, dass laut Nummerierung mindestens 140 PFMailboxen vorhanden sind und sogar einige mit identischem Namen in der gleichen DB.
Der Inhalt aller Exchange-Unbekannten PFMailboxen scheint alt zu sein.
Hat sowas schon mal jemand gesehen? Google findet auch leider nichts passendes.
Bevor ich nun an den damaligen Dienstleister trete, würde ich gerne die Lage etwas besser einschätzen können…
Gruß
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 643443
Url: https://administrator.de/contentid/643443
Ausgedruckt am: 18.11.2024 um 21:11 Uhr
3 Kommentare
Neuester Kommentar
Hallo,
dieses Problem ist wohl zu speziell... Werde es mal an anderen Anlaufstellen probieren.
Sorry dann für's Crossposting.
Poste dann was raus kam
Gruß
dieses Problem ist wohl zu speziell... Werde es mal an anderen Anlaufstellen probieren.
Sorry dann für's Crossposting.
Poste dann was raus kam
Gruß
Aufgrund der jüngsten Änderungen im Office 365-Backend schlägt die Postfachsicherung für Öffentliche Ordner mit dem Fehler "Der Vorgang ist fehlgeschlagen. Auf das Postfach muss als Eigentümer zugegriffen werden" fehl. Dieses Problem betrifft Benutzer von Veeam Backup für Microsoft Office 365, die Postfächer für Öffentliche Ordner mit den Standardeinstellungen sichern.
Alice Lamm
proessays admin
Alice Lamm
proessays admin
Halo,
als kleines Update (hat leider was länger gedauert):
Der Dienstleister geht davon aus, dass dies noch von den Migrationsversuchen übrig ist. D.h. Migration gestartet,abgebrochen und neugestartet. Dabei aber leider vergessen, die ersten Versuche zu bereinigen.
Da Exchange diese Mailboxen nicht kennt, gibt es auch keine Möglichkeit diese zu löschen.
Einzige Möglichkeit: Alle validen Mailboxen in eine neue DB verschieben und dann am Ende die vermeintliche leere DB löschen.
Gruß
als kleines Update (hat leider was länger gedauert):
Der Dienstleister geht davon aus, dass dies noch von den Migrationsversuchen übrig ist. D.h. Migration gestartet,abgebrochen und neugestartet. Dabei aber leider vergessen, die ersten Versuche zu bereinigen.
Da Exchange diese Mailboxen nicht kennt, gibt es auch keine Möglichkeit diese zu löschen.
Einzige Möglichkeit: Alle validen Mailboxen in eine neue DB verschieben und dann am Ende die vermeintliche leere DB löschen.
Gruß
