Citrix App Layering – With Extra Frosting

I’ve had the pleasure of using Citrix App Layering for the past few weeks.  I have to say it’s pretty addicting.  Immediately after using the product I could see it’s potential. What started out as a POC/Demo turned into a layering frenzy.  First the OS layer, the Platform layer, then an App Layer.  Now we have over 40 App Layers, 4 Platform layers and 2 OS layers, all mixed into 10 different images.  This product is so simple to spin up too.

A few of us on twitter were recently discussing how powerful the product is and some ideas we would like to see implemented in future versions.  I wanted to write this to help let Citrix know we love the product, but want to see more!

For those that want some more information on the basics here are a couple websites to get you going:

• https://www.unidesk.com/support/learn/4.1.0/citrix_app_layering/index_welcome_co4
• https://www.citrix.com/blogs/2017/04/03/now-available-citrix-app-layering/
• http://www.carlstalhood.com/app-layering

During this post I’d like talk about the ‘Frosting’.  These are the extra features and possible opportunities I’d like to see Citrix make to the product in the future.  Before anyone starts getting down on me, just know that I’m an optimist and a full believer in exploring new ideas to make something better.  Like all good managers will tell you, the day your employees stop coming to you with new ideas is the day you need new employees.  Also, you can’t get what you don’t ask for.  So here goes…

Extra Frosting Ideas:

1. Folders – Currently there is no way to categorize any layers.  This is fine if you only have a handful of layers, but if your organization is like mine, you’ll soon have 100+ layers.  You do have the option to ‘search’, but us Citrix Admins like our folders (Appcenter > Studio).
2. Elastic Layers for ALL – Right now the only way you can provide elastic layers is to deploy an ‘App Layering Image’.  For those that want to try your first elastic layer, you‘ll need to deploy 1 OS layer, 1 Platform layer, and 1 Elastic image.  Citrix should be able to make this simpler and let us deploy an ‘agent’ to a standalone VM/physical PC.  This is a pretty big one IMO.  When admins are demo’ing/POC’ing this product they are going to compare it to App-V, AppVolumes, etc…  Right away the product will fail to meet their needs with the ‘virtualizing apps’ way of thinking.  This product does Image Management firstly, and app virtualizing secondly.  Citrix will need to fix the flexibility of Elastic Layers to truly compete with other vendors in this space.
3. Provisioning Time – This is probably the number 1 complaint I hear about.  The whole process takes too long.  The majority of the steam comes from ‘publishing the image’, whether it’s to PVS or a Hypervisor.  If your on XenServer/Hyper-V there aren’t as many conversions since the VM itself is VHD.  However, if you run VMware there are conversions that need to happen to go from VMDK to VHD.   If you want to test a new version, be prepared to wait 30 minutes.  Office isn’t activating?  New version and wait 30 minutes.  Forgot something?  New version and wait 30 minutes.  The more layers you have the larger the Image and the longer you’ll have to wait.  This goes for adding versions too, not just publishing.  When you add a new version it takes a copy of the locally stored OS layer and spins up a new disk on the hypervisor of choice.  This all takes time.  Any way of streamlining or making this faster would greatly benefit us admins.
4. Testing Layers – I think of this one like PVS streaming to server.  We need the ability to test layered versions quickly, without having to wait 30 minutes to publish an image.  Now I don’t need this to be ‘production ready’, I just want something that I can test quickly to verify functionality.
5. Where’s VHDX – the images that App Layering publishes are all VHD, unless you’re provisioning to VMware.  Over the last two years there have been so many enhancements to use VHDX that I feel Citrix needs to get this incorporated.
6. DR/HA – Currently Citrix/Unidesk recommends that you backup your ELM (virtual appliance) and CIFS location like you normally would any other device.  Their viewpoint is that if ELM goes down, you aren’t really down.  Since elastic layers will still be available, you just won’t be able to make any changes, to elastic layers or to any layers.  To me this thinking won’t cut it in the enterprise world.  There are teams dedicated to virtualizing apps and managing images.  A missed day could mean a zero day patch doesn’t get deployed.  There is a ‘layer sync script’ for VMware appliances – https://www.unidesk.com/forum/scripts-and-utilities/unidesk-layersync#comment-42535. However, I’m currently using XenServer.  I would love to see something built into the product to manage my high availability for me.
7. Mix/Match OS layers –  This would give us the ability to use the same layer on multiple OS versions.  While I 100% get why they took away this option, I just would rather they let us choose.  If you want to put a checkbox with a disclaimer that it’s not supported on a per layer basis, fine.
8. Automation/API – Us admins need the ability to script, automate, and control actions.  It would be nice to be able to script updating Chrome in a new layered version.  That’s just the tip of the iceberg, you could pretty much script all individual parts of the published image (windows updates, patches, new DLLs, etc…).  Think MDT on steroids.
9. Notifications/Alerting – I like knowing whats going on and being able to fine tune the alerts.  Maybe i want to be alerted when the layer is done sealing, or maybe i want to be notified when the layer is done publishing.  Maybe it’s an email or a popup in the task bar.  I just want notification options 😉

I just want to reiterate, I’m loving this product so far.  The ease of use and power to manage images is amazing.  I have no doubt Ii’ll continue to use it in the future.  These are just a few things I’d love to see in future versions.

Let me know if you have you’re own ideas to better App Layering.