Hi there,
first a "Thank you" for this great software :)
Recently tried to create an update to deploy a custom install.wim / install.esd to auto upgrade our windows 10 clients from 1511 to 1607. Since the files are pretty big (3,4GB) I discovered that WPP as well as "makecab" (directly executed from cmd) seems to limit .cab files to 2GB.
Since I had set the max cab file size to 4096 MB, I thought it would be great to limit this to maybe 2048 MB or 2000 MB, so others who try to create such huge updates don't run into the same issue... ;)
Cheers,
Michael
PS: Meanwhile discovered another method how to upgrade by using a custom install.wim / install.esd with WPP :)
Comments: Pretty easy to explain - Btw. sorry for the long text, but I thought it's better to tell the whole story at the time ;) Our environment looks like: > Default system UI language : en-US > System locale : __de-DE__ > User locale : __de-DE__ > Input locale : __de-DE__ > Default time zone : __W. Europe Standard Time__ > Active keyboard(s) : __0407:00000407__ > Keyboard layered driver : PC/AT Enhanced Keyboard (101/102-Key) > Installed language(s): en-US > Type : Fully localized language. After an upgrade with the default package from Microsoft, in our case "Feature update to Windows 10 Enterprise, version 1607, en-us", any system would look like: > Default system UI language : en-US > System locale : __en-US__ > User locale : __en-US__ > Input locale : __en-US__ > Default time zone : __Pacific Standard Time__ > Active keyboard(s) : __0409:00000409__ > Keyboard layered driver : PC/AT Enhanced Keyboard (101/102-Key) > Installed language(s): en-US > Type : Fully localized language. Therefore we needed to find another way to upgrade our clients. Our first attempt was based on a script which we deployed via GPP and let it run before the upgrade to save and after the upgrade to restore the settings (as scheduled task). The powershell script did already work to 95%, but while researching to get around with the last 5% I had an idea: Let's deploy a custom install.wim / install.esd with our regional settings which would be easier and even more failsafe :) So I took the standard iso for 1607 Enterprise, mounted the install.wim, used dism to set international settings to de-DE and placed the content of the iso with the modified install.wim onto the ServicePackages network share / folder on the wsus server. Finally I created a little .vbs script to call the setup.exe on the network share with switches "/auto upgrade /quiet". To deploy the script I used "iexpress" (Windows -> Run -> "iexpress"), so I could create a normal update from an .exe in WPP and not a custom update from the .vbs :D Ideas for the solution are based on these sites / articles: > http://www.gruppenrichtlinien.de/artikel/windows-10-inplace-update-per-wsus-verteilen/ > https://social.technet.microsoft.com/Forums/scriptcenter/en-US/c0e7575a-6983-453b-8959-c6d889ccc01f/stepbystep-to-wrap-a-vbs-into-an-exe > https://msdn.microsoft.com/windows/hardware/commercialize/manufacture/desktop/windows-setup-command-line-options?f=255&MSPPError=-2147217396 The solution works pretty good so far - only thing that I'd like to improve is to add a check that aborts my .vbs script when the wsus network share is not reachable anymore since setup.exe first copies the files to the local folder C:\$Windows.~BT and until this is done there needs to be a network connection, which is mostly the case, but you never know, so will look into that and then the update can be deployed :) Regards, Michael
first a "Thank you" for this great software :)
Recently tried to create an update to deploy a custom install.wim / install.esd to auto upgrade our windows 10 clients from 1511 to 1607. Since the files are pretty big (3,4GB) I discovered that WPP as well as "makecab" (directly executed from cmd) seems to limit .cab files to 2GB.
Since I had set the max cab file size to 4096 MB, I thought it would be great to limit this to maybe 2048 MB or 2000 MB, so others who try to create such huge updates don't run into the same issue... ;)
Cheers,
Michael
PS: Meanwhile discovered another method how to upgrade by using a custom install.wim / install.esd with WPP :)
Comments: Pretty easy to explain - Btw. sorry for the long text, but I thought it's better to tell the whole story at the time ;) Our environment looks like: > Default system UI language : en-US > System locale : __de-DE__ > User locale : __de-DE__ > Input locale : __de-DE__ > Default time zone : __W. Europe Standard Time__ > Active keyboard(s) : __0407:00000407__ > Keyboard layered driver : PC/AT Enhanced Keyboard (101/102-Key) > Installed language(s): en-US > Type : Fully localized language. After an upgrade with the default package from Microsoft, in our case "Feature update to Windows 10 Enterprise, version 1607, en-us", any system would look like: > Default system UI language : en-US > System locale : __en-US__ > User locale : __en-US__ > Input locale : __en-US__ > Default time zone : __Pacific Standard Time__ > Active keyboard(s) : __0409:00000409__ > Keyboard layered driver : PC/AT Enhanced Keyboard (101/102-Key) > Installed language(s): en-US > Type : Fully localized language. Therefore we needed to find another way to upgrade our clients. Our first attempt was based on a script which we deployed via GPP and let it run before the upgrade to save and after the upgrade to restore the settings (as scheduled task). The powershell script did already work to 95%, but while researching to get around with the last 5% I had an idea: Let's deploy a custom install.wim / install.esd with our regional settings which would be easier and even more failsafe :) So I took the standard iso for 1607 Enterprise, mounted the install.wim, used dism to set international settings to de-DE and placed the content of the iso with the modified install.wim onto the ServicePackages network share / folder on the wsus server. Finally I created a little .vbs script to call the setup.exe on the network share with switches "/auto upgrade /quiet". To deploy the script I used "iexpress" (Windows -> Run -> "iexpress"), so I could create a normal update from an .exe in WPP and not a custom update from the .vbs :D Ideas for the solution are based on these sites / articles: > http://www.gruppenrichtlinien.de/artikel/windows-10-inplace-update-per-wsus-verteilen/ > https://social.technet.microsoft.com/Forums/scriptcenter/en-US/c0e7575a-6983-453b-8959-c6d889ccc01f/stepbystep-to-wrap-a-vbs-into-an-exe > https://msdn.microsoft.com/windows/hardware/commercialize/manufacture/desktop/windows-setup-command-line-options?f=255&MSPPError=-2147217396 The solution works pretty good so far - only thing that I'd like to improve is to add a check that aborts my .vbs script when the wsus network share is not reachable anymore since setup.exe first copies the files to the local folder C:\$Windows.~BT and until this is done there needs to be a network connection, which is mostly the case, but you never know, so will look into that and then the update can be deployed :) Regards, Michael