Virtually Jason

I’ve been working with Unidesk lately, as well as with the vSphere PowerCLI .  One of my customers has also been having an intermittent issue where they cannot browse their datastores (it just sticks at “Searching Datastore…” until they lose patience and close the window).  All of this has gotten me thinking about the relationship between vCenter and the ESXi hosts.  When we send a command to vCenter, such as creating a new VM, we all know that vCenter is simply relaying that command to one of its ESXi hosts, which does the actual work.  Same thing with file copies through the Datastore Browser, and in fact even reading the datastores through that same tool. How do we, as administrators, know which ESXi Host vCenter is using as its “workhorse”?  In a clustered environment, it’s really very unclear.  It turns out that, if that workhorse ESXi host is having an issue, it may prevent a lot of those basic vCenter functions from working (such as the aforementioned “searching datastore

One of my customers deleted their Unidesk desktops from the View Administrator again and, once again, the system happily deleted a layer from the CachePoint.  This causes a problem in that you can no longer build desktops on that CachePoint that use that Layer (read that linked older post if you want more detail about that situation).  Last time this happened, we knew which Layer was affected because it was a rarely assigned application, but this time we didn’t have any such indicator.  We went through a discovery process this time that we didn’t go through last time and we came up with a far easier solution this time, so here’s the scoop. First, we had to figure out which Layer was affected.  To do so, I used the Datastore Browser in the vSphere Client.  I knew which CachePoint was missing the Layer, for that CachePoint was the one that was failing to build out the desktops.  I simply Browsed the datastore that that CachePoint manages, as well as the datastore that houses the M

One of my customers has been having an intermittent issue with their Windows 7 VDI Desktops.  Occasionally after they update the Operating System, when the desktops boot back up they fail to use their NICs.  The NIC is still attached to the VM and is still on the right network, but Windows fails to recognize it (it doesn’t get a DHCP address and, in fact, registers within the OS as being physically disconnected from the network).  Restarting the desktop doesn’t help, reinstalling drivers doesn’t help (we’re using the VMXNET3 network adapter, for those who are interested).  Removing the adapter from Windows seems to be the key to getting the desktop back online.  We’ve gotten desktops back online by removing the adapter from Device Manager and then scanning for hardware changes (and rebooting).  We’ve also removed the NIC from the VM (with the VM shut down) and replaced it; that’s also alleviated the issue. Unfortunately, those steps just alleviate the symptom.  They get people ba

Andre Leibovici has posted an interesting article at myvirtualcloud.net about direct PCoIP connections to VDI Desktops .  Apparently, VMware is testing this ability right now and is considering making it generally available; I find this fascinating! Andre points out a couple of use cases that seem largely focused on the small business space.  The use case that I’m most interested in is the “Cloud Provisioning” option that he mentions.  I’m interested in that because, near as I can tell, “Cloud Provisioning” really just means “desktops that are not provisioned or managed by View”.  That is exciting because it might open the doors for deeper 3 rd party integration or whole 3 rd party connection brokering for PCoIP (like the late Panologic did with RDP sessions). My favorite aspect of Panologic’s solution was how seamless it was, from the user perspective.  Since the VDI desktop could be associated with the Pano device, the RDP session was established as soon as the device boo

We recently experienced some confusion when creating vShield App firewall rules, so I figured that it would make for a good post.  For those who are unaware, vShield App (which is now a component of the vCloud Networking and Security solution) is a virtual firewall.  Rather than being a traditional firewall though, which allows for rules based on either layer 2 or layer 3 constructs, this firewall integrates with vCenter and so can have rules based on vCenter constructs.  At first glance, this is a little confusing, but once you become familiar with the concept it becomes very empowering. We have a motley collection of Port Groups in this VDI environment.  Each Port Group needs different firewall rules to be applied to it.  We have a “production” Port Group where the bulk of the customer’s employees sit, we have an “internet only” Port Group for external users and we have a whole bunch of Port Groups that are in between those two extremes for consultants, which allow that consult

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

Yeah, I know that this isn’t Virtualization related, but I scoured the internet over the weekend and wasn’t able to come up with this bit of data (and so had to go the trial-and-error route)… and this is my best venue for adding it to the Google Index.  If you’re building a piano stand for a Yamaha P-95 B digital piano, you will need 4 very specific bolts in order to attach it to the stand.  Those bolts are standard 10-32, and the threaded holes on the bottom of the piano are at least an inch deep.  No, I'm not mechanically inclined and no, I don't know what those numbers mean besides a nebulous concept of "size".  And now back to our regularly scheduled programming.

You’ve rolled out a shiny new VDI solution, but most of your user base is on good physical desktops that don’t need replacing… and that you don’t have the budget to replace with thin clients yet.  What do you do?  I think that most VDI rollouts get to the point where they’re asking that question eventually.  There are two main answers that you get (ignoring the “replace them anyway!” opinion).  You can run your View Client as an Application on the desktop or you can run it as the desktop’s Shell.  In my opinion, they are both viable solutions... but they both certainly have drawbacks.  Let’s talk about the Application option first. The View Client is an application, just like any other.  That means that you can place a shortcut on the user’s desktop and, after they sign in, they can start it and log in to their VDI Desktop.  If they user needs to get out of their VDI Desktop, it’s very obvious that they can simply minimize the window (or even close it).  This fact is both a good thi

One of my customers asked me to convert some of their physical Windows desktops into dedicated VDI Clients.  A quick google search revealed a VMware Blog post  with some basic instructions.  They’re written up for Windows XP, but they work fine for a Windows 7 Client as well.  Basically, you just change the registry on the client machine to run a VBS script that calls a batch file that starts the View Client, instead of starting up the normal Explorer shell in Windows.  It’s a very easy change to make and, while it’s quick and dirty, it does what it’s designed to do.  I use a slightly modified view.cmd file, as seen below. Rather than just starting an infinite loop that keeps the View Client running, this version will allow a user to actually log off of their client device when the View Client closes.  If not for that change, when they log out of VDI, they’re right back at their desktop selection screen, since the user is still logged in to the client device (which causes some secur

A customer recently came to me with a very specific request.  They wanted all of the drive mappings that each user had created on their local workstation (their View Client) to be created on their VDI Desktop.  Without roaming their profile, I created a simple logon script for the VDI Desktop to execute (VMware’s Profile Migration does not capture Drive Mappings, at least not when converting from XP to Win 7).  As you’ll see below, I really just found 3 other smarter people’s scripts and mashed them together  (with some minor adjustments to work in the VDI scenario) in order to get them to do what I needed.  Since the results are highly specific (and a bit interesting), I figured that I’d go ahead and post the script.  Be aware that it abuses the fact that, in this environment, everyone is a local administrator on their physical desktop, so I expect that some of the client registry queries might fail under other circumstances. Just so that everyone knows, the customer is consider

Getting control over your Default Printer in a Windows 7 VDI environment is a little more difficult than I would have expected.  There are a lot of different factors that can come into play and, depending on the type of client connection, you can get some unexpected results.  Here are the factors that I know of that can set a desktop’s default printer: 1) The user’s Profile 2) A logon script/GPO 3) Windows’s spooler behavior when the default printer that it expects is missing 4) The TPAutoConnect.exe program (which executes automagically at PCoIP session connection) My current customer is intending to use a combination of #2 and #4.  The logon script is setting their network printer based on who they are and is responsible for 90% of the printer assignment.  TPAutoConnect.exe is used to install direct-attached client printers and map them into the VDI desktop.  The simple fact that the plan doesn’t involve #1 and #3 doesn’t remove them from the equation… they’re still happil

