Hello all, Is there any Dynamic Updates (which should be copied into "sources" folder of ISO) for Windows 8.1 with Update 3 ISOs? I didn't find any info on it, neither download links. Would be appreciated. Regards, Nima
I have run again the “InSpectre” app and it reports that my system is NOT Spectre protected! These patches/updates intel/microsoft microcodes have been applied for a year now in every monthly CU. What else could it need?
Yes read it later trying to see what was missing. Shame since for the Meltdown exploitation fixes are available.
Yes, almost some updates will not be applicable to embedded and embedded will have few specific updates it's hard to tell without trying all WHDownloader updates, then checking Windows Update
Not sure if this is news here, but I have just spent one full day trying to figure out why .NET Framework patches and their supersedence were behaving differently on only one out of 6 test Windows 2012 R2 servers which I use for various purposes, Windows Update testing being only one of them. Specifically, with all rollup patches up to date: - In WSUS, 5 servers of 6 were showing KB4055271 2018-01 Security Only Update for .NET Framework as installed, while the other one was showing as not installed and not applicable. - With only 2019-02 KB4487080 installed, superseded patches for .NET Framework 2017-11 and 2017-09 were showing as required, but on only one server, the same one with the issue above. To clarify, the Security Only patch was not manually installed, but due to interactions between various .NET Framework patches (bundles), WSUS detection shows a number of Security Only patches for .NET Framework as installed, even if they were never installed in fact. All the issues mentioned show only for the .NET Framework updates, while none is an issue for the regular Windows Updates and rollups. After many hours of experimentation, I figured out that the issue was the missing compatibility registry key known from the times of the first Spectre/Meltdown updates RegKey="HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\QualityCompat" Value Name ="cadca5fe-87d3-4b96-b7fb-a231484277cc" Type="REG_DWORD" Data="0x00000000" While Microsoft claims that this key is no longer required, this seems to be true only for the regular Windows Updates, while removing this requirement was missed in relation to the .NET Framework patches. Although I have not tested on Windows 8.1, I am convinced that the behaviour should be the same, at least for the 64-bit versions. Steps to reproduce: - Uninstall all superseded .NET Framework patches - be aware that the numbers are different than the bundle as a whole. Keep the most current update only, 2019-02. - Remove the registry key above if it exists. - Run Windows Update and see what happens. It should offer the 2017-09 as Security and 2017-11 as Update (Recommended), although they are superseded. - Enter the registry key as above. - Run Windows Update. This time the superseded patches are no longer offered. Note: This behaviour was noticed on machines with .NET Framework 4.5.2, but chances are that it is the same on machines with 4.6.x/4.7.x
This attribute file is used for Windows 10 upgrades (from build to another, not from Win 7/8.1) yep, 4 possible formats for PonchAllow, i think any of them suffice for 64-bit OS block value supposedly ment for AV products that was not yet compatible
WSUS probably has a special relation rule between Monthly Rollup group and Security-Only group (no direct supersedence metadata, but if rollup is installed the corresponding SO and IE CU become not needed) i think they cannot add KB4483187 to the Rollup supersedence chain because of that actually, since the evolve of IE11 and KB2919355 era, IE CU became not-possible to be fully superseded on CBS level, and metadata is require to supersede it through WU that's why KB3185319 (latest IE CU before rollup series) was requested in WU if active rollup is preview https://forums.mydigitallife.net/posts/1347280/
KB4483187 was released as a one off patch to fix a specific issue in December 2018. It is still offered by Windows Update and not only by WSUS. I am not sure why it cannot be superseded in metadata by the monthly rollup on the regular WU, which would apply to WSUS as well. They both use the same metadata which is the one in the catalog as well. The difference is that WSUS gets extra updates sometimes, like the recent timezone update rollups or the Security-Only updates. In other cases, mostly for Windows 10, WSUS does not get all the second updates ("preview") for the month. What you say suggests that if the monthly rollup metadata supersedes KB4483187, then this may break the Security-Only (for IE) supersedence chain. It is possible, and being affirmed by you, I would say very likely. While KB3185319 is offered and installed if the latest cumulative update is the preview for the month, after installing the regular cumulative update for the month and running StartComponentCleanup, KB3185319 is uninstalled. And it repeats again next month and again and again. Talking about how consistent WU is. As a matter of fact, I know some places where they apply both regular and Security-Only updates every month, while letting Windows CBS to sort it out. This is in fact the default out-of-the-box behaviour for WSUS which has Security Updates and Critical Updates set to install automatically without prior approval. I don't particularly have an opinion about this method and I would rather apply only the regular updates, same which come on WU. I only mentioned that it happens, without endorsing that approach.