i have tried both methods. no problem here. original boot.wim and updated boot.wim work without any problem.
Thanks, murphy78 I've thrown everything away and picked up the iso i initially made, mounted the x64 boot.wim #2 \ sources, copied the setup.exe (14393.206) and compared it to the one in "iso:\sources" (14393.0) and replaced the .0 with the .206. Test: Now it works Thanks, aboddi1406 and murphy78 PS, on the x86 iso the setup.exe from boot.wim #2 \ sources = 14393.0 and the one in "iso:\sources" = 14393.0 and it works like a charm Both are 14393.0 Boot.wim #2 x86 Getpackages: Code: Package Identity : Package_for_KB3199209~31bf3856ad364e35~x86~~10.0.1.0 State : Installed Release Type : Update Install Time : 10/17/2016 9:49 PM Package Identity : Package_for_RollupFix~31bf3856ad364e35~x86~~14393.321.1.5 State : Installed Release Type : Security Update Install Time : 10/17/2016 9:52 PM
New updates are out it seems. Update for Windows 10 #KB3199986 and Cumulative update for Windows 10 #KB3197954 (Unsure if one or perhaps even both of them are for the release preview branch.) EDIT: Cumulative update at least seems to be release preview (And slow?) ring insider only. EDIT: 14393.351 build now. EDIT: The Win10 update looks to be related to the servicing stack functionality.
KB3199986 contains files at level .350, the new insider preview is at .351, does the ip cu (KB3197954) supersede KB3199986? KB3199986 = Servicing Stack (according to abbodi1406's W10UI_1.8 script). Code: ============================================================ Checking Updates... ============================================================ ============================================================ Installing servicing stack update... ============================================================ Deployment Image Servicing and Management tool Version: 10.0.14393.0 Image Version: 10.0.14393.0 Processing 1 of 1 - Adding package Package_for_KB3199986~31bf3856ad364e35~x86~~10.0.1.0 [==========================100.0%==========================] The operation completed successfully. I see i'm telling old news
Ok. I will delete the line "delete permanence="permanent"", and then use your uninstaller script to remove superseded servicing stack update.
According to Update.catalog and this test, it doesn't supersede anything: I installed the new "servicing stack" update (KB3199986) after I've integrated KB3199209 and did a resetbase, result: Code: Package Identity : Package_for_KB3194343~31bf3856ad364e35~x86~~10.0.1.0 State : Installed Release Type : Security Update Install Time : 10/20/2016 5:29 PM Package Identity : Package_for_KB3199209~31bf3856ad364e35~x86~~10.0.1.0 State : Installed Release Type : Update Install Time : 10/17/2016 7:44 PM Package Identity : Package_for_KB3199986~31bf3856ad364e35~x86~~10.0.1.0 State : Installed Release Type : Update Install Time : 10/21/2016 1:29 PM Package Identity : Package_for_RollupFix~31bf3856ad364e35~x86~~14393.351.1.4 State : Installed Release Type : Update Install Time : 10/21/2016 1:34 PM
servicing stack updates are permanent and won't be removed with resetbase does kb3199209 get requested by WU if you install kb3199986 alone?
Removed (KB3176936) installed (KB3199209) nothing requested (WU) Removed (KB3199209) installed (KB3199986) (KB3176936) requested (WU).... strange