Intro to Compatibility Containers - Part 1
In this blog series I would like to give an introduction to Compatibility Containers and will cover the following topics:
- Creating Containers (this blog)
- Redirection (upcoming)
- Updating Containers (upcoming)
- Troubleshooting Containers (upcoming)
I will also explain where the similarities and perhaps more importantly, the differences, are with existing Application Virtualization technologies.
So without further ado let's start this part 1 with Creating Containers
Creating a new Cointaner starts by launching the Cloudhouse Auto Packager which can be obtained from our portal if it's not already installed:
If you have the auto packager already installed, it will automatically fetch the latest version from the Cloudhouse portal. This will ensure that you have the latest updates including the exclusion list (files and folders that change during the capture phase but are not relevant to the application you want to capture such as files changes by the operating system) and new Application Compatiblity fixes:
Once the Auto Packages has been installed we can start the capture phase by selecting an output folder and clicking Start Capture. This will take a snapshot so that anything the application installs can be captured against this snapshot.
When the capture has been finished, the application can be installed in the "Install Application" phase by clicking the Next button.
After we've installed the application (I took my favourite tool, Total Commander, for this example) we have a seperate "Run Phase".
This means that we've already captured the files and registry changes made by the application's installer but have have a seperate detection of changes that an application makes during runtime.
This means that we can capture anything the application is doing during it's (first) launch such as accepting the EULA, installing a license file or making settings or configuration changes.
I've seen many applications that register ActiveX controls during first usage or first launch so this is a perfect way to capture those.
Typically that results in issues that are discovered during testing by end users, resulting in rework or even repackaging!
In my case I will be installing my license file (to get rid of the nag screen during launch) and configure Total Commander to my preference:
When your application has been configured the capture can be completed which will take us to the "Edit Package" screen:
The left part of the Captured Files screen shows the folder and files that have been captured during installation and are included by default.
The right part shows files and folders captured during runtime which can optionally be included.
This is important because we don't want to included every change the application has made during runtime but only the required ones.
In the same way we configure the registry keys and optionally include selected keys from the runtime capture.
Last step is to Package the App which will create the actual Container:
Just as other virtualization technologies (.e.g. App-V or ThinApp), Cloudhouse uses a capture process with an initial snapshot, install application and capture the difference approach.
In contrast to App-V and ThinApp, Cloudhouse also supports Capturing and Containerization of Server Side Applications (.e.g. SQL Server). This is important as often applications are only compatible or supported with specific versions of backend/server applications.
Unique to Cloudhouse is that we have a seperate capture of the run phase of an application, where we can detect runtime changes and selectively include those in the resulting Container.
You might wonder what the resulting Container looks like, how you deploy it and what prerequisites it might have.
In the next blog I will discuss the architecture of Cloudhouse Compatibility Containers dealing with a.o. these questions.
By Remko Weijnen, EUC Specialist