Das passende MDT-Alternativprodukt hängt davon ab, wie Sie Windows heute bereitstellen. Vielleicht müssen Sie vorhandene Tasksequenzen weiterführen, ein konfiguriertes Windows-Systemabbild auf mehrere PCs verteilen oder Geräte über Cloud-Dienste bereitstellen, auf denen Windows bereits installiert ist. Diese Anforderungen führen zu unterschiedlichen Migrationswegen.
Microsoft hat das Microsoft Deployment Toolkit (MDT) im Januar 2026 offiziell eingestellt. Bestehende Installationen können weiterhin funktionieren, aber Updates und Support wurden beendet. Für Ihre nächste Bereitstellungsplattform sollten Sie deshalb zuerst erfassen, welche Aufgaben MDT heute übernimmt, und anschließend passende Ersatzlösungen auswählen.
Kurzantwort: Welche MDT-Alternative passt zu Ihrem Workflow?
Wenn Sie bereits Configuration Manager einsetzen, sollten Sie zunächst dessen native Funktionen für die Betriebssystembereitstellung (OSD) prüfen. Wenn Sie den klassischen MDT-Ansatz mit Tasksequenzen beibehalten möchten, ist DeployR eine Option. Für PXE, WinPE und die Bereitstellung eines konfigurierten Windows-Systems ist Wittytool Disk Clone relevant. Für cloudbasierte Bereitstellung auf Geräten, auf denen Windows bereits installiert ist, kommen Windows Autopilot und Intune infrage.
Mit dieser Übersicht können Sie die Auswahl zunächst eingrenzen:
| MDT-Alternative | Geeigneter Ausgangspunkt | Wichtiger Migrationspunkt |
|---|---|---|
| Configuration Manager OSD | Bestehende ConfigMgr-Umgebungen | MDT-abhängige Schritte durch unterstützte Workflows ersetzen |
| Windows Autopilot + Intune | Cloudbasierte Bereitstellung und Geräteaufnahme | Separaten Weg für die eigentliche Windows-Installation planen |
| DeployR | Bereitstellung auf Basis von Tasksequenzen | Workflows neu abbilden und passendes Supportmodell wählen |
| Wittytool Disk Clone | PXE, WinPE und Bereitstellung konfigurierter Windows-Systeme | Ein kompatibles Image im unterstützten Format erstellen |
| SmartDeploy | Image-Bereitstellung auf unterschiedlichen Hardwaremodellen | Geräte, Treiber und Image-Workflow aufeinander abstimmen |
| ManageEngine OS Deployer | Zentrale Image-Bereitstellung und Konfiguration | Templates, Treiber und Bereitstellungsinfrastruktur planen |
| AOMEI Image Deploy | LAN-Bereitstellung mit Backupper-Images | Kompatible Images vorbereiten und passende Edition wählen |
| FOG / Clonezilla | Open-Source-Imaging und Batch-Cloning | Imaging- und Boot-Umgebung selbst betreiben |
| OSDCloud | PowerShell-basierte Windows-Bereitstellung | Skripte, Boot-Medien und Bereitstellungsinhalte pflegen |
Was bedeutet die MDT-Einstellung für die Windows-Bereitstellung?
Bestehende Installationen können weiterlaufen, aber der Microsoft-Support ist beendet
Microsoft hat MDT offiziell eingestellt. Die offizielle MDT-Mitteilung von Microsoft beendet Updates, Fehlerbehebungen, Support und zukünftige Kompatibilitätsupdates für neue Windows-Versionen. Gleichzeitig erklärt Microsoft, dass bestehende Installationen zunächst weiterhin funktionieren.
Damit haben Sie Zeit für eine geplante Migration, aber die Verantwortung für den Weiterbetrieb einer bestehenden MDT-Umgebung verändert sich. Ein Deployment, das heute funktioniert, garantiert nicht die Kompatibilität mit der nächsten Windows-Version, einem neuen ADK oder neuer Hardware.
Planen Sie die Migration deshalb möglichst gemeinsam mit anstehenden Windows-, ADK- oder Hardwareänderungen. So können Sie die Ersatzlösung testen, bevor die bisherige Umgebung an ihre Grenzen kommt.
Standalone-MDT und die Configuration-Manager-Integration sind beide betroffen
Die Einstellung betrifft sowohl MDT Standalone als auch die Integration von MDT in Configuration Manager.
Configuration Manager OSD selbst bleibt eine unterstützte Bereitstellungsoption. Entscheidend ist daher zunächst, welche Art von MDT-Umgebung Sie tatsächlich betreiben.
Der Ersatz einer eigenständigen Deployment Share ist eine andere Aufgabe als das Entfernen der MDT-Erweiterungen aus vorhandenen Configuration-Manager-Tasksequenzen.
Prüfen Sie vor Änderungen:
- Welche Tasksequenzen existieren?
- Welche Schritte stammen direkt aus MDT?
- Welche Skripte und Variablen werden verwendet?
- Welche Boot-Images und Inhalte hängen von MDT ab?
- Welche Komponenten werden über eine Deployment Share bereitgestellt?
Wenn Ihr Workflow zusätzlich Windows Deployment Services (WDS) für PXE verwendet, sollte diese Abhängigkeit separat betrachtet werden, da Microsoft auch WDS auf einen neuen Migrationspfad führt.
Was hat MDT eigentlich übernommen?
MDT hat Bereitstellungsinhalte mit einer automatisierten Abfolge von Aktionen verbunden.
Eine Deployment Share konnte unter anderem Betriebssysteme, Anwendungen, Treiber und Skripte enthalten, während Tasksequenzen festlegten, wie diese Ressourcen während der Bereitstellung verwendet werden.
Die wichtigste Frage bei der Migration lautet daher nicht:
„Welches Produkt ersetzt MDT?“
Sondern:
„Welche MDT-Funktionen muss meine neue Umgebung tatsächlich ersetzen?“
| MDT-Funktion | Was die neue Umgebung bereitstellen muss |
|---|---|
| Tasksequenzen | Eine Orchestrierungs-Engine, z. B. ConfigMgr OSD oder DeployR |
| Deployment Share | Einen Speicherort für Images, Anwendungen, Treiber und Skripte |
| WinPE-Integration | Einen Weg zum Erstellen, Pflegen und Starten der Bereitstellungsumgebung |
| OS-Images | Unterstützte Funktionen für Erfassung, Speicherung und Bereitstellung |
| Treiber | Treiberverwaltung oder Treiberintegration |
| Anwendungen | Anwendungsinstallation und -konfiguration oder vorkonfiguriertes Image |
| Skripte | PowerShell oder eine andere Automatisierungsumgebung |
| Benutzerstatus | USMT oder ein anderes Verfahren für die Migration von Benutzerdaten und Einstellungen |
PXE gehört dabei zur umgebenden Netzwerkstart-Infrastruktur und wurde in klassischen MDT-Umgebungen häufig über WDS bereitgestellt.
WinPE kann dagegen weiterhin Teil der neuen Bereitstellungsumgebung sein. Die entscheidende Frage ist, welches Werkzeug WinPE erstellt und startet und was nach dem Start des Zielcomputers passiert.
MDT-Alternativen nach Bereitstellungsworkflow
Microsoft Configuration Manager OSD für bestehende ConfigMgr-Umgebungen
Wenn Ihre Organisation bereits Configuration Manager für Inhalte, Distribution Points und Geräteverwaltung einsetzt, ist das native Configuration-Manager-OSD ein naheliegender erster Kandidat.
Configuration Manager bietet weiterhin:
- Tasksequenzen
- Boot-Images
- OS-Images
- Treiberverwaltung
- Bereitstellungsüberwachung
Die aktuelle Dokumentation zur Betriebssystembereitstellung mit Configuration Manager beziehungsweise die aktuelle Configuration-Manager-OSD-Dokumentation sollte bei der konkreten Migration als technische Referenz dienen.
Der wichtigste Teil der Migration besteht darin, alle MDT-Abhängigkeiten aus den vorhandenen Tasksequenzen zu identifizieren.
Eine Tasksequenz kann weiterhin in der Configuration-Manager-Konsole sichtbar sein und trotzdem MDT-spezifische Schritte, Skripte oder Pakete enthalten.
Diese Abhängigkeiten müssen ersetzt werden, bevor die MDT-Integration entfernt wird.
Der Vorteil dieser Route liegt vor allem darin, dass das vorhandene Wissen und die bestehende Infrastruktur weiter genutzt werden können. Wenn Sie dagegen nur einen kleinen eigenständigen MDT-Server betreiben, sollten Sie Aufwand, Lizenzierung und Administration einer vollständigen Managementplattform gegen Ihren tatsächlichen Bedarf abwägen.
Windows Autopilot und Intune für cloudbasierte Bereitstellung
Windows Autopilot und Intune eignen sich für Organisationen, die Geräte über Cloud-Identität, Anwendungen und Richtlinien konfigurieren möchten.
Im typischen Szenario startet Autopilot mit dem vom Hersteller installierten Windows und macht daraus ein verwaltetes Unternehmensgerät.
Das verändert die Vorbereitung von Mitarbeiter-PCs grundlegend. Statt möglichst viele Anwendungen und Einstellungen in ein Referenzimage einzubauen, werden diese über Managementdienste zugewiesen.
Das ist besonders interessant, wenn:
- Geräte direkt an Mitarbeitende ausgeliefert werden,
- Geräte über das Internet erreichbar sind,
- Intune bereits eingesetzt wird,
- Microsoft Entra ID Teil der Umgebung ist,
- eine Cloud-first-Strategie verfolgt wird.
Die wichtigste Einschränkung gegenüber klassischem MDT-Imaging betrifft die eigentliche Windows-Installation.
Ein Gerät mit leerer Ersatzfestplatte benötigt weiterhin einen Weg, Windows zu installieren. Microsoft bietet außerdem einen Autopilot-Workflow für bestehende Geräte, bei dem eine native Configuration-Manager-Tasksequenz zur Neuinstallation und Vorbereitung verwendet wird.
Autopilot kann daher der primäre Provisioning-Weg werden, während eine andere Methode Geräte übernimmt, bei denen eine vollständige Neuinstallation oder ein klassisches Imaging erforderlich ist.
DeployR für Tasksequenz-basierte Bereitstellung
DeployR ist besonders interessant, wenn der zentrale Bestandteil Ihres bisherigen MDT-Workflows die Arbeit mit Tasksequenzen ist.
Der Ansatz deckt unter anderem Bare-Metal-Bereitstellung, Windows-Image-Bereitstellung, Treiber und Anwendungsinstallation ab.
DeployR Community bietet einen kostenlosen, Community-unterstützten Ansatz mit benutzerinitiierten Tasksequenzen, PXE-Unterstützung sowie USB- und Offline-Medien.
Das macht DeployR für Administratoren interessant, die nach dem Ende von MDT weiterhin mit einer ähnlichen Form der Bereitstellungsorchestrierung arbeiten möchten.
Der entscheidende Punkt ist jedoch der Migrationsaufwand.
Vertraute Konzepte bedeuten nicht, dass bestehende MDT-Tasksequenzen, Regeln oder Skripte direkt übernommen werden können.
Dokumentieren Sie deshalb zunächst, was jeder einzelne MDT-Schritt tatsächlich tut, und bilden Sie dieses Verhalten anschließend in der neuen Plattform ab.
Wenn bedingte Schritte und komplexe Anwendungsinstallationen das Zentrum Ihrer Builds sind, ist dieser Ansatz besonders interessant.
Wenn Sie dagegen vor allem dieselbe vorkonfigurierte Windows-Umgebung per PXE und WinPE auf mehrere Rechner verteilen möchten, passt ein imagebasierter Ansatz möglicherweise besser.
Wittytool Disk Clone für PXE, WinPE und die Bereitstellung vorkonfigurierter Windows-Systeme
Wittytool Disk Clone ist interessant, wenn Sie einen Bereitstellungsprozess beibehalten möchten, der auf PXE, WinPE und einem vorkonfigurierten Windows-System basiert.
Das passt beispielsweise zu:
- Büro-Rollouts
- Schulungsräumen
- Laboren
- standardisierten Arbeitsplatz-PCs
- mehreren Geräten mit derselben Software- und Konfiguration
Wittytool Disk Clone unterstützt PXE-Boot, die Erstellung einer WinPE-Umgebung und die zentrale Windows-Image-Bereitstellung.
Weitere Informationen bietet die deutsche Seite zur Windows-Image-Bereitstellung auf mehreren PCs.
Die Lösung unterstützt einen Workflow, bei dem das Quellsystem zunächst als Image bzw. Backup gesichert und anschließend auf Ziel-PCs bereitgestellt wird.
Dabei können installierte Anwendungen und Benutzerkonten Bestandteil des bereitgestellten Systems bleiben. Die Windows-SID der Ziel-PCs kann bei Bedarf während der Bereitstellung geändert werden.
Ein möglicher Ablauf ist:
- Quellsystem vorbereiten und benötigte Anwendungen konfigurieren.
- Mit Wittytool Disk Clone ein kompatibles System- oder Datenträger-Image erstellen.
- WinPE- und PXE-Bereitstellung für das Zielnetz vorbereiten.
- Die Ziel-PCs verbinden und die Bereitstellung automatisch oder manuell starten.
- Anwendungen, Treiber, Identität und Zugriff auf Unternehmensressourcen prüfen.
Wichtig für die Migration: Wittytool Disk Clone arbeitet mit System- oder Datenträger-Images aus dem eigenen Backup-Workflow. Ein bestehendes MDT-WIM kann daher nicht einfach als direkte Importdatei vorausgesetzt werden.
Die Image-Ebene und die bisherige MDT-Tasksequenz-Logik müssen getrennt betrachtet werden.
Wenn Sie ein konfiguriertes Windows-System möglichst direkt auf mehrere Geräte übertragen möchten, ist dieser imagebasierte Ansatz eine andere Migrationsrichtung als die vollständige Ablösung von MDT durch eine Tasksequenz-Plattform.
SmartDeploy für Imaging auf unterschiedlichen Hardwaremodellen
SmartDeploy ist interessant, wenn Treiber und unterschiedliche Hardwaremodelle einen großen Teil der bisherigen MDT-Arbeit ausmachen.
Der Ansatz trennt das Windows-Image von den hardwarebezogenen Treibern und verwendet dafür unter anderem Platform Packs.
Das kann den Image- und Treiberbereich eines MDT-Workflows ersetzen.
Bei der Bewertung sollten Sie Ihre realen Hardwaremodelle, Anwendungen und Einsatzorte berücksichtigen.
Ein erfolgreicher Test mit einem einzigen Laptop bedeutet noch nicht, dass die gleiche Struktur auch für Desktop-PCs, unterschiedliche Generationen oder Außenstellen funktioniert.
Dokumentieren Sie außerdem, welche Aktionen vor und nach der eigentlichen Image-Bereitstellung ausgeführt werden. Besonders PowerShell-Skripte und Anwendungsinstallationen dürfen bei der Migration nicht einfach aus dem Blick geraten.
ManageEngine OS Deployer für zentrale Bereitstellungsverwaltung
ManageEngine OS Deployer richtet sich an Teams, die Images zentral erfassen, Treiber verwalten und Bereitstellungen über eine zentrale Verwaltungsoberfläche konfigurieren möchten.
Dieser Ansatz ist interessant, wenn Ihr bisheriges MDT-System mehr geleistet hat als das bloße Schreiben eines Images.
Beispielsweise können Betriebssystembereitstellung, Geräteeinstellungen und Anwendungsinstallation Teil desselben wiederholbaren Prozesses sein.
Vor der Migration sollten Sie festlegen:
- Wo Images und andere Inhalte gespeichert werden.
- Wie Zielgeräte booten.
- Welche Funktionen Ihre benötigte Edition unterstützt.
- Wie Außenstellen eingebunden werden.
- Wie Geräte außerhalb des lokalen Netzes behandelt werden.
Nehmen Sie einen repräsentativen bestehenden MDT-Build in den Pilotbetrieb auf und ordnen Sie jeden erforderlichen Schritt dem neuen Template oder Prozess zu.
AOMEI Image Deploy für LAN-Bereitstellung mit Backupper-Images
AOMEI Image Deploy ist eine Option für Organisationen, deren hauptsächlicher MDT-Anwendungsfall die Verteilung eines vorbereiteten System- oder Datenträger-Images auf mehrere PCs im lokalen Netzwerk ist.
Die Lösung arbeitet mit Images aus AOMEI Backupper und bietet unterschiedliche Editionen für verschiedene Anforderungen.
Dieser Ansatz ist besonders interessant, wenn Sie vor allem eine gemeinsame Windows-Umgebung auf mehrere Rechner verteilen möchten.
Allerdings ist das Image-Format ein wichtiger Migrationspunkt.
Planen Sie die neue Umgebung um den unterstützten Backupper-Workflow herum, statt davon auszugehen, dass das vorhandene MDT-WIM direkt übernommen werden kann.
Auch Aufgaben nach der Image-Bereitstellung müssen neu verortet werden:
- Anwendungsanpassungen
- Computeridentität
- Skripte
- organisationsspezifische Konfiguration
FOG und Clonezilla für Open-Source-Imaging
FOG und Clonezilla sind getrennte Open-Source-Optionen für Teams, die ihre Imaging-Infrastruktur selbst betreiben möchten.
FOG eignet sich eher für eine zentrale Netzwerk-Imaging-Umgebung mit eigenem Server und Boot-Infrastruktur.
Clonezilla konzentriert sich stärker auf Datenträger- und System-Imaging. Clonezilla Server Edition und verwandte Modi können für die Bereitstellung auf mehreren Rechnern genutzt werden.
Beide Ansätze können den Image-Verteilungsanteil eines MDT-Workflows abdecken.
Sie müssen jedoch weiterhin eigene Lösungen für Anwendungsbereitstellung, Treiber, Benutzerdaten und spezielle Automatisierungslogik planen.
Der wesentliche Unterschied liegt in der Betriebsverantwortung: Weniger Lizenzkosten bedeuten nicht automatisch weniger Administrationsaufwand.
OSDCloud für PowerShell-basierte Windows-Bereitstellung
OSDCloud ist interessant, wenn Ihre Administratoren eine stark PowerShell-basierte Bereitstellungsstrategie bevorzugen.
Die Plattform kann aus WinPE ausgeführt werden und Windows aus Online-Quellen oder einem lokalen USB-Cache bereitstellen.
Dieser Ansatz bietet viel Kontrolle über die Bereitstellungslogik.
Er eignet sich deshalb für Teams, die bereit sind, Skripte und deren Abhängigkeiten selbst zu pflegen.
Mit jeder neuen Windows-Version, jedem ADK-Wechsel und jeder neuen Hardwaregeneration müssen diese Skripte erneut getestet werden.
Die Migration besteht daher weniger darin, MDT gegen ein anderes Paket auszutauschen, sondern darin, das benötigte Verhalten Schritt für Schritt in einer neuen skriptbasierten Umgebung abzubilden.
Was sollten Sie vor der Wahl einer MDT-Alternative vergleichen?
Tasksequenzen, feste Images oder Cloud-Provisioning
Beginnen Sie mit dem gewünschten Ergebnis.
Wenn verschiedene Rollen unterschiedliche Anwendungen und Skripte benötigen, sollten Sie eine Tasksequenz- oder Automatisierungsplattform prüfen.
Wenn mehrere Geräte exakt dieselbe vorbereitete Umgebung benötigen, ist Image-Bereitstellung möglicherweise die bessere Wahl.
Wenn Windows bereits installiert ist und Anwendungen und Einstellungen über Managementdienste verteilt werden können, kann Cloud-Provisioning besser passen.
Diese Ansätze können auch kombiniert werden.
Beispielsweise können Mitarbeiter-Laptops über Autopilot bereitgestellt werden, während ein Schulungsraum weiterhin mit einem standardisierten Image eingerichtet wird.
Treiber, Bootmethoden sowie Remote- und Offline-Standorte
Prüfen Sie beide Phasen der Treiberbereitstellung:
- Die Bereitstellungsumgebung muss Netzwerk und Speicher erkennen.
- Das installierte Windows-System benötigt anschließend die passenden Treiber.
Testen Sie deshalb:
- UEFI
- Secure Boot
- tatsächliche Hardwaremodelle
- Netzwerksegmente
- Speicherorte der Inhalte
- lokale und entfernte Standorte
Für Offline-Standorte müssen alle benötigten Medien und Inhalte lokal verfügbar sein.
Bei Remote-Benutzern muss außerdem geklärt werden, wie eine Neuinstallation beginnt, wenn Windows nicht mehr startet.
Lizenzierung, Support und laufender Wartungsaufwand
Vergleichen Sie die Gesamtkosten:
- Softwarelizenzen
- Server und Speicher
- Image-Pflege
- Skriptwartung
- Support
- Testaufwand
- Dokumentation
Eine kostenlose Community-Version, ein Open-Source-Projekt und eine zeitlich begrenzte Testversion sind nicht dasselbe wie eine dauerhaft kostenlose Enterprise-Lösung.
Für Wittytool Disk Clone sollte außerdem geprüft werden, welcher Plan zu den geplanten Zielgeräten und dem Image-Deployment-Szenario passt.
So planen Sie die Migration von MDT
Deployment Share und wiederverwendbare Inhalte inventarisieren
Sichern Sie die Deployment Share und dokumentieren Sie die Konfiguration, bevor Sie Änderungen vornehmen.
Erfassen Sie insbesondere:
- Tasksequenzen und ihre Bedingungen
- Variablen und Abhängigkeiten
CustomSettings.iniBootstrap.iniunattend.xml- Anwendungsinstallationen
- Konfigurationsdateien
- Treiberpakete
- Boot-Images
- eigene WinPE-Komponenten
- OS-Images
- Skripte
- Anforderungen zur Migration des Benutzerstatus
Markieren Sie jeden Bestandteil als:
- wiederverwendbarer Inhalt,
- Logik, die neu aufgebaut werden muss,
- oder Abhängigkeit, die entfernt werden soll.
Ein Anwendungsinstaller kann beispielsweise weiterverwendbar sein, auch wenn der MDT-Schritt, der ihn gestartet hat, ersetzt werden muss.
Ein WIM kann auf einer Plattform nutzbar sein, während auf einer anderen Plattform ein neues Image erstellt werden muss.
Workflow neu aufbauen und repräsentative Geräte testen
Bevor ein Pilot ein Betriebssystem-Image schreibt, sollten notwendige Benutzerdaten gesichert und die Ziellaufwerke überprüft werden.
Testen Sie mit Geräten, die Ihre tatsächliche Hardware und Ihre verschiedenen Bereitstellungsorte repräsentieren.
Definieren Sie vor dem Pilot:
- Windows startet erfolgreich.
- Treiber sind vorhanden.
- Anwendungen funktionieren.
- Computeridentität ist korrekt.
- Domain- oder Cloud-Enrollment funktioniert.
- Management-Agenten werden korrekt registriert.
- Geschäftsanwendungen und Ressourcen sind erreichbar.
Testen Sie anschließend zunächst eine kleine Anzahl Geräte.
Dokumentieren Sie Fehler, Wiederherstellungsschritte sowie Auswirkungen auf Netzwerk und Speicher.
MDT-Abhängigkeiten aus Configuration Manager sicher entfernen
Wenn Sie MDT in Configuration Manager integriert haben, sollte die Entfernung erst erfolgen, nachdem die benötigten Funktionen dokumentiert und in der Testumgebung ersetzt wurden.
Microsoft empfiehlt ausdrücklich diese Reihenfolge:
Zuerst alle MDT-Tasksequenzschritte entfernen, danach die MDT-Integration entfernen.
So sollen Beschädigungen und Probleme bei späteren Änderungen an Tasksequenzen vermieden werden. Nutzen Sie die aktuelle Microsoft-Anleitung zur MDT-Migration für die konkrete Reihenfolge.
Sichern Sie vor der Änderung die vorhandenen Tasksequenzen und stellen Sie sicher, dass die Ersatzschritte bereits getestet wurden.
Standalone-MDT-Umgebungen benötigen einen eigenen schrittweisen Cutover, einschließlich Ersatz für Boot-Medien, Inhaltszugriff und Wiederherstellungsprozess.
Häufig gestellte Fragen
Wird MDT nach seiner Einstellung noch unterstützt?
Nein. Microsoft hat MDT eingestellt. Das gilt sowohl für die Standalone-Version als auch für die Integration in Configuration Manager.
Bestehende Installationen können weiter funktionieren, erhalten aber keine Updates, Fehlerbehebungen, Supportleistungen oder zukünftigen Kompatibilitätsupdates.
Welche MDT-Alternativen sind kostenlos?
DeployR Community bietet eine kostenlose, Community-unterstützte Bereitstellungsoption. FOG und Clonezilla sind Open-Source-Alternativen für Imaging. AOMEI Image Deploy bietet ebenfalls eine kostenlose Edition mit eigenen Funktions- und Nutzungseinschränkungen.
Vergleichen Sie nicht nur den Lizenzpreis, sondern auch Support, Wartungsaufwand und die benötigte Funktionalität.
Kann ich meine vorhandenen MDT-Tasksequenzen und WIM-Images weiterverwenden?
Das hängt von der Zielplattform ab.
Installer, Skripte und Treiber können häufig weiterverwendet werden, während die Tasksequenzlogik neu abgebildet werden muss.
Auch WIM-Kompatibilität variiert.
Wittytool Disk Clone arbeitet mit Disk- oder System-Images aus dem eigenen Backup-Workflow. Ein vorhandenes MDT-WIM sollte deshalb nicht als direkt importierbares Image vorausgesetzt werden.
Kann Windows Autopilot MDT für bestehende Geräte ersetzen?
Autopilot kann Bestandteil einer Migrationsstrategie für bestehende Geräte sein.
Microsoft bietet einen „Autopilot for existing devices“-Workflow, bei dem eine native Configuration-Manager-Tasksequenz für die Neuinstallation und anschließende Bereitstellung verwendet wird.
Bei der Planung muss daher sowohl die Windows-Installation als auch Enrollment, Anwendungen, Richtlinien und Geräteidentität berücksichtigt werden.
Kann ich eine konfigurierte Windows-Umgebung ohne Sysprep bereitstellen?
Wittytool Disk Clone unterstützt einen Image-Bereitstellungsworkflow ohne vorheriges Sysprep und bietet optional eine SID-Änderung auf den Ziel-PCs.
Das bedeutet jedoch nicht, dass damit die Generalisierung eines Windows-Images durch Sysprep vollständig ersetzt wird. Prüfen Sie weiterhin Ihre Anforderungen an Hardware, Identität, Anwendungen und Support.
Die passende MDT-Alternative sollte sich danach richten, welche Arbeit Ihr Team weiterhin erledigen muss.
Für bestehende Configuration-Manager-Umgebungen ist native OSD ein sinnvoller Ausgangspunkt. Für komplexe Tasksequenzen sollten Tasksequenz-Plattformen geprüft werden. Für Cloud-Provisioning eignet sich Autopilot, wenn es zum Gerätelebenszyklus passt.
Wenn der Workflow dagegen hauptsächlich aus PXE, WinPE und der Bereitstellung eines konfigurierten Windows-Systems besteht, sollte Wittytool Disk Clone als imagebasierte Migrationsoption betrachtet und zunächst mit repräsentativen Geräten getestet werden.