Schlagwort: Virtual Desktop 57 Beiträge

Finding in the Wild | Citrix HDX – Copy & Paste bringt die Sitzung zum Absturz!

Ein ungewöhnliches Fehlerbild in einer Citrix-Umgebung:

Benutzer arbeiten problemlos in ihrer virtuellen Sitzung. Doch sobald Inhalte vom lokalen Windows-Client in eine Citrix-Anwendung kopiert werden, stürzt die Anwendung ab – oder die gesamte ICA-Sitzung wird getrennt.

❌ Anwendung beendet sich unerwartet
❌ Citrix-Sitzung verliert die Verbindung
❌ Fehler tritt beim Einfügen von Inhalten auf
✅ Kopieren vom VDA zum Client funktioniert weiterhin

🔍 Root Cause

Citrix dokumentiert unter HDX-99696 eine Regression in der Citrix Workspace App für Windows 2511.1.

Betroffen ist die Übertragung von Zwischenablageinhalten vom lokalen Endpoint in die HDX-Sitzung.

Die Gegenrichtung ist laut Citrix nicht betroffen.

Das macht die Fehlersuche besonders interessant: Auf den ersten Blick sieht es nach einem Anwendungsabsturz oder einem instabilen VDA aus.

🛠️ Mein Troubleshooting-Ansatz

Zuerst prüfe ich die installierte Workspace-App-Version auf dem Endpoint.

Anschließend teste ich beide Clipboard-Richtungen getrennt:

➡️ Client → VDA
⬅️ VDA → Client

Danach kontrolliere ich die Windows-Ereignisanzeige auf Anwendungsabstürze und korreliere die Zeitpunkte mit den Citrix-Verbindungsabbrüchen.

Wichtig ist außerdem, unterschiedliche Clipboard-Inhalte zu testen: einfachen Text, formatierten Text und Dateien.

✅ Der Fix

Citrix hat den Fehler mit Workspace App 2607 LTSR behoben.

Deshalb würde ich zunächst einen betroffenen Endpoint gezielt auf die korrigierte Version aktualisieren und den Fehler erneut reproduzieren.

Kein pauschales Abschalten von HDX Clipboard Redirection und kein unnötiger Eingriff in die VDA-Konfiguration.

💡 Mein Fazit

Nicht jeder Anwendungsabsturz innerhalb einer Citrix-Sitzung wird durch die Anwendung oder den VDA verursacht.

Manchmal liegt die eigentliche Ursache auf dem Endpoint – und ein einfacher Copy-&-Paste-Vorgang reicht aus, um die Sitzung zu beenden.

HDX-99696 – ein kleines Benutzerverhalten mit ziemlich großen Auswirkungen.

Finding in the Wild | Citrix PVS – VMware Tools Update legt das Master Image lahm!

Ein vermeintlich einfaches VMware-Tools-Update auf einem Citrix-PVS-Master-Image – und plötzlich ist die Netzwerkverbindung weg.

Das Problem: Die virtuelle Maschine verwendet einen VMXNET3-Netzwerkadapter, über den gleichzeitig das PVS-Streaming läuft.

❌ Das Fehlerbild

– VMware Tools Update startet zunächst problemlos.
– Während der Installation wird der VMXNET3-Treiber aktualisiert.
– Die Netzwerkverbindung wird unterbrochen.
– Das PVS-Target verliert den Zugriff auf seine gestreamte vDisk.
– Die Aktualisierung schlägt fehl oder das System reagiert nicht mehr.

🔍 Root Cause

Citrix PVS ist auf eine kontinuierliche Netzwerkverbindung zur vDisk angewiesen.

VMware Tools aktualisiert unter anderem den VMXNET3-Netzwerktreiber. Wird dieser während des laufenden PVS-Streamings neu initialisiert, kann das Target seine Verbindung zum Provisioning Server verlieren.

Das Ergebnis: Ein Treiberupdate unterbricht genau die Verbindung, über die das Betriebssystem seine Daten bezieht.

🛠️ Mein Lösungsansatz: Ein temporärer zweiter Netzwerkadapter

Anstatt das Update über den aktiven VMXNET3-Adapter durchzuführen, nutze ich einen zusätzlichen E1000E-Adapter.

1. Neue PVS-Maintenance-Version erstellen.
2. E1000E-Netzwerkadapter in VMware hinzufügen.
3. MAC-Adresse des E1000E-Adapters in der PVS-Konsole hinterlegen.
4. Das Master-Image über den E1000E-Adapter booten.
5. VMware Tools inklusive VMXNET3-Treiber aktualisieren.
6. System herunterfahren und ursprüngliche VMXNET3-Konfiguration wiederherstellen.
7. MAC-Adresse in PVS zurückändern und E1000E entfernen.
8. Master-Image erneut starten und Streaming validieren.

