Schlagwort: Virtual Desktop 69 Beiträge

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.

Finding in the Wild | Citrix CVAD 2603: MCSIO-Treiber prüfen

Citrix dokumentiert für CVAD 2603 einen Known Issue bei Machine Catalogs mit MCS I/O Storage Optimization.

Fehlt der Citrix MCS I/O Driver im Master Image, kann ein späteres Update des Machine Catalogs auf einen neuen Snapshot fehlschlagen. Das Tückische: Die VDA-Installation selbst kann zunächst erfolgreich wirken.

Empfehlung

Vor einem produktiven Catalog-Update prüfen:

– MCSIO ist im Catalog aktiviert
– Der MCS-I/O-Treiber ist im Master Image installiert
– Das Image wurde in einem Test-Catalog veröffentlicht
– Ein funktionierender Rollback-Snapshot ist vorhanden

Ein registrierter VDA ist noch kein vollständig validiertes MCS-Image.

Finding in the Wild | StoreFront + Entra ID wird ernsthaft interessant

Bei einem aktuellen Citrix-Projekt bin ich über eine Entwicklung gestolpert, die für zukünftige StoreFront-Architekturen ziemlich spannend wird.

StoreFront kann Microsoft Entra ID inzwischen direkt über die Management Console konfigurieren.

Besonders interessant wird es bei hybriden Umgebungen:

-> Hybrid-Benutzer können Ressourcen aus Citrix DaaS und On-Premises CVAD über StoreFront bereitgestellt bekommen.

-> Ab CVAD 2603 unterstützt StoreFront Entra-ID-SSO zu veröffentlichten Ressourcen, sofern die VDAs entsprechend Hybrid Entra ID Joined sind.

-> Noch spannender: Entra SSO und FAS können innerhalb desselben Stores parallel verwendet werden.

StoreFront entscheidet anhand des Logon Type der jeweiligen Delivery Group, welches Authentifizierungsverfahren für den Ressourcenstart verwendet wird.

Damit lässt sich beispielsweise eine Umgebung schrittweise modernisieren, ohne FAS direkt aus dem Design werfen zu müssen.

Was ich daraus für neue Designs mitnehme

Ich würde künftig bereits in der Designphase eine Authentifizierungsmatrix erstellen:

Delivery Group → VDA Join State → Authentication Method → SSO Method

Zum Beispiel:

• klassische AD-VDAs → FAS
• Hybrid Entra ID Joined VDAs → Entra SSO
• DaaS Workloads → passend zum jeweiligen Identity Design

Gerade bei größeren Hybrid-Umgebungen verhindert das später einiges an Chaos.

Für mich ist das ein weiterer Schritt dahin, dass StoreFront auch in modernen Entra-ID-/DaaS-Architekturen wieder deutlich interessanter wird – und nicht zwangsläufig nur als Bestandteil klassischer On-Prem-CVAD-Umgebungen betrachtet werden sollte.

Finding in the Wild | Nur der erste User nach dem VDA-Reboot hat ein Problem

Ein interessantes Verhalten bei Windows Server 2025 + Citrix VDA + Citrix Profile Management (CPM):

Nach einem Neustart des VDAs meldet sich der erste Benutzer an – und plötzlich starten die eigentlich automatisch vorgesehenen Anwendungen nicht.

Betroffen können dabei verschiedene Autostart-Mechanismen sein:

HKLM\…\Run ❌
HKCU\…\Run ❌
Startup Folder ❌

Das Kuriose:

Sobald sich ein Benutzer einmal angemeldet hat, funktionieren die Autostarts bei allen folgenden Sessions wieder völlig normal.

Bis zum nächsten Reboot.

🔍 Wo würde ich bei so einem Fehler suchen?

Das Verhalten wurde in der Praxis auf Citrix Profile Management eingegrenzt. Ohne CPM funktionierte der erste Login nach dem Reboot wieder korrekt.

Eine interessante Spur führt dabei zu:

Dieser Bereich kann über das Benutzerprofil persistiert werden und spielt beim Session-/Explorer-Verhalten eine Rolle.

