forums.wsusoffline.net

My windows 10 download directory is now starting to get to be a stupid download size with now downloading 3 versions of windows 10....

Is there anyway to delete the unwanted files after its downloaded them and then to create the hash files for validation purposes ?

My download folder is over 6 gig in size and my windows 10 dvd is only 2.5 gig seems a little silly to have all that space wasted!!!!!!!

Remove all files that you don't need and then remove the corresponding lines from the hashdeep file wsusoffline/client/md/hashes-w100-x64-glb.txt.

Note, that the hashdeep files are CSV-formatted text files. The last column is the relative path to the file; so you'll be able to figure that out.



If you need to recreate the file: lines 3 and 4 of the hashdeep file indicate the directory, from which hashdeep was executed, and the command line, which was executed; for example:

Code: Select all

## Invoked from: I:\wsusoffline\client\md
## I:\wsusoffline\client\md> ..\bin\hashdeep.exe -c md5,sha1,sha256 -l -r ..\w100-x64\glb

Then just repeat it: In this example, change to the directory

Code: Select all

I:\wsusoffline\client\md

and the repeat the command

Code: Select all

..\bin\hashdeep.exe -c md5,sha1,sha256 -l -r ..\w100-x64\glb

Or you could just uncheck the option "Verify installation packages" in the Update Installer, and skip the revalidation with hashdeep.

Why do we need an integrity database in the first place? WSUS Offline Update was once designed to create custom update CDs/DVDs. It will create an ISO image, which must be burned to writable CD/DVD. But such media are not very reliable: Some self-burned CDs may be "coasters" and unusable from the start; others may go bad after some time. Then it is fine, if there is a way to verify the files again, before trying to install them.

But optical media are not much used today. Digital file signatures are verified with Sigcheck after download. If you keep the archives on reliable media like internal/external hard drives, this should be enough. Unfortunately, the Update Generator and the download script don't allow an "uncoupling" of the verification of digital file signatures with Sigcheck and the creation of the integrity database with hashdeep. For reliable media, this might be a useful option.

@hbuhrmester:
Thank you for your helpful remarks about verification of updates.

...but the original topic is still relevant:
"Download folder for Windows x64 is over 6 gig in size."
I have tried several times in the last four weeks, with or without removing these files, with or without verification. Always the same!
As negg stated, there are several versions of windows10-64 update files in that folder.
There are always 18 files in \w100-x64\glb folder, only 12 with 1,5 GB for windows10-32 in \w100\glb.
Updateinstaller seems to last forever on windows10-64. This does not look ok...

No real change with new 10.8.1.
Now there are 20 files with a total of 6.3GB in \w100-x64\glb folder, still only 12 with 1.5 GB for windows10-32 in \w100\glb.

The \w100-x64\glb folder contains additional files for
windows10.0-kb3192440
windows10.0-kb3194798
windows10.0-kb3195038
windows10.0-kb3198389
windows10.0-kb3199442,
which are not present in \w100\glb.
According to Microsoft-Support-Pages these updates are are crucial for 32- and 64bit Versions?
Sorry, I would like to help, but I just don't have enough substantial knowledge. Just wondering...

For a laugh I decided to do a clean install of windows 10 64 bit without access to the internet. After installing and running wsus it stated it wanted to install 8 updates. On installing these updates it said it skipped the majority of them as not needed. Why did it want to install them in the first place and why did it skip them!!!!!! I think something needs to be looked into as to how windows 10 updates are handled it's getting stupid.

MS does not make any differences between the different Windows 10 versions in the catalog. As soon as I testes hbuhrmesters new superseded update code, I may be able to say more.

My question rather is: Why is there such a big discrepancy between w100 and w100-x64?

Some thoughts...

x64 downloads are about twice as large as the corresponding x86 downloads:

Code: Select all

467M  windows10.0-kb3192440-x86_6d42b875dcc756fd87546d1734e3d3630858b14a.cab
527M  windows10.0-kb3192441-x86_8d14a1ac4c747f83ff6458129e409d60a23e18b0.cab
421M  windows10.0-kb3194798-x86_5534f2d58501364854c2489bdc28dc5edfccc46e.cab

1,1G  windows10.0-kb3192440-x64_fd2776f199941ee34f971e13214f70b81fb03179.cab
991M  windows10.0-kb3192441-x64_d28ff26ba03c21a398e842c029d200b8fc6ed9f0.cab
779M  windows10.0-kb3194798-x64_01caec375c3a480327cd13012a5169f3bf90606d.cab

Some downloads are specifically for Windows Server 2016, which is 64-bit only:

Servicing stack update for Windows Server 2016 Technical Preview 5: July 13, 2016
https://support.microsoft.com/en-us/kb/3173423

Cumulative update for Windows Server 2016 Technical Preview 5: October 11, 2016
https://support.microsoft.com/en-us/kb/3195038

Code: Select all

11M   windows10.0-kb3173423-x64_90670bfe5ce19d79087c6464b7f65c08717e99be.cab
749M  windows10.0-kb3195038-x64_f2933233063b098ea8f893c80f3e7b7604032e17.cab

This could also explain, why there are more variants for x64 than for x86; e.g. kb3172729 appears twice for x86 but three times for x64:

Code: Select all

32K   windows10.0-kb3172729-x86_ccd5d58825da26dc8c870b6f85bd59ab8d8399dd.cab
32K   windows10.0-kb3172729-x86_ea33b213bf595af9948003317c2b107957ffb688.cab

1,4M  windows10.0-kb3172729-v2-x64_ccc19baa66b28b18518e015e10674bd992e258b8.cab
31K   windows10.0-kb3172729-x64_bb12a14ec3891ec0a9e24edb529632263783d389.cab
32K   windows10.0-kb3172729-x64_f4fc9775baa98c176f43e87c40088231a884122b.cab

9,8M  windows10.0-kb3201860-x86_2457117ae1e74d956d12dd84acc74332f5509d89.cab
9,8M  windows10.0-kb3201860-x86_95841b6110cd8c614d2ac421c1c986524d68b9f3.cab
9,8M  windows10.0-kb3201860-x86_d335830dcaf5c422b4f30dd441f4134a4a7d3ff0.cab

21M   windows10.0-kb3201860-x64_76b2785dfb80f7fc1101942cbcc61a1c90b9f5ee.cab
21M   windows10.0-kb3201860-x64_8ad6a8b2b935d037a07c650642e3824ca3293107.cab
21M   windows10.0-kb3201860-x64_8b6259b6743f19fa7a3a95aeef6c86570669fab0.cab
21M   windows10.0-kb3201860-x64_db91222b6b88a2a49fb15d89f63b7ef9ef642140.cab

I'm glad the next big update has been put on hold tell the new UUP goes 100% live but when it does that means probably another size increase and will probably be 2 or 3 gig if not more. If this happens I think wsus will become pointless for windows 10 unless it's possible to control what and how it downloads W100 and W100-x64.

Great. MS OS version/SP chaos became MS branch chaos. Instead of retiring EOL OS we have to retire obsolete branches, now. And, MS, where is the improvement there?

Maybe we eventually need to, for the sake of media size, split/segment branches* like we did segment OSes before, like "I need only Windows 1607 updates on the media, and no server packages, please!"

*
CB
CBB
LTSB2015
LTSB2016
Server2016
.
.
.

To be continued.