Windows 11 Deployment scheitert bei DomJoin in eine konkrete OU

Die wilde Inge

Redakteur
Teammitglied
Registriert
Aug. 2009
Beiträge
2.290
Grüße,

ich habe mal ein tiefergehendes Problem mit dem OS Deployment von Windows 11 24H2
Vielleicht ist ja hier der eine oder andere Fachinformatiker unterwegs, der mir helfen kann.

Also, wir deployen Windows 11 per Software, basierend auf dem was Microsoft zur Verfügung stellt. Das heißt Windows ADK mit PEAddon (neuste Version), installiert auf einem Windows Server 2022, TFTPServer etc.

Das ganze funktioniert auch tadellos, inkl. DomJoin.
Allerdings nur bis wir die unattended .xml anpassen. Die Änderung sind exakt nach MS-Vorgabe:


<component name="Microsoft-Windows-UnattendedJoin" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">
<Identification>
<Credentials>
<Domain>domaene.local</Domain>
<Password>1234567*</Password>
<Username>adm_join</Username>
</Credentials>
<JoinDomain>domaene.locall</JoinDomain>
<MachineObjectOU>OU=Windows11,OU=Clients,OU=Systeme,DC=domaene,DC=local</MachineObjectOU>
<UnsecureJoin>false</UnsecureJoin>
</Identification>
</component>

Die Accounts, Domänenname und die OUs habe ich ersetzt.

Der DomJoin in die OU funktioniert übrigens, das Gerät bleibt aber im OOBE Prozess hängen und verlässt dadurch das Windows Setup erst nach Stunden oder wenn man das Gerät selber durchbootet.

Mit Windows 11 23H2 lief übrigens früher alles perfekt.

Das Ganze ist beliebig reproduzierbar, auch mit unterschiedlicher Hardware. Ohne den Eintrag in der Unattended geht dann wieder alles tadellos.

Ich weiß mittlerweile echt nicht mehr weiter.
Das verrückte ist, dass ich mit der gleichen Unattended, in einer anderen Umgebung (andere Domäne) überhaupt keine Probleme habe. Genau die gleiche Datei, nur die OUs sind entsprechend angepasst, funktioniert es. An der Unattended sollte es also im Prinzip nicht liegen.

Die OSD-Umgebung wurde indes bereits komplett neu aufgesetzt, der Fehler bleibt aber.

In den Panther Logs (setuperr.log) stehen nur 8 Zeilen drin, alle aus der gleichen Sekunde. Alles wohl uninteressant:

[NETIOUGC.EXE] TCPIP: Error while processing the the 'UnicastIpAddresses' registry key.

Irgendwer noch eine Idee?
Würde wohl ansonsten auch mal bei Microsoft selber nachfragen, aber vielleicht kennt ja schon jemand das Problem.
 
<JoinDomain>domaene.locall</JoinDomain>

Sind da auch im Ori 2xL?

Und hat der adm_join genügend Rechte auf der OU?
 
Hi, nein, keine zwei ll, die Domäne heißt völlig anders. Das sind hier nur Platzhalter.
Rechte müssen passen, da der Join in die OU ja im Prinzip funktioniert, das Windows Setup hängt sich einfach nur auf.
 
Keine Ahnung, ob das dort geschriebene noch gilt, da schon ziemlich alt.

Ich habe mal in unsere autounattend.xml geschaut, aber da haben wir gar keine OU drin, da die Objekte vor der Betankung direkt in der entsprechenden OU im AD erstellt werden.
 
Das Objekt ist in der AD nicht angelegt. Wird es vorher angelegt, kommt es zu einem Fehler - das kenne ich ehrlich gesagt auch genau andersherum ...

Wir testen jetzt mal den DomJoin über den ersten Startbefehl zu automatisieren, mal gucken wie sich das Setup verhält, wenn man den DomJoin zu einem anderen Zeitpunkt des Setups machts.
 
Zurück
Oben