In Fall of 2009 there was a perfect storm of tools and automation to enable something I have wanted to do for some time, automate local physical-to-virtual migration of a Windows client machine and redeliver and integrate that old environment within a new Windows build using full automation. The pieces we had in November 2009 were:
At that point, the ingredients were fundamentally there to get everything working. In the Spring another valuable component came online to enable Virtual PC on machines without Hardware Assisted Virtualization. With all of these components in place, it was time to glue everything together and get it working end-to-end. Being a deployment guy, I’ve always been a fan of task sequencing engines and I knew that MDT could do everything I needed to configure the right things at the right times and drop the right components needed in the process.
Michael Niehaus and I had a working prototype in December, but before I could proceed any further, I had to look into the licensing and activation implications of doing this. Since we are transferring the install from one PC to another (even though it is a “virtual” PC), OEM-installed copies of Windows cannot be P2V’d, as they do not allow for a transfer to another PC. Retail copies of Windows (for example, if you buy a full Windows DVD copy from your local retailer) allow for a transfer from one computer to another. Software Assurance and Volume License (VL) media enables a couple of things for this: the right to create custom desktop images, the right to run up to four additional virtual clients for PCs covered with Software Assurance, and the Volume Activation on VL-media-based copies of Windows to ensure that end-to-end automation works without prompting for reactivation after the system has been P2V’d. In Windows XP VL media for instance, the activation remains in a valid state after P2V and in Windows Vista and newer VL media, we can use the Key Management Service to automatically reactivate after P2V. Non-VL installs will require reactivation. These rules apply to all P2V operations of Windows client operating systems, whether the tools come from Microsoft or third parties.
In parallel to looking at these issues, I worked with Mark Russinovich to get some additional needed features built into the Disk2VHD tool. Mark added command line scriptability, a generic mass storage driver for Virtual PC, and finally a fix to boot.ini on Windows XP systems that prepare them for use with Virtual PC with a new default boot entry while keeping old configurations with the previous boot entry. At this point Disk2VHD is now in version 1.62 and several of the point releases were made to enable local P2V migration with Virtual PC as the VHD viewer.
MDT 2010 Update 1 development was in full swing until the update released in July and we were working on additional requirements to get the solution supported when finished. At that point, we formalized the project under the moniker of “P2V Migration for Software Assurance.” The “for Software Assurance” part in the title isn’t because we are gating the tool’s downloadable content to Software Assurance customers, it is more of an indication of when P2V is a legitimate practice for Windows client operating systems and when the automation will work end-to-end, which then in-turn means what is tested and will be supported.
The refresh process at the PC looks just like what I announced originally to the MDT Connect community last week and these are probably the best images I have to explain what happens:
Starting Windows environment with Windows XP SP3 or newer. Environment is personalized with applications (potentially) not compatible with Windows 7. This version of Microsoft Golf and Microsoft Bob (see the video at 12 minutes in) both install to the root of C: and have 16-bit components, which won’t work in a 64-bit OS.
Microsoft Deployment Toolkit 2010 initiates fully-automated migration to Windows 7. Process includes P2V conversion of the running OS using Sysinternals Disk2VHD.
Windows 7 migration complete. Windows 7 contains the previous operating system in its entirety within a virtual machine.
Standalone application and Internet Explorer links published from virtual machine to native Windows 7 start menu.
Incompatible application from previous operating system is launched seamlessly within Windows 7 using RemoteApp integration and Virtual PC.
If you want to see a video of how to get it working with a demo of the machine I used to capture the images above, check out the video blog we just posted on TechNet Edge (skip to about 12 minutes in to see the client experience).
While everything was fully-automated and working for the in-place computer refresh scenario for many months (where the virtual machine is captured on the same machine we install Windows 7 on), the computer replacement scenario (where we retire the first PC and transfer the VHD and user state to a new PC) and System Center Configuration Manager support needed to be built. That is roughly what we’ve been working on since MDT 2010 Update 1 shipped in July. The current Beta has support for the Refresh and Replace scenarios without Configuration Manager at the moment; another Beta release with Configuration Manager documented/working and better international support is coming in the coming days. The same video above shows what you need to do to get it working if you already have a Microsoft Deployment Toolkit environment running. Once you install P2V Migration, the task sequence option is just a drop down like the others included in MDT:
You just need to build a new task sequence and select one of the new entries for P2V migration – replace or standard – used like the normal MDT template task sequences and try it out on a client with Windows XP SP3 or newer operating system.
This process has a few limitations. First, you probably shouldn’t be using this on more than a handful of blocking desktops. The best way to deliver a standardized local Virtual PC environment to many users is to use Microsoft Enterprise Desktop Virtualization. It enables provisioning and management of much lighter weight VMs, lets you manage how links are published to applications from the VM, redirect URLs to the VM’s browser and back, start the VM when the user logs into the physical machine, etc. It also requires that you know about and manage the applications going into the VMs. Where P2V Migration comes in is where you don’t have the source media, don’t want to include rarely required apps into a standard VM (all this applies to Internet Explorer customization as well). For that handful of users with highly-specialized and otherwise deployment-blocking PCs, you can target them for P2V Migration.
The biggest technical limitation is Virtual PC’s maximum VHD size. Virtual PC cannot use a VHD container larger than 127GB – that means even if the P2V’d system was consuming 10GB of disk space for example or I made the Windows partition with 10GB on a 160GB or larger hard disk, we still cannot boot into it using Virtual PC. This is documented on the Sysinternals Disk2VHD site and in the solution documentation. The other main issue will be using non-VL media Windows on the starting system. It will break the automation and require reactivation in the VM after you convert it to a VHD. This is the same with all P2V tools whether from Microsoft or third parties – you need a qualifying version of Windows to do this without stopping the automation and requiring reactivation. The Release Notes document additional limitations, many of which are in scope for a future Beta release in the coming days.
P2V Migration for Software Assurance is available on Microsoft Connect in Beta 1 form. As with any Beta, we are looking for people to run this through its paces and test the P2V scenarios integrated with their MDT and/or System Center Configuration Manager deployment environments. Uptake has been good so far, but more testing will ultimately bring a higher quality release.