With the release of Horizon Mirage 4.0 a new feature called application layering was introduced. This features enables Mirage administrators to deploy applications independent from the base layer.
|Horizon Mirage Layers explained|
|If you want to learn more about the basic layering concept behind Mirage you should have a look at following article: Horizon Mirage Layers explained.|
In this article I will focus on the application layering itself and explain how to create and update application layers. Creating and updating application layers is done in four simple steps:
I will cover these steps later, but first some general things you need to know about the Mirage app layering technique. App layering in Mirage works very different from the most application virtualization products. With app layering an application doesn’t get virtualized and therefore not decoupled from the operating system. This means applications aren’t isolated from each other and they aren’t portable as they depend on the underlying operating system.
But because Mirage doesn’t virtualize applications it can do some stuff using application layers which don’t work with application virtualization products. For example Mirage can deploy applications which depend on drivers (i.e. PDF creators or hand scanner software) and it can also deploy applications which integrate deeply into the OS (i.e. services, shell extensions).
All this is possible because, as already said, applications inside an app layer aren’t virtualized. Instead you can imagine an application layer as nothing more than a bunch of registry keys and files. If an app layer is assigned these registry keys and files are transfered (of course with all the fancy block- and file-level deduplication Mirage offers) to the client system and merged into the native system. As Mirage knows exactly whats contained in the application layer and in the base layer you can also remove an application layer as easily it was assigned before. The Mirage client then just removes all the content contained in the app layer from the native system.
Based on this fact you need to keep in mind that it is only possible to deploy application layers to a device which is fully managed by Mirage. This means it has to have a base layer deployed. Also the base layer has to contain the same operating system the application was recorded on. If you created an application layer on Windows 7 you can only deploy this to a client which runs Windows 7. Also the bitness of the operating system has to be the same. You can not deploy a layer captured on Windows 7 32-bit to a Windows 7 64-bit and vice versa.
The last thing you need to know, before we actually capture and update an app layer is that application layers are merged in sequential order. This means if you have two or more layer which contain for example an DLL file with the same name on the same location but in different versions, the DLL from the last layer applied wins.
As you can see in the diagram above the layer called “AppLayer 3” was applied at last and therefore the “Horizon.dll v3” and the “App.dll v2” are overwriting the other versions. This is the case because the applications aren’t isolated from each other.
Prepare a reference machine
Preparing a reference machine for recording a Mirage application layer doesn’t really differ when compared to preparing a machine used for software repackaging or capturing ThinApp packages. All you need is a system, I recommend to use a virtual machine, which contains the same operating system as the base layer you later want to deploy the app layer to.
For example if you have two base layers deployed one with Windows 7 32-bit and one with Windows XP you need two reference machines. But you don’t need different reference machines if you have for example Windows XP SP2 and SP3.
Also you want to make sure that your reference machine is as clean as possible:
- No anti-virus, malware or personal firewall installed
- No additional software (*)
- No Windows update or auto-updating in general
(*) Obviously if you want to package an application which depends on another application you need to have the application your app depends on installed in the reference machine. Let’s say I package an application which needs Office 2010 which is integrated in by base layer then I need to install Office 2010 into my reference machine before I start the recording process. I highly suggest to create a snapshot before the installation of the prerequisites as you then can easily go back to your clean machine state.
That said after you made all the configuration and optimization needed on your reference machine you have to install the Mirage client on it. When this is done you can shut down the machine and take a snapshot labeled “clean state” or something similar. It is crucial to take this snapshot as it enables you to reuse the virtual machine to capture another app layer.
How to create an app layer
The process of creating an app layer is pretty straight forward. I will not cover this in a step by step manner as this already done as part of the official documentation. I will however talk about some things which are good to know respectively some gotchas everyone should be aware of.
|Official VMware Horizon Mirage Documentation|
|VMware Horizon Mirage Administration Guide|
|The purpose of this document is to guide System Administrators through the installation and deployment of VMware® Horizon MirageTM.|
|VMware Horizon Mirage Application Layers Guidelines|
|This guide describes the VMware® Horizon Mirage™ application layer concept and provides guidelines to ensure successful application layer creation.|
Before starting the capturing process make sure you’re reference machine contains everything you need (preinstalled software, installer, license files, etc.). I personally copy everything over to C:temp and use a specific upload policy for my reference machines which excludes this directory.
When you are finished prepping your machine start the capture process by using the “Capture App Layer” wizard. When the wizard is finished initializing the app layer recording you can start installing your application. In this step it is crucial that you install and configure everything the way you want. You will not be able to edit your application layer after you finished recording.
It is also worth mentioning that the recording process only captures changes made to the machine and discards everything which is specific to a user. So you are not able to preconfigure an application if this data is saved in the user profile, for example %AppData% or HKCU.
Example: if you create a Mozilla Firefox app layer and you configure a different start page this setting isn’t retained in the application layer as Firefox saves all its settings under %AppData%Mozilla.
Once you finished the capture process your new application layer in ready to be assigned to a managed device. Keep in mind you can only assign an app layer to a managed device which uses the same operating system the application layer was capture on.
How to update an app layer
Let me say this first, there is no way to update the content of an application layer. As already said you can not modify an application layer once the recording is completed.
When you want to update an application layer you have rerecord the particular layer. So if you want to update your Mozilla Firefox 18.0.1 application layer to Mozilla Firefox 19.0.2 for example you basically have to record a new application layer with the newer Firefox version.
The difference between creating a new application layer and updating an app layer is how it is saved. While a new application layer gets a new name an updated layer is saved under the name of an existing layer and only the version number is incremented. This allows an administrator to easily push this update to all clients which already had assigned this app layer.
With the exception of this point there is really no technical difference between creating and updating an application layer. Therefore the same rules apply.
Post-app layer deployment script
There is one neat little function when deploying an application layer. It is possible to launch a script after an application layer is deployed. This may come in handy when you want to deploy a device specific license or copy the newest configuration file to the local machine after the layer is deployed.
To apply a post-app layer script you have to save the script during the capture process in %ProgramData%WanovaMirage Service. The script needs to have .bat as file extension and also it requires a unique name. I would recommend a name like “post_layer_update_appname_appversion_layerversion.bat”. Of course you can use this script only as bootstrap for another script (e.g. PowerShell, VBScript, etc.).
After an application layer is deployed the Mirage client checks if a script is available and then executes it.
With Mirage 4.0 VMware released the first version of the powerful application layering feature. While some things definitely need some work (e.g. update process) application layering works really well and is definitely worth a try. You just have to keep the following things in mind:
- Application layering is not application virtualization
- Application layering supports applications which depend on drivers and integrate deeply into the OS (i.e. services, shell extensions).
- Application layers can only be deployed to Mirage clients which have a base layer deployed
- Application layers depend on the operating system and therefore can only be deployed to the same operating system they were captured on
- Application layers are applied sequentially
- An application layer does not contain any user specific settings
- Application layers can’t be edited after the recording process
- Updating an application layer is the same as creating a new application layer