We need to get to images restored into VMs running on Hyper-V for the test Swing Migration we are doing for the messed up “Professional” SBS in this post.
The deeper we are digging into this the more and more it may be a good idea to start fresh and work the client workstations from there.
But, we have committed to the business owners to run through the Swing test anyway, so we are well into it now.
The existing SBS was imaged using ShadowProtect and has been restored to one of our lab servers using the Hardware Independent Restore feature. We cleaned up the IBM XServe hardware pieces in the Device Manager and made sure that the lab server hardware drivers were installed and stable.
- Cleanup methodology blog post: SBS & ShadowProtect - Some Hardware Independent Restore considerations.
We are running a portion of the Swing virtually with the NewSBS ending up on the same lab server we have the restored SBS on now which is a Swing Off and Swing On again.
On this particular SBS network there is a Terminal Server. So, we took an image of it as well as one critical workstation. We are restoring both images to VMs running on Hyper-V Server 2008 (yes, we got it up and running though with no add-in RAID controller).
When we went to boot from the ShadowProtect I.T. Edition ISO in the VM, the WinRE would choke on the networking portion of the ShadowProtect startup routine. We ended up needing to uninstall the standard Hyper-V NIC and use a Legacy NIC to get things rolling. We were using the Windows Vista WinRE version too.
We placed the two ShadowProtect images on a network share to run the restore process in the Hyper-V based VMs using drive mapping feature in the ShadowProtect recovery environment.
When it comes to restoring an encrypted ShadowProtect image that is password protected using AES 128bit security, CPU crunching capabilities and GHz speed sure make a huge difference on the restore times.
Microsoft Small Business Specialists
Co-Author: SBS 2008 Blueprint Book