I no longer work at Microsoft, so please don't bother leaving a comment here or trying to contact me through my MSDN blog.
You can find my new blog at http://www.technologytoolbox.com/blog/jjameson. My new site also provides copies of all posts from my MSDN blog.
Last week a colleague was asking me how I manage my various VMs. More specifically, he wanted to know how I created SysPrep'ed images in order to quickly "spin up" new VMs for development, testing, or demo purposes.
Note that I like to keep my environments as "clean" as possible. Consequently, I don't want my SysPrep'ed image of, say, Windows Server 2008 Service Pack 2 to have all of the patches that were released through Windows Update prior to the release of SP2. However, I also don't want to spend a lot of time waiting for Windows Update to apply dozens of patches each time I create a new VM. Installing a few patches after firing up a new VM isn't a big deal, provided the Windows Update process doesn't take more than 5 minutes or so.
Let's suppose you were just starting your VM library today. Here's the high level overview of the process that I recommend you follow. Note that it doesn't really matter whether you are using Hyper-V, Virtual PC, or some other virtualization platform -- the general approach is the same.
To add a base Windows Server 2008 Standard Edition x86 VM to your library:
At this point, you have clean images for the following configurations:
Now you can simply create a new VM (for example, named foobar) and select the option to create a new VHD for the VM. However, before booting the new VM for the first time, copy ws2008std-x86.vhd to foobar.vhd, thus starting from a SysPrep'ed image of Windows Server 2008 x86 SP2 with all of the latest patches.
Note that there might be a scenario where you are trying to identify an issue that only occurs after installing SP2 or one of the recent patches from Windows Update. In this case, you would copy ws2008std-x86_RTM.vhd or ws2008std-x86_SP2.vhd, respectively, when overwriting foobar.vhd.
In other words, the "snapshots" of the VHD file allow you to quickly go back to different baseline versions of the OS. Don't confuse the word "snapshots" that I've used here with the term as it applies to Hyper-V. [I definitely don't recommend using Hyper-V snapshots in order to support this particular scenario (they are great for other scenarios -- just not this one).]
Suppose that some time goes by and you find that it takes longer than you would like to install the latest patches from Windows Update whenever you create a new VM. To resolve this issue, simply boot the ws2008std-x86 VM, run Windows Update, reboot, and then run SysPrep again. The next time you create a new VM starting from a copy of ws2008std-x86.vhd, you won't have to wait long at all for Windows Update to finish.
Let's fast forward to some future point in time when Windows Server 2008 SP3 is released. Here is what I will do in the "Jameson Datacenter" (a.k.a. my home lab) at that point:
I should point out that your ws2008std-x86 image isn't going to do you much good if you need to install SharePoint Server 2010 (because it is 64-bit only). Therefore, like me, you should consider creating additional VM images in your library, such as:
In the Jameson Datacenter, I currently have an image for Win2k3EE (Windows Server 2003 Enterprise Edition), but I don't use it very often anymore. Note that most of the time, all of these "base" VMs are shutdown. I only start them when a Service Pack is released or when Windows Update exceeds my personal threshold while creating a new VM.
There are a couple of details that I should point out with regards to using this process with Hyper-V. This is because Hyper-V isn't quite as "friendly" as Virtual PC when it comes to copying a VM (or VHD).
The first issue is related to permissions on the VHD file, which I've already covered in a previous post. The second is that you will likely end up with extra network connections (e.g. Local Area Connection 2). As long as you are using DHCP, these extraneous network connections shouldn't cause any issues. However, if you want to remove them simply follow the steps detailed in KB 269155 (Method 1).