Virtual Applications with ThinApp
- 1 Originating Author
- 2 Video Content [TBA]
- 3 Introduction to Virtual Applications with ThinApp
- 4 Getting Started with ThinApp
- 5 Introduction to Registering ThinApps
- 5.1 Registering ThinApps to View Desktop Pools
- 5.2 Registering ThinApps with ThinReg.exe
- 6 Capturing Internet Explorer 6 and Managing ThinDirect URLs
- 7 Controlling URL Redirection with ThinDirect & Microsoft Group Policies
- 8 Rebuilding a ThinApp with Custom Package.ini Settings
- 9 Managing File Associations
- 10 Managing Upgrades and Updates
- 11 Managing ThinApp MSIs
- 12 Other ThinApp Utilities
- 13 Conclusion
Video Content [TBA]
Introduction to Virtual Applications with ThinApp
Version: Horizon View 5.1
Acknowledgement: We’d like to this opportunity to thank Peter Bjork and Peter Von Oven of VMware for their help whilst writing this chapter.
We are now moving on to a whole other aspect of VDI, and that’s the virtualization not just of operating systems but the applications as well. There are many different application virtualization vendors out there on the market, and you are by no means restricted to using VMware ThinApp. You could investigate the use of tools such as App-V from Microsoft, Spoon, and InstallFree. When used effectively you will come to see the virtual desktop merely as a “container” for running applications – and the roles and responsibilities of the operating system become increasingly secondary. Remember, to users the operating system practically doesn’t exist – what they really care about are their applications and their persona. Before we go any further its perhaps worth remembering that although our discussion here will be dominated by VMware View, roughly 30% of ThinApp customers are using either Citrix XenApp or XenDesktop. There is also significant number of customers using ThinApp to deliver virtualized applications to physical desktops. So ThinApp is by no means a VMware View only technology – but sits independently of View, whilst at the same time - sharing some integration points.
In many ways “Application Virtualisation” does for applications what VMware Workstation and VMware ESX did for operating systems. When VMware first came to the scene they were one of the first virtualization vendors that allowed you install the operating system natively to the VM without having to recompile the kernel of the guest operating system. At the time this was a major break through – because whilst some OSes are open to the kernel being re-compiled, the elephant in the room was Microsoft Windows. A recompile of it would lead to invalidating any chance of support. In a similar way “application virtualization” does this for applications. At no stage does VMware ThinApp touch or modify the source .EXE it is capturing – it makes no modifications or hacks to say excel.exe during the process of conversion. With that in mind, we hope that ISV’s (Independent Software Vendors) will increase support for application virtualization – as they eventually did the virtualization of the operating system. That’s something were beginning to gradually see – for example SAP now support the application virtualization of their GUI client.
Advantages of Application Virtualization
There are many benefits to application virtualization including:
• Less conflicts between one application and another
• Same App, Different Versions: The ability to run different versions of the same application in the same Windows environment
• Keeping the Virtual Desktop Lean and Mean: Keeping your virtual desktop as an environment to merely execute programs rather than store them locally in C:\Program Files
• App-on-a-stick: Application Virtualization is not limited to virtual desktops. Often you carry your applications around on a memory stick and execute them anywhere as they work within their own sandbox
• ThinApps: One key advantage of ThinApp is that the virtualization allows for total encapsulation - in other words, there is no need to install a special client at the destination where the ThinApp will run. A ThinApp is an entirely separate and independent .EXE in its own right. The ThinApp runtime uses a Primary Data Container to hold the ThinApp runtime itself - a read-only virtual file system and virtual registry. ThinApp is popular because unlike some application virtualization products it is agentless and clientless. This is seen as being more portable than other solutions. It allows the application to be ported to virtual desktops and terminal services without rebuilding or recompiling the application
• Network Streaming: Most application virtualization products will “stream” apps if delivered over the network – in other words, the client just downloads the files it needs as it needs them. Often these can be configured to be cached – just like a web browser - to speed the application’s launch when it is next loaded by the user. Whilst this caching can be beneficial much depends on the type of virtual desktop pool you have and how it is configured. For example if you use floating pools, and enabled the option to delete the VM on log off, there is little point in virtual applications being cached.
• ThinApp the View Client – If you think about it, one of the challenges of deploying View is the fact that a client needs to be installed on the endpoint device. A simple remedy to this situation is to create a ThinApp of the client. It also means that when the client needs upgrading, you can simply publish a new version of the ThinApp. With that said because both the USB and ThinPrint component require drivers these features are not supported if you ThinApp the View Client.
• Play in your sandbox – Most application virtualization tools have a sandbox concept, and ThinApp is no different. The idea is that all the changes a user makes to an application are directed to this sandbox location. So, unlike a conventional Terminal Services environment where end user customization can be difficult, the sandbox allows the user to customize the application to suit their needs. The sandbox is normally included inside the user’s roaming profile, but it can be redirected to a USB location for local use, or to a network location - the choice is yours. Additionally, the sandbox can be made so that when the user closes the application all the changes made there are deleted. So while a user can open the application in their ThinApp session and make changes to their preferences, once the user logs out, the ThinApp returns to its default settings. If something goes wrong with a ThinApp, you could delete the sandbox associated with it, and this would force the re-creation of the sandbox as if the user had yet to run the ThinApp for the first time. The end-users personal sandbox is by default located in their user profile (local or roaming) or persona management location. In Windows 7 with VMware Persona Management enabled it would be located
Thinstall was the name of the product before VMware acquired the company that created it called Jitit, and re-branded it as VMware ThinApp. Remember its Thinstall NOT ThinInstall as directory name. It’s an easy schoolboy error and one we have made more than once in our time!
• All this and more – You can do all this and more – ThinApp itself is in part a ThinApp, and the installer is just 7MB in size. How’s that for efficient programming! The ThinApp RunTime itself is only about 600-700Kb in size, and this compares very favourably to other agent-based systems which can be anywhere between 30-40Mb in size. One great selling point is there is no client side software needed to be installed with ThinApp, unlike some of its competitors that require one to function.
The diagram below shows a typical architecture overview of the ThinApp system. Each application sits within the ThinApp runtime that provides a virtual file system and virtual registry. As with server and desktop virtualization, the ThinApp-enabled application believes it is running in an unmodified environment - in most cases, applications should work happily within ThinApp. This virtual file system and virtual registry is given the collective name of the sandbox. The sandbox is a read-writable environment by default. As long as users have read-write access to their user profile (where the sandbox is stored), then any changes the users make to the application will be saved. Using the ThinApp “package.ini” file, it is possible to make the sandbox destroy itself every time the application is closed - this effectively makes the sandbox a read-only container, which discards any changes that the user made when the ThinApp was loaded.
When ThinApps are created everything that makes up the ThinApp is held in what VMware calls the “Primary Data Container”. This container holds a virtual file system and Windows Registry – when loaded the ThinApp thinks it can see a real C:\ drive when in fact it sees a virtual C: drive. The whole thing, once loaded, is referred to as the “Virtual Operating System” or VOS. If you like, your ThinApp is running a Virtual Operating System, inside an operating system which is contained in a virtual machine!
Limitations and Requirements
It’s worth acknowledging that some of these issues are a pain point whether you use application virtualization or not. The Licensing and Activation process can be a royal pain in the rear, and you could argue that any large corporation with a dedicated application packaging and deployment team would look at these issues and say “Well, yes we have to manage these with or without application virtualization, and anyway, application virtualization is one tool that helps us deal with those crummy installers.”
• Application is not installed natively: One of the selling points of virtual desktops compared to the shared desktop model is that applications can be installed natively to the client operating system. By definition, if we use application virtualization this is no longer the case. One of the downsides of application virtualization is the inevitable fact that, sooner or later, a software vendor might arbitrarily decide not to support the use of ThinApp or other tools of its ilk. We want to be honest with you here, Application Packaging is as much an art as a science. It’s something you get good at by practice, and by using all your resources especially online. Our own example in this chapter of creating a ThinApp for Acrobat ReaderX turned out that way. We must have done about 10 attempts until we cracked it, and we only cracked it with the help of the forums. If you have or can employ a team of professional packagers this is to be commended. One of the issues we have seen is that ThinApp and application virtualization is on a surface level getting easier and easier for the novice to take on board. That’s great, but it can also create a false sense of security and optimism. We wouldn’t ask a person specializing in packaging to manage a vSphere Clustered environment, so why is it seen as acceptable to ask VMware server guys, to go around packaging applications? However, we appreciate that necessity is often the mother of virtue – and it maybe down to a relatively small team to take ownership of “Everything VMware”.
• Software with Drivers: Software that installs or requires some kind of kernel mode driver will in most cases be impossible to capture in the application virtualization software. For example, you cannot create a ThinApp of VMware Workstation. When VMware Workstation installs, it adds drivers to the underlying Windows OS and modifies the underlying network infrastructure as well. This limitation also extends to scanner software and webcam software. Previously, we described creating a ThinApp of the View Client. If you do this, we recommend that you do not include the virtual printing or USB redirection service – both of these install kernel-mode drivers.
• File Associations: Although you can have three different versions of Acrobat Reader or Microsoft Word simultaneously running happily on one OS, only one of them can “own” the file associations of the application. So when you double click on a PDF file, the question would be which ThinApp would be used as the default application? Most application virtualization vendors have a method of setting a preference. In the case of View, it uses an .INI file
• Support Politics: If you think running an application or service inside a virtual machine with source code totally unmodified can be political in the sense that an application vendor may not officially support it, how do you think these same application vendors respond to virtualizing their client applications? Expect to see comments like “re-engineering” and “not by design”. A bit like with server services, these client application guys need to catch up. As with virtual appliances, distributing a client application that runs preconfigured and independently of the windows OS without an installation routine is the way to go. In fact, a virtualized application is likely to create less problems and conflicts due to using a sandbox. With luck one day we will see these same application vendors will start to distribute their software pre-built as ThinApps, as they begin to realize they are easier to support than the conventional installers.
• Licensing and Activation Processes: As with virtual machines and the guest operating system, you will really want to hunt down and use so-called “Corp” editions that often allow for bulk activation, or even bypass the activation process altogether. However, ThinApp obviously doesn’t change your application vendor’s license policy, it merely captures the install you would have done if you didn’t own some kind of application virtualization software. So, if you want to run 20 copies of an application, and the vendor says you need a special unique TXT file for each application that runs, the same restriction would apply to a ThinApp. The last thing you want to do is to have to create 20 ThinApps; that kind of defeats the object of the exercise.
• Dependencies Captured: You will need a clean or “base” Windows install every time you capture an app, so that there are no dependencies present during the capture process. This avoids a situation where a .NET application refuses to function because the source OS had .NET installed before the capture process, and it was therefore ignored. When the virtual application is loaded on the destination it might fail because .NET is not installed. To get round this issue we install the ThinApp software to a clean “Build” machine and share out its directories. Then we take a snapshot of our Parent VM, and run the ThinApp software remotely while we install the new software. Once the build process is over, we can then revert the snapshot on the Parent VM so it is returned to a clean state – ready for our next ThinApp
• Application Updates: Most software comes with its own “Hey, I see you’re busy working right now. But we’ve released a new version of this software which fixes all the problems we knew we had in the beta program, would you like to download it to fix it – and then have a whole new bunch of bugs introduced that no-one knows the workarounds to?” Seriously, when an application tells us it has a new version, we sit there and think, “Are we tempting fate here?” As an end user who manages his own single PC, I take that decision and live with the fact I’m not patched to the hilt. The same cannot be said for those in the corporate space. It’s important to switch off these application updates because they will most likely waste space in the end user sandbox, while at the same time failing because they are not aware they are running in the ThinApp sandbox. Given the complexity of our environments and multiplicity of different software packages most corporates switch off auto update features as they waste precious bandwidth, and introduce business risks of introducing new components that stop other applications from working.
• ThinApp Every App?: Some organizations decide that large multi-app application suites like Microsoft Office are best installed locally to the virtual desktop, leaving application virtualization to deliver strategic applications. This is not dissimilar from how many corporates use Citrix XenApp to deliver mission critical services like email and database access, but still continue to install applications locally. It remains to be seen whether such approaches remain popular as application virtualization technology matures. As with server virtualization, we might move to an “Application Virtualization First” policy with ThinApp or one of its competitors
Frequently Asked Questions
Q. How do I get my ThinApps to the desktops that need them?
A. There are many different ways – and that includes systems that would work with physical and virtual desktops in equal measure. We intend to show you a variety of methods but not all of them. We will focus on the ones in bold which are specifically VMware-only methods.
Here is list of possible distribution methods:
• Save on CIFS share, and create shortcuts
• Create a companion MSI file, and push out using Microsoft Software Policies or some other 3rd party electronic software distribution system
• Register ThinApps using the “Templates” feature in VMware View
• Use a logon script and the thinreg.exe command within ThinApp
• Download and Configure ThinApp Factory and use its “ThinApp Store”
• Download, Configure and License VMware’s Horizon Application Manager and configure a “Windows Apps” location that contains your ThinApps
Q. Can you build 64-bit applications and run them on 32-bit operating systems?
A. No. A 64-bit application still makes calls to the processor looking for 64-bit attributes. So just as 64-bit virtual machines could not execute on 32-bit processors (in the days of ESX 3.x), the same applies to application virtualization. As it is at the moment ThinApp does not even support 64-bit applications.
Q. Would a 32-bit application built-in Windows XP 32-bit run in Windows 7 64-bit?
A. Perhaps, to some degree application virtualization insulates you from the operating system differences, and 64-bit processors and operating systems still support 32-bit applications. In fact, application virtualization is a good way of allowing legacy applications that won’t install on new operating systems to continue to function. This is similar to how we P2V’d legacy Windows NT4 operating system servers into virtual machines in the last decade to extend their life beyond the hardware support period. But there is no guarantee it would work – ideally the source capture OS should be the same as the OS that it executes on.
Q. If I publish ThinApps, or groups of ThinApps, to a linked clone desktop, and then I refresh, recompose or rebalance the pool what happens then?
A. View will “reinstall” the ThinApp for you.
Q. If I’m packaging something large like Microsoft Office what’s the best practice? One large ThinApp – or a ThinApp for each component – Word, Excel and so on?
A. You could make Office a part of your default build installed locally. We use ThinApp to deliver strategic applications in an on-demand basis. If you do wish to ThinApp a large suite of applications like Microsoft Office – then the general recommendation is to create one ThinApp for the suite. This will preserve the interoperability and productivity enhancements where one application acts as a “helper” for another. Splitting out the applications could create incompatibilities and lost functionality. For example if Office applications are captured separately then you will find the dictionary not syncing changes between separate packages of Word, Excel and so on. If a change is made to the autocorrect or dictionary in Outlook is goes in a different sandbox than the sandbox for Word.
It’s worth saying that some applications like Office are so widely used that customers often install them natively to the virtual desktop without using application virtualization at all. Due to some restrictions with application virtualization its unlikely that you will be able to virtualize 100% of your applications – your goal, like with server consolidation, should be to aim for the highest percentage of application virtualization that you can achieve to maximize the benefits to the business.
A Little Word of Advice
ThinApp is an incredibly easy application to use. But in our experience there’s a bit of advice or caveats if you like that we would like to take on board before you begin.
1. Backup. A ThinApp is just a bunch of files – just like a VM is. The changes you make are written to those files permanently. So if you making major changes, backup the project folder first. Then should anything go pear-shaped you can revert to its previous state. It seems an obvious thing to say – but if you upgrade destructively a ThinApp from one version to another there’s no way back except finding your upgrade. ThinApp does not automatically keep a copy of every version of your project. It would be nice if it did.
2. Plan your shares. In our examples we merely shared out the location where ThinApps are compiled. This isn’t really best practice. You should have a folder that keeps your projects – and then many builds of those – separate from the “bin” or .exe that the end-users runs. That does mean that if you rebuild the ThinApp you will need to copy the new version to the shared location. But it is really not good practice to give your end-users access to your project directory – for reasons ¬we hope are obvious. Finally, if the directory that holds your project also contains the ThinApp .EXE the users are running you will find that if users have the ThinApp open across the network – it will become locked. This means all users would have close down the ThinApp before you could re-build it. If you not careful you can get “access denied” error message caused by using a single shared location. Additionally, you might want to consider a third “staging” share that is used to distribute applications to small selection of users whilst you’re in your user testing and user acceptance phase. This way you can move seamlessly from build, stage and deploy phases. You might prefer to copy the ThinApps to a robust engine for storage – such as your storage array if it supports CIFS sharing. This means your ThinApps are stored on your most redundant storage available.
Note: Access denied message caused by shared location for the project and ThinApp .exe
3. Every change needs the build.bat re-running. When you first create a ThinApp it’s setting are stored. Any subsequent changes will need you to run a script called build.bat. If you don’t run build.bat your changes will not be affective. Time and time again we have seen people make changes, and then say its not working – only to remind them they must re-run build.bat again to make the changes affective. We have even done it ourselves – and upon discovering this have shouted “DOH!” just like our friend Homer Simpson!
4. You need two VMs at least. The first VM is the “build” machine – this will be where the ThinApp software is installed and you can regard it as your “admin” machine. The VMware ThinApp directory can be shared out, and the contents run from any machine on the network, assuming they have the appropriate rights. The Second VM is your “capture” VM. This is a clean install of your target OS with VMware Snapshot. This allows you to capture installations, and then revert the VM to a clean state every time. Often we map a network drive in this OS back to the “Build” machine with “net use x: \\buildmachine\VMware ThinApp”. The “build” machine could be used as the source for sharing out ThinApps to your end-users.
5. ThinApps Registration – Many times a ThinApp will run across the network directly without any special “install” or “registration” process. However, if you want a ThinApp to have the look and feel of locally installed application to the end-user then registration is something you may wish to consider.
Getting Started with ThinApp
Install ThinApp – The “Build” Machine
1. Getting started with ThinApp involves a number of stages – the first is creating the “build” machine to which you download and install ThinApp by executing the VMware-ThinApp-N.N.N-NNNN.exe on an ordinary virtual machine. View supports the configuration of a file server known as the ThinApp Repository. You could install ThinApp on this Repository server and only share out the Capture directory where your ThinApps are compiled. Alternatively you could copy the ThinApp from the Build machine to the Repository server. Essentially, the repository server is just something that supports CIFS/SMB sharing – so it could equally be your storage array if it supports this protocol. In our case we were very, very naughty. We used our domain controller (dc01nyc) as our build and repository server. This something we would never recommend in a production environment.
2. Login to your “Build” machine
3. Run the ThinApp installer – and Accept the EULA
4. Input your License String and License Display name
The “License Display Name” is shown whenever a ThinApp is loaded. When a ThinApp is loaded, a small tray icon appears with the name of the application and the License Display Name. This is used in lieu of the vendor’s own “splash” or welcome screen. It may be required in order to meet the terms and conditions of some EULAs. On separate note – you will want to make this string relatively brief – as the pop-up box is not very large and longer string will not display correctly so “Corp, Inc” is better than “Big Global Corp Incorporated”.
5. Next share out the directory of C:\Program Files \VMware \VMware ThinApp. We setup this location to be shared out in such away that allows the admin running the capture and build process to have read/write access to this location. End-users o the other hand only need read rights to access a shared repository of ThinApps.
Create a ThinApp – The “Capture” VM
In our case we cloned our template VM to create a clean Windows 7 instance. We then applied a VMware Snapshot, so after every “capture” with ThinApp “Setup Capture” wizard we could revert it to a clean state. As such the “Capture” VM needs to be clean, and we mean really clean. For example setting up the capture machine to have the View Agent, and then testing you can connect to it from the View client is not a bad idea – but bear in mind when you login you are likely to create a local profile. The .dat contents of your test user could end up being part of the ThinApp if you are not careful. How do we know? Because we have made the same mistakes ourselves, and seen the contents of test user’s local profile being added to our ThinApp packages – so beware clean means clean, not “Oh, well I only wore this t-shirt a couple of hours yesterday, and it smells OK…”.
One of the joys of ThinApp is that it is very easy to use, and if you have ever used some type of application capturing tool before, they feel very much the same – although the quality of them varies. So, if you have used Veritas WinInstallLE or Citrix Application Packager, it is very similar. The difference is that the output is a self-contained .EXE. Most packaging systems have a four stage process:
• Pre-analyse the clean environment (Pre-Scan)
• Install the Application Software (Install)
• Capture the Differences (Post-Scan)
• Output Package to default location (Build)
During the Pre-Scan and Post-Scan stage, ThinApp creates its own virtual registry and file system to capture all the changes being made. There is a snapshot taken both before and after, and by comparing the two, ThinApp can then begin the build process. In our example we are going to capture the installation of Acrobat Reader 10.
1. Login to your Capture VM and take a snapshot
2. Locate and Download the Acrobat Reader installation package
3. Once the download has completed, Run the ThinApp “Setup Capture” Wizard by browsing the network for the build machine on the network
4. Click Next at the Welcome Screen
5. Notice the warnings about the significance of having a clean PC
6. Click the Rescan button. ThinApp will start the initial Prescan of the virtual desktop
The Advanced Scan Locations option allows you to select which virtual disks will be scanned, and also which parts of the registry. ThinApp always scans the HKEY_CURRENT_USER hive (which is, in fact, the user’s profile), and you can optionally choose not to include HKEY_LOCAL_MACHINE (Windows system settings) and HKEY_USERS (the default user profile). This scanning process creates a snapshot of the machine’s state prior to installing the application. If you subsequently cancel the Setup Capture wizard and then restart the process, a dialog box will appear asking how you want to manage the existing snapshot:
7. At the end of the Prescan, when you see the “Install your application now!” prompt, minimize the ThinApp Window and start the install of the application, in our case Acrobat X
The “Internet Explorer” button here controls what are called “entry points”. It allows you to control how the application calls Internet Explorer. It’s possible to create your own custom instance of IE, or allow the native version of IE to be called and then run inside the VOS.
Important Tip: Most application recording packages allow for a nifty hidden advantage. During the recording process, it is possible at the end of the install to load the application and modify the settings. If you do this before the post-analysis, these modifications (in our case to Acrobat Reader 10) will become global defaults for all users who access the ThinApp. This is handy, as some application vendors do not support Microsoft GPOs and sometimes are very tight-lipped about the registry locations for various options that might not be desirable in your environment. For example, I like to load Acrobat Reader and accept the Adobe Acrobat EULA on behalf of our end users. I also like to enable the option “Do not download or install updates automatically” in Edit, Preferences, Updater. The general recommendation is that if an application has its own (annoying) auto-updater facility that you disable it where possible for ThinApps. The update is likely to fail, and will definitely fail if you have made the “Sandbox” read-only. If you do need to update an existing ThinApp with a new version, patch or plug-in you can use the “sbmerge” utility to facilitate this process. In the case of Acrobat Reader 10 we found we had to remove the tick next to the option to “Enable Protected Mode at Start-up”. This security feature appears to conflict with ThinApp as it causes Acrobat Reader to create its own “sandbox” for security purposes:
If this feature is not disabled users would be confronted with this error message every time the ThinApp was opened.
8. Once you have finished with the installer, close the application and restore the ThinApp Setup Capture window. Click the Postscan button and this will trigger the Postscan phase. Click OK in the Setup Capture dialog to indicate the install has completed
9. After the scan has completed, ThinApp will list the “User-accessible entry points”. These are EXEs that the user can trigger the launch of the application in the ThinApp runtime environment.
The problem with most application recorders and packagers is that they quite frequently get confused. Frequently they cannot detect the difference between an installer .EXE and the application it is installing; in contrast ThinApp makes a good job of this. However, I noticed that this dialog box didn’t include all the executables.
ThinApp detects these as Entry Points - the multiple executables that make up a single installer. It is possible to de-select these multiple executables to just select the .EXE you wish ThinApp to build.
It’s worth mentioning that our testing and validation won’t be anywhere near as rigorous as yours, or will it? We think the general point we want to make about this dialog box is that every single application will produce different results, and we think you would have to know the application very well before considering deviating from these defaults. For example, the default selection didn’t include AdobeARM.exe. Why not? What controls the enabling of an entry point is if the installer created a shortcut to the .EXE during the installation. All of the .EXE would be accessible to the end-user, but only ticked entry points could be used as a method of triggering the ThinApp runtime. In the real world the only entry point actually needed here is the core .exe called “Adobe Reader X.exe” so if you wanted the other entry points (AcroBroker.exe, AcroBroker.exe, AcroRd32info.exe and Adobe Air Applciation.exe), could be disabled. If at a later stage you felt the use needed access to these entry points they could be re-enabled in the package.ini and the ThinApp rebuilt with the build.bat script.
The best way to describe an “entry point” is to see it as a “door” into an application, so for example when you install many files and ancillary applications are copied but the main “entry point” from the end-user’s perspective is winword.exe, excel.exe, powerpnt.exe and so on. When an entry point is executed, that sends out an instruction to load the ThinApp Runtime – which in turn can read the entry point information to launch the application. It is possible to add additional entry points in this dialog box – for use in debugging purposes.
In the next part of the Setup Capture wizard, if you’re working with ThinApp 4.7 or later you will find that it now contains an option to capture the application with settings valid for VMware Horizon Application Manager and the Horizon Agent. We will be discussing Horizon Application Manager in our final chapter about the future of application deployment.
The main thing to note is if you are using ThinApp with Horizon Application Manager there is no requirement to enter anything here. It’s entirely optional. It provides is a “link” to where the user can download and install the Horizon Agent if it isn’t already present. What is required are two settings in package.in called:
If you do complete this field you will need the “External URL” for you Horizon Connector service – by default this listens on port 80, but can be secured with port 443 and trusted certificates – so http://horizon.corp.com or https://horizon.corp.com would be valid entries.
10. In the next window you can control how the ThinApp will be built
Note: The “Group” window does not appear if you are making your ThinApp available via Horizon Application Manager. In that scenario it’s Horizon Application Manager that handles the authentication and entitlement process. This configuration corresponds to the PermittedGroups entry in the package.ini file. As such it is possible to edit the .ini file and modify the group membership, and then re-run the build.bat within the ThinApp capture directory for that application to modify it.
If you using Horizon Application Manager it is both AD aware, and has its own internal system of group membership – so you may need to be a little careful with these settings to avoid situations where the user may have rights in Horizon, but not the correct rights to the ThinApp. The recommendation if you are using Horizon Application Manager is to NOT use this feature of ThinApp to control access – but instead use Horizon’s access controls instead.
You can encode Active Directory controls that define the parties able to run the application. The idea is to restrict the portability of VMs, such that if a ThinApp leaks out of your organization, no-one will be able to run it without first authenticating to your private, internal and firewalled domain. ThinApps are very, very portable and without these sorts of controls, it is straightforward for a virtual desktop user to upload an entire application to box.net or dropbox.net. Obviously they are still potentially able to do this, but the file cannot be executed from outside the organization. There are many virtual Internet drives which offer very cheap storage - a user could use these to upload applications out of the organization, and then download them for use at home. You have been warned. Notice how we have only included our core Virtual Desktop Users group, this means that even if I was full administrator of the domain, I would not be able to run the ThinApp unless I was a member of this group. If you do try to run the application without the appropriate rights you receive this message:
11. The next dialog box is a difficult one, as it is difficult to know 100% in all cases which option to select. There is something to be said for experimentation and rigorous testing
“Merged isolation mode” is very close to how applications normally behave when they are installed in a conventional desktop. However, in our virtual desktop, we can either disable or redirect many of the locations that are referred to here. The recommendation is to select this option for Microsoft Office and Windows Logo Certified applications. WriteCopy isolation mode is recommended for legacy or untrusted applications, and results in a more isolated or sandboxed ThinApp.
Many admins who’s job is packaging prefer to use “WriteCopy” when building and managing the ThinApp – as this gives them a more isolated frame work to operate in. However, when it comes deploying the ThinApp into a production environment the recommendation is to the rebuild the ThinApp with the build.bat script to work with “Merged Isolation Mode”.
One thing that is worth mentioning is that some advanced tools from ThinApp require the use of “WriteCopy Isolation Mode” such as the “sbmerge” utility. It is possible to switch from one mode to another after the capture process. This is done by modifying the package.ini file within the project, and rebuilding the ThinApp with the build.bat script – the entry that would need to be modified is held under the [Isolation] section at the top of the file and change from DirectoryIsolationMode=Merged to DirectoryIsolationMode=WriteCopy
12. The next option allows you to control where the user sandbox will be held
To maintain a per-user setting, ThinApp allows you to save per-user settings in three different locations – the User Profile, a USB device or a Network location. As we saw earlier, folder redirection can relocate the Application Data part of a user profile to a network location (such as the user’s home directory) so a network drive and user profile location could effectively be the same. The USB location is clearly not aimed at a virtual desktop environment but for a more stand-alone mode. This is popular with IT staff that can carry a memory stick of their favourite management applications. We’ve decided to stick with the User Profile option as we redirect this to the network anyway.
These pages can change depending on what application is being ThinApp’d. For example if you try to ThinApp a web-browser like Apple’s Safari for Windows – ThinApp will detect this, and offer you the opportunity to “redirect” URLs from IE to Safari.
Note: We will be looking in detail the process of capturing a web-browser later in this chapter – when demoing how to capture Internet Explorer 6 from Windows XP installation.
13. Next, select your Inventory Name and Project Location. The Inventory Name is the friendly name used by ThinApp when using VMware View or Microsoft GPOs to publish the ThinApp to the end user’s virtual desktop. The Project Location will be the destination of all the files discovered during the postscan stage, together with your ThinApp held in the \VMware ThinApp \Captures \<Your Inventory Name> \bin directory
Note: You might notice that the “Inventory” name is constructed from the full version details of the application (10.1.1). You might prefer a more “generic” label like (10.x.x.). This means you can upgrade the ThinApp from 10.1.1 to 10.2 that might be a bit more meaningful. Having a 10.2 application stored in a folder called 10.1.1 can be a bit confusing. When the application moves to version 11, perhaps then you would consider a brand new capture and build of that application. Alternatively, you could have a naming convention that dispensed with numbers altogether and just stated “Acrobat Reader”. The choice is really yours – remember you can always find out the version of any Windows application anywhere from Help and About. The main thing to say is that end-users don’t really need to be able to see the version number in the icons and folders – and you might prefer to have something more generic – that allows you to upgrade from one version of the application to another without them realizing. It’s worth mentioning that there are limitations on the length of file paths so using mapped network drives and shorter share names is a good practice.
14. Next, select your build options – this allows you to set where the project files will be located (this is where you will find the ThinApp)
As you can see here, by default “Adobe Reader X (10.1.1).dat” has been selected as the Primary data container rather than the entry point. In our discussions with VMware it became clear that using the .dat file during the build process was the ideal option, but then to publish the entry points the end user needs. Here’s why. What you're selecting here is the container for holding the virtual applications data – you can store them in the end-point (that has a .exe extension) or in separate data container (that has a .dat extension). By default if your package is greater than 200MB in size, then ThinApp will default to using the separate .dat file. Windows has a limit on the maximum file size of any executable that is 2GB in size. In fact if an .EXE is greater than 2GB it simply won’t load. By separating the application data from the entry-point you can easily get around this limitation – for example the entry-point could be 500KB, with the .dat file 8GB. If all this application data was stored in the entry-point Windows would not allow it to load. There are some other advantages when it comes to streaming as well and anti-virus. If you have 8GB entry-point it’s likely your AV would download the whole of the entry-point, scan it and then allow it to be loaded in the ThinApp RunTime. This would take some time, and negate the point of streaming (where only the bits of the application are delivered when needed). If you separate the entry-point from application data into a .dat file – the AV only needs to check a small entry-point that is a couple KB in size. We wouldn’t go so far to say that using .dat is a best practice – the important thing to say is try to be consistent in your settings. We would recommend you don’t have some ThinApps using the entry-point, and others using the .dat as the storage container.
IMPORTANT: In addition to the Primary Data Container option – we have both MSI package generation and compression options too. The “Build MSI package” option will create an MSI file that you can then use to copy the ThinApp to the system – use this if you intend to have the ThinApp running from within the virtual desktop’s virtual disk. This option is required if you want to use View’s method of linking virtual desktops to the ThinApp. It’s also required if you want to use application streaming where you deliver the ThinApp across the network using View Templates. For other deployment approaches this is not a requirement.
If you are just testing the application, use the option “Non Compression” which is generally much quicker. When you’re ready to build the application for Production you can use “Fast Compression”, as this can potential reduces the time it takes to stream the application to the end user – but takes significantly longer to build. If you’re looking for a feel as to how long, large applications like Microsoft Office can take a couple of hours. Fast Compression can reduce the size of the package significantly (in some cases by as much as 50%) but the compression does come with an overhead for the actual load time of the ThinApp. The best that can be said about the compression option is your mileage can and will vary so its difficult to say that is always of benefit – to coin a VMware catchphrase – it depends.
15. At the end of the post-configuration stage of ThinApp, first save your Project
16. After this has completed, you will be offered additional configuration options just before the ThinApp is built.
The “Open Project Folder” button will allow you to modify various .INI and .INF files for advanced configuration. Once you are finished, you can return to the Build Now option. Buried inside the ThinApp application is a batch file (build.bat) that you can run to re-execute the build process located in the capture project directory. If you make changes to .INI files after the build, this allows you to re-build the ThinApp without going through the whole capture process again. For a complete list of all the package.ini settings, visit this location:
There’s also a more detail package.ini guide available here:
You may wish at this stage to bypass the build process so you can encode custom settings to the package.ini file.
Some of our favourite and most popular package.ini settings include:
RemoveSandboxOnExit=1 which controls whether the sandbox is deleted when the last part of the ThinApp closes. This value is remarked by default in package.ini file. Using 1 enables the removal of the sandbox. Set this option to make it impossible for the user to change settings within the ThinApp. Whilst we love this feature, it can be a little dangerous in the wrong hands. Suppose your application prompts a user for settings when it is first run – if that setting is not dealt with by the ThinApp Admin, every time the user loads that application they will see that pop-up message. No matter how many times they confirm their preferences when the close the application – the sandbox is deleted and their preference is lost. It can be horribly annoying to end-users!
MSIStreaming=1. Additionally, we also enable which enables View 5.x to be used as a deployment method. If you not using View 5.x “Templates” as the deployment approach it is not needed..
Note: Horizon Application Manager from VMware does not require this option be enabled in order for ThinApps to be streamed from its “Application Catalog” (aka “AppStore”). However, we would still recommend enabling this option if you wanted to have ThinApp application streaming for both Horizon and non-Horizon distribution methods.
VMware Horizon Application Manager Parameters: Over time we have become big fans of Horizon Application Manager and the integration that exists between it and ThinApp. So we often add the Horizon parameters to our package.ini as well. We would urge a little caution with the HorizonOrgURL parameter it does compile the ThinApp in such away that it will only work with Horizon. That could cause you problems if you want to distribute one version of the ThinApp in many different ways. The AppID and NotificationDLLs parameter are required, but the HorizonOrgURL is optional.
During the project save process you may find you receive “save warnings”. Generally, these are warnings you can safely ignore. Temporary files being detected by ThinApp during the installation often cause these warnings and ThinApp occasionally thinks they are real files needed by the application. Many installers will delete the temporary files once the setup has completed, and this occasionally confuses ThinApp. This is a very common experience with competitive application virtualization technologies.
17. Click the Build' button
'18. At the end of the build process, ThinApp should open a window showing the ThinApp and other ancillary executables. The core files for us are the Adobe Reader X ThinApp and the Adobe Reader X.msi file. The MSI file was created for us by the option “Generate MSI package” selected earlier in the wizard
19. As a quick test, you may copy the files to a network location accessible to your users virtual desktops, and validate the load without error
IMPORTANT: Once you have finished with your “capture” VM, remember to revert the snapshot to undo your changes before carrying out your next “recording”. Remember your project files reside on the separate “Build” VM which will allow for modifications and changes after the initial capture process.
TIP: If you forgot to change your settings in Package.ini. All you would do is edit package.ini in the location where the ThinApp was captured, and then re-run build.bat in the same location for them to take affect.
And Finally: Notice how the ThinApp entry-point is just a couple of kilobytes in size as is the .dat data container. Essentially, these represent just the “metadata” needed by the ThinApp Engine to then load the real executable into the ThinApp RunTime and Sandbox.
The actual Adobe Reader X.exe and its associated .DLL’s is actually much larger than 705KB. For example just the folder that contains the “Reader” at C:\Program Files\Acrobat Reader\Adobe\Reader is 110MB in size.
ThinApp “Setup Capture” will also “record” the creation of shortcuts, and when used in conjunction with publishing methods will automatically recreate those shortcuts on the end-point. If you’d rather not have these shortcuts created on the desktop then before you carry out the post-scan remove them. Personally, we are cool about shortcuts on the Start Menu, but lots of shortcuts on the desktop can look somewhat “messy”. If you have already built your ThinApp, and would like to stop the creation of desktop shortcuts you can disable them by using the package.ini file. If you look towards the end of the file you should find your entry-point such as [Adobe Reader X.exe]. Underneath you should see an entry that reads shortcuts= with paths for creating shortcuts on the “Desktop and with the “Program” menu.
Introduction to Registering ThinApps
There are many many ways by which you can either publish or register a ThinApp. The guys who develop ThinApp are really interested in the packaging process primarily – and haven’t historically considered themselves as the “distribution engine”. However, they have always supported other methods of deploying ThinApps. We think the assumption is that every customer has their own preferred way of distributing the software to their end-users – and ThinApp didn’t want to introduce yet another. However, with that said times-are-a-changing. As you will see in our last chapter about end-user computing futures there will soon be web-portal called “ThinApp Factory” available, and ThinApp 4.7 does integrate with the VMware Horizon portal as well. Both systems could be regarded as way of publishing or advertising new applications to end-users.
As you saw in chapter 18, you could be using a redirected desktop GPO system to advertise the ThinApp on the user’s Start Menu. Alternatively, you can install the ThinApp using the MSI file created during the build of the ThinApp itself. This MSI installer could be triggered using GPO and Software Installation Policies. These methods are very much Microsoft-orientated and probably well understood by most people. From a VMware View perspective version 4.5 introduced a method of assigning groups of ThinApps to virtual desktop pools. As alternative, ThinApp always allows you to manage the registration process using the ThinReg.exe – in fact many customers prefer this method to using the new method introduced in View 4.5. That’s because they are using ThinApp for both physical and virtual desktops – and need an approach that will work both systems. Additionally, they may also prefer the powerful logic that a login script and its accompanying scripting language can offer them. So in this section we will be focusing on the View Method and the ThinReg Method as examples. We are often asked which method we prefer – for the moment we feel that ThinReg offers the most flexibility and controls. So we would personally recommend it over using View native ability to assign groups of ThinApps to desktop pools using its “templates” feature.
In this section we switched to our pool of “Accounts Desktops” that had no Microsoft GPO restrictions or folder redirection so the full functionality of ThinApp integration with View could be demonstrated.
Registering ThinApps to View Desktop Pools
Beginning with View 4.5, it’s also possible to publish ThinApps via the View Administration tool. As with Local Mode desktops, you can configure a file server that centrally holds your ThinApps, and then you select which desktop pools receive the ThinApps from the central library. First, configure the file server you wish to use, then copy all your desired ThinApps to the share on your file server. In our case, we decided to use our View Transfer Server as the file server to save on the number of VMs needed in our lab environment.
Configuring the ThinApp Repository
1. In View Administration select View Configuration
2. Select ThinApp Configuration
3. In the Add Replication Repository page, type a friendly name for the ThinApp Repository such as Corp Application Repository, followed by a UNC path to the file server which will store your ThinApps
4. Click the Save button
Adding ThinApps into View Server
The next stage is to set the View Connection servers to scan for the ThinApps held in the repository.
1. In View Administration select Inventory
2. Select the ThinApps node, and then click the Scan new ThinApps… button
3. In the Scan New ThinApps… dialog box, from the “Application repository” dropdown list, select the share location configured a moment ago, and click the Next button
As you can see, we didn’t stop with Adobe Reader X. For a bit of realism, we packaged up some other applications as well, and uploaded them to our repository. This will help later when we come to create what are called Application Groups.
4. In the next dialog box, select the discovered ThinApp(s) and click the Finish button to import them into the View environment
Entitling a ThinApp to a Desktop Pool via an Application Template
Previous releases of View referred to application templates, as application groups. VMware made the name change in View 5.0 but the functionality is much the same.
There are in fact many ways to entitle a ThinApp so users get the applications they need. If you have many ThinApps, it’s possible to create groups or templates of ThinApps and then assign them to pools of desktops. It’s possible to assign a ThinApp to:
• Desktop(s) – this is useful if you have a dedicated pool, and one user’s desktop needs a particular application which they would not normally receive via their membership of a group
• Pools – this is useful for building standard desktops replete with standard applications
• An Application Template (which contains multiple ThinApps) – this is the most efficient method of entitling many applications to a desktop or pool
Whichever method you use, you will have the option of running the ThinApp locally (which VMware refer to as a full install), or streaming it from the repository file share configured earlier. The full installation is only supported for the Dedicated pool type. Remember MSIStreaming=1 is needed in the package.ini for View – if its not enabled the option will be dimmed in the View Management web-pages.
1. In the ThinApps node, below the Scan new ThinApps'… button select the New Template… button
2. Type in a new template name such as “Accounts ThinApp Template” and then click the Add… button
3. In the list select a ThinApp and click the Add-> button
4. Now we have our ThinApp Application Template, we can entitle the template of applications to the pool. Select the Application Group, click the Add Entitlements button, and select Pools from the list
5. In the Entitle Pools to Template dialog box, select the Pool you wish to Add to the template – and then select the Installation type based on your preferences and then click OK
You can see the ThinApp assignments to the desktop pool by viewing the pool, and switching to the Inventory tab, and clicking the ThinApp link
If you are using the Full format, end users see this popup message (shown in the screen grab below) near the tray location in Windows as each application is installed using the MSI created in the ThinApp build process. Shortcuts are created on the Start Menu with the same look and feel as if the standard installer had been run, and the ThinApp applications are copied into the C:\Program Files location, each with the label “(VMware ThinApp)” in their directory name.
If on the other hand the “streaming” option is selected, the .MSI merely creates a shortcut, and the ThinApp stays on the network at the “Repository” location, and it is streamed into the virtual desktop. Remember for this streaming option to be available, the ThinApp must be built with the MSIStreaming=1 option enabled in the package.ini file.
Warning: By default, this ThinApp install process creates shortcuts on the user’s desktop if the original installer created them. However, if you impose rigorous folder redirection policies as discussed in Chapter 18: “Microsoft Group Policies”, this will fail. Instead, you will have to create these shortcuts yourself. We found we could log in as a local administrator to test a virtual desktop, and then copy these shortcuts to a shared folder redirection location.
It’s perhaps worth saying this process of advertising the ThinApp to the user is not a technically a “registering” process. It’s merely a way of easily giving the user access to a shortcut on the desktop or start menu. For that reason certain features such as ThinApp AppLink may not work as expected such as registering file extensions, protocol and other objects. That’s not a error as such AppLink, but more about the way the folder redirection process works.
Registering ThinApps with ThinReg.exe
As mentioned earlier many customers actually prefer to use login scripts to prepare the end-users environment – in preference to other methods such as Start Menu/Desktop redirection or the ThinApp Repository in VMware View. That’s because they are attracted to the powerful logic that login scripts can provide and the more granular controls they offer. Additionally, ThinApp can be used with physical and virtual desktops – and login scripts work seamlessly in both environments. It’s somewhat ironic that despite all the developments in system administration over the last two decades – the login scripts still persists in most peoples environments.
To handle the registration of ThinApp we can use the command-line utility ThinReg.exe which is located in this path in the ThinApp installation:
C:\Program Files (x86)\VMware\VMware ThinApp
Install ThinDirect.msi for Windows
There’s a companion utility that’s also very handy to have called “ThinDirect”. This adds a plug-in to Microsoft Internet Explorer that allows you to control how URLs are handled by ThinApps. For example it enables you to say if URL1 is used then open Internet Explorer 6, but for all other URLs – use the FireFox ThinApp.
We would recommend pushing out the ThinDirect.msi to all your clients both physical and virtual to allow controls whichever way you deploy your ThinApps. Of course you could make ThinDirect a default component of your templates and/or your Parent VMs that make up linked clones.
ThinDirect also comes with an .adm file so as we saw in previous chapters its possible to control this URL feature with GPO objects. Once the ThinDirect.msi has been installed it appears as an add-on within Internet Explorer.
If you do carry out a Setup Capture of web-browser, and select the “Generate MSI package” option – then ThinApp will automatically include the ThinDirect.msi. If that ThinApp is then deployed using the .MSI generated by ThinApp then it will automatically install the ThinDirect.msi for you. This makes sense given the dependencies – as there’s no point in enabling URL redirection, and capturing a web-browser – if then the dependency that is needed is not installed as well. However, this is a small risk if these conditions aren’t met that you could register a ThinApp that requires it – which would fail. Here’s an example of that error in the dialog box below:
Due to this experience it has lead us to conclude that it is better for you the administrator to deploy this to your physical and virtual desktops – rather than run the risk that for whatever reason ThinDirect is not installed.
Finally, one final very important note – the Thin Direct plug-in only works with embedded version of Internet Explorer. The user must be in the habit of opening this embedded browser for all their Internet work, and ideally it would be set as their default web-browser. If a user opens a ThinApp web-browser or some other locally installed web-browser such as Chrome, the ThinDirect plug-in will not be opened, and clever redirection to the right browser will not work.
Registering ThinApps with ThinReg.exe
Note: In this chapter we will be talking about the challenges of managing file extensions with ThinApps.
As stated earlier ThinReg can be used to register ThinApps to any system be physical or virtual. This registration process can also be used to overwrite the current file associations on the targeted system. So with some thoughtful use of login scripting you can make sure that the right ThinApp controls the file extension associated with it. The command has number of switches – but the simplest is /r to register and /u to unregister.
For example on our desktop there is index.htm file which is currently associated with the default web-browser in Windows 7 - Internet Explorer 9.
I mapped a network drive (x:) to a shared location where both thinreg.exe was located as well as our capture of FireFox. By using the command:
X:\thinreg "x:\Captures\firefox-8.0\Mozilla Firefox.exe"
This registered the FireFox ThinApp and also updated the file associations accordingly and also added the FireFox icon to the desktop.
The ThinReg utility does support the use of wild-cards – so to register all the applications within a shared location you could use something like:
Capturing Internet Explorer 6 and Managing ThinDirect URLs
TIP: If you are using ThinApp to capture web-browsers we would recommend running the browser once in the Setup Capture phase. So many web-browser check to see if they are default browser nowadays, in effort to hijack this default for their own purposes. Also you will find web-browsers like FireFox have run-once settings that attempt import your favourites and settings from Internet Explorer to it – which you might not want your end users to see. Additionally, when you have multiple browser tabs open – many web-browsers ask how you want to handle those when the browser is closed. Web-browsers can be some of the most annoying applications to capture – because they often have lots of annoying run-once, run-a-second-time, run-a-third-time and on-exist pop-up messages – which you might not want you users to see – additionally, they often have their own ways of registering extensions and plug-ins – and oh, yes lots of annoying messages and warnings to the user on the first-time they are installed and run. Other examples include first time visits to SSL websites, switching between http and https website, and whether the browser should check if it’s the default. You might also like to think about popular sites that now ask for you regional location (UK or US) such as MSN and YouTube.
We’d recommend playing around with the web-browser whilst in capture mode to get rid of the vast majority of these to reduce the amount of nagware the user has to deal with.
With ThinApp 4.6 it is possible to virtualize Internet Explorer 6 despite the fact there is no installation package available for it. The process works by extracting from a clean installation of Windows XP the files that make up IE6 so they can be run on new operating systems. The demand for this functionality comes from many corporates having systems that were designed around IE6 which do work as designed with the new web-browsers. Face with cost of rebuilding these web-applications compared to merely allowing selective access to IE6 via application virtualization – its seen as cheaper model to extending the lifetime of these portals.
You should be aware that there has been some considerable politics in doing this from Microsoft. Who claim their EULA does not allow for this sort of “redistribution” or re-packaging. Microsoft has warned customers that if the flout the EULA they could face legal action. So far this appears to have been mere sabre rattling from Microsoft. The chances are that VMware Enterprise customers are also Microsoft Enterprise customers also – and it would be foolhardy process to start suing your own customers. We think virtualizing IE6 is a great idea, and kudos goes to VMware for helping their customers fix real-world problems. If you’re scared of litigation and looking for alternative to application virtualization – you could check out browsium.com. They are former Microsoft IE people who have started a company that solves the IE6 problem without application virtualization. Mike’s wrote a flavoursome article on TechTarget’s SearchVirtualDesktop.com site called “To hell with Microsoft rule against IE Virtualization”.
Start with a clean install of Windows XP with the level of Service Pack you require. Beware that Service Packs for client OSes occasionally roll in an Internet Explorer update – so be careful not to allow that update to take place. Next you run setup capture against Windows XP as you would normally – but without installing any software – unless you need additional supporting software such as Java to work with Internet Explorer 6. At the “Install Application Now!” prompt you should see there is a “Internet Explorer” button.
When you click the button you should see the following dialog box which allows you to control the entry-points
To make IE6 work on Windows Vista/Windows 7 or Windows 8 you need to choose the 3rd radio button choice to “include an entry point for a fully virtualized Internet Explorer”. As you go through the Setup Capture wizard you see that ThinApp picks up VirtIE6.exe as an entry-point.
ThinApp will detect that your capturing a web-browser and will allow you to encode URLs you would prefer to be redirected to IE6 assuming the target system that loads the ThinApp has ThinDirect installed as an add-on.
'Note: There’s are rather wonderful April Fools joke setup to try and kid people into thinking IE6 is best browser in the world, and are campaign to save it. The campaign is at: http://saveie6.com/. Personally, we think you might better off setting this redirected URL using the ThinDirect .ADM file and using your Group Policy Objects in Active Directory.
Once IE has been captured it can be registered to the target system like so:
Now if user types http://www.saveie6.com into a web-browser, by email link or from the run box – they will be redirected to IE6 instead. This redirection process works for any web-browser (for example Safari or FireFox), so long as the ThinDirect add-on has been included in the built-in version of IE in Windows 7 or 8.
Controlling URL Redirection with ThinDirect & Microsoft Group Policies
As we saw in chapter 18 both VMware View and VMware ThinApp come with .adm template extensions which can be added into Microsoft Group Policy object. This allows you to control that URLs are redirected to which web-browser. The policy system allows for white lists and black lists depending on your needs so you could express policies that would state – for example a policy that said to always use the default web-browser except for the URL called http://www.microsoft.com which would open instead with Internet Explorer 6. The ThinDirect Policy settings allows for up to five virtual browsers to be configured.
The .ADM allows controls for five virtual web-browsers, and placeholders for 25 URLs per virtual web-browser. It’s entirely possible to have thousands of URLs and hundreds of virtual web-browsers – simple open the .ADM in notepad and use copy function to create more placeholders as needed.
The “Define your setting for virtual browser” is quite a simple affair – simply enable the policy setting – and then in the “Virtual Browser Name” type the UNC path to the location of the ThinApp. If your share names or directories have spaces in them there’s no need to specify “speech/quotation marks” around the string, as you would have at the command-line. Then simply add your URLs – including an asterisk at the end of a URL indicates the entire domain, and sub-virtual directories are also redirected.
Rebuilding a ThinApp with Custom Package.ini Settings
There are many custom options available to ThinApp that can be leveraged by editing the package.ini file. Personally, we find it a bit odd that ThinApp’s advanced options are held in an .ini file, which feels somewhat Windows 3.x to us! We’re looking forward to the release of ThinApp Factory that holds all your ThinApps in a library, from which these advanced settings can be found and applied with a graphical front end – and also automates the process of creating and maintaining ThinApps. In the meantime you might be interested in project called “ThinApp Helper” that creates a nice graphical front-end on top of the package.ini file.
If you make edits to this file after the ThinApp has been built, you will need to rebuild the ThinApp using the build.bat utility, and then re-upload and import the ThinApp into your ThinApp Repository. So it’s perhaps worth reviewing these advanced options before embarking on a large full-scale project to ThinApp every application you can. This book is not intended to be an exhaustive explanation and review of every package.ini setting. What we have tried to do below is document, explain and demonstrate the package.ini settings that we feel are the most important. Invariably they fall into four categories – settings that improve performance, stability or functionality and settings that stop you needing to capture the installation of the application every time you need to make a change. You should also know that there is an attributes.ini file that can be used for further settings. Package.ini is used to modify the global project settings, whereas attribute.ini is used for changing a particular folders settings such as modifying a folders isolation mode or its compressions settings.
|Controls the isolation mode used in the Setup Capture for the file system and registry. A more aggressive Full Isolation mode is available within attributes.ini but VMware don’t recommend it.|
|FileTypes||File extensions in .doc.docx format||Allows you to modify file extensions. If you want to run Word 2003 and Word 2007 you could modify the FileTypes to make Word 2003 open .doc files, and Word 2007 open .docx files.|
Group Name separated by comma
|Allows you to modify both the access denied message and the list of permitted groups from the Groups section of the Setup Capture wizard. Permitted Groups is normally remarked out of the file if you have not set any restrictions.|
|Used to control how the Microsoft User Account Control (UAC) feature is managed, if enabled within Windows Vista or Windows 7. You can pre-set the option to stop UAC messages appearing|
|UACRequestedPrivilegesUIAccess||True/False||Stops privileged access to operating system if set to “false”. UAC is not included in Setup Captures taken from Windows XP.|
|RemoveSandboxOnExit||1 or 0||Controls whether the sandbox is deleted when the last part of the ThinApp closes. This value is remarked by default in package.ini file. Using 1 enables the removal of the sandbox. Set this option to make it impossible for the user to change settings within the ThinApp.|
Remember, if you change any of these options you will need to run the build.bat file to recompile the ThinApp.
Managing File Associations
At the moment ThinApp does not have an explicit way of managing file associations within the product. To be more strictly accurate the package.ini file does contain listing of extensions that the application claims by default – but that is it. The current attitude from folks within ThinApp, is that file associations are an element that belongs to the operating system and beyond the scope or remit of ThinApp. The attitude appears to be that job of a “Packaging Team” to manage these file associations – and if something goes wrong then it is their fault. I’m not sure we buy into this view for three main reasons. Firstly, not every organization that uses ThinApp has an application team that can dedicate hours to managing the process. Secondly, it’s Murphy’s Law that one day you will accidentally ThinApp and register a ThinApp that hijacks the default file associations. Finally, there other technologies that can and help customers manage default associations – and we don’t believe it is beyond the abilities of ThinApp to do the same.
The default behaviour is one that will be sadly familiar to those who have used Windows for some years – when two applications both claim to support an extension. In the world of ThinApp it’s the last ThinApp that registers with the system that claims those extensions by default. So, if you have two applications that support the same extension such as two web-browsers – it will be the last ThinApp registered which will “hijack” extensions of the previous ThinApp.
This default behaviour can have some “interesting” outcomes for example – lets assume that you first deploy Office 2010, and then later for backwards compatibility ThinApp and register Office 97. The default behaviour would be thus…
• If a user was sent an email with a .doc file it would open in Word 97
• If a user was sent an email with a .docx file it would open in Word 2010
• If a file was created in Word 2010, and saved with a .doc extension – and then sent as email attachment it would be opened in Word 97 despite being original created in a new version, and saved down into a lower version
• If a user had rights to Word 97, but not Word 2010 they would not be able open .docx files
• If a user had rights to Word 2010, but not Word 97 – then all files (.doc and .docx) would be opened in Word 2010
As we can see the issue is made somewhat murkier by the fact that it is the users Active Directory membership that controls which applications they can access – which in turn controls extensions are owned by which ThinApp.
We feel that for the moment you maybe better off using ThinApp’s ThinReg.exe to register applications – which then will allow you control the order of the registration process – and thus ensure the right application claims the extensions for context-sensitive double-clicks – where the user double-clicks a file, and expect an application to retrieve the file.
Managing Upgrades and Updates
IMPORTANT: We would recommend working with a copy of your project before embarking on this process. Should anything go awry you would always have your original.
IMPORTANT: For this process to work your package must not have the sandbox set to not be removed at log off. If you have used the parameter RemoveSandboxOnExit=1, then remark it out and rebuild the application using build.bat to re-create the ThinApp. Additionally, your isolation mode must be set to “WriteCopy” before embarking on the process, and set back to “Merged” when finished if that was your preferred setting for the ThinApp in production. Both settings can be modified in package.ini and then be applied using build.bat. There are number of steps/stages to using sbmerge. As a precaution you should also delete any sandbox your profile associated with the application you are updating to ensure your system is entirely clean. Otherwise you run the risk of incorporating your personal changes into the project – and passing them on unwittingly to your end-users.
Before we get down into the weeds, here’s an overview of those stages. You might want to return to this overview once you have been down in the weeds to remind yourself of the high-level steps we have undertaken. Like everything in IT from the surface it does look like a convoluted process – but once you have carried it out a couple of times it becomes almost second nature. Almost…
1. Edit package.ini and if set
Remark out: “RemoveSandboxOnExit=1”
Ensure that: “DirectoryIsolationMode=WriteCopy” is set
Desirable: Enable cmd.exe as entry point for administrative purposes
2. Delete any of your personal sandboxes for this package – this guarantees that WriteCopy is active as default isolation mode and makes sure you do not have unwanted/private settings present
3. Rebuild the ThinApp with build.bat to make these changes apply
4. Run the update or upgrade from the application if possible, OR as necessary use the cmd.exe entry point
5. [Optional: Revert to previous version non-destructively]
6. Run sbmerge to merge the sandbox into the project
7. Revert any temporary changes made to package.ini at step 1
8. Run build.bat again
Clearly over a period of time applications can and will receive updates and upgrades – either updating them from one sub-release to another (5.0 to 5.01) and upgrades between one release to another (5.0 to 6.0). ThinApp comes with its own methods of handling this issue. The primary one is a utility called “SBmerge.exe” or “Sandbox Merge”. Essentially, what this allows is for the Administrator to run the ThinApp, and trigger an update or upgrade from within the ThinApp application. This process makes changes in the administrators personal “sandbox”, and the sbmerge utility allows you to take the sandbox and merge it into the project – once the ThinApp is rebuilt the update/upgrade is available to end-users. The changes can be made non-destructively (the older version of the application is still available) or destructively (when sbmerge overwrites the previous project files – finally commits the change from version 1.1 to version 1.2 of your application). The affect on the user is the appearance of seamless upgrade.
It’s worth saying that this process can also be used to make changes to applications default settings after the main capture process. It’s possible to load up the application as the administrator – make some changes in the settings or preferences, and then use sbmerge to merge those changes to your personal sandbox into the ThinApp project. This can be especially useful if a particular settings or options only become troublesome once the application is in production use. It’s often easier to find these settings in the application than wading through interminable registry contents and trying to modify it there.
You should be able to carry out the process of updates using the applications own update routine. However, The reliability of these updaters being run in the runtime context of ThinApp can vary massively in our experience. For example in the case of Acrobat Reader 10, we kept on receiving an error message stating that the Windows Installer Service could not be accessed.
In other attempts with upgrading FileZilla – the FileZilla updater downloaded the update to the local machine, terminated the ThinApp, and proceeded to try to install the application natively to the local machine.
However, all is not lost. If your application doesn’t support this type of “in place update”, you can add cmd.exe as an entry point to the ThinApp, then download the update – and then call the update within a ThinApp version of cmd.exe. The important thing is the update or upgrade must occur within the context of the ThinApp RunTime thus making changes to sandbox along the way.
In our case example we will use FileZilla. When this chapter was wrote FileZilla was on release 3.5.2. Of course as we went through the polishing and review process – FileZilla has since released a new version of the software. At the time of writing according to them the latest version of the software is 3.5.3. This is of course, a highly important update – and we must deploy it to our users at the earliest opportunity!
1. Login into your “Capture” VM, and download the update you require…
2. Whilst that is downloading at your “Build” VM, locate the package.ini with the ThinApp, and open with notepad
3. Next search for cmd.exe as one of the entry-points in the ThinApp – it should be reference down at the bottom of the file. In most case this it will be turned off with the entry disable=1. Modify this so instead the text reads:
4. Confirm that the “isolation mode” is set to be “WriteCopy”. If the isolation mode is set to “Merged” – then change the [Isolation] parameters accordingly. Remember for sbmerge to work you must use the “WriteCopy” mode during the process.
5. Confirm that RemoveSandboxOnExit=1 is not engaged, and if it is enabled disable it by remarking the option out with a semi-colon ;
6. If you have run the application before from your “Capture” VM, ensure that the sandbox is deleted from your administrator account login. The location of the sandbox will be very much dependent on how you manage user profiles by default it is located in: C:\Users \Administrator.CORP \AppData \Roaming \Thinstall
If you don’t do this your own personal changes to the ThinApp that have accrued could accidentally become incorporated into the Thin project. Deleting an existing sandbox ensures the ThinApp is run in a clean state. The sandbox is located where ever %APPDATA% resides. Opening a command prompt and typing cd %APPDATA% should take you to the correct location for the current logged in users sandbox.
7. Save the package.ini file and rebuild the ThinApp with the build.bat script. This should add cmd.exe as new entry point in the ThinApp “bin” folder like so:
Note: Again we have created a number of rather unnecessary end points because we merely accept the default options. There is no real need to make the uninstall.exe end point accessible.
You must use the cmd.exe from the bin directory of the ThinApp itself. This ensures that when you run the update/upgrade it happens within the context of the sandbox – that will be later merged into the project.
8. Next move into the directory where the upgrade/update package was downloaded – in our case C:\Users \Administrator.CORP \Downloads – and run your upgrade package.
Revert to Previous Version (Non-Destructive Upgrade)
At this point the changes that have been made haven’t been permanently committed to the project. The affective version will be your update/upgrade version that was recently installed. So if we run our version of FileZilla, although the folders still show the old name of 3.5.2, the actual ThinApp is the newer 3.5.3 version. This version is running inside your personal sandbox – and does not affect end-users running the application from the same shared location. When you run the ThinApp you will get the 3.5.3 version, when they run it they will get the 3.5.2 version.
Note: ThinApp from the “package administrators” perspective.
Note: ThinApp from the “end-users” perspective.
Now assume you begin the process of rigorous testing and in that time you discover a bug, error or incompatibility. We can actually revert the application back to its previous state. This is because the upgrade/update resides in your personal sandbox that has yet to be committed (with sbmerge) to the ThinApp Project. Simply by creating a folder called “thinstall” within the “bin” directory force the older version of the application to be launched instead.
If you delete the “thinstall” folder the new version is run from administrators sandbox instead. This according to the folks at VMware ThinApp is an unique feature that only they provide currently. The typical mistake that most folks make here is they accidentally type “thininstall” instead of “thinstall”.
Commit new version with SBmerge (Destructive Upgrade)
Once you are happy that the upgrade/update ThinApp is now functioning correctly we can use sbmerge to take the version residing in our administrators sandbox, and merge it into the project. This is a destructive upgrade and once completed the trick with the “thinstall” folder shown above will no longer work. This also updates the project such that the upgrade is applied to end-users as well. When previously only the administrator had access to the upgraded version of the ThinApp.
1. Close the ThinApp command-prompt opened via ThinApp, and any copies of the ThinApp itself
2. Next open up a local command-prompt on the “Capture” VM – in this case we need to run the sbmerge.exe from local command-prompt
3. The easiest way to run sbmerge.exe is from the ThinApp project folder – which means it just takes the sandbox difference created by the update and merges that into the main ThinApp. We use the “apply” switch to complete the process:
Note: Here we mapped a network drive called X: to the shared location on the VM that has the ThinApp Software installed. Then we moved into the ThinApp Project directory associated with FileZilla. The two ..\..\ allows the command prompt to locate the sbmerge utility, and defaults to applying the sandbox to the Project in the default path. What you will see next is sbmerge move all the files captured during the upgrade/update to the administrators sandbox, into the project location.
4. Once sbmerge has merged the sandbox data together we undo the changes made in package.ini earlier – such as the isolation mode, sandbox removal and the addition of the cmd.exe entry point. The sbmerge utility removes the upgrade data held in the sandbox, and makes it a part of the project.
5. Then we can re-build the ThinApp again with build.bat.
Using the ThinApp AppLink Utility
WARNING: During our early use of AppLink we had problems getting ThinApps to be linked together. That wasn’t a fault of ThinApp but a fault in our understanding. In somewhat desperate bid to make AppLink work we tried “registering” the ThinApps. That was a mistake. Not because “registering” ThinApps is bad or wrong thing to do. But more that the two process are NOT remotely linked. AppLinking is totally separate issue and concept, and has nothing to do with registering. It’s an important distinction because the registering process does modify the operating systems file system associations – and could give a false impression that AppLinking is functioning correctly. We want to tell you about this because we want to be honest, but also think that if we can make a silly mistake – then chance are that other folks will do as well.
It’s common that different applications have other software dependencies that must be met first, and application virtualization can go a long way to addressing these issues. For example you may want one website open with FireFox and Java 2.0, with the rest opening with native web-browser such as Internet Explorer Additionally, you may want to have the dependencies to be easy to uncouple. It makes updates much easier – if you have 6 applications that all use Java, you could link to one capture of Java for all 6 applications. By updating Java just once you would update it for all of them – although we would recommend thorough testing before doing so! So if at latter stage you wanted allow Internet Explorer 6 to use Java 6.0 you would not need to rebuild the ThinApp from scratch. It’s for precisely this sort of scenario that AppLink was developed.
One of the easiest way to AppLink is to create “plugins” folder inside the “bin” directory of the application – and then populate it with end-points that can be called by the ThinApp. So in the case of a web-browser the folder would reside say within a capture of FireFox, and in the plug-ins folder would be components like Java or Flash. If you have many ThinApps that share the same plugins this could be a shared location.
Capturing JRE 6 and FireFox 11
Note: If you are looking for the complete list of current and past version of Java, Oracle’s archive page is good place to look:
1. Ensure your capture VM is in clean state
2. Run the ThinApp Setup Capture
3. Install FireFox 11 and Build the ThinApp
4. Next without resetting the VM, capture the JRE 6 Update 30 installation
We take this particular order of install to ensure that Java enables support for Mozilla. If we didn’t support for Java would not be added to Mozilla. The same goes for other plug-ins and Mozilla. For example if you open IE during the capture process, and install Adobe Flash even once it is installed, FireFox complain about “Missing Plugins” even though flash is there, and works fine. By the end of this chapter we personal had a hatred for FireFox and Flash that knew no bounds. Welcome to the Wonderful World which is end-user applications!
5. So the same session we went on to capture Java 6 Update 30 in the same way…
6. At the installation you might want to launch FireFox at the website or system that requires Java 6 to load. This will allow you to deal with any web-browser preferences or Java based pop-ups you would like the user not to see.
7. At the end of this process we saved the project, and built the Java 6 ThinApp
8. Once the build process has completed, you can revert the Capture VM to a clean state
AppLinking JRE 6 to FireFox 11
1. On the Build VM, navigate into the Bin directory create a new folder called “Plugins”
2. Copy the Java JRE 6 end-point into this location
3. On the Build VM, open the package.ini for FireFox 11
4. Underneath the [BuildOptions] remark out the “;OptionalAppLinks” line by typing:
5. Save the package.ini file, and re-run build.bat for FireFox 11
You can test your Java Version by visiting a website like javatester.org/version.html and of course, you can switch from version of a plug-in or update plugs by simply dragging and dropping them in and out of the plugins folder.
Once the optional plugins folder is enabled you can add and remove plugins at will. The ThinApp will check this folder every time it is launched.
Managing ThinApp MSIs
Occasionally customers want to modify the .MSI file that’s created by ThinApp using third-party packaging tools such as Microsoft Orca. For example they might wish to use the .MSI to add a registry key or use it to call additional .MSI’s from the ThinApp. The important thing to note here is that if you attempt this it will fail. The .MSI file generated by ThinApp has a special structure that conventional packaging tools cannot interpret – as it contains a virtualized file system within it. Indeed attempts to edit the ThinApp .MSI is most likely to cause corruption. For this reason every ThinApp has its own template.msi which can be loaded up into conventional packaging systems – so long as you restrict your changes to it you should be fine. Of course, after making changes to template.msi you should rebuild the ThinApp with build.bat to enforce your changes to the ThinApp .MSI file.
Other ThinApp Utilities
There are plenty of other important ancillary utilities bundled with ThinApp and these will be useful if you decide to become a long-term user of the product. These include:
|relink||A new .exe introduced in ThinApp 4.5 for legacy versions of ThinApp. It allows the administrator to update older ThinApps to work with the new ThinApp runtime
Important: ThinApp 2.7.2 introduced new integration options to Horizon Application Manager – specifically the ability to relink and stream applications via the Horizon portal. To enable this feature any previously created ThinApps would need updating. There are couple of ways to update ThinApps to support these new functions. You could re-capture, you could edit package.ini add the Horizon settings or you could use relink which now supports –h switch specifically for Horizon. Full instructions can be found in KB 2021928
|Log_monitor.exe||Used to troubleshooting ThinApps|
|AppsSync||AppsSync checks a location on the network for an update or a new version of the ThinApp. It allows to update a deployed package with a new version of package – the benefit is an incremental update which only downloads the difference and therefore is very efficient if you delivering the ThinApp across the WAN. One of the advantages is for keeping software up to date on “unmanaged” systems – such as contractors PCs. Where the contract brings in their own laptop, needs company software – but isn’t part of the domain.|
Application Virtualization isn’t going to be a good fit for everyone, with every application – but we are firm believers in the less you install to the virtual desktop the better. We don’t really care that much if you use VMware ThinApp or some competitor; we believe in the virtues of application virtualization as an inherent good. But realistically we accept that it will be inevitable that some applications will either be too complex or bulky to virtualize. A virtual desktop will still help in terms of maintaining that software. You will be able to update your parent image in linked clones with new software, and then refresh the desktop to make that new build available. That must be more efficient than pushing out bulky updates from software vendors across the network.
In the future we might look forward to a brave new world where end-user applications are delivered in the cloud through HTML5 standards. However, in the short to medium term it’s likely to be the case that a hybrid model will exist – a blend of cloud applications together with conventional Windows .EXE’s that have been made more manageable via the good use of application virtualization.
Now that you’re completely happy with the View and ThinApp environment we’re going to take a look at the future of application delivery – a short survey of technologies from VMware such as Horizon Application Manager (HAM), ThinApp Factory (TAF), and AppBlast amongst others. We were “lucky” enough for our book project to be delayed (with the release of View 5.1) because this has allowed to us to add two additional chapters to this book. One on ThinApp Factory and the other on Horizon Application Manager – it just so happen we had some free cycles during the “review” process that we were able to sneak them in. If you have no intention of using ThinApp Factory or Horizon we would recommend just reading the next chapter so you know something about them. If your more curious you might choose skim this next chapter and head of those instead. The choice is yours.