CloudVolumes, Mirage and ThinApp: when to use what?

Just last week VMware bought a company called CloudVolumes. CloudVolumes is a solution that uses a technique called layering to deploy application in real-time. After the news broke many customers asked what will happen to Mirage, isn’t that layering as well? And what about ThinApp? Do I need ThinApp anymore?

First of all we need to take a step back and have a look on how these products actually work.


VMware Mirage, formerly called Wanova, was developed with physical machines in mind. Mirage completely operates inside the Windows operating system and uses core Windows technologies like VSS. Besides deploying operating system and applications, called base layer and application layers, Mirage supports additional functions like backup and recovery of end points and also Windows migration scenarios. A huge benefit of Mirage, especially in distributed environments with WAN connections, branch offices and roaming users, are the optimisation techniques included. Mirage uses file- and block-level deduplication as well as compression to reduce the amount of data transferred between the Mirage servers and end points as much as possible.

Of course Mirage will work with virtual machines and VDI environments (using full clones) because it operates purely inside the Windows operating system and therefore doesn’t care if it is run on a physical machine, a virtual desktop on top of VMware Workstation/Fusion or even a Hyper-V virtual machine. Mirage also introduced some optimisations especially for VDI environments, for example, disabling compression and block-level deduplication as well as possibility to limit concurrent operations. But still the way Mirage works isn’t really optimised for VDI environments because for each layer update a reboot is required, each deployment operation is done inside each individual desktop including the file dedupe calculation and non-persistent desktops / linked-clones are not supported. In addition VMware doesn’t support back up/recovery scenarios in virtual environments, even though it is technically possible.

While Mirage can be used in virtual desktop environments and it makes absolutely sense for some use cases, e.g. persistent full clone desktops and containerised desktops, there are some use cases where it doesn’t fit quite right and there is a better way – introducing CloudVolumes.


CloudVolumes works very different in comparison to Mirage. It uses hypervisor technologies to optimise the delivery of layers, in CloudVolume terms a layer is referred to as a CloudVolume. Because CloudVolumes uses hypervisor technologies out of the box it only works with virtual machines running on top of VMware vSphere.

A layer, or a CloudVolume, is basically a VMDK containing the application executables, registry and all supporting application data. When the application layer is deployed to a virtual desktop or user the VMDK is mounted to the corresponding virtual machine and the CloudVolume agent running inside Windows is integrating the mounted VMDK so that is not represented as an additional drive but instead integrated in the native file system and registry. For example, if you deploy Mozilla Firefox using a CloudVolume it is not represented as E:Mozilla Firefoxfirefox.exe because it is integrated in the native file system and looks like a natively installed application which is located at C:Program FileMozilla Firefoxfirefox.exe.

Because the VMDK is read-only the same VMDK can be used for a virtually unlimited number of virtual desktop. Another huge benefit is that layers can be assigned on demand without the need of a reboot.

In addition CloudVolumes supports non-persistent and persistent desktop as well as full and linked clones.


CloudVolumes as well as Mirage are technologies to deploy application. Simply put they are both just a way of transporting application files and registry to a Windows desktop. While ThinApp can also be used as delivery mechanism, especially in combination with Workspace portal, the true power of ThinApp is the ability to isolate an application.

An application deployed using Mirage or CloudVolumes behaves like a natively installed application. It has full access to all installed applications and operating system components and vice versa. This fact makes it simple to deploy applications and gives us a very high success rate when deploying applications this way but it also has the same limitations as any other deployment mechanism that is not application virtualization. You will not be able to run multiple version of an application (e.g. run older version of Internet Explorer in parallel to the latest one) and you won’t be able to prevent DLL conflicts, just to give you two examples.

With ThinApp, because it adds a layer of virtualization, you will be able to run applications isolated from each other and from the operating system. This allows running applications independent from other native installed and virtualized applications and therefore prevent conflicts. It also makes the virtualized applications, to a certain degree, independent from the underlying operating system.

When to use what?

First of all lets discuss when to use Mirage and when to use CloudVolumes. Currently it totally depends on the use case.

When it comes to managing physical end points and containerised desktops Mirage is the way to go. The features Mirage offers, e.g. distribute layers in a highly optimised fashion (file- and block-level dedupe, compression) and backup / recovery functionalities, are huge benefits and must have features in these environments.

