Erfahrungsbericht: Exchange Server 2003 Fehler

[singlepic id=1012 w=200 h=200 mode= web20 float=left]Fehler im System mag keiner. Wenn ein Programm abst?rzt ist es zwar ärgerlich, aber im großen Teil sind keine Daten betroffen. Anders verhält es sich mit einem Fehler beim Exchange Server 2003 von Microsoft. Bei einem Kunden wird seit den Feiertagen der Fehler 447 (Event ID 447 in ESE) in nicht ganz sporadischen – ich w?rde sagen im Millisekundentakt – Schritten ins Ereignisprotokoll geworfen. Dieses ist seitdem auf eine beachtliche Größe gewachsen voll von 447er Einträgen. Lustig anzusehen, wenn es lustig wäre.

Im Exchange Store hat sich irgendwo in den Datenobjekten mindestens ein Fehler versteckt und den galt es operativ, am Besten ohne Zange, Skalpell und Schl?pfer zu entfernen. Microsoft macht es sich an dieser Stelle sehr leicht und empfiehlt eine Datensicherung vor dem ersten Fehlereintrag einzuspielen. Ganz großes Kino an dieser Stelle, denn das erste Auftreten des Ereignisses war vor den großen Feiertagen, genannt Weihnachten. Ergo wären alle eingegangenen und versendeten Mails futsch. Das ist nat?rlich nicht im Sinne und Interesse des Kunden, welcher uns auch prompt mit der Reparatur beauftragte. Lieber 10 Mails weg, als 100 oder gar 1000.

Der Fehler 447 verursachte nämlich eine verzögerte oder gar keine Zustellung von externen Mails in den Exchange Store. Diese blieben in der Empfangswarteschlange einfach stecken und frohlockten mit der Meldung „Verzögerte Zustellung“. Genau das Richtige zu Weihnachten. Wenns klemmt bei der Post, dann verzögert sich das auch bei denen.

[singlepic id=1011 w=200 h=200 mode= web20 float=right]Bei der Reparatur einer Exchange Datenbank empfiehlt Microsoft den Weg des geringsten Widerstandes – mit dem Hammer auf den Kopf. Sprich, sie empfehlen die Reparatur unter Akzeptanz von gelöschten Einträgen. Die Anleitung tippe ich aber hier nicht ab, denn die gibt es bei Microsoft sehr ausf?hrlich sogar in Deutsch. Zugegeben, die maschinelle Übersetzung krankt doch ganz schön und um ehrlich zu sein, habe ich das gleich auf Englisch umgestellt. Aber das Wichtige, die Befehle, kann man Schritt f?r Schritt deuten. Zu Hause sitzend mittels VPN zur Firma auf den hiesigen Firmen Terminal Server, und von dort aus via SSH-Tunnel zum Kunden via RDP, verrichte ich meine Arbeit und mein Kollege verfolgt mein Tun als Lehrvorf?hrung via Teamviewer.

Was Microsoft aber verschweigt, ist die aufzuwendende Zeit f?r solche Aktionen. Beim Kunden handelt es sich „nur“ um eine Exchange Datenbank von knappen 19 GB Gesamtgröße. Mit dem ersten Befehl habe ich heute um knapp 14.00 Uhr orts?blicher Zeit angefangen. Just in diesem Moment des Schreibens ist es 22.24 Uhr geworden und der zweite Schritt hat nach 15 Minuten seiner Ausf?hrung den ersten Punkt seiner total tollen Prozentskala gef?llt. Nach derzeitigen Hochrechnungen braucht die Abarbeitung also nur noch knappe 12,5 Stunden. Das reiß ich doch mit der linken Gesäßhälfte ab.

Was steht nach der Defragmentierung noch an? Die Datenbank muss wieder eingekoppelt werden, damit sie dann wieder ausgekoppelt werden kann. Wieso, das weiß nur MS, aber danach soll erst der Integritätscheck funktionieren. Manchmal zweifle ich daran, ob einige Menschen ?berhaupt integer sein können. Aber ich schweife ab …

Danach sollte alles funktionieren, wenn es nach der Anleitung von Microsoft geht. Ich lasse mich ?berraschen. Die folgenden Zeilen zeigen nun die jeweiligen Zeit- und Aktionspunkte des Geschehens, damit der geneigte Leser eine Zeitvorstellung von den Dingen erhält.

22.30 Uhr: Die 15% Marke des Defragmentationsstatus ist geknackt. Schneller als erwartet „saust“ das Tool einfach so ?ber die Datenbank hinweg. Obwohl – unter Sausen versteh ich etwas anderes.

