Windows Remote Desktop (RDP) wake-up for Workforce executions

Why

Running automation that requires interaction with Windows desktop requires an active user session to Windows.

For example, running Workforce Agent as a service can perform so-called "headless" operations. Still, it cannot interact with UI applications.

The standard solution to the problem is making and maintaining "infinitely" running user sessions. Still, these are pretty brittle and can be security risks, so a better solution is needed.

Goals

Enable full desktop access for the robot execution on the target machine that does not have a user logged in.
Assign work to the machine from Robocorp Control Room just like any other Workforce environment.
Make Windows Remote Desktop access as limited as possible and fully controllable by the end-user or IT managing it.
- RDP access from external networks is NOT required, only from localhost.
Solution works after the target machine reboots.
Make the setup as secure and straightforward as possible.
- Communication between the service and Cloud is encrypted.
Enable running multiple setups on one Windows Machine using different user accounts.

Requirements

Administrator permissions for the setup phase on the target machine.
- Executing user accounts do not need to be admins unless the specific robot execution demands that.
Add or select the user on the target machine you want this setup to use.
- You can use this user to limit access to the machine the way you want.
- User can be a local user or from AD; you need to know the user's domain.
- You need to know the password of this user.
Windows Remote Desktop enabled on the target machine.
- The RDP session is only opened inside the target machine (localhost) and does not need to be open to external connections.
- The connections are made from TERMSRV/127.0.0.2
The target machine cannot have Windows Interactive Logon messages enabled.
- These usually come in the form of legal notices and cannot be bypassed by automation as they are designed to require human input.
- Disabling these has to be done with the permission of the IT controlling the target machine as these are usually set up for a reason.
The RDP connection must allow the use of stored passwords.
- There are a bunch of settings and ways in Windows to demand the password input via prompt.
- The solution requires the RDP connection coming from TERMSRV/127.0.0.2 to use a password from Windows Credential Manager; more details are in the guide below.
The solution uses the following techniques:
- Windows Service to maintain the secure connection to Robocorp Control Room.
- RDP connection inside localhost to open the user session.
- Windows Task Scheduler to launch the Workforce Agent in the opened user session to execute the robot.

Installation

1. Setup using the helper tool

Get Robocorp Service Helper tool to the target machine. Fill in and run the helper command:

There are three ways of running the helper tool:

Interactive -mode: The service-helper will interactively ask for the needed information.
Command-line arguments: Full control for CI/IT users
Using a config file: Full control for CI/IT users in file form

Note for Active Directory (AD) cases:
It is best to use the command-line or config file mode as you need to check the user domain value especially.
We have seen that the %USERDOMAIN% is not always set correctly.
You can run command whoami in Command Prompt to check the correct value to the domain

Interactive -mode

Interactive mode assumes it is executed with the same account where the service will run.
The service-helper will automatically find username and domain that matches Windows variables %USERDOMAIN% and %USERNAME% and uses these to generate unique service names.

robocorp-service-helper.exe setup-login-service

Command-line arguments

To run from the CI system, use flag: --ci to ensure the tool is running in non-interactive mode.

Run:

robocorp-service-helper.exe setup-login-service --help

...to get details on the arguments

Config file:

Define the arguments in a YAML file and run robocorp-service-helper.exe setup-login-service -c config.yaml

# --- Arguments are optional, comment to use defaults. ---

# Environment name shown in Robocorp Control Room and name of the service on the machine
# Defaults to `echo Robocorp-WFA-%COMPUTERNAME%-%USERNAME%`
resourceName: Robocorp-WFA-MACHINE_ABC-JohnDoe

# User domain: Defaults to `echo %USERDOMAIN%`.
# For Active Directory (AD) use command `whoami` to check the correct domain value.
domain: MACHINE-ABC

# Username: Defaults to `echo %USERNAME%`
username: JohnDoe

# Full path to location where run content is stored
# Defaults to `echo %LOCALAPPDATA%\robocorp`
instancePath: C:\Users\JohnDoe\AppData\Local\robocorp

# Full path to the location where environment caching is done (no spaces or special characters in this path)
# Defaults to `echo %LOCALAPPDATA%\robocorp`
robocorpHome: C:\Users\JohnDoe\AppData\Local\robocorp

# Link token from Robocorp Control Room
linkToken: <link token>

2. Activate service and RDP

The helper tool sets up the services and RDP items, but the setup and optionally setting the password are separate steps at the moment.

To activate following steps are needed:

Set the password for the service and start the service.
Set the password for the Windows credential manager and test the RDP setup.

2.1. Set the password for the service and start the service

Open Windows Services > Find & open Robocorp Workforce Agent properties > Log on
- The username is set, but you need to input the user password here and Apply changes.
- You can now start the service from the General tab to test that everything is OK.

2.2. Set the password for the local RDP and test

Setup the RDP user and password to Windows Credential Manager:
- Open Credential Manager by typing credential manager in the Start via
- Select Windows Credentials and modify the generic credential: TERMSRV/127.0.0.2
  - Password: Password of the user account
You need to test the connection once by running: %localappdata%\robocorp\workforce-agent-core-service\local.rdp - On the first run the connection you will see the following popups and should run them with the ticks in the pictures below. If you run this from the target user account, your current RDP connection is kicked out, and you can continue to the next step.

3. Assign work in Control Room

You can now configure steps under Workforce Process to point to the new environment and choose whether or not to Use RDP Connection:

rdp-setup-cloud

You can use a simple robot that takes a screenshot from the target machine to test the whole setup. Example:

*** Settings ***
Library  RPA.FileSystem
Library  RPA.Desktop

*** Tasks ***
Minimal task
    Create Directory    %{ROBOT_ARTIFACTS}
    Take Screenshot    %{ROBOT_ARTIFACTS}${/}screenshot.png

Multiple RDP executors on one machine

Running multiple RDP setups on one machine reduces the cost of setup and maintenance of Windows machines. You can achieve this with the solution described here.

Setup

Create separate user accounts on the machine or via AD.
Set the amount of allowed RDP connections on the machine:
- Windows Group Policy editor: Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Connections ..the default is 1 if not set
- Run the installation steps for each account.
- You should now see the environment in your Robocorp Control Room under Environments
  - You can use the Environment Groups -feature to collect these together.

Limitations

User account per service

Do not use the multiple sessions per user feature; this solution does not support it. It pretty much ensures resource collisions as all robots would be accessing the same files and resources under the user account.

You need to set up a separate user account per service.

Running multiple robots on a single Windows machine can cause resource collisions

Execution in the multiple RDP case can run the robot concurrently. For example, multiple robots can easily create file locking and race-conditions by accessing a common file outside the users' folder (e.g. C:\temp\test.txt).

Robots need to be mindful of their resources on the machine and the boundary between user-specific and machine-wide items.

August 20, 2021

Webinar