Thursday, March 4, 2010

Citrix and Microsoft: Better together for “merchandising” applications

By:Scott E. Lane
What exactly is application merchandising? It is a term that we will start hearing more and more about in the industry. Especially as desktop virtualization becomes more prevalent and application virtualization technologies continue to mature. We will also see more of a focus on this as companies start to leverage “bring your own PC initiatives”. This document is an overview of how Citrix and Microsoft are working together to enable easy, iTunes-like access to corporate issued applications that are delivered with different technologies.
This News Article details a joint announcement between Citrix and Microsoft to extend the capabilities of Application Virtualization. This means that Citrix will add value to App-V in a similar manner to the way Citrix has for years added value to RDS or Terminal Services.

First off let me approach this from a very high level, and then I'll get specific about the moving pieces that make this all happen. Basically, you have three methods for placing applications inside of virtual desktops.
  1. Install the applications directly onto the base vdisk image that comprises the virtual desktops. This is less attractive because each time an application requires updates, the vdisk requires updates. However, it does afford a very fast launch for the user when the application icon is clicked. We typically see this for core system apps like anti-virus and the Citrix Receiver Framework (more on that in a moment). We also see it sometimes for apps that everyone has, like Adobe Reader and the corporate MS Office Standard.
  2. Stream the apps into the virtual desktop. This would be either XenApp streaming or MS App-V (hence the announcement). The bigger issue here is once we supply applications that aren't installed, how do we merchandise them to the users? I'll have more on that in a moment, but this is part of the bigger Citrix Microsoft partnership. The advantage of streaming these apps is that one vanilla desktop image can host a wide variety of applications for different user classes, depending upon who logs in. The application set dynamically assembles for the user upon logon to the VDI session. Additionally, even if you installed office into the base OS image, you can leverage streaming or application virtualization technologies for differing versions. For example, say you've standardized your company on Office 2007. But then someone says they have an old Access database on Office 97 and it won't convert. You can stream Access 97 to this user or group exclusively and it won't interfere with Office 07. This is true whether Office 07 is installed or streamed. We are able to do this because streaming, both in Citrix or MS App-V flavor places the application execution into isolation environments on the target. In this case the target being the virtual desktop. Management of streamed apps really helps with overall application delivery. That's because file shares, which Citrix calls App Hubs, hold single instance streaming profiles of each app to be delivered thru streaming. That means patching these apps doesn't require the VDI disk image to be modified. It also means that an app administrator can apply patches to the app image just once, replicate it to all "app hubs", and have the patch automatically be in place for all users. Application streaming can also enable offline usage of centralized apps. This is not pertinent to VDI approaches. But it is very useful for road warriors who carry laptops, and in the near future for our XenClient laptop hypervisor users.
  3. XenApp hosted approach. You are most familiar with this one, as most Citrix customers deliver apps this way. Its the application running on a XenApp server and showing up on a target. But in VDI, the target for XenApp hosted application is the virtual desktop itself. The reasons why this is chosen for delivery in a VDI world are varied. One would be that you already have applications set up and tuned for delivery in this method, and that it makes sense to continue using XenApp infrastructures in this manner. Also, it depends on the data tier location. For example if the VDI infrastructure is in Kansas City but the application backend itself resides somewhere far away, it would make sense to deliver the application with a XenApp hosted infrastructure located at the remote location where the application resides. Additionally, there are sometimes resource intensive applications that will cut into your VDI session per hypervisor host scalability. These apps are sometimes better off being delivered from a XenApp server where their resource needs can be better managed while keeping balanced in the hypervisor silos.
Delivery Framework
Okay, now I've described 3, and really 4 methods for placing applications inside virtual desktops. The "install on vdisk" option is pretty self explanatory. But when we choose the other methods, we suddenly end up with a bunch of clients, client interfaces, and client updates. The user suddenly has different methods to get their apps depending on how they are delivered. That's where Citrix comes into a partnership again with Microsoft with two new technologies, Receiver and Dazzle.

Receiver is a client framework that you install on an endpoint, and in this case the base Vdisk of your VDI infrastructure. It is the "keeper of the clients" or what we now call plug-ins. Once receiver is in place it talks back to a virtual appliance, Merchandising Server.

Merchandising Server runs as a small footprint on a XenServer back in the datacenter. Administrators install the plug-ins there, and configure which plug-ins (versions) are to be used. When the user logs into their VDI session the Receiver checks with the Merchandising Server. If there is a newer version of say the ICA Client (now called the Plug-in for Hosted Apps), the new version is automatically downloaded and made available for the user in the VDI session. Same is true for the Citrix streaming client (now called the Citrix offline plug-in). We'll do other plug-ins too from the Citrix side including the Password Manager Agent and the Access Gateway Secure Access Client (which doesn't apply in VDI, but its great for laptop users again, and XenClient users in the future). But here's the MS and Citrix marriage again, we'll also deliver the App-V streaming client thru Receiver, so that it’s always kept up to date.

