Category Archives: Unidesk

What’s the Next Step to Achieving VDI Utopia?

One Master VDI Image

If you’ve been deploying VDI technologies for some time, you’re probably familiar with the VDI Utopian goal of “one master image” and with the technologies available today, is this goal achievable?

Now, going back to the IT stone ages of 2009, when I first started deploying VDI technologies (referring to VMware View and Citrix XenDesktop….I’m not counting XenApp for the purposes of this article), my first two projects, which you can read more about here, were pretty eye opening.

  • Citrix, to their credit, could kinda-sorta provide a single master image with XenDesktop assuming all applications could be published from XenApp servers.  However, this required a Provisioning Server infrastructure that some administrators couldn’t quite understand or get a handle on AND it could require many XenApp servers and multiple XenApp server silos depending upon the required applications.  Though I did get a single master image on the desktop side, I did have to manage multiple XenApp server-based images to support application publishing.  As I wrote in the post referenced above, to support 300 Windows XP desktops and their required applications, 50+ Citrix servers were required.  So, does this really count in achieving the goal of one master image?
  • VMware, at this time as best I can can recall, didn’t make any, “Use VMware View and you’ll only need one master image!” promises.  Again, if I can recall 2009 correctly, VMware did claim that VMware View was “simpler” than XenDesktop in terms of deployment and configuration.  I found the claim to be true in that I only needed a single connection server to support 125 virtual desktops.  However, to support the 125 virtual desktops and their different functions within the organization, I needed 11 master images.

Simplified, my primary observations upon completing these project was this:

  • Generally speaking…Citrix XenDesktop requires fewer desktop images (if not 1) but requires more server-based infrastructure to support OS streaming and published applications.  Compared with XenDesktop, VMware View requires significantly less server-based infrastructure, but requires more desktop images based on the application and configuration requirements of the organization.
  • There’s got to be some better solution….there must be some way to cut down on the number of both master images and server-based machines to provide a good, dynamic, and scalable VDI solution.

Enter application layering….

In 2011, I deployed Unidesk and it quickly became a “mandatory” component on all of our VDI projects.  With Unidesk we were able to minimize both the number gold images and the number of server-based resources required to support VDI initiatives…the Unidesk solution gave us the best of both worlds.  The only time multiple gold images are required is if a customer wants to support multiple OS’s such as Windows 7, Windows 8.1, Windows 10, etc.  But gone are the days when I need 11 Windows 7 gold images to account for distinct use cases and gone are the days when I need 50+ back-end servers to support standard enterprise applications.

Recently, we have been able to achieve the same goal using VMware App Volumes so the “single master image VDI environment that minimizes server-based requirements that also provides a dynamic and scalable infrastructure that’s relatively easy to manage” dream has become a reality.

What’s next VDI dream?

What’s the new dream in the realm of VDI Utopia?

Deploying only Non-Persistent Virtual Desktops

Maybe it’s deploying only non-persistent virtual desktops, an idea, a concept, and a question many organizations are looking into.  Why?

  • It’s easier….something happens to a desktop, you reboot it and it is reset back to its “clean” state
  • There is a belief (and I say this because I haven’t studied this first-hand) that the more non-persistent desktops you deploy, the fewer virtual desktops you’ll ultimately need.  If you can reduce the number of deployed virtual desktops, you reduce the number of servers required to host virtual desktops, you reduce the amount of storage that’s required to host virtual desktops….in short, you can reduce the cost of the VDI infrastructure.

This dream may soon become a reality as there are now tools out there, from VMware and Liquidware Labs as examples, that allow an organization to provide, if this makes sense, persistence in a non-persistent VDI environment.

A Single Non-Persistent Virtual Desktop Pool for the Entire Organization??

Or maybe it’s deploying non-persistent desktops from a single desktop pool….and I bring this up based on the VMware EUC video Delivering Secure Role-Based Desktops with VMware NSX and App Volumes

It seems VMware has a dream to break away from the traditional VDI pool-based approach and instead focus on a user-based approach, utilizing App Volumes and NSX, in order to reduce OPEX and complexity.  Basically, App Volumes would be used to dynamically deliver applications specific and NSX would be used to configure unique security policies based on the user’s role….the virtual machine itself becomes more or less irrelevant.

Conceptually it sounds great and I’m sure App Volumes and NSX will play important parts in VDI infrastructure for years to come, but in my experience, many users have multiple roles and some machines have unique purposes which may limit the effectiveness of a single desktop pool….hospitals and education are two organizational segments that come to mind.  For example, a single nurse may work within the ICU, ER, Labor and Delivery, OR, etc. but the machines themselves in those departments are typically specialized in order to perform that department’s unique function within the hospital, thus a single desktop pool may not be the answer.

