Don't we have a ThinApp FAQ?
As a matter of fact, we do have a ThinApp FAQ! It can be found here. And, while you've probably read the ThinApp FAQs, we thought it might be nice to post something a bit more recent along with some answers…and some bonus questions.
So, not just FAQs – the Top 10 ThinApp questions plus a few extra bonuses!
1. What is the recommended deployment method for ThinApp packages?
ThinApp is a flexible solution. Virtualized application packages may be deployed using portable devices as small as a USB flash drive, manually copied or executed from a network server, or automated using an enterprise electronic software deployment (ESD) platform of your choice.
1. (Alternate) What is the most common method to deploy ThinApp packaged applications?
While this might depend upon whom you ask this of, here in the U.S. the most common deployment option for ThinApp packages is via a network accessible ThinApp package repository.
Shortcuts to ThinApp EXEs are presented to end users via logon scripts which utilizes the ThinReg utility. Remember, ThinReg will register applications (including their file type associations, protocols, and COM objects defined) as well as create shortcuts in the user’s start menu, desktop or wherever they’ve been defined to be created.
ThinReg will honor any Active Directory Security Groups (including nested) defined within the ThinApp packaged app.
Now, all of this said, I'm told "across the pond" in Europe the most common deployment mechanism is via MSI through a 3rd party ESD. This is also a nice feature as any ThinApp built into an MSI can be incorporated into any 3rd party ESD solution.
2. Can ThinApp packages run on Linux or Mac Platforms?
Not directly, however, one can login to a View Desktop or other type of system remotely and execute a ThinApp packaged application just like any other application.
3. Are there any size limitations to a ThinApp package?
No. There are no size limitations of the ThinApp packaged app. Any limitations are going to be a restriction determined by the Windows OS the ThinApp packaged application is being executed upon.
To add some detail to this, there are issues when packaging an app into a single EXE of a certain size (or larger) which vary based upon the version of Windows the ThinApp packaged app is being executed on.
- Windows XP has an EXE size limitation of 512MB.
- Windows Vista (and potentially Win 7) has an EXE size limitation of 2GB.
An EXE larger than the allotted size may have issues such as trouble displaying it's icon, may take an excessively long time to launch due to loading of the large EXE (or due to the Anti-virus solution scanning the EXE), or may even have issues just launching due to the enormity of the EXE.
Fortunately, ThinApp provides a solution to these operating system .EXE size issues by allowing a ThinApp packaged application to exist not only as single EXE applications but as multiple exe applications as well by use of a very large Primary Data Container – for example a .DAT file – and a very small Entry Point executable file (or files).
Note: Think of Office as an example here. In fact, here's a screen shot of my ThinApp'ed Office showing multiple Entry Points and a single large Primary Data Container (.DAT) file.
4. Can ThinApp integrate with 3rd party packaging solutions? If so, which?
Yes. You should be able to integrate ThinApp packaged applications into any 3rd party packaging solution.
5. What applications can be packaged using ThinApp?
While ThinApp has an industry leading 90-95% packaging success rate, VMware does not currently maintain a list of applications which can or cannot be packaged as there are just too many applications out there. A good place to check, however, is the ThinApp Communities Portal – which is where many ThinApp Community members post recipes, instructions, comments, and even issues seen when packaging their specific apps.
VMware does not set nor enforce any application packaging success criteria, which means customers and Independent Software Vendors (ISVs) are free to establish success criteria themselves. Nearly any application can be successfully packaged using ThinApp, although the variability lies in the amount of time needed in the packaging effort for testing and troubleshooting.
ThinApp can package 32-bit applications as well as 16-bit applications (both 16-bit Win and 16-bit DOS apps).
NOTE: 16-bit applications cannot be executed on 64-bit platforms due to an OS limitation. ThinApp does NOT support 64-bit apps at this time.
6. What would prevent an application from being virtualized?
Before answering this, it should be noted every true application virtualization product or solution has these four issues or “gray areas” as they are not limited to ThinApp specifically.
- Drivers – Drivers cannot be virtualized as they are Windows OS Level controlled components which must interface with a logical or physical device. Applications which install drivers, however, may still be virtualized with ThinApp as the drivers can usually be installed natively to the OS while the rest of the application remains virtualized. Adobe Pro is a great example of this as the Print-to-PDF driver cannot be virtualized but the rest of Adobe Pro can still be packaged with ThinApp. If the driver is installed natively, the virtualized Adobe Pro can still utilize the driver and will automatically enable the functionality based upon if it sees the driver installed.
- COM Plus – COM Plus objects cannot be virtualized as they are Windows OS Level controlled components (ThinApp can virtualize COM objects). The same thing goes for COM Plus objects as for drivers – if the COM Plus objects can be installed to the native OS, it is likely the rest of the application can still be virtualized with ThinApp.
- Network DCOM – Network DCOM objects cannot be virtualized as there are two sides to Network DCOM objects – a local and a remote side. ThinApp cannot virtualize the REMOTE side. If the Network DCOM objects are installed natively to the OS, it is likely the application can still be virtualized. Now, it should be noted, ThinApp can virtualize DCOM – a.k.a. Local DCOM.
- Windows Components – ThinApp does not support virtualizing some OS Level Windows components such as DNS (client/server), DHCP (client/server), WINS (client/server), IIS, etc. This is due to the fact these components are operating at a very low level within the OS to the point where they are utilizing drivers or components or other OS level hooking technology to link into things such as the the network stack or other things. ThinApp can (and does) virtualize Internet Explorer and .NET FrameWork components just fine.
7. What types of customers are currently using ThinApp?
ThinApp virtualized applications are in use in many industries, including healthcare (and even rigorously regulated FDA environments), education, financial services, government, insurance, manufacturing, and more.
8. Can ThinApp integrate with a Citrix Infrastructure?
Absolutely! In fact ThinApp'ed applications will help reduce your Citrix server footprint by solving application incompatibilities within the Citrix XenApp (a.k.a. MetaFrame, Presentation Server, WinFrame) server – thus eliminating the need for the server silos.
9. How does ThinApp compare to it’s competitors?
ThinApp provides the flexibility to determine if a packaging effort is justified based on some legacy application platforms. For example, ThinApp has the ability to take a Windows 2000-based legacy application, capture it, and create a package which can be run in a newer Windows OS such as XP, Vista, or 2003. However, the ability to run applications designed for older versions of Windows on a newer version of Windows is not supported by all application virtualization solutions on the market today.
Because ThinApp packages operate in 100% user mode, normal context switching performance issues are eliminated. Other application virtualization solutions typically operate in kernel mode from both an agent and application perspective and therefore affect context switching performance.
ThinApp is one of the only agentless application virtualization solutions. Other solutions typically require an agent – which can break. Incidentally, this is also why ThinApp can integrate into any other management solution (i.e. TIVOLI, SMS/SCCM, etc.).
Note: A broken Agent/Client means no apps and possibilities for a BSOD.
10. How do I monitor the usage of ThinApp packaged apps?
Monitoring and metering of ThinApp packaged apps can be accomplished identically to natively installed applications. While ThinApp is solely an application virtualization solution, it should be noted ThinApp can plug in to any existing Metering/Monitoring solution in existence. If you don't have one in existence in your network environment, a recommended 3rd party solution is Concept Software’s SoftwareKey Metering Solution developed specifically to work with ThinApp and it’s agentless architecture.
What’s the one question missing here?
“Will my ThinApp’ed app work on Windows 7?”
Answer: The current release of VMware ThinApp (version 4.0.4) doesn’t “Officially” support Windows 7. However, there are “experimental capabilities” for Win 7 so you may find your ThinApp packaged application may work on Win 7 once it is rebuilt with ThinApp 4.0.4. It should be noted, the application does not need to be recaptured, only rebuilt with current version of ThinApp. So save your ThinApp projects!
UPDATE!: Since the release of ThinApp 4.5, ThinApp has officially supported Windows 7. With the upcoming release of the next version of ThinApp after 4.5, as seen in the "Internet Explorer 6 on Windows 7" article, ThinApp should also be able to support Internet Explorer 6 on Windows 7!
The same "rebuild only" solution goes for applications built with a Trial license of ThinApp. Once a valid full license is installed, just rebuild the ThinApp project and redeploy it.
See the ThinApp Blog article on How to Change Your ThinApp License.
So there you have it. These are the most common questions we get from customers today. Additional “Frequently Asked Questions” and answers can be found in the ThinApp FAQ located here.