blog@netplanet > SupportWelt

| Abonnieren via RSS

Kabel BW – und draußen bist du.

4. November 2014 | 1 Kommentar | Veröffentlicht in SupportWelt

Ich kann ja inzwischen auf 16 Jahre IT-Support zurückblicken und mit gutem Gewissen sagen, dass mich in Sachen IT-Probleme und -Leidensberichten so schnell nichts mehr umhaut. Technik versagt, Menschen versagen auch und in dieser Kombination kommt selten etwas gutes dabei heraus, wenn sich nicht einer hinstellt und das Problem in die Hand nimmt. Man glaubt es mitunter kaum, wie wenig Menschen es gibt, die letzteres dann auch tatsächlich mal tun.

Zur Zeit kann ich sehr anschaulich beobachten, wie es sich der Kabelnetzprovider Kabel BW bei einem Kunden von mir verscherzt. Business-Kunde, Internet&Telefon-Flat mit 100 Mbit/s Bandbreite für schlappe 80 Euro im Monat. Also kein Billighosting, sondern richtig etwas bezahlt dafür. Ich habe zwar das alles nicht empfohlen und das nicht erst nach der folgenden Odyssee, aber nun ist es einmal so. Der Zugang wurde beantragt und damit beginnt die Geschichte.

Aller Anfang ist gut.

Kurzum: Den Bestellvorgang kann Kabel BW und es wäre eine sehr kurze Geschichte hier geworden, wenn Kabel BW es nicht perfektioniert hätte, den an sich komplexen Vorgang von Internet über das Kabelnetz soweit zu optimieren und zu verpacken, dass es einigermaßen industriell aussieht. Das beginnt damit, dass die TV-Verkabelung aus den 1980er Jahren stammt. Da wurde zwar einst das beste Kabel von der damaligen Deutschen Bundespost – klar, alles steuerfinanziert – verbuddelt, aber die grundlegende Netzstruktur bei Kabelnetzen ist vornehmlich für das einseitige Verbreiten von Fernsehsignalen gedacht gewesen und deshalb endet das Kabel am Kabelverteiler im Keller.

Immerhin: Kabel BW schickt zur erstmaligen Installation einen Techniker, der von dort ein Kabel bis zum gewünschten Aufstellraum des Routers legt und auch anschließt. Meist sogar Kabel der richtigen Sorte und meist wird auch fachmännisch angeschlossen, was nicht unbedingt normal ist, denn der Außendienstler war ein Subunternehmer eines Unternehmens, der für Kabel BW tätig ist.

Großes Handicap: Kabel BW bringt seinen eigenen Router mit, es herrscht Routerzwang. Das ist in diesem Fall eine kastrierte und auf Kabel BW gebrandete Fritzbox 6490, die einen Teil der Konfiguration von Kabel BW erhält – und nur von dort. Die Netzeinstellungen und auch die Einstellungen für die VoIP-Rufnummern sind vom Endnutzer nicht konfigurierbar. Für mich persönlich ein No-Go, denn entweder gehört der Router mir oder meinem ISP und wenn letzteres der Fall ist, kann der Router überall steht, nur nicht bei mir.

Aber okay, meinen Kunden stört das nicht und Kabel BW durfte alles schön aufbauen und es funktionierte sogar alles erst einmal.

Die Probleme.

Funktionieren tat es allerdings nur ein paar Tage zufriedenstellend, dann gab es die ersten schwerwiegenden Probleme. Und die sahen so aus, dass die Fritzbox offenbar irgendwann die Verbindung verlor, durchstartete und danach jungfreulich dastand. Die Box kam danach zwar wieder ins Internet, alles andere war aber vergessen … lokale Netzeinstellungen, DHCP-Serving, DECT-Einstellungen, Telefonbuch. Das ist ziemlich unschön, weil es einen Vor-Ort-Einsatz von mir erforderlich machte. Einmal. Und auch ein zweites Mal.

Beim dritten Mal hatte ich die Nase voll und bat den Kunden, sich doch bitteschön mal mit Kabel BW in Verbindung zu setzen zwecks Analyse der Problematik. Auf fremde Router kann ich nicht schauen und bitteschön… ich repariere nicht Router fremder Leute, die dafür auch noch Geld verlangen.

