Product documentation
Citrix DaaS
View PDF

App packages

June 9, 2025
Contributed by: 
C

App packages are pre-configured application deployments that Citrix manages. They allow applications to be virtualized, which implies that the applications run independently of the user’s device’s operating system and interface.

App packages simplify application management, reduces IT overhead, and ensures that applications are secure and functional throughout their lifecycle.

Citrix supports the following packaging technologies for delivering applications to users:

This article walks you through how to deploy and deliver these packaged applications in your Citrix DaaS environment.

App-V applications

Application Virtualization (App-V) is a Microsoft technology that allows applications to be streamed and accessed without requiring installation on the end user’s device. Citrix DaaS can use App-V to deliver applications, providing a centralized and efficient way to manage applications across various client machines.

For more information about the components and concepts with which you interact when delivering App-V packaged applications, see the Microsoft documentation: Application Virtualization (App-V) for Windows client overview.

Important terms

  • Management server: Provides a centralized console to manage App-V infrastructure and delivers virtual applications to both the App-V Desktop Client and a Remote Desktop Services Client. The App-V management server authenticates, requests, and provides the security, metering, monitoring, and data gathering required by the administrator. The server uses Active Directory and supporting tools to manage users and applications.
  • Publishing server: Provides App-V clients with applications for specific users, and hosts the virtual application package for streaming. It fetches the packages from the management server.
  • Dynamic configuration files: App-V packages can be customized using dynamic configuration files, that when applied to the package, can be used to change its characteristics. For example, you can use them to define extra application shortcuts and behaviors. For more information, see Dynamic configuration files

Dynamic configuration files

Citrix App-V supports both types of dynamic configuration files. File settings are applied when the application is launched:

  • Deployment Configuration files provide machine-wide configuration for all users. These files are expected to be named <packageFileName>_DeploymentConfig.xml and in the same folder as the App-V package they apply to. These files are supported by single and dual admin management.

  • User Configuration files provide user-specific configuration that supports per-user customizations to the package. Single Admin supports user config files named in the following format: <packageFileName>_[UserSID | Username | GroupSID |GroupName_]UserConfig.xml and located in the same folder as the App-V package they apply to.

    When multiple User Configuration files exist for a particular package, they are applied with the following priority:

    1. User SID
    2. Username
    3. AD Group SID (First found wins)
    4. AD Group Name (First found wins)
    5. Default

    For example:

     MyAppVPackage_S-1-5-21-000000001-0000000001-000000001-001_UserConfig.xml
 MyAppVPackage_joeblogs_UserConfig.xml
 MyAppVPackage_S-1-5-32-547_UserConfig.xml
 MyAppVPackage_Power Users_UserConfig.xml
 MyAppVPackage_UserConfig.xml
 <!--NeedCopy-->

    Note:

    The user-specific portion of the file name can also optionally occur at the end (for example MyAppVPackage_UserConfig_joeblogs.xml).

Important:

You cannot apply changes to Dynamic Deployment Configuration when there are user sessions with an application in the package open. You can apply changes to Dynamic User Configuration files if other users (but not the current user) have the application from the package open.

Dynamic configuration file location

In single admin management, the Citrix App-V components only process dynamic configuration files, which are found in the same folder as their App-V package.

When applications in the package are launched, any changes to the corresponding dynamic configuration files are reapplied. If your dynamic configuration files are in a different location to their packages, use a mapping file to map packages to their deployment configuration files.

To create a mapping file:

  1. Open a new text file.

  2. For each dynamic configuration file, add a line that specifies the path to the package using the format <PackageGuid> : path.

    For example:

    F1f4fd78ef044176aad9082073a0c780 : c:\widows\file\packagedeploy.xml
<!--NeedCopy-->
  3. Save the file as ctxAppVDynamicConfigurations.cfg in the same folder as the package.

The entire directory hierarchy on the same UNC share as the App-V package is searched recursively upwards for this file every time an application in the package is launched.

