Sektion 23: Driver Updates via Intune: Management & Deployment

Einleitung: Warum Driver Management in Intune eine eigene Meisterklasse verdient

Treiberupdates sind das unsichtbare Rückgrat jedes Windows-Ökosystems. Sie entscheiden über Grafikleistung, Netzwerkstabilität, Energieverwaltung und — zunehmend wichtig — über die Sicherheit des Systems. Ein veralteter Intel-Grafiktreiber kann Bluescreens verursachen, ein alter Netzwerktreiber den Standby-Modus brechen, und veraltete Firmware ist heute eine der häufigsten Angriffsflächen für physische Angriffe (Think: UEFI-Exploits wie „LogoFAIL“). Während Feature Updates und Patches in Intune seit Jahren erstklassig gemanagt werden können, war Driver Management lange Zeit ein vernachlässigtes Stiefkind — manuell über OEM-Tools, per USB-Stick im Helpdesk oder über SCCM-Pakete, die jemand pflegen musste.

Mit den Windows Driver Update Policies in Microsoft Intune hat Microsoft hier nachgezogen: Driver- und Firmware-Updates lassen sich jetzt über denselben Kanal verwalten, der ohnehin für Windows Updates genutzt wird — Windows Update for Business. Das bedeutet: keine zusätzlichen Infrastruktur-Komponenten, keine SCCM-Pakete für Treiber, kein Herunterladen von INF-Dateien von Hersteller-Websites. Stattdessen bekommst du ein policybasiertes, reportingfähiges und skalierbares Driver-Management, das voll in deinen bestehenden Intune-Tenant integriert ist.

In dieser Sektion bauchen wir tief ein: von den Grundkonzepten der Treiber-Architektur über die praktische Implementierung von Driver Update Profiles bis hin zu fortgeschrittenen Szenarien wie manuellen Genehmigungs-Workflows, Graph-API-Automatisierung und dem Deployment von Treiberpaketen außerhalb von Windows Update. Danach beherrscht du Driver Management in Intune auf einem Niveau, das den meisten Admins — die Treiber nach wie vor manuell via Hersteller-Website jagen — meilenweit voraus ist.

Grundkonzepte: Wie Windows Treiber wirklich behandelt

Treiber-Architektur in Kürze

Ein Windows-Treiber ist im Kern ein Paket aus einer INF-Datei (der Installationsbeschreibung), den eigentlichen Binärdateien (SYS, DLL, CAT) und einer digitalen Signatur. Windows verwaltet alle installierten Treiber im Driver Store (C:\Windows\System32\DriverStore\FileRepository). Diese zentrale Instanz ist der Grund, warum Windows Treiber so robust rollbacken kann: Jedes installierte Treiberpaket bleibt physisch im Store erhalten, auch wenn ein älterer oder neuerer Treiber aktiv ist.

Microsoft betreibt einen riesigen Katalog an Treibern im Microsoft Update Catalog. OEMs wie Lenovo, HP, Dell, Intel und NVIDIA veröffentlichen ihre WHQL-signierten Treiber dort. Das ist der gleiche Katalog, den Windows Update für den Download nutzt. Wichtig: Microsoft veröffentlicht Treiber nicht automatisch für alle Geräte — die Verteilung wird über „Targeting“ gesteuert, das auf Hardware-IDs basiert. Jedes Gerät scannt gegen diesen Katalog und erhält genau die Treiber, die zu seiner Hardware-ID (HARDWARE_ID aus dem ACPI/PnP-System) passen.

Der Unterschied zwischen Update Rings und Driver Update Policies

Viele Admins verwechseln die beiden Mechanismen. Deshalb die klare Trennung:

Update Rings (in Intune unter Devices > Windows > Update Rings for Windows 10 and later) steuern Quality Updates (Sicherheitspatches) und Feature Updates (Versions-Upgrades). Sie haben explizite Deferral-Zeiten in Tagen und steuern, wann ein Update installiert wird.
Windows Driver Update Policies steuern ausschließlich Treiber- und Firmware-Updates über Windows Update. Sie haben keine Deferral-Zeiten pro Kategorie, sondern arbeiten mit einem Genehmigungsmodell: Automatische Genehmigung oder manuelle Prüfung.