Die Inkompetenzen beim Telefonsupport.

Telefonsupport ist so eine Sache. Macht keinem Spaß, dem Kunden nicht und dem Dienstleister und seinem Subunternehmer auch nicht. Telefonsupport ist Quälerei. Aber es geht nun mal nicht ohne. Immerhin müssen Business-Kunden nicht in die richtig üblen DDR-Intershop-wir-haben-heute-Bananen-Warteschleifen, sondern haben eine eigene “Business-Hotline”, bei der die Wartezeit auf schmale 5 Minuten beschränkt ist. Zwar wird man auch da gern mal genau da abgeworfen, wenn das Freizeichen des nächsten, extra für mich reservierten Mitarbeiters ertönt, aber nach 10 Minuten hatten wir tatsächlich einen Menschen am Telefon.

Der auch vieles tun wollte. Er wollte die Leitung messen, er wollte Probleme sehen, er wollte die “zuständige Fachabteilung” informieren und einen Techniker rausschicken und hatte das dann wohl bedauerlich nach dem Anruf verschwitzt, denn der versprochene Rückruf erfolgte nicht. Ein zweiter Anruf meines Kunden zwei Tage später war dann schon nicht mehr so lustig, was auch die Supportdrohne erkannte und umgehend für einen Techniker sorgen wollte. Das war Freitagmorgen und der Techniker kam dann auch schon am Montagmittag, nachdem wir am Montagmorgen nochmal an der Hotline daran erinnern mussten.

Der Techniker und das mit dem Halbwissen.

Der Techniker war dann wieder ein Subunternehmer der, sagen wir es freundlich, bescheidenen Wissensklasse. Von Netzwerktechnik verstand er so viel, dass er irgendein Gerät an die Leitung anschloss und befand, dass der Leitungsdurchmesser zu klein sei und der Kabelwiderstand zu hoch. Wohlgemerkt, die Leitung, die vor einigen Wochen von einem Kollegen von ihm verlegt wurde. Gut, soll alles nicht mein Problem sein, ist ja sein Kabel und er tauschte das alles dann auch brav aus.

Und weil er offenbar auch nicht so recht seinen Worten glauben mochte, tauschte er auch gleich noch die Fritzbox aus. Allerdings ohne einen Export der Konfiguration, so dass nach seinem Besuch erst einmal nichts funktionierte. Was auch seiner Aussage nach so sein müsse, denn Kabel BW schicke einige Stunden danach die Netzkonfiguration auf das Gerät.

Das ist natürlich alles nur so halbhalb richtig, denn tatsächlich schickt Kabel BW nur die reine Netzkonfiguration und die Telefoneinstellungen auf den neuen Router. Und das natürlich auch erst dann, wenn der neue Router in der Kabel-BW-Technik als Router eingetragen wird, was der Techniker offenkundig vergaß. Sprich: Hätten wir am nächsten Tag nicht die Kabel-BW-Hotline angerufen und hätte der dortige Supporter nach der Durchsage der MAC-Adresse der neuen Box mal in seinen Computer hineingeschaut, hätten wir vermutlich bis an das Ende aller Tage darauf warten können, je wieder Internet über diesen Anschluss zu bekommen. Ich gab dem Herrn also die MAC-Adresse der Fritzbox durch, die er sich von mir von der Rückseite der Fritzbox hat vorlesen lassen.

Alles klar, so der Hotliner dieses Mal, er sehe jetzt auch die neue Box und könne nun die neue Konfiguration von der “zuständigen Fachabteilung” aufdrücken lassen. Einige Stunden könne das aber dauern.

Geht es? Oder geht es nicht?

Kurzum: Auch nach einigen Stunden ging der Internet-Zugang nicht. Zwar bekam die dumme Box in der Zwischenzeit eine IP-Adresse, Subnetzmaske und DNS-Server, allerdings lässt Kabel BW einen nicht vom eigenen System authentifizierten Router nicht ins Internet. Nanu, sagst du dir vielleicht, der Hotliner hatte doch im letzten Gespräch gesagt, dass es nun dann gehen müsse?

