Remove / Re-add the updates so the Dism packages issue only occur after using Wim-Integration.cmd? or even without it?
I did try removal, but got access denied so I think the problem was caused by me. For some reason after applying the wim and verifying with WU, I ended up with WU offering a bunch of old updates. Normally I have WU set to inform only, but when I quit for the evening the system started installing updates during shutdown and I immediately killed it, which most likely corrupted something. The system booted fine the next day and I thought all was fine. Anyway, the Wim-Integration.cmd works as advertised because I did not have any package problems this time around after reapplying the same image, but I am still being offered old updates and they are all superseded. My previous build with all updates through Dec gave me a clean WU. Basically the packages between the Dec. and Apr. builds are the same except for LCU and .NET CU. Are the old updates being offered related to the ESU Suppressor when integrating embedded updates into the image? Spoiler Edit: I do see another problem though. I don't recall this being there when I checked the final sysprep before doing the wimlib capture and running Wim-Integration.cmd. Code: Checking Component Store (f) CSI Manifest and S256H Do Not Match 0x00000000 winsxs\Manifests\amd64_microsoft-windows-s..edsecurityupdatesai_31bf3856ad364e35_6.3.9603.30600_none_6022b34506a8b67a.manifest amd64_microsoft-windows-s..edsecurityupdatesai_31bf3856ad364e35_6.3.9603.30600_none_6022b34506a8b67a Summary: Seconds executed: 262 Found 1 errors CSI Manifest and S256H Do Not Match Total count: 1 Unavailable repair files: winsxs\manifests\amd64_microsoft-windows-s..edsecurityupdatesai_31bf3856ad364e35_6.3.9603.30600_none_6022b34506a8b67a.manifest Code: [SR] Cannot verify component files for Microsoft-Windows-SLC-Component-ExtendedSecurityUpdatesAI, Version = 6.3.9603.30600, pA = PROCESSOR_ARCHITECTURE_AMD64 (9), Culture neutral, VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type neutral, TypeName neutral, PublicKey neutral, manifest is damaged (TRUE)
If you're worried about OS corruption, take a look at response #7311 (from the link listed below) and perform a little maintenance on your hard disk OS. Just don't be online when you don't need to during some of the processes listed. https://forums.mydigitallife.net/th...dates-eligibility.80606/page-366#post-1784697 Be mindful to check your Power Settings in the Control Panel, that you don't have your computer set to either sleep or hibernate for at least 2 hours. Take care of this first before continuing with re-installs of "repeat updates" - do the "sfc /scannow" in a Command Prompt window opened as "Run As Administrator". Try this before making use of the System Update Readiness Tool for repairing misconfigurations. Then re-install the components listed below in their listed order. I'll quote you something from response #7335 when you're installing security updates on Windows, for your own conditioning: "As a helpful monitoring of this process, open the Windows Task Manager (CTRL+ALT+DEL once, then select the very bottom option "Start Task Manager") => Press the "Show processes from all users" button. As you observe on the Task Manager, you will see the process "TrustedInstaller.exe" use up the CPU resources constantly. This may continue for 10-15 minutes until the "System Idle Process" task has CPU resources again at a constant 99%. You can safely restart your PC system now (all necessary pre-restart configurations have been completed). You may observe the restart process for your own leisure. The configurations should proceed into restarting. Once the pre-logon wallpaper appears the post-installation configurations may continue until achieving 100%. Even after the desktop reloads, you still best wait until the post-installation configurations complete another 10-15 minutes (you may reopen the Windows Task Manager to monitor this progress). It is important that you let Windows complete this process, as a misconfigured OS can occur when impatience is a factor (it will cost you time later to repair these instabilities)." Ok, well (here we go)... For starters, if you've chosen to not be networked with any Windows 10 computers, you won't need the KB3118401 update. Choose to Hide it before continuing. Get these original Windows 7 updates and security updates installed before concerning yourself about the .NET Frameworks ones. Some of these updates I experienced getting requested once after installing the very last Monthly Quality Rollup Preview (KB4539061) from February 2020: Critical Update (KB2676562) - Hacker Compromise - May 12 Security Update (KB3123479) - MS Root Certificate SHA-1 Hashing Algorithm Patch - January 16 It happens sometimes, that a recent Security Monthly Quality Rollup in a Windows OS supported series (eg. Windows 7 ESU) will change one or more components to an extent that the original updates/hotfixes for those components need to be re-installed. Critical Update (KB2813347) - Remote Desktop Client v6-1, v7-0 and v7-1 Hacker Compromise - April 13 The changes from installing Security Monthly Quality Rollup KB5017361 from 2023-02 (February 2023) may have affected these components: Update (KB2846960) - (Windows/IE10) Explorer Resource Error With SharePoint Document Library Hotfix - September 13 Security Update (KB3076949) - WebDAV SSL v2-0 Security Feature Bypass (Info Disclosure) Patch - August 15 Security Update x64 (KB3124280) - WebDAV EOP Vulnerability Patch - February 16 (It's clear to me that you're running a 64-bit version of Windows 7). (Which Cumulative Security Update for Windows 7 was your Windows Update client requesting..? Was it this one?) Cumulative Security Update (KB3185319) - IE11 FINAL Update - September 16 Cumulative Security Update (KB4507434) - Update (Supersedes ALL) - July 19 Cumulative Security Update (KB4534251) - IE11 Security Vulnerabilities Resolution FINAL - January 20 Okay, now the .NET Framework updates... .NET v3.5.1: (The file sizes fit the WU request) Security & Quality Rollup (KB5013637) - NET v3-5-1 Framework DoS Patch + APIs Crash Fix - May 22 (Included in 2022-10 KB5018547 .NET Frameworks Rollup Bundle) Security & Quality Rollup (KB5020861) - NET v3-5-1 Restricted Mode XPS File Parsing RCE Patch - December 22 Good luck.
No, not worried. In the past for me, any time WU offered superseded updates after a clean install it was caused by incorrect meta data supplied by Msoft. Some superseded updates had to be kept to satisfy WU which I don't think is the case here. I'm still looking into this and I edited my post above. I hope abbodi1406 can help me resolve this.
So what's the issue exactly? WU offer old updates? or re-offer installed updates? did you use latest fixed BypassESU-v12_u.7z?
A lot of superseded updates offered and the manifest issue. I'll check on the v12 that was used. If I did not use the 12_u version, Do I just remove and then add again?
[QUOTE=" Edit: I do see another problem though. I don't recall this being there when I checked the final sysprep before doing the wimlib capture and running Wim-Integration.cmd. Code: Checking Component Store (f) CSI Manifest and S256H Do Not Match 0x00000000 winsxs\Manifests\amd64_microsoft-windows-s..edsecurityupdatesai_31bf3856ad364e35_6.3.9603.30600_none_6022b34506a8b67a.manifest amd64_microsoft-windows-s..edsecurityupdatesai_31bf3856ad364e35_6.3.9603.30600_none_6022b34506a8b67a Summary: Seconds executed: 262 Found 1 errors CSI Manifest and S256H Do Not Match Total count: 1 Unavailable repair files: winsxs\manifests\amd64_microsoft-windows-s..edsecurityupdatesai_31bf3856ad364e35_6.3.9603.30600_none_6022b34506a8b67a.manifest Code: [SR] Cannot verify component files for Microsoft-Windows-SLC-Component-ExtendedSecurityUpdatesAI, Version = 6.3.9603.30600, pA = PROCESSOR_ARCHITECTURE_AMD64 (9), Culture neutral, VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type neutral, TypeName neutral, PublicKey neutral, manifest is damaged (TRUE) [/QUOTE] The .manifest file reported as "Unavailable repair files" is located in the "bin" folder in either of the BypassESU-v12 setup folder, or the BypassESU-v12_u setup folder (you can't miss it, it's right at the top.) You've already attempted to copy this .manifest file into the C:\Windows\winsxs\manifests\ folder, right? (You may need a third party program with Administrator privileges to assist you in this, as this folder is protected from tampering with.I can't say whether PowerRun may get you success there.) amd64_microsoft-windows-s..edsecurityupdatesai_31bf3856ad364e35_6.3.9603.30600_none_6022b34506a8b67a.manifest Then you may try again to uninstall the BypassESU, and then re-install it later. You also attempted to re-install some of those superseded updates, or none of them (with half of them requested, their original installations became corrupted or misconfigured after installing the February 2023 Security Monthly Quality Rollup)? With superseded updates, sometimes it is necessary to have a record of installing that original update in the Windows Update History, or to still pertain its installation files in the System Update cache. I say simply re-install them (if Windows Update won't help you download and install those components, go to the Microsoft Update Catalog and download the .MSU file packages for installing individually by referencing their KB numbers in the Search bar.) Else, you will need to correct a possible installer or Windows Update corruption in your DataStore records with the System Update Readiness Tool.
Okay, I finally have a clean install after starting over. Blame it all on me. My posts above were caused by the following: 1. Not running ESU-Patcher before checking for updates resulted in WU offering a bunch of old updates. 2. Killing updates during shutdown corrupted something in the system and caused bad packages.txt running Dism on reboot. Since WU was not set to only inform, the bogus updates related to the missing ESU-Patch started to auto-install. 3. Not running the latest v12 Bypass before installing any embedded updates during sysprep resulted in incorrect hash values which led to the manifest issue in the captured image. After avoiding my previous mistakes, I have a clean install now with WU only offering 2 updates Spoiler
Hello, everyone. I want to apologize right away for my English. I will use the translator to ask my question. I have installed the original Microsoft Windows 7 with SP1 Updated 12.05.2011 and I would like to install all the latest updates on it. At first, I used DrWindows_Updatepack_Win7_Jan23 but then I found out that: 1. If you have regular Windows 7, only updates up to and including January 2020 will be installed 2. If you have a licensed Windows 7 with an Extended Security Update (ESU) subscription, all updates included in the package will be installed. Also, all updates will be installed if you have self-configured your ESU update restrictions bypassed. Can you please tell me how I can get updates for my Windows7? I can't understand what step by step to do with BypassESU-v12_u.7z to get all updates.
The best way to update your computer from the original SP1 version is to use the Simplix Pack. Quote from Simplix Pack first page: "Set allows you to update Windows 7 SP1 (x86 x64) and Server 2008 R2 SP1 live operating systems, as well as to integrate the updates in the distribution (Install.wim). Can be installed on any language. Includes all critical, recommended, and security updates and updates for all versions of Internet Explorer."
Although this is another good method of updating ISOs/installs but i never like to spam in others threads.
First of all let me say that I have a great amount of respect for you, having seen your very helpful posts in a great many threads and all of the people you have helped in the past, but lately you seem to be over reacting to helpful, but slightly off topic posts. I fully understand that this is the ESU Bypass forum and that almost all posts should be confined to that, but I think it's much better to try to answer someone's question and point them in the right direction and perhaps the right forum, or tool. The ESU Bypass is a wonderful tool which I have used many times for month to month updates (and a great credit to the developers and testers), but for accomplishing one off updates from older installs the Simplix Pack is (in my opinion) easier to use. After all isn't the entire purpose of threads, tools and forums to help people solve problems they may not otherwise be able to on their own.
It always has been my mo to not promote/spam "my" "solutions" in others threads. Over reacting as in?
Perhaps it's just a misunderstanding as to terms, and it wouldn't have bothered my so much if you had said something to the effect that you would prefer other solutions not to be mentioned in this thread, but the post is hardly Spam see the definition below. Spam is any unsolicited communication sent in bulk. Usually sent via email, spam is also distributed through text messages (SMS), social media, or phone calls. Spam messages often come in the form of harmless (though annoying) promotional emails. But sometimes spam is a fraudulent or malicious scam
OK, then let me apologize for mentioning Simplix in this thread. EDIT: Removed smiley waving face (as caption said bye, and I just meant all's OK now)
OK, since my previous post seems to have been deleted, perhaps because it was only a "thank you" message, I'm going to ask about this strange anomaly that happened on my Win7 Pro (x64):- I had been using the ESU Bypass successfully for ages with no problems I had .NET versions 2.0, 3.0, 3.5, 4.6.2, 4.7, 4.71, 4.72, 4.8 installed and I manually updated accordingly. Then since February using the Stand Alone .NET Bypass I found that Control Panel shows ALL my .NET installation dates as 22nd Feb 2023 and all as "NET 4.8". (screenshots taken today attached). Should I just leave things as they are? Any advice would be gratefully received.