Mit der Einführung der Azure v6 VM SKUs, also aller virtuellen Maschinen mit NVMe‑basierter temporärer Festplatte, hat Microsoft das Verhalten des Temp‑Laufwerks geändert. Im Gegensatz zu früheren VM‑Generationen wird das Temp‑Drive nicht mehr automatisch formatiert und initialisiert. Dieses neue Verhalten ist in der Microsoft‑Dokumentation beschrieben:
https://learn.microsoft.com/en-us/azure/virtual-machines/enable-nvme-temp-faqs
Gerade in Umgebungen mit Azure Virtual Desktop (AVD) kann das zu Problemen führen. Viele Konfigurationen setzen voraus, dass das Laufwerk D: direkt nach dem Start verfügbar ist – beispielsweise für das Pagefile, temporäre Daten oder Caching‑Mechanismen. Bei v6‑VMs ist das jedoch nicht mehr garantiert.
Was passiert, wenn das Pagefile konfiguriert ist, aber das Temp‑Drive fehlt?
Kurz zusammengefasst:
- Windows kann die Pagefile‑Konfiguration auf
D:nicht anwenden - Es wird ein Notfall‑Pagefile auf C: angelegt – oder im ungünstigsten Fall gar keines
- In AVD führt das zu Performance‑Problemen und instabilen Sessions
Genau deshalb ist es entscheidend, dass das Temp‑Laufwerk vor der Anwendung der Speicherverwaltung zuverlässig bereit steht.
Wie ich auf die Lösung gekommen bin
Mein MVP‑Kollege Julian Mooren hat mich auf dieses veränderte Verhalten aufmerksam gemacht und ein PowerShell‑Script entwickelt, das die Initialisierung des Temp‑Laufwerks bei NVMe‑basierten v6‑VMs zuverlässig sicherstellt. Sein Blogbeitrag beschreibt die technischen Hintergründe und Details sehr ausführlich
In diesem Artikel liegt mein Fokus weniger auf dem eigentlichen Script selbst, sondern vielmehr auf der Frage:
➡️ Wie lässt sich diese Logik sauber und zuverlässig in Nerdio Manager for Enterprise (NME) integrieren?
Warum keine Nerdio Scripted Actions?
Nerdio Scripted Actions sind ein mächtiges Werkzeug, für dieses Szenario aber nur bedingt geeignet:
- Scripted Actions werden nicht automatisch bei jedem VM‑Start ausgeführt, sondern als Custom Script Extension übergeben, und dann auf dem Session Host ausgeführt. Eine Ausführung bei jedem Boot wäre zu langsam und würde den Start verzögern.
- Das Temp‑Laufwerk wird bei jedem Start neu erzeugt, nicht im Golden Image. Eine Konfiguration im Image löst das Problem daher nicht
Da die Initialisierung des Temp‑Drives bei jedem Bootvorgang sicherzustellen ist, war ein anderer Ansatz notwendig.
Lösung: Einsatz einer Nerdio Shell App
Anstelle der Scripted Action habe ich eine Nerdio Shell App umgesetzt. Eine Shell App erlaubt es, die notwendigen Ressourcen und Konfigurationen während des Provisionings auf dem Session Host bereitzustellen und einzurichten. Damit lässt sich der geplante Task auf dem Session Host einrichten, welcher das Script bei jedem Start des Session Hosts ausführt. Da das Script schon auf dem Session Host vorhanden ist, muss keine Custom Script Extension mehr ausgeführt werden.
Die Shell App besteht aus vier Teilen:
- Detection Script
Prüft, ob die Temp‑Drive‑Initialisierung bereits installiert ist. - Install Script
Kopiert das eigentliche Script auf den Session Host und richtet eine geplante Aufgabe ein. - Uninstall Script
Formell vorhanden, in AVD‑Umgebungen jedoch kaum relevant, da Session Hosts in der Regel neu erstellt und nicht die Shell Apps „deinstalliert“ werden. - Main Script
Das Initialisierungs‑ und Self‑Healing‑Script basiert auf Julians Lösung und wurde etwas angepasst.
Der vollständige Code ist öffentlich verfügbar: https://github.com/alphasteff/nerdio-scripted-actions-public/tree/2dddedc21fb8e320559bc3fd4382d8cea3bc5ccb/shellapps-scripts/Self-Healing%20Pagefile
Meine Erweiterungen am Script
Ich habe das Script an einigen Stellen erweitert und Anpassungen vorgenommen, damit ich dies auch bei meinen Kunden verwenden kann (ich nutze eine andere Methode der Bereitstellung):
- Umbenennung des Error‑Switches auf -IsError
- Ergänzung eines Warning‑Levels mit -IsWarning
- Neuer Log‑Pfad: C:\Windows\Logs\AVDPagefileSetup\
- Aktualisierte Deployment‑Prüfung von CSECompleted auf DeploymentCompleted
- Erweiterte Service‑Behandlung:
- Prüfung, ob Services existieren
- Berücksichtigung von Disabled / Manual / Automatic
- Verbesserte und nachvollziehbare Logs
- Sicherheitshärtung des Temp‑Laufwerks:
- Entfernen von Users und Authenticated Users auf D:
- Stabilere Initialisierung von Marker‑Werten bei fehlenden Einträgen
- Vorziehen des Stoppens bestimmter Services, um Race Conditions während der Initialisierung zu vermeiden
Wichtigste Erweiterung
➡️ Benutzer erhalten keine Schreibrechte mehr auf dem Temp‑Laufwerk.
Das erhöht die Sicherheit deutlich und reduziert das Risiko von Missbrauch oder unerwünschten Schreibzugriffen auf das NVMe‑basierte Temp‑Drive.
Meine Anpassungen habe ich auch Julian zur Verfügung gestellt, damit sie in seine ursprüngliche Lösung einfließen können.
Warum das besonders für AVD relevant ist
In AVD‑Umgebungen sind Konsistenz und Vorhersehbarkeit entscheidend. Das Temp‑Laufwerk:
- Wird bei jedem VM‑Start neu erzeugt
- Muss früh im Bootprozess verfügbar sein
- Wird häufig für Pagefiles und Performance‑Optimierungen genutzt
- Darf keine unsicheren Standard‑Berechtigungen enthalten
Durch die Kombination aus Nerdio Shell App und dem erweiterten Initialisierungs‑Script wird sichergestellt:
✅zuverlässige Initialisierung des Temp‑Drives
✅saubere und sichere Berechtigungen
✅stabile Pagefile‑Konfiguration
✅automatisches Self‑Healing bei jedem Start
✅einheitliches Verhalten über alle Session Hosts hinweg
Fazit
Die Azure v6 VM SKUs bringen dank NVMe‑Storage erhebliche Performance‑Vorteile, erfordern jedoch neue Konzepte im Betrieb. Die automatische Initialisierung des Temp‑Laufwerks ist dabei kein optionales Feature, sondern eine zwingende Voraussetzung für stabile AVD‑Umgebungen.
Mit einer Nerdio Shell App und einem robusten Initialisierungs‑Script lässt sich dieses Verhalten sauber, sicher und automatisiert umsetzen.
➡️ Wer AVD auf v6‑VMs betreibt, sollte diese Lösung fest einplanen.