Microsoft Defender for Endpoint: Onboarding – Grundlagen & Voraussetzungen

Bevor ein Gerät in Microsoft Defender for Endpoint (MDE) Warnungen liefert und im Portal auftaucht, muss es angebunden werden – das sogenannte Onboarding. Der eigentliche Onboarding-Vorgang ist schnell erledigt, doch die häufigste Fehlerquelle liegt nicht beim Skript, sondern bei den Voraussetzungen. Wer die Reihenfolge einhält – erst Voraussetzungen und Netzwerk prüfen, dann mit dem Client Analyzer validieren und erst danach die Onboarding-Methode wählen – erspart sich langwierige Fehlersuche mit Geräten, die nicht oder nur teilweise Daten senden.

Dieser Artikel behandelt die Grundlagen: was ein Gerät erfüllen muss, wie die Netzwerkkommunikation aussieht, worin sich Streamlined und Standard Connectivity unterscheiden, welche Rolle der DiagTrack-Dienst spielt und welche Onboarding-Methode sich je Plattform empfiehlt. Das konkrete Ausrollen je Plattform folgt in den nächsten Teilen der Serie.

Hinweis: Microsoft Defender Antivirus (Defender AV) und Next-Generation-Schutz sind ein zentraler Bestandteil der Plattform, werden hier aber bewusst ausgeklammert. Alle Themen rund um Antivirus – inklusive Migration von Drittanbieter-Lösungen, Passivmodus und EDR-Block – behandeln wir in eigenen Kapiteln.

Die cloud-native Architektur von Defender for Endpoint.

Voraussetzungen zuerst

Damit der Dienst sauber funktioniert, müssen bestimmte Mindestanforderungen erfüllt sein (Betriebssystemversionen, Lizenzierung, Netzwerkzugriff). Der wichtigste Rat aus der Praxis: Diese Voraussetzungen vor dem breiten Rollout konfigurieren und an einigen Testgeräten validieren. So fängt man Netzwerk- oder Konfigurationsprobleme ab, bevor sie Hunderte Geräte betreffen. Die vollständige, stets aktuelle Liste der Mindestanforderungen pflegt Microsoft in der Learn-Dokumentation.

Netzwerk und Konnektivität

Jedes Endgerät benötigt Internet-Konnektivität – entweder direkt oder über einen Proxyserver. Für die Kommunikation mit dem Defender-Dienst nutzt der Sensor Windows HTTP (WinHTTP). Wichtig zu wissen: Die MDE-Sensoren laufen im Systemkontext (Konto LocalSystem), nicht im Benutzerkontext. Eine per Browser gesetzte Proxy-Konfiguration greift daher nicht automatisch.

Dienst-URLs freischalten

Vor dem Onboarding sollte man die erforderlichen Dienst-Domains validieren und sicherstellen, dass die Endgeräte die URLs des Defender-Dienstes erreichen. Microsoft stellt dafür eine herunterladbare Tabelle bereit, die alle Dienste und zugehörigen URLs auflistet. Zu beachten:

• Keine Firewall oder Netzwerkfilter darf diese URLs blockieren.
• Die Tabelle enthält regionale URLs. Freizuschalten sind alle Einträge mit der Geography WW (weltweit) plus die Einträge der Region, in der die Defender-Daten des Tenants gespeichert werden.
• Bei aktivem HTTPS-Scanning / SSL-Inspektion – in größeren Umgebungen üblich – müssen sämtliche Defender-URLs von der Inspektion ausgenommen werden. Andernfalls bricht die Kommunikation zwischen Sensor und Dienst.

Geräte ohne direkten Internetzugang (Proxy)

Für Geräte ohne direkte Internetverbindung empfiehlt sich eine Proxy-Lösung. Früher setzte man dafür den MMA-Agenten und das OMS-Gateway ein; der moderne MDE-Client kann jedoch direkt über eine Proxy-Konfiguration betrieben werden. Sämtliche Telemetriedaten lassen sich dann über den Proxy senden. Die Konfiguration für Windows beschreibt Microsoft unter „Geräte-Proxy und Internet-Konnektivität konfigurieren".

