Here are a couple of tips to get the restore working relatively quick:
- Use the Legacy NIC in Hyper-V if the restore files are on a network share.
- Use only 1 virtual CPU to run the restore.
- Use the Integration Services drivers as part of a Hardware Independent Restore for the guest OSs:
- Extract the contents of the VMGuest.iso to an architecture specific folder.
- msiexec /a Windows5.x-HyperVIntegrationServices-x86.msi /qb targetdir=c:\temp\x86
- msiexec /a Windows5.x-HyperVIntegrationServices-x64.msi /qb targetdir=c:\temp\x64
- Use a utility like CDBurnerXP to place the extracted content into an ISO file.
- Mount that ISO file when it comes time to run the restore in SP.
- Install _every_ driver that is in the \Hyper-V Integration Services folder for the required architecture.
- 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
MPECS Inc.
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.
6 comments:
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?
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. :(
Philip
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.
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.
Philip
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)
Alex,
Awesome tip! :0)
Thanks,
Philip
Post a Comment