Summary: Der Fehler 'Cannot open mailbox /o=First Organization /ou=Exchange Administrative Group' tritt auf, wenn Sie versuchen, den Abschnitt Add-Ins unter Organization im Exchange Admin center (EAC) zu öffnen. Dies kann vorkommen, wenn die Datenbank(en) aufgrund einer Beschädigung demontiert wurde(n) oder kritische Exchange-Dienste aufgrund eines Problems mit dem Exchange-Server entweder nicht laufen oder gestoppt sind. In dieser Anleitung helfen wir Ihnen, den Fehler zu beheben und die Datenbankbeschädigung mit einem Exchange-Wiederherstellungstool, wie Stellar Repair for Exchange, zu beheben.
Exchange Server funktioniert mit allen Funktionen und Möglichkeiten, die er bietet, wie ein Zauberstab. Eines der Merkmale von Exchange Server ist seine Fähigkeit, Add-Ins für Outlook-Benutzer zu veröffentlichen. Diese Add-Ins erweitern die Fähigkeiten des Outlook-Clients um Informationen und Tools, die mit Outlook kompatibel sind. Wie wir alle wissen, handelt es sich bei Add-Ins um Anwendungen von Drittanbietern, die einen Mehrwert für die Anwendung darstellen. Sie können über eine URL, eine Datei oder den Office-Store installiert werden.
In unserer Exchange Server-Infrastruktur möchten wir nicht zulassen, dass unsere Benutzer falsche Add-Ins von Drittanbietern installieren, die die Kommunikation oder die Funktionsfähigkeit von Outlook beeinträchtigen. Als Administratoren würden wir ein rationalisiertes System bevorzugen, in dem die Benutzer alle Tools haben, die sie für die Zusammenarbeit benötigen, und die Installation kontrollieren können. Dies kann über das Exchange Admin Center (EAC) erfolgen. Dadurch erhalten wir die Rollen und können die Fähigkeit der Benutzer, diese Add-Ins zu installieren, kontrollieren. Dazu müssen wir auf Organisation und dann auf Add-Ins klicken.
Von hier aus können wir die zu installierenden Add-Ins hinzufügen, entfernen und kontrollieren. Manchmal tritt jedoch beim Zugriff auf die Registerkarte “Add- Ins” ein Fehler auf.
Die Fehlermeldung lautet wie folgt:
"Postfach kann nicht geöffnet werden /o=My Organization/ou=Exchange Administrative Group (GUI)/cn=Configuration/cn=Servers/cn=EX01/cn=Microsoft System Attendant".
Was müssen wir tun, um das Problem zu beheben?
Zunächst müssen wir überprüfen, ob alle Dienste unseres Exchange Servers laufen und sicherstellen, dass alle Dienste, die auf automatischen Start eingestellt sind, auch gestartet werden.
Als Nächstes müssen wir überprüfen, ob die Datenbanken auf unserem Exchange-Server alle gemountet und in Ordnung sind. Dazu öffnen Sie das Exchange Admin Center (EAC) und klicken dann auf Server und Datenbanken.
Nun müssen wir sicherstellen, dass der Status aller Datenbanken auf “Gemountet” gesetzt ist. Wenn eine oder mehrere Datenbanken nicht gemountet sind, müssen wir der Sache nachgehen.
Zu diesem Zweck ist zunächst zu prüfen, ob der Server und das Laufwerk, auf dem die Datenbanken und Protokolle gespeichert sind, über ausreichend Speicherplatz verfügen. Dies ist einer der Hauptgründe, warum eine Datenbank nicht gemountet wird, und die Hauptursache für eine mögliche Beschädigung der Exchange-Datenbank oder -Protokolle.
Als nächstes müssen wir die Lizenzversion des installierten Exchange Servers mit der Anzahl der konfigurierten Datenbanken vergleichen. Die Exchange Server Standard-Version erlaubt bis zu 5 Online-Datenbanken. Das heißt, wenn Sie mehr als 5 Datenbanken haben, sind nur 5 online und die restlichen werden abgemeldet. Normalerweise würde dies nicht passieren, da der Exchange- Administrator die Kontrolle über die Anzahl der zu konfigurierenden Datenbanken hat. Wenn aber jemand anderes zu Testzwecken oder aus anderen Gründen neue Datenbanken angelegt hat, werden die zusätzlichen Datenbanken abgemeldet. Die einzige Lösung für dieses Problem besteht darin, entweder die zusätzlichen Datenbanken zu löschen oder eine Exchange Server Enterprise- Lizenz zu erwerben, was für mittelständische Unternehmen recht teuer ist.
Wenn Sie Daten in der zusätzlichen Datenbank haben, müssen Sie die New- MailboxExportRequest verwenden, um alle Postfächer und andere Informationen daraus zu exportieren. Wenn sich öffentliche Ordner in der Datenbank befinden, ist es etwas komplizierter, da Sie Skripte verwenden müssen, um die Daten zu extrahieren, oder Outlook verwenden.
Außerdem ist zu prüfen, ob eine neue Anwendung auf dem Server installiert wurde oder ob ein Upgrade der aktuellen Serveranwendungen durchgeführt wurde. Wenn eine Anwendung nicht mit Exchange Server kompatibel ist, kann sie in der Regel den Betrieb behindern und sogar die Daten beschädigen. Die üblichen Verdächtigen sind Antiviren- und Sicherungssoftware. Wenn die Anwendungen nicht kompatibel oder Exchange Server-freundlich sind, können sie den Betrieb behindern und Dateien blockieren.
Ein weiterer Grund ist die Beschädigung der Exchange Server-Datenbanken aufgrund von Softwareproblemen oder Hardwarefehlern, z. B. einer defekten Hauptplatine, eines plötzlichen Stromausfalls oder einer fehlerhaften Patch- Installation. Wenn die Datenbank nicht sicher getrennt wird, kann dies ein Grund sein, warum die Datenbank oder das Protokoll beschädigt wird.
Zu Beginn müssen wir die EseUtil verwenden, um den Zustand der Offline- Datenbank zu ermitteln.
Wir müssen die Exchange Management Shell (EMS) in unserem Exchange Server öffnen und den folgenden Befehl eingeben, um den Status der Datenbank zu sehen.
eseutil /MH <Pfad der Edb-Datei>
Wenn sich die Datenbank im Status “Clean Shutdown” befindet, können wir die Datenbank einfach mounten. Wenn die Datenbank jedoch aufgrund einer Beschädigung oder einer fehlenden Protokolldatei nicht gemountet werden kann, wird der Status als “Dirty Shutdown” angezeigt.
Wir können die Datenbank reparieren, indem wir die Soft Recovery oder die Hard Recovery durchführen.
Zunächst führen wir die Soft Recovery aus, eine Schnellreparatur für Datenbanken mit geringfügigen Beschädigungen. Wenn wir den Parameter /MH ausführen, müssen wir auch die Zeile mit der Aufschrift “Log Required” (Protokoll erforderlich) beachten, da sie Auskunft über die fehlenden Protokolle gibt. Ein Beispiel für eine solche Zeile lautet wie folgt:
Protokoll erforderlich: 4-4 (0x4-0x4)
Je nach dem Grad der Beschädigung und der Größe der Datenbank wird dies einige Zeit in Anspruch nehmen. Die sanfte Wiederherstellung kann mit dem eseutil/reseutil/r-Parameter (wie unten angegeben).
EseUtil /r E04 /l "M:\mbx01\logs" /d "M:\mbx01\mbx01.edb"
Dadurch wird eine schnelle Reparatur der Datenbank durchgeführt. Danach können wir EseUtil mit dem Parameter /MH erneut ausführen und den Zustand der Datenbank überprüfen. Befindet sich die Datenbank immer noch im Zustand “Dirty Shutdown”, müssen wir die harte Wiederherstellung mit dem Parameter /P durchführen.
Ein Wort der Vorsicht: Verwenden Sie die harte Wiederherstellung als letzten Ausweg, da sie alle Daten löscht, die als beschädigt gelten, und es keine
Garantie dafür gibt, dass die Datenbank nach der Ausführung dieses Befehls wiederhergestellt wird.
Sobald wir den Befehl ausführen, werden Sie aufgefordert zu bestätigen, dass Sie den Datenverlust akzeptieren.
Alternativ, um Ärger und langwierigen Prozess zu vermeiden, verwenden Sie Stellar Repair for Exchange. Diese Anwendung kann jede beschädigte Exchange Server-Datenbank öffnen. Es extrahiert Daten aus EDB und speichert sie in PST und anderen Formaten. Darüber hinaus ermöglicht es, wiederhergestellte EDB- Daten direkt in eine andere Exchange Server-Datenbank oder Office 365 zu exportieren, wodurch das Problem mit weniger Aufwand und in viel weniger Zeit gelöst wird.
