Search the VMware Knowledge Base (KB)
View by Article ID

Using VMware ThinApp packages with non-persistent Floating Pools in VMware Horizon View (2045513)

  • 8 Ratings


Non-persistent Floating Pools offer the most cost effective implementation of Virtual Desktop Infrastructure (VDI). However, the Windows operating system is not designed for a non-persistent scenario, therefore special consideration must be taken when designing your virtual desktop environment. Windows is designed for and works very well when one user has a single dedicated desktop. Traditional software deployment is also tied to the user's desktop. While you may entitle using user names/groups, at the end of the day the software is deployed to the user's desktop.

Using application visualization allows for true per user entitlement as the software is never installed onto the user's desktop. Users simply get access to an application shortcut, which can then be executed.

In a non-persistent deployment, users are presented with a new, clean desktop every time they log in. To preserve the user experience and the notion of a personal desktop, you must make use of roaming profiles. The roaming profile concept is also developed from the basis of a more or less static desktop assignment. If you move to a new desktop, all applications would have to be installed onto that new desktop, but the user will keep Internet Favorites, documents, and application settings.

Using ThinApp and thinreg.exe to register the applications allows for a very flexible and effective application entitlement design. The issue arises when used in a non-persistent environment. Special consideration must be given to both the Sandbox location and registration information, and how they are roamed with users. For example, by default Windows does not roam all file type registrations. In a traditional desktop environment, the application is deployed locally so there is no advantage to roaming this registration information.

This article provides the steps to take to support ThinApp in a non-persistent virtual desktop design.


The Sandbox

The location of the Sandbox can be customized in many different ways. You can specify SandboxPath= in the package.ini file or make use of an environment variable. If you place the Sandbox on a network share, it will no longer be managed by the roaming profile. The disadvantage of having the Sandbox on a network share is speed. In a worst case scenario, network performance is hit twice; once when the package is streamed to the user's desktop, and again if visualized content must be copied to the Sandbox. Therefore, the default location of the Sandbox is often used, which is the user's roaming profile (%AppData%).

If you store the Sandbox in the user's profile, you must implement some kind of roaming of the profile. For this you can use the built-in roaming profile functionality in Windows. The problem with this feature is that the whole profile is copied from a network location to the desktop on each login and back to the network on each logoff. This copying impacts your login and logoff time.

A more common approach is to implement a third-party roaming profile tool. While there are many vendors and solutions available, this article uses the tool included with Horizon View.

All roaming profile tools are intelligent enough to understand that the whole profile is not needed to log in and start using Windows. A roaming profile tool copies only what is requested to the local desktop when it is requested, and this greatly improves the login time. Many of these tools offer a background sync of the profile so updates are synced to the network while the users are using the operating system and therefore improving the logoff time as well.

ThinApp packages, however, work differently. A ThinApp package keeps a file system database in its virtual registry and stores modifications of this file database in the Sandbox. The application registry is accessed by the package immediately, but the files in the Sandbox might not be accessed by the package immediately, causing the roaming profile tool to ignore copying these files in the Sandbox. This can cause the Sandbox to be in a non-consistent state, and runs the risk of the package trying to access a file not in the local copy of the Sandbox. This can result in a corrupt Sandbox.

To work around this issue, ensure that all Sandboxes are pre-fetched by the roaming profile tool you use. This feature is supported by most tools, but may be named differently. The simplest method is to specify the whole %AppData%\Thinstall folder to be pre-fetched.

To specify the GPO to pre-fetch the Sandbox using View Persona Management:

VMware View Agent Configuration/Persona Management/Roaming & Synchronization

  • Folders to background download
  • Enabled
Specify folders that are downloaded in the background after user login.

Folders to download:
  • For Windows 7: AppData\Roaming\Thinstall

Keeping application registration

The most common method of registering ThinApp packages on a virtual desktop is by using thinreg.exe in the login script. The thinreg.exe tool is intelligent in that it will not re-register a package that is already registered on a machine by default. The thinreg.exe registration information is located in the roaming profile. If you now have a profile implemented in a non-persistent desktop environment using a roaming profile, thinreg.exe only registers entitlements once. Old entitlements already registered using thinreg.exe will appear to thinreg.exe as being already registered. This makes registration work when you initially log in to a virtual desktop, but the next time, when assigned a new desktop, only parts of the registration is actually present (the part stored in the roaming profile).

Most of the user's profile and what makes sense in a physical world to roam is stored in the user's %AppData% folder, typically C:\Users\vmware\AppData\Roaming (on Windows 7), and is therefore already covered by your roaming profile implementation.

However, the UsrClass.dat file(s), which is important for a more dynamic non-persistent environment, are not covered by the roaming profile implementation. The UsrClass.dat file contains the HKEY_CURRENT_USER\Software\Classes hive, and this stores file type extension registration and much more. This part of the registry is very important for the full functionality of an application being registered on a machine.

The solution for using thinreg.exe in a non-persistent virtual desktop environment is to ensure that the UsrClass.* files are roamed. To enable this roaming, use View Persona Management to configure your GPO.

To configure your GPO using View Persona Management:

VMware View Agent Configuration/Persona Management/Roaming & Synchronization

  • Files and folders excluded from roaming
  • Enabled
Specify folders that will not be roamed with the user's persona.

Files and folders:
  • AppData\Local
  • AppData\LocalLow

Files and folders excluded from roaming (exceptions)

  • Enabled
Specify folders that are exceptions to the list of folders included in the Files and folders excluded from roaming policy.

File and folder exceptions:
  • AppData\Local\Microsoft\Windows\UsrClass.dat
  • AppData\Local\Microsoft\Windows\UsrClass*.*
  • Roam local settings folders
  • Enabled

Additional Information

There are some other implementations using thinreg.exe. Using thinreg.exe /reregister forces a registration of already registered packages, however using /reregister is a very time consuming and has a negative impact on login time.

Request a Product Feature

To request a new product feature or to provide feedback on a VMware product, please visit the Request a Product Feature page.


  • 8 Ratings

Did this article help you?
This article resolved my issue.
This article did not resolve my issue.
This article helped but additional information was required to resolve my issue.

What can we do to improve this information? (4000 or fewer characters)

Please enter the Captcha code before clicking Submit.
  • 8 Ratings