Just to clarify: did you mean that I can apply a consumer-edition *.svf file to a business-edition *.iso file and vice versa without problems?
Yes I know it. But this is not something I wanted to make sure of. I'm specifically asking about the new MSDN ISOs. Also I was not connected to the Internet at the time of enabling DotNet 3.5. Note that /LimitAccess switch as well.
Yes. This sounds logical. So WU should offer the update if I used if /Source and /LimitAccess I don't have that test install but should test this again. Thanks for your help.
Not bad if download link(s) could be obtained... So links should be in the log file after running Code: get-WindowsUpdateLog -verbose ?
WU downloads the same microsoft-windows-netfx3-ondemand-package~31bf3856ad364e35~amd64~~.cab file present in \sources\sxs\. At least their both digital signature dates are the same (Friday, December 6, 2019 6:38:17 PM.) The same microsoft-windows-netfx3-ondemand-package~31bf3856ad364e35~amd64~~.cab is also on UUP. So I assume WU does not download something newer/different from what's currently available in \sources\sxs\. Also WU did not offer KB4552925, but instead re-ioffered CU KB4556803. Let's see then.
I see. OK. I cannot even hope this M$€ even think about fixing this. And I guess this happens even if W10UI used. (I believe I raised the concern before) Probably the best option if using W10UI without including any DotNet update and then installing the latest DotNet CU manually after installing/configuring Windows.
There is nothing to fix, it's normal, after enabling a feature, the latest CU will be re-downloaded (partially) to update the added components. W10UI integrates the updates, (runs cleanup or resetbase, if selected) and next enables the feature and re-integrates the dotnetcu and normal cu afterwards. And WU won't redownload anything after installation of the created ISO.
Here is a reason that can explain many of the reports of updates being re-offered out of the (seemingly) blue: https://forums.mydigitallife.net/th...prise-n-ltsc-2019.76325/page-267#post-1597313 https://forums.mydigitallife.net/th...prise-n-ltsc-2019.76325/page-267#post-1597314
Interesting. So, maybe there's actually nothing inside KB4552925 that could apply to DotNet3.5? Wu does not download KB4552925, if it already integraded. Also after enabling DotNet 3.5. WU downloads the CU KB4556803 to update DotNet 3.5 components, that we just enabled. Well I'm not insisting on this anyway. Think I understood what's going on.
Seems that dotnetfx48 is already uptodate in this scenario, dotnetfx35 seems to only need to be updated by the normal CU
Adding a desktop experience from one major build to another major build, which does not have it natively, will become a frankenbuild. Server 2019 (17763.xxx) is the current server version with desktop experience.