Win 11 25H2 unattend.xml issues

carlosmp

New Member
Messages
18
Reaction score
1
Hi,

I've been having issues with the unattended installs. I have been playing with the options of Copy to install image, and copy to boot image. I'm fairly certain i don't have any issues in my xml. In both cases, if I do a Shift-F10, and check the Panther folder, there's two xml files, unattend.xml (177 bytes) and unattend-original.xml (6KB). The log (C:\Windows\Panther\setupact.log) shows it copied. Where is the original file coming from, which seems to be the right file...

SP 12 | Copy unattend payload from D:\autounattend.xml to G:\$WINDOWS.~BT\Sources\Payload...
SP 86 | Add unattend file C:\$WINDOWS.~BT\Sources\Payload\Unattend\autounattend.xml
SP 134 | Create file C:\$WINDOWS.~BT\NewOS\Windows\Panther\unattend.xml on the new system

Any things to check?

TIA
 
What exactly is the nature of the problem?

When Setup runs, it searches for an unattended file in several location following a specific search order. The first matching file is then copied to "\Windows\Panther" and used.

https://learn.microsoft.com/en-us/w...=windows-11#implicit-answer-file-search-order

Normally, creating autounattend.xml on the ISO's root folder will allow one unattended file to be used for all install images.

If you want a per-image unattended file to override a possible autounattend.xml, NTLite can copy unattended.xml inside the currently loaded image (Copy to install image). This only applies to one image at a time.

(Copy to boot image) is also an override against the autounattend.xml, but it applies to all images. Since there is one boot.wim for the ISO.
 
When i expand the ISO after creating, I have only one autounattend.xml in the root folder. The preset i have only has the Pro version. I've tried all 4 combinations of the Copy to Install/Boot, none, and all... all seem to result the same way...upon reboot ends up at the select keyboard. If I Shift-F10 out, and then run this :

Code:
copy /Y C:\Windows\Panther\unattend-original.xml C:\Windows\Panther\unattend.xml
copy /Y C:\Windows\Panther\unattend-original.xml C:\Windows\System32\Sysprep\unattend.xml
%windir%\System32\Sysprep\sysprep.exe /oobe /reboot /unattend:C:\Windows\Panther\unattend.xml

It works perfectly fine.
 
If you expect to perform sysprep, the autounattend.xml is usually written to stop the install and drop you into audit mode.

But after you're finished with sysprep, you're expected to replace the current \Windows\Panther\unattend.xml with the "final" unattend.xml that runs once Windows enters the OOBE pass.

Some people will copy a new file into \Windows\Panther, other people use the sysprep.exe command line like you posted. At this point, it's not a NTLite-specific problem. There are IT admins that write more elaborate unattended files to automate some of the steps, by calling helper scripts to do this task.

But that's outside of what NTLite can do out of the box.
 
In previous images we had this same process and were able to consistently create fully automatic images. It seems something changed in Win11 25H2. I looked into the BypassNRO setting, but it seems that's already in the Registry. I checked both the boot.wim and install.wim, and there's no autounattend.xml file, the Panther folders, are clean, and there's no $OEM$/$$ folder in either of them.
 
Spent way more time than i expected, but finally got some good results. Had to employ claude so i can't take all the credit...

What's actually happening​


Windows 11 24H2 introduced and 25H2 expanded a new "ConX" setup experience that runs SetupPrep.exe instead of the legacy setup.exe. From the May 2024 forum thread by someone reporting this exact issue:


"Determining whether we should run ConX or legacy setup. Will launch ConX setup experience. Found unattend file at [D:\autounattend.xml]; examining for applicability. Found usable unattend file for pass [windowsPE] at [D:\autounattend.xml]. Launching ConX setup experience. Launching X:\Sources\SetupPrep.exe /boot"

The ConX setup experience does not properly process autounattend.xml for the oobeSystem pass on 25H2. It picks up windowsPE settings (your disk wipe/partition works), then hands off to a different code path for OOBE that ignores or improperly reuses your unattend. That's why disk wipe/install completes fine but OOBE runs interactively.


The Korean blog post (noways.tistory.com) and the Eleven Forum threads both document the workaround: force Windows Setup to use the legacy setup.exe path instead of ConX. This is done by adding a winpeshl.ini file to boot.wim's \Windows\System32\ directory that calls setup.exe /legacy.