Methods

You can use the following methods to deliver and manage App-V packages:

  • Dual Admin: In this method, Citrix DaaS and App-V servers work together to deliver and manage packages. This method requires Citrix DaaS to periodically refresh the snapshot view of the App-V server’s state. It incurs hardware, infrastructure, and administration overhead. Citrix DaaS and App-V servers must stay synchronized, particularly for user permissions.

    This method works best in closely coupled App-V and Citrix deployments. In this method:

    • App-V management server handles the dynamic configuration files
    • App Packages Delivery Component installed on VDA machines: Manages the registration of the appropriate publishing server required for an application launch.

    This ensures that the publishing server is synchronized for the user at the appropriate time. The publishing server maintains other aspects of the app package life cycle (like refresh on logon and connection groups) using the settings that it is configured with.

  • Single Admin: Application packages are stored on network shares. Citrix DaaS delivers and manages packages independently.

    This method reduces overhead because the App-V servers and database infrastructure aren’t needed in the deployment.

    In this method, you store App-V packages on a network share and upload their metadata from that location to your environment. The App Packages Delivery Component installed on VDA machines then manages and delivers applications as follows:

    • Process the Deployment Configuration Files and User Configuration Files when an application is launched.
    • Manage all aspects of the life cycles for packages on the host machine.

Note:

  • You can use one or both management methods simultaneously. In other words, when you add applications to Delivery Groups, the applications can come from App-V packages located on App-V servers or on a network share.
  • If you are using both management methods simultaneously, and the App-V package has a dynamic configuration file in both locations, the file in the App-V server (dual management) is used.
  • When you select App packages in the Web Studio navigation pane, the display shows package names and sources. The Package type column indicates which technology is used to deliver the package and where they are referenced in the Application Library. When you select a package, the details pane lists the applications and shortcuts in the package.

MSIX and MSIX app attach applications

MSIX is a Windows app package format that provides a modern packaging experience to all Windows apps. MSIX is suitable for various Windows application types, including Win32, .NET, and UWP apps.

MSIX app attach utilizes MSIX packages that are pre-expanded onto virtual hard disks, which can be mounted to the target machine as required, rather than streaming the package contents. It can improve deployment times, reduce network traffic, and lower IOPS on the target machine, but requires additional work to create and maintain the app attach disks.

Citrix DaaS delivers MSIX and MSIX app attach applications to users through the App Packages Delivery Component installed on VDA machines. This component manages all aspects of the life cycles for packages on the host machine.

For more information about MSIX and MSIX app attach, see the Microsoft documentation: MSIX documentation and App Attach in Azure Virtual Desktop respectively.

Note:

  • We support native MSIX Packages on Desktop and server VDAs and MSIX app attach on .vhd, .vhdx, and .cim disk image formats on Desktop VDAs only.
  • Microsoft does not offer an AppAttach implementation for Server 2019. While AppAttach is present in Server 2022 and 2025, Microsoft does not support it on these versions. Therefore, we also do not support AppAttach on Server 2022 and 2025.
  • Enable sideloading on Windows Server 2019.
  • Ensure VDAs trust the certificates that packages are signed with.

FlexApp applications

FlexApp is an application layering solution developed by Liquidware that attaches any application to a Windows session without modifying the underlying base image through the traditional application installation process.

FlexApp One applications are encapsulated in a single, shareable file, allowing them to operate without requiring an additional application player on Windows sessions. Users can initiate the application by clicking the container file, which quickly integrates one or more applications into their Windows workspace.

Citrix delivers FlexApp applications to users through the App Packages Delivery Component and FlexApp delivery agent installed on VDA machines. These two components manage all aspects of the life cycles for packages on the host machine.

Deploy and deliver app packages

Prerequisites

To support the delivery of App-V, MSIX, MSIX app attach and FlexApp packages, you must first install the App Packages Delivery Component on VDA machines. See Install the App Packages Delivery Component on VDA machines for details.

