Troubleshooting problems with respect to AppSense policy can be difficult. There are a lot of different, equally valid approaches, and your problem might be easily resolved if you could just choose the right one. While getting AppSense to work is rarely a cumbersome task, there are a variety of ways that it can break. Here’s a few questions you need to ask if you find that your Environment Manager configuration is not doing what you think it ought to do.
Do you see at least part of your AppSense policy being applied?
Is the problem isolated to specific triggers?
In my experience, using the Session Disconnected/Session Reconnected triggers is unsuccessful in a Citrix environment–be it XenApp, XenDesktop, or VDI-in-a-Box. Try using the Session Locked/Session Unlocked triggers instead–they will accomplish ostensibly the same thing, but I have found them infinitely more reliable. Incidentally, the reverse has been true for VMware View.
Another very common problem with AppSense policy has to do with timing. Your particular AppSense policy might be perfect in terms of logic, but if the AppSense agent moves faster than your machine can handle, you can run into problems. Where possible, you should avoid the Login trigger. The more actions you add here, the longer your login process will be, and in some cases, the less likely your actions will be to succeed. If your end-user is not going to require certain things instantaneously, consider running the actions after the userinit.exe process stops. This is the Windows system process that builds the desktop according to the user’s profile, and the desktop is completely usable before it completes. Actions run after it stops will still take place early, but they will allow for a quicker login time and will take place in the background while the user begins to work.
Is the problem isolated to specific nodes?
It is important to remember that, as you look at nodes in the Environment Manager GUI, anything not nested runs simultaneously. Let’s say you have an action that sets a particular registry value in one node. In another, you have a group of actions that run dependent upon what that value is. You will want to be sure that any nodes with such a condition run after the value is actually set. Instead of running these nodes alongside the former, nest them beneath it. This will instruct AppSense to run the node that sets the registry value first, and only then move on to the nodes that rely on it.
Is the problem with specific actions?
The most common issue here is user rights. AppSense, by default, will run most actions as the currently-logged-in user. If that user does not have rights to perform the actions in the desktop, the actions will likewise fail when AppSense attempts to trigger them. Your resolutions here are manifold–you can use Application Manager to dynamically update user privileges in the desktop; you can simply add the necessary rights for users in the virtual desktop pool itself; or you can run tell AppSense to run these actions as a specific user who does possess those rights. The latter is not recommended by AppSense for security purposes, but I won’t judge you if you go that route anyway.
Is the problem with specific conditions?
One of the things that makes AppSense policy so dynamic is the use of conditions. However, the Stop if Fails tag can be disruptive. This tag tells AppSense that all subsequent condition checks and actions should only be run if the Stop If Fails condition is met. Effectively, if you have multiple conditions that can pass in a single session (For instance, if the PC name contains ABC and if the IP address is in a particular range), checking the Stop if Fails box for any one condition tells AppSense that all conditions need to pass if the node is to be completed. Literally, if any condition fails, AppSense stops doing everything else that might otherwise come after.
That aside, in case this was not obvious, be sure to check whether your actions are able to run in the absence of conditions. This will pretty quickly narrow the scope of the problem if they run afterwards.
Does none of your AppSense policy get applied?
This one’s a bit more tricky, and far less common. The AppSense Bigot has yet another great post about this (though it is slightly dated as of this writing), and it addresses most of the flowchart that stems from the above question. However, if he does not answer your question, I have run into one additional problem that has crippled the entire solution. It single-handedly managed to turn a 100% functional AppSense policy into an utterly broken one. If this sounds like your problem, the good news is that the fix is likely very simple.
I was working at a customer site when we found that, after they installed a particular clinical application, their AppSense policy completely ceased functioning in their pool. Not a single action was run at any trigger, regardless. I am to this day embarrassed about the length of time it took to identify the reason for this, because it turned out to be so simple. As it turns out, AppSense policy itself gets stored on the local machine as a .aemp file in C:\ProgramData\AppSense\Environment Manager. This software, for reasons unknown, modified the permissions of the ProgramData folder, and regular users were no longer allowed to read its contents. This, in turn, resulted in AppSense being unable to read the policy itself, which in turn resulted in a completely unusable AppSense policy. We corrected the permissions error, and voila, everything worked again.
Hopefully that wall of text was sufficient to resolve your problem–or at the very least, I hope it put you on the right track. Let me know if none of the above was effective and I’ll see if I can’t offer any additional answers.