Virtually Jason

One of my customers had a challenge with a nonpersistent VDI pool.  They were using a web app that required some specialized software in order to work.  That specialized software installs per user, when the web app is executed.  On persistent desktops, it’s not too big of a deal, since the user installs it once and is good to go.  On the nonpersistent pool, it proved to be a pain point, as it was prompting to install every day for every user. After digging into it a bit, it turned out that the key to the install was a .cab file.  Extracting that file didn’t prove helpful, so I went another route.  If you buy VMware View, you get ThinApp along with it.  So, I ThinApped Internet Explorer and set it to WriteCopy isolation mode.  I stuck the executable onto a file share and created a ‘thinstall’ folder alongside it (so that the sandbox for that package would reside on the file share).  Once that was in place, I instructed one of the desktop ad...

ThinApps occasionally require some special manipulations to get working correctly.  One of the most common issues that I’ve seen with otherwise working ThinApp packages is a failure to close correctly.  Sometimes, even after a ThinApp is closed, a process will be left running that might keep the sandbox undesirably locked or cause issues with re-execution.  An easy way to resolve that issue is with a ThinApp Script. These scripts can be used to solve all sorts of issues.  A ThinApp Script is just a VBS script that runs at one of four specified points in a ThinApp’s execution.  The vbs script can be named anything, but should be placed as a sibling with the package.ini file (you only get one vbs file though a script can call another script ad infinitum), in the root of the package.  The vbs script will be automatically baked into the package, and each of 4 optional functions will be executed at the appropriate time.  Those functions are as follows...

Every now and then I get a little too aggressive when cleaning up files in a ThinApp package and all of my file type icons disappear within that package. They’re fine in the OS, but viewed from the ThinApp itself, you get nothing but default Windows icons. Microsoft Office is notorious for this – the actual ThinApp executables all have good icons and files within Explorer all look good… but the Open Dialogue box has no working icons! It took me a bit of poking around to figure out what was happening, so I figured that I’d write it down here so that I can easily look it up in the future (and maybe someone else will benefit from this too!). The problem (with Office) comes from when you clean up files from %systemroot%\Installer. In my ThinApp Office 2010 Instructions you’ll notice that I do some work with Robocopy – that’s to work around this issue. Rather than just preserving the executables that Office uses (which was my goal there), I’ve decided to actually go into some detail...

When you install ThinApp, it includes several utilities that are very useful for manipulating and troubleshooting your ThinApp packages. One of them is vregtool, which I’m going to discuss today. Vregtool allows you to examine and manipulate the registry for a ThinApp. Why would you need this when you can simply embed Regedit inside your package and use a tool with which you’re already familiar? Well, vregtool can be used to examine .tvr files, like the registry change files that get stored in the sandbox. What this means is that you can start up a ThinApp, change some setting and then examine exactly what registry change was made to reflect that setting change. That can make it very easy to cherry pick the application settings that you want to embed within your package, vs. those that you want to leave out. Perhaps the concrete example of my use case will help this to make sense. A customer recently had me package Office 2007 for use in their VDI environment. Office 2007 i...

A customer recently asked me to deploy Microsoft Office 2010 (KMS Licensed) to their 64 bit Windows 7 VDI desktops and so, after a little work, I was able to get a working ThinApp package. As an added difficulty, we are using a Floating Pool and so have redirected the users’ %appdata% to a file share on an SMB2 NAS device (so we’ve disabled SMB2 in Windows 7 until a ThinApp release where this doesn’t cause issues). Here are the steps that I followed, mostly taken from the excellent blog entry that VMware put together (http://blogs.vmware.com/thinapp/2011/02/quick-start-guide-for-deploying-office-2010-using-thinapp-461.html). I began this procedure with ThinApp 4.6.1, moved to 4.6.2 and have now run it with 4.7. 1) Prepare a clean capture machine. I use 32 bit Windows XP for my capture machine and have come across licensing issues when capturing on Windows 7 32 bit. 2) Perform the prescan 3) Install Microsoft Office, selecting a Custom Install and (people recommend ensur...

An easy way to restrict who can access a given ThinApp (for example, for license compliance or even just to simplify the thinreg script) is with Permitted Groups. When you restrict a package to certain AD groups during the capture process, it simply adds a “PermittedGroup=XXXXX” line to the [Build Options] section of the Package.ini file. This means that all entry points for the ThinApp are restricted, only giving users in the defined group(s) the right to execute to execute. Alternately, you can set the PermittedGroup line under a specific entry point in your Package.ini file, in which case that restriction is only applied to that specific entry point. It’s important to note that this sort of restriction only applies to the entry point itself, not the actual executable within the package. What this means is that, if you create a command prompt entry point for a package, even though another entry point might be restricted a user, from that command prompt, could still invoke the ap...

Here’s a quick tip – when testing a ThinApp, you’ve got to make sure that you have a clean sandbox for each testing iteration. If you fail to clean your sandbox, you’ll bring junk over from a previous test and will taint your results (usually in the form of confusing failures to start). We all know that ThinApps default to storing your sandbox in your profile (%appdata%\Thinstall\Package Name). What you may not know is that that is not the first location in which the package will look for a sandbox. A quick and easy way to make a fresh sandbox for testing (without having to rename an existing “known good” sandbox) is to just create a directory alongside your package named “Thinstall”. There’s actually about a dozen locations in which the package will attempt to place a sandbox prior to using the specified location in the package.ini file – this makes it very easy to override that behavior for testing, without the need to rebuild with a new package.ini setting. You can overri...

Hi – I’m Jason Coleman and have been working in the virtualization industry since 2005. I’ve decided to start this blog in order to document some of the tips and tricks that I’ve picked up and to give back to the community that’s been so helpful to me as a professional. I’m going to start with an easy one: If you’re like me, you enjoy using Putty from a command prompt or at least invoking it from the “run” dialogue. On a laptop or even a dedicated VDI desktop, this is easily accomplished by placing the executable in a folder that is already contained in your PATH variable. In a floating VDI Pool where Putty is only available to a select group of users, it is slightly more complicated. Here’s how I did it. I packaged Putty with ThinApp and used ThinApp to restrict access (using the permittedgroups entry in the package.ini file) and place a shortcut into an appropriate directory. Packaging Putty is about as easy as it gets – it’s a standalone executable. Literally, run your presca...