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

Wanova.Server.Cli.exe localhost -c "addCollection MyCollection This is my collection" 

or this

Wanova.Server.Cli.exe localhost -c "addCollection MyCollection "This is my collection""

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:

<span class="crayon-r ">Wanova.Server.Cli.exe</span> localhost<span class="crayon-e "> -c</span> <span class="crayon-s">"addCollection MyCollection \"This is my collection\""</span>

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:

C:\Program Files\Wanova\Mirage Service\Wanova.Desktop.Service.exe.config

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

<add key="showUpgradeBalloon" value="true"/>


<add key="showUpgradeBalloon" value="false"/>

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:

<Config Name="showUpgradeBalloon" Value="false" />

Please be aware that this entry is case sensitive.

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

<?xml version="1.0" encoding="utf-8"?>
<DesktopPolicy xmlns:xsi="" xmlns:xsd="">
<UploadChangesIntervalMs>3600000</UploadChangesIntervalMs> <FullUploadChangesIntervalSeconds>0</FullUploadChangesIntervalSeconds>
<Config Name="showUpgradeBalloon" Value="false" />
<Directory path="%anyvolume%" recursive="true" filter="*.vmdk" />
<Directory path="%anyvolume%" recursive="true" filter="*.vmem" />
<Directory path="%anyvolume%" recursive="true" filter="*.vmsn" />
<Directory path="%anyvolume%" recursive="true" filter="*.vmss" />
<Directory path="%anyvolume%" recursive="true" filter="*.vhd" />
<Directory path="%anyvolume%" recursive="true" filter="*.vfd" />

VMware Horizon Mirage client disk space requirements

Lately the question comes up how much disk space the Mirage client does require?

The VMware Horizon Mirage Installation Guide states: At least 5GB of free space

These 5GB of space are required for normal operation. Normal operation in Mirage terms are centralization and steady state uploads. For both operations the 5GB are required for VSS snapshots, manifest files and other Mirage data.

When it comes to base layer and app layer deployments the required disk space is higher of course. The reason is that you need space to save the data which is contained in the base layer or the app layer.

For example: You want to deploy Office 2013 as an app layer. Office 2013 requires around 3GB of disk space. In this case you need to have at least 8GB free disk space on the client to successfully deploy this application (layer).

5GB for the Mirage client + 3GB for Office 2013 = 8GB total required disk space

If Mirage is used for Windows 7 migrations the required disk space growth even further. When a Windows 7 migration is done with Mirage as first step the Windows 7 base layer and optionally some application layers (this is a new feature in Mirage 4.3) are downloaded to the client.

Example: Your Windows 7 base layer has around 25GB. Then you need at least 30GB of free space on the clients hard drive.

5GB for the Mirage client + 25GB for the Windows 7 base layer = 30GB total required disk space

If you deploy an application layer the same time you do the migration you require additional free disk space in the size of the application layer.

Another example: Your Windows 7 base layer has 25GB and you deploy Office 2013, which requires 3GB disk space, in the same process. Then you need 33GB of free disk space.

5GB for the Mirage client + 25GB for the Windows 7 base layer + 3GB for Office 2013 = 33GB total required disk space

After the Migration you are able to free a lot of disk space because, if the migration was successful, you can delete the Windows.old folder. The Windows.old folder is created during the migration process and contains a complete copy of the old Windows installation. The deletion of this folder can be easily automated, just follow the instructions in this knowledge base article: Removing the Windows.Old directory after User Profile or Windows 7 Migration with VMware Horizon Mirage

And now the disk space requirements for a restore operation. As a rule of thumb for a restore operation (e.g. disaster recovery, revert to old Windows version, hardware migration) you need as much disk space as it was occupied on the original system. This equates to the total size of the CVD which can be found in the CVD properties in the Mirage management console.


Example: So if your system drive contained 80GB of data you need 80GB free space in addition to the 5GB for the Mirage client.

5GB for the Mirage client + 80GB total CVD size = 85GB total free required disk space

Lastly we need to have a look at the disk space requirements for the driver library. The free disk space required for the driver library on the end point depends on the number of drivers you import and assign to a device using the driver profile/library.

For example if you download the Lenovo Windows 7 driver pack for the ThinkPad T430/T530 series and import it into the driver library as is you require around 1.5GB of free disk space. Incase of a Windows 7 migration using a base layer in the size of 25GB and a driver profile containing 1.5GB of drivers you required 26.5GB of free disk space plus the 5GB for the Mirage client.

