VHD_WIMBOOT - Apply and Capture of WIM Files for OS in VHD

VHD_WIMBOOT? never been so good as it is now! keep up with all the work, flying dutchman, higher aims ahead!!!

Thank you very much for your support 

It helps me to make all these improvements ....

would it be unmaidenly of me to ask for a middle ground measure between 3.9 and 5 gb for a vhd size? I dont know, something like 4 or 4.5?

plus, could a script be written for automating my findings on get-alladafluff-out? because it takes a whole day or so to take all the stuff out of the storage and out of the registry, by brute force, as alacran rightly calls my effort.

would it be unmaidenly of me to ask for a middle ground measure between 3.9 and 5 gb for a vhd size? I dont know, something like 4 or 4.5?

plus, could a script be written for automating my findings on get-alladafluff-out? because it takes a whole day or so to take all the stuff out of the storage and out of the registry, by brute force, as alacran rightly calls my effort.

Why do you want 4.5 GB if you have 3.9 ( = 4 ) GB  and 5 GB available already ?

Adding a script to remove items is a good idea. As a start we can think of adding option to run base_winsxs.cmd to Reduce WinSxS.

The problem is How to automate what you have been doing manually, since there is no detailed description or manual that I can follow.

If I know a good procedure that can be scripted then I can certainly add such option to make a minimal Win10x64 that is still functioning as the full Win10x64.

What I need in fact a list of files and folders that can be removed safely, combined with as little as possible but necessary changes in the registry.

As you know I managed to Create Mini 7 and Mini 8 in VHD, where the full registry is used combined with a reduced filelist.

It will be most interesting to reduce the footprint (Used Size is now about 3 GB) of Win10x64 Compact LZX mode in FILEDISK.

If we can bring it down to below 1 GB by removal of entire folders (think of removal of .NET and SysWOW64 and a lot of WindowsApps and SystemApps) that would be interesting ....

For booting from RAMDISK the Used Size is already minimal (about 200 MB) when using WimBoot mode.

As regards 3.9 and 5 gb, the former is too small (video and picture thumbnails stay blank, indistinct) and the latter is too large (forced updates may seep thru, which would not be able to in smaller free spaces). 

As for a detailed list of shrinking procedures, I would not relinquish .net and directx (practically the only things I have installed); I have just finished deleting a big amount of files and folders in the following fashion, though:

1) delete all instances of languages from anywhere, apart from the ones u use

2) use swiftsearch to search for mail, sidebar, hyper-v, onedrive, tabletpc, parental, windowsstore, xbox, office, edge, cortana, cloudexperience, internet explorer, internetexplorer, retaildemo, smartcard, narrator, search, defender, xgpuejectdialog, update and remove any files and folders u can find as a result of each search.

3) between each previous and next of the operations above, use tweak.com windows repair to recover activation that may get lost in the process.

4) use registry first aid to automatically straighten and fix various registry errors until u find none.

5) use registrar to delete entries concerning mail, sidebar, hyper-v, onedrive, tabletpc, parental, windowsstore, office, edge, cortana, cloudexperience, internet explorer, internetexplorer, retaildemo, smartcard, narrator, search, defender, xgpuejectdialog, windowsupdate

6) use registry first aid again for the same reason as above.

how much can u automate of all this?

As regards 3.9 and 5 gb, the former is too small (video and picture thumbnails stay blank, indistinct) and the latter is too large (forced updates may seep thru, which would not be able to in smaller free spaces). 

As for a detailed list of shrinking procedures, I would not relinquish .net and directx (practically the only things I have installed); I have just finished deleting a big amount of files and folders in the following fashion, though:

1) delete all instances of languages from anywhere, apart from the ones u use

2) use swiftsearch to search for mail, sidebar, hyper-v, onedrive, tabletpc, parental, windowsstore, xbox, office, edge, cortana, cloudexperience, internet explorer, internetexplorer, retaildemo, smartcard, narrator, search, defender, xgpuejectdialog, update and remove any files and folders u can find as a result of each search.

3) between each previous and next of the operations above, use tweak.com windows repair to recover activation that may get lost in the process.

