WinSxS LCU Purge Constraints

Short answer — it depends on whether you use /ResetBase, but even without it, you're shortening your rollback window significantly.

Here's what's actually going on under the hood. The WinSxS component store keeps superseded component versions around specifically so the OS can reverse-apply a cumulative update if needed. Windows has a built-in scheduled task (Microsoft\Windows\Servicing\StartComponentCleanup) that does this cleanup automatically, but it waits 30 days after a component is superseded before removing the old version — that 30-day buffer is your rollback safety net.

When an IT tech runs DISM /Online /Cleanup-Image /StartComponentCleanup manually, it performs the same cleanup but skips that 30-day grace period entirely. Superseded components get purged right away. So if last month's LCU was superseded by this month's, those old component payloads are gone — and with them, the ability to cleanly uninstall the current LCU through wusa /uninstall or Settings > Update History.

If you add /ResetBase to that command, it's even more aggressive — every currently installed update becomes permanently baked into the baseline. No existing update can be uninstalled at all after that.

For an IT environment where you might need to pull back a bad patch, the safer approach is to just let the scheduled task handle cleanup on its own 30-day cycle. That gives you a full month to catch regressions before the rollback path disappears. If disk pressure is the concern, run DISM /Online /Cleanup-Image /AnalyzeComponentStore first — it'll tell you whether cleanup is actually recommended before you commit to it.