Solved

Streamed Thinapping with Group Policy Preferences

Posted on 2016-11-06
3
19 Views
Last Modified: 2016-11-27
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,

Thanks
0
Comment
Question by:Indie101
  • 3
3 Comments
 
LVL 4

Accepted Solution

by:
Squidly_Man earned 500 total points (awarded by participants)
ID: 41879329
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” (http://www.screencast.com/t/ODU2YWNlZWEt) 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.
http://blogs.vmware.com/thinapp/2009/03/common-system32-dlls.html
http://blogs.vmware.com/thinapp/2009/05/app-troubleshooting.html

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 www.sysinternals.com 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 (http://blogs.vmware.com/thinapp).  You may wish to peruse the Troubleshooting section (http://blogs.vmware.com/thinapp/troubleshooting).


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

-Dean F.
1
 
LVL 4

Assisted Solution

by:Squidly_Man
Squidly_Man earned 500 total points (awarded by participants)
ID: 41879350
If you are experiencing slowness over the network when launching ThinApp packages from a network share....here 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.
1
 
LVL 4

Expert Comment

by:Squidly_Man
ID: 41902955
These are the common best practices for ThinApp.  For additional details and support, see documentation on vmware.com/thinapp or blog postings at blogs.vmware.com/thinapp
0

Featured Post

Complete VMware vSphere® ESX(i) & Hyper-V Backup

Capture your entire system, including the host, with patented disk imaging integrated with VMware VADP / Microsoft VSS and RCT. RTOs is as low as 15 seconds with Acronis Active Restore™. You can enjoy unlimited P2V/V2V migrations from any source (even from a different hypervisor)

Join & Write a Comment

This is an issue that we can get adding / removing permissions in the vCSA 6.0. We can also have issues searching for users / groups in the AD (using your identify sources). This is how one of the ways to handle this issues and fix it.
Last article we focus in how to VMware: How to create and use VMs TAGs – Part 1 so before follow this article and perform the next tasks, you should read the first article how to create the TAG before using them in Veeam Backup Jobs.
Teach the user how to use vSphere Update Manager to update the VMware Tools and virtual machine hardware version Open vSphere Client: Review manual processes for updating VMware Tools and virtual hardware versions: Create a new baseline group in vSp…
This Micro Tutorial steps you through the configuration steps to configure your ESXi host Management Network settings and test the management network, ensure the host is recognized by the DNS Server, configure a new password, and the troubleshooting…

746 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

12 Experts available now in Live!

Get 1:1 Help Now