ThinApp 4.6.1 is a maintenance release and includes fixes for more than 160 known issues.
Unfortunately is there an error in our documentation and questions has been raised regarding where should the new parameter OptimizeFor= be placed. It must be placed under the Compression section in package.ini and not as stated in the manual under the BuildOptions section..
Often, we get asked one of the following questions or a variation of them:
- What is a ThinApp Data Container?
- Is there more than one Data Container?
- What is the Data Container used for?
- What does the Data Container do?
- What are ThinApp Entry Points?
- What are Entry Points used for?
- What do Entry Points do?
- Why does ThinApp sometimes recommend a “.DAT” file?
Recently on the ThinApp Communities portal, VMware Community member “CookieMe” asked a question which sparked my interest. ThinApp has the ability to package an app and assign Active Directory Security Groups to the package in order to limit who can use them. Essentially, CookieMe was asking, “Can I prevent Users A from attaching a file from the ‘Bookkeeping’ share to an email and sending it to someone?” To put this in other words, can ThinApp be used to restrict a document, spreadsheet, presentation, or other non-executable file from also ‘walking off’ a company’s network? Absolutely!
Some Things to Note:
- First and foremost ThinApp is an Application Virtualization solution ONLY and NOT a security product, even though it can be used to enhance other security solutions within a network environment.
- This will NOT prevent someone from copying the ThinApp package off the network or zipping and emailing it off the network. It will only lock the ThinApp package to the security group(s) defined, and when a ThinApp package cannot authenticate to it’s respective group, the package cannot be opened.
The above dully noted, in this procedure, we show how to make a ThinApp Package which contains a non-executable file.
So what is this PACKAGE.INI file anyways? What does it contain, why do I need it, and how can I use or modify it? These are common questions we get around the PACKAGE.INI file.
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!
What do we mean when asked to use a "clean PC" for capturing our applications? This question has many answers and ultimately depends on what you want to capture. But since that common answer is a little too vague, let's dive into this topic briefly to discuss what is technically involved here.
We all know that when we ThinApp our applications we are simply parsing the differences between two snapshots of our workstation. That in itself is simple enough, but the idea of the "clean PC" really should be phrased as the "The software I want in my ThinApp that is not currently installed, so therefore the differences in my snapshots will be reflected in my capture. " 🙂 The problem is that is way to difficult to place on the SetupCapure window and thus we use the term "Clean PC". But, that is essentially what we mean.
Consider the following. I want to capture my application that requires the .NET framework. Should I already have .NET installed locally or not? This is the simple question that comes up time and again. The answer is equally as simple. Do you want your application to include the .NET framework so you don't need it on the target workstation or would you rather manage that requirement outside of ThinApp. When looked at in this context, it's much easier to make the decision of what to have pre-installed versus what to install during a capture. But what does that have to do with the idea of a clean workstation???
The idea of a clean workstation is just one that does not have the software pre-installed that you want to capture. That's really it. So, the real trick is to understand what software requirements our applications need. Most of the time we find that in the System Requirements provided to us from the application vendor. Other times, we have just learned what an application needs as a matter of practice. When you hear of folks using a "clean PC" that only has the latest SP and no other components like .NET, Java, etc…, one may ask, "Why do they bother if all they need to ensure is that their software isn't already installed?"That too is an easy answer. It's because most of our apps are LOB and we often have very little information to begin with. If I use a workstation like I just described, then the prevailing idea is that if my application needs anything, it will either install it for me or scream about it during the install. This type of error dialog is common for developers who write their setup routines to look for these types of supporting components.
So, what type of workstation will you use to capture your applications on? Just ask yourself this one question, "do i know what my application needs to have in order to run and will the workstation I use this on have those already?" After that, you decide what type of workstation makes the best platform to capture your applications. If you're like me, I have several flavors in VM Workstation to allow me the option to pick and choose what makes sense for the application in hand. Ultimately, you will do what makes sense too, but I thought it would be a good idea to discuss the technical impact to what we call a "clean PC"
We recently did some research on how to best deploy a ThinApp packaged application by pushing the ThinApp packaged MSI out to workstations via an Active Directory Group Policy Ojbect.