Kategorie: Citrix 49 Beiträge

Praxisnahe Anleitungen, Troubleshooting und Best Practices für Citrix Virtual Apps and Desktops, StoreFront, WEM, Provisioning und moderne EUC-Umgebungen.

Finding in the Wild | Citrix 2607 LTSR – Upgrade erfolgreich, aber plötzlich sind Softwarelizenzen ungültig!

Diese Woche habe ich bei einem Kunden die Citrix-Umgebung auf das aktuelle CVAD 2607 LTSR aktualisiert.

Das Upgrade lief zunächst vollkommen problemlos.

✅ VDAs starteten sauber
✅ Registrierung am Delivery Controller erfolgreich
✅ Anwendungen ließen sich starten
✅ Keine Auffälligkeiten in Citrix Director

Eigentlich ein erfolgreiches Upgrade.

Doch kurz darauf meldeten einzelne Fachanwendungen plötzlich Lizenzprobleme.

❌ Lizenz ungültig
❌ Hardware-ID geändert
❌ Erneute Aktivierung erforderlich

Zunächst deutete alles auf ein Problem mit der Lizenzierungssoftware hin.

Die eigentliche Ursache lag allerdings bei einer Änderung in Citrix MCS.

🔍 Was habe ich festgestellt?

Seit VDA 2511 sorgt Citrix bei MCS-provisionierten Windows-Maschinen für eine eindeutige MachineGuid.

Früher konnten mehrere MCS-Maschinen denselben Wert aus dem Master-Image übernehmen.

Mit den neueren VDA-Versionen – einschließlich 2607 LTSR – wird diese Maschinenidentität eindeutig vergeben und bleibt über Neustarts und Image-Updates hinweg bestehen.

Technisch eine sinnvolle Verbesserung.

Allerdings verwenden einige Fachanwendungen die Windows-MachineGuid als Bestandteil ihres Lizenz-Fingerprints.

Ändert sich dieser Wert beim Upgrade, erkennt die Software möglicherweise eine neue Maschine.

🛠️ Wie habe ich das geprüft?

Über die Registry lässt sich die MachineGuid auslesen:

Der Vergleich mit den bisherigen Maschinenidentitäten zeigte die Änderung nach dem Upgrade.

Damit war auch klar, warum die betroffenen Anwendungen eine erneute Lizenzaktivierung verlangten.

Was nehme ich für zukünftige Upgrades mit?

✔ MachineGuid vor dem Upgrade dokumentieren
✔ Lizenzabhängigkeiten von Fachanwendungen prüfen
✔ Neue VDA-Version zunächst mit Pilotmaschinen testen
✔ Lizenzaktivierung nach dem Upgrade validieren
✔ Gegebenenfalls Reaktivierung mit dem Hersteller abstimmen

⚠️ Die alte MachineGuid einfach wiederherzustellen oder auf mehrere VDAs zu kopieren, ist keine saubere Lösung.

💡 Mein Fazit

Das Citrix-Upgrade war technisch erfolgreich. Trotzdem hatte eine Änderung im Hintergrund direkte Auswirkungen auf die Anwendungen der Benutzer.

Nicht jeder Fehler nach einem Citrix-Upgrade ist ein klassischer Citrix-Fehler. Manchmal verändert sich eine technische Grundlage, auf die andere Anwendungen angewiesen sind.

Citrix dokumentiert dieses Verhalten unter PMCS-58288.

Finding in the Wild | Citrix UPM – erster Login fehlerhaft, zweiter Login funktioniert!

Diese Woche hatte ich bei einem Kunden ein interessantes Problem mit Citrix Profile Management (UPM).

Nach einem Neustart der VDAs wurden bei der ersten Benutzeranmeldung verschiedene Autostart-Anwendungen nicht ausgeführt.

Das Fehlerbild:

❌ Anwendungen aus den Windows-Run-Keys starteten nicht
❌ Verknüpfungen im Autostart-Ordner wurden ignoriert
✅ Bei der zweiten Anmeldung funktionierte alles
❌ Nach einem VDA-Neustart trat das Problem erneut auf

Zunächst hatte ich die üblichen Verdächtigen im Blick: GPOs, WEM, Anmeldeskripte und Windows Explorer.

Doch die eigentliche Ursache lag im Benutzerprofil.

🔍 Was habe ich festgestellt?

Bei der Analyse fiel mir folgender Registry-Schlüssel auf:

Dieser enthält sitzungsbezogene Informationen des Windows Explorers.

