Schlagwort: Virtual Apps 74 Beiträge

Finding in the Wild | Citrix MCS – VDA startet, aber die Domänenvertrauensstellung ist defekt!

Ein Fehlerbild, das in nichtpersistenten Citrix-Umgebungen besonders unangenehm werden kann.

Der VDA startet nach einem Reboot scheinbar problemlos. Die VM ist erreichbar, die Netzwerkverbindung steht – aber Benutzer können sich nicht mehr anmelden.

❌ Windows meldet eine fehlerhafte Domänenvertrauensstellung
❌ Benutzeranmeldungen über ICA oder RDP schlagen fehl
❌ Ein Neustart behebt das Problem nicht dauerhaft
❌ Im schlimmsten Fall sind mehrere Maschinen eines MCS-Katalogs betroffen

🔍 Wo liegt die eigentliche Ursache?

Bei Citrix Machine Creation Services (MCS) erhält jede Maschine eine eigene Identität.

Diese wird unter anderem über die MCS Identity Disk bereitgestellt.

Sie enthält die maschinenspezifischen Identitätsinformationen, die für die korrekte Zuordnung zur Active-Directory-Domäne erforderlich sind.

Wenn das Maschinenkontokennwort beziehungsweise die Trust-Informationen nicht mehr zum AD-Computerkonto passen, kann die Domänenvertrauensstellung fehlschlagen.

Mögliche Auslöser sind beispielsweise Snapshot-Rollbacks, fehlerhafte Identity-Informationen oder manuelle Änderungen an AD-Computerkonten.

🛠️ Mein Troubleshooting-Ansatz

Zunächst prüfe ich auf dem betroffenen VDA den Secure Channel:

Anschließend kontrolliere ich:

✔️ Netlogon-Ereignisse
✔️ Das zugehörige AD-Computerkonto
✔️ Die Zuordnung der MCS Identity Disk
✔️ Den Maschinenstatus im Citrix Broker

Und jetzt kommt der interessante Teil:

Citrix bietet mit Repair-AcctIdentity eine gezielte Reparatur der Maschinenidentität.

Damit lassen sich Maschinenkennwort und Trust-Informationen reparieren, ohne direkt den gesamten Machine Catalog neu aufzubauen.

Beispiel:

Wichtig: Die betroffene VM muss dafür ausgeschaltet und im Maintenance Mode sein.

💡 Mein Fazit

Bei einem defekten Secure Channel in einer nichtpersistenten MCS-Umgebung würde ich nicht einfach den Computer aus der Domäne entfernen und erneut aufnehmen.

Die Maschinenidentität wird durch MCS verwaltet. Eine manuelle Reparatur innerhalb des VDAs kann deshalb beim nächsten Neustart wieder verloren gehen.

Erst die MCS-Identität prüfen, dann gezielt reparieren – statt direkt den kompletten Katalog neu aufzubauen.

Finding in the Wild | Windows 11 26H2 – Black Screens und endlose Citrix-Anmeldungen

Nach Windows-Updates häufen sich Probleme in Citrix-Umgebungen:

❌ Anmeldung hängt bei „Willkommen“ oder „Bitte warten“
❌ Schwarzer Bildschirm nach erfolgreicher Anmeldung
❌ Explorer startet nicht
❌ Benutzerprofile werden nicht vollständig geladen

Das Problem: Gleiche Symptome, unterschiedliche Ursachen.

Aktuell gibt es mehrere bekannte Fehlerbilder:

1️⃣ Windows Shell / explorer.exe
Microsoft bestätigt Explorer-Probleme nach der Anmeldung, insbesondere in virtuellen Windows-11-Umgebungen mit FSLogix.
✅ Fix: KB5127648 (Oktober 2026).

2️⃣ Citrix UPM – UPM-13949
Unter Windows 11 26H2 können neue Benutzerprofile auf MCS-Maschinen beim ersten Login hängen bleiben. Der Profilordner wird erstellt, die Anmeldung aber nicht abgeschlossen. Bestehende Profile funktionieren.
⚠️ Citrix untersucht das Problem.

3️⃣ FSLogix – Profilcontainer
Mögliche Ursachen sind verzögertes VHDX-Mounting, SMB-Latenzen, Storage-Engpässe, gesperrte Container, Berechtigungen oder Antivirus-Interferenzen.

4️⃣ Citrix UPM – Profile Store
Fehlerhafte NTFS- oder Share-Berechtigungen nach Profilmigrationen können verhindern, dass das Profil korrekt initialisiert wird.

5️⃣ Citrix VDA – Registrierungsprobleme
Nach KB5127648 können VDAs im Status „Registering“ hängen bleiben. BrokerService meldet unter anderem SecurityNegotiationException.
➡️ Citrix dokumentiert einen Registry-Workaround.

6️⃣ Remote Desktop Services
Nach bestimmten Windows-Updates kann TermService hängen bleiben. Sitzungen verbleiben bei „Connecting“, neue Verbindungen scheitern.

7️⃣ MCS Master Image
Wenn plötzlich alle Maschinen betroffen sind, sollten Windows-Build, VDA-Version, GPOs, Logon Scripts und der letzte funktionierende Snapshot verglichen werden.

🔧 Mein Troubleshooting-Ansatz:

✔ VDA registriert?
✔ Session tatsächlich gestartet?
✔ Neues oder bestehendes Profil betroffen?
✔ FSLogix-VHDX beziehungsweise UPM-Profil geladen?
✔ Fehler im User Profile Service?
✔ explorer.exe gestartet oder abgestürzt?
✔ Windows-Updates und VDA-Version geprüft?
✔ Einzelne VDAs oder gesamter MCS-Katalog betroffen?

💡 Fazit

Ein Black Screen ist ein Symptom, keine Diagnose.

Wer nur FSLogix untersucht, obwohl der Explorer abstürzt oder der VDA nicht registriert, verliert wertvolle Zeit.

Erst feststellen, an welcher Stelle die Anmeldung scheitert. Dann gezielt die Ursache beheben.

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.