Many of you who design, administer, and implement VMware View environments have probably encountered the discussion of how to integrate ThinApp into View desktops.  So FYI there is a series of posts on the ThinApp Blog which discuss a strategy for integration. The ThinApp Blog has a series of posts, Integrating ThinApp Packages with View Part 1, Integrating ThinApp Packages with View Part 2, View and ThinApp Integration Guide - Part 3 or you can download the end product of that series . . . the VMware View and ThinApp Integration Guide.  The guide discusses several of the topics covered in the previous posts but brings it all together with some task based scenarios that walk you through initial setup and configuration with screenshots and sample scripts.

So if you are looking for answers to these questions, this guide is for you.

Requirements

The following items and knowledge are required for use of this procedure:

• Familiarization with instructions on how to virtualize a software product via ThinApp (see, "How to Make a ThinApp Application" on the VMware ThinApp Blogs).

DISCLAIMER!

This site may contain information about third party products, services, tools and/or applications that are not owned or controlled by Ervik.as.Ervik.as does not endorse or make any representations or warranties about such third party products, services, tools and/or applications referenced in this site.

Notes:

It should be noted that the tools and applications listed are just examples of what can be used for application troubleshooting in general and techs should not limit themselves to just the applications/tools mentioned.  Don't just think "outside the box" - think inside the app.  What does the app need or want to see?  What tool will tell you or help you find out what that app is looking for?  Once this information is found, how can you get the application to behave in a manner that works properly in your network environment?  Is there some tool which will help you make that cumbersome app work the way you want/need it to?

Those are the general things to keep in mind when working with an application, regardless of ThinApp or not.

Application Troubleshooting Tools

Running Process Viewers

One of the first things needed is a process viewing tool which, at minimum, shows all running processes in a detailed manner.  Having a process viewer which shows what files, registry keys and other objects processes have open, which DLLs they have loaded, etc., is a big plus when trying to find out what the troublesome application is attempting to do.

An example of a process viewer which provides more details than the built in tool is Process Explorer by Microsoft.

Activity Loggers

It is a must to have a process monitoring tool which will log all activity of an application and allow a tech to review which folders, files, registry keys, registry entries, and other objects is a must.  This kind of tool can be used as a first step in troubleshooting a misbehaving application in general (ThinApp non-specific).

An example of a process monitoring tool is Process Monitor by Microsoft.  Additionally, Microsoft has retained the predecessors to this tool which are FileMon and RegMon by Sysinternals.

Dependency Viewers

A dependency viewing tool will allow a tech to select an application's executable and view all modules it is dependent upon.

A tool that falls into this category is Dependency Walker – a free tool that is available for download from http://www.dependencywalker.com.

Open Handle Viewers

Every now and then it is necessary to see what open handles are locking a file or registry entry.  Having a tool which shows that is a plus.

An example of something that shows this is Handle by Microsoft.

File Explorer

The majority of all techs use the built in Windows Explorer and Command Line to browse and manipulate the file structure but there are plenty of other file explorer and editing tools available for free or for a small price on the Internet.

Examples of 3rd party file explorers which should work within a ThinApp packaged application are the A43 File Manager (which does not need to be installed but can be copied into a package) and Windows File Explorer by Soft32.com (which requires an installation at the same time as the application).

Registry Editor

To mirror the file explorer comments, most techs use the built in Windows Registry Editor to view, browse, and modify the registry of a Windows system.  There are plenty of free and inexpensive registry editors available for download from the Internet which have different functionalities.

ThinApp Packaging and Troubleshooting Tools

Folder Isolation Viewer

While there is no substitute for knowing how to work with a file structure in Windows Explorer and a Command Line, it is sometimes necessary to get a different view of the file structure with isolation levels.  Having a graphical interface tool which can quickly display a ThinApp project's folder isolation settings can prove to be very helpful.

There are plenty of free tools which can be used for this.  Examples are the Thinstall Helper by the CIS Group and the Folder Isolation Viewer by Bob Carter.

NOTE: 3rd party tools should be used with care as some of them are written for specific versions of either ThinApp or Thinstall and may not work correctly with projects created by newer versions of ThinApp.

