What I meant is: how many hotfixes that are in the zuko bonus pack are in the repo thanks to them being released by MS? 80%, 85%, 90%?
Thats a bit hard to determine since its not known how many of the updates in the list posted on Wzor have been superseded, or how many have been added (both released and non-released hotfixes) to that list. Assuming the list is now around say, 200 updates, it would seem around 50 percent. Taking in to account superseded updates, and that there may be updates that have been superseded by another, and in turn, that update superseded Its probably around 70-75 percent. The remaining 25 percent, and I point out that figure is purely specularity, are the reason why the Zuko bonus packs are appealing. They are the updates that are not available by KB articles, and may never be released to the public in any shape or form (or released later).
And also, since there's no KB article you have no idea at all what is fixed (or broken) by one of these do you?
Thats true, but thats not the purpose of installing the updates the reason behind installing these updates is to be up to date. If you look through the kb articles for these updates you'll find that most of them probably don't directly apply to you anyway... Basically, if there's an update that gives you newer USB related files for example, then at least you know the update is related to USB! KB articles may be incomplete anyway, they often don't describe all the specific changes relating to all the files contained within the update. Think of LDR versions of those updates, they contain all previous changes to the files relating to that update. In that sense, although the update may specifically relate to issue (say) G, it won't give you details of changes A through F. If you install a previous GDR update to C, if you install the new update, G, the files used are then the LDR version and you get the changes A-G anyway! So basically, KB articles are guides so if you have that issue, you can find the update needed to install. Beyond that, it doesn't serve as a proofing method for the contained changes relating to that update. If there is a concern about the changes made with the updates, considering what I wrote about the contents of the KB articles, and about updates without KB articles currently, then the repository probably isn't for you... or at least, just installing those updates that you may think will be useful to you. I don't mean to sound like I'm flaming what you wrote, just trying to put it into perspective
whats the best way to verify the integrity of your hotfix chain? still sfc /scannow? or will that blow something up? is there a DISM command that will do it?
@burfadel sent you a PM requesting to add option to use your Windows Installer script for offline install/integration BTW I am not sure but I think for the LDR hotfixes you are only installing with the update-bf.mum?...Its also a good idea to install the update.mum especially if the update is from on MS update, unless the GDR files are also installed (via the update.mum) MS update may want that hotfix reinstalled So LDR updates its best to install with both mum files
LOL, not at all. I'm just playing devil's advocate with that comment, I am just as likely as you are to want my system fully up to date even if I don't know what is being fixed.
I think i answer this one at least twice and this is last time ill write about it... First of all this is _not_ real SP1 update even if it shows on WU, second it gets superseeded by some other update and because of some unknown bug it still shows on WU.
What about justsomeboy's "KB2301288-v3, KB2413670-v3, KB2459492-v2, KB2460922-v2, KB2462137-v2, KB2462585-v2, KB2466373-v2, KB2468316-v2, KB2470949-v2, KB2480118, KB2481453-v2, KB2491890" missing updates? For x86 here are the missing updates which is not in repo: xxx.datafilehost.com/download-eafd951e.html
what about them? try to install them and on fully patched system and then maybe you will figure it out why they are not in repo... also this updates where initaly released in those 3 sweetsmiles packs anyway, they are not there for a reason (superseeded updates or updates for RSAT/Active Directory).
Ok, here's an interesting list. These files have version 7601.17514 on the Windows Setup disk in the sources folder, however in the image itself, and hence the files that are install to the computer, the version is 7600.16385 This is using the correct Windows SP1 ISO, fresh install, not using the SP1 update. It looks like Microsoft stuffed up here, it leads you to wonder how many files they really left out of the final SP1?... (or whether this is just another stuff up, which is likely) Notice the DISM files, including dism.exe, dismhost.exe and dismprov.dll. I'm sure if you're making an integrated ISO you'd want to use the proper SP1 7601.17514 version and not the 7600.16385 one... The other files in the sources folder not listed below are either not applicable to the final install, or the same as is installed. System32 Folder: Code: apds.dll apircl.dll apss.dll dism.exe drvstore.dll input.dll migisol.dll msdelta.dll mspatcha.dll pidgenx.dll smipi.dll spwizimg.dll ssshim.dll unattend.dll uxlibres.dll wdscore.dll System32\AdvancedInstallers Code: cmitrust.dll cmiv2.dll cntrtextinstaller.dll locdrv.dll oemhelpins.dll System32\Dism: Code: compatprovider.dll dismhost.exe dismprov.dll folderprovider.dll logprovider.dll System32\Mgwiz: Code: unbcl.dll System32\Oobe: Code: diager.dll diagnostic.dll du.dll unbcl.dll pnpibs.dll w32uiimg.dll w32uires.dll wdsutil.dll System32\Wbem: Code: esscli.dll fastprox.dll mofd.dll mofinstall.dll wbemprox.dll wmiutils.dll I successfully copied these files over the exisiting old files by using the 'Repair My Computer' option from the SP1 iso and selecting 'Command Prompt' from the menu. I then had to go to G: (as the drive letters change, so keep that in mind!) I then used: Code: xcopy /e * g:\Windows\system32 which copied the files and the files in the subfolders to the correct folders in system32. Doing it this way avoided problems with any files that were open. I did this out of interest, and yes it does work The files I tested were x64 only, since that is what the setup is. Note that under the syswow64 folder there are 32-bit versions of the same files, many of which aren't needed but Microsoft put them there anyway They're no good for compatibility, try running dism from syswow64 (the 32-bit version) and you'll find it won't work, and no thats not related to me copying the files over as I tested that before I copied them over!... Anyways, with the above copying method: - don't copy 32-bit files over 64-bit ones, and vice-versa! I should also point out that sfc will come up with unrepairable errors if you do this. Thats actually inconsequential, it just means it can't copy the 7600.16385 files back over these. Its Microsoft that made the blunders, the USB driver issues, these omitions, and possibly other omitions that you would think would be correct... If you look at the files in syswow64\dism, and system32\dism, you'll notice the system32 dism folder has the 7600.16385 versions, x64 of course, and syswow64\dism has 7601.17514 versions! (x86 only, can't be copied over of course). SO how come? ... note that even with the corrected files copied over for x64, you are still missing some of the provider files. BIG BIG stuffup Microsoft! Its been 3 months since they finalised the service pack with the images and service pack update files being the true final updates. They can regain some credibility by releasing an update that corrects these missing files and issues, they've had enough time to afterall!
I copied these files from the sources folder on the SP1 iso to an empty folder on c:, say 'Files' I then made the subfolders: Advanced Installers Dism Mgwiz Oobe Wbem and copied the files into those files as outlined in my post. After this is done, reboot the computer, and run windows setup from the Windows SP1 DVD (a previously burnt ISO) When the window shows to install now or repair the computer, click on repair. The next window will show a list of items, including memory diagnostic, system restore etc. You want to click on 'Command Prompt'. The drive lettering most likely will not be in the same order as in Windows, I believe from this command prompt window it goes by the first partition on the disk connected to the lowest port, and proceeds from there. For me, drive C: from this command prompt actually became G:, which is why I had to copy them to g:\windows\system32. On your system, basically just go through C:, D:, etc till you come to what is normally C: from windows. If you only have one drive and one partition, this could very well be D: due to the hidden system partition. So, what you want to do is change to the 'files' (or whatever you called the location where you copied the files to) folder. From there, instead of manually copying the files for each folder to system32, system32\wbem etc, you can use the xcopy command which is much more powerful (and has been around a very, very long time). Windows actually has 3 command line copy programmes! The first is the built in one to the command interpreter, the second one is the aforementioned xcopy, and the last one is robocopy. xcopy allows you to copy all the files and folders at once, which makes things a lot easier. Thats what the /e command is for, if you type in /? from the command prompt you can see /e copies all files, folders, and files in the subfolders.