Schlagwort: Virtual Apps 74 Beiträge

Finding in the Wild | Hohe CPU durch Citrix Workspace App?

Ein Blick auf receiver.exe lohnt sich.

In letzter Zeit höre ich häufiger von ungewöhnlich hoher CPU-Auslastung im Zusammenhang mit der Citrix Workspace App.

Tatsächlich hat Citrix ein entsprechendes Problem offiziell dokumentiert:

RFWIN-41567

Auf Windows Server 2022 konnte receiver.exe in bestimmten Installationen eine erhöhte CPU-Auslastung verursachen.

Der Fix ist seit Citrix Workspace App 2603.10 enthalten.

Gerade auf Server-Systemen, Jump Hosts oder in Double-Hop-Szenarien kann das schnell zum Performance-Problem werden.

Wichtig: Bei hoher CPU würde ich nicht automatisch von diesem Bug ausgehen. Erst prüfen:

– Welcher CWA-Prozess verursacht die Last?
– Welche Workspace-App-Version läuft?
– Dauerhafte oder periodische CPU-Spikes?
– Läuft gerade ein Store Refresh?
– Sind Teams/Webex/Zoom-Optimierungen beteiligt?
– Welchen Einfluss haben AV/EDR/DLP?

Meine Empfehlung:
Läuft CWA auf Windows Server 2022 und receiver.exe verursacht auffällig hohe CPU-Last, zuerst die Version prüfen. Bei Builds vor 2603.10 einen aktuellen unterstützten Build in einer Pilotgruppe testen.

Hier ist es nicht nur ein Community-Phänomen – Citrix hat den Fehler offiziell bestätigt und behoben.

Finding in the Wild | Citrix MCS + Nutanix AHV – nicht mehr als 10 VMs pro Batch

Gestern bin ich bei einem Citrix-MCS-Projekt mit Nutanix AHV / Prism Central über ein interessantes Verhalten gestolpert.

Beim Hinzufügen einer größeren Anzahl von VMs zu einem MCS Machine Catalog kann der Vorgang mit einem:

OutOfMemory

fehlschlagen.

Erst dachte ich natürlich an Ressourcen auf Nutanix oder der Citrix-Infrastruktur. Tatsächlich ist das Problem aber bei Citrix bekannt und unter PMCS-58254 dokumentiert.

Citrix empfiehlt aktuell ausdrücklich:

👉 Maximal 10 VMs gleichzeitig zu einem MCS-Katalog hinzufügen.

Der Workaround ist entsprechend simpel: Bei größeren Rollouts die Maschinen in Batches von maximal 10 VMs erstellen.

Interessant dabei: Das Problem ist nicht nur im neuen Release dokumentiert, sondern findet sich auch bei 2507 LTSR sowie Citrix DaaS.

Wieder so ein kleines Citrix-Detail, das einem bei 5 VMs nie auffällt – bei einem größeren Rollout aber plötzlich ziemlich viel Zeit kosten kann. 😉

Finding in the Wild | PVS + Secure Boot: Ein kleines CU2-Feature, das 2026 ziemlich wichtig werden könnte

Citrix Provisioning 2507.1 LTSR CU2 ist da.

Und zwischen den üblichen Fixes steckt eine Änderung, die ich für PVS-Umgebungen deutlich interessanter finde als die Versionsnummer vermuten lässt:

👉 Support für Microsoft Windows UEFI CA 2023

Warum ist das wichtig?

Microsoft erneuert aktuell die Zertifikatskette hinter UEFI Secure Boot. Die bisherigen Secure-Boot-Zertifikate stammen teilweise noch aus 2011 und Microsoft migriert Windows schrittweise auf die neuen 2023 Certificates.

Und genau hier wird es für Citrix PVS interessant.

PVS muss die neue Secure-Boot-Welt verstehen

Mit PVS 2507.1 LTSR CU2 unterstützt Citrix jetzt Secure Boot mit Images, die über das neue Windows UEFI CA 2023 Certificate signiert sind.

Das klingt zunächst nach einem kleinen Compatibility-Fix.

Ist es aber nicht unbedingt.

Wer PVS kennt, weiß:

💥 Wenn die Boot Chain nicht stimmt, gibt es keine Citrix Session.

Dann diskutieren wir nicht mehr über Login Duration, Profile oder HDX Performance.

Dann bootet das Target schlicht nicht.

Noch eine interessante Änderung

PVS erkennt beim Start eines Target Devices jetzt automatisch, ob das System über:

BIOS oder UEFI

gebootet wurde.

Diese Information wird am Device Record gespeichert und steht zusätzlich über die Farm-Telemetrie zur Verfügung.

Gerade bei größeren oder historisch gewachsenen PVS-Farmen finde ich das ziemlich praktisch.

Denn dort findet man erstaunlich häufig unterschiedliche Firmware- und Boot-Konfigurationen.

Was würde ich jetzt prüfen?

Wer PVS + Windows 11 oder Windows Server 2025 + Secure Boot einsetzt, sollte CU2 definitiv auf dem Radar haben.

Vor einem Rollout würde ich insbesondere testen:

👉 Secure Boot + Windows UEFI CA 2023
👉 Target Device Boot
👉 PXE / BDM
👉 bestehende vDisks
👉 Hypervisor Firmware / UEFI Configuration
👉 Boot nach vDisk Version Promotion
👉 Failover auf einen zweiten PVS Server

Denn genau bei solchen Änderungen gilt:

„Die vDisk funktioniert seit Jahren“ ist keine Garantie dafür, dass auch die zukünftige Secure-Boot-Chain funktioniert.

Mein Fazit

PVS 2507.1 CU2 ist für mich deshalb nicht einfach nur:

„Noch ein Cumulative Update mit ein paar Bugfixes.“

Der Support für Windows UEFI CA 2023 ist ein klassisches Future-Proofing-Thema.

Microsoft verändert die Secure-Boot-Trust-Chain.

Citrix zieht mit PVS nach.

Und spätestens wenn ein Target nach einem Windows-/Secure-Boot-Update nicht mehr startet, wird aus einem unscheinbaren Release-Note-Eintrag plötzlich ein ziemlich wichtiges Feature. 😎

Finding in the Wild | Citrix Admins: Wie viele eurer PowerShell-Skripte verwenden noch Get-BrokerMachine?

Vermutlich mehr, als euch lieb ist.

Wer eine Citrix Virtual Apps and Desktops Umgebung schon etwas länger betreibt, kennt das Cmdlet:
Get-BrokerMachine

Es steckt in unzähligen:
👉 Health-Check-Skripten
👉 Monitoring-Lösungen
👉 Automatisierungen
👉 Reporting-Skripten
👉 Scheduled Tasks
👉 eigenen Admin-Tools

Mit CVAD 2507 LTSR hat Citrix Get-BrokerMachine allerdings als deprecated markiert.

Der vorgesehene Nachfolger lautet:
Get-BrokerMachineV2

Warum sollte mich das interessieren?
Deprecated bedeutet zunächst einmal nicht, dass das Cmdlet morgen nicht mehr funktioniert.

Und genau deshalb werden solche Änderungen gerne ignoriert.

Das Problem kommt meistens später.

Das nächste CVAD Upgrade wird durchgeführt, alles sieht gut aus – und irgendwann funktioniert ein zehn Jahre altes PowerShell-Skript plötzlich nicht mehr.

Dann beginnt die Suche:
„Was hat sich eigentlich geändert?“

Dabei stand die Antwort möglicherweise schon mehrere Releases vorher in der Deprecation List.

Jetzt ist der richtige Zeitpunkt zum Prüfen

Ich würde deshalb nicht warten, bis Citrix das Cmdlet tatsächlich entfernt.

Einmal durch die eigenen Citrix-Skripte suchen nach:
Get-BrokerMachine

und prüfen:
Kann ich das bereits auf Get-BrokerMachineV2 umstellen?

Besonders interessant sind dabei Skripte, die automatisiert laufen.

Denn ein interaktives Admin-Skript fällt relativ schnell auf.

Ein Scheduled Task, der seit Jahren jede Nacht Reports erzeugt oder Maschinenzustände verarbeitet?

