Workspace Environment Management Archive

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.

Finding in the Wild | Citrix WEM – Backup vorhanden, Restore unmöglich!

Ein unangenehmes Szenario bei Citrix Workspace Environment Management:

Die WEM-Konfiguration wurde vor dem Upgrade ordnungsgemäß gesichert. Nach der Aktualisierung soll ein älteres Configuration Set wiederhergestellt werden.

Doch plötzlich schlägt der Restore fehl.

❌ Unable to restore. Try again later.
❌ Beim Upload erscheint invalid content
❌ Das Backup stammt aus einer älteren WEM-Version
❌ Ein erneuter Import führt zum gleichen Ergebnis

🔍 Root Cause – WEM-54462

Citrix dokumentiert einen Kompatibilitätsfehler zwischen älteren WEM-Konfigurationsbackups und dem neuen Schema.

Betroffen sind insbesondere:

* Backup erstellt vor WEM 2.44 (Schema 2605 oder älter)
* Restore in WEM 2.44 oder neuer (Schema 2606 oder neuer)

Backups, die bereits mit Schema 2606 oder neuer erstellt wurden, lassen sich dagegen regulär wiederherstellen.

Das Problem liegt also nicht zwangsläufig an einer beschädigten Backup-Datei, sondern an der Verarbeitung älterer Backupformate.

🛠️ Mein Troubleshooting-Ansatz

Zuerst prüfe ich die Herkunft des Backups und die Version der Zielumgebung.

Anschließend kontrolliere ich:

1. Ist die JSON-Datei syntaktisch gültig?
2. Wurde das Backup vor oder nach dem Schemawechsel erstellt?
3. Funktioniert der Restore eines aktuellen Backups?
4. Tritt der Fehler bereits beim Upload oder erst beim Restore auf?

So lässt sich ein beschädigtes Backup von einer Versionsinkompatibilität unterscheiden.

✅ Sichere Migrationsstrategie

Mein bevorzugter Ansatz:

1. Originalbackup unverändert sichern.
2. Bestehende WEM-Konfiguration zusätzlich dokumentieren.
3. Wiederherstellung ausschließlich in einer isolierten Testumgebung prüfen.
4. Bei einem älteren Backup den offiziellen Citrix-Support-Workaround anfordern.
5. Nach erfolgreicher Migration ein neues Backup im aktuellen Schema erstellen.
6. Restore und Konfigurationszuweisungen vor der Produktivübernahme validieren.

Wichtig: Keine manuellen Änderungen an der JSON-Struktur und keine ungeprüften Schema-Manipulationen in der Produktivumgebung.

🛠️ Citrix Support Workaround

Citrix führt den Fehler unter WEM-54462 und verweist für ein entsprechendes Workaround-Skript ausdrücklich an den technischen Support.

Ein allgemeingültiges, öffentlich dokumentiertes Skript gibt es dafür nicht.

💡 Mein Fazit

Ein erfolgreich erstelltes Backup ist noch kein Nachweis für eine funktionierende Wiederherstellung.

Gerade bei WEM-Upgrades gehört deshalb nicht nur der Export, sondern auch ein getesteter Restore zur Migrationsplanung.

Backup erfolgreich ≠ Restore garantiert.

Finding in the Wild | Manchmal kommen alte Citrix-Probleme einfach wieder.

Aktuell bin ich bei WEM 2507 CU1 auf non-persistent VDAs über ein Verhalten gestolpert, das mir ziemlich bekannt vorkam.

Und ja – ich habe das Verhalten selbst gesehen.

Der VDA startet sauber, registriert sich und sieht auf den ersten Blick völlig gesund aus.
Aber der WEM Agent Cache wird nicht sauber initialisiert und die WEM-Konfiguration greift entsprechend nicht zuverlässig.

Interessanterweise sieht man aktuell auch in der Community ähnliche Fälle:

Golden Image → WEM funktioniert ✅
Provisionierter VDA → WEM Cache Problem ❌
Cache Reinitialize → WEM funktioniert wieder ✅

Laut einem Community-Bericht vermutete Citrix Support ebenfalls ein Timing-Problem beim Start: VDA und WEM Agent kommen hoch, bevor die lokale WEM Cache DB sauber initialisiert wurde.

Das Spannende daran:
Das Thema ist eigentlich überhaupt nicht neu.
Bereits 2017 hat BIS-F einen WEM Cache Refresh beim Systemstart eingeführt.
Später kam eine Funktion hinzu, die ich bei non-persistent Images besonders interessant finde:
“Move WEM Agent Cache to the PVS or MCSIO persistent disk”

Damit landet der WEM Cache nicht auf der non-persistent Systemdisk, sondern beispielsweise hier:

PVS/MCSIO CacheDisk
↓
Citrix
↓
WEMCache

Zusätzlich kann BIS-F beim Systemstart beispielsweise:

-RefreshCache -RefreshSettings -RefreshCache -Reinitialize

ausführen.

Genau diese Funktion hatte ich ehrlich gesagt lange nicht mehr groß auf dem Radar – bis ich das Verhalten jetzt selbst wieder gesehen habe.

Für mich deshalb ein guter Reminder:
Nur weil ein alter Workaround irgendwann nicht mehr notwendig erschien, heißt das nicht, dass die dahinterliegende Architektur keine Rolle mehr spielt.

Gerade bei PVS/MCSIO + WEM + non-persistent VDAs würde ich deshalb den WEM Cache und dessen Persistenz wieder mit in den Health Check aufnehmen.

Eine öffentliche Citrix Bug-ID, die das aktuelle Verhalten explizit WEM 2507 CU1 zuordnet, habe ich bislang übrigens nicht gefunden. Deshalb bleibt es zunächst genau das:

Finding in the Wild. 🔎

Installation von Workspace Environment Management

Workspace Environment Management optimiert die Citrix Worker für die bestmögliche Leistung (Benutzerdichte, Anmeldezeit und Anwendungsreaktionszeit).

WEM unterliegt dem Current Release Lifecycle (Additional Component) und daher gibt es von WEM keine LTSR Version.

Um WEM nutzen zu können muss eine aktive Customer Success Services (CSS) für eine der folgenden Lizenzen vorliegen:

Citrix Virtual Apps Advanced
Citrix Virtual Apps Premium
Citrix Virtual Apps and Desktops Advanced
Citrix Virtual Apps and Desktops Premium
Citrix Workspace Premium
Citrix Workspace Premium Plus

Technische Übersicht

Workspace Environment Management (WEM) beruht auf der folgenden Architektur:

WEM Administration Console – Teil 1 (Actions, Filters & Assignments)

Aktuelle Version ist Workspace Environment Management 2206.

Bekannte Probleme

Wenn VUEMRSAV.exe verwendet wird, um Ergebnisse zu Aktionen anzuzeigen, die über eine Aktionsgruppe für den aktuellen Benutzer angewendet wurden, zeigt die Registerkarte Applied Actions möglicherweise die falsche Quelle der Aktionen an. [WEM – 20002]