AppSense Environment Manager issues

I recently completed an AppSense implementation for a XenApp 6 farm running on VMware vSphere.  XenApp 6 servers that were running Microsoft Windows 2008 R2 which were being provisioned via Citrix provisioning servers.  The profile management strategy we chose for this was AppSense’s Environment Manager sitting on top of a mandatory profile solution.  The mandatory profile would be the vehicle for us to populate the initial settings while AppSense would capture user settings and lay them back in as needed.

Throughout the engagement we hit the normal bumps in the road expected during a complex software implementation but I did hit 2 particular AppSense specific issues that I think deserve a quick write up.  I couldn’t really find any information on the web related to these so I figured I would pop it up on the blog.  Unfortunately, their KB was also not very helpful.  Support was great and without them, I might still be searching for solutions.

The first involves a bug where the AppSense agent puts the Mandatory Profile into a Roaming state during login but then *OCCASIONALLY* fails to flip it back which causes it to overwrite the mandatory profile.  Since the windows servers mistakenly thinks that the profile is roaming, it tries to write it back to the ‘source’ which is the main mandatory profile.  Normal users would only have read writes to the directory but when an admin logged in, it would write back and update the system.  This would screw up profile permissions and litter it with user keys that we did not want in a shared profile.  When the next user logged in, all sorts of weird application issues would crop up due to the ‘busted’ mandatory profile.  Since the box was a provisioned server, everything would sort of straighten itself out after a reboot which made diagnosis even more sketchy.  Once we determined the problem, the workaround we came up with was to remove ALL MODIFY writes to the mandatory profile directory from everyone except one account and that one user account is explicitly denied access to the AppSense User Personalization features  which prevents it from doing it’s voodoo.  Clearly, an ACTUAL fix from AppSense would be appreciated but for now this workaround serves it’s purpose.

The second one was just a weird fluke.  During some routine User Personalization modifications, an entry for HKUMandySoftwareMicrosoft… found its way into an exclusion list in the console.  Mandy is typically the key name we use when loading up the mandatory profile and making modifications to it.  Once this errant value found it’s way onto the system, the AppSense AGENTS on all end points (XenApp Servers) began crashing in each session as users logged in.  During login, the entire configuration is sent down to the agent which then parses it for relevant data.  I can only assume that it was only expecting HKCU or HKLM type data so the HKU completely freaked it out and burst it into flames.  Eventually, the value was found and a simple change back to HKCU fixed the issue.  During the time with the error though, AppSense was rendered useless and all user personalization settings were trapped in the DB. L

That’s the short and long of it.  Google, Bing and Yahoo; come index this and help someone out of a jam.