Registry Isolation Viewer

To mirror the comments about the Folder Isolation Viewer, there is no substitute for knowing how to work within the Windows Registry; however, there are times when a graphical representation can help.

There are a number of freely available tools on the Internet.  Examples are the Thinstall Helper by the CIS Group and the Registry Isolation Viewer by Bob Carter.

NOTE: 3rd party tools should be used with care as some of them are written for specific versions of either ThinApp or Thinstall and may not work correctly with projects created by newer versions of ThinApp.

ThinApp Log Monitor

ThinApp's own log monitor utility is great for monitoring everything a packaged application does or attempts to do.   It can provide numerous amounts of information with regards to any issue the package application may be having.

Large Text File Viewer

It is essential to have a text editor for viewing large log files and ThinApp registry files.  While Windows Notepad is easy to use in a pinch, because of the fact that ThinApp's Log Monitor utility can generate text files in excess of 1GB in size, it is beneficial to have a text file editor which can view and manipulate text files of larger sizes as Windows Notepad cannot handle files beyond 1GB very well.

EditPad Lite by JGSoft and Notepad Lite by GridinSoft are examples of free text editors capable of reading large text files.

Comparison Utility

Having a tool which can compare files, folders, and registries is highly beneficial for comparing ThinApp Projects for differences when one package works and another package doesn't.

A comparison utility available for purchase is Beyond Compare by Scooter Software.
NOTE: At last check, Scooter Software gives 20% discounts on Beyond Compare purchases by entering the discount code of "THINAPP".

Multilanguage Scripting Editor

Another tool worth having is a Multilanguage script editor – specifically something that can handle VBS, BAT, CMD, and INI files, and give abilities to interface with DBs, LDAP, ADSI, WMI, and COM objects.  Having a script editor which can also build executables out of the scripts which it can support is also a plus.

An editor that falls into this category is Admin Script Editor by iTripoli.
NOTE: At last check, iTripoli gives 20% discounts on any purchase of Admin Script Editor by entering the discount code of "THINAPP".

ThinApp Multi-Version Builder Utility

When testing against issues which may potentially be related to ThinApp, it is very beneficial to have a way to easily test a package against multiple versions of ThinApp.  This tool easily allows the building of ThinApp projects into packages with different versions of ThinApp.

This tool can be found on the T3chNot3s blog.

NOTE: This is a 3rd party blog which is NOT sponsored in any way by VMware. 3rd party tools should be used with care as some of them are written for specific versions of either ThinApp or Thinstall and may not work correctly with projects created by newer versions of ThinApp.

ThinApp Multi-Version MSI Loader

This tool works in support of the afore mentioned ThinApp Multi-Version Builder Utility as it allows techs to easily load up ThinApp MSIs for multiple different versions of ThinApp.

This tool can be found on the T3chNot3s blog.

NOTE: This is a 3rd party blog which is NOT sponsored in any way by VMware. 3rd party tools should be used with care as some of them are written for specific versions of either ThinApp or Thinstall and may not work correctly with projects created by newer versions of ThinApp.

ThinApp Tips

Long File Names Issue

Often times when packaging larger projects, techs will run into long file name issues when using the default folder of "C:\Program Files\VMware\VMware ThinApp\Captures".  An easy fix for this is to not use the Captures folder in this location but to create another captures folder off the root of the C: drive ("C:\Captures").  Another way to easily fix this issue is to create a substitute drive which maps directly to the "C:\Program Files\VMware\VMware ThinApp" folder.  The command is as follows:
SUBST.EXE "C:\Program Files\VMware\VMware ThinApp"

NOTE:  The above command can also be placed in a shortcut located in the Startup folder of the packaging system.

Running Explorer and 3rd Party File Browsers

Running an application which spawns a Windows Explorer window will, by default, launch that EXPLORER.EXE process outside the virtual environment.  This is due to embedded settings within the Windows Operation System and EXPLORER.EXE itself.  The EXPLORER.EXE process is actually designed to first check to see if another instance of EXPLORER.EXE is running and, if not, launch itself as the desktop shell.  Therefore, all Windows Explorer processes will always reside in the physical environment unless the initial EXPLORER.EXE process is launched within the virtual environment.  See the ThinApp blog article on Running EXPLORER.EXE Inside the Bubble as well as the blog article on Creating Windows Entry Points for Troubleshooting ThinApp Packages – both can be found on the VMware ThinApp Blogs.

