Encountering Error "A specified logon session does not exist" in Orchestrator 2020.10

Help Orchestrator
,
1

Hello,

We are currently using UiPath Orchestrator 2020.10 (on-premises) with Robots in version 2020.10. We have around 50 processes running on two virtual machines (Azure Windows 10 VM). Each process is configured to use a different user, and all robots are set as unattended with the “Login to Console” option set to false.

Over the past three weeks, we’ve been experiencing faulted jobs with the following error message:

Info: Could not start executor. A specified logon session does not exist. It may already have been terminated. (Exception from HRESULT: 0x80070520)
RemoteException wrapping System.Exception: Could not start executor. A specified logon session does not exist. It may already have been terminated. (Exception from HRESULT: 0x80070520).

This error occurs sporadically and seemingly randomly for different users, VMs, and processes. It doesn’t seem to be related to a peak in triggers. Typically, retrying the process shortly after results in it running without any issues. Our virtual machines have ample CPU resources.

We have tried various solutions, including extending the UiPath_SESSION_TIMEOUT environment variable to 60 seconds, resetting Robots, and even restarting the VMs, but the error still persists.

One noteworthy observation is that this error does not occur when the bot is started from a trigger or manually run from Orchestrator after we manually log in to the bot’s user using Remote Desktop Connection (RDC). What’s unusual is that after the job ends, we used to be automatically logged out from RDC, however recently, the session isn’t ending, and we can still see the user logged in.

It’s also worth mentioning that once we were logged in with one user on the VM and started a job manually from Orchestrator for another user, we monitored the task manager and noticed that the robot’s user didn’t appear in the logged-in users list even for a second.

We are seeking your insights and expertise in resolving this session error. Any ideas on what could be causing this issue and how we can fix it would be greatly appreciated.

Thank you in advance for your assistance!

2
  • You may try upgrading your robot to a more recent Official supported version.
  • In Orchestrator → Tenant → Manage Access → Edit your impacted robot → Robot Settings → Login Console should e enabled and set to No
  • After performing the above, you need to make sure that you Sign out from the robot account in VM (make sure to not disconnect)

Notes:

If the Login to console is TRUE the robot service will attach to the current Console Session. This is not recommended for HD robots as there is only 1 console session which can be active at a given time, regardless of OS (Server vs Standalone).

If the Login to console is FALSE the robot service will initiate an RDP connection from the Robot machine onto itself and attach the session to it. This is the appropriate configuration for HD robots. Initiating an RDP connection in this case depends on some factors like licenses, local policies, connectivity constraints.

Notes:

The default timeout to wait for creating windows user session is 30 seconds. On some machines this time is insufficient due to slow performance (slow connections, policies applying from domains are slow, updates, other logon scripts).

The UiPath_SESSION_TIMEOUT environment variable should be defined on Windows system environment variables and represent the seconds to wait for a user session.
If is not defined, default timeout (30 seconds) will be used. After setting the UiPath_SESSION_TIMEOUT environment variable the UiRobot service needs to be restarted.

Example:

In the robot VM open a powershell.exe console as Administrator and run the below command:

[Environment]::SetEnvironmentVariable("UIPATH_SESSION_TIMEOUT", "True", "300")

  • Make sure sufficient connection slots exist:

    Run gpedit.msc

    Verify the Policy: Windows Components\Remote Desktop Services\Remote Desktop Session Host\Connections: Limit number of connections

  • Check Username used to connect to Robot machine:

This error also occurs when you are connected over RDP/Console to a Robot machine with a different username (e.g. a Robot has the X - admin and you are connected over RDP with the Y username). To avoid this error, sign out all the RDP connections on the Robot machine.

To validate logins after the fact you can Audit Logons: Audit Logon - Windows Security | Microsoft Learn and Logoffs: Audit Logoff - Windows Security | Microsoft Learn

  • Check the following registry keys:

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
fPromptForPassword 1 (TRUE)
fInheritAutoLogon 0 (FALSE)

This will require authentication to happen twice, which we do not support.

  • Autologon with non-securely stored password not supported

If autologon password is set up using the following deprecated method, console logins might not work:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultPassword

Solutions:

  • Disable autologon (delete DefaultPassword, DefaultUserName, AutoAdminLogon)
  • Use the newer method to store the password: delete DefaultPassword, use netplwiz.cpl to configure Autologon (which stores the password in LSA private store). Link
  • Upgrade to 18.4 which uses credential provider
3

Hi Marian,

Thank you for your quick response and your valuable suggestions. Here’s an update on our situation with some additional details:

  1. Robot Update: We’re planning to update our robots, but the current error is causing some disruptions in our Production environment. So, we’d like to address this issue first to ensure a smooth update.
  2. Login to Console: All our robots are configured with “Login to Console” set to No, and the resolution is configured as recommended.
  3. Manual VM Sign Out: Whenever we log into our Production VMs manually, we’re sure to sign out properly rather than just disconnect, to close sessions cleanly.
  4. Prerequisites and Hardware: We have thoroughly verified that all software prerequisites are met, and our hardware resources exceed the recommended requirements by at least twice.
  5. RDP Error: You mentioned an RDP connection as a potential factor, and we’re actively exploring this possibility. However, we haven’t definitively linked the error to Remote Desktop connections yet. Can you suggest something??
  6. UiPath_SESSION_TIMEOUT: We initially set UiPath_SESSION_TIMEOUT to 60 seconds and later extended it to 150 seconds, but it didn’t resolve the issue.
  7. VM Connection Limit: Our VMs are set to allow unlimited connections, which should handle concurrent robot execution.
  8. Multiple Robots on the Same VM: Due to resource optimization, it’s common for us to have multiple robots running simultaneously on the same VM. We cannot sign out all RDP connections on Robot machine as we have two machines for 50+ Robot/Job pairs on 6 Unattended licenses so it’s often the case that more than Robot is running concurrently on the same VM at the same time.
  9. Registry Keys: The registry keys you mentioned have been verified, and there is no double authentication occurring.
  10. Robot Accounts: We’ve ensured that Robot accounts are correctly added to the Administrators group on our Production VMs.

If you have any further recommendations, potential solutions, or insights to offer, please do share them. We genuinely appreciate your assistance.

4

Orchestrator 2020.10.x will be out of support in 2 weeks → you need to upgrade Orchestrator first. We recommend Orchestrator 2022.10.7 from here https://download.uipath.com/versions/22.10.7/UiPathOrchestrator.msi

Reference: https://docs.uipath.com/overview/other/latest/overview/product-lifecycle#manage

Robot 2020.10.x will be out of support in 2 weeks → you will need to upgrade Robots to a supported version after the Orchestrator. We recommend Robot 2022.10.11 from here https://download.uipath.com/versions/22.10.11/UiPathStudio.msi

Reference: https://docs.uipath.com/overview/other/latest/overview/product-lifecycle#run

After upgrading the robots to 2022.10.11, run the below command in a powershell.exe console as Administrator in the Robot VM(s):

[Environment]::SetEnvironmentVariable("UIPATH_HEADLESS_WITH_USER", "True", "Machine")

Check if you followed the prerequisites from this documentation for your Unattended robots:

https://docs.uipath.com/robot/standalone/2022.10/user-guide/installing-the-robot