Virtual Desktop Infrastructure, Part 3: Optimal VDI - 23 Jun 2011

In the first two articles in this series (Virtual Desktop Infrastructure, Part 1 and Virtual Desktop Infrastructure, Part 2), I covered the technologies that make up desktop virtualization, as well as the technique for creating a Microsoft Virtual Desktop Infrastructure (VDI) solution in Windows Server 2008 R2. Although Server 2008 R2’s built-in VDI solution will meet the needs of many organizations, for a true best-of-breed Microsoft-based VDI architecture that maximizes functionality and accessibility while minimizing management and required resources, thus enabling a VDI infrastructure that meets any organization’s requirements, you need to employ third-party solutions.

In this article I discuss Citrix’s XenDesktop 5 desktop virtualization solution, as well as the AppSense Management Suite solution, which focuses on user personalization virtualization. Other great solutions also exist, but I don’t have the space to discuss all of them here. XenDesktop and AppSense are complementary third-party solutions that let you maximize Server 2008 R2’s VDI benefits.

XenDesktop 5

XenDesktop is Citrix’s presentation virtualization solution; it enables the delivery of a desktop experience to pretty much any type of client device. It uses the ICA protocol rather than standard Windows RDP, thus providing a great experience even over very slow, high-latency links. XenDesktop also supports several high-performance components that make up Citrix’s HDX technology (High Definition eXperience) to give users a full-fidelity experience. Although many people think of Citrix as a Terminal Services–type solution in which the desktops are hosted on a server OS, XenDesktop also offers a very powerful client OS desktop experience through its own VDI implementation that interfaces nicely with Microsoft technologies. XenDesktop 5 offers several enhanced features over XenDesktop 4, plus it supports (and requires) Server 2008 R2 and Server 2008. (XenDesktop 4 was limited to Windows Server 2003 R2 and Windows Server 2003 for its services.)

Although this article focuses on XenDesktop 5’s VDI uses, it’s important to realize that XenDesktop 5 is far more than just extra bits for VDI. XenDesktop 5, with its XenApp components for application streaming and XenClient for client-side OS virtualization, enables many different methods for users to access and use virtualized OSs. This flexible solution, combining XenDesktop and XenClient, is called FlexCast. It isn’t a single piece of code or technology but rather Citrix’s ability to support essentially any type of endpoint and maximize the resources of that end client. To really understand this concept, let’s look at some of the key Citrix use cases.

Hosted shared desktops. When you think about old-school Citrix, you probably think of MetaFrame, which consists of one or more server OSs running Terminal Services (called Remote Desktop Services—RDS—in Server 2008 R2) with the XenDesktop technology overlaid, allowing many users to have unique sessions on a single OS instance. This option is still very popular because you get the highest number of users per OS instance (as many as 1,000 users per box) and relatively simple management. This scenario is great for task-based workers who don’t need to be able to customize the OS environment (which isn’t possible, because the OS is shared by all users).

Hosted blade PC desktops. Each user connects via the Citrix ICA client to a dedicated physical machine in the data center, which could be a blade PC or simply desktops that are relocated to the data center. This use case is typically for users with very high resource requirements, such as graphics professionals.

Local streamed desktops. The client OS runs on the user’s local computer without actually being installed. Instead, the computer boots over the network using the Preboot Execution Environment (PXE). The OS is streamed to the client as needed, which is actually how the hosted blade PC functions (as does the VDI solution, which I explain later in the article).

Local VM-based desktops. A new feature in XenDesktop 5 allows a virtual machine (VM) to be “checked out” from the XenDesktop infrastructure and run locally on the client machine, using the XenClient hypervisor. The key difference here between the local VM-based desktops and Windows 7’s VHD Boot is that with VHD Boot, the OS isn’t running within a virtualization environment, and only the file system is virtualized. With Citrix’s local VM-based desktops, the OS is actually running within a hypervisor, meaning all aspects of the hardware are virtualized, which introduces a useful capability: Multiple OS images can be run concurrently on the same desktop. Many organizations use this technique to have a corporate image running on a machine for work actions that are heavily locked down and a second personal image that lets users do what they want but doesn’t have the same access to corporate resources. These separate VM environments are totally isolated from each other, stopping vulnerabilities in one VM from affecting the other while still allowing the user to easily switch between them with a keystroke. These local VMs can actually be the same image a user is utilizing through VDI or other streaming methods but simply wants to take offline. Changes made offline are synchronized back (if desired) once network connectivity is again available, using block-level differencing, which minimizes bandwidth consumption.

