Und hier nun die Zusammenfassung (KI-assistiert):
CGM ALBIS-Update Q3/2026 (26.30.139) und Windows Server 2016 – Erfahrungsbericht und Einordnung
Kurzbericht
Das ALBIS-Onlineupdate Q3/2026 (26.30.139, "Nachlieferung" vom 15.07.2026) ist auf Windows Server 2016 nicht lauffähig. Ursache ist die Umstellung auf Qt6, dessen aktuelle Version Betriebssystemfunktionen voraussetzt, die Server 2016 (technische Basis: Windows 10 Version 1607) nicht bereitstellt. Das Update ist gleichzeitig fachlich nicht verzichtbar: Es korrigiert einen Anzeigefehler im Dosierschema (Dauermedikation ohne Dosierungsangabe) und enthält HzV-Datennachlieferungen.
Der Hinweis auf mögliche "Einschränkungen" unter Server 2016 fand sich erstmals am Ende der Ankündigungs-E-Mail zur Nachlieferung vom 15.07. – nicht in der ursprünglichen Update-Mail vom 09.07., nicht im Betreff, und vor allem: nicht im Installer selbst. Dieser läuft bis zum Ende durch, meldet dann eine nicht erfolgreiche Wartung und hinterlässt eine nicht startfähige Installation.
Gelöst wurde die Situation durch ein In-Place-Upgrade des Servers von Windows Server 2016 auf Server 2025 am Samstag, gefolgt von der erfolgreichen Installation des ALBIS-Updates. Die Praxis war damit rechtzeitig vor Montag wieder arbeitsfähig – relevant, da sie in der Ferienzeit die Vertretung für drei weitere Hausarztpraxen übernimmt.
Problemverlauf im Detail
Die Fehlversuche in chronologischer Folge:
- 26.30.139 auf Server 2016: Installer läuft durch, meldet am Ende "Wartung nicht erfolgreich". Der Programmstart scheitert zunächst an einer als fehlend bemängelten DLL aus dem Bereich ICU (International Components for Unicode). Gegenprobe: Nach manuellem Bereitstellen aktueller DLL-Dateien folgt der Fehler "Prozedureinsprungspunkt nicht gefunden" – ein Indiz dafür, dass eine Systemfunktion angesprochen wird, über die Windows Server 2016 schlicht nicht verfügt.
- 26.30.138 (drei Minuten vor der .139 per E-Mail angekündigt, ohne jeden Server-2016-Hinweis): identisches Fehlerbild.
- 26.30.124: ebenfalls nicht lauffähig.
- Erschwerend: Für jeden erneuten Installationsversuch mussten die älteren ALBIS.EXE/ALBISCS.EXE zurückkopiert werden, da der Installer sonst "eine neuere Version" erkennt und abbricht.
Die Ursachenanalyse ergab (per Webrecherche als bestätigt anzusehen):
Qt6 ist auf Windows Server 2016 nicht ohne Weiteres lauffähig, weil eine aktuelle ICU-Bibliothek fehlt. Windows Server 2016 basiert auf Windows 10 Version 1607, und für diese Plattform existiert keine aktuellere ICU. Damit war klar, dass kein Patch-Level der 26.30er-Reihe das Problem löst. Etwaige Umgehungslösungen sind aufgrund des Anspruchs auf Integrität und Stabilität einer Praxissoftware nicht angezeigt.
Bewusste Entscheidung gegen Bastellösungen
Technische "Umwege" wären denkbar gewesen, wurden aber verworfen – aus drei Gründen: Eine Praxissoftware muss innerhalb der Spezifikation und ohne amateurhafte Modifikation betrieben werden (Haftung, Betriebssicherheit am Montag); Server 2016 ist ohnehin in diesem Jahr abzuwickeln (Ende der Sicherheitsupdates Anfang 2027); jede investierte Frickelstunde wäre wirtschaftlich verloren, weil das OS-Upgrade in wenigen Wochen sowieso anstünde.
Die Lösung – was konkret nötig war, damit die Praxis am Montag arbeiten kann
- Vollständiges Systemimage bzw. Spiegelung auf frische Datenträger (neue SSDs/NVMe) als Rückfallebene
- Vorbereitung des Servers 2016 für die neue Hardware und Prüfung aller Upgrade-Voraussetzungen (mehrere Stunden Vorarbeit)
- In-Place-Upgrade auf Windows Server 2025 – reine Upgrade-Laufzeit: rund 45 Minuten, bemerkenswert reibungslos
- Installation des ALBIS-Updates 26.30.139 – diesmal erfolgreich, ALBIS startet
- Nacharbeiten: Auf dem Server war noch die Ausführung der vc_redist.x64.exe (Visual-C++-Laufzeitumgebung) aus dem Ordner albiswin\wkflapi\bin samt Neustart erforderlich, damit auch der CGM ASSIST korrekt startet. Der einzelne Terminal-Client läuft übergangsweise weiter, bis RDS-CALs beschafft und aktiviert sind; Hyper-V und die Domain-Controller-VM verbleiben vorerst auf 2016 und werden separat migriert. Auf den Windows-11-Clients waren keinerlei Änderungen erforderlich – dort lief lediglich die Update-Installation wie üblich.
Zeitbedarf: Bei vorhandenem Image, gut gepflegtem System und genauer Systemkenntnis rund 2 Stunden für OS-Upgrade plus ALBIS-Update. Für einen Vertriebs- und Servicepartner ohne intime Kenntnis der individuellen Umgebung sind realistisch
4 bis 12 Stunden anzusetzen – das ist legitim, denn der Dienstleister trägt Haftungsrisiko und muss Voraussetzungen erst prüfen. Hinzu kommen ggf. Hardware (Datenträger), Serverlizenz und RDS-CALs.
Einordnung: Was am Vorgehen des Herstellers nachvollziehbar ist
Es ist ausdrücklich
kein Vorwurf, dass eine Software Server 2016 nicht mehr unterstützt. Moderne, gepflegte Komponenten (auch von Drittanbietern) laufen auf einer Plattform von 2016 irgendwann nicht mehr; Rückwärtskompatibilität um jeden Preis ginge zu Lasten von Stabilität und Sicherheit. Mitgeschleppte Sicherheitslücken in veralteten Modulen sind in einer Praxisumgebung nicht tragbar. Auch dass der Support endet,
bevor Microsoft im Februar 2027 den letzten Patch liefert, ist vertretbar, wenn neue Pflicht-Features aktuelle Plattformen benötigen. Aus Sicht eines Softwarehauses ist die Entscheidung selbst korrekt. Der Tag X musste kommen.
Kritik – sachlich, aber deutlich
Das Problem ist nicht die Entscheidung, sondern ihre
Kommunikation und technische Absicherung:
1. Der Hinweis kam zu spät und an falscher Stelle. Die Erst-Ankündigung vom 09.07. enthielt keinerlei Hinweis. Der Warnabsatz erschien erst in der Mail zur Nachlieferung vom 15.07. – ganz am Ende, in weichgespülter Formulierung ("Einschränkungen können auftreten"), während tatsächlich ein harter Breaking Change vorliegt: Die Software startet nicht mehr. Wer die erste Mail gelesen und – auf Anraten des Servicepartners – mit dem Update abgewartet hatte, konnte in die Falle laufen.
2. Der Installer prüft die Plattform nicht. Ein Betriebssystem-Check vor Installationsbeginn mit klarer Abbruchmeldung wäre trivial umzusetzen und hätte den gesamten Schaden verhindert. Stattdessen läuft die Installation durch und hinterlässt ein defektes System. Erst muss der Schaden eintreten, dann greift man zur Dokumentation.
3. Es fehlt eine Übergangsstrategie. Der Kontrast im eigenen Haus: Bei TURBOMED wurde rechtzeitig und mit Vorlauf angekündigt, ab welchem Quartalsupdate ein aktuelles Betriebssystem Pflicht ist – und für die verbliebenen Bestandskunden wurde vorübergehend eine alternative Update-Version bereitgestellt. Bei ALBIS kam der Schnitt faktisch aus dem Nichts, mitten in der Ferien- und Vertretungszeit, gekoppelt an ein Update, das wegen des Dosierschema-Fehlers (potenziell patientensicherheitsrelevant!) nicht aufschiebbar ist. Wer Freitagabend installiert, steht ohne Support vor einem sehr unangenehmen Montagmorgen – oder der Servicepartner darf am Wochenende eine Notlösung aufspielen. Ob dabei am Ende auch neue Server verkauft werden, sei dahingestellt; nötig wäre es bei ordentlicher Vorlaufkommunikation jedenfalls seltener kurzfristig.
Und zur Fairness auch Kritik in die eigene Richtung (bzw. an alle Praxen und Admins in ähnlicher Lage):
- Ein Quartalsupdate am Freitagabend vor einem kritischen Montag einzuspielen, ist ein selbst gewähltes Risiko – auch wenn hier mildernde Umstände vorliegen (die Erstversion war auf VSP-Rat übersprungen worden, die Nachlieferung fachlich dringend).
- Dass ein Produktivserver Mitte 2026 noch auf Server 2016 läuft, sieben Monate vor Support-Ende, ist kein Skandal, aber die Migration stand erkennbar ohnehin an. CGM hat hier nicht das Ob erzwungen, sondern nur den Zeitpunkt – ungeplant und zur Unzeit, aber die Rechnung wäre so oder so gekommen. Der ursprüngliche Plan (Migration Richtung Quartalsende September, gebündelt mit zwei weiteren Server-2016-Praxen) war der bessere; er wurde von außen kassiert.
- Das manuelle Nachschieben von DLLs in eine Praxissoftware ist genau die Art "amateurhafter Modifikation", die man im Produktivbetrieb ausschließen muss – als Diagnosewerkzeug in der Nacht vertretbar, als Lösung zu Recht verworfen.
Gesamtbetrachtung
Fachlich hat CGM das Richtige entschieden und es handwerklich schlecht ausgeliefert. Die Abkündigung einer zehn Jahre alten Plattform ist normaler Software-Lebenszyklus; ein nicht startfähiges System nach einem regulären, fachlich zwingenden Quartalsupdate ist es nicht. Drei Maßnahmen hätten den Unterschied gemacht, und keine davon ist teuer: eine prominente Vorankündigung mit konkretem Stichtag (Betreffzeile, nicht Fußnote), ein Plattform-Check im Installer vor dem ersten Schreibzugriff, und – nach dem Vorbild der eigenen TURBOMED-Linie – eine befristete Kompatibilitätsversion als Brücke für Bestandskunden.
Für Praxen mit Windows Server 2016 lautet die praktische Konsequenz:
Dieses Update nicht ungeprüft installieren. Vor der Installation Betriebssystemversion klären, aktuelles, getestetes Systemimage anlegen, und die Server-Migration jetzt aktiv terminieren statt sie bis Februar 2027 auszusitzen – der nächste Qt6-abhängige Pflichtpatch wartet nicht. Wer den Weg über den Servicepartner geht, sollte 4–12 Stunden Aufwand plus Material einplanen; in Eigenregie mit Vorbereitung und Systemkenntnis ist der Umstieg an einem Wochenende gut machbar, wie dieser Fall zeigt.
Am Ende steht ein versöhnliches technisches Detail: Das In-Place-Upgrade von Server 2016 direkt auf Server 2025 lief in rund 45 Minuten durch – flüssiger als mancher Umstieg von Windows 10 auf 11. Die Plattform war also nicht das Problem. Die Ankündigungspolitik war es.
