Finding in the Wild | Teams warnt vor dem Ende der VDI-Optimierung – aber nicht jeder Endpoint muss schon auf SlimCore

Aktuell taucht bei Nutzern mit der klassischen Citrix HDX/WebRTC-Optimierung in Microsoft Teams eine ziemlich prominente Meldung auf:

“Teams optimization for your virtual desktop will soon be unsupported.”

Das Problem dabei:
Eine dokumentierte Möglichkeit, diese Warnung administrativ auszublenden, gibt es aktuell offenbar nicht.

Entsprechend vorhersehbar ist das Ergebnis:
👉 User sehen die Meldung.
👉 User melden sich beim Helpdesk.
👉 Dabei besteht nicht überall unmittelbarer Handlungsbedarf.

Denn Microsoft unterscheidet beim Support-Ende zwischen den Endpoint-Plattformen:

🪟 Windows Endpoints
Die bisherige WebRTC-basierte Optimierung erreicht am 01.10.2026 das Support-Ende. Hier führt der Weg Richtung SlimCore.

🐧 Linux Thin Clients wie IGEL
sind von diesem Termin ausdrücklich ausgenommen. Die bestehende Optimierung bleibt unterstützt, bis eine entsprechende neue VDI-Optimierung für Linux verfügbar ist.

Gerade in gemischten Umgebungen entsteht damit eine interessante Situation:

Windows → SlimCore
IGEL/Linux → weiterhin bestehende Optimierung

Aus der Community gibt es inzwischen Hinweise, dass Microsoft das Problem mit der Warnmeldung kennt und angeblich an einer Möglichkeit arbeitet, sie zu unterdrücken.

Das ist aktuell allerdings noch nicht offiziell dokumentiert.

Für mich wieder ein schönes Beispiel dafür, dass eine technisch korrekte Warnmeldung nicht unbedingt zu einer guten User Experience führt. 😉

Wer Windows und IGEL/Linux parallel betreibt, sollte deshalb nicht allein aufgrund dieses Popups die komplette Teams-VDI-Strategie über den Haufen werfen.

Finding in the Wild | Citrix FAS + Entra ID: Anmeldung funktioniert – aber kein PRT?

Ein kleines Finding in the Wild aus einem aktuellen Citrix-FAS-Projekt.

Die Ausgangslage:

* Hybrid Entra Joined VDA
* FAS-Anmeldung funktioniert
* Zertifikat wird korrekt ausgestellt
* CRL intern erreichbar
* trotzdem kein Primary Refresh Token (PRT)

Interessant war vor allem: In älteren FAS-Umgebungen habe ich vergleichbare Konfigurationen bereits umgesetzt, ohne Certificate-Based Authentication (CBA) explizit in Entra aktivieren zu müssen.

Der entscheidende Unterschied kann im verwendeten PRT-Acquisition-Flow liegen.

Entra CBA verändert die Zertifikatsprüfung

Wird für die PRT-Ausstellung native Microsoft Entra Certificate-Based Authentication verwendet, muss CBA unter

Entra ID → Authentication methods → Certificate-based authentication

für die entsprechenden Benutzer aktiviert sein.

Und dann kommt ein zweiter wichtiger Punkt:

Eine ausschließlich intern erreichbare CRL reicht nicht aus.

Wenn Entra das Zertifikat validiert, muss Microsoft auch die Certificate Revocation List erreichen können.

Die interne CA muss deshalb nicht ins Internet. Es reicht, die signierte .crl über einen öffentlich erreichbaren HTTP-Endpunkt bereitzustellen.

Damit wird aus:

FAS → Windows Logon funktioniert → kein PRT

eine Fehlersuche entlang der kompletten Kette:

FAS → Zertifikat → Entra CBA → CA Trust → CRL → PRT

Mein Learning daraus: Bei älteren und neuen FAS-Umgebungen nicht automatisch davon ausgehen, dass der PRT über denselben Authentifizierungspfad beschafft wird.

Manchmal liegt das Problem nicht bei Citrix – sondern zwischen der eigenen PKI und Microsoft Entra ID.

Finding in the Wild | Citrix Workspace App + IGEL – „BadWindow“ im Multi-Monitor-Betrieb

