Monday 22 March 2010

ShadowProtect Restore to Hyper-V VM Tips

Here are a couple of tips to get the restore working relatively quick:

  1. Use the Legacy NIC in Hyper-V if the restore files are on a network share.
  2. Use only 1 virtual CPU to run the restore.
  3. Use the Integration Services drivers as part of a Hardware Independent Restore for the guest OSs:
    1. Extract the contents of the VMGuest.iso to an architecture specific folder.
      1. msiexec /a Windows5.x-HyperVIntegrationServices-x86.msi /qb targetdir=c:\temp\x86
      2. msiexec /a Windows5.x-HyperVIntegrationServices-x64.msi /qb targetdir=c:\temp\x64
    2. Use a utility like CDBurnerXP to place the extracted content into an ISO file.
    3. Mount that ISO file when it comes time to run the restore in SP.
    4. Install _every_ driver that is in the \Hyper-V Integration Services folder for the required architecture.
      • image
    5. Boot into the OS and clean things up HIR style (previous blog post).

The WinRE used by ShadowProtect will not pick up the Hyper-V NIC by default. So, run the restore with the Hyper-V legacy NIC in place. Once the restore is complete, shut down the VM and switch out the Legacy NIC for the Hyper-V native NIC.

This is what a restore looks like with 2 virtual CPUs for throughput:


This is what a restore looks like with only 1 virtual CPU:


So, somehow having anymore than 1 virtual CPU enabled causes a real problem with not only the restoration process, but navigating around the ShadowProtect recovery GUI too. Things are a lot more responsive with just 1 vCPU.

Using the above procedure will yield the following on a Windows 7 P2V:


The 100MB system partition that Windows 7 creates during its install routine is not needed to restore the OS as a Hyper-V guest. We needed to use the Hardware Independent Restore process to get beyond a BSOD 0x0000007E.

Philip Elder
Microsoft Small Business Specialists
Co-Author: SBS 2008 Blueprint Book

*Our original iMac was stolen (previous blog post). We now have a new MacBook Pro courtesy of Vlad Mazek, owner of OWN.

Windows Live Writer


Absoblogginlutely! said...

Interesting you posted this after the hassles I had this weekend with shadow protect (and still having).
Out of curiosity have you had issues with drives getting incorrect drive letters if you don't restore all drives in the right order?

Philip Elder Cluster MVP said...

To date, we have always had to boot into Safe Mode after a server restore with multiple partitions and restructure the drive letters.

I don't recall ever seeing the correct letters come back with SP. They have always gone C, D, E, etc.

Now to figure out why I am getting a weird trust error on the Windows Driver Framework portion of the IS install on the TS box. :(


Absoblogginlutely! said...

Phew - glad it's not just me then. I did find that restoring c, then creating a D drive (which would normally hold all the data but i don't need it for my testing) and using the browser to save a couple of files to D and then restoring the E partition gave me drives back in the right order (instead os switching D and E) and I didn't have to go to DSRM mode....but now it needs activating and logs me off after I say Yes to Activate with MS.

Philip Elder Cluster MVP said...

Yeah, lots of fun.

We unpacked the Hyper-V IS into its folder structure then ISOd that content.

We then ran the HIR in SP and installed the IS component drivers into the OS as part of the restore.

We now have a booting SBS which was not the case during the first run where HIR was not used.

Going to flatten the TS and restore again using HIR and the IS drivers. Hopefully we will get further along with it.


Unknown said...

So far I've found the easiest way to restore drive letters is to do it within the recovery environment itself (Hidden well in Tools > Boot config utility > untick Hide Advanced Options > select additional boot tools > drive letter, along with a few other handy options)

Philip Elder Cluster MVP said...


Awesome tip! :0)