22.41 Uhr: Der graphisch hochwertige Fortschrittsbalken ist bei satten 22% oder 12 Punkten angekommen – je nachdem, wie man es am Liebsten hat. In der Zwischenzeit habe ich meine Abendwäsche nebst Duschen erledigt. Ich glaube, ich lese nebenbei etwas. Ich hab da noch so einen Wälzer rumliegen – Mac OS X Leopard – Missing Manual von David Pogue.

22.47 Uhr: Gute 40 Seiten mit allerlei Ablenkung habe ich gelesen und mich köstlich dabei am?siert. Kann das Buch nur empfehlen. Nebenbei schaue ich gerade auf den Balken, welcher mir einen Status von 38% suggeriert.

22.52 Uhr: Ich komme kaum noch hinterher, so schnell der Balken seinen Status ändert. 44% ist er nun und ich bin nur knappe 10 Seiten weiter. Zugegeben, ich habe mir die PSP gekrallt und etwas Loco Roco 2 gespielt. Irgendwie muss man sich von dem hypnotischen Balken ja ablenken.

Angenommen, ich wäre jetzt beim Kunden vor Ort, dann wäre das alles immer noch Arbeitszeit, oder?

22.58 Uhr: Die magische 50% Marke ist durchbrochen worden. Mit Hypergeschwindigkeit, – ach was sage ich – Wahnsinnige Geschwi… – quatsch, Lächerliche Geschwindigkeit geht es nun Schritt f?r Schritt vorwärts. Die VPN Verbindung dudelt nun seit knappen 11 Stunden gen Firma.

23.03 Uhr: Die Aktualisierung meines FreeNAS Servers ist gerade fertig geworden und der Server hat gerade seine Neustart-Runde gedreht. AFP (Apple Filing Protocol) und SMB Zugriffe funktionieren in einer affenartigen Geschwindigkeit. Stellenweise kratzt der Datentransfer an der 80 MByte / Sekunde Marke. Da sollte sich MS mal eine Scheibe von abschneiden, denn der Defrag-Vorgang ist jetzt erst bei 60% angekommen.

23.05 Uhr: Mein Kollege schaut mir noch gespannt und ohne m?de zu werden dabei zu, wie ich in der RDP Sitzung lässig den Maus-Cursor hin und her bewege. Gelernt ist eben gelernt. Nebenbei nutzen wir Notepad in der Sitzung, um miteinander zu „chatten“. Naja, es ist eher ein gegenseitiges Getippe in einer Textbox, wo der Eine dem Anderen immer den Text unterbricht, sowie den Cursor klaut, um seine Weisheiten zum Problem via Tastatur loszuwerden. Wir sollten uns aber mal auf ein Synchronisationszeichen verständigen, damit die Kommunikation mal geordnete Bahnen läuft. Sicherer geht es aber auf keinen Fall.

23.10 Uhr: Die Schallmauer wird nun durchbrochen. 73% sind erreicht. Mein Kollege und ich fragen uns, ob der IsInteg-Befehl auch noch einmal so lange brauchen wird?

23.19 Uhr: Bin gerade von einem erfrischenden Besuch auf dem Balkon zur?ck. Notiz an mich: Es ist Winter und ich sollte eine Jacke anziehen. Aber die Kälte hat sich gelohnt, denn der Balken ist bei sagenhaften 90% angekommen.

23.24 Uhr:  Mein Kollege und ich diskutieren ?ber das Aufwachverhalten seines MCE-Rechners. Dieser ist einfach so angegangen und nach Zeit X ausgegangen. Kein Netzwerk ist angeschlossen. Ich empfahl ihm mal seinen IR-Empfänger abzudecken. Es gibt Fernbedienungen, die auch das MCE beeinflussen via IR. Oder aber er nutzt Neonröhren mit flackerndem Licht. Oder aber, der Rechner hat eine Meise – wer weiß es schon so genau. 98% sagt der Balken. Je länger ich ihn ansehe, um so vertrauter wird er. Er wird mir sicherlich fehlen, wenn das Ganze vorbei ist …

23.29 Uhr: Bye bye Balken – er hat uns f?r immer verlassen. Aber es gibt ein Wiedersehen mit seinem Bruder, der prompt danach aufploppt. Dieser zeigt den Status/die Menge der zu kopierenden Datei an. Er bewegt jetzt die temporäre defragmentierte Datei an den Zielort. Der Balken bewegt sich suggestiv etwas schneller und ist bereits bei 20%.

23.35 Uhr: Zu fr?h gefreut. An die geplante Datensicherung des Servers hatten wir gedacht. Leider gibt es dort noch andere Server, die mitunter jetzt fleißig auf das Volume sichern, wo die temporäre Datei drauf liegt. Clever sag ich nur, denn nun sackt der Kopierprozess zusammen und steht noch bei 22%. Ich liebe es, wenn ein Plan funktioniert. Nicht meiner – der Sicherungsplan *grummel*

