We have 3 unattended bots on 3 Windows Server machines, each mapped 1:1 with a domain account:
Machine 1 → ajahg\s-rpaadmin (10.1.12.232)
Machine 2 → ajahg\s-rpaadmin2 (10.1.12.233)
Machine 3 → ajahg\s-rpaadmin3 (10.1.12.236)
Setup:
UiPath Modern Folders
Unattended Robots
RDP access
LoginToConsole tested with Yes/No
Dispatcher-Performer with triggers
Issue:
After every job, the session ends (“session has ended”), so the bot logs in again next time. This makes login time very high. Earlier, LoginToConsole = Yes helped, but now it doesn’t.
Questions:
Why does the session log off after each job?
How to keep the bot session active to avoid repeated logins?
try to again set LoginToConsole = No for better RDP handling, and configure group Policy to disable or extend RDP session timeouts. or check with IT team.
Manually RDP into one of the servers as the robot AD user for that server, now disconnect the RDP session - don’t log out. Try running your bot process.
Dear Mr. @Anil_G,
We are running Dispatcher and Performer processes. The application we use takes around 20 seconds to log in.
To optimize this, we navigate to a favorite page at the end of each process, so the bot can start from that page next time instead of logging in again.
After every job, the session closes and we see “The session has ended”. So when the next job starts, the bot logs in again, which defeats the optimization.
We want to keep the session active (idle) so that the bot can continue from the favorite page without logging in again.
If the web app supports cookies then better way would be to grab the cookies and use them to sign in the next time
The suggestion of logging in and leaving it might pose unidentified errors..also if there are any hardware events ot might fail..screenshot activities might not work..
TBH, I’m not sure if it is a good practice or not.
There’s nothing wrong with leaving an RDP session logged on but disconnected; you may have to get your IT admin to push some policies to keep the session active.
In terms of not closing an application at the end of the bot process and restarting where it left off, it is something you have to think carefully. Everybody understand that a bot needs to start from a consistent state every time. If you can verify the application state every time the bot starts, then I guess it is ok.
I have an application that was designed when dinosaurs roamed the earth, which takes 2 minutes to start up and more than 2 minutes to shutdown. I need to process multiple documents every 5 minutes. As you can see, it is not possible to start/stop the application every 5 minutes. I use a PowerShell script to kill the application at the end of business hours and the bot would start it back up the next day. Also the server is restarted every week through another PS script, followed by autologin the bot user. It is very risky to enable autologin on a Windows server; you should know what you are doing and mitigate the security risk posed by the autologin feature. I’m not going to post the risk factor here - not giving people ideas
The robot licence gets attached to a machine, but not a specific user on the machine.
As such you could have 1 licence but 10 robot accounts to do different processes if you wanted.
Because the robot logs out when its done it means a different user can log on without issue, otherwise, a VM typically has a limit of around 2 users per machine and so after 2 runs on different users, a third robot would be blocked from logging in to starts its process.
Logging off keeps the sessions clean and the machine using fewer resources.
The issue of an windows login being slow, and/or an application being slow is indeed a relatable one, keeping the session open and the application open should be considered carefully, as advised.