5GB for the Mirage client + 25GB for the Windows 7 base layer + 1.5GB for the driver profile = 31,5GB total required disk space

The driver library ist applied automatically on operations such as centralization, migration, hardware migration and restore, base layer update and of course if you use the “Set driver library” option. So you should add the driver library every time you do a free disk space calculation like you would do for the 5GB required by the Mirage client.

If for some reason or another you end up not having enough free disk space on the client an event is logged in the Mirage management console.

As you can see the event log even shows you how many free space you have and how many is actually required to successfully finish the current operation.

All listed disk space requirements in this article are not exact and just estimates. The actual disk space required may vary based on the deduplication functionalities in Mirage. Anyway the numbers outline in this article should give you a good idea about the required disk space and most of the time the required disk space will be less.


“Please contact technical support” event in the VMware Horizon Mirage Event Log

In the latest release of Horizon Mirage 4.3 a bug was discovered that might cause upload failures. These upload issues are logged in the Mirage event log with the remark to “Please contact technical support”.

This problem may appear if you updated you Mirage environment from an older release (4.0.2, 4.2.2, 4.2.3) to the latest 4.3 release. Only if you upgraded your environment you may be affected by this problem, new installation based on 4.3 are not affected.

As always our Mirage engineering team solved this issue right away and released a specialized version of the Mirage server tools which allow to fix the upload problems. Inside the download package a PDF called “Fixing potential upload problems in Horizon Mirage” is included which specifies the steps to solve the upload failures as mentioned below:

  1. Upgrade to Mirage 4.3
  2. Download the attached server tools (available in the Mirage download “Tools” section).
  3. Extract the tools in a new folder, not overwriting the installed Mirage binaries.
  4. Run the server tool “LegacyCvdIntegrityCheck”

Wanova.Server.Tools.exe LegacyCvdIntegrityCheck

Usage: LegacyCvdIntegrityCheck
-serverAddress [Management Server Address]
-concurrentScans [number of concurrent integrity scans. Recommended 1-5]
-scanMode [Optional. FixForUpload (Default), CheckOnly, FixForRestore, ProactiveFixForRestore, ProactiveFixForUpload]

Example: Wanova.Server.Tools.exe LegacyCvdIntegrityCheck -serverAddress localhost -concurrentScans 2

If you have any further questions about this tool or bug please contact VMware Technical support or your local VMware rep.


ThinApp 5.0 and support for Horizon View and Workspace

In ThinApp 5.0 some major changes we’re incorporated and therefore broke the interoperability with Horizon View 5.2 and Horizon Workspace 1.5.

Officially only the following scenarios are supported and do work:

  • Horizon View up to 5.2: Only 32-bit ThinApp 5.0 packages are supported
  • Horizon View 5.3 and later: ThinApp 5.0 is fully supported (32-bit and 64-bit packages)
  • Horizon Workspace 1.5: ThinApp 5.0 is not supported at all, wether 32-bit nor 64-bit packages.

Unfortunately there is a bug in the knowledge base article which states that ThinApp 5.0 is, at least for 32-bit packages, supported in Horizon Workspace 1.5. This however is not true and will technically not work. If you want to use ThinApp with Horizon Workspace please use the version 4.7.3 of ThinApp.

Update (29/11/2014): The knowledge base article was updated and now states the correct and supported scenarios.

Source: Horizon View and Horizon Workspace support for ThinApp 5.0 applications

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.

View Connection Server Memory Sizing and JVM Heap Size

In general VMware always recommends to assign at least 10GB of memory to each View Connnection Server when deploying View in production with more than 50 and up to 2000 desktops per Connection Server . There is also a a minimum requirement of 4GB of memory if you only want to deploy 50 desktops or less per Connection server.

Until version 5.3 of Horizon View the installer of the Connection Server automatically set the JVM heap size to a static amount of memory dependent on the amount of memory installed in you server. For example if your server has less then 10GB of memory installed the JVM heap size was set to 512MB. You even get a message at the end of the installation of Connection server that the system is configured with reduced resources due to the limited amount of memory.


So if you configured your Connection server with 4GB of memory at the beginning and later changed it to 10GB, because you added more desktops, the JVM heap size needed to be changed. While there are some guides how to do this manually it is recommended to reinstall the View Connection server software to get the JVM heap size right.

