Will Windows 7’s 'offline domain join' finally rid us of third party 'fast sysprep' functions? No :(

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.

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?

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Brian, the boot from a single disk is just Ardence/Citrix Provisioning Server's way of doing things.  Using sysprep against linked clones or machines that were generated with a SAN Storage Vendor's duplication technology, i.e. NetApp, EMC, Hitachi, HP... do not boot from a single disk, but rather create copy on write clones of an original virtual machine.  Those can be sysprepped like any other machine and use no more storage than Ardence/PVS.  Vmware's Quickprep was likely used because it's faster than Sysprep.

Am I a fan of Sysprep, not really, I just wanted to point out that this problem is not pervasive across all virtual machine deployments.  Precreating 1000 VMs using NetApp, EMC, Hitachi... any vendor with COW technology doesn't take long at all, and they would join the domain like any other Windows machine that has been sysprepped.


Yeah I guess I could have been clearer in the semantics. I view a spawned copy on write clone the same as booting from a single disk.

But let me ask this. Do you think the technology we have today is ok.. I mean to precreate all those VMs? (obviously undertstanding that they don't consume actual disk space), or is there a better way? Maybe I'm just looking for an elegant solution when there's already a fine solution in place.


In the immediate term, I think this is up to the hypervisor/desktop virtualization vendors to solve, and this was one of the bigger technology hurdles we faced at Virtual Computer when we were designing and implementing our one-to-many management technology.  In fact, the problem is further compounded with distributed execution on a client hypervisor, as you need to make one master image work across thousands of endpoints that do not share a common stored LUN.  In our case, we also wanted to take a virtual machine that was created and subsequently updated using Microsoft hypervisor technology on a server and deploy it to our Xen-based client hypervisor with completely different virtual hardware characteristics.  It took a lot of creativity, many turns of the crank, and lots and lots of testing, but were ultimately able to crack the code on how to do with speed and scalability for both XP and Vista.  Having said that, we’d much rather spend our engineering cycles on exciting new virtualization features than on fixing aspects of Windows that break in a virtual desktop model, so while the Windows 7 offline domain join isn’t itself a silver bullet, it will without a doubt make life easier for third party product developers like us who are filling the gaps.


Unfortunately we are at the mercy of the OS we are virtualizing.  Using methods today other than sysprep or other SID modifiers for Windows like Quickprep open a security hole with the local account authentication.  Being that one of the advantages gained with SBC is security we should not create such a weakness.  Even if it gains us faster vm recreation we must resist exposing our systems to possible breaches.

Whoever comes up with the best answers do IT folks really care.?

I do agree with Doug Lane that we would rather virtualization engineers spend more time on exciting new features rather than work arounds for an OS that is not really virtualization aware. But unless the OS developers take on the task it will be up to virtualization vendors to take care of the problem.


Isn't this the promise of Altantis Computing/Unidesk? Unproven and new technologies, but they all about provisioing  layers quickly