Delivering Droplet Computing containers with Citrix Virtual Apps (formerly XenApp)

Michelle Laverick – Chief Technologist

It’s been a long, long while since I looked at anything Citrix based. It feels really odd saying that because, before VMware came along, I was a Citrix Certified Instructor (CCI) and a Citrix Certified Enterprise Admin (CCEA). I first got into Citrix on the tail end of NT4 Terminal Services Edition (available from Q4 1999 to the end of 2003) and MetaFrame 1.8 (1998 to 2001 when it because MetaFrame XP) and stuck with it until around the Presentation Server 4.5 days (launched in 2007). At the time I wanted to keep both Citrix and VMware on my resume, but once agencies and other sources of my freelance work knew I was VMware certified, it seemed like no one wanted to punt me out for Citrix-based courses. The market kind of dictated my career direction to some extent. So, it was nice to hit this week and download the binaries to check out what they now call “Citrix Virtual Apps and Virtual Desktops”, or the products formally known as “XenApp and XenDesktop”.

As I was stepping away from all things Citrix in 2004/5 administration was still very much carried out by Java-based apps, web-admin tools, and a smattering of Microsoft Management Consoles (MMC). It seems like everything is MMC based from a configuration perspective. Initially, I started off with a Microsoft RDS build with Droplet Computing as the application being served up, and that worked just fine.

Droplet Container App delivered using Microsoft RDS/RemoteApp

The container app launched as expected and the apps installed in my image file were readily available. In this instance I used the DCI-X container to deliver legacy Microsoft Office apps.

Droplet Container App running as a published app in RDS

Note: It’s interesting to see, after being away from server-based computing environments for more than a decade, that Microsoft RDS now delivers seamless windows as Citrix did back in the MetaFrame 1.8 days!

The setup of Citrix Virtual Apps and Virtual Desktops is a relatively simple affair and used Windows 2016 as the base OS instead of Windows 10 that is what we would normally run our software on within in PC environments. I built a very simple “Controller” which hosted all the key roles and then a separate Windows 2016 image that would serve up the applications and form the bedrock to my Citrix Server Farm. That’s old-timer speak for what Citrix now calls “Machine Catalogs” – collections of Virtual Apps Servers or Virtual Desktops that end users are allocated to.

Configuring Citrix Machine Catalogs

Installing the Droplet Container App on is no different to any other installation. But the main focus was on how to manage the all-important Droplet Container Image (DCI). We have two different types of container; DCI-X and DCI-M. The DCI-X image is designed to maximize compatibility with legacy applications and has a relatively modest payload. The default settings allocate 1 CPU and 2GB of RAM that is, in most cases, more than enough. In fact, some customers have been able to get away with just 1GB memory – so much depends on how memory hungry those legacy applications are. The DCI-M image is designed for modern applications and has a slightly larger payload – and generally, I run that on my Apple Mac with an allocation of 2 CPU and 4GB RAM.

Following my recent work and research with Amazon WorkSpaces and AppStream, I’ve developed a set of best practices and recommendations that are in the process of being ratified by the Office of the CTO. My thinking is this; when we install Droplet containers to physical environments, customers should really try the DCI-M image first. It offers blistering performance once our hardware acceleration is enabled, and is a modern collection of kernel, exe, DLLs, and application libraries and frameworks. Only if the target application won’t install to our DCI-M (because the legacy app is ancient), would you consider the DCI-X image.

In contrast, the recommendation for virtualized environments such as Citrix Virtual Apps/Desktops, AWS WorkSpaces, and AppStream – and at some stage, VMware Horizon View and Microsoft Windows Virtual Desktop (WVD) – will be to use the DCI-X image type. That’s because while local host memory and CPU resources are plentiful, we still need to optimize and efficiently use data center or public cloud resources. With the DCI-X image having a much smaller CPU, memory, and disk footprint it makes sense to use it.

Another consideration is that our hardware acceleration leverages Intel VT instructions, and in public cloud instances, those attributes aren’t usually exposed anyway. I can see – over time as resources become more plentiful and customers begin to see containers as their primary and preferred way of delivering applications – this could very easily change. For now, as an organization, it is important for us to walk before we try to run.

The other consideration is where to store the Droplet Container Image (DCI) file. This is important to understand the DCI files relationship to the end user. The DCI is a per-user file, meaning that every user gets their own personal DCI file. In the context of local host devices, like my physical Apple Mac, I just store these files on my local SDD drive. In the context of technologies like Citrix Virtual Apps, it’s important to understand that the DCI image file is not a “shared” file that is used simultaneously by a group of users. In this case the DCI becomes your “master” image, in a similar way you would build a desktop image for VDI. That DCI image file, once built, creates from the base-DCI ready for distribution, allowing it to be copied a gazillion times in a way that again resembles that virtual machine template. In my case, I merely ensured each user had a home directory on my NAS and ensured the Droplet Container Application knew the path to that location when the container was started.

In my initial tests, I just copied the file manually and, later on, I just wrote a very simple script that would automate the process for the first time a user uses our software. It’s an embarrassingly simple DOS-based command/batch file that checks for the existence of the DCI.droplet file and, if it’s not present, copies it into the home directory.

The other thing this script does is copy down a base apps.json, settings.json, droplet.lic and eula_accept files. These core files which are just a couple of KB in size reside in the user’s profile location:


As we are more or less completely platform agnostic every Droplet Container App is just a file, and a simple file copy is all that’s needed to set up the user environment, usually grabbed from a tested and running version in the IT Lab.

Anyway, once these pieces were in place, it was a relatively simple process to allocate the Delivery Groups.

Configuring Citrix Delivery Groups

And then, bingo! My Citrix Virtual Apps user could access the legacy applications from the Droplet Computing container. All I needed to do was crank up a web-browser to the Citrix Control Center and log on to the Citrix StoreFront (what old-timers like me would have called Citrix nFuse or the Citrix Web Interface).

Droplet Container App Delivered by Citrix StoreFront

Note: To make screen capturing easier I’ve positioned the Droplet Computing App together with the web pages of the Citrix StoreFront. The two windows are independent of each other, and the Droplet Container App is present as a stand-alone seamless window. In fact, it looks no different from the Droplet Container App running locally.

Droplet Container App running Excel 2003 Delivered by Citrix StoreFront

So, what next? Well, I’m forging ahead demonstrating that Droplet Computing containers will run in practically every application delivery solution you care to think of. Droplet Computing containers EVERYWHERE is my motto. I’ve already written whitepapers for Droplet Computing as delivered by Amazon WorkSpaces and AppStream, so the next logical step will be to do that for Citrix Virtual Apps and Desktops and keep on working through these systems, gathering experience and insights that we can share with customers and the wider industry. I seem to bounce from a week or two geeking off in my lab, to then writing up those experiences and feeding it back into blogs, whitepapers, our partner community, and enablement materials. I’m thinking the next thing I’d like to do is a collection “Getting Started” videos because some people prefer video-information to documents.

It’s exciting times at Droplet Computing. We are pushing the boundaries of what our tech is capable of, and increasingly engaging with potential new customers and being exposed to real-world scenarios. As ever, it’s when the rubber hits the road where you really learn the most. There’s nothing like being down there at the coalface and in the weeds… I just wrote that to see how many mixed metaphors I could put into one sentence!