Network Failure

Manchmal hat man es echt nicht leicht, wenn das Netzwerk wieder kaputt ist. Eine dramatische Geschichte!

Der ganz normale IT-Wahnsinn

Zur Zeit geht auf der Arbeit IT-mäßig alles drunter und drüber. Nicht, dass letzte Woche eines morgens sogar einmal das komplette System still stand, erst nach langwieriger Datenprüfungen wieder lief und danach ziemlich viel Stress angesagt war. Nein, es kommen auch manchmal Fehler zutage, die ich nicht richtig nachvollziehen kann. Beispielsweise macht man ein Update von Office 2003 auf Office 2010 und übernimmt einfach mal einen IMAP Account. Natürlich möchte man nun auch seine gesendeten Mails im Gesendete Objekte Ordner nach dem Senden abgelegt haben. Also stellt man dies in den Kontoeinstellungen ein und sendet zum Test mal eine Mail. Was passiert? Nichts. Die Mail kommt zwar beim Empfänger an, aber wo ist die Kopie abgeblieben? Richtig, sie ist nicht mehr da…
Man ist ja nicht von gestern und löscht einfach mal das Konto, schließt Outlook, startet es wieder und richtet ein neues Konto ein.
Doch egal, was man einstellt und an welcher Schraube man dreht: Es ändert sich nichts an der Tatsache, dass keine Kopie einer versendeten Mail im Gesendeten Ordner abgelegt ist. Schließlich werden andere Clients, wie Thunderbird oder sogar auf einem anderen Rechner ausprobiert. Überall tut es und sogar mit Outlook 2010 auf einem anderen Rechner. *harhar*
Da der Rechner sowieso immer wieder einfriert, trotz neuer Hardware (i5 750 mit ordentlichem RAM und recht schneller Festplatte) wird eben ein neuer Rechner für den User eingerichtet. Sofort mal das IMAP Konto mit Outlook eingerichtet und getestet. Tut alles… ;) Solche Probleme nerven auf Dauer dann doch echt. Aber nun ist es ja gelöst, zumindest im Geschäft. Beim User daheim gibt es wahrscheinlich noch die gleichen Probleme. :)

Schon seit längerer Zeit beschweren sich die Nutzer, dass das Netzwerk manchmal extrem hängt. Man wundert sich schon seit Jahren darüber. Über die Jahre hinweg, hab ich einiges ausprobiert. Hintergrunddienste ausgemistet und zuletzt überall die Windowssearch aus dem Autostart ausgesteckt bzw. beim Server deaktiviert. Weiter dann noch alle Clients auf 100Mbit/s gedrosselt. Da wir dann einen neuen Mailserver bekommen haben, habe ich mal mal spaßeshalber die Geschwindigkeit des Server-RAIDs gemessen. *harhar* Von 130 Mbit/s Spitze mal abgesehen, war während des Tests die Geschwindigkeit meistens zwischen 1,2 Mbit/s und 15 Mbit/s. Und dann wundert sich noch einer, warum die User immer jammern, weil alles einfriert?!? :)
Die Ursache war dann aber recht schnell ausgedoktert. Schon seit jeher wurden aus Backup-Gründen die PST-Dateien von den Usern immer auf dem Netzlaufwerk ausgelagert. Wenn die User nicht immer E-Mails aufbewahren würden, wäre das auch nie ein großes Problem geworden. Nun ist es aber so, dass damals 10 Mitarbeiter mit Outlook gearbeitet haben und heute 20 Mitarbeiter am Schaffen sind und kaum einer seine E-Mails aussortiert. Kann man ja alles irgendwann noch gebrauchen! Mach ich privat ja auch so, da Googlemail ja ewig Speicher hat.
Doch dummerweise hat Microsoft die PST-Dateien nicht für Netzlaufwerke ausgelegt. Denn sobald eine neue Mail kommt, wird diese in die Datei geschrieben. Und sobald eine E-Mail gelöscht wird, bleibt diese aber weiterhin als Leiche in der PST-Datei. Außer man komprimiert die Datei hin und wieder mal. :)
Bei ein paar Clients, die gleichzeitig mit Outlook arbeiten kommen damit viele Lese und Schreibanforderungen auf den Server zu. Gleichzeitig läuft da drauf noch ein WaWi. Kein Wunder also, dass alles langsam ist. Der Server ist ansonsten nicht von schlechten Eltern. 2 XEON Prozessoren mit 2,8 GHz. 4 GB RAM mit ECC. Leider aber noch den langsamen mit 400 MHz oder sogar 333 MHz. Doch an und für sich reicht das noch locker aus, man muss nur mal die Mailgeschichte in den Griff bekommen.

