This blog post will explain how you can configure your ThinApp packages for integration with VMware UEM without using vb-script or any other black magic. When you have VMware UEM and ThinApp integrated users’ application settings flow seamlessly between both natively installed, published applications (Terminal Server/RDSH based) and ThinApp packaged applications. Using the integration you can centrally manage default and mandatory application settings also for ThinApp packages. Continue reading →
I’m getting more and more requests to package IE8 so I think it is about time to write a blog post on how to do it.. According to our Internet Explorer support statement (http://kb.vmware.com/kb/2069870) packaged IE8 is supported by us and works on most platforms.
By Dean Flaming, Sr. Technical Marketing Manager | Lighthouse & EUC Enablement, End-User Computing, VMware
With VMware’s acquisition of App Volumes (formerly known as CloudVolumes), customers now have another option for deploying VMware ThinApp packaged applications. ThinApp packaged applications have always supported a variety of deployment options. So when it comes to using ThinApp packages with VMware App Volumes, what might be the easiest and best way to combine the technologies? And why would you want to do this?
With the ThinApp 5.1 release we introduced quite a few new features. This blog post is the first in a series where we will introduce and explain each feature more in depth.
The first feature to be examined a bit more closely is the feature we call Project to Physical or P2P. P2P is probably not the best name for it because there are billions of other features in the world using the same abbreviation. The Project to Physical feature does a ThinApp Setup Capture, but in reverse. Setup Capture captures an application—all its registry keys, files, and folders—and stores it in the ThinApp project folder. Project to Physical converts an existing ThinApp project folder into a natively installed application.
AppLink is a great feature of ThinApp. The possibility to merge two or many packages together allows for a much more modular deployment model. But how do your deploy your AppLinks?
I think we (read VMware) did ourselves a big disservice when we decided to add ;OptionalAppLinks=plugins\*.exe as a default setting in the package.ini file. Many out there now think it is required to use a folder called plugins relative to the parent package in order to use AppLink. This is far from true.
Do the Application Linking feature (AppLink) affect performance? Unfortunately the answer is, it depends.. Using AppLink will merge two or more Data Containers together. During this merge of the virtual environments, AppLink does its conflict resolution (learn more about conflict handling in AppLink here: http://blogs.vmware.com/thinapp/2011/03/the-power-of-applink.html) so yes, this will take some time to complete. Often this is not noticeable to the end-user though. One or two AppLinks are typically okay. Having 20 AppLink packages might be a little bit of a stretch. Then your end-users will start to notice a delay in start time. But..
By Aaron Black, End-User Computing Product Manager, VMware
I’d like to introduce a capability from our partner CloudVolumes, which allows ThinApp packages to be delivered as VMDKs. This is an exciting form factor because of the added performance and flexibility that any customer with ThinApp packages and a vSphere datastore can start utilizing today. There are a number of benefits with this approach which complement the isolation and cross-platform compatibility that application virtualization provides. Let’s highlight a few of them below:
Customers can now present ThinApp packages as dynamically attached volumes on storage instead of moving bits around the data center via the network (so ’90s . . .). This removes the network variable, which is often the limiting factor for scalability and performance for deploying ThinApp packages in streaming mode.
Entitlement to AD users and groups and ThinApp registration become immediate turnkey processes, driven through a centralized GUI, without any need for login scripts or for users to log in and log out for changes to take effect.
ThinApp packages retain their read-only property and can be mounted either in a shared fashion to multiple virtual machines or attached to virtual machines individually (on local storage as well). The ThinApp sandbox can also be made portable by utilizing writable CloudVolumes to fully enable the needs of the nonpersistent desktop.
This is not a VDI-only solution! ThinApp is used heavily on the RDSH platform for very dense application delivery environments, and the combination of CloudVolumes and ThinApp delivers a truly remarkable solution without trade-offs. Having administered my fair share of RDSH boxes, I really appreciate this angle!
This is an elegant solution that empowers IT to provide scalable growth, significant storage savings, and simpler application management, while end users benefit from the accelerated performance. So we worked with the CloudVolumes team to put together a framework for understanding the benefits and some test data that really shows the solution off. Please take a read HERE!
Not a reader? I understand :-). Check out the video at either YouTube or Vimeo, or scope out the diagram below for a conceptual view.
All – I’m pleased to announce that the ThinApp Factory has now taken residence on our VMware GitHub location. What started out as a Fling and garnered plenty of valuable feedback has now come back to the community as a freely downloadable and customizable technology to be used by customers and partners. We’ve de-composed the appliance itself and provided documentation that allows you to re-assemble on the distribution of your choice or you can simply use the components and build your own better faster mousetrap if you choose.