Today on one of Citrix’s Blogs, they announced a new upcoming technology called “Hosted Virtual Machines” (HVM).  As if the Virtualization Soup of technology wasn’t big enough already, but this does solve an interesting problem.  Without much more information on the subject, here is my take.

Short Version: You want to host an application on a managed VM, but Terminal Services won’t work for a number of reasons.  With HVM, you use a client OS such Windows XP to run the application, but the presentation of it (just like Terminal Services) is then sent to the user.

Long Version: It seems that “Virtualization” is getting more and more attached to every new technology, but at the end of the day it’s about access to applications (that includes the OS and other applications).  Let’s put aside the delivery of an OS for now and focus just on the application.  There are a number of ways to provide a user with access to an application.

1. Traditional – This is where you get a CD or copy files from a file share and install the application locally
2. Terminal Services – Based on using a single OS instance, such as Windows Server 2008, and allowing multiple users to logon at one-time, but they each have their own “space”/desktop.  The display of that OS, or sometimes just a given application, is presented to the user.  Everything runs on the server, but show to the user on their computer
3. Application Virtualization – There are a few flavors of this.  This simplest view is about delivery.  The application is “preinstalled” and “captured” on a given OS (do a traditional install, but all files, registry settings, shortcuts, etc. are captured) and then deployed to any number of users.  So one “install” is then executed on any number of computers.  The application will run on the local computer, BUT it’s not installed there.  No files, registry, or shortcuts are anywhere to be found on your computer, but it still works locally.  That’s the virtual part.  Again, it’s all about deployment.

The big issue here is the ability to still provide “Terminal Services” like deployment of applications, but overcome some of the issues that “Terminal Services” (TS) has.  What kind of TS issues?  Well TS is still a Server OS.  It doesn’t have may of the client components (e.g. Windows 7) that some applications require.  TS is also Multi User based and there are some application that don’t work there either.

So why can’t Application Virtualization (e.g. Microsoft App-V or Citrix XenApp) work?  First off, there are certain applications that are developed either by a custom software development shop and built for a given customer and for a given OS/Application mix.  There are other applications that are certified by an Independent Software Vendor (ISV) that has specific requirements.  And then there are organizations like the Government, Health Care, and more that need to ensure that certain applications and data behave in a given way.  For all of these scenarios, an IT shop may want to provide an application to their users, but refrain from deploying them locally, it won’t work via TS, Application Virtualization won’t fulfill their requirements, and whatever else.

So the solution by Citrix XenApp (in the future) opens some very interesting doors.  I don’t think it will be part of the mass adoption, but it will break down certain barriers.

This leads me to think of other solutions such as Microsoft MED-V (Part of MDOP) and MokaFive that provide this kind of host based virtualization, although with HVM Citrix also allows this to be hosted on a server.  I guess I’ll have to wait for a Citrix demo and trial for me to learn more.

BTW, I wonder how this will impact hosters looking to get into the application delivery model.  Since this does require another client OS, Citrix rightfully notes that you’ll need the Microsoft VECD license.  Too bad VECD is not on the Microsoft SPLA list.  Bummer

I just read the announcement that Microsoft put out about their new licensing model for Virtual Desktop Infrastructure (VDI):

http://blogs.technet.com/virtualization/archive/2009/07/13/Microsoft_1920_s-new-VDI-licensing_3A00_-VDI-Suites.aspx

If you’ve ever had to figure out Microsoft licensing for any type of business use, you’ll know how complex (and frustrating) it can be.  There’s plenty of good reasons why it’s so complicated.  With the VDI scenario, it makes licensing even harder since you’re not just talking end devices anymore (e.g. your laptop), but you’re also dealing with many virtual components (e.g. virtual applications deployed on a virtual desktop, deployed on a virtual server, deployed on a thin-client).

So based on the new announcement, when it comes to doing an all Microsoft VDI solution, what licensing components do you need to keep in mind?

