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.

ThinAppIE6onWin81

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.

Use blanks/spaces with the Horizon Mirage server command line interface (CLI)

Using the Wanova.Server.Cli.exe Mirage supports a vast amount of commands to automate different tasks.

My colleague Andreas Wilke (@automatecloud) over at wilkeplanet.de has created an article series covering all the commands and options available.

For some commands you may want or need to use spaces, i.e. for the description of a CVD collection.

But doing something like this

or this

will result in an error (“Error: invalid number of parameters.”) or something other you did not expect.

To use blanks when using the Wanova.Server.Cli.exe -c option you need to use a backslash (\) as escape character like this:

This does not only apply to the “addCollection” command but to any other command of the CLI you want to use spaces with.

How to disable the Horizon Mirage client upgrade balloon

When updating the Mirage server infrastructure to a newer version all Mirage clients are automatically updated the next time they connect to the upgraded Mirage server. During the client update the user gets notified that the client is being upgraded.

MirageAutoUpgrade

While this notification is somewhat non-disrupting sometimes it needs to be deactivated. Of course this is possible with only a minor change to the Mirage desktop service configuration file located here:

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

to

Most customers change this key while deploying the Mirage client using a post-install script. But what to do when Mirage is already up and running, the Mirage clients are deployed and you are planning an upgrade?

Thats even easier. You can centrally change this setting by updating your CVD policy. Here is how:

  1. Export your CVD policy using the Mirage management console
  2. Add the text outlined below inside the configuration tags
  3. Import your CVD policy using the Mirage management console
  4. Save the policy as new (minor) version
  5. Assign the updated CVD policy to all your clients

The following parameter has to be added inside the configuration tags:

Please be aware that this entry is case sensitive.

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

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.

 

Page 2 of 1512345...10...Last »