Beiträge von balu

Hallo,

bitte nicht falsch verstehen. Ich wollte hier nicht über Microsoft meckern. Die jenigen, welche sich mit der Wiedeherstellung beschäftigt haben, habe uns bei dem Problem auch geholfen. Der jenige, welcher sich mit dem MAPI Profil beschäftigt hilft auch. Gut wir müssen horende Summen für die Analyse bezahlen (anderes Thema; will wie gesagt nicht meckern).

Die Sache mit dem Performance Counter war ein Tipp, welcher Entwicklungszeit von uns nachzieht. Die Probleme, welche es damit gibt ist auch wieder ein anderes Thema.

Mein Anliegen hier war mal nachzufragen, ob irgendwer eine Idee hat, wie man dieses Problem aktiv angehen kann, weil trotz allem die Probleme selbst mit allen Begrenzungen noch vorhanden ist. Es geht mir hier nicht darum eine Antwort für das defekte Profil zu bekommen. Dafür läuft die Analyse bei MS.

Ich werde im Normalfall von MS unterstützt und kann mich auch über den Support nicht beschweren. Alles was wir, wenn es akute Probleme gab, hatten wurde gelöst.

Es nutzt nur nichts, da ich zur Zeit einfach nicht weiss, was ich machen soll, es hat irgendwie halt keiner eine Lösung für mich.

Gruss

Jens

Danke für die Antwort,

aber leider bringt das alles nichts.

Das mit dem Offline Defrag haben wir zeitlich nachgelagert. Hatte aber wieder ein nicht vorhanden sein des Exchange Dienstes zu folge und bei einem Betrieb, welcher in Teilbereichen 24*7 arbeiten muss, ist dies immer #Zensiert#.

Es handelt sich nicht um Exchange 2003 Standard. Die Umgebung sieht folgender Massen aus:

8 Exchange 2003 Enterprise, welche sich in 2 Vierknotencluster verteillen, vovon jeweils 2 aktiv sind. Das Ganze ist auf 2 RZs mit redundatem SAN verteilt und hostet 10000 Benutzer.

Mittlerweile haben wir durch Tests noch weiteres heraus gefunden. Es ist binnen Minuten möglich die Datenbank in die Knie zu zwingen. Wenn ein Benutzer eine Mail erstellt und dort eine Anlage von 100GB (oder mehrere ISO DVD Images oder irgendwas anderes)einfügt, dann wird diese in die Datenbank übertragen. liegt die Mail im Entwurf und der Benutzer löscht den Entwurf wieder, dann liegt die Datei im Dumpster und die Postfachbegrenzungen ziehen nicht mehr.

Da dies halt immer funktioniert ist eine Überwachung der Transaktionlogs schwierig (Punkt 6). Wir führen übrigens eine solche Überwachung mittels MOM durch und wir waren zu langsam, da es nach den normalen Geschäftszeiten passierte und für die IT nur noch eine Rufbereitschaft verfügbar war. Bezweifele, dass wir es geschafft hätten wären den Geschäftszeiten zu reagieren.

Die Punkte 2,4 und 5 der Antworten haben wir dann auch durchgeführt. Helfen aber nicht das Problem zu eliminieren.

Den Ansatz des Punktes 3 fanden wir auch, leider ist dieser Punkt nicht machbar, da von seiten der zentralen Systeme eine MAPI Sitzung nicht so einfach trennbar ist. Hier spielt der MBI Cache, welcher die Sitzung bis zu 2 Stunden aufrecht erhält, nicht mit. Weiterhin wäre der Löschjob schon dem Exchange übergeben worden und es würde dem Exchange reichlich egal sein, dass die Sitzung weg ist. Er würde es abarbeiten. Die einzige Möglichkeit die Sitzung zu beenden wäre die Datenbank zu dismounten. Da habe ich aber imme rnoch das Problem, dass die Transaktionlogs dann abgearbeitet werden und dies auch zu einem Kollaps führen kann.

Gruss

Jens

Hallo,

bin irgendwie total verzweifelt. Habe ein Problem, welches alle (!) Exchangeversionen betrifft und keine Lösung dafür. Meiner Meinung ist es ein Sicherheitsproblem.

Was ist passiert?

Durch ein defektes MAPI Profil sind Löschungen in einem Postfach ausgelöst worden, welche vom Exchange an das Outlook irgendwie nicht bestätigt wurden, so dass Outlook die gleichen Mails immer wieder löschen wollte. Dies führte dazu, dass die Partition für die Transaktionlogs voll lief und trotz MOM Überwachung und Vorsichtsmassnahmen die Datenbank abgehängt wurde. Leider war kein Platz mehr vorhanden um die Datenbank wieder zu mounten. Hier wurde im SAN die Partition vergrössert, ein kompletter Restore der Datenbank plus roll forward der Transaktionlogs durchgeführt um die Datenbank wieder online zu bekommen. Ausfallzeit cirka 12 Stunden plus weiteren 6 Stunden für die Nacharbeiten, wie z.B. offline Defrag für die Datenbank.

Die Recherche hat ergeben, dass es immer passieren kann und es keine Lösung hierfür gibt. Der Fehler hat es geschafft die Datenbank innerhalb von 2 Stunden auf über 90GB(!; von ursprünglich 10GB) anwachsen zu lassen. Der Benutzer hat eine Postfachbegrenzung von 100MB, welche aber hier nicht greift, weil trotz ausgeschaltetem Dumpster die Löschungen über die Transaktionlogs in den Dumpster verschoben werden, welcher trotz dem Eintrag 0 Tagen immer erst nachts wirklich löscht und nichts mehr mit der Postfachbegrenzung zu tun hat. Der Dumpster selber ist auch nicht begrenzbar.

Es ist somit jeder Zeit möglich mit Benutzerrechten, je Konfiguration der Systeme eine oder alle Datenbanken eines Exchangesystems zu dismounten!!!
Ein Schadprogramm könnte dies ausnutzen indem es via MAPI, mit den vorhandenen Benutzerrechten, Mails erstellt und sofort wieder löscht.

Wir haben dies an Microsoft eskalliert und sind jetzt seit 4 Wochen daran eine Lösung zu finden. Es kam von Microsoft bis jetzt keine und so wie es aussieht wird es auch keine geben.

Angeblich wurde der Vorfall von unserem Microsoft TAM an die Securityabteilung eskalliert und folgender Massen beantwortet: "Für MS ist dies keine Sicherheitslücke, sondern nur die Möglichkeit für eine DOS Attake bei jeder Exchangeversion. Deswegen wird es hierfür nichts geben."

Deswegen jetzt hier die Frage eines wirklich Verzweifelten. Kennt jemand eine Möglichkeit so etwas abzufangen?

Gruss

Jens