Tripredacus Posted October 13, 2020 Share Posted October 13, 2020 I have three disks that have Windows 10 on them that I have to image. The caveat is that I cannot boot into these disks to see if VSS is enabled prior to doing this. If VSS is enabled, is there a file or folder present that is there and is not if disabled? What about registry keys? Link to comment Share on other sites More sharing options...
HarryTri Posted October 16, 2020 Share Posted October 16, 2020 Doesn't Windows 10 have VSS enabled by default? Link to comment Share on other sites More sharing options...
jaclaz Posted October 17, 2020 Share Posted October 17, 2020 What difference there is (for imaging[1]) if VSS is enabled or not? Anyway: https://www.securesolutions.no/detecting-if-volume-shadow-copies-has-been-disabled/ OfflineReg should do: http://reboot.pro/topic/18527-offlinereg/ jaclaz [1] talking of "proper" imaging, i.e. dd-like or "forensic sound". Link to comment Share on other sites More sharing options...
Tripredacus Posted October 29, 2020 Author Share Posted October 29, 2020 DISM FFU (sector based) does not work if VSS is enabled, among other things. In the end, it was one of those other things that determined I could not use it... the fact that the OS on the disk was not generalized. Link to comment Share on other sites More sharing options...
JFX Posted October 29, 2020 Share Posted October 29, 2020 If a volume has a shadow copy there will be a big file \System Volume Information\{someguid}{someguid} containing the data. But why not check return code of "vssadmin list shadows /for="? Link to comment Share on other sites More sharing options...
Tripredacus Posted October 30, 2020 Author Share Posted October 30, 2020 Being able to check from within the OS itself is trivial. As in the op, the disks were not allowed to be booted. Now the documentation for DISM FFU does show what is and isn't allowed: https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/deploy-windows-using-full-flash-update--ffu In typical fashion, we cannot be entirely certain if the line of "Captures of disks that have Volume Shadow Copy Service (VSS) enabled are not supported" means: - vss is enabled and a capture is present or - vss is enabled but a capture hasn't occurred yet. The worst part is that while DISM will fail a capture for verify specific reasons (not generalized, or vss is enabled) the log file do not make sense. It will just show some strange message that you have to figure out what is causing it. As an example, this is the errors that DISM will throw if the OS is not generalized COfflineHiveT<class CEmptyType>::Init#63 failed with 0x0. CWindowsOSHelper::GetOSInformation#197 failed with 0x800703f1 CDiskReaderT<class CEmptyType>::GetOSInformation#280 failed with 0x800703f1. CManifest:Initialize#836 failed with 0x800703f1. CManifest::CreateInstance#536 failed with 0x800703f1. FfuCaptureInternal#420 failed with 0x800703f1. FfuCaptureImage#116 failed with 0x800703f1. I did not save the log file for my test capture which was a disk that had an OS that had VSS enabled and was not generalized, but the errors were different. There seems to be a load order regarding what DISM looks at for compatibility, as the log had different errors entirely with nothing in common with this one. I also am not sure about this statement: "Deploy Windows faster on the factory floor by using the Full Flash Update" since I can't imagine how it would be faster to push an image tens or hundreds of gigs in size vs an image that is ~8 GB. Link to comment Share on other sites More sharing options...
jaclaz Posted October 30, 2020 Share Posted October 30, 2020 (edited) 3 hours ago, Tripredacus said: I also am not sure about this statement: "Deploy Windows faster on the factory floor by using the Full Flash Update" since I can't imagine how it would be faster to push an image tens or hundreds of gigs in size vs an image that is ~8 GB. How do you estimate the tens or hundreds of GB? JFYI: https://win10.guru/windows-ffu-image-faster-capture-deployment/ The .ffu image is 30-40% bigger, but the capture took 1/6 of the time and 2/3 for the applying phase (not taking into account partitioning and format, needed for the .wim) jaclaz Edited October 30, 2020 by jaclaz Link to comment Share on other sites More sharing options...
jaclaz Posted October 31, 2020 Share Posted October 31, 2020 (edited) Also, review this, where through experiment the minimal requirement for .ffu image capturing were found: http://reboot.pro/topic/22182-capture-and-apply-windows-full-flash-update-ffu-images/ In a nutshell needed files are: http://reboot.pro/topic/22182-capture-and-apply-windows-full-flash-update-ffu-images/?p=213318 Quote \Windows\System32\ntoskrnl.exe \Windows\System32\config\SYSTEM \Windows\System32\config\SOFTWARE Since the .ffu is a "whole" disk image, one could probably get away with a second tiny partition with only those files (and the search for the minimal requisites these file must gave is still open, very likely only a bunch of keys are needed in the two registry hives). jaclaz Edited October 31, 2020 by jaclaz Link to comment Share on other sites More sharing options...
Tripredacus Posted November 2, 2020 Author Share Posted November 2, 2020 I made a guess about how big the sizes were. Considering it is unknown to me how much data was on the disks already, but using the general number of around 12 GB as a size of images made from un-optimized installs, and the fact that the disks were 1 TB. The results of the test in the first link are foreign to me. I have never seen DISM take a half an hour to capture a partition. In fact, the 5 minutes shown as being the FFU capture speed is typically the speed I see using DISM regularly. Of course my setup is entirely different, since I use real hardware. For image application, 3 minutes (using that site's example again) is not that great of an efficiency boost in imaging speed when real people are involved. BUT good to know that it is not supported for use in manufacturing. Link to comment Share on other sites More sharing options...
jaclaz Posted November 2, 2020 Share Posted November 2, 2020 (edited) Since the .ffu is a compressed format, taking a .ffu image of (a whole) disk that has been zeroed out will be only slightly bigger than a .wim (image of the contents of a volume) as 00's compress fairly well. (or of the sum of multiple .wim's in case of multiple volumes/partitions) 2 hours ago, Tripredacus said: BUT good to know that it is not supported for use in manufacturing. Yep don't you love the good MS guys, a tool that can basically ONLY be useful in production is not supported in exactly that single scenario where it may be of use (and like if - outside that particular scenario MS support actually existed) jaclaz Edited November 2, 2020 by jaclaz Link to comment Share on other sites More sharing options...
Tripredacus Posted November 3, 2020 Author Share Posted November 3, 2020 While there has been some inroads recently, MS builds products for (and licenses them appropriately) for a world where only supported Microsoft products exist. They had previously planned to release a feature into WDS for Server 2012 that could do whole disk imaging but to my knowledge it was not released then. I remember being at a presentation where it was talked about and I asked the presenter if it could be used to image Linux disks on WDS. He said he did not know but it was not supported. 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