23.41 Uhr: Da wird nicht lange gefackelt. Sicherungssoftware angeschmissen und die Backup-Job gekillt. Heute ist auch noch Montag und da machen die Server ein Vollbackup. Das kann gefälligst nach unserer Aktion laufen. Wer lacht an dieser Stelle zuletzt, häh? Transferratenklauer der …

23.56 Uhr: Super! Trotz abgebrochener Jobs verweilt der Kopierprozess in der affenartigen Geschwindigkeit. Und ich wollte Feierabend machen – ist schließlich schon spät. So viel zu „Macht mal schnell – kann ja nicht lange dauern …“

24.00 Uhr: Zum Heulen – Bild steht, RDP Sitzung ist eingefroren. Mich deucht, die Zwangstrennung in der Firma ist eingetroffen. Also heißt es warten, bis ich wieder rauf kann. Wieso kann es denn nicht einmal ….

00.04 Uhr: Es ist klar, dass ich auch prompt eine neue RDP Sitzung beim Kunden erhalten habe. Typisch. Muss ich sie mir wieder heranziehen. Zum Gl?ck ist diese Option konfiguriert, ansonsten hätte ich jetzt ein Problem mehr.

00.11 Uhr:  Ein Balkon- und Toilettengang später ist der Kopierprozess jetzt bei knappen 58% angekommen. Das erinnert mich immer wieder an die typische Microsoft-Sekunde. Diese dauerte des Öfteren eine ganze Stunde. Wer mal Visual Studio .Net installiert hat (die erste Version), der weiß, was ich meine.

00.25 Uhr:  Sage und schreibe 62% sind bisher kopiert worden. Keinen Blassen, wieso das so lange dauert, da auf das Volume, wo die temporäre Datei liegt, keinerlei Zugriff anderweitig zu verzeichnen sind. Immer öfter kommt mir in den Sinn, was wohl der derzeitige Zustand wäre, wenn ich erst am Abend und nicht schon am Nachmittag damit angefangen hätte. Gut Ding will Weile haben, sagt der Volksmund, aber langsam bin ich der Meinung, dass der Server mal in die Puschen kommen sollte. Ich hab noch einen wichtigen Termin mit der Chaiseloung. Und diesen Termin verschiebe ich wirklich ungern … 

00.35 Uhr:  So mir nichts, dir nichts zaubert der Server knappe 90% aus dem Hut. Derartiges Verhalten muss und will ich nicht verstehen, da sich mir der Kontext nicht erschließt. Vielleicht sollte ich öfter mal nicht hinschauen. Vielleicht schämt sich ja der Server und wird rot und fängt an zu straucheln. Eigentlich ist es mir auch egal, solange das Teil endlich fertig wird.

00.47 Uhr: Wie sollte es auch anders sein. Wenn der Admin m?de ist, dann heißt das noch lange nicht, dass der Server auch pennen gehen kann. Nahezu Stillstand bei 92%. Ich merke schon die Äderchen in den Augäpfeln pulsieren.Nervöses Zucken? Ich? Niemals …

01.02 Uhr: Die Freude war eben groß, als er verk?ndete, dass er fertig ist. Ich vergaß, dass die Datenbank – der Store – aus 2 Dateien besteht: EDB- und STM-Datei. Nun werkelt er mal auf die „Schnelle“ an der STM. Wenn der Datendurchsatz der Gleiche ist, dann kann ich getrost schlafen gehen. Tief in die Mitte rein atmen und alle negativen Energien von sich absch?tteln … *aaarghh*

01.04 Uhr: Ich wollte mich wieder gerade freuen. Aber der Balken wanderte so schnell auf die 40% zu, dass dieser unweigerlich dort wieder stehen bleiben musste. Murphy ist halt immer anwesend …

01.22 Uhr: Kleckerhaft fließen Daten, aber der Balken bleibt immer noch bei 40% stehen. Und um 6.15 Uhr ist die Nacht zu Ende. Ich freu mich ein Loch in den Bauch.

01.31 Uhr: Entnervt lasse ich die Sitzung offen, habe Kollegen instruiert f?r morgen/heute fr?h und instruiere mich selbst zum Bett. Die Datenrate ist auf bescheidene 50KByte/s gefallen und somit d?rfte die 7GB Datei noch Jahre  brauchen, bis sie fertig ist. Wieso das so ist, das steht auf einem anderen Blatt – geklärt werden muss diese miese Performance allemal.

Gute Nacht!

Das könnte Dich auch interessieren...

1 Antwort

  1. 6. Januar 2009

    […] Erfahrungsbericht: Exchange Server 2003 Fehler Jan […]

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.