✅ Das Ergebnis

Während des Updates läuft das PVS-Streaming über den temporären E1000E-Adapter.

Der VMXNET3-Treiber kann aktualisiert werden, ohne dass der gerade verwendete Streaming-Adapter neu initialisiert werden muss.

Nach dem Update läuft das System wieder über VMXNET3.

💡 Mein Fazit

In einer klassischen VM ist ein Netzwerktreiber-Update normalerweise Routine.

Bei Citrix PVS kann derselbe Vorgang das laufende Betriebssystem praktisch von seiner eigenen Festplatte trennen.

Manchmal ist der zweite Netzwerkadapter der entscheidende Unterschied zwischen einem fehlgeschlagenen Update und einer erfolgreichen Wartung.

Finding in the Wild | MCSIO Cache Disk vorhanden – aber sie bleibt einfach leer

Das ist wieder so ein Citrix-Problem, bei dem auf den ersten Blick eigentlich alles richtig aussieht.

Ihr aktualisiert eure Umgebung auf VDA 2607.

MCS provisioniert die Maschine.

Die Write-Cache-Disk ist vorhanden und korrekt an der VM attached.

VDA registriert.

User können arbeiten.

Sieht gut aus.

Nur eine Kleinigkeit stimmt nicht:

👉 Die MCSIO Write-Cache-Disk bleibt leer.

Die Kombination ist entscheidend

Citrix dokumentiert das Problem aktuell unter PMCS-63379 für genau diese Kombination:

**Windows Server 2019 * VDA 2607 * MCSIO**

Die Cache-Disk wird zwar erfolgreich an die provisionierte VM angehängt, aber nicht wie vorgesehen als Write-Back Cache verwendet.

Das Gemeine daran:

Wer beim Upgrade lediglich kontrolliert, ob die Cache-Disk vorhanden ist, kann das Problem sehr leicht übersehen.

Der Workaround ist fast schon Citrix-typisch 😎

Auf dem Master Image muss unter

ein leerer Registry-Key angelegt werden:

Parameters

Ja.

Ein leerer Registry-Key.

Danach:

Master Image herunterfahren/resealen → neuen Snapshot erstellen → MCS Catalog aktualisieren → Maschinen neu starten.

Anschließend sollte sich die Write-Back-Cache-Disk bei normaler Benutzeraktivität wieder füllen.

Warum ich das interessant finde

MCSIO ist genau dafür da, Schreibzugriffe über RAM und die temporäre Cache-Disk abzufangen.

Citrix verwendet dabei unter anderem die Datei:

mcsdif.vhdx

Wenn die Disk zwar attached ist, aber nicht verwendet wird, reicht ein einfacher Blick auf die VM-Konfiguration also nicht aus.

Meine Empfehlung nach einem VDA-Upgrade

Bei MCSIO nicht nur prüfen:

✅ Cache-Disk attached

sondern auch:

✅ MCSIO Driver vorhanden
✅ Cache tatsächlich aktiv
✅ mcsdif.vhdx vorhanden
✅ Write-Cache-Disk wird beschrieben
✅ Catalog Update funktioniert

Denn:

„Disk attached“ bedeutet offenbar nicht automatisch „Cache funktioniert“. 😉

Betroffen: VDA 2607 + Windows Server 2019 + MCSIO

Citrix Issue: PMCS-63379

Finding in the Wild | Wenn identische Machine SIDs bei Citrix plötzlich zum Problem werden

Jahrelang war es in Citrix-Umgebungen völlig normal:
Golden Image erstellen → mit MCS oder PVS hunderte VDAs provisionieren → fertig.

Dabei können Maschinen aus demselben Image die gleiche lokale Machine SID besitzen.
Normalerweise kein großes Problem.

Die Computer besitzen schließlich jeweils eigene Active-Directory-Computeraccounts mit eindeutigen Domain SIDs.

Durch verschärftes Windows Security Hardening wird diese alte Architekturannahme inzwischen allerdings interessant.

Was kann passieren?
Kommunizieren zwei geklonte VDAs miteinander, können bestimmte Machine-to-Machine-Verbindungen aufgrund der identischen lokalen Identität blockiert werden.

