Question on "Desktop disconnected" error and Robots and RDP sessions

Help
1

I know the “Desktop disconnected” error has been asked about before and I sorta understand what is likely contributing to it. Just trying to understanding this a little better.

I’m using the UiPath Public Orchestrator so I’m using a Development Robot.

My questions / comments (edited after posting):

  1. RDP Client and minimizing that same client - I found this: executing-tasks-in-a-minimized-rdp-window in the UiPath Documentatoin. Ok great … I’ve done that and using the standard Windows RDP Client. See how that works out.

  2. Disconnecting the RDP Client while Studio is running a workflow - what about this situation ? I’m not a Windows RDP guru at all. What I think I’ve seen / found is, UiPath seems to “pause”. At some point I think this is what generates the “Desktop has disconnected” error in the Studio logs.

  3. Robots and types of robots - reading this Introduction … I think a Development robot is the same as a unattended robot but it should only be used to connect Studio to Orchestrator. Even though it has the features of Unattended-but-use-to-connect-Studio-to-Orchestrator, does that somewhat imply if your Studio is on a remote system and you use RDP to connect, will it only work within RDP as long as RDP is connected (or minimized with the RegEdit tweak) ?? Is that an accurate statement ?

  4. A Unattended robot is what I would need to to true disconnected robots runs without using RDP at all correct ? So what happens if you use RDP to connect to the Windows account for the Unattended Robot to see what it is doing and then disconnect ? Does my question for #2 come into play here as well ?

2

This is my understanding, so take it with a grain of salt…

If you minimize the RDP, it turns off the GUI so that’s when the activity will timeout. When you disconnect, it interrupts the logon session, and therefore says disconnected. I am not sure there is a workaround for this, other than setting up your robot environment in a way that encourages developers to not interrupt the robot’s execution. - such as disallowing users to login to the robots (not that I support this method), or at the very least understanding that if you do interrupt a robot’s execution to not disconnect the RDP. You can also check Task Manager from another user account to see if a robot is in use (active logon session) before logging into it or look in Orchestrator to see if it is busy.

If you want to monitor the process, then I would suggest that you just not disconnect it while watching it. Also, check out the StreamRobot found in Go. - I have used the Stream Robot and it works pretty cool. Alternatively, you will just need to have good logging and screenshot storage to know how the robot is performing.

It’s simply a robot license but is included with your Studio install to benefit developers. You can use this license on a robot even if Studio is not installed on that server, however keep in mind that this will take away from the license that you would use with your Studio. So, I would suggest keeping this robot with where you are developing from. You can also use “Floating” robots which means that the license will migrate to the active user/server. For example, if you develop on one machine, then decide to develop on another machine, the floating license will change to that other server when you login, just as long as the other machine has no open logon session (you need to log off first).

Technically, you can watch and use the Unattended robot like Attended, but like you said, you still don’t want to interrupt it by making an RDP connection, unless you plan on watching it until it is finished. Like I recommended, you will want to have good logging and screenshot/error handling, so you can identify issues efficiently. Also, if you are interested in the StreamRobot, you can check that out in Go - it basically runs an .exe that streams the server to a port, which you can watch remotely on another machine like your laptop (however, this only works from my understanding on one robot per server at one time, so you couldn’t stream two robots on the same server at the same time… and also, if you program your robot to use this, make sure you are killing the .exe after each run. Note: only use this for testing, because there is a security concern that opens the stream to anyone on the network)

I hope I answered your questions, and like I said, take it with a grain of salt.

Regards.

3

I Have a Similar kind of scenario where a task is run using Attended bot using rdp where the task run time is approximately 20hrs.My rdp disconnects every 3hrs.How can I resolve this?

Thanks in Advance

4

Hi @sreekanth
I suggest you work with your IT Server Administrators on configuring your remote server to increase the time limit or disable it and thus to better integrate with automated tasks.

Here’s potentially more info on that:

1 Like