Small update to hotfix-list out. Thanks to pointzero who found the mistake in 2615128 (I forgot to update the version of shell).
KB958488 definitely shouldn't be required, not sure why it showed up in Windowsupdate for you but then again, KB947821 has to be useful for something?! As for the rest of them, some of the other KB9x updates may be redundant, it seems strange Microsoft didn't include some of them in Service Pack 1 or at least release newer SP1 pack versions. Either way, almost all of the updates are useless for most people, maybe the server specific updates in one download file, and the new valid Win 7 updates in another? or at least, some variation thereof?
I removed the service "Offline" in windows 7 if I don't install the update KB2610379-v2 that includes the file "shell32.dll" (version of 21864) it's not a problem? if I install the KB2615128-v3 and the version of shell32.dll is 21869 thanks
The files in 958488 are versioned 6.2.7600.16513 whereas for SP1 they are versioned 6.2.7601.17514. They are located in the WinSxS folder, since the files in the system32 folder are versioned 4.0.40305.0 with SP1. I believe it tries to install because its detecting that its newer, 4.0.40305.0 --> 6.2.7600.16513, and that its not detecting the 6.2.7601.17514 versioned files. I don't know why the filenames are like that, since 4.0.40305.0 and 6.2.7601.17514 are both part of SP1, but in any case, the 6.2.7600.16513 KB958488 files are outdated! The separate folder for those updates to be added to the repository is exactly what I meant thought it would come in handy!
The version of SP1 is not 6.2.7601.17514 it is 6.1.7601.17514, maybe that's the problem. The version 4.xxx could represent .Net 4 updates. Anyway, I checked the DVDs which have 958488 included and saw: They all have .Net 4 preinstalled. MS installed 958488 before SP1. The files in the system32 dir are the files from SP1 (not the ones from 958488) I also checked the registry changes defined in 958488 on an clean installation (no updates installed) all entries are already there. I additionally checked the .Net 4 installer for Server Core, which is designed for SP1 only. I thought 9584488 could be missing, but it also installs the 958488. I don't know why. That will remain one of MS's secrets. I also tried to reproduce the "update" is missing popup for 958488, can't! (If somebody could, please inform!) So 958488 applies, but does nothing if SP1 is installed. Therefore, I think it is save to declare 958488 as an update for RTM. By the way, the version number of an update is not a sufficient condition. It's only an indication. MS Agent has 6.1.7600.16426 and most additions have a "7600" version too.
Thats exactly what I was thinking. Don't know why there is this odd version numbering (I think there's other files like this too), not to mention the 7.1.7601.x file numbering!
Hey burfadel, Windows Updates V23c: with the online changed to offline as per your instructions earlier in this thread works beautifully integrating SoLor's repository into my sysprepped Windows 7 Ultimate x64 image-very nice!
Thanks I just started on the integration feature, its going to be a little more advanced than just a simple reference change (which is why I haven't yet included it). Can't give an ETA on a test version date, I'm working on it bit by bit It will work on an extracted iso (not mounted), and will: - Automatically mount the Install.wim - Ask which index to process (or you can select to process all...) - Process - Unmount - Mount, process, and unmount boot.wim if answered yes to the question of whether you want them processed too, upon which the WinPE index and Setup is also updated using the same lists. This would be done before integrating Install.wim. Many of the updates aren't applicable, which won't matter, DISM will just skip them (and show an error line at the end of the list for each update that got skipped). Looks a little messy on screen, but thats all - Update the setup servicing stack files in the sources folder (not the WIM files which don't update, which is known) - Able to integrate x86 Windows on x64 and vice versa.
Anyone know why DISM cannot remove KB2545698 even though it is there when I do /get-packages? I can install it with no errors, but I can't remove it. This is what is listed in my offline image and I wanted to remove the older version: Code: Package_for_KB2545698_BF~31bf3856ad364e35~x86~~6.1.1.3 Uninstall Pending Package_for_KB2545698_BF~31bf3856ad364e35~x86~~6.1.1.5 Install Pending Package_for_KB2545698~31bf3856ad364e35~x86~~6.1.1.3 Uninstall Pending Package_for_KB2545698~31bf3856ad364e35~x86~~6.1.1.5 Install Pending I changed burf'S update command to /remove-package and removal worked on all of the 21 fixes that were replaced in solor's kb000000 01.11 version. The above fix was the only one still in the wim. I then integrated the 30 new fixes from 01.16 and basically ended up with the same wim as if I had done a vanilla_SP1.wim + solor's kb000000 01.16 version except for the Uninstall Pending entries. I wanted to save the time integrating the 255 fixes that were identical in the 01.11 and 01.16 hotpacks. It did make a big difference in the time saved. Code: Deployment Image Servicing and Management tool Version: 6.1.7600.16385 Image Version: 6.1.7601.17514 Processing 1 of 2 - The package Package_for_KB2545698_BF is not present in the image. Processing 2 of 2 - The package Package_for_KB2545698 is not present in the image. Al