Kategorie: Virtual Apps und Desktops 37 Beiträge

Planung, Bereitstellung, Migration und Optimierung von Citrix Virtual Apps and Desktops – inklusive VDAs, MCS, PVS, Profile und Performance.

Finding in the Wild | Wenn Citrix Director selbst zum Performanceproblem wird!

Wer kennt es nicht? Ein Citrix VDA zeigt plötzlich eine ungewöhnlich hohe CPU-Auslastung. Die üblichen Verdächtigen werden geprüft: Benutzerprozesse, Anwendungen, Antivirus, Windows-Dienste und Hintergrundjobs.

Doch was, wenn ausgerechnet das Monitoring selbst die Ursache ist?

🔎 Das Fehlerbild

In bestimmten Citrix-Virtual-Apps-and-Desktops-Umgebungen kann die CPU-Auslastung auf dem VDA erheblich ansteigen, sobald in Citrix Director die Ansicht Session Performance geöffnet wird und geöffnet bleibt.

Das Besondere: Die Performanceanalyse, die eigentlich bei der Fehlersuche helfen soll, beeinflusst selbst die zu untersuchende Umgebung.

🛠️ Technischer Hintergrund

Citrix dokumentiert dieses Verhalten unter:

* Issue-ID: CVADHELP-29162
* Betroffene Komponente: Citrix Director / VDA
* Fehlerbild: Erhöhte CPU-Auslastung bei geöffneter Session-Performance-Ansicht
* Fix: Citrix Virtual Apps and Desktops 2507 LTSR CU1

💡 Troubleshooting-Tipp

Wenn ein VDA unerklärlich hohe CPU-Last zeigt:

1. CPU-Auslastung und betroffene Prozesse auf dem VDA erfassen.
2. Prüfen, ob parallel eine Session-Performance-Ansicht in Director geöffnet ist.
3. Die Ansicht schließen und die CPU-Auslastung erneut beobachten.
4. Den installierten CVAD-Build und den verfügbaren Fixstand vergleichen.

Wichtig: Eine sinkende CPU-Last nach dem Schließen der Ansicht ist ein Hinweis, aber noch kein vollständiger Ursachenbeweis.

🎯 Warum ist das relevant?

Gerade bei Performanceanalysen verlassen wir uns auf Monitoring-Werkzeuge, um Engpässe sichtbar zu machen.

Dieser Fall zeigt, dass auch die Diagnosewerkzeuge selbst Teil der Fehlerursache sein können.

Die entscheidende Frage lautet also nicht immer nur: Was verursacht die Last? Sondern auch: Wer misst sie gerade?

📌 Referenz: Citrix CVAD 2507 LTSR CU1 – Fixed Issues, CVADHELP-29162

Finding in the Wild | Wenn Citrix HDX Direct durch einen Cipher-Mismatch ständig die Verbindung verliert!

Citrix-Sitzungen, die sich scheinbar ohne erkennbaren Grund immer wieder trennen und automatisch neu verbinden.

Die erste Vermutung?

Netzwerkprobleme, Paketverluste, Firewalls oder eine instabile UDP-Verbindung.

Doch nicht immer liegt die Ursache im Netzwerk.

🔎 Das Problem

Bei der Verwendung von EDT (Enlightened Data Transport) über HDX Direct kann es zu wiederholten Session-Disconnects und Reconnects kommen.

Besonders interessant: Die Verbindung wird grundsätzlich aufgebaut, bleibt aber nicht stabil.

Citrix dokumentiert dieses Verhalten unter der Fehlernummer CVADHELP-29336.

🛠️ Die Ursache

Ein Cipher-Mismatch bei der Verwendung von EDT über HDX Direct.

Damit liegt die Ursache nicht zwangsläufig an schlechter Netzwerkqualität, sondern an einem Problem bei der Aushandlung beziehungsweise Verwendung der Verschlüsselung.

Das macht die Fehlersuche besonders interessant, weil die Symptome zunächst stark nach einem klassischen Netzwerkproblem aussehen.

💡 Was sollte man prüfen?

✅ Verwendet die betroffene Sitzung tatsächlich EDT über HDX Direct?

