If MS lists 2959977 before 2934018, you should follow their advice. I have not seen any conflict between these two kb files. I think their advice is more for people that are unable to install 2919355 correctly, but their instructions should never be ignored. As far as the one at a time thing, well... It's hard to explain. I've had problems with all-at-once integration before. I don't know enough about the servicing to explain why it's better. I wish I did. If you went through the install error hell that I went through with my win8 and win8.1 esd recovery compression aio versions, you'd know that you should avoid anything that causes these weird errors like the plague. One of the things that seems to cause these weird install errors is resetbase'ing non-pending updates into your offline image. Another is installing a ton of updates at once without installing them one at a time. Back in win8, toward the end of my integration efforts on it, there was over 1gigs of compressed updates to integrate into the x64 version. I would integrate them all at once. As soon as I was able to export them to esd recovery compressed versions, I did so. It didn't make sense to use non-esd files since they were all too large to fit on fat32, and hence breaks the way most UEFI users would install it. There's just something about the way the all-at-once method integrates that doesn't jive with recovery compression. I don't know if it's messing with pointer files incorrectly, or some weird mathematical error is causing incorrect chunk verification or what. I just know that whatever causes these problems, is not worth the hassle of dealing with. It's much better to use a loop to integrate all *.msu or *.cab files in a folder than to use the whole-folder integration method.
murph, I think u should add instruction with wsim (windows system image manager) answer file (available with windows ADK or WAIK) as it much more fast for integrating update into offline image (normal integration, not LDR/GDR integration). with wsim, integration to offline image take about 30 minutes, while with add-packages command and specify manually, take about 1,5 hours (that's becuz the kb package extracted first with the servicing tool aka DISM one by one, while with wsim only once DISM extracted in temp directory and then all the package). note: kb2919442 and kb2919355 cant use wsim, but the rest package update 1 for windows 8.1 can use wsim, and it's only support *.cab package, not msu
Never tried esd files before but in a case of an AIO using one of those compared to wim files, I guess wim files are considerably faster, no? I mean installations time is shorter with wim files than esd files. Could someone provide a brief statistic based on their own experience? Is it really worth besides file size reduction to use esd files in terms of time?
wsim runs dism commands via answer files. It runs them all at once, which is akin to running dism /add-package pointed at a single folder full of msu or cab files. While it is faster to point it at a whole folder, it presents the esd recovery compression problem discussed many times here in this thread.
I honestly couldn't tell you which one is faster. In my experience, they have been roughly the same speed. I don't think you'd really know the full speed difference unless you had a very high speed source and target drive. My limited experiences with 30-50 MB/s source drives and 100ish MB/s write speed target drives pretty much max out at the write speed, considering all the file system overhead and small files involved. If you had a really high speed usb3 source drive and a sataIII SSD target drive, you could probably paint a more accurate picture.
I dont have problem integrate some update with wsim and after that compress the image with esd recovery format, could u more specific explain the problem or referring to the post so I can read that? thx in advance
It's difficult to explain. The problem seems to occur when servicing many different indexes in an AIO. doing a resetbase command on the non-pending updates seems to cause a problem integrating a lot of updates also seems to cause a problem. What happens is boot setup will get to about 85~ percent and then give an install failure. I've noticed it since win8.1 came out and we were able to export to esd It doesn't happen every time. In fact, it can be either very rare or very common. Integrating hotfixes one at a time seems to reduce or eliminate this problem. I've had a few different ideas at how to fix the issue over the last few months, though. Firstly, I thought that limiting boot ram helped, but I think it only reduced the likelihood a little. So I just stopped doing that and started trying to go after the cause instead of the symptom. If you don't experience the problem, then I'm glad for you. It's really frustrating.
I have been playing with minimizing win8.1 images. I've been trying ways of reducing the image without breaking things. Firstly, the non-invasive methods: Removing provisionedappxpackages disable-feature /remove certain features This method works, but doesn't reduce the image by much and doesn't speed up the OS at all. So that just leaves the invasive methods that will break system files. The two largest additions are windows recovery environment (winre.wim) and language files. On the language files thing, Windows likes to store tons of localized files for all the various system programs regardless of the language pack you have installed. Using winreducer you can remove both of these things and also the control panel shortcuts and files for language changing. That being said, it doesn't speed up your system. Removing files makes more room, but since the files are never loaded in the first place, there's no performance increase. So to improve performance, there's really only a few options. You can disable Windows Defender and Windows Search Indexing service. You can also disable the security center service that monitors that stuff and nags you via the taskbar. Changing these things would improve performance, but it's nothing that you cannot do by simply disabling defender in the GUI and setting the search indexer to disable in services.msc Again, removing the files only saves a little room, it's stopping the running files that improves performance. So my verdict on 8.1 minimizing is that if its done, it should only be done because of space constraints. It causes way more problems than benefits gained. Also, when you tinker around with the system settings with these methods, the superfetch has to re-calibrate itself or whatever... I don't know exactly how to describe it. Your system is actually slower during setup after minimizing because the system is going through a hissy-fit trying to figure out what's damaged. You can also store the acl information on the winsxs folder and then compress the files with compact.exe, but it would actually slow down your performance a little by needing to decompress the files each time they are loaded. I'm not gonna elaborate on how to do that because it's a terrible idea and I wouldn't want people to try it.
hello i created a session with sysprep (vmware) and windows 8.1 update 1 but windows update doesn't find any updates. Without sysprep works perfectly. How can fix this problem?
Typical scenario I do when sysprepping 8.x is create user and let it finish install Then I install a few things like directx, netfx3, vc++ redists. Then I run wuapp.exe and install updates and reboot and repeat the process until no longer needing any updates. Then i run %windir%\system32\sysprep\sysprep.exe /audit /reboot When in audit mode, go into control panel and delete the temp account. Then you sysprep /oobe /shutdown using the sysprep tool that's always started when in audit mode. Then you capture it with a config.ini that eliminates both your temporary user account directory, administrator directory, and the softwaredistribution directory. Anyway, to run ps1 scripts, you just set execution policy to remotesigned (only runs scripts from your own system if unsigned) Then you run the appropriate script with powershell. Typical cmd script to do this would be like: Code: powershell Set-ExecutionPolicy RemoteSigned powershell %TEMP%\PSR.ps1 Obviously change the path and such to match the scripts you wish to use and run the script as admin. Remember your pushd command because running as admin will change your current directory to system32 automatically unless pushd "%~dp0" is specified.