In der betroffenen Umgebung wurde dieser Schlüssel durch Citrix UPM im Benutzerprofil persistiert und bei einer neuen Anmeldung wiederhergestellt.

Dadurch wurden offenbar veraltete Sitzungsinformationen übernommen, die die Initialisierung der Autostart-Anwendungen beeinflussten.

🛠️ Meine Lösung

Ich habe den Registry-Schlüssel in der Citrix-UPM-Konfiguration von der Profilsynchronisierung ausgeschlossen.

Citrix UPM GPO:

Profile Management → Registry → Exclusion list

Folgenden Eintrag hinzugefügt:

Software\Microsoft\Windows\CurrentVersion\Explorer\SessionInfo

Anschließend habe ich die bereits gespeicherten SessionInfo-Daten im betroffenen Testprofil bereinigt und die Anmeldung erneut getestet.

Das Ergebnis:

✅ Autostart-Anwendungen starteten wieder beim ersten Login
✅ Kein erneutes Auftreten nach einem VDA-Neustart
✅ Keine Anpassung an den eigentlichen Anwendungen erforderlich

💡 Mein Fazit

Nicht jeder Anmeldefehler ist ein Problem mit GPOs, WEM oder Windows selbst.

Gerade in nichtpersistenten Citrix-Umgebungen sollte man darauf achten, welche Registry-Informationen tatsächlich zwischen Sitzungen erhalten bleiben müssen.

Sitzungsbezogene Explorer-Daten gehören für mich nicht in ein dauerhaft synchronisiertes Benutzerprofil.

Deshalb werde ich den Ausschluss von Explorer\SessionInfo künftig bei meinen UPM-Baselines berücksichtigen – nach Prüfung der jeweiligen Umgebung.

⚠️ Der Ausschluss ist kein pauschal bestätigter Citrix-Fix und sollte vor einem produktiven Rollout getestet werden.

Finding in the Wild | Citrix VDA – plötzlich kein Internet mehr in Microsoft Edge!

Diese Woche bin ich bei der Analyse eines Citrix-Problems auf ein interessantes Verhalten gestoßen.

Ausgangssituation:

Windows 11 mit Citrix VDA 2507 LTSR CU2 im Remote-PC-Access-Szenario.

Nach der Installation des VDAs funktionierte der Internetzugriff über Microsoft Edge nicht mehr zuverlässig.

Das Kuriose daran:

✅ Netzwerkadapter aktiv
✅ Windows-Firewall nicht die Ursache
❌ Edge konnte externe Webseiten nicht mehr zuverlässig erreichen
❌ Ein Downgrade des VDAs brachte keine Abhilfe

Erst nach der vollständigen Deinstallation des Citrix VDAs funktionierte der Zugriff wieder.

🔍 Wo lag die Ursache?

Nicht am klassischen Netzwerkstack, sondern an einem Citrix-HDX-Hook:

CtxWebAuthnHook.dll

Dieser Hook ist Bestandteil der Citrix-WebAuthn-Integration und wird für die Unterstützung entsprechender Authentifizierungsszenarien eingesetzt.

In der betroffenen Umgebung wurde zusätzlich eine Proxy-Auto-Configuration-Datei (PAC) verwendet.

Genau diese Kombination führte offenbar zu einem Konflikt zwischen dem Citrix-Hook und Microsoft Edge.

🛠️ Was war die Lösung?

Der entscheidende Hinweis war die prozessbezogene Hook-Konfiguration für:

CtxWebAuthnHook\msedge.exe

Nachdem der entsprechende Registry-Eintrag entfernt wurde, funktionierte der Internetzugriff wieder.

Der VDA konnte installiert bleiben.

⚠️ Wichtig: Das ist ein gezielter Workaround für die betroffene Konstellation. Vor Änderungen an Citrix-Hooks müssen mögliche Auswirkungen auf WebAuthn- und FIDO2-Authentifizierung geprüft werden.

💡 Mein Learning aus diesem Finding:

Wenn nach einer VDA-Installation plötzlich Browserprobleme auftreten, sollte man nicht ausschließlich bei DNS, Firewall, Proxy oder Netzwerkadapter suchen.

Auch die Citrix API-Hooking-Konfiguration kann Einfluss auf das Verhalten einzelner Anwendungen haben.

Gerade bei Umgebungen mit PAC-Dateien, WebAuthn und FIDO2 lohnt sich ein genauer Blick auf die geladenen Citrix-Hooks.

