Home > Blogs > VMware ThinApp Blog > Author Archives: Aaron Black

Author Archives: Aaron Black

Aaron Black

About Aaron Black

Aaron Black is a VMware EUC senior product manager. Over 10 years with EUC, he has worked across a range of VMware Horizon technology. He shamelessly loves software and strives to be in the field with customers. Previously, he was a Citrix systems engineer, lead a Sprint technical corporate IT team and designed solutions for VMware and Citrix partners.

ThinApp Packages Can Now Be Delivered in VMDKs!

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.



ThinApp Factory moves into new home on GitHub

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.

ThinApp Factory on Github


ThinApp Puts On The Suit(e)

Last week, VMware made some major announcements with regard to the arrival of the Horizon Suite and the new pricing and packaging framework to simplify and unite the VMware EUC technologies for our customers.  This is a milestone for EUC because it marks a concerted effort by VMware to streamline the adoption and implementation of products into a solution stack that customers can easily procure and implement.

One of the changes that was announced is that at the end of the year ThinApp will no longer be sold as a standalone product as in the past.  Unfortunately, the product support life cycle has limited terms of description so the ‘End of Availability’ announcement has caused some some concern as some interpreted this as EOA of the technology.  I apologize for the confusion and want to clarify that the EOA term ONLY applies to the standalone SKU as ThinApp will actually be included in ALL of the Horizon bundles – VMware Horizon View™, VMware Horizon Mirage™, VMware Horizon Workspace™ and VMware Horizon Suite™.  A good place to get a feel for the bundles can be found here – Horizon Suite.  Being included across the Horizon suite means that more customers than ever will be able to use the features and capabilities of ThinApp.  The Horizon licensing model still allows flexibility for ThinApp to be used on the desktop without any other products if that is the use case needed by the customer.

I highly encourage you to consider the affinity between Horizon Mirage and ThinApp as we now have the capability to address every application on the Windows desktop; if you need apps with drivers and remote DCOM then use Mirage application layers, if you need cross platform support or isolation then ThinApp containers are ideal.  Not only do these technologies cover 100% of the application list but Mirage is an ideal deployment mechanism for ThinApp containers as it can deliver ThinApps to the farthest endpoints without any dependence on branch infrastructure, Active Directory, or costly backend architecture.  Customers can deploy layers and containers and then inventory those endpoints for centralized management of both native and virtualized applications.

To be clear to our customers (and competitors), our commitment to ThinApp technology hasn’t changed as we are actively working on our next release for mid-year which will include some very tangible architectural and compatibility improvements.  Here is an FAQ that has been created which should help address any particular details.

The . . . Definitive Guide for VMware ThinApp

Over the last four years I’ve been working with customers and partners on articulating and demonstrating the value of VMware ThinApp.  While ThinApp does offer one of the most flexible and streamlined solutions for virtualizing Windows applications there are still times when you need to put the product knowledge and the application expert together to get the results you want.  That has now occurred in written (and ebook) form with the release of the definitive guide for VMware ThinApp.  The title, VMware ThinApp Essentials, much like the author, is understated as you will find the relevance of this book greatly exceeds the ‘essentials’.  Yes, the author is one of our own VMware employees, but see for yourself that Peter Bjork always speaks to the reality of the customer environment and the satisfaction of well-implemented technology.  Leverage Peter’s dedication to the technology, wide spectrum of application experience, and commitment to help you extract the most value out of your investment in application virtualization.

Windows 8 Support with VMware ThinApp 4.7.3

On behalf of VMware, I’d like to announce that we have released version 4.7.3 of VMware ThinApp.  The big headline for this release is enabling ThinApp packages to run across the broadest spectrum of operating systems from Windows XP to the recently released Windows 8.  We’ve also updated the ThinApp Factory Fling to include the 4.7.3 runtime so that you can automagically package with the most current ThinApp version. Lastly, the ThinApp SDK has been rev’d to keep up with those of you creating some integrated offerings or just streamlining the registration of ThinApp packages. (see other blog entries about how to use the SDK)

ThinApp 4.7.3 is now available @  http://bit.ly/Is2ZvV
Release Notes @  http://bit.ly/T662Mv
ThinApp 4.7.3 SDK @  http://bit.ly/oZJD7h
ThinApp Factory @ http://bit.ly/MOqVp1

As always, we invite you to evaluate ThinApp and see for yourself how virtualizing Windows applications can simplify delivery and management.


Jumpstart your ThinApp Factory with Ninite

We are excited to announce that Ninite has provided VMware customers a trial feed for use with the recently released ThinApp Factory.  In short, the trial feed provides the ThinApp Factory a cloud-based catalog of 99 applications that can be pulled directly into the Factory and used to jumpstart our customers ThinApp Factory installations.  The process is incredibly simple and can even be described as 'fun' if you have geek DNA in your veins.

Steps to use Ninite to Jumpstart your ThinApp Factory

1.  Install Thinapp Factory Appliance   

2.  Add Ninite Trial Feed to your ThinApp Factory Instance

Continue reading

View and ThinApp Integration Guide – Part 3

