Skip to main content

July 16, 2026

Requirements for ThinApp Integration with Omnissa Access

When you capture and store ThinApp applications to distribute from Omnissa Access, you must meet certain requirements for ThinApp packages and the network share repository. Also make sure that you use supported versions of all components required for the integration.

Component Requirements

You require the following components for the Omnissa Access integration with ThinApp.

  • An Omnissa Access cloud tenant or Omnissa Access virtual appliance version 22.09 or later

  • One or more instances of the Virtual App service, a component of the Omnissa Access Windows connector, version 22.09 or later

  • A ThinApp installation, version 5.2.9 or later

  • (For end users) Omnissa Access Desktop application, version 22.09 or later, installed on a Windows 10 20H2 machine

Requirements for ThinApp Packages

  • To create or repackage ThinApp packages that Omnissa Access can manage, you must use a version of ThinApp that Omnissa Access supports. Omnissa Access supports ThinApp 5.2.9 and later. For updated information about supported versions, see the Product Interoperability Matrix.

  • You must create ThinApp packages that Omnissa Access can manage. See the ThinApp documentation for information about the appropriate parameters to use to create a package compatible with Omnissa Access.

    For existing ThinApp packages, you can use the relink - h command to enable the packages for Omnissa Access.

  • You must store the ThinApp packages on a network share that meets the requirements for Omnissa Access.

Requirements on the Network Share Repository

The ThinApp packages must reside on a network share, also known as the ThinApp package repository. Omnissa Access has the following requirements for the network share.

  • The network share must be accessible using a Uniform Naming Convention (UNC) path from each system running the Omnissa Access Desktop application used to access the ThinApp packages. For example, a network share named appshare on a host named server is accessible using the UNC path \\server\appshare.

  • The fully qualified hostname of the network share folder must be resolvable from the Omnissa Access connector.

  • Omnissa Access supports Server Message Block (SMB) file shares only.

  • Omnissa Access supports only account-based access to the network share.

    You must configure the connector to use a share user account and password to access the network share and the packages. The share user account and password is any combination that has read access to the UNC path to the network share folder.

  • You can use the following installation modes for ThinApp packages.

    • If the user's Windows system is not joined to the domain, the client must use the HTTP_DOWNLOAD installation mode to obtain the virtualized application. This installation mode corresponds to using the ThinApp download mode for the virtualized application.

      The connector uses the share user account to retrieve the packages from the repository.

    • If the user joins the Windows system to the domain, the client can use either the COPY_TO_LOCAL installation mode or the RUN_FROM_SHARE installation mode to run the user's entitled ThinApp packages. The account that is used to log in to the client Windows system is the user account that is used to obtain the packages from the network share, and that account must have the appropriate permissions on the network share.

    • If the user's Windows system might be joined to the domain at some times and not joined to the domain at other times, you can install the client with the COPY_TO_LOCAL mode and the AUTO_TRY_HTTP option enabled.

      With this configuration, the client first tries to use the COPY_TO_LOCAL mode to download the packages. If the Windows system is not joined to the domain at that time, that attempt to copy the packages fails. However, with the AUTO_TRY_HTTP option enabled, the client immediately makes an attempt to use HTTP to download the packages. This combination of COPY_TO_LOCAL and AUTO_TRY_HTTP is the default when you install the Omnissa Access Desktop application on a Windows system by running the graphical version of the client's installer program.

      Important: HTTP_DOWNLOAD mode requires the Base Download URL, which you set in the ThinApp virtual apps collection, to be reachable from the user's Windows machine. RUN_FROM_SHARE and COPY_TO_LOCAL modes require the ThinApp share to be reachable from the user's Windows machine.

In addition, the ThinApp packages repository must meet the following criteria.

  • When your settings involve systems joining the Active Directory domain, make sure that a disjoint namespace does not prevent domain member computers from accessing the network share that hosts the ThinApp packages. A disjoint namespace occurs when an Active Directory domain name is different from the DNS namespace that machines in that domain use.

  • The network share's file and sharing permissions must be configured to provide read access and the ability to run applications to those users that you want to run the ThinApp applications using the COPY_TO_LOCAL or RUN_FROM_SHARE option.

    For example, for the Active Directory user accounts of those users that you want to run the ThinApp applications in streaming mode, setting the Shared Folder permission to Read and the NTFS permission to Read & Execute provides read access and the ability to run the applications to those users.

    The NTFS permission setting of Read & Execute is required to run a ThinApp application using the ThinApp streaming mode, which corresponds to the Omnissa Access Desktop application's RUN_FROM_SHARE installation mode. If your organization requires the NTFS permission set to Read, your users can use the ThinApp download mode for the virtualized application. ThinApp download mode corresponds to installing the Windows client with either the COPY_TO_LOCAL installation mode or HTTP_DOWNLOAD installation mode. With either of those installation modes, the applications are downloaded to the Windows systems and launched locally.

    In the network share, the ThinApp packages must be organized in individual subdirectories in a directory under the namespace, not subdirectories in the namespace itself, such as \\server\appshare\thinapp1, \\server\appshare\thinapp2, and so on. See Create a Network Share for ThinApp Packages That Omnissa Access Manages.

Was this page helpful?

Provide feedback for this topic

Was this topic helpful?

Please do not include any personal or confidential information.

Generating link…