Yes, that's the goal but like i said, you may get another 1,2 or 3 updates in WU because satisfy list varies i actually included 4 satisfy updates that didn't showed to me in WU all the times
So if I install these live in VM for sysprep, I could install the Important and Recommended with LDR script? And then install the Satisfy updates with GDR script? So for those 3 updates, I just install with GDR script also? Or since I'm running live in VM anyway, I could also just run WU after installing Important, Recommended, and IE11, I would think, and forego the Satisfy updates as I'm able to use WU instead. Does that sound right?
The included install script is modified to do that exactly (install Important and Recommended in LDR, and install the Satisfy updates in normal GDR) those three updates have exception in the script, meaning they will be installed in GDR during LDR session and yes, it's might more reliable to install Satisfy updates of WU i only included them as reference and to make the integration process as complete as possible
OK, since it's an offline script you made, I wasn't sure exactly how to convert it to an online version, so I used my existing LDR and GDR scripts. Meaning, there was no express exception for those 3 updates you mentioned in the way I applied them (that I'm aware of) but otherwise I installed Important and Recommended (Optional) with LDR script and the Satisfy updates with GDR. I then installed IE11 and its updates. Reboot. Then as I ran WU for the first time, this is the list I got offered: Important: 2446710 (dotNET3.5.1) 2894844 (dotNET3.5.1) 2667402 (dotNET3.5.1) 2676562 (dotNET3.5.1) 2813347 (dotNET3.5.1) 2862966 (dotNET3.5.1) 2864202 (dotNET3.5.1) 2868626 (dotNET3.5.1) 2871997 (dotNET3.5.1) 2918614 (dotNET3.5.1) 3025390 (IE11) Optional: 2545698 2547666 2574819 2592687 2647753 2729094 2761217 2830477 Reboot. Ran WU second time, and I got: After reboot, second run of WU: Optional: 2592687 (also present in first WU run above) 2830477 (also present in first WU run above) ^^These two are RDP/RDC updates; as I mentioned before in the thread, I've been having problems installing RDP/RDC related updates and have to do several passes for them to install or otherwise for WU to be quiet about them.^^ Reboot. Ran WU a third time, and I got: Important: 2965788 2984976 2984981 Optional: 2923545 2994023 Succeeded 2 updates. Failed 3 updates. Reboot. Ran WU a fourth time, and I got: Optional: 2923545 ^updates successfully installed - WU finally quiet^ This has probably not that much to do with your list as it does with those RDC/RDP updates I mentioned a little earlier in the thread. It's like they have to be installed 3 times to 'take' on Win7 x64. I don't have that problem doing the same routines on a Win7 x86 image. I guess the dotNET updates are normal? EDIT: I compared the install.wim sizes between my fully updated Dec19 install.wim and the one I made via your list and the WU runs. The one with your list is around 310mb smaller. Not bad
I actually made the script specifically for Offline only, because i know that installing +200 on live system will be very slow and messy, and will give you some errors most of the updates you got in 1st check are the one that don't exist in WHD repo, so you need to download them manually and put them in Satisfy folder only 2446710 and 2894844 are dotNET you got 2864202 because you installed 2685811 in LDR 2574819 likewise based on 3rd check, RDC/RDP (2592687/2830477) wasn't installed at all before even 1st check (did you verify the installed updates after reboot?) i agree that RDC/RDP updates are a mess on there own
OK, for this purpose it might be best for me to offline integrate and then I could always finalize with sysprep afterwards. I like sysprep because of ability to not have pending updates and being able to install the non-integratable updates. Plus it's easy to run/apply things like I always run a script to clean certain directories like nativeimage cache and some other things. Strange, then, because except the IE11 update, all those updates listed on my first WU run under 'Important' were actually designated as dotNET3.5.1 in WU: 2446710 (dotNET3.5.1) 2894844 (dotNET3.5.1) 2667402 (dotNET3.5.1) 2676562 (dotNET3.5.1) 2813347 (dotNET3.5.1) 2862966 (dotNET3.5.1) 2864202 (dotNET3.5.1) 2868626 (dotNET3.5.1) 2871997 (dotNET3.5.1) 2918614 (dotNET3.5.1) No, I did not verify installed updates after the reboot. I've gotten used to certain updates being offered again by now (really has only been happening in the last couple of months, never before) so my strategy was to just run WU until it was quiet
Maybe WU had a moment of delusion regarding nativeimage cache, is't really not needed and delete it won't cause problems with .NET apps?
In my experience, nativeimage cache does not need to be present already on an image. On Win7, you can delete nativeimages_v2 caches and on Win8.x nativeimages_v4 (default). They just regenerate (mscorsvw.exe) by themselves so it can make your install.wims quite a bit smaller. So I usually run: Code: @echo off cls echo. echo ********************************************** echo ************ Cleaning for Sysprep ************ echo ********************************************** echo. echo ~ Clean .NET Assemblies ~ taskkill /IM mscorsvw.exe /f echo. FOR /D %%f IN (C:\Windows\assembly\Nati*.*) do rd /q /s "%%f" rem [this section is only for Win8.x as dism for Win7 does not support this] rem echo. rem echo ~ Clean winSxS ~ rem dism /online /cleanup-image /startcomponentcleanup /resetbase rem echo. echo. echo ~ Clean SoftwareDistribution ~ net stop wuauserv net stop bits del /q /f "C:\Windows\SoftwareDistribution\*" FOR /D %%f IN (C:\Windows\SoftwareDistribution\*) do rd /q /s "%%f" echo. echo ~ Clean temp folder ~ del /q /f "C:\Windows\Temp\*" FOR /D %%f IN (C:\Windows\temp\*) do rd /q /s "%%f" echo. echo. pause ^^The rem'd out part can be enabled for when you run it on Win8.x as Win7 doesn't have that dism option. I also usually delete event log entries and some other things. Doesn't WU stand for Wasted Updater?
Thanks for that BTW, I always try to thank you right away, but being the big fish you are, it seems you have a sucker fish that always beats me to it Nothing wrong with it, it's just amazing I guess that makes me a slow sucker fish
you don't need to clean the SoftwareDistribution folder, it gets completely deleted when sysprep is executed. -andy-
Thanks, I've actually only just been using that particular script for a few weeks as a friend gave it to me who was working on Win8.1 images and asked me what I usually delete to make the image smaller He put the softwaredistribution part in there so I just left it but thanks for the reminder as I had forgotten about that and sysprep. Lately I've also been using NTLite to do a lot of these things (it removes NativeImages_vX and other caches) as I've been testing that and there's a lot of things that can be removed (beside component removal by NTLite, hehe) but few are as dramatic as nativeimage assemblies as they can grow pretty big. Especially nice when you integrate dotNET 4.5.x and have 4 assemblies in Win7. Another thing I do sometimes before applying sysprep is stop module installer service and remove the CBS logs (which can be pretty big too at times). If you install IE11 and sysprep Win7 there's normally also the webcache folder with 35/40mb dat file, that folder can be deleted completely as it regenerates when you start IE11 for the first time, etc. If you use sysprep and apply the reg tweak to enable folder view of the assembly folder, you can actually delete those folders manually live without having to take ownership, just check if mscorsvw.exe instances happen to be running and kill those if so (as the script does).
What do the registry fixes accomplish or improve? Any chance of a windows8U3-Mini for updating an offline W8.1 wim? komm hasn't done any updates for W8 since September and i've been using WHD to rebuild an updated offline wim from scratch, but eventually this will no longer be practical.
It's just registry values that were suggested in some KB articles: Code: KB2011767,KB2555948,KB2581464,KB2646060,KB2668751,KB2685007,KB2712435,KB2728738 KB2743013,KB2807849,KB2824491,KB2826910,KB2829589,KB2830154,KB2831013,KB2831154 KB2856657,KB2893519.KB2901005,KB2927681,KB3008627,KB922976, KB937624, KB942974 Windows 8.1 don't have the same discrepancy or much hotfixes, WU demanding most of replaced monthly rollups, that something cann't be solved from our side and resetbase command would solve the bloat issue