I started a blog series on integrating View and ThinApp with these posts, Integrating ThinApp Packages with View Part 1Integrating ThinApp Packages with View Part 2, but I'm going to finish the series with a completed 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. 

While I believe that customers get the greatest value out of starting with ThinApp in their physical environment, its obvious that many of us are taking on desktop and appvirt simultaneously with the VMware View Premier bundle.  Much of the information in the guide applies to the physical environment as well but its the only doc avail today that completely focuses on ThinApp for View desktops.   

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

  1. Should I stream all my ThinApp packages from a fileshare or deploy them into the VMs?
  2. Where you I put my ThinApp packages? On the C:, the User Data Disk, a fileshare?
  3. How do I manage updates after the packages are in use?
  4. Will users keep their unique settings like toolbar buttons when running ThinApps from different desktops?
  5. How do I manage shortcuts and FileTypeAssociations for multi-user VMs?

There are additional documents for design and information on specific topics at these locations as well.  VMware ThinApp Reference Architecture , Streaming Information Guide, or Deployment Guide

Feel free to comment for all to see or communicate directly to aaronblack@vmware.com or aaronblack_vmw on Twitter

Integrating ThinApp packages with VMware View – Part 2

We are going to re-visit question 2 and 3 from Part 1, hopefully you’ve drawn some conclusions about which applications to stream and which ones to deploy over the last week or so.  Question 2 really deals with the question of where to put the thinapp packages which are your applications.  The options are A.  C: drive of guest VM  B.  User Data Disk or C. Fileshare.  Options A & B are for deployed packages and C is for streamed packages. If you’ve read this paragraph are lost already then make sure you read Part 1 and then come back to this post J 

For option A you’ll need to consider the specifics of the desktop pool, specifically the template that the VM’s are based off of if you’re using View Composer and whether this is a persistent or non-persistent pool.  When using View Composer its likely you’ll be doing a recompose and refresh operation periodically which will affect the linked clones off of the C: drive.  You can use that to your advantage because it is an opportunity to not just patch the OS but update the thinapp applications on the C: drive.  Consult the View Admin guide for the details of View Composer, but basically you are going to power on the VM that the other desktops are based off of, patch it, put some new thinapps in, and then take a snapshot.  At that point, you go to the View Administrator and say that you’d like for the desktop pool to now be based on that new snapshot.  In one fell swoop you’ve updated the OS and Applications.  For thinapps that you deploy in the vm its hard to beat this and there are very few downsides.  The limitation you do get is that updating only the thinapps has to be done using some other process, like a script that pushes the.exe’s out to a certain directory, or configuring the packages to use an AppSync url, or use a sw distribution tool to do the work for you.  So go through the process of a View Composer refresh and weigh that against the effort to update via the other methods discussed in Question 3.  Summary – View Composer + C:\ThinApps = very efficient OS and App management

Option B is slightly different in that it utilizes User Data Disks.  UDD’s are basically a separate vmdk (virtual disk file) that is logically attached to a virtual desktop.  I tend to think of them as the equivalent of USB drives as they are a different drive letter, can be moved between vm’s, and maintain more of the personal data such as profile, my documents, and typically user data.  (profile and my documents are automatically redirected here from the C drive)  So there is more of a separation between this location and the C:\ of the vm which is maintained by the Administrator.  The advantage of that is that users can have their own directory of ThinApps which can either be populated by the Administrator or they can drag over from a central location.  This gives the user some control over which applications they want to use but Administators will need to create a central directory of ThinApps for them to choose from.  So it’s not truly user installable apps because the administrator has to prepackage the app and virtualized apps are never installed anyway.  Summary – UDDs (D:\ThinApps) provide a location with a little bit more user liberty that is not affected by View Composer ‘Refresh’ or ‘Recompose’ operations on the template VM. 

Option C is for those apps that you have decided should be streamed.  A fileshare location is all that’s required but I’m a big proponent of DFS for this as a simple way to provide a logical link between your desktops and your virtualized applications.  When we get to Part 3 or Part 4 of this series we will get into the details of application registration, but at this point just know that it’s handy to be able to reference an entire directory of applications without putting in a server specific share.  Its probably reason enough to just mention that to provide a redundant fileshare is important and DFS is a simple means to do that.  The fileshare should be redundant and have plenty of bandwidth and locked down to read-only for users of course.  Summary:  Streaming Apps need to live on a highly avail fileshare with plenty of network throughput

Now for Question 3.  How do I manage updates to virtualized applications?  There are two methods of updating thinapp packages – Side-by-Side or Appsync. 

Side-by-Side is my personal favorite because it means simply placing a new package next to the older one and naming the newer package.1 or .2 or .3.  No downtime for update and easy contingency (just rename the file) built in to back out of update.  Another reason that side-by-side appeals to me is that it can be used on a central fileshare or on a local directory of thinapps.  Same update method for both deployed and streamed thinapps – the practicality appeals to me.