Beide Mechanismen laufen über denselben Windows-Update-Agent, sind aber logisch getrennt. Ein Gerät, das nur in einem Update Ring ist, bekommt trotzdem Treiber über Windows Update — und zwar automatisch genehmigt, sofern keine Driver Update Policy greift, die das steuert. Das ist für viele Organisationen die Initial-Zündung: Sie haben jahrelang Treiberupdates bekommen, ohne es zu wissen.

Automatic vs. Manual Approval — das Herzstück

Jede Windows Driver Update Policy in Intune hat zwei Betriebsmodi:

Automatic Approval: Microsoft genehmigt jeden neuen Treiber automatisch für alle Zielgeräte. Kein manueller Eingriff, keine Prüfung. Das ist der „Fire-and-Forget“-Modus — für viele Organisationen der Standard, aber mit Restrisiko: Ein fehlerhafter OEM-Treiber verteilt sich ungefiltert.
Manual Approval: Neue Treiber erscheinen in einer Inbox im Intune-Portal. Du prüfst jedes Treiberupdate (Hersteller, Treiberklasse, betroffene Modelle, Versionsnummer) und genehmigst es explizit — oder schiebst es per „Snooze“ auf. Das ist der Enterprise-Modus für Organisationen mit strengen Change-Management-Anforderungen.

Damit wird Driver Management zum ersten Mal ein echtes Managed Deployment statt eines „Windows entscheidet“-Prozesses. Microsoft hat bewusst das Modell von WSUS übernommen: Genehmigung vor Verteilung.

Wann Windows Update als Treiberquelle nicht reicht

Trotz allem gibt es Szenarien, in denen der WUfB-Kanal an seine Grenzen stößt:

Der OEM veröffentlicht kritische Treiber nicht (oder verspätet) im Microsoft Update Catalog.
Deine Organisation nutzt WSUS oder Configuration Manager parallel — dann landen WUfB-Treiber nicht automatisch am Gerät, weil der Update-Scan gegen WSUS gerichtet ist.
Du benötigst eine exakte, versionierte Verteilung (Compliance-Anforderung, z.B. „alle Geräte müssen Treiber X.Y.Z haben“).

Für diese Fälle zeigen wir in der Praxis-Implementierung den parallelen Weg über Win32-Apps mit pnputil — also klassisches Treiber-Deployment, aber in modernem Intune-Gewand.

Praxis-Implementierung: Driver Update Policies Schritt für Schritt

Szenario und Voraussetzungen

Wir bauen ein realistisches Szenario auf: Eine Organisation mit 2.500 Windows-11-Geräten (hauptsächlich Lenovo ThinkPad-Serie, gemischt mit Surface- und Dell-Geräten) soll von manuellem Treiber-Management auf zentrale Driver Update Policies umgestellt werden. Voraussetzungen:

Geräte sind in Intune angemeldet (Benutzer- oder Geräte-Anmeldung, Autopilot oder manuell).
Geräte sind Windows 10 (mit aktuellen kumulativen Updates) oder Windows 11.
Hybrid-Joins dürfen kein WSUS-GPO haben, das Treiber gegen WSUS umleitet — dazu später in Troubleshooting mehr.
Die Geräte prüfen gegen den öffentlichen Windows-Update-Service.

Schritt 1: Driver Update Profile erstellen (Portal)

Die Driver Update Policies findest du im Intune-Portal unter Devices > Windows > Windows updates > Windows Driver Update Policies. Klicke auf + Create Profile. Das Formular ist bewusst schlank:

Name: z.B. „Drivers – Pilot Ring“
Description: Dokumentation des Rings, z.B. „Manuelle Genehmigung, Pilotgruppe IT-Abteilung.“
Update approval: Automatically approve oder Manually approve
Add all driver updates: Aktivierst du diese Option, werden alle aktuell verfügbaren Treiberupdates sofort genehmigt (nur im Manual-Modus sinnvoll, wenn du den Rückstand einmalig abholen willst — Vorsicht: das kann hunderte Treiber auf einmal freigeben).

Für unser Pilot-Szenario wählen wir Manually approve und lassen „Add all driver updates“ bewusst weg — wir wollen jeden Treiber einzeln prüfen, bevor er an die Pilot-Gruppe geht.

Schritt 2: Assignment mit Filtern kombinieren

Bei der Zuweisung (Next > Assignments) weist du das Profil einer Entra-Gruppe zu — zum Beispiel der dynamischen Gruppe „Windows-Pilot-Devices“. Hier lohnt sich die Kombination mit Intune-Filters: Du kannst das Profil zusätzlich auf Geräte filtern, die bestimmte Hardware-Eigenschaften haben. Ein sinnvolles Setup für den Produktiv-Ring wäre:

Gruppe: „Windows-Prod-Devices“ (alle Produktiv-Geräte)
Filter: (device.manufacturer -eq "LENOVO") or (device.manufacturer -eq "Microsoft Corporation")
Modus: Assign — nicht „Do not assign“, da wir explizit steuern wollen.

Damit erreichst du, dass Dell-Endgeräte (die in unserem Szenario über ein eigenes Tool betreut werden) das Profil nicht erhalten, obwohl sie in der Gruppe liegen. Filter sind bei Treibern Gold wert, weil Hardware-Hersteller das entscheidende Kriterium sind.

Schritt 3: Manuelle Genehmigung im Workflow

Nach dem Erstellen des Profils erscheint unter Windows Driver Update Policies dein Profil. Klicke hinein und wähle den Reiter All driver updates (oder im Profil-Detail: Driver updates). Hier siehst du die Inbox: alle Treiberupdates, die Microsoft für deine Zielgeräte als relevant identifiziert hat — mit Hersteller (z.B. „Intel Corporation“), Treiberklasse (z.B. „Display adapters“), Version, Freigabedatum und der Anzahl betroffener Geräte.

Der Workflow pro Treiberupdate:

Approve: Der Treiber wird für alle Geräte im Profil freigegeben und beim nächsten Update-Scan installiert.
Pause/Snooze: Das Update wird für einen definierten Zeitraum (bis zu 35 Tage) zurückgestellt — ideal, wenn ein Treiber zwar relevant, aber gerade erst von einem CVE oder Instabilitäts-Report begleitet wird.

Praxis-Tipp: Prüfe GPU-Treiber (Klasse „Display adapters“) und Firmware-Updates zuerst — diese beiden Kategorien verursachen die meisten Incidents. Netzwerk- und Chipset-Treiber sind meist unkritisch und können ohne Prüfung genehmigt werden.

Schritt 4: Treiber-Inventur per PowerShell — die Basis für Entscheidungen

Bevor du blind genehmigst, willst du wissen, welche Treiber auf den Geräten überhaupt installiert sind. Diese PowerShell-Abfrage auf einem Referenz-Gerät (oder via Proactive Remediations fleetweit) liefert die aktuelle Treiberlandschaft:

# Alle signierten Treiber mit Version und Datum
Get-CimInstance -ClassName Win32_PnPSignedDriver |
    Where-Object { $_.DeviceName -and $_.DriverVersion } |
    Select-Object DeviceName, DriverVersion, DriverDate, Manufacturer |
    Sort-Object DeviceName |
    Format-Table -AutoSize

# Nur kritische Klassen: Grafik, Netzwerk, Firmware
Get-CimInstance -ClassName Win32_PnPSignedDriver |
    Where-Object {
        $_.DeviceClass -in @('DISPLAY','NET','SYSTEM','FIRMWARE')
    } |
    Select-Object DeviceName, DriverVersion, @{N='Age (Days)'; E={
        (New-TimeSpan -Start $_.DriverDate -End (Get-Date)).Days
    }} |
    Sort-Object 'Age (Days)' -Descending

