When designing Tasks, it is crucial to understand how Automation Workshop handles user accounts.
Introduction. Automation Workshop service itself runs as service user (
NT AUTHORITY\SYSTEM local service account, or
SYSTEM in short). However, the Tasks can be executed in the following user accounts:
Each option provides some benefits, while also posing particular limitations. The goal of this article is to explain how to use Automation Workshop in multi-user contexts of Microsoft Windows. Each Task has individual Run As settings that allow specifying its proper execution environment.
Understanding user profile. A Microsoft Windows user profile contains data unique to particular user. Among other things each user profile contains unique set of the following items:
These folders, settings and applications are inaccessible from another user accounts and, in specific cases, even from the Administrator account. When roaming user profiles are used in a Windows Server domain (Active directory), the user data might even not be present on local machine. That is why you should keep in mind which folders and data are accessible from all user accounts and which ones only from particular accounts.
Understanding user desktop. In contrary to the user profile that is fully accessible when executing a Task with proper credentials provided, the user desktop is only loaded when a user actually logs into the system. User desktop should not be confused with Desktop folder (the latter is merely displayed in the former as the default surface). Among other things the user desktop serves as the graphical environment in which the application graphical user interfaces (GUIs) are drawn. If the user whose credentials are used to start a program is not logged into the system, his desktop is not prepared and hence the program's screen output will not be shown anywhere.
Microsoft Windows allows multiple users to be logged in simultaneously, e.g. as when using Terminal Server. The Fast User Switching feature makes it possible to quickly switch between logged in users without logging off the system (and hence closing all applications and, importantly, shutting down their desktops / graphical environments). On the other hand, using user's credentials to run a Task is not equivalent to the user being fully logged into the system. The main difference lies in the accessibility of the graphical environment.
Note that on older systems such as Microsoft Windows XP and Microsoft Windows Server 2003 (before Session 0 Isolation was introduced), the screen output of application's graphical user interface is shown to the desktop of currently logged user if the specified user is not logged in or the application is run as service user (SYSTEM). In other words, the screen output for users who are not fully logged in (yet whose credentials are used to run a program) is redirected to current user's desktop (if available).
Consider the following example. A Task is executed with credentials (username and password, specified in Task Run As settings) of user John. The Task uses the Start Program / Application Action to start the Notepad application. When Task starts, Mary's Desktop may be open and Notepad may appear on Mary's Desktop, even if it was started without Mary's credentials. When the Task is executed, the results depend both on operating system and the fact whether Mary is logged in or not.
On Windows XP and Windows Server 2003:
On Windows Vista, Windows 7 and Windows Server 2008, 2012 and 2016:
It is evident that running an application that requires user interaction in accounts of users that are not fully logged in (only credentials are provided) poses a problem on older Windows operating systems. When running programs (or performing Automation Workshop actions) that, on the other hand, do not require user interaction and do their work automatically, screen output can be rather inessential and, even if existent, does not require the user to be logged in.
Understanding Run As settings in Automation Workshop. Now, when the concepts of user profile and user desktop are explained, let us see how this applies to Automation Workshop. Depending on whether an user is logged into the system at the moment when a Task is started, Automation Workshop can execute the Task using different user accounts. Each Task differentiates between the situations when a user is logged into the system and when is not. Accordingly, Automation Workshop supports multiple options for running Tasks in multi-user contexts:
Configuring Run As settings in Automation Workshop. Each Task allows configuring its own Run As settings. Initially user specifies the settings in the Task Wizard (the Run As step, just after configuring Triggers and Actions). After the Task has been created, the Run As settings are available in the Run As tab of Task properties.
The Task is executed from two (possibly different) user accounts or not executed at all according to the user logon / logoff state which is detected at the moment the Task is about to be started and respective Run As settings.
If user is logged in scenario contains the following options:
If user is logged off scenario contains the following options:
If the Run Task as specified user option is selected for either logon / logoff state, it is necessary to specify Username or Domain\Username and Password. First, enter username (with or without domain name, as necessary). Click Password button. The entered username should appear in the box. Enter password twice. If credentials are valid, the info message will appear in the Set Password window. Likewise, it will be reported if entered passwords do not match or the login has failed. This allows to verify in advance whether the Task will be able to use necessary credentials when it is automatically started at a later time.
If the Run Task as default user option is selected for Task execution in either logon / logoff state, make sure that the default user is properly set. Default user settings are located in the Tasks tab of Automation Workshop options. The Tasks tab is also accessible by following the link in the Run As tab of Task properties (if Run task as default user option is selected). Enter default username, click the Password button and ensure that valid credentials are provided. You can also choose this default user to be used for all new Tasks by enabling the Default Run As option upon new task creation checkbox.
Additional notes. While handling user logons and logoffs, Automation Workshop both shows in Log pane and saves into service log the Event ID 2041 information message which indicates the name of currently logged in user. When multiple users are logged in the local machine simultaneously, the one with opened desktop (physical display) is considered to be currently logged in. In server scenario, such as Terminal Services, when multiple active users are connected through Remote Desktop connections and the Administrator is meanwhile using the physical console, it is not guaranteed that the status of current user is assigned to the Administrator (or any other particular user for that matter).
Starting from Windows Vista and Windows Server 2008, if a Task requiring user desktop or running GUI application is started from service user account (SYSTEM), the Interactive Services Detection window is shown which offers to show the message that user interaction is required. If no user interaction is actually required, this Windows notification can as well be ignored.
Conclusion. The article has explained user profile which can be used regardless of whether user is fully (proper login) or partially (specifying user credentials) logged in. At the same time, the user desktop or graphical environment is accessible only if the user is fully logged in. The difference of fully and partially logged users therefore lies in the Tasks they can run. While fully logged in users can use both user privileges and graphical screen output, the partially logged in users are limited to the former. It is crucial to remember this difference when designing Tasks which start external applications that require user interaction. Special attention should be paid to the use of the Start Program / Application Action.
Furthermore, the benefits and limitations of various user account types were listed. Some types do not have access to network while some other might be limited in some other ways. Always think about user privileges necessary to successfully carry out the Task.
Finally, the practicalities of configuring user account handling, specification of credentials and other parameters in Automation Workshop were briefly listed. The online help option is always at hand when designing and configuring Tasks in Automation Workshop.
If you have any questions, please do not hesitate to contact our support team.