Sep. 13, 2016
Managing applications and managing the images they are installed on can be a challenge. The Citrix AppDisks feature is a solution. AppDisks separate applications and groups of applications from the operating system, enabling you to manage them independently.
You can create different AppDisks containing applications designed for individual user groups, and then assemble the AppDisks on a master image of your choice. Grouping and managing applications this way gives you finer control of applications, and reduces the number of master images you maintain. This simplifies IT administration and enables you to be more responsive to user needs. You deliver the applications in AppDisks through Delivery Groups.
If your deployment also includes Citrix AppDNA, you can integrate the AppDisks feature with it; AppDNA allows XenApp and XenDesktop to perform automatic analysis of applications on a per-AppDisk basis. Using AppDNA helps make the most of the AppDisks feature. Without it, application compatibility is not tested or reported.
AppDisks differ from other application-provisioning technologies in two ways: isolation and change management.
Good to know:
The following list summarizes the steps to deploy AppDisks. Details are provided later in this article.
Using AppDisks has requirements in addition to those listed in the System requirements article.
The AppDisks feature is supported only in deployments containing (at minimum) versions of the Delivery Controller and Studio provided in the XenApp and XenDesktop 7.8 download, including the prerequisites that the installer automatically deploys (such as .NET 4.5.2).
AppDisks can be created on the same Windows OS versions that are supported for VDAs. The machines selected for Delivery Groups that will use AppDisks must have at least VDA version 7.8 installed.
Citrix recommends that you install or upgrade all machines with the most recent VDA version (and then upgrade Machine Catalogs and Delivery Groups, if needed). When creating a Delivery Group, if you select machines that have different VDA versions installed, the Delivery Group will be compatible with the earliest VDA version. (This is called the group's functional level.) For more information about functional level, see the Create Delivery Groups article.
To provision VMs that will be used to create AppDisks, you can use:
AppDisks cannot be used with other host hypervisors and cloud service types supported for XenApp and XenDesktop.
Creating AppDisks is not supported with machines in MCS catalogs that use caching of temporary data.
Remote PC Access catalogs do not support AppDisks.
The Windows Volume Shadow Service must be enabled on the VM where you are creating an AppDisk. This service is enabled by default.
Delivery Groups used with AppDisks can contain machines from pooled random Machine Catalogs containing server OS or desktop OS machines. You cannot use AppDisks with machines from other catalog types, such as pooled static or dedicated (assigned).
Machines on which Studio is installed must have .NET Framework 3.5 installed (in addition to any other installed .NET versions).
AppDisks can affect storage. For details, see Storage and performance considerations.
If you use AppDNA:
Separating applications and the OS using two disks, and storing those disks in different areas can affect your storage strategy. The following graphic illustrates the MCS and PVS storage architectures. "WC" indicates the write cache, and "Thin" indicates the thin disk used to store differences between a VM's AppDisk and OS virtual disks.
In MCS environments:
You can continue to balance the size of the AppDisks and OS virtual disks (vDisks) using your organization's existing sizing guidelines. If AppDisks are shared between multiple Delivery Groups, the overall storage capacity can be reduced.
OS vDisks and AppDisks are located in the same storage areas, so plan your storage capacity requirements carefully to avoid any negative effect on capacity when you deploy AppDisks. AppDisks incur overhead, so be sure your storage accommodates that overhead and the applications.
There is no net effect on IOPS because the OS vDisks and AppDisks are located in the same storage area. There are no write cache considerations when using MCS.
In PVS environments:
You must allow for the increased capacity and IOPS as applications move from AppDisk storage to the hypervisor-attached storage.
With PVS, OS vDisks and AppDisks use different storage areas. The OS vDisk storage capacity is reduced, but the hypervisor-attached storage is increased. So, you should size your PVS environments to accommodate those changes.
AppDisks in the hypervisor-attached storage require more IOPS while the OS vDisks require fewer.
Write cache: PVS uses a dynamic VHDX file on an NTFS formatted drive; when blocks are written to the write cache, the VHDX file is dynamically extended. When AppDisks are attached to their associated VM, they are merged with the OS vDisks to provide a unified view of the file system. This merging typically results in additional data being written to the write caches, which increases the size of the write cache file. You should account for this in your capacity planning.
In either MCS or PVS environments, remember to decrease the size of the OS vDisk to take advantage of the AppDisks you create. If you don’t, plan to use more storage.
When many users in a Site turn on their computers simultaneously (for example, at the beginning of the workday), the multiple startup requests apply pressure on the hypervisor, which can affect performance. For PVS, applications are not located on the OS vDisk, so fewer requests are made to the PVS server. With the resulting lighter load on each target device, the PVS server can stream to more targets. However, be aware that the increased target-server density might negatively affect boot storm performance.
There are two ways to create an AppDisk, install applications on it, and then seal it. Both methods include steps you complete from your hypervisor management console and in Studio. The methods differ in where you complete most the steps.
Regardless of which method you use:
AppDisks on machines from Machine Catalogs created by Provisioning Services require additional configuration during AppDisk creation. From the Provisioning Services console:
This procedure includes three tasks: create the AppDisk, create applications on the AppDisk, and then seal the AppDisk.
Create an AppDisk:
Remember: If you are using PVS, follow the guidance in the PVS considerations section above.
After the wizard closes, the Studio display for the new AppDisk indicates "Creating." After the AppDisk is created, the display changes to "Ready to install applications."
Install applications on the AppDisk:
From your hypervisor management console, install applications on the AppDisk. (Tip: If you forget the VM name, select AppDisks in the Studio navigation pane and then select Install Applications in the Actions pane to display its name.) See the hypervisor documentation for information about installing applications. (Remember: You must install applications on the AppDisk from your hypervisor management console. Do not use the Install Applications task in the Studio Actions pane.)
Seal the AppDisk:
After you create the AppDisk, install applications on it, and then seal it, assign it to a Delivery Group.
In this procedure, you complete the AppDisk creation and preparation tasks from the hypervisor management console and then import AppDisk into Studio.
Prepare, install applications, and seal an AppDisk on the hypervisor:
Use Studio to import the AppDisk you created on the hypervisor:
After you import the AppDisk into Studio, assign it to a Delivery Group.
You can assign one or more AppDisks to a Delivery Group when you create the Delivery Group or later. The AppDisks information you provide is essentially the same.
If you are adding AppDisks to a Delivery Group that you are creating, use the following guidance for the AppDisks page in the Create Delivery Group wizard. (For information about other pages in that wizard, see the Create Delivery Groups article.)
To add (or remove) AppDisks in an existing Delivery Group:
The AppDisks page (in the Create Delivery Group wizard or in the Manage AppDisks flow) lists the AppDisks already deployed for the Delivery Group and their priority. (If you are creating the Delivery Group, the list will be empty.) For more information, see the AppDisk priority section.
When a Delivery Group has more than one AppDisk assigned, the AppDisks page (in the Create Delivery Group, Edit Delivery Group, and Manage AppDisks displays) lists the AppDisks in descending priority. Entries at the top of the list have the higher priority. Priority indicates the order in which the AppDisks are processed.
You can use the up and down arrows adjacent to the list to change the AppDisk priority. If AppDNA is integrated with your AppDisk deployment, it automatically analyzes the applications and then sets the priority when the AppDisks are assigned to the Delivery Group. Later, if you add or remove AppDisks from the group, clicking Auto-Order instructs AppDNA to re-analyze the current list of AppDisks and then determine the priorities. The analysis (and priority reordering, if needed) may take several moments to complete.
After you create and assign AppDisks to Delivery Groups, you can change the AppDisk's properties through the AppDisks node in the Studio navigation pane. Changes to applications in an AppDisk must be done from the hypervisor management console.
Important: You can use the Windows Update service to update applications (such as the Office suite) on an AppDisk. However, do not use the Windows Update Service to apply operating system updates to an AppDisk. Apply operating system updates to the master image, not the AppDisk; otherwise, the AppDisk will not initialize correctly.