Install the App Packages Delivery Component on VDA machines

The App Packages Delivery Component manages the publishing process for application packages in App-V, MSIX, MSIX app attach, and FlexApp formats. This component isn’t installed by default when you install a VDA. You can install the component during or after VDA installation.

To install the component during VDA installation, use either of the following ways:

  • In the installation wizard, go to the Additional Components page and then select the App Packages Delivery Component checkbox.
  • In the command line interface, use the /includeadditional “Citrix Personalization for App-V – VDA option.

To install the component after VDA installation, follow these steps:

  1. On the VDA machine, go to Control Panel > Programs > Programs and Features, right-click Citrix Virtual Delivery Agent, and then select Change.
  2. In the wizard that appears, proceed to the Additional Components page and then enable the App Packages Delivery Component checkbox.

Note:

  • Microsoft App-V Desktop Client is the component that runs virtual applications from App-V packages on user devices. Windows 10 (1607 or later), and Windows Server 2019 and later already include this App-V client software. You must only enable it on VDA machines. For more information, see this Microsoft documentation article: Enable the App-V in-box client.
  • For FlexApp applications, install the FlexApp One Agent on the VDA along with the App Packages Delivery Component.

Install the FlexApp One Agent

  1. Launch an administrator command prompt on the VDA.

  2. Locate the network path for any FlexApp One Package.

  3. Input the following command:

    \\path\to\any\FlexAppOnePackage.exe --install
<!--NeedCopy-->
  4. Accept any prompts that appear.

Deliver packaged applications

After you complete installing the prerequisites, do the following to deliver packages applications to your users:

  1. Store application packages on network shares.
  2. Upload application packages into your environment.
  3. Add applications to delivery groups.
  4. To enable automatic delivery of interdependent App-V packages, create isolation groups.

Store application packages on network shares

After you set up the infrastructure, generate the application packages and store them in a network location, such as a UNC or SMB network share, or on an Azure File Share.

Detailed steps are as follows:

  1. Generate application packages. See the Microsoft documentation: Creating and managing App-V virtualized applications for details.

  2. Store application packages in a network location:

    • For App-V Single Admin: Store the packages and the corresponding Dynamic Configuration Files (App-V) on a UNC or SMB network share or on an Azure File Share.

    • For App-V Dual Admin: Publish the packages onto the App-V management server from a UNC path. (Publishing from HTTP URLs isn’t supported.)

    • For MSIX or MSIX app attach: Store the packages on a UNC or SMB network share or on an Azure File Share.

    • For FlexApp: Store the packages on a UNC or SMB network share or an Azure File Share.

  3. Make sure that the VDA has read permission on the package storage path:

    • If you store packages on a UNC or SMB network share in your AD domain, grant the VDA machine read permission to the storage path. To do so, you can give the machine’s AD account read permission to the share explicitly, or include the account in an AD group that has that permission.

    • If you store packages on an Azure File Share, first grant a user account read permission to the storage path in Azure. Next, configure ctxAppVService running on the VDA machine to use that user account to access the package storage path. See the Change the user logon account for the detailed steps.

Change the user logon account

Change the user logon account in the following two scenarios:

  • To access packages on an Azure File Share using a linked AD account:
    • The connecting entity must be a user account, not a machine account, as Azure AD doesn’t grant read permissions to machine accounts on File Shares.
  • If MSIX and MSIX AppAttach packages contain services:
    • The package must be published using a user account with administrative privileges on the local machine before it can be published to any non-administrative users. This is necessary for packaged services to be installed and packages can only be published to users, not machines, making the default LocalService account unsuitable.

The VDA calls ctxAppVService to access package storage paths and perform operations that require administrative privileges. By default, ctxAppVService runs under the context of the machine’s LocalService account that authenticates to AD using the machine’s identity and is not suitable for the preceding scenarios.

