CGM ALBIS-Update Q3/2026 (26.30.139) und Windows Server 2016 – Erfahrungsbericht und Einordnung

[FortiSecond]

EDIT
Hier ist die komplette Zusammenfassung: viewtopic.php?p=72988#p72988
/EDIT

Tja, das Update ist da.
Allerdings stelle ich gerade fest, dass die Version 26.30.139 auf einem Server 2016 nicht läuft.
Die fehlenden DLLs konnte ich zwar manuell nachschieben, aber bestimmte Funktionen, die ALBIS nun verlangt, gibt es im normalen Server 2016 einfach nicht.

Na, das wird spannend. Muss ich echt an diesem schwülen WE glatt noch ein Inplace-Update des Servers durchführen? Ich hoffe nicht.
Mal sehen, ob der Installer mit nun vorhandenen DLLs durchlaufen will.

EDIT
Update dazu: Nö.

Screenshot 2026-07-18 011411.png

[FortiSecond]

Haha, die lachen mich tot:

In der E-Mail zum ALBIS-Update 26.30 vom 09.07.2026 gab es KEINEN Hinweis zu möglichen Problemen mit Server 2016.

In der E-Mail zum ALBIS-Update 26.30 vom 15.07.2026 ("Nachlieferung") gibt es am Ende der E-Mail einen Hinweis. Siehe unten.
Dieses Update scheint essentiell zu sein, denn

[...]vor wenigen Tagen haben Sie von uns das CGM ALBIS-Onlineupdate 26.30 erhalten.
Nach der Bereitstellung zeigten sich in bestimmten Konstellationen Unstimmigkeiten bei der Anzeige des Dosierschemas: Das Dauermedikament wurde angezeigt, jedoch ohne Dosierungsangabe.
Dieses Programmverhalten wurde inzwischen korrigiert, sodass wir Ihnen heute ein aktualisiertes Update zur Verfügung stellen.
Zusätzlich enthält dieses Update HzV-Datennachlieferungen.[...]

Also... es MUSS sein.

Die Installer-Routing läuft durch, um ganz am Ende zu meckern, dass die Wartung nicht erfolgreich sei.
Dann Crash beim Starten (eine DLL fehlt). DLL nachgerüstet... Crash mit Prozedureinstiegpunkt [bla...].

Screenshot 2026-07-18 011526.png

Und in der E-Mail zur Nachlieferung unten dann ein Absatz:

Sie nutzen CGM ALBIS auf einem System mit Windows Server 2016?

Technologien und Plattformen entwickeln sich kontinuierlich weiter - damit steigen auch die Anforderungen an Leistung, Funktionsumfang und Sicherheit. In diesem Zusammenhang haben wir festgestellt, dass bei der Verwendung von Windows Server 2016 mit CGM ALBIS Einschränkungen auftreten können.

Um sicherzustellen, dass CGM ALBIS weiterhin reibungslos funktioniert, lassen Sie bitte vor der Update-Installation ihre Systemumgebung durch Ihren Vertriebs-und Servicepartner prüfen und das weitere Vorgehen mit ihm abstimmen.

Weitere Infos unter https://www.cgm.com/deu_de/lp/cgm-praxi ... -2016.html

Aha. Erinnert ein wenig an die Sonder-Edition von TURBOMED-Updates für Windows 10-Clients bzw. Server 2012 R2. Hatten wir ja hier im Forum. Ist natürlich GANZ GEIL, wenn so ein Absatz am Ende der Mail zu einer NACHLIEFERUNG steht und der Installer nicht beim Start direkt sagt, dass es mit Server 2016 nicht weitergeht. So ein "Breaking Change" kommt ohne entsprechend große Warnung - Erst muss der Schaden eintreten.

"Prima" für Vertriebspartner, die womöglich dann am Montag eine Notlösung aufspielen müssen (immer toll nach einem Update-Wochenende) oder - ich will jetzt kein Kalkül unterstellen - direkt einen neuen Server verkaufen können.

