View Persona Management Update and Logon Scripts


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 attempts (basically, after waiting long enough for the persona to complete synchronizing).

The issue with logon scripts is much more important and is what I’m currently troubleshooting.  We’re doing all sorts of things with logon scripts right now (which you may have gathered based on the number of recent posts that touch on that subject), and the fact that they are not running when VPM is enabled is causing some grief.  Testing and troubleshooting has revealed a few interesting facts about this issue:

1) It only seems to apply to Logon Scripts that are applied by a Loopback Processed GPO.  That is to say that it is a User Logon Script that is on an OU that contains the virtual desktop’s Computer account.  User Logon scripts that are on OUs that contain actual User Accounts work fine.
2) The problem only comes up on subsequent logons.  The first time a user logons on (before they have a profile for Persona Management to download), the scripts run just fine.  Only subsequent logons are affected.
3) Examining RSOP.MSC on affected logons reveals no logon scripts (from the Loopback Processed Policies), however GPRESULT /R reveals that the desktop is applying those policies (so they’re not being filtered out for some reason).
4) VPM seems to be the important variable.  I’ve set my pool’s Parent Image up in the VPM OU (logging into it directly as a test bed) and recreated the issue without Linked Clones being in place, and I’ve set that Parent Image up in an OU without VPM and watched it receive those Logon Scripts successfully, even after a local profile was created.

This is pure conjecture, but considering those observations (especially #3) leads me to believe that VPM must start its process after the initial application of policies but before the loopback policies are applied.  It either interrupts the application of the loopback policies or overwrites whatever settings are being created to run those scripts with stale (pre-loopback processed) data.

I have a support ticket open about this issue and so will post an update when I have more information.  My gut feeling is that this is a bug in the current implementation and that we can look forward to a fix in the future.  One of my coworkers suggested a very effective workaround that I have in place right now.  It’s not as elegant as a GPO with a centrally available script, but these scripts should need almost no changes and so it will work well enough.

His suggestion, which I’ve successfully prototyped, was to use a Scheduled Task in Windows 7.  The trick was to set the task to run as the local “Users” group, which has the end result of the task running as whoever is logged in at the time (or at least seems to).  I defined my task’s Trigger as “At log on” for any user, and set the Action to run my script.  I could probably run the scripts based on a UNC path, but for now I’m going to play it safe and just have local copies on the VDI desktops themselves.  This requires that I recompose to update the scripts, but these scripts shouldn’t need updating any time soon.

Update: out of the blue, my logon scripts started working.  The AD guys didn't change anything and I only made some minor changes to the scripts (to write logs instead of throwing message boxes when a troubleshooting flag is set).  The only thing that I hate more than something failing for no good reason is when it starts working again at the same provocation.

Comments

Post a Comment

Sorry guys, I've been getting a lot of spam recently, so I've had to turn on comment moderation. I'll do my best to moderate them swiftly after they're submitted,

Popular posts from this blog

PowerShell Sorting by Multiple Columns

PowerShell's Sort-Object cmdlet is super useful, especially when preparing output for human consumption.  A few people have found my blog while looking for more information about its use, specifically while looking for how to sort by multiple columns (well, properties, technically).  I've never done so (much less written about it), so I hope those folks found answers elsewhere.  But, it got me curious... and it turns out that it's really easy. The Technet article on Sort-Object has the answer directly spelled out: just use commas to create a list of properties to sort by (in order to precedence).  Let's look at some examples!  First, prepare a variable with some good sortable data: $myData = get-eventlog System -newest 25 And then we can get to sorting!  Say you want to sort primarily by EntryType (Warning, Information, Error) and then by Source.  Easy-peasy: $myData | sort EntryType,Source How about if you want it to be in descending order?  Yeah, there&
Read more

Clone a Standard vSwitch from one ESXi Host to Another

One of my customers is standardizing the configurations on their HP C7000 enclosures (they've been set up at various sites by various administrators with varying involvement from the architecture team).  As such, we need to stand up some temporary resources so that we can take down the main enclosure for reconfiguration.  That's fine, we can easily ship a smaller enclosure to each site for temporary compute resources.  Some of the sites are using Standard vSwitches, so we need to be able to quickly copy the networking configuration over from their existing blades to these new, slightly different blades.  As I see it, we had 2 good options: 1) Capture a Host Profile with the desired vSwitch configuration.  Delete every other component of the Host Profile so that only the networking section is applied; design the new ESXi hosts so that the vSwitches'll work with the old vmnic-to-vswitch configurations. 2) Write a script to clone the vSwitch from ones ESXi host to another.
Read more

Deleting Orphaned (AKA Zombie) VMDK Files

A problem that most Virtualization Administrators need to deal with is Orphaned VMDK files (or Zombie VMDK files, as some people call them).  These are Virtual Machine hard drive files that are just hanging out, taking up storage, but are attached to no VMs.  How can this happen?  Well, the most common way is when an administrator needs to delete a VMDK but isn't quite ready to commit... so, after pressing "remove", they select "remove from virtual machine" rather than "remove and delete files".  The intent is always good: "I want to be able to restore this if it turns out to be necessary... so I'll just come back and delete it next week if nothing breaks!"  But, of course, next week something else happens and the file doesn't get deleted.  After a little while, it turns into "which files did I rename, again?" and nothing seems to happen. So, how do you deal with these orphaned files?  Well, a few years ago I found a scrip
Read more