So now with of the plug-ins in place, we need one central place for users to get their apps. Typically users expect them to be on the Start Menu. But with so many varied ways to get applications into the virtual desktops, only the "hard installed into the vdisk" apps are showing in the Start menu. That's where Citrix Dazzle comes in. We call this delivery "merchandising" the applications, much like iTunes provides a self service store for music and video content. Dazzle is a self service store for application content.

Dazzle can be pushed out and managed thru, you guessed it, the Citrix Receiver and Merchandising Server. Once I open Dazzle, I can pick and choose from all of the apps being made available to me. The sources can be App-V, Citrix Streaming, or Citrix Hosted. If I'm a road warrior who uses a laptop or XenClient, I am told if the application is available for offline use, and I can choose appropriately. Once I select my apps, they appear in the start menu. The user can then put icons on the desktop if they wish. File type association works.

So there is one final piece to this simple puzzle. As you know, when I log off a VDI session, the pooled VM reboots and any changes made while the VM was running are thrown away. That means all of the icons for the apps that I selected, right? Not when profile management is in place. That's why Citrix has Profile Management. It’s a lot like roaming profiles, extending the base profile infrastructure that MS provides us. Profile Manager takes the user environment changes, like the desktop shortcuts and Start Menu changes, and migrates them off when the VDI session is logged off. When the user logs back in, perhaps to a completely different pooled VDI VM, the users profile settings are automatically applied. That means the icons are there for launch.

So what if I need a new app, and I go into Dazzle and can't find it? In future releases we will include application requesting. When a user requests an app it will set off a workflow to get the request reviewed, and ultimately fulfilled if appropriate.

So that's our vision, and after that explanation of how all of these pieces fit together, and what they do, where is Citrix with releasing these components. Here are the current releases, as of this writing, with the status of functionality.

Citrix Receiver
  • Currently available, version 1.1
  • App-V plug-in support is expected in future release
Receiver supports the following new plug-in releases:
  • Online plug-in 11.2 (XenApp Hosted)
  • Offline plug-in 5.2 (XenApp Streaming)
  • Service monitoring plug-in 5.1 (EdgeSight)
  • Secure access plug-in 4.6.1 (Access Gateway)
  • Dazzle Tech Preview
  • Communications plug-in 3.0 (EasyCall)
  • Profile Management plug-in 2.0

Citrix Merchandising Server
  • Currently available, version 1.2
  • Must run on a XenServer as a virtual appliance
  • Support for other hypervisor platforms expected in the future
  • Manages the setup of Citrix Receiver component that is running in VDI desktops and mobile endpoints
  • Enables "plug-ins" to support multiple types of delivery services
  • Centralizes management of all updates
  • Enables access to web-based user support services
  • Offers robust management reporting feature
Citrix Dazzle

  • Currently available, version 1.1
This is basically a Tech Preview version, I have noticed the following issues/workarounds:
  • This version is English only
  • Launching Dazzle invokes an animated splash screen which requires Windows Media. For quicker launches, especially in VDI situations, this splash screen can be disabled by simply renaming the windows media source file
  • This release doesn't inform users when certain streamed apps are not configured for their OS
  • Pass thru authentication is not available yet. However, users can choose to have their credentials saved for subsequent launches.
  • Receiver does not yet officially support App-V plug-ins, however, there is a documented way to deploy App-V plugins with the Merchandising Server. It is in tech preview right now. Dazzle can merchandise App-V apps, this being done as published content thru XenApp or a published app (which pulls the App-V package to the XenApp server and connects the user thru ICA). We will probably see more App-V options within the XenApp console itself in coming releases/feature packs.
So to answer a question you probably have by now, are we there yet? Well no, not quite. But I expect in the very near term we will have new releases. This announcement is nearly 7 months old now. I know we have made significant progress in these areas, as it is a VERY high priority. I also know that internally at Citrix we have all of this working. Check out the attached video; My colleague at Citrix proves this is not vaporware, and note this video was recorded 7 months ago.
Following Kurt’s steps, I have actually pieced it together in a lab. Nothing official here, but we could see a full release of Dazzle with XenApp6 (Project Parra). Who knows? We may see more details on App V delivery. I honestly don’t know myself, as I’m not in Product Management. But I can assure you this tight Microsoft integration is a very high priority for Citrix, and we can expect the missing pieces to be in place very quickly.

Keep your ear to the ground for timeframe announcements.
Read Even MORE!!!
blog comments powered by Disqus
Microsoft Virtualization, Citrix, XENServer, Storage, iscsi, Exchange, Virtual Desktops, XENDesktop, APPSense, Netscaler, Virtual Storage, VM, Unified Comminications, Cisco, Server Virtualization, Thin client, Server Based Computing, SBC, Application Delivery controllers, System Center, SCCM, SCVMM, SCOM, VMware, VSphere, Virtual Storage, Cloud Computing, Provisioning Server, Hypervisor, Client Hypervisor.