Open Hammerfest opened 2 weeks ago
Using the evaluation .iso image 26100.1.240331-1435.ge_release_CLIENT_IOT_LTSC_EVAL_x64FRE_en-us.iso, I can reproduce your findings. Thank you for bringing this to my attention!
• When the RecoveryMode=None
query string parameter is set, no recovery partition is created during the WindowsPE phase of Windows Setup. This is the expected behavior. However, it seems that Windows Setup automatically creates the recovery partition during a later stage, at the end of the disk. I don't know yet if this can be avoided. Since RecoveryMode=None
also deletes the C:\Windows\System32\Recovery\Winre.wim
file, Windows Setup cannot successfully install Windows RE, and the recovery partition remains empty. Furthermore, it appears that this behavior applies to 24H2 in general, not just IoT/LTSC/Enterprise editions.
• The bloatware removal logs (C:\Windows\Temp\remove-packages.log
, C:\Windows\Temp\remove-caps.log
, C:\Windows\Temp\remove-features.log
) are suspiciously empty, but I think this is due to the fact that almost all of these components are missing from this image in the first place. Also note that 26100.1.240331-1435.ge_release_CLIENT_IOT_LTSC_EVAL_x64FRE_en-us.iso
is about 650 MiB smaller than e.g. Windows11_InsiderPreview_Client_x64_en-us_26080.iso
.
No worries, the eval should be the same as the OEM release with the exception of not being convertible to full release. I get my copy from work but you should be able to find the full version if you think the differences make a difference, its not like its hidden 🗡️ .
As for the bloatware, yes, most of it is gone, but paint, notepad, etc etc are still there, so there is bloat to remove its just not doing it.
EDIT: interesting it impacts regular as well and not just LTSC
What is the output of
Set-StrictMode -Off;
$(
Get-AppxPackage -AllUsers;
Get-AppxProvisionedPackage -Online;
Get-WindowsOptionalFeature -Online;
Get-WindowsCapability -Online;
) | Where-Object -FilterScript {
-join( $_.Name, $_.DisplayName, $_.PackageName, $_.FeatureName ) -match 'notepad|paint'
};
in an elevated PowerShell window? Note that there is a classic and modern variant of Notepad, and also there is Paint and Paint 3D.
I have just committed https://github.com/cschneegans/unattend-generator/commit/d9eccd9ebb65dce57bb202d3407590cfb46035e0, which provides better logging for bloatware removal. Ideally you would repeat the installation with a refreshed autounattend.xml. In any case, please send me the files C:\Windows\Temp\remove*.log
and the autounattend.xml file used (there's a copy in C:\Windows\Panther\unattend.xml
).
Sorry for the delay. As I've not deployed and just in test/image creation phase I have gone ahead and done a totally fresh install. Find attached the autounattend I re-created today, sadly, there is no .log in the C\Win\Temp directory. autounattend.zip
Here is the output you request as well:
Using your autounattend.xml
file (with one modification, see below) and the 26100.1.240331-1435.ge_release_CLIENT_IOT_LTSC_EVAL_x64FRE_en-us.iso
image, Windows Setup removed both Notepad and Paint:
Name : Microsoft.Windows.MSPaint~~~~0.0.1.0
State : NotPresent
Name : Microsoft.Windows.Notepad~~~~0.0.1.0
State : NotPresent
Indeed, C:\Windows\System32\notepad.exe
did no longer exist.
Windows Setup asked me for a work or school account, which I don't have. Instead, I let Windows Setup create a local user account using the UserAccountMode=Unattended
query string value.
To be honest, I have no idea why this does not work for you, so I would really need to see the logfiles. When checking the C:\Windows\Temp
folder, avoid using Windows Explorer. Instead, open an elevated PowerShell session and type these commands:
Get-Item -Path 'C:\Windows\Temp\remove*.ps1';
Get-Content -Path 'C:\Windows\Temp\remove*.log';
Interesting, are you by chance letting the system connect to the internet? I dont have the VM connected to the internet at all, and it doesnt prompt me for a work or school account at all, goes straight to local, its also using the bypassnro for your autounattend setup so it seems like that may be broken as well if you had to change useraccountmode.
Nice, disabling the network adapter in VMware let me use a local account without any modifications to your autounattend.xml
. Still, bloatware removal works as before. In particular, notepad.exe
is removed.
Actually, I think I may have found another bug or limitation, it doesn't seem to wipe the drive prior to the partitioning commands Meaning if you dont do it on a fresh disk the set from prior remains
EX: From a totally fresh disk, setup actually only prompts me for the key which is as the autounattend was designed, HOWEVER, when i try to do it over, I noticed my EFI partition size which I had changed in this new autounattend, did not change (default was 300, I set to 512), SO, I went back in, did a DPC during setup while asking for the key, and after that it prompted me for which disk to install it as if the autounattend was being read from the internal disk instead of the install disk and thus didnt know what to do anymore
A simple restart fixed it, but the point here, is what your seeing is sadly a byproduct of this, you removed it before, and thinking it would clear the disk with the autounattend, it actually did not so your left with the remnants
Key takeaway: without clearing the disk manually, its not actually wiping the disk with each future run contaminating the results
Generating an autounattend.xml
file with query string parameter PartitionMode=Unattended
will always emit a diskpart script that contains a CLEAN
command. This is also the case with the autounattend.xml
file you posted earlier:
<RunSynchronousCommand wcm:action="add">
<Order>1</Order>
<Path>cmd.exe /c ">>"X:\diskpart.txt" echo SELECT DISK=0"</Path>
</RunSynchronousCommand>
<RunSynchronousCommand wcm:action="add">
<Order>2</Order>
<Path>cmd.exe /c ">>"X:\diskpart.txt" echo CLEAN"</Path>
</RunSynchronousCommand>
During the PE stage of Windows Setup, you can even inspect the X:\diskpart.log
logfile to verify the disk has been wiped:
I hear ya, and I see ya, but again, I used a prior installation, added the new script with the 512MB EFI, and after the script was done it was still the 300MB EFI I started with.
Not a big problem, it may just be an oddity that time around, simply making sure to clean manually before letting autoattend work, its telling when i clean the disk during the setup process that it forgets what its supposed to do meaning its using internal disk info not usb
This may be LTSC specific, I have yet to try it on full blown 24H2 as its not out yet, while LTSC is partially out.
Bloatware did not get removed and Recovery partition remains despite all being checked and using the remove option.
Haven't had a moment to check the rest, just redid the image twice to make sure.
Let me know if you need anything from me.