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.

Mirage

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

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 Firefox\firefox.exe because it is integrated in the native file system and looks like a natively installed application which is located at C:\Program File\Mozilla Firefox\firefox.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.

ThinApp

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.

Upgrading VMware Mirage 4.x to 5.0

As VMware Mirage 5.0 is now available many want to upgrade to the latest version. While the way of doing an upgrade from 4.x to 5.0 has not change it will change with 5.0 going forward.

Up to version 5.0 you need to uninstall old versions of the Mirage server components first and then install the new ones. This needs to be done in a specific order:

  1. Uninstall all Mirage servers
  2. Uninstall Mirage management server
  3. Uninstall additional components (Mirage management console, WebAccess and WebManagement)

After everything is uninstalled the components need do be installed as follows:

  1. Install Mirage management server
  2. Install Mirage servers
  3. Install additional components

It is most important to (un)install the Mirage management server and Mirage server in the right order. The remaining components can be (un)installed in no particular order. For more information about upgrading Mirage have a look at the following article: Best practices for upgrading VMware Horizon Mirage.

For future upgrades, for example, from Mirage 5.0 to Mirage 5.next it will not be required to uninstall the Mirage server components first. You will be able to just run the MSI of the new Mirage version and it will automatically detect all existing settings (like database configuration, service account used, cache and storage location) and then do the upgrade.

From a technical point of view the upgrade from 4.4.x to 5.0 could also be done using this new mechanism. But because some advanced error handling needed to be implemented in the Mirage server software, which was implemented with Mirage 5.0 and is not available in prior versions of Mirage, it is not supported and therefore not recommended to use this upgrade method when upgrading from 4.4.x to 5.0. The traditional way via the (un)install upgrade method must be used.

Post-scripts in VMware Mirage

For many operations VMware Mirage allows to run so-called post-scripts.
Post-script are scripts that run on the endpoint after one of the following operations is completed:

  • Windows migration
  • Base layer provisioning
  • Base layer assignment
  • App layer deployment

A post-script allows you to run scripts and programs and do customisations.

Practical use cases are:

  • Delete the Windows.old directory after a Windows migration
  • Customise configuration files based on computer name
  • Install OEM software based on the specific hardware type
  • Deploy applications that are not yet compatible with app layers
  • and many more

All post-scripts are located under %ProgramData%\Wanova\Mirage Service and need to be included in the base layer respectively in the app layer in case of the post-app layer deployment script.
Below you find an overview of the different script names that are used.

Script file name
Execution time
post_migration.batPost-Windows migration
post_provisioning.batPost-Base Layer Provisioning
post_core_update.batPost-Base Layer Assignment
post_layer_update_*.batPost-App Layer Deployment

By default the post_migration.bat and a file called post_bi_update.bat are located inside the %ProgramData%\Wanova\Mirage Service directory. While you can freely modify the post_migration.bat to execute programs and scripts after a Windows migration it is highly recommended not modify the post_bi_update.bat script. The post_bi_update.bat script is more or less just a wrapper for the post_provisioning.bat and post_core_update.bat.

So, if you want to run scripts after a base layer provisioning or assignment you first have you create the corresponding script (post_provisioning.bat or post_core_update.bat) inside the %ProgramData%\Wanova\Mirage Service directory. Those two script are call by the post_bi_update.bat so there is no need to modify this file directly.

Inside the scripts you can basically do whatever you want you just have to be aware of the following:

  1. The scripts and therefore everything you do inside the scripts are executed in the context of the system account
  2. Make sure your script returns a proper error code. Return a zero (0) if the script execution is successful. Everything else is interpreted as an error and logged as such in the Mirage event log.
  3. By default there is a 300 second (5 minute) time out for post-scripts. If the script isn’t finished during this timeframe Mirage will no longer wait for the script and proceed.

MiragePostScriptErrorMiragePostScriptTimeout
The screenshots above showing a post-script error and time out message in the Mirage event log.

While most scripts are placed inside the base layer the post-app layer deployment script needs to be included in an app layer. During the app layer recording process create a file called post_layer_update_*.bat in the folder %ProgramData%\Wanova\Mirage Service. Of course you need to replace the asterisk (*) with a unique name. You have to make sure that each app layer has a unique script name.

Example: post_layer_update_firefox22_0485345.bat

Unfortunately troubleshooting post-scripts can be bit cumbersome as you have no chance to see the script execution interactively. Therefore it is recommended to implement logging functionalities in your script so that each step is recorded in a log file. A perfect location for log files created by post-layer scripts is the Mirage service log directory located at %Program Files%\Wanova\Mirage Service\Logs. Just make sure you choose a unique log file name.

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))

driverlibrary4

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

driverlibrary3

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:

driverlibrary1

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.

Drivers

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

Mirage44USMT

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.

Mirage44FilePortalMultiSelect

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.

Mirage44WebMgmtMassCentralization

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

Page 1 of 1512345...10...Last »