I was recently working on setting up a proof-of-concept of ThinApp for a customer. The customer wanted to compare Horizon Hosted applications and ThinApp applications. To be fair, from an end-user perspective, there is little to no difference between Hosted applications and ThinApp applications, therefore providing a proof-of-concept will most likely be of little use. The real difference is in the technology and how the application is delivered to the end-user. When trying to decide between Hosted applications and ThinApp applications, some of the questions that need to be asked include:
- Who will manage both new and existing applications?
- What kind of applications are you using? Legacy applications? Software-as-a-Service applications? Cloud or Web applications?
- Will users require offline access to applications (no LAN connectivity)?
- Will users require access to applications from a tablet or mobile device?
- Will the application work in a shared environment, where multiple users are accessing the same executable file?
The application I plan on using for this proof-of-concept is Microsoft Office. While working with the Microsoft Office 2013 ThinApp that I created, I ran into a few issues. This article will detail some of those issues and how I resolved them. This article is not a comparison of Hosted Apps vs ThinApp, although that does sound like a good topic. Perhaps I’ll save that for a later article.
I should first state the goal of the proof-of-concept. The customer is already aware of the differences between Hosted applications and ThinApp applications. Within ThinApp applications, the customer prefers the Streaming Deployment model of ThinApp. The way the Streaming Deployment model works is the ThinApp of the application is created and the administrator creates a shortcut to the application executable. The shortcut points to a location on the network, such as a file-share. The end-user sees the shortcut on their desktop and when launched, launches the application executable from the network. A benefit of this approach is that the application can be updated in one place and all users receive the updated application. You can use the Streaming Deployment model in conjunction with application management tools such as Group Policy and SCCM to control the deployment and configuration of the application shortcut.
The first issue I ran into occurred after I had already created the application package in ThinApp. I needed to update a setting within the Package.ini file. The Package.ini file is the brains behind the ThinApp’ed application. You can modify the Package.ini file at any time, however in order for the changes to be recognized by the application, the application package must be rebuilt. In order to rebuild the application package, you must execute the build.bat script. The build.bat script is located in the same directory as the application package. The build.bat script does require that ThinApp be installed, therefore you may have to run it from the workstation or virtual machine you’re using to package applications.
The other issue I ran into occurred when I tried to run the application when double-clicking on the application shortcut. I received a pop-up that the Horizon Agent must be installed. This didn’t make sense to me so I did some research. While I was building the application, I specified a Horizon Workspace Portal address. Since I specified these settings, the ThinApp’ed application was expecting to be managed by Horizon Workspace. In order to fix this problem, all you need to do is modify the Package.ini file and make sure the following 3 lines have no values.
- AppID=
- NotificationDLLs=
- HorizonOrgUrl=
These lines are located in the VMware Workspace Portal Parameters section of the Package.ini file. After making changes to the Package.ini file, remember that you must rebuild the Package using the build.bat script (see above). This issue is outlined in VMware KB 2052718.
I will share any additional speed bumps that I run into. Also, I am anxiously awaiting the release of AppVolumes (formerly CloudVolumes) under the VMware name. This will provide yet another way to package and deliver applications to end-users. Why is this important? As Paul Maritz said a long-long time ago (I believe VMworld 2010), it’s all about the apps.