Ja, eigentlich schon. Wenn der Hotliner seine Hausaufgaben richtig gemacht hätte. Denn die MAC-Adresse, die auf der Rückseite der Fritzbox steht, ist nicht die MAC-Adresse, die Kabel BW zur Authentifizierung ihrer Fritzboxen verwendet. Die muss dazu umgerechnet werden und das geht im Support-Tool von Kabel BW. Hat aber der Kollege Hotliner wohl nicht getan und damit die falsche MAC-Adresse im System hinterlegt. Kabel BW wartet also auf eine MAC-Adresse zur Authentifizierung, die allerdings nicht kommen wird, wenn ich morgen nicht da nochmal anrufe und dem Mitarbeiter mitteile, dass er doch bitte mal die gestern von seinem Kollegen abgefragte MAC-Adresse einmal überprüft und korrigiert. VLAN-Tagging geht halt nicht gut aus, wenn man MAC-Adressen nicht wirklich akribisch kontrolliert.

Der gemeine Kunde wäre spätestens hier völlig ahnungslos ausgeliefert, würde vielleicht wieder einen Techniker kommen lassen, vielleicht würde wieder die Superkompetenz in Person anwackeln, wieder die Fritzbox austauschen, wieder die neue Box nicht registrieren lassen …. etc. etc. etc. Vielleicht tue ich dem lokalen Außendiensttechniker ja wirklich Unrecht und ich entschuldige mich auch vorsorglich dafür, dass ich ihn eigentlich für nichts tauglich halte, für rein gar nichts. Tischkick-Amateur herumirrend in der Champions League. VfB-Fan.

WTF?

Ich weiß nicht, was ich hier empfehlen würde. Ich weiß nur: Ich traue weiterhin keinem ISP, der mir einen Router aufzwingt und bei dem ich nicht zu 100 % alles selbst eintragen kann und bei dem ich auch nicht weiß, ob er sich an Authentifizierungsstandards hält oder nicht. Es ist nicht nur so, dass der ISP bei Routerzwang kaum Lösungen für Vorfälle kennt, die eben durchs Raster fallen, sondern es ist auch so, dass es in so einem Kunden-ISP-Beziehungsumfeld unglaublich kompliziert ist, neutralen IT-Service zu geben. Wenn ich all meine Analyse- und Lösungsversuche meinem Kunden in Rechnung stellen würde, die ich jetzt betreiben musste, wäre sein Internet-Zugang für die nächsten 12 Monate nicht bei 70 Euro, sondern mindestens beim Doppelten. Ohne externen IT-Service ist so ein, pardon, Internet-Murks aber gar nicht zu bewältigen.

Ach, Google, wann kommst du endlich mit Google Fiber nach Deutschland?

Tags: , , , , ,

Variationen des Bootens.

5. März 2010 | Keine Kommentare | Veröffentlicht in SupportWelt

Zum Freitag mal wieder etwas kleingeistig anmutende Berufsphilosophie. Wie heißt der Vorgang eigentlich richtig, den wir als den beschreiben, wenn der Rechner gebootet werden muss?

“Soll ich den Rechner mal durchbooten?”

Der Begriff “durchbooten” ist nahe dran, aber eigentlich eine waschechte Tautologie. Das Präfix “durch” will sagen, das etwas “gänzlich” oder “vollständig” durchgeführt werden soll, “booten” kann man aber eben nur gänzlich bzw. vollständig. “Etwas booten” gibt es nicht. Wie auch immer, der Begriff “durchbooten” hört sich so nach “durchbum…” an, ich muss da deshalb immer etwas lächeln, wenn diese Sprachwahl beispielsweise eine Sekretärin anschlägt. Ja, ist chauvinistisch, ich weiß. ;-)

Soll ich den Rechner mal durchstarten?”

Hört sich sauberer an, als “durchbooten”, aber ist eigentlich verkehrt, denn wer sein Betriebssystem mit der Option “neu starten” beendet, startet ja eigentlich nicht seinen Rechner neu, sondern das Betriebssystem. Käme man jetzt mit der Begrifflichkeit “Kaltstart” und “Warmstart”, wäre man mit dieser Formulierung schon wieder im Reich der Missverständlichkeiten.

Soll ich den Rechner mal resetten?”

