Kategorie: Citrix 94 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 MCS – Rearm-Fehler nach November 2026 Windows-Updates

Aktuell bin ich bei zwei meiner Kunden auf dasselbe Problem gestoßen:

Nach Installation der November-Windows-Updates schlägt die Imagevorbereitung über Citrix Machine Creation Services (MCS) fehl.

Und offenbar bin ich damit nicht allein. In den Kommentaren bei Günter Born berichten weitere Administratoren über vergleichbare Probleme.

⚠️ Auffällige Windows-Updates:

• Windows Server 2019 – KB5131085
• Windows Server 2022 – KB5131090
• Windows Server 2025 – KB5131080

🔍 Das Fehlerbild

Die MCS-Imagevorbereitung bricht mit folgender Meldung ab:

Image preparation failed to rearm the copy of Windows installed on the master image.

Damit scheitert die Bereitstellung des aktualisierten Master-Images.

🔬 Technische Einordnung

Der Fehler tritt während des Windows-Rearm-Vorgangs innerhalb der MCS-Imagevorbereitung auf.

Ob eine Änderung am Windows Software Protection Service, der Aktivierungslogik oder am Zusammenspiel mit Citrix MCS verantwortlich ist, ist aktuell noch nicht geklärt.

Die zeitliche Nähe zum November-Patchday ist auffällig, beweist aber noch keine konkrete Root Cause.

🛠️ Meine Handlungsempfehlung

1️⃣ November-Updates zunächst ausschließlich auf Test-Master-Images installieren.

2️⃣ MCS-Imagevorbereitung vollständig testen – nicht nur den erfolgreichen Windows-Start.

3️⃣ Bei Fehlern die Citrix-ProvTask-Details, Preparation-VM-Logs und Windows-Aktivierungsereignisse auswerten.

4️⃣ Den letzten funktionierenden Master-Snapshot für einen Rollback bereithalten.

5️⃣ Produktive Katalogaktualisierungen bis zur erfolgreichen Validierung zurückstellen.

Von manuellen Änderungen an slmgr /rearm oder den Windows-Aktivierungseinstellungen würde ich ohne geklärte Ursache abraten.

❗ Aktueller Stand

Das Fehlerbild ist bei zwei meiner Kunden aufgetreten. Zusätzlich gibt es mehrere vergleichbare Community-Meldungen.

Eine offizielle Bestätigung oder ein dokumentierter Fix von Citrix beziehungsweise Microsoft liegt bislang nicht vor.

Hat jemand bereits eine reproduzierbare Ursache oder einen funktionierenden Workaround identifiziert? Besonders interessant wären die eingesetzte CVAD-Version und die Windows-Aktivierungsmethode.ö

Finding in the Wild | Citrix Workspace App + VDA – Wenn die Telemetrie Probleme macht

Bei einem meiner letzten Kundeneinsätze bin ich auf ein interessantes Citrix-Problem gestoßen: LCM-22664.

In der betroffenen Umgebung waren sowohl die Citrix Workspace App als auch der Citrix Virtual Delivery Agent (VDA) auf demselben Windows-System installiert.

🔴 Das Problem

Bei der Analyse fiel auf, dass die Registry-Überwachung des Citrix Telemetry Service nicht wie erwartet funktionierte.

Die Ursache: Ein von Citrix dokumentiertes Problem mit Workspace App 2402 LTSR CU4, wenn diese gemeinsam mit einem VDA installiert ist.

Gerade in Nested-Citrix-Umgebungen ist diese Kombination keine Seltenheit.

🔍 Meine Vorgehensweise

✅ Installierte Workspace-App- und VDA-Versionen geprüft

✅ Citrix Telemetry Service untersucht

✅ Registry-Konfiguration und Telemetrie-Logs kontrolliert

✅ Das Fehlerbild mit Citrix Known Issue LCM-22664 abgeglichen

🛠 Der Fix

Citrix hat das Problem mit Workspace App 2402 LTSR CU4 Hotfix 1 behoben.