1. Microsoft Virtual Desktop Infrastructure Standard Suite (VDIS) – This is the “Platform” license.  It covers all of the licenses you need to run a complete Microsoft solution for VDI.  It spans Virtual OS (Hyper-V), Management (System Center + MDOP), and Server CAL (Remote Desktop).  (Premium Suite includes additional rights for Session Based Remote Desktop….Formerly named Terminal Services)
2. Microsoft Windows Virtual Enterprise Centralized Desktop (VECD) – This is actual client OS license.  It’s covered per device (e.g. the thin-client that you connect from) and allows you to run up to 4 OS instances from that device (which can be spread across any number of servers). Even if your NOT using Microsoft for your Hypervisor and/or management (e.g. you’re using VMware or Citrix), you MUST still purchase this license.

So what does this mean from a cost perspective?  Both of the licenses above are priced on a per device (e.g. thin-client or “Legacy” PC) on a per year basis.

1. VDIS Standard: $21.00 (US) per year
2. VECD for SA: $23.00 (US) per year – This is if your device is a Windows Client OS that ALREADY has Software Assurance on it.
3. VECD: $110 per year. – This is for a traditional Thin-Client.

So why does Microsoft do a VECD license in the first place?  If you look at the license of the Windows Client OS (like I’m sure we all do), you’ll notice that the license is perpetual.  So where you install it, it must stay there.  Not only that, I need an OS license for each OS Instance I use.  With VECD, I don’t have that same headache.  The IT department can deploy any number of combinations of Windows XP, Windows Vista, and Windows 7 for specific role, tasks, training, or whatever.  It doesn’t need to track the total number of virtual OS instances for licensing as the OS license is being tracked by the number of end devices using a given image.  Now this doesn’t mean that an IT department will deploy thousands of images (what a headache) as there are better ways to use “golden” images and to dynamically deploy new Virtual Machines to a “Pool” of available clients (Future Post!!).  But this does free up the IT department to provide OS Instances and Applications on demand for customers because VECD covers them to do so!  Again, this is something that is a MUST for ALL VDI DEPLOYMENTS no matter what vendor you use for Virtual Desktop.

I think the license change from Microsoft will make it MUCH easier for customers to budget for Virtual Desktop using the Microsoft platform.

I was fortunate enough to be asked to contribute to a new book focused on IIS 7.0.  I thought this would be a great way to dive deep into the product which would in turn help me sell the platform as Windows Server 2008 comes out (although the book focuses on Windows Vista).  The final name of the book is “How to Cheat at IIS 7 Server Administration“.  The target audience for this book is the IT generalist that is looking to quickly learn IIS 7 and perform the standard operational and support function.  This was my first time contributing to a book and it was quite the effort.  It took up many nights and weekends, plus I had a two week deadline (that was rough).  I may contribute again in the future, but I’ll have a better idea of what I’m getting into and plan accordingly (with my family that is).

Chris Adams was the Technical Editor and I was one of the contributing authors and I produced Chapter 6: Troubleshooting 101.  Although I’m not listed as an official author, my name is printed on the cover of the book and I’m listed as a contributor within the book as well.

• Paperback: 384 pages
• Publisher: Syngress (May 28, 2007)
• Language: English
• ISBN-10: 1597491551
• ISBN-13: 978-1597491556
• Product Dimensions: 9 x 7.4 x 1.2 inches

Here is a blog post by Chris Adams as he gives a brief overview of the book: http://blogs.iis.net/chrisad/archive/2007/07/13/first-it-pro-focused-iis7-book-hits-market-how-to-cheat-at-iis7.aspx

Get your copy today!

http://www.amazon.com/gp/product/1597491551?ie=UTF8&tag=agramontnet-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=1597491551

So after my first post on the subject of “expanding a VHD” by actually copying the contents of a VHD image using WAIK (Copy a Microsoft Virtual Machine VHD/Increase VHD size using Windows Automated Installation Kit), I got some good feedback on my laziness of not going down the VHDMount method. So I took a bit of time tonight to work through that scenario.

A key new feature in Service Pack 1 for Microsoft Virtual Server 2005 R2 is the availability of a new tool named, “Offline VHD Mounting”. It’s a command-line utility that allows you to mount a Virtual Hard Drive (VHD) as a local drive on a host server. The great advantage to doing it this way versus using an imaging technology (like I did using ImageX.exe as part of the WAIK), is that you don’t need the overhead of taking a snapshot, deploying, rebooting, etc. You simply need to mount the original image, mount the new image, and then do a copy.

