Showdown, zweiter Teil.

Der Showdown von gestern hat sich dann doch etwas überraschend gelöst – der Systemberater hat das Problem wohl erkannt, die zweite Domain, die im TRANSIT war, aus dem TRANSIT zu seinem Provider gezogen, gleich auf Anhieb korrekt konfiguriert und so lief das dann gestern Abend noch. Da hofft man doch, dass die Aha-Effekte, die da wohl gestern jemand gehabt haben muss, auch noch lange anhalten.

Zumindest die Strategie habe ich jetzt kennengelernt, die der Systemberater (und “Systemberater” schreibe ich nur aus Kulanzgründen) bei seinem Neukunden verfolgt: Er hostet ihn bei seinem Provider und verdient da vermutlich den ein oder anderen Euro, den er auf die Preise draufschlägt, die er als Partner bekommen wird.

Ein Scheißgeschäft und das sage ich als jemand, der bei einem ISP arbeitet. So Geld zu verdienen, ist zwar vermeintlich einfach, aber im Grunde genommen hat man als Partner nur wenig davon, wenn der Provider im Massengeschäft tätig ist, denn für so einen Discounter ist ein Partner, der nicht mindestens einen fünfstelligen Umsatz im Monat ins Haus bringt, nichts als eine Nummer von vielen. Die Argumente, dass nur die großen Provider zuverlässige Dienste hosten können, sind schon längst vorbei – ganz das Gegenteil ist der Fall: Gerade kleinere Provider bringen die notwendige Flexibilität mit, im Ernstfall auch Dinge zu bekommen, die personal- und zeitintensiv sind, beispielsweise der schnelle Zugang zur eigenen Hardware.

Das könnte man ja noch alles verschmerzen. Viel schlimmer ist aus meiner Sicht, dass solche Partnerprogramme mit Standardprodukten gerade kleine Hobby-Consultants dazu beflügeln, bei Kunden den größten Quark zu erzählen und technische Mittelmäßigkeit als State-of-the-art zu beschwören. Etwas zu verkaufen, weil es nicht gut ist, sondern billig, das ist keine Kunst, das macht jede Putzfrau so.

Um bei meinem Patienten zu bleiben: Er hat sich darüber aufgeregt, dass wir dem Kunden einst einen Exchange-Server aufgedrückt haben. Aus seiner Sicht völliger Overkill und viel zu teuer. Mit sowas kann man auch als bescheiden begabter Systemberater bei einfachen Kunden Eindruck schinden.

Dazu folgendes:

  1. Der Kunde hat keinen Exchange-Server bekommen, sondern einen Small-Business-Server, der auch einen Exchange-Server beinhaltet. Der SBS ist für kleine Unternehmen gedacht, im Vergleich auch viel günstiger, als ein einzelner Exchange und ideal für den Betrieb auf einem einzigen Server, für den er im übrigen auch nur lizenziert ist.
  2. Der Kunde hat mit einem Exchange-Server E-Mail und das dann auch richtig, nämlich direkt per SMTP. Wenn er jetzt noch eine Internet-Anbindung mit einer festen IP-Adresse hat, kann er seinen Server so betreiben, wie die SMTP-Architekten das einst mal erdacht hatten, nämlich direkt am Internet. Das hat Zeitvorteile, man ist unabhängig von hostenden Providern und muss das Mailarchiv nicht auf der Arbeitsstation sammeln, sondern kann das dem Server überlassen.
  3. Mit einem Exchange-Server hat der Kunde darüber hinaus noch die Möglichkeit, etwas zu nutzen, was man zugegebenermaßen verstehen und auch richtig verkaufen muss: Collaboration. Gemeinsame Kalender, zentral verwaltete Adressbücher, delegierbare Aufgaben, generische Postfächer. Das sind Dinge, auf die man selbst in einem Zweimannbetrieb nicht verzichten mag, wenn man mal in den Genuss solcher Annehmlichkeiten gekommen ist.

Nein, nicht so hier, der Exchange-Server kommt weg. Tatsächlich. Dabei ist er noch nicht mal kaputt oder besonders langsam, sondern er kommt einfach weg, weil der Systemberater die Losung verkündet hat, das sei Overkill.

Das ist alles so das Ergebnis der ständigen Kundenverdummbeutelung, die seit Jahren erfolgreich grassiert und auch Hobby-Consultants befallen hat – wir nehmen den Discountmist, den es bei den Discounthostern als Massenware gibt und verkaufen ihn als Innovation, der Rest, den es in der Welt gibt, ist dann halt einfach als Dreck zu verteufeln. Im einfachen Fall sind das dann eine Horde von Mailaccounts, die dann beim Provider liegen und in die sich dann jeder Mitarbeiter jeden Morgen von der Ferne aus einzuloggen hat und in grandiosen Spezialfällen so Kunstwerke wie Exchange-Server, die nicht per SMTP ihre Mails direkt bekommen, sondern alle paar Minuten per POP3 vom Provider ziehen müssen – und der Systemberater verkauft diese Katastrophe dann auch noch mit Sicherheitsaspekten. Ich nenne es Blödheit und kalkulierte Bevormundung des Kunden.

