Workspace ONE Access Requirements for ThinApp Packages and the Network Share Repository

When you capture and store ThinApp applications to distribute from Workspace ONE Access, you must meet certain requirements. These include requirements on the ThinApp packages as well as requirements on the network share repository.

Requirements on the ThinApp Packages

To create or repackage ThinApp packages that Workspace ONE Access can manage, you must use a version of ThinApp that Workspace ONE Access supports. Workspace ONE Access supports ThinApp 4.7.2 and later. For updated information about supported versions, see the VMware Product Interoperability Matrixes at http://www.vmware.com/resources/compatibility/sim/interop_matrix.php.

You must have ThinApp packages that Workspace ONE Access can manage. In the ThinApp capture-and-build process, you can create packages that Workspace ONE Access can manage or ones that it cannot manage. For example, when you use the ThinApp Setup Capture wizard to capture an application, you can make a package that Workspace ONE Access can manage by selecting the Manage with Workspace check box. See the VMware ThinApp documentation for detailed information on ThinApp features and the appropriate parameters to use to create a package compatible with Workspace ONE Access.

For existing ThinApp packages, you can use the relink - h command to enable the packages for Workspace ONE Access. For information about how to convert existing ThinApp packages to packages that Workspace ONE Access can manage, see the Workspace ONE Access Administration Guide.

You must store the ThinApp packages on a network share that meets the requirements for the combination of network share type, repository access, and desired ThinApp package deployment mode for your organization's needs.

Requirements on the Network Share Repository

The ThinApp packages must reside on a network share, also known as the ThinApp package repository. The network share must be accessible using a Uniform Naming Convention (UNC) path from each system running the Workspace ONE 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 Workspace ONE Access connector.

The network share can be a Common Internet File System (CIFS) or a Distributed File System (DFS) share. The DFS share can be a single Server Message Block (SMB) file share or multiple SMB file shares organized as a distributed file system. CIFS and DFS shares running on NetApp storage systems are supported. DFS shares on Isilon storage systems are also supported.

The network share must meet the criteria appropriate for the type of access you configure Workspace ONE Access to use for accessing the ThinApp package repository: domain-based access or account-based access. The type of access determines the allowable combinations for the following items:

Whether you use a CIFS network share or a DFS network share for the ThinApp package repository.
Whether you must join the connector and the network share's host to the same Active Directory domain.
Whether the user's Windows system must join the Active Directory domain to use the ThinApp packages.
The ThinApp package installation mode that the installed Workspace ONE Access Desktop application is set to use for obtaining and running the virtualized applications on the Windows system on which the application is installed. The package installation mode that is used on the user's Windows system is set during the installation process when the Workspace ONE Access Desktop application is installed on that Windows system. This package installation mode determines the mode of ThinApp deployment used by that Windows system, download mode or streaming mode.

Access Type	Network Share Type	Requirements on Workspace ONE Access	Requirements for the User's Windows System
Domain-based access	You can use a CIFS share for your ThinApp package repository when you use domain-based access. You cannot use a DFS share for domain-based access. If you have a DFS share, you must use account-based access.	You must join the connector to the Active Directory domain so it can join the Windows network share and access the packages. Note: Windows authentication is not required. The network share must support authentication and file permissions that are based on computer accounts. The connector accesses the network share with the computer account of the connector in the domain. The network share's folder and file permissions must be configured such that the combination of permissions allows read access for the computer account of the connector in the domain.	The user's Windows system must join the Active Directory domain before that user can use their entitled ThinApp packages. The following systems must all be joined to the same domain: The user's Windows system The Workspace ONE Access connector The host of the network share drive with the ThinApp packages When you use domain-based access, the following installation modes for the ThinApp packages are allowed. COPY_TO_LOCAL. With this installation mode, packages are downloaded to the client Windows system. This installation mode corresponds to using the ThinApp download mode for the virtualized application. The account that is used to log in to the client Windows system is the user account that is used to copy the packages from the network share to the client Windows system, and that account must have permissions to read the packages and copy the files from that network share. After the package is downloaded to the client Windows system and the user launches the package, the virtualized application runs locally on the client Windows system. RUN_FROM_SHARE. With this installation mode, packages are not downloaded to the client Windows system. A user launches the packages using shortcuts on the local desktop and the virtualized applications run from the network share using ThinApp streaming mode. The account that is used to log in to the client Windows system is the user account that is used to run the packages from the network share, and that account must have permissions to read and execute files from that network share. Note: RUN_FROM_SHARE is best suited for Windows systems that will always have connectivity to the ThinApp packages' network share. Windows systems that best fit that description are Horizon desktops, because they are always connected to their domain. Floating, or stateless, Horizon desktops best use RUN_FROM_SHARE to avoid the resource usage inherent in downloading the packages to the Windows system. By default, the COPY_TO_LOCAL installation mode is set as the default installation mode when you install the Workspace ONE Access Desktop application on a Windows system by running the graphical version of the client's installer program. To set a different installation mode as the default installation mode for the packages, you must run the client installation using the command line. See the Command-Line Installer Options for Workspace ONE Access Desktop. Important: HTTP_DOWNLOAD mode requires the IDP URL 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.
Account-based access	You can use either a CIFS share or a DFS share for your ThinApp package repository when you use account-based access.	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 do not have to join the connector to the Active Directory domain to access the network share. Note: In the Workspace ONE Access console, you must complete the Join Domain page before you can use the ThinApp Packages page. Note: Account based access is required if you are using NetApp share.	The user's Windows system does not have to join the Active Directory domain before that user can use their entitled ThinApp packages. Windows authentication is not required. The user's Windows system, the connector, and the host of the network share with the ThinApp packages do not have to be joined to the same Active Directory domain. With account-based access configured, the following installation modes for the ThinApp packages are allowed. 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, as long as the connector is configured for account-based access. 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 Workspace ONE Access Desktop application on a Windows system by running the graphical version of the client's installer program. The connector must be configured for account-based access for the attempt to download the packages using HTTP_DOWNLOAD mode to succeed. Important: HTTP_DOWNLOAD mode requires the IDP URL 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.

