This is Dean Flaming's Typepad Profile.
Join Typepad and start following Dean Flaming's activity
Join Now!
Already a member? Sign In
Dean Flaming
Seattle, WA
VMware, ThinApp Global Product Specialist
Recent Activity
Unfortunately, what you are asking is not allowed within the ThinApp Enterprise EULA. From my understanding the only way this could be accomplished with the Enterprise version of ThinApp is if each of your customers bought their own copy of ThinApp and the proper number of client licenses they needed. You could then package the customer's application with their ThinApp license. The other way is VMware has a Developer Edition of ThinApp (a.k.a ISV version of ThinApp) which allows for redistribution of ThinApp packages assuming the redistribution requirements of the packaged app has been addressed (assuming you own the app being packaged, are selling the application being packaged to the customer, or the customer already owns the app being packaged). I would highly recommend you contact your VMware representative for clarification so we can thoroughly review your needs and help you address the requirements.
1 reply
@Ravi - Either way will work (packaging the subcomponent with the app or separately and using AppLink settings such as OptionalApplink or RequiredApplink).
1 reply
Before you complete the ThinApp post setup capture process (after installing the application) you need to ensure the file type is registered on the system or for the user. It sounds like you are doing this but in order to test this, I would suggest following the ThinApp Troubleshooting Procedure found here. http://blogs.vmware.com/thinapp/2010/10/thinapp-troubleshooting-methods.html This way you can isolate where the issue is (during or after capture, within the ThinApp package or in the native environment).
1 reply
@Jason - This is current but please make certain to read all of the comments as this is a living document. There were a number of suggested resolutions for different issues in the comments.
1 reply
@netjim66 - You can use whatever executable you wish as an entry point. Since users do not launch ".NET Framework" directly on their own PCs (applications use this), any entry point is fine...most customers usually use the primary/default entry point selected and then create a separate data container file. Remember, it can be changed after the fact as well. See the ThinApp Pubs (http://bit.ly/thinapppubs) for more details on how to modify the PACKAGE.INI file after the fact. When using AppLink to link another ThinApp package to this .NET Framework ThinApp package, reference the Data Container of this ThinApp package. Example: OptionalApplink=[path]\DOTNET.DAT Above assumes the Data Container is a separate file called DOTNET.DAT. See the AppLink section of the ThinApp pubs for further information on application linking (http://bit.ly/thinappapplink). Also, you may wish to review the ThinApp Bootcamp Series - AppLink Fundamentals as this goes into both the basics and some interesting advanced concepts for using AppLink. This ThinApp Bootcamp may be found here: vmware.com/go/thinappbootcamp
1 reply
My recommendation....if you only read one thing in the ThinApp Pubs, make it the Sandbox Search Order documentation. http://pubs.vmware.com/thinapp4/help/sandbox_search_order.html
1 reply
That will definiitely work as well. What's nice with SBMERGE, if you use the Default Sandbox path (%APPDATA%\Thinstall) or have the default sandbox path variable(s) set (%_SANDBOX_DIR% or %THINSTALL_SANDBOX_DIR% environment variables), then you can just go to the root of the project and type "SBMERGE APPLY" and it will work. For more info, there's also the blog posting on SBMERGE: http://blogs.vmware.com/thinapp/2010/02/simple-steps-for-using-sbmerge.html :-)
1 reply
Toby, To your question, the command goes in a VB Script in the root of the project. For future doc update requests you can hit the email link in the upper right corner of the documentation when viewing it online at http://pubs.vmware.com/thinapp4/help/ as this will send the feedback directly to our documentation folks as this would probably be best directed towards them as your point is valid. I'll forward this along to them. :-)
1 reply
@TobyFruthParsons - Theoretically you should be able to do this but it will take some custom tweaking as you'll need some way to look at the same native key as the virtual key. It's possible you might be able to rename the virtual key but there's always the chance this will break the service or app which relieas on it. But it may be possible if you manually start this renamed service (after validation checks determine it doesn't exist natively) the app may just detect the virtual OSPPSVC running and use it. Another option is somehow using the ExecuteExternal API. See the below link for more details (open the API section). http://pubs.vmware.com/thinapp4/help/scripts.html#995325 You'll have to test this, of course. :-) Hope this helps!
1 reply
@TobyFruthParsons - Theoretically you should be able to do this but it will take some custom tweaking as you'll need some way to look at the same native key as the virtual key. It's possible you might be able to rename the virtual key but there's always the chance this will break the service or app which relieas on it. But it may be possible if you manually start this renamed service (after validation checks determine it doesn't exist natively) the app may just detect the virtual OSPPSVC running and use it. Another option is somehow using the ExecuteExternal API. See the below link for more details (open the API section). http://pubs.vmware.com/thinapp4/help/scripts.html#995325 You'll have to test this, of course. :-) Hope this helps!
1 reply
@Jonas - Yes.... You can find all the information on this in the ThinApp Pubs (http://bit.ly/ThinAppPubs). The specific link you're looking for is http://pubs.vmware.com/thinapp4/help/wwhelp/wwhimpl/js/html/wwhelp.htm?href=folder_macro_list.html#996413
1 reply
MSI files are not utilized in side-by-side updating. Only EXEs/DAT (or whatever extension you utilize for the data container). Use of the ThinApp created MSI is a delivery technology used to interface with 3rd party ESD solutions. Side-by-side updating is only meant to update the already registered ThinApp packaged application.
1 reply
@George - This sounds like you captured the app with ThinApp 4.6.1 and are attempting to build it with 4.6.0 or older. In 4.6.1, the Data Container is no longer "BIN\PACKAGE.RO.TVR" - it is now just "PACKAGE.RO.TVR". This was done for flexibility purposes in the project build process when combining ThinApp into other 3rd party packaging solutions. Key Symptom: If you attempt to build a project captured with 4.6.1 with anything earlier than 4.6.1, you'll get an invalidly built package and it will just create an entry point which, when launched, says it cannot find/open the sandbox! Resolution: Build with ThinApp 4.6.1 or, if building with older versions of ThinApp, edit the PACKAGE.INI and change data container's value "ReadOnlyData=Package.ro.tvr" to "ReadOnlyData=bin\Package.ro.tvr" or upgrade to ThinApp 4.6.1 or higher, then rebuild the project. Note: The below will show up under the Primary Data Container settings in the PACKAGE.INI as a reminder of this. ---SNIP--- ;Change ReadOnlyData to bin\Package.ro.tvr to build with old versions(4.6.0 or earlier) of tools ---SNIP---
1 reply
@Ken- You got it on the second post. :-) The files are in the %SYSTEMSYSTEM% folder of the project.
1 reply
@Ken- You got it on the second post. :-) The files are in the %SYSTEMSYSTEM% folder of the project.
1 reply
@Ken- You got it on the second post. :-) The files are in the %SYSTEMSYSTEM% folder of the project.
1 reply
Keep in mind the following: 1. ThinApp uses Delta technology. 2. An application installation is nothing more than a package containing new or newer files than what exists on the end user system and new or different registry settings than what exist on the end user system. 3. Newer Windows operating system contain additional and more components than older operating system - which means newer files, more files, and newer registry settings and more registry settings. Taking into account the above, this can mean applications captured on a newer operating system (i.e. WIn 7) will likely not work on an older operating system (i.e. Win XP). A good example is Win 7 has .NET FrameWork 3.5 embedded into the OS. Windows XP, on the other hand, does not come with any .NET FrameWork. If I capture an application which requires .NET FrameWork on a clean Win 7 OS and try and run that packaged app on a Win XP system, it's not going to work unless .Net FrameWork is already installed natively. This ultimately means I must create two ThinApp captures - one for Win7 and one for Win XP. While this isn't a big deal, it is more work. Conversely, if I capture on my lowest common OS (i.e. Win XP), then the app will work on XP, and be more likely to work on newer operating systems as well (i.e. Win 7). For discussions around setting up a Clean Capture and Build PC, see this blog article: http://blogs.vmware.com/thinapp/2009/05/what-do-you-mean-by-clean-machine.html
1 reply
I would suggest trying manually with THINREG.EXE /U [PATH\APP.EXE] as well as removing user from group, logging out and back in, then manually trying THINREG.EXE [PATH\APP.EXE] (no /U switch). If you're having an issue where removing the user from the group (and logging out and back in) doesn't automatically remove the app from the user's desktop (assuming THINREG.EXE is part of your user's login script), please ensure you are on the latest version of ThinApp 4.6 (download from VMware.com) and the package is built with ThinApp 4.6 (capturing with 4.6 is not needed, only building with 4.6 is). If you are still having issues after all of this, please do contact VMware Support on the web at http://www.vmware.com/support or by phone at 1-877-4-VMWARE (1-877-486-9273) or 1-650-475-5345.
1 reply
@DrG - This is true, and here I remind everyone ThinApp is an Application Virtualization product, not a security product. Additionally, other ThinApp features can come into play here such as wiping the sandbox on exit or only allowing the ThinApp package to run from authorized systems as they may help in achieving the desired results. While this article was more to show some possibilities around ThinApp, don't forget there may be other ways outside of ThinApp which may better accomplish the desired results. In this scenario, such as locking the file to read-only for all users and not allowing email attachments or using other tools such as Adobe Pro to create a secure PDF (password, print, copy/paste protected document) may be a more suitable solution. The point here is, using ThinApp in conjunction with other solutions may help in obtaining the desired results in very unique situations and this is very much an example of the many ways in which it might be used.
1 reply
If you have multiple domain controllers, AD synchronization can take some time (depends upon the settings you have configured for domain synchronization - and while password changes and account disablement forces immediate synchronization, group membership changes do not). If you go into AD Sites and Services, you can force the synchronization of your domain controllers. See Microsoft Technet at http://technet.microsoft.com/en-us/library/cc776188%28WS.10%29.aspx for more info on forcing domain synchronization. For changing the default synchronization intervals, see Microsoft's KB 214678 at http://support.microsoft.com/kb/214678 for more info.
1 reply
@Calvin Woods Apologies on the delay... To answer your question you can place the sandbox in virtually any location (so long as the location is accessible and the user has complete permissions to that location) using a number of different means. Rather than typing them all out here, I would suggest the following reading in the online help manual as it fully discusses how the ThinApp Sandbox is located and - through this discussion - how you can configure the location of the sandbox for the specific application, all applications per user/per system/per environment variable/etc. to be wherever you need them to be. http://pubs.vmware.com/thinapp4/help/wwhelp/wwhimpl/js/html/wwhelp.htm?href=sandbox_search_order.html When viewing the above link, also make sure to look in the left-hand pane and see the section on "Controlling the sandbox location". Additionally, you may also wish to review the article on the Package.ini file. http://blogs.vmware.com/thinapp/2009/12/the-packageini-file-explained.html
1 reply
Generally a proof of concept is to provide proof the technology works as expected as well as not only learn how the technology works but what are the best ways in which to implement the technology into ones own environment. Keeping things simplistic at this point helps in accomplishing this. After the POC is complete, then, as mentioned in the "Wrap Up" section, more complicated applications can be tested. Remember, this is for the do-it-yourself-ers who would rather figure everything out on their own - so one must assume a certain baseline understanding, figure out where it best fits into their environment, and go forth from there. The point of this article is to help establish a solid baseline for which someone can first understand the technology, then attempt more complex applications. To use an analogy; when learning how to swim, one does not jump into a deep and fast flowing river. They walk into the shallow end of a pool or other calm waters, learn to hold their breath, kick their legs, and swing their arms in a particular style. Only then, after practicing the basics can one work their way up to the more complex waters. :-)
Toggle Commented Dec 16, 2010 on ThinApp POC (In a Blog) at VMware ThinApp Blog
1 reply
@Thomas J - This sounds as if it could be any number of things from isolation settings to potentially a glitch with double-byte characters. Please contact VMware support on the web at http://www.vmware.com/support or by phone at 1-877-4-VMWARE (1-877-486-9273) or 1-650-475-5345 and open a support ticket on this issue. If you have troubles doing so or are evaluating ThinApp (and don't have a support agreement), please contact your VMware Account Rep or SE. If all else fails, please direct message me by clicking on my name and sending me an email so we can get you in contact with the proper person. Thanks!
1 reply
@Thomas J - This sounds as if it could be any number of things from isolation settings to potentially a glitch with double-byte characters. Please contact VMware support on the web at http://www.vmware.com/support or by phone at 1-877-4-VMWARE (1-877-486-9273) or 1-650-475-5345 and open a support ticket on this issue. If you have troubles doing so or are evaluating ThinApp (and don't have a support agreement), please contact your VMware Account Rep or SE. If all else fails, please direct message me by clicking on my name and sending me an email so we can get you in contact with the proper person. Thanks!
1 reply
Not to my knowledge but I wouldn't be surprised if there were. The trick is finding the right Browser Helper Object and it's associated ClassID. While this is a bit like searching for a needle in a haystack, you can methodically weed out the areas which don't resolve the issue by making a backup of the original project then tweaking one step at a time. See the ThinApp Blog Troubleshooting section (http://blogs.vmware.com/thinapp/troubleshooting/) as they do review some "Best Practices".
Toggle Commented Sep 13, 2010 on Java Pop-Ups Slow in IE7/IE8 at VMware ThinApp Blog
1 reply