Schlagwort: Virtual Apps 74 Beiträge

Finding in the Wild | Neue Edge Security Baseline – und plötzlich funktioniert eure Browser-Integration nicht mehr?

Microsoft hat die neue Security Baseline für Microsoft Edge 151 veröffentlicht.

Normalerweise klingt das erstmal nach:

Neue Version → neue ADMX → Baseline aktualisieren → fertig.

Diesmal würde ich bei Citrix- und RDS-Umgebungen aber etwas genauer hinschauen.

Microsoft nimmt mehrere neue Empfehlungen auf. Eine davon finde ich besonders interessant:

👉 Process Isolation

Was steckt dahinter?

Process Isolation soll verhindern, dass andere lokale Prozesse in Microsoft Edge eingreifen beziehungsweise Browserprozesse manipulieren.

Security-technisch absolut nachvollziehbar.

In Enterprise-Umgebungen gibt es allerdings genügend Software, die genau an dieser Stelle ansetzt.

Zum Beispiel:

DLP / Endpoint Security / SSO / Monitoring / Browser Integrations / Legacy Agents

Und jetzt wird es für Citrix interessant.

Auf einem normalen Client betrifft das einen Benutzer.

Auf einem Multi-Session VDA mit 30, 50 oder mehr Benutzern kann eine kleine Änderung an der Browser-Baseline plötzlich ziemlich viele Sessions gleichzeitig betreffen.

Typisches Szenario

Neue Edge ADMX werden ins Central Store übernommen.

Die neue Security Baseline wird auf die Citrix VDAs angewendet.

Edge startet.

Webseiten funktionieren.

Test erfolgreich?

Nicht unbedingt. 😉

Denn interessant wird es erst bei den Integrationen:

👉 Funktioniert SSO noch?
👉 Funktionieren DLP-/Security-Komponenten?
👉 Funktionieren Browser Extensions?
👉 Funktionieren interne Webanwendungen?
👉 Gibt es plötzlich Fehler oder ungewöhnliche Prozesse?

Noch ein Punkt: Automatic HTTPS

Microsoft empfiehlt außerdem, Automatic HTTPS zu evaluieren.

Auch das klingt erstmal sinnvoll.

Wer allerdings noch interne Anwendungen betreibt, die ausschließlich über HTTP erreichbar sind, sollte mit aggressiven Upgrade-Modi vorsichtig sein.

Gerade in älteren Citrix-Umgebungen findet man davon erfahrungsgemäß noch einige. 😎

Meine Empfehlung

Eine neue Browser Security Baseline gehört für mich deshalb nicht direkt auf das produktive Golden Image.

Erst:

Baseline Diff → Test-VDA → Security/SSO/DLP → interne WebApps → Multi-Session-Test → Produktion

Und wenn Process Isolation Probleme verursacht:

Nicht einfach die Policy wieder deaktivieren.

Erst herausfinden, welche Software eigentlich in den Browserprozess eingreifen möchte.

Denn vielleicht ist genau das das eigentliche Finding.

Fazit

Security Baselines sind keine Sammlung von Einstellungen, die man einfach auf Enabled stellt.

Gerade auf Citrix Multi-Session VDAs können kleine Browseränderungen eine ziemlich große Wirkung haben.

Hardening ohne Compatibility Testing ist eben auch nur eine andere Form von Troubleshooting-Vorbereitung. 😉

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.