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

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.

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.

What’s new in VMware ThinApp 5.0 (Tech Edit)

Today VMware made ThinApp 5.0 generally available. While there is a lot of information out there on what’s new spread across multiple announcements, release notes and blogs I want to summarize the most critical information on what’s new in VMware ThinApp 5.0 from a technical point of view.

End-of-availability canceled

Even if this isn’t a technical point it is still pretty important to know. With the announcement of the VMware Horizon Suite it was also announced that after December 15th, 2013 ThinApp would not be available as standalone product anymore. Shortly after this announcement was made is was pretty clear that our customers where not amused and VMware clearly had underestimated on how many customer count on ThinApp – one of the leading application virtualization products – as a standalone product.

Therefore with the announcement of ThinApp 5.0 VMware also announced that the end-of-availability is canceled. This means VMware will continue to offer ThinApp as a standalone product and you will be able to get at least five more years of service and support for ThinApp.

Re-architecture

In version 5.0 much was changed on the internal plumbing of ThinApp. From a very technical point of view VMware is moving away from import address table hooking of Win32 API to inline hooking of the Windows Native API (NTDLL.dll). As you can see in the figure below this hooking takes place in a much earlier stage and therefore increases the overall application compatibility.

Image source: http://technet.microsoft.com/en-us/library/cc768129.aspx
Image source: http://technet.microsoft.com/en-us/library/cc768129.aspx

Also it greatly reduces the number of hooked API. Because instead of hooking all the high-level Win32 API functions ThinApp now hooks low-level functions of the Windows Native API, which are also used internally by all the Win32 API functions.

The following screenshots are showing the DLLs used by a virtualized instance of Notepad++. As you can see there are a lot more DLLs in play with ThinApp 4.7.3 as  there are with ThinApp 5.0.

HookedDLLsThinApp

All in all the number of of hooked APIs are reduced from about 600 to 200. Which results in a much smaller code base of ThinApp 5.0 and therefore decreases the number of potential bugs. Also, as already mentioned, it should boost the already very good application compatibility of ThinApp to a new level.

64-bit support

ThinApp always supported 64-bit operating systems and was always able to run virtualized 32-bit applications on top of Windows 64-bit versions. But with ThinApp 5.0 finally the virtualization of 64-bit applications is  possible. This was one of the most requested feature by our customers.

The ability to virtualize 64-bit applications opens up many new use cases, i.e. the virtualization of 64-bit version of Office and Internet Explorer but also the virtualization extensive CAD/CAM applications.

The following tables shows the supported capture and deployment scenarios of ThinApp 5.0.

As you can see ThinApp supports pretty much every available scenario with the exception of the following two:

  1. ThinApp 5.0 does support capturing 32-bit applications on top of 64-bit operating systems but only if you build and deploy it to 64-bit machines only. If you want to run a 32-bit package on top of 32 and 64-bit operating systems you need to create the package on top of a 32-bit operating system.
  2. ThinApp still supports the virtualization of 16-bit applications on top of 32-bit operating systems but does not and never will support 16-bit applications on top of Windows 64-bit. You can blame – or in my opinion thank – Microsoft for that. See 64-bit versions of Windows do not support 16-bit components, 16-bit processes, or 16-bit applications

VMware supports the following operating systems for running virtualized 64-bit applications:

  • Windows 7 64-bit
  • Windows Server 2008 R2
  • Windows 8 64-bit
  • Windows Server 2012
  • Windows 8.1 64bit
  • Windows Server 2012 R2

Not supported are:

  • Windows XP 64-bit
  • Windows Server 2003 64-bit
  • Windows Vista 64-bit
  • Windows Server 2008 64-bit

ThinApp 5.0 of course still support these platforms for running virtualized 32-bit applications on top of them. And of course all other 32-bit platforms (like Windows XP, Vista, 7 and so on) are still supported.

Office 2013 and Internet Explorer 10 support

With ThinApp 5.0 you can virtualize the latest Microsoft applications like Office 2013 and Internet Explorer 10. While Office 2010 was a pain to virtualize in prior version of ThinApp, ThinApp 5.0 includes many fixes to make packaging much more reliable. Also VMware provides official packaging guidelines for Office 2010 (See KB 1022287) and 2013 (See KB 2062691).

Unfortunately support for both products is limited at the moment. While virtualizing Internet Explorer 10 with ThinApp 5.0 is supported up to Windows 8 (but not 8.1), virtualizing Office 2013 is only supported up to Windows 7 (but not Windows 8 / 8.1).

This is likely to change within a future version of ThinApp.

Compatibility

