MicrosoftMaliha_Qureshi
- highest LCU is installed (e.g. KB5041178 currently)
- highest baseline LCU is staged or installed (KB5038603 currently)
- run Windows Update Cleanup (or Deployment Image Servicing and Management tool cleanup)
- RTM packages and lowest baseline LCU (KB5038575 currently) are removed
- an LCU Reservicing operation is needed (e.g. installed a FOD or enabled a feature)
- highest LCU reinstallation will take a long time and resources, trying to generate files for all baseline LCUs
- it fail to generate the lowest baseline LCU files, because baseline RTM files are removed
- highest LCU reinstallation will still succeed, because it's highest baseline LCU still staged
why does it need to generate files for unneeded LCU? and why it does not use the reverse deltas to generate them?
We've been having a lot of problems with this feature when language packs are involved. Our base image is the 2033 ESD image.
We follow the instructions here:
to apply the checkpoint update along with the January Update. They both succeed, but when the system is rebooted, it (sometimes) stays at the 2033 build that was part of the ESD file, rather than go to the 2894 build. I'd say it's about a 33% chance of succeeding. Had the MSU's failed to inject, I could understand why it would stay on 2033, but it's actually succeeding.
At this point, there's nothing we can do to update the machine if it's stuck at 2033, with Windows Update, MSU, checkpoints - anything - the CBS store is corrupt.
We're hoping this feature can be removed/reverted until Microsoft tests it more as all it is doing is causing headaches and systems that simply cannot patch even when they have direct Windows Update access.
Other things that could be done:
Even on brand new NVMe-based hardware, injecting two MSU files offline takes an exceptional amount of time. The servicing stack is really showing its age and probably needs an overhaul at some point.
