In ThinApp 5.0 some major changes we’re incorporated and therefore broke the interoperability with Horizon View 5.2 and Horizon Workspace 1.5.
Officially only the following scenarios are supported and do work:
- Horizon View up to 5.2: Only 32-bit ThinApp 5.0 packages are supported
- Horizon View 5.3 and later: ThinApp 5.0 is fully supported (32-bit and 64-bit packages)
- Horizon Workspace 1.5: ThinApp 5.0 is not supported at all, wether 32-bit nor 64-bit packages.
Unfortunately there is a bug in the knowledge base article which states that ThinApp 5.0 is, at least for 32-bit packages, supported in Horizon Workspace 1.5. This however is not true and will technically not work. If you want to use ThinApp with Horizon Workspace please use the version 4.7.3 of ThinApp.
Update (29/11/2014): The knowledge base article was updated and now states the correct and supported scenarios.
Source: Horizon View and Horizon Workspace support for ThinApp 5.0 applications
With Horizon Mirage 4.3 some new advanced options inside of the CVD policies were introduced.
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.
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.
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
VMware today announced Horizon Suite as well as three new products called Horizon Workspace, Horizon Mirage and Horizon View.
As you probably noticed two of these four products aren’t actual new. VMware View and VMware Mirage are still the same products, but updated and rebranded to match the new Horizon umbrella.
VMware Horizon View 5.2 contains many new cool features like clientless HTML 5 access, hardware accelerated 3D graphics and Windows 8 support. Andre Leibovici (@andreleibovici) wrote a very good article about what’s new in VMware Horizon View 5.2. VMware Horizon Mirage 4.0 biggest new feature is the support for application layering. This allows you to deploy applications and ThinApp packages using Mirages new app layering technique.
VMware Horizon Workspace is a brand new product enabling IT departements to deliver secure and policy-driven data and applications to any device. Last but not least, Horizon Suite is a new product bundle which combines View, Mirage and Workspace. To get more information about the Horizon Suite and Workspace I suggest another great article by Andre: Introduction to the new VMware Horizon Suite.
With all the excitement about this product launch you may still have noticed that ThinApp is gone from the product listing. Don’t panic, ThinApp is still alive and kicking but there are some changes.
Unfortunately ThinApp will not be available as a standalone product anymore. ThinApp is now bundled with the Horizon product line. No matter if you buy Horizon Mirage, View, Workspace or the whole Suite you will always get ThinApp. ThinApp will be integrated in each of this products, so that you can see and use it as a product feature now.
To make a long story short: ThinApp transformed from being a standalone product to being an integral part of the Horizon product family. In my opinion that is a good thing. ThinApp will gain a lot of traction being an integral part of Horizon and also it will gain additional functionality. For example reporting and auditing when combined with Horizon Workspace or a completely new deployment method using Mirages app layers.
To be clear you can still use ThinApp in standalone mode. There is no need to deploy Horizon Workspace, View or Mirage to use ThinApp, but to license ThinApp in the future you have to buy one of the Horizon products. If you still want to buy ThinApp as a standalone product the ThinApp standalone licenses are still available to buy until the end of 2013. After that ThinApp will only be available as part of the Horzion product family. You can read more about the end of availability announcement of VMware ThinApp as a standalone product in the following FAQ: VMware ThinApp Client & Suite End of Availability and End of Support Lifecycle FAQs (direct link to PDF).
Ps: The ThinApp product page is still available.