Three ways to deploy applications using Horizon Mirage application layers

Application layers in Horizon Mirage are a pretty flexible way to deploy applications. In fact you have three ways of deploying applications using Mirage application layering:

  1. Deploy applications using native application layer functionality
  2. Deploy ThinApps using application layers
  3. Deploy application installers using application layers

The first way is obviously the preferred way for any application you want to deploy and use natively. While I normally recommend to install core applications in the base layer some applications may be better suited when deployed via application layers. Examples are departmental apps or applications which are only deployed to a few users. Also applications that need to be updated often and need to be used natively (not virtualized) are good application layer candidates.

The second option is to use ThinApp inside an application layer. Using ThinApp has many great benefits compared to the native application layer deployment. For example running different application versions at the same time, isolate applications to prevent conflicts, get old Windows XP applications up and running on Windows 7 more easily, run old versions of Internet Explorer and browser plug-ins and so on.
While application layers are not yet optimized to deliver ThinApps (you still need to reboot) this is nevertheless a viable option. Especially if you have no other deployment system or deploying ThinApps to branch office users. When deploying ThinApps to branch offices using Mirage application layering the data will be cached on the Mirage branch reflector. Therefore it will only be transferred over the WAN once. This of course is true regardless of which way you use application layers.

The third way is a bit special. When deploying application layers Mirage allows you to run so called post-application layer deployment scripts. Using these scripts you can do more or less anything you want after an application layer is deployed. So why not install an application this way? This may seem a bit cumbersome at first but makes sense for some applications, i.e. to deploy disk encryption software which is not supported using application layers. Or deploy applications which do not work with application layers yet, like VMware Workstation/Player or Microsoft SQL Server. Again deploying applications this way is highly optimized for branch offices scenarios. The application installation files which are placed inside the application layer and the post-script itself are cached on a branch reflector.

Looking at all three options you see that Mirage application layers can be used in many ways. You can deploy any type of application using application layers.

Release: VMware Horizon Workspace Agent 1.5.1

With VMworld Europe 2013 just around the corner VMware just release an update to the VMware Horizon Workspace agent.

While the new version indicates that it is just a minor upgrade it is in fact a complete rewrite and contains major improvements on how ThinApp packages are handled.

Here a short list of the updates:

  • Command line support – sync of new ThinApp entitlements can be done by command line.
  • Full self-service support – User now can add and remove ThinApp packages and the actually get installed and uninstalled on-demand.
  • Better handling of ThinApp updates deployed via Horizon Workspace
  • Enhanced Kerberos Single-Sign In

Much more information about this new release can be found in the following article by Peter Björk (@thepeb) on the official VMware ThinApp blogThe new VMware Horizon Agent are now available.


Migrate ThinApp sandboxes with USMT in Horizon Mirage

In one of my last articles I showed how it is possible to extend the User State Migration Tool (USMT) which is used inside of Horizon Mirage. While I showed the steps on how to get a custom XML file recognized and used by Mirage I left all the heavy lifting of creating the custom XML files to you.

As many of our customers are using ThinApp and USMT as well as Mirage don’t support the migration of ThinApp user and application settings out of the box I though I published the XML file to get this done below. Luckily ThinApp saves all settings on a per-user per-application basis in a central location. By default this location is %AppData%Thinstall. Additionally ThinApp sandboxes are as portable at the ThinApp packages itself and therefore can be easily transferred between different systems.

The following XML file is telling Mirage respectively USMT to include this directory during the migration process.

<migration urlid="">
<!-- This component migrates ThinApp sandboxes -->
<component type="Documents" context="User">
<displayName>ThinApp Sandboxes</displayName>
<role role="Data">
<rules context="User">
<pattern type="File">%CSIDL_APPDATA%Thinstall* [*]</pattern>

Just save this file as ThinApp.xml inside your USMT x86 and x64 folder and customize the Launch_USMT.cmd to add it to the Mirage USMT process. How this can be done is outlined in my article called: How to customize USMT in Horizon Mirage.

Vote now! VMworld US 2013 public voting has begun!

The public voting for the VMworld sessions started yesterday. There are many really good sessions in the voting and you should really have look and take the opportunity to vote for the sessions you want to see.

Christoph from and I submitted a few sessions and we are really glad that all of them are now online. If you want to learn about Horizon Mirage, Workspace, View and ThinApp it would be great if you vote for us.