Das kann beispielsweise auffallen bei:
❌ RDP zwischen VDAs
❌ SMB / File Sharing
❌ Printer Sharing
❌ bestimmten NTLM-/Kerberos-Szenarien

Im Windows Event Log kann dabei unter anderem LsaSrv Event ID 6167 auftauchen.

Und genau hier wird das Thema spannend:
Die VDAs sind sauber domain-joined.
Die AD Computer Accounts sind eindeutig.
DNS stimmt.
Kerberos sieht auf den ersten Blick ebenfalls sauber aus.
Trotzdem wird die Verbindung blockiert.

Warum?
Microsoft verschärft zunehmend die Validierung von Maschinenidentitäten.
Eine Designentscheidung, die bei geklonten Windows-Systemen jahrelang unproblematisch war, kollidiert damit plötzlich mit modernerem Windows Security Hardening.

Und das betrifft nicht irgendeine exotische Citrix-Funktion.

Es betrifft eines der Grundprinzipien von:
MCS und PVS – viele Maschinen aus einem Golden Image erzeugen.

Citrix weist deshalb inzwischen selbst stärker auf die Sicherheit lokaler persistenter Konten in gemeinsam verwendeten MCS-/PVS-Images hin und empfiehlt ausdrücklich, solche Konten nicht bereits im Master Image anzulegen.

Was heißt das für die Praxis?
Wenn nach Windows Security Updates plötzlich Kommunikation zwischen zwei VDAs desselben Catalogs fehlschlägt:
Nicht sofort Firewall, DNS oder Citrix Policies zerlegen. 😉

Schaut auch ins:
System Event Log → LsaSrv
und insbesondere nach Event ID 6167.

Das ist für mich ein schönes Beispiel dafür, warum Golden-Image-Architekturen heute nicht nur gegen neue Citrix-Versionen getestet werden müssen.

Finding in the Wild | PVS 2507 – wenn die Device License plötzlich verschwindet

Aktuell bin ich bei einem Kunden über einen alten Bekannten gestolpert:
“No device license is currently available for this computer. A system shutdown will be initiated in 720 hours.”

Eigentlich eine klassische PVS-Fehlermeldung.
Bei PVS 2507 + LAS lohnt sich aber ein genauerer Blick.

In der Community gibt es beispielsweise einen interessanten Bericht zu PVS 2507 auf Windows Server 2025:

Die Lizenzierung funktioniert zunächst problemlos – nach ungefähr 23 Stunden verliert PVS jedoch die Lizenzierung. Nach erneutem Ausführen des PVS Configuration Wizard funktioniert es wieder. Bis zum nächsten Tag.

Community Finding? Ja.

Aber Citrix hat inzwischen auch offiziell mehrere interessante PVS-Licensing-Probleme in 2507.1 CU2 behoben:
🔴 CVADHELP-31063
Nach einer Migration auf Citrix License Activation Service (LAS) konnte PVS fälschlicherweise Not entitled melden. Unter anderem spielte die Verarbeitung von Ablaufdatum und Zeitzone eine Rolle.
🔴 CVADHELP-31165
Bereits Zeitunterschiede zwischen PVS-Servern konnten Probleme beim Device Licensing verursachen. Mit CU2 toleriert PVS hier nun bis zu 15 Minuten Clock Difference.

Dazu kommt nach einer LAS-Migration noch ein weiterer Klassiker:
Cloud vs. On-Premises Licensing.

Bei CVAD On-Prem + PVS + UHMC/Platform Licensing sollte kontrolliert werden, ob PVS tatsächlich auf On-Premises konfiguriert ist und die entsprechenden PVS_CCS / PVSD_CCS Entitlements vorhanden sind.

Mein aktueller PVS-2507-Licensing-Check sieht deshalb so aus:
✅ exakten PVS Build prüfen
✅ 2507.1 CU2 / bekannte Fixes berücksichtigen
✅ LAS Status und Entitlements kontrollieren
✅ Cloud vs. On-Premises prüfen
✅ PVS_CCS / PVSD_CCS kontrollieren
✅ NTP/Clock zwischen allen PVS-Servern vergleichen
✅ Stream Service nach Licensing-Änderungen berücksichtigen

Erst danach würde ich anfangen, den klassischen Weg über Ports, Firewall und License Server auseinanderzunehmen.

Das Interessante daran:
Die Fehlermeldung ist alt.
Die möglichen Ursachen dahinter sind es nicht.

Wer bei PVS 2507 einfach die alte CTX132198-Checkliste abarbeitet, kann die neueren LAS-/2507-spezifischen Ursachen leicht übersehen.