Lesetipp: In getrennten (disconnected) Umgebungen konkurrieren oft mehrere Proxy-Einstellungen. Welche gewinnt, erläutern zwei lesenswerte Blogbeiträge von Brian Baldock zu „Defender for Endpoint and disconnected environments" und „proxies and Microsoft Defender for Endpoint".

Streamlined vs. Standard Connectivity

Microsoft hat den Konnektivitätsmodus um einen neuen Typ ergänzt: Streamlined Connectivity. Statt zahlreicher einzelner Dienst-URLs führt Streamlined eine konsolidierte Domain ein:

*.endpoint.security.microsoft.com

Diese eine Domain ersetzt mehrere bislang getrennte Dienste:

• Cloud Protection / MAPS
• Malware Sample Submission Storage
• Auto-IR Sample Storage
• Defender for Endpoint Command & Control
• EDR Cyberdata

Für die Streamlined-Methode braucht es die neueren Onboarding-Pakete, die diesen Konnektivitätstyp unterstützen. Der Vorteil liegt in einer deutlich schlankeren URL-Allowlist – gerade in stark gefilterten Netzwerken ein spürbarer Betriebsvorteil. Der klassische Standard-Modus mit der vollständigen URL-Liste bleibt weiterhin verfügbar; die Wahl trifft man im Microsoft Defender-Portal beim Erstellen der Onboarding-Pakete.

Einstellungen für Streamlined Connectivity im Microsoft Defender-Portal.

DiagTrack: der Diagnosedatendienst

Der Windows-Diagnosedatendienst DiagTrack (Anzeigename Connected User Experiences and Telemetry) ist Voraussetzung für die Datenübermittlung. Er muss aktiviert sein und den Starttyp AUTO_START besitzen. Ist der Dienst deaktiviert, sendet das Gerät keine Sensordaten – ein klassischer Grund für „fehlkonfigurierte" Geräte.

Den aktuellen Zustand prüft man per Kommandozeile:

Überprüfung des DiagTrack-Dienstes per Kommandozeile.

sc qc diagtrack

Steht der Starttyp nicht auf automatisch, lässt er sich so korrigieren:

sc config diagtrack start=auto

Voraussetzungen validieren: Client Analyzer

Ob ein System die Voraussetzungen erfüllt, prüft man am zuverlässigsten mit dem Microsoft Defender for Endpoint Client Analyzer. Der große Vorteil: Das Tool läuft auch im Pre-Onboarding-Stadium – MDE muss also noch nicht installiert oder aktiv sein. So testet man Konnektivität und Dienste, bevor überhaupt ein Onboarding-Paket ausgerollt wird.

Download: https://aka.ms/mdeanalyzer

Die Schritte nach dem Download:

1. ZIP-Archiv entpacken.
2. MDEClientAnalyzer.cmd als Administrator ausführen.
3. Den Ordner MDEClientAnalyzerResult öffnen.

Zur Auswertung gibt es zwei zentrale Dateien:

• MDEClientAnalyzer.HTM – die grafische Ergebnisseite. Ist ein Gerät bereits erfolgreich angebunden, zeigt sie Details wie Organization ID, Device ID, SENSE ID und den EDR-Status.
• MDEClientAnalyzer.txt (im Unterordner SysteminfoLogs) – im Pre-Onboarding-Stadium die aussagekräftigere Datei. Sie enthält tiefergehende Informationen und die Ergebnisse des Netzwerk-Tests, also ob die erforderlichen URLs erreichbar sind.

Grafische Ergebnisseite MDEClientAnalyzer.HTM mit Organization ID, Device ID und EDR-Status.

Detaillierte Ergebnisse und Netzwerk-Test in der Datei MDEClientAnalyzer.txt.

Erst wenn der Client Analyzer grünes Licht gibt – Netzwerk erreichbar, DiagTrack aktiv, Voraussetzungen erfüllt –, sollte man mit der eigentlichen Onboarding-Methode fortfahren.

Onboarding-Methoden im Überblick

MDE lässt sich über verschiedene Verfahren anbinden. Unter Windows stehen zur Verfügung:

• Lokales Skript (PowerShell)
• Gruppenrichtlinie (GPO)
• Microsoft Intune (Endpoint Manager)
• Microsoft Endpoint Configuration Manager (ConfigMgr / MECM)
• VDI-Skripte
• Integration über Microsoft Defender for Cloud (Defender for Servers)

Nutzt eine Organisation andere Verteilungswerkzeuge (etwa Altiris, DesktopCentral oder Ansible), lässt sich in den meisten Fällen das GPO-Skript auch über diese Tools ausrollen.

Empfohlene Methode je Plattform

Aus der Praxis ergibt sich folgende Empfehlung:

Intune und Defender for Cloud bieten das modernste, cloudbasierte Management. Werden noch „Legacy"-Methoden wie Gruppenrichtlinien eingesetzt, sollte man perspektivisch umsteigen. Es gibt allerdings legitime Fälle, in denen weder Azure Arc, Defender for Cloud noch Intune praktikabel sind – etwa in Filialen oder an PoS-Systemen. Dort bleiben ConfigMgr oder Gruppenrichtlinien der beste Weg.

Onboarding-Pakete herunterladen

Die Installations- und Onboarding-Pakete findet man im Microsoft Defender-Portal unter Settings → Endpoints → Onboarding. Zur Auswahl stehen:

• Lokal (Script)
• Gruppenrichtlinie (GPO)
• Microsoft Endpoint Configuration Manager (Current Branch)
• Mobile Device Management (MDM) / Microsoft Intune

Nur wenn weder Defender for Cloud noch Intune für das Onboarding integriert wurden, muss man die Pakete manuell herunterladen.

Praxis-Tipp: Ist PowerShell die einzige Option, sollte man dennoch das GPO-Skript verwenden – das lokale Skript erfordert Benutzereingaben und läuft nicht unbeaufsichtigt.

Praxis-Tipp: Onboarding-Pakete regelmäßig aktualisieren. Microsoft veröffentlicht gelegentlich Updates mit Verbesserungen. Insbesondere beim einheitlichen Server-Agenten sollte man stets die neueste Version verwenden (aktuellste Produkt- und Sense-Engine-Version).

Auswahl der Bereitstellungsmethode beim Download der Onboarding-Pakete.

Server-Onboarding: Azure Arc, Direct Onboarding und Defender for Servers

Das Server-Onboarding unterscheidet sich vom Client-Onboarding, weil die Server-Lizenz für MDE über Defender for Cloud läuft. Grundsätzlich gibt es drei Wege.

Defender for Servers (über Defender for Cloud)

Microsoft Defender for Cloud (MDC) ist eine cloud-native Plattform zum Schutz von Ressourcen (CSPM und CWPP). Der Defender for Servers-Plan ist Teil davon und in zwei Stufen erhältlich:

• Plan 1 (P1): Fokus auf Defender-for-Endpoint-Technologie, ca. 5 $ pro Server/Monat (nach Laufzeit/Stunde abgerechnet).
• Plan 2 (P2): volle Bandbreite erweiterter Funktionen wie Netzwerkschicht-Bedrohungserkennung, File Integrity Monitoring (FIM), Qualys-Schwachstellenbewertung sowie 500 MB freien Daten-Ingest, ca. 15 $ pro Server/Monat.

Defender for Servers Plan 2 im Defender for Cloud-Portal.

Defender for Servers Plan 1 im Defender for Cloud-Portal.

Beide Server-Pläne enthalten Defender for Endpoint Plan 2 vollständig. Wird der Plan in Defender for Cloud aktiviert, erfolgt das MDE-Onboarding automatisch per Azure Policy: Das Onboarding-Skript und weitere Einstellungen werden ausgerollt, das Resultat ist die VM-Erweiterung MDE.Windows (bzw. MDE.Linux) für Windows Server 2012 R2 und höher. Vorteile der Integration: automatisiertes Onboarding, einfache Azure-Arc-Bereitstellung on-premises und Anzeige der MDE-Warnungen auch in den Defender-for-Cloud-Portalseiten.

Wann Defender for Servers? Wenn die Server in Azure betrieben werden. Die Absicherung ist dann besonders einfach, und erweiterte Schutzfunktionen wie FIM oder Just-in-Time-VM-Zugriff stehen bereit.

