Haben Sie Probleme, ADKS unter Windows 11 zu nutzen? Wie lassen sich typische Fehler schnell beheben und die optimale Lösung effizient umsetzen?
Das Windows Assessment and Deployment Kit (ADK) von Microsoft unterstützt Administratoren beim Deployment, der Anpassung von System‑Images, der Erstellung von WinPE und automatisierten Installationen.
Mit Windows 11 erscheinen regelmäßig neue ADK‑Versionen, oft verbunden mit Kompatibilitätsproblemen, Bugs und Designänderungen, die insbesondere Tools und Skripte betreffen, die auf WinPE oder bestimmte ADK‑Versionen angewiesen sind. Im Folgenden werden typische Probleme, ihre Ursachen sowie Lösungsansätze und Best Practices vorgestellt, um ADK unter Windows 11 zuverlässig zu nutzen.
Häufige Probleme mit ADK unter Windows 11
❗ WinPE‑Build stimmt nicht mit Windows 11 überein / 32‑Bit fehlt
- Mit dem ADK für Windows 11 (z. B. Version 22H2) hat Microsoft die 32‑Bit‑Variante von WinPE entfernt. Das bedeutet: WinPE existiert nur noch in 64 Bit.
- Viele Deployment‑Werkzeuge wie Microsoft Deployment Toolkit (MDT) oder andere Skripte erwarten jedoch traditionell, dass auch der Ordner
...\WinPE\x86\WinPE_OCsexistiert — selbst wenn 32‑Bit nicht genutzt wird. In solchen Fällen führen Pfadprobleme zu Fehlern oder Abstürzen. - So berichtete etwa ein Fall, in dem beim Erstellen eines Startabbilds mit MDT der Pfad nicht gefunden wurde — der Prozess brach ab, obwohl ein 64‑Bit‑Image gebaut wurde.
Folge: Boot‑WIMs oder Deployments lassen sich nicht korrekt erzeugen oder starten.
💻 Fehlende Unterstützung für VBScript / Skripte & HTA‑Anwendungen
- In der ADK‑Version vom September 2023 (Build 25398) fehlt offenbar die
vbscript.dll— damit funktionieren VBScript und HTA‑basierte Scripte im WinPE nicht mehr. - Das betrifft insbesondere Umgebungen, die auf VBScript angewiesen sind — etwa MDT‑Tasksequenzen, HTA‑Dialoge, Installationsskripte etc. Viele Nutzer in Foren und Communities melden danach Script‑Fehler, Abbrüche oder unerwartetes Verhalten.
- Für HTA-Anwendungen unter WinPE (z. B. Setup‑Dialoge) gibt es dokumentierte Fehlermeldungen wie „Script Error – An error has occurred in the script on this page“.
Folge: Automatisierungen, Installationsroutinen oder Anpassungen brechen ab — vor allem wenn sie auf VBScript oder HTA basieren.
🔄 Fehlerhafte Boot‑Environment‑Erstellung / DISM‑Fehler & Image‑Probleme
- Bei der Erstellung eines bootfähigen WinPE‑Images mit bestimmten ADK‑Versionen (z. B. 10.1.25398.1) kann es zu Fehlern beim Mounten/Unmounten der WIM kommen. Bei diesem Vorgang scheint
DISMin manchen Fällen mit Fehlern wie „Commit failed“ oder „Unmount failed“ abzubrechen. Dies wurde im Zusammenhang mit Boot‑Environment‑Tools gemeldet. - Manche Tools oder Workflows (z. B. Backup‑ oder Deployment‑Tools), die Boot‑Environments erzeugen, funktionieren dann nicht mehr — oder der erzeugte Boot‑Stick verweigert den Dienst.
Folge: Boot‑WIMs sind defekt oder unbrauchbar — Deployments oder Notfall‑Sticks funktionieren nicht.
⚠️ Kompatibilitätsprobleme mit Deployment‑Frameworks (z. B. MDT, ConfigMgr)
- Offizielle Quellen weisen darauf hin, dass bestimmte ADK‑Versionen (z. B. 10.1.25398.1) nicht unterstützt sind, wenn sie mit Tools wie Microsoft Configuration Manager (ConfigMgr) verwendet werden.
- Für MDT gibt es bekannte Probleme: Beim Versuch, mit ADK 22H2 ein Startimage zu erstellen, schlägt der Assistent fehl — unabhängig davon, ob 32‑Bit wirklich gebraucht wird.
- Zahlreiche Nutzer berichten in Foren, dass nach einem ADK‑Upgrade ihr Deployment‑Workflow nicht mehr funktioniert — und dass der Rückgriff auf ältere ADK‑Versionen (z. B. ADK 10.1.22000 für Windows 10) Abhilfe schafft.
Folge: Deployment‑Prozesse sind instabil, unzuverlässig oder brechen ab — was zu Zeitverlust und größeren Aufwand führt.
🔐 Einschränkungen bei BitLocker‑Preprovisioning und neuem Speicher (z. B. UFS)
- Mit der ADK-Version 25398 existieren negative Berichte, dass BitLocker‑Preprovisioning im WinPE nicht funktioniert — bei Einsatz dieser ADK‑Version schlägt der Vorgang mit „file not found“ fehl.
- Zudem gibt es dokumentierte Einschränkungen bei Geräten mit UFS‑Speicher (z. B. einige moderne Notebooks oder Tablets). Beim Einsatz von DISM oder anderen Image‑Tools kann es zu Systemabstürzen kommen (z. B. DPC_WATCHDOG_VIOLATION).
Folge: Verschlüsselte Installationen oder Geräte mit modernen Speichertypen können instabil oder gar nicht deploybar sein.
Ursachen: Warum gehen manche Dinge schief?
| Ursache | Beschreibung |
|---|---|
| Designänderungen in ADK | Microsoft hat z. B. 32‑Bit‑WinPE entfernt — das bricht alte Annahmen in Skripten und Deployment-Frameworks. |
| Unvollständige Qualitätssicherung / fehlende Legacy‑Komponenten | Im September 2023 wurden Komponenten wie vbscript.dll entfernt — ohne dass Dokumentation oder Hinweis folgten. |
| Komplexität von Deployment‑Toolchains | Kombination aus ADK, WinPE, MDT/ConfigMgr, Skripten, BitLocker, Hardware — viele Variablen = viele Fehlerquellen. |
| Nicht ausreichende Kompatibilitätstests für neue OS‑Versionen | Manche ADK‑Builds werden nicht mit allen Szenarien unter Windows 11 getestet — etwa MDT, Server‑Deployment oder ältere Hardware. |
Lösungswege & Best Practices
✅ 1. Verwenden Sie eine stabile, unterstützte ADK‑Version
- Meiden Sie problematische Builds wie ADK 10.1.25398.1 (Sep 2023), wenn Sie auf Tools wie MDT, ConfigMgr oder Skripte angewiesen sind.
- Aktuell empfohlen: ADK 10.1.26100.2454 (Dezember 2024) — diese Version unterstützt Windows 11 (25H2, 24H2) und ist laut Microsoft gepflegt.
- Beim Deployment mehrerer Windows‑Versionen sollte die ADK‑Version möglichst der höchsten Version entsprechen.
🔧 2. Workarounds für fehlende Komponenten (z. B. VBScript, WinPE x86)
Wenn Sie nicht umsteigen können — etwa wegen integraler Skripte/Prozesse — gibt es Möglichkeiten:
- Für VBScript: Sie können die fehlende
vbscript.dllaus einer früheren ADK-Version übernehmen und im WinPE registrieren. Damit funktionieren VBScript/HTA wieder. - Für MDT mit ADK ohne x86 WinPE: Legen Sie manuell einen leeren Ordner
x86\WinPE_OCsin der ADK‑Installation an. Manche Tools erwarten diesen Pfad — und brechen sonst ab.
🖥️ 3. Wenn Boot‑Environment / WinPE erforderlich ist: Boot‑Image regenerieren & Testen
- Nach jeder ADK‑Änderung WinPE neu generieren, Boot‑Image komplett neu bauen — nicht einfach nur alte Images weiternutzen. Das hilft, alte Inkonsistenzen loszuwerden.
- Wenn Sie Tools wie BitLocker‑Preprovisioning, Imaging oder spezielle Skripte einsetzen: Vor dem Rollout gründlich testen — idealerweise auf Testhardware.
🧪 4. Bei Problemen: Analyse mit DISM / Protokollen / Logs
- Nutzen Sie
DISMzur Überprüfung der Imageintegrität — besonders, wenn Boot‑Images nicht starten oder WIM‑Fehler auftreten. Ähnlich wie bei generischen Windows‑Fehlern. - Achten Sie auf Rückmeldungen beim Mounten / Unmounten von WIMs — Fehler wie „Commit failed“ oder „Unmount failed“ weisen auf ein beschädigtes Boot‑Environment hin.
Typische Fehlerszenarien & praktische Empfehlungen
| Szenario | Typische Fehler / Symptome | Empfehlung |
|---|---|---|
| Deployment mit MDT nach Upgrade auf ADK 22H2 / 23H2 | Deployment‑Wizard crasht, Boot‑Image kann nicht erstellt werden | ADK-Version wechseln oder leeren x86\WinPE_OCs‑Ordner anlegen. |
| Tasksequenz oder Installationsskript mit VBScript/HTA unter WinPE | „Script Error“, Skript bricht ab, GUI‑Dialoge funktionieren nicht | vbscript.dll nachladen/registrieren oder Skript auf PowerShell umstellen. |
| Boot‑Stick / WinPE‑Medium erstellen — startet nicht / hängt beim Start | WIM schreibt Fehler, Boot hängt, Neustart-Schleife | WinPE neu erzeugen, DISM prüfen, ggf. andere ADK-Version verwenden. |
| BitLocker-Preprovisioning im Deployment | Fehler „file not found“, BitLocker nicht aktivierbar | Neueren ADK (>= 10.1.26100) nutzen oder Umgebung prüfen. |
| Geräte mit UFS‑Speicher, neue Hardware | Image‑Installation bricht mit DPC/Watchdog‑Fehler ab | Kompatibilität prüfen, ggf. Windows RE statt WinPE nutzen oder neuere Updates abwarten. |
Warum ADK‑Probleme gerade jetzt zunehmen
- Mit Windows 11 führen neue Sicherheitsmodelle, neue Hardware (z. B. UFS, neue CPUs/UEFI) und veränderte Anforderungen zu komplexeren Deployment‑Szenarien. Damit steigt die Wahrscheinlichkeit, dass ADK und Tools nicht mehr sauber zusammenarbeiten.
- Microsoft optimiert und ändert ADK — z. B. Entfernen von Legacy‑Komponenten (VBScript, 32‑Bit), Anpassungen für neue Windows‑Versionen — was alten Skripten/Setups schadet.
- Die große Vielfalt an Kombinationen (ADK‑Version × WinPE × Deployment‑Tool × Hardware × Windows‑Version) macht es fast unmöglich, dass alle Szenarien stabil bleiben.
Fazit & Empfehlung
Das Windows ADK bleibt ein mächtiges, aber gleichzeitig komplexes Werkzeug — gerade in Kombination mit Windows 11. Kompatibilität, Versionswahl und Deployment-Setup sollten mit Bedacht gewählt werden:
- Verwenden Sie bewährte, unterstützte ADK-Versionen (z. B. 10.1.26100.2454) statt experimenteller Builds.
- Testen Sie vor dem produktiven Einsatz gründlich — gerade bei Boot‑Images, BitLocker, Deployment‑Routinen.
- Wenn Sie auf Legacy‑Skripte oder HTA/VBScript setzen: Überlegen Sie, ob eine Migration auf moderne Werkzeuge (z. B. PowerShell) sinnvoll ist — oder implementieren Sie Workarounds wie DLL‑Nachinstallationen.
- Dokumentieren Sie Ihre Deployment‑Umgebung und halten Sie stabile Archiv‑Versionen bereit.
Damit lässt sich das ADK auch unter Windows 11 zuverlässig nutzen — ohne unangenehme Überraschungen oder Deployment‑Ausfälle.