Nun denn - mir egal, gibt´s halt spontan einen Samstag mit einem OS-Upgrade, damit die Praxis am Montag in der Ferienzeit die Vertretung für 3 andere Hausärzte ohne Infarkt übersteht. Danke, CGM... für den spontanen zusätzlichen Umsatz. Wäre aber nicht nötig gewesen. Hätte das lieber im September in Richtung Quartalsende gemacht, wenn die zwei weiteren Praxen mit Server 16 (nicht ALBIS, sondern TURBOMED) auch dran sind. Immerhin habe ich noch ein paar frische SSD und eine Serverlizenz zur Hand. Zum Glück ist da nur 1 Terminal-Client dran, der läuft erstmal so mit, bis die RDS-CAL gekauft und aktiviert sind.

Brrrrr!

[FortiSecond]

Nachtrag:
Mal sehen, ob die .138 funktioniert.
Die wurde drei Minuten vor der .139 per E-Mail angekündigt - OHNE Hinweis auf Probleme mit Server 2016.
Ist das die Kompatibilitätsversion?
Es bleibt spannend.

Screenshot 2026-07-18 011116.png

[FortiSecond]

Aber die Hoffnung ist nicht groß.
Immerhin gibt es einen Unterschied: Version .138 ist 3 Bytes größer.

Screenshot 2026-07-18 012517.png

[FortiSecond]

Nix da... Gleiches Problem.
Es nervt so sehr... vor allem, wenn man die ältere ALBIS.EXE und ALBISCS.EXE drüberbügeln muss, damit der Installer nicht "eine neuere Version" findet. Brah... Mal sehen, was die .124 bringt.

[FortiSecond]

Brah... Mal sehen, was die .124 bringt.

Nix. Die war auch schon unfähig.
Hmm... da war im letzten Jahr schonmal was Ähnliches. Irgendeine DLL. Es bleibt frustrierend.

[FortiSecond]

Brah... Mal sehen, was die .124 bringt.

Nix. Die war auch schon unfähig.
Hmm... da war im letzten Jahr schonmal was Ähnliches. Irgendeine DLL. Es bleibt frustrierend.

Nicht der selbe Fehler wie im Vorjahr.
Es liegt an Qt6, was auf Windows Server 2016 nicht lauffähig ist. Ob´s einen "Umweg" gibt? Schaumermal.

[FortiSecond]

Nun, es könnte Umwege und Tricks geben, und ich habe eine ganze Packung voller Ideen.
Doch abseits von der sportlichen Herausforderung hätte es keinen (nachhaltigen) Nutzen, sondern birgt Risiken für den Betrieb am Montag und ggf. auch Haftungsrisiko... und ist darüber hinaus wirtschaftlicher Unsinn.

Ergo:
1) Es ist immer noch eine Praxissoftware, und die muss innerhalb der Spezifikationen und ohne "amateurische Modifikation" betrieben werden.
2) Windows Server 2016 ist am Ende und in diesem Jahr zwingend abzuwickeln. Warum also jetzt irgendwas frickeln, um dann in einigen Wochen sowieso das Betriebssystem zu aktualisieren.

Dass eine Software nicht mehr für Win2016 entwickelt wird , weil die die Programmierer letztlich nicht die Rückwärtskompatibilität auf Kosten der Stabilität bereitstellen können, ist nachvollziehbar. Also ist nun Tag X gekommen. Das inhärente Risiko mitgeschleppter Sicherheitslücken in älteren und eventuell nicht für aktuelle Plattformen verfügbaren Modulen (teils auch Dritter) ist nicht mehr tragbar.
Bestimmte moderne Features brauchen nun einmal aktuelle Bausteine, die in ihrer aktuellen (gepflegten) Version nicht mehr auf W16 laufen. Und irgendwann muss es halt so kommen.

-> So weit, so gut. Alles verständlich, alles okay. Würde ich als Softwarehaus auch nicht anders machen wollen.
-> Und ja, nur weil W16 noch bis Februar 2027 nicht völlig tot ist, sondern noch Sicherheitspatches bekommt, bedeutet es nicht, dass man es bis zum letzten Tag unterstützen muss. Zumindest nicht, wenn neue (Pflicht-)Features eine gängige Plattform (Server 2022, 2025) benötigen.