A number of 3rd party file browsers are present on the Internet for download which can be utilized to give the user and/or administrator of the ThinApp packaged application a view into the virtual file system – or at least, what the application thinks is the real file system.

An example of a free file browser is the A43 File Manager.  To utilize this tool, place a copy of it into your ThinApp project and create an entry point for it within your ThinApp Project's PACKAGE.INI file.

Folder Sharing

Sharing out the VMware ThinApp folder on the host system is also a great way to allow VMware Workstation VMs running on that system access to save ThinApp Project captures by default (without manual intervention).  This means that ThinApp does not have to be installed onto the VMs prior to capturing and project folders do not need to be manually copied off the VMs prior to restoring the VMs to a known good snapshot.

See the article on How to Make a ThinApp Application Package on the VMware ThinApp Blogs.

Sandbox Redirection

Redirecting the default sandbox for test systems to a folder of easy access (i.e. "C:\TEMP\SANDBOX") may be a way in which to easily troubleshoot packaged applications.

See the "Controlling the Sandbox Location" section of the ThinApp Online Documentation for more information.

Using Compression

If troubleshooting or fine tuning a ThinApp package where constant rebuilds are occurring, it may improve efficiency in testing on larger projects if FAST compression is used as this decreases the time of the subsequent builds/rebuilds of the package in question.  This occurs because ThinApp creates a Build Cache where it stores all compressed files in the event of subsequent builds of the project.

Note:  Some files or file types in a project may have issues with being compressed.

Adjusting the SNAPSHOT.INI

In some instances, you may be wondering how to not continually capture a specific file or registry setting. The default settings of ThinApp can be modified by editing the SNAPSHOT.INI file in the VMware ThinApp folder. These are the default settings with which ThinApp Setup Capture operates by.

Why would you modify this file? Well, maybe you have a utility program set to run upon startup of your VM and you don't wish for the outcome of that to be captured by ThinApp. Or, maybe you need to capture a Windows setting which, by default, is set to NOT be captured so that your application will properly run when packaged with ThinApp. Or maybe you are building specific versions of the same application and you know you need certain folders or registry settings to always be set to WriteCopy vs. Full or Merged. These types of modifications can be made by customizing your SNAPSHOT.INI.

NOTE: It is recommended to make a backup of the SNAPSHOT.INI prior to any modifications!!

Periodic Cleanup

Periodically performing cleanup of the ThinApp Build Cache is function which can keep the build system from running out of disc space.  Check the size of the "%USERPROFILE%\Local Settings\Application Data\Thinstall\BuildCache" folder and delete its contents if you deem it safe to do so.

Run the App

One of the biggest tips for properly capturing an application is, once the application is installed, run the application.  This is not only for testing the application - for an application which won't work natively in Windows will not work as a ThinApp packaged app either (i.e. Junk In - Junk Out) - but also for the many types of applications which don't finish their setup until the first run of the application.  An example would be applications which ask for file type associations upon first launch.

 

VMware Workstation Snapshots

VMware sells ThinApp with a licensed copy of VMware Workstation for a couple of reasons.  First and foremost, this is done to give customers an environment which is not intermixed in any way with their production system.  Secondly, this is done to keep customers from having to reallocate a production system or purchase a lab specific system for packaging, and finally, it's done to add in the snapshot abilities of VMware Workstation.

A single clean Windows VM can be snapshotted at the clean build state and cloned (full or linked) to create a near infinite number of test environments.  Because of this, one can conduct a pre-installation ThinApp Setup Capture, install the application, test it, and keep this configuration for later troubleshooting, but still be able to role back to a clean build for additional application packaging.

 

Setup Capture Command Line for GUI

