Unable to Auto-Match Disks - Windows 10

[MarkKoester]

Hello all.

I recently needed to replace Surface Pro 4 so I took a successful full system restore prior which is on an external USB-connected SSD. On the new Surface, I was able to boot to the USB stick I created during the software installation on my old Surface. VEB has no issue finding the successful backup location on the external SSD. Under "Restore Mode" when I select "Entire Computer" VEB cannot auto-map my drives and it puts me in manual restore mode. That step can only see Disk 0. I've gone through all of the files/folders on the USB recovery media and the external SSD where the backup files reside but I still cannot see another hard drive under this step.

I've been through http://helpcenter.veeam.com/endpoint/11 ... ource.html but can't seem to get the second disk recognized for restore at this point. Any suggestions?

-Mark

[tomtomnavigator]

Is there more than 1 drive installed in the Surface 4?
Disk 0 is the internal drive?

If so you you have to manual match the partitions to the internal drive like shown here:
http://helpcenter.veeam.com/endpoint/11 ... ource.html

[Dima P.]

Hi Mark,

external USB-connected SSD

Bare Metal Restore to external USB devices is currently not supported.

[MarkKoester]

I'm trying to use a USB-connected external SSD as the source for bare metal restore. The destination is the Surface's internal drive. Sorry if that wasn't clear in my initial post. Is that a supported configuration? If so, what can I do to get it to work?

[Dima P.]

Thanks for the clarification – yes, the USB device as a source is fully supported (sorry - I may need another coffee jug). Can you clarify how many internal disks you have in your Surface?

[MarkKoester]

Just one internal disk on the Surface. In total, I've got the internal disk, a USB-connected external disk where the backup files reside, and the USB stick used to boot into VEB. VEB can see the external USB disk as a source file but then I cannot get a second drive to show up when trying to manually match partitions. Automatic selection doesn't work. Looking forward to your suggestions on next steps!

[Dima P.]

I see. Could it be protected by BitLocker? Also what if you run a diskpart list disk while booted into recovery media (cmd can be started from the Tools menu)?

[MarkKoester]

I've never booted this Surface into Windows as it's a brand new replacement for my previous Surface (same CPU/RAM/SSD/OS). What I've read online is inconclusive as to Bitlocker being on by default so I'm not sure if it's on with the Surface I'm restoring to. The Surface where I'm restoring from (as backed up to the external SSD) was not protected by Bitlocker as best I know (I don't recall enabling it or setting a Bitlocker password).

Running diskpart list disk gives me three disks: 0, 1, 2. All are online. 0 is 238 GB and GPT *. 1 is 298 GB. 2 is 7800 MB. 0 is the only one where GPT has an *. Listing the volumes results with 5: 0 is drive C / Windows / NTFS / Partition / 237 GB / Healthy. 1 is SYSTEM / FAT32 / Partition / 260 MB / Healthy / Hidden. 2 is Windows RE / NTFS / Partition / 920 MB / Healthy / Hidden. 3 is drive D / <no label> / NTFS / Partition / 298 GB / Healthy. 4 is drive E / VEEAMRE / FAT32 / Removable / 7799 MB / Healthy.

[Mike Resseler]

Hi Mark,

Dima is correct. Every surface pro comes with bitlocker enabled by default. Since it is a different surface, it is also a different encryption key. Best you can do is actually boot that new surface, get the encryption key and use that to unlock the disk when you want to do BMR from your previous one. Our solution can not now what the newest encryption key is so therefore it is an issue to see the volumes

Cheers

Mike

[MarkKoester]

Perhaps it's different in EMEA, but I booted the Surface into Windows 10 and confirmed that BitLocker is off by default. Based upon this http://helpcenter.veeam.com/endpoint/11/bitlocker.html I'd expect that if a drive were protected by BitLocker that I'd get prompted to type the password for that volume which didn't happen. I agree, Mike, that VEB shouldn't be able to work to see inside an encrypted volume without having the key to get into the volume. Unfortunately, that doesn't seem like the case here. The issue in this case is that when I went to do the restore I couldn't event see the volume during the restore step but I could see it earlier in the process.

I appreciate everyone's help on this. At this point, I've thrown in the towel on getting the full system restore to work and am restoring individual files / directories instead. I've got VEB installed on the new OS and the restores are going very quickly. I'm headed out on a trip in a few hours and would like to take a functioning Surface with me else I would have been able to further dig into what was causing the issues with the full system restore. As-is, I'm done with the file restores and have a few additional pieces of software to reconfigure.

-Mark

[Dima P.]

Mark,

Any recovery logs left on your end? I’d like to pass it to QA team for investigation.