I answer lots of questions every day about Citrix App Layering, and up to 30 percent of those questions boil down to what layer type should be used for layering “xyz” application. Because applications can be complex, sometimes handling the process of packaging and delivering them to non-persistent desktops and session hosts can be challenging.
This blog post will cover the concepts that govern layering strategy and how to approach creating layers so that customers using Citrix App Layering can see the differences between layer types and how to use those differences to their advantage.
App Layering — Layer Strategy
In Citrix App Layering there are three types of layers:
- OS
- Platform
- Application
The OS layer is created from a hypervisor gold image, then imported into Citrix App Layering as the main building block for desktops or session hosts. The Platform layer is intended primarily to include the drivers and agents required for a specific platform, like Citrix Provisioning on a vSphere Hypervisor or a Machine Creation Services (MCS) image on Citrix Hypervisor. Most of the software in an image will be created within Application layers.
That said, there are definitely rules and best practices to consider when deciding which layer to use for an application. I’ll try to outline most of those here. There are also a set of best practices to guide you on how to make certain Windows optimizations. See my blog post, Optimizing Windows and Citrix App Layering, for more information.
One strong point of Citrix App Layering, compared to other layering technologies, is that it can be used for almost any application because layers can be deployed in the published image. This includes applications with drivers and services that must start at boot time. Therefore, as long as they are applications that can normally be delivered as part of a non-persistent image like those used for Citrix Provisioning or Machine Creation Services, they can be layered.
I used to say if an application has directions for how to deploy with “Ghost,” it would work as a layer. Of course, these days the “Ghost” type of imaging technologies are not used as often as they used to be, but the concept still applies. For an application to work with Citrix App Layering, which is designed for non-persistent images, the application must first work using image deployment technologies like Citrix Provisioning and Machine Creation Services.
OS Layer
The way to think about what should go into the OS Layer is that if it gets updated with Windows Update, it’s a good idea to include it in the OS layer. That way it gets updated with Windows Update when you patch the OS Layer. This would include things like .Net binaries, C++ runtimes, and any Windows Feature or Role. This does not include other apps like Microsoft Office, which should go in its own Application layer.
Keep in mind that the OS Layer is the only layer where you can make modifications to the local Security Account Manager (SAM) database, so you must add a local account or group in the gold image prior to import or in a version of the OS layer. The best way to handle adding domain accounts to local groups is by using Active Directory Group Policy Preference. If you do this, it’s a good idea to force a gpupdate on boot by creating the file c:\windows\setup\scripts\kmsdir\rungpupdate.txt. This tells the kmssetup.cmd boot script to run gpupdate /force.
Platform Layer
The first thing to note with the Platform layer is that there are two types: publishing and packaging. The main one is used for publishing, and its purpose is to install software required for a specific platform to function. This is needed because Citrix App Layering supports multiple hypervisors and provisioning systems simultaneously. The same OS and Application layers can be used across hypervisors, and the Platform layer adds in specific drivers for the defined platform. For example, if I am making an image to deploy on Citrix Provisioning, I will create a Platform layer with both the Citrix Provisioning drivers and the desired VDA. If I am making an image to deploy using Machine Creation Services, I will just need the VDA in that Platform layer.
The packaging Platform layer allows for the inclusion of drivers required when a packaging machine is created. I have had very few reasons over the years to use a packaging Platform layer. One time was when a hospital needed to install scanner software that would only install if it could see the scanner attached to the desktop. To attach a scanner when packaging, the VDA software must be installed to allow a USB connection to the scanner. We used a packaging Platform layer to install the VDA, then added the packaging machine to a catalog to provide HDX access so the scanner could be connected. This also requires adding the desktop to Active Directory; remember, however, at the end it needs to be put back into a workgroup.
I get asked all the time if hypervisor machine tools should be installed into the Platform. It’s a little confusing because the answer is “it depends.” If you are only using one hypervisor, then the hypervisor tools go in the OS layer. This enables you to perform packaging without having to use a packaging Platform layer that includes those tools. Then, for secondary hypervisors that you want to publish to, you would add the tools for the secondary hypervisor in the Platform layer used for the images you would be creating on that hypervisor. Also, based on this, if you have multiple hypervisors, then the hypervisor that you normally package on will be the one that has its tools installed in the OS layer so that you do not need a packaging Platform layer to add those tools every time you create a packaging machine.
Platform layers are also the highest priority layer in a published image. This means that when the image is being built, one layer at a time, the Platform layer comes last and its files and settings take priority over the OS layer (at the bottom) and all Application layers. The priority of Application layers is from the oldest layer to the newest, which means that when compositing the image, Citrix App Layering will apply the oldest layer first, then second oldest, and so on, as it builds the image.
Sometimes you might try an application in the Platform layer to make it a higher priority. Just remember that prioritizing can be changed for Application layers by creating a new layer for an application, to move it higher in the priority list, or by using a utility I wrote (see Layer Priority Utility) to change priority.
All that said, there are some good reasons to install an application in the Platform layer. If the application modifies Windows logon providers, like the VDA does, add it to the Platform layer so that the changes made will work with the VDA and not be overwritten by it. An example of this type of application is Imprivata OneSign. Another type of application to install into the Platform layer is one that modifies the WMI schema. WMI is implemented as a database, which means that if the WMI schema is modified in more than one layer, only the one with the highest priority will work. Because the VDA modifies the WMI schema, that means all applications that do so should be installed into the Platform Layer. Fortunately, there are many applications that use WMI but not many that change the schema. One example of an application that does is Microsoft System Center Configuration Manager. SCCM should be installed in the Platform layer if the agent is used on a VDI desktop. See this article for more details on installing SCCM with App Layering.
Customers often install any application that has drivers into the Platform layer. That is not required at all. Citrix App Layering expects that applications that have drivers will be installed into Application layers unless its known that they won’t work that way. Citrix App Layering can merge drivers from different layers in a published image. This includes antivirus software, most of which can be installed in an Application layer. The exceptions are usually products that create a local account when they install.
Always try to install antivirus software in an Application layer first, after checking the App Layering Antivirus Guide to see if your software is included in the antivirus Citrix tests with each release. This guide is there to help customers with the most-requested antivirus recipes. We expect that all antivirus software will work, but if you are having issues layering yours, please open a support case.
Finally, always recreate a Platform layer if you are making a major change to it, like when you upgrade the Citrix Provisioning Tools version or VDA version. In those cases, we are just uninstalling the Citrix components and installing a new version anyway so it’s a lot cleaner to just rebuild. If you have issues with new published images after upgrading the Citrix App Layering appliance, try recreating the Platform Layer. I have seen this fix the issues quite often.
And make sure you review this article before creating a Platform layer.
Application Layers
I covered what to put in OS layers and Platform layers first because those are really the exceptions. Most applications should be added using Application layers, and you should always try an Application layer first for any new application you are layering.
When I am starting with a new application, I always first search “Citrix App Layering ‘Application xyz’” to see if there are any surprises associated with an app. I also want to figure out if the app works in a non-persistent environment, so I will look for things like “Support for Citrix Provisioning,” “MCS,” or even something like “Ghost,” as I discussed earlier.
Application layering is very flexible. You can create a layer for a single application or many applications. You should base your strategy of whether to combine or layer separately on whether the applications layered together will all be used on the same images, if they will be updated by the same resources, and if they are likely to have major updates in the same time frames. If those things are not true, it might be better to separate the applications into different layers.
One important thing to keep in mind with Application layers that will be used elastically is that there will be a separate persistent connection to the file server for each one. For elastic layers at least, it makes sense to combine applications, if possible, to conserve on the number of connections. This is more important for a VDI deployment than for published apps or hosted shared desktops, due to the scale involved.
Lastly, remember that Windows apps can be very integrated into the registry (or not at all). When you are creating a layer, your installer is not really seeing the entire registry, and it might edit or add keys and values that have also been edited or added in other application layers. You will not find out about collisions between files and registry keys until publishing the layers together and testing the applications. If an application does not work as expected, first try publishing it to an image with no other Application layers. This will tell you if there are conflicts with other layers. Then you can try to figure out where those conflicts are or what layers they are in.
Closing Thoughts
Just like any other technology used to deploy applications to many desktops / servers, there is quite a lot to learn when using Citrix App Layering. In most cases applications just work without any difficult installation steps but some applications take a little more knowledge and skill to deal with. With our documentation and blog posts like this, Citrix customers should find it easier to handle those tougher applications and enjoy all the power that Citrix App Layering provides.