Now with version 5.3 of Horizon View the JVM heap size is automatically adjusted to the optimal size on each start of the View Connection server. No need for manual adjustment or reinstalling the Connection server.

As additional help every now and then you get an event log warning when your View connection server is not configured with the recommended amount of memory.


Update: To check if the JVM heap size was changed after adjusting the amount of physical memory available just have a look inside the current Connection server debug log file located under %ProgramData%VMwareVDMlogs, e.g. debug-2014-01-08-145917.txt.

If you configure your server with less then 10GB of memory the following entry should be found:

2014-01-09T09:32:06.072+01:00 INFO (09A8-0C18) <Service Main Thread> [ws_TomcatService] The service 'TomcatService' is started
2014-01-09T09:32:06.072+01:00 DEBUG (09A8-0C1C) <javabridge> [ws_java_bridgeDLL] Java heap size configured to -Xmx1024m -Dcom.vmware.vdi.SmallPhysMemory=1

If you configure your server with 10GB of memory or more the following entry should be found:

2014-01-09T09:42:47.696+01:00 INFO (0A94-0C14) <Service Main Thread> [ws_TomcatService] The service 'TomcatService' is started
2014-01-09T09:42:47.696+01:00 DEBUG (0A94-0C18) <javabridge> [ws_java_bridgeDLL] Java heap size configured to -Xmx4096m

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.

Antivirus exclusions for VMware Horizon Mirage

To use VMware Horizon Mirage in your environment it is crucial to set some specific Antivirus exclusions. Not setting the exclusions mentioned below can result in slow performance or even failure of any Mirage operation. Also, on the server-side, not setting the proper exclusions can result in Mirage storage inconsistencies.

As you can see it is absolutely a must to set the following exclusions when using Mirage.

Client-side Antivirus exclusions

Configure your Antivirus solution to exclude the Mirage stating area from being scanned:

C:\Wanova Volume Information

White-list the following process in your Antivirus solution:


Both exclusions need to be applied to every machine with the Horizon Mirage client installed.

Server-side Antivirus exclusions

Configure your Antivirus solution to exclude the Mirage local cache on each Mirage server from being scanned. The location of the local cache may vary in each installation as the path is configurable when installing the Mirage server. If you have not changed the location of the cache the following path should be added to the exclusion list:


Mirage local cache location

If you have forgotten where you placed the Mirage local cache you can check the location by having a look at the Mirage server service configuration file (“Wanova.Server.Service.exe.config”) placed in the Mirage server install directory (“C:Program FilesWanovaMirage Server”).

You need to search for the parameter “serverCacheDir” and then you will find the location of your cache directory. As you can see in the screenshot (? marks the line) below in this example cache is located on C:MirageLocalCache.


Your Mirage storage volume (containing all the layers, CVDs, etc.) should be excluded from being scanned too. When it is placed on a Windows file server or on storage directly attached to the Mirage server this is easy. Just add your storage path, e.g. E:MirageStorage, to the list of exclusion in your Antivirus software.

If you use a third-party unified storage it may not be possible to exclude a whole directory from being scanned instead you can only configure file extensions from being excluded. Luckily in Mirage version 4.3 all relevant files and folders on the Mirage storage will be saved with the extension .vhm (VMware Horizon Mirage) and therefore you can just add this extension to the exclusion list. Please be aware that this setting is only valid for the Mirage storage (not the local cache or the client) and is only applied if you create a new storage with version 4.3 of Mirage. Mirage volumes upgraded from an older version to 4.3 will not get this setting.

White-list the following server process in your Antivirus solution on each Mirage server:


White-list the following server process in your Antivirus solution on the server running the Mirage management server:



On the server-side exclude the following location/processes from being scanned by your Antivirus solution:

  • Mirage volume (e.g. E:MirageStorage) or use the .vhm extension
  • Mirage local cache (default location: C:ProgramDataWanovaMirageLocalCache)
  • Wanova.Server.Service.exe (on each Mirage server)
  • Wanova.Management.Service.exe (on the Management server)

On the client-side add the following path and process from being scanned by your Antivirus product:

  • C:Wanova Volume Information (Mirage staging area)
  • Wanova.Desktop.Service.exe

For more information about the Antivirus configuration have a look at the official knowledgebase article Configuring Antivirus and Computer Protection Software Exclusions for VMware Horizon Mirage 3.x and 4.xwhich also served as source for this article.