A big benefit of using ThinApp over competitor products to package applications is it's use of the tried-and-true delta snapshot technology and it's non-requirement to be running during the installation of an application.  In short, this means one can install the application exactly the same way they would install it on a regular workstation.  More importantly, this means the clean VM can be rebooted as many times as necessary.  After each reboot of the VM, ThinApp Setup Capture will re-launch, picking up where it left off.  If the application installation or configuration is not complete, simply cancel the setup capture or close it by clicking the red "X".

This information to relaunch the GUI upon login is stored in registry under the following key.
HKEY_CURRENT_USER\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN
Entry:  ThinApp Setup Capture Continue
Value:  "<DRIVE:\><PATH\>SETUP CAPTURE.EXE" "<DRIVE:\><PATH\><SNAPSHOT FILE.SNAPSHOT>" "<SCAN ITEMS>"
Type:  REG_SZ:

It should be noted for those who use the GUI that some applications installations will wipe the HKEY_CURRENT_USER\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN registry key of all it's entries, and in doing so also remove the ThinApp Setup Capture Continue entry as well.

To work around this, simply locate the initial SNAPSHOT file - usually located in the account's %TEMP% folder although sometimes found in the %PROGRAMFILES%\VMware\VMware ThinApp\ folder- and run the value from the run window or command line.

NOTE:  You will need to remember your initial scan settings.  Default is the C: drive, the HKEY_LOCAL_MACHINE and HKEY_USERS hives.

Example:
"C:\Program Files\VMware\VMware ThinApp\Setup Capture.exe" "C:\DOCUME~1\Admin\LOCALS~1\Temp\{7498EF29-9F66-4018-BAD3-B0B5E645CACB}.snapshot" "C:\ HKEY_LOCAL_MACHINE HKEY_USERS"

NOTE:  The above command line is a single line but may appear word wrapped in your browser.

ThinApp Packaged App Troubleshooting - Slow Apps

Often times we hear the app works but starts up slowly.  The first thing to help you here is this; does it start slowly the first time ONLY or does it start slowly each and every time.  Remembering the application is creating, building, and extracting contents to the sandbox a little more so the first time it executes, we can assume that if the application only runs slow the first time, it must be something which is being extracted, created, built, or otherwise dumped to the sandbox.

Regardless of this, here are some additional items to check:

• Services are starting up.  It could be the case the services are not needed – if so, disable the services either in the ThinApp Project registry (HKEY_LOCAL_MACHINE.TXT file) or set the AutoStartServices=0 BuildOption in the PACKAGE.INI.  If the services are needed and they are taking a long time to launch, test the services start/stop times on a native Windows clean VM and see if the same thing happens there.  If so, a call to the app manufacturer is in order.
  Example:  Office will load and set the Machine Debug Manager (MDM.EXE) service and CTFMON.EXE services to auto-start.  These are not necessarily needed to launch a ThinApp'ed version of Office and can usually be disabled.