Here is an overview of our sessions:

4836 Managing Windows desktops is like playing with Lego (Disclaimer: But only if using Horizon Mirage and ThinApp)
Everyone loves the simple approach of Lego in terms of inventing and building new things. Just throw some Lego bricks together and build something completely new. And when you have a new idea you can simply build something completely different again. Wouldn’t it be nice if we could build Windows desktops as easy as building something with Lego? With VMware Horizon Mirage and ThinApp you can do exactly this. Just think about all these different components like drivers, operating system, applications, anti virus as different bricks which can be combined in every possible way you can imagine. We show you how you can accomplish this using Horizon Mirage and ThinApp.

4863 Dare to compare: Mirage application layering and ThinApp
This session compares Mirage application layering and ThinApp. We will start by examine how each of the products work and how they compare. We will discuss pros and cons of each product and show how we can offer the best of both worlds by combining them. As conclusion we will show different use cases and explain which product will the best fit.

4901 Horizon Suite and ThinApp – the perfect match
ThinApp is now an integral part of the Horizon Suite. It brings new functionalities and advantages to each product (i.e. Mirage, Workspace and View) included in the Horizon Suite.. Do you want to know how you can track the usage of your ThinApp packages? Or maybe you always wanted to use ThinApp in your branch offices but until now it was a hassle to deploy those packages to your branch office users? VMware Horizon View, Mirage and Workspace in combination with ThinApp can help you with that. Attend this session if you want to learn what this new match made in heaven has to offer and which benefits each of the products gains.

4960 Things you never thought were possible with ThinApp
Using ThinApp is a breeze, but did you ever wonder how you could do X or Y with ThinApp? Or did it seem impossible to do some specific task with ThinApp out-of-the-box? And what about the those features the other vendors promise but ThinApp allegedly doesn’t offer? We tell you some neat things you can do with ThinApp you never thought were possible. Stuff like:

  • Deploying delta updates using AppLink
  • Native shell integration with virtual packages
  • Check for prerequisites before running a package

Join our session to see how highly customizable and easily extendable ThinApp is.

Link to the voting:

Deploy ThinApp packages via Horizon Mirage

With the release of the new Horizon Suite, Workspace and the new version of Mirage ThinApp is now included in each and every one of these products. To be able to use ThinApp as part of Mirage is very helpful and you can do some nice things which wasn’t very easy to do with ThinApp in the past, for example deploy ThinApp packages to branch office. But ThinApp also brings all the benefits of application virtualization to Mirage’s application layering.

I talked about Mirage’s application layering in my last blog post so if I want to understand the basics of Mirage’s application layer I would recommend to read the article first. In this article I am going to show some options to deploy ThinApp packages thru application layering.

Using MSI

The easiest way to deploy ThinApp with Mirage is to create a MSI installer for your ThinApp package. Just remove the semicolon from the MSIFileName and MSIDefaultInstallAllUsers parameter in the package.ini and then rebuild your package. It is crucial that MSIDefaultInstallAllUsers is enabled and set to 1 if you want to deploy a ThinApp package using Mirage’s app layering. Mirage only records changes to the system and not changes made to a specific user profile during the application layer capturing process. Therefore you must enable the MSI package to install itself for all users and not only for a specific user.


Now you can create a new application layer like you would do it with a normal installation but instead of installing a native application you install your ThinApp MSI package. As you can see in the screenshot below the Mirage application capture process detects the application as it would be installed natively.


To update an application layer to a newer version of your ThinApp package you simply have to create a new layer and install your new ThinApp MSI into it. If you want your users settings to persist make sure both versions of your ThinApp package inside the application layer use the same sandbox name and location. If this isn’t the case all user settings are lost (they are not really lost but your new ThinApp package does not acces the old sandbox/settings) after you deploy the updated application layer.

Using thinreg.exe

Instead of installing a ThinApp MSI package during the application layer recording process you can also use thinreg.exe to deploy your application into the layer. This is done in two simple steps:

  1. Copy your ThinApp package to a location on the reference machine
  2. Run thinreg.exe /allusers to register the package on the reference machine

Example: If you want to deploy your VLC ThinApp package using thinreg.exe you first have to copy your VLC.exe ThinApp package to C:ThinAppVLC.exe and then run thinreg.exe /allusers C:ThinAppVLC.exe.

