Hinweis: im Oktober 2025 wird offiziell der Support für den MDT (Microsoft Deployment Toolkit) eingestellt.
Der Fehler
Aus heiterem Himmel hagelte es nach dem Deployment neuer Clients Fehlermeldungen im Abschlußbildschirm.
Wenn man sich die Details dazu ansah, dann wurde angezeigt, dass eine Handvoll Anwendungen wegen Fehler 1618 nicht installiert wurden.
Wer schon länger in der IT unterwegs ist, der weiß, dass „Error 1618“ zurückgegeben wird, wenn bereits eine Installation im Gange ist.
Beginn der Fehlersuche
Das erschien mir drollig, denn das MDT startet die Installation der nächsten Anwendung erst, wenn die Vorherige, unabhängig vom Rückgabe-Code, beendet ist.
Die Log-Datei bdd.log verzeichnete ebenfalls nichts anderes, als die Meldung im Abschlußbildschirm.
Ebenso waren die weiteren log-Dateien am Client unter c:\Windows zwar detaillierter, doch nicht ergiebiger.
Erster Workaround
Als nächsten Schritt habe ich in die Task Sequenz einen Haltepunkt eingebaut, um bei der Installation der Anwendungen beobachtend daneben sitzen zu können.
Da ließ sich erkennen, dass der Benutzer „SYSTEM“ einen weiteren msiexec.exe Prozeß startete, während bereits eine Installation lief.
Woher der kam, blieb unklar.
Der Verdacht war, dass sich das Windows Update von Windows 11 dazwischen schiebt.
Da sich während der Task Sequenz „Install Applications“ keine weiteren Skripte einbinden lassen, wenn man die Option „Multiple Applications“ verwendet, habe ich eine zweite Task Sequenz erstellt und die Anwendungen jeweils einzeln eingebunden.
Zwischen den einzelnen Anwendungen habe ich jeweils ein Skript eingehängt, dass eine einminütige Pause eingelegt wurde und anschließend alle msiexec-Prozesse beendet werden.
Das führte zwar zum Erfolg, aber die Flexibilität einzelne Anwendungen während des Setups an- und abzuwählen, verschob sich.
Man muss auf diesem Weg in der Task Sequenz vor dem Deployment die einzelnen Schritt an- oder ausschalten. Das ist unter anderem auch suboptimal, wenn man zeitgleich mehrere Clients bedienen möchte. Die Wartezeit dazu ist nervig.
Kein schöner Weg, aber besser als manuell fehlende Anwendungen nach zu installieren. Das bedeutet höheren zeitlichen Aufwand und ist fehleranfällig.
Dann kamen wir drauf, dass der Fehler nicht auftrat, wenn das Deployment in eine Arbeitsgruppe und nicht mit einem Domänenbeitritt durchgeführt wurde.
Im nächsten Schritt wurde der Task-Sequenz Schritt mit dem Domänenbeitritt deaktiviert.
Das Problem blieb bestehen.
Lösung
Also musste es einen weiteren Triggerpunkt in der autounattend.xml geben.
Man kann dieses Datei über den MDT in einer GUI ändern, allerdings ist die sehr gemütlich unterwegs.
Daher ändert man deutlich schneller die unattend.xml direkt im Pfad des MDT unter D:\\Control\.
Es sind einfach die folgenden 11 Zeilen zu löschen.
Als finalen Schritt brauchte es noch einen eigenen Task Sequenz Schritt zum automatisierten Domänenbeitritt an beliebiger Stelle nach „Install Applications“.
Und die Problematik war behoben.
