_14e30a.png)
_8126ce.png)
abbodi1406
Members
-
Joined
-
Last visited
Everything posted by abbodi1406
-
Updated
-
I don't know anything about signing or security cats replacing mum files is not a problem can be done with modifying the permissions (not recommended) or using cmd with trustedinstaller token or having the original files inside a wim file which preserve the nt security permissions, therefore can by applied using dism/imagex but like you said, install this update after OS install is not a big deal
-
Actually the reason is known each .mum file is paired with security .cat file to verify the contents modifying mum file cause the failed integrity check “Installed Updates” scans packages mum files in \Windows\servicing\Packages and make a cache database for it in \Windows\WinSxS\ManifestCache
-
Yes i know the files are the same and the modded cab will give functional servicing stack for modded or lited editions/aio this is not a problem but for users whou care about updates or WU, this would be a problem MS made that update exclusive for a reason there is a workaround for this issue, by replacing the altered mum/manifest files with the original ones after integrating the update but that would require RunasSystem/RunFromToken to be able to replace the files without changing permissions
-
Can't be done including LP will need a new separate addon
-
Modifying update.mum file will result later in failed integrity check, specially when using System Update Readiness Tool or checking "Installed updates" in control panel
-
Won't be Addon'ed until RTM
-
4.x updates can be satisfied with LDR however, some 3.x updates require GDR to satisfy WU (KB2894852, KB2972213, KB2973114, KB2979573) like i said, both branches are OK regular hotfixes are already GDR only .NET hotfixes are already LDR only so, normal integration mode is the only available
-
LDR branch is practically deactivate/dead in Windows 8.1, almost all updates have only the normal GDR branch yes this includes hotfixes only some .NET (3.5 and 4.5) updates and hotfixes are having LDR, which is understandable because those frameworks are shared with other windows systems (7, 8) problems or issues happens in any updates (most botched updates are GDR) so, installing those .NET updates in LDR mode would be recommended
-
That's just a regular update related to WMF i'm not sure how it's related to .NET 4.5 framework or addon
-
Deployment Image Servicing and Management toolVersion: 6.1.7600.16385You can't service Win 8.1 image using Win 7 Dism you need Windows 8.1 ADK
- 2 replies
-
- win-toolkit
- wintoolkit
- updates
- integration
-
Tagged with:
-
-
Those updates are superseded (replaced) with hotfixes but WU doesn't acknowledge those hotfixes, thus it demands for those updates you can safely ignore them, or simply let WU install them
-
As ricktendo stated, in Windows 8.1 only some .NET updates have both GDR+LDR branches 2898847,2898850,2966826,2966828,2968296,2972103-v2,2972213,2973114,2977765,2978041,2978122,2979573,2979576there are some hotfixes that are LDR only (all are .NET related except one 2974735) 2925384-v4,3011110-v2,3000059-v3,3013375LDR is as good as GDR
-
All updates are for Post-SP1
-
Updated
-
- Where? - In Options > Misc, change one of Wintoolkit Temp or Mount folder pathes btw, what are the sizes of the three partitions you have (c:, d:, f:)?
-
- attach C:\Windows\Logs\DISM\dism.log - update your ADK to latest (Update 6.3.9600.17029) btw, since your current system is Win7SP1, why do you use ADK to update Win7 image? - you are integrating updates from D:\ , using Dism from C:\ , to Mount directory on F:\ , and Scratch (extract) directory on C:\ so the updates are extracted from d: to c: then copied to f: that's a long way try to change mount folder to C: or D: , or change Temp folder to D:
-
All the errors in you log indicates ACCESS DENIED if you have Anti-virus, stop it, real time scanning may prevent the process and you may try this fix: http://support.microsoft.com/kb/968003
-
Does the actual dism report 6.1.7601.17514? for me i get 6.1.7600.16385 on x64 system: it seems something not solid, so 6.1.7600.16385 doesn't always means RTM sorry for hijacking your thread hayedeh
-
Only this file? i don't think it's worth the trouble Wintoolkit's cleanup feature deletes all *.log files in Windows directory although, this MSDTC.LOG file is not actually a text log file, it's just a plain stream file
-
You will have install.esd file in the iso not install.wim
-
Just a cosmetic reason to modifiers, so the iso looks as new It's working here as expected make sure you select a correct valid folder to create iso
-
When using x86 dism, the Win7 SP1 x64 version is reported as 6.1.7601.17514 but when using x64 dism, the Win7 SP1 x64 is reported as 6.1.7600.16385 the cause of this confusion is when servicing x64 image using x86 dism, Windows\SysWOW64\Dism\DismHost.exe from the image is used (and its version 6.1.7601.17514) but when servicing it using x64 dism, Windows\System32\Dism\DismHost.exe is used (and its version is 6.1.7600.16385)
-
Unlike x86, Win7 SP1 x64 image version in default is reported by dism as 6.1.7600.16385