In VDI environments, especially in environments in which linked-clones are used, CloudVolumes is the perfect fit. It allows us, in a best case scenario, to use just one golden master and add all user and department specific application using layers. In addition adding an application to a desktop is simply put just a mount of a VMDK the overhead from a performance point of view is negligible especially in comparison to Mirage.

What about full clone, persistent VDI environments? In this case Mirage as well as CloudVolumes offer great functionality and need to be evaluated. But what if I tell you that CloudVolumes enables you to have a persistent desktop experience on top of a non-persistent linked-clone using CloudVolumes. CloudVolumes allows users to install their own applications. All changes are dynamically redirected to a user-specific writable CloudVolume. This volume is automatically mounted when a user logs on to a non-persistent desktop. This makes CloudVolumes a rather nice fitting solution for persistent desktop environments because you can still efficiently manage your master image using linked-clones (View composer) and add user/department specific application using CloudVolumes and optionally even support user-installed application using writable CloudVolumes.

Last but not least there is server-based computing. While Mirage does not support managing server-based operating systems this can be done with CloudVolumes today.

Did I forget ThinApp? No, I didn’t. ThinApp can and should be used complementary on top Mirage and/or CloudVolumes. If you require the benefits of isolating an application, e.g. running an old version Java for a specific application, you can just add this package to a Mirage application layer or a CloudVolume. Because, as I already said, CloudVolumes and Mirage are both just a way to deliver an application, and an application virtualized using ThinApp is still an application that needs to be delivered.

How to deploy application installers using Horizon Mirage application layers

In one of my last blog post I wrote about the different ways to use Mirage app layers to deploy applications. I also introduced a new way to deploy application installers using application layers.

Currently there are two types of applications which can not be deployed using a Horizon Mirage application layer: apps which create users and/or groups during the installation and also applications which modify the local disk like some disk encryption software does.

Still you may want to use Mirage application layers because you may not have another ESD solution or you also want to use all the compression, deduplication and branch reflector functionalities for the deployment and installation of native application installers.

Now I will show you how to deploy an application installer using application layers and how you automate the installation using post-application layer deployment scripts. I will use VMware Player as an example.

I assume that you already have practice in creating and deploying application layers using Mirage and therefore an application layer reference machine is available. If this is not the case please have a look at my article on how Horizon Mirage application layering works.

First you have to start the recording progress for a new application. During the recording process you have to copy the installation source files of the application you want to install to the application layer reference machine. I normally use a location under the Program files directory, something like


In my example the variable %AppLayerName%; is replaced by VMwarePlayer6. So I copy the VMware Player installation executable inside this directory.

After that I create a new post-application layer deployment script. For each application layer the script needs to have a unique name using the format “post_layer_update_*.bat”. The asterisk needs to be replaced with an unique value. I recommend to use the application name for identification and a random number at the end.

For example: post_layer_update_vmwareplayer6_7716.bat

The script has to be placed inside the directory “%ProgramData%WanovaMirage Service”.

The following command line creates a unique post-script in the correct directory and automatically opens it up using Notepad.

notepad.exe "%ProgramData%\Wanova\Mirage Service\post_layer_update_AppName_%random%.bat

Please make sure to replace “AppName” with the name of the application you want to install and to run the command as administrator.

After the script is created and Notepad is opened up you have to add two things: (1) the command line to install the application silently and (2) optionally a command to delete the installation source files after the installation to save local disk space.

For my example I  created the following post-app layer script:

start /wait "Installing VMware Player" "%ProgramFiles%\MirageAppLayerDeployment\VMwarePlayer6\VMware-player-6.0.1-1379776.exe" /s /v EULAS_AGREED=1 COMPONENTDOWNLOAD=0 SIMPLIFIEDUI=1 ADDLOCAL=ALL AUTOSOFTWAREUPDATE=0 DESKTOP_SHORTCUT=0 QUICKLAUNCH_SHORTCUT=0
rd /s "%ProgramFiles%\MirageAppLayerDeployment\VMwarePlayer6"

Of course this script can contain everything you want. You could also run a PowerShell script or something else. One thing you need to keep in mind is that the script is running under the local system account. So user specific changes (HKCU, %AppData%, etc) will no arrive at the locally logged on user but for the local system account.

After you copied the installation sources files to the corresponding directory and created the script file you can finish the application layer.