In either case, the service must be reconfigured to use an AD user account that has administrative privileges locally and has been granted read access to the storage location for the packages, be that an SMB share or an Azure File Share, as follows:

  1. Start Services, right-click ctxAppVService, and then select Properties.
  2. On the Log on tab, select This account:
    1. Enter a user account that has local administrative privileges and read permission to the package storage path
    2. Enter the user’s password twice.
  3. Click OK.

Upload application packages into your environment

After you store application packages to a network location as needed, upload them to your environment for delivery. Use either of the following methods as needed:

Preparations

Citrix DaaS uses a VDA machine to set up the connection to the network location for package discovery. Therefore, create a delivery group beforehand and make sure that at least one VDA in the group meets the following requirements:

  • VDA version:
    • To discover App-V packages: 2203 or later
    • To discover MSIX and MSIX app attach packages: 2209 or later
    • To discover FlexApp packages: 2311 or later and the FlexApp Agent software
  • App Packages Delivery Component: Installed
  • Permission on the package location: Read (See Store application packages on network shares for details.)
  • Power: On
  • State: Registered
Upload application packages in bulk

Upload packages in a network location to your environment. Make sure that you have the following items ready before the upload:

  • A delivery group that meets the Preparations requirements
  • The network location path

To upload packages in bulk, follow these steps:

  1. In the left pane, select App packages.
  2. On the Sources tab, click the Add Source button. The Add Source page appears.
  3. In the Name field, enter a descriptive name for the package source.
  4. In the Delivery group field, click Select a delivery group. Next, select a delivery group that meets the requirements stated in Preparations and then click OK.
  5. In the Location type field, select Microsoft App-V server or Network share based on where you store the packages, and then complete the corresponding settings:
    • If you select Microsoft App-V server, enter the following information:
      • URL of the Management server. Example: http://appv-server.example.com
      • Login credentials of the management server administrator.
      • URL and port number of the publishing server. Example: http://appv-server.example.com:3330
    • If you selected Network share, specify the following information:
      • Enter the UNC path of the network share. Example: \\Package-Server\apps\
      • Select the package types that you want to upload. Options include App-V, MSIX, MSIX app attach, and FlexApp.

      • Specify whether to search subfolders for packages.

        Note:

        If you search for MSIX app attach packages on a folder structure containing cim images, ensure that you select the Search subfolders. Otherwise, the disks are not discovered correctly.

  6. Click Add Source.

    The Add Source page closes and the newly added source appears in the source list. Citrix DaaS uploads the packages to your environment using a VDA in the delivery group. After the upload completes, the Status field shows Import successful. The corresponding packages appear on the Packages tab.

    Note:

    To check for package updates in a source location and import them to your environment, select the location in the source list and click Check for Package Updates.

Upload application packages one by one

Upload an application package from a network share to your environment. Before the upload, make sure that you have the following items ready:

  • A delivery group that meets the requirements stated in Preparations
  • The network location path.

To upload a package to your environment, follow these steps:

  1. In the left pane, select App Packages.
  2. On the Packages tab, click the Add Package button. The Add Package page appears.
  3. In the Delivery group field, click Select a delivery group. Next, select a delivery group that meets the requirements stated in Preparations, and then click OK.
  4. In the Package full path field, enter a path as needed:
    • To upload several packages at a time, enter their full paths, separated by semicolons (;). Example: \\Package-Server\apps\office365.appv;\\Package-Server\apps\skype.msix;\\Package-Server\apps\slack.vhd
    • To upload all packages present on a network share, enter the storage path. Example: \package-Server\apps\

  5. Click Add Package.

    The application package appears on the Packages tab.

Add applications to delivery groups

After an application package is fully uploaded to your environment, add its applications to one or more delivery groups as needed. As a result, users associated with those delivery groups can access the applications.