So, I implemented Persona Management a few months ago and figured that I’d write a quick followup with my experiences since then.  As a technology, it strikes me as both really cool and a little difficult.  It deals with the persistency issues that you would typically enable Roaming Profiles to resolve, and  I haven’t seen any of the profile corruption issues in Persona Management for which Roaming Profiles are infamous.  So, that’s a plus.  It also does what it’s supposed to do, which isn’t always a given when you’re working with relatively new technologies.  That said, there are some issues that it seems to have introduced into this environment. 1) Rapidly logging back in after logging out causes a hung logon. 2) Loopback processing applied logon scripts are ignored after the initial Persona is created. The rapid logoff/logon issue doesn’t strike me as vital.  I’d certainly like to fix it, but that’s a fringe case and it seems to be self-correcting after a few more logon attemp

One of my customers has been trying to figure out how they are going to deal with printer assignment in their View environment.  In truly stateless desktops (without Persona Management, even), you have to completely depend on external printer assignments, either through a logon script or through Active Directory.  I prototyped both solutions for this customer.  In order to minimize our logon times, we preinstalled our printer drivers in the parent image (for both tests). We found that a normal Windows 7 logon onto a stateless desktop (where it’s always the first logon and so has to create a local profile and apply group policy) takes about 20 seconds from the time the user hits “connect”.  Using Group Policy to distribute printers increased that logon time to about 45 seconds… which was a bit too much for my liking.  Using a logon script, on the other hand, does not delay the logon process (even if the printers are not actually present immediately upon logon), and so this is the

I feel silly linking to the Lone Sysadmin, as if my blog might get readership that his doesn’t, but I recently had to configure an MSSQL 2008 server for VCenter  for one of my customers, and his article on that subject was amazing.  I am by no means a DBA, but I feel that, by following his process, I’ve configured a server that a real DBA might look at and not immediately break down with tears of frustration.  In case any of you have missed it, it’s an excellent read and seems to result in a very robust configuration.

One of my customers recently had a fairly unique issue.  It was unique enough that I thought that it would make an interesting write up, just in case anyone sees something similar in their own environment.  We haven’t been able to track down root cause, but what ended up happening is all of the pointer VMDK files on a specific LUN were deleted.  The –flat.vmdk files were still there, but none of the <VM>.vmdk files were present.  This meant that no VM on that LUN could power on, as they were all throwing an error “File <unspecified filename> was not found”.  That error message is slightly better than “An unspecified error occurred”, but only just barely. This customer is still on ESX 4.0 and, as you’d guess, they’re pretty far out of date as far as patches go.  In addition, one of the fibre ports on their switch was flapping, causing some intermittent storage access issues.  Neither of those facts sounds like a cause of the issue that we came across to me, but we didn