Das finde ich auch immer wieder spannend: Resetten. Unter einem Rechner-Reset verstehe ich eigentlich den Pieks mit einem Kugelschreiber oder einer Büroklammer auf ein meist extrem kleines Löchlein, das dazu führt, dass die Betriebssystemsitzung “herunterfällt”. Und lacht nur über den Reset-Knopf, den gibt es häufiger, als man denkt, praktisch jedes Notebook hat einen solchen – er ist meist nur nicht dokumentiert. Wenn also ein Kunde seinen Rechner “resetten” will, zucke ich meist leicht und frage nochmal nach.

Soll ich den Rechner mal booten?”

Da sind wir beim richtigen Wording. Gebootet wird nicht das Betriebssystem, sondern tatsächlich der Rechner. Das Betriebssystem wird “neu gestartet”, den so genannten Bootstrap auslesen und ausführen tut aber der Rechner noch weit vor dem Starten des Betriebssystems.

Tags: ,

So beschriften die Profis.

6. Februar 2010 | 3 Kommentare | Veröffentlicht in SupportWelt

Wenn man gar nichts anderes mehr zu beschriften hat, geht zur Not auch zwei Zentimeter breites Beschriftungsband. Das Ergebnis ist auch gleich viel übersichtlicher. Vor allem, wenn man aus dem Typografieangebot dann wirklich aus dem Vollen schöpfen kann:

Tags: ,

Von schwankenden Netzwerken.

4. Februar 2010 | 3 Kommentare | Veröffentlicht in SupportWelt

Eine E-Mail eines Kunden verbreitete kürzlich ungeahnte Heiterkeit im Büro. Da fragte der Kunde, der ein umfangreiches Unternehmensnetzwerk mit vielen Filialen betreibt und am Hauptstandort eine Außenanbindung mit mehreren unabhängigen Upstream-Anbindungen zu verschiedenen Providern pflegt, was eine bestimmte BGP4-Konfiguration auf seinem zentralen Router bedeutet. Nämlich “neighbor x.x.x.x weight 100”.

Bei sowas schrillt der Alarm, denn am externen Routing herumzubasteln, gerade wenn man BGP4 zwecks mehreren Provider-Anbindungen einsetzt, ist das unqualifizierte Schrauben an solchen Einstellungen äquivalent zu Analogien, bei denen man während einem Flug von Frankfurt nach New York einfach mal die Cockpit-Steueranzeigen umkonfigurieren möchte.

Offensichtlich, so die Mail, passierte ähnliches. Der mutige Mitarbeiter entfernte einfach mal die betreffende Zeile in der Konfiguration einer Provider-Anbindung, was dazu führte, dass der nach außen gerichtete Datenverkehr plötzlich “flappte”, mal ging es zum einen Provider hinaus, mal zum anderen. Das Internet geriet (sinnbildlich) in Schieflage, Anbindungen zu anderen Unternehmen und Außenstellen brachen ab und das endete alles erst, als man die Zeile wieder hinzufügte. Ja, sowas hebt die Spannung in einer EDV-Abteilung ungemein. Ein Angriff der Klingonen, die mit romulanischen Tarnvorrichtungen bis direkt vor die Enterprise geflogen sind, ist vermutlich nichts dagegen.

”neighbor xxx weight 100” ist, um es jetzt mal sehr vereinfacht zu erklären, ein IOS-Befehl, der zur Gewichtung benutzt wird, welchen Upstream man eher benutzen möchte, als einen anderen. Das dient hauptsächlich dazu, um bei mehreren vorhandenen Anbindungen eine so weit für bestimmte Zieladressen (oder auch für alle) zu bevorzugen, bis diese eine Schwelle der Funktionalität unterschreitet, bevor der Router dann eine andere Anbindung nimmt.

Das besondere an diesem Befehl ist aber, dass die Gewichtung nur auf dem Router selbst passiert und nicht an andere Teilnehmer im Routing weitergegeben wird. Hat also ein Router mit der Gewichtung ein Problem, so nutzt das Netzwerk eben diesen Router nicht. Diese Gewichtung granuliert man sich deshalb äußerst fein auf die vorhandenen Anbindungen und bewertet das dann auch regelmäßig, um gegebenenfalls Gewichtungen anzupassen, denn im Normalfall muss das alles im laufenden Betrieb passieren.

