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.

CVDTotalSize

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.

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

Download: https://my.vmware.com/web/vmware/details?downloadGroup=MIRAGE-430-TOOLS&productId=322

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.

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.

AdvancedOptionsCVDPolicy

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.

MirageHorzionViewconoperations

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:

Wanova.Desktop.Service.exe

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:

C:\ProgramData\Wanova\Mirage\LocalCache

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.

MirageServerCache

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:

Wanova.Server.Service.exe

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

Wanova.Management.Service.exe

Summary

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.

Release: VMware Horizon Mirage 4.3

Today VMware released the new version 4.3 of Horizon Mirage.

This release includes major improvements of the interoperability between Horizon Mirage and View and therefore officially supports image management of full clone virtual desktops.

The new release includes:

  • Support for image management of VMware Horizon View full clone desktops
  • Ability to do image management only (without the need to centralizing an endpoint first)
  • Ability to deploy app layers during a Windows 7 migration process
  • A bunch of tools for synchronizing (export and import) layers, CVDs and the driver library between different Mirage server clusters
  • Enhancements to the Mirage volume for better exclusion support in regards to Anti-virus solutions
  • A new web-based console with support for the Protection Manager role, which allows you to do all the tasks needed for protecting and synchronizing your endpoints.

Also there are many bug fixes included in this release.

Because covering each new features would blow up this article so much I decided to cover each feature in a separate article over the next few weeks.

Release Notes | Documentation | Download

Migrate ThinApp sandboxes with USMT in Horizon Mirage

In one of my last articles I showed how it is possible to extend the User State Migration Tool (USMT) which is used inside of Horizon Mirage. While I showed the steps on how to get a custom XML file recognized and used by Mirage I left all the heavy lifting of creating the custom XML files to you.

As many of our customers are using ThinApp and USMT as well as Mirage don’t support the migration of ThinApp user and application settings out of the box I though I published the XML file to get this done below. Luckily ThinApp saves all settings on a per-user per-application basis in a central location. By default this location is %AppData%Thinstall. Additionally ThinApp sandboxes are as portable at the ThinApp packages itself and therefore can be easily transferred between different systems.

The following XML file is telling Mirage respectively USMT to include this directory during the migration process.

<migration urlid="http://www.microsoft.com/migration/externalUserDocs">
<!-- This component migrates ThinApp sandboxes -->
<component type="Documents" context="User">
<displayName>ThinApp Sandboxes</displayName>
<role role="Data">
<rules context="User">
<include>
<objectSet>
<pattern type="File">%CSIDL_APPDATA%Thinstall* [*]</pattern>
</objectSet>
</include>
</rules>
</role>
</component>
</migration>

Just save this file as ThinApp.xml inside your USMT x86 and x64 folder and customize the Launch_USMT.cmd to add it to the Mirage USMT process. How this can be done is outlined in my article called: How to customize USMT in Horizon Mirage.

How to customize USMT in Horizon Mirage

When doing a Windows 7 migration using Horizon Mirage the User State Migration Tool from Microsoft is used to migrate user settings and data as well as operating system settings.

USMT by itself already supports a lot of settings and additionally Mirage adds support for even more settings which are automatically migrated. Have a look at my previous article to get to know about the settings which are migrated out of the box.

Still in most cases USMT inside Mirage needs to be modified as additional application, user or operating system settings and data need to be transferred during the migration. For example you may want to migrate Google Chrome, Mozilla Firefox or SAP GUI settings.

Extending USMT is just a matter of creating additional XML files which contain the information on what additional settings should be migrated. This can be done manually by following the USMT user guide custom XML examples or using a nice tool called USMT XML Builder GUI.

After the XML file with the needed settings is created (in my example it is called ThinApp.xml) it needs to be copied into the USMT x86 and x64 folder. To get these folders you have to download USMT and update it. I covered how this can be done in my prevoius article on how to import USMT into Mirage.

USMTXMLFile

When the USMT folder is prepared an the custom XML files are added we need to customize the USMT script inside Mirage. During the USMT stage Mirage launches a script called “Launch_USMT.cmd” which is located in the Mirage Client folder under ” C:Program FilesWanovaMirage Service”. This file needs to be copied to the root of the USMT folder.

USMTRoot

After this is done the script needs to be adjusted to include the newly created custom XML file. For this just open the “Launch_USMT.cmd” in a text editor of your choice and modify the variable USMT_MIG_XML to include the custom XML file.

LaunchUSMTCmd

For each new XML file the following parameter needs to be appended to the variable:

/i:%USMT_LOCATION%CustomXMLFile.xml

Of course you have to change the name of the XML to the appropriate one. After you changed the variable it should be look similar to following example:

Before:

set USMT_MIG_XML=/i:%USMT_LOCATION%MigApp.xml /i:%USMT_LOCATION%MigDocs.xml /i:%WallpaperFile_XML_PATH% /i:%KeyboardLayout_XML_PATH% /i:%MigRegionalSettings_XML_PATH% /i:%DefaultPrinter_XML_PATH% /i:%Win7CustomSettings_XML_PATH%

