That part tells DISM to use the ESD format and use the ultra compression routine it does not work on .wim format. Windows 10 can use .wim or .esd formats for installing.
I see. Cheers for that info. I have never actually converted a .wim to .esd, have done it the other way round though. I think I am going to look carefully at the toolkits script to see what was going on when it saved the file after importing the update.
It can come in handy converting to ESD format, i had a wim file over 6gb at one time, i did a test and converted to esd format and the result was a file less than 4.1gb i was impressed. Took a while to compress but was worth it. It not take any longer to install Windows with a esd instead of a wim. The only down side is servicing, I think you have to convert back to a wim, do your bits and pieces and then convert back to a esd. Other than that it can make the file a lot smaller.
On that post i read it has the Winre.wim holds both Pro and Home info. So if i am just making a Pro image i do not need the Home info in this Winre.wim file. Am I right in this thinking ? How does somebody delete the Home info and keep the Pro info ? I mounted the original install.wim. Found Winre.wim. Copied it to my DISM folder structure and ran Code: @echo off color 1f title Get Image Info Dism /Get-ImageInfo /ImageFile:C:\DISM\Winre.wim\Winre.wim pause and got this info I sort of was expecting to see 2 indexes and not just 1.. any pointers.
This is my french 15063.502 install.wim x64 containing 11 indexes, all have the same uptodate winre.wim (with ms dart 10 french) install.wim: 4.27 GB (4,593,522,493 bytes) install.esd: 3.09 GB (3,319,195,931 bytes) Used script: @abbodi1406's W10UI_3.3 for updating @abbodi1406's WIM<>ESD for compressing to install.esd Winre.wim only has one index. Lately all sku's/indexes have winre.wims which are not the same anymore, so if you export one index or delete the others and leave one index inside the install,wim that would decrease the size of the wim with at least the file size of the winre.wim from the other index. Putting the same winre.wim inside all indexes: On the Multiple Editions install.wim it would be 400+MB. On the ClientCombined(SL) ESD>ISO converted install.wim it would be 3-4 times 400+MB. That's why @adguard and @abbodi1406 build in the unify winre.wim option in their ESD>ISO converters.
Just run the toolkit again to see what it does, taking more attention of what is said. After mounting, adding the update I select save and commit it does this Now to be honest I have never seen this before, so I googled it and it read quite interesting. So i am just about to test and see what happens. I have this Code: @echo off color 1f title Image Componenent Cleanup With ResetBase DISM /Image:%~dp0mount /Cleanup-Image /StartComponentCleanup /ResetBase pause Which I am going to run after adding the update just prior to saving with commit.. Then I will export the pro index. We'll see.
Yep that's the ticket. Started from afresh, but used the new command ( see above ) After exporting the Pro index i have an install.wim at under 4GB. Just like the one using the toolkit gave me. Now i know what was different. Sorted.
/resetbase will save you about 200MB but brakes the resetpc option. When you are at 15063.xxx (host) disableresetbase will be set to "1" in the registry and it won't be performed, instead only cleanupimage will be performed (it will save a few bits less compared a full resetbase).
Is this bad then ? To me this is what the toolkit was doing, or how i read it. To be honest though, it is just a mess about for me, seeing i am at 15063.502 at a fresh install but with the update ran manually post install.