A simple, low-cost, inelegant method of virtualizing a physical machine running a Windows server operating system leverages Windows Server Backup and the recovery option of a corresponding OS installation ISO. I’ve used this many times for a quick and dirty way to move a physical machine to Hyper-V but a common issue can lead to wasted time and troubleshooting. This has burned me enough times to warrant documenting the entire process, along with a couple of trivial registry fixes, so as to minimize wastage of time in the future. Note that one benefit of this very unsophisticated approach is that the original physical server remains completely untouched/unmodified, allowing you to rollback to the original network configuration (with the physical server) should some intractable issue get in the way of completing the P2V conversion.

Steps to Virtualize a Physical Server for Operation on Hyper-V

1. Perform a full backup of the physical server using Windows Server Backup to a network location. One variant is to backup to an external hard drive, then attach that drive to a networked machine such as a Windows workstation and access the drive in subsequent steps via a network path (e.g., \\workstation\x$, where x$ is the drive letter assigned to the external hard drive by the workstation you’ve attached it to).
2. Turn off and/or remove the physical server from the network.
3. Boot a “shell” of a VM running on Hyper-V using a corresponding Windows server OS ISO.
   • For example, assume you are trying to virtualize a Windows Small Business Server 2011 Essentials server, which runs Windows Server 2008 R2 as its foundation. Run Windows Server Backup and create a full server backup of the SBS 2011 Essentials server onto a network share.
   • Shutdown the physical server.
   • Create a “shell” VM on Hyper-V with specifications adequate to host the image of the original physical server. If the original server had four processor cores, 8 GB of RAM, and two physical disks of 1 TB each, you could create a corresponding VM with the same specs and with two IDE-attached dynamically expanding empty 1 TB drives.
   • Attach an ISO for “Windows Server 2008 R2 with SP1” to the DVD drive of the Hyper-V “shell” VM.
   • Start the VM.
4. Proceed past the first screen of the installation process but rather than click “Install” on the next screen, click the “Repair” link.
5. Follow the prompts (depending on the installation OS version you’re using) to recover your computer from a system image. Enable networking, then connect to the device and share on which you originally backed up the physical server in Step 1 above. Ideally, choose not to automatically reboot. Why? Because the original server likely had a static IP address and before the restored server can reboot using a dynamically assigned address, there are some important cleanup steps that need to be accomplished before clients reconnect to the newly virtualized server.
6. When restoration is complete, shut down the VM.
7. Using Hyper-V Manager, remove all of the VM’s connection(s) to the live network [keep the virtual NIC(s) active but don’t attach them to the network(s) that the physical server was originally connected to].
8. Attempt to start the newly restored VM.
9. If you encounter a BSOD with a “Stop error code 0x0000007B (INACCESSIBLE_BOOT_DEVICE)” message, oftentimes the issue is very simple to fix. If the steps below don’t work, you will have to do additional research at support.microsoft.com. However, in most cases, the steps below, possibly followed by a startup repair, will be all that are required:
   • Boot the VM with any suitable OS installation ISO that will eventually allow you to run Regedit. These ISOs can include WS 2008 R2, WS 2012, WS 2012 R2, Windows 7, Windows 8, etc. In the case of the example cited above, we could simply reboot using our WS 2008 R2 installation ISO.
   • As we did earlier, bypass the ISO install option and choose to “Repair” your installation.
   • Skip the system recovery options and answer appropriately until you get to “advanced repair” and/or other options that will allow you to access a Command Prompt (if you get lost, you can simply press Shift-F10 in the GUI to access a Command Prompt).
   • Launch regedit.
   • Select the HKEY_LOCAL_MACHINE node. Then from the Regedit File menu, select the option “Load Hive…”
   • At the “Load Hive” dialog box, locate the drive where the restored OS is located (e.g., C:) and select the SYSTEM file located in \Windows\System32\Config. For example, if your boot ISO was assigned the X: drive letter and your boot OS volume was assigned the D: drive letter, you would load the SYSTEM hive located at D:\Windows\System32\Config. You will be asked for a name to assign to the loaded hive. Pick something easily distinguishable from the other nodes in the Regedit tree so you can easily locate it under the HKLM node.
   • Find and set the following three “Start” values located under the Services node of the mounted SYSTEM hive:
     Intelide, 0
     Msahci, 3
     Pciide, 3
     Note: One ore more of these may be “incorrect” because the system image restore process does not modify these values and they may be set to match the configuration of the physical server. However, once virtualized, the “incorrect settings” may make the new virtual disk inaccessible to the VM (unless the above Start values are changed to the settings shown above). There are many variations of this theme, depending on the types of disks/controllers in the original physical server.
   • Select the node in the Regedit tree corresponding to the name you assigned to the loaded SYSTEM hive, and from the File menu, choose “Unload Hive…”
   • Exit Regedit.
   • Exit the GUI installation/repair interface and allow the VM to boot. If the above technique resolved the “inaccessible boot device” error, you will eventually see your newly virtualized server boot properly.
10. With the new VM still off the original network that the physical server was connected to, use a process to reveal and remove any “ghosted NICs” [which can prevent you from successfully assigning the same static IP address(es) to the new virtual NIC(s) that was/were used by the physical NIC(s) before virtualization)] One approach to identifying and removing “ghosted NICs” is as follows:
    • Log into the new VM.
    • Launch a “Command Prompt” with administrator-level access.
    • Type “set devmgr_show_nonpresent_devices=1” followed by pressing the Enter key.
    • Type “devmgmt.msc” followed by Enter, which will launch Device Manager.
    • Choose the option from the View menu to “Show hidden devices”.
    • Drill into and select any “ghosted” (grayed-out) entries under “Network adapters” (should be one or more corresponding to physical NICs in the original server), right-click, and select “Uninstall”.
11. With all “ghosted NICs” removed, set the desired static IP configuration(s) for the virtual NIC(s) of the new VM.
12. Shut down the VM’s operating system.
13. In Hyper-V Manager, connect the virtual NIC(s) to the appropriate networks that will result in your virtualized server operating on the same network(s) that the physical server was originally on.
14. Start the VM.

A recommended follow-on cleanup process for fellow server maintenance purists is to use the same procedure detailed in Step 10 above to identify and remove all “ghosted” legacy entries for physical components (processors, drives, controllers, etc.) that are no longer pertinent for the virtualized server.