Question on boot.wim size - integrating updates and drivers

C

chrcol

Member
Ok so what I have done for this example here does not include anything other than drivers and updates, all other parts of ntlite blank for these 2 isos I made.

Having reading posts everywhere i decided to make a new base image for my tinkering that would already have updates and drivers integrated.

What I did on the first one was to fetch the online update list, I left the default updates ticked and imported the .net 3.5 template.

I then made the image using dism (compatibility) option and also the parallel + cache.

I have since booted that iso and from what I can tell it worked perfect. The install.wim was 3.94GB and boot.wim 640.6MB

--

I then did a second pass on the edit cache and integrated virtio drivers, on install.wim and both options on boot.wim, these I know were already working as was integrating previously, but wanted this done on base so i wouldnt have to keep redoing boot.wim.

After this was done however I observed the new iso was about 200MB smaller.

I then extracted both iso's to each have their own edit cache, and opened up wiz tree to compare, the install.wim is fine, but the boot.wim is now 200MB smaller on the newer image. I fear the driver integration may have undone dynamic update or something?

I also tested this second iso, and it appears fine, drivers working, no new CU or new .NET CU.

But something tells me the boot.wim shrinking there is something wrong? Or can I ignore this and move on? Maybe I should have done drivers before updates?

If I have to do in single pass I will do, but DISM is very slow so prefer to not have to redo that process every time.
 
Last edited:
I have discovered even integrating drivers on stock image removes 200MB from the size, so maybe the new wim has better compression or something.

But because of this, I only integrated drivers as a base image, and will do updates in one pass alongside everything else.

learn.microsoft.com

Update Windows installation media with Dynamic Update - Windows Deployment

Learn how to acquire and apply Dynamic Update packages to existing Windows images prior to deployment
learn.microsoft.com

Watched process, and after feature changes, it seems to not touch updates again, so everything after that would be ok I think in a separate pass.
 
Last edited:
Dism (compatibility) runs at first before updates and removals - therefore Updates integrated won't be cleaned up for replaced update files before second run of NTL.
You've the option to cleanup ComponentStore fetching an updated image from UUPdump instead of having the hassle updating MCT images.
 
I recorded it, was something like this.

Dynamic setup update first.
CU update's. (slow)
DISM (compatible). - (extremely slow)
Feature removals/additions.
.NET 3.5. - (this is quite slow surprisingly)
CU update again. (very quick)
Read updated data.
Prepare data.
Then everything else, remove components, reg integration, settings, post-setup, unattended, it didnt touch anything updates related again.

Boot.wim is still the smaller size so the shrinkage, I think is largely down to better wim compression. After the dynamic updates, a bunch of language folders are added, its a en-gb iso, but now I have 20+ language folders on the ISO.

So DISM is after initial long batch of updates but before feature changes and quick second batch of update processing.
 
Microsoft doesn't export boot.wim indexes to a new file (don't rebuild boot.wim) after integrating updates so some old files are kept.

Opening boot.wim with 7-zip:

2023-05-30 15_34_16.png

To get the actual size you can within NTLite right-click on boot.wim and go to Convert -> Recompress.
 
Just to add, Dynamic Update simply replaces Setup files in the ISO's sources folder. There is no backup created because it's directly extracted from the CAB file. Once installed, you can't revert DU without starting over from a clean ISO.

DU is pointless if you're always making updated Windows images right before you install them. All it does is check if a newer version of the monthly update is available, and applies it over your (outdated) image.
 
So thats all DU is. just a built in CU updater for setup?

Might remove it then, so the ISO is less cluttered. I can do it again from stock ISO without DU.
 
https://learn.microsoft.com/en-us/windows/deployment/update/media-dynamic-update#dynamic-update

Dynamic Update​

Whenever installation of a feature update starts (whether from media or an environment connected to Windows Update), Dynamic Update is one of the first steps. Windows Setup contacts a Microsoft endpoint to fetch Dynamic Update packages, and then applies those updates to your operating system installation media. The update packages include the following kinds of updates:
  • Updates to Setup.exe binaries or other files that Setup uses for feature updates
  • Updates for the "safe operating system" (SafeOS) that is used for the Windows recovery environment
  • Updates to the servicing stack necessary to complete the feature update (see Servicing stack updates for more information)
  • The latest cumulative (quality) update
  • Updates to applicable drivers already published by manufacturers specifically intended for Dynamic Update

Setup is running WU right before the install, assuming you have a valid network. But it only picks up the latest SSU/CU combination, with no changes to .NET or other App packages. The end result is the same if you ran WU right after install.

There's nothing wrong with DU, except it might change what monthly update is installed -- especially if you're trying to keep your image to an older CU to prevent later feature changes from happening.
 
Yes I dont want unpredictability, I added DU as I thought it included bug fixes for the setup process and its selected by default in ntlite. There is a Microsoft web page I read which indicated it made it more likely feature updates would succeed, especially when language packs outside of en-US are used.

But if its just SSU and CU of which I have integrated, I prefer that predictability vs been slightly out of date.
 
You must log in or register to reply here.
Back
Top