Requesting help. Moving a slow SBS 2003 system onto HyperV on Windows Server 2012.

I am trying to prepare.  Any discussion, links to documents, suggestions are greatly appreciated.

Old SBS 2003 running on outdated hardware. 

A) Buy a new server running Windows Server 2012
B) Image the 2 volumes of an old SBS 2003 system.
C) Restore these images INTO HyperV on new hardware.

I have never used HyperV before

Procedure help.  I need to start somewhere!

Thank you





It's pretty straight

It's pretty straight forward.

You'll want to create fixed size VHDX disks for your new VM that are at least the same size or bigger than the original volumes.

Your OS volume must be attached as an IDE disk, your data volumes can be attached as SCSI disks.

Create a share on your hyper-V server for ISO files, copy the ISO for the recovery environment in to it.

Create a new VM and attach the necessary disks, configure it to use the ISO for the recovery environment for the dvd drive.

If you want to minimize downtime and you have a good amount of data to restore, you can start the restore while continuing to run the sbs 2003 system.

You'll first want to disable the ImageManager service so no collapse work is done, if a collapse runs when you're in the middle of a head start restore you won't be able to finalize it.


Then you can restore your volumes, unchecking the option to finalize the volume at the end of the restore.

when your first restore run is completed, run one final incremental of your source machine and shut it down.

You can then run the restore wizard again, and choose the restore subsequent incrementals option, this time checking the option to finalize the volume.

Also on your OS volume you want to check off the hardware independent restore option.

On your first boot, boot in to safe mode w/ networking and confirm that the drive letter assignments are identical to what they were on the source machine.

If the NIC driver was installed, configure the same IP that your source machine had.

You may need to boot in regular mode, install the hyper-V integration components, reboot again in safe mode w/ networking to assign the proper IP.


That's really all there is to it, it sounds like you're buying the full version of windows 2012 so you'll have a gui to work with.

One thing which is a pain with hyper-V 2012 is you can only manage it from systems running Windows 8 or 2012.

the MMC for windows 7 doesn't support many features like VHDX files, although you can just use powershell CMDlets to create and attach VHDX files to a VM.


Basically you may need to use New-VMHardDiskDrive to create a fixed size VHDX and  Add-VMHardDiskDrive to attach it if you have no windows 8 clients and are installing the free version of hyper-v server 2012 or using server core.

 i have done this recently and it went very smooth, although I was using the free hyper-v server 2012 so i had to make use of a combo of the MMC management snap-in on windows 7 and powershell to create + attach VHDX files to the new VM.

You could do it all in powershell but it's certainly easier to create a VM in the MMC hyper-v manager.

Also i would recommend running the hyper-V host server in a workgroup and not join it to the domain.

Otherwise if your VM goes down that's your only domain controller you won't be able to manage your hyper-v system since you can't authenticate.



As listed in this thread it's

As listed in this thread it's not too difficult to restore from a physical box to a virtual box.  When restoring from an SBS environment the only issue you may run into (also somewhat stated) is the NIC on the machine.  A lot of the time things will go through without issue however there are times where you do the restore and you'll get to where the logon screen is and it will hang.  This is because it's trying to load the old NIC for the domain/active directory.  To work around this you can boot into Active Directory Restore Mode, remove the old NIC, reboot into normal mode, reconfigure the new NIC.

-------------------Active Directory Restore ------------------------------


                When you are restoring Domain Controller with Active Directory Services the process is the same as any restore but there are a couple extra steps to get the machine back up and running.  If the restore is to the same hardware you may not need to go through this process but it is recommended to do so.

Recovery Environment:

                Restore the backup images using the standard process through the Restore Wizard.  Once all of the volumes have been restored you will want to ensure the primary partition is bootable.  To do this you will use the “Boot Configuration Utility” which is located in the tools drop down menu. 

                Once you are in the “Boot Configuration Utility” you will see a check box in the lower left corner of the screen that is labeled “Hide Additional Tools”.  Uncheck that box and you will then see a “Diagnose” button in the upper right area of the screen.  Once you select that button it will show some info in the lower text box.  As long as everything shows as ok the system is ready to be rebooted