Wenn plötzlich mehrere Anbindungen gleich für die gleichen Zieladressen bevorzugt werden sollen, so mag das vielleicht basisdemokratisch aussehen, führt aber zu katastrophalen Ergebnissen. Das hat unser Kunde jetzt verstanden. Ich gebe zu, ich habe das einst auch so gelernt. ;-)

Tags: , , , ,

Wie ich am schnellsten einen SQL-Server ruiniere.

26. Januar 2010 | 3 Kommentare | Veröffentlicht in SupportWelt

Würde mich jemand fragen (was natürlich niemand tut, sondern selbst ausprobiert), wie man am schnellsten und effektivsten einen SQL-Server so richtig in Schwierigkeiten reinreiten möchte, dann würde ich das so machen:

  1. Eine völlig blöde Konfiguration voraussetzen, beispielsweise alles auf einer Festplatte und alles auf einer Partition: Betriebssystem, SQL-Server-Software, Datenbankdateien, Protokolldateien. Das macht so richtig Spaß, denn wenn ein Teil dieser vier Komponenten heftig zu tun hat, dann hält es einfach alle anderen mit auf. Und wenn die Platte stirbt, wechselt dann auch einfach gleich alles das Ufer des Rubikon.
  2. Server beschäftigen und zwar in ganz großem Stil. Das macht man auf Datenbankservern gern mit “Optimierungsprogrammen” wie Defragmentieren oder Virenscannern und lässt die dann auf Datenbank- und Protokolldateien los.
    1. Der Virenscanner wird sich redlich bemühen, gigantisch Arbeitsspeicher fressen, die Festplatte polieren und in der Regel nie etwas finden können. Denn selten liegen die Muster, nach denen ein Virenscanner sucht, genau so in einer Datenbankdatei – eine Datenbankdatei ist immer fragmentiert, hat ein eigenes Speicherformat und ist gesperrt. Besonders clevere Virenscanner setzen sich über die Sperrung hinweg und nudeln den Server auf diese Weise sehr effizient in die 386er-Klasse herunter.
    2. Der Defragmentierer wird loslegen und Teile zusammenpuzzeln wollen, die allerdings ständig in Bewegung sind. Datenbankdateien wird jeder vernünftige Defragmentierer nicht anfassen wollen, wenn sie gesperrt sind, aber an den Protokolldateien kann er sich austoben. Dabei sind Protokolldateien noch viel stärker im Fluss, denn in der Regel werden Protokolldateien von einer Datensicherung bis zum Sicherungspunkt eh wieder gelöscht oder es existiert auf einem SQL-Server, der nicht datengesichert wird (brutaler Fehler) eine Umlaufprotokollierung (noch brutalerer Fehler), d.h. ältere Protokolldateien werden gelöscht, wenn neue angelegt werden. Und wenn dann noch Mist passiert und Protokolldateien beschädigt werden, verbaut man sich damit den allerletzten Notnagel, denn Protokolldateien sind eigentlich dazu da, Operationen auf den Datenbankdateien zu protokollieren. Ohne Protokolldatei ist eine defekte Datenbankdatei nicht mehr wiederherstellbar.
    3. Datensicherungen tagsüber laufen lassen, richtig schön bei Spitzenzeiten. Dann hat auch gleich jeder etwas davon.
  3. SQL-Server-Dienste abschießen (“Mann, der SQL-Server hängt aber!”) oder auch einfach den Server hart aus- und einschalten (“Mann, ist die Kiste lahm”). Gern mehrfach. Ja, das Herunterfahren eines Servers, auf dem Datenbankdienste laufen, kann manchmal sehr lange dauern. Das liegt vor allem daran, dass eine gut konfigurierte Datenbank Inhalte nicht sofort in ihre Datenbankdateien kratzt, sondern im Arbeitsspeicher vorhält. Will ein Dienst beendet oder ein Server neu gestartet werden, müssen diese Inhalte möglichst logisch auf in die Datenbankdateien und das dauert. Wer hier abschießt, der wird büßen. Im günstigsten Fall rattert beim nächsten Start der SQL-Server eine ganze Weile, weil die Datenbankdateien “dirty” geschlossen wurden, im ungünstigsten Fall erleidet man Datenverlust, weil nicht fertiggeschrieben werden konnte.
  4. Keine Datensicherung haben. Mir kann niemand erzählen, ihm wären die Daten in einer Datenbank nicht so wichtig genug, als dass man sie sichern müsste. Wären sie unnötig, hätte man keine Datenbank, fertig. Und hat man eine Datenbank, hat man sie zu sichern. Dabei genügt es nicht, einfach die Dateien zu sichern, denn ein Datenbank-Server läuft in der Regel ständig und hat, wie bereits geschrieben, gerade die Datenbankdateien exklusiv geöffnet, lässt diese also auch nicht einfach “flach” sichern. Es braucht also entweder eine (ziemlich peinliche) Notlösung, während der Sicherung den Datenbankdienst vorübergehend zu stoppen oder es braucht eine intelligentere Datensicherungslösung, die die Datenbank auf Transaktionsebene sichert. In der Regel nicht trivial, allerdings eine Lebensversicherung. Und selbstverständlich sichert man nicht gerade dann, wenn am meisten los ist und die Datenbank auch schon ohne Datensicherung unter Druck steht, sondern verschiebt das auf eher ruhige Tageszeiten. Und ja, man testet auch gelegentlich mal, ob die Datensicherung überhaupt sichert.