When you get a chance, watch the video (it’s about 15 minutes).  Regardless of whether or not a single pool can support your environment, it is certainly interesting to think about and consider the trends and technologies that are driving the VDI landscape and I look forward to continued innovations as we march toward VDI Utopia.

Leave a comment

Filed under Liquidware Labs, Unidesk, VDI, VMware

The Death of Citrix Provisioning Server?

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.

Leave a comment

Filed under Citrix, Unidesk, VDI, VMware

My VDI Story….why I like VMware View and Unidesk

Years ago, when I was hired by my current employer in 2007….I was brought on as a Microsoft and Citrix delivery engineer focusing primarily on AD/Exchange and Citrix Presentation Server/XenApp technologies and projects.  While I’m here, let me also say this, one of the best days of my professional career was the final day of my last Exchange 2003 to 2007 migration.  Fortunately, I had been and was being trained on EMC and VMware products and began to focus more and more on those types of projects….and so on that final day, I purged everything I ever knew about Exchange and it was glorious.

OK, back to VDI….though I was able to move away from Exchange, I was still the “Citrix guy” which was fine as I enjoyed working with Citrix who had been doing “VDI” long before it was cool with MetaFrame, then Presentation Server, and then XenApp.  Prior to late 2009/early 2010, XenApp was our primary desktop/application virtualization platform and then Citrix XenDesktop 4.0 came out and more customers began talking about deploying virtual desktops to their end-users.

To that end, I built a portable lab and even took it across North Carolina to show it off in an attempt to feed the masses; to fuel their thirst and desire for virtual desktops.  And it worked!  Our first project (in which I worked with Citrix) was for approximately 300 Windows XP virtual desktops running XenDesktop 4.0, with applications published from whatever version of XenApp was out at the time (5 maybe) and hosted on XenServer infrastructure.

If you’re familiar with VDI technologies, how many times have you heard about the utopia goal of “one master image”? That’s what everyone shoots for and I can say with this project, because the applications were published from XenApp servers, we were able to achieve that goal, however (and I don’t want to say this necessarily as a negative), to conform to Citrix best practices, all machine “roles” were separated out so we had to the best of my recollection:

  • Citrix License Server
  • Citrix Web Interface Servers
  • Secure Gateway Servers
  • EdgeSight Servers
  • SQL Servers
  • Provisioning Servers
  • XenApp Servers

Maybe there were even dedicated Data Collectors…really it was a long time ago but I do remember seeing an environment diagram when all was said and done, 53 Servers/VMs were deployed to support the 300 Windows XP virtual desktops.

Our next XenDesktop project wasn’t nearly as big or complicated, just needed to deploy Windows XP VMs to a few computer labs, publishing applications from existing XenApp servers….and I thought that it went great until I checked back with the customer a few months later to find they weren’t using the XenDesktop environment at all.  Why?  Provisioning Server….they had a hard time wrapping their mind around how to use it, how to update images, etc.  I explained how it worked while I was onsite but I have found that there are times that, after I complete a project and leave, my customers are pulled in so many directions, put out so many fires, there is the potential for new technologies to sit unused and forgotten as IT staff focus on the “tyranny of the urgent”.  Despite my best efforts, I could not explain PVS in such a way as to make it easily understandable and XenDesktop ended up sitting there until we upgraded to version 5 and switched to MCS.

And so, you think to yourself….is there a better way to do VDI?

Then in late 2010, a customer requested a VMware View POC for 125 VMs.  Being the “Citrix guy”, I was selected as the best candidate to become the “VMware View guy”; perhaps some of you have had similar experiences.  Honestly, I was leery about VMware jumping into the VDI realm because I loved Citrix so much….surely this PCoIP cannot compare to ICA!  Surely VMware’s product is not nearly as mature as Citrix Xen!  But I went into the project trying to keep an open mind and did see almost immediately that I would not need 53 servers to support the environment.  I think we built 1 VDI vCenter server, 1 connection broker, and 2 ESX servers.  The problem however, was application delivery….this environment was unique in that no Citrix farm existed so we had 2 choices, install the applications onto the master image and/or using ThinApp.  We tried ThinApp, but it was “slow” to the end-users so we began to install the applications onto the golden image.  Once this process started, it became apparent that one master image would not be possible because of the mixture of applications needed for each department, but not just the mixture, but one application in particular required different configuration settings based on the department.

Though I didn’t need 53 servers, we did end up 11 gold images to support 125 virtual desktops….as you might imagine, this lead to a great deal of frustration and I wondered again, is there a better way to do VDI?  Is VDI worth doing at all at this time?