Active Directory Services:

                This is where the extra steps come into play with an Active Directory restore.  Before booting into Windows normally you will need to boot into the “Active Directory Restore Services” mode.  To do this you will need to tap the “F8” key (just like safe mode) to access the boot menu for Windows.  Select the “Active Directory Restore Services” and boot into that mode.

                Once the “Active Directory Restore Services” has loaded, open a command prompt with administrative rights.  Then type the following commands:

“Set devmgr_show_nonpresent_devices=1” press enter (Enables non-present drivers to be shown)

“Devmgmt.msc” press enter (Opens the Device Manager)

                Once the device manager is open, select the “View” drop down menu and select “Show Hidden Devices”.  Then navigate to the “Network Adapters” in the device manager and remove the grayed out non-present drivers (mainly the previous network driver).  Once those are cleared out, reboot the server

Regular Mode:

                Once the drivers have been removed from the Active Directory Services mode then the server should boot to a desktop.  Beware; this can take a while depending on the roles of the server.  Once you are at the desktop you will need to make sure the network drivers are loaded and functioning.  You will then need to configure the adapter with your network configuration settings. 

                Once that is done you will need to fine tune the drivers for the server and the process will be complete.  If you have further Domain/Active Directory issues then you may need to contact Microsoft for further assistance.


Which ShadowPrortect version do I buy?

I will be creating an image from the old SBS-2003 machine.
I will be, as discussed herein, restoring that image to the HyperV virtual machine on this new hardware running Server 2012.

