Virtually Jason

Update:  I just posted a followup to this post with an easier process for recovering a lost Unidesk Application Layer VMDK .  This post still has a lot of good information about what's going wrong with the system when one of those VMDK files are deleted, so it's still probably worth a read. We had a bit of a PEBCAK issue recently where an administrator (read: me) was cleaning up some older View only desktop pools to clear up resources to bring in more Unidesk desktops.  Inadvertently, a Unidesk desktop pool was deleted from the View Administrator and the option to delete all VMs from disk was selected.  Oops.  By and large, you could probably do this and get away without any issues (aside from needing to restore those desktops), unless you deleted all of the desktops that are using a particular instance of an Application Layer.  Let’s look at what happens in that situation (based on what happened when we accidentally did just that). When you open up the View Administrat

I've recently had the opportunity to deploy Unidesk at one of my customer sites for their VDI solution.  I was preparing to write up a post about the install process, but it was actually very simple and is extremely well documented on their site (which is sadly behind an authentication wall so is not google indexed).  If I did end up writing such an article, it would end up just being a big love letter and wouldn’t be particularly interesting to anyone (well, with the possible exception of the Unidesk sales team).  Instead, I’m going to write this article about some of the things that I've broken and fixed, and some of the interesting things that you can do from a troubleshooting perspective. First, a brief overview of Unidesk.  It’s a Layering technology.  A given desktop is basically a collection of read-only vmdk files that are all stacked up together with their specialized driver in Windows to make it look like a single hard drive.  On one of those vmdk files you’ll