It's superseded but v1903 permanize all updates once you cleanup the image, even normally only a full resetbase might remove superseded updates, but that will break things up
With this test and checking the installed packages afterward: https://forums.mydigitallife.net/threads/windows-10-hotfix-repository.57050/page-418#post-1532793 But as you can see under, that test is not applicable anymore I set W10UI_6.6 to resetbase, but you probably mean a full resetbase for CU?
So what's the difference between this and older ones? Why MS changed 1903 update integration method what they achieved by this?
This is quite annoying. I think the only reliable way to clean up the superseded updates is to uninstall them before running the component cleanup. This is on the assumption that we keep track of updates and their supersedence relationship. I like your remarks about the Service Packs being well and alive through the technology used in 1903, but the CUs are hardly true Service Packs, although the delivery mechanism seems to be similar. The true Service Packs might be the Feature Updates like 1607, 1703, 1709, 1809, 1903 though. There is one more aspect here. In WUMT, some (maybe all in some conditions?) Windows 10 updates show as Feature Updates. Other updates are grouped in WUMT under the same Security Updates like the Office Security Updates. I am ignoring on purpose here the mid-cycle CUs which are like Preview Updates, those not flagged as Security Updates, but Updates. I still don't understand entirely how the Windows 10 Security Updates (monthly CUs) are seen as Feature Updates, although there was an earlier post on MDL saying the those "Feature Updates" are essentially a combination of all updates for a month, like CU, .NET CU, Flash Update & SSU.
The only thing that's make 1903 LCU not service pack is releaseType (Update or Security Update) otherwise, evey bit of the distribution mechanism and packages are identical to Win7 SP1 since RS3 16299, cumulative update and servicing stack update are grouped and distributed with UUP upgrade files UUP metadata define if the OS get SSU/LCU alone (normal updates) or the whole set (feature update) that's why you will only get 1 CU entry in WUMT, even with "include superseded" checked, because there is no supersedence chain metadata WU provide OS attributes to UUP, which return the appropiate single metadata
From what you posted here and elsewhere, I should understand that in fact the "full" package for updates is currently provided under UUP and not under what is considered by most people "full install", which are the downloads from Catalog or the packages provided by WSUS. This would explain why sometimes the only available mechanism for repairing faults in WU/MU is to run against the online servers and not even using WUMT. WSUS provides supersedence chain though. The same is likely to be provided in Catalog. On a side note, not long ago, I uninstalled older updates on 1903 after running the cleanup by overwriting them with Catalog installs of the same package, which probably filled in the missing bits which allowed uninstall. Even so, the sequence for the procedure is a bit counter intuitive. I think we discussed this earlier at least in part here on MDL. I think it is only you and selected few people here on MDL who can find some answers in this mess created by Microsoft. The ideas in themselves may be technically sound, but due to the rapid cycle of changes which are implemented, most people cannot follow properly.
Exactly... I had an old habit of doing a /ResetBase on the online image after the monthly SSU/CU installations (usually by WU). - I think I started doing it on Win8 when I had to work with small SSDs but I included it in my "generic maintenance" script and saw no reason to remove it. - Later I learned about the DisableResetBase registry entry in the context that it's now gone from Win10 1903 (although I didn't check this yet on a clean VM install). So, I changed that registry entry to 0 (I was already on 1903). - Ever since I updated to 1903 I had trouble installing CUs, so I decided to change that registry entry back to 1. However, there was no new CU since then, so I can't be sure if it's now fixed (this could still be some completely different issue - I didn't yet experiment in a VM with this either). So far, for 1903 I did "in-place upgrades" with the CUs integrated to the installer to get the CUs (initially I made the ISO with offline ResetBase but the last time I skipped that there as well). I am not even sure if the host registry entry controls both the online and offline cleanup. So, yeah, I am confused if I should just completely stop using /ResetBase (I don't really need this anymore, those small SSD machines are completely gone and SSDs in general are bigger/cheaper now in general, so this was more of an OCD habit). I read about the "restore .1 state, update, deltacompress" update method above, so it seems logical that I need the .1 state available for CUs. However, I think there should still be a way to delete the states between .1 and the latest. So, instead of disabling resetbase, there should be a registry switch which controls if .1 should be kept by resetbase.
@janos666 Generally, 1903 don't need ResetBase for Cumulative Updates, because they are direct updates to system packages, thus, a normal cleanup image will remove related superseded files however, ResetBase still needed to get rid of superseded components of the other updates (SSU, Flash, .NET), but that will break future CU installations, so it's not reasonable to use the approch i found/find useful with 1903 is to add REG_DWORD SupersededActions 3 (it works even with DisableResetbase 1), it makes CBS delta-compress the superseded components this only work without /ResetBase parameter Code: Dism /Online /Cleanup-Image /StartComponentCleanup
Code: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide\Configuration] "SupersededActions"=dword:00000003 get rid of C:\Windows\WinSxS\Backup folder Code: "DisableComponentBackups"=dword:00000001 get rid of C:\Windows\WinSxS\ManifestCache\ files Code: "DisableManifestCache"=dword:00000001 "TransientManifestCache"=dword:00000001 NTFS compress C:\Windows\Logs\CBS\ files Code: "CBSLogCompress"=dword:00000001 limit (or disable) CBSPersist_*.log Code: "NumCBSPersistLogs"=dword:00000000 these two i'm not sure if they have any effect not to reoffer LCU Code: "LCUReoffer"=dword:00000000 "ReofferUpdate"=dword:00000000
June 26, 2019 – KB4509476 (OS Build 15063.1898) June 26, 2019 – KB4509477 (OS Build 16299.1239) June 26, 2019 – KB4509478 (OS Build 17134.860) June 26, 2019 – KB4509479 (OS Build 17763.593)
The first is only for Holographic devices, the second is for updating the install media (iso:\sources), not superseded by any update, till the next is released.