✅ Treten die Disconnects ausschließlich bei UDP/EDT auf?

✅ Bleibt dieselbe Sitzung bei Verwendung von TCP stabil?

✅ Gibt es Hinweise auf Transport- oder Verschlüsselungsfehler in den Citrix-Diagnosedaten?

✅ Welche VDA-Version und welcher Cumulative-Update-Stand sind installiert?

Wichtig: Ein Wechsel auf TCP kann bei der Eingrenzung helfen, ist aber keine dauerhafte Lösung für das eigentliche Problem.

🔧 Der Fix

Citrix führt CVADHELP-29336 in den Fixed Issues von Citrix Virtual Apps and Desktops 2507 LTSR CU1 auf.

🎯 Mein Fazit

Nicht jeder Citrix-Reconnect ist ein Netzwerkproblem.

Gerade mit EDT, HDX Direct und den unterschiedlichen Transportwegen wird die Fehlersuche zunehmend komplexer.

Wenn TCP stabil läuft, EDT aber ständig Reconnects verursacht, sollte man nicht nur Firewalls und Paketverluste untersuchen, sondern auch bekannte Citrix-Transportfehler berücksichtigen.

Finding in the Wild | Wenn Citrix plötzlich alle Benutzer auf denselben VDA schickt!

Diese Woche hatte ich bei einem Kunden wieder einen interessanten Fall, der auf den ersten Blick nach einem klassischen Performanceproblem aussah.

Mehrere Multi-Session-VDAs, ausreichend Ressourcen und eigentlich eine funktionierende Lastverteilung.

Trotzdem landeten immer mehr Benutzer auf demselben Sessionhost, während andere VDAs kaum ausgelastet waren.

🔎 Was war auffällig?

Bei der Analyse der Umgebung fiel auf, dass einzelne VDAs ihre Load-Indizes nicht mehr vollständig meldeten.

CPU-, RAM- und Disk-Load-Werte fehlten teilweise. Dadurch hatte der Citrix Broker keine zuverlässige Grundlage mehr für die Lastverteilung.

Die Folge: Neue Sitzungen wurden nicht mehr gleichmäßig auf die verfügbaren VDAs verteilt.

🛠️ Die Ursache

Nach weiterer Analyse stieß ich auf einen dokumentierten Citrix-Bug:

CVADHELP-28688

Während der Initialisierung der Citrix Group Policy Client-Side Extension (CseEngine) kann die FQDN-Ermittlung des VDAs fehlschlagen.

Das kann dazu führen, dass die Load-Indizes nicht mehr korrekt gemeldet werden.

Citrix hat das Problem mit CVAD 2507 LTSR CU2 behoben.

💡 Was sollte man prüfen?

Wenn die Lastverteilung in einer CVAD-Umgebung plötzlich merkwürdig reagiert:

✅ Load-Indizes aller VDAs miteinander vergleichen.

✅ Prüfen, ob CPU-, RAM- und Disk-Load-Werte vollständig vorhanden sind.

✅ DNS- und FQDN-Auflösung der betroffenen Sessionhosts kontrollieren.

✅ Citrix Policy Engine und zugehörige Ereignisprotokolle untersuchen.

✅ VDA-Version und installierte Cumulative Updates überprüfen.

🎯 Mein Fazit

Nicht jedes Citrix-Performanceproblem ist ein Ressourcenproblem.

Manchmal sind genügend CPU, RAM und Sessionhosts vorhanden – aber der Broker bekommt schlicht nicht die Informationen, die er für eine vernünftige Lastverteilung benötigt.

Und genau deshalb lohnt es sich, bei ungleichmäßig ausgelasteten VDAs auch die Load-Indizes genauer anzusehen.

📌 Referenz: Citrix CVADHELP-28688 – CVAD 2507 LTSR CU2 Fixed Issues

Finding in the Wild | Windows October Update breaks Citrix VDA Registration!

Neuer Patchday, neue Überraschung. Und diesmal trifft es die Citrix VDA-Registrierung.

Nach der Installation des Windows-11-Sicherheitsupdates KB5127648 (Oktober 2026) können sich Citrix Virtual Delivery Agents plötzlich nicht mehr am Delivery Controller registrieren.