Azure Arc als Brücke

Azure Arc erweitert die Azure-Plattform auf lokale Umgebungen und andere Clouds (AWS/GCP). Damit ein Nicht-Azure-Server angebunden werden kann, muss der Azure Connected Machine Agent installiert sein. Arc ist aber weit mehr als ein MDE-Onboarding-Weg: Es ermöglicht Azure Policies, Update Management, Extensions, Automanage und mehr für Server außerhalb von Azure.

Ein entscheidender Punkt: Sollen benutzerdefinierte Log-Daten über den Azure Monitor Agent (AMA) gesammelt werden, ist Azure Arc für lokale bzw. Nicht-Azure-Server zwingend erforderlich – der AMA wird dort nur über Arc unterstützt.

Wann Azure Arc? Wenn die erweiterten Management-Funktionen von Arc benötigt werden oder Log-Daten via Azure Monitor gesammelt werden sollen.

Direct Onboarding (ohne Azure Arc)

Seit Juni 2023 gibt es das Direct Onboarding. Damit lassen sich lokale Windows- und Linux-Server direkt – ohne Azure Arc – in Defender for Endpoint aufnehmen, im Rahmen von Defender for Servers Plan 1. Man rollt das Onboarding-Paket bzw. Skript direkt aus dem Defender-Portal aus, während Lizenzierung und Abrechnung weiterhin über Azure/Defender for Cloud laufen. Zusätzliche Agenten oder Extensions sind nicht nötig.

Direct Onboarding ist eine Opt-In-Einstellung auf Mandantenebene. Nach dem Aktivieren werden alle bestehenden und neuen Server des MDE-Tenants mit einem konfigurierten Azure-Abonnement verknüpft; das Abonnement dient dann der Lizenzierung, Abrechnung, Alarmierung und Übersicht. Die in MDE eingebundenen Server werden ins Inventar von Defender for Cloud synchronisiert.

Wichtig: Bei Direct Onboarding nutzt man den Defender-for-Cloud-Teil nur zur Lizenzierung. Für weitergehende Konfiguration und zusätzlichen Schutz – sowie für den AMA – muss weiterhin Azure Arc eingesetzt werden.

Wann Direct Onboarding? Wenn ausschließlich Defender for Endpoint genutzt werden soll, kein Azure Monitor Agent benötigt wird und Azure Arc unnötigen Overhead bedeuten würde (Arc bringt eigene Sicherheitsrichtlinien und Design-Entscheidungen mit).

Betriebssystem-Unterschiede bei Servern

Der EDR-Sensor ist nicht auf allen Windows-Versionen integriert. Das beeinflusst den Onboarding-Aufwand:

Für Windows 10 (ab 1607) und Windows Server 2019+ genügt es also, das Onboarding-Skript auszuführen und die Voraussetzungen zu konfigurieren. Für Server 2012 R2 und 2016 gibt es inzwischen einen einheitlichen Agenten (Unified Agent).

Tipp: Immer den neuen einheitlichen Installer verwenden. Der veraltete Microsoft Monitoring Agent (MMA) für Server 2012 R2/2016 sollte nicht mehr genutzt werden – ihm fehlen viele Funktionen und Erkennungsmechanismen (z. B. Attack Surface Reduction, automatisierte Untersuchung, Netzwerkschutz).

Windows Server 2016 bringt Defender AV bereits mit; bei Server 2012 R2 musste früher System Center Endpoint Protection (SCEP) manuell installiert werden. Die neue einheitliche Lösung schließt diese Lücken und ist allgemein verfügbar.

Testen im Evaluierungslabor

Wichtig: Microsoft hat das Defender Evaluierungslabor ab Mitte Januar 2024 eingestellt. Die nachfolgend beschriebene Funktion steht nicht mehr zur Verfügung. Als Alternative empfiehlt sich eine eigene Testmaschine mit Angriffssimulationen; für AV-Tests wird Red Canary genannt.

