Defektes Postfach kann nicht gelöscht werden

    Nachtrag zu ExBPA:


    .NET Framework 1.1 hat wohl Probleme mit Windows 7 und ExBPA läuft nicht ohne .NET Framework 1.1.


    ExBPA läuft laut MS (http://www.microsoft.com/downl…ddbd258df3&displayLang=de) nur auf Windows 2000 Service Pack 4; Windows Server 2003; Windows XP Service Pack 2.


    Brauche ich also eine "Windows XP Service Pack 2"-Workstation oder würde es auch auf einem Vista-Rechner laufen? Hat da jemand Erfahrungen gesammelt?


    Ansonsten müsste ich ExBPA wohl doch auf dem Server installieren (obwohl MS das nicht empfiehlt: http://www.microsoft.com/downl…ddbd258df3&displayLang=de).


    Also doch die Frage nach Alternativen: Wie bekomme ich möglichst viele Informationen über mögliche Fehler ohne mich durch die dafür notwendigen Aktionen dem Verdacht auszusetzen, die Situation zu verschlimmern?

    ExBPA findet nichts schlimmes an der Datenbank.


    Ob die Online Maintenance besser löscht als das manuelle Löschen bzw. der Cleanup-Agent, wird aktuell getestet.

    Ein weiteres Zwischenergebnis: Auch mit MFCMapi kann auf das defekte Postfach zugegriffen werden. Der betroffene Ordner kann auf viele, viele Ebenen ausgeklappt werden, bis irgendwann Schluss ist. Dennoch ist dort genauso wie mit Outlook und OWA kein Löschen möglich (also auch kein Löschen des untersten Ordners in der Struktur, i.e. dem, für den keine Unterordner mehr angezeigt werden).

    Zusammenfassung: Auch die Online Maintenance löscht das Postfach nicht. Es tritt weiterhin der folgende Fehler auf:


    Ereignistyp: Fehler
    Ereignisquelle: MSExchangeIS Mailbox Store
    Ereigniskategorie: Allgemein
    Ereigniskennung: 1203
    Benutzer: Nicht zutreffend
    Computer: SRV-SBS
    Beschreibung:
    Das Postfach von /O=***/OU=FIRST ADMINISTRATIVE GROUP/CN=RECIPIENTS/CN=*** konnte aufgrund von Fehler 0x3f0 nicht gelöscht werden.


    Hier nochmal die gesammelten Daten:


    Microsoft Windows Server 2003 für SBS, SP 2
    Exchange 2003 (6.5), Service Pack2, Standard
    Microsoft Exchange-Informationsspeicher, Version 6.5 (Release 7638.2)


    ExBPA und ExTRA liefern keine Fehler bezogen auf die Datenbankintegrität.


    Es ist jederzeit möglich, neue Postfächer zu erstellen und wieder zu löschen. Alle anderen Postfächer funktionieren fehlerfrei.


    Ein Zugriff auf das defekte Postfach kann mit Outlook, OWA oder MFCMapi erfolgen. Im Ordner "Gelöschte Objekte" erscheint eine tief verschachtelte Ordnerkette. Diese kann nicht gelöscht werden. Es tritt (in Outlook) ein Fehler auf, dass nicht mehr als 4000 Objekte auf einmal gelöscht werden können. Zudem tritt (wohl beim Synchronisieren) folgende Meldung auf:


    Ereignistyp: Fehler
    Ereignisquelle: MSExchangeIS
    Ereigniskategorie: Allgemein
    Ereigniskennung: 9646
    Benutzer: Nicht zutreffend
    Computer: SRV-SBS
    Beschreibung:
    Die MAPI-Sitzung "/o=***/ou=first administrative group/cn=Recipients/cn=***" hat die maximal zulässige Anzahl von 500 Objekten vom Typ "objtFolder" überschritten.


    Sollten noch irgendwelche Informationen fehlen, sagt es mir bitte.


    Meine Frage ist jetzt also: Gibt es a) irgendeine Idee, wie man diese Ordnerkette clientseitig entfernen könnte (gerne auch im Rahmen der bereits versuchten Möglichkeiten) oder b) wie man das defekte Postfach aus dem Postfachspeicher bekommt?


    Der Ansatz a) wäre mir natürlich lieber, zu Ansatz b) könnte die Datenbank vorher gesichert werden, um sie dann eventuell komplett zu löschen und anschließend nur die funktionierenden Postfächer zurückzuspeichern.

    Bei Microsoft habe ich noch das hier gefunden: http://social.technet.microsof…3a-4b74-9267-46bd1bf064b5
    das geht ansatzweise in die selbe Richtung, ebenfalls dies hier: http://www.office-outlook.com/…forum/index.php/m/507784/
    leider aber wohl auch noch über ein Jahr später noch nicht gelöst: http://www.varlog.us/?paged=2


    Ich fürchte wirklich, eine clientseitige Lösung scheidet aus :-(.


    Der Vollständigkeit halber hier noch die kompletten Meldungen von Outlook -

    Zitat

    Dieser Fehler kann auftreten, wenn Sie mehr als 4000 Nachrichten gleichzeitig löschen möchten. Outlook kann nicht mehr als 4000 Nachrichten löschen, wenn ein Servernachrichtenspeicher verwendet wird.
    Löschen Sie weniger als 4000 Nachrichten gleichzeitig, um diesen Fehler zu vermeiden.
    Möglicherweise besitzen Sie nicht die erforderlichen Berechtigungen, um diese Nachrichten zu löschen. Falls Sie den Inhalt im Ordner eines anderen Besitzers löschen müssen, wenden Sie sich an den Besitzer, um die entsprechenden Berechtigungen zu erhalten, oder bitten Sie den Besitzer, den Inhalt zu löschen.


    und MFCMAPI beim Löschen -

    Zitat

    Warning:
    Code: MAPI_W_PARTIAL_COMPLETION == 0x00040680
    Function lpParentFolder->DeleteFolder( lpItemEID->cb, (LPENTRYID) lpItemEID->lpb, lpProgress ? (ULONG_PTR)m_hWnd : NULL, lpProgress, ulFlags)
    File .\MsgStoreDlg.cpp
    Line 958


    bzw. Verschieben -

    Zitat

    ...


    Update: Als ich gerade mit MFCMAPI verschieben wollte (was bisher nicht ging), um die Fehlermeldung hier zu posten, konnte ich verschieben. :-?


    Habe also den kompletten Ordnerstrang aus den gelöschten Objekten nach oben verschoben (direkt unter "Top of Information Store") und versuche ihn nun zu "zerstückeln". Ging auch ganz gut, bis ich eben beim Aufklappen wieder bis zum Ende gegangen bin - da wo MFCMAPI nicht mehr weiter aufklappt und der Server dann folgendes meldet -


    dann kommt von MFCMAPI -

    Zitat

    Warning: CopyFolder failed.
    Code: MAPI_W_PARTIAL_COMPLETION == 0x00040680
    Function (null)
    File .\MsgStoreDlg.cpp
    Line 609


    Versuche nun mit dem Aufklappen vorsichtiger zu sein und kleinere Stücke zu verschieben. Ich melde mich wieder.

    Verschachtelter Ordner weg, korruptes Postfach weg, neues Postfach da, alle Daten importiert - perfekt.


    Einen riesigen Dank auch an den fleißigen Helfer im Hintergrund. Es ist schön, dass es noch Leute gibt, die einem die Hand reichen und nicht gleich die Hand aufhalten.


    Schön auch, dass die Reparatur im Endeffekt clientseitig und ohne außergewöhnliche Aktionen auf dem Server funktioniert hat.