Tags: , , ,

Showdown, zweiter Teil.

4. November 2009 | 8 Kommentare | Veröffentlicht in SupportWelt

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.

Tags: , , ,

Showdown.

3. November 2009 | 8 Kommentare | Veröffentlicht in SupportWelt

Wenn man so ein paar Jahre im Internet-Business unterwegs ist, lernt man ein paar Dinge. Dazu gehören zwei sehr wichtige Punkte:

  1. Lies dir den Dreck an, mit dem du arbeiten willst.
  2. Pöbele bei technischen Problemen nicht einfach andere Leute an, wenn du dir nicht sicher bist, ob der Mist, der da vor sich hingärt, nicht von dir stammt.

Unter echten Sysadmins – die erkennt man vor allem durch ihre schwarze Kleidung, dem Benutzen von mindestens zwei Mobiltelefonen und einem eingängigen RIPE-Handle – ist das ehernes Gesetz. Selbst wenn man in einem Worst-Case-Szenario die größten Netzwerkprobleme ins Internet herausbläst, meinetwegen falsche Routen per BGP4 ins Internet propagiert oder einen guten, alten Spam-Angriff hostet – niemand schnauzt dich grundlos an, bevor er nicht in klarer Sprache mit dir geredet hat. Im Internet-Business kann man mit nur sehr wenigen Handgriffen so viel falsch machen, da geht man mit den Leuten, die versuchen, das tägliche Chaos in den eigenen Netzen zu bewältigen, mit einer gewissen Portion Respekt um.

Nicht echte Sysadmins, ich nenne sie der Einfachheit halber einfach “Blender”, kennen das alles nicht. Sie haben entweder das Internet nicht verstanden, halten sich nicht an die zwei obigen Punkte oder haben aus dem Grabbelsack, aus dem man als junger Mensch den passenden Beruf zieht, den falschen gezogen. Kommt vor, ich habe bis zu einem gewissen Grad sogar Mitleid damit.

Nicht so bei unserem aktuellen Patienten. Der ist wohl so eine Art Systemberater. Da gibt es auch solche und solche, einige machen einen guten Job für ihr Geld, andere nicht. Der da macht keinen guten Job und lässt uns alle daran teilhaben.

Zuerst hat er uns einen Kunden abgeschwatzt. Damit können wir leben, der Grundsatz im Business lautet: “Kunden kommen – Kunden gehen.” Dieser Kunde will gehen. Es wird ordentlich gekündigt, wir versuchen noch die Gründe zu hinterfragen, es kommen keine wirklich tollen, aber ab einem gewissen Grad hat man das eben zu akzeptieren.