4) use registry first aid to automatically straighten and fix various registry errors until u find none.

5) use registrar to delete entries concerning mail, sidebar, hyper-v, onedrive, tabletpc, parental, windowsstore, office, edge, cortana, cloudexperience, internet explorer, internetexplorer, retaildemo, smartcard, narrator, search, defender, xgpuejectdialog, windowsupdate

6) use registry first aid again for the same reason as above.

how much can u automate of all this?

What can be automated is the netto effect of these measures and not the procedure that you describe.

What I mean is that I can:

- remove a list of files / folders

- adjust some essential registry settings to make Win10x64 bootable after the removal of files / folders

As an example:

- remove entire SysWOW64 folder (with exception may be of some essential files)

- make small registry adjustment to keep Win10x64 bootable and functioning without trouble

In my idea we could have such receipe as given above for a few user selectable Windows items:

WinSxS (realised already by cdob)

servicing

SoftwareDistribution

Microsoft.NET

SystemApps

System32\DriverStore (reduction in size)

Users\username\AppData\Local\Microsoft

Users\username\AppData\Local\Packages

wonderful example, this of yours, with a few caveats, though:

1) remove entire SysWOW64 folder (with exception may be of some essential files) - excellent

2) make small registry adjustment to keep Win10x64 bootable and functioning without trouble - excellent

3) WinSxS (realised already by cdob) - done

6) Microsoft.NET - most people, including me, need it, or at least they think so

7) Fonts - not everybody considers them superfluous (language expunction looks more useful, I mean all those we do not use, so that is very nationality-bound)

8) SystemApps - that'll be the day!!!

9) System32\DriverStore - reduction in size is already done by some cleaning software, but I do not know if your way would be quicker and more in-depth.

10) Users\username\AppData\Local\Microsoft - that'll be the day!!!

11) Users\username\AppData\Local\Packages - that'll be the day!!!

12) perceptionsimulation can be removed from storage and registry as well.

13) to the best of your knowledge and belief, is there any other file or subfolder in windows whose absence is of no hindrance to the functionality of the system?

@antonino61

As wimb said  :

What can be automated is the netto effect of these measures and not the procedure that you describe.

JFYI, the generic procedure is:
1) know what you have on your hands ( a complete DIR list of the volume hosting the install AND a snapshot of the Registry might do)
2) do whatever change/deletions/whatever you think fit
3) know what you have on your hands after the changes ( a complete DIR list of the volume hosting the install AND a snapshot of the Registry might do)

4) list the differences between #3 and #1

The more you segment the procedure (more small iterations 1-4) you do,  the easier would be to replicate/script them in "independently selectable blocks", i.e. besides the "make the smallest possible windows" other people may want to (say) remove office but keep defender.

More or less the final result should be something loosely similar to what good ol' nlite did for XP or that ntlite can do for later Windows, but post-install.

Wonko

right u r, wonko, this is why I have suggested one do a registry fixing and system rebooting between the previous and the next operations. all operations can be made independently of each other, so, they're all there for the choosing. as for comparing it to ntlite, well, we will  try to do it as close as possible, but, as u know, this is brute force, so extrema ratio, very loosely similar, as u were saying - we would have done it all on ntlite, if we had been able to. some things are hard-coded (eg: xbox I have been able to eradicate in terms of files and folders; when I take the entries off of the registry, my system will not boot again, which is why i did include it in the storage list but did not in the registry entry list). the result has so far been sort of approximate, albeit effective in a sense. one detail has struck me so far, I dont know if it is a good idea to mention it, because I do not want to discourage anyone from making this endeavor, but I will: the actual space gain has been sort of negligible compared to the effort made, which has been worth my while in terms of system responsiveness and resilience to forced changes from the Great Beyond (ya know what I mean, forced updates etc.). the wimboot vhd is noticeably smaller than before, but the wim is only a few megs short of the wim before the brute force procedure (probably due to non-alacran-like defragmentation of the source vhd). I did try defraggler, but the content was almost all defragged already.

