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

Overview

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 is making and maintaining "infinitely" running user sessions. Still, these are pretty brittle and can be security risks, so a better solution is needed.

The main parts of the solution are:

  • A Windows Service that provides the secure connection to Robocorp Control Room to trigger robot executions.
  • Local RDP connection is used to open the user session (only for the execution duration) so that the robot can interact with the full Windows UI.
  • Executor launched via Task Scheduler when the user logs in so that the robot executor is working with the target user's privileges. Overview

Target goals, requirements and installation instructions are all on this page so check these out.

As we have seen, different enterprises can have quite varied ways of setting up Windows Group Policies, Active Directories, etc., so any feedback on the guides and tools is highly appreciated. Do not hesitate to contact us in the Robocorp Slack or Forum

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.
  • 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.

Azure Active Directory (AAD) -users cannot be used to run Windows services, so the user for the RDP setup needs to be either a local user or from a regular Active Directory.

Despite its name Azure Active Directory has very little in common with the regular Active Directory regarding functionalities, so the naming is quite confusing. Checkout a summary of the differences here.

  • 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\workforce-agent-core-service`
instancePath: C:\Users\JohnDoe\AppData\Local\robocorp\workforce-agent-core-service

# 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. service-password
    • You can now start the service from the General tab to test that everything is OK. service-start

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 credential-manager-01.png
    • Select Windows Credentials and modify the generic credential: TERMSRV/127.0.0.2
      • Password: Password of the user account credential-manager-02.png

  • 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 popup and should run it with the tick in the picture below. rdp-popup If you run this from the target user account, your current RDP connection is kicked out, and you can continue to the next step.

    Optional setting to accept the certificate automatically.

    It is possible to set a group policy to accept the Robocorp Inc certificate thumbprint automatically.

    Edit the group policy from Group Policy Editor (gpedit) by opening with writing gpedit to windows search and pressing enter. The following window should open.

    gpo-editor

    Navigate to: Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Connection Client\Specify SHA1 thumbprint of certificates representing trusted .rdp publishers

    Click to enable the feature and add Robocorp Inc thumbprint to the list: f8bdffe480bb29ce20ad457cc06f618e8adfe91b

    gpo-enable

    Once the Group Policies are edited, run from powershell: gpupdate.

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 multiple-rdp-connections
    • 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.

Updating the service

Update the Workforce Agent running in the service requires three actions, all supported by Robocorp Service Helper tool to the target machine.

If you are logged in as the service user, you can run the robocorp-service-helper status command to check the service status and get the service name. The default name for the service can be seen by running the command: echo Robocorp-WFA-%COMPUTERNAME%-%USERNAME%

If possible, verify from Robocorp Control Room that no automation is running or is about to start. Stopping the service will make the environment offline for the duration of the update. The update itself should only take under a minute as it only downloads the new executable,

  1. Get Robocorp Service Helper tool to the target machine.
  2. Stop the service
    • robocorp-service-helper stop --name <service name>
  3. Update the Workforce Agent Core
    • robocorp-service-helper update --name <service name>
  4. Restart the service
    • robocorp-service-helper start --name <service name>

You should now see the environment in Idle -state in Control Room.

Uninstall

If you need to remove the Workforce Agent RDP setup or you want a clean start, the guide below helps you out

Note: The uninstall sequence cannot at the moment remove the environment from Control Room, so it is good to identify the environment there so you can remove the correct environment once you have uninstalled the services.

  1. Get Robocorp Service Helper tool to the target machine.
  2. If you are logged in as the service user, you can run the robocorp-service-helper status command to check the service status and get the service name. The default name for the service can be seen by running the command: echo Robocorp-WFA-%COMPUTERNAME%-%USERNAME%
  3. To remove the service and related items, first you should stop the service with command:
    • robocorp-service-helper stop --name <service name>
  4. You can remove the service with the command:
    • robocorp-service-helper remove --name <service name> --all

After this, you can check the three places where the service is visible:

  • Windows Services: The service with the given name should no longer be listed.
  • Task Scheduler > Task Scheduler Library Schedule starting with the given service name should no longer be listed.
  • Credential Manager > Windows Credentials > TERMSRV/127.0.0.2: Should no longer be listed.
December 1, 2021