Streamed Thinapping with Group Policy Preferences

Hi, I have taken over a customers case who have been using streamed thinapping with group policy preferences. They are running View 6.0.1 I had assumed they would be running thin apps through View (from talking to one of their managers) but they don't have the licence for that right now

My question is I am looking for best way to implement troubleshooting as their performance is mixed , (they have no end to endpoint network monitoring software) I would ideally like to get to them up to the higher View licence and use thinapp from their or instead use App Volumes,

Who is Participating?
This depends upon what the issues are and what products they are related to.

If it is specific to ThinApp packages, here are some best practices around ThinApp.

I'd suggest the following:

1. Make sure your capture VM is clean (I would recommend it be XP Pro SP3 and the VM tools).  NO Updates, NO Hotfixes, NO IE7 or IE8, NO .NET Framework, No AV, No Firewall - Nothing Else.

2. Prior to capturing, run the application and it's components and ensure they all get registered correctly.  Also, if any DLL's need to be registered manually, do this prior to conducting the post-installation snapshot.

3. Try setting the ThinApp Project to WRITECOPY as the default file system isolation mode.   Also try setting the entire project to MERGED (all folders).  An easy way to do this is grab Bob Carter’s “ThinApp Folder ISO Viewer” ( and use the “SET ALL MERGED” button.  NOTE:  This can be restored by using the “RESTORE ALL ISO MODES” button.

4. Add a "%%TEMP%" folder into your package and set isolation on that folder to WRITECOPY. Remove this if it doesn't fix issue.

5. Check the ThinApp blogs on additional system files that are commonly present in Windows and don't always get captured (because of the VM not being "clean").  Also see the App Troubleshooting blog entry.

6.  When capturing items for AppLink, it is recommended to first capture the entire app and all of it’s needed subcomponents together into one ThinApp package to ensure it works correctly.

7. If the above things do not do the trick, then use PROCMON and PROCEXP from to review what other items the packaged app is looking for.  I personally use PROCEXP to watch the native process fire up to learn how it’s startup process works.  Then I visually compare that to the ThinApp’ed version on the same system.

Some things to note about testing:

1.  Each time you test the application, ensure you are testing it on a clean system.

2.  Delete the sandbox between tests as leaving the sandbox can give false test results.

3.  Copy the packaged exe to the local system and run it to eliminate network overhead and any drive dependency issues the app may have.

4.  Next, you should run a "washed" test. That is, start removing the local components one at a time and re-test. At some point, the application should fail based on your production test scenario. However, if the the application doesn't fail, then run a "clean" test with the reverted snapshot of the CnB workstation. If the application passes that, then the issue is most likely an environmental one and thus you should consider those items associated it. As an example, I often name the CnB "localhost" so that any application that tries to pick the workstation name for the registry or some configuration would pick that name which can resolve to any local workstation.

Testing Procedure

*   Dirty Test
   *   A dirty test is one that is conducted on the CnB with the application still locally installed. Any issues arising from this test will most likely be code related and will present obvious issues right away.
*   Washed Test
   *   Simply use Add/Remove Programs to uninstall the application from the CnB. Then run the ThinApp to test. If any issues occur here, the likelihood that they are related to missing components or settings is very high.
*   Clean Test
   *   Revert your CnB back to a clean state and test your ThinApp. This test builds upon the ides of the washed test and will also provide insight to any potential issues that may result from files and setting that are not removed during an uninstall procedure.
*   Production Test
   *   Using your ThinApp, test in a live production workstation. Local policy, security applications and other items may cause issues. This test will allow you to determine if problems are environmental in nature.

5.  At this point you may also wish to use Log Monitor - but even I don't like using it as it was written by developers for developers.  If you do, look through the MODULES LOADED to see where EXEs/DLLs are being loaded (Memory Mapped Anon means loaded by ThinApp) and POTENTIAL ERRORS sections and also keep an eye out throughout the logs for any DLLs it is loading externally which you think might need to be loaded internally.  Note the POTENTIAL ERRORS section will have numerous superfluous artifacts which would be present even if the app is working correctly.

The ThinApp Blogs are a great reference here (  You may wish to peruse the Troubleshooting section (

Hope this helps.  Please post back if you need further details.

-Dean F.
If you are experiencing slowness over the network when launching ThinApp packages from a network are some things to consider

First off, slowness from a network share is almost assuredly an environmental issue.  Usually slowness issues are because the ThinApp package is being subject to not only the network traffic but, more importantly, the Windows Network Stack and SMB overhead when accessing over a drive/share over the network.  View (or other similar technologies) will eliminate some of this as the desktop presumably would be running logically next to the file share where the ThinApp packages exist.

Some common things to check are:
Logical path / # hops between file share and desktop.  There is no recommended max here as it is really very environment dependent (30 hops on a 10Gb network might actually be quicker than 3 hops on a 10Mb network).

What’s the share sitting on?  ThinApp packages can sit on any SMB/CIFS share accessible by Windows – but make sure the hardware can support file services at the level you need it to.  Think of ThinApp packages like a 16-bit flat-file database to some extent as there’s going to be a higher demand for files at certain times (shift worker-like).

Is that server busy doing other things which tasked at a higher priority?  ThinApp’s have no problem running from slower systems, but making the user wait is not a good perception for any I.T. Person.  This might mean selecting a server which has a lesser load to be used – or setting up a DFS with some sort of existing replication so people don’t all hit one specific server.

How is the share configured?  Make sure that system’s share (SMB/CIFS/NTFS) settings are not too limiting to users.  Typically users only need read permissions and NOT write permissions to run ThinApp packaged apps. However, on a NetApp or other CIFS share, remember, READ permissions do not equal EXECUTE permissions as they do in Windows (or SMB shares).  This means the users executing ThinApp packages from a CIFS share will need EXECUTE permissions as well.  This specifically is not a "slowness" issue per se since the user with too restrictive of permissions will just not be able to launch the ThinApp...but it does point to how permissions can negatively affect a ThinApp packaged application.

Where is the sandbox located?  While the ThinApp package can be located on a READ ONLY network location, the Sandbox must be in a location where the user has WRITE permissions.  Additionally, sticking the sandbox locally can help with speed of the ThinApp package if the app does a lot of writing to the sandbox (temp files, DB, etc.) as the reading/writing speed for the sandbox is also affected by the environment it sits within.  So if the sandbox is on a network location (i.e. Home Drive, Roaming Profile, etc.) then it is also affected by the network traffic, Windows Network stack and SMB overheads.

Is that server’s AV scanning access to that folder?  If On-Demand AV scanning is enabled, this could severely reduce performance of a ThinApp package.  For ThinApp packages on a share, typically we see customers disabling On-Demand scanning for that shared folder and setting up a scheduled, off-hours, AV scan to ensure the folder remains clean.  Additionally, most of these customers also ensure users only have READ access to the share.

When placing a ThinApp package and/or a packaged app’s sandbox on a network location, think back to the old days of installing Office 95 to a network share (as we didn’t have but 30MB drives and Office 95 was often too big for this).  In those cases, Office 95 didn’t run as well as it did when installed completely locally as it had to cross the network to get to the bits it needed to run.
These are the common best practices for ThinApp.  For additional details and support, see documentation on or blog postings at
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.