Der kann auch mal einige Tage kaputt sein, bevor jemand merkt, dass etwas fehlt. 😎
Und es betrifft nicht nur Get-BrokerMachine

Auch andere ältere Citrix PowerShell-Funktionen werden schrittweise deprecated.
Ein weiteres Beispiel aus CVAD 2507 ist:
Repair-AcctADAccount

Deshalb gehört für mich zu einem Citrix Upgrade inzwischen nicht nur:
Supported OS → Hypervisor → SQL → VDA → StoreFront

sondern auch:
Welche eigenen Automatisierungen hängen eigentlich an der Citrix PowerShell API?

Meine Empfehlung
Vor dem nächsten CVAD-Upgrade:
👉 PowerShell-Repositories nach deprecated Cmdlets durchsuchen
👉 Scheduled Tasks kontrollieren
👉 Monitoring- und Health-Check-Skripte berücksichtigen
👉 eigene Admin-Tools nicht vergessen
👉 Ersatz-Cmdlets im Lab testen

Alte Automatisierungen haben eine unangenehme Eigenschaft:
Sie funktionieren jahrelang hervorragend – bis zu dem Tag, an dem sie es nicht mehr tun.

Und dann natürlich meistens während eines Upgrades.

Finding in the Wild | Eine Citrix Site umbenennen – was soll schon passieren?

Eigentlich eine ziemlich harmlose Änderung.

Der Name einer Citrix Site soll angepasst werden.

Kein VDA-Update.
Kein StoreFront-Upgrade.
Keine Änderung am NetScaler.

Nur ein neuer Site Name.

Was soll da schon schiefgehen? 😎

Mehr als man denkt.

💥 StoreFront verliert Optimal HDX Routing

Citrix hat mit StoreFront 2507 LTSR CU2 einen interessanten Fehler behoben:

Beim Umbenennen einer Citrix Site konnte die bestehende Optimal HDX Routing Configuration in StoreFront gelöscht werden.

Und damit wird aus einer vermeintlich kosmetischen Änderung plötzlich ein Networking-Thema.

Optimal HDX Routing entscheidet schließlich darüber, über welchen NetScaler Gateway der ICA-/HDX-Traffic zu einer bestimmten Citrix Site beziehungsweise Zone geleitet wird.

Ist diese Zuordnung weg, kann sich der Session-Pfad verändern.

Im schlechtesten Fall bedeutet das:

StoreFront funktioniert.

Die Anwendung wird angezeigt.

Der Benutzer klickt auf Start.

Und trotzdem läuft der ICA-Traffic anschließend nicht mehr über den vorgesehenen Gateway-Pfad – oder der Launch funktioniert überhaupt nicht mehr wie erwartet.

Genau deshalb mag ich solche Findings

Bei einem StoreFront-, NetScaler- oder CVAD-Upgrade erwartet jeder Auswirkungen und plant entsprechende Tests.

Aber bei:

„Wir ändern nur den Namen der Site.“

denkt kaum jemand an Optimal HDX Routing.

Und genau diese vermeintlich kleinen Änderungen sind häufig die interessanten.

Betroffen?

Citrix hat das Verhalten mit StoreFront 2507 LTSR CU2 behoben.

Wer noch einen älteren 2507-LTSR-Stand betreibt und Optimal HDX Routing verwendet, sollte das bei einem Site Rename berücksichtigen.

Meine Empfehlung

Vor einem Site Rename:

👉 StoreFront-Konfiguration sichern
👉 Optimal HDX Routing dokumentieren
👉 Gateway-Zuordnungen prüfen
👉 nach der Änderung einen echten ICA Launch durchführen
👉 ICA-/Gateway-Pfad verifizieren

Und natürlich:

StoreFront 2507 LTSR CU2 einplanen.

Fazit

Wieder ein schönes Beispiel dafür, dass eine Änderung in Citrix nicht unbedingt dort Auswirkungen haben muss, wo man sie durchführt.

Site Name geändert → StoreFront Routing weg → ICA Traffic nimmt plötzlich einen anderen Weg.

Finding in the Wild. 🕵️‍♂️

Oder anders gesagt:

Never assume an administrative change is just cosmetic. 😉