When using thinreg.exe make sure you specify the /allusers parameter for the same reasons you have to enable the MSI all user installation. Also make sure you don’t have the argument /noarp specified. This prevents the ThinApp package to be registered under Add/Remove Programs (Windows XP) or Programs and Features (Windows 7) and therefore from being detected by the application layering recording wizard.

To update your ThinApp package you have to follow the same procedure as when updating a layer created with an ThinApp MSI package. Just create a new layer using the two steps described above and make sure you packages are using the same sandbox name and location.

Using ThinApp out of the box deployment methods

Of course you can still use all of ThinApp out of the box deployment methods like placing ThinApp packages on a network share and then apply thinreg.exe. Or you could use Mirage deploy the first ThinApp package and then use AppSync.


Creating a Mirage application layer to deploy ThinApp packages is pretty straight forward. You just have to make sure everything is installed in the machine context (all users) and not for a specific user. When deploying ThinApp packages using Mirage you will gain great benefits when deploying ThinApp packages to branch offices as all the Mirage file- and block-level deduplication is also applied to application layers with ThinApp packages inside. Also when deploying ThinApps thru Mirage you still have most of the benefits an application virtualization solution brings to the table, e.g. isolation, portability and consolidation.

The only downside of deploying ThinApp packages with Mirage’s application layering technique today is that the user has to restart the computer for the new application layer to be applied. But while there are definitely use cases (remote and branch offices, mobile worker) to deploy ThinApp packages using Mirage application layers you still can use all the usual ThinApp deployment methods in combination with Mirage.

How does Horizon Mirage 4.0 application layering work?

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

Horizon Mirage Layers explained

With the newest release of Horizon Mirage everyone is talking about layers, base images, application layering and so one. If you never have worked with Mirage or another layering technology before you may have seen something like this in the past:


With this layer cake vendors explain and show the benefits of virtualization. Virtualization, as everybody should know by now, is a technique to abstract the logic from the physical ressource. Well-known examples are:

  • You can abstract the operating system from the physical hardware by using virtual machines (e.g. VMware ESXi).
  • You can abstract applications from the operating system by using application virtualization (e.g. VMware ThinApp).
  • You can abstract the user profile from the application and operating system by using user virtualization (e.g. AppSense Environment Mananger)

When using a virtualization product you not just simply abstract the logic but you put something between the logic and the physical ressource to get the abstraction done, products like ESXi or ThinApp for example. At the beginning of the virtualization boom every product had major limitations but today virtualization technologies got mature and most of the limitations are gone. Still there are some types of virtualization which got some limitations, for example you can’t virtualize drivers with any application virtualization products or the big penalties you have to pay in terms of hardware compatibility, performance and end user experience when it comes type-1 client hypervisors.

Horizon Mirage doesn’t use any virtualization product to abstract the logic from the physic, but we still abstract the logic. With Mirage the layers look something like this:

MirageLayersDetailedTo abstract all these layers from each other Mirage uses some clever engineering work. Simply put Mirage takes all the files, registry keys and drivers and puts them in the right layer. Of course this is done differently for each type of layer. The following list describes how this is done for each layer:

  • Driver layer
    For the driver layer the administrator has to import the drivers he wants to deploy manually. Download the driver package from vendor, extract it and import it into the management console. Drivers then can be combined to driver profiles. So for example you could import all drivers you need for your Dell E6500 laptop and then create a driver profile called “Dell E6500” which contains all the drivers you need for this laptop. Drivers then can be assigned to your managed computers based on a variety of matching rules, for example operating system, hardware vendor and model.
  • Base layer
    A base layer is created by installing the Mirage client on a reference machine and then centralizing this machine. A reference machine is a computer installed with an operating system you want to manage and it also contains your core configuration, infrastructure software (e.g. anti virus) and core apps. When you have configured your reference machine with all the software and settings as needed you can create a new base layer. By default the entire content of the reference machine is saved in a base layer. This however can be modified to exclude specific subsets of content.  Also there are some factory rules applied. The base layer is the first thing deployed to a client machine if its completely managed by Mirage.
  • App layer
    As the name says an application layer contains an application. An application layer is not limited to one application, you can also install multiple applications into an application layer. Even ThinApp packages can be distributed via a Mirage app layer (more on this in another post). An app layer is created using a snapshot technique. You install the Mirage client again on a reference system, create a snapshot before you install your application you want to put in a layer, than you install your application and afterwards Mirage creates another snapshot and compares the differences and compiles them into an app layer. An application layer contains everything detected as delta except for changes written to a specific user profile and again some factory rules.
  • User layer
    The user layer contains all the content a user creates on top of the base layer and app layers. This layer is automatically created for every computer managed by Mirage. Mirage knows, based on the base layer and the app layers assigned to the particular computer, what it needs to save in this layer automatically.
