A specified logon session does not exist

We have the lastest 2018.4 version of the orchestrator, but we always get the same error.
Do you know why ?

Hi Nicolas,

Do you get this error on only one machine? With different processes?
Have you checked this post: Usual Orchestrator errors (FAQ) - Troubleshooting

for all servers, on all processes.
But it seems we add to installed also the last UiPath version on robot side…
We will try this

What is the Robot version?

How to download the last 2017.1 version ?

Only by request: Contact Technical Support

Quick workaround is giving Admin to the provisioned ID on robot machine.

You wonderful man you

IS it sorted out, I am facing the same issues.

@hacky are you on version 2018.2-.4 Studio and Orchestrator… it may have been fixed if you are on an old version.


I am working on UiPath Enterprise version 2018.2.3.

Please suggest.

Also check out the Troubleshooting guide found in this post:


I am able to run the unattended bot when I run manually from the orchestrator. But when I am scheduling the robot and disconnecting from the RDP server I am getting the error and the job remains “Faulted”.

Yeah, I understand. But last time I had that issue was before we upgraded to 2018.
As a workaround, you can manually log in your robots, then disconnect them from the server (not sign off); this will keep a logon session available so they can log in.

To resolve issue, you might need to consult your local IT department and UiPath Technical Support: Contact Technical Support

That is, if the Troubleshooting guide posted above does not help resolve the issue.



I get it.

But then again, as you said, I have just logged in and closed the RDP session (never signed off), but still I am getting the very same issue. I guess I am missing out certain settings to be done in order to deal with this.

Kindly advise.

Thanks and Regards,

Try signing them off instead, then.

Also, there are posts in this topic that might be helpful.

The same issue here. Robot v18.2.3; Orch. v18.2.6
@hacky has described the issue perfectly.

The system only functions when the bot account is actively logged into the robot server (Win. 2012 R2).

TY for the expected update fix.

Hi @ChrisConti,

This issue has been sorted out.

When you create a robot in an orchestrator, click on RUNTIME and set “Login to console” to be ON.
Note that after doing this, you need to select “Yes”.

After doing this, even when you are disconnected from the server machine, your robot will login and perform the given task without any glitch.

Thanks and Regards,

I came across the same incident, Orchestrator & Robot version 2019.4.2, though I constructed “High Density” Robots on a VM machine.
In my case, I fixed it successfully by granting Robot User Account to start RDP session.
I set AD group policy “Computer Configuration > Administrative Template Policy definitions (ADMX files) retrieved from the local computer. > Windows Components > Remote Desktop Service > Remote Desktop Session Host > Connections > Allow users to connect remotely by using Remote Desktop Services” as “Enabled”.
And make sure that Robot User must not start Robot Agent on their account, Robot Agent must be started by the other Administrator account. When Orchestrator dispatching a job to Robot, Robot User can use the Robot Agent process started by other Administrator accounts in order to execute job dispatched.

I hope this would help you to resolve your issues.

I know this is an old thread, but I ran across it looking for something else and wanted to say…

Setting “login to console” to on is not an appropriate solution - this will cause only one automation to be able to run at one time on a server. For proper functioning of your overall automation environment, “login to console” should be off so that Orchestrator can run multiple RDP sessions at one time.