Building a Multiboot System

The need for multiple environments

Sometimes, as a consultant in the field, we have to support either multiple products, many facets of one product or to demo products. This raises the need for having multiple environments, or Operating Systems installed or available for use. They very old way to do this was to create multiple partitions, install multiple operating systems, and boot accordingly. The problem with this was that we had to sacrifice disk space and carve up our hard drive.  Recently, most of us changed to running virtual environments by running either Virtual PC/Virtual Server or Server 2008 with Hyper-V.  These were ok solutions, but had their limitations. Not all hardware was able to be directly accessed, and we were limited to the amount of Ram and Processor power we could use.  In the case of a Virtual PC, we could only use 32 bit environments.

Enter Windows 7

With Windows 7, and Windows Server 2008 R2, we now have the ability to actually boot from a VHD. Booting from a VHD offers the following enhancements:

• No partitions to carve out
• Direct and full hardware access
• Dynamically expanding virtual drive
• Real performance and great user experience*
• Full 64 bit support (on 64 bit hardware)

*Since the environment is booting from a virtual drive, there is a slight (3%-5%) performance hit on disk I/O.

The Process

The Concept

The concept is simple. Create a VHD and make it accessible, edit the boot menu of the OS, boot into the VHD.  The execution has a little more to it.

Create the VHD

There are a few ways to create the VHD, but the easiest I have found is to use Windows Server 2008 with Hyper-V to create the VHD. You can use Virtual PC, however Hyper-V allows you to create a 64 bit environment, and that is why I prefer Server 2008.  The OS for the VHD must be either Windows 7 or Windows Server 2008 R2 in order to boot.  Typically, I will just create a base image with OS only, and then build it once I am booted into it. The process to build the VHD is as follows:

• Launch Hyper-V and create a new virtual environment.
• Make sure to enable growth, and set the maximum size to something manageable, I use between 50 GB – 80 GB, but that will depend on how much the environment will hold (Note, you will get slightly better performance if you use a fixed disk size…)
• Memory is not really important, however the more you allocate the faster the OS install will go.
• Map an install disk to the environment
• When done, boot into the virtual environment and install the OS and all features (.Net, IIS, etc…), as well as all updates
• Once the OS base image is done, run SYSPREP
  • SYSPREP is done to strip all hardware references from the environment so you can port the environment to another system
    • C:\windows\system32\sysprep
    • Use default setting of OOBE
    • Check the ‘Generalize’ box
    • Shutdown option should be ‘Shutdown’
    • Once SYSPREP is completed the image will shut down.
    • Once the image has shut down, you can export the image for use (or just do a copy of the VHD. You only need the VHD for this, not the supporting files.)

Booting the VHD

Once you have a Windows 7 or Windows Server 2008 R2 VHD, then you can copy it to computer that you wish to boot the VHD.  I typically create a folder called VHDs at the root of the C: drive to place the VHD.  You only need to copy the VHD, not the supporting configuration files from the Hyper-V export.  Once you have the VHD on the hard drive, then all you need to do is edit the boot menu. Since Vista, the tool to edit the boot menu is BCDEDIT. Complete the following steps to add the VHD to the boot menu.

• Open a command prompt as ADMINISTRATOR
• Enter the following commands
  • bcdedit /copy {current} /d “Your_VHD_Menu_Item_Name”
  • Copy the CLSID at the end of the successful statement. It will be the id within the brackets {}.
  • bcdedit /set {CLSID} device vhd=[C:]\VHDs\vhdname.vhd
  • bcdedit /set {CLSID} osdevice vhd=[C:]\VHDs\vhdname.vhd
  • bcdedit /set {CLSID} detecthal on

Once the commands are completed, you should now be able to re-boot, and see the new VHD in the boot menu. Boot into the VHD, and it will begin setup as if you are on a brand new computer.  It will make you create a new user account, but once done you can boot into the existing user account that was created in the Hyper-V setup.

Conclusion

As you can see, setting up the environment is straight forward, and not too complicated. It allows a multi-boot environment without the ‘Muddy’ aspect of creating partitions, overwriting the native OS, or any of the old ways to multi-boot.  It also allows for full hardware access with minimal hard drive footprint.  You can also access the physical hard drive and other VHD’s by attaching them with disk manager.  I have found this to be the best way to have native Windows 7 for everyday use, and Server 2008 for development/testing and an environment that I can just ‘trash’ without fear of wiping my main OS, and if I want to get rid of one of the environments, all I do is:

• bcdedit /delete {GUID} /cleanup

 

There are other ways to set this up, even on a bare hard drive with no existing OS.  You can boot with the OS DVD, go to a command prompt, and use DISKPART to create the VHD and install the OS. I decided to go the easier route, but there are many blogs that cover this approach.

Any questions or comments please let me know!

Happy Virtualizing!

The Evolution of SharePoint

Microsoft’s SharePoint product has recently evolved into its next iteration. SharePoint 2010 is a departure from its predecessors in many ways, and as such, adds a new layer of complexity to many areas. Designing, Planning, Architecting, Installation, Deployment and Development all have some changes that can be a challenge at first, but once you dig into the product, it begins to make sense.  One of the first changes one might notice, is the lack of a Shared Service Provider (SSP.)

The SSP was a way to create, configure and share services within a Farm to the Web Applications associated with it, or between Farms.  The concept was sound, but there were some limitations. One of which, if you wanted to share the search service, you had to share the whole SSP. Also, if you wanted a separate search or profile service, you had to create a whole new SSP. 

Enter the new shift to Shared Services. Services are now independent, and can be shared with web applications or other Farms easier than being contained in an SSP.  Services that can be shared across Farms are:

• Business Data Connectivity Services
• Managed Metadata Service
• People
• Search
• Secure Store Service
• Web Analytics Service

Services, such as Search, can now be load balanced for higher availability and scalability.  This new shift makes administration and resources more efficient, and ultimately provides a better End User experience.

In a nutshell, SSP is gone in SharePoint 2010 and a better Shared Services infrastructure takes its place. 

In my later posts, I will give a walkthrough of Planning, Installing, Configuring and Using these services from start to finish. 

Dave P.