The Importance of
“User Workspace
Virtualization” in
Desktop Virtualization
of the user workspace and the user personalization aspects of desktop virtualization, it’s probably worth spending a few paragraphs discussing what is meant by “desktop virtualization” in the context of this paper.
When thinking about “desktop virtualization,” a lot of people immediately think “VDI.” But VDI is only part of it.
At its most basic level, “virtualization” is separating the physical from the logical, so therefore “desktop virtualization” is separating the physical desktop device (laptop, desktop, etc.) from the logical desktop software (Windows).
So while it’s true that VDI is desktop virtualization—it’s only one type of desktop virtualization. The entire desktop virtualization universe is much bigger than just VDI.
For example, Terminal Server (and the various Terminal Server-based solutions like Citrix XenApp) is desktop virtualization, since it provides a desktop to a user (from the remote server) to a user’s device (like a thin client) where the desktop OS is not installed on the device. (In this sense, Terminal Server and VDI are very similar, with TS being a multi-user and VDI being a single-user type of server-based computing.)
But desktop virtualization can also be more than server-based computing. For example, “OS streaming” describes a technology where a copy of Windows runs locally on a client device (so “client-based computing” rather than “server-based computing”). But with OS streaming, the OS image is “streamed” from a central point down to the client rather than installed locally. And this OS streaming can be used “natively” on a client device—where the only real change from traditional computing is that the copy of Windows is a shared copy coming across the network instead of installed locally— or it can be used in combination with some kind of hardware virtualization running on the client device.
Additionally, there’s a whole other category of desktop virtualization that comes from combining traditional hardware virtualization with the newer desktop virtualization. Citrix, VMware, and startup companies Virtual Computer and Neocleus all intend on releasing “client hypervisor” products later this year. Client hypervisors are similar in concept to VMware ESX or Microsoft Hyper-V, except they run on laptops
like servers.)
Finally, other companies, such as RingCube and Mokafive, have products which allow administrators to run centrally-controlled corporate virtual machines directly on client devices on top of existing client operating systems (even Linux or Mac), combining user freedom of choice and administrator control.
So as you can see; VDI, terminal server, OS streaming, client hypervisors, and client-based virtual machines are all forms of desktop virtualization.
Why a single master disk image is important
As was briefly mentioned in the opening paragraphs of this paper, one of the key reasons companies implement these various forms of desktop virtualization is to save money through reduced management costs. And one of the primary ways that happens is by letting multiple (hundreds or even thousands) of users share a single copy of Windows. Doing so means that all your Windows maintenance tasks— hotfixes, patches, and configuring changes—can be done once to that single shared master image, instead of over and over and over for each individual user.By the way, it’s probably worth pointing out that “sharing” a copy of Windows does not literally mean that multiple users actually login to and use the same Windows VM or even the same disk image. Instead, this “sharing” capability is enabled via things like snap-shotting or cloning or dynamic provisioning or some other technical capability that lets a single disk image (vhd, vmdk, etc.) be used by multiple machines at the same time. So you get lots of users, one instance of Windows.
To those who’ve never considered this sharing concept, a lot of complex problems become pretty clear. For example, if all your Windows desktops are sharing the same disk image, how do you deal with duplicate computer names and SIDs and all the other problems that would come up as soon as you tried to boot up multiple
these problems (the discussion of which is beyond the scope of this paper). However, there are still a lot of logistical that users will face, namely, if each user starts with the same Windows disk image, how do you differentiate one user’s desktop from another? How do you let users customize their environment or change their own settings?
While these problems can seem daunting at first, we’re fortunate that there’s a fifteen-year precedent showing us how to do this: Terminal Server! (After all, in a Terminal Server environment, several users “share” the same Terminal Server Windows image—it’s just that they share it in their own session instead of on their own computer.)
So in order for desktop virtualization to be successful, we need to figure out a way for all users to share a single master copy of Windows while not losing the capacity to personalize their own desktop as they see fit.
Making the “master” image a reality: The
“layer” concept
Now that we’ve looked at why getting to a single master shared disk image is important, let’s dig in to the “how” of how this happens. Microsoft Windows (from the old days of Windows NT up through Windows 7 today) is based on architecture that’s meant for a single user to run it locally on a client device. It has always been assumed that users would be able to install apps and personalize their desktop as they saw fit. So that’s fine if we’re using Windows the “old” way. But if we want to let many users share a single master copy of Windows in a desktop virtualization environment, we have to think about changing the way that Windows works.
This “thinking differently” is more than just a user’s desktop personalization. If we want to share a single master disk image for all users, we also have to address the fact that different users will want to use different types of hardware, and that different users will need different applications.
Fortunately there’s an easy way to graphically represent this way of thinking. If we think about all the different kinds of customizations we need for a single copy of Windows to be shared by many users, we can group them into several broad categories, including:
• Operating System • Hardware
We can visualize these categories as a set of layers. Much like other layered models, such as the OSI stack, we can think of higher layers building on top of lower layers, producing a “desktop stack” that looks something like this:
You can probably imagine that if we were able to cleanly delineate these four layers on a Windows desktop, it would be relatively easy for us to share that master disk image among all of our users. Each user could start with his or her own “hardware” layer (whether that was a local laptop or a remote VDI instance). Then we could “lay down” our OS layer (which again, is shared by many hundreds or thousands of users). Then the applications could be laid down as needed for that specific user, and finally the user desktop workspace (or “user desktop”, “personality” or “user session” or whatever you want to call it) could be laid down on top of that.
You would have a dynamically-created Windows desktop that’s totally customized for each user, by being built dynamically from various components at various layers as needed. It’s probably easy to understand why this would be great, and at this point, most people reading this are probably thinking, “Yes, please!”
Unfortunately the real world is not so simple. While we really want a layered model shown back in Figure 1, the reality is that Microsoft Windows just doesn’t work that way. In fact, Figure 2 is probably more accurate:
Hardware
operating system
applications
User Workspace
If you look closely at Figure 2, you’ll see that technically all four layers are there. We have hardware, OS, application, and user workspace layers. The problem is that there’s not a clean level of separation between the layers.
What exactly does this mean? Consider the OS layer and the hardware layer. There’s a lot of hardware-specific stuff in the OS layer that ties it to a specific piece of hardware (drivers, configurations, HKLM registry settings, etc.). If you’re not sure about how much of a problem this is today, just pull a hard drive from one desktop, install it into another desktop that’s a different model, and turn it on. The desktop probably won’t even boot up, because each copy of Windows was highly customized for the specific client device on which is was installed.
The same can be said about applications. Today’s Windows applications are very tightly tied to the OS on which they’re installed. (Think of HKLM registry settings, shared DLLs, drivers, kernel-mode EXEs, services, etc.) So again, you can’t just lift an application from one instance of Windows and run it on another. (Again, just try to copy an application’s “Program Files” folder from one computer to another. Chances are good that the app just won’t run unless it was properly “installed” pm on the new desktop. This installation process is what highly customizes that application for that specific instance of Windows.)
As if this wasn’t messy enough, we even have some overlap
Transforming Windows into a
properly-layered solution
As you can probably imagine, if we could sort of “transform” Windows so that it had clean separation between the layers, that would enable us to do all sorts of great things in terms of desktop management.
For example, we could have different apps for different users while sharing the same base installation of the OS. Or we could have user settings follow the users around as they logged in and out of different types of hardware.
The good news is that being able to cleanly separate the various layers of the Windows stack is really what “virtualization” is all about, and there are several different products and technologies that facilitate this.
For example, hardware virtualization products such as VMware ESX, Citrix XenServer, and Microsoft Hyper-V already create the nice clean separation between the OS layer and the hardware layer. (After all, if you run your Windows machine in a VM, then yes, you can cleanly move it between different types of hardware and it still runs.)
And the various application virtualization solutions, such as Microsoft App-V, VMware ThinApp, Symantec Workspace Virtualization, and Citrix XenApp streaming all work to make a clean layer break between the application and OS layers. Understanding that, it’s easy to see how a similar product which virtualizes the user settings could create a nice clean
Hardware
operating system
applications
User Workspace
Different Hardware
operating system
other applications
User Workspace
Figure 3. A properly layered Windows stack lets us do cool things
Hardware
Operating System
break between the user desktop and the application and OS layers.
An added bonus of the proper “layerization” of Windows is that much like the OSI stack, we can allow higher-level layers to essentially ignore the layers below them. In theory, if our applications were properly virtualized, it wouldn’t matter what the OS layer looked like. (Obviously today it still has to be Windows, but you could envision an application virtualization environment where a single Windows app package could run on Terminal Server, Windows 7 client, or Windows XP.) The same is again true at the user workspace layer. If we properly isolate and virtualize all of our user desktop settings, then the user could get his or her own, rich, fully-customizable desktop regardless of which type of desktop virtualization was used—be it Terminal Server, VDI, client hypervisors, or a traditional desktop.
User workspace virtualization: isn’t this just
roaming profiles?
If we’re defining user workspace virtualization as the abstraction of all user settings from the applications and the OS, then there’s a good chance you read this and think, “Hmm… that sounds a lot like roaming profiles.”
And the truth is that’s absolutely right. The concept of user desktop virtualization is essentially identical to the concept of roaming profiles. The problem is again that the way roaming profiles work in real world doesn’t quite jive with the vision of what we want.
The main drawback to roaming profiles is that they only capture certain portions of the user desktop. (Specifically they capture files written to the user profile folder and registry keys written to the HKCU registry area.) But in the real world, user settings are written and saved in several all over the place—
not just these two pre-defined profile locations. So roaming profiles won’t capture any files written outside of the users profile folder, and they won’t capture settings written into other registry areas.
The other problem with roaming profiles is that they’re “all or nothing” in terms of the registry. So as an admin, you can turn on roaming profiles which means that each user’s HKCU will be saved and restored. But once you do that, you lose the ability to then make changes to the registry for the user. From a practical standpoint, this means that you can’t pick-and-choose which user settings you’d like to enforce versus those that you’d like to let the user customize. So with the roaming profiles capability built-in to Windows, it’s either the “Wild West” where users can control everything, or “total lockdown” where they can control nothing.
By the way, if anyone reading this is not familiar with the drawbacks of roaming profiles, or if anyone reading this doesn’t believe relying only on roaming profiles won’t work, then I challenge you to use roaming profiles for a week for your own personal Windows desktop. Try to work as a “regular” user and see what you lose by using roaming profiles, and then see if your mind is changed!
so what is user workspace virtualization?
From a high-level, all we’ve done so far in this paper is (1) established that yes, user workspace virtualization is important for successful desktop virtualization usage, and (2) we can’t rely on roaming profiles by themselves. So what exactly is user workspace virtualization, and how does it differ from the built-in roambuilt-ing profiles capabilities?Much like Windows roaming profiles, user workspace virtualization solutions “watch” what changes and
customizations a user makes while using his or her desktop. These changed are then encapsulated and stored in a central
Hardware
operating system
applications
Figure 4. The various types of virtualization products give us clean breaks between layers
app Virtualizaton
And since we’ve fully decoupled the user’s workspace and desktop customizations from Windows, administrators can refresh or re-clone the master desktop again and again without affecting a user’s personalizations or settings. Of course we still haven’t specifically addressed how these user workspace virtualization products differ from the built-in roaming profiles capabilities, so let’s go through those now: Unlike Windows roaming profiles, most user workspace virtualization products operate continuously, so any user change or personalization is instantly captured and transmitted to the central storage location. This means that users’ personalizations are retained even if they don’t get a “clean” logoff. This is a big advantage over roaming profiles, since with roaming profiles the saving process happens as part of the user logoff process.
Second, and perhaps more importantly user workspace virtualization products have the capability to capture all changes made during a user’s session, including those that are written outside of the standard user profile locations. This means that the types of changes and personalizations captured and retained by these products is much broader that what can be captured via roaming profiles.
Third, all user workspace virtualization products have some form of centralized management console that administrators
configuration, while at the same type giving the user the ability to customize his or her own Out of Office settings. And finally, since these user workspace virtualization products are written by companies other than Microsoft and purpose-built for these kinds of use cases, they have a much broader compatibility than the built-in roaming profiles capabilities. For example, what if your specific use cases dictate that you need to provide some applications via Windows Server 2008 Terminal Services, local desktops via Windows Vista, and VDI desktops via Windows XP? A roaming profile won’t “survive” in that environment, as the different versions of Windows will change and corrupt things. (And some user settings saved on one platform won’t be read on another, forcing the user to make the same personalizations over and over again as he or she switches platforms.)
