Oh, thanks, I missed the "N.1" WinRE image in the list (indeed, it only appears after install.wim is mounted, which makes total sense.Hi,
add monthly cumulative updates to it, same like to Install.wim. You can easily chain that after loading the target install.wim edition, go to the Apply page -
Reapply - Integrate Updates - tick WinRE as well.
You can also see specific WinRE updates here, those starting with "Safe OS Dynamic Update".
Navigate older pages to see how often.
But this is more complex, it can be superseded by a newer Cumulative update, so use only if necessary.
I recommend adding cumulative updates, and in case of urgent fixes before the next cumulative update, add SafeOS update to it.
If anyone knows more on the correct practices regarding the SafeOS updates, feel free to chime in - I might add them to the update list if deemed often necessary.
Regarding the versioning.
After loading an image edition, tool will list found WinRE under it (for deployed Windows e.g. C:\Windows it's always listed if found).
Choose New Session in the Image toolbar (or restart the tool) and load the edition from newly listed WinRE.
After loading look in the status bar lower-right of it for the version info, should be the same as the install.wim one if patched.
CUs have their own editions, or more correctly the base versions. You can find out which by reading it from the cumulative update version.So then the question is, how do cumulative updates work? Does a cumulative update only apply on top of "its own" edition (like 22H2), or on top of any edition, or something in between?
Question still open: is it better to skip CUs for WinRE and use only SafeOS updates.In other words, I'm editing a Windows 10 22H2 installation image (10.0.19045.2965), but the non-patched Winre.wim shows as 20H1 (10.0.19041.1). Is it safe to apply the same cumulative update to the Winre.wim as I would to the main image (i.e. tick the "reapply" checkbox), or do I have to edit Winre.wim in its own session such that NTLite would pick the "right" cumulative?
Sorry, I'm confused nowCUs have their own editions, or more correctly the base versions. You can find out which by reading it from the cumulative update version.
e.g. 19041, 22621, 26100 etc.
CUs are shared only between the same-basis editions which get converted into the higher one with a Feature Enablement package, like 19041->19045.
To not overcomplicate things, consider each Windows version to have their own CU, not each edition.
Question still open: is it better to skip CUs for WinRE and use only SafeOS updates.
Logic dictates that MS would not be releasing these SafeOS updates for no reason, it's just puzzling are they valuable only until CU for that month is out, or CUs block the integration of those SafeOS updates and do not contain the necessary fixes.
It is equally confusing why would they skip merging SafeOS fixes into the next CU, why allow Boot.wim updating with a CU, but not WinRE.
My recommendation for now is to integrate SafeOS updates to WinRE only - unknown if CUs have those fixes.
Or keep your machine disconnected while installing, then you don't have to update WinRE.wim/Boot.wim at all.
As I just said, I *don't* want it to be strictly offline, on the opposite, I want it to be *strictly online* and that's why I want to follow the best practice in applying all applicable updates to it.If you want it to be strictly offline - get rid of all network drivers, protocols, and disable remaining network services. On top of that get rid of Non-UEFI Boot Manager if possible. I customize Marcium Reflect WinRE.wim that way to keep it fully offline.
No idea.I take it LCU and SafeOS update different files. Why would there be any conflict merging both even if MS isn't doing it in their official ISO's? Does SafeOS even update Boot Manager? That's very important for WinRE.wim. To this day, Black Lotus vulnerability has not been fully patched because of a 2011 MS certificate, removal of which is needed, but such removal messes up many machines, including the ones with common TPM 2.0. August 2024 LCU tried to remove that 2011 MS certificate, but ended up reverting changes due to BitLocker breakage.
Which means that the cumulative update has to be applied to the WinRE image, and it should be done *before* the LCU is applied.Starting in February 2021, the latest cumulative update and servicing stack update will be combined and distributed in the Microsoft Update Catalog as a new combined cumulative update. For Steps 1, 9, and 18 that require the servicing stack update for updating the installation media, you should use the combined cumulative update.
That's simply not true using DISM on a pre-extracted update (update.mum).Win11 24H2 LCU msu is not applicable (actually metadata-skipped) for winre.wim
only the SSU update will be added
Thanks for the feedback.nuhi Okay, so I've found this article:
Update Windows installation media with Dynamic Update
Learn how to acquire and apply Dynamic Update packages to existing Windows images prior to deploymentlearn.microsoft.com
At a first glance, it says that one should not apply the LCU to the WinRE image (the "Add latest cumulative image" row is empty in the first column). However, there is this remark here:
Which means that the cumulative update has to be applied to the WinRE image, and it should be done *before* the LCU is applied.
So, I'm editing Winre.wim in a separate session, adding the LCU (at the time of speaking, this is KB5044273) and the SafeOS dynamic update (which is KB5044615). However, NTLite orders the dynamic update *before* the LCU, causing the LCU to get skpped:
However, if I manually apply the LCU and then, in a separate session, apply the SafeOS Dynamic Update, both updates are applied.
Is this a bug in NTLite, or does this mean that this specific LCU subsumes this specific Dynamic Update?
I just wanted to note that this topic was about Windows 10 22H2, and on this build right now it's exactly the opposite: current SafeOS update refuses to integrate before the CU. So whatever the solution is, it should take into account that it can go both ways.Integrating CU after the SafeOS update works the best, that covers WinPE and all of the CU updates, but SafeOS update must be integrated first as it denies to integrate after the CU.
Will add SafeOS to the update list and keep allowing for WinRE CU integration as well, properly sorted.
This sorting will require a tool update first, and to skip SafeOS update for the install.wim, as it does not deploy to anything except 26100.1.
Must be the Servicing Stack update from the CU package that makes that difference. Thanks for the heads up, will include that in the tests.I just wanted to note that this topic was about Windows 10 22H2, and on this build right now it's exactly the opposite: current SafeOS update refuses to integrate before the CU. So whatever the solution is, it should take into account that it can go both ways.
Yes, I can confirm, it's exactly the way you described. If I extract the SSU cab and queue all of 1) the SSU cab, 2) the SafeOS dynamic update, and 3) the remaining cab from the CU (or even the entire CU *.msu again), integration finishes correctly in this exact order.Must be the Servicing Stack update from the CU package that makes that difference. Thanks for the heads up, will include that in the tests.
SafeOS update should not depend on the cumulative update itself since Microsoft advertises it as independent in the Dynamic Update guidance.
To confirm this, try extracting the SSU CAB update from the CU MSU and add it together with the SafeOS, without the full CU.
Great, will then automate that as well. Adding CU after it will update the rest of the files.Yes, I can confirm, it's exactly the way you described. If I extract the SSU cab and queue all of 1) the SSU cab, 2) the SafeOS dynamic update, and 3) the remaining cab from the CU (or even the entire CU *.msu again), integration finishes correctly in this exact order.
(I did not try to diff the images between this order and the opposite order, though, to see if there were any material differences. Could you give me a hint, how do you diff the images effectively?)
That's simply not true using DISM on a pre-extracted update (update.mum).
I have compared WinRE with and without CU, the difference is huge, files are updated throughout.
Try it - mount WinRE 26100.1 and a copy of the same WinRE after CU (baseline + latest) in another mount dir and compare them.
If your method skips it, let me know how it was tested so that I can confirm on my side and adjust accordingly.
Thanks.
<MSConditionalFeatures>
<ConditionalFeature UpdateAction="Add" FeatureID="CumulativeUpdate_KB5039417" FMID="MSDN">
<Condition Type="PackageAnyVersion" Status="NotInstalled" Name="WinPE-Rejuv-Package~31bf3856ad364e35~amd64~~" />
</ConditionalFeature>
</MSConditionalFeatures>
Someone should ask them why, it looks like an unnecessary limit, not to mention dangerous one not to update with CU after applying a Safe OS update.Yes, using pre-extracted LCU (update.mum) is not blocked for winre.wim
it's only LCU msu specific metadata block
XML:<MSConditionalFeatures> <ConditionalFeature UpdateAction="Add" FeatureID="CumulativeUpdate_KB5039417" FMID="MSDN"> <Condition Type="PackageAnyVersion" Status="NotInstalled" Name="WinPE-Rejuv-Package~31bf3856ad364e35~amd64~~" /> </ConditionalFeature> </MSConditionalFeatures>
you would think they added that condition for a reason
they also unified SafeOS DU package name Package_for_SafeOSDU
2024-10 SafeOS updates for Win10 v1809 and later are also changed to that name (24H2 already had it)