Virtual applications. I discussed application virtualization, and Microsoft Application Virtualization (App-V) specifically, in the first article in this series. Application virtualization essentially abstracts an application from the OS by virtualizing all aspects of the OS to which the application commonly installs (i.e., the file system, registry, DCOM, user services), then runs the application in a virtual environment, which lets the application run on an OS without being installed on it. I also discussed presentation virtualization, in which an application runs on a remote server, with application window screen updates sent to the user’s desktop so that the application appears to be running locally, although all execution is actually performed on the remote server. Citrix’s XenApp provides the same capabilities; however, XenApp takes virtualized application accessibility to the next level, with great web-based UIs, plus the Dazzle plug-in for the local Citrix Receiver. (The Citrix Receiver is the main Citrix client application that’s used to connect to Citrix services.) Applications are either streamed seamlessly to the OS and executed locally or executed on a Citrix server and presented via presentation virtualization, depending on the endpoint capabilities and best performance. XenApp actually supports App-V sequenced applications, which gives corporations the benefit of XenApp’s flexibility in making virtualized applications available while leveraging App-V’s power and superior capabilities for sequencing and abstracting applications from the OS. In addition, the Citrix interfaces can present web-based applications and Software as a Service (SaaS) applications, creating a corporate application marketplace that includes everything a user will ever need to access.

Virtual Desktop Infrastructure. Last but not least—and the entire focus of the three articles in this series—is VDI, or as it’s otherwise known, hosted virtual desktops. Citrix’s VDI solution is one of the six main use cases, but it leverages the technologies used by most of the other use cases that I discussed—which is what makes the Citrix desktop virtualization solution so powerful and appealing. A great deal of this power comes from XenDesktop’s provisioning services capability and its HDX user experience.

When I discussed the Microsoft VDI solution in the second article in this series, I explained that one of the pain points is managing the client OS images. Remember that each VM needs its own Virtual Hard Disk (VHD), and those VHDs must be patched and managed, or they must be routinely deleted and recreated. Although this process can be automated, it’s still fairly storage intensive—not to mention the amount of storage necessary to store a VHD for each virtual desktop. This is where the Citrix Provisioning Services component comes in.

Citrix Provisioning Services. Citrix Provisioning Services is an amazing piece of technology that lets you have a master OS image that’s streamed to clients as it’s needed, then cached. Note that I use the term client rather than VM; this is intentional. Although the focus of this article is VDI, I want to be clear that this streaming of an OS isn’t limited to streaming to a VM. Citrix Provisioning Services can stream to a VM, a blade PC or workstation in a data center, or a user’s desktop. All these types of clients can be streamed with the Windows OS over the network, thus removing the need to have a local OS and therefore removing the need to maintain and manage that local OS.

Remember that with application virtualization, we send only the bits of the application over the network that are actually needed for the parts of the application the user is using. Citrix Provisioning Services does the same thing but with the whole OS. Basically, the client device boots over the network and obtains an IP address from DHCP as usual. Citrix Provisioning Services’ PXE service responds with its Trivial FTP (TFTP) location and the bootstrap name, which allows the client to boot over the network after the bootstrap is downloaded. The client can then locate a provisioning server that will create a virtual disk (vDisk, in Citrix terminology) based on the specified configuration. Next, the client device boots into Windows, and the Windows OS is streamed to the client as the client accesses the different parts of the Windows image and is cached to avoid additional network traffic.