Um es in sehr einfachen und sehr deutlichen Worten zu sagen: Wer als Unternehmen keine eigene Maillösung nutzt, hat nicht begriffen, dass E-Mail und eine vernünftige Collaborationsoftware in erster Linie ein Produktivitätswerkzeug innerhalb eines Unternehmens sein kann und mitnichten viel Geld kosten muss, wenn man etwas länger als bis zum nächsten Monat denkt.

Aber da kannste dir gelegentlich sowas den Mund fusselig reden, da ist es manchmal besser, diskret wegzuhören, wenn man das Geseier hört, mit dem ein Wettbewerber das goldene Los gezogen hat.

Exchange 2003: Ausgehende Warteschlangen löschen

Am Freitag gab es wieder einen Klassiker im Support, der nicht ganz so oft vorkommt, dafür jedoch Nerven kostet und Zeit raubt. Und da ich zum wiederholten Male mir den Weg mangels Dokumentation mühsam suchen musste, dokumentiere ich mal hier.

Problem: Ein Mitarbeiter sendet einen Newsletter an eine ganze Reihe von Empfängern und hängt fatalerweise einen größeren Anhang an. Dass sich das alles fatal addiert, machen wir mal an einer kleinen Beispielrechnung auf. Gegeben seien 300 Empfänger, an die ein 9 Megabyte großer Anhang versendet wird. Mit gängiger Kodierung vergrößert sich im Versand zuerst einmal ein zu versendender Anhang um rund ein Drittel, so dass wir schon mal bei 12 Megabyte Datenmenge pro Mail sind. Das dann mal 300 und wir sind netto bei etwa 3,6 Gigabyte. Damit ist eine mittlere Anbindung schon mal gut beschäftigt, wenn der hauseigene Mailserver loslegt.

Der Begriff „netto“ hat aber eine entscheidende Fußfalle: Viele empfangende Mailserver bocken bei größeren Anhängen oder deklarieren eine Nachricht gleich als Spam. Mit dem Ergebnis, dass man in der Gewichtsklasse damit rechnen kann, dass etwa nur zwei Drittel dieser Brummer sofort durchgehen und der absendende Mailserver mit dem letzten Drittel noch richtig schön lange zu tun hat und ständige Neuversuche unternimmt.

Das kann man als Sysadmin aussitzen, sollte man aber nicht, denn wenn bei einer Anbindung der Upstream ins Internet für Stunden lahmgelegt wird, zeichnen sich dank TCP auch beim Downstream unweigerlich Probleme. Sprich: Man muss den Exchange bremsen und die Warteschlange mit den ausgehenden Mails löschen.

In der fast schon vorzeitlichen Exchange-Welt gab es für solche Ernstfälle einen verglasten Notschalter: Exchange-Dienste beenden und in einem Exchange-Verzeichnis, in dem die Warteschlange in Form von einzelnen Mails und Dateien lag, den Inhalt leeren. Exchange-Dienste wieder hoch und Ruhe war.

Mit neueren Exchange-Versionen funktioniert das so nicht mehr, da auch die Mailqueues aus Gründen der Performance als Datenbank vorliegen. Man muss also im laufenden Betrieb die Warteschlange leeren. Und das wird spätestens dann zu einem Problem, wenn man remote auf den Exchange muss, eben aber dank der Versendungsaktion keine Bandbreite mehr vorhanden ist.

Lösung: Den SMTP-Dienst auf dem Exchange-Server nicht beenden, sondern bei einer vor dem Exchange-Server liegenden Firewall oder einem Router den Standart-TCP-Port 25 temporär ein- und ausgehend blockieren.

Dann gibt es zwar so lange keine neuen E-Mails, dafür kann man aber nun in Ruhe auch remote an die Ursachen gehen und die Warteschlangen leeren. Und das ist gerade bei den älteren Exchange-Versionen 2000 und 2003 leider durchaus langwierig und zeitraubend, da hier die Warteschlangen nach Zieldomains sortiert sind und man bei jeder einzelnen Zieldomain zunächst wartende Nachrichten suchen und dann löschen muss. Bei 100 wartenden Mails darf man für diesen Praktikantenjob gern mal eine Arbeitsstunde einkalkulieren.

Beim Exchange 2007 hat man bei Microsoft übrigens das Problem erkannt und unter anderem einen erheblich schnelleren Zugriff auf die Warteschlangen eingebaut.