If you have installed the AppSense Environment Manager (EM) Agent on your client you will find in the local Group Policy the following Log Off script:

The script contains the following:

@echo off
ECHO Running EmExit script
“C:\Program Files\AppSense\Environment Manager\Agent\EmExit.exe” %1

Normally there is no issue but occasionally if a script/action is misbehaving this process (EmExit.exe) will hold up the log off process. If you are running AppSense EM on a RDS (Remote Desktop Services) environment you will notice multiple EmExit.exe’s holding up sessions from ending.

What is EMExit?

“EmExit.bat is a script which AppSense implemented in Environment Manager 8.1 – 8.4 to try and get around a Microsoft timing issue. Microsoft only allow vendors a minimal time window to respond to a request to determine how much time they need to perform all logoff / shutdown actions. Vendors that do not respond within that time limit usually end up in the black window that you’ll most likely have seen allowing users to kill the application. Group policy is one of a few exceptions to the standard rule which is why we adopted that method.

When a user / administrator (or the system) initiates a shutdown EmExit.bat will run for all users. This launches an EMUserLogoff for every user who is logged on and will synchronise all personalised applications that are pending a sync to the database. This will include Desktop Settings, Session Data, Certificates and any applications that were open when shutdown was initiated.”

So what happens when EmExit is holding the log off/shut down process?

This is usually because you have an action/process in your policy causing the log off/shut down process to be delayed.
This doesn’t necessarily have to be in a Log off or Shutdown node, the action could be called from any part of the policy and the AppSense EM Agent will wait for it to end before proceeding.

In order to avoid this situation there are a few things you can do:

  1. Add time-outs for your scripts/actions where possible
  2. Ensure scripts have proper exit codes
    The majority of the time a badly behaved script is likely the cause, troubleshooting these require you to know if they have completed successfully or not.
  3. Prompt a user if an action is going to take some time for awareness.
    A user is less likely to log out if they know the client is processing something.
  4. Use actions that can be pause/resumed where possible.
    For example RoboCopy is able to resume a folder sync even if it is interrupted so you could take steps to force this action to stop.

Future Versions

Environment Manager 8.5 onwards has an overhauled process regarding log off and shut down actions  however the above best practices are likely to stay valid.