Hypothetically, setting up your policies properly is enough to allow for User A to login to a desktop, get his Citrix virtual desktop, and then lock the machine confident that his session is secure and inaccessible to User B who logs in next. Unfortunately, as of this writing (and version 4.8, hotfix 1), that’s not always the case.
If you find that, unlike the ideal situation above, you notice that Citrix Receiver stays open during the switch and User B is able to see User A’s session after the fact (Followed shortly by a second Receiver session opening over top of the first), there are a few things to consider. First, take a look at your policy.
- On the Virtual Desktop tab of your endpoint’s computer policy, ensure you have selected “Automate access to Citrix XenDesktop or XenApp, and that you have chosen to shutdown the client and disconnect the user session.
- On the Override User Policy tab of the same policy, tick the box for Challenges, set whatever hotkey you’d like, and set the policy to “Log Off User and Terminate Session.” This will ensure unequivocally that the desired behavior on this endpoint is to leave no session open if it is not being actively used. N.B. It will also (at least make an attempt to) close Receiver whenever the machine is locked, either actively by a user or passively due to idle activity.
- Ensure you have chosen to automate virtual desktop access on the respective tab in your user policy as well.
If you’ve installed Nvidia drivers on your endpoint in the past, it is possible that you may need to start your image from scratch (or at least from a revision prior to the drivers’ installation). I have found at two different customer sites that the installation of these drivers was enough to go from a world where everything works to a world where Receiver stays open every single time. At this time, I am not certain of what specific change is made that causes Imprivata such trouble, but we do know that simply uninstalling the drivers does not revert the system to a state where Imprivata will work again. I was at a customer site where, thankfully, reverting back to an older endpoint image that preceded the installation of the Nvidia drivers was an option, and it resolved this problem for them. Sure enough, as soon as we installed the drivers again, the problems with Imprivata reappeared and we could find no way of reversing it. I wish I had better news, but this is the first thing to consider when facing this problem.
If this is absolutely not an option for you, there is a quick and [very] dirty workaround. Simply create an Imprivata EXO that kills the Receiver process at desktop lock. It looks something like this:
taskkill /F /im wfica32.exe
and it will absolutely make this work. I know of at least one enterprise using this method and it is effective, and although I am not aware of any stability issues arising therefrom, I can’t say I recommend this.
A second alternative is to take advantage of Receiver’s built-in Shift+F3 disconnect hotkey. You will need a script that sends the hotkey, then accepts the prompt that follows (one which cannot, as far as I am aware, be suppressed or bypassed). As per above, set this script to run at Machine Lock and you will be all set. Note that you may want to turn off system sounds if you are not interested in hearing a *ding* every time a user disconnects his or her session.
- If you are using Win7 on your endpoint, be sure to disable UAC if you haven’t yet.
- Symantec has been known to interfere with Imprivata’s ability to control processes. If it is not essential on your endpoint, I encourage you to remove it, as this will likely resolve your issue. If that is not an option, ensure that you whitelist both the SSOManHost and ISXAgent processes so that they are able to operate freely.
Hopefully at least one of the above was a viable solution for you. If not, please let me know in the comments (include any possibly relevant information about your environment!) and I’ll see if anything else comes to mind. Good luck!