Microsoft Defender for Endpoint in VDI-Umgebungen

VDI-Umgebungen (Virtual Desktop Infrastructure) lassen Endnutzer von nahezu jedem Gerät aus auf zentral bereitgestellte virtuelle Desktops zugreifen – ohne dass die IT für jeden Nutzer physische Hardware bereitstellen und pflegen muss. Wie jedes andere System brauchen auch diese virtuellen Desktops einen EDR- und Antivirus-Schutz. Beim Onboarding in Defender for Endpoint (MDE) gelten dabei aber besondere Spielregeln – vor allem, wenn die Sessions non-persistent sind. Dieser Teil zeigt, wie du VDI-Instanzen sauber onboardest, welche Fallstricke beim Klonen und beim Image-Update lauern und wie du dich zwischen single-entry und multi-entry entscheidest.

Persistent vs. Non-Persistent

Bei der Onboarding-Strategie ist zuerst die Frage entscheidend, ob die VDI persistent oder non-persistent ist.

• Persistente VDI: Ein persistenter virtueller Desktop wird genau wie eine physische Maschine behandelt. Du onboardest ihn über die üblichen Wege – Gruppenrichtlinie, Microsoft Configuration Manager, Intune oder lokales Skript – mit dem normalen Onboarding-Paket aus dem Defender-Portal.
• Non-Persistente VDI: Hier wird die Session bei jeder Anmeldung neu aus einem Golden Image bereitgestellt und danach verworfen. Genau für diesen Fall gibt es im Portal ein eigenes Deployment-Verfahren: „VDI onboarding scripts for non-persistent endpoints".

Die typischen Herausforderungen non-persistenter Umgebungen sind:

• Sehr frühes Onboarding kurzlebiger Sessions – das Gerät muss praktisch beim Boot, noch während der Bereitstellung, an den Dienst angebunden werden.
• Wiederverwendung des Gerätenamens – neue Sessions bekommen oft denselben Hostnamen.

Non-persistente VDI-Sessions setzen mindestens Windows 10 1809 voraus. Für Windows Server 2016 und 2012 R2 muss zuerst das Installationspaket angewendet werden, bevor du onboarden kannst.

Single-Entry oder Multi-Entry?

Je nach gewählter Methode erscheinen die VDI-Instanzen im Defender-Portal auf zwei unterschiedliche Arten. Diese Entscheidung ist die wichtigste in diesem Kapitel:

• Single entry (ein Eintrag pro Gerät): Für jede VDI-Instanz existiert dauerhaft genau ein Objekt im Portal. Wird die Instanz gelöscht und mit demselben Hostnamen neu erstellt, entsteht kein neues Objekt – die Historie bleibt an einem Eintrag. Voraussetzung: Beim Erstellen der Session muss stets derselbe Gerätename vergeben werden (z. B. über eine Unattend-Answer-File).
• Multi entry (mehrere Einträge pro Gerät): Für jede Session entsteht ein eigenes Objekt. Das führt bei volatilen Umgebungen schnell zu vielen Duplikaten desselben physischen Ziels.

Microsoft empfiehlt für Umgebungen, in denen Hosts häufig gelöscht und neu bereitgestellt werden (etwa Azure Virtual Desktop), klar die single-entry-Methode. Sie hält die Investigation-Erfahrung im Kontext genau eines Geräts (basierend auf dem Maschinennamen) und verhindert Verwirrung bei der Incident-Analyse durch mehrere Objekte für dieselbe Maschine. Beim single-entry-Verfahren musst du die virtuellen Desktops zudem nicht offboarden.

Für alle VDI-Maschinen gilt beim allerersten Onboarding ein Client-Delay von rund 3–4 Stunden, bis sie vollständig im Dienst sichtbar sind.

Onboarding-Paket herunterladen

Das passende Paket holst du dir direkt im Portal:

1. Im Defender-Portal (security.microsoft.com) zu Settings → Endpoints → Device management → Onboarding navigieren.
2. Betriebssystem wählen (z. B. Windows 10 / Windows 11).
3. Als Deployment method den Eintrag „VDI onboarding scripts for non-persistent endpoints" auswählen.
4. Auf Download package klicken und die WindowsDefenderATPOnboardingPackage.zip speichern.

Das Archiv enthält – je nach Methode relevant – die folgenden Dateien:

• WindowsDefenderATPOnboardingScript.cmd – das eigentliche Onboarding-Skript.
• Onboard-NonPersistentMachine.ps1 – der PowerShell-Wrapper für das single-entry-Verfahren.

Skripte ins Golden Image einbetten

Der Kern des non-persistenten VDI-Onboardings: Das Skript wird als Startup-Skript im Golden Image hinterlegt, damit es bei jedem Boot einer frisch provisionierten Instanz sofort läuft.

Kopiere die Dateien aus dem entpackten Ordner in das Golden Image unter den Pfad:

C:\WINDOWS\System32\GroupPolicy\Machine\Scripts\Startup

Welche Dateien du kopierst, hängt von der gewählten Methode ab:

• Single entry: beide Dateien – Onboard-NonPersistentMachine.ps1 und WindowsDefenderATPOnboardingScript.cmd.
• Multi entry: nur WindowsDefenderATPOnboardingScript.cmd.

Wird der Ordner ...\Scripts\Startup nicht angezeigt, ist er vermutlich ausgeblendet. Aktiviere im Datei-Explorer die Option „Ausgeblendete Dateien und Ordner anzeigen".

Anschließend das Skript als Startup-Skript registrieren. Öffne dazu den Editor für lokale Gruppenrichtlinien und navigiere zu Computer Configuration → Windows Settings → Scripts → Startup:

Für das Onboarding non-persistenter VDIs lässt sich statt der lokalen auch eine Domain-Gruppenrichtlinie verwenden. Für Azure Virtual Desktop bietet sich zusätzlich eine zentral abgelegte Skriptdatei an, die per Immediate-Task-GPO ausgeführt wird.

Ausführungszeitpunkt und Execution Policy

Zwei Details entscheiden beim single-entry-Verfahren über Erfolg oder Duplikate:

• Führe Onboard-NonPersistentMachine.ps1 erst aus, nachdem die VM ihren finalen Hostnamen erhalten und ihren letzten Reboot abgeschlossen hat. Bei Provisioning-Prozessen mit mehreren Neustarts nach dem Klonen sollte das Skript also bis zum letzten Reboot warten. Läuft es zu früh, drohen doppelte oder inkonsistente Einträge.
• Das Skript Onboard-NonPersistentMachine.ps1 ist nicht signiert. In Umgebungen mit restriktiver Execution Policy brauchst du eine freigegebene Ausführungsmethode, z. B. -ExecutionPolicy Bypass.

Grundsätzlich gilt: Das Startup-Skript sollte so früh wie möglich im Boot-/Provisioning-Prozess laufen, um die Zeitspanne zwischen „Maschine nimmt Sessions an" und „Gerät ist im Dienst onboarded" klein zu halten.

Lösung testen

Microsoft empfiehlt einen einfachen Funktionstest, bevor du produktiv gehst:

1. Einen Pool mit einem Gerät erstellen.
2. Am Gerät anmelden.
3. Vom Gerät abmelden.
4. Mit einem anderen Konto erneut am Gerät anmelden.
5. Ergebnis prüfen: Bei single entry darf im Portal nur ein Eintrag erscheinen, bei multi entry entsprechend mehrere.

Kontrolle über Devices list im Portal: Gerätenamen eingeben und als Suchtyp Device wählen.

Stolperfalle Klonen: Template niemals onboarden

Der wichtigste Fehler in Klon-basierten Umgebungen (z. B. VMware Instant Clones oder ähnliche Technologien):

Stelle sicher, dass deine internen Template-VMs und Replica-VMs nicht in Defender for Endpoint onboarded sind.

Der Grund: Beim single-entry-Verfahren würden aus einem onboardeten Template geklonte Instanzen dieselbe senseGuid erben. Das verhindert, dass geklonte VMs als neue Einträge in der Device-Inventory auftauchen – die Sichtbarkeit für dein Security-Team bricht damit still zusammen.

Images aktualisieren

Ein onboardetes Primary-Image bringt dich in dieselbe Falle. Wenn du das Primary-Image, die Template-VM oder eine Replica-VM per single-entry onboardest, hindert das Defender for Endpoint daran, für neue non-persistente VDIs überhaupt Einträge zu erzeugen.

Ist der SENSE-Dienst im Primary-Image aktiv (also bereits onboarded), musst du das Image offboarden und die lokalen MDE-Registrierungsdaten bereinigen, bevor es wieder in Produktion geht:

1. Maschine offboarden.
2. Sicherstellen, dass das PsExec-Tool im Command-Prompt-Pfad verfügbar ist (es wird gebraucht, um eine Shell unter dem SYSTEM-Konto zu starten und die Registry zu bereinigen).
3. Prüfen, ob der Sensor noch läuft:

sc query sense

4. Anschließend die lokalen Registrierungsdaten über eine SYSTEM-Level-Shell zurücksetzen.

Einige der Registry-Löschbefehle können die Meldung „The system was unable to find the specified registry key or value" zurückgeben. Das ist erwartetes Verhalten, wenn der entsprechende Pfad schlicht nicht existiert, und kann ignoriert werden.

Antivirus für VDI konfigurieren

Nach dem Onboarding gehört auch die Next-Generation-Protection sauber eingestellt. Für Remote-Desktop- und VDI-Szenarien gibt es dazu eigene Empfehlungen von Microsoft – unter anderem zum Umgang mit Security-Intelligence-Updates in großen Session-Umgebungen, um Storage- und Netzwerklast beim gleichzeitigen Boot vieler Instanzen zu begrenzen. Die konkreten Werte findest du unter Configure Microsoft Defender Antivirus on a remote desktop or VDI environment.

Nächster Teil der Serie: MDE ausschalten & Offboarding.