Access Type

Network Share Type

Requirements on Workspace ONE Access

Requirements for the User's Windows System

Domain-based access

You can use a CIFS share for your ThinApp package repository when you use domain-based access.

You cannot use a DFS share for domain-based access. If you have a DFS share, you must use account-based access.

You must join the connector to the Active Directory domain so it can join the Windows network share and access the packages.

Note: Windows authentication is not required.

The network share must support authentication and file permissions that are based on computer accounts. The connector accesses the network share with the computer account of the connector in the domain.

The network share's folder and file permissions must be configured such that the combination of permissions allows read access for the computer account of the connector in the domain.

The user's Windows system must join the Active Directory domain before that user can use their entitled ThinApp packages.

The following systems must all be joined to the same domain:

The user's Windows system
The Workspace ONE Access connector
The host of the network share drive with the ThinApp packages

When you use domain-based access, the following installation modes for the ThinApp packages are allowed.

COPY_TO_LOCAL. With this installation mode, packages are downloaded to the client Windows system. This installation mode corresponds to using the ThinApp download mode for the virtualized application. The account that is used to log in to the client Windows system is the user account that is used to copy the packages from the network share to the client Windows system, and that account must have permissions to read the packages and copy the files from that network share. After the package is downloaded to the client Windows system and the user launches the package, the virtualized application runs locally on the client Windows system.
RUN_FROM_SHARE. With this installation mode, packages are not downloaded to the client Windows system. A user launches the packages using shortcuts on the local desktop and the virtualized applications run from the network share using ThinApp streaming mode. The account that is used to log in to the client Windows system is the user account that is used to run the packages from the network share, and that account must have permissions to read and execute files from that network share.
Note: RUN_FROM_SHARE is best suited for Windows systems that will always have connectivity to the ThinApp packages' network share. Windows systems that best fit that description are Horizon desktops, because they are always connected to their domain. Floating, or stateless, Horizon desktops best use RUN_FROM_SHARE to avoid the resource usage inherent in downloading the packages to the Windows system.

By default, the COPY_TO_LOCAL installation mode is set as the default installation mode when you install the Workspace ONE Access Desktop application on a Windows system by running the graphical version of the client's installer program. To set a different installation mode as the default installation mode for the packages, you must run the client installation using the command line. See the Command-Line Installer Options for Workspace ONE Access Desktop.

Important: HTTP_DOWNLOAD mode requires the IDP URL 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.

Account-based access

You can use either a CIFS share or a DFS share for your ThinApp package repository when you use account-based access.

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 do not have to join the connector to the Active Directory domain to access the network share.

Note: In the Workspace ONE Access console, you must complete the Join Domain page before you can use the ThinApp Packages page.

Note: Account based access is required if you are using NetApp share.

The user's Windows system does not have to join the Active Directory domain before that user can use their entitled ThinApp packages. Windows authentication is not required.

The user's Windows system, the connector, and the host of the network share with the ThinApp packages do not have to be joined to the same Active Directory domain.

With account-based access configured, the following installation modes for the ThinApp packages are allowed.

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, as long as the connector is configured for account-based access.

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 Workspace ONE Access Desktop application on a Windows system by running the graphical version of the client's installer program.

The connector must be configured for account-based access for the attempt to download the packages using HTTP_DOWNLOAD mode to succeed.

In addition, the ThinApp packages repository must meet the following criteria according to the described situation.

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 Workspace ONE 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.

Both CIFS and DFS network shares must have the ThinApp packages 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 Workspace ONE Access Manages.