Rolling Back a Change

This page covers both kinds of rollback: undoing a change you made, and going back to the previous version of a Cloudhouse Alchemy Compatibility Package.

Note: A rollback rebuilds the deployed copy from a base package, so it undoes anything that was only ever changed in the deployed Compatibility Package on that machine, whether or not that was what you intended to roll back. Before rolling back, check whether any local change needs preserving, and make it in the base package first.

Before You Start

Have the following to hand:

The package folder you are currently running from.
The package folder for the previous version, if what you are rolling back is a package update. It must be the complete folder, not a partial copy.
An administrator account on the machine.
A maintenance window. Rolling back a Compatibility Package stops the application while it happens.
A note of what changed, and when.

Note: If you are not sure whether you are undoing your own change or a package change, work through Step 2: Decide What You Are Rolling Back first. Rolling back the wrong layer costs you the maintenance window and tells you nothing.

Step 1: Identify the Package Version You Are Running

Every Compatibility Package identifies itself in a plain-text file called chmetadata.json, in the root of the package folder. Open it in Notepad:

{
  "PackageId": "...",   <-- always quote this
  "Name": "...",        <-- and these two, if the file has them
  "Version": "...",
  "Publisher": "..."
}

Quote us the PackageId. It is the only value every Compatibility Package is required to carry, it is unique to that package version, and it identifies your package exactly. Name and Version are optional, so a package may not have them; send them as well when they are there.

Unless the Compatibility Package was deliberately deployed hidden, it also appears in Apps & features, or Programs and Features, on the machine. That confirms it is deployed and lets you check the name.

Step 2: Decide What You Are Rolling Back

What happened	What to roll back	Where to go next
You changed a setting or a configuration file, and the application then misbehaved.	Your own change. Restore the file or setting from the copy you took before the change, then restart the application.	Nothing further. No package rollback is needed.
A new package version was deployed, and the application then misbehaved.	The Compatibility Package. Redeploy the previous package version.	Step 3.
Nothing you know of changed.	Neither, yet. A rollback can destroy the evidence needed to find the cause.	Raise it with us before rolling anything back. See What to Send Us When You Raise an Issue.

Step 3: Roll Back to the Previous Package Version

What follows is the general procedure. Your handover document names the exact commands, folders and deployment directory for your Compatibility Package. Where the two differ, follow the handover document.

The deployment program is Cloudhouse.Container.Deployment.exe, in the root of the package folder. Run the commands below from an administrator command prompt: uninstalling a Compatibility Package deployed in the machine context requires one.

Confirm you have the previous Compatibility Package available in full, in its original folder.
Note how the Compatibility Package was originally deployed: to a machine, to a server, to a user, or to a shared context. You need to redeploy it the same way in step 4.
Remove the currently deployed Compatibility Package. From the currently deployed package's folder, run:
```
<path_to_package>\Cloudhouse.Container.Deployment.exe /uninstall
```
The same command uninstalls a Compatibility Package deployed to the user, machine or shared context. Compatibility Packages built before version 4.6.2112.3364 are the exception: on those, add /deploytype machine or /deploytype user to match how the package was deployed. 4. Deploy the previous version, using the same deployment type as the original. From the previous package's folder, run the command for that type.

Machine:
```
<path_to_package>\Cloudhouse.Container.Deployment.exe /deploydir <target_path> /accepteula
```
Server:
```
<path_to_package>\Cloudhouse.Container.Deployment.exe /deploydir <target_path> /accepteula /deployalias server
```
User:
```
<path_to_package>\Cloudhouse.Container.Deployment.exe /deploydir <target_path> /accepteula /deploytype user
```
Shared:
```
<path_to_package>\Cloudhouse.Container.Deployment.exe /shared /accepteula
```
A shared deployment is itself either a machine or a user deployment, and the command above returns it in the machine context. If the original was shared to users, add /deploytype user. The difference is not cosmetic: a machine deployment registers file associations and COM servers in HKLM, a user deployment in HKCU.

Where the command takes /deploydir, set <target_path> to the same deployment directory as the original deployment. Put it in quotes if it contains a space, for example /deploydir "C:\Program Files". 5. Reopen the application and confirm the problem has gone.

Warning: Redeploy with the same deployment type as the original. /deployalias server, /deploytype user and /shared are required for server, per-user and shared deployments; if the switch is missing, the Compatibility Package is deployed in the Machine context instead, which changes where its registry settings are applied. Nothing reports an error when this happens.

Note: Where the command takes /deploydir, use the same deployment directory as the original deployment. Deploying to a different directory does not replace the original: it leaves it in place and creates a second deployment alongside it.

For the full switch list and what each deployment type does, see Deploy an Alchemy Compatibility Package to a Machine, Deploy an Alchemy Compatibility Package to a Server, Deploy an Alchemy Compatibility Package to a User and Deploy an Alchemy Compatibility Package from a Shared Context.

What Survives a Rollback, and What Does Not

What	Survives a package rollback?
Documents and data held outside the application's own folders: file shares, databases, documents in user profiles, local registry	Yes. A rollback does not touch them.
Edits you made on the machine to configuration files that the Compatibility Package also carries a copy of	No, if the change was made only on the machine: the deployed copy is rebuilt from the base package. Yes, if you also made the change in the base package. This is the clearest illustration of why the two copies must be kept in step.
Settings held in the registry settings captured into the Compatibility Package	No. These return to what the Compatibility Package carries.
Files you added by hand to the folder the Compatibility Package deployed to	No. Deployment manages that folder.
Licence activation	Usually, but a licence tied to the installation may need reactivating. Check it after the rollback.
Per-user application settings	Depends on the application and how the Compatibility Package was built. Confirm this for your Compatibility Package before you rely on it, using the note below.

Note: How per-user settings and data behave across a redeployment depends on the specific application and how its Compatibility Package was built, so this page cannot answer it for every case. Your handover document records it for your Compatibility Package. If it does not, ask us before you rely on it.