You can use whatever type of storage you want. Within the same network - including VMs - a network share is the most simple and comfortable one IMO. You can also skip directories you don't need on the target system when copying the wsusoffline\client directory, if so required. If you don't have any MS Office installed on the target machine, then skip wsusoffline\client\ofc directory; if you don't have Win8.x/Server 2012 on the target machine, then skip wsusoffline\client\w62 and w63 directories, and so on.

I only use network shares myself, so I don't have to mess around with storage media or worry about how to get the update files to the target machine(s).

If starting the UpdateInstaller.exe as a normal User it will ask for Superuser Permission, but then there is no Access to the Samba Share anymore. If trying to start the Software as a Superuser, this will fail for the same reason, so the only way is to copy the whole set of files to the client...

No, that's caused by the Network drive management of Windows.I'd suggest you to run UpdateInstaller.exeusing the UNC-path. When using an auth-free path, wsusou (just UpdateInstaller.exe, none of the CMD-files) is able to auto-mount it.

Running normally vs. running with elevated rights, that's technically like two different users for network shares. If you use a mapped resource, you need to assign it two times: Once as normal user and once as Superuser. Otherwise, the share is simply gone after the user context switch.

These files must be updated after each official patch day, which is the second Tuesday each month. They are needed to prevent WSUS Offline Update from downloading and installing full quality update rollups as well.

The function seconly_safety_guard compares the modification dates of the configuration files to the date of the official patch day, to make sure, that the files have been updated. Otherwise, the download will be postponed.

After about one year in beta status, this version is now designated version 1.0.

Bugfix: The function download_single_file_failsafe was revised to delete partial files between tries.

The function download_single_file_failsafe is used to download the four virus definition files mpam-fe.exe, mpam-fex64.exe, mpas-fe.exe, and mpas-feX64.exe and the WSUS catalog file wsusscn2.cab in one pass. If the download fails, it is started new from scratch. This is necessary, because there are often different versions of the same file in the Microsoft content delivery network. Partial files must be removed between tries, but a bug caused them to persist.

Bugfix: The declaration of indexed arrays with "declare -ag" was removed.

The declaration of arrays with "declare -ag" can lead to "unbound variable" errors in old versions of the bash, e.g. GNU bash, version 4.2.25, from Ubuntu 12.04 LTS. This error does not happen in more recent versions of the bash.

But, since this declaration with "declare -ag" is not really necessary, it was removed now.

The option --unlink is useful, if hard links are used to create local snapshots or backups, but this option is not available in old versions of GNU Wget.

A new standalone script rebuild-integrity-database.bash was added.

The integrity database consists of hashdeep checksum files in the directory wsusoffline/client/md. They are accessed twice during each run:

Before each download, the existing files are verified by recalculating their hashes and comparing them to the values in the integrity database.

After each download, the hashes files are deleted and rebuilt with the new folder contents. This allows a simple integrity test: Most security downloads include the SHA-1 hash in the filename, as a hexadecimal number of 40 digits length. After calculating the hashes with hashdeep, the SHA-1 hashes can be compared to the expected values.

Recalculating all hashes twice during each run causes a lot of processing. For convenience, the usage of the integrity database can be disabled in the preferences files. The new script rebuild-integrity-database.bash allows to recreate all checksum files at a later time.

However, this script is optional – you can just keep the regular schedule, as it was established by the Windows script DownloadUpdates.cmd.

The functions remove_german_language_support and remove_english_language_support now keep the file modification date.

The new filter function todos_line_endings changes the output of hashdeep to DOS line endings on the fly.

The functions trash_file and unpack_wsus_catalog_file were revised to produce more output.

The copyright was updated to 2018.

Source files are still licensed on a per-file basis, since this is often recommended, e.g. by the GPL itself (see the section "How to Apply These Terms to Your New Programs" at the end of the GPL).

The version information, release date and intended compatibility are removed from most files. They are now only in the scripts update-generator.bash and download-updates.bash, in the files version-history.txt and installed-version.txt, and in this file.

Dear HartmutI had yesterday a broken (automatic) update and today morning again.....I thought it was a download problem and didn't had a closer look. Today I found the temp file intact from the download yesterday and assumed according the log file, that the program is using the defect download. BUT: after deleting the the temp directory and a fresh download the log shows the same Validation error