Das Interessante daran: Der VDA ist erreichbar. RDP funktioniert. Aber Citrix bleibt auf „Registering“ hängen.

🔍 Das Fehlerbild
– Citrix Studio: „Trying to re-register“
– VDA-Status bleibt auf „Registering“
– Published Desktops lassen sich nicht starten
– RDP auf die betroffene Maschine funktioniert weiterhin

Citrix dokumentiert das Problem offiziell unter CTX697231 für Windows 11 24H2/25H2, gemeldet mit VDA 2511. Andere VDA-Versionen könnten ebenfalls betroffen sein.

🔬 Der entscheidende Hinweis steckt im Eventlog

Auf dem Delivery Controller:
Event ID 131075
Prozess: BrokerService.exe
Exception:
System.ServiceModel.Security.SecurityNegotiationException
Fehlermeldung:
The caller was not authenticated by the service.
Betroffene Operation:
Citrix.Cds.Protocol.Worker.IQueryAgent.Test()

Damit wird es interessant: Nicht die klassische Erreichbarkeit des Controllers ist das Problem, sondern die Authentifizierung während der Kommunikation zwischen Broker Service und VDA.

🛠️ Der Workaround

Citrix hat bereits eine getestete Mitigation veröffentlicht:

Anschließend den betroffenen VDA neu starten.

Der Registry-Wert stellt vom neuen Windows Administrator Protection auf den klassischen Admin Approval Mode um.

Citrix bestätigt, dass sich die betroffenen VDAs danach wieder erfolgreich registrieren.

⚠️ Wichtig: Das ist ein temporärer Workaround, der eine zusätzliche Windows-Sicherheitsfunktion zurücknimmt. Die Änderung sollte kontrolliert erfolgen und nach einem endgültigen Fix erneut bewertet werden.

💡 Was lernen wir daraus?

Ein VDA, der nach dem Patchday nicht mehr registriert ist, muss nicht zwangsläufig ein Citrix-Problem haben.

Und wenn RDP funktioniert, bedeutet das noch lange nicht, dass auch die Citrix-Broker-Authentifizierung funktioniert.

Bevor ihr also VDAs neu installiert, Delivery Controller repariert oder die Active-Directory-Konfiguration auseinandernehmt:

Prüft KB5127648, Event ID 131075 und TypeOfAdminApprovalMode.

Citrix und Microsoft untersuchen die eigentliche Ursache weiterhin gemeinsam.

📚 Quelle:

Windows 11 KB5127648 Causes Citrix VDA Registration Failure
Windows 11 KB5127648 Causes Citrix VDA Registration Failure

Finding in the Wild | Citrix FIDO2 – Browser funktioniert, Office 365 nicht!

Bei einem Kunden hatte ich ein interessantes Problem mit der FIDO2-Weiterleitung in einer Citrix-Umgebung.

Das Fehlerbild:

✅ FIDO2-Authentifizierung im Browser funktioniert.

❌ In Microsoft Teams und OneDrive wird der FIDO2-Key nicht erkannt.

Die Citrix-Session selbst funktioniert problemlos, auch die FIDO2-Weiterleitung scheint zunächst korrekt eingerichtet zu sein.

Nach einiger Fehlersuche bin ich in den Citrix Docs auf zwei interessante Fixed Issues gestoßen:

🔹 CVADHELP-29179: FIDO2 funktioniert nur in Browser-Sessions, nicht aber in Office-365-Anwendungen.

🔹 CVADHELP-29040: FIDO2 funktioniert standardmäßig nicht mit Edge WebView2.

Die Lösung:

Ein Update auf Citrix VDA 2402 LTSR CU4.

Danach funktionierte die FIDO2-Authentifizierung auch in Teams und OneDrive.

💡 Mein Learning:

Wenn FIDO2 im Browser funktioniert, aber in Microsoft-365-Anwendungen nicht, muss es nicht an Entra ID, dem Security Key oder den Citrix Policies liegen.

Manchmal steckt die Lösung bereits in den Fixed Issues eines Citrix Cumulative Updates. 😉