Das Evaluierungslabor war ein bequemer Weg, MDE ohne eigene Umgebung auszuprobieren. Man fand es im Defender-Portal unter Evaluation & Tutorials → Evaluation lab. Über Setup Lab wurde die Umgebung eingerichtet, danach ließen sich über Add device Testgeräte hinzufügen. Verfügbar waren Windows 10, Windows 11, Windows Server 2019, Windows Server 2016 und Linux (Ubuntu Server).

Testgeräte im Evaluierungslabor über „Add device" hinzufügen.

Windows Server 2019 lässt sich im Lab als Domänencontroller bereitstellen.

Die VMs liefen in einem isolierten Azure-Netzwerk, wurden automatisch in MDE eingebunden (Name TestMachine plus Nummer) und waren mit Sicherheitsfunktionen wie ASR (im Audit-Modus), Block at First Sight, Controlled Folder Access, Exploit Protection, Netzwerkschutz, PUA-Erkennung, Cloud-delivered Protection (Modus High+) und SmartScreen vorkonfiguriert. Optional ließen sich Java Runtime, Python, Office und Sysinternals mitinstallieren. Nach 15–30 Minuten (Status zunächst Setting up) war die VM per RDP erreichbar, und über die Simulation Gallery standen Angriffssimulationen von AttackIQ und SafeBreach bereit. Das Administrator-Kennwort wurde nur einmalig angezeigt und musste sofort gesichert werden.

Das Administrator-Kennwort der Test-VM wird nur einmalig angezeigt.

Im Defender-Portal erhält die Maschine zunächst den Status „Setting up".

Über die Übersichtsseite des Labs lässt sich der Fortschritt verfolgen.

Zugriff auf die fertige VM per RDP-Datei und generierten Zugangsdaten.

Get-MpPreference zeigt die aktive Defender-Konfiguration auf der Test-VM.

Angriffssimulationen von AttackIQ und SafeBreach in der Simulation Gallery.

Troubleshooting beim Onboarding

Taucht ein Gerät nach dem Onboarding nicht im Portal auf, ist tiefergehende Fehlersuche gefragt. Der erste Schritt ist immer: Alle MDE-Voraussetzungen prüfen (Netzwerk, URLs, DiagTrack).

Onboarding-Informationen legt Windows in der Registrierung ab, unter:

HKLM\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection

Onboarding-Informationen in der Windows-Registrierung.

Empfohlene Prüfschritte:

• Nach dem Onboarding den MDEClientAnalyzer ausführen, um Konnektivität, Sensor-Status und Dienste zu überprüfen.
• Das Eventlog SENSE kontrollieren, unter Applications and Services Logs → Microsoft → Windows → SENSE. Alle Event-IDs des SENSE-Dienstes sollten betrachtet werden.

Das SENSE-Eventlog in der Windows-Ereignisanzeige.

Gerätestatus in Defender for Endpoint

Nach dem initialen Onboarding erscheint das Gerät mit dem Status Onboarded (Angebunden). Der Gerätestatus gibt Auskunft über die Systemgesundheit. Neben Onboarded sind vor allem zwei weitere Status relevant.

Gerät mit dem Status „Onboarded" in Defender for Endpoint.

Übersicht der möglichen Gerätestatus in Defender for Endpoint.

Inactive (Inaktiv) – wird in mehreren Fällen gesetzt:

• Das Gerät war 7 Tage ohne Aktivität.
• Das Gerät wurde neu installiert oder umbenannt – dann legt Defender eine neue Geräteinstanz an, während die alte in der Liste verbleibt.
• Das Gerät wurde offboarded – es bleibt aber sichtbar.
• Das Gerät sendet länger als 7 Tage keine Signale (aus beliebigem Grund).

Misconfigured (Fehlkonfiguriert) – weist auf Kommunikationsprobleme hin:

• Impaired communications: Die Kommunikation zwischen Gerät und Defender-Dienst ist eingeschränkt.
• No sensor data: Das Gerät hat zwar Verbindung zum Dienst, übermittelt aber keine Sensordaten.

Beide Status sind meist ein direkter Hinweis auf verletzte Voraussetzungen – womit sich der Kreis schließt: Netzwerk, URLs und DiagTrack zuerst.

Nächster Teil der Serie: Onboarding je Plattform (Intune, Defender for Cloud, Azure Arc, Config Manager/GPO, macOS, iOS).