Error Failed to resolve the selected Disk (Snap Deploy build 1666)
We're trying to image a few Surface 3 (not Pro) tablets with Snap Deploy. I was able to make an image using a stand-alone Win PE baded USB boot disk, however I can't deploy the image using our Snap Deploy server. If I PXE boot everything looks like it's working but the imaging fails with a couple error codes:
Error Code 1 - Module 52: Host has failed the deployment
Error Code 6 - Module 51: Failed to resolve the selected disk
Error Cdoe 51 - Module 51 : Failed to resolve disk by number '1'
If I try to boot of the USB drive and attach to the imaging server the client gives an error and stops working.
Any ideas are appreciated.


- Se connecter pour poster des commentaires

Bobbo, for some reason our Surface 3's running Windows 10 won't boot from the Linux USB disks. They'll only boot from a USB formatted as FAT32, not NTFS, so we made WinPE Fat32 based boot disks. (Our standard linux disks work fine on our other hardware platforms, including the Surface Pro 4). It's just the Surface 3 model that exhibits this problem, and it may be related to Windows 10. A google search turned up a number of others having a similar issue booting the Surface 3 from USB drives, and that's how I came up with the solution of using a FAT32 formatted drive. The Surface 3 will also PXE boot, but I couldn't get that to work either because the Snap Deploy client throws an error message. Unfortuantely I don't have the text of that one written down but I can get it easily enough.
I don't believe it's a permissions issue because our Snap Deploy server is serving to all our other hardware platforms just fine. In fact, when we boot the Surface 3 from the USB and connect to the server, it connects and the liittle progress bars on the client go green for an instant before the image fails. So the client and the server are definitely talking, up to a point.
After further experimenting, I'm able to use the ASDCMD utility on the WinPE disk to perform the image if I have the image on a USB drive attached to the Surface. However, multicasting is really what we'd like to do. I've read that some Lenovo machines exhibited the error message that I'm seeing, and an update to the Acronis software addressed that issue, so I'm rather leaning toward the idea that this is a bug that needs to be fixed. I have a screenshot of the error messages I'm getting from the server logs, I attached it to this post.
Fichier attaché | Taille |
---|---|
382267-132307.jpg | 7.28 Mo |
- Se connecter pour poster des commentaires

Hi Doug - all of the Acronis bootable media should be used on a flash drive that has been formatted as FAT32 and the USB drive needs to be 32GB or smaller. When you build the media with Acronis media builder, it won't detect a USB drive unless it is formatted as FAT32 already. So if you're using NTFS formatted drives, I'm guessing you're using the .iso and burning it to the flash drives with a 3rd party tool like RUFUS or something similar? If you are, I would suggest formatting the drive with a tool like mintool parition wizard free to make sure that it is properly formatted as FAT32 and that there are no hidden partitions the flash drive (Windows can only see one partition on flash drives and there may be something else on there that you can't see when using diskpart or disk management). Then let Acronis Snap Deploy build the USB disk for you directly.
2nd, as a test, don't use a USB hub (even though you'll need one). For starters, just plug the newly created flash drive into the Surface 3 directly and try to boot into it. If it boots without the hub, but can't boot with the hub, try a differnt hub. Maybe even try a different USB flash drive for peace of mind.
Since you're able to push the image from a local drive, that shows the image is OK - it also shows that the system is capable of booting Acronis media so that's a good sign. With WinPE though, you don't have stand-a-lone deployment and that's why I'm suggesting you try the Linux media which should boot on this machine too. That way, you can actually test the network authentication using the recovery media. I don't have a regular surface 3 to test with so can't say 100% the Linux media will work, but there has yet to be a system I can't get it to boot with and I've tried a lot of systems. v1666 should not only boot, but be able to see an eMMC flash hard drive, standard SATA hard drive and/or NVME hard drives once booted. I have the Surface Pro 3's and it boots fine on it. I have other eMMC flash based hard drive tablets (which I believe the standard surface 3 is using with an ATOM baytrail processor like my ASUS T200, Aspire Switch 10 and various generic tablets like a Fry's Vulcan and a Winbook 8) and all work with SD5 since 1660 - even the 32-bit ones.
If/when you get the bootable media to not only boot, but also to be able to deploy an image from a network share, then you'll be able to confirm the permissions are correct that you're entering to authenticate with. If you can't authenticate, it's either the user account does not have access, or you're not entering it correctly. At least rule it out to be sure and don't guess as resolving the issue takes steps and you can't skip over the basics and assume their working when you have not validated it to be certain.
Regardless of the machine type, the bootable media doesn't care about what hardware it's being run on - only matters that 1) the bios is configured correctly to allow the bootable media to boot up 2) there are drivers that can find the hard drive and the NIC and 3) that the NIC gets a valid IP that allows it to communicate across the network. Once that's validated with the resuce media and network access is working and you can deploy an image, then try a unicast deployment from the server and make sure it works. If it does, then try mulicast.
You may have switching/routing issues or rules in place that prevent multicast - many networks will limit this in an effort to prevent DoS attacks. Who knows though, may not even be an issue and could be something much more simple, but need to step through, test and validate the low hanging fruit and then consider the more in depth afterwards if the easy stuff is working.
What USB to ethernet adapter are using as well? I have had great success with these:
https://www.amazon.com/Anker-Gigabit-Ethernet-Converter-Support/dp/B014…
https://www.amazon.com/Plugable-Gigabit-Ethernet-Network-Adapter/dp/B00…
- Se connecter pour poster des commentaires