Kunde besitzt zwei Domains, von denen der Systemberater allerdings nur eine kennt. Die ihm bekannte Domain wird ordentlich gekündigt und die übernimmt der Systemprovider auch über seinen Provider. Die andere Domain wird vergessen. Kündigungszeitpunkt kommt und wir machen das, was man mit vergessenen DE-Domains zu machen hat: TRANSIT. Wir löschen also so eine Domain nicht, sondern geben sie dem DENIC zurück, das wiederum den Domainbesitzer kontaktieren wird. Wir tun also das, was von uns gefordert wird, wenn der Kunde schläft und dessen EDV-Mensch ebenso.

Nun gibt es ein Problem: Diese vergessene Domain zeigte auf einen Webserver und die übernommene Domain zeigte wiederum auf die vergessene Domain. Die vergessene Domain führt bei einem Aufruf in einem Webbrowser zur TRANSIT-Informationsseite des DENIC und damit jetzt eben auch die übernommene Domain. Das ist natürlich blöd. Allerdings auch nicht unser Problem, denn man müsste einfach mal den Kopf einschalten und seine Nameserver-Konfiguration im Griff haben. Hat er aber nicht. Seit Tagen nicht. Er ist nun der Meinung, dass wir die Domain, die er bei uns abgeholt hat, nicht an seinen Provider gegeben haben, sondern an das DENIC. Was technisch gar nicht geht, denn die Zustimmung zu einer Domainübernahme kann man nur an den Provider geben, von dem auch die Domainübernahme gestartet wurde. Könnte man begreifen, wenn man sich das in Ruhe mal anschaut, was man da so fabriziert.

Der Höhepunkt der Scharmützel dann heute: Ein Anruf. Damit wollte es uns der Systemberater sicherlich mal so richtig zeigen. Er landete bei mir. Hätte er sachlich gefragt, hätte ich ihm auf den richtigen Trichter gebracht. So wurde es allerdings dann doch nichts:

Besim: “Karadeniz. Guten Tag.”

Systemberater: “Was ist denn das jetzt für eine Blutgrätsche, die ihr am <Kundenname> ausübt?”

Besim: “Okay, wenn Sie mir schon mit so Begrifflichkeiten wie ‘Blutgrätsche’ kommen würde ich vorschlagen, dass Sie sich zuerst einmal darüber kundig machen, wie die Technik funktioniert, mit der Sie arbeiten.”

Systemberater: (überzeichnend) “Okay, dann wünsche ich Ihnen noch einen schönen Tag!”

-klick-

Was jetzt passiert, ist jahrelange Erfahrung, die man mit Blendern sammelt. Er wird frohlockend zu seinem Kunden springen, auf uns ach so böse Leute schimpfen und den Kunden aufstacheln. Wir sind sehr gespannt.

Tags: , , ,

Exchange 2003: Ausgehende Warteschlangen löschen

16. August 2009 | Keine Kommentare | Veröffentlicht in SupportWelt

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.

Tags: , , ,

Internet kaputt.

18. Februar 2009 | Keine Kommentare | Veröffentlicht in SupportWelt

Gerade von einer meiner Gernekunden (nämlich genau bei dem im Artikel gemeinten Gernekunden) habe ich in den letzten Tagen vermehrte Anrufe bekommen, dass der Internet-Zugang bei ihnen Spacken machen würde. Jeden Morgen würde der Zugang erst einmal nicht funktionieren und man müsse erst einmal den DSL-Router neu starten, denn erst danach würde es funktionieren – bis zum nächsten Morgen.

Nun sagt der Admin-Bauch, dass das entweder ein kneifender T-DSL-Anschluss ist oder der DSL-Router kränkelt. Den T-DSL-Anschluss habe ich dann durch die Telekom prüfen und zurücksetzen lassen, was die Symptome nicht verschwinden ließ. Blieb also nur der DSL-Router, den ich dann heute eigentlich austauschen wollte. Mich störte nämlich grundsätzlich auch der Umstand, dass die Administrationsseite des DSL-Routers über die feste IP-Adresse, die der Internet-Zugang hat, nicht erreichbar ist.

