Schlagwort: Virtual Apps 74 Beiträge

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.

Finding in the Wild | SQL Server 2019 installiert – Citrix sagt trotzdem „SQL zu alt“

Beim Upgrade einer Citrix-Umgebung auf CVAD 2507 LTSR kann man über einen ziemlich unscheinbaren Stolperstein laufen.

Der SQL Server ist aktuell.
SQL Server 2019 wird verwendet.
Alles sieht sauber aus.
Und trotzdem scheitert das Citrix Site Upgrade aufgrund der SQL-Anforderungen.

Die Ursache kann in der Datenbank selbst liegen.
Ein SQL Server Upgrade hebt nämlich nicht automatisch den Compatibility Level bestehender Datenbanken an.

So kann die Umgebung beispielsweise aussehen:
SQL Server: 2019
Citrix Site DB: Compatibility Level 110
Citrix Monitoring DB: Compatibility Level 110
Citrix Logging DB: Compatibility Level 110

Und 110 bedeutet:
👉 SQL Server 2012

Der SQL Server lebt also 2019 – die Citrix-Datenbank denkt noch, wir hätten 2012. 😄

Schnell geprüft:
SELECT
name AS DatabaseName,
compatibility_level AS CompatibilityLevel
FROM sys.databases
ORDER BY name;

Die wichtigsten Levels:
110 = SQL Server 2012
120 = SQL Server 2014
130 = SQL Server 2016
140 = SQL Server 2017
150 = SQL Server 2019
160 = SQL Server 2022
170 = SQL Server 2025

Bei einem SQL Server 2019 kann der Compatibility Level beispielsweise angepasst werden mit:
ALTER DATABASE [CitrixSite]
SET COMPATIBILITY_LEVEL = 150;
GO

ALTER DATABASE [CitrixLogging]
SET COMPATIBILITY_LEVEL = 150;
GO

ALTER DATABASE [CitrixMonitoring]
SET COMPATIBILITY_LEVEL = 150;
GO

⚠️ Natürlich nicht einfach blind ausführen.

Vorher:
✅ Citrix-/SQL-Supportmatrix prüfen
✅ Datenbanken sichern
✅ tatsächliche DB-Namen kontrollieren
✅ Wartungsfenster verwenden
✅ anschließend Compatibility Level und Citrix Site testen

Und noch ein zweiter Punkt aus der Praxis:

Beim CVAD 2507 Site Upgrade sollte auch das verwendete SQL-/Upgrade-Konto geprüft werden. Fehlende Berechtigungen für notwendige Änderungen innerhalb der Citrix-Datenbanken können ebenfalls für interessante Fehlersuche sorgen.

Mein neuer Citrix Pre-Upgrade-Check
Vor einem größeren CVAD-Upgrade gehört deshalb für mich inzwischen neben Controller-, VDA-, StoreFront- und SQL-Version auch dieser kleine Query dazu:

SELECT name, compatibility_level
FROM sys.databases;

Dauert 10 Sekunden.

Kann einem aber eine ziemlich lange Fehlersuche während des Wartungsfensters ersparen.
Finding in the Wild. 🔎

Manchmal ist nicht der SQL Server zu alt.
Sondern nur die Datenbank, die vergessen hat, welches Jahr wir haben. 😄

Finding in the Wild | CWA CleanInstall & Teams SlimCore

Bei einem aktuellen Citrix Workspace App Update bin ich auf ein interessantes Verhalten im Zusammenspiel mit Microsoft Teams SlimCore gestoßen.

Auf dem Client war das Microsoft Teams VDI Plugin bereits installiert. Anschließend wurde die Citrix Workspace App im Rahmen des Updates mit /CleanInstall aktualisiert.

Danach sah zunächst alles sauber aus:
Citrix Workspace App ✔️
Teams VDI Plugin ✔️
Software Deployment ✔️

Trotzdem funktionierte die SlimCore Optimization nicht mehr.

Bei der Analyse zeigte sich: Die benötigten DLLs im ICA-Client-Verzeichnis waren nicht mehr vorhanden – das Teams VDI Plugin wurde unter „Apps & Features“ aber weiterhin als installiert angezeigt.

Genau das macht das Problem so interessant.

Wer bei einem automatisierten CWA-Update nur den Installationsstatus kontrolliert, bekommt ein grünes Deployment, obwohl die eigentliche Teams-Optimierung nicht mehr funktioniert.

Für meine Update-Tests bedeutet das:
CWA-Version → Teams VDI Plugin → DLLs → SlimCore → tatsächlicher Optimization Mode
müssen gemeinsam geprüft werden.

