by
Brian Madden
One of the things that’s most annoying about the desktop virtualization industry is that we’re doing things with Windows that Windows was never really designed for. For example, we’re taking a single Windows disk image and sharing it among many (hundreds or thousands even) VMs. This is a technical challenge for so many reasons, most of which have to do with changing each cloned disk image’s domain identity (computer name, domain SID, ACLs, policies, secrets, etc.)
Of course Microsoft has for years provided deployment tools to help address this, most notably Sysprep. Sysprep is a built-in tool that will “scrub” the identity from a machine and then shut it down. Then the next time it boots up, it can either ask the user (or read from an unattended file) the specific settings that instance of Windows should have, including the computer name and whether it should be part of a domain.
Sysprep works great for traditional desktop deployments when you're doing a one-time deployment to a physical machine. It's pretty miserable in VDI environments though.
In a VDI environment, people typically want to have a master image that sits there waiting for users to login, and when that happens, the virtualization engine spawns a new differential disk image for a new VM the user will connect to. Then that VM boots up with the spawned copy of the original disk.
Unfortunately Sysprep doesn't really deal too well with that, because it's kind of slow and requires a couple boot cycles. So if you want to use Sysprepto create the unique VMs on-demand, you better have users who would be ok with a login message along the lines of “Thank you for logging in. Please wait 5-10 minutes while we provision your new desktop.”
How do the virtualization vendors get around this Sysprep limitation? Several ways:
- Perform a massive “pre-creation” operation,
- “Pre-create” just a few VMs to keep them ready,
- Completely throw away Sysprep and write their own version of it that’s purpose built for this scenario.
Option 1. Massive VM pre-creation
Since Sysprep is slow and requires reboots, the most obvious way around this is just to provision all your VMs ahead of time. While this technically works, it's S-L-O-W. I mean think about it. The thing has to methodically boot every target VM, run through the
Sysprep process, getting each VM ready to go, and repeat. If you have a lot of
users, this can take days!
Option 2. Small batch VM pre-creation
One way to get around the massive prep time needed is to just prep a few VMs at a time. You could configure your system so that it always had ten VMs prepped and ready to go, and then as users logged in and connected to them, a new one could go through the complicated Sysprep process. This method actually works well when your users will get a fresh VM each session, since you can sort of continuously roll-in new VMs. The only real downside here is if you have huge simultaneous logons, you'll need to have enough VMs ready in your pool.
Option 3. Use another technique besides Sysprep
The final option is the most popular, where individual vendors realize that Sysprep is not appropriate for this scenario so they built their own capability. This is what Citrix (Provisioning Server), Virtual Computer, Red Hat and probably ten other vendors have done. Most of these vendor solutions work in similar ways, where they pre-create all the computer accounts in AD and then also simply pre-create the delta differential disk image files on their own without waiting for Sysprep to do it's thing. (Actually, I think this is what everyone does except for Citrix, who instead maintains a database of each VM's personality data which is then injected via a custom disk driver as the VM reads it from its virtual disk.)
Regardless of the exact method used, the point is that (1) these third-party solutions are better than the out-of-the-box capabilities that Microsoft provides, and (2) it's too bad that third-party vendors have to do this. It's BS that the whole industry is collectively wasting time implementing ten different versions of something that Microsoft should have done in the first place.
So imagine my glee when I learned that Windows 7 had a new feature called "offline domain join!"
New feature in Windows 7: Offline Domain Join
Obviously the new "offline domain join" feature means you can join a Windows 7 / Windows Server 2008 R2 computer can join without having to contact the domain controller. While this is cool, it's not ground-breaking. After all, the problem with Sysprep (and the whole domain joining process) for VDI is that the computer has to reboot, not that it has to contact the domain controller to join.
That said, reading through the offline domain join TechNet documentation uncovered a little gem: In addition to using the offline domain join tool as part of the initial Windows installation unattended answer file, you can also copy the offline domain join file into the Windows folder and then just boot up the machine (even an existing machine). That should mean that we can use this for VDI!
Except wait, what's that? This method still requires a reboot first? Oh. :( And what's that? There's a warning in the TechNet article which states "Do not use differencing disks from the same parent VHD for these
virtual machines. The differencing disk will not start correctly after
you complete the steps to perform the offline domain join."
So wow. That kind of kills that fantasy.
Where does that leave us?
Going into the end of 2009, it looks like we still don't have a simple way to do this from Microsoft. Well, at least not built into Windows. What are your thoughts? What are the best methods for dealing with cloned images that need unique domain identities? Should we look to the hypervisor vendors? The desktop virtualization vendors? The storage vendors? Microsoft?
Whose problem is this to solve?
(Note: You must be logged in to post a comment.)
If you log in and nothing happens, delete your cookies from BrianMadden.com and try again. Sorry about that, but we had to make a one-time change to the cookie path when we migrated web servers.