Bei einem Kunden bin ich auf ein interessantes Problem mit der Citrix Workspace App auf IGEL OS gestoßen.

Das Fehlerbild:

In einer Multi-Monitor-Konfiguration kam es sporadisch zu Problemen mit einzelnen Citrix-Fenstern. Die Session selbst funktionierte grundsätzlich, allerdings tauchten in den Logs X11-Fehler wie diese auf:

BadWindow
BadDrawable
BadGC

Nach einiger Analyse konnte ich das Problem auf das Zusammenspiel zwischen IGEL OS, Citrix Workspace App und der X11-Fensterbehandlung eingrenzen.

Interessant ist dabei ein Parameter, den IGEL für die Citrix Workspace App bereitstellt:

app > cwa > wfclient > thinwire30 > ignorexerrors

Dort können bestimmte X11-Fehler beispielsweise mit

20.0/3, 55.0/9, 60.0/13

ignoriert werden.

Damit ließ sich das Verhalten in meinem Fall entschärfen.

Aber Vorsicht: Das ist kein wirklicher Fix der Ursache.

IgnoreXErrors sorgt dafür, dass die entsprechenden X11-Fehler ignoriert werden. Gleichzeitig tauchen diese Fehler anschließend auch nicht mehr im Logging auf.

Das sollte man beim Troubleshooting unbedingt berücksichtigen. Eine danach „saubere“ Logdatei bedeutet also nicht automatisch, dass die eigentliche Ursache verschwunden ist.

Mein Learning aus dem Fall:

Wenn Citrix auf einem IGEL-Endgerät grundsätzlich funktioniert, aber insbesondere im Multi-Monitor-Betrieb merkwürdige Fensterprobleme auftreten, lohnt sich ein Blick in die CWA-/X11-Logs.

BadWindow, BadDrawable oder BadGC können hier ein ziemlich guter Hinweis sein.

Und bevor man VDA, HDX Graphics oder die komplette Citrix-Infrastruktur auseinandernimmt:

Erst einmal den Endpoint anschauen. 😉

Finding in the Wild | XenServer 9 + Windows Server 2025 – wenn der Boot Storm zum Problem wird

Ein interessantes Detail aus den aktuellen XenServer-9-Known-Issues, das insbesondere für größere Citrix-Umgebungen relevant werden kann:

XenServer dokumentiert unter CP-51655 ein Problem mit Windows Server 2025.

Werden viele Windows Server 2025 VMs gleichzeitig auf demselben XenServer-Host gestartet, können einzelne VMs beim Start fehlschlagen.

Warum finde ich das im Citrix-Umfeld besonders interessant?

Weil genau dieses Szenario dort völlig normal ist.

Morgens fährt Citrix Power Management mehrere Worker hoch.

Ein MCS-Katalog wird nach einem Wartungsfenster gestartet.

Oder bei PVS werden nach einem Reboot Schedule zahlreiche Targets nahezu gleichzeitig gebootet.

Dann sieht das Fehlerbild möglicherweise zunächst so aus:

„Einige meiner Citrix Worker starten nicht.“

Und die Fehlersuche beginnt wahrscheinlich bei MCS, PVS, dem Master Image oder dem Delivery Controller.

Die Ursache kann aber eine Ebene tiefer liegen.

XenServer beschreibt ausdrücklich, dass das Problem auftreten kann, wenn eine größere Anzahl Windows-Server-2025-VMs gleichzeitig auf einem einzelnen Host gestartet wird.

Das macht auch die Abnahme neuer Server-2025-Citrix-Umgebungen interessant.

Ein Test mit zwei oder drei VDAs reicht möglicherweise nicht aus.

Ich würde bei XenServer 9 + Windows Server 2025 deshalb auch einen echten Boot-Storm-Test einplanen:

5 VMs → 10 VMs → 20 VMs → 30+ VMs gleichzeitig starten.

Dabei nicht nur prüfen, ob die VDAs anschließend registriert sind, sondern bereits auf XenServer-Ebene beobachten, ob einzelne VM-Starts fehlschlagen.

Gerade mit Windows Server 2025 als zukünftiger Multi-Session-Plattform ist das ein kleines Detail mit potenziell großer Auswirkung.

Known Issue: CP-51655

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