Vier Dienste liefen mit, von denen die Dokumentation nichts wusste
Vor jeder Umstellung sehen wir nach, was auf dem Server tatsächlich läuft, und nicht, was die Dokumentation davon kennt. Auftrag: die Dienste durchgehen, die geplanten Aufgaben, die Schnittstellen zu anderen Programmen und die Werkzeuge, die irgendwann jemand installiert hat. Jeder Eintrag kommt auf die Liste für das Umstellungswochenende. Was dort nicht steht, nehmen wir nicht mit. Soweit die Routine.
Befund: In einem Betrieb, den wir übernommen haben, liefen vier Dienste auf der Maschine, die in keiner Dokumentation standen. Eine Schnittstelle zur Zeiterfassung. Zwei geplante Aufgaben, die nachts Dateien verschoben. Und ein Werkzeug, von dem niemand mehr wusste, wer es installiert hat.
Alle vier hängen an der Maschine, die getauscht werden soll. Folge: Die vier stehen auf der Liste und ziehen am Wochenende mit um. Genau dafür sehen wir vorher nach. Einzeln ist so ein Dienst harmlos. Vier davon entscheiden über die erste Woche nach der Umstellung.
Umgestellt wird ohnehin selten aus Begeisterung. Umgestellt wird, weil die Hardware fällig ist oder weil die Version auf ihr Support-Ende zuläuft. Beides sind Termine, die man kennen kann. Wer sie nicht kennt, bekommt sie zugeteilt.
Fünf Punkte.Still für sich beantwortet.
Es geht nicht um Schuld, nur um das Muster.
Die Angaben, die niemand zur Hand hat
Das Anschaffungsjahr. Es steht in keiner Liste, sondern in einer Rechnung, die im Ordner des Jahres liegt, in dem sie bezahlt wurde. Gesucht wird sie erst, wenn jemand nach dem Alter der Maschine fragt. Bis dahin schätzt man.
Die Dienstliste. Was auf dem Server läuft, weiß im Alltag niemand vollständig. Eingerichtet haben vieles davon Leute, die längst woanders arbeiten, und aufgeschrieben hat es niemand. Bemerkt wird die Lücke erst, wenn einer der Dienste ausfällt.
Und das Support-Datum. Bis wann die Version noch Sicherheitsupdates bekommt, ist keine Zahl, die im Betrieb herumliegt. Nachlesen lässt sie sich beim Hersteller, nachgesehen hat dort seit Jahren niemand. In der Budgetrunde fehlt sie deshalb regelmäßig.
Für Technik-Interessierte Hardware, Hotpatching, Lizenzen
Vier Punkte entscheiden, was der Umstieg wirklich kostet.
Server-Maschinen halten vernünftigerweise fünf bis sieben Jahre. Kommt ohnehin neue Hardware, ist das der natürliche Moment für das aktuelle Betriebssystem.
- Die Hardware-Voraussetzungen. Die Version verlangt einen 64-Bit-Prozessor mit SLAT, NX/DEP, CMPXCHG16b und POPCNT, für etliche Sicherheitsfunktionen dazu TPM 2.0 und UEFI mit Secure Boot. Die Befehlssätze bringen Prozessoren seit etwa 2012 mit, die Anforderung allein sortiert also wenig aus. Wer die Version auf Hardware der letzten Jahre plant, ist auf der sicheren Seite, sehr alte Maschinen scheiden aus.
- Hotpatching. Sicherheitsupdates lassen sich im laufenden Betrieb einspielen. Das spart die meisten Neustarts. Für Server außerhalb der Microsoft-Cloud ist das ein kostenpflichtiges Abo und an eine Verwaltungsanbindung geknüpft.
- Die Lizenzierung. Wie bisher pro Prozessorkern, in den Ausgaben Standard und Datacenter, die sich vor allem in den Virtualisierungsrechten unterscheiden. Dazu kommen Zugriffslizenzen für Benutzer oder Geräte, und die vergessen Anbieter gern.
- Der Support-Rahmen. Die Version ist Ende 2024 erschienen, und Microsoft versorgt sie rund zehn Jahre mit Sicherheitsupdates. Das Betriebssystem überlebt die Maschine damit deutlich.
„Eine Umstellung ist für mich gelungen, wenn der Rückwegplan in der Schublade bleibt und am Montag niemand merkt, wie lang das Wochenende war.“
Und wie wird so etwas geplant?
Wochen davor die Inventur. Sie steht am Anfang, weil alle weiteren Schritte auf ihrem Ergebnis aufbauen: Was zieht mit, was wird ersetzt, was kann abgeschaltet werden. Ohne diese drei Antworten hat der Terminplan keine Grundlage.
Wochen davor auch der Testlauf. Die kritischen Anwendungen prüfen wir vorab auf dem neuen System, allen voran die Branchensoftware, deren Hersteller die Freigabe bestätigt haben muss. Manchmal lautet das Ergebnis: noch nicht, der Hersteller braucht ein Quartal. Das ist eine völlig legitime Entscheidung.
Kurz davor der Rückwegplan. Es steht fest, bis wann am Wochenende die Entscheidung „wir drehen zurück“ fällt und wie der alte Stand binnen Stunden wieder läuft. Gebraucht wird er fast nie, gebraucht wird das ruhige Gefühl, ihn zu haben.
Und am Wochenende die Umstellung. Freitagabend letzte Sicherung, dann der Umzug von Daten und Diensten, Samstag und Sonntag Tests aller Abhängigkeiten, Sonntagabend die Abnahme.
Sitzt die Umstellung, spricht am Montag niemand darüber. Die Mitarbeiter melden sich an wie immer, die Laufwerke sind da, die Branchensoftware startet. Von der neuen Version selbst sieht im Büro niemand etwas, und das ist in Ordnung so.
Das Anschaffungsjahr herauszufinden, beim Softwarehersteller nachzufragen und ein ruhiges Zeitfenster zu suchen, sind Telefonate und ein Blick in alte Rechnungen. Die Umstellung selbst, von der Inventur über den Testlauf bis zum Wochenend-Umzug mit Rückwegplan, gehört in Hände, die das regelmäßig machen. An einem Server hängt zu viel, um daran zu üben.
„Aber er läuft doch“
Der Einwand kommt in fast jeder Budgetrunde, und er ist nicht dumm: Die Maschine tut, was sie soll, warum also Geld ausgeben. Stimmt, solange nichts passiert.
Fällt ein Server aus, statt getauscht zu werden, kauft man, was gerade lieferbar ist, zahlt Expresszuschläge und Wochenendstunden, und der Umzug passiert unter Zeitdruck. Den Firmenwagen tauschen Sie ja auch nicht erst, wenn er auf der Südosttangente stehen bleibt.
Vier Fragen, und was Sie selbst tun können.
Wer hier ins Schwimmen kommt, hat Ihren Server am Laufen gehalten, mehr nicht.
Nach dem Lebenszyklus-Plan gefragt.Und nichts aus dem Inventar bekommen?
Dann kennt niemand die Abhängigkeiten, die am Umstellungswochenende auffallen. Reden wir eine halbe Stunde darüber. Wir sagen Ihnen, auf welcher Version Ihre Server laufen und wie lange sie noch Updates bekommen.
