blog@netplanet > SupportWelt

| Abonnieren via RSS

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: ,

Gernekunden.

19. Dezember 2008 | 1 Kommentar | Veröffentlicht in SupportWelt

Vermutlich hat jeder, der in seinem Beruf Kundenkontakt hat, so seine Lieblingskunden. Manche ein paar mehr, manche ein paar weniger. Ich kann für mich sagen, dass ich eigentlich mit den allermeisten unserer Kunden gut auskomme. Ich habe im Beruf relativ wenig Berühungsängste und was weggeschafft werden muss, das muss eben weggeschafft werden. Dennoch hat man seine Lieblingskunden, bei denen man sich wirklich freut, wenn sie mal anrufen und man ihnen helfen darf. Tatsächlich, “darf”.

Zu diesen Lieblingskunden gehört ein älteres Ehepaar, die ich im Jahr 2000 als einer der ersten Kunden hatte und ihnen zunächst eine Homepage für ihren kleinen Uhrenzulieferbetrieb erstellte. Inzwischen betreiben sie den Betrieb von zu Hause aus und nach rund zehn Jahren ist nun ein neuer Computer fällig geworden. Und in den passte die bisherige ISDN-Karte nicht mehr hinein, so dass nun doch tatsächlich ein T-DSL angeschafft wurde. Zum heutigen Installationstermin des Routers, den ich mitgebracht habe, gab es Kaffee und Kuchen und fast schon ein halbes Kaffeekränzchen, während der Mann im Vorraum an der Maschine leise vor sich hinarbeitete.

Diese kleinen Familienbetrieb – im wahrsten Sinne des Wortes – waren früher einmal weit verbreitet in der Region, ob nun die kleine Firma oder schlicht die Heimarbeit in Form von Kettenlöten oder ähnlichen Arbeiten, die für die hiesige Uhren- und Schmuckindustrie von großer Bedeutung waren. Dieses hochinteressante Miteinander von Minifirma und Privatleben, in das man als Dienstleister so eintauchen kann, ist leider etwas, was unserer Region, die eigentlich mal ein Schmuck- und Uhrenzentrum weltweit war, langsam aber stetig unrettbar verlorengeht.

Ich sehe solche Kundenbesuche als Highlight an und mache sowas erheblich lieber, als in irgendwelchen Datencentern herumzustehen oder oder im stillen Kämmerlein Server zu installieren. Der “Nahkampf” an vorderster Kundenfront ist mitunter gelegentlich stressig, allerdings gibt es eben Einblicke, die man nirgendwo anders findet.

Tags:
  • Letzte Beiträge

  • Das Buch zum Blog


    Gesammelte Werke aus 3,5 Jahren BesimBlog, erhältlich als eBook im Kindle-Shop.

  • besim@Twitter

  • Tagcloud

  • Letzte Kommentare

  • Kategorien

  • Archive