Archive for the ‘Virtual Machines’ Category

yes, Virginia, there is a Santa Claus who can help you convert your physical SBS server to a virtual machine to run under Hyper-v.  But dear, they don’t tell you nearly enough, so pay careful attention to this.  Especially if you want to user the same server box to be your new Hyper-v host machine.

Preliminary Work

The assumption is that you have SBS installed on a physical machine.  You would like to use that physical machine as a Hyper-v host.  How can you convert SBS to a virtual machine?  And what does it take to host Hyper-v on that box?

If your SBS is 2008 or 2011, you needn’t worry about whether the server can support 64-bit because both of those are 65-bit operating systems.  If, however, your starting point is SBS 2003, you need to verify that it can run a 64-bit OS.  If your server is from around the time when SBS 2003 was first released, I suggest you look at a new server to save yourself a lot of frustration, time and eventually money.  You can purchase a lovely box from Dell, HP and others for about $1500.  Then  you can do a migration to SBS 2011 between two physical boxes.  See my post about setting up SBS 2011 as a virtual machine and do the migration to it.

Once you are convinced your current server box will support the Hyper-v host os, check on how much memory you you have.  I would recommend16GM as the minimum necessary for a successful system and as much more as you can add past that to accommodate the number of virtual machines you plan on hosting.

I have a few virtual machines for SBS running between 8GB and 16GB and all give more than satisfactory performance.  They run along with 4-8 other virtual machines (other 2008 R2 servers, Windows 7, and XP operating systems). More memory is better of course  but you may find the marginnal benefit of 1GB more memory to not show up in the other vm performance .

Now you have determined a proper machine to host Hyper-v with sufficient memory.  It is my very strong suggestion that you now purchase new disks for the OS hosting environment. Why? Because if something goes wrong in the conversion, you don’t want to have clobbered your original system disks to be able to go back to a physical machine.  I know the cost and complexity of new system disks will vary from installation to installation, but disk prices have dropped so much that the cost of even a pair of 500GB (RAID 1 scenario) is under $100.  What is your time for recovery worth:?

The last thing you will need is a disk that can house the .vhd created on the physical installation to be copied to the new os environment for the virtual machine.  An external USB drive is perfect for this, but an internal hard disk that can remain mounted when you create the new hosting environment works well, too.

Cleaning Up the System

Before you convert to a .vhd, do as much cleanup on your SBS system as possible.  Not only will this make the conversion faster, it will make it easier.  And in some cases, it can mean the difference between success and failure.  The conversion utility will convert up to 127GB, so if you have too much data on your system disk, it may not convert at all.

Here are some suggestions:

  1. Move your Exchange data files to another hard disk.  As a rule. I never leave them on the system volume.
  2. Do the same with your SharePoint data files.  Same rule for moving it to another disk.
  3. Move any user profiles to another disk.
  4. If you have any data files that are shared, move them as well and update the share.
  5. Empty the recycle bin.
  6. Delete any temporary files.

In short, anything that is on your system disk that is not essential to the system either delete or move.  Note: if files are small, weigh the inconvenience of moving them against the conversion impact.  A few kilobytes won’t make a difference but a few gigabytes might.

Disk2vhd Utility

You will need this free and downloadable utility to convert your system disk to a .vhd file (click to download it).  It is straightforward to use and can work with a system that is online.  I will share with you some of the tricks I have picked up to make it easier for you.

Disk2vhd works by taking a snapshot of the files to be converted.  What you don’t want to happen is have those files updated while the conversion is running, possibly causing data consistency issues.  Exchange is a case in point, so before you start the conversion, stop Exchange services.  Do the same for SharePoint and any other applications that might be updating files as they run,

If you have been following closely about the preparations, you will have detected my overall approach:  isolate the system to the c: drive, convert it to a .vhd, bring up the new os and create a virtual machine from it, and have all of the data files remain on media that are mounted onto the host operating system.

With that in mind, when you run the conversion utility, you will be just converting the system disk.


In the above example, I have isolated Exchange, SharePoint and user data and even have a separate drive to store the .vhd file.  (Remember, I am a big iSCSI fan and this is a piece of cake to do).

Much  more important, however, is to note that I have selected not only drive C: but the System Reserved area as well.  If you don’t select the System Reserved area, the resulting .vhd will not be recognized as bootable.  When you try to attach it as a virtual drive and start the machine, you will get the following messages:

disk error has occurred
Ctrl+alt+del to continue

But of course there is nothing to continue to.

Choose your destination for the .vhd, then click Create.  It can take thirty minutes to over an hour, so entertain yourself while it runs.

The Hyper-v Host

Now shut down the SBS system, remove the system disk(s), insert the new disk(s) for the host os, and install the os.  If you have a license for Windows 2008 R2, use it by all means.  If you don’t own or want to pay for a license, you can download Windows 2008 Hyper-v for free.  Be aware that it has only a limited interface and that you will need to do enable remote execution of Hyper-v manager on it to be effective.  Still, it is free.

Install the os and launch Hp yer-v manager.  Create a new virtual machine following the wizard.  But instead of creating a new .vhd, instead point to the .vhd you created with the disk2vhd utility.

Before you start the virtual machine, adjust the settings as follows by highlighting that vm and clicking on settings.

  1. Memory – use dynamic setting.
  2. Processor – use the number of virtual processors that match the host cpu.
  3. Network adapter – you can use the same adapter as the host machine or an additional one.
  4. iSCSI Controller – Use this to add disk drives attached to the host system.  For example, if you have USB drives (for backup, e.g.) connect them to the virtual machine.  Same for data drives.  Note – if you are using iSCSI targets, the virtual machine can connect directly to them without adding them as hardware.

Now start the virtual machine.  What you will discover is that it doesn’t start right up like you would think.  Instead, it appears to be “hung” without the desktop appearing.  This could take from five to thirty minutes.  What is happening is that SBS is adding new devices to the system as they have been attached through the virtual interface.  When that is complete, you will get a message that new hardware has been added and you should reboot.

After the reboot, check the network settings to make sure they are correct.  You may have to run fix my network or connect to the internet wizard from the SBS console.  Check to make sure all services are properly started and that Exchange connected to the databases.

Your virtual SBS is now complete and you can add other virtual machines as necessary.


I was pulling my hair out, wondering why the clock on client machines in a SBS 2011 domain were off about 5 minutes fast.  Surely the server time was the issue, and I kept resetting it only to see it go back to its five minutes fast setting again.  So I rolled up my sleeves, dug into all the command options of w332tm and registry settings, and they all looked fine.  My server was set to use

Why didn’t this work?

I finally paid attention to the result of this command:

w32tm /query /status

I slapped my forehead and also did another command

w32tm /query /source to amplify the results I was looking for

Here is what I got

Since I had set the time server to, I was puzzled why that time server did not show up and what the heck was VM IC Time?  Almost instantly it hit me: the hyper-v SBS 2011machine was getting its time from the host, and my settings were not overriding that.

Sure enough, I looked at the host machine (not part of the domain) and it was not using an authoritative time server and was – gasp! – about 5 minutes fast.  A few simple things fixed it all.

On the Hyper-v Host

From either the control panel or time in systray, set the computer clock.  Click on the Internet Time tab and if it is not set to synchronize, click Change Settings…. In the dialogue box that appears, click the Synchronize box and leave the server as or change to another value.  Click update now button, then OK to close.  Click OK again.

On the SBS 2011 Server

Open a command prompt in elevated mode (run as administrator).  Enter this command

w32tm /resync

You should see the clock change to match the value on the hyper-v host machine.

On Client Machines

You will see the time change when the client machines follow the time synchronization schedule, but you can do it immediately if you want.  Use the procedure above for the SBS Server but on your client machines.

That’s it.

There’s Another Way……

This made me think, there’s gotta be another way to deal with this.  Sure enough, a bit of snooping led me to play with the hyper-v host settings, and here is a way to let your SBS 2011 hyper-v machine throw off the shackles of the host time server.

On the hyper-v management console, click on the SBS 2011 server and choose settings.  On the left hand pane under Management, click on Integrated Services and clear the check mark next to Time Synchronization then OK or Apply.  You can actually do this while the hyper-v machine is running.

Once you have done this, log onto the SBS 2011 server, run command prompt and type

w32tm /query /source

You should now see the source changed to or whatever other time server source you have configured.

Either method you choose will work, but I prefer the change in Integration Services to make your SBS server less dependent on its host.

