Hi, everytime we try to run a process this error is shown: Could not start executor. Rdp connection failed: Message: The connection transport layer failed., Last error: 131085
Does someone know why is this?
3 Likes
Check this Remote Desktop Failing from Windows 10 Client to Windows Server 2008 R2 Gateways but fine from Windows 7 clients. If this is not related then can you please post the error screenshot and explain in detail about how the job is executed on robot, OS details. Version of Orchestrator, robot
1 Like
This happened on my end when I changed the Robot to not log on to console, in the Robots options within Orchestrator.
5 Likes
Thanks a lot, it works for me
Hi Bro,
If we get the same issue again, then how can we get an email alert notification from orchestration for this issue? “RDP is not up.” Thanks in advance.
You can leverage the native alerts in orchestrator for job faults. That should alert you of any job fault including RDP issues.
Can I ask how you overcame this, I cannot get unattended automations to trigger on a windows 10 machine, they worked fine until my windows crashed and I needed to format and reinstall. If I turn on the login to console I get a different error and if I turn off I get this error (I believe the same as the ticket)
I have also made sure I was completely signed out of all users on windows machine before triggering automation from orchestrator
Could not start executor. Rdp connection failed: Message: The connection transport layer failed., Last error: 131085
RemoteException wrapping System.Exception: Could not start executor. Rdp connection failed: Message: The connection transport layer failed., Last error: 131085
I’m sorry, no this is 3 years ago and I don’t recall anything about this :o)
Hello
Did you find solution please about this issue?
Best regards
Hi,
This was a never ending story topic actualy.
We had to request special support from UiPath which was included in the service package we bought, nevertheless we never got a definitive solution more than trying to add more time between triggers.
Sorry I can provide further details, but it was a long time ago as well and I can’t remember at all.
Regards!
1 Like
Hello,
Did you find solution please about this issue?
Best regards
Hi, we are experiencing this problem also on our central Robot terminal server.
Since about 2 month this happens totally random (about 4 times a day).
So in between we start hundrets of robots without any problem, and then, one is failing…
Any ideas?
Hi,
It’s weird that this is random, but can you make sure the user the robot is running with is present in the Remote Desktop Users in here:
1 Like
I am facing the same issue,
the strange thing is that it was working properly in log in to console feature for my robot account,
then I changed it to RDP login (Login to Console option = NO) and it worked properly for more than 1 day (I have at least 350 Jobs for each robot account on a daily basis) then suddenly at the same moment on 3 different VMs but with the same robot account the RDP connection failed
any idea what is the issue?
I am facing the same issue,
the strange thing is that it was working properly in log in to console feature for my robot account,
then I changed it to RDP login (Login to Console option = NO) and it worked properly for more than 1 day (I have at least 350 Jobs for each robot account on a daily basis) then suddenly at the same moment on 3 different VMs but with the same robot account the RDP connection failed
any idea what is the issue?
Based on your log, as the user session was not created in one minute, you had that timeout and the job Failed.
We recommend either increase the UIPATH_SESSION_TIMEOUT environment variable to 15 minutes or add a bigger delay (couple of minutes) between jobs.
Open a powershell.exe console as Administrator and run the below command:
[Environment]::SetEnvironmentVariable("UIPATH_SESSION_TIMEOUT ", "900", "Machine")
Restart the UiPath Robot service from services.msc to apply the change.
Also, starting with Robot 2022.10.4 we fixed this bug: “A job triggered from Orchestrator would fail to run if the Windows session used for the previous job did not complete the sign out process.”. If you are in a lower robot version, we recommend to upgrade the robot to a higher version and in the latest patch.
Reference: Robot - 2022.10.4
1 Like
Thank you for your Reply Marian,
I can increase the timeout duration to create sessions, but this will not solve the issue, because I have to trigger a lot of jobs cant wait this time
my question which will solve the issue of why the session is taking a long time to be created?
You will still have the same issue if you are not performing what I mentioned. You need to have a very powerful machine if you want to schedule at every minute a new job. Also, this will not guarantee that the previous job finished the logout session and is ready to create a new session.
You need to check internally why the logout and login of RDP session was more than one minute. Maybe you have some scripts that are running at the login, maybe you have a high resource consumption at that time…
Is it up to you to follow my instructions or not.
Hi Marian,
Sorry I didn’t mean that your instructions are not useful, just I wanted to mention that the issue happened at the same moment in 3 different Host VMs I checked the last jobs that were running on those VMs and the most recent job was running before 8 mins of the accident moment, so the issue in creating the session only not related to the frequency of assigning job to the VMs
I will apply what you told me, thank you for your help
