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%\Wanova\Mirage Service”.

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

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:

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.

Virtualize Internet Explorer with VMware ThinApp

For many years now application virtualization solutions and especially ThinApp support the virtualization of Internet Explorer.

A lot of companies need to run old or even multiple versions of Internet Explorer for several reasons, for example:

  • Web applications only work within a specific Internet Explorer version
  • A browser plug-in (Active X, Java, etc.) requires a specific Internet Explorer version

ThinApp allows you to run multiple versions of Internet Explorer and also to run old IE versions on different Windows operating systems, i.e. running Internet Explorer 6 on Windows 8.1.


All supported scenarios can be found in the following knowledge base article: Support Policy for Internet Explorer virtualized with VMware ThinApp

While virtualizing Internet Explorer is somewhat straight forward please follow the procedures outlined in the KB article. If you want to virtualize IE10 you should also have a look at another article of mine: Virtualizing Internet Explorer 10 with ThinApp 5.0. You should also make sure to always use the stand-alone installer of Internet Explorer and not Windows Update to virtualize it.

The last thing to consider is the way virtual instances of Internet Explorer are supported by Microsoft. Officially Microsoft does not support running multiple instance of Internet Explorer on a single instance of Windows.  Also Microsoft will probably not support a virtualized version of IE using ThinApp as Microsoft suggest the following solutions to virtualize Internet Explorer: Med-V, Windows XP Mode or Terminal Services.

While these solutions of course do all work it is a massive effort to build up a terminal services environment to just run Internet Explorer. Also running a virtual machine (Med-V, Windows XP Mode) to run a single version of IE is just a waste of resources.

Virtualizing Internet Explorer using ThinApp is a much leaner way and adding ThinDirect into the mix makes it much more user friendly. But is this a feasible solution if it is not supported by Microsoft? Of course it is. First of all you will still get support from Microsoft if your IE problem can be recreated with a native installation. So if there is a problem with your web application or browser plug-in in a virtualized IE instance just try to recreate it in a native one. If the problem still exist just contact Microsoft Support.

But what happen when the problem only exist in the virtual Internet Explorer instance? This is also not problem at all. Just contact the VMware Technical Support. As long as you have virtualized Internet Explorer according to the Support Policy for Internet Explorer virtualized with VMware ThinApp you will get support from VMware.

For more information about support and licensing of ThinApp’s virtualized Microsoft Internet Explorer 6 on Windows have a look at the following knowledgeable article: Support and licensing of ThinApp’s virtualized Microsoft Internet Explorer 6 on Windows 7.

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.

Use blanks/spaces with the Horizon Mirage server command line interface (CLI)

Using the Wanova.Server.Cli.exe Mirage supports a vast amount of commands to automate different tasks.

My colleague Andreas Wilke (@automatecloud) over at has created an article series covering all the commands and options available.

For some commands you may want or need to use spaces, i.e. for the description of a CVD collection.

But doing something like this

or this

will result in an error (“Error: invalid number of parameters.”) or something other you did not expect.

To use blanks when using the Wanova.Server.Cli.exe -c option you need to use a backslash (\) as escape character like this:

This does not only apply to the “addCollection” command but to any other command of the CLI you want to use spaces with.

How to disable the Horizon Mirage client upgrade balloon

When updating the Mirage server infrastructure to a newer version all Mirage clients are automatically updated the next time they connect to the upgraded Mirage server. During the client update the user gets notified that the client is being upgraded.


While this notification is somewhat non-disrupting sometimes it needs to be deactivated. Of course this is possible with only a minor change to the Mirage desktop service configuration file located here:

Open this XML file in your favourite editor and change the following setting from


Most customers change this key while deploying the Mirage client using a post-install script. But what to do when Mirage is already up and running, the Mirage clients are deployed and you are planning an upgrade?

Thats even easier. You can centrally change this setting by updating your CVD policy. Here is how:

  1. Export your CVD policy using the Mirage management console
  2. Add the text outlined below inside the configuration tags
  3. Import your CVD policy using the Mirage management console
  4. Save the policy as new (minor) version
  5. Assign the updated CVD policy to all your clients

The following parameter has to be added inside the configuration tags:

Please be aware that this entry is case sensitive.

After you edited your CVD policy the XML file should look similar to this example:

Page 2 of 1512345...10...Last »