Das ist keine Legacy-Anwendung, sondern eine aktuelle Anwendung.

Wenn sich eine Anwendung auf einem Multi-Session-Host nicht benimmt, nennen wir sie „Legacy“ und machen weiter. Dieses Wort leistet ziemlich viel Arbeit, die es sich nicht verdient hat.

Die Anwendung in diesem Projekt ist aktuell. Wird aktiv entwickelt, aktiv verkauft, bekommt regelmäßig Releases. Und sie legt ihre komplette Konfiguration – allen voran die Datenbankanbindung – in HKEY_LOCAL_MACHINE ab. Nicht pro Benutzer. Nicht pro Session. Einmal pro Maschine.

Auf einem Citrix VDA heißt das: Jeder Benutzer arbeitet gegen dieselbe Datenbank. Für eine Fachabteilung, die Produktion, QA und Entwicklung parallel braucht, ist das ein K.-o.-Kriterium. Der Kunde hatte bisher App-V im Einsatz, das ist abgekündigt, also musste Ersatz her. Der Reflex: Citrix App Layering – Entscheidung bereits gefallen, mit drei Ausrufezeichen.

Erst mal fragen, was wirklich weh tut

Bevor ich über Technologie spreche, setze ich mich mit der Fachabteilung zusammen, nicht mit der IT. Die Frage ist immer dieselbe: Was genau funktioniert nicht?

Die Antwort war präzise. Keine Isolation. Keine DLL-Konflikte. Keine parallelen Runtimes. Nur eine Handvoll Registry-Werte unter HKLM, die sich nicht pro Benutzer setzen lassen. Und, wie sich herausstellte: Die Anwendung lässt sich mehrfach unter unterschiedlichen Exe-Namen starten.

Das ist kein Application-Virtualization-Problem. Das ist ein Redirection-Problem – und App Layering ist darauf nicht die richtige Antwort.

Die Lösung: Citrix Profile Management App Access Control

Die meisten kennen App Access Control als „Anwendungen auf dem Golden Image ausblenden“ – die Citrix-Antwort auf FSLogix App Masking. Weniger bekannt ist die zweite Hälfte: Redirect-Regeln für Dateien, Ordner, Registry-Keys und -Werte, zugewiesen pro Benutzer, Maschine oder Prozess.

So läuft die Umleitung von HKLM nach HKCU:

1. Den Rule Generator for App Access Control findet ihr im Citrix Environment Tool Hub. Es gibt auch einen PowerShell-Weg – ihr habt jetzt davon gehört und dürft ihn direkt wieder vergessen.
2. Rule Generator starten → Create rule → Redirect → Registry Key.
3. Den umzuleitenden Key auswählen oder eintragen:
   HKLM\Software\MyApp\DB
   → HKCU\Software\MyApp\DB_Prod
   → HKCU\Software\MyApp\DB_QA
   → HKCU\Software\MyApp\DB_DEV.
4. Prozesse zuordnen: MyApp_Prod.exe, MyApp_QA.exe, MyApp_DEV.exe.
5. Die Citrix-Richtlinie App access control bearbeiten, die Rohdaten einfügen, aktivieren und speichern.
6. Die eigentlichen HKCU-Werte pro Benutzer über Gruppenrichtlinien-Einstellungen verteilen.

Fertig. Multiuserfähig – ohne Paketierung, ohne Sequencer, ohne zusätzliches Layer.

Weil der Kunde mehrere Datenbankstände betreibt, haben wir es eine Stufe weitergedreht: dieselbe Anwendung mehrfach veröffentlicht, und die Redirect-Regel zeigt je Prozess auf ein anderes Ziel. Eine Installation, mehrere Regelsätze, kein zweites Image.

Besser als FSLogix App Masking

FSLogix-Regeldateien liegen auf jedem Server oder im Master-Image; jede Änderung bedeutet Verteilung oder Rebuild.

Der Citrix-Regelsatz liegt zentral in der Richtlinie – anpassen, Rohdaten kopieren, einfügen. Und obendrauf: Der Rule Generator kann bestehende FSLogix-Regelsätze importieren.

Das Tool ist schlicht besser – aufgeräumte Kategorie-Ansicht und deutlich mehr Beschreibung dessen, was man da eigentlich tut.

Fazit

Ein Projekt, das nach Application Virtualization roch, ist am Ende auf ein paar Redirect-Regeln in einer Richtlinie hinausgelaufen.

Wie oft repariert ihr Design-Entscheidungen eines Herstellers mit Infrastruktur – und meldet ihr das jemals dorthin zurück?