Ein weiteres Erlebnis mit Unternehmen-A - ein kleines Abenteuer mit RDP-Sessions und verbundenen Resourcen. Oder auch: Wenn du mit einem Finger auf jemanden anderes zeigst, bedenke immer das 3 Finger auf dich zeigen.

Aaalso - Unternehmen-A hat da eine RDP-Serverfarm. Auf den RDP-Servern läuft diverses an Software, von PDF-Programmen der $BigMoneyCorp-A über Office-Applicationen von $BigMoneyCorp-M bis zu komischer Wirtschaftssoftware von $MakeMoreMoneyCorp-S. Dazu dann noch so eine kleine Branchensoftware von Firma-B, über die ich dann an der ganzen Geschichte mit dranhänge. Zu den RDP-Servern noch eine kleine Randnotiz: Man hat in die Höhe gebaut, nicht in die Breite. D.h. man hat wenige gro0e Server mit einer entsprechend hohen Benutzerlast, anstatt viele kleine, mit denen man deutlich dynamischer agieren kann. Ist dann halt auch problematisch, wenn mal ein Server ausfällt - ein kleiner ist leichter zu verschmerzen als ein großer Server.

Immer mal wieder passiert es den Benutzern der RDP-Serverfarm, das sie von Fall auf Knall nicht mehr drucken können. Passiert dann übrigens auch allen nachfolgenden Benutzern, die sich entweder neu anmelden oder ihre getrennte Sitzung wieder aktivieren. Dann melden diese sich beim IT-Support des Unternehmens-A, der von Firma-A (ihres Zeichens die Auslagerung der IT-Abteilung des Unternehmens-A in eine eigenständige Firma) geleistet wird. Die gucken dann auf den Server, nehmen den aus der Produktion, warten bis alle Benutzer abgemeldet sind und starten den dann danach neu. Fehlersuche findet quasi nicht statt, es gibt keinen Reserve-Server / Testserver / whatever.

Da die Software von Firma-B diejenige ist, über die am häufigsten gedruckt - im Sinne von Papier schmutzig machen - wird, fällt das dort natürlich auch am ehesten auf wenn es ein Problem gibt. 'Schlaue' ITler denken dann natürlich sofort ohne weitere Analyse daran, das die Software von Firma-B das Problem sein muss. So kam es dann, das Firma-A sich meldete und sagte: Alles Sch…., seht zu und fixt das endlich. Wir können es uns nicht erlauben, das wir immer mal wieder einen der Server (ihr erinnert euch? In die Höhe gebaut, nicht in die Breite) für X Stunden aus der Produktion nehmen müssen. Ich habe mir dann irgendwann mal einen der Firma-A-ITler geschnappt und habe ihm gesagt die sollen doch bitte mal ganz unten und rudimentär anfangen, Server- und Client-Protokolle durchschauen. Und das ganze mal mit dem guten alten Notepad (dümmstes anzunehmendes Programm, das von $BigMoneyCorp-M frei Haus geliefert wird. Hat 0 eigegene Intelligenz, wenn es um das drucken geht.) nachvollziehen. Immer wieder ergebnislos. Irgendwann gab es dann eine kleine TelCo, an der auch ein Mitglied der mittleren Führungsetage beteiligt war. Und der hatte was interessantes zu berichten: Wenn die Drucker nicht mehr verfügbar sind, funktionieren auch die eingebundenen Client-Laufwerke in einer RDS-Sitzung nicht mehr. Und das ganze passiert auch, ohne das die Fachanwendung von FIrma-B gestartet wird / ist. Es reicht eine normale RDS-Destkopsession. Uii, was wurden die ITler der Firma-A auf einmal hellhörig… leider habe ich nicht mehr mitbekommen, ob das Problem gelöst worden ist - und wenn ja, was die Lösung war, da a) die Rückmeldungen eher sporatisch waren und b) ich meinen Arbeitgeber 'n gutes halbes Jahr später gewechselt habe.

Noch'n kleiner Joke zu dem Thema: Ihr kennt doch diese Radio-Button Dialoge, in denen man eine von n Möglichkeiten auswählen kann? Nach einem Update der Software von $MakeMoreMoneyCorp-S hat die Benutzung eines solchen Dialoges dazu geführt, das der LOKALE RDP-Client abgestürzt und die Sitzung getrennt worden ist. Gab dazu dann auch mal wieder das übliche Fingerpointing, unsere Bitte nach einem Testserver ohne jegliche weitere Software wurde mehrfach abgelehnt. Bis dann in einer TelCo das o.g. Mitglied der mitteren Führungsetage dabei war - und einer der ITler von Firma-A sich etwas verplappert hat: Oh, schwierig, Lizenzen.. Reihenfolge der Software bei der Installation…

Damit wurde mir dann klar:

1. Die verwenden keine DataCenter-Lizenzen, mit denen es egal ist wieviele Server installiert werden. Soll heißen: die haben wohl untere anderem um Lizenzkosten zu sparen in die Höhe gebaut.
2. Es gibt wohl mehr als eine Abhängigkeit in deren Software-Zoo - die von der IT irgendwie zusammengehalten wird.

Um es kurz zu machen: Wir haben dann irgendwann unseren kleinen Testserver bekommen, nur unsere Software drauf - alles sauber, alles schick - keine Probleme. Explizit Benuzter testen lassen, die extrem von dem Problem betroffen waren - keine Probleme.