CGM ALBIS-Update Q3/2026 (26.30.139) _ VORSICHT!

[FortiSecond]

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.