Site icon Frankys Web

Exchange 2010 SP1: Reparatur von Fehlern in Postfächern und Datenbanken

Vor dem Exchange Server 2010 Service Pack 1 ließen sich Fehler in der Datenbank mit dem Tool ISINTEG beheben. Dafür musste die betreffende Datenbank offline sein. Mit dem Service Pack 1 für Exchange 2010 wurde ISINTEG durch ein CMDlet in der Exchange Management Shell abgelöst. Das neue CMDlet heißt „New-MailboxRepairRequest“
und kann ausgeführt werden während die Datenbank online ist. Möglich ist auch nur bestimmte Postfächer in der Datenbank zu überprüfen und Fehler zu beheben. Wie das geht, beschreibe Ich in diesem Artikel.

Um eine Datenbank auf Fehler zu prüfen genügt der folgende Befehl:

New-MailboxRepairRequest -Database „Mailbox Database“ -CorruptionType ProvisionedFolder,SearchFolder,AggregateCounts,Folderview –DetectOnly

Der Befehl prüft die Datenbank „Mailbox Database“ und alle darin enthaltenen Postfächer auf Beschädigungen. Der Parameter -CorruptionType gibt an, nach welchen Problemen gesucht werden soll. Der Schalter –DetectOnly gibt an das Fehler nur protokolliert werden, aber nicht versucht wird die Fehler zu beheben.

Folgende Typen können für den Schalter -CorruptionType angegeben werden:

SearchFolder = Auf beschädigte Suchordner prüfen

FolderView = Ansichten für Ordner prüfen die falsche Inhalte zurückgeben

AggregateCounts = Prüfen auf aggregierte Zählerwerte für Ordner, die falsche Werte anzeigen

ProvisionedFolder = Prüfen auf bereitgestellte Ordner, die auf nicht bereitgestellte übergeordnete Ordner zeigen

Wenn der Parameter –DetectOnly weggelassen wird versucht Exchange die gefunden Fehler auch direkt zu beheben.

Um nicht die komplette Datenbank sondern nur ein Postfach auf Fehler zu prüfen genügt dieser Befehl:

New-MailboxRepairRequest -Mailbox Frank -CorruptionType ProvisionedFolder,SearchFolder,AggregateCounts,Folderview

Um Postfach und Archiv zu testen fügt man –Archive hinzu:

New-MailboxRepairRequest -Mailbox Frank -CorruptionType ProvisionedFolder,SearchFolder,AggregateCounts,Folderview –Archive

Nach dem Absetzen des Befehls lässt sich die Prüfung nur noch durch offline schalten der Datenbank abbrechen. Ergebnisse der Prüfung werden im Anwendungs Event-Log des Servers protokolliert. Die Events tragen die folgenden Ereignis-IDs:

10044

10045

10046

10047

10048

10049

10050

10051

10059

10062

Beispiel:

Das Anwendungs Log, lässt sich auf die entsprechenden IDs filtern, dazu einfach im Aktionsfeld auf „Aktuelles Protokoll filtern“ klicken und die ID eingeben

Exit mobile version