Imprivata – Citrix Receiver Stays Open at User Switch

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.

Policy Settings

  • 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.

Nvidia Drivers

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.

No Nvidia?

  • 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!

Top of Page
Go Back

5 thoughts on “Imprivata – Citrix Receiver Stays Open at User Switch

    1. 3.2 Enterprise. I want to say that it was after that version that Citrix removed the API that Imprivata needs for the virtual desktop automation.

      1. So i must downgrade to this version for automation to work ? I though Citrix and Imprivata were partners…3.2 is like 2 years old ?

        1. Sorry to say, but yes, it is likely you will need to downgrade. I have been told on multiple occasions to use 3.2 by Imprivata, and it is the only version that I have seen consistent success with. If you find otherwise, I’d be interested to hear about it!

  1. Imprivata wasn’t closing wfica32.exe automatically for us either, settings were exactly as they should be. Turns out the Citrix Receiver installation on the kiosk endpoint wasn’t installed as it probably should have been. Uninstalled it, and reinstalled with: CitrixReceiver.exe /includeSSON LOGON_CREDENTIAL_CAPTURE_ENABLE=No and this fixed the issue for us. I think only the /includeSSON was required (probably dont need the rest). We are using Receiver 4.2 Update 1 HF 1 ( Beyond that, a bunch of settings are required to be adjusted in Imprivata… as well as the Citrix Receiver ADM templates. No issues with anything else…. just this 1 piece with wfica32.exe stole an entire day of work for me. Found this post on google (and it’s the only one discussing the issue I could find). So hopefully this helps someone else out there.

Leave a Reply

Your email address will not be published. Required fields are marked *