(Hintergrund: Server 2016 basiert auf Windows 10 Version 1609, also quasi das "Ur-Windows10". Hier fehlen unglaublich viele der heute selbstverständlichen Features, die Windows 10 in seinem Leben, speziell ab 1903 erhalten hat.)

Dennoch gibt es EINE Sache, die mich richtig ärgert:
Während bei TURBOMED rechtzeitig gewarnt wurde, dass ab Update Qx/20xx zwingend ein aktuelles Betriebssystem vorgehalten werden muss UND (freundlicherweise!) für ein paar Handvoll Kunden vorübergehend noch eine alternative Update-Version vorgehalten wurde, kommt es hier mehr oder weniger "aus dem Nichts". Macht man das Update am Freitagabend, nachdem man schon auf Anraten des VSP abgewartet hat (weil die erste ALBIS Q3/2026 nicht 100% war), gibt´s keinen Support und einen fürchterlichen Montagmorgen, wenn man Pech hat.


So, genug geschrieben. Jetzt kommt der Werkzeugkasten, sprich: Vollständiges Image auf neue SSD, Anpassungen, dann In-Place-Upgrade des W2016-Servers auf 2022 oder 2025. Hyper-V und Die VM für die Rolle Domain Controller bleiben noch auf 16. Eins nach dem Anderen. Aufi geht´s.

[FortiSecond]

Jetzt bin ich gespannt. Nach einigen Stunden Vorarbeit (Datenträger spiegeln, umbauen, Win 2016 die NVMe schmackhaft machen und alle sonstigen Voraussetzungen checken) dauerte das komplette Upgrade auf Server 2025 nun knappe 45 Minuten.

Kein Witz: Das Server-Upgrade läuft flüssiger als der Umstieg von Windows 10 auf Windows 11.

Update ALBIS 26.30.139 installiert seit 5 Minuten. Balken 60%.

[FortiSecond]

"ALBIS wird gestartet..."

[FortiSecond]

Okay, Kurzfassung:
Nachdem man ein sauberes Systemimage angelegt (oder direkt auf frische Datenträger gespiegelt) hat und wenn der Server 2016 ansonsten regulär eingerichtet ist, sind das
Upgrade auf Server 2025 plus ALBIS-Update in rund 2 Stunden machbar.


Das gilt nicht für solch einen Vorgang über den VSP.
Dabei will ich aber nicht ausschließen, dass das je nach Qualität der Zusammenarbeit so funktionieren kann - auch was die berechneten Stunden angeht. Hängt auch immer davon ab, wie gut der Partner das System kennt oder gar im Rahmen eines Wartungsvertrags in Schuss hält.

Wenn man die regulären Voraussetzungen und wenig bis keine Kenntnis des individuellen Systems berücksichtigt, kommt da eine Menge mehr zusammen. Das ist legitim, weil der Dienstleister ein Haftungsrisiko trägt.

Wir reden also über eine realistische Spanne zwischen 4 Stunden bis 12 Stunden für solch ein Unterfangen.

[FortiSecond]

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:

1. 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.
2. 26.30.138 (drei Minuten vor der .139 per E-Mail angekündigt, ohne jeden Server-2016-Hinweis): identisches Fehlerbild.
3. 26.30.124: ebenfalls nicht lauffähig.
4. 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

1. Vollständiges Systemimage bzw. Spiegelung auf frische Datenträger (neue SSDs/NVMe) als Rückfallebene
2. Vorbereitung des Servers 2016 für die neue Hardware und Prüfung aller Upgrade-Voraussetzungen (mehrere Stunden Vorarbeit)
3. In-Place-Upgrade auf Windows Server 2025 – reine Upgrade-Laufzeit: rund 45 Minuten, bemerkenswert reibungslos
4. Installation des ALBIS-Updates 26.30.139 – diesmal erfolgreich, ALBIS startet
5. 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.