Gerade mit der zunehmenden Umstellung auf SlimCore sollte dieser Funktionstest meiner Meinung nach Bestandteil eines CWA-/Teams-Updates sein.

👉 Finding in the Wild: „Installed“ bedeutet nicht automatisch „Operational“.

Solche Dinge sind genau der Grund, warum ich Citrix-Updates nicht nur installiere, sondern anschließend auch die relevanten Funktionen überprüfe.

Finding in the Wild – ich bleibe dran.

Finding in the Wild | Windows Server 2025 – Published App geschlossen, Session bleibt

Bei einem aktuellen Citrix Virtual Apps Setup auf Windows Server 2025 bin ich auf ein interessantes Verhalten gestoßen:

Der Benutzer schließt seine Published Application ganz normal – die Citrix Session meldet sich aber nicht ab.

Teilweise bleibt die Session noch 1–2 Minuten aktiv.

Also habe ich mir genauer angesehen, was die Abmeldung eigentlich noch festhält.

Die eigentliche Anwendung war bereits beendet, trotzdem liefen innerhalb der User Session noch mehrere Prozesse weiter. Besonders auffällig:

ShellAppRuntime.exe

Der entscheidende Test:
ShellAppRuntime.exe beendet → Session meldet sich unmittelbar ab.

Damit hatte ich zumindest eine konkrete Spur.

🔍 Wo habe ich nachgeschaut?

Bei Seamless-/Published-App-Problemen lohnt sich ein Blick unter:

HKEY_USERS\<User-SID>\Software\CitrixVolatile\Seamless\Sessions\<Session-ID>\

Dort lässt sich nachvollziehen, welche Prozesse innerhalb der Seamless Session noch eine Rolle spielen.

Und genau das ist deutlich hilfreicher, als im Task Manager auf Verdacht Prozesse abzuschießen.

Interessant wird das Ganze vor allem auf Windows Server 2025: Das Verhalten lässt sich auch mit unterschiedlichen VDA-Versionen beobachten. Auf vergleichbaren Server-2022-Systemen erfolgt der Logoff dagegen innerhalb weniger Sekunden.

Besonders unschön wird das in Verbindung mit FSLogix oder Profile Containern:

Published App geschlossen

→ Session bleibt aktiv
→ Profile Container bleibt gemountet
→ Benutzer startet nächste App
→ VHDX möglicherweise noch gesperrt

Für mich ist deshalb ein neuer Testpunkt für Windows-Server-2025-Citrix-Umgebungen dazugekommen:

Nicht nur prüfen, ob eine Published App sauber startet – sondern auch, ob die Session nach dem Schließen tatsächlich sauber beendet wird.

Ob ShellAppRuntime.exe selbst die eigentliche Ursache oder nur ein Symptom eines tieferliegenden Windows-Server-2025-Verhaltens ist, muss ich noch weiter untersuchen.
Aber für die Fehlersuche war der Registry-Pfad der entscheidende Hinweis, um herauszufinden, warum die Abmeldung nicht erfolgt.

🔎 Finding from the Field – App geschlossen heißt nicht automatisch Session beendet.

Finding in the Wild | Citrix Workspace App 2603.11 x64

Ich bin über ein interessantes Problem mit der Citrix Workspace App 2603.11 in der nativen 64-Bit-Version gestolpert.

Und das ist besonders interessant, weil 2603.11 gleichzeitig einer der Builds ist, auf den Citrix aufgrund von CVE-2026-78546 und CVE-2026-78547 aktualisieren lässt.

Nach dem Update können unter bestimmten Bedingungen:
❌ Published Apps und Desktops nicht mehr starten
❌ Domain Pass-through Authentication gegen StoreFront fehlschlagen
❌ Benutzer plötzlich einen Credential Prompt erhalten

Die Ursache hängt mit einem fehlenden bzw. falschen Verweis auf die 64-Bit cck.dll zusammen.

Citrix hat dafür inzwischen einen Workaround dokumentiert:

Dort muss der folgende Wert vorhanden sein:
Name: X64
Type: REG_SZ
Value: C:\Program Files\Citrix\ICA Client\Receiver\cck.dll

Per Command Line:

Citrix plant den Fix für einen kommenden 2603-Release.

💡 Das Interessante daran:
Security sagt: Upgrade auf 2603.11 oder neuer.

Operations sagt: Nicht ohne Test – insbesondere bei StoreFront + Domain Pass-through.

Genau solche Kleinigkeiten sind es, die in einer Testumgebung schnell übersehen werden und anschließend beim breiten Client-Rollout richtig Spaß machen. 😉

Finding in the Wild: Wer aktuell auf CWA 2603.11 x64 geht, sollte App/Desktop Launch und Domain Pass-through explizit testen.