WU is seriously f*cked up... I just got KB947821 (may 2012) to install on a os that had it pre-integrated. It happened once this month's updates were installed. Very weird...
KB947821 isn't an update, it's a local system update repository consistency check tool disguised as an update. You actually need to run it separately, its not something that can work by being integrated. Having it 'integrated' just gives the illusion that it has already been run. It can also be run as many times as you 'like', since it is a system check tool and not an update. It will also take some time to run. It will appear 'stalled', but that is just the point where the tool is running. If you have installed all hotfixes etc allow for (honestly no idea) time, maybe half an hour?
burfadel, I really don't understand what you're saying... I always integrated it to an offline image, and always WU didn't complain about it. Now it's the first time. Also it's the first time an update for VC2008 SP1 came up ( an update from june, I've used ricktendo's installer without WU problems 'till this month check - a couple of days ago that june update wasn't visible in WU). Something appears to be wrong with WU these days...
What I'm saying is KB947821 shouldn't be integrated, in the sense that integrating it just means it won't ever have actually run. If you run KB947821 it may very well fix the problem locally which is causing the updates to show anyway! What do you mean for VC2008 SP1? The whole program or the runtime? Either way, that is also something which may be fixed with KB947821.
Ok, so you're saying that KB947821 shouldn't be integrated to an offline image? It's the first time I've heard about this... or is it just your opinion? I use Win Toolkit to integrate updates to an offline image, I can easily move it to the silent installer section and it will run during first boot. However, I don't understand the reason, since DISM ALWAYS ''integrated'' it fine to an offline image. So you're absolutely sure that KB947821 it's a tool that NEEDS a live system to run on?
No, it is not his opinion only. This update is not an update as such. This "update" should be run manually every time after all updates or hotfixes got installed. This also means if you integrate updates and hotfixes this so-called update should be run as run-once or something.
This is what M$ says: The System Update Readiness Tool is used to resolve inconsistencies in file data or registry data. When file data or registry data is inconsistent, your computer may be unable to install updates from Windows Update. After the System Update Readiness Tool is installed, you can install updates from Windows Update on your computer. The System Update Readiness Tool scans for inconsistencies in your computer as it is being installed. It typically takes less than 15 minutes to run the scan. However, the tool might take significantly longer on some computers. Although the progress bar may seem to stop, the scan is still running and you should not cancel the update. It fixes issues in the Windows Servicing Store for future updates or service packs as well software which will probably be prevented from being installed without this kind of update.
I have 14/03/2012 07:59 633,534 Windows6.1-KB999159-x86.msu <assemblyIdentity name="Microsoft-Windows-DriverFrameworks-UserMode" version="6.1.7601.22039" processorArchitecture="x86" language="neutral" buildType="release" publicKeyToken="31bf3856ad364e35" versionScope="nonSxS" /> <assemblyIdentity name="Microsoft-Windows-DriverFrameworks-UserMode.Resources" version="6.1.7601.22039" processorArchitecture="x86" language="en-US" buildType="release" publicKeyToken="31bf3856ad364e35" versionScope="nonSxS" /> In last update 27/07/2012 20:53 1,065,217 Windows6.1-KB2685813-x86.msu <assemblyIdentity name="Microsoft-Windows-DriverFrameworks-UserMode" version="6.1.7601.22002" processorArchitecture="x86" language="neutral" buildType="release" publicKeyToken="31bf3856ad364e35" versionScope="nonSxS" /> <assemblyIdentity name="Microsoft-Windows-DriverFrameworks-UserMode.Resources" version="6.1.7601.22002" processorArchitecture="x86" language="en-US" buildType="release" publicKeyToken="31bf3856ad364e35" versionScope="nonSxS" /> Which is 'better' ?
Definitely the last one (KB2685813). Despite the update version being lesser than KB999159, the files the update updates are actually newer. These are Windows 8 components for Windows 7. KB999159 is basically Windows 8 RP 8400, and KB2685813 is Windows 8 RTM 9200. The same goes with KB999158 and KB2685811, KB2685811 is the one that should be used. In actual fact, KB2685811 and KB2685813 (and the superseded KB999158 and KB999159) may be separate updates, but they should both be installed together. As KB999158 and KB999159 are superseded they are no longer required. They MUST be uninstalled before installing KB2685811 and KB2685813.
i ignored 2647753-v3 if somebody likes this faulty update ask. i think it was the publishing of 2647753-v3 and 2712808 that causes the problems on x64. maybe also 2713128 solves the problem. (2712808 and 2713128 supersed parts of 2647753) I had no problems on my x64 computers using 2647753-v2 which was installed some months ago.
new is v3 (sometimes i forget the version numbering) paced in the "OLD for BAD" folder on my server interesting 2578113 -v2: for terminal server amd64_microsoft-windows-tsproxy-edgeadapter_31bf3856ad364e35_6.1.7601.22024_none_9caf238bfc7ac045.manifest amd64_microsoft-windows-tsproxy-edgeadapter_31bf3856ad364e35_6.1.7601.17866_none_9bfc6f82e37b8fab.manifest -v1: for cluster server amd64_microsoft-windows-f..overcluster-clusres_31bf3856ad364e35_6.1.7601.21772_none_1f47632fcceae532.manifest never saw a update change like that. maybe thats the reason MS removed 2578113-v2 from the hotfix server 2578113-v1 is superseded with 2685891 so it is not needed anyway.
Komm, you forgot the KB2703157 (IE8) in the "removed" liste from your changelog and remove it in the IE8 folder