@burfadel I allway uninstall the packages previously added to install.win with: dism /image:%tmpdir% /remove-package /Packagenameackage_for_KB2615128~31bf3856ad364e35~amd64~~6.1.1.0 If I first remove the old 2615128 and than add the new 2615128-v2 the old package is no longer in the packages list. dism /image:%tmpdir% /Get-packages /Format:table >x64-image-pack.txt If I do it in the oposit way Package_for_KB2615128~31bf3856ad364e35~amd64~~6.1.1.0 still present in the packages list. Also some Updates with state "superseded" can only be removed from the install.wim, if you first uninstall the supersedeing update, than remove the superseded update and then add the superseding update again. Can you check if this situation is also true for online systems? Run dism /online /Get-packages /Format:table >x64-online-pack.txt on your system.
The old ones are definitely removed when uninstalling after (I did double check with dism) There is a difference between integrating and installing to an online image though. The method of uninstalling v1 after v2 should work, its probably a minor issue with dism etc... Through integration the changes are made and finalised immediately on each update install/uninstall. On an online system, if the files are in use (which would be most of the time), the changes are summed with each update, and the files to be changes are placed in the Windows\winsxs\Temp\PendingRenames folder, with the change instructions in the Windows\winsxs\pending.xml file. So, if you install a new update, the change commands are written which are finalised upon reboot. Once the reboot has taken place, the files of the superseded update are no longer in use, so can be removed immediately. If you uninstall the superseded update first, since the files are in use, the change commands are written (to pending.xml and files copied to the pendingrenames folder), and they are finalised upon reboot. Once you reboot, the original files are now in use, so when you install the new update, you have to restart again for the new update files to be committed. This seems less practical and sensible, and you are also left between the installs using the original files. If you install the new update after uninstalling a superseded update, but before the superseded update uninstall changes are committed, you may run the risk that the changes are done incorrectly or some form of complication to arise. There is also a 'system' folder in Windows\winsxs\Temp (same location as the PendingRenames folder called PendingDeletes. Its not visible normally because its set as a 'system' folder. If you start messing around with uninstalling the superseded updates first, then installing new updates without restarting, its possible you could add clutter to this folder... or at least be one potential way of adding stuff to this folder that isn't deleted and will just end up taking disk space. So for integration it seems like you need to uninstall the superseded update first, and for an online system it seems you need to uninstall the superseded update after you install the new update and have rebooted
Yes, i checked it also, on an online system the correct order should be 1. add newest 2. remove oldest. for install.wim 1. remove oldest 2. add newest
Man, this latest repo is givin' me BOD's like it was normal and I never get BOD's as a rule-very seldom; on a live system, in sysprep installing all the updates or after integrating them during install...I have a funny feeling it's the AMD hotfix, not sure because I have to blow the partition and restore an image in my backup folder.
@burfadel After running VC++ Runtime Installer v7., I get KB2538243 as a needed update. BTW, does anyone make a silent installer for VC++ runtimes beside shon3i?
Yes, same here now you mention it! its the same issue as with KB2556532, its superseded but because its classed as a security update it seems Windows thinks it needs to be installed... Update KB2556532 is just the 6161 release of the C++ 2008 runtimes, and does not have any extra more functional files than the newer 6225. I don't know if Ricktendo64 knows of a way to make it so KB2538243 doesn't show... (without manually hiding it that is). I know of a way to hide it... Code: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\ApplicabilityEvaluationCache\Package_for_KB2556532~31bf3856ad364e35~amd64~~6.1.1.1] "ApplicabilityState"=dword:00000070 "CurrentState"=dword:00000000 In the above code, if you had 'applicability state' set to 0, it will resolve the problem. The issue is, the key is read only! and you can't change the permissions for it either, so it seems.
IMO its always better to integrate the updates you can and only sysprep the updates you cant integrate I am not having the same problem as you guys, WU is clean here
Hmmm, if its not possible to get around the update showing issue, I might have to include both the 6161 and 6225 versions, since for people with WU turned on not doing so would create an annoyance. Seems stupid and pointless though!
I just notice that you need to change something in the update.cmd in the Windows Hotfix repository in order to install some updates. For example Windows6.1-KB2604521-v2-x64 won't install with update.cmd. I changed something in update.cmd and it installed fine replace Code: IF EXIST "%TEMP%\updates.install\unpacked\%%A\update-bf.mum" ( dism /Online /LogPath:"%~dp0DISM.log" /Add-Package /PackagePath:"%TEMP%\updates.install\unpacked\%%A\update-bf.mum" /NoRestart /Quiet ) ELSE ( dism /Online /LogPath:"%~dp0DISM.log" /Add-Package /PackagePath:"%TEMP%\updates.install\unpacked\%%A\update.mum" /NoRestart /Quiet ) with Code: IF EXIST "%TEMP%\updates.install\unpacked\%%A\update-bf.mum" ( dism /Online /LogPath:"%~dp0DISM.log" /Add-Package /PackagePath:"%TEMP%\updates.install\unpacked\%%A\update-bf.mum" /NoRestart /Quiet ) IF EXIST "%TEMP%\updates.install\unpacked\%%A\update.mum" ( dism /Online /LogPath:"%~dp0DISM.log" /Add-Package /PackagePath:"%TEMP%\updates.install\unpacked\%%A\update.mum" /NoRestart /Quiet )