They do that often, but usually, they slap a "v2", "v3" etc. onto the name. Truly silent updates are the plague.
I doubt it doesn't even matter which one of the 20H2 EPs you integrate (maybe only when the source is higher as the build the EP is from), it's probably only on WU which one gets downloaded. I made 2 19042.487 ISOs, one with the old and one with the new 20H2 EP, installing the first one. EDIT: Installed both and only the edge experience after first logon differs.
After doing some checking around, websites are saying that the first enablement package was released on 6/17 and the second enablement package was released on 8/26. So if I downloaded an enablement package on 6/18 and then on 8/24, both of these are the old one. For reference, here is the file information: 79.4 MB (83,270,970 bytes) SHA1=ef52b309dd25d5b8439145722083f9874a1d4523 <-- Released 6/17 84.7 MB (88,868,862 bytes) SHA1=75cbce76d188e8fdab860946c0131789de35ea64 <-- Released 8/26 And yes, I realize you stated this info earlier, but the dates got me confused a bit. For me, it would be easier if MS had a different KB# for each of the enablement packages, but that's just how I am. I'd like to also point out that the enablement package can be rolled back and then reinstalled.
The first enablement package was v10.0.1.1 The second enablement package was v10.0.1.2 These version numbers are visible when the packages are applied using DISM. I think there may have been an Edge version change in the packages. When I booted a machine with the first enablement package and went to "Edge > Help > About", it quickly downloaded and applied an update to Edge v84.0.522.63 and then it updated a second time to v85.0.564.41. On a machine with the second enablement package installed, the version was v85.0.564.41 with no updating going on.
Adobe Flash Player is not allowed for 19041\2 PPIPro Error: 0x800f081e The specified package is not applicable to this image. Code: Microsoft Windows [版本 10.0.18363.1049] (c) 2019 Microsoft Corporation. 著作權所有，並保留一切權利。 C:\windows\system32>dism /english /image:D: /get-currentedition Deployment Image Servicing and Management tool Version: 10.0.18362.900 Image Version: 10.0.19042.450 Current edition is: Current Edition : PPIPro The operation completed successfully. C:\windows\system32> Code: Microsoft Windows [版本 10.0.18363.1049] (c) 2019 Microsoft Corporation. 著作權所有，並保留一切權利。 C:\windows\system32>dism /english /image:D: /add-package:Z:\Windows10.0-KB4561600-x64.cab Deployment Image Servicing and Management tool Version: 10.0.18362.900 Image Version: 10.0.19042.450 Processing 1 of 1 - Adding package Package_for_KB4561600~31bf3856ad364e35~amd64~~10.0.1.1 [==========================100.0%==========================] Error: 0x800f081e The specified package is not applicable to this image. The DISM log file can be found at C:\windows\Logs\DISM\dism.log C:\windows\system32>
Using the 'install .cab updates from context menu' reg file I installed the new enablement package on a system with the old one already installed and it does install and ask for a reboot.
Windows Update doesn't re-offer the new one when the old one is already installed, the only difference is edge version installed by it and the first experience of how edge is promoted.
When you installed the second enablement package, it probably didn't effect the Windows 10 version/build number. It stayed at 19042.487. But if you uninstall the first enablement package, it decrements the number back to 19041.487. Then, if you install the second enablement package, it increments the version back to 19042.487 again. I think that all these actions require a reboot. Deconstruction of the cab files from each package shows that the bulk of the changes are in the "microsoftedgestandaloneinstaller.exe" file. The properties of that file don't immediately reveal a version number. Without analysis (or installation) of the .exe file, it's hard to tell what version of Edge is installed. I uninstalled (rolled back) the first package and then reinstalled the second one. I'm at 19042.487. It's working fine, but I'm not sure about all the changes the package makes.
I'm not sure either. I only posted above to mention the reboot it asked for. That implies that something in memory changed but certainly does not guarantee it. I knew about the edge version, didn't notice the change in edge promotion. On that topic I have had a few installs with the new Edge integrated tell me that I should try the new Edge, I hope they iron that out with a simple test that suppresses that promotion if it is already installed.
No, it's just that EP package demand restart, regardless Code: <package identifier="Microsoft-Windows-20H2Enablement-Payload" releaseType="Feature Pack" restart="required">
Quick questions, which should I use : whdownloader or https://forums.mydigitallife.net/th...-17763-xxx-pc-rs5.77945/page-216#post-1490183 this one here ? should i combine them together ? I am creating 2019 LTSC ISO with the latest updates. Thanks
Wouldn't recommend installing this for those on Coffee Lake and above if you care about performance and correct uncore/ring multipliers. If the 906EA microcode is indeed CA, it is plagued by multiple performance issues and lowered default/stock multi for the uncore. if it's B4, it's OK. Tested on my 8700K since motherboard vendors are already on the D6-DE microcode for the platform, and basically B4 was the last one that can be deemed "normal". Intel truly messed up with its security holes.
You should still give it a shot, you can delete the file if it's that bad, just make sure you benchmark before&after. My post was really short and your mileage may vary, especially on you 10 core CPU. Even on my 8700K, the new microcodes are basically just shaving performance in benchmarks (let's say Cinebench R15 scores of 1460/205 when the 8700K launched, at stock, to 1455/197 in the better, 2019 era of microcodes, to 1410/194 with the 2020 ucodes). Even when OCed it will still lose some performance. In games though, there's no effect whatsoever, but again, with a 2080S, YMMV. Plus, CML has some of the bugs fixed in silicon, so who knows, and Intel surely doesn't care about Coffee Lake S or R as much now, although all of these CPUs are 14nm Skylake successors basically, so yeah, they will be quite similar.