Only on 1809 and not on any subsequent versions right ? Okay, thanks for your help, then it must be something else breaking windows update, since it's the second time it's happening.
I made a mistake, the normal cleanup doesn't hurt to use, /resetbase breaks resetpc on 1809, on 1903 and up it should be fixed by @abbodi1406 his updates integration script (from W10UI). I install many many many uup generated ISOs and WU never failed for me.
But I have to remove the updates from the UUP folder and run convert-UUP. cmd because the script adds setup dynamic update even with addupdates disabled
That's why i always advise to download the Cumulative Update option when you want a 18362.1/19041.1 ISO, but it should not matter if the du for sources is used or not.
That happens to me also when I try to create a clean base 19041.1 ISO. I think the problem is when creating boot.wim: Code: if %AddUpdates% neq 1 if exist "!_UUP!\*Windows10*KB*.cab" ( call :uups_du ... I changed to: Code: if %AddUpdates% gtr 1 if exist "!_UUP!\*Windows10*KB*.cab" ( call :uups_du ... It appears to fix it for me. But only abbodi1406 will be certain if it breaks anything.
The DU for sources will always be integrated on the ISO, that's how it's coded now, by just not downloading using the feature update option and have addupdates set to 0, all should be fine to endup with a .1 ISO..
Ok. I tried to help Ramiro and at the same time saw a way to make the script a little more flexible. The change, if confirmed working, would make simple, for example, generate a .1 ISO ("AddUpdates=0) and then right after generate an updated one with LCU, changing "AddUpdates=1". This without moving files on UUPs folder.
As I'm working with this (I'm making a clean base .1 ISO and an updated one), I notice the that Convert-UUP makes ISOs with \Windows\WinSxS\Backup on WinRE.wim (and on Boot.wim) that is later copied to install.wim. I think it could make a little more lighter ISO without that Backup folder, that is unnecessary and making boot.wim and install.wim bigger (when Windows is installed winre.wim is also bigger than needed). This would be also beneficial helping to mantain install.wim < 4GB for FAT32. MS official ISOs don't have WinSxS\Backup folder on winre.wim and boot.wim. Also I checked and they have HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide\Configuration\DisableComponentBackups=1 on all indexes of that wims. The script, right after exporting/creating winre.wim (even if we set AddUpdates=0), could: 1. set DisableComponentBackups = 1 registry value/data 2. delete Backup folder 3. reexport the new winre.wim optimized and go on and do all the rest... abbodi1406, I don't know if is a big change and be certain about all implications to the script. If this is valid, it could save some tens of MBs on wims and final ISO.
@p0werb1t WinSxS\Backup is removed when you run Dism cleanup (with DisableComponentBackups set) after adding updates it's not removed manually, and it's owned by Trustedinstaller that's why it's found in clean base ISOs (without updates)
Is see. I didn't know that it couldn't be simple deleted on an offline image. Could you do a cleanup just after creating/exporting winre.wim image? As I said I think it could save some tens of MBs on wims and final ISO.
winre.wim is not modified without updates, i don't intend to change that however, i will add DisableComponentBackups registry before Dism cleanup (when adding updates) when using final or production builds, updates will be always available when using Insider Preview builds, you can set SkipWinRE to save size and conversion time
Thanks! Actually most of the times we build recent updated image/ISO, so the change is applied. I did a test cleanning WinRE and the space gains are much less than I expected . Windows\WinSxS\Backup folder (base 19041.1) ocuppies 180MB , is compressed (LZX:50) on WIM file to 75MB, however because WIM's Single Instancing (I think!) the gains are effectively little 1 MB. Nevertheless, every saving is good and this change is closer to MS practices (the good ones!). Thanks again abbodi1406 for taking time with this.