Die Spalte „Age in Days“ ist dein Risikokompass: Alles über 730 Tage (2 Jahre) ist ein Kandidat für priorisierte Genehmigung. Mit einer Proactive Remediation (Detection + Remediation-Skript) kannst du diese Inventur zentral einsammeln und in einem Dashboard zusammenführen.

Schritt 5: Profil-Erstellung per Graph API (Automatisierung)

Für Multi-Tenant-Setups oder Terraform/DevOps-Ansätze erstellst du Driver Update Profiles direkt per Graph API. Der Endpoint ist deviceManagement/windowsDriverUpdateProfiles:

Connect-MgGraph -Scopes "DeviceManagementConfiguration.ReadWrite.All"

$profileBody = @{
    "@odata.type" = "#microsoft.graph.windowsDriverUpdateProfile"
    displayName  = "Drivers - Pilot Ring"
    description  = "Manuelle Genehmigung, Pilotgruppe IT"
    approvalType = "manual"
} | ConvertTo-Json

$profile = Invoke-MgGraphRequest -Method POST `
    -Uri "https://graph.microsoft.com/beta/deviceManagement/windowsDriverUpdateProfiles" `
    -Body $profileBody `
    -ContentType "application/json"

# Zuweisung auf eine Entra-Gruppe
$groupId = (Get-MgGroup -Filter "displayName eq 'Windows-Pilot-Devices'").Id

$assignBody = @{
    assignments = @(
        @{
            target = @{
                "@odata.type" = "microsoft.graph.groupAssignmentTarget"
                groupId       = $groupId
            }
        }
    )
} | ConvertTo-Json -Depth 5

Invoke-MgGraphRequest -Method POST `
    -Uri "https://graph.microsoft.com/beta/deviceManagement/windowsDriverUpdateProfiles/$($profile.id)/assign" `
    -Body $assignBody `
    -ContentType "application/json"

Mit dem Graph Explorer oder Invoke-MgGraphRequest gegen .../windowsDriverUpdateProfiles/{id}/driverInventory holst du dir zusätzlich die Treiber-Inventur pro Profil — perfekt für automatisierte Reports, die dir wöchentlich per Teams-Webhook die offenen, noch nicht genehmigten Treiber vor die Füße werfen.

Alternative: Treiber-Deployment via pnputil als Win32 App

Wenn Windows Update nicht greift (WSUS-Umgebungen, Offline-Compliance, exakte Versionierung), deployst du Treiberpakete als Win32-App. Der Kern ist das Tool pnputil.exe, das seit Windows 10 2004 alle nötigen Operationen beherrscht:

# Treiberpaket lokal extrahieren (Setup.exe entpacken oder OEM-ZIP)
# z.B. Intel-Grafiktreiber als ZIP entpackt nach .\extracted\Graphics

# 1) Alle INF-Dateien im Treiberpaket in den Driver Store importieren
pnputil /add-driver ".\extracted\Graphics\*.inf" /subdirs /install

# 2) Prüfen, ob der Treiber erfolgreich importiert wurde
pnputil /enum-drivers | Select-String -Pattern "Intel" -Context 3,5

Als Win32-App verpackst du das komplette Treiberpaket (mit Microsoft Win32 Content Prep Tool zur .intunewin-Datei), als Install-Kommando:

# install.cmd — Treiberpaket aus dem App-Verzeichnis installieren
pnputil /add-driver "%~dp0drivers\*.inf" /subdirs /install

Als Detection Rule nutzt du eine benutzerdefinierte Skript-Erkennung, die die exakte Treiberversion prüft:

$expected = "31.0.101.5333"
$driver = Get-CimInstance -ClassName Win32_PnPSignedDriver |
    Where-Object { $_.DeviceName -like "*Intel(R) UHD Graphics*" }

if ($driver -and $driver.DriverVersion -eq $expected) {
    Write-Output "Treiber $expected vorhanden"
    exit 0
}
exit 1

