VMware Horizon Mirage driver library best practice

Mirage offers many great functionalities which can be applied to different types of hardware. With Mirage you are able to do hardware migrations (e.g. from a hardware vendor to another), single image management (one image for different types of hardware), disaster recovery (e.g. from a hardware to a VM) and of course Windows migrations.

But all of these operations need one crucial thing to work: device drivers.

Without the correct drivers for your hardware many operations will fail. For example, Mirage will not be able to migrate a client to a new hardware if no suitable drivers are available. The good thing though is that Mirage will never render a system unbootable as it actively checks if all boot critical drivers are available. But Mirage will not check if you have, for example, the proper network or sound card drivers available instead Mirage will warn you if you do not have a matching driver profile for your hardware.

Driver profile

What is a driver profile? Mirage uses driver folders and driver profiles to dynamically provide drivers to a type of hardware.

A driver profile consists out of two things: (1) matching rules to specify to which hardware / endpoint drivers should be provided and (2) which drivers out of the driver folders should used.

From my experience driver profiles should be created with matching rules that are as specific as possible because wrong driver profile rules may result in unnecessary traffic (drivers will be downloaded to devices which do not require them) and wasted disk space on the endpoint. Also you want to make sure that each device only get the drivers meant for this specific device. This is to prevent that untested/unwanted drivers may be installed on a device.

Most of the time I use a combination of the following rules:

  • Vendor (e.g. Hewlett-Packard)
  • Model (e.g. HP Compaq 8200 Elite)
  • Version / Part of the serial number (if you have the same hardware model in different revisions)
  • Operating system (e.g Win7 (x64))


As profile name I use a combination out of the values above, for example: HP Compaq 8200 Elite – Windows 7 x64.


Driver folders

Driver folders are more or less the same as a folder structure in your file system to sort and store your drivers. My personal preference is to set up the folders in the following format:

  • Vendor
    • Model
      • Operating System
        • audio
        • graphics
        • network
        • storage

If you use Mirage only for Windows migrations you can disregard the operating system folder as you are only using one OS. A productive structure may look something like this:


Of course the driver library is also deduplicated. So if you import a driver more than once it will not consume more space on the Mirage volume because of dedupe.


For Mirage you need “raw” device drivers with an inf and a cat file. Most of the times, if the customer does not provide some specific drivers, I rely on the the SCCM driver packs offered by the hardware vendors. Most vendors, including Dell, Lenovo and HP, offer ready to go driver packs. While these driver packs are designed to be used with SCCM/MDT they are in “raw” format and can also be used by Mirage.

Driver profile, driver folders and drivers combined

If you combine all three components the result is called the driver library.

Mirage driver library at work

The driver library is downloaded in almost all Mirage operations. To be specific:

  • Centralisation
  • Windows migration
  • Hardware migration and restore
  • Machine cleanup (Layer enforcement with remove user applications option set)
  • Base layer assignment, update and provisioning
  • Apply driver library

When a driver library download is triggered the drivers, which are dynamically matched using the driver profile, are downloaded to the endpoint to the following location: %windir%\WDL\Drv. This folder is also added to the DevicePath registry key (For more information see Configure Windows to Search Additional Folders for Device Drivers).

Now, when Mirage starts the plug and play driver detection (e.g. during a migration, base layer update, etc.) Windows first looks in the Windows driver store for suitable drivers. If no driver was found it looks for a suitable driver in the locations listed in the DevicePath registry key. In this case %windir%\WDL\Drv.

By the way, the “Apply driver library” option only triggers the download but no plug and play driver detection. Also every driver library download operation is optimised. If the drivers already downloaded they will not be downloaded again because Mirage’s deduplication functionality is used.

Prioritise drivers in the Mirage driver library

Sometimes, even if the correct drivers are available in the driver library, Windows does not detect/install the driver provided by the driver library and instead uses a basic Windows driver. This happens because for some drivers it is specified that the basic driver is sufficient and therefore after a driver is found in the Windows driver store no search will be done in the DevicePath locations.

Setting the following registry entry on your endpoint (or base layer) will enable driver search in both locations (Windows driver store and DevicePath) regardless if the driver configuration specifies that a basic driver out of the Windows driver store is sufficient.

What’s new in VMware Horizon Mirage 4.4 (Tech Edit)

Today VMware released version 4.4 of Horizon Mirage. Even if the official version is just a minor change there are major new features in this release.

In this article I try, like I did for ThinApp 5.0, to summarise and give an overview of all the new features included in version 4.4 from a technical point of view.

Windows 8 / 8.1 support for disaster recovery scenarios

