I won’t go into great detail in regards to benefits of layering technologies when deploying VDI solutions.  I will say, and perhaps this is an oversimplification, that the goal of any layering technology (such as Unidesk or VMware App Volumes) is to simplify the deployment, management, and updating of operating systems and applications that comprise a virtual desktop environment using a building block approach.

In my head, I visualize OS and application layers as Lego’s.  I think of the OS layer as that big green piece which serves as the foundation and the smaller blocks, representing the application layers, are used to build whatever my mind imagines. Though I may have a finite number of pieces, I can use those pieces in an infinite number of ways.

So, what does this have to do with Citrix Provisioning Server?

Citrix Provisioning Services (PVS), often referred to as the “secret sauce” of any XenApp/XenDesktop deployment, provides a streaming service which allows physical or virtual computers to obtain an image from the network. When using PVS, an administrator prepares a Master Target Device for imaging by installing an operating system and any required applications on that device.  A vDisk image is created from the Master target device’s hard drive and saved to the network.  The Provisioning Server(s) are then configured to stream the vDisk to configured target devices on demand, in real time.

To date, PVS has been the primary method of deploying, managing, and updating server images to ensure consistency throughout the XenApp environment.  However, going forward, will PVS continue to be the primary method used to deploy new XenApp servers and ensure consistency throughout the environment?  As good as PVS is, I’ve encountered 2 main problems in which it is used in XenApp environments:

1. Gold image sprawl

  • Even in the most basic PVS environments, organizations will inevitably have multiple master images.
    • Some applications won’t work together with others and so multiple master images need to be created to separate applications which don’t necessarily mix well.
    • Multiple images may be created to support the publishing of different versions of the same application, for example, Office 2010 and Office 2013.  Since they cannot exist on the same server/image, a new image would be needed to publish both Office 2010 and Office 2013 simultaneously.
    • In regards to the previous two bullet points, I’ve assumed an organization has chosen to simply publish applications, but what if XenApp is used to publish desktops and different departments have different applications?  I know you can get crafty and “hide” the Program Files menu as well as the C:, using application publishing the Receiver to place application shortcuts on the desktop and I have seen customers do that to avoid deploying a master image for each unique use case….but I’ve also seen others deploy separate gold images to meet the need to each department.

2. Complexity

  • Though its true PVS makes deploying and managing XenApp easier, it can be complex in its own right
    • If a customer has no previous experience with PVS, I have experienced longer learning curves when deploying and attempting to teach the technology to new administrators.  I say attempting because I realize part of the problem in “getting” PVS may be in my teaching.  Regardless, it can take some time for the “light bulb” to go off and the administrator to feel confident in using the technology.
    • Depending gold image sprawl, you may also see PVS sprawl.  If the number of gold images and/or the number of user connections increase, you’ll likely need more Provisioning Servers to do the work.

Toward the end of last year, upon thinking of an upcoming project and the number of master images I’d need to support the various application mixtures, I had the thought that my life would be much easier if I could use application layering (specifically Unidesk in this case) to deploy my XenApp servers, avoiding PVS altogether.  In fact, I went so far as to open a case with Unidesk asking if this were possible, here’s the actual question I asked Unidesk support:

I got to thinking, “Is there any way I can use Unidesk to build Citrix XenApp servers?  And once I assign the layers to these servers, can I then publish them out like I would a typical XenApp scenario?  Can I replace Provisioning Server with Unidesk?”

Maybe I don’t love PVS as much as the next guy….but I thought, “O, to eliminate PVS!  O, to avoid the complexity of multiple master images! O, to be able to deploy XenApp servers using application layering!”….that may be somewhat of an embellishment, but the thought was a good one.  I firmly believed that if I could deploy XenApp servers with layers, I could eliminate gold image sprawl and the complexity of PVS.

Well unbeknownst to me, Unidesk and VMware, through App Volumes, thought the same thing and now (or very shortly), I will be able to use both Unidesk and VMware App Volumes to deploy XenApp servers using OS and application layering! Because layering separates the OS from the applications, an organization should be able to consolidate their PVS images into a single OS template (big green Lego pad) and then use application layers (Lego blocks) to construct and customize the XenApp server based on its specific purpose or use case.

Granted, layering won’t eliminate server silos; if you need to simultaneously publish Office 2010 and 2013, you’ll still need a group of XenApp servers with an Office 2010 application layer and another group with Office 2013, but layering will eliminate the need for multiple master images to support such a scenario.  Additionally, when using layering technologies to deliver XenApp, complexity is reduced since a PVS infrastructure, and all that it entails, is no longer required.

Think of the voice of the narrator from the old Batman TV show….”Is this the end of PVS?!”  I’ll commit to doing my part but ultimately, you’ll be the one who determines the answer.