Damit ergibt sich ein Fehlerbild, das bei MCS- oder PVS-Umgebungen besonders leicht übersehen werden kann:

VDA rebootet
→ erster User meldet sich an
→ Startup Apps fehlen
→ zweiter User testet
→ alles funktioniert
→ Problem scheinbar verschwunden.

Genau solche Fehler finde ich spannend, weil ein klassischer Citrix Smoke Test sie sehr leicht übersieht.

💡 Mein Take-away

Bei Windows Server 2025 würde ich nach einem Image-Update oder VDA-Reboot inzwischen bewusst auch den allerersten Benutzer-Login testen.

Nicht nur:

VDA Registered ✔️
Login funktioniert ✔️
Published App startet ✔️

sondern auch:

Run Keys ✔️
Startup Folder ✔️
WEM Actions ✔️
CPM/Profile Processing ✔️

Denn manchmal macht es einen entscheidenden Unterschied, ob man der erste oder der zweite Benutzer auf dem VDA ist.

⚠️ Aktuell ist das ein Finding from the Field und kein genereller Windows-Server-2025-/CPM-Fehler. Ich würde daraus also noch keine allgemeine Produktregression ableiten.

Finding in the Wild | Citrix WEM – Wenn ein Benutzer die Anwendungen anderer Benutzer blockiert

Ein ungewöhnliches Fehlerbild auf Citrix Multi-Session-VDAs:

Anwendungen funktionieren zunächst problemlos. Ein weiterer Benutzer meldet sich am selben Session Host an – und plötzlich lassen sich bestimmte Anwendungen in bereits bestehenden Sitzungen nicht mehr starten.

❌ Anwendungen werden unerwartet blockiert
❌ Unterschiedliches Verhalten auf identisch konfigurierten VDAs
❌ Der Fehler tritt scheinbar zufällig auf
❌ Ein erneuter Login kann das Verhalten verändern

🔍 Root Cause: WEM Application Security + Windows AppLocker

Citrix WEM kann Application-Security-Regeln benutzerbezogen zuweisen.

Windows AppLocker arbeitet jedoch mit einer maschinenweiten Richtlinie.

Ist in WEM der Enforcement Mode Overwrite aktiviert, kann die Anmeldung eines weiteren Benutzers die bisherige AppLocker-Richtlinie ersetzen.

Fehlen in der neuen Richtlinie zuvor vorhandene Allow-Regeln, werden Anwendungen plötzlich blockiert – auch für Benutzer, die längst angemeldet sind.

🛠️ Mein Troubleshooting-Ansatz

Zuerst prüfe ich die AppLocker-Ereignisse auf dem betroffenen VDA:

* Event ID 8004 – EXE/DLL blockiert
* Event ID 8007 – Script/MSI blockiert
* Event ID 8001 – AppLocker-Richtlinie angewendet

Danach exportiere ich die effektiven AppLocker-Regeln:

Get-AppLockerPolicy -Effective -Xml

Besonders aufschlussreich ist der Vergleich vor und nach der Anmeldung eines weiteren Benutzers.

In den WEM-Agent-Logs suche ich nach:

AgentHostProxyService.ProcessAppLockerRules()

und:

Mode Overwrite will be applied

✅ Die Lösung

In WEM Application Security den Rule Enforcement Mode von Overwrite auf Merge umstellen.

Damit werden Regeln unterschiedlicher Benutzer zusammengeführt, statt bei jeder Anmeldung die vorhandene Richtlinie zu ersetzen.

Wichtig: Vorher bestehende AppLocker-Regeln auf unerwünschte Freigaben prüfen. Merge darf nicht dazu führen, dass Anwendungen ungewollt erlaubt werden.

💡 Mein Fazit

Wenn Anwendungen auf einem Citrix Session Host plötzlich blockiert werden, muss die Ursache nicht bei der Anwendung selbst liegen.

Manchmal reicht die Anmeldung eines anderen Benutzers, um die effektive Sicherheitsrichtlinie zu verändern.

Multi-Session-Betrieb und maschinenweite Sicherheitsrichtlinien sind eine Kombination, die man bei WEM unbedingt berücksichtigen sollte.