One big advantage of ThinApp’s agent- and client-less architecture is that you are able to run multiple versions of the ThinApp runtime at the same time. Therefore integrating a new version of ThinApp is easy as pie. Still there are some things to consider when bringing ThinApp packages in version 5.0 in to an existing ThinApp environment.

AppLink: with ThinApp 5.0 we support linking ThinApp 5.0 packages with ThinApp 4.5 (and later) packages. There is only one gotcha: The parent package always has to be packaged with ThinApp 5.0. So if you for example have Mozilla Firefox virtualized and several AppLink packages like Flash and Java connected you first have to update the Mozilla Firefox package to ThinApp 5.0 in order to update any linked package (Flash or Java) to ThinApp version 5.0.

In-place update: With ThinApp it was always possible to update current ThinApp packages to a newer version of the runtime or the application it self by copying the new package side-by-side with the old package and adding integer at the end of the package.

For example: If the user is currently using Notepad++ 6.0 as a ThinApp package called Notepad++.exe and you want to deploy Notepad++ 6.5. Just copy the new ThinApp package as Notepad++.exe.1 side-by-side to the original Notepad++.exe ThinApp package and as soon as the user launches or relaunches (yes, you can do this while the user is using the application) he will get the new Notepad++ 6.5 package.

When doing an in-place update to a 5.0 package that contains the new .alt file this file should be named as *.n.alt where n is the integer you choose for the base .dat or .exe file. In this case it would be Notepad++.exe.1.alt.

AppSync: Of course you can also update your applications using the AppSync mechanism but only 32-bit packages. Also see the following article: When you perform Appsync from 4.7.2 to 4.7.3. AppSync displays the following error message “The operating system cannot run”.

MSI: Updating ThinApp packages from prior versions of ThinApp to version 5.0 is done the normal way. (See Upgrade a deployed ThinApp package with the help of MSI) There are no special considerations necessary.

Sandbox: It it worth mentioning that the sandbox (if the sandbox names are identical) will be reused during an upgrade. So if you updating your packages to ThinApp 5.0 all application settings are available after the update. Please keep in mind that updating to a newer version of an application or even a different application bitness (32-bit vs. 64-bit) may result in loss of the application settings as they are probably  saved in a different location in the registry. In this scenario it would be advisable to use a new sandbox and not to reuse the existing sandbox.

ThinDirect enhancements

ThinDirect in ThinApp 5.0 was update to support newer browsers like Internet Explorer 10 and also 64-bit versions of Internet Explorer.

Also the ThinDirect policies – that controls which URL should be opened in which virtual browser – are now available as ADMX template.

Updated SDK

The ThinApp SDK was also updated with version 5.0. It now includes a separate 64-bit DLL (ThinAppSDK64.dll) and therefore eliminates the need of the ThinAppSDKSrv.exe on 64-bit operating systems.

You can use the new SDK and all your scripts/programs without any change with existing ThinApp packages prior version 5.0. If you want to enable your scripts/programs to support ThinApp 5.0 packages you actually have to change them.

Have a look at the release notes to get more details on this particular point.

VMware Horizon View and Workspace integration

ThinApp is an integral part of VMware Horizon View, Workspace and Mirage. While you can start using ThinApp 5.0 in your Mirage deployments right away as there is no direct link between Mirage and ThinApp you have to be aware of some limitations when it comes to the View and Workspace integration.

The current releases of Horizon View will support ThinApp 5.0 32-bit packages out of the box. Support for 64-bit ThinApp 5.0 packages will be introduced in future version of Horizon View. Horizon Workspace 1.5 does not support ThinApp 5.0, neither 32-bit nor 64-bit.

In regards to Horizon View you of course have always the possibility to use ThinReg or the SDK to register ThinApp 5.0 64-bit packages using a logon script or deploy them via MSI. This is fully supported and this way you can enjoy 64-bit ThinApps from day one.

For more information see the official knowledge base article: Horizon View and Horizon Workspace support for ThinApp 5.0 applications

AppSense Environment Manager integration

While it was always possible to manage the personality of a ThinApp package using Environment Manager from AppSense by copying the sandbox at logon and logoff. With VMware ThinApp 5.0 the Environment Manager from AppSense can actually look into the sandbox and therefore do all the amazing cross-application personalization stuff. So you can for example configure your local Office 2010 on your laptop and when you connect to your virtual VMware View desktop you have the same settings in your Office 2010 ThinApp package.

More information on the integration can be found in the following blog post by AppSense: AppSense Environment Manager Integrates with VMware ThinApp 5.0

As you can ThinApp 5.0 contains many major improvements and new features. I hope you will enjoy working with ThinApp 5.0 as much as I do.

Release Notes | Documentation | Download

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.

AppLayerPackageIniMSI

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.

AppLayerThinAppPackage

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.

Summary

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.

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:

OldLayers

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)