RUSerious Posted November 11, 2017 Share Posted November 11, 2017 Anyone figure out how to do a feature / build / version update (1703 to 1709) within a VHDX file? Normal updates (Win+X > Update & security) work fine, but MS will not allow version updates on a USB or VHD / VHDX drive. Tried obvious of mounting / attaching the VHDX, then cloning it to an internal partition, and then editing BCD to boot to the clone. Acts likes it going to boot to the VHDX clone (on the internal HDD partition), but just ends up with the eternal gray screen. Familiar with BOOTICE if that helps...TIA Link to comment Share on other sites More sharing options...
JFX Posted November 12, 2017 Author Share Posted November 12, 2017 Yes, Microsoft does not allow OS upgrades with VHD(X) boot. Easiest way would be to boot the VHD in Hyper-V and make the upgrade there. Link to comment Share on other sites More sharing options...
Atari800XL Posted November 13, 2017 Share Posted November 13, 2017 On 9-11-2017 at 10:31 PM, JFX said: Yep, DISM command line does not allow more than one /SWMFile parameter. And *.* is not accepted, so it requires that all files have the same extension. Did you know that the latest imagex.exe does support multiple "ref" parameters? (I sure didn't). It also supports "*.*": imagex /apply Education_en-us.esd 3 Z: /ref *.esd /ref *.cab imagex /apply Education_en-us.esd 3 Z: /ref *.* Abbodi1406 found out: https://forums.mydigitallife.net/threads/windows-10-imaging-customization-and-deployment.59187/page-28#post-1388789 Link to comment Share on other sites More sharing options...
JFX Posted November 13, 2017 Author Share Posted November 13, 2017 (edited) Interesting, thought they wanted to deprecate imagex, but now it proves to be useful again. Seems to work nice, just wonder does wimgapi/imagex 16299 works for you? I'm always getting something like this: Quote J:\Download\uupdl\uup\16299.19\en-us\amd64>imagex /apply Education_en-us.esd 3 X: /ref *.esd /ref *.cab ImageX Tool for Windows Copyright (C) Microsoft Corp. All rights reserved. Version: 10.0.10011.16384 [ 8% ] Applying progress: 7:34 mins remaining [ RETRY ] Restoring X:\Windows\InfusedApps\Packages\Microsoft.WindowsSoundRecorder_10.1706.1561.0_x64__8wekyb3d8bbwe\PersonPicture.UAP.dll again (Error = 1784) [ RETRY ] Restoring WIM J:\Download\uupdl\uup\16299.19\en-us\amd64\Microsoft.ModernApps.Client.All.esd, offset 0000000006f59b8a, length cc4ec2 again (Error = 6) [ RETRY ] Restoring WIM J:\Download\uupdl\uup\16299.19\en-us\amd64\Microsoft.ModernApps.Client.All.esd, offset 0000000006f59b8a, length cc4ec2 again (Error = 6) [ RETRY ] Restoring WIM J:\Download\uupdl\uup\16299.19\en-us\amd64\Microsoft.ModernApps.Client.All.esd, offset 0000000006f59b8a, length cc4ec2 again (Error = 6) [ RETRY ] Restoring X:\Windows\InfusedApps\Packages\Microsoft.WindowsSoundRecorder_10.1706.1561.0_x64__8wekyb3d8bbwe\PersonPicture.UAP.dll again (Error = 6) [ RETRY ] Restoring X:\Windows\InfusedApps\Packages\Microsoft.WindowsSoundRecorder_10.1706.1561.0_x64__8wekyb3d8bbwe\PersonPicture.UAP.dll again (Error = 6) [ RETRY ] Restoring X:\Windows\InfusedApps\Packages\Microsoft.WindowsSoundRecorder_10.1706.1561.0_x64__8wekyb3d8bbwe\PersonPicture.UAP.dll again (Error = 6) [ ERROR ] X:\Windows\InfusedApps\Packages\Microsoft.WindowsSoundRecorder_10.1706.1561.0_x64__8wekyb3d8bbwe\PersonPicture.UAP.dll (Error = 6) Error restoring image. Das Handle ist ungültig. But it is working fine with wimgapi 15063. Edited November 13, 2017 by JFX Link to comment Share on other sites More sharing options...
Atari800XL Posted November 13, 2017 Share Posted November 13, 2017 I'm still testing as well, my first test was with imagex.exe from the dism folder (using your GetWAIKTools) in PE. This was version 16299, x86, and gave no errors. But it looked to finish too quickly, so I thought something must have gone wrong. I cleared the partition again (didn't run the install), then ran WinNTSetup, to time how long that took. WinNTSetup did the apply in around 7 minutes. After that I checked the size of C:, around 5.6gb was applied. So I tested imagex.exe again, it finished in 5 minutes, also with 5.6gb applied. Huh? How can it be so much faster?! The install seems to have gone OK while I'm typing this, so lots of interesting stuff to test and analyze... Link to comment Share on other sites More sharing options...
JFX Posted November 13, 2017 Author Share Posted November 13, 2017 Time difference could be caused by disk caching, here on a ryzen + ssd system I get simular times for both (around 2 minutes +- 5 seconds). Link to comment Share on other sites More sharing options...
Atari800XL Posted November 14, 2017 Share Posted November 14, 2017 Repeated the test, with a reset inbetween. Still 5 minutes for imagex, 7 minutes for WinNTSetup. Does it have something to do where you set the temp/ extract folder, or maybe verify on/off? (Just blurting out something, as I said, the first time I tried imagex I thought maybe it skipped files, but it doesn't seem to be that way). Link to comment Share on other sites More sharing options...
JFX Posted November 14, 2017 Author Share Posted November 14, 2017 No, there is no verify made and temp folder is set to be the installation drive. Do you measured yourself or are the 7 minutes from the WinNTSetup.log? Link to comment Share on other sites More sharing options...
Atari800XL Posted November 14, 2017 Share Posted November 14, 2017 OK, thanks, I was wondering about verify and temp folder. Yes, I measured by old-fashioned manual timer :-) But I don't want to go too much off-topic, just wanted to share the remarkable difference. Link to comment Share on other sites More sharing options...
Atari800XL Posted November 18, 2017 Share Posted November 18, 2017 Last message about the difference between WinNTSetup apply and "manual" Imagex,exe 10.0.16299.15 (using unmodified/ unconverted UUP files). I have repeated all the tests, using PE versions from Windows 7 (3.1) upward. Tests were done on a spare laptop (Pentium dual core TT2370, 3gb, apply from external 2.0 usb hd to internal hd). Reboot between tests (no disk cache effect). For WinNTSetup (3.8.8.2b1), the timer is stopped as soon as the apply stage is done (when it starts applying tweaks). Pretty much all tests show WinNTSetup takes 7:00 minutes, manual apply with Imagex.exe takes 4:55 to 5:00 minutes. I'm not coplaining about WinNTSetup at all (will still use it), I just wonder where this time difference is coming from. And of course, I wonder why Microsoft is "hiding" this fast UUP-functionality in Imagex.exe ... Link to comment Share on other sites More sharing options...
JFX Posted November 18, 2017 Author Share Posted November 18, 2017 (edited) I'm still curious about the exact time that is written to the log file Something like this: Successfully applied WIM Image. (Operation took: 1:03 min) Edited November 18, 2017 by JFX Link to comment Share on other sites More sharing options...
Atari800XL Posted November 18, 2017 Share Posted November 18, 2017 Sorry, forgot about that. Log file says "Operation took: 7:47 min)". Link to comment Share on other sites More sharing options...
jaclaz Posted November 18, 2017 Share Posted November 18, 2017 2 hours ago, Atari800XL said: Sorry, forgot about that. Log file says "Operation took: 7:47 min)". I.e. much more than what you manually measured? Or do you have 3/4th of a whole minute in reaction time? jaclaz Link to comment Share on other sites More sharing options...
abbodi1406 Posted November 19, 2017 Share Posted November 19, 2017 Howdy @Atari800XL imagex time is the one reported as elapsed it after finish applying? for me i used echo %time% before and after imagexin a script, the difference was ~ 3:40, while imagex reported 3:00 still, manual observation of WinNTSetup applying gives ~ 4:20 BTW, where do i find WinNTSetup log? and it detects 1st index of UUP as 64bithttps://i.imgur.com/yNRfOpq.png 1 Link to comment Share on other sites More sharing options...
JFX Posted November 19, 2017 Author Share Posted November 19, 2017 Hi abbodi1406, The log is placed in the Windows folder of the chosen installation drive. Seems a wim index without <arch> in the xml is interpreted as x64. Will fix this. 1 Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now