Stopping WSUS download (and installation?) activity

[WsusJ]

As a new user, I just set up the latest WSUS build (8.5) on my computer. As I do with all programs, I started it just to "try it out," and confirm that it was operating correctly. It immediately made the required connections, made checks, and began downloads. Satisfied that everything was operating properly, I then tried to stop the process because I didn't want to have my bandwidth tied up with a long download activity. However, I found no way in the Command Prompt window, or in GUI interface, to simply stop the activity. I eventually closed the connection with SysInternals TCPView, and then killed the process with Task Manager.

I then came here, and searched the discussion board for the term "stop download." I found only one apparently-relevant post (viewtopic.php?f=3&t=3555&p=10304&hilit=stop+download#p10304). On 11.01.2013, 00:33, boco wrote: "Never stop it mid-download. Especially if Verify is enabled this disturbs the generated hashes and the next run will fail with a hash verify error."

Whether they are new to the program, or a veteran, there are many reasons why a user might want to stop the download process before it reaches its conclusion. Since stopping downloads, and/or resuming them later, is such a fundamental part of the Internet experience today, almost no one would suspect that doing so would cause problems. Since it does, I suggest that your next update include the ability to gracefully stop the download process without causing corruption or errors. Such an addition would also be valuable for the updating process as well, if there are problems caused by stopping it.

[boco]

Since large parts of WSUSOU are batch files this ain't easy.

Maybe the CRC part could be optimized:
Once the downloader has checked and verified CRCs as being good, it should rename the .txt file to .bak (overwriting old .bak as necessary). After downloads have finished it creates new CRCs, anyways. With the renamed CRC file, attempts to interrupt downloads will only get a warning next time (no CRC .txt file), but not an error.

Resuming isn't possible, the downloader (WGet or aria2) doesn't know if it is a truncated or an updated file.

[WsusJ]

Maybe the CRC part could be optimized:
Once the downloader has checked and verified CRCs as being good, it should rename the .txt file to .bak (overwriting old .bak as necessary). After downloads have finished it creates new CRCs, anyways. With the renamed CRC file, attempts to interrupt downloads will only get a warning next time (no CRC .txt file), but not an error.

I'm sorry that the program's use of batch files makes this difficult, but your idea seems like it would accomplish everything essential. If this change was made, there might even be no reason to issue the warning.

I don't think the fact that "resuming [the download] isn't possible" is a problem. Many servers still don't allow that, so it wouldn't be a surprise. Moreover, the most important effect of resuming a download is achieved by the basic operation of the program: it checks for the existence of each file, and does not re-download those that have already been downloaded.

How about at the other end of the process? Is there a workaround if the installation process is interrupted, or is WSUS already set up to handle that possibility without error?

I'll close by adding something I forgot to add the other night. It's not just user choice that can cause either downloads or installations to be interrupted. Any number of things can cause loss of internet connectivity, and WSUS is probably not immune to crashes or hangs of its own process, those caused by other processes running simultaneously, or the entire system.

Thanks for getting back to me.

[WSUSUpdateAdmin]

Hi.

As you already know, you may of course break both download and installation batch runs using <Ctrl>C.

From a technical point of view, it's not possible for the running script to reach a defined line or state, then.

In practice, this doesn't matter:
- If you break download #85, a subsequent download run will skip files #1 to #84, because the remote files don't differ from the local ones (wget -N).
- If you break installation #85, on a subsequent installation run Windows will decide whether to re-install #85 or not.

But, as boco mentioned, the hash-based verification is a problem:

Maybe the CRC part could be optimized:
Once the downloader has checked and verified CRCs as being good, it should rename the .txt file to .bak (overwriting old .bak as necessary). After downloads have finished it creates new CRCs, anyways. With the renamed CRC file, attempts to interrupt downloads will only get a warning next time (no CRC .txt file), but not an error.

Good idea!
Thanks, will be in r498.
BTW: Why not just delete the hash files once an audit passed? As you said, they'll be re-created anyway...

Regards
Torsten Wittrock

[boco]

BTW: Why not just delete the hash files once an audit passed? As you said, they'll be re-created anyway...

Old IT rule: Make a backup. Oh, well, not required, I guess.

[WSUSUpdateAdmin]

Thx!

[boco]

Spoke too soon. Seems we need a different solution for the 'once per day' updates... The hashes' time stamp was used as trigger AFAIK.

[WSUSUpdateAdmin]

Doesn't matter, I think:
Same day -> skip download (and audit) -> no deletion of hash file
Older -> download (and audit) -> deletion and new hash file
Greets
Torsten

[boco]

Strange, C++ installers are checked every run right now...

[WSUSUpdateAdmin]

You're right, I'll fix that.