Virtual disks. Obviously, you don’t want every client that Citrix Provisioning Services provides with an OS to require its own dedicated VHD. This would consume a huge amount of disk space and not save any management work in terms of patching and maintenance—in fact, it would increase your workload. Instead, you want to use the single master image that all the clients in your environment use, whether they’re blade PCs, desktops, or VMs. If you use a master image, that image must be read-only because you can’t have 500 different clients writing to the same VHD—to say that this situation would be confusing would be an understatement! Instead, the master image is placed in a read-only mode and each client is assigned a virtual disk (again, vDisk according to Citrix) that’s used to store any writes the clients makes, such as OS customization or Active Directory (AD) membership.

A standard vDisk image type is typically used, which means that each time the client reboots, the vDisk content is wiped, essentially resetting the client back to the master image state. This is preferable in most scenarios, especially VDI. We can also use a differential vDisk image type, which works the same way as the standard vDisk, except writes are persisted across reboots (meaning that any changes are kept). The differential vDisk would be limited to select client environments that need changes persisted; however, it’s important to remember that if the master image is changed (e.g., if patches are applied), even differential vDisks are wiped.

If you need a long-term persistent state of a client OS, you can use a private vDisk, which is a read/write image just for that client. However, you lose most of the benefits with this model because you must patch and manage the image separately from your master image. If you architect your environment correctly, the need for this type of environment should be very limited because the application and user states are virtualized and dynamically composited together at user logon time. Thus, a user has the impression of being on the same desktop even though a different OS might be used for each connection.

The virtual disk location is configurable and can be stored on the provisioning server (which isn’t typically recommended), the client disk, or in client memory. Remember that in the case of VDI, the provisioning service’s client is actually the hypervisor, so this method would use the hypervisor’s disk or memory resources.

What all of this means is that we now have a single master image that we must patch and maintain and that will be used for all provisioning service clients: our VDI VMs, blade and workstation data center PCs, and streamed desktops. In addition, this master image can be checked out by clients and used offline for local VM desktops. Not only do we save a huge amount of maintenance work, but our disk space requirements on the data center back end also drop drastically because we must store only the virtual disk write changes. These changes will be minimal, considering that the applications are virtualized and all user data is redirected to network folders.

Machine Creation Services. New to XenDesktop 5 is Machine Creation Services (MCS), which leverages Citrix Provisioning Services technology but requires less infrastructure and configuration and is targeted at small environments and proof-of-concept projects. Rather than performing OS streaming only as needed, MCS still has a master image—but in addition to the differencing disk where changes are written, there’s an identity disk that stores the unique information about the OS instance, such as AD membership and computer name. The reason MCS is targeted for small environments is simply that it’s a newer technology that hasn’t been tested in large environments. However, I think we’ll see similar scaling for MCS and Citrix Provisioning Services in the future. It’s important to note that MCS works only on VM-based desktops (i.e., VDI), whereas Citrix Provisioning Services supports all the different use cases I discussed, as well as provides much more power and flexibility.

ICA. Citrix Provisioning Services sounds great, but what about the actual client experience when accessing the OS remotely? Citrix installs its Virtual Desktop Agent (VDA) on all the Windows OSs it serves. Citrix’s XenDesktop solution includes the ICA protocol, which replaces Microsoft’s RDP and is a key part of Citrix’s HDX user experience. (HDX is another key feature of XenDesktop that offers highly efficient bandwidth utilization, adjusted quality based on latency and speed, multimedia support, Adobe Flash, 3D applications, real-time collaboration, and many types of USB peripherals.) If your endpoint devices have capabilities such as graphics rendering, those capabilities are utilized, thus reducing the load on the back-end servers by sending the native media streams and graphics commands. Where available, optional server-side hardware accelerators can be leveraged.

The area in which Citrix shines brightest is endpoint device support for ICA, which is why many organizations leverage Citrix for presentation virtualization. As new platforms come out, Citrix seems to be ready and waiting with a version of its Citrix Receiver (the ICA client) for that platform. The Citrix Receiver covers all the major platforms, including Windows 7, Windows Vista, Windows XP, Windows Mobile, Mac, Linux, iOS (yes, your iPad will work), Android, and BlackBerry.

