By Thomas Underwood 🕢 Updated on May 21, 2024 at 7:30 pmAutomation Workshop allows you to create automated workflows that can run under different user accounts. The Run As Settings enable your workflows or apps to operate under current, specified, administrator, or SYSTEM accounts.
This no-code automated workflow creation allows you to automate all your boring and mundane computer tasks with precise rules regarding which account the workflow will execute under, whether a user is logged on or not.
Automation Workshop can manage everything from a simple one-user workstation to a server with Microsoft Remote Desktop Services (Terminal Services) accommodating multiple users logged on simultaneously.
Introduction
When designing Tasks, it is crucial to understand how Automation Workshop handles user accounts.
Automation Workshop Service itself runs as a 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 a 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 other 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 the local machine. Therefore, it is important to consider which folders and data are accessible from all user accounts and which ones are only accessible from specific accounts.
User Desktop
Contrary to the user profile, which 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 canvas).
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 Remote Desktop Services (formerly Terminal Services). 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 (before Session 0 Isolation was introduced), the screen output of an application's graphical user interface is shown on the Desktop of the currently logged-in 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 the current user's Desktop (if available).
Example
Let us start with an example before Microsoft fully implemented user separation in Windows. A workflow is executed with the 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 the operating system and the fact whether Mary is logged in or not.
On older Windows versions (prior 2008):
- 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.
Modern Windows (including Windows 11, and Windows Server 2022):
- 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 user interface will not be accessible.
It is evident that running an application requiring user interaction under accounts where users are not fully logged in (only credentials are provided) poses a problem on older Windows operating systems. Conversely, when running programs (or performing Automation Workshop Actions) that do not require user interaction and operate automatically, screen output can be largely inessential, and does not necessitate the user being 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 they are 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 the 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 the user upon logon. The Task started from the account of the currently logged-in user also gets access to the 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 the 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 the local machine. However, the Task that runs as the Service user cannot access network computers, devices, drives, etc. The Service user account also does not provide a user Desktop.
Running the Task as the Service user (SYSTEM) is recommended only when no interaction with the user interface is expected and no shared folders are involved.
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 a specific user is logged off, to run a Task in the 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 the Default Run As option upon new Task creation. It is useful when you need to create multiple Tasks to work within that user account with relevant privileges
- When you need to change user accounts for multiple Tasks. Changing the default user in Automation Workshop Options (Tasks settings) 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 a 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 unsuitable.
Configure Run As…
Each Task allows configuring its own Run As settings. Initially, it is possible to specify 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 settings of Task Properties.
It is possible to execute a Task from two user accounts or not execute it at all, depending on the user's logon and logoff state, which is detected at the moment the Task is about to start, according to the 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 a Username (or Domain\Username) and Password.
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 the Automation Workshop options.
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 the Log Pane and saves into the Service log the Event ID 2041 information message which indicates the name of the currently logged-in user.
When multiple users are logged into the local machine simultaneously, or using Remote Desktop via Terminal Server, the user with the Automation Workshop user interface open is considered to be currently logged in.
On older Windows systems, if a Task requiring the user Desktop or running a GUI application is started from the Service user account (SYSTEM), the Interactive Services Detection window is displayed, indicating that user interaction is required. If no user interaction is actually needed, this Windows notification can be ignored.
On newer Windows systems, if a GUI workflow is initiated under the Service (SYSTEM) account, the actual user interface may appear on the Administrator Desktop.
Conclusion
A user profile can be used regardless of whether the user is fully or partially (specifying user credentials in the Run As settings) 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 shows user interface or starts external applications that require user interaction.
Furthermore, the benefits and limitations of various user account types were listed. Always think about user privileges necessary to successfully carry out the Task (for instance, accessing a network share).
Run differently?
Assistance is here…
If you have any questions, please do not hesitate to contact our support team.