The fix​


Add a winpeshl.ini file to your boot.wim that forces legacy setup:


winpeshl.ini contents:

Code:
[LaunchApps]
%SystemDrive%\sources\setup.exe, /legacy

After injecting this into boot.wim, it's working. Now how to get this to persist through Win ISO updates.
 
Settings -> System -> Boot Setup/Legacy -> Legacy

btw I introduced the ElevenForum method (CmdLine), and that Korean guy likes to argue his method is easier. My method doesn't change any of the ISO or boot.wim files, so it doesn't conflict with any user-made changes.
 
Settings -> System -> Boot Setup/Legacy -> Legacy

My method doesn't change any of the ISO or boot.wim files, so it doesn't conflict with any user-made changes.
Your method here, consisting in changing some registry in the boot.wim, therefore in the boot.wim/ISO ?
A method where you assume that if we don't understand your poorly expressed procedure, we're "technically impaired", and where nobody can understand what it means to "mount boot.wim", given that we want to boot on a pendrive, and where nobody can understand implicitely how to save a new ISO with such a modification. Yeah I can use AnyBurn, but that doesn't explains all the steps.

Or this method maybe, where you ask us to put only one line in the autounattend.xml, or it won't work, when we're supposed to use the autounattend for many things and not just launching the legacy setup.exe ? What's the point of ruining our aunattend.xml to launch the setup.exe wich is supposed to... read that fucking unattend.xml ? How funny are you ?

At least, carlosmp's method is implying that we should inject some file in boot.wim with more clarity than your pseudo solutions without spitting like a pseudo technician full of contempt and not as competent as he thinks he is. Now we just have to search for how to open and inject things, instead of "mounting". Jesus Christ...
 
Let me explain how to express properly and clearly like a real technician.

1. Read the content of the W11 ISO (not "mount") with AnyBurn.
2. Access the "/source" directory, and find boot.wim.
3. Open its content with.... [replace here with the solution I don't have]
4. Create a file winpeshl.ini at the root of boot.wim with this content :
[LaunchApps]
%SystemDrive%\sources\setup.exe, /legacy
5. Save boot.wim
6. Save the ISO in AnyBurn.

Yeah, I don't have the solution in the step #3, because there's no fucking way to open boot.wim when we are already using AnyBurn to read the ISO. That's not recursive, double-clicking on it does nothing, and right-clicking neither.

That's why reading your pseudo-method made me loosing it. You're so convinced you're communicating clearly that you lack capability to put yourself in the other's shoes.

Now I'm suspecting I can extract the whole ISO, then relaunch AnyBurn and open boot.wim directly, but I'm not supposed to GUESS things constantly. Computing is full of incompetency, debilitating communications, and holes in the cheese everwhere, in wich telepaths with barely the capability to intelligibly comprehend their own "knowledge" seems to be fine having it directly from the holly spirit.
 
Last edited:
Let me explain how to express properly and clearly like a real technician.

1. Read the content of the W11 ISO (not "mount") with AnyBurn.
2. Access the "/source" directory, and find boot.wim.
3. Open its content with.... [replace here with the solution I don't have]
4. Create a file winpeshl.ini at the root of boot.wim with this content :
[LaunchApps]
%SystemDrive%\sources\setup.exe, /legacy
5. Save boot.wim
6. Save the ISO in AnyBurn.

Yeah, I don't have the solution in the step #3, because there's no fucking way to open boot.wim when we are already using AnyBurn to read the ISO. That's not recursive, double-clicking on it does nothing, and right-clicking neither.

That's why reading your pseudo-method made me loosing it. You're so convinced you're communicating clearly that you lack capability to put yourself in the other's shoes.

Now I'm suspecting I can extract the whole ISO, then relaunch AnyBurn and open boot.wim directly, but I'm not supposed to GUESS things constantly. Computing is full of incompetency, debilitating communications, and holes in the cheese everwhere, in wich telepaths with barely the capability to intelligibly comprehend their own "knowledge" seems to be fine having it directly from the holly spirit.

Extract from the opened ISO image, edit - I use 7-Zip -and then put it back into the ISO....
 
Back
Top