My main Win PC is offline and uses Win 10. Therefore, occasionally I
have used the WSUS tool to update it. I downloaded the latest version
of the tool today and specified the 1909 update along with frameworks, security, etc. All proceeded well and it looks like several GB of files
were downloaded. I started the update tool from among the downloaded
files. I had the chance to select frameworks and a couple of other
things, but I noticed that the 1909 update was not listed. Once the
updates were complete, I checked Win and still at 1809. Ideas for the
remedy would be welcome and thanks in advance.

bill

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bill S Dimetto <[email protected]> wrote:

My main Win PC is offline and uses Win 10. Therefore, occasionally I
have used the WSUS tool to update it. I downloaded the latest
version of the tool today and specified the 1909 update along with frameworks, security, etc. All proceeded well and it looks like
several GB of files were downloaded. I started the update tool from
among the downloaded files. I had the chance to select frameworks
and a couple of other things, but I noticed that the 1909 update was
not listed. Once the updates were complete, I checked Win and still
at 1809. Ideas for the remedy would be welcome and thanks in
advance.

What does "WSUS tool" mean?
- WSUS Offline (https://wsusoffline.net/)
- WSUS Offline CE (https://gitlab.com/wsusoffline/wsusoffline/-/releases/12.4_CommunityEdition)
- Or, a Microsoft WSUS server in your domain/network. I can't help if
you're using a WSUS server (never used one nor maintain one).

The WSUS Offline project was discontinued. There haven't been updates
for quite a while to support later editions of various Windows versions.
You have to instead use the version of WSUS that got picked up by some community.

https://gitlab.com/wsusoffline/wsusoffline/-/releases/12.4_CommunityEdition

When the original author of WSUS dropped working on it, I dropped using
it. No idea if the community edition is getting updated.

When a later version of WSUS notes that it dropped support of old
versions of Windows, you have to download and use an older version of
WSUS that did support the old Windows version. However, just because
you have an old version of WSUS that could retrieve the old updates from Microsoft WU catalog for an old version of Windows does not mean
Microsoft still has the updates in the catalog for the old Windows
version.

Windows 10 1909 support was dropped back on May 11, 2021. Once dropped, Microsoft may stop providing the old files in their WU catalog. That's
why you had to periodically run WSUS Offline, even keeping older
versions of it, so YOU had the update files. Each version of WSUS
Offline get puts in a different folder, and WSUS Offline eventually
itself drops older versions of Microsoft-ware, so if you need the older
stuff then you keep the folders for the older versions of WSUS Offline
after it did its downloads back then.

I haven't tried it, but perhaps you could use an .iso file created by
the Media Creation Tool (MCT). You have MCT create an ISO image file
for you. Whether you can run its setup to have it do an update instead
of a full install is something someone else will have to remark upon.
Online article suggest you can do an upgrade from an ISO.

Create Windows 10 installation media https://www.microsoft.com/en-us/software-download/windows10

So, why are you using WSUS Offline if your intent is to upgrade your
current Windows 10 installation to the latest build? Why not use the WU
Client to update Windows? Yes, you have to go online, but you have to
go online with WSUS Offline, too, to have it get the updates. Or are
you trying to update to the 1909 build instead of the latest 22H2 build?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

T24gMTAvMzEvMjQgNDoxOCBQTSwgLi4ud8Khw7HCp8KxwqTDsSB3cm90ZToNCj4gQmlsbCBT IERpbWV0dG8gd3JvdGUgb24gMTAvMzEvMjQgMTozNiBBTToNCj4+IE15IG1haW4gV2luIFBD IGlzIG9mZmxpbmUgYW5kIHVzZXMgV2luIDEwLsKgIFRoZXJlZm9yZSwgb2NjYXNpb25hbGx5 IEkgDQo+PiBoYXZlIHVzZWQgdGhlIFdTVVMgdG9vbCB0byB1cGRhdGUgaXQuwqAgSSBkb3du bG9hZGVkIHRoZSBsYXRlc3QgdmVyc2lvbiANCj4+IG9mIHRoZSB0b29sIHRvZGF5IGFuZCBz cGVjaWZpZWQgdGhlIDE5MDkgdXBkYXRlIGFsb25nIHdpdGggZnJhbWV3b3JrcywgDQo+PiBz ZWN1cml0eSwgZXRjLsKgIEFsbCBwcm9jZWVkZWQgd2VsbCBhbmQgaXQgbG9va3MgbGlrZSBz ZXZlcmFsIEdCIG9mIA0KPj4gZmlsZXMgd2VyZSBkb3dubG9hZGVkLsKgIEkgc3RhcnRlZCB0 aGUgdXBkYXRlIHRvb2wgZnJvbSBhbW9uZyB0aGUgDQo+PiBkb3dubG9hZGVkIGZpbGVzLsKg IEkgaGFkIHRoZSBjaGFuY2UgdG8gc2VsZWN0IGZyYW1ld29ya3MgYW5kIGEgY291cGxlIA0K Pj4gb2Ygb3RoZXIgdGhpbmdzLCBidXQgSSBub3RpY2VkIHRoYXQgdGhlIDE5MDkgdXBkYXRl IHdhcyBub3QgbGlzdGVkLiAgDQo+PiBPbmNlIHRoZSB1cGRhdGVzIHdlcmUgY29tcGxldGUs IEkgY2hlY2tlZCBXaW4gYW5kIHN0aWxsIGF0IDE4MDkuICANCj4+IElkZWFzIGZvciB0aGUg cmVtZWR5IHdvdWxkIGJlIHdlbGNvbWUgYW5kIHRoYW5rcyBpbiBhZHZhbmNlLg0KPj4NCj4+ IGJpbGwNCj4gDQo+IElzIHRoZXJlIGEgcmVhc29uIGZvciB1cGRhdGluZyBXaW4xMCBmcm9t IGEgbm8gbG9uZ2VyIHN1cHBvcnRlZCANCj4gdmVyc2lvbigxODA5KSB0byBhIGxhdGVyIG5v IGxvbmdlciBzdXBwb3J0ZWQgdmVyc2lvbigxOTA5KT8NCj4gDQo+IFdoeSBub3QganVzdCB1 cGRhdGUgV2luMTAgdG8gMjJIMiB0aGUgbW9zdCBjdXJyZW50IHJlbGVhc2UuDQo+IE5vdGU6 IFdoZW4gdXBkYXRpbmcgYW4gYWxtb3N0IDYgeXIuIG9sZCBvL3MoMTgwOSkgdGhlIHVwZGF0 aW5nIHdpdGggMjJIMiANCj4gbWVkaWEoVVNCLCBtb3VudGVkIElTTywgZXRjLikgaXMgbGlr ZWx5IHRvIG5vdCBiZSBhIGRpcmVjdCB1cGRhdGUgdG8gDQo+IDIySDIgbGF0ZXN0IHJlbGVh c2VkIExDVS4NCj4gIMKgLSBpLmUuIFByZS1yZXF1aXNpdGUgYW5kIHByaW9yIG1pbmltdW0g TENVLCBTU1UsIFdpbmRvd3MgVXBkYXRlIA0KPiBlbmdpbmUsIFdpblJFIGV0Yy4gd2lsbCBi ZSBuZWNlc3NhcnkgZm9yIHVwZGF0aW5nIC0gd2hpY2ggdXN1YWxseSBtZWFucyANCj4gYWRk aXRpb25hbCBhbmQgbmVjZXNzYXJ5IEtCJ3Mgd2lsbCBiZSBvZmZlcmVkIGFuZCBuZWVkIHRv IGJlIGluc3RhbGxlZCANCj4gYmVmb3JlIHVwZGF0aW5nIHRvIHRoZSBsYXRlc3QgMjJIMiB2 ZXJzaW9uL2J1aWxkLg0KDQpPaywgSSB3YXMgbm90IGF3YXJlIHRoZXJlIHdhcyBzdWNoIGEg dmVyc2lvbi4gIEkgdGhvdWdodCAxOTA5IHdhcyB0aGUgDQpsYXN0IHVwZGF0ZWQgV2luIDEw IHZlcnNpb24uICBDYW4gdGhpcyB1cGRhdGUgYmUgZG9uZSB2aWEgdGhlIFdTVVMgdG9vbD8g DQogIFRoZSBQQyBpcyBvZmZsaW5lIHNvIG5vdCBzdXJlIGlmIFdpblJFIG9yIHRoZSBvdGhl cnMgd291bGQgd29yay4NCg==

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 10/31/2024 7:32 PM, Bill S Dimetto wrote:

On 10/31/24 4:18 PM, ...w¡ñ§±¤ñ wrote:

Bill S Dimetto wrote on 10/31/24 1:36 AM:

My main Win PC is offline and uses Win 10.  Therefore, occasionally I have used the WSUS tool to update it.  I downloaded the latest version of the tool today and specified the 1909 update along with frameworks, security, etc.  All proceeded well

and it looks like several GB of files were downloaded.  I started the update tool from among the downloaded files.  I had the chance to select frameworks and a couple of other things, but I noticed that the 1909 update was not listed.  Once the
updates were complete, I checked Win and still at 1809.  Ideas for the remedy would be welcome and thanks in advance.

bill

Is there a reason for updating Win10 from a no longer supported version(1809) to a later no longer supported version(1909)?

Why not just update Win10 to 22H2 the most current release.
Note: When updating an almost 6 yr. old o/s(1809) the updating with 22H2 media(USB, mounted ISO, etc.) is likely to not be a direct update to 22H2 latest released LCU.
  - i.e. Pre-requisite and prior minimum LCU, SSU, Windows Update engine, WinRE etc. will be necessary for updating - which usually means additional and necessary KB's will be offered and need to be installed before updating to the latest 22H2

version/build.

Ok, I was not aware there was such a version.  I thought 1909 was the last updated Win 10 version.  Can this update be done via the WSUS tool?  The PC is offline so not sure if WinRE or the others would work.

https://en.wikipedia.org/wiki/Windows_10_version_history

Summary winver.exe

1809 October 2018 Update 17763
1903 19H1 May 2019 Update 18362
1909 19H2 November 2019 Update 18363
2004 20H1 May 2020 Update 19041
20H2 20H2 October 2020 Update 19042
21H1 21H1 May 2021 Update 19043
21H2 21H2 November 2021 Update 19044
22H2 22H2 2022 Update 19045

Media is available here. If you run this link from WinXP or from Linux,
then the MediaCreationTool is not an option and a pair of direct download
links to ISO files are created. The link URLs are valid for 24 hours.
There is no point in me creating these, because you might need a
different country or language. You can see in the sample URLs I've posted,
you are receiving 22H2.

https://www.microsoft.com/en-ca/software-download/windows10

https://software.download.prss.microsoft.com/dbazure/Win10_22H2_English_x64v1.iso?t=...

https://software.download.prss.microsoft.com/dbazure/Win10_22H2_English_x32v1.iso?t=...

On the target machine, copy the ISO file to, say, the Downloads folder.
In explorer, "open" the file. The right-click context menu would
say "mount" if you didn't have Imgburn loaded.

Alternately, you could try, from a Terminal. In attempting to "open" the
file this way, perhaps Imgburn binding to the file type, will be avoided.
The downloaded files can be larger than a single layer DVD, which is
why the word "DVD" is not a part of this procedure. We're doing an Upgrade Install using an ISO file instead.

cd Downloads
explorer ./Win10_22H2_English_x64v1.iso

and maybe that will create the "virtual DVD" drive desired. Look in the
File Explorer window for a new virtual DVD drive. The virtual DVD drive
will not survive a reboot, which is just fine during the Upgrade sequence, since the Upgrade does not refer to the DVD, after the first reboot.

On the virtual DVD drive, locate "Setup.exe" and double click it.
This will do an Upgrade Install of 22H2. It will keep your applications
and user data. You need sufficient remaining space on the C: drive,
for the Upgrade Install to have enough space. This could be anywhere
from 20GB of space to 85GB of space (depends on size of hiberfil.sys created).

Now, you're at 19045.xxx release .

On the C: drive, will be C:\Windows and C:\Windows.old .

The latter directory could be 20GB or more in size. Not only
does it have a copy of the old Windows folder, it also has
copies of a few programs removed during the upgrade. If you needed
to revert the upgrade (or if the process rolls back because of
a compatibility issue), the Windows.old directory provides sufficient
materials to support the rollback.

Let's say, the winver.exe now reports "19045.1", then
you're missing a number of updates. One of the update types,
is a security issue with a certificate in the UEFI BIOS, something
which has been revoked, and is used for secure boot of WinRE.
The size of the Recovery partition (alternate boot OS for emergencies),
that partition is too small for the necessary patch, and will cause
all sorts of "failure" messages during Windows Update. Much of the
rest of the update process now, *when you plug in the machine*,
should work without incident, because a 19045.xxx machine is still
in support. There could be Servicing Stack Updates, regular Cumulative Updates, and so on, to install. The DoSVC cache on another machine, is unlikely
to contribute much in the way of bandwidth reduction, during the Windows 10 update download process.

WSUSOffline appears to have stopped at 1909, so pulling updates
from microsoft.com with that tool, is not going to take the place
of *plugging in* today. So *plug in* and finish the job.

The license status of the machine, whether you're inside a VirtualBox VM,
these can influence how Windows Update behaves when you *plug in* .

Good luck.

Paul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

T24gMTEvMS8yNCAxMjowOSBBTSwgUGF1bCB3cm90ZToNCj4gT24gVGh1LCAxMC8zMS8yMDI0 IDc6MzIgUE0sIEJpbGwgUyBEaW1ldHRvIHdyb3RlOg0KPj4gT24gMTAvMzEvMjQgNDoxOCBQ TSwgLi4ud8Khw7HCp8KxwqTDsSB3cm90ZToNCj4+PiBCaWxsIFMgRGltZXR0byB3cm90ZSBv biAxMC8zMS8yNCAxOjM2IEFNOg0KPj4+PiBNeSBtYWluIFdpbiBQQyBpcyBvZmZsaW5lIGFu ZCB1c2VzIFdpbiAxMC7CoCBUaGVyZWZvcmUsIG9jY2FzaW9uYWxseSBJIGhhdmUgdXNlZCB0 aGUgV1NVUyB0b29sIHRvIHVwZGF0ZSBpdC7CoCBJIGRvd25sb2FkZWQgdGhlIGxhdGVzdCB2 ZXJzaW9uIG9mIHRoZSB0b29sIHRvZGF5IGFuZCBzcGVjaWZpZWQgdGhlIDE5MDkgdXBkYXRl IGFsb25nIHdpdGggZnJhbWV3b3Jrcywgc2VjdXJpdHksIGV0Yy7CoCBBbGwgcHJvY2VlZGVk IHdlbGwgYW5kIGl0IGxvb2tzIGxpa2Ugc2V2ZXJhbCBHQiBvZiBmaWxlcyB3ZXJlIGRvd25s b2FkZWQuwqAgSSBzdGFydGVkIHRoZSB1cGRhdGUgdG9vbCBmcm9tIGFtb25nIHRoZSBkb3du bG9hZGVkIGZpbGVzLsKgIEkgaGFkIHRoZSBjaGFuY2UgdG8gc2VsZWN0IGZyYW1ld29ya3Mg YW5kIGEgY291cGxlIG9mIG90aGVyIHRoaW5ncywgYnV0IEkgbm90aWNlZCB0aGF0IHRoZSAx OTA5IHVwZGF0ZSB3YXMgbm90IGxpc3RlZC7CoCBPbmNlIHRoZSB1cGRhdGVzIHdlcmUgY29t cGxldGUsIEkgY2hlY2tlZCBXaW4gYW5kIHN0aWxsIGF0IDE4MDkuwqAgSWRlYXMgZm9yIHRo ZSByZW1lZHkgd291bGQgYmUgd2VsY29tZSBhbmQgdGhhbmtzIGluIGFkdmFuY2UuDQo+Pj4+ DQo+Pj4+IGJpbGwNCj4+Pg0KPj4+IElzIHRoZXJlIGEgcmVhc29uIGZvciB1cGRhdGluZyBX aW4xMCBmcm9tIGEgbm8gbG9uZ2VyIHN1cHBvcnRlZCB2ZXJzaW9uKDE4MDkpIHRvIGEgbGF0 ZXIgbm8gbG9uZ2VyIHN1cHBvcnRlZCB2ZXJzaW9uKDE5MDkpPw0KPj4+DQo+Pj4gV2h5IG5v dCBqdXN0IHVwZGF0ZSBXaW4xMCB0byAyMkgyIHRoZSBtb3N0IGN1cnJlbnQgcmVsZWFzZS4N Cj4+PiBOb3RlOiBXaGVuIHVwZGF0aW5nIGFuIGFsbW9zdCA2IHlyLiBvbGQgby9zKDE4MDkp IHRoZSB1cGRhdGluZyB3aXRoIDIySDIgbWVkaWEoVVNCLCBtb3VudGVkIElTTywgZXRjLikg aXMgbGlrZWx5IHRvIG5vdCBiZSBhIGRpcmVjdCB1cGRhdGUgdG8gMjJIMiBsYXRlc3QgcmVs ZWFzZWQgTENVLg0KPj4+ICDCoMKgLSBpLmUuIFByZS1yZXF1aXNpdGUgYW5kIHByaW9yIG1p bmltdW0gTENVLCBTU1UsIFdpbmRvd3MgVXBkYXRlIGVuZ2luZSwgV2luUkUgZXRjLiB3aWxs IGJlIG5lY2Vzc2FyeSBmb3IgdXBkYXRpbmcgLSB3aGljaCB1c3VhbGx5IG1lYW5zIGFkZGl0 aW9uYWwgYW5kIG5lY2Vzc2FyeSBLQidzIHdpbGwgYmUgb2ZmZXJlZCBhbmQgbmVlZCB0byBi ZSBpbnN0YWxsZWQgYmVmb3JlIHVwZGF0aW5nIHRvIHRoZSBsYXRlc3QgMjJIMiB2ZXJzaW9u L2J1aWxkLg0KPj4NCj4+IE9rLCBJIHdhcyBub3QgYXdhcmUgdGhlcmUgd2FzIHN1Y2ggYSB2 ZXJzaW9uLsKgIEkgdGhvdWdodCAxOTA5IHdhcyB0aGUgbGFzdCB1cGRhdGVkIFdpbiAxMCB2 ZXJzaW9uLsKgIENhbiB0aGlzIHVwZGF0ZSBiZSBkb25lIHZpYSB0aGUgV1NVUyB0b29sPyDC oFRoZSBQQyBpcyBvZmZsaW5lIHNvIG5vdCBzdXJlIGlmIFdpblJFIG9yIHRoZSBvdGhlcnMg d291bGQgd29yay4NCj4gDQo+IGh0dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL1dpbmRv d3NfMTBfdmVyc2lvbl9oaXN0b3J5DQo+IA0KPiBTdW1tYXJ5ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgd2ludmVyLmV4ZQ0KPiANCj4gMTgwOSAgICAgICAgICAgIE9jdG9i ZXIgMjAxOCBVcGRhdGUgICAgIDE3NzYzDQo+IDE5MDMgCTE5SDEgICAgTWF5IDIwMTkgVXBk YXRlICAgICAgICAgMTgzNjINCj4gMTkwOSAJMTlIMiAgICBOb3ZlbWJlciAyMDE5IFVwZGF0 ZSAgICAxODM2Mw0KPiAyMDA0IAkyMEgxICAgIE1heSAyMDIwIFVwZGF0ZSAgICAgICAgIDE5 MDQxDQo+IDIwSDIgCTIwSDIgICAgT2N0b2JlciAyMDIwIFVwZGF0ZSAgICAgMTkwNDINCj4g MjFIMSAJMjFIMSAgICBNYXkgMjAyMSBVcGRhdGUgICAgICAgICAxOTA0Mw0KPiAyMUgyIAky MUgyICAgIE5vdmVtYmVyIDIwMjEgVXBkYXRlICAgIDE5MDQ0DQo+IDIySDIgCTIySDIgICAg MjAyMiBVcGRhdGUgICAgICAgICAgICAgMTkwNDUNCj4gDQo+IE1lZGlhIGlzIGF2YWlsYWJs ZSBoZXJlLiBJZiB5b3UgcnVuIHRoaXMgbGluayBmcm9tIFdpblhQIG9yIGZyb20gTGludXgs DQo+IHRoZW4gdGhlIE1lZGlhQ3JlYXRpb25Ub29sIGlzIG5vdCBhbiBvcHRpb24gYW5kIGEg cGFpciBvZiBkaXJlY3QgZG93bmxvYWQNCj4gbGlua3MgdG8gSVNPIGZpbGVzIGFyZSBjcmVh dGVkLiBUaGUgbGluayBVUkxzIGFyZSB2YWxpZCBmb3IgMjQgaG91cnMuDQo+IFRoZXJlIGlz IG5vIHBvaW50IGluIG1lIGNyZWF0aW5nIHRoZXNlLCBiZWNhdXNlIHlvdSBtaWdodCBuZWVk IGENCj4gZGlmZmVyZW50IGNvdW50cnkgb3IgbGFuZ3VhZ2UuIFlvdSBjYW4gc2VlIGluIHRo ZSBzYW1wbGUgVVJMcyBJJ3ZlIHBvc3RlZCwNCj4geW91IGFyZSByZWNlaXZpbmcgMjJIMi4N Cj4gDQo+IGh0dHBzOi8vd3d3Lm1pY3Jvc29mdC5jb20vZW4tY2Evc29mdHdhcmUtZG93bmxv YWQvd2luZG93czEwDQo+IA0KPiAgICAgaHR0cHM6Ly9zb2Z0d2FyZS5kb3dubG9hZC5wcnNz Lm1pY3Jvc29mdC5jb20vZGJhenVyZS9XaW4xMF8yMkgyX0VuZ2xpc2hfeDY0djEuaXNvP3Q9 Li4uDQo+IA0KPiAgICAgaHR0cHM6Ly9zb2Z0d2FyZS5kb3dubG9hZC5wcnNzLm1pY3Jvc29m dC5jb20vZGJhenVyZS9XaW4xMF8yMkgyX0VuZ2xpc2hfeDMydjEuaXNvP3Q9Li4uDQo+IA0K PiBPbiB0aGUgdGFyZ2V0IG1hY2hpbmUsIGNvcHkgdGhlIElTTyBmaWxlIHRvLCBzYXksIHRo ZSBEb3dubG9hZHMgZm9sZGVyLg0KPiBJbiBleHBsb3JlciwgIm9wZW4iIHRoZSBmaWxlLiBU aGUgcmlnaHQtY2xpY2sgY29udGV4dCBtZW51IHdvdWxkDQo+IHNheSAibW91bnQiIGlmIHlv dSBkaWRuJ3QgaGF2ZSBJbWdidXJuIGxvYWRlZC4NCj4gDQo+IEFsdGVybmF0ZWx5LCB5b3Ug Y291bGQgdHJ5LCBmcm9tIGEgVGVybWluYWwuIEluIGF0dGVtcHRpbmcgdG8gIm9wZW4iIHRo ZQ0KPiBmaWxlIHRoaXMgd2F5LCBwZXJoYXBzIEltZ2J1cm4gYmluZGluZyB0byB0aGUgZmls ZSB0eXBlLCB3aWxsIGJlIGF2b2lkZWQuDQo+IFRoZSBkb3dubG9hZGVkIGZpbGVzIGNhbiBi ZSBsYXJnZXIgdGhhbiBhIHNpbmdsZSBsYXllciBEVkQsIHdoaWNoIGlzDQo+IHdoeSB0aGUg d29yZCAiRFZEIiBpcyBub3QgYSBwYXJ0IG9mIHRoaXMgcHJvY2VkdXJlLiBXZSdyZSBkb2lu ZyBhbiBVcGdyYWRlDQo+IEluc3RhbGwgdXNpbmcgYW4gSVNPIGZpbGUgaW5zdGVhZC4NCj4g DQo+ICAgICAgY2QgRG93bmxvYWRzDQo+ICAgICAgZXhwbG9yZXIgLi9XaW4xMF8yMkgyX0Vu Z2xpc2hfeDY0djEuaXNvDQo+IA0KPiBhbmQgbWF5YmUgdGhhdCB3aWxsIGNyZWF0ZSB0aGUg InZpcnR1YWwgRFZEIiBkcml2ZSBkZXNpcmVkLiBMb29rIGluIHRoZQ0KPiBGaWxlIEV4cGxv cmVyIHdpbmRvdyBmb3IgYSBuZXcgdmlydHVhbCBEVkQgZHJpdmUuIFRoZSB2aXJ0dWFsIERW RCBkcml2ZQ0KPiB3aWxsIG5vdCBzdXJ2aXZlIGEgcmVib290LCB3aGljaCBpcyBqdXN0IGZp bmUgZHVyaW5nIHRoZSBVcGdyYWRlIHNlcXVlbmNlLA0KPiBzaW5jZSB0aGUgVXBncmFkZSBk b2VzIG5vdCByZWZlciB0byB0aGUgRFZELCBhZnRlciB0aGUgZmlyc3QgcmVib290Lg0KPiAN Cj4gT24gdGhlIHZpcnR1YWwgRFZEIGRyaXZlLCBsb2NhdGUgIlNldHVwLmV4ZSIgYW5kIGRv dWJsZSBjbGljayBpdC4NCj4gVGhpcyB3aWxsIGRvIGFuIFVwZ3JhZGUgSW5zdGFsbCBvZiAy MkgyLiBJdCB3aWxsIGtlZXAgeW91ciBhcHBsaWNhdGlvbnMNCj4gYW5kIHVzZXIgZGF0YS4g WW91IG5lZWQgc3VmZmljaWVudCByZW1haW5pbmcgc3BhY2Ugb24gdGhlIEM6IGRyaXZlLA0K PiBmb3IgdGhlIFVwZ3JhZGUgSW5zdGFsbCB0byBoYXZlIGVub3VnaCBzcGFjZS4gVGhpcyBj b3VsZCBiZSBhbnl3aGVyZQ0KPiBmcm9tIDIwR0Igb2Ygc3BhY2UgdG8gODVHQiBvZiBzcGFj ZSAoZGVwZW5kcyBvbiBzaXplIG9mIGhpYmVyZmlsLnN5cyBjcmVhdGVkKS4NCj4gDQo+IE5v dywgeW91J3JlIGF0IDE5MDQ1Lnh4eCByZWxlYXNlIC4NCj4gDQo+IE9uIHRoZSBDOiBkcml2 ZSwgd2lsbCBiZSBDOlxXaW5kb3dzIGFuZCBDOlxXaW5kb3dzLm9sZCAuDQo+IA0KPiBUaGUg bGF0dGVyIGRpcmVjdG9yeSBjb3VsZCBiZSAyMEdCIG9yIG1vcmUgaW4gc2l6ZS4gTm90IG9u bHkNCj4gZG9lcyBpdCBoYXZlIGEgY29weSBvZiB0aGUgb2xkIFdpbmRvd3MgZm9sZGVyLCBp dCBhbHNvIGhhcw0KPiBjb3BpZXMgb2YgYSBmZXcgcHJvZ3JhbXMgcmVtb3ZlZCBkdXJpbmcg dGhlIHVwZ3JhZGUuIElmIHlvdSBuZWVkZWQNCj4gdG8gcmV2ZXJ0IHRoZSB1cGdyYWRlIChv ciBpZiB0aGUgcHJvY2VzcyByb2xscyBiYWNrIGJlY2F1c2Ugb2YNCj4gYSBjb21wYXRpYmls aXR5IGlzc3VlKSwgdGhlIFdpbmRvd3Mub2xkIGRpcmVjdG9yeSBwcm92aWRlcyBzdWZmaWNp ZW50DQo+IG1hdGVyaWFscyB0byBzdXBwb3J0IHRoZSByb2xsYmFjay4NCj4gDQo+IExldCdz IHNheSwgdGhlIHdpbnZlci5leGUgbm93IHJlcG9ydHMgIjE5MDQ1LjEiLCB0aGVuDQo+IHlv dSdyZSBtaXNzaW5nIGEgbnVtYmVyIG9mIHVwZGF0ZXMuIE9uZSBvZiB0aGUgdXBkYXRlIHR5 cGVzLA0KPiBpcyBhIHNlY3VyaXR5IGlzc3VlIHdpdGggYSBjZXJ0aWZpY2F0ZSBpbiB0aGUg VUVGSSBCSU9TLCBzb21ldGhpbmcNCj4gd2hpY2ggaGFzIGJlZW4gcmV2b2tlZCwgYW5kIGlz IHVzZWQgZm9yIHNlY3VyZSBib290IG9mIFdpblJFLg0KPiBUaGUgc2l6ZSBvZiB0aGUgUmVj b3ZlcnkgcGFydGl0aW9uIChhbHRlcm5hdGUgYm9vdCBPUyBmb3IgZW1lcmdlbmNpZXMpLA0K PiB0aGF0IHBhcnRpdGlvbiBpcyB0b28gc21hbGwgZm9yIHRoZSBuZWNlc3NhcnkgcGF0Y2gs IGFuZCB3aWxsIGNhdXNlDQo+IGFsbCBzb3J0cyBvZiAiZmFpbHVyZSIgbWVzc2FnZXMgZHVy aW5nIFdpbmRvd3MgVXBkYXRlLiBNdWNoIG9mIHRoZQ0KPiByZXN0IG9mIHRoZSB1cGRhdGUg cHJvY2VzcyBub3csICp3aGVuIHlvdSBwbHVnIGluIHRoZSBtYWNoaW5lKiwNCj4gc2hvdWxk IHdvcmsgd2l0aG91dCBpbmNpZGVudCwgYmVjYXVzZSBhIDE5MDQ1Lnh4eCBtYWNoaW5lIGlz IHN0aWxsDQo+IGluIHN1cHBvcnQuIFRoZXJlIGNvdWxkIGJlIFNlcnZpY2luZyBTdGFjayBV cGRhdGVzLCByZWd1bGFyIEN1bXVsYXRpdmUgVXBkYXRlcywNCj4gYW5kIHNvIG9uLCB0byBp bnN0YWxsLiBUaGUgRG9TVkMgY2FjaGUgb24gYW5vdGhlciBtYWNoaW5lLCBpcyB1bmxpa2Vs eQ0KPiB0byBjb250cmlidXRlIG11Y2ggaW4gdGhlIHdheSBvZiBiYW5kd2lkdGggcmVkdWN0 aW9uLCBkdXJpbmcgdGhlIFdpbmRvd3MgMTANCj4gdXBkYXRlIGRvd25sb2FkIHByb2Nlc3Mu DQo+IA0KPiBXU1VTT2ZmbGluZSBhcHBlYXJzIHRvIGhhdmUgc3RvcHBlZCBhdCAxOTA5LCBz byBwdWxsaW5nIHVwZGF0ZXMNCj4gZnJvbSBtaWNyb3NvZnQuY29tIHdpdGggdGhhdCB0b29s LCBpcyBub3QgZ29pbmcgdG8gdGFrZSB0aGUgcGxhY2UNCj4gb2YgKnBsdWdnaW5nIGluKiB0 b2RheS4gU28gKnBsdWcgaW4qIGFuZCBmaW5pc2ggdGhlIGpvYi4NCj4gDQo+IFRoZSBsaWNl bnNlIHN0YXR1cyBvZiB0aGUgbWFjaGluZSwgd2hldGhlciB5b3UncmUgaW5zaWRlIGEgVmly dHVhbEJveCBWTSwNCj4gdGhlc2UgY2FuIGluZmx1ZW5jZSBob3cgV2luZG93cyBVcGRhdGUg YmVoYXZlcyB3aGVuIHlvdSAqcGx1ZyBpbiogLg0KPiANCj4gR29vZCBsdWNrLg0KPiANCj4g ICAgIFBhdWwNCg0KVGhhbmtzLCBidXQgbG9va3MgcHJldHR5IG1ham9yLiAgSSB0aGluayBJ J2xsIGRvIGEgZnVsbCBiYWNrIHVwIGZpcnN0IA0KanVzdCBpbiBjYXNlIHRoaW5ncyBkb24n dCB0dXJuIG91dCB3ZWxsLiAgQWxzbywgSSB3b25kZXIgaWYgdGhlcmUncyBhbnkgDQpyZWFs IGFkdmFudGFnZSBpbiB1cGdyYWRpbmcgZnJvbSB3aGF0IEkgaGF2ZSBub3csIDE4MDksIHRv IHRoZSBsYXN0IA0KdXBkYXRlPyAgVGhhdCBQQyBoYXJkbHkgZXZlciBnb2VzIG9ubGluZSBh bmQgdGhlIHNvZnR3YXJlIHNlbGRvbSBjaGFuZ2VzIA0Kb24gaXQuDQo=

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 11/1/2024 12:37 AM, Bill S Dimetto wrote:

Thanks, but looks pretty major.  I think I'll do a full back up first just in case things don't turn out well.  Also, I wonder if there's any real advantage in upgrading from what I have now, 1809, to the last update? 
That PC hardly ever goes online and the software seldom changes on it.

Agreed. I forgot to put that paragraph in, about the backup step.

I recommend one of the third-party backups, Macrium, AOMEI, Easeus
free [Full] backups for a safety backup. While Windows has its
own backup routine, you need to practice with that to have any
confidence in it (it's one strange squirrel). You can store the
backup on an external drive, and unplug the external before starting
the Upgrade Install.

Commercial backups, the backup is likely stored in a single file,
so you "can't lose parts of it" by accident. The commercial ones
also support "verify", which is a way of checking the CRC of
the file at any future time. This checks that nothing got
corrupted while you were shifting it between file shares or whatever.
I once had two backups corrupted by bad machine RAM, and the
Verify warned me something was broken.

I generally only recommend that the OS drive be present during
an OS installation procedure. This prevents "splatter" or damage,
or unintentional coupling to any other disk drive. These are
general rules of thumb that can be applied to any situation,
even Linux. I once had a Linux distro, wipe the other Linux
OSes off a drive -- too funny. A backup would have helped.

*******

There really isn't any difference between

hardly ever goes online

absolutely NEVER goes online

A side-lined machine can act as a virus reservoir, serving
to infect media plugged into it. Or in the case of network
worms, if the machine is connected to the LAN for some reason,
a worm could pass from one machine to another.

You have to remember who your opponents are. Maybe at the current
time, the ransomware people are more interested in hospitals,
than punters. Maybe the attack spectrum is pretty muted at the moment.
But if a nation state actor makes malware, it's going to get
into everything. You should still do your best to make the
machine at least "nominally" secure. Have that recent signature
definitions installed.

Take my (sampling of) machine collection:

motherboard with E7500 CPU - 2MB/sec file compression rate (can test AGP and PCIe cards)
Optiplex 780 E8400 CPU - 3MB/sec file compression rate
Daily driver Zen3 - 25MB/sec file compression rate
Strongest machine Zen3 - 50MB/sec file compression rate

A lot of machines are going to need to be broken, before
I will be using the Optiplex (slower). But the Optiplex right now
does have 22H2 installed. I had to install a video card
from the junk room, as 22H2 needs better than GMA 3500 graphics :-)
If I seriously wanted to use the machine (switch to it as daily
driver) , then I would be doing Windows Update to bring
in about eight months worth of updates. The machine is not
in the room, is not on a table, has to be set up to use it.
I don't plan on lifting it onto a table every 31 days,
for updates :-)

And my track record is, I have had two broken machines before,
and needed a *third* machine to dial out for help. This
does not happen too often, but you get the idea. I might need
to connect that Optiplex... about once every ten years.

Paul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 1 Nov 2024 01:48:34 -0400, Paul <[email protected]d> wrote:

Commercial backups, the backup is likely stored in a single file,
so you "can't lose parts of it" by accident. The commercial ones
also support "verify", which is a way of checking the CRC of
the file at any future time. This checks that nothing got
corrupted while you were shifting it between file shares or whatever.
I once had two backups corrupted by bad machine RAM, and the
Verify warned me something was broken.

Right alongside the Verify function, I've wondered why they don't provide a Repair function, since it would be so easy to do. The Quickpar usage model comes
to mind, and speaking of Quickpar, anyone can use it to verify (and repair) any file or set of files. Still, it would be nice if Macrium, for example, just offered a similar functionality as part of the backup dialogue.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 11/1/2024 9:41 AM, Char Jackson wrote:

On Fri, 1 Nov 2024 01:48:34 -0400, Paul <[email protected]d> wrote:

Commercial backups, the backup is likely stored in a single file,
so you "can't lose parts of it" by accident. The commercial ones
also support "verify", which is a way of checking the CRC of
the file at any future time. This checks that nothing got
corrupted while you were shifting it between file shares or whatever.
I once had two backups corrupted by bad machine RAM, and the
Verify warned me something was broken.

Right alongside the Verify function, I've wondered why they don't provide a Repair function, since it would be so easy to do. The Quickpar usage model comes
to mind, and speaking of Quickpar, anyone can use it to verify (and repair) any
file or set of files. Still, it would be nice if Macrium, for example, just offered a similar functionality as part of the backup dialogue.

The tool did not support Repair at one time, but
now it has a Repair function. I don't know any more
about it than that.

To do a good job of a Repair function, could mean abandoning
backward compatibility on the format. The backup could, at
a minimum, have one hash for the entire (2TB) backup file,
which leaves little syndrome for correction. If you add too many
hash calcs, the program would slow down too much (half speed).

On the other hand, it could have ten percent overhead Reed Solomon,
just as a random example of a corrector.

The problem with Par2, was it wasn't mathematically sound.
Some samples had "matrix sensitivity" -- the scheme uses a
sparse matrix, and if two lines in the matrix are very similar,
this can cause problems. I did not observe this myself, but
one of the people working on PAR at the time, made the claim
it had something to do with matrix math.

What I didn't understand at the time, is why a user could not
do a Par2 method, then do some "test restores" to see if they
exhibited sensitivity or not. Then maybe, you would leave the
PAR result as is on the media, if it isn't screwing up. I don't know
how fleeting the failure symptoms are with that.

Example for the audience (this is from memory, and is likely wrong)

1 2 3 4 5 6 7 PAR_BLK PAR_BLK

You make some parity blocks, based on separate blocks of source material.

Later, if some are lost to corruption (such as two of your
CDs rotted out of a set of nine CDs), then as long as
any seven of the nine items are available...

1 2 3 6 7 PAR_BLK PAR_BLK

you can compute the original set, which is:

1 2 3 4 5 6 7

In the example, if three blocks go missing of nine, you're screwed.

There are various ways to slice your data, but I don't
remember the details, as for the most part the idea
was abandoned on the news the math wasn't working "perfectly".

There are some hardware failure modes in a computer, that
cannot be fixed under any circumstances. My detection of
trouble via Verify, only worked because the "problem" was in
the perfect place to detect it. There could be other fault
causes, that Verify would not pick up. (Your data would
be recorded in a corrupted state and all the checksums
would be good as they used the corrupted data in the calc.)

Paul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)