The past two years at Citrix Synergy, Rob Zylowski and I have had the opportunity to present on stage and share our top lessons learned from helping our largest customers streamline their image and application management strategies with Citrix App Layering. You can check out recordings of our 2018 and 2019 sessions. This year, we were also joined by Daniel Lazar, the Citrix App Layering product manager, for a sneak peek into future vision for the product.
Synergy also enabled us to talk with a slew of customers at various phases of their App Layering journeys who had a broad array of ideas, requirements, and challenges. As you can imagine, between these interactions and the many customers deploying App Layering we speak to as part of our day jobs, we heard some common themes. So for those of you new to App Layering, I’m going to share with you the top four mistakes I see customers making early on in their Citrix App Layering journeys and some tips on how to avoid them.
1 – Misaligned PoC vs. Production Expectations
What makes Citrix App Layering different from all of the other application layering technologies on the market is that everything is a layer, including the OS itself. This allows us to not only reduce the potential amount of images you need to manage but also to make the images that you do need simpler to manage.
To facilitate this, the Enterprise Layer Manager (ELM) needs to create full images from sets of layers and publish these images to your various platforms and provisioning systems (though we’ve made significant performance optimizations to how we do packaging over the last 18 months). Long story short, packaging and publishing is IOPS- and bandwidth-intensive.
When PoC’ing App Layering, if you’re not using production-grade hardware or taking other shortcuts you wouldn’t in production such as packaging/publishing over the WAN, packaging and publishing are likely to take a good bit longer than they will on your snappy production hardware and with a sound architecture for packaging and publishing in your various data centers and clouds. Make sure that when you’re evaluating App Layering, that you contextualize packaging and publishing times with the hardware platform you’re running the PoC on and the network links you’re traversing versus what you’d actually use in production, which in my experience is often much faster.
2 – Didn’t Keep a Clean Copy of the OS Layer
As you might know, application and platform layers are tied to OS Layers, not OSes. When creating layered images, you can only select application and platform layers that were created using the OS layer (or versions of the OS layer) they were created with. The key implication of this is that in the event that you need to rebuild your OS layer from scratch, you’d also need to rebuild your full stack of corresponding app/plat layers.
You can head this problem off by doing two things from the start:
- Before importing your OS Layer, install Windows from the official ISO from Microsoft, run Windows Update, install the hypervisor tools of the virtualization platform you’re using for packaging, and install and run the OS Machine Tools on the image. That’s all! No updates, no other software, no optimizations. (One that’s bitten a few of my customers is removing Store apps, a recommended optimization if you don’t absolutely need them. But this has proved difficult to add back later when a requirement to use them has arisen.) These can all be done as a new version of the OS layer. This gives you the cleanest possible imported OS layer as a starting point.
- Now that you’ve created this perfectly clean OS Layer, which you can subsequently modify through as many versions as you please, never delete the original imported version. Going back to the constraint described above, this would allow you to “rebuild” your OS layer essentially from scratch, without having to import a new OS layer and all the fun associated with that. As an added bonus, this can be handy to have to help rule out optimizations/updates/other software in the OS layer as variables when troubleshooting an issue with an application layer.
If you’re already far down the path with your App Layering deployment and didn’t do this (or something similar to this), don’t worry. The scenarios that would require a complete OS layer rebuild are uncommon. Just make sure you follow this guidance with any future OS layers you create.
3 – Didn’t Adjust Operational Paradigms to App Layering Way
Managing applications and images with Citrix App Layering is completely different from what you’re used to. The ELM is what’s actually creating your images, and none of the machines you use to add or update applications are domain-joined or even use a consistent name, just to name a few. As a result, I’ve seen a lot of customers spend a lot of time fighting two battles in particular:
- Attempting to ingest an existing “corporate standard” operating system build as the OS layer: For Exhibit 1 against importing a “corporate standard” build as your OS layer, see the previous mistake about the OS layer. I frequently get asked, “Well, what bad things could happen if I include X, Y, and Z apps in my OS layer that you don’t recommend putting into your OS layer?” That’s an impossible question to answer generally. The answer could be “nothing” if you’re lucky, to “a complete rebuild of all layers for that OS” if you’re unlucky. The better approach is to do things the App Layering way: make your OS layer as minimal as possible and do everything else as additional layers. You can achieve the same end result as far as software, security lockdowns, etc. are concerned, but you’re potentially saving yourself a lot of headaches by not trying to retrofit existing processes into the App Layering operational model.
- Trying to leverage existing software deployment tools (SCCM, BigFix, etc.) as a major part of the layer creating and update process: When it comes to software deployment products and Citrix App Layering, there’s a whole litany of material I could discuss on this topic. But in general, the way packaging machines are spun up makes targeting difficult (not domain-joined, name of the machine will vary, IP is set via DHCP). The time that you’d spend taking additional steps to work around this (and troubleshooting steps if you inadvertently put things into a layer that shouldn’t be there) often completely offsets the benefit of having used the deployment tool to install/update the app. My “broad strokes” advice here would be that you get the best bang for your buck when you use the packages you created for the tools, but not the tools themselves, for managing the deployments.
I’m not trying to say it isn’t in the realm of possibility to do either of those things, but in my experience, I haven’t seen success in the long term with trying to retrofit either of those items into the App Layering world. Attempting to do so can add more complexity to your approach than you may have bargained for.
Long story short: if you find yourself mired in discussions about how to integrate Citrix App Layering into legacy processes and you’re concerned that doing so moves you away from our recommended practices or it just doesn’t seem to make sense with the way that App Layering works, your intuition is probably right. Take a step back, look at the big picture, and push to get buy-in for the “App Layering way” of doing things, which doesn’t align with many existing management paradigms that were designed with a different technology stack and set of challenges in mind.
4 – Too Reliant on Elastic Layering in Layering Strategy
Before we get too far into this, let me be clear: Elastic Layering is a critical part of Citrix App Layering technology. The ability to map applications to users is critical when creating a non-persistent workspace solution for a broad set of use cases. I’m not downplaying the importance of Elastic Layering, but I do have some practical advice on how to come up with a layering strategy that best meets your requirements.
If I had a nickel for every time someone’s articulated attaining the “one gold image per OS” panacea … you get the point. Elastic Layering, without a doubt, can help you get you closer to that goal. However, unless you’re using Citrix Virtual Apps and Desktops for a small set of very well-defined user populations, even with Elastic Layering in the picture, this is very difficult to achieve in practicality.
There are two main reasons behind this. First, not all apps will work with Elastic Layering (or any application layering technology that mounts applications at logon). Inevitably, at least one application outside of your core apps is going to need to be included in a layered Image. Second, even if you could deliver every single non-core app elastically, you probably wouldn’t want to. While we’ve made logon performance better with Elastic Layering through features like late load, it’s still another filter driver in the stack and another set of activities that needs to happen at login, which inevitably is going to add time to logins. That’s a trade-off you can’t make with certain use cases.
In sum, don’t start your journey expecting to have one image per OS by using Elastic Layering for every application. It isn’t realistic — for any application layering technology — but that’s OK! As described above, that’s what’s so great about layered images: You don’t incur the same management overhead adding additional images that you would if you weren’t using Citrix App Layering. (I talk a bit more about this here and here.)
Wrapping Things Up (TL;DR)
When starting your App Layering journey, keep these four things in mind to avoid common mistakes:
- Don’t judge packaging and publishing performance on your PoC environment running on old, slow hardware. Your production environment should be better equipped to handle the IOPS and bandwidth needed for speedy packaging and publishing, and you may end up with a multi-ELM architecture to keep most of that activity local to the data center.
- Make an extremely clean OS build for import (no optimizations, no customization, no other apps), and hang onto it forever. This can save you from some substantial rebuild work if you run into issues with your OS layer down the road.
- Citrix App Layering requires very different operational methodology than you may be used to for updating and testing apps and images. Embrace the “App Layering way” and adjust your operational methodology to best fit into the functionality of App Layering rather than trying to fit a square peg into a round hole.
- Elastic Layering is great but has an associated set of design considerations. Make sure your entire strategy doesn’t hinge on being able to elastically layer the majority of your apps, and don’t measure your success exclusively on image-count reduction.
I hope those of you in the early stages of your Citrix App Layering journeys got some value out of this post and can avoid some key early pitfalls (who doesn’t love some free consulting 😉). And as always, if you need any additional guidance or help from the experts, don’t hesitate to reach out to your sales representative about working with Citrix Consulting Services.
Until next time,
Dan Morgan
Enterprise Architect, Citrix Consulting Services
Citrix Tech Bytes – Created by Citrix Experts, made for Citrix Technologists! Learn from passionate Citrix Experts and gain technical insights into the latest Citrix Technologies.
Click here for more Tech Bytes and subscribe.
Want specific Tech Bytes? Let us know! tech-content-feedback@citrix.com.