Once this work is done, I will be using StorageCraft to take periodic backups of the new machine (and it's new SBS-2003 Virtual Machine).
So here's my question:  What version of ShadowProtect do I need to buy for this scenario.

Please understand:  Neither server (old or new) is using StorageCraft now.
I need to buy ShadowProtect to create the images of the old (pair of) volumes,  Then I will transfer that license to the new box for the initial restore and for ongoing daily backups.
What version of ShadowProtect do I need to buy for this scenario.
I have seen ShadowProtect SBS ($495) and ShadowProtect Server ($995).

Thank you again





ShadowProtect 4.2.7 would be

ShadowProtect 4.2.7 would be the best version to run on the machines.  Currently that is our latest version.  When setting up your new server it would be highly recommended to put the Hyper-V Virtual Disks on a separate volume then the primary OS.  If the server host is being backed up and the Virtual disks are stored on the same drive then you will run into pauses on the VM systems.  This is caused by VSS taking the snapshots.  A booted VM isn't "VSS" aware so it will hang during the snapshot process.

So make sure your new server has a partition/drive for the OS and then a separate partition/volume for the virtual disks.  Then you will want to have ShadowProtect installed on each server that you are running.  This way each machine will have it's own backups in which you can restore from.


Correct version

Isn't it true, that, at one time, you had to buy a Server version of the SC software?
So, when you wrote:  ShadowProtect 4.2.7, did you mean "the regular $89 version"?  Or did you mean one of the "server" versions.
That is what I meant by "version".  I didn't mean whether to use 4.2 or 4.1 or 3.5.  Sorry.
And, again:  Whatever I buy will be used first on the old server - to get the image.  Then, on the new server to restore the images into the HyperV VMs.  I know I will need to davtivate and reactivate.
Thank you



I now know what version (edition)

I've spoken to SC sales (very helpful).
I've learned the following:
- Use a trial version to take the images on the old machine.
- Buy the "Virtual edition" for the new machine.  Use it in the virtual machine.
- Use another trial version to take a lone image of the physical machine.
So, I'm OK on this part.



Which version (edition) - I know now

I've resolved the version/edition question.


I'm glad you were able to get

I'm glad you were able to get the info you needed.  We appreciate all feedback on these forums so if you run into any new problems please feel free to post them here (in the forums).


Well.  I got it done.  Some

Well.  I got it done.  Some certain people helped me a LOT. 

In doing this, I hit a few brick walls.  Those include:
a.  It is not enough to create the Virtual Disks.  You have to initialize them.  Otherwise, the Recovery Environment doesn't see them.  The Recovery Environment DOES see them in the Disk Map.  And, I am guessing there is a way to initialize them in the Recovery Environment.
b. Be advised.  Hyper-V doesn't support USB.  So, if you want to do backups, consider creating a virtual backup drive.  Then let a connected machine copy those backups to a USB drive.
c.  In deleting the old NIC card, wacth out for this:
You need to delete the old, not-present NIC cards.
I went into Device manager.  I didn't see them.  I then selected Show Hidden Devices.  I still didn't see them!
So, as written by STC-Court, you MUST do exactly this - (or you will cry).
“Set devmgr_show_nonpresent_devices=1” press enter (Enables non-present drivers to be shown)
“Devmgmt.msc” press enter (Opens the Device Manager)
Once you do this, you can delete this old card.
UNTIL you do this, you will have no IP.
d.  I had to tell my BIOS to enable Virtualization before I could create a Virtual Machine.
e.  Nowhere in the above help is the following mentioned:
You need to click on Action -> Insert Integration Services Setup Disk
If you don't do it, you will have driver issues that will thwart your progress.
f.  I had ShadowDesktop installed on the old server (the box I was virtualizing).  When I launched it on the new, virtualized system, I was told the trial had expired (which it hadn't).  I know why.  Now, that would be simple to remedy, if you had IP, which I didn't at that point, so I had to go through a manual activation.  (I like to take lots of backups, even intermediate backups).

There are good videos on YouTube about installing Hyper-V and creating a Virtual Machine.  They helped me.

I found this blog very helpful.  It uses Disk2VHD, instead of StorageCraft.  I did not try it.  I think that wold be more efficient, if it works.

Mega-thank yous, to all who helped me on this project.
I am left with a few questions, neither critical.
- In such an install, is it proper to join the HOST to the network?  I guessed "no" and did not, but it would have been convenient.
- A StorageCraft question:  In backing up the source drive, which were apparently 2 partitions on one physical drive, I got weird stuff during recovery.  I restored C and saw it as the left partition in a row of 2 or 3.  When restoring the other drive (F), I saw it as the second partition in the row of 2 or 3.  I guess this is the realm of dynamic drives or something.  I wish I understood it more clearly.



I'm glad you were able to get

I'm glad you were able to get this up and running.  As for "Disk2VHD" that may do what's needed.  ShadowProtect is a backup/restore application.  We (as you know) also include the abiltity to "restore" to the same machine or a different platform.  With having the ability to restore to a different platform means you can use ShadowProtect to migrate from one machine to the next (physical/virtual).

One thing that is nice about ShadowProtect and this process is when you're looking to either build a new server to replace an existing server or going virtual is that you can do a "HeadStart Restore" of sorts through the recovery environment.  Your active server needs to be running at all times and it's constantly making backups.  So what you would do is boot to the recovery environment on the new platform and go to the restore wizard.  Here you will select the chain to restore but when it asks if you want to finalize it you will select to not.  At this point it will push the bulk of the backup chain to the new machine (in some cases this can take hours or days depending on the data).  Once the bulk of the backups are done you can schedule the original machine to be shut down and then push in the backps that were created since the original restore (in most cases doesn't take long at all).  Reboot the new server and configure the NIC and when it's back online your data is 100% caught up with very minimal down time.


HeadStart restore trumps Disk2VHD

Dear STC-Court,
This particular installation was very, very small.
In this case, Disk2VHD might have been easier and faster.
In larger installations, as you've shown, SC would be better because of HSR.




HeadStart restore trumps Disk2VHD





Hyper-v Backup to USB

Just an FYI, for what I usually do on my hyper-v servers.  I connect the USB drive directly to the host.   In hyper-v I create an internal network on a seperate subnet.   On the hyper-v server, install the file services role, and share out the USB drive.   Map to the shared USB drive from the VM using the private network created.   Technically you can also use the regular LAN connection for sharing, but technically I'm not sure if there would be a performance impact on the network during backups, so I just always create the internal network in Hyper-v.

As for you question regarding connecting the Hyper-v to the network.  Do you mean add it to the domain, or physically cable it into the network?  You will only want to add the Hyper-v host to the domain if you have additional domain controllers that do not rely on this physical server.  If you have the ability to add additional DCs, then I'd recommend adding the hyper-v server to the domain, as it makes management easier.




seperate subnet and Hyper-v host to the domain

Sharing USB:
In hyper-v I create an internal network on a seperate subnet.
Can you elaborate a bit on the specifics of how to do this?

Putting host of the domain:
The installation is tiny.  One server and 3 workstations.
Can I safely put the Host on the domain in this environmnet.


In hyper-v manager, on the

In hyper-v manager, on the right side, click on Vritual Switch manager.  On the new virtual switch area, select internal, and create virtual switch.  Name it something like Internal and save it.  Now on the host, you will have a new network adapter.  Go into the IP settings and give it a different private IP than your LAN, such as  You need a subnet mask but no gateway.  Next, you need to add this adapter to your VM, so shut down your VM, go into the settings for the VM, select Add Hardware and choose Network Adapter.  Select the Internal switch and save it.   When you boot your VM, you should have another adapter in which you'll give it another IP, ie.  On the hyper-v server, choose Manage, Add roles and features, and install the File and Storage services.  Now you can share your directly attached USB device and map it from the VM using the IP.  I don't know exactly if performance is improved by using the internal switch, but logically it makes sense to me.

As for adding your Hyper-v Server to the domain.  Don't do it in your case.   If you do, what happens when the server reboots and the VM doesn't boot?  Best case, you get delays in the Host server booting up because the DC isn't available.  Worst case, credentials aren't cached and you can't log in.  Leave the Hyper-v server on a workgroup, and just try to remember to manually update the passwords when you do it on the DC.  If at any point you add another physical server, put a VM on it thats another DC, then you can add your Hosts to the domain.


Backup stratefy for Virtual SBS-2003 in HyperV?

The virtual machine (VM) has 3 disks:  C: - O/S, F = data, S - image repository
These 3 virtual disks (VDSK) exist as 3 .vhdx data files on the D drive of the host.

If the VM were to crash and require a restore, would it be sufficient to simply restore these VDSKs?
Is a good backup strategy for this installation (one VM running in Hyper-V):
   Run ShadowDesktop on the Host
   Back up the Host to USB

Presently, I run ShadowProtect in the VM.  I suspect this may be wrong - especially since I haven't yet implemented the VM sharing the Host's USB - as suggested, just above, by craigeb78.  I am currently copying these backups (on S) to a USB drive on a network workstation. 

Thank you




Backup stratefy for Virtual SBS-2003 in HyperV?

I'm sorry if this appears twice.  I entered the whole thing and then didn't see it.

I am currently running ShadowDesktop in the VM.  I am not running it in the Host.
The VM has 3 Virtual disks (.vhdx).  These exist as data files on the D drive of the Host.

Is it an appropriate backup strategy to -only- back up the Host?
Then, if the VM needed to be restored, I would restore these 3 .vhdx files?

Please educate me on this.

Thank you


It's not recommended to

It's not recommended to backup the virtual disks on the host system.  You will want to install ShadowProtect on each VM and run the backups indevidually.  The reason behind it is this, everytime a backup would take on the host it will halt production to capture the data on the drive (meaning the virtual disks) until the snapshot has taken.  It then writes the data into the backup image.  Now, the VM's were in a crash consistant state and therefore may have missed data.  When ShadowProtect takes a backup it will use the VSS writers to capture all the data that is in memory to the drive and then redirect the flow back to memory while the snapshots are taken.  If you just backup the virtual disks this process doesn't happen.

Next the backups will be very large due to the size of the virtual disks and the amount of data that changes within them.  This process also makes a restoration a lot more difficult.  Yes you can mount the backup and copy the images over but there isn't a way of easily testing the backups and therefore you may find that the data captured is not usable when you really need it.  

So no, you don't want to backup the host drive with the virtual disks on it.

Terms and Conditions of Use - Privacy Policy - Cookies