Dieser Ansatz hat klare Vor- und Nachteile: maximale Kontrolle über exakte Versionen und Hardware-Targets, aber manueller Wartungsaufwand für jedes neue Treiberrelease. Nutze ihn gezielt für Ausnahmefälle — als Standard-Kanal bleibt Windows Update die richtige Wahl.

Reporting: Der Windows Driver Update Report

Nachdem das Profil zugewiesen ist und die ersten Genehmigungen durch sind, kontrollierst du die Verteilung unter Reports > Windows updates > Windows Driver update reports. Der Report zeigt pro Gerät und pro Treiberupdate den Status: Installed, Failed, Not installed oder In progress. Für die weitergehende Analyse exportierst du das als CSV und filterst in Excel/Power BI nach Fehlern.

Wichtig zu wissen: Das Reporting ist nicht Echtzeit. Die Daten basieren auf dem Windows-Update-Telemetrie-Zyklus und können mehrere Tage zurückliegen. Ein Gerät, das du gerade synchronisiert hast, erscheint nicht sofort im Report — das ist normales Verhalten, kein Bug. Für Live-Prüfung nutze die Gerätesynchronisation und die lokale Diagnose (siehe Troubleshooting).

Best Practices: Driver Management, das im Enterprise überlebt

Ringe einführen — auch bei Treibern

Der wichtigste Rat: Baue dieselbe Ring-Logik auf, die du auch für Feature Updates nutzt. Ein bewährtes Drei-Ring-Modell für Treiber:

Ring 0 (Canary): 5–10 IT-Geräte, Automatic Approval. Hier laufen alle Treiber sofort rein — inklusive der schlechten. Dieser Ring ist dein Frühwarnsystem.
Ring 1 (Pilot): 50–200 Geräte aus allen Abteilungen und Hardware-Klassen, Manual Approval mit kurzer Prüfroutine (maximal 3 Werktage Snooze).
Ring 2 (Broad): Alle übrigen Geräte, Manual Approval mit Genehmigung nach 2 Wochen Ring-1-Betrieb ohne Vorfälle.

Das Profil für Ring 0 und Ring 1 unterscheidet sich nur im approvalType und in der zugewiesenen Gruppe — baue es also als Copy-and-Adjust, nicht als Neuentwurf.

Hersteller- und Modell-Filter statt Vertrauen

Genehmige nie blind nach Treiberklasse über alle Hersteller hinweg. Prüfe im Genehmigungsdialog, für welche Hardware-IDs der Treiber freigegeben wird. Bei Surface-Geräten ist das unkritisch (Microsoft kontrolliert die Pipeline selbst), bei Business-Notebooks von Lenovo, HP oder Dell dagegen relevant: Ein einzelner Treiber im Microsoft-Katalog kann sich auf Dutzende Modellvarianten beziehen, die deine Flotte gar nicht hat — das Genehmigungs-Risiko steigt trotzdem nicht, aber deine Prüfung wird ungenauer. Filtere die betroffenen Geräte im Report auf deine kritischen Modelle.

Firmware und BIOS separat denken

Firmware-Updates über Windows Update verhalten sich anders als klassische Treiber: Sie installieren sich nur, wenn das Gerät am Netzteil angeschlossen ist und über ausreichend Akku verfügt. Im Reporting erscheinen Geräte mit „Not installed“ oft nur deshalb — kein Fehler, sondern Schutzmechanismus. Plane Firmware-Wellen bewusst: Sie erzeugen Reboots außerhalb der Arbeitszeit (oder fordern den Benutzer zum Neustart auf), also kommuniziere Firmware-Genehmigungen idealerweise an die User, statt sie still einzuschieben.

WSUS-Umgebungen sauber managen

