Virtually Jason

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