Meine Empfehlung: Den Hotfix zunächst auf einem Test-VDA validieren, bevor er produktiv ausgerollt wird.

💡 Mein Fazit

Nicht jeder Citrix-Fehler äußert sich durch einen ICA-Abbruch oder eine fehlgeschlagene Anmeldung.

Manchmal funktioniert die eigentliche Sitzung problemlos, während im Hintergrund die Diagnoseinfrastruktur beeinträchtigt ist.

Und genau das kann bei der nächsten Fehlersuche zum Problem werden.

📌 Citrix Issue: LCM-22664
📚 Quelle: Citrix Workspace App 2402 LTSR CU4 – Fixed Issues

Finding in the Wild | Citrix – OAuth erfolgreich, aber die Anwendung wartet weiter!

Bei meiner Beschäftigung mit Citrix Bidirectional Content Redirection (BCR) bin ich auf ein interessantes Fehlerbild gestoßen.

Die OAuth-Authentifizierung wird aus einer Citrix-Sitzung heraus gestartet und an den lokalen Browser weitergeleitet.

Der Benutzer authentifiziert sich erfolgreich, inklusive MFA.

Doch die Anwendung innerhalb der Citrix-Sitzung wartet weiterhin auf die Anmeldung.

🔍 Wo liegt das Problem?

Zunächst würde ich bei einem solchen Fehlerbild die üblichen Verdächtigen prüfen:

➡️ Microsoft Entra ID und MFA
➡️ OAuth Redirect URI
➡️ Browser- und Citrix-Richtlinien
➡️ Workspace App und VDA

Dabei ist ein Punkt entscheidend:

Eine erfolgreiche Authentifizierung im lokalen Browser bedeutet nicht automatisch, dass das Ergebnis wieder beim VDA ankommt.

💡 Root Cause – CVADHELP-32527

Citrix dokumentiert einen Fehler, bei dem das OAuth-Authentifizierungsergebnis bei Bidirectional Content Redirection nicht korrekt an den VDA zurückgegeben wird.

Der kritische Punkt ist der Rückweg:

VDA → lokaler Browser → OAuth → VDA

Die Anmeldung kann erfolgreich sein, während die Übergabe zurück in die Citrix-Sitzung scheitert.

🛠️ So würde ich den Fehler eingrenzen

1️⃣ BCR-Policies prüfen

Sind Bidirectional Content Redirection und die entsprechenden URL-Regeln korrekt konfiguriert?

2️⃣ OAuth-Callback analysieren

Mit den Browser Developer Tools kontrollieren, welche Redirect URI nach erfolgreicher Anmeldung aufgerufen wird.

3️⃣ Workspace App überprüfen

Installierte Version ermitteln und mit den Citrix Fixed Issues abgleichen.

4️⃣ Client- und zentrale Policies vergleichen

Prüfen, ob widersprüchliche Einstellungen oder veraltete Konfigurationen vorhanden sind.

✅ Der Fix

Citrix hat das Problem unter CVADHELP-32527 dokumentiert und in Workspace App 2507.1 LTSR CU3 behoben.

Meine Empfehlung:

✔ Korrigierten Workspace-App-Build einsetzen
✔ OAuth-Redirect-Konfiguration überprüfen
✔ BCR-Richtlinien bereinigen, falls erforderlich
✔ Den vollständigen Authentifizierungsprozess erneut testen

🎯 Mein Fazit

Gerade bei Citrix lohnt es sich, den gesamten Authentifizierungsfluss zu betrachten.

Nicht jeder vermeintliche OAuth- oder MFA-Fehler liegt am Identity Provider.

Manchmal funktioniert die Anmeldung einwandfrei – aber die Rückgabe an den VDA scheitert.

Und genau solche Fehler machen das Troubleshooting interessant. 😉

Finding in the Wild | Citrix – Wenn das Teams-VDI-Plugin den ICA-Start verhindert!

Ein interessantes Fehlerbild aus der Citrix-Welt:

