kb3081424 and kb3074683 (and most previous cumulatives) share the same version number of plenty components and for DISM, the package isn't flagged as "deeply superseded" unless all its components are completely replaced with newer versions
Did you clean the sysprepped image leftovers properly? specially this folder contents, they can be up to 200 MB Code: C:\Windows\WinSxS\ManifestCache\ nonetheless, you can open original install.wim and syspre install.wim with 7-zip and cross-compare or find where's the increased size located in
Thanks for the tip...i did't clean that folder...never done with win 8.1 1) the folder manifestcache has just 1 file of 38mb 2) the big differences i see between the 2 wim files are: - the sysprepped wim has and Administrator folder under users and weights: ~ 150mb ( maybe the generalize didn't worked??) - winsxs in the sysprepped wim is much bigger than the original one. any tip?
It's better to use wimscript.ini when capturing syspreped image Spoiler Code: [ExclusionList] \Boot \Recovery \Recovery.txt \BOOTSECT.BAK \ProgramData\Microsoft\Network\Downloader\* \Users\Administrator \Windows\debug\* \Windows\inf\*.etl \Windows\inf\*.log \Windows\Logs\CBS\* \Windows\Logs\DISM \Windows\Logs\dosvc \Windows\Logs\DPX \Windows\Logs\PBR \Windows\Logs\SetupCleanupTask \Windows\Logs\SIH \Windows\Logs\WindowsUpdate \Windows\Logs\DirectX.log \Windows\Panther \Windows\Prefetch \Windows\security\database\*.chk \Windows\security\database\*.log \Windows\security\database\*.jrs \Windows\ServiceProfiles\LocalService\AppData\Local\FontCache-S-1-5-21-*.dat \Windows\SoftwareDistribution \Windows\System32\catroot2\*.chk \Windows\System32\catroot2\*.log \Windows\System32\catroot2\*.jrs \Windows\System32\CodeIntegrity\bootcat.cache \Windows\System32\Sysprep\Panther \Windows\System32\Sysprep\Sysprep_succeeded.tag \Windows\System32\winevt\Logs\* \Windows\Temp\* \Windows\WinSxS\ManifestCache\* \Windows\WinSxS\Temp\PendingDeletes\* \Windows\comsetup.log \Windows\DtcInstall.log \Windows\lsasetup.log \Windows\PFRO.log \Windows\setupact.log \Windows\setuperr.log \Windows\TSSysprep.log.log \Windows\vmgcoinstall.log
On many sites they say and i believe murphy said it also in the past, cleaning up winsxs folders can result in dodgy windows versions (in case of future updates/changes). Is it still the case?
According to murphy78 in an 8.1 comment he says you could remove the admin accountfolder after generalize before capturing but my findings where that this results in temporary state when boot/switched to admin after install. Sort a like the static state in xp (i can't remember the correct name for it). Than you can do things and when windows is rebooted everything will be undone.
I don't really know enough about winsxs cache stuff to make a judgement call either way. I generally avoid messing with winsxs since I'm so ignorant on its fine details. I have told ppl not to delete the winsxs/backup folder to save space, but it's like deleting a bunch of manifest failsafe files. They only exist to be copies of manifests in case said manifests become corrupted, so the system can repair them.
That's the comment i meant So maybe abbodi can tell me/us some more about safely deleting winsxs files/folders?
I'm not cleaning any components folder, ManifestCache is as it's name says: cache for .mum files located in: Code: C:\Windows\servicing\Packages which get created and loaded when checking "Installed update" btw, the ExclusionList is constructed by comparing and checking vanilla install.wim it's not a tweak one
To really figure out what is safe to delete or not, you have to compare a offline image to an online image. Windows bloats up your system by about a gig. If you were to figure out exactly where all of that data was, you could make a superb sysprep image. Of course, you'd need to get it all, because if you leave some file like pending.xml and delete all the stuff that it's referencing, you'll have problems. The same goes for a lot of stuff in the system. Anyway, to abbodi's point: I'm seeing microsoft themselves saying that ppl can delete the manifestcache files so I don't see why it wouldn't be safe to exclude them.
no have no fear heres how dism /Image:C:\(path of offlineimage) /Get-Packages>featurelist.txt it will save it to c:\windows\system32\featurelist here an example of what you will see Package Identity : Package_for_KB3074680~31bf3856ad364e35~amd64~~10.0.1.0 State : Installed Release Type : Security Update Install Time : 24/7/2015 6:38 ££ Package Identity : Package_for_KB3074681~31bf3856ad364e35~amd64~~10.0.1.0 State : Installed Release Type : Security Update Install Time : 26/7/2015 10:31 §£ Package Identity : Package_for_KB3074683~31bf3856ad364e35~amd64~~10.0.1.0 State : Installed Release Type : Security Update Install Time : 28/7/2015 5:16 ££ Package Identity : Package_for_KB3074686~31bf3856ad364e35~amd64~~10.0.1.0 State : Installed Release Type : Update Install Time : 24/7/2015 2:10 ££ Package Identity : Package_for_KB3081424~31bf3856ad364e35~amd64~~10.0.1.0 State : Installed Release Type : Update Install Time : 5/8/2015 6:44 ££ now let just say you want to remove KB3074683 type dism /image:c:\(path of your mount dir) /remove-package /packagenameackage_for_KB3074686~31bf3856ad364e35~amd64~~10.0.1.0
kb3074683 is really/officially/WU superseded. It's just not needed at all resetbase is no go for offline integration, the small updates that are not pending are not worth it Code: dism /Capture-Image /ImageFile:install.wim /CaptureDir:Z:\ /Name:"Windows 10 Pro" /ConfigFile:winscript.ini /Compress:max /CheckIntegrity or imagex /COMPRESS maximum /CONFIG winscript.ini /capture z: install.wim "Windows 10 Pro"
I have a noob question if I want to intergrade a wu it makes any diference if i intergrade to install.wim or winre.wim i never intergrade to winre.wim and i found 2days ago of its existence so a little noob friendly explaination will be much appreciated
Thanks for handing me those commandlines, i am now entering sysprep in vmware and will test this after generalizing. Before i used gimagex and wtk 1.5.4.3
Murphy would test it when he had the time, i'm also (patiently) waiting for his comment on using updates in winre.wim and boot.wim
I'm sure there is something not proper, and a logic explanation but still, kb3074683 should not be used
I have now integrated kb3074686, 3074678 did a reset base command and integrated kb3081424, when i look up the size of the winsxs\manifestcache folder it's 22.48MB. The winsxs backup folder is about 150MB. According to you i could safely remove the files inside the manifest cache folder? But leave the winsxs backup folder?