• Fonts being extracted on the fly to the sandbox during initial startup.  Look for a %FONTS% folder in the sandbox and copy it into the ThinApp project.  Rebuild the ThinApp project and retest this.
• Awaiting numerous fonts to be loaded.  Sometimes an app will load every font it can find.  In this scenario, it might be wise to remove all but the necessary fonts from the %FONTS% folder in the ThinApp Project and install them natively to the Windows host.
• Auto-repair functions.  Most apps will auto-repair themselves when they detect something incorrectly configured – and sometimes ThinApp will cause this if isolation or other settings are not properly configured in the ThinApp package.  Look for things like the MSIEXEC.EXE process/service running (attempt to stop if possible) and other app-specific auto-repair functions or processes.  Seeing these run may indicate a misconfigured application and often times kick off an auto-repair of the application without even showing this process to the user executing the application (ThinApp’ed or not).
• Excessive package size.  If the ThinApp project is excessive in size (there is no specific size here - it's specific to what the environment can handle), it can take longer to load depending upon how the application works and loads itself, and - of course - the environment it is running on.  Remove unnecessary items from the ThinApp project before building.  Typically items such as the following can be removed from a project (MAKE A BACKUP OF THE PROJECT FIRST!):
• • %SYSTEMROOT%\INSTALLER — The contents of this folder will likely contain some MSI files – these MSI files can usually be removed if they are not needed.
  • %APPDATA%, %LOCAL APPDATA%, and %PROFILE% -- Since these folders are all part of the user’s “profile”, if the application is installed to the entire system (meaning, anyone can login to the specific system the app is installed on and launch the app), then the contents of these folders are not typically needed unless it is desired to package the customer user configuration information with the application.
  • %PROGRAMFILESDIR%\<app folder>\<app backup folder> -- Sometimes an application will install a backup of itself into a subfolder of the %ProgramFilesDir%\App folder. This is typically for auto-repair functionality as well, much like the %SYSTEMROOT%\INSTALLER folder contents are for repairing the app.
    Example:  Adobe products (depending upon the product and the version of the product) will often store a complete backup of the installation source code in %PROGRAMFILESDIR%\ADOBE\<Product>\Setup Files.  Sometimes it's hidden in %PROGRAMFILESDIR%\ADOBE\ADOBEPATCHFILES as well.  So...it boils down to "Know Thine App"!
  • %COOKIES%, %HISTORY%, and %INTERNET EXPLORER CACHE% -- Unless actually capturing an IE application or an IE plugin/addon, these folders may not be needed for your specific application, and thus the entire folder can be removed.

Click here to read the full article

What is the PACKAGE.INI?

First and foremost, the PACKAGE.INI file is the the brains behind the project.

What does it contain?

It is where ThinApp stores all of the settings to the questions you answered within the ThinApp GUI.

In addition, it stores settings and configurations not configurable through the ThinApp GUI such as MSI, AppLink, and AppSync parameters.

Can I modify it?

Absolutely! Simply open it with NOTEPAD or any other text editor to modify it to fit your needs.

Where can I find help on the contents of the PACKAGE.INI?

For a very detailed read on every single setting within the PACKAGE.INI, you can go to the ThinApp Online Documentation and you will be able to find every single entry and subsequent values listed.

NOTE: Not ever entry will be present within your PACKAGE.INI, however default values will still be assumed.

What are the contents of the PACKAGE.INI File?

Notes and Help

ThinApp's Developers and Engineers took great care to make the PACKAGE.INI lay out in a logical format for easy access, reading, and manipulation. To that end, the very first thing listed is a URL. This URL, when pasted into your browser of choice, will bring up the very latest online help for your version of ThinApp!.

Compression and Isolation

The first two sections of note are COMPRESSION and ISOLATION. Under COMPRESSION is the CompressionType value which is quite simple as it's either NONE or FAST ("Fast" being the actual name of the PKZIP compression algorithm).

Specifically for ISOLATION, the Default Directory Isolation Mode (DirectoryIsolationMode) is the entry found underneath it. Another entry which can be manually entered underneath the ISOLATION section is the "RegistryIsolationMode". Both entries have values of either "Merged" or "WriteCopy". For further explanation on Isolation Modes, see the ThinApp Blog article (and subsequent embedded video) ThinApp 101: Differences Between the Isolation Modes.

NOTE: Do not use "Full" isolation in either "DirectoryIsolationMode" or RegistryIsolationMode" entries as this will prevent the application from seeing the Windows Operating System.

Build Options

Under the Build Options, you'll find numerous other settings, so I'll attempt to stick with the basics here to help keep things simple. It should be noted, however, the Build Option entries do not need to appear in any specific order or even at all since, as previously stated, any option not specifically present will have it's default value assumed.

MSI Parameters

Under this section you'll find every value you need in order to not only create an MSI but create it in any number of fashions - even allowing a regular user to execute the MSI or doing such things as configuring the parameters to use an MSI to update a ThinApp'ed application previously deployed with an MSI.

AppSync Parameters

The AppSync Parameters are remarked out by default and only placed within the PACKAGE.INI as an example of what to do in order to configure Application Syncing.

For additional information on Application Syncing, see the ThinApp Blog article (and subsequent video), AppSync Explained.

Parameters used only during Setup Capture

This title is not entirely true for this section as the AccessDeniedMsg entry is used for when the PermittedGroups or PermittedComputers entries are enabled and utilized.

 

As for the other entries, you'll find CapturedUsingVersion which simply denotes the ThinApp Version used to capture the application package in question and OutDir which tells ThinApp the folder to create and then dump the packaged app to.

General Purpose Parameters

Under this section, you'll find a various set of entries. The typical ones being the following:


• SandboxName= This is the name of the Sandbox folder created for the application (typically under the %APPDATA%\THINSTALL folder within the user's profile).
NOTE: Make sure you also read up on the Search Order for the Sandbox.


• InventoryName= This is what is used to determine the default names of the project folder and sandbox during the application capture process.


• ;PermittedGroups= The Active Directory or Local Windows Security Groups of users defined who may execute the ThinApp packaged application in question. Typically this is remarked out unless defined within the GUI.
NOTE 1: This value like any other PACKAGE.INI value, may be defined after the fact. Defining the PermittedGroups value after the fact can be done by entering the Security Group name or SID value. Using a Security Group's Name requires the system doing the build process have access to enumerate the Active Directory Group in question to look up it's respective SID value. NOTE 2: PermittedGroups and PermittedComputers entries can also be defined under each Entry Point for a packaged application suite such as Office in order to define specific security settings for each individual Entry Point (i.e. Word, Excel, Outlook, etc. only open for users of those respective groups - even if a user is only a member of the Word group and not the Excel or Outlook Groups - hence they cannot open Excel or Outlook, only Word).


• ;RemoveSandboxOnExit= Remarked out by default but used to tell ThinApp to wipe the application's Sandbox upon exit of all parent and child applications within the respective ThinApp package.


• ;SandboxNetworkDrives= This value, remarked out be default, is used to tell ThinApp to use the Sandbox for Network Drive access. The default is NOT to use the sandbox for Network Drives.


• ;SandboxRemovableDisk= This value, remarked out be default, is used to tell ThinApp to use the Sandbox for Removable Media access. The default is NOT to use the sandbox for Removable Drives.


• ;VirtualizeExternalOutOfProcessCOM= This entry, remarked out by default, controls whether external out-of-process COM objects can run in the virtual environment or not.


• ;OptionalAppLinks and ;RequiredAppLinks entries are both remarked out by default. They are used to link the respective Parent ThinApp packaged application to any number of child ThinApp packages either on an optional or required basis. For additional information on Application Linking (AppLink) see the Configuring Dependent Applications with Application Link and the Application Linking articles in the online help.


• VirtualDrives= The VirtualDrives entry is used to define what drive letters are to be virtualized by the ThinApp Virtual Operating System (VOS) for the application to see an interact with. A virtual drive can either exist natively as any other drive type or not exist natively but only virtually. Using this entry, one can create such things as a virtual CD drive for an application which normally requires a physical CD be inserted for proper execution - and then include the contents of the CD within the ThinApp package to eliminate the need for the physical CD.
NOTE: ONLY ONE VirtualDrives entry can be used within the PACKAGE.INI file. The second, remarked out, ";VirtualDrives" entry is for demonstration purposes only!


• AnsiCodePage= This entry uses a numerical value to specify the country locale where you captured the application. ThinApp uses the value to translate multibyte strings.


• LocaleIdentifier= This entry parameter displays a numeric ID for the locale information. The value for this entry locates the correct language resources from the application.


• ;Wow64= This entry is used to simulates a 32-bit environment for 32-bit applications which cannot run (at least not properly) on a 64-bit Windows operating system. As the note within the PACKAGE.INI says, if you have problems running your 32 bit application under 64 bit Windows, try enabling this line and rebuilding your project.

Entry Points

Your entry points will appear within the PACKAGE.INI at this point forward. Typically the first entry point will be the Primary Data Container, as denoted by the "ReadOnlyData" entry underneath it. The ReadOnlyData entry defines the ThinApp Virtual Registry package container and, as stated by the entry name, is Read Only. All other entry point sections will link back to this Data Container by use of the Shortcut entry underneath each of the Entry Point names.

For additional settings which can be defined underneath each Entry Point, see the Configuring Individual Applications article in the Online Help.

---

These are the basics for each ThinApp PACKAGE.INI. Remember, additional information can always be found in the Online Help!