Viele Unternehmen modernisieren ihr Endpoint Management mit Microsoft Intune, Windows Autopilot, Entra ID Join, Cloud Policies und moderner App-Verteilung. Das ist sinnvoll, denn für viele Standardgeräte ist Intune heute die richtige Plattform.
Trotzdem bleibt eine wichtige Frage offen: Was passiert, wenn ihr ein Betriebssystem nicht nur konfigurieren, sondern vollständig neu installieren müsst?
Genau hier bleibt Bare-metal Deployment auch 2026 relevant. Nicht als Gegenmodell zu Intune, sondern als gezielte Fähigkeit für Recovery, Rebuilds, Offline-Szenarien, Hardware Refresh, Sondergeräte und Umgebungen, in denen ihr den Ausgangszustand eines Windows-Systems wirklich kontrollieren müsst.
Das WIchtigste in Kürze
- Bare-metal Deployment bleibt auch 2026 relevant, weil Intune und Autopilot Geräte vor allem konfigurieren, aber kein vollständig neues Betriebssystem von Grund auf installieren.
- Besonders wichtig ist Bare-metal Deployment für Sonderszenarien wie Ransomware-Recovery, Offline- und Notfallszenarien, Hardware Refresh, Sonderhardware, isolierte Umgebungen oder kontrollierte Neuinstallationen.
- Cloud-first und Bare-metal schließen sich nicht aus: Autopilot eignet sich für Standardgeräte, Bare-metal Deployment ergänzt die Endpoint-Strategie dort, wo ein sauberer, definierter Ausgangszustand nötig ist.
- Native WDS-Workflows sind 2026 keine belastbare Zukunftsoption mehr. Wer Bare-metal Deployment ernsthaft braucht, sollte auf dedizierte Plattformen wie SCCM/MECM oder die baramundi Management Suite setzen.
1 Was ist Bare-metal Deployment?
Bare-metal Deployment bezeichnet die vollständige Neuinstallation eines Betriebssystems auf leerer, gelöschter oder neu vorbereiteter Hardware. Das Gerät startet dabei typischerweise über PXE, USB oder ein anderes Bootmedium. Anschließend wird Windows neu installiert, partitioniert, mit Treibern versorgt und nach definierten Standards vorbereitet.
Der entscheidende Punkt: Beim Bare-metal Deployment wird das Betriebssystem from scratch aufgebaut. Das unterscheidet es grundlegend von vielen modernen Provisioning-Szenarien, bei denen ein vorhandenes Windows weiterverwendet und anschließend konfiguriert wird.
Typische Schritte sind:
- Gerät startet über PXE, USB oder ein lokales Medium.
- Datenträger werden erkannt, vorbereitet und bei Bedarf neu partitioniert.
- Windows wird neu installiert.
- Treiber, Spracheinstellungen, Basiskonfigurationen und Sicherheitsvorgaben werden angewendet.
- Das Gerät wird anschließend in euer Endpoint Management überführt.
Je nach Plattform kann dieser Prozess über Task Sequences, OS-Deployment-Profile, Skripte, Treiberlogik, Paketquellen und lokale oder zentrale Deployment-Infrastruktur gesteuert werden.
2 Vorteile: Warum Bare-metal Deployment 2026 noch relevant ist
Bare-metal Deployment ist nicht deshalb relevant, weil alte Deployment-Methoden romantisch verklärt werden sollten. Es ist relevant, weil bestimmte IT-Szenarien weiterhin einen vollständigen Neuaufbau erfordern.
Das gilt besonders dann, wenn der bestehende Zustand eines Geräts nicht mehr vertrauenswürdig, nicht mehr erreichbar oder nicht mehr standardisiert ist.
Recovery nach Ransomware, Malware oder Systemkorruption
Nach einem schwerwiegenden Sicherheitsvorfall wollt ihr euch nicht darauf verlassen, dass ein kompromittiertes Betriebssystem durch nachträgliche Konfiguration wieder sauber wird.
Wenn ein Gerät durch Ransomware, Malware, Rootkits, Manipulationen oder eine nicht mehr nachvollziehbare Systemveränderung betroffen ist, braucht ihr einen bekannten, sauberen Ausgangszustand. Genau hier ist Bare-metal Deployment wertvoll.
Ein vollständiger Rebuild kann sicherstellen, dass:
- das alte Betriebssystem entfernt wird,
- Partitionen kontrolliert neu aufgebaut werden,
- ein definierter Windows-Stand installiert wird,
- Treiber und Basiskonfigurationen nach Standard angewendet werden,
- das Gerät anschließend wieder in Intune, SCCM oder eine andere Management-Plattform aufgenommen wird.
Für eure Endpoint-Strategie bedeutet das: Modern Management reduziert viele operative Aufwände. Es ersetzt aber nicht automatisch eine belastbare Wiederherstellungsfähigkeit.
Offline- und Notfallszenarien
Cloud-basierte Verwaltung funktioniert hervorragend, solange Identitätsdienste, Internetzugang, Cloud-Endpunkte und Netzwerkpfade erreichbar sind. In Notfallsituationen kann genau das aber eingeschränkt sein.
Beispiele:
- Außenstandorte ohne stabile Verbindung
- isolierte Netzwerke
- Produktionsumgebungen mit restriktivem Internetzugang
- Netzwerkausfälle
- Disaster-Recovery-Situationen
- Field Deployments
- Geräte, die außerhalb klassischer Unternehmensstandorte wiederhergestellt werden müssen
Bare-metal Deployment kann je nach Umsetzung auch mit lokalen Medien, USB-Quellen oder lokalen Deployment-Shares funktionieren. Das ist besonders dann wichtig, wenn zentrale Dienste gerade nicht zuverlässig verfügbar sind.
Der Punkt ist nicht, dass jedes Unternehmen USB-basierte Notfallinstallationen braucht. Der Punkt ist: Wenn ihr solche Szenarien habt, solltet ihr sie bewusst planen und nicht erst im Ernstfall feststellen, dass eure Deployment-Fähigkeit vollständig von Cloud- oder Netzwerkkonnektivität abhängt.
Standardisierte Neuinstallation bei Hardware Refresh und Re-Use
Viele Geräte durchlaufen nicht nur einen einzigen Lebenszyklus. Sie werden neu zugewiesen, nach Reparaturen zurückgeführt, für andere Rollen vorbereitet oder im Rahmen eines Hardware Refresh neu ausgerollt. Hier reicht ein einfacher Reset nicht immer aus.
Bare-metal Deployment hilft euch, Geräte reproduzierbar auf einen definierten Stand zu bringen. Das ist besonders hilfreich, wenn ihr:
- Geräte aus unterschiedlichen Quellen vereinheitlichen wollt,
- OEM-Installationen bereinigen möchtet,
- Geräte vor der Weitergabe vollständig neu aufsetzen müsst,
- alte Konfigurationen sicher entfernen wollt,
- Hardware für neue Rollen vorbereitet,
- Geräte zwischen Fachbereichen, Standorten oder Nutzungskonzepten verschiebt.
Gerade bei Shared Devices, Kiosk-Systemen, Schulungsräumen oder produktionsnahen Clients ist ein definierter Ausgangszustand oft wichtiger als maximale Flexibilität.
Kontrolle über Windows-Version, Partitionierung, Treiber und Basiskonfiguration
Autopilot reduziert den Aufwand für eigene Images deutlich. Das ist einer seiner größten Vorteile. Ihr müsst weniger Images pflegen, könnt stärker standardisieren und neue Geräte schneller in Betrieb nehmen.
Trotzdem gibt es Fälle, in denen ihr mehr Kontrolle über den technischen Basiszustand braucht.
Dazu gehören zum Beispiel:
- definierte Partitionierung
- spezielle Treiberlogik
- bestimmte Windows-Versionen
- sprach- oder regionsspezifische Installationsstände
- Geräte mit Sonderhardware
- Vorbereitungen für bestimmte Sicherheits- oder Compliance-Anforderungen
- Umgebungen, in denen OEM-Images nicht gewünscht sind
Bare-metal Deployment gibt euch diese Kontrolle zurück. Ihr entscheidet nicht nur, welche Richtlinien später auf dem Gerät landen, sondern wie das Gerät technisch aufgebaut wird.
Microsoft Configuration Manager unterstützt Betriebssystembereitstellung über Task Sequences, mit denen unterschiedliche Aktionen innerhalb eines Deployment-Prozesses gesteuert werden können. Microsoft dokumentiert außerdem PXE-Boot-Prozesse in Configuration Manager für OS-Deployment-Szenarien.
Das ist kein Argument gegen Intune. Es ist ein Argument dafür, Deployment und Management sauber voneinander zu unterscheiden.
Sonderumgebungen bleiben Sonderumgebungen
Nicht jeder Endpoint ist ein klassischer Office-Laptop. In vielen Unternehmen gibt es Gerätetypen, die mit Standard-Autopilot-Prozessen nur teilweise oder gar nicht sinnvoll abgebildet werden können:
- Industrie-PCs
- Kiosk-Systeme
- Shared Devices
- Laborsysteme
- Schulungsraumgeräte
- Test- und Referenzsysteme
- Geräte in isolierten Netzwerken
- Geräte mit spezieller Peripherie
- Clients in produktionsnahen Umgebungen
- OT-nahe Windows-Systeme
Gerade solche Umgebungen brauchen häufig mehr als Cloud Enrollment und Policy Assignment. Sie brauchen klare Standards für Installation, Wiederherstellung, Treiber, Sonderkonfigurationen und Betrieb.
3 Bare-metal Deployment vs. Autopilot: kein Entweder-oder
Die Diskussion wird oft falsch geführt. Es geht nicht darum, ob Bare-metal Deployment oder Autopilot „besser“ ist. Es geht darum, welches Verfahren zu welchem Szenario passt.
Autopilot ist stark, wenn ihr neue Standardgeräte schnell, nutzernah und cloudbasiert bereitstellen wollt. Bare-metal Deployment ist stark, wenn ihr das Betriebssystem vollständig neu aufbauen oder einen definierten technischen Ausgangszustand erzwingen müsst.
In der folgenden Tabelle sind die wesentlichen Unterschiede zusammengefasst:
Wann Intune und Autopilot meistens ausreichen
Intune und Autopilot passen besonders gut, wenn ihr:
- neue Standardgeräte direkt vom Hersteller oder Distributor bereitstellt,
- mit Entra ID Join oder Hybrid Join arbeitet,
- Geräte über Internetverbindung einrichten könnt,
- keine vollständige Neuinstallation benötigt,
- OEM-Images akzeptiert oder bewusst nutzen wollt,
- Apps, Policies, Compliance und Security zentral über Intune steuert,
- End User möglichst wenig IT-Kontakt bei der Erstbereitstellung haben sollen.
In solchen Fällen ist Bare-metal Deployment oft nicht notwendig. Es wäre sogar zusätzlicher Aufwand, wenn ihr mit Autopilot bereits ein stabiles, schlankes und skalierbares Bereitstellungsmodell habt.
Wichtig ist aber: Ihr entscheidet euch damit bewusst gegen bestimmte Vorteile eines vollständigen Neuaufbaus. In Sondersituationen wie Ransomware-Recovery, Offline- oder Notfallszenarien sowie bei Anforderungen an maximale Kontrolle über Installation, Treiber, Partitionierung und Basiskonfiguration kann Bare-metal Deployment weiterhin die bessere Ergänzung sein.
4 SCCM und baramundi als mögliche Umsetzungswege
Wenn ihr Bare-metal Deployment weiterhin braucht, stellt sich die nächste Frage: Womit setzt ihr es um?
Native WDS-Workflows sind dafür 2026 keine belastbare Zukunftsoption mehr. Microsoft hat das automatisierte Hands-free Deployment über WDS im Zusammenhang mit CVE-2026-0386 gehärtet: Seit den April-2026-Updates ist es standardmäßig deaktiviert und wird nicht mehr unterstützt. Diese Einschränkung betrifft vor allem native WDS-Szenarien, nicht dedizierte Deployment-Plattformen mit eigenen Boot-Images und Bereitstellungsmechanismen.
Für viele Organisationen kommen deshalb etablierte Plattformen infrage, insbesondere SCCM oder die baramundi Management Suite. Beide Ansätze können je nach Bestand, Know-how, Infrastruktur und Betriebsmodell sinnvoll sein.
SCCM für komplexe Microsoft-nahe Umgebungen
Microsoft Endpoint Configuration Manager, auch bezeichnet als SCCM oder ConfigMgr, bleibt vor allem dort relevant, wo bereits eine gewachsene Microsoft-Client-Management-Umgebung existiert oder komplexe OS-Deployment-Prozesse benötigt werden.
Typische Stärken sind:
- Task Sequences
- PXE-basiertes Deployment
- Integration in bestehende Microsoft-Management-Prozesse
- Treiber- und Paketlogik
- Verteilung über Distribution Points
- Unterstützung komplexer Bestandsumgebungen
Wenn SCCM bei euch bereits sauber betrieben wird und es nicht nur noch aus historischen Gründen existiert, kann es weiterhin ein sehr leistungsfähiger Baustein für OS Deployment sein. Die entscheidende Frage ist nicht, ob SCCM „modern genug“ ist. Die entscheidende Frage ist, ob der operative Nutzen die Komplexität rechtfertigt.
baramundi Management Suite für integriertes Client Management und OS Deployment
Die baramundi Management Suite kann eine sinnvolle Alternative zu SCCM sein, wenn ihr OS Deployment, Client Management und Automatisierung in einer anderen Plattform bündeln wollt. Baramundi ist aus unserer Sicht die zurzeit stärkste Alternative zu SCCM am Markt und wird im Gegensatz zu SCCM konsequent weiterentwickelt. Es besteht ebenfalls die Möglichkeit des Co-Managements mit Microsoft Intune.
Auch hier gilt: Das Tool ist nicht der Ausgangspunkt der Entscheidung. Ausgangspunkt sollten eure Anforderungen sein.
5 Fazit: Bare-metal Deployment bleibt ein sinnvoller Baustein neben Intune
Bare-metal Deployment ist auch 2026 nicht tot, sondern hat eine klarere Rolle: Es ergänzt Intune und Windows Autopilot dort, wo Geräte nicht nur konfiguriert, sondern vollständig neu aufgebaut werden müssen.
Für Standardgeräte ist Autopilot oft der bessere Weg. Bei Recovery, Offline-Szenarien, Hardware Refresh, Sonderhardware oder isolierten Umgebungen bleibt Bare-metal Deployment aber ein wichtiger Baustein.
Der praktische Selbsttest lautet: Könnt ihr heute ein Gerät ohne Internetverbindung, ohne OEM-Image und ohne manuelle Nacharbeit auf einen definierten, sicheren Stand bringen?
Wenn die Antwort Nein lautet, fehlt euch eine wichtige Recovery- und Deployment-Fähigkeit. SOFTTAILOR unterstützt euch dabei, diese Lücke sauber zu bewerten und eine passende Lösung aufzubauen – von Intune und SCCM/MECM über die baramundi Management Suite bis zu Managed Services für Endpoint Management und Security.
Dorian beschäftigt sich seit 2011 mit Unternehmens- und IT-Strategie. Aufgrund der Endpoint Security Defizite vieler Unternehmen und der Informationsüberflutung hat er die Endpoint Strategie entwickelt. Dorian ist Mitgründer des Expertenzirkels "Endpoint Management" im IAMCP e.V.
Jahre Erfarung
Verwaltete Endgeräte