Citrix/Microsoft partnership. Last, but certainly not least, is Citrix’s unique relationship with Microsoft regarding desktop virtualization. Citrix and Microsoft have joint solutions for desktop virtualization, and the two companies’ development teams work closely to ensure the best client experience when using their joint solution. Citrix integrates very well with Microsoft System Center Configuration Manager (SCCM), App-V, and Microsoft System Center Virtual Machine Manager (VMM) for virtualization management. Citrix will also take advantage of Microsoft’s Hyper-V 2008 R2 SP1 Dynamic Memory and RemoteFX features in an upcoming XenDesktop update. For more information about XenDesktop 5, go to Citrix’s XenDesktop website.

AppSense Management Suite

Windows 7 made improvements in its roaming profile technology to allow background synchronization. However, we still need different profiles for XP clients (version 1) and Windows 7 (version 2) and Vista clients, in addition to different profiles for terminal servers, and so on. Also, problems can occur if users log on concurrently to multiple machines with the same profile—in which case the last writer wins.

Citrix includes some basic functionality to improve handling of the user profile; however, the best solution comes from AppSense. The company’s AppSense Management Suite virtualizes and streams the user profile as needed and isolates distinct parts of the profile, including individual application portions, to let users have multiple concurrent sessions using the same profile across different platforms. Without users even logging off, user profiles are kept synchronized in real time.

Typically, customizations made to an application that’s natively installed and one that’s executed using application virtualization aren’t shared, so you must customize the applications multiple times. With AppSense your customizations are persisted if the application is installed locally, is running remotely, or is virtualized. These customizations aren’t limited to cosmetic changes. Applications with user-defined dictionaries, for example, are maintained not only by profile syncing but also by capturing file system content that contains application data (e.g., custom dictionaries).

The following is a great example of AppSense in action. Suppose you have one user who is logged on to a Windows 7 machine and an XP machine, using the same username and therefore the same user profile. On the XP machine, the user launches Microsoft Word, changes the layout of Word, adds some words to the custom dictionary, saves a new document, and closes Word without logging off. The user then switches to the Windows 7 machine (which is already logged on) and starts Word. The document the user saved under XP is listed under recently used documents; when the user opens the document, the words the user added to the custom dictionary are available, and the look and feel of Word match what the user configured in the XP session.

This flexibility and granularity is achieved because AppSense doesn’t treat the profile as a single blob but instead breaks the profile down into individual elements that can then be synchronized and streamed to the client as needed by the environment and applications. This treatment of the profile and supporting file system structures is achieved in a similar fashion to how application virtualization works for applications. When the user launches an application, AppSense injects a DLL (appinit.dll) to intercept file system and registry calls by the application. This interception sits above the App-V engine interception, which means customization and configuration of applications are kept and synchronized between different sessions regardless of whether one app instance is local and another is virtualized, as Figure 1 shows. (Note that App-V is supported but not required.) As you can see, three layers exist in an environment: the OS virtualization layer, the application virtualization layer, and the full user virtualization layer. This structure allows full flexibility and portability across platforms and delivery mechanisms.

AppSense clients communicate over HTTP or HTTPS to the AppSense Personalization Server role, which uses SQL Server to store the profile elements. This communication occurs each time a user opens or closes an application. AppSense checks whether anything has changed, and if so, synchronizes the delta, thus minimizing network usage and making the synchronization process very fast.

Using SQL Server to store each profile element enables other powerful capabilities. On the AppSense Personalization Server role, administrators can launch an AppSense Personalization Analysis of all users or selected users, then drill down to look at each user’s personalization, including the personalization of each application a user has used. You can open each element to see the virtual registry and file system associated with each application’s part of the profile, which can be modified (e.g., deleting settings from the registry or files from the virtual file system to then be used the next time the application launches).

Sometimes users encounter problems, and you might need to roll back to a previous profile version. AppSense lets you roll back a profile to a previous point in time—but even better, you can also roll back an application element to a previous point in time without affecting the rest of the profile, as Figure 2 shows. This capability would be useful, for example, if a user called the Help desk to report a broken application; the administrator could simply roll back the application’s configuration to a previous point in time.

