Please could someone tell me how the variable could be to install the updates without having to put as in the example: @echo off pushd "% ~ dp0" dism / image: c: \ mount / Add-Package / PackagePath:"C:\x64\update\Extr \BrowserChoice" etc. What would be the variable that finds all the updates that are in the "Extra" folder without having to put "C:\x64\update Extra BrowserChoice" I give thanks advance
You mean something like that ... : Code: for /R "C:\x64\update\Extra" %%A in (*.cab) do ( dism /Image:"c:\mount" /Add-Package /PackagePath:"%%A" )
That's what I want But for other folders as: C:\x64\update\General C:\x64\update\Hotfix etc.... I would have to put each of them: for /R "C:\x64\update\Extra" %%A in (*.msu) do ( dism /Image:"c:\mount" /Add-Package /PackagePath:"%%A" ) It could be another variable?
Just wanted to say that although this method is slower than simply pointing dism at the folder and integrating them all at once, it is a much better idea. Integrating them one file at a time is much more stable for the filestream and will cause much less problems if you convert to esd.
Nice, wasn't aware of a shorter way but good to know mine is more foolproof, did it to be able to count them before . Using it in a similiar way to get the install order for the updates from a text file and process in a loop for all indices .
One of these days, im going to consolidate all my DISM cmd scripts that S1ave77 and Murphy78 have offered to help others. and publish in a nice Book. and everybody else who has offer scripts to help. Thanks Guys for all the super scripts... Old Dog learning new tricks.
Proper post-update wim integration: Code: dism /mount-wim /wimfile:c:\win81x86\sources\install.wim /index:1 /mountdir:d:\mount dism /image:d:\mount /add-package /packagepath:E:\Win81slipstream\KBFiles\x86\KB2919355\Windows8.1-KB2934018-x86.msu dism /image:d:\mount /add-package /packagepath:E:\Win81slipstream\KBFiles\x86\KB2919355\Windows8.1-KB2959977-x86.msu dism /image:d:\mount /add-package /packagepath:E:\Win81slipstream\KBFiles\x86\KB2934520\Windows8.1-KB2934520-x86.msu for %%A in (E:\Win81slipstream\KBFiles\x86\*.msu) do (cmd /c "dism /image:d:\mount /add-package /packagepath:%%A") dism /unmount-wim /mountdir:d:\mount /commit Improper integration that produces apply-image failures during winpe setup: Code: dism /mount-wim /wimfile:c:\win81x86\sources\install.wim /index:1 /mountdir:d:\mount dism /image:d:\mount /add-package /packagepath:E:\Win81slipstream\KBFiles\x86\resetbase\Windows8.1-KB2899189-x86.msu dism /image:d:\mount /cleanup-image /startcomponentcleanup /resetbase :resetbase causes some sort of error here (not in dism, but in the wim filestream) dism /image:d:\mount /add-package /packagepath:E:\Win81slipstream\KBFiles\x86\KB2919355\Windows8.1-KB2934018-x86.msu dism /image:d:\mount /add-package /packagepath:E:\Win81slipstream\KBFiles\x86\KB2919355\Windows8.1-KB2959977-x86.msu dism /image:d:\mount /add-package /packagepath:E:\Win81slipstream\KBFiles\x86\KB2934520\Windows8.1-KB2934520-x86.msu dism /image:d:\mount /add-package /packagepath:E:\Win81slipstream\KBFiles\x86 dism /unmount-wim /mountdir:d:\mount /commit When the 2nd example is exported to esd recovery compression, you will get rare errors in your boot setup, and possibly your upgrade setup.
Unfortunately, with the adoption of more and more cloud computing, these things will be rapidly evolving. Things will be changing from a slow-changing OS with a lot of offline integration, to a constantly changing online platform. A lot of our old tricks will no longer be necessary when most of the programs are simply ran off of servers and downloaded on demand. I think a lot of us old-dogs will gravitate more to server-based OSes and leave the end-users to their simple netbook-style computing.
Is it safer to use for loop to 'add-package' individually? Code: for %%A in (E:\Win81slipstream\KBFiles\x86\*.msu) do (cmd /c "dism /image:d:\mount /add-package /packagepath:%%A")
Sorry for double post but I want to be sure you could see it: Edit: I've just saw your post three above mine and I guess this is my answer (thanks to s1ave77 to point me in the right direction)... One more thing, according to Alphawaves and aboddi KB2959977 goes before KB2934018, you have the opposite, then what is the right order?
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?