Ein funktionierender Netzwerkstack bedeutet nicht automatisch, dass der Browser problemlos kommunizieren kann.

Finding in the Wild | Citrix Workspace App 2607 LTSR x64 – StoreFront SSO funktioniert nicht mehr

Ein Citrix Workspace App Upgrade, und plötzlich funktioniert die automatische Anmeldung am StoreFront nicht mehr.

Genau solche Fehlerbilder sind besonders interessant, weil die Ursache nicht unbedingt dort liegt, wo man sie zunächst vermutet.

Das Fehlerbild:

❌ Windows-Anmeldung funktioniert problemlos
❌ StoreFront fordert erneut Benutzername und Kennwort an
❌ Domain Pass-through Authentication funktioniert nicht mehr
✅ Vor der Umstellung auf die native x64 Workspace App war SSO funktionsfähig

Der erste Verdacht fällt schnell auf Kerberos, GPOs, StoreFront oder die SSON-Komponente.

Die eigentliche Ursache:

Citrix dokumentiert für die Workspace App 2607 LTSR x64 ein Known Issue bei der Domain Pass-through Authentication.

Dabei kann die Registrierung der cck.dll-Komponente im 64-Bit-Registry-Zweig fehlen beziehungsweise nicht korrekt hinterlegt sein.

🛠️ Der Workaround

Auf dem betroffenen Client lässt sich die Registrierung über folgenden Befehl korrigieren:

Anschließend die Workspace App vollständig beenden und die Anmeldung erneut testen.

Mein Fazit:

Wenn nach einem Workspace-App-Upgrade plötzlich StoreFront-SSO ausfällt, würde ich nicht sofort die gesamte Authentifizierungskette auseinandernehmen.

Ich prüfe zuerst die Client-Version, die Architektur und die Registrierung der beteiligten Komponenten.

Ein kleiner Registry-Eintrag kann hier den entscheidenden Unterschied machen.

⚠️ Der Workaround gilt für das dokumentierte Fehlerbild und sollte vor einem breiten Rollout getestet werden.

Finding in the Wild | Citrix FAS – SSO funktioniert nach dem Upgrade nicht mehr?

Bei Citrix-Upgrades schaue ich mir nicht nur die VDA-Registrierung und den Sitzungsstart an, sondern auch die komplette Authentifizierungskette.

Gerade bei Citrix Federated Authentication Service (FAS) gibt es seit Version 2511 eine interessante Änderung, die in gemischten Umgebungen schnell übersehen werden kann.

Das Fehlerbild:

❌ Benutzer können sich am StoreFront anmelden
❌ Der veröffentlichte Desktop startet, aber Windows-SSO schlägt fehl
❌ Zertifikatsvorlagen und CA-Konfiguration sehen korrekt aus
❌ Nicht alle VDAs zeigen dasselbe Verhalten

🔍 Was steckt dahinter?

Mit FAS 2511 hat Citrix das neue V2-Ticketformat eingeführt.

Der entscheidende Unterschied:

Bisher (V1):
Der VDA benötigt die FAS-Serveradressen über die bekannte Registry-/GPO-Konfiguration.

Neu (V2):
Die FAS-Adresse wird direkt im Ticket übermittelt.

Damit entfällt für VDAs ab Version 2511 die separate FAS-Adressliste.

⚠️ Der entscheidende Punkt:

In einer gemischten Citrix-Umgebung mit älteren und neueren VDAs darf die bisherige FAS-Konfiguration nicht einfach entfernt werden.

Ältere VDAs benötigen weiterhin die FAS-Serveradressen.

🛠️ So gehe ich bei der Analyse vor:

1. FAS- und VDA-Versionen vergleichen.
2. Prüfen, ob die FAS-Serveradressen auf älteren VDAs weiterhin konfiguriert sind.
3. Auf dem FAS-Server das Application Event 204 auswerten. Dort lässt sich erkennen, ob V1- oder V2-Tickets verwendet werden.
4. Erst danach Zertifikate, CA-Templates und Berechtigungen untersuchen.

💡 Mein Fazit:

Nicht jedes FAS-SSO-Problem liegt an der Zertifizierungsstelle.

Mit FAS V2 wird die Architektur einfacher – allerdings nur, wenn alle beteiligten VDAs das neue Ticketformat unterstützen.

Gerade bei LTSR-Migrationen und gemischten VDA-Versionen gehört die FAS-Ticketversion deshalb für mich auf die Troubleshooting-Checkliste.