In addition to being a great VDI solution, AppSense is also a useful technology throughout the entire enterprise. For example, migrating from XP to Windows 7 with AppSense is a snap because there’s essentially no work related to the user profile (which is typically a large part of the migration process). Even if you aren’t currently using AppSense, when you deploy the program, the agent will automatically migrate XP profiles into AppSense. As soon as you test those pesky applications for Windows 7, you’ll be good to go.

Looking toward the future, AppSense is working on solutions to handle user data and user-installed noncorporate applications with the same power with which the AppSense Management Suite currently handles user profiles and policies. I’m excited to see these features in a future release. Although I touched on only one of AppSense’s major features in this article, the product offers a range of benefits, including a full policy engine that’s highly granular and that doesn’t require logons or logoffs to apply policy changes but can still read standard Group Policy ADM templates. Because AppSense virtualizes the user state, the product can also help with App-V virtualization issues for certain applications that otherwise require complex changes to the virtualized application. For more information about AppSense, go to the company’s website.

A Truly Integrated Solution

Now that you understand all the components available for creating a VDI architecture, as well as their power, you can see that overlaps exist between technologies. Citrix provides application virtualization with XenApp, whereas Microsoft provides App-V. Citrix has XenServer and Microsoft has Hyper-V. Microsoft has roaming profiles, but AppSense’s features are far superior to the in-box roaming profiles. We need to consider all these technologies together to create the most optimal solution.

Working from the ground up, an optimal architecture uses Hyper-V for the hypervisor. Why would we use Hyper-V rather than XenServer? Because Hyper-V provides the best performance and density for Windows 7 virtualized OSs. If you’re setting up an XP VDI environment, then XenServer provides better performance—however, if you’re setting up an XP VDI environment today, we need to talk! Another reason to use Hyper-V is Microsoft’s investment in the Hyper-V technology, including improvements in Server 2008 R2 SP1 to add dynamic memory and RemoteFX, both of which are key VDI features that XenDesktop will also leverage in the future. Even Citrix recommends the use of Hyper-V over its own XenServer for Windows 7 VDI environments. The best choice to manage the Hyper-V environment is VMM.

Next, we need to consider the actual brains of the VDI environment, including the broker, provisioning services, and application streaming. XenDesktop is the best choice in this area because it offers superior functionality over Microsoft VDI, primarily because of its capabilities around master images as the basis for the client VMs and its wide array of supported client devices through ICA and HDX.

For application virtualization (i.e., abstracting the application from the OS), App-V is the best choice. Some people might wonder why you’d use App-V sequencing rather than XenApp profiling, especially because XenDesktop includes XenApp, so you’ll already own it. However, several reasons exist for using App-V rather than XenApp for application virtualization. Again, Microsoft has invested a huge amount of time and research into making App-V the most powerful application virtualization technology. The App-V sequencing process is far more flexible and comprehensive than the XenApp profiling process, resulting in greater application virtualization success. App-V supports virtualization of user mode services and DCOM, which XenApp doesn’t. In the future, Microsoft applications will be delivered with templates that enable very easy sequencing with App-V; the rest of the industry is likely to follow. XenApp hooks into App-V, allowing XenApp services to deliver App-V–sequenced applications. Thus, we get all the virtualization power of App-V and the delivery and presentation capabilities of XenApp—the best of both worlds.

The obvious OS choice is Windows 7. In addition, installing the Citrix Virtual Desktop Agent lets you use the ICA protocol to access desktops and take advantage of the HDX experience from all the various platforms that provide Citrix Receivers.

For user virtualization, AppSense provides a seamless user experience during a VDI session, local session, terminal server session, or even in a mix of OSs. AppSense uses a minimum of resources and bandwidth but provides great management capabilities to help solve any user problems that might occur.

Although this integrated solution, which Figure 3 shows, combines software from three different vendors, these vendors have a very strong partnership. This solution combines the best products available to create a state-of-the-art VDI architecture that will meet all of your organization’s virtualization needs.