Factory rules and policies
Factory rules and policies are set in place by VMware to ensure that nothing is included or excluded in a specific layer which could hinder Mirage or the layers (operating system, applications, etc.) deployed by Mirage to work probably. An administrator can see what factory rules and policies are applied using the Mirage management console.

The miragcle miracle Mirage now performs is to bring all these layers to your computer and merge these layers as if they were never separated. After you deployed the base and app layers to a device you can basically just uninstall the Mirage client and everything will still work as expected.

As you can see Mirage works like a virtualization solution on the management site. You can separate apps, operating system, drivers and user settings/apps in different logical layers but on the end point, the users desktop, everything is merged back together and works like a native system.

This has obviously many advantages compared to solutions like application virtualization products and typ-1 client hypervisors, for example:

  • The user always gets full native performance.
  • There is no hardware compatibility list. As long your device runs Windows everything is fine.
  • The application is installed locally and so apps with drivers and shell integration can be easily deployed.

Besides the centralized image management and provisioning functionalities Mirages can do much more thanks to the layering approach, for example Windows migrations, hardware migrations, and backup and recovery.

Mirage overlaps with many solutions on the market such as software deployment systems, backup and recovery and image management tools. The good thing about Mirage is that you can combine it with other solutions but you can use it also as a standalone product. There is no either or.

If you want to learn more about Mirage have a look at the Horizon Mirage 4.0 Reviewer’s Guide or the product page.

Sources: VMware, VMware (2), VMware (3)

VMware announced Horizon Suite, but where did ThinApp go?

VMware today announced Horizon Suite as well as three new products called Horizon Workspace, Horizon Mirage and Horizon View.


As you probably noticed two of these four products aren’t actual new. VMware View and VMware Mirage are still the same products, but updated and rebranded to match the new Horizon umbrella.

VMware Horizon View 5.2 contains many new cool features like clientless HTML 5 access, hardware accelerated 3D graphics and Windows 8 support. Andre Leibovici (@andreleibovici) wrote a very good article about what’s new in VMware Horizon View 5.2VMware Horizon Mirage 4.0 biggest new feature is the support for application layering. This allows you to deploy applications and ThinApp packages using Mirages new app layering technique.

VMware Horizon Workspace is a brand new product enabling IT departements to deliver secure and policy-driven data and applications to any device. Last but not least, Horizon Suite is a new product bundle which combines View, Mirage and Workspace. To get more information about the Horizon Suite and Workspace I suggest another great article by Andre: Introduction to the new VMware Horizon Suite.

With all the excitement about this product launch you may still have noticed that ThinApp is gone from the product listing. Don’t panic, ThinApp is still alive and kicking but there are some changes.

Unfortunately ThinApp will not be available as a standalone product anymore. ThinApp is now bundled with the Horizon product line. No matter if you buy Horizon Mirage, View, Workspace or the whole Suite you will always get ThinApp. ThinApp will be integrated in each of this products, so that you can see and use it as a product feature now.

To make a long story short: ThinApp transformed from being a standalone product to being an integral part of the Horizon product family. In my opinion that is a good thing. ThinApp will gain a lot of traction being an integral part of Horizon and also it will gain additional functionality. For example reporting and auditing when combined with Horizon Workspace or a completely new deployment method using Mirages app layers.

To be clear you can still use ThinApp in standalone mode. There is no need to deploy Horizon Workspace, View or Mirage to use ThinApp, but to license ThinApp in the future you have to buy one of the Horizon products. If you still want to buy ThinApp as a standalone product the ThinApp standalone licenses are still available to buy until the end of 2013. After that ThinApp will only be available as part of the Horzion product family. You can read more about the end of availability announcement of VMware ThinApp as a standalone product in the following FAQ: VMware ThinApp Client & Suite End of Availability and End of Support Lifecycle FAQs (direct link to PDF).

Ps: The ThinApp product page is still available.