Verzweifelt.

1. offizieller Beitrag

    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

    • Offizieller Beitrag

    Hi,


    mir fallen mehrere Dinge ein die Du hättest machen können.


    1. Die Begrenzung der Datenbank auf 70 GB, wenn Exchange 2003 Standard.


    2. Die Offline Defrag kannst Du zeitlich definieren, wenn dieser laufen soll. ggf. auch mal kurz auf 13Uhr einstellen.


    3. Das betroffene Postfach trennen


    4. Die DB auf einem anderen Laufwerk mounten wo mehr speicer frei ist.


    5. Ofline Defrag mit dem Parameter /t auf einem anderen Laufwerk durchführen, wo mehr Speicher verfügbar ist.


    6. Überwachung des Transaktionsverzeichnisses, (auf Grösse) um dies frühzeitig zu erkennen.


    Viele Grüsse
    Heinz

    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

    • Offizieller Beitrag

    Hallo Jens,


    Dein Beitrag hat mich nicht so wirklich los gelassen. So wie Du es geschildert hast, hat man Dein Problem aufgenommen, als Bug beschrieben und dann Dich mit Deinem Problem alleine gelassen. Da diese Vorgehensweise ganz und gar Microsoft untypisch ist habe ich das Thema mal bei MS nachgefragt. Dazu habe ich gerade ein Telefonat mit den Kollegen gehabt, die sich derzeit noch immer mit Deinem Fall beschäftigen.


    Da stellt sich die Lage ein wenig anderes dar und ich finde es nur fair auch mal die andere Seite zu zeigen. Ob dies nun ein Bug ist oder nicht, steht noch gar nicht fest. Dies wird derzeit noch analysiert! Daher kann man auch noch nicht sagen ob es etwas geben wird oder nicht. Erst wenn die Ursache genau fest steht, kann man sich über eine Lösung unterhalten. :)


    Zudem hat Dich der Support in der Vergangenheit aktiv bei der Problemlösung unterstützt.
    1. Deinen Exchange Server wieder ans arbeiten zu bekommen
    2. Geholfen einen Performancecounter für die Überwachung in MOM zu schreiben, welcher diesen Fehler im Vorfeld erkennt und Dich so vorher informiert.


    Entsprechend kannst Du jetzt wieder arbeiten und sollte das Problem wieder auftreten, so kannst Du durch die MOM Info direkt schützen. Parallel wird das Problem genauer analysiert um zu prüfen ob es wirklich ein Fehler in der Software ist.


    Ich finde es immer leicht bei einem Problem über den Hersteller zu meckern und ich kann Dich auch zum Teil verstehen. Es ist ärgerlich, wenn ein System nicht arbeitet aber wie wäre es gewesen, wenn Du ganz alleine mit Deinem Problem gewesen wärst. Wenn ich an meinem Internet Provider Denke, der mich 3 Monate offline gelassen hat und 3 Techniker nicht in der Lage waren mich online zu bringen. Erst als Nobby mit einen Tipp gegeben hatte, konnte ich das Problem mit der Telefondose selber lösen.


    Ich hoffe Doch sehr, dass Du auch die Anzahl der Mails, so wie die maximale Grösse von Anlagen beschränkt hast. Ein Exchange Server oder auch jeder andere Mailserver ist kein Transferverzeichnis, dazu sollte man sich den Fileservern bedienen. Zudem stellt dies eine so hohe Last auf den Servern, Bandbreiten und Clients dar. Hatte auch mal den Fall, das einer ein 600MB ISO an einen Kollegen gesendet hat der Ihm gegenüber gesessen hat, und wundert sich dann, dass sein Client ein paar Minuten nicht reagiert.


    Ich denke aber eine solche Diskussion führt ein wenig zu weit. :)


    Viele Grüsse
    Heinz

    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

    Hallo,


    hier und jetzt möchte ich mich auch mal zu Wort kommen.


    "Da stellt sich die Lage ein wenig anderes dar und ich finde es nur fair auch mal die andere Seite zu zeigen. Ob dies nun ein Bug ist oder nicht, steht noch gar nicht fest. Dies wird derzeit noch analysiert! Daher kann man auch noch nicht sagen ob es etwas geben wird oder nicht. Erst wenn die Ursache genau fest steht, kann man sich über eine Lösung unterhalten."


    Microsoft hat uns allerdings keine Hoffnung gemacht jemals die genaue Ursache ermitteln zu können. Davon mal abgesehen, ist eine Lösung des Problems nicht davon abhängig, ob unser MAPI Profil analysiert werden kann, oder nicht. Denn wie Jens ja geschrieben hat, kann dies auch ohne defektes MAPI Profil böswillig reproduziert werden.


    Zudem hat Dich der Support in der Vergangenheit aktiv bei der Problemlösung unterstützt.
    1. Deinen Exchange Server wieder ans arbeiten zu bekommen
    2. Geholfen einen Performancecounter für die Überwachung in MOM zu schreiben, welcher diesen Fehler im Vorfeld erkennt und Dich so vorher informiert.


    Zu Punkt 1) Ja man hat uns geholfen, der Server funktioniert wieder


    Zu Punkt 2) Den Performancecounter habe ich ohne Hilfe von MS geschrieben. Sowohl die Idee als auch die Umsetzung ist auf meinem Mist gewachsen.


    Ich hoffe Doch sehr, dass Du auch die Anzahl der Mails, so wie die maximale Grösse von Anlagen beschränkt hast. Ein Exchange Server oder auch jeder andere Mailserver ist kein Transferverzeichnis, dazu sollte man sich den Fileservern bedienen.


    Wir haben fast alles beschränkt, was man nur beschränken kann, aber all das verhindert nicht die Möglichkeit einer DOS Attacke. Die Beschränkung des Files (grösse und Anzahl) wirkt sich erst beim senden aus. Lösche ich aber einfach eine von mir erstellte Mail mit 10000 Files und 7TB, die ich noch nicht gesendet habe, welche nur im Ordner Drafts liegt, wandert diese direkt in den Dumpster, welcher nicht beschränkt werden kann.


    Auch finde ich es sehr bedenklich, wenn man eine Aussage bekommt, die da lautet: Das ist keine Sicherheitslücke, sondern "NUR" die Möglichkeit einer DOS-Attacke.


    Ich hoffe, das ich weiterhin gut mit dem Support-Kollegen von MS weiterarbeiten kann, dieser ist glaub ich der einzige, der unser Problem verstanden hat und sich mühe gibt, leider scheinen seine Arme aber etwas zu kurz zu sein, um bei MS etwas bewegen zu können.



    Gruss
    The Coder

    • Offizieller Beitrag

    Hi Jens,


    dann kann ich Deine Einstellung auch Teilen. Den Weg den Du eingeschlagen hast war der einzig richtige. Bei so einem Problem, welches sich wiederholen könnte ist es am einfachsten und auch am besten, sich direkt an den Hersteller zu wenden. Dies gibt übrigens nicht nur bei MS, sondern in allen Bereichen.


    Nun ist es aber auch so, dass man in so einem Fall verschiedene Prios setzen muss.


    Als erstes ist es am wichtigsten, dass das System wieder arbeitet und so die Mitarbeiter in Ihrer Arbeit nicht eingeschränkt sind. -> Dies ist ja bereits erfolgt und der nächte Punkt kann folgen.
    Identifikation der Ursache für das Problem. -> Dies ist ebenfalls erfolgt, da es am MAPI lag.
    Analyse wie es zu diesem Fehler gekommen ist. - > Derzeit in Arbeit
    Behebung der Ursache, damit sich der Fehler nicht wiederholt. -> Abhängig von der Analyse


    Ich kann Dir nur raten aktiv mit den Ansprechpartnern in Verbindung zu bleiben und den Verlauf mit zu verfolgen / zu unterstützen. Es setzen sich derzeit mehrere Instanzen bei MS mit Deinem Fall auseinander.


    Viele Grüsse
    Heinz

    • Offizieller Beitrag

    Hi Coder,


    dann empfehle ich Euch nur den Weg weiter bei zu halten zu falls Ihr den Eindruck habt, dass nicht weiter daran gearbeitet wird, dass Problem über Euren TAM zu eskalieren. Der ist ja der erste Ansprechpartner für Euch. Eine solche Problematik lässt sich leider nicht in 24 Stunden lösen, dafür ist das Tehma zu komplex.


    Haltet uns auf dem laufenden wie es weiter geht.


    Viele Grüsse
    Heinz