Automate Event Monitor & Remote Desktop

Introduction

This document describes how the Automate Event Monitor (and the Automate Enterprise Agent Event Monitor) functions in a remote desktop (RDP, formerly known as "Terminal Services") environment, and the limitations such an environment imposes on Automate's functionality versus a standalone client. (

NOTE: This document refers to Automate nomenclature and assumes the Event Monitor is AMEM.exe and the Task Service is AMTS.exe; the same rules apply to Automate Enterprise but substitute BPAEM.exe and AMTS.exe for the Event Monitor and Task Service processes respectively.

What is a Session?

Paramount to understanding how the Event Monitor and Task Service interact with Remote Desktop Services (as of Server 2008 Microsoft has combined and renamed “Terminal Services” and “Remote Desktop” into “Remote Desktop Services” ). According to MSDN:“…(each) session is associated with an interactive window station. The only supported window station name for an interactive window station is ‘WinSta0’; therefore, each session is associated with its own ‘WinSta0’ window station. There are three standard desktops for each window station: the Winlogon desktop, the screen-saver desktop, and the interactive desktop.”

When Windows starts up, two sessions are immediately created: session 0 for services, and session 1 for the “console” (the user at the physical keyboard ). The existence of a session does not necessarily imply that a user is logged on; indeed, session 1, with its logon screen visible, is what is displayed at the console at startup. However, in order for Windows to consider a session to be “Active”, there must be a user logged onto it. When a user connects to the system by way of Remote Desktop, a new session is created. This session is then connected to the display of the Remote Desktop. Depending on the operating system and it’s settings, this may cause the other active session (if it’s present) to lock itself while the other user interacts with her/her session, or to it could allow the user to logon with a completely new session unrelated any other session active at that time. In other words, it’s possible for a Windows system (in this case a server system) to have any number of active sessions, using the same or different users logged onto them.

It is important to note that Windows systems have Remote Desktop Services active and in play. In fact, the Remote Desktop limitations seen in some versions of Windows are actually licensing restrictions on Remote Desktop Services that prevent more than a set number of sessions from being created at any given time. The implication of this being that the Automate Task Service takes Remote Desktop Services into account regardless of what the operating system is, as the logic to determine where and how a task or the Event Monitor is to run is the same.

Role of the Event Monitor

While the Event Monitor (AMEM in Automate and BPAEM in Automate Enterprise/Agent) has several roles in the Automate system, its primary purpose is to provide a gateway to the desktop of a logged on user in order to carry out functions that can only be done in the session space of a logged on user. Triggers that require an interactive session (currently the Window, Hotkey and Idle triggers) use the Event Monitor to watch for their respective triggering events. The presence of the Event Monitor on a session is used by Automate to determine on whether or not a workstation is logged on or locked.

Event Monitor Startup

The Automate Task Service is responsible for starting the Automate Event Monitor on a user's session. Depending on the Event Monitor Startup setting, this could be the first active session, the console, or the first session found with a specified user. The diagram below outlines the control flow that the Task Service uses to determine what session to start the Event Monitor in. Note that there can only be one Event Monitor process running on a system, therefore, if the Event Monitor is already running in a session, it will not start in another session regardless of the Event Monitor startup setting.

If the Automate Event Monitor starts, the following steps are performed:

  • Hot-key and window triggers are registered for the user session on which the Event Monitor is running

  • The session ID of the Event Monitor is transmitted to the Task Service, allowing tasks to run on the correct session

  • The username of the user who started the Event Monitor is transmitted to the Task Service. If no TerminalServicesUser exists, this username becomes the only user that can start subsequently start the Event Monitor until that registry key value is removed or reset.

Task Service Responsibilities

With Automate, it is the Task Service's responsibility to monitor and regulate the execution of the Automate Event Monitor. Users should not have to start the Event Monitor manually or by way of the Microsoft Run key (regardless of whether). The Automate Task Service, on a regular interval, executes the control flow outlined in the image above to determine if any active sessions are present and, if so, which active session (if any) the Event Monitor should be started in.  

Task Administrator

In an RDP environment, the Task Administrator will:

  • Attempt to connect, as always, to the Task Service on localhost (if there is a Task Service present, otherwise it will prompt for a hostname to connect to).
  • Does not provide a warning if it determines it is being run on a remote desktop session (as opposed to pre-Automate 10.1. versions which did).
  • Administered as normal, but tasks run manually or by trigger will only run on the session where the Event Monitor is running (if no event monitor is found to be running, the workstation is considered to be “logged off”).

Limitations & Caveats

In an RDP environment the following limitations exist for Automate:

  • Interactive tasks will run only on the session on which the Event Monitor is running.

  • Because only one Event Monitor process will run on the system at a time, only one user session can run interactive tasks at any given time.

  • If a user logs out of a session that is running the Event Monitor but is still logged into another session, and the Event Monitor Startup type is set to “First Come, First Served”, the Event Monitor will "jump" to that session once the Task Services notices that the Event Monitor is no longer running.

  • There is currently no way to choose or force the Event Monitor to a specific session other than the console.

RDP & Non-server Operating Systems

Some versions of Windows technically offer Remote Desktop Services while not identifying themselves to Automate as "remote desktop servers" or "terminal services servers" as Windows Server 2008 does. The functionality of Automate, however, is basically the same for all systems. The only difference is there can only be one active session at a time in these OSes, and thus most of the logic used to determine the correct session on which to run is superfluous. Because RDP sessions for each logged on user is limited to one, and that remote session becomes a view of the original session (as opposed to a new session in its own right as is possible in Server), the Event Monitor will work correctly in RDP sessions of these OSes.  

Automate gives the user more control over how and in what session the Event Monitor starts. A new preferences setting, “Event Monitor Startup Type”, provides greater control over the Event Monitor startup process by adding the following options:

  • First Come, First Served - The Event Monitor will start on the first active session found (as provided by the operating system) if the Event Monitor is not already running on another session.

  • Console Only - The Event Monitor will only start on the console session. This essentially locks the Event Monitor out of Remote Desktop sessions Windows Server machines.

  • Specified User Only - The Event Monitor will start on the first active session found that is owned by  the specified user. This username is provided in the settings.