Wonko turning Shakespearean!! Wow!!! Windows As You Like It!!! I dig it!!! Let us see what Alacrán will say to that.

I have just taken a look at mini8, which seems to be the closest to mini10-to-be. Excellent I would say, so much so that we might as well start by the same script, and when it fails, try adding the folders it left out one by one until we get it right. Alternatively, we can continue deleting folders from win10 my way and get as close as possible to the mini8 list. I do not know if I have made myself understood and which one is the better idea. or does anyone have anything even better in mind?

I have used wimb's mini 7 and 8 VHDs since long time ago, and latter Wimboot & Compact installed the mini VHDs too, they work fine, but you can't install Office on them as they are, if installed on first VHD it is necessary to edit the file list, unfortunatelly I don't have that info anymore.

But I still have my mini 8.1U1x64 VHD Compact LZX installed (+ SVBus, diskmod, Office, FireFox and some other portables).

About reducing Win10 footprint:

I don't like the idea to lose any functionality, I only remove all Windows and system Apps, including Cortana, Edge and OneDrive, apply some tricks, and add Classic Shell and my favorite programs and portables.

To me it is fine just as it is now, since we keep all functionality in a very acceptable small space, on both Wimboot and Compact installations.

I'm not in favor of a chopped OS, who don't like it the way it is, should better use Win10XPE_x64, there are a lot additional scripts for for it.

In fact I think a program to make a Win10XPE_x64 flat install (Normal and/or Compact mode) on a USB partition or on a VHD located on a USB, would be easier and a more practical approach.

alacran

I would consider ur proposal if winpe were, or could be made into, an install.wim-based (as opposed to boot.wim-based) os. Chopped or reduced, is just a matter of words. office, I have never needed it in the first place - we have portables.

I have used wimb's mini 7 and 8 VHDs since long time ago, and latter Wimboot & Compact installed the mini VHDs too, they work fine, but you can't install Office on them as they are, if installed on first VHD it is necessary to edit the file list, unfortunatelly I don't have that info anymore.

 

But I still have my mini 8.1U1x64 VHD Compact LZX installed (+ SVBus, diskmod, Office, FireFox and some other portables).

About reducing Win10 footprint:

I don't like the idea to lose any functionality, I only remove all Windows and system Apps, including Cortana, Edge and OneDrive, apply some tricks, and add Classic Shell and my favorite programs and portables.

 

To me it is fine just as it is now, since we keep all functionality in a very acceptable small space, on both Wimboot and Compact installations.

 

I'm not in favor of a chopped OS, who don't like it the way it is, should better use Win10XPE_x64, there are a lot additional scripts for for it.

 

In fact I think a program to make a Win10XPE_x64 flat install (Normal and/or Compact mode) on a USB partition or on a VHD located on a USB, would be easier and a more practical approach.

 

alacran

I agree completely with you. 

The present approach of Apply Compact LZX mode as FILEDISK with UsedSize = 3 - 5 GB and Apply WimBoot mode as RAMDISK with UsedSize 200 - 600 MB works quite well.

So there is no need to chop Or reduce size which has the advantage that the Win10x64 OS has full functionality.

What I can do is integrate Reduce WinSxS of cdob as extra Option in Apply Compact modes of VHD_WIMBOOT. That does not reduce the functionality.

I did Fresh Install of Win10x64 version 2004 and added some Programs (New Edge, 7-zip, VLC Player, Office 2003 updates to 2014 integrated,  and No Windows Updates).

After VHD_WIMBOOT Capture followed by Apply in Compact LZX mode then UsedSize in VHD is about 6 GB.

When Windows Update for this month is allowed then the Compact LZX VHD UsedSize rapidly grows to over 11 GB which is bad (a doubling of the original OS) 

What is the origin of the rapid growth and what can I do after Windows Update to reduce the UsedSize down to say 6 GB ? 

If there is a good solution, How can we integrate such solution in the Compact LZX VHD and in VHD_WIMBOOT ?

Windows Update is the real pain in the whole process  .....

Dear wimb

thank you for steady progress of your tool.

What is the origin of the rapid growth (..) ?