Note:

  • You can deliver packaged applications to single-session VDAs and multi-session VDAs through delivery groups.
  • By default, end users have access to all packaged applications assigned to the delivery groups associated with their single-session (or called Desktop) VDAs. To limit visibility of a packaged application on desktop VDAs to specific users or groups, go to the Applications node, select the application, and then select Edit Application Properties > Limit Visibility to make changes. See Limit visibility of applications

To add one or more applications in a package to several delivery groups, follow these steps:

  1. In the left pane, select App Packages.
  2. On the Packages tab, select a package as needed.
  3. In the action bar, click Add Delivery Groups. The Assign Applications to Delivery Groups page appears.
  4. Select one or more applications in the package as needed, and then click Next.

  5. In the list of delivery groups, select the groups to which you want to assign the applications, and then click Next.

    Note:

    • If you selected an MSIX or MSIX app attach package, only delivery groups whose VDA version is 2106 or later are shown in the list.
    • If you selected a FlexApp package, only delivery groups whose VDA version is 2402 or later appear in the list.
  6. Click Finish.

To add applications in various packages to multiple delivery groups, follow these steps:

  1. In the left pane, select App Packages.
  2. On the Applications tab, select Add Applications.
  3. On the Groups page, select one or more delivery groups as needed.
  4. On the Applications page, select one or more application packages as follows:
    1. Click Add and then select Application packages.
    2. Select the type of package source needed (for example, App-V Single Admin). All packages of this type appear.
    3. Select one or more packages as needed.
    4. Click OK and then Next.
    5. To add more applications of a different package type, repeat steps a through d.
  5. Click Finish.

You can also add packaged applications to a delivery group when:

(Optional) Create isolation groups for App-V packages

You can create isolation groups to enable the automatic delivery of interdependent App-V packages.

Note:

Isolation groups are supported for the App-V Single Admin method. If you’re using the App-V Dual Admin method, you can achieve the same goal by creating connection groups in the Microsoft App-V infrastructure. For more information, see this Microsoft documentation article: About the connection group file.

About isolation groups

An isolation group is a collection of interdependent application packages that must run in the same Windows Sandbox to create a virtual environment. Citrix App-V isolation groups are similar but not identical to App-V connection groups. An isolation group includes two types of packages:

  • Explicit application packages: Applications with specific licensing requirements. You can restrict those applications to a specific range of users by adding them to delivery groups.
  • Automatic application packages: Applications that are always available to all users regardless of whether they are added to delivery groups.

For example, the application app-a requires JRE 1.7 to run. You can create an isolation group that contains app-a (marked as Explicit) and JRE 1.7 (marked as Automatic). Next, add the App-V package for app-a to one or more delivery groups. When a user launches app-a, JRE 1.7 is automatically deployed with it.

When a user starts an App-V application marked as Explicit in an isolation group, Citrix DaaS checks the user’s access permission to the application in delivery groups. If the user has permission to access the application, any Automatic application packages in the same isolation group are made available to the user.

You do not need to add the Automatic packages to any delivery group. If there’s another Explicit application package in the isolation group, that package is made available to the user only if it is in the same delivery group.

Create an App-V isolation group

Create an isolation group and add interdependent application packages to it. Detailed steps are as follows:

  1. On the Isolation Groups tab, click Add Isolation Group.
  2. Enter a name and description for the isolation group. All App-V Single Admin packages in your environment appear in the Available Packages list.
  3. From the Available Packages list, select an application as needed, and then click the right arrow. The selected application appears in the Packages in Isolation Group list.
  4. In the Deployment field, select Explicit or Automatic for the application.
  5. Repeat steps 2–3 to add more packages.
  6. To adjust the order of packages in the list, click the up or down arrow.
  7. Click Save.

Note:

Isolation Group configurations result in the creation of an App-V Connection Groups on the VDA. Deployment scenarios can become complex and the App-V client supports packages that are only in one active Connection Group at a time. We recommend that you avoid adding the same package to two different isolation groups that are added to the same delivery group.