Appsync isn’t a bad mechanism either but its usually used to update applications that have been deployed on unmanaged machines out in the wild via a Https location over the Internet.  With AppSync you can centralize the updating ‘from’ location to a UNC location.  However, when using AppSync you need to incorporate the update ‘from’ location when you package the application so think through this before you distribute the packages.  The package.ini should include a line like this before you build the package – file://<server>/<share>/<path>/<package_name>.exe The major benefit here is that you can have decentralized packages that look to a central location for updates.  So there is no need to use something in the middle to actually distribute the updates.  This is probably the determining factor for whether you want to use AppSync or Side-by-Side.  If you have a mechanism to put a package.1 file in a C or D drive directory then Side-by-Side is a good option, if you don’t have a good distribution process or mechanism then use AppSync.

So those are the two methods of updating, let’s relate that back to our primary discussion of View desktops and the Options A,B, and C that we laid out above.  Keep in mind that these methods are only needed when you want to update applications for Option B or Option C when you aren’t using View Composer for application updates. Also, Option C is a little different because it’s a shared directory so Side-By-Side is your best option.

Summary of suggestions for how to update virtualized applications  

Option A. C:\ThinApps – Use View Composer for thinapp updates or Side-by-Side for application only updates.

Option B.  D:\ThinApps – Use AppSync or Side-by-Side

Option C.  \\Server\ThinAppShare – Side-by-Side  or just replace the package with newer version

Hopefully this will provide you a good framework to look through as you make your design decisions.  I’m looking forward to Part 3 where we will discuss some of the finer details like persistence of application settings and application registration.  As always feel free to comment or contact me directly via aaronblack@vmware.com or twitter:  aaronblack_vmw



Integrating ThinApp Packages with VMware View – Part 1

This is a common topic that I encounter with customers so I thought I'd put down some suggestions in a blog post. I say suggestions because you'll need to make some decisions that are unique to your environment. But before that let's list some of the questions that lead to this discussion . . .

  1. Should I stream all my ThinApp packages from a fileshare or deploy them into the VMs?
  2. Where you I put my ThinApp packages? On the C:, the User Data Disk, a fileshare?
  3. How do I manage updates after the packages are in use?
  4. Will users keep their unique settings like toolbar buttons when running ThinApps from different desktops?
  5. How do I manage shortcuts and FileTypeAssociations for multi-user VMs?

OK – I'll admit that I put those questions in a certain order for my own purposes. 'To stream or not to stream, that is the question', this comes down to a choice of centralized administration versus guaranteed performance. I need to clarify that by centralized administration I mean the beloved 'one to many' model that efficiency junkies crave. If you choose to stream ThinApps, you have one location to go to for deployment and update. For example, update one package and all the VM's will use the updated version on next application launch, add a ThinApp application and all AD groups authorized in the package will get a new desktop icon – you get all this without even touching the guest VM's, that's the centralized administration part. Now, when running in streaming mode, the guest vm's will load the necessary bits to run the application each time the application is launched. This means that performance is dependent on network speed and throughput between the guest vm and the file-share. Launch your apps and use Task Manager to see what the average payload is for each of your ThinApps, then take your network admin to lunch and ask him if the network can handle those payloads launched X times a day by Y users. A lot of VMware View environments are architected with a very healthy network and can accommodate this but you don't want to find out afterwards that your environment isn't one of those. So back to the guaranteed performance, if you choose to give up centralized administration and put the ThinApps in each of the guest VM's, your application performance will not be subject to network throughput. (however, the DISPLAY performance to the endpoint will be) You are 'guaranteeing' the cpu and memory resources from the local OS for minimal application launch time and optimal execution.

There is more detail to this discussion so if you'd like to skip to the diagrams and details then pull down the VMware ThinApp Reference Architecture , Streaming Information Guide, or Deployment Guide

So hopefully I've given you something to think about regarding the decision to stream or not to stream. If you're feeling some anxiety over this decision then let me say that most often customers determine that a hybrid approach is best. Streaming frequently updated line-of-business applications and deploying the MS Office suite into the guest vm's is very common. On my next post I'll delve into question 2 and 3 which will cover more specifics about when you choose not to stream and what to do if you change your mind . . .

Feel free to comment for all to see or communicate directly to aaronblack@vmware.com or aaronblack_vmw on Twitter

ThinApp Deployment Guide and Intro

Greetings to everyone – Aaron Black here – I've joined the ThinApp team here at VMware and have just completed my first project of creating a 'Deployment Guide' for ThinApp.  Download VMware_ThinApp_Deployment_Guide

The idea was to put together a document that provided a 1000 ft view to help someone beginning with ThinApp to understand the overall process and terms yet provide enough detail to help with some common queries like How do I integrate this technology? Recommendations on Streaming versus Deployed mode? and What do I need to get started?

Its great to be focused on application virtualization because I always ended up focusing on virtual desktops and applications anyway as a VMware systems engineer or in my previous career with Citrix. ThinApp, in my opinion, is a truly great solution with uncommon attributes of simplicity AND flexibility.

In my role at VMware in Tech Marketing, I'm given the charter of getting helpful ThinApp technical content out the door and into customers hands. So let me know if the Deployment Guide is a good start, feedback is greatly appreciated – you can either comment or send me an email directly at aaronblack@vmware.com