I am currently doing a migration from Windows 2003 (not SBS) to SBS 2011 for a client.  The didn’t want to invest in new hardware since their server was a fairly recent vintage and needed only a bit more memory.  My plan for them is to:

  • Physically locate their server in my office on a new network segment;
  • Set up their router to get a static IP address from my network;
  • Configure parent DNS to point to this new network segment;
  • Run Migration Prep Tool on the old server;
  • (all of the above done
  • Create an answer file for the migration and store it on the desktop of the host OS machine that runs hyper-v (see additional comments later);
  • Install Virtual Clone software on the parent OS of the hyper-v machine;
  • If you have an .iso of the SB 2011 install disk, make sure it is somewhere in the disk space  of the parent OS hyper-v machine and mount it on the virtual drive.  If you have a physical DVD, insert it in the drive on the parent OS machine.
  • Create the virtual machine for SBS 2011.  Make sure you assign a network connection so it can talk to the local network as well as have Internet access;
  • Capture either the virtual or real drive with the SBS 2011 install and start the virtual machine.

It is really a good thing to not have the old server as on the LAN.  If it is that address, change it and be sure to change your port forwarding on the router to match.

When you create the answer file, use for the new server and whatever IP address the old one had. The user administrator will be the system user, and you can add a new one and make the old one inactive.

While the initial part of the install is running, take a made a CD or DVD with the answer file on it.  When the dialogue for migration appears and the SBS 2011 install says it can’t locate the answer file, eject the SBS 2011 install disk, insert the CD with the answer file and try again.  If you used a virtual drive, just capture the physical drive from the Clipboard menu on the Hyper-v connection to the new SBS 20111 server.

Using Virtual Clone was imperative for me in running some things on the old server; it had no DVD drive.  If that were the case on the new server, how would you get the answer file to work?  One way is to create the CD with the answer file on it, then use a program like Magic ISO to convert the CD to an .iso image.  Then you can mount the .iso on a virtual drive  on the parent os and capture if on the hyper-v console.

Once you have the new SBS 2011 running as a virtual machine, then just do all of the migration steps you normally would with two physical machines.

Now that you have the basics of how to create a volume on an iSCSI target and mount it for use, let’s explore some reasons for doing so.

Server Storage

The simplest case I will present is a single SBS server.  There are several important data stores for SBS:

  • Exchange Server
  • SharePoint
  • Shared folders
  • LOB or other data that is used by SBS members

When you first install SBS, these are all going to be located on the OS drive.  Using the SBS console, you can migrate them to another drive location.  In the case of LOB data, which is set up independently, you no doubt can chose the drive on which to locate it.

You could start with disks installed on the server in a traditional fashion.  Maybe the drives are 500GB, 1TB, or larger drives.  Your Exchange requirements might be modest, say 15GB.  You estimate that SharePoint files are likely to grow to 20GB in the next six months to a year.  Shared folders might start at 20GB but could go up or down depending on what migrates to SharePoint, for example, and what other growth you anticipate.

You can use one drive for Exchange, one for SharePoint, one for shared folders, and one for LOB data.  But perhaps your server can’t accommodate that many drives.  And it certainly might not accommodate them as RAID 5 or 6 volumes and be independent of each other.  What are the choices?  Well, you could  use one physical disk, no RAID, and create several volumes and use different ones for different data types.  Or perhaps use several drives to create a RAID set and and allocate volumes on it.

Now that you have several volumes on your drive or drive array, sized to accommodate the data you anticipate, what happens if you start to run out of space?  If you have a partition management software tool, you could expand the size of the allocation if there is more free space on the drive(s), or shrink another partition if that were possible and then increase the size of the desired one.  Or, if you have the space available, create another larger partition and move the data to the new one.

Using iSCSI targets is similar to this approach but without the drawbacks and pitfalls of locally attached drives.  First, your storage platform is robust and will have RAID enabled drive support.  Since mountable drives are created from an available pool of space, you can start with the most reasonable size for each disk you need.  Later, you can, on the fly, create a new iSCSI target that is larger or smaller, move or migrate the data to it, disconnect the original target and then delete it.  It is far easier than partition management.

Don’t forget backups.  You can create an iSCSI target and mount it on the SBS server and then configure backups to this drive.  Need another destination?  Very simple.  You get the idea.

Virtual Machines

You probably know from reading some of my other posts I am a fan of virtual machines.  I like the idea of running SBS as a Hyper-v machine; the same box can support test machines, client machines used for remote access, special LOB servers, you name it.  In a virtual machine environment, iSCSI shines.

Start with the drive on which you store the .vhd files.  These can be on a locally attached or a iSCSI drive.  I use iSCSI because I can allocate a right-sized disk in a matter of minutes and have it available on the host server.  Once the virtual machine is created, I can allocate and attach additional iSCSI targets to meet the needs of that vm.

Consider that you might want to test some new software or application, such as a web site, SharePoint feature, or LOB application.  Create a virtual machine and allocate the disk space it needs.  If it turns out to be incorrect, or once your testing has been completed, it is a simple matter to delete the iSCSI targets and return the disk space back to the available pool.

Note a potential disaster recovery scenario.  If you were to lose the host server, the .vhd for the virtual machines would still be on the iSCSI target.  Simply use them to create a virtual machine on another host, and you are back up and running.


Admittedly, I stole some of my own thunder when talking about virtual machines, but the testing environment is perfect for iSCSI.  Just allocate a target, use it and then delete it once the testing is done.

But it is not just for server and server-level software that iSCSI is useful in testing.  Suppose you want to test from your desktop.  Guess what.  Windows 7 has the same iSCSI initiator, and you can download one for XP.  That means you can create disks, use them and subsequently delete them at the client desktop as well as at the server.

Ad Hoc Uses

I have also used iSCSI targets for quick, one time efforts.  I wanted to update the OS on a laptop for a friend, and I wanted to end up with a clean install but make sure I didn’t lose anything important.  The trouble was that my friend couldn’t tell me what was important…. So I removed the laptop drive, connected it to my desktop with a USB drive connector, copied it completely to an iSCSI target I created, put the drive back in his laptop and installed the new OS.  There were a few things to go back and retrieve, but once he was satisfied I simply deleted the drive.

I will often be called upon to change something at an installation.  I usually create an iSCSI target, do an appropriate backup (sometimes it is just copying files, other times, a more holistic backup), then make the changes.  Getting back to the original state if something goes wrong is neat and tidy; so is the deletion of the disk once I am done.

Less Common But On My Wish List

Recall from Part I that the SCSI commands to read and write data are sent over the network to the target device.  Theoretically, it doesn’t matter whether the network is local or very WAN.  Practically, it is how long it takes for the commands and data to get back and forth.

Here is where I think cloud backups might go for some types of transaction-sensitive data.  Suppose you have a database that gets updates continuously from user transactions, web traffic, etc.  If that data were stored on an iSCSI target, remember that the data and commands to read and write it travel across the network.  Now imagine that the iSCSI target machine, when it gets a write command, also sends that command with the data to another iSCSI target, a mirror, that is remote, i.e., the cloud (public or private).  The difference is that the local target can respond back to the server that the write is complete, but there are no such time constraints on the write to the cloud. The iSCSI target would have to create a queue of writes and execute them in order as they complete asynchronously to the writes it completes locally.  This is not unlike playing a log file against a database.

Because only writes need be executed across the WAN, this is a very efficient operation and with broadband speeds continuing to increase, such a scheme because a very practical continuous backup procedure.

No solution like this is commercially available that I know of, and it would not be appropriate for every application.  Nevertheless, you heard it here first if it does come to pass.

I hope this gives you a flavor of the convenience and wide range of uses that iSCSI provides. In Part III I will discuss the costs and purchasing of a unit.


I have become a huge fan of iSCSI for use with SBS.  If you are not familiar with iSCSI, this first part of my posts will give you an overview of what it is and does and how it can be used.

iSCSI stands for Internet Small Computer System Interface.  SCSI has long been a favorite for high performance and reliable disk storage for servers.  There are several reasons for its popularity:

  • SCSI controllers almost always had RAID implemented to protect against single or even multiple drive failures.  Extra information was stored across the disk volumes to make certain that all the data could be recovered by replacing the errant disk.  Hot swap is also common, meaning that a drive could be replaced without stopping the system.
  • SCSI offloaded many of the processing tasks associated with reading and writing data to the controller rather than having the computer’s processor do all the work.
  • Data transfers from the device to memory were more efficient and often very much faster than for standard access drives.
  • SCSI disks themselves were often more rugged, faster and reliable than standard disk drives.

With high speed networks becoming not only the norm but very affordable, and with the need for shared storage among many servers, iSCSI came into vogue.  The controller and drives were now located in a separate box, and the commands to read and write and otherwise process the stored data were sent over the network instead of over a local bus.  Data to be read or written also travels over the network, and is done so with excellent efficiency.

Removing the disk drives from the server itself offers a great deal of flexibility.

  • It no longer matters where the server and controller/drives are located.  They can be next to each other, in different rooms, or across the country or world; response time and performance are still considerations, however.
  • Multiple servers can access the iSCSI device by using their network connections.
  • Servers “see” a disk on the iSCSI device as an allocated volume.  Volumes can be assigned from among a pool of drive space, and the remaining drive space can be used for other volumes on the same or different servers.
  • You can quickly create a new volume and hence drive for a special purpose on a server then as quickly delete it once you are done.  Think testing, making copies, and so much more.
  • iSCSI devices can be managed separately from the servers they provide storage for.

You might be tempted to ask, isn’t that just what a NAS device does?  The answer is no.  NAS devices provide file level access.  The server sees the files as a share, not a disk device.  While this may not strike you as being important, it certainly is critical for things like Exchange databases.  Exchange does not support storing data on NAS devices but does for iSCSI devices.  And for virtual machines, you are going to want to assign them drives, not folders.  More about virtual machines later.

While this is not an exhaustive list by any means, it will probably get you thinking about how cool it would be to have this flexibility for particular situations you have found yourself facing before.  So why don’t you have iSCSI already?

Historically, the answer was oh so simple: cost.  Storage area networks with iSCSI were outrageously expensive and could only be justified in some of the most business critical scenarios.  Think hundreds of thousands of dollars.  But after a while, the price came way down.  To tens of thousands of dollars.  Not exactly the budget range of most SBS installations.  If you are one of them who could afford it, please do call me, though, as I know we can work a deal.

Today, you can purchase a small iSCSI system for about the same price as a medium-sized NAS device.  As the size of an iSCSI system increases, you are going to pay about $800-$1500 more for the device over the cost of the individual disks.  Let me assure you that it is money very well spent.  I suspect you will save around half of it by more efficient use of your disk space.  I will have another post on selection and cost.

Well, cost aside, you might say, it is probably difficult and technically challenging to set up and use an iSCSI device.  Not at all.  Support for iSCSI is not only built into SBS, it is also built into Windows 7, and you may have occasion to use it with client computers in your environment.  I admit to having done so by needing a test or copy disk, which I allocated and attached in less than a minute.  It takes me longer to go grab a USB drive and plug it in.

While it may not be universally true of all iSCSI device manufacturers, many have provided great web based interfaces that are intuitive and easy to use.  When you first install the device, you have a few general tasks to do to get it ready to use.

  1. Set up the network connection.  Assign IP address(es) to the network adapter(s).
  2. Setup credentials.  Hopefully, your device will support the domain AD credentials, and it is a simple matter to provide the administrator credentials for the device to access AD.
  3. Initialize the storage for iSCSI if the device does not do it automatically.
  4. Create one or more iSCSI volumes.

To calibrate this effort, if you are not familiar with the interface, this might take 15 minutes.  If you are, maybe 3-4 minutes.

Once you have done this, turn your attention to the server.

  1. From the start menu, accessories, chose iSCSI Initiator.  You will see
  2. Enter the IP address you set up for the iSCSI device into the Target box and click Quick Connect.
  3. The targets will appear.
  4. Highlight the volume you want to use and click Connect.  The status should change to Connected.

That is how hard it is to get the iSCSI work done.  Let me repeat.  That is how hard it is to get the iSCSI work done.

But there is still the issue of making this volume a drive on the server.  To do that, you need to open Server Manager.  Once you have, click on Storage to expand, then click on Disk Management.  You should see something like this:

Note the unallocated disk at the bottom.  Right click on the Disk 7 (or whatever yours shows) area, then chose Initialze Disk.  Accept the defaults and click ok.

Now right click inside the disk space, create a new simple volume.  The wizard will let you assign a drive letter and to do a quick format. Once you are done, your disk is ready to use.

The next part of my iSCSI posts will discuss some practical situations on how to use it for a variety of applications and special circumstances.