I guess Windows.old folder, which is left after upgrade.

"Disk cleanup" reduces normally around 8GiB.

Regards   T.

I guess Windows.old folder, which is left after upgrade.

"Disk cleanup" reduces normally around 8GiB.

 

Thanks for your approval for the VHD_WIMBOOT Tool 

There is no Windows.old folder.

I did fresh Install of Win10x64 version 2004 followed by Windows Update of this month, which doubled the UsedSize 

I agree completely with you. 

 

The present approach of Apply Compact LZX mode as FILEDISK with UsedSize = 3 - 5 GB and Apply WimBoot mode as RAMDISK with UsedSize 200 - 600 MB works quite well.

So there is no need to chop Or reduce size which has the advantage that the Win10x64 OS has full functionality.

What I can do is integrate Reduce WinSxS of cdob as extra Option in Apply Compact modes of VHD_WIMBOOT. That does not reduce the functionality.

 

I did Fresh Install of Win10x64 version 2004 and added some Programs (New Edge, 7-zip, VLC Player, Office 2003 updates to 2014 integrated,  and No Windows Updates).

After VHD_WIMBOOT Capture followed by Apply in Compact LZX mode then UsedSize in VHD is about 6 GB.

When Windows Update for this month is allowed then the Compact LZX VHD UsedSize rapidly grows to over 11 GB which is bad (a doubling of the original OS) 

What is the origin of the rapid growth and what can I do after Windows Update to reduce the UsedSize down to say 6 GB ? 

If there is a good solution, How can we integrate such solution in the Compact LZX VHD and in VHD_WIMBOOT ?

 

Windows Update is the real pain in the whole process  .....

Integrate base_winsxs.cmd from Reduce WinSxS of cdob as an optional feature sounds good to me.

But I suggest to apply it before Capture, doing it this way will help reduce the captured WIM file too (which is good for Wimboot too), or maybe better if added as a separate and independent feature, to let the user run it when he prefers, even on already made final VHD Compact mode installations, letting this way to test it, before make a rebuild.

About the mega monolithic updates:

I think only solution is avoid Updates. And if you want, make a new build when a new final version is available (twice a year).

I usually make a new build only once a year and this is after wait some time to see there is no big troubles with new version.

This are the free tools I use to control Updates and Telemetry as much as possible:

To have more control on Telemetry and Updates, see: O&O ShutUp10.

I recommend to run it after activation as some options block the activation process (it happended to me)

I usually select all options. It is necessary to run it twice with a reboot after each run to keep permanently disabled Update Service.

And finally to control incoming and outgoing connections, see: Firewall App Blocker (Fab)

Select the white list and then the programs allowed to connect to Internet, usually only the browser is enough, and you can additionally reinforce control with specific inbound and outbound blocking rules too.

alacran

Integrate base_winsxs.cmd from Reduce WinSxS of cdob as an optional feature sounds good to me. But I suggest to apply it before Capture, doing it this way will help reduce the captured WIM file too, or maybe better if added as a separate and independent feature, to let the user run it before Capture or after Reapply.

 

About the mega monolithic updates:

 

I think only solution is avoid Updates. And if you want, make a new build when a new final version is available (twice a year).

I usually make a new build only once a year and this is after wait some time to see there is no big troubles with new version.

 

This are the free tools I use to control Updates and Telemetry as much as possible:

 

To have more control on Telemetry and Updates, see: O&O ShutUp10.

I recommend to run it after activation as some options block the activation process (it happended to me)

I usually select all options. It is necessary to run it twice with a reboot after each run to keep permanently disabled Update Service.

 

And finally to control incoming and outgoing connections, see: Firewall App Blocker (Fab)

Select the white list and then the programs allowed to connect to Internet, usually only the browser is enough, and you can additionally reinforce control with specific inbound and outbound blocking rules too.

 

alacran

Thanks a lot for your advice and info about free tools to control Windows Updates 

Indeed it is better to use base_winsxs.cmd before Capture and it will be better to have it as a separate tool.

It will be useful to add such tool to the VHD_WIMBOOT package.

@ wimb

