UiPath Robot machine RDP access

Help
1

We plan to install UiPath with Orchestrator module and 5 back office bots. All these components (1+5) will be installed in different servers (total of 6). One AD service account will be used to run the orchestrator and the bots in the individual machines. According to the bot installation guide -
Installing the Robot, we need to add the bot running user account to Remote Desktop Users group in the bot machines and also we need to enable RDP access but our organisation policy restricts RDP usage.So, Is this really required? Do we need to enable RDP access in all the bot machines? Is it required even if we use Orchestrator for scheduling, triggering the workflows? What is the purpose of it? Any info regarding this is appreciated!!

2

Yes, you need to enable RDP access.
Scheduling in orchestrator will only make a robot(s) to execute a job at a specified time.

3

Thanks but would be great if someone can explain the purpose of RDP access.

4

Hi @sudhakarg

No. That is only for HD Robots (as it says in the guide). But you said that the Robots will be in individual machines so it doesn’t seem to be the case for you.

So, I will try to explain based on my knowledge so far. When you install the Robot on a machine, the LoginToConsole parameter is set to “true” by default. So when you run the Robot from Orchestrator, it will login using the console (the one you as a human use to manually login). But the Robot has also another way to communicate/login - Remote Desktop Protocol (RDP). In this case you will set LoginToConsole to “false” and also you need to Allow log on through Remote Desktop Services for the Robot to be able to run the process.

Am I making sense? I will research this anyways :slight_smile:

2 Likes
5

Thank you Ovi for the quick response. That was useful.

But I think there are 2 different scenarios when it comes to the nature of the bot machine’s platform (windows workstation, windows server).
For workstation - can we conclude that when we setup LoginToConsole=“true”, we don’t need to add the executing user account to “Remote Desktop Users” group. This may be possible because, only one user can access the machine at a given time and when the second user logs in the existing session (if any) is taken by the latest user.
But how does it work for a server (not HD setup but still individual windows 2008/12 server having a bot)? Here, multiple users (usually 2 or 3) can login. So, accessing the console is not possible without a new RDP session. Perhaps the guide documentation requires some update in this regard.

6

Hi,

For Scenario 2,
i.e LoginToConsole as false, Robot accessing machine thru RDP we encounter issue with timeout,
(Question here: If UnAttended Bot is running setting LoginToConsole as false, why do we encounter timeout issue)

However this is not case for Scenario 1,
setting LoginToConsole as True runs process smoothly and without timeout

Appreciate if you could elaborate.

7

@roma.sodha

It could be a robot version issue. One of the old versions have timeout problem.

8

Hello,

You could increase the RDP timeout (default is 30 seconds). See: Config RDP timeout to create user session

But there could be other causes. Without any details about the error that you receive, the version of the robots that you use, what windows version, etc is hard to help you.

Thanks,
Cosmin

2 Likes
9

Hi @roma.sodha,

There are some reasons why an RDP connection can fail, here are a few, most RDP service config or RDP licensing related:

  • Using a non Windows Server OS (this has a limit of RDP sessions of 1)
  • Not having sufficient licenses in Windows Server
  • As Cosmin said, we timeout the RDP session at 30 seconds by default, but there are cases when that is much slower due to various reasons (slow loading policies, scripts, lack of resources etc.). That can be increased
  • You are using “a double login” - IE the policy Always prompt for password is checked and autologin is disabled (you can quickly see this by simply trying to run an RDP session and feeding the password in mstsc. If you’re asked for the password again in the RDP window)
  • You’re using CredSSP protocol versions 4, 5 and 6 supported starting with 18.4.
    This can be resolved for lower builds by setting the Policy: Encryption Oracle Remediation under Computer Configuration > Administrative Templates > System > Credentials Delegation to mitigated

I would recommend raising a ticket with the error and what steps and configuration you’re using so we can see some logs.

Regards,
Constantin

4 Likes
10

Tried doing so, still facing same issue.