Best practices

  • To deploy App-V packages, enable the App-V subsystem on the VDA using the PowerShell command Enable-AppV.
  • To deploy MSIX (and AppAttach) packages, the VDA must trust the certificates that the packages are signed with.
  • On Windows Server 2019, enable sideloading to deploy MSIX packages. Sideloading is not needed for Windows 10, 11, Windows Server 2022, and 2025.
  • App Attach has no implementation at all on Windows Server 2019 and is not currently supported by Microsoft (or Citrix by extension) on Windows Server 2022 or 2025.

Advanced

Automate packaged application publishing

You can use PowerShell commands to automate packaged application publishing:

On the Delivery Controller, run the following PowerShell commands:

  1. To load the commands present in the Package Discovery Module:

    Import-Module "D:\Support\Tools\Scripts\Citrix.Cloud.AppLibrary.Admin.v1.psm1"
<!--NeedCopy-->

    Note:

    The version of the package discovery module can be found on the Citrix DaaS ISO on the path mentioned in step 1.

  2. The package discovery module must be from the ISO of a Citrix DaaS version that also supports the package type you are publishing, that is, 2311 or higher is needed for FlexAppOne Applications. We recommend using the latest available.

  3. To retrieve the relevant delivery group IDs and packaged application IDs:

    Get-BrokerDesktopGroup | Format-Table Uid, Name 
Get-AppLibAppVApplication | Format-Table Uid, Name
<!--NeedCopy-->

  4. To publish the packages and create the appropriate BrokerMachineConfigurations:

    Publish-PackagedApplication -AppLibararyApplicationUid <AppLibararyApplication.Uid > -DesktopGroupUid <DesktopGroup.Uid>
<!--NeedCopy-->

  5. To synchronize the Broker configurations, which are later sent out to the Broker agent on VDA:

    Update-DesktopGroupMachineConfigurations -DesktopGroupUid <DesktopGroup.Uid>
<!--NeedCopy-->

    Note:

    Ensure to run the PowerShell command Update-DesktopGroupMachineConfigurations after you publish or remove packaged applications from a delivery group through the PowerShell command line. Otherwise information about the published applications is not sent to the VDA correctly and launches fail.

Limit visibility of applications

In a Citrix DaaS environment, when applications from packages are published to desktops, the system respects Active Directory (AD) user and group visibility settings for those applications. However, even if a user only has visibility to one application within a package, the entire package must be deployed to the Virtual Desktop (or Seamless App) Session since individual package components cannot be subdivided on the VDA. Additionally, before VDA version 2503, changes that reduce application visibility after the initial publishing won’t result in a clean-up of previously published packages on subsequent desktop launches. Furthermore, other visibility layers, such as desktop versus workspace visibility, operate on top of these AD visibility assignments.

You can control whether packaged applications must appear in Workspace or are deployed to the users’ VDI Desktop sessions. Once a packaged application has been published you can update the PackagedApplicationVisibility property on the BrokerApplictaion using the PowerShell command Set-BrokerApplication -Name "MyApp" -PackagedApplicationVisibility "Workspace|Desktop|WorkspaceAndDesktop".

The default value of PackagedApplicationVisibility is WorkspaceAndDesktop.

The value Workspace: app appears only in WorkspaceApp and is available for a seamless AppLaunch, but the app won’t automatically be published to any desktop session that users start.

The value Desktop: hides the app’s icon from WorkspaceApp making it unavailable for a seamless AppLaunch but the app can still be deployed to users’ desktop sessions if users also have access to it through their AD Group settings.

Note:

Packaged Applications published to Single Session Static desktops are never available in Workspace App regardless of the value configured in this setting.

App packages
June 9, 2025
Contributed by: 
C
June 9, 2025
Contributed by: 
C

In this article

Site feedback | Your privacy choices footer linkYour Privacy Choices | Privacy and legal terms | Cookie preferences | Consent settings | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.