Virtually Jason

I’ll say it again – I’m not an Active Directory guy. That said, my customer had me out to implement a VDI solution for them and, as we all know, that’s highly dependent on Active Directory (at least, if you’re using Windows desktops). This particular customer didn’t have any printer deployment solution in place; instead they sent out a member of their IT team to configure each user’s printers manually. Needless to say, that printer solution doesn’t scale very well into a Nonpersistent Floating desktop pool scenario, and just as obviously, it fell upon me to guide them to a better solution. This customer is using Windows 2008 R2 print servers and has Windows 2008 Domain Controllers. There’s some pretty cool GPO based printer deployment solutions in this version of windows, so the first solution that I attempted was to just use Active Directory to deploy printers when people log in. I was able to get this working without too much difficulty, but in the Floating environment, it a...

IOPS – Input/Output Operations Per Second – is a key factor when designing a View solution (more important than storage space even, given the various tools that deal with storage consolidation). That’s old news. What I’ve been having fun doing recently is trying to determine just what kind of IO I can expect from the various LUNs that have been carved from my SAN. I’m using pretty standard techniques here that would work for any server analysis, however I’m applying them to my virtual desktops in order to ensure that my storage can support the number of desktops that I plan to load up. We’ve probably all seen tables that reveal per disk information in a table like this (taken from Wikipedia): Device Type IOPS Interface Notes 7,200 rpm SATA drives HDD ~75-100 IOPS [2] SATA 3 Gb/s 10,000 rpm SATA drives HDD ~125-150 IOPS [2] SATA 3 Gb/s ...

So, I don’t know anything about database administration. One of my customers is primarily an Oracle shop, which is fine for most things VMware (even if VMware’s Oracle documentation isn’t quite up to the standards set by their SQL documents). View Composer 2.7 however, has a very specific version of Oracle 11g R2 that it’s looking for (11.2.0.1 Patch 5, to be exact). I’ve never in my life applied patches to an Oracle client (and prior to working with this customer, I’d never installed the Oracle client at all!), and boy could they learn a thing or two from Microsoft… or VMware… or Symantec… or just about anyone else who has ever sold software, ever. I used to complain about the experience of browsing HP’s or Dell’s website, looking for firmware or drivers. Dell has implemented a nice work around with their service tags so that you will hopefully never need to actually navigate the site. HP’s site is indexed by google, so once again you’ll hopefully never need to actually brows...

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...

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...