As my colleague, Dan Morgan, announced a few weeks ago, Citrix Consulting hosted a webinar on Citrix App Layering on July 19 that included a live Q&A portion with experts Rob Zylowski and Spencer Sun from Unidesk to help address your questions. We recorded the webinar for those who missed it, and the on-demand version is available here.
We got more questions than we could handle during the live Q&A, so as promised, here are answers to many of them:
Q: What the licensing entitlement for App Layering? If I have Platinum, can I call in for support? What is the dependency on Citrix Cloud? Is elastic layering only available from the cloud? Can App Layering be used in on-premises environments where no cloud or Internet connection is allowed, such as for security reasons?
All Editions of XenDesktop include Citrix App Layering. If you are licensed for XenDesktop Platinum Edition, you may also use the User Layers and Advanced Configuration features of Citrix App Layering. User Layers is currently a beta feature that enables writable layers for personalization. Advanced Configuration is for deploying layers to multiple hypervisor types, clouds, provisioning mechanisms, or broker types. The XenApp and XenDesktop Feature Matrix has been updated to include this information.
It is currently possible to deploy App Layering without Citrix Cloud (fully on premises). Elastic layers are a built-in feature of the Enterprise Layer Manager (ELM), so they can be used in an on-prem or a cloud-based solution. Elastic layers will be located on a CIFS or SMB share, so this needs to be available to your VMs. Eventually, we will move the control plane permanently to the cloud, where it is easier to keep up to date and patched, but there will always be an on-prem appliance to hold the layers.
Q: What does App Layering mean for the future of AppDisks? Personal vDisk? Provisioning Services/Machine Creation Services?
Citrix has added a “Deprecation” section to the XenApp and XenDesktop eDocs pages under “What’s New” to provide previews of features targeted for deprecation in future releases. Within this section, you will see the following statement regarding AppDisk and Personal vDisk support:
Citrix is replacing the AppDisk and Personal vDisk functionality provided by XenApp and XenDesktop with recently acquired technology from Unidesk. During this transition time, Citrix continues to maintain current support levels as described in XenApp and XenDesktop Servicing Options.
As for Provisioning Services/Machine Creation Services, App Layering relies on provisioning technologies to spin up machines based on the layered images created, so we view these technologies as complementary and inter-operational. Specifically regarding Provisioning Services, with App Layering, we publish a vDisk. It is a full image every time. The default name for the vDisk is the image name plus a date-time stamp for versioning. We provide the ability to run scripts when an image is published, and we provide a script that will allow you to make the published image a version in Provisioning Services. This allows you to use promote and demote functionality, but it is not really using Provisioning Services versioning with incremental VHDX technology.
Q: What hypervisors are supported? Where do I find documentation? Is there cross-compatibility between App Layering versions?
Documentation for App Layering is being ported over to Citrix eDocs and is also being maintained on Unidesk’s website (with a greater historical record) here. System requirements, for example, are available here for platform support questions.
Keep in mind that, although the Unidesk products were named 2.x, 3.x and 4.x, they are not updates of the same product but entirely different products. Therefore, layers are not compatible between 2.x, 3.x or 4.x.
Q: Are physical devices supported? Can application layers be “streamed” / delivered to physical endpoints?
Not at this time. App Layering requires a provisioning system to deploy images and manage updates, and leverages a connector to create OS layers. It also expects a non-persistent solution so that updates can be deployed easily. Most physical system management solutions cannot handle this requirement.
Q: On a semi-related note, can I deliver just an application layer without an OS/platform layer?
With layering, you are not installing an application on every machine. You only install the application when you are packaging. Windows operating systems create some of their internals dynamically. These can include GUIDs, short folder names and short file names. Some applications will then install settings using these internals. If we allowed you to use an application layer on an OS that was not the same as the OS the layer was created on, these internals might not match, breaking the application. And the breaking might not be obvious or found in testing. This is why we enforce the limits that we do. Unidesk learned over seven years ago that this was not a good practice. The other vendors that allow it have no special secret sauce – they have just decided it is OK for applications to fail.
Q: What monitoring and/or automation capabilities are available?
There is currently no monitoring, reporting or API-based automation included. We have a task and queue model for our appliance that keeps the console updated with progress, but nothing more at this time. This capability has been requested by multiple customers, so it is being considered for future releases as the product becomes more integrated with the rest of the Citrix product suite.
Q: How does this integrate with SCCM for patch management?
SCCM is very difficult to integrate directly with App Layering at this time. Packaging machines are not domain joined and are created dynamically every time. For now, the best method is to use the same source MSI that SCCM would use in a new version of the application layer, or just use Windows Update in App Layering.
Q: What dependencies are there between layers? Is there a hierarchical view? Can layers be shared between operating systems?
Layers depend on each other outside of the OS layer or if prerequisites are defined by an administrator. Layers cannot be shared between OS layers. When we make a prerequisite, it is only to create the packaging machine. That information is not stored anywhere for later use. During the merging of the layers to create the image file, there is a conflict resolution process that specifies which layer’s contents will have priority. The OS layer will always have the lowest priority and the platform layer will have the highest. Application layers will be between, with the oldest having the lowest priority by default. It is possible to change the default priority using a utility, but it is by layer, not file.
Q: Can multiple platform layers be deployed? For example, one platform layer for Provisioning Services target device software and one for Citrix Receiver?
The ELM will only allow a single platform layer for an image template. This is because we use the platform type parameters to intelligently merge the layers together.
Q: How well do elastic layers scale? Is there a maximum number supported?
Elastic layers are VHD files mounted by Windows. Windows allows 1024 VHD mounts on a single machine, but we limit published images to 200 layers. Elastic layering will always have a performance impact. When you use elastic layers, they are mounted on logon, which is one performance hit, though not that big. On a XenApp system, the hit is only for the first user on a server that must make the server mount the layer. However, elastic layers also use a virtualized registry and file system. This adds latency to the app. The more registry entries an application adds, the higher the latency. If a file in a layer must be modified, then that file must be copied to the writable portion of the desktop/session host so it can be modified. All of this has a small performance penalty. You must decide if the flexibility that elastic layers provides is worth the performance overhead.
Q: How do you publish an elastic layer from Studio?
Currently, elastic layers work only on published desktops based on Active Directory group membership. You can, however, publish the executable to an elastic application by manually specifying the path to the executable. As the layer will be mounted before the logon process is completed, XenDesktop will be able to launch the application for the user. Tip: If you do this, use the same Active Directory group you used to assign the application elastically to publish the application. This will ensure that the user will have access to the application.
Q: Can layers be shared between images / VDI farms / different sites? Is there an export/import function?
Layers can be shared across composite images (so long as the underlying OS is consistent). As of App Layering 4.3, it is possible to export all your layers from one ELM appliance to a Windows share, and then import them to another appliance. This process could be used to keep two appliances in separate physical sites in sync.
Elastic layers are attached to the OS layer they were created on. A new version of an OS layer is still the same OS layer, so it will still work with the existing application layers. The reason is that Windows uses dynamic creation of some GUIDs, short folder names, short file names, etc. Applications remember those, so we need to keep them consistent. Updating OS layers by creating a new version of the layer (as opposed to importing a new OS image) is therefore recommended.
Q: How do you handle applications that are licensed based on MAC address or IP address or other machine-specific property?
This sounds less like an App Layering issue and more like a provisioning (Provisioning Services or Machine Creation Services) issue. Cloning machines that may include machine-specific data (MAC-based licensing, registration GUIDs, etc) comes down to the options within the software: regenerate this license on boot, perform some kind of generalization within the image or leverage DHCP reservations for IP-based functions.
Q: Are all application settings captured as part of the packaging process (including command line parameters)?
When you are packaging an application for App Layering on a packaging machine, the App Layering software captures all writes to the storage and any registry changes from when the packaging machine is first booted. When the installation occurs, it is also captured. However, any changes made to a user profile are captured in the local administrator profile; they are never played back on a desktop or session host. Therefore, any changes for the end user must be made via logon script or GPO.
Q: How do I package an application that is installed on the D drive or has dependency on the D drive?
Unfortunately, App Layering only supports applications installed to the system drive. Alternate drives are not supported.
Q: How do applications communicate across layers? For example, how does Adobe Reader integrate with Office as an Office plugin?
You can create prerequisite layers for applications that depend on each other. For example, when you create the Adobe layer, use Office as a prerequisite layer so that Adobe sees that Office is installed and can create the appropriate plugins. This assumes that Office is already packaged as a separate application layer. Alternatively, Adobe and Office can be included in the same layer.
Q: How do you handle applications that have different Java dependencies or DLL conflicts? Can applications that do not normally work on XenApp be made to work via App Layering? What if applications are incompatible with each other?
App Layering is not an application isolation solution and therefore will not solve inter-application compatibility issues or OS compatibility issues. Application streaming products such as App-V may be able to assist in some of these cases.
Q: Last but not least, roadmap: when will user layers move out of labs? Will there be any AppDNA integration? Is there a timeline for user layers with XenApp? Will Hyper-V Gen2 VM support be in the next release?
Unfortunately, we cannot comment on roadmap items here 😊
Stay tuned and thanks very much to all those who attended – especially everyone who stayed on for the Q&A. We hope you find this information useful on your App Layering journey. Comment below if you have other questions we can help answer…