After:

set USMT_MIG_XML=/i:%USMT_LOCATION%MigApp.xml /i:%USMT_LOCATION%MigDocs.xml /i:%WallpaperFile_XML_PATH% /i:%KeyboardLayout_XML_PATH% /i:%MigRegionalSettings_XML_PATH% /i:%DefaultPrinter_XML_PATH% /i:%Win7CustomSettings_XML_PATH% /i:%USMT_LOCATION%ThinApp.xml

After the variable is changed and the updated script is saved the USMT folder needs to be imported to Mirage again.

MirageUSMTCommit

From now on the customized USMT is used for any migration task.

What does Horizon Mirage migrate with USMT?

VMware Horizon Mirage is often used for migration scenarios. Besides hardware migrations Mirage also supports the migration from one Windows version to another. To be more specific Mirage supports the migration from Windows XP to Windows 7 and Windows Vista to Windows 7.

During the migration process Mirage uses the Microsoft User State Migration Tool (USMT) to migrate operating system settings and user data from the old Windows version to Windows 7.

By default the following data is migrated (Source: What Does USMT Migrate?):

  • Folders from each user profile. My Documents, My Video, My Music, My Pictures, desktop files, Start menu, Quick Launch settings, and Favorites.
  • Folders from the All Users and Public profiles. Shared Documents, Shared Video, Shared Music, Shared desktop files, Shared Pictures, Shared Start menu, and Shared Favorites.
  • File types. .accdb, .ch3, .csv, .dif, .doc*, .dot*, .dqy, .iqy, .mcw, .mdb*, .mpp, .one*, .oqy, .or6, .pot*, .ppa, .pps*, .ppt*, .pre, .pst, .pub, .qdf, .qel, .qph, .qsd, .rqy, .rtf, .scd, .sh3, .slk, .txt, .vl*, .vsd, .wk*, .wpd, .wps, .wq1, .wri, .xl*, .xla, .xlb, .xls*.
  • Access control lists.

USMT also migrates a whole bunch of operating system settings. Mirage uses the offline migration feature of USMT to migrate the user and operating system settings from the Windows.old directory to the new Windows 7 installation. Because Mirage uses offline migration by default only the following settings are migrated:

  • Accessibility settings
  • Address book
  • Command-prompt settings
  • EFS files
  • Favorites
  • Folder options
  • Fonts
  • Group membership
  • Microsoft® Open Database Connectivity (ODBC) settings
  • Mouse and keyboard settings
  • Network drive mapping
  • RAS connection and phone book (.pbk) files
  • Remote Access
  • Windows Mail. Microsoft Outlook® Express Mail (.dbx) files are migrated from Windows XP.
  • Windows Rights Management

Because some major settings are missing when using the default settings in offline migration mode Mirage adds additional functionalities to USMT to migrate the following settings:

  • Keyboard layout
  • Regional settings
  • OS language
  • Network printers (behind network share) + network drives
  • Raw network printers
  • Default printer
  • Time zone
  • Static IP settings
  • Wallpaper
  • Internet Explorer start page
  • Explorer and Taskbar options

Last but not least USMT supports the migration of several application settings. Most of them are only supported in specific (and often very old) versions. One major application suite which is supported is Microsoft Office of course. USMT supports Office 2003 to 2010 and also supports the migration from one Office version (e.g. Office 2003) to another (e.g. Office 2010).

For more information about USMT and which applications are supported have a look at the following article: What Does USMT Migrate?

Because USMT is very flexible it is possible to add additional applications and operating system settings to it. More information about USMT can be found in the User State Migration Tool 4.0 User’s Guide

Add USMT to Horizon Mirage

While adding the User State Migration Tool (USMT) to Horizon Mirage is a pretty straight forward task it isn’t documented in any way.

Update: Since version 4.3 the method to import USMT into Mirage is now covered by the official documentation. If you like a more detailed description with pictures this article is still worth reading.

First of all Mirage in the current version (4.x) only supports USMT version 4.0. To get this USMT version you first have to download the Windows Automated Installation Kit for Windows 7 (WAIK) from Microsoft. This download may take a while as the complete kit is around 2 gigs.

After WAIK is downloaded you have to install it. After the installation you will find the USMT sources under C:Program FilesWindows AIKToolsUSMT.

USMTFolder

Unfortunately the version of USMT 4.0 which is included in WAIK doesn’t support Office 2010. If you need Office 2010 support you have to download the USMT 4.0 update.

After this is done you have to place the files contained in the update inside the USMT folder and replace the files loadstate.exe, migapp.xml, migcore.dll and scanstate.exe in the x86 respectively in the x64 folder.

USMTUpdate

After you have merged the update to the USMT folder it is time to import USMT using the Mirage management console.

USMTImport

 

After the import Mirage now automatically migrates settings and files when doing a Windows XP/Vista to Windows 7 migration.