Virtually Jason

I was performing a late night p2v of a Windows 2008 server the other night and I ran into an issue that I figured I’d share. This server was initially installed with the help of Dell’s server utility, and as such the first partition on the drive was one of those small utility partitions. Standard practice during a p2v is to leave those partitions behind. Since the server’s not on Dell hardware any more, Dell’s utilities aren’t going to serve a purpose. Most of my experience with p2v is with Server 2000 and Server 2003 (and in fact, I’ve done more NT than 2008 at this point), and with 2003 I’ve seen those partitions cause more harm than good. We moved forward with the cookie cutter p2v of the server and the first anomaly was the fact that the utility partition was the Active partition (as opposed to the C: partition with Windows installed). Given that Converter doesn’t give you the option to leave behind an active partition any more (and I do miss that option), we decided to forge a

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