In late 2011, a coworker, after doing some research around VDI technologies, brought Unidesk to our attention.  He had seen their demo, had spoken to a sales engineer, and was very excited exclaiming that Unidesk could solve every VDI problem we had encountered with its layering technology; with Unidesk layers, we could achieve a single golden image yet build diverse virtual desktops for any purpose.  It really is a remarkable technology….I think of the layers as highly customizable blocks (kinda like Legos) which allow me to build any desktop my client may need without having to install any applications into the golden image.

Our first Unidesk installation was for the client mentioned above with 11 gold images for 125 virtual desktops in an effort to alleviate their pain points and we found, that we could deploy 125 virtual desktops with a single golden image (just the OS) while using the layers to customize the application settings and roll them out to the proper department quickly and easily. Unidesk saved the day by easing (significantly) the administrative burden of managing the virtual desktop environment….if Unidesk had not delivered on its claims, the customer was ready to go back to physical desktops and likely turned their backs on VDI for good.

Since that project we have, in effect, made Unidesk mandatory for all of our VMware View based projects and I can assure you, it has made my life easier and it has made the lives of dozens of IT administrators easier as well.  To date, I have not met an application (or anything really) I’ve not been able to layer in Unidesk….Unidesk really allows one to think outside the box when creating layers, it doesn’t necessarily have to contain an application….I’ve built a “mandatory profile” layer, a layer to put specific shortcuts on the desktop, layers for non-standard print drivers that are mapped through GPOs, you name it, you can probably create a layer out of it and apply it to your virtual desktops.

Layering is “so in” these days!  VMware, of course, has released their App Volumes which is similar in concept to Unidesk though their are some differences in the two.  If you are considering virtual desktops and even Citrix XenApp, I strongly advise you to research and check out these layering solutions, you will be glad you did.

In closing, here are some other random VDI thoughts:

  • Seems like App Volumes (or maybe even VDI in general) is pushing more towards non-persistent desktops.  Could this make a profile management tool such as Liquidware Labs Profile Unity more important?  Should Profile Unity be mandatory on VDI projects?
  • Hyper-V?
    • Folks have begun asking about using Hyper-V with Unidesk as opposed to vSphere in order to save $$, but does it really save $$?  And can I overcome my personal hypervisor bias?  🙂
  • VMware App Volumes
    • How does in work in production as opposed to Unidesk?
    • Can I use App Volumes on Citrix XenApp projects to replace Provisioning Server?
  • Integrating Mobility Management technologies
    • People connect to virtual desktops from so many devices….will VDI drive a demand for mobility management solutions like VMware AirWatch or Citrix XenMobile?

Leave a comment

Filed under Unidesk, VDI, VMware, Windows Desktops

VMware View and Unidesk – VMs “stick” at STARTUP after DST

Ran across an issue recently when using VMware View and Unidesk to build VDI VMs. The project started in February and we built our gold image, created an OS Layer in Unidesk, and rolled out a few desktop pools with no issues, but in the last month, we started to notice most VMs would “stick” with a Status of STARTUP in VMware View administrator thus they were unavailable to end users.

The problem could be resolved in one of two ways:
1. Wait an hour and eventually the Status would change to Available
2. Reboot the VM via the Unidesk Management Console and more often than not, the VM would “wake up” and become available after a second reboot.

We tried seemingly everything to resolve the issue…we then opened a case with VMware who initially believed it was the Java Memory Heap or something. While collecting logs for the VMware case, I saw that several people were having a similar problem ever since Daylight Savings Time (DST) went into effect. On the surface, the ESX server, the VMs, and the domain controllers were all in sync but still the connection server showed messages being received from the View agents at different times from the time of transmission, almost a one hour difference.

To resolve the issue in a standard View environment, the basic high-level process is as follows:

1. Boot the Master Image
2. Patch Master (if required)
3. Release IP and Set correct time to it.
4. Shutdown
5. New Snapshot
6. Recompose

But I’m using Unidesk to push out my virtual desktops so the process is still easy, but a little different:

1. Add a version to the existing OS Layer
2. Login to the installation machine and set the time zone to something other than your own and reboot. For example, I am in the Eastern time zone so I set my installation machine to the Central time zone and rebooted.
3. Login again and change the time zone to the correct time zone. Again, I’m in the Eastern time zone so I changed my VM from Central to Eastern.
4. Personally, before I finalize any Unidesk layer I reboot so I rebooted my installation machine once more.
5. After the reboot, open the Unidesk Management Console and finalize the new OS Layer.
6. Deploy the new OS layer to an initial batch of pilot/test VMs and verify that the Status reads Available after the VMs reboot to deploy the new OS layer.

For us, this simple fix corrected our STARTUP status problem…I wonder if I’ll have to do the same thing in November?

Leave a comment

Filed under Unidesk, VDI, VMware