In diesem Praxisbericht geht es um ein Update der VDI-Plattform Omnissa Horizon von Version 2303 auf 2503 in einer komplexen, hochverfügbaren Umgebung eines Kunden aus dem KRITIS-Sektor.
Im kritischen Infrastrukturumfeld sind maximale Verfügbarkeit, stabile Verbindungen und ein störungsfreier Betrieb verpflichtend.
Als Omnissa Platinum Partner haben wir uns bei der Planung und Durchführung dieses Projekts zunächst exakt an die offizielle Update-Sequenz des Herstellers gehalten.
Trotzdem stießen wir im Laufe des Updates auf unerwartete Probleme – insbesondere in Verbindung mit den Veränderungen nach der Übernahme von Horizon durch Omnissa und der damit verbundenen Umstellung.
Warum diese Herausforderungen entstanden sind, wie wir sie erfolgreich gemeistert haben und worauf andere IT-Teams beim nächsten Horizon-Update achten sollten, teilen wir in diesem Bericht.
Technische Ausgangslage – Setup vor dem Update
Die zu aktualisierende VDI-Umgebung basiert auf einer redundanten, hochverfügbaren Architektur.
Es werden mehrere Unified Access Gateways (UAG) und Connection Server (Connection Broker) eingesetzt, um sowohl Ausfallsicherheit als auch kontinuierliche Verfügbarkeit für alle Nutzer zu gewährleisten.
Vorgeschaltete Load Balancer regeln dabei die Zugriffe von externen Nutzern (über die DMZ) und internen Nutzern gleichermaßen und verteilen sie zuverlässig auf die jeweils verfügbaren Komponenten.
Innerhalb dieser Infrastruktur bestehen komplexe technische Abhängigkeiten zwischen mehreren Softwarekomponenten, darunter insbesondere:
- Unified Access Gateway (UAG) für sicheren externen Zugriff
- Connection Broker (CB) für das Session-Management und die User-Authentifizierung
- Dynamic Environment Manager (DEM) zur Verwaltung von Nutzerprofilen und Umgebungseinstellungen
- AppVolumes Manager zur dynamischen Bereitstellung von Anwendungen
- Enrollment Server für zertifikatsbasierte Authentifizierung sowie Single Sign-On
- Agenten der jeweiligen Services
- Diverse Zertifikate, die für Vertrauensstellungen zwischen den Komponenten sorgen
Gerade diese Abhängigkeiten sorgen dafür, dass Updates in einem solchen Umfeld präzise vorbereitet, getestet und schrittweise implementiert werden müssen, um einen reibungslosen Betrieb während und nach dem Update sicherzustellen.
💡 Hinweis: Die Grafik zeigt das konkrete Setup der beschriebenen Infrastruktur vor dem Update und visualisiert die Zusammenhänge zwischen den genannten Komponenten.
Offizielle Update-Anleitung – Wie es laut Hersteller laufen sollte
Für das Update von Horizon 2303 auf Version 2503 gibt der Hersteller Omnissa eine klare Reihenfolge vor, um eine maximale Kompatibilität zwischen allen beteiligten Komponenten zu gewährleisten. Diese offizielle Update-Sequenz sieht folgenden Ablauf vor:
- Update des AppVolumes Managers – für die dynamische Anwendungsbereitstellung und -verwaltung.
- Update der Horizon Connection Server (Connection Broker) – zur Sicherstellung der Authentifizierung und zentralen Steuerung der Benutzerverbindungen.
- Anschließendes Update weiterer Komponenten, darunter:
- Dynamic Environment Manager (DEM) – Verwaltung der Nutzerprofile.
- Unified Access Gateway (UAG) – Absicherung des externen Zugriffs.
- Horizon Agenten – installiert auf den Zielmaschinen für Endanwender.
Um unerwartete Probleme zu vermeiden, haben wir vor Beginn des Updates selbstverständlich zusätzlich die vom Hersteller offiziell bestätigte Interoperabilität der Komponenten geprüft. Konkret erfolgte dabei eine sorgfältige Prüfung auf Kompatibilität folgender Komponenten und Versionen:
- VMware Tools
- Dynamic Environment Manager (DEM)
- Unified Access Gateway (UAG)
- AppVolumes Manager
- DEM Agent, Horizon Agent, App Volumes Agent
Obwohl alle Komponenten laut Hersteller kompatibel waren und der Prozess offiziell abgesegnet erschien, kam es in der Praxis dennoch zu unvorhergesehenen Schwierigkeiten – dazu mehr im folgenden Abschnitt.
Problem 1: Authentifizierung schlägt fehl
Nach Durchführung des offiziellen Update-Prozesses trat das erste ernsthafte Problem auf:
Die Authentifizierung über die Unified Access Gateways (UAG) schlug plötzlich fehl, und Nutzer konnten sich nicht mehr am Horizon Connection Broker anmelden. Stattdessen erhielten Anwender beim Loginversuch die Fehlermeldung:
„HTTP 403 – Authentication failed.“
Unsere technische Analyse ergab, dass nach dem Update der Connection Server von Version 2303 auf 2503 die UAGs mit der vorherigen Version 2303 nicht mehr zuverlässig mit den aktualisierten Connection Servern bis auf die Virtuelle Maschine kommunizieren konnten. Die Vertrauensstellung zwischen UAG und Connection Broker war offenbar gestört.
Als unmittelbare Lösung führten wir daraufhin das Update der UAG-Komponenten von 2303 auf 2503 durch. Dieses Update stellte die Vertrauensstellung und damit die Verbindung wieder her – die Authentifizierung funktionierte anschließend wieder. Allerdings führte genau diese Maßnahme zu einem neuen, unerwarteten Problem.
Problem 2: Blast-Verbindung schlägt fehl
Nachdem wir die Authentifizierungsprobleme über die UAG erfolgreich behoben hatten, zeigte sich unmittelbar danach ein weiteres kritisches Problem: Die Verbindung der Benutzer per Blast-Protokoll zu ihren virtuellen Maschinen schlug fehl. Konkret wurde folgende Fehlermeldung angezeigt:
„VDPConnect Gateway Error“
Im Rahmen des Troubleshootings stellten wir fest, dass die Ursache in einem Versionskonflikt zwischen dem aktualisierten Connection Broker bzw. den UAGs und den noch nicht aktualisierten Horizon-Agenten in den virtuellen Maschinen lag.
Die Lösung bestand darin, den Horizon-Agenten auf dem Master-Image ebenfalls auf Version 2503 zu aktualisieren und anschließend die Desktop-Pools vollständig neu auszurollen. Nach dieser Aktualisierung und dem erneuten Rollout konnten die Anwender wieder problemlos über das Blast-Protokoll auf ihre Maschinen zugreifen.
Mit diesem Schritt war zwar das unmittelbare Problem gelöst, doch weitere unerwartete Herausforderungen warteten bereits auf uns – insbesondere aufgrund versteckter Kompatibilitätsfallen durch die Herstellerumstellung von VMware zu Omnissa.
Unerwartete Herausforderungen
Im Zuge unseres Troubleshootings tauchten weitere unerwartete Herausforderungen auf, die unmittelbar mit dem Namenswechsel von VMware zu Omnissa zusammenhingen. Insbesondere drei kritische „versteckte“ Probleme machten sich bemerkbar:
Herausforderung 1: Enrollment Server vertraut Connection Broker nicht mehr
Nach dem Update stellte sich heraus, dass der Enrollment Server plötzlich dem aktualisierten Connection Broker nicht mehr vertraute. Die Ursache lag darin, dass sich die Pfade zu den Zertifikaten im Zuge des Hersteller-Namenswechsels geändert hatten (von „VMware“ zu „Omnissa“). Da Zertifikate für die Vertrauensstellung essenziell sind, führte diese scheinbar geringfügige Änderung unmittelbar zu gravierenden Kommunikationsproblemen zwischen den Komponenten.
Herausforderung 2: AD LDS Migration Skript schlägt fehl
Ein weiteres kritisches Problem entstand bei der Migration der AD LDS-Datenbank (früher ADAM). Das Skript „OmnissaHorizonPartitionMigration-v2“, dass der Hersteller zur automatischen Aktualisierung der Datenbank bereitstellt, funktionierte nicht wie vorgesehen, da es auf die englische Sprache hardcodiert war.
Konkret bedeutete dies, dass das Skript bei einem Betriebssystem in deutscher Sprache scheiterte und die Migration der Partitionen nicht vollständig durchführen konnte. Dies hatte direkte Auswirkungen auf die Vertrauensstellung zwischen Connection Server und Enrollment Server.
Herausforderung 3: Datenbank-Upgrade vs. alter VMware-Referenzpfad
Ein weiteres potenziell kritisches Szenario besteht darin, dass bei einem vorzeitigen Update der Datenbank alte VMware-Pfade und -Referenzen auf „Omnissa“ geändert werden. Dadurch drohen Skripte und Automatisierungen, die sich auf diese Referenzen verlassen, plötzlich fehlerhaft zu laufen oder vollständig auszufallen.
Diese drei Herausforderungen verdeutlichen, wie komplex und potenziell problematisch scheinbar harmlose Namensänderungen und automatisierte Migrationsskripte bei einem Versionswechsel in der Praxis sein können. Sie machen auch deutlich, warum eine systematische, vorsichtige und gut getestete Vorgehensweise bei solchen Updates unerlässlich ist.
Unsere erfolgreiche Lösungsstrategie
Nachdem wir die beschriebenen Schwierigkeiten detailliert analysiert und die Ursachen eindeutig identifiziert hatten, haben wir eine alternative Update-Reihenfolge entwickelt und erfolgreich in der Praxis getestet. Diese von uns validierte Sequenz berücksichtigt gezielt die Abhängigkeiten zwischen den einzelnen Komponenten und weicht deshalb bewusst von der offiziellen Omnissa-Anleitung ab:
Unsere empfohlene Update-Sequenz im Detail:
- Update des Horizon Agenten auf den Master-Images
- Validierung der aktualisierten Master-Images im Testpool
- Aktualisierung des Horizon GPO-Bundles
- Rollout der getesteten Master-Images in die produktiven Pools
- Aktualisierung aller App Volumes Server
- Umstellung des internen und externen Loadbalancers auf eine UAG und einen Connection Broker für einen ununterbrochenen reibungslosen Betrieb
- Update des ersten Connection Brokers und der ersten UAG
- Durchführung ausgiebiger Tests bevor die Loadbalancer auf die aktualisierte Seite umgeschaltet werden.
- Update des zweiten Connection Brokers und der zweiten UAG
- Anschließendes Update der Enrollment Server
- Abschließende Aktualisierung der DEM ADMX Files und der DEM Management-Konsole
Warum funktioniert diese Reihenfolge?
Die entscheidende Änderung gegenüber dem offiziellen Vorgehen ist, dass die Agent-Updates zuerst durchgeführt und validiert werden, bevor andere zentrale Komponenten wie der Connection Broker aktualisiert werden. Dadurch vermeiden wir Versionskonflikte, die bei veralteten Horizon-Agenten entstehen.
Zudem stellen wir durch eine gezielte, schrittweise Loadbalancer-Umstellung sicher, dass der Betrieb während des Updates nicht beeinträchtigt wird – eine besonders wichtige Voraussetzung bei kritischen Infrastrukturen. Die abschließenden Updates der Management-Komponenten wie Enrollment Server und DEM-Konsole erfolgen bewusst zuletzt, um bereits bestehende Vertrauensstellungen zwischen aktualisierten Komponenten sicherzustellen und keine inkonsistenten Zertifikats- oder Datenbankzustände zu verursachen.
Die Praxiserfahrung hat gezeigt: Diese angepasste Update-Sequenz minimiert technische Risiken erheblich und ermöglicht einen stabilen, störungsfreien Übergang zur neuen Version.
Besonderheit in der Version 2503 (AD LDS Update)
Eine besondere Herausforderung, auf die wir bei diesem Projekt gestoßen sind, betrifft explizit das offizielle AD LDS-Migrationsskript OmnissaHorizonPartitionMigration-v2, welches für die automatische Aktualisierung von Datenbankpartitionen und Referenzen eingesetzt wird.
Im letzten Update des ”OmnissaHorizonPartitionMigration-v2” wurden folgende wichtige Änderungen von Omnissa vorgenommen:
- Das Skript kann jetzt mit allen Sprach- und Ländereinstellungen des Horizon Connection Servers verwendet werden.
- Es gibt jetzt zusätzliche Prüfungen, um sicherzustellen, dass der Benutzer, der das Skript ausführt, über die erforderlichen Horizon-Administratorrechte verfügt.
- Die Naming-Master-Rolle wird automatisch belegt, um bestimmte LDIF-Import-Fehlerszenarien zu beheben.
- Die Protokollierung wurde zur besseren Nachvollziehbarkeit und Fehlersuche verbessert.
Praxistipp für Admins:
- Sollten Sie keine POD-Architektur haben, planen sie für das Update der Datenbank unbedingt ein Wartungsfenster ein, da es definitiv zu einem stillstand der Umgebung kommt, da die Connection Broker ihren Dienst beenden müssen.
- Lesen Sie den KB Artikel 6000797 genaustens durch und laden Sie immer das aktuelle Migrationsskript herunter.
- Stellen Sie sicher, dass Sie jederzeit ein Backup deiner Umgebung wieder einspielen könnten.
Wer diesen Aspekt frühzeitig beachtet, vermeidet unnötige Troubleshooting-Zeit und stellt eine zuverlässige Migration sicher.
Fazit & Lessons Learned
Unser Praxisbericht macht deutlich: Selbst die exakte Einhaltung offizieller Herstelleranleitungen garantiert noch keinen reibungslosen Update-Prozess. Gerade bei komplexen Systemen wie Omnissa Horizon sind unabhängige, sorgfältige Tests vor dem produktiven Rollout unverzichtbar.
Folgende Erkenntnisse sollten Admins und IT-Verantwortliche beim nächsten Update berücksichtigen:
Herstellerunabhängig testen:
Verlassen Sie sich nicht blind auf offizielle Vorgaben. Insbesondere bei größeren Versionssprüngen oder Herstellerwechseln empfiehlt sich eine ausführliche Validierung in einer separaten Testumgebung.
Namensänderungen (VMware → Omnissa) kritisch beachten:
Die scheinbar kleinen Anpassungen von Hersteller- oder Produktnamen können erhebliche Auswirkungen auf bestehende Skripte, Pfadangaben und Zertifikate haben. Prüfen Sie diese Abhängigkeiten frühzeitig und umfassend.
Redundante Umgebungen gezielt nutzen:
Gerade in kritischen Infrastrukturen minimiert ein redundanter Aufbau deutlich das Risiko unerwarteter Ausfälle. Durch schrittweises Vorgehen bei den Updates können Sie Probleme erkennen und beheben, bevor sie die Produktivumgebung beeinträchtigen.
Tests in realitätsnahen Umgebungen:
Erstellen und validieren Sie unbedingt einen Testpool mit realen Arbeitsbedingungen, bevor Sie ein Update flächendeckend ausrollen. Idealerweise simulieren Sie sämtliche relevanten Zugriffe und Szenarien in einer separaten Umgebung, um mögliche Fehler frühzeitig zu entdecken.
Diese Lessons Learned helfen, beim nächsten Update eine stabilere, risikominimierte Durchführung sicherzustellen und damit die Zuverlässigkeit der IT-Infrastruktur nachhaltig zu stärken.
Checkliste: Optimale Vorbereitung auf Horizon Updates in komplexen Umgebungen
Nutzen Sie diese Checkliste, um dein nächstes Omnissa-Horizon-Update in einer komplexen, kritischen Umgebung optimal vorzubereiten und mögliche Fehlerquellen zu minimieren:
- Backup- und Software-Shares vorbereiten: Richten Sie zentrale Ablageorte für Backups, Konfigurationsdateien sowie Installationspakete und Lizenzdateien ein.
- Zertifikate aktualisieren: Prüfen Sie frühzeitig die Gültigkeit und Pfade aller benötigten Zertifikate und bereiten Sie notwendige Anpassungen vor – insbesondere bei Namensänderungen (z. B. VMware → Omnissa).
- Load Balancer vorab einplanen: Definieren Sie im Vorfeld, wann und wie der Load Balancer während des Updates angepasst wird, um einen störungsfreien Betrieb zu gewährleisten.
- Zugänge & Rechte sicherstellen: Stellen Sie sicher, dass sämtliche Administratorrechte und Zugänge zu Servern und Komponenten für den Update-Prozess vorbereitet sind.
- Omnissa KB Artikel lesen und Release Notes prüfen: Beachten Sie, dass bestimmte Versionen Neuerungen haben, die bei einem Update auch zu Problemen führen können.
- Namensänderungen in Skripten & Datenbank berücksichtigen: Überprüfen Sie alle Skripte und Datenbankpfade explizit auf Verweise zum alten Hersteller (VMware), um ungewollte Ausfälle durch Namensänderungen auf Omnissa frühzeitig zu erkennen und zu beheben.
Wenn Sie diese Punkte beachten, sorgen Sie für ein reibungsloses Update und minimieren das Risiko von unerwarteten Problemen und Ausfallzeiten erheblich.
Sie haben Fragen zum Projekt oder sind auf der Suche nach einer passenden VDI-Lösung?
Fragen Sie uns gerne nach einer kostenlosen Beratung. Wir freuen uns auf Sie!
oder 👉 Starten Sie mit einem kostenlosen IT Health Check für VMware-Umgebungen
Mehr über die verwendeten Produkte in diesem Projekt erfahren Sie hier:
