Allow Unattended Bots to Run without Active RDP Sessions

This feature is to remove the requirement for unattended Bots launched in the Orchestrator to not have to have an Active RDP session open. The ask is for any unattended bot launched from the Electroneek SaSS Orchistrator would be able to create its own session so it has UI control to run.
See the related articles in this url and its associated related links.
Problems when working with a minimized RDP window – ElectroNeek Help Center

Reasons for this Enhancement
Having to maintain an open, unlocked and active RDP session From MachineB to MachineA has the following drawbacks that all customers have to deal with.

  • Extra Windows configurations on the machines
  • Having to install additional machines in the infrastructure to maintain and patch
  • training all the staff to know not to lock the RDP session or to activate it if it closed for any reason. Patching, accidently closed, etc
  • We install Bot Runners in multiple client sites so we have to ask for AD policy exceptions for RDP and/or user screen lock policies.
  • Bots will fail without notice and get into bad states if the RDP session is closed or locked. This takes a lot of effort to effectively monitor and creates tickets that need immediate action to reestablish open RDP sessions.
  • Locked / broken RDP session is our #1 reason by far for Bot Failures

There are also Security concerns of keeping active session on ComputerB to ComputerA at all times.

  • Special care would need to be taken to keep the PW for the robot user secure if automation would open the session on reboot for example
  • if users log / hack into ComputerA then they get full access to ComputerB
  • RDP is a common surface area for attack and keeping it active 24x7 should be avoided.
1 Like

Hello @benoates,
Thank you so much for your suggestion. We appreciate the feedback and will look into this request. If there are changes made regarding this functionality, I will be sure to update you.

Hello @benoates !

We had some similar problems a while ago, here are some solutions that worked out for us.


-Schedule a connection just before you need to run an automation on computer B. This can be done by making an automation and scheduling it to run on orchestrator or by using the task scheduler on windows to open a .rdp file.

-At the end of the workflow running on computer B add a “Command Prompt” activity to run the “logoff” command. Besides logging off Computer B, this will also close the connection between computers, avoiding it to stay up longer than necessary.


-You can set up a small ubuntu machine and use a program called FreeRDP to create a new RDP session on Computer B, you don’t even need to have any gui installed on the machine.

-You can also schedule this to run just before the automation on Computer B by using Crontab(similar to the windows task scheduler) to schedule the connection.

Thank you for taking the time to comment, @Joao.Melo. It is always lovely to hear from our active users! Have a nice weekend!

1 Like

Those are some great tips and can help mitigate the issue to some extent. Ultimately, I’d really love for there to be no preconditions for running the bots.

I’ll take your considerations for the future.

1 Like

@benoates Thank you once more, and we very much look forward to working with you again for the benefit of our community and beyond!