An idea for Trim

pmikep

Active Member
So, being a Good Do-Bee - and perhaps a bit obsessive - I did a Trim of updates when I was preparing for this latest use of NTLite. (I haven't used NTLite on my desktop for about a year.)

Unfortunately for me, one of the old, now obsolete KB's that I later found I needed, was removed during Trim.

(KB4592438.)

It isn't available from MS anymore.

Fortunately, I was able to restore it from backup.

So this brings up a suggestion: Would there be any harm if NTLite did NOT delete an old obsolete KB unless the user has downloaded a KB that supersedes it?

Kind of a "life saver," in the sense that, if I were not able to restore KB4592438 from backup to my hard drive, I would not have been able to do a Host Refresh of 19042.631 and been able to keep my Programs and Files.
 
System Restore (if enabled) would have saved you in this situation. Expecting NTLite to predict what it needs to back up, before every host refresh, is not realistic. There are simply too many variables to test.

Use System Restore for what it's designed to do, rolling back bad changes.
 
So this brings up a suggestion: Would there be any harm if NTLite did NOT delete an old obsolete KB unless the user has downloaded a KB that supersedes it?

Kind of a "life saver," in the sense that, if I were not able to restore KB4592438 from backup to my hard drive, I would not have been able to do a Host Refresh of 19042.631 and been able to keep my Programs and Files.
Doesn't "obsolete" mean "superseded"?
Also which mode was used for update cleanup?

Thanks.
 
Let me try to clarify.

First, I don't understand the question "Which mode was used for update cleanup?"

If you're asking if I used the DISM type of cleanup option from the Install > Updates tab when processing an image, this is not in view in my request.

What I am talking about is the Trim button on the (Tool) Settings page, that trims obsolete updates from the Downloaded Updates Cache.

Second, I realize that the old (CU) KB that I needed was obsoleted by a more recent (CU) Update.

(I need it because, as I think we have discussed a year ago in this forum, the release of Win10 20H2 v2 (631) was locked out (by Microsoft) from allowing a "Keep all programs and files" type of Host Refresh. A CU was needed to unlock it. And so I have been using the next CU after 20H2's initial release (November 2020, 685) so that I can do a Host Refresh of 20H2 and keep my programs.

You might tell me "Just use the latest CU KB." But I do NOT want to ruin my installation by using the latest CU. (For example, I don't want to break Network Printing.) I need to keep this old, now obsolete KB.

So here's what I'm suggesting for the Trim button:

Some conditionals:

IF an obsolete CU KB is found during Trim, and IF the user has downloaded a more recent CU KB, then offer to trim the obsolete CU KB, as normal.

But,

IF an obsolete CU KB is found, and IF the user has not downloaded a more recent CU KB, then either 1) Issue a Warning (or Advisory) to the user that "You are about to remove an obsolete CU. But you might need a more recent CU." Or 2) since NTlite is now using colors in its Template thing, perhaps color the about to be removed CU in Yellow Text. (Signifying "Caution.")

Perhaps overkill, since you list the KB's to be trimmed, and I suppose it falls to me to know what I'm doing.

But I don't always know what I'm doing. I'll take any help (from the Tool) that I can get.

Did this clarify my Idea for Trim?
 
Last edited:
Ah, "withdrawn" as in "something was wrong with it"?

If so, good to know. I didn't see a distinction between withdrawn and superseded in Microsoft's History of updates. In MS's list, all the CU KB's appear to be superseded.

If I have to install an old CU KB in order to do keep my programs and files during a Host Refresh, I suppose I should install one that hasn't been withdrawn. (Although, since I'm going to "refresh" down to 19402.631, I suppose the quality of the CU KB doesn't matter, as long as my Host OS allows the Refresh.)
 
Withdrawn implies serious errors discovered after its release. As a monthly CU, the next month's replaces it.
Unfortunately, the history of CU updates never gets corrected to reflect removed KB's -- since it's a log and not a live repository like MUC.

Pick the next CU above or below KB4592438.
 
Wilco.

Please, where does one find the list of what KB's are withdrawn? I remember that WSUS Offline Updater used to make a distinction. IIRC, It used to remove withdrawn KB's, IIRC. (But I haven't used WSUS Offline Updater for years, now, ever since NTLite started offering updates.)
 
Wow, that's a lot of work. It sounds like a (new) Feature that NTLite could automate, reporting to users in the TRIM setting whether an old KB is obsolete or withdrawn.
 
Wow, that's a lot of work. It sounds like a (new) Feature that NTLite could automate, reporting to users in the TRIM setting whether an old KB is obsolete or withdrawn.
When Microsoft removes an update, it usually means it's now part of a cumulative update, the fix was no longer needed (a driver update instead etc) or was replaced by a better, safer solution.

In essence, it's very rare, and I don't see a benefit in detecting those, very case-specific.
 
Back
Top