Before we get started, please make sure that you have downloaded and installed the following

• Microsoft Virtual Server 2005 R2: http://www.microsoft.com/downloads/details.aspx?familyid=6DBA2278-B022-4F56-AF96-7B95975DB13B&displaylang=en
• Microsoft Virtual Server 2005 R2 Service Pack 1 (Beta 2): https://connect.microsoft.com/site/sitehome.aspx?SiteID=151

So here are the steps I took to “expand a VHD” by coping the contents from the original to a new VHD that was created at a much larger maximum size.

1. Ensure the Virtual Machine (VM) that holds the original VHD is currently stopped.
2. Mount the original image
   1. Open a Command Prompt and change directories

      cd “C:\Program Files\Microsoft Virtual Server\Vhdmount\”

   2. Mount the original image (the path I have below reflects my deployment.

      vhdmount.exe /m F:\Images\Configs\DepA-Web02\DepA-Web02.vhd V

3. Create a new VHD – Using the Virtual Server Administration Website, create a new Virtual Hard Drive (VHD) that has the new storage capacity that you feel you’ll need.
   1. Click Start > All Programs > Microsoft Virtual Server > Virtual Server Administration Website
   2. From the Virtual Disks menu, select “Dynamically Expanding Virtual Hard Disk” or “Fixed Sized Virtual Hard Disk“
   3. Provide the new hard drive name and location. You may also notice that the default size for a VHD is no longer 16 GB, but is now 127 GB.
   4. Click the Create button
4. Mount the new VHD (same steps as step #2, but you need to point to the new VHD location)
5. Once the new VHD is mounted, I wasn’t able to actually see it using File Explorer. As any new drive, virtual or physical, it has yet to be partitioned and formatted. So the next step is to create a partition and format the new VHD. This (as is everything else) is done on the host machine. There are two ways that we can perform this task: The GUI way using the “Disk Management” MMC Snap-in or the command-line way using the “DiskPart” utility. Below are the steps using DiskPart
   1. Open a Command Prompt and execute:

      diskpart

   2. Find the disk number for the new image. It should have a “Size” and “Free” value that are the same number AND should be the size of the VHD that you created.

      list disk

   3. Now we’ll create the partition on the drive (the disk number for my new VHD was 4, but you should use the number that you found from the above command) and assign it a drive letter

      select disk 4

      clean

      create partition primary

      assign letter=w

      exit

   4. The next step is to format the new drive

      format w: /FS:NTFS /Q

   5. Finally, we’ll go back into diskpart and activate the partition

      diskpart

      select disk 4

      select partition 1

      active

      exit

6. At this point, we now have a VHD drive ready to be used. So now we’ll simply start copying all of the contents from the original image to the new image. (This will take a while…)
   1. Using the default xcopy command within Windows, we’ll copy all of the contents

      xcopy v:\ w:\ /E/H/K/O

7. Once the copying is complete, we should now unmount the drives
   1. Open a Command Prompt and change directories

      cd “C:\Program Files\Microsoft Virtual Server\Vhdmount\”

   2. Mount the original image

      vhdmount.exe /u v

      vhdmount.exe /u w

8. We’re now ready to point the target Virtual Machine from the original VHD to the new VHD.
   1. Click Start > All Programs > Microsoft Virtual Server > Virtual Server Administration Website
   2. From the “Virtual Machines” menu on the left side, hover over the “Configure” section and then click on the target Virtual Machine from the pop out window.
   3. Click on the “Hard Disks” configuration section link
   4. We don’t “really” need to remove and add a new hard drive. What we’ll do instead is point the old path to the new path in the “Fully qualified path to file” section for the appropriate disk. Then click OK.
9. We’re all done! Now you can start up you VM and it should now be using your new VHD, but with the previous (and I’m sure lots of time invested in created) content. But don’t delete you VHD just yet. I’d give it a few days or hours of testing before you delete the original VHD to save space.

I’m sure most of this could be scripted out and perhaps that’s another late night project for me. But for now, this should at least get you going down a path that worked for me.

Update:

I thought some of you might find the before and after file sizes interesting:

• Original VHD: 15 GB
• WIM of original VHD: 5.58 GB
• VHD using WAIK: 12.5 GB
• VHD using VHDMount: 13.3 GB