Nach der Installation oder Aktualisierung des Microsoft Teams VDI Plugins lassen sich plötzlich keine Citrix-Anwendungen oder Desktops mehr starten.

❌ ICA-Launch schlägt fehl
❌ Anwendungen und Desktops starten nicht
❌ StoreFront und Delivery Controller können weiterhin erreichbar sein
❌ Der Fehler tritt erst nach der Plugin-Installation auf

🔍 Root Cause – CVADHELP-34806

Citrix dokumentiert einen Fehler, bei dem die Installation des Microsoft Teams VDI Plugins den Registry-Wert VirtualDriverEx beschädigen kann.

Dieser Wert gehört zur Konfiguration der Citrix ICA Client Engine und ist für die Registrierung zusätzlicher Virtual-Channel-Komponenten relevant.

Wird er beschädigt, kann bereits der ICA-Sitzungsstart fehlschlagen.

🛠️ Mein Troubleshooting-Ansatz

Zuerst prüfe ich, ob der Fehler zeitlich mit einem Teams-VDI-Plugin-Update zusammenhängt.

Anschließend kontrolliere ich auf dem Endpoint:

* Workspace-App-Version und Teams-VDI-Plugin-Version
* Den Registry-Wert VirtualDriverEx
* Unterschiede zu einem funktionierenden Referenzclient
* Workspace-App-Logs und den ICA-Startprozess

Die entscheidende Prüfung:

Dort den Wert VirtualDriverEx auslesen und vergleichen.

✅ Der Fix

Citrix hat das Problem mit Workspace App 2507.1 LTSR CU3 Hotfix 1 behoben.

Meine Vorgehensweise:

1. Registry-Konfiguration vor Änderungen sichern.
2. Betroffenen Endpoint auf den korrigierten Workspace-App-Build aktualisieren.
3. Teams-VDI-Plugin und Virtual-Channel-Registrierung überprüfen.
4. ICA-Start und Teams-Optimierung erneut testen.

Keine Registry-Werte blind von anderen Systemen übernehmen und keine Teams-Optimierung dauerhaft deaktivieren.

💡 Mein Fazit

Wenn Citrix-Sitzungen plötzlich nicht mehr starten, liegt die Ursache nicht zwangsläufig beim VDA, Broker oder StoreFront.

Manchmal reicht ein fehlerhafter Registry-Eintrag auf dem Endpoint, um den gesamten ICA-Launch zu verhindern.

Ein Teams-Plugin kann also einen Citrix-Startfehler verursachen – lange bevor Teams überhaupt geöffnet wird.

Finding in the Wild | Citrix-Drucker nach einem Windows-Upgrade verschwunden?

Citrix dokumentiert aktuell einen Known Issue im Umfeld von CVAD 2603:

Nach einem In-Place-Upgrade von Windows auf einem System mit bereits installiertem Citrix VDA können die Citrix Print Provider aus der Windows-Ausführungsreihenfolge verschwinden.

Mögliche Symptome:

– Clientdrucker werden nicht mehr erstellt
– Der Citrix Universal Printer fehlt
– Druckprobleme treten nur auf den aktualisierten VDAs auf
– Spooler und Citrix Print Manager laufen trotzdem fehlerfrei

Die Ursache liegt laut Citrix im Windows-Upgradeprozess: Die registrierte Reihenfolge der Print Provider wird nicht vollständig beibehalten.

Workaround:

Unter

im Wert „Order“ folgende Einträge vor den anderen Providern ergänzen:

• Universal Printer
• Client Printer

Anschließend muss der VDA neu gestartet werden.

Meine Empfehlung:

Nach jedem In-Place-Upgrade eines VDA nicht nur die VDA-Registrierung und den Sitzungsstart prüfen, sondern ausdrücklich auch Client Printer, Session Printer und Universal Printer testen.

Denn ein erfolgreicher Login bedeutet noch lange nicht, dass anschließend auch jemand drucken kann.