Integrate base_winsxs.cmd from Reduce WinSxS of cdob as an optional feature sounds good to me.

 

But I suggest to apply it before Capture, doing it this way will help reduce the captured WIM file too (which is good for Wimboot too), or maybe better if added as a separate and independent feature, to let the user run it when he prefers, even on already made final VHD Compact mode installations, letting this way to test it, before make a rebuild.

 

alacran

I was editing my previous post quoted section when you made your last post.

I know you are already agree to make this addition as a separate and independent feature, but I think it is important to share with you the additional benefits I saw.

alacran

There is no Windows.old folder.

My fault: Of course not on UPDATE.
I swapped Update and Upgrade.

Could not imagine UPDATE causing this much growth.

Regards   T.

if u dont block *.etl files, u will always have the culprit update which now and then makes ur vhd bulge again. i fdid by sending all of them to ram, but if anyone has another idea I am ready to experiment.

Back to the further shrinking project, I have tried installing win8 for hints coming from a consequent mini8: well, i did not find anything useful for post-install shrinking, which comes down to folders and files in the end. so I will now try and see if any other windows subfolder can be deleted with no prejudice to the functioning of the system. I will do it one by one and at least tell u which are not safe to remove.

I would consider ur proposal if winpe were, or could be made into, an install.wim-based (as opposed to boot.wim-based) os. Chopped or reduced, is just a matter of words. office, I have never needed it in the first place - we have portables.

This is the way to do it, see my new topic: http://reboot.pro/to...ct-mode-on-vhd/

alacran

if u dont block *.etl files, u will always have the culprit update which now and then makes ur vhd bulge again. i fdid by sending all of them to ram, but if anyone has another idea I am ready to experiment.

 

Can you describe for me exactly how to do this so that I can reproduce what you are doing ?

use swiftsearch to locate *.etl files on c:\ (the vhd concerned). go to each one of the locations and move single *etl's or folders containing them (use ur common sense in doing so) to a ramdisk and junction them back to the original location (where the system expects them to be) by means of hardlinkshellext.exe and rerun the vhd. whatever the system recreates will physically end up in ram, so it is 6 of 1 and half a dozen of the other to us.

use swiftsearch to locate *.etl files on c:\ (the vhd concerned). go to each one of the locations and move single *etl's or folders containing them (use ur common sense in doing so) to a ramdisk and junction them back to the original location (where the system expects them to be) by means of hardlinkshellext.exe and rerun the vhd. whatever the system recreates will physically end up in ram, so it is 6 of 1 and half a dozen of the other to us.

Thanks for the info.    These are the steps that I did already, but need help to proceed .....

1. After booting with Win10x64 VHD then use SwiftSearch to search for *.etl files - I have got 116 entries as result

2. use ImDisk Toolkit to make RAMDISK 2GB that is Launched at Windows Startup - What Size RAMDISK do you use ?

3. Download Visual C++ Redistributable for Visual Studio 2015 and Install vc_redist.x64.exe and vc_redist.x86.exe - needed for Link Shell Extension

4. Download Link Shell Extension and Install HardLinkShellExt_X64.exe

5. .....

6. .....

How to do in steps exactly what you have been doing ? What is the next step .....

Can you give ScreenShots that illustrate what I need to do and to show what is the final result

Is there an easy way to move to RAMDISK  the *.etl files found in the search ?

for a ramdisk I use primo ramdisk 5.6 (no higher) the size is half my ram so 32gb, but it is only theoretical (up to 32gb, which never has so far and never will, so dont worry, it uses as much as it is needed, that is to say only a few megs). if I find an etl file in directory x, i point to it by "open location" or something of the kind. once there, I check if it is the only etl or not. if it is, I move it to the ramdisk and right click on it to junction it from ram back into the original place. if there are many etl's in the directory, I will move the whole of the directory into ram and junction it all from ram back to its original location, and so on and so forth. 

at the end of the process, I use registryfirstaid to check that all links and connections are ok and possibly have them corrected if they are not. everything should go fine. this process should be carried out until one gets zero errors. then I shrink the registry and reboot.