By Thomas Underwood 🕖 Updated on June 17, 2021 at 7:00 pmWhen 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:
- User account into which a user is currently logged in.
- User account into which a user is not logged in at the moment of Task execution.
- Service user account (SYSTEM).
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.
User profile
A Microsoft Windows user profile contains data unique to particular user. Among other things each user profile contains unique set of the items:
- Windows Desktop folder.
- Documents folder.
- A subfolder in Users folder containing user-specific files and settings.
HKEY_CURRENT_USERregistry settings.- Permissions for disks, folders and files.
- Applications installed for the user.
- Application data associated with the user.
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.
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 desktop 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 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).
Example
A Task is executed with credentials (username and password, specified in Task Run As settings) of user John. The Task uses the Start App 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 Server 2003:
- If Mary is logged into the system, the Notepad window will be drawn on Mary's desktop;
- If Mary is not logged into the system, the Notepad window will be drawn on John's desktop. Or Notepad will not be drawn at all if no one is logged into the system.
Since Windows 7 and Windows Server 2008:
- If Mary is logged into the system, the Notepad window will not be drawn on Mary's desktop;
- If Mary is not logged into the system, the Notepad application will be executed in John's account, but its window will not be accessible.
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.
Run As settings
Now, when the concepts of user profile and user desktop are explained, let us see how this applies to Automation Workshop.
Depending on whether a 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:
Run Task as currently logged in user
Running the Task from the account of currently logged in user is only possible if a user is fully logged in. In this case credentials do not need to be explicitly specified since they are already provided by user upon logon. The Task started from the account of currently logged in user also gets access to user desktop and can effectively start applications that require user interaction. Besides, the Task inherits full access to the same resources as the user (like access to network shares, disks, folders, files, etc.). Running the Task as current user is most suitable for environments where only a single user is logged in at a time.
Run Task as Service user · SYSTEM
The Service user does not require any user to be logged in and has extensive privileges for Task execution on local machine. However, the Task run from Service user cannot access network computers, devices, drives, etc. Service user account also does not provide user desktop. Running the Task as Service user (SYSTEM) is recommended only when no interaction with user is expected and no network is involved. The user profile of system user account is that of All users.
Run Task as specified user
No matter which user is currently logged in or if there is such a user at all, the Run Task as specified user option allows using credentials of any user to start the Task. No matter whether the specified user is or is not already logged in, his user profile is accessible for the Task. However, if the user is not logged in, his user desktop environment is not available, and the application's interface will not be shown. Run Task as specified user is a good choice for the following situations:
- The systems where multiple users are simultaneously logged in and it is necessary to clearly indicate which user profile (including disk and network access, graphical environment, etc.) will be used as a context for Task execution;
- When specified user is logged off. To run a Task in particular user profile without the graphical environment.
Run Task as default user
The Run Task as default user option specifies that the Task will be run with privileges of the user set as default in Automation Workshop. It can be any user account with valid credentials. The option itself is similar to Run Task as specified user. If the default user is logged in, the Task can use both his profile and desktop. If not, then only his profile is used. Running the Task as default user is useful in the following situations:
- The default user is used as Default Run As option upon new task creation and user creates multiple Tasks to work within that user account with relevant privileges;
- When multiple Tasks have to change their user account. Changing the default user in Automation Workshop options (Tasks tab) instantly brings changes in all Tasks which are using the default user account.
Do not run the Task
Some Tasks can be successfully performed only when a user is logged in. One example is running an application which shows its window on user desktop and requires interaction with user. Or, perhaps, the timing is right only when a user is logged in. Other Tasks, on the contrary, perform much better or only can be done when there is no user logged into the system. By choosing the Do not run the Task option for either scenario if user is logged in or if user is logged off it is possible to set the Task not to run when inappropriate.
Configure Run As…
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:
- Run Task as currently logged in user.
- Run Task as Service user · SYSTEM.
- Run Task as specified user.
- Run Task as default user.
- Do not run the Task.
If user is logged off scenario contains the following options:
- Run Task as Service user · SYSTEM.
- Run Task as specified user.
- Run Task as default user.
- Do not run the Task.
If the Run Task as specified user option is selected for either logon or 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 or 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 7 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 App 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.
Run differently?
Assistance is here…
If you have any questions, please do not hesitate to contact our support team.