Shared Deployments - Running Containers From File Shares (Deploy without Container Copy)

17/12/2018 Cliff Hobbs

When the deployment executable is run with the /shared switch, shortcuts and file type associations will be created and registered to the Container's current directory, which can be a directory on the local computer or a remote file share. 

Success

Containers deployed in this configuration, run in "shared" mode where the same Container folder is used as the source for multiple servers or desktops. Storing Containers on a file share and deploying them in this way, means the Container can be used in non-persistent server or desktop environments as it avoids installing the application into the base image. Cloudhouse recommends having a copy of the Container per server, or for a limited number of desktop users, and making use of storage de-duplication technologies to minimise the amount of storage used.

Registration

  • Based on the deployment type (machine or user), the shortcuts specified in the shortcuts.xml are registered for the specific user(s).
  • Based on the deployment type (machine or user), the file type associations specified in the FileAssociation.xml files are created in the respective HKLM or HKCU root keys of the registry.
  • The Container's source files will not be deployed to the target machine and will run from the current location of the Container, either from the file share or local directory.

To register a Container stored on a file share with the server or desktop:

Warning

/shared deployments do NOT install the Container on the desktop or server. This means shared deployments do NOT support Containers including the following application features: 

  • COM
  • COM+
  • DCOM
  • Services
  • Use of Deployment.xml to perform MSI installs

Command

\\<share>\<path_to_container>\Cloudhouse.Container.Deployment.exe /<switches> [ machine | user ] [/tokenlocation <drive>:\<path_to_token_outside_container>] /acceptEULA

where <path_to_container> is the path to the Container and <switches> are the relevant command-line switches you wish to specify.

For example:

\\share\containers\container-name\Cloudhouse.Container.Deployment.exe /shared /deploytype [ machine | user ] [/tokenlocation c:\path\to\token\outside\container] /acceptEULA

NOTE: The token is expected to be in the Container unless the path to the token is specified with the /tokenlocation switch. The path can be a local path or a UNC share. The user deploying the Container must be able to read from the token location.

Deprecated in Cloudhouse.Container.Deployment (4.5.1807.555)

  • The option /noprotect has been deprecated.
  • Defaulting to shared deployment when the /deploydir switch is not supported has been deprecated. Instead, you are required to use the new /shared switch.
By default, when the Container source is stored on the shared location, the shortcuts will not have access to shared icons.

Icons and Network Shares

Icons will not be displayed if the Container is on a remote path — for example, a UNC file share. To work around this, create and apply a Group Policy to enable the use of remote paths in shortcut icons. To create the Group Policy:

  1. Load gpedit.msc
  2. Navigate to Computer Configuration | Administrative Templates | Windows Components | File Explorer | Allow the use of remote paths in file shortcut icons 
  3. Select Enabled then click OK.
  4.  Apply the Group Policy.

Uninstall

When the uninstall command is run, the Container's source files will not be deleted.

Source:
Was this article helpful?

Table of Contents

    Can't find what you're looking for?

    Contact Support