By Don Wiggins on January 14, 2016 21:41
Throughout my career, I have noticed my IT skill set is made much of opportunities that have been presented to me. Often times, there is no other way to gather the invaluable real world experience that can only be found when fighting for career survival.
For me, the path presented to me took me quickly into a server room and worrying more often about databases, storage throughput, and I/O than SCCM, packaging applications, and customizing installations. After my path took me to virtualization and my storage specialties brought into VDI workloads, I worked to round out my ability to offer the entire solution I was being tasked to deliver. The Windows OS was still Windows; I had plenty of understanding of Windows OS’; I had worked on Citrix farms, (but never really cared about what was installed on them); and all I cared about was resource usage. I was not a novice but what I didn’t know at the time is what I didn’t know. I was in for an education on how the complexity of abstracting an application from the operating system.
For those who work with application virtualization, remote delivery, etc., there are two kinds of relationships people have with it: love/hate or hate/hate. To me, application virtualization and remote delivery provides options.
So, to cover the “Art” piece of this. Some people I have known, as well as myself, say there is more art than science to application virtualization. To a certain degree, that is the truth and that’s what makes it hard so often. I have followed a SOP and gotten a different result in what seems like the same circumstance. It is not all hopeless though. While I cannot tell you how to virtualize every app, I can offer some insights based on my previous experiences.
In this first series on Application Virtualization, I plan to start where I started – with the basics of ThinApp. Many people try to avoid ThinApp but right now it offers a very unique architecture that is hard to beat when it works. It allows you to remove an application from the OS like a Citrix application while allowing you to have it on top of the operating system and hook into the registry and file system like it is locally installed. It is an amazing capability and allowed us to do things on a non-persistent virtual desktop that people could not believe was possible. For the ones that purely hate it, I understand. It may be the most maddening task I have ever done in my career given the complexity, grey area, and annoying procedure you have to follow to test. A quick change takes an hour, only to find you have to go back to the drawing board. I have had a few projects I was nearly ready to walk out feeling like I would never get it to work. No kidding there, it can make you feel like you will never win.
To quickly explain how ThinApp works – A ThinApp is basically the delta’s of the changes an application makes to the operating system placed into a executable to merge in pieces so that is may work symbiotically with the guest operating system. Much like a linked clone, ThinApps are the read package (like a Replica and the Sandbox/OS is the linked clone.
First, REALLY make sure your capture machine has no patches. Open Add/Remove programs and look at the installed Windows updates. If there is a single patch listed, uninstall it. If you can’t, get a different image. I would just getting a new image with no patches from the start. Install Service Packs the old way, if necessary. An application requirement would be one reason to do so.
Second, do not delete your package! I see this often and it pretty much sets you up for doing all your hard work over at a later time. Or in some cases I have seen, a new guy getting completely hosed having a bunch of ThinApps that he cannot edit and doesn’t know all that was done to capture them the first time.
Folders, Files, and registry are a good place to start on where the rubber meets the road for a capture. Knowing what folders the application installs to and what you want isolated, merged or write-copied are important keys to successfully capturing an application. That, and it working.
For a quick explanation of the isolation settings – Isolated will keep the folder, files, and contents within the package isolated from the operating system. Merged will merge the data with the guest operating system, Write-Copy will write a copy to the user sandbox.
Knowing the Windows registry will do you well. When I first started doing ThinApp captures, I thought I knew a lot about the Windows registry, boy was I wrong. I feel like I have gone from stumbling and Googling to reading the Matrix when I navigate the registry for what I missed and what is going on. Without a decent knowledge of what the application is setting in registry, complex applications and especially customizations to installs will be very hard.
When working on a package I will say, it is alright to research and it is alright to work with people more familiar with the application. It is often times very hard to do non-standard applications with no understanding of them. It is impossible for anyone to know every application. Also, be prepared to find little help from vendor support. Often times the knowledge of the application is what resolves issues. Knowing how to apply the change in ThinApp is often not the hard part. Knowing what it does to the application and why are.
In the next series I will cover some of the more technical concepts and exercises in ThinApp, as well explaining how AppVolumes, Flex-Disk, Flex-App, and RDSH hosts can be used in conjunction with ThinApps to offer additional benefits.