Klassischer Enterprise-Falle: In einer Umgebung mit Configuration Manager oder WSUS zeigen Geräte plötzlich keine Treiber-Updates mehr — weil ein GPO den Update-Scan auf WSUS umleitet. Wenn du parallel Treiber über Windows Update verteilen willst, ohne die WSUS-Struktur für Patches zu brechen, nutze die Richtlinie Specify source service for specific classes of Windows Updates (in Intune als Einstellung im Settings Catalog: Administrative Templates > Windows Components > Windows Update). Diese erlaubt, die Treiberklasse explizit auf „Windows Update“ umzuleiten, während Patches weiter gegen WSUS laufen:

Policy-CSP (Settings Catalog): 
  "Specify source service for specific classes of Windows Updates" = Enabled
  Set "Driver Updates" = "Windows Update" 
  Set "Software Updates" = "Windows Server Update Service (WSUS)"

Das ist die Brücke zwischen klassischer und moderner Treiber-Verteilung — und rettet dir in Hybrid-Umgebungen den Überblick.

Änderungen dokumentieren und Snooze diszipliniert nutzen

Führe ein Treiber-Change-Log: Jede Genehmigung mit Datum, Treiberklasse, Version, betroffener Ring und — wichtig — jede Snooze-Entscheidung mit Begründung. Snooze hat eine harte Obergrenze von 35 Tagen, danach läuft der Timer ab und der Treiber wird automatisch genehmigt, wenn du nicht aktiv verlängerst. Ein „Snooze und vergessen“-Verhalten führt also am Ende doch zur automatischen Verteilung — nur dann ohne dass jemand die Entscheidung verantwortet hat. Setze dir lieber eine wöchentliche Review-Erinnerung, als Snooze als dauerhafte Lösung zu missbrauchen.

Troubleshooting: Wenn Treiber nicht kommen oder schiefgehen

Gerät bekommt keine Treiber-Updates — Prüfliste

Der häufigste Fall: Ein Gerät ist im Profil, aber der Driver Update Report bleibt leer oder zeigt ewig „Not installed“. Gehe diese Prüfliste durch:

# 1) Hat das Gerät die Driver-Policy überhaupt empfangen?
Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\PolicyManager\current\device" -ErrorAction SilentlyContinue

# 2) Gegen welchen Update-Dienst scannt das Gerät?
$sm = New-Object -ComObject "Microsoft.Update.ServiceManager"
$sm.Services | Select-Object Name, IsDefaultAUService

# 3) Erzwinge sofortigen Update-Scan inkl. Treibern
$us = New-Object -ComObject "Microsoft.Update.Session"
$searcher = $us.CreateUpdateSearcher()
$result = $searcher.Search("IsInstalled=0 and Type='Driver'")
$result.Updates | ForEach-Object { $_.Title }

# 4) Windows-Update-Eventlog nach Fehlern scannen
Get-WinEvent -LogName "Microsoft-Windows-WindowsUpdateClient/Operational" -MaxEvents 50 |
    Where-Object { $_.LevelDisplayName -eq "Error" -or $_.Message -match "Driver" } |
    Select-Object TimeCreated, Id, Message | Format-List

Die häufigsten Ursachen in der Praxis:

WSUS-Redirect: Das Gerät scannt gegen WSUS, Windows-Update-Treiber werden ignoriert. Lösung: die oben beschriebene „Specify source service“-Richtlinie, oder für reine Intune-Geräte: WSUS-GPO entfernen.
Keine Windows-Update-Verbindung: Firewall/Proxy blockiert *.windowsupdate.com oder *.deliveryoptimization.com. Prüfe mit Test-NetConnection delivery.mp.microsoft.com -Port 443.
Reporting-Verzögerung: Der Report aktualisiert verzögert — synchronisiere das Gerät manuell in Intune (Sync im Gerät-Detail) und warte 24–48 Stunden, bevor duAlarm schlägst.
Fehlende Profil-Zuweisung: Das Gerät liegt in der Gruppe, aber die dynamische Gruppe hat es (noch) nicht aufgenommen — dynamische Gruppen aktualisieren nur periodisch.

Treiber-Installation schlägt fehl — Error-Codes verstehen

Wenn ein Treiber im Report als Failed auftaucht oder am Gerät mit Fehlercode abbricht, sind das die Klassiker:

0x800f0203 / 0x800f0233: Der Treiber passt nicht zur Hardware-ID am Zielgerät — meist ein Fehler in Microsofts Targeting oder ein falsches Modell im Filter. Prüfe die Hardware-ID: Get-CimInstance Win32_PnPEntity | Where-Object { $_.DeviceID -like "*VEN_8086*" }.
0x800f082e (0x80242006): Kompatibilitätsblock durch Setup-Regeln (z.B. Firmware-Update verweigert wegen Akkustand/Netzteil). Lass das Gerät ans Netz, synchronisiere neu.
0x80070003 / 0x8024001e: Download-Problem — Delivery Optimization oder Proxy. Prüfe Get-DeliveryOptimizationStatus und die DO-Logs unter Get-DODownloadLogs.

Für die tiefere Analyse generiere das lesbare WindowsUpdate-Log:

# WindowsUpdate.log aus ETL-Format nach Text konvertieren
Get-WindowsUpdateLog -LogPath "$env:USERPROFILE\Desktop\WindowsUpdate.log"

# Danach nach Treiber-Ereignissen filtern
Select-String -Path "$env:USERPROFILE\Desktop\WindowsUpdate.log" `
    -Pattern "Driver|Firmware" | Select-Object -Last 40

Treiber-Rollback — der Notfallplan

Wenn ein genehmigter Treiber auf einer Modell-Serie Probleme macht (Bluescreens, Standby-Defekte, Docking-Ausfälle), ist dein Notfallplan:

# 1) Treiber im Device Manager identifizieren und Rollback triggern:
pnputil /enum-devices /problem

# 2) Alternativ: gezieltes Rollback via WMI (Device Manager-Äquivalent)
# Device Manager > Gerät > Treiber > "Rollback Driver" (GUI)

# 3) Vor Windows Update schützen: Treiber-Verweigerung per Gruppenrichtlinie
# Settings Catalog: "Prevent installation of devices that match device IDs"
# oder als temporäre Maßnahme: "Do not include drivers with Windows Updates" aktivieren

Parallel im Intune-Portal: Den problematischen Treiber im Profil sofort pause setzen (falls bereits breit genehmigt) und die betroffene Modellserie in den Assignments per Filter ausschließen, bis der OEM eine korrigierte Version veröffentlicht. Dokumentiere den Vorfall — das ist genau das Szenario, für das Manual Approval existiert.

Fazit: Driver Management als reifer, geprüfter Prozess

Treiber-Updates über Intune zu managen ist kein „nice to have“ mehr — es ist der Standardweg für moderne Windows-Umgebungen. Mit Windows Driver Update Policies bekommst du drei Dinge, die vorher undenkbar waren: Steuerung (Automatische vs. manuelle Genehmigung, inklusive Snooze-Mechanik), Transparenz (Windows Driver Update Reports pro Gerät und Treiber) und Skalierbarkeit (dieselbe Policy-Engine, dieselbe Graph-API, dieselben Gruppen wie der Rest deiner Intune-Welt).

Der eigentliche Reifegad-Unterschied liegt im Betriebsmodell: Wer Treiber blind laufen lässt (Automatic Approval überall), hat kein Driver Management — nur Zufallsmanagement mit verzögertem Reporting. Wer dagegen Ring-Logik, manuelle Genehmigung für kritische Treiberklassen, Snooze-Disziplin und einen dokumentierten Notfallplan etabliert, hat Driver Management auf Enterprise-Niveau. Und genau das trennt Intune-Beginner von Intune-Profis: nicht die Features, sondern der Prozess, mit dem du sie betreibst.

Die nächsten Sektionen bauen hierauf auf: Von Firmware-Security über Windows Autopatch als vollautomatisierte Variante des Ring-Konzepts bis hin zu proaktiven Remediations, mit denen du deine Treiber-Inventur kontinuierlich überwachen kannst — bevor der nächste Anruf aus der Abteilung „Mein Docking-Station geht nicht mehr“ reinkommt.