Bis ich mal heute spaßeshalber auf die Idee bekommen bin, nicht HTTP auf Port 80 zu nutzen, sondern HTTPS auf Port 443. Und siehe da, es kam etwas zurück. Nur nicht die Administrationsseite des DSL-Routers, sondern die Administrationsseite eines NAS, eines Network Attached Storage. Das wäre schon kurios genug, wenn es nicht den Umstand gäbe, dass der Kunde gar keine NAS bei sich zu Hause stehen hat.

In der Tat ist es nämlich so, dass die vergebene IP-Adresse, die ich bei der Anmeldung des ADSL-Zuganges erhalten habe, gar nicht mit dem ADSL-Zugang verknüpft ist und der Zugang bei jeder neuen Einwahl – nämlich alle 24 Stunden – mangels zugeteilter IP-Adresse vom Einwahlrouter gar keine nach außen rout-fähige IP-Adresse erhält. Damit funktioniert nach erfolgter Neueinwahl zwar der Internet-Zugriff in Richtung Internet, von außen ist der Router und das Kundennetz jedoch nicht zu erreichen. Und die ursprünglich vergebene IP-Adresse gehört einem ganz anderen Kunden. Auf solch spannenden Probleme muss man erst einmal kommen.

Die Lösung wiederum ist dann unspektakulär einfach – man suche eine wirklich freie IP-Adresse aus dem für die DSL-Zugänge reservierten Adresspool heraus, editiere den Datensatz, der per RADIUS bei der PPPoE-Anfrage herausgegeben wird und schon gibt es bei der nächsten Einwahl, die durch einen simplen Neustart des DSL-Routers provoziert wird, eine gültige und auch rout-fähige IP-Adresse.

Bei so einem Problem hat der ursprüngliche Hilferuf, dass das Internet kaputt sei, ausnahmsweise eine richtige Berechtigung gehabt. Es war hier wirklich kaputt.

Tags: , , , ,

Warum ein Ticketsystem auch viel kaputtmachen kann.

22. Dezember 2008 | 5 Kommentare | Veröffentlicht in SupportWelt

Im Customer Support geht eigentlich – von speziellen Ausnahmen abgesehen – nichts ohne ein Ticketsystem, also einem Verwaltungsmechanismus, in das Problemmeldungen eines Kunden eingegeben werden, diese dann einen Vorfall erzeugen, dieser Vorfall automatisch oder manuell an die Mitarbeiterschaft delegiert und so erledigt werden. Ohne Ticketsystem ist es in komplexen und beratungsintensiven Umfeldern kaum mehr möglich, sinnvoll und zeitnah Kundenservice anzubieten, weil sich selten ein Kundendienstfall gleicht. Und gleichzeitig kann so ein Ticketsystem eine exzellente Basis für eine Kundendokumentation und für eine Support-Datenbank werden.

Die Kunst bei der Benutzung eines Ticketsystems ist die, dass der Anwender nicht das Gefühl bekommt, dass sein Problem ein Ticket ist. Und genau da knallt es, denn hier prallen Welten aufeinander: Kunde hat ein individuelles Problem, Support nimmt den Fall auf und antwortet mit einer Ticketnummer, die sich der Kunde doch bitteschön unbedingt notieren soll, weil das nun die Kennung seines Problems ist. Während also das individuelle Kundenproblem nun (hoffentlich) intern beim Dienstleister eskaliert und blüht, ist die Sichtbarkeit des Problems beim Kunden zu einer Nummer degradiert und schon einmal im negativen Licht.

Bei systematisch denkenden Menschen, wie wir EDV-Leute das sind, ist das eigentlich eine tolle Sache, denn ich muss die Probleme, die ich abarbeiten muss, ja systematisch abbauen. Bei Menschen, die das jedoch nicht gewohnt sind (und das sind nun mal die meisten Menschen, die beim Support anrufen), ist das eine Unzulänglichkeit. Wie finden wir denn Ticketsysteme in Ämtern? Unpersönlich und negativ behaftet, weil der Eindruck entsteht, die Maschine entscheidet darüber, wer nun bedient wird und wer warten muss.

Es sollte also das Ziel sein, dem Kunden zu vermitteln, dass man sich individuell um sein Problem kümmert und man dazu weder seine Kundennummer benötigt, noch ihm irgendwelche Ticketnummern aufs Auge drückt. Denn beides geht.

Tags: ,