Windows Installation automatisieren mit Antwortdateien (Unattend.xml)

Eine Unattend.xml kann weit mehr als nur die OOBE-Dialoge ausblenden. Mit den richtigen Komponenten legst du lokale Konten an, setzt Sprache und Zeitzone, hinterlegst den Produktschlüssel, vergibst Computernamen und nimmst Systeme automatisch in die Domäne auf. Die folgenden Szenarien decken die häufigsten Anforderungen ab und lassen sich frei kombinieren.

Zum Aufbau: Jede Einstellung gehört in eine bestimmte Komponente und einen bestimmten Konfigurationspass. Die Beispiele nennen beides jeweils, damit du sie korrekt in dein Gesamtgerüst einbaust. Wichtig für die Zuordnung: Die Pässe windowsPE, specialize und oobeSystem verarbeitet Windows Setup selbst, die Pässe generalize, auditSystem und auditUser laufen dagegen nur, wenn du Sysprep ausführst. Eine Einstellung im falschen Pass wird schlicht ignoriert. Zum Erstellen und Validieren nutzt du den Windows System Image Manager (WSIM) aus dem Windows ADK.

Gerade in Testumgebungen oder bei speziellen Anforderungen sollen bestimmte lokale Konten direkt beim Deployment entstehen. Das erledigt der Abschnitt UserAccounts in der Komponente Microsoft-Windows-Shell-Setup, Pass oobeSystem:

Wichtig zum Verständnis: PlainText auf false bedeutet keine Verschlüsselung, sondern nur eine Base64-Kodierung. Windows erwartet dabei den Passwortwert plus das angehängte Wort „Password", kodiert als UTF-16LE. Du erzeugst den Wert mit einer PowerShell-Zeile:

Weil Base64 in Sekunden dekodierbar ist, schützt diese Kodierung nur gegen zufälliges Mitlesen, nicht gegen Angreifer. Behandle jede Antwortdatei mit Passwörtern wie eine Klartext-Datei: Zugriff einschränken, nach dem Deployment entfernen und für produktive Konten nur Wegwerf-Passwörter hinterlegen, die du nach der Bereitstellung rotierst.

Steht die Zielregion fest, nimmst du dem Benutzer die Sprach- und Layoutauswahl im OOBE ab. Dafür ist die Komponente Microsoft-Windows-International-Core im Pass oobeSystem zuständig:

0407:00000407 steht für die deutsche Sprache mit deutschem Tastaturlayout. SystemLocale bestimmt die Codepage für Nicht-Unicode-Programme, UserLocale die Formate für Datum, Zeit und Währung. Installierst du komplett unbeaufsichtigt von einem Installationsmedium, setzt du dieselben Werte zusätzlich in der Komponente Microsoft-Windows-International-Core-WinPE im Pass windowsPE, damit schon das Setup selbst auf Deutsch läuft.

Die Zeitzone setzt du in der Komponente Microsoft-Windows-Shell-Setup im Pass specialize, dann muss sie niemand mehr manuell auswählen:

W. Europe Standard Time steht für die mitteleuropäische Zeitzone (MEZ/MESZ). Alle gültigen Bezeichner listet dir tzutil /l direkt auf dem System auf, alternativ die Microsoft-Dokumentation zu den Default Time Zones.

In Volumenlizenzumgebungen hinterlegst du den Schlüssel direkt in der Antwortdatei, ebenfalls in Microsoft-Windows-Shell-Setup im Pass specialize:

Der gezeigte Schlüssel ist der öffentliche KMS-Client-Key (GVLK) für Windows 11 Pro. Er legt nur die Edition fest und aktiviert nichts: Die eigentliche Aktivierung läuft gegen deinen KMS-Server im Netzwerk, der GVLK darf deshalb bedenkenlos in jedem Image stehen. Anders beim MAK (Multiple Activation Key): Der aktiviert direkt bei Microsoft und verbraucht dabei Aktivierungen aus deinem Kontingent. Einen MAK trägst du deshalb nur in Antwortdateien ein, deren Verbleib du kontrollierst, sonst verteilt sich dein Schlüssel unkontrolliert mit jedem Image.

