Deploying an Alchemy Compatibility Package from a Shared Context

Save to PDF

Applies to: Alchemy

25/03/2024 Brian Saladino   ID: 1414159

Use the Shared option when you need to deploy the same Cloudhouse Alchemy Compatibility Package to several servers and desktops.

In this scenario, shortcut and file type associations will be created and registered to the Compatibility Package's current folder, which can be a folder on the local computer or a remote file share.

Delete

Note

By default, when the Compatibility Package source files are stored on the shared location, the shortcuts will not have access to shared icons (for example, a UNC file share).To work around this, see Creating a Group Policy to Allow Access to Share Icons.

Also, your source Compatibility Package is not modified when it is deployed.

Prerequisites

To deploy a Compatibility Package from a Shared context, you need:

  • An account with access to the target computers.
  • A valid Licensing Token within the Compatibility Package.

Process to Deploy a Compatibility Package in Shared Context

  1. Start a Command Prompt.
  2. Run the following command:
<path_to_package>\Cloudhouse.Container.Deployment.Exe /shared /accepteula /switches

where:

  • <path_to_package> is the path to the source Compatibility Package you want to deploy.
  • <switches> are any optional command-line switches you wish to specify.
Delete

Important

The following command-line switches are required to deploy a Compatibility Package to a Shared context:

  • /shared
  • /accepteula

See Alchemy Compatibility Package Deployment Command-Line Options for details of the switches supported for deploying a Compatibility Package.

For example:

C:\Packages\ERP-v2\Cloudhouse.Container.Deployment.Exe /shared /accepteula
Delete

Note

The /deploytype switch is not mandatory. If it is not specified as part of the Shared context deployment command, the Compatibility Package is deployed to the Machine context.

Also, the commands can be run manually, as part of a build script executed by the Administrator, or a third-party electronic software deployment (ESD) tool.

What happens during a Shared Deployment?

When a Compatibility Package is deployed to a Shared context, the following files are copied:

  • App Registry File (AppRegistry.xml).
  • Com Deployment File (ComDeployment.xml).
  • Com Registry Keys File (ComRegistyKeys.xml).
  • Deployment Script File (DeploymentScript.xml).
  • File Associations File (FileAssociations.xml).
  • Services File (Services.xml).
  • Shortcuts File (Shortcuts.xml).

Where these files are copied to depends on whether you are deploying to a User or a Machine:

  • For a User deployment, these files are copied to the following shared location:
    C:\Users\{username}\AppData\Local\Cloudhouse\deployments\{packageId}.
  • For a Machine deployment, these files are copied to the following shared location:
    C:\ProgramData\Cloudhouse\deployments\{packageId}.

where:

  • {username} is the user ID of the user the Compatibility Package is being deployed to.
  • {packageId} is the unique ID of the Compatibility Package.

What happens next depends on whether the Compatibility Package is deployed to Machines or Users:

Delete

Note

There are limitations on support for features that are imposed by Windows. For example, COM or services cannot reference a location on a network share.

For a machine deploy:

  • The application is installed with Administrator rights and the Compatibility Package is registered for all users on the machine.
  • Any file type associations specified in FileAssociations.xml are created in the HKLM registry hive, accessible to all users of that computer.
  • Any shortcuts specified in Shortcuts.xml are registered for all users of the computer. Any shortcuts with a path pointing to the user's desktop or Start menu are translated to the equivalent of the All Users folder so they are accessible to all users on the computer.
  • Any services specified in Services.xml will be registered to the Windows Services, accessible by all users on the computer.
  • Any Com servers specified in ComDeployment.xml will be registered in the HKLM registry hive, accessible by all users on the computer.

For a user deploy:

  • The application is installed without Administrator rights and the Compatibility Package is registered for only a single user.
  • Any file associations specified in FileAssociations.xml are created in the HKCU registry hive, accessible by a single user on the machine.
  • Any shortcuts specified in Shortcuts.xml are registered for a single user on the machine. Any shortcuts with a path pointing to the All Users Desktop are translated to the Users Desktop and any shortcuts with a path pointing to the All Users Start Menu are translated to the Users Start Menu, accessible by a single user on the machine.
  • Any Com servers specified in ComDeployment.xml are registered in the HKCU registry hive, accessible by only a single user. 

Validation

When a Compatibility Package is deployed in the Shared context, validations are performed to ensure that:

  • A valid licensing token exists at the top level of the Compatibility Package.
  • The AAV binaries exist in the Compatibility Package and all have the same version.
  • The Compatibility Package binaries exist within the Compatibility Package and all have the same version.
  • All required components exist in the Compatibility Package.
  • All XML files are valid.

Creating a Group Policy to Allow Access to Shared Icons

If required:

  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.
Source:
Was this article helpful?

Related Questions

Table of Contents

    Can't find what you're looking for?

    Contact Support

    © 2017 - 2024: Powered by Helpjuice