- 1 Originating Author
- 2 Video Content [TBA]
- 3 Introduction to ThinApp Factory
- 3.1 Download and Configure the Virtual Appliance
- 3.2 Download and Install the VMware Remote Console and Client Integration Plug-in (VMRC)
- 3.3 Create a ThinApp Factory “Workpool”
- 3.4 Adding Storage (for Output of ThinApps)
- 3.5 Adding a File Share (for input of Setup Programs)
- 3.6 Adding a JSON Feed (Setup.exe & Recipe)
- 4 Introduction to Setup Capture with ThinApp Factory
- 5 Publishing to the ThinApp Store
- 6 Conclusion
Video Content [TBA]
Introduction to ThinApp Factory
Version: Horizon View 5.1
Acknowledgement: We would like to specifically thank Peter Von Oven of the VMware EUC group in the UK for his review and additional information he supplied during the edit and review process.
We would also like to extend our thanks to Aaron Black, Alan LaMielle and Alejandro Guzman of VMware. They helped immensely in remotely supporting our installation and configuration.
This chapter was based around ThinApp Factory 0.3.0 that was distributed with the 4.7.1 release of ThinApp. Very shortly VMware will be refreshing the appliance to support the 4.7.2 release. However, cosmetically ThinApp Factory will retain the same look and feel.
We greatly recommend you work your through the ThinApp chapter before working with ThinApp Factory.
VMware ThinApp Factory (TAF) is a virtual appliance based solution that delivers a centralised administration and automation process for creating virtualised Windows applications using VMware ThinApp technology. ThinApp Factory utilises vSphere API's to spin-up workloads to automatically convert file shares containing application installers into ThinApp based virtualized application containers.
ThinApp Factory also adds a web user interface or dashboard to make editing the package.ini file much easier and the integration to allow the automated updating of the application data stored in Horizon, meaning packages auto update in a users workspace.
ThinApp Factory will need a location to store both the installers and the output of the ThinApp. This can be local internal storage on the appliance itself or else a CIFS share can be setup on an external system. As part of the post-configuration process you will need to create a workpool. Workpools are merely collections of Windows XP or Windows 7 virtual machines that are used during the setup capture phase. You can either use a existing VM for the source or provide your Windows XP or Windows 7 .ISO image and ThinApp with automate the install of the OS and its cloning with snapshots. Essentially, creating a linked-clone environment that contains the VMs in your Workpool. These multiple VMs inside the workpool allow you to capture many applications simultaneously.
Whilst ThinApp Factory is still a fling we are very much dependent on support from the community. The main ThinApp Factory Forum is here:
Community based JSON Recipes are available from here:
Finally, in recent weeks Innate has done some sterling work in gathering a whole host of applications that are freely available and adding JSON recipes for them. Ninite is website gathers different installers from the various ISVs and allows you to install them and update them from single UI. The JSON recipe for Ninite is located here:
Download and Configure the Virtual Appliance
ThinApp Factory is available as a download from the VMware Labs website. So the first step is to pop across there and import it into your virtual infrastructure environment. It can be download in two formats – a raw .OVF format that you can import from File, Deploy OVF Template or the with a setup.exe that guides you through the configuration process. We have tried both methods and given the volume of questions asked during the configuration we recommend using the setup.exe method. It is wizard based install process and it verifies many of the steps as it goes along, so you are less likely to make a mistake.
It does come with its own “installation guide” which we worked from as part of preparing to write this section:
However, we felt a blog based article had better documentation (and screen grabs too, what a concept eh?!?):
We really need VMware NOT to do this – because it will put authors like us out of business!
1. After the running the installer you will be asked if you want to deploy a new ThinApp Factory Appliance.
2. Then you will be asked if you want to deploy it to vSphere or VMware Workstation.
3. Next you will be required to provide the name and credentials of vCenter. One thing to note here is that the appliance does not support the use of the old-style DOMAIN\Username format.
4. Once the installer has enumerated your environment (which can take some time). You can select which cluster and resource pool you want to use. This controls the location of both the ThinApp Factory appliance and any VMs that are created in its workpools.
5. Next, set a datastore to hold the appliance and the workpool VMs.
6. Next, set the hostname for the appliance itself.
7. Next set the portgroup for the virtual appliance.
IMPORTANT: ThinApp Factory does not currently support creating workpool VM VMware’s Distributed vSwitches. Remember the workpool VMs are just workhorses used to create ThinApps. When they finished with their work their snapshot is reverted and they are powered off. So they have a largely ancillary function in ThinApp Factory
8. Next, set the IP configuration for the ThinApp Factory appliance
9. Finally, input your ThinApp licensing string and the license display name that will be shown whenever a ThinApp is launched from the ThinApp Store.
IMPORTANT: Be careful here in using evaluation licenses that expire within a 60-day period. Without a valid license all though ThinApp Factory will capture the application installation, it will fail to execute the build.bat script within the workpool VM.
TIP: At the end of the installation you can save your installation settings to a file. These can be reused to install multiple instances of the ThinApp. The file has an AFSP extension, and can be opened in a text editor. An interactive install can be triggered by dragging and dropping the .AFSP file on to the ThinApp Factory installer or non-interactively by running the ThinApp Factory Installer together with the path and filename to the .AFSP file.
We think most of this is pretty straightforward. However, you do need to think about the right size datastore for the ThinApp metadata. The appliance is 500GB in size when deployed in “thick” format, and about 138GB in a “thin” format. You will also need to calculate the number of Windows XP or Windows 7 VM’s that you will create in a workpool. As you might recall, workpools are collections of VMs that are used in the packaging process. The bigger the number of VMs in the workpools the more simultaneous ThinApp builds you can achieve. You may need at least two pools for applications that can only be captured in Window XP or Windows 7. VMware recommends you allow for about 20GB for each VM you add to the workpool. Finally, you need to think about the space required to install and build into ThinApps. The recommendation is to start with about at least 80GB of space.
Finally, by default the “admin” account used to manage the appliance has no password. You can use the console to reset this or after installation, log into the appliance under “Settings” and “Administration”.
Download and Install the VMware Remote Console and Client Integration Plug-in (VMRC)
This plug-in extends your local machine with the tools needed to connect to the console of the VM. It’s required if you want to do any “manual” captures. This is where TAF kicks off a setup.exe, but you, as the administrator, interact with the installation routine for those applications that are too difficult to capture in an automated way or for the ones where no recipe exists. Of course in the ideal world you might wish to take what you learn about this manual process and automate with recipe. Ideally, you would share these recipes with other people within the TAF community.
Create a ThinApp Factory “Workpool”
Workpools are collections of virtual machines that are used to process the setup.exe or installation process you provide from other ISVs, to be converted into ThinApps. Workpool VMs are only needed during the primary setup capture phase. After all only Windows can run a Windows installer. However, once captured – if at later stage you make a change to the ThinApp – say for example you modify the package.ini settings – you only need to run a rebuild option from the appliance. This rebuild process executes on the virtual appliance, not within the context of a workpool VM.
There’s a couple of ways of generating these VMs that make up the workpool. You can supply an existing VM say one newly created from a template, or alternatively from your ISO store you can supply a Windows XP or Windows 7 .ISO file from which an unattended installation can be done for you. If you are using an existing machine ensure that it’s a clean vanilla build with no pre-existing software installed that could cause unexpected outcomes in the ThinApp capture process. We would recommend using a .ISO image as this guarantees a clean install.
1. Login to your instance of the ThinApp Factory VA using a web-browser pointed at either its IP address or FQDN such as: http://appfactory.corp.com
2. Click the Settings link in the top-right hand corner, and in the “Workpool” tab select “Add”
3. Once the web-page has opened you can give the Workpool a name and select the number of instances in the pool you want to use. The number of instances is basically the number of VMs that could be spun up simultaneously to process the packaging. One tip here is to ensure you have enough infrastructure resource to accommodate this. Selecting the option to “Use ISO to create a new VM” updates the web-page to allow you select the OS type, set the license key, registration name, registration company name– as well selecting a network and datastore for the .ISO file.
4. After clicking Save, then ThinApp Factory will spawn a new VM, and automate installation of the guest operating system
Adding Storage (for Output of ThinApps)
By default the ThinApps created in the factory are stored inside the appliance. If you have large number of ThinApps this can quickly fill up and so it is a good idea to save these to a CIFS file share. That way it can also be backed up and should you need to rebuild the appliance for some reason; all the packages you have created are external to the appliance. To add a ThinApp Storage location:
1. Click the Settings link in the top-right hand corner, and in the “Storage” tab select “Add”
Notice how ThinApp Factory ships with a 20GB of free space in a “packages” share. If you are adding in alternative storage remember to set it as the default location.
2. Next provide the friendly name and a file sharing type (currently TAF only support CIFS). Then provide the shared location in a UNC format together with the username and password.
3. Once added you can change the default storage location away from the internal storage of the VA to new external location.
Alongside setting a location for the output of ThinApps, it’s possible to copy all your setup.exe’s to a file share, and mount this to the ThinApp Factory Appliance. If you are using JSON feeds – very often these feeds contain where to download the setup.exe from and how to install it. So this shared location is really for software that you run internally. Of course you could use a combination of both.
You have the option when adding a setup share to automatically start the capture process for all the .EXE files discovered or alternatively triggering that on an application-by-application basis. To add files share for your setup programs:
1. Click the Settings link in the top-right hand corner, and in the “File Share” tab select “Add”. As you might expect the configuration is similar to the options we saw above.
Watch out for the option “OK to convert”. If enabled this would trigger an automatic capture of any setup.exe into a ThinApp capture process. This option can be re-enabled at any time if you so wish.
2. Once the form is completed, you can click the “Scan” button –this mounts the file share and starts to look for .EXE files residing within the share. This generates a list of all the .EXE files found:
In our case we choose to skip FileZilla 3.5.2. By default we found fields of name, version, vendor, revision, language were blank. These appear to be option components – but we think filling these out will be very useful elsewhere in ThinApp Factory.
3. Once you are done, click Save'.
If you add more .EXE files to the share, all you need to do is log into the appliance, and the share will have a “Re-scan” option. This checks the share again and those new .EXE’s will be flagged up as “New” in the UI.
These “command” fields are pretty important. Without additional setup.exe switches most installs we open in a graphical mode and then wait for user input. This rather defeats the object of ThinApp Factory because what we are really looking for is a silent installation. ThinApp Factory does support a “manual” mode for difficult to package applications which need a human operator to be involved.
Historically, this sort of command line information has been difficult to find. Fortunately, there’s a growing community of ThinApp Factory users who are sharing what they learn and are packaging up their solutions in the form of “recipes” in the JSON format.
However, IF you do know how to supply the command-line switches to an installer so works silently – you can replace the $appfile text with those parameters. For example Filezilla has simple /s switch to carry out a silent installation like so:
Note: For this work FileZilla needs space before /S
Despite this ability to automate the installation – the real benefit of using ThinApp Factory is locating pre-made recipes in the JSON format. Where you do not need to find the installer setup.exe program or hunt around on the Internet looking for command-line switches.
Adding a JSON Feed (Setup.exe & Recipe)
Another way of adding a setup.exe and recipe to ThinApp Factory is using what are called JSON feeds. A JSON feed can contain just the recipe, or it can contain the setup.exe download and the recipe. Most community based JSON recipes require you to download the setup.exe separately as regulations stop the free distribution of software independently of the ISV. Vendor based JSON feeds often contain both because as the owner of the software they have automatic distribution rights.
A good example of this is the VMware View Client JSON feed. All you need to add a feed is a friendly name for the entry, and URL to the JSON file. The JSON file is just a plain text .XML file that contains the metadata needed to process the conversion process. Remember the great thing about these feeds is that ThinApp Factory can rescan these locations – and automatically download and convert the software for you.
1. Click the Settings link in the top-right hand corner, and in the “Feeds” tab select “Add”.
2. We found the feed details on the ThinApp forum here:
The URL below contains the URL to the VMware View Client Feed and Recipe information.
We typed in a friendly name for the feed, and cut and pasted the URL directly above.
There are recipes for other applications which you can find in the “documents” tab on the ThinApp/ThinApp Factory forum:
Many of these recipes have actually been submitted by folks from VMware who work within the EUC/ThinApp Team including Arron Black, Squidly Man (Dean Fleming) and guzmana1 (Alejandro Guzman).
Introduction to Setup Capture with ThinApp Factory
Setup Capture without a recipe
Now we have all our sources (.EXE share and JSON Feeds) and destinations (CIFS share location) in place we can now proceed to asking ThinApp Factory to generate ThinApps for us. If you navigate to the “Installers” tab you can see all the sources we have added so far:
1. Select the installer in the “Installers” tab
As you can see under “Installers” on the right-hand side there are a number of options and views. The “Upload Installer” allows you to upload a.EXE file that you have downloaded to the ThinApp Factory, when you do this a dialog box will appear that allows to you to browse to the .EXE, and also add some of the metadata that we saw after the scan of our file share.
2. If you are ready to create a ThinApp all you need to do is select it from the list and click “Capture”. We started with an application that we thought would give us little trouble – just to test our configuration.
3. After clicking the capture button the web-page will refresh like so:
The “Pick Recipe” option allows you to apply preconfigured options for the Setup Capture. The reason it says there is 1 recipe here comes from our import of the View Client JSON feed previously. On the right-hand side you can select your preferred workpool, ThinApp Version and Project Location. Clicking the “Auto Capture” button starts the process off. You can follow the capture process by following the status option in the bottom right-hand corner.
As well as in the Running Tasks page:
Running multiple conversions causes ThinApp Factory to spawn another instance from within the “workpool” – based on your settings for the size of the workpool VMs, you might find that tasks are in the “queue” whilst ThinApp Factory waits for a VM in the pool to finish its current task and become available
Setup Capture with Recipe (VMware View Client)
Earlier in this section we added a JSON Feed for the VMware View Client – that includes both the software and recipe. The feed actually contains four different versions of the client:
We will carry out a Setup Capture of the 5.1.0 release, in keeping with the current version of the client software.
1. Select the 5.1.0 release in the “Installers” tab, and click the Capture… button
Note: The ignore button allows you to hide an .EXE that appears in the list that you don’t want to display.
2. In the next windows, click the Pick Recipe button
3. Select the View Client Feed Recipe and click the Pick Recipe button
Notice the “Add New Recipe” button that allows you to add JSON Recipes that contain just the recipe without the software. Use this to add community based recipes
4. Once selected the recipe opens up to allow you to add variables to the capture process. Most of these are “logical” such as DESKTOPSHORTCUT, QUICKLAUNCHSHORTCUT and STARTMENUSHORTCUT and accept a Boolean 1 or 0 value to indicate if the ThinApp is “installed” or whether a short cut is created. Whereas ADDLOCAL controls what components are installed or not, such as ThinPrint or USB. The VDMSERVER is optional and allows you to pre-set the URL for the View connection server..
5. Once you have selected your options and provided the variables, you are ready to click the Auto Capture button. In our case we used the variables 1, 1, 1, Core and view.corp.com
If you are running ThinApp Factory on vSphere it is possible to open a console window on the “Workflow” VMs and observe the installation process. Some JSON recipes are totally silent (so you don’t see any on screen activity). Others default to showing status windows. Occasionally error messages are displayed in the console which you might find useful in troubleshooting.
Setup Capture with Multiple Installers
In the “Installer” tab if you select more than one setup.exe to be captured, you will see a slightly different UI which allows you to allocate the right recipe to the right setup.exe and also provide any variables required.
Manual Capture Mode
For those applications that remain stubbornly difficult and troublesome to capture there is always the “manual” capture mode. This requires the VMware Remote Console to be installed on the management PC that you use to access the ThinApp Factory web pages. It adds itself as an extension to your web-browser, and is triggered when you hit the “manual Capture” after selecting an installer to capture in the “Installer” tab.
The first time you click the “Manual Capture” you will have to enable the plug-in and also allow pop-ups to be allowed for the ThinApp Factory web page. Once completed you should find the VMRC opens and takes you through the five stages of – preparing, customize VM, Pre-capturing, Install and Finish.
The “Next” button at the top of the VMRC allows the administrator to move the progress on to the next stage, until you’re ready to run the installer itself. Notice how the VM in the workpool maps a drive to your store of setup.exe files added under the storage tab earlier.
After the installation process has completed and after you click Next, ThinApp Factory will close the VMRC window, and return you to the “Task” tab that shows the progress of the ThinApp build process.
Custom Package.ini Settings and ThinApp Factory
Once an application has been through the “setup capture” and build process it is possible to make edits to package.in. Such edits will require a rebuild of the application. Typical reasons to edit the package.ini would be is making the ThinApp support MSI Streaming and create a .MSI installation file. Essentially, the same settings that you would see in the package.ini in say notepad, can be added to the package.ini.
Alternatively, you might find a ThinApp Factory control the enabled entry-points generated during the setup capture. For example if we use Acrobat Reader JSON this doesn’t create an .MSI file and creates additional entry points that are unwanted.
Note: The screen grab above shows the .dat file and the Adobe Reader X.exe file – but the AcroBroker.exe, AcroRd32Info.exe and PDFPrevHndlrShim.exe entry-points that are not actually needed Finally, you might want to control if ThinApp Factory generates shortcuts on the desktop or in the programs location on the Start Menu.
1. Click the Settings link in the top-right hand corner, and in the “Feeds” tab select “Add”.
2. We found the Adobe Acrobat feed details on the ThinApp forum here:
The URL below contains the URL to the VMware View Client Feed and Recipe information.
We typed in a friendly name for the feed, and cut and pasted the URL directly above just by right-clicking the download link and selecting “Copy Shortcut”
3. After a short while Acrobat Reader should appear on the “Installers” and you can select it and the recipe
4. To modify the ThinApp’s package.ini you need to select the ThinApps “name” in the Projects tab
5. This should open a page that will allow you modify the package.ini file and carry out other modifications. In our case we selected the BuildOptions category in the “Sections” column
6. New values can be added to the "BuildOptions” by clicking the “New Value” button
7. This produces and edit box that allows you set new build options. In our case we need to add the settings that would allow us to enable ThinApp Streaming and also generate .MSI. Remember this is requirement if you want to use VMware View 5.1 “ThinApp Templates” assigned to a desktop pool, and also want to stream the application to the desktop.
You can carry on adding the required parameters for MSI building. Once finished you can click the “Save Package.ini” button. When you return to the Project tab, you should find that the ThinApp enters the “Staged” status with message indicating it is need of rebuild.
9. To disable the unwanted entry-points of AcroBroker.exe, AcroRd32Info.exe and PDFPrevHndlrShim.exe. You can either delete them or add the value Disabled = 1
10. Shortcuts are generated on a per entry-point level. If we select the “Acrobat Reader X.exe” section you can see that it set to create shortcuts for desktop and programs
By removing the reference to %Desktop% we can inhibit the creation of shortcut on the desktop if the ThinApp is installed, registered or delivered by Horizon Application Manager
11. Once you have made the required changes – select the ThinApp and click Rebuild
These changes should result in entry-points being removed, and .MSI file generated.
Publishing to the ThinApp Store
ThinApp Factory does have its own “ThinApp Store”, in these early stages we think it would be fair that its is relatively rudimentary, and intended for demonstration purposes. There is no ThinApp streaming available via the ThinApp Store currently – to stream a ThinApp directly from web-based portal, you would need to consider the VMware Horizon Application Manager. For now the ThinApp Store is has “http” delivery process that use a “launch” to facilitate the download and install of the ThinApp to the local machine. This does require that the user has administrator rights. If you intend to use ThinApp Factory in a production environment we would directory to many different ways by which ThinApps can be distributed. These include (but are not limited to):
• View ThinApp Templates
• Logon scripts with ThinReg
• Microsoft AD Software Distribution Policies
• VMware Horizon Application Manager
Once the application has been captured to ThinApp Factory it will enter a “staged” area.
This is intermediary step design to ensure that ThinApps don’t automatically become available to end-users. ThinApps can be published to the ThinApp Store merely by selecting them, and clicking the Publish button. The “unpublish” button can be used to remove ThinApps from the store. If you select the ThinApp under the “name” column, this allows for advanced options such as the package.ini settings to be exposed. We will look at example of modifying the package.ini settings in the next section.
After changes have been made the ThinApp can be updated by using the “rebuild” button under the Packages tab.
Users can gain access to the ThinApp Store by browsing to the URL for the ThinApp Factory followed by /store – for example our store is referred to as:
This URL is not secured and does not require authentication, and when the user selects a ThinApp in the windows its background turns green indicating that it is selected. This then shows the “Get Applications” button. Clicking this generates a “setup.exe” that can be downloaded to “install” the ThinApp.
Despite the fact that ThinApp Factory is just a “fling” at the moment – it does substantially streamline the “Setup Capture” process. It will be of particular interest to those people who support a large number of applications that frequently are updated and upgraded by vendors. Keeping all your packages up to date can feel at times like painting the Golden Gate Bridge. Just as think you have got to the end of the process its start all over again.
There’s some way to go with ThinApp Factory for the moment. We would love to see all those package.ini settings turned into simple radio buttons – making the process of capturing and configuring a Thinapp something that’s accessible to all, and doesn’t require a whole amount of packaging experience. Sorry, for folks in specialist “packaging teams” – but we feel the packaging process needs to be simplified for the masses. It will be interesting to see what happens to the ThinApp Store. We suspect their will be a latent demand for quick and dirty “app store” that’s only available internally, and allows for either an install or streaming of the Thinapp. Whether we will see that depends – some might it regard it as treading on the toes of Horizon Application Manager. ThinApp Factory does integrate with the Horizon Application Manager service produce by VMware. And that’s where were headed next. It’s our last big chapter!