Unsere Lösung ist nun IMAP. Damit ist zwar auch alles auf dem Server, aber jede E-Mail als einzelne Datei und vor allem auf einem anderen Server. Das hat natürlich auch für die iPhone User immense Vorteile. Man kann von unterwegs aus mal eben seine Mails checken oder auch schreiben. :)

So ziemlich parallel habe ich auch mal die ehrenwerte Aufgabe bekommen eine Lösung zur Synchronisation mit der COM-Schnittstelle zu programmieren. Über die COM-Schnittstelle habe ich mich ja schon Anfang des Jahres ausgekotzt und damals das durch fremde Hilfe und externe Programmaufrufe lösen können. Nun musste ich das aber selbst lösen. Durch ein paar Tipps in die richtige Richtung und mal genauerem Lesen der Dokumentation ist es mir dann doch leichter gefallen. Das war fast sogar schon leichter, als die ewige Fehlersuche bei dem Performanceproblem und dem blöden Outlook-Problem. Nebenbei bemerkt mag ich VB.NET nun richtig gerne. Klar sieht C# eleganter aus, doch wenn man mal keine ; schreiben muss, ist das doch auch toll. Performancetechnisch macht das heute ja eh kein Unterschied mehr. Mit den ganzen Sicherheitsroutinen und der großen Rechenleistung geht ja alles flott. Nur bei den COM-Aufrufen muss man sinnvoll programmieren, sonst dauert alles ewig. ;)

Genug gekotzt. Jetzt kommt endlich auch mal ein WLAN in unser Netz (natürlich Fremdnetz), damit unsere Besucher auch noch arbeiten können. Manche Kollegen freuen sich darüber auch. Denn WLAN ist doch um einiges schneller als das Handy-Internet.
Nebenbei habe ich endlich auch wieder Zeit gefunden um meine persönlichen Dokumentationen für die Aufgaben, die wiederkehren (Rechner installieren, Netzwerkkonfig, Excelformeln) zu pflegen. Irgendwie war das Ganze also auch sinnvoll. :) Meistens macht man sich ja nicht die Mühe die Doku zu pflegen und in ein paar Wochen, Monaten oder gar Jahren kommt dann große Erwachen und die ewige Sucherei: Wie ging das nochmal?

RFC gibt reservierte IPv4-Blöcke frei

Nachdem nun alle modernen Betriebssysteme mittlerweile IPv6 unterstützen, würde dem Wechsel zu IPv6 nicht mehr allzu viel im Wege stehen. Da so ein Umzug zeitkritisch und vor allem nie ohne Komplikationen abläufen würde, muss eben alles Stück um Stück geschehen: Die Hersteller müssen neue Router und Switche herausbringen bzw. Firmwareupdates schreiben. Ob alle alten Router das neue IPv6 von der CPU Last überhaupt unterstützen würde ist natürlich auch noch abzuwägen. Kurzum all diese Dinge werden Zeit und Geld kosten und manchen Admin vielleicht auch ein paar Nerven, da eben vieles neu ist und man sich erst einlesen und einarbeiten muss.
Vielleicht gibt gerade deshalb das neue RFC 5735 die einst reservierten IP Blöcke (14.0.0.0/8, 128.0.0.0/16, 191.255.0.0/16, 223.255.255.0./24, 24.0.0.0/8 und 39.0.0.0/8) frei. Schließlich gibt es immer mehr Menschen mit Internetzugang und immer mehr Endgeräte benötigen eine eigene IP-Adresse. Die regionalen Internet Registries (RIPs) können diese nun in gewohnter Weise vergeben.
Weiter berichtet Heise, dass laut Vorhersagen von Experten die IP Adressen nur noch rund 600 Tage ausreichen würde. Mitte September 2011 werden dann wohl ein paar Leute in die Röhre schauen. Doch bis dahin ist ja noch einige Zeit hin. Vielleicht erfinden die Provider dann ein NAT für ihre Endkunden. Quasi eine offizielle IP für 50 Kunden und diese Kunden bekommen für den Zugang zum Provider eine private IP-Adresse (z.B.: 192.168.0.0/24). Doch damit wird man dann vermutlich auch wieder mit Performanceeinbussen rechnen müssen.
Die sinnvollere Lösung wäre natürlich allen Kunden zwangsweise IPv6 zu verordnen. Eventuell schauen dann aber auch wieder ein paar Internetnutzer mit alter Routerhardware (ich besitze noch die gute alte Fritzbox 7050) in die Röhre und brauchen neue Hardware.
Mal sehen was kommt.