Now, when you assign the application layer to a managed device the following will happen:

  1. The installation source files and the post-application layer deployment script will be downloaded to the client.
  2. A reboot is required to apply the application layer.
  3. After the reboot is done the post-layer script will run and install the application.

As you can see the installation is not directly done when the application layer is downloaded but after the application layer is applied (after the reboot/pivot phase). Another gotcha to be aware of is when the application layer is removed the application will not be uninstalled. An application layer can only remove files and registry keys which are included in the layer itself, nothing else. So when you remove the layer only the installation source files will be remove but not the application installed by the post-layer script.

If you also want to use application layers to remove applications installed this way just create an uninstall application layer. This layer contains nothing more than post-layer script which silently runs the uninstallation for your specific application.

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.

Managing Horizon View Desktops with Horizon Mirage: Supported scenarios

With the latest release of Horizon Mirage (4.3) VMware introduced the ability to manage Horizon View Desktops using Mirage. While the supported scenarios are currently somewhat limited it is still a major benefit when you have to manage full clone persistent desktop.

Support for managing virtual desktops with Mirage is currently limited to the following scenarios:

  • The virtual desktop needs to be deployed using VMware Horizon View 5.3
  • The virtual desktop needs to be deployed as full clone persistent desktop

Also currently only the following Mirage operations are officially supported with full clone persistent desktops:

  • App layer management
  • Base layer management
  • Enforce layers (to enforce IT applications and settings)
  • Apply driver library

Even with all these restrictions in mind you now have the ability to manage your virtual persistent desktops and your physical desktop with the same tool and the same image (Single image management). This is a huge benefit.

Another big benefits comes in to play when you think about managing your non-persistent virtual desktop using Mirage. It is currently not supported to manage non-persistent desktops directly with Mirage but with a little workaround it can be done today.

As you know, when deploying a non-persistent desktop, Horizon View is using View Composer to created linked-clones. This is a highly optimised process to deploy virtual desktops fast with as little storage consumption as possible. View Composer uses a template virtual machine (master image), better said a snapshot of this machine, to create the linked-clones. As administrator you always install new software, updates and any other customisation to this master image and the recompose all your non-persistent desktops. This means the next time the user logs in he has all the updated stuff on his virtual desktops.

As already said you are not able to manage a linked-clone virtual machine with View yet but of course you can manage your master image with Horizon Mirage. So you can use Mirage deploy all the application, updates, etc. to your master image, uninstall the Mirage client afterwards and then deploy your linked-clones the way you know it.

Now you are able to manage your persistent and non-persistent virtual desktops with Mirage as well as your physical desktops with the same tool.

Last but not least, from a technical point of view, you can of course manage full clone persistent desktops the same way you would manage a physical desktop with Mirage including operations like centralisation, restore, steady state uploads, revert to snapshot, etc. So technically you are able to do a full backup and restore and all other Mirage tasks with a full clone persistent desktop. In this scenario you will put much more workload on your virtual infrastructure as Mirage needs, like every backup tool, resources to backup and restore all the data.

Please keep in mind that officially only the first scenario is currently officially supported by VMware. The second scenario (Managing the master image with Mirage) is kind of a gray area but works perfectly from a technical point of view. The last scenario (full Mirage functionality on a full clone persistent desktop) is definitely not supported but will work.

Advanced options of the Horizon Mirage CVD policy explained

With Horizon Mirage 4.3 some new advanced options inside of the CVD policies were introduced.


The new options are:

  • Optimize for VMware Horizon View
  • Layer assignment only
  • Optimize for LAN environments
  • Disable client throttling

First I will cover the “Layer assignment only” option, followed by the “Optimize for LAN environments” and “Disable client throttling” options. Last but not least I will cover the “Optimize for VMware Horizon View” option and some additional settings referring to the Horizon View optimization.

Layer assignment only

As soon as this option is set no data (with the exception of some meta data) from the client is uploaded to the server. For this reason you have no backup of all of the end point data and functions like restore to snapshot are not possible. Still it is possible to assign layers (base and app layers) and this way you can use Mirage simply as an image management tool without all the heavy lifting of the centralization (full backup of the client).

Optimize for LAN environments

Because Mirage was developed for centralized management of a decentralized fleet of computers located in different offices behind various WAN connections it heavily optimizes the connection between client and server. For example every file transferred between the Mirage client and server is compressed on the fly. Also a deduplication on file- and block-level is done before the data is transferred. As soon as the Mirage server as well as the client are located in the same local area network compressing and deduping the traffic isn’t really necessary as most of the time there are at least ethernet or gigabit ethernet connections available and this is exactly what this option does. As soon as this option is activated compression and block-level deduplication is deactivated on each CVD which has this policy assigned to. This speeds up the process of centralization in LAN environments and also lowers the resources consumed on the end point/server as no compression and block-level dedupe calculations are done anymore. Last but not least the restore streaming functionality is disabled too when this option is activated.

Disable client throttling

Mirage is developed so it can run in the background without the user knowing that some Mirage task (e.g. layer update or synchronization) is currently running. The reason for this is that the Mirage client monitors the users activity and as soon as the user is doing something on his computer the Mirage client throttles down so that the applications run by the users do not slow down. This is a very useful and highly appreciated feature but in proof of concept or test environments this feature just slows down the Mirage processes. The option “Disable client throttling” also disables network throttling within the Mirage client. Normally the Mirage client throttles down its network traffic to not block any other traffic but when you enable this option also this type of throttling isn’t done anymore.

Until now both features had to be disabled in the Mirage desktop XML config file manually but now it is possible, by enabling this option, to set it centrally.

Optimize for VMware Horizon View

The most prominent new CVD policy advanced option is the “Optimize for VMware Horizon View” one. This option does two things: (1) it marks each CVD assigned to this policy as View desktop and (2) automatically enables the options “Layer assignment only” and “Optimize for LAN environments”. As soon as a CVD is marked as View desktop Mirage limits the number of concurrent operations (concurrent layer updates). As this is currently a cluster wide settings this means that by default no more than 20 View desktops will be updated at the same time.


For example if you assign a new layer to 100 desktops only 20 desktop will get the update at the same time. As soon as one of the first 20 desktops has finished updating the next desktop will be updated until all 100 desktop are finished. Of course you can adjust the number to your needs but you need to make sure that the number of concurrent operations isn’t the too high. If the number is too high this could result in degraded performance and therefore user experience as the underlying hardware can’t handle the additional load.

Mirage application layering 4.0 vs. ThinApp 4.7 – the differences

With Horizon Mirage application layering and ThinApp VMware has now two options to deploy applications to endpoints. The big difference between both products is that ThinApp is an application virtualization solution and Mirage Application Layering is not.

While this is the main difference there are still many, many differences between both products in terms of functionality and deployment options. In the following table I tried summarizes most of the differences.

Functionality / Product Mirage application layering 4.0 ThinApp 4.7
Application isolation (running multiple version of the same application, prevent DLL conflicts, etc.) No Yes
OS independency (possibility to build a package on another OS version than it runs on) No Yes
Run different versions of the same application No, only if application supports this natively. Yes
Supports Internet Explorer virtualization / running multiple Version of IE No Yes
Supports application with (kernel) drivers Yes No
Supports applications with native shell extensions Yes No
Support for 64-bit applications Yes No
Require agent on the end point Yes No
Requires additional components on the end point Yes, Microsoft .NET Framework 3.5 No
Endpoint is required to be managed by Mirage Yes No
Optimized deployment method for WAN environments Yes, dedupe, compression and so on No
Methods to deploy application updates Yes, create new applayer with newest application build. Yes, multiple options.
Change application after capturing No Yes
Deploy updates without user interruption Yes Yes
Application updates need reboot Yes No, but you need to restart the application for the update to be applied
Optimized deployment method for applicaliton updates for WAN environments Yes, dedupe, compression and so on Yes, when using AppSync (only block level delta are transfered)
Easy application rollback Yes Yes, but depends on the used update method
Easy application break fix Yes Yes, delete sandbox
User-based application deployment No Yes
Machine-based applicaton deployment Yes Yes
Restrict application access based on Active Directory groups No Yes
Sandboxes user settings No Yes
Run scripts on application start and stop? No Yes
Run script after application is deployed on the system? Yes No

This table only compares Mirage application layer version 4.0 and ThinApp version 4.7.x.

I hope this table may give you a better understanding on the differences between both products. If you found another point in which these products work or behave different you’re welcome to post a comment and I will update the table with your feedback.

If you want to learn more about Mirage application layering and ThinApp and how they compare please vote for our VMworld US 2013 session: 4863 Dare to compare: Mirage application layering and ThinApp

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)