Finally, the wait is over. After years of no significant releases VMWare have now released ThinApp 5.0. But is it too little, too late? I first started using ThinApp about 5 years ago. At the time I compared it to Softgrid\App-V and it was quite exciting. It was the first time I saw this concept of a portable virtual application. It’s isolated just like an App-V application but doesn’t require a client! It seemed great. What’s more, some applications I couldn’t capture successfully with App-V, worked with ThinApp, another win!! The VMWare trainer even had an old copy of Doom which he had captured as a ThinApp and could bring with him and run anywhere. I was sold. This was something I was interested in and wanted to use.
Unfortunately for me at the time. Enterprise customers were not really adopting this technology. In fairness, at the same time not very many were embracing App-V either. It was still so ‘bleeding edge’ that it was considered a risky venture with more risk than reward. As time went on App-V got ahead of the pack, likely because Microsoft had such a strong presence in the Enterprise already and may have been seen as less of a risk. In my opinion, they also did a great job of encouraging people like me to collaborate and get involved with the Online community. It then became the case, that ThinApp seemed to be the third most popular Application Virtualization technology, behind App-V and XenApp Profiling. What I was hearing from peers was that ThinApp was not designed for large Enterprise. This was later reflected by the fact I worked with a few customers who required ThinApp ‘Packaging’ but these were for a very low volume of apps and also for a very low volume of users.
Fast forward to the present and XenApp Profiling is no more. ThinApp now has an void it can fill and climb into second place. XenApp Profiling had a very limited use and also did not receive a whole lot of development focus by Citrix, it was just something that you could use, they never seemed to encourage it’s use. In fact, Citrix released a statement with the tag line along the lines of ‘Use App-V, no, go ahead, really’. They have continued on with this notion and have fully embraced App-V which is now integrated. Unfortunately, as my opening remarks may have suggested. VMWare also did not focus much development on ThinApp. I hadn’t used the product in 3 years, when I did use it again pretty much nothing had changed and most disappointing of all, the product could not support 64-bit applications! Well that has changed.
Setup
Like with all capture tools, you’ll want to setup the capture tool on a Virtual Machine with snapshotting capabilities, this is to ensure you can revert the machine quickly to a clean state after each application created to ensure a consistently clean environment to capture in. You may also want to disable Windows Updates and any other services which may interfere with captures. Note: If supporting 32-bit and 64-bit Operating Systems, you should capture your 32-bit applications on a 32-bit virtual machine, not a 64-bit VM.
Launch the installer
The Setup will launch
Click Next
Enter a valid License Key and the name you wish to appear on the title screen. E.g. Your company name.
Click Finish
Create a Virtual Application
Launch Setup Capture Tool
You’ll see that the Setup Capture tool will being to launch, this is actually a ThinApp tool thus the VMWare notification over the taskbar
Click Next>
On the above screen you have the option to click on Advanced Scan Location
The options checked are where the tool will scan. It’s likely you won’t need to change this for 99.9% of your applications. Click OK and then Click PreScan
Like in previous versions of ThinApp, there’s an Internet Explorer button if you intend to virtualize IE. IE 10 64-bit and 32-bit are now supported by VMWare. For any other application, go ahead now and install and configure the application. Then click Postscan>
Click OK
The Postscan will be carried out which will basically do a comparison of the state of the machine when the first snapshot was taken, anything which has changed on the system in the mean time will be identified as part of the app and added to the virtual package.
Check any shortcuts you wish to include in your package. If you’d like to include debug entry points for troubleshooting purposes (an in, into the virtual environment to see the contents of the package and possibly run commands in the virtual package) check the ‘Show entry points used for debugging’ checkbox. Click Next>
If you intend to manage the app with Horizon Workspace, another product form VMWare, you can go ahead configure that here. This enables central management of VMWare ThinApp applications for your virtual application end users, it also enables the ability to stream applications with ThinApp.
If you’d like to lock down an application (possibly due to licensing restrictions) you can lock it down using AD Groups here. Or you could allow it to be used by Everyone. Click Next>
By choosing Merged isolation Mode, you ensure the virtual application will be able to write to the local machine and read from the machine as needed.
Restricted ensures the application can only write to user writable locations such as the Desktop and My Documents. All other run time files\registry will be written to a user sandbox.
Click Next>
If you’d like to make the application completely portable it’s a good idea to write the sandbox to the same directory that the app is run from. You could also write to a network drive, perhaps a user\home drive. Alternatively you can set this to write to the User Profile, which is the default. Click Next>
Like with most products, you opt to send real time feedback to VMWare or not. Click Next>
The Inventory name is just a distinguishing name for identification purposes which will appear in the Package.ini file created with the application. The Project Location is where the output will be saved to. Click Next>
Select the container option. An entry point creates the application into the .exe entry point as normal. This .exe is self contained, it’s one file which you can carry around and execute from a Windows machine and run the application. The .DAT file container, I believe and I’m not sure is due to some limitation with larger applications, I believe there’s some issues which can arise when capturing larger apps as just .exe, when choosing the .DAT option you’ll notice the .exe entry point files for each shortcut of the application will be very small in size, while the .DAT file will contain the virtual file system and so will be larger. This .DAT file will need to be in the same directory as the shortcuts when launching.
You can generate an MSI, this is great for deploying the virtual applications with a Software Distribution tool such as Marimba, LANDesk, SCCM etc.
You can also choose to compress the package to reduce the size and thus save money on storage space.
Click Save>
Clicking Open Project Folder will bring you to the output folder which contains the bin folder (contains all entry points and dat file if selected) all Registry key text files, mimic variabilized folders for the file system and finally the Package.ini file which is the main project file, this contains a lot of fields which you can change to your liking:
[Compression]
CompressionType=Fast
[Isolation]
DirectoryIsolationMode=Merged
[BuildOptions]
;——– MSI Parameters ———-
;Enable MSIFilename if you want to generate a Windows Installer package.
MSIFilename=Test.msi
MSIManufacturer=Rorymon.com
MSIProductVersion=1.0
MSIDefaultInstallAllUsers=1
MSIRequireElevatedPrivileges=1
MSIInstallDirectory=Test (VMware ThinApp)
;MSIProductCode={796E1704-
MSIUpgradeCode={B75275A3-E674-
MSIStreaming=0
MSICompressionType=Fast
MSIArpProductIcon=%
MSIIs64Bit=0
;——– AppSync Parameters ———-
;AppSyncURL=https://example.
;AppSyncUpdateFrequency=1d
;AppSyncExpirePeriod=30d
;AppSyncWarningPeriod=5d
;AppSyncWarningFrequency=1d
;AppSyncWarningMessage=This application will become unavailable for use in %remaining_days% day(s) if it cannot contact its update server. Check your network connection to ensure uninterrupted service.
;AppSyncExpireMessage=This application has been unable to contact its update server for %expire_days% day(s), so it is unavailable for use. Check your network connection and try again.
;AppSyncUpdatedMessage=
;AppSyncClearSandboxOnUpdate=0
;——– Parameters used only during Setup Capture ———-
AccessDeniedMsg=You are not currently authorized to run this application. Please contact your administrator.
CapturedUsingVersion=5.0.0-
CaptureProcessorArchitecture=9
CapturePlatformVersion=0601
CaptureOSArchitecture=64
OutDir=bin
;——– General Purpose Parameters ———-
SandboxName=Test
InventoryName=Test
InventoryIcon=%SystemSystem%\
;PermittedGroups=
;RemoveSandboxOnExit=1
;RemoveSandboxOnStart=1
;SandboxNetworkDrives=1
;SandboxRemovableDisk=1
;
;OptionalAppLinks=plugins\*.
;RequiredAppLinks=\\server\
VirtualDrives=Drive=c, Serial=943608ef, Type=FIXED
;VirtualDrives=Drive=a, Serial=00000098, Type=REMOVABLE; Drive=c, Serial=943608ef, Type=FIXED; Drive=d, Serial=943608ef, Type=CDROM
;VirtualComputerName=
AnsiCodePage=1252
LocaleIdentifier=1033
LocaleName=en-US
; If you have problems running a 32 bit application under 64 bit Windows, try enabling this line before building the project
;Wow64=0
; If you have problems running a mixed 32/64 bit application under 64 bit Windows, try enabling this line before building the project
AltArchitectureShortcut=0
; Enable this option to load .Net binaries from the system instead of the package on Windows 7 or above
;LoadDotNetFromSystem=Win7
QualityReportingEnabled=0
; Enable this option to ignore DDE messages from external processes
;IgnoreDDEMessages=1
[cmd.exe]
Source=%SystemSystem%\cmd.exe
;Change ReadOnlyData to bin\Package.ro.tvr to build with old versions(4.6.0 or earlier) of tools
ReadOnlyData=Package.ro.tvr
[regedit.exe]
Source=%SystemRoot%\regedit.
Shortcut=cmd.exe
As you may see in bold above, there’s several options with the Package.ini file that now provide controls for 64-bit applications. At this point it’s important to highlight that if you are supporting both 32-bit and 64-bit Operating Systems, it’s best to capture the 32-bit applications on a 32-bit OS and not a 64-bit OS.
In this Package.ini file just like in previous versions you can see that you can change things as trivial as the name of the MSI, Where the MSI should install the virtual application to. But can also take care of more advanced things such as Required AppLinks (application dependencies that must be present for functionality of the app) and Optional Links (application dependency which is not required but can be used in conjunction with the app, so if it’s there allow the apps to interact)
There’s also the AppSync configuration, this is to enable you to ‘stream’ any application upgrades required. It’s not like App-V or Symantec Workspace Streaming, it’s not quite that sophisticated but it can work in certain cases for streamlining small application upgrades.
Once you’re happy with the settings in the Pakckage.ini file save it and Click Build.
The app should now be built. Click Finish.
You should now have your MSI and entry points in the bin folder which you can use to deploy or simply launch the .exe’s to test.
Templates and Utilities
Unfortunately from what I can tell, it doesn’t look the utilities have changed much. There’s now extra Group Policy Templates file compared to the last version (not just an .adm but also .admx and .adml etc) for controlling the virtual IE behavior, other than that, it looks like the only change is that the tools now work for 64-bit. But again, I haven’t used these tools in any meaningful way, quite yet.
My old buddy SBMerge is still there. You can read more about that HERE All of the same utilities are still there, the log utility for troubleshooting, the relink tool can be used to upgrade old applications to use the newest ThinApp (embedded client), ThinReg for registering the application COM, shortcuts, FTA’s etc. Obviously ThinDirect is back as that’s instrumental in the virtual IE’s, especially when trying to support older versions of IE. If you can remember, ThinDirect can help ensure a web app which may only work in say IE8 and not IE10 or 11 will only run for the user on a virtualized IE8. So if they open IE10 on their machine and type in the web address or go to their favorite for that web app, it automatically get’s redirected and run in the virtualized older version of IE8, all seamlessly.
There’s also a template MSI file which you can try to configure to conform to your company standard. I had mixed success with this in previous versions, it seemed to corrupt the MSI.
Conclusion
With ThinApp 5.0 we get 64-bit compatibility and Windows 8.1 compatibility. We can also virtualize IE 10 and Office 2013. Which will benefit current customers greatly. Version 5.0 boasts a changed architecture, applications now use ntldll.dll hooking, which sounds like it may allow applications to be more closely integrated with the system at the Kernel level, the product is too new for me to confirm what the implications of this are but I would think it should mean better compatibility of applications. Though, I have yet to see this in my own testing. Unfortunately drivers still do not work. In honesty, thus far I haven’t noticed any of my former problem apps now working…yet. As I use it more, I’ll be sure to post a few blurbs about the successes and\or failings I encounter with this. A few months ago VMWare announced that they were going to stop providing ThinApp as a standalone product and instead would only sell it along with other products such as Horizon, they later retracted this and decided to provide it standalone. With this release and the fact, there’s no real evident significant changes to me, maybe that makes sense. If you use ThinApp with Horizon you benefit much more greatly than using it standalone, you get better benefits with streaming, easy central management and a more ‘dynamic’ experience. It’s certainly quite attractive for a VDI environment. As for ThinApp 5.0 as a standalone product, I will reserve judgement until I can throw more problem applications at it.