First of all the installation of the Mirage client is now supported on Windows 8 and 8.1. While the full feature set, especially layer management and migrations, isn’t yet support the disaster recovery scenario is fully supported in Mirage 4.4. The disaster recovery scenario contains file/full system recovery and restore as well as self-service recovery using the Mirage file portal and client context menu. One thing important to know is that restore operations for Windows 8 devices can only be performed within the same operating system version, for example, Windows 8.0 to Windows 8.0 or Windows 8.1 to Windows 8.1. But using Mirage 4.4 you will be able to downgrade a Windows 8/8.1 device to Windows 7. This feature is more then welcome when you get new hardware preinstalled with Windows 8(.1) and want to deploy your corporate standard Windows 7 image using Mirage.

To support Windows 8 and Windows 8.1 Mirage now supports version 6.3 of the User State Migration Toolkit (USMT). Mirage now actually supports three versions of USMT:

  • USMT 4 or 5  for Windows XP to Windows 7 migrations and user data restores
  • USMT 6.3 for Windows 8 and 8.1 for user data restores


The import function also was enhanced to block the import of USMT 4.0 if it does not include the Office 2010 hotfix.

Mirage DMZ edge gateway

The ability to connect external / roaming users to Mirage without VPN was request from many clients. While Mirage always supported to work via VPN most users aren’t connect to VPN all the time. Therefore Mirage 4.4 introduces the Mirage gateway. The Mirage gateway is a hardend Windows service which normally will be deployed in a DMZ and is made available over the internet. This allows the Mirage client to securely connect (SSL is a requirement) to the internal Mirage infrastructure, tunnel through the Mirage gateway, if the machine is successfully authenticated. The authentication is done by the user itself when the Mirage client connects to the Edge gateway the first time. When the username and password is validated a is token created and stored for future authentications. It is possible to set a time-out for the token so a re-authentication, to make sure the device is still allowed to connect to Mirage, would be required. A Mirage edge gateway supports up to 1000 end points per server and multiple edge gateways can be deployed.

One thing to mention is that the Mirage gateway allows features like file restore, layer management and centralisation to work for distributed users. But operations which require the end point itself to communicate with the Active directory, for example full system restores of domain joined computer or Windows migrations, are not supported using the gateway because it only tunnels Mirage specific traffic and nothing more.

Support for updating Horizon View agents via Mirage (app) layers

Following the support of managing full clone persistent desktops in Mirage 4.3 the newest release of Mirage now supports updating Horizon View agents from version 5.3 to future releases. As you can see the integration of View and Mirage proceeds further and makes managing persistent desktops much easier. The ability to do Horizon View agents upgrade via Mirage application or base layers makes migrations to newer View releases much easier as all persistent desktops can update using as simple 2-step process.

  1. Create an updated app or base layer containing a future View agent release
  2. Deploy the layer to all clients and after a reboot the update is done

Additionally, no 3rd party tools are required to manage full clone persistent desktops.

Do Windows migrations without centralising the end point

In Mirage 4.3 the ability to do layer management only was introduced. This allowed you to deploy application and base layers to desktops without centralising them. This way you can do central image management for all your end points without using Mirage backup / disaster recovery functionalities. In Mirage 4.4 this function was enhanced to support Windows 7 migrations without the need to centralising the client first.

While you will lose the possibility to revert your desktop to your old Windows version in the case something goes wrong the storage requirements are much less. Therefore the most complex part (storage) of a Mirage infrastructure design is no longer needed. You just need a small amount of storage to hold your base and application layers, drivers and USMT.

Enhancements to the file portal and web management

The most prominent change to the Mirage file portal and the web management is the requirement of a SSL certificate. Access to both services is now only possible through a HTTPS connection. This decision was made to protect user (and admin) credentials and data accessed using both portals. So please make sure when you upgrade to version 4.4 to have a SSL certificate ready to use on your IIS hosting the file portal and web management.

The file portal was enhanced to allow users to allow multiple file portal at once.


The web management  got some minor face lifting and also a new mass centralisation functionality which allows you to centralise many clients at once by simply selecting them or applying a rule.  The mass centralisation functionality can be access by clicking the “pending devices” tile on the dashboard.


Better client identification

Last but not least in Mirage 4.4 the client identification was enhanced. In prior version of Mirage the client was identified by using the clients UUID and BIOS identifier. Unfortunately sometimes, when these value were not available or could not be read, Mirage misbehaved. To solve this issue all clients are now identified not only by the UUID and BIOS identifier but also using a attribute, an auto-generated GUID.

Release notes, documentation and download

Using the buttons below you find direct access to the VMware Horizon Mirage 4.4 release notes, the documentation and the download (requires a MyVMware account). With Mirage 4.4 also a nice new VMware Horizon Mirage Getting Started Guide (PDF direct link) is released.

I hope you enjoy this release as much as I do and if you have any comments or questions just leave them below.

Release NotesDocumentationDownload

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 partice 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.

Page 1 of 1412345...10...Last »