Der hinterlegte ProductKey hat zwei angenehme Nebeneffekte. Die OOBE fragt nicht mehr nach einem Schlüssel, weil sich Windows automatisch aktiviert. Und für die Image-Pflege entschärft er das Rearm-Thema: Mit gültigem Key in der Antwortdatei kannst du dein Referenz-Image laut Microsoft ohne Aktivierungssorgen wiederholt generalisieren.

Ohne Vorgabe erzeugt Windows einen generischen Namen im Muster DESKTOP-ABC1234. Willst du das Verhalten steuern, setzt du ComputerName in Microsoft-Windows-Shell-Setup im Pass specialize:

Der Stern ist der offizielle Weg für Zufallsnamen: Windows generiert dann einen eindeutigen Namen mit maximal 15 Zeichen. Ein fester Wert wie WIN11-BUCHHALTUNG funktioniert nur bei Einzeldeployments, weil sonst alle Klone denselben Namen tragen. Platzhalter wie %RANDOM% kennt die Antwortdatei nicht. Brauchst du ein eigenes Namensschema (etwa nach Seriennummer oder Asset-Tag), löst du das über dein Deployment-Framework: MDT und Configuration Manager schreiben den Namen zur Laufzeit in die Antwortdatei, alternativ benennst du per Skript im First Logon um.

Den Beitritt zu einer Active-Directory-Domäne übernimmt die Komponente Microsoft-Windows-UnattendedJoin im Pass specialize. Die naheliegende Variante mit Benutzername und Passwort sieht so aus:

Das Problem: Das Passwort steht hier zwingend im Klartext, eine Base64-Option gibt es für den Domain Join nicht. Nutze dafür ausschließlich ein dediziertes Join-Konto mit minimalen Rechten (nur Computerkonten in der Ziel-OU anlegen), niemals einen Domänen-Admin.

Sicherer ist der Offline Domain Join mit djoin.exe. Dabei provisionierst du das Computerkonto vorab auf einem Domänencontroller oder Admin-System:

Den Inhalt der Blob-Datei trägst du in der Antwortdatei im Abschnitt OfflineIdentification unter Provisioning/AccountData ein. Der Blob enthält keine wiederverwendbaren Anmeldedaten für andere Systeme, wodurch ein abgeflossenes Image deutlich weniger Schaden anrichtet als eines mit Join-Passwort. Der Nachteil: Du brauchst pro Rechner einen eigenen Blob, was sich nur mit Skripting oder einem Deployment-Framework sauber skaliert.

OEM- und Supportinformationen. Über OEMInformation in Microsoft-Windows-Shell-Setup (Pass specialize) hinterlegst du Herstellerangaben und Support-Kontakte, die in den Einstellungen unter System angezeigt werden. Für Systemhäuser und MSPs ein einfacher Weg, die eigene Hotline auf jedem ausgerollten Gerät sichtbar zu machen:

Skripte beim ersten Anmelden ausführen. Mit FirstLogonCommands in Microsoft-Windows-Shell-Setup (Pass oobeSystem) startest du nach der ersten Anmeldung beliebige Befehle, etwa ein PowerShell-Skript für die Nachkonfiguration. Damit verlagerst du alles, was die Antwortdatei nicht abbildet (Software-Nachinstallation, Registry-Anpassungen, Bereinigung), in ein wartbares Skript:

Treiber über das Generalisieren retten. Baust du dein Image für identische Zielhardware, verhinderst du mit PersistAllDeviceInstalls in der Komponente Microsoft-Windows-PnpSysprep (Pass generalize), dass Sysprep die installierten Geräte deinstalliert. Die Geräteneuerkennung im specialize-Pass entfällt, was das erste Booten auf den Zielrechnern beschleunigt. Auf gemischter Hardware lässt du die Einstellung auf dem Standardwert false, sonst schleppst du falsche Treiberzuordnungen mit:

Generalisieren direkt aus der Antwortdatei. Sysprep per Aufgabenplanung oder RunSynchronous-Befehl zu starten ist nicht unterstützt. Der dokumentierte Weg: die Einstellung Generalize in der Komponente Microsoft-Windows-Deployment. Mit Mode auf OOBE und ForceShutdownNow auf true generalisiert Windows Setup das System nach der Verarbeitung der Antwortdatei automatisch und fährt es herunter, fertig zum Capture. Für Anpassungsarbeiten vor dem Versiegeln startest du stattdessen per Reseal mit Mode auf Audit direkt in den Audit Mode. Dort kannst du über RunSynchronous-Befehle im Pass auditUser auch Skripte laufen lassen, deren Status Windows im AuditUI-Fenster anzeigt, praktisch zur Fehlersuche bei automatisierten Image-Builds.

EULA-Anzeige und OOBE-Dialoge. Die Schlüssel HideEULAPage, HideOnlineAccountScreens und ProtectYourPC überspringen die Erstkonfigurationsdialoge. Das Grundgerüst dazu findest du im verlinkten Sysprep-Artikel.

Automatische Updates und Netzwerkkonfiguration. Update-Verhalten und statische IP-Adressen (für Umgebungen ohne DHCP) lassen sich zwar teilweise per Antwortdatei setzen, in der Praxis erledigst du beides besser per Gruppenrichtlinie beziehungsweise per Skript im First Logon. Die Antwortdatei bleibt dadurch schlank und du änderst die Konfiguration später zentral, ohne das Image neu zu bauen.

Windows speichert die bei der Installation verwendete Antwortdatei zwischen und wendet ihre Einstellungen bei späteren Konfigurationsdurchläufen erneut an, auch bei jedem Sysprep-Lauf. Wunderst du dich also, warum ein generalisiertes Image Einstellungen setzt, die in deiner aktuellen Datei gar nicht stehen, ist meist die gecachte Antwortdatei der Grund. Willst du bewusst mit anderen Einstellungen generalisieren, übergibst du deine Datei explizit:

Windows Setup legt Kopien der verwendeten Antwortdateien unter C:\Windows\Panther ab. Bekannte Passwortfelder schwärzt das Setup dort zwar, verlass dich aber nicht darauf, dass jeder sensible Wert zuverlässig entfernt wird. Prüfe die zwischengespeicherten Dateien nach der Bereitstellung und lösche sie, wenn sie Konten, Schlüssel oder Join-Daten enthalten. Ein Aufräumbefehl im FirstLogonCommands-Block automatisiert genau das.

Mit einer Unattend.xml automatisierst du den kompletten Ersteinrichtungsprozess: lokale Konten, Sprache und Tastaturlayout, Zeitzone, Produktschlüssel, Computername und auf Wunsch der Domänenbeitritt laufen ohne einen einzigen Klick durch. In größeren Umgebungen und Laboren, wo standardisierte Installationen zählen, ersetzt eine gepflegte Antwortdatei viele manuelle Arbeitsschritte und eliminiert die Tippfehler, die bei Handarbeit zwangsläufig passieren.

Der kritische Punkt bleibt der Umgang mit Anmeldedaten. Die Base64-Kodierung der Kontopasswörter ist keine Verschlüsselung, und das Join-Passwort für die Domäne steht sogar im Klartext in der Datei. Daraus folgen drei Regeln für den produktiven Einsatz. Erstens: Jedes Konto in der Antwortdatei bekommt minimale Rechte und ein Passwort, das du nach dem Rollout rotierst. Zweitens: Wo es geht, ersetzt du Passwörter durch Verfahren ohne wiederverwendbare Credentials, beim Domänenbeitritt also djoin.exe statt Join-Konto. Drittens: Nach dem Deployment räumst du die zwischengespeicherten Antwortdateien unter C:\Windows\Panther ab.

Halte die Antwortdatei außerdem bewusst schlank. Alles, was sich per Gruppenrichtlinie, Intune oder Nachkonfigurationsskript steuern lässt, gehört dorthin und nicht ins Image. So bleibt die Unattend.xml das stabile Fundament deiner Bereitstellung, während sich die eigentliche Konfiguration zentral pflegen lässt, ohne dass du für jede Änderung ein neues Image baust und verteilst.