Hello everyone,
i've mounted on an old HP 530 Laptot a new SSD disk (empty without any volume). When i've launch the deployment from ADS 5 Management console (release 1660) i received the error "impossibile to resolve the disk". The template is set on "default disk" on the option "disk layout".
Have you got any ideas?
Thanks. Bye
- Se connecter pour poster des commentaires

djtia88, try initializing the disk first and see if that helps. I've had to do this before as well. When restoring the image, it will format it in the process anyway, but not sure why there is a need to initialize the disk first (sometimes).
- Se connecter pour poster des commentaires

Bobbo_3C0X1 wrote:djtia88, try initializing the disk first and see if that helps. I've had to do this before as well. When restoring the image, it will format it in the process anyway, but not sure why there is a need to initialize the disk first (sometimes).
Thank you Bobbo_3C0X1 for the suggestion. I will try to initializing the disk and retest the deployment. I'll let you know as soon as possible the result of the test.
Bye
- Se connecter pour poster des commentaires

Hello Bobbo_3C0X1,
i've tested the deployment with your suggestion, and the process is ended correctly now. Thank you for the suggestion.
Another question. Can i upload the drivers (NIC and Masstorage devices) on an ftp server for the universal deployment of the image?
On the ASD official guide is mentioned only the network share how example.
Bye
- Se connecter pour poster des commentaires

Honestly, I'm not sure as I haven't tried it with FTP before. You can do this with DMV network shares for sure. I will have to test to see if FTP is even an option.
- Se connecter pour poster des commentaires

Bobbo_3C0X1 wrote:Honestly, I'm not sure as I haven't tried it with FTP before. You can do this with DMV network shares for sure. I will have to test to see if FTP is even an option.
OK. At the moment i will upload the drivers on a NAS network share. Can you inform me with the result of this test?
Thank you. Kind regards
- Se connecter pour poster des commentaires

I will try to test in a bit... I currently don't have time at the moment - perhaps later this weekend though.
- Se connecter pour poster des commentaires

I am also getting the error "Failed to resolve disk by number '1'" when trying to deploy onto a Lenovo Yoga 720. I am using the non-WinPE bootable media, and the master image is on a USB drive attached to the deploy server. Once I initiated the deployment, the progress bars on the target system start for a second, then it fails and restarts.
Also the disk on the target system is initialized with Windows 10, booting using UEFI.
Error log from the deployment:
Type: Error
Date and time: Thursday, July 13, 2017 3:27:22 PM
Code: 1 (0x340001)
Module: 52
Message:
Host '192.168.0.108' has failed the deployment.
Additional info:
--------------------
Error code: 1
Module: 52
LineInfo: 6934824D6BD2F69E
Fields: $module : "osd_server_vs_1656"
Message: Host '192.168.0.108' has failed the deployment.
--------------------
Error code: 6
Module: 51
LineInfo: A6EF0BE19DB526B2
Fields: $module : "osd_server_vs_1656"
Message: Failed to resolve the selected disk.
--------------------
Error code: 51
Module: 51
LineInfo: 3E2D5B2FC56679A9
Fields: $module : "osd_server_vs_1656"
Message: Failed to resolve disk by number '1'.
Acronis Knowledge Base: http://kb.acronis.com/errorcode/
Event code: 0x00340001+0x00330006+0x00330033
- Se connecter pour poster des commentaires

Doug, we're deploying 100's of Surface 3 units (non-pro.) I can't speak regarding your other issues, but the trick to PXE booting the S3's with the standard Linux media (for us) is to use official Microsoft USB to Ethernet adapters and disabling secure boot control. Once the units are imaged, you may re-enable secure boot control. Apparently, per support, this is a known-issue and will be corrected. However, I don't see that happening due to the S3's being pretty much EOL.
- Se connecter pour poster des commentaires