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

Popular posts from this blog

Clone a Standard vSwitch from one ESXi Host to Another

PowerShell Sorting by Multiple Columns

Deleting Orphaned (AKA Zombie) VMDK Files