Usually I just connect via remote desktop application.
The automation is already set-up and running successfully in the so-called server.
For the longest time, it was also successful even if the user is logged-off the server(running through orchestrator or windows task scheduler via bat file execution).
Suddenly when the automation is not proceeding when the user is logged-off the server.
tested out this below cases:
Case1: when logged-in the server:
tested out via UiPath studio(run/debug) → successful
tested out windows task schedule via bat file → successful.
tested out via orchestrator(unattended setup) → successful
Case2: when logged-off the server:
tested out windows task schedule via bat file → failed (executed the bat file then close remote desktop(RDP))
tested out via orchestrator(unattended setup) → failed(closed the RDP then run thru orchestrator using separate laptop)
Here is below screenshot of orchestrator “Job/Logs” when running the Process while connected.
Again I’d like to emphasize number 4 in the above stating,
For the longest time, it was also successful even if the user is logged-off the server(running through orchestrator or windows task scheduler via bat file execution).
For some reason the process suddenly is not working when RDP is closed.
You mentioned that you tested with Orchestrator unattended setup, but it’s crucial to ensure that the Robot is configured correctly as an unattended Robot. When the Robot is set up as an unattended Robot, it should be able to run processes without requiring an active session. Double-check the Robot configuration and make sure it’s set to “Unattended.”
Yes
If the job logs in Orchestrator show that the process is configured as “Service Unattended” with a “Runtime Type” of “Production (Unattended),” then it’s correctly configured for unattended execution
So base from these 2 cases: Case1: when logged-in the server:
tested out via UiPath studio(run/debug) → successful
tested out windows task schedule via bat file → successful.
tested out via orchestrator(unattended setup) → successful
Case2: when logged-off the server:
tested out windows task schedule via bat file → failed (executed the bat file then close remote desktop(RDP))
tested out via orchestrator(unattended setup) → failed(closed the RDP then run thru orchestrator using separate laptop)
Its not possible for a user disconnect to a server when running the automation anymore in UiPath?
Based on the information you’ve provided, it seems that the configuration for unattended automation is correctly set up in Orchestrator. However, there might be specific factors related to the server environment, dependencies, or the nature of the automation that are causing issues when the RDP session is closed.
Well when u r running the bot in a remoter server and disconnecting or even signing out, you are actually stopping the UiPath service agent which means stoping the robot execution abruptly
That’s why it fails
This will not work anyhow as I mentioned above
This will work as you are closing the remote server and trying to trigger from orchestrator
If it’s failing u can understand with the exception it throws
Can u share that error u r getting
As for this I actually stopped already the orchestrator.
However last I checked with the error saying “Element cannot be found” or something like that.
Element meaning the activity element I used.
In my automation process I have a “Use Application/Browser” its pointing to that activity throwing the error.
My guess was some activities suddenly cannot be executed/run when the host of the process is off.
So what I did is tried to revise the entire process but is not successful in that due to some activities are incompatible with the automation objective.
Well if this the error then it’s not because of orchestrator or even the remote server
It is something to be validated with bot workflow
Try to include the changes as per the load time of the application you are using in the process
Like Check App State and wait for element to appear
Lit bit of code tweak and fixes will help here
already tried some minor tweaks but still unsuccessful.
Tried also with windows tasks schedule when disconnecting to server.
Error is related to privilege access.
I think only option now is to have the server setup as still on-screen active even though user has disconnected
You need to ensure whether the robot is installed in service mode or user mode
Reason being…
Service Mode - recommended for unattended automation scenarios and large-scale platform deployments, and runs with the same rights as the user under which it is registered.
User Mode - recommended for attended automation scenarios, and runs under the user that installed it, having the exact rights as that particular user.
You can check in what mode it is installed
Go to start → Task Manager → Services and search for this
UiPath.Service.host - this comes only for service host
UiPath.Service.Userhost - this will be there for user mode
However watching the video, it didn’t mentioned anything about:
What will happen if wil re-install again coz obviously a community edition with studio is already installed. (Personally im afraid to try coz the project is already running and it might coz conflict and might result to the process having errors or something )
After installation, how will the process execute via service mode? Would it be automatically triggered if a job is to be executed to the server or virtual machine whose user is not logged-in?
If it’s community edition with which u r trying to run when logged off it won’t work as there is no service mode in it
If u want robot to be installed in service mode you need an enterprise license
U can get trial license from here
For this setup, the robot Service is running as a Windows Service in Session 0 under the Local System user. It always runs and it always keeps the connection with Orchestrator open. Whenever Orchestrator says a process needs to run, the Service creates a new Windows Session for the User (set up in Orchestrator’s Robot ormal user rights. From unattended we don’t and we’ll never support running processes with elevated rights. It’s too big of a security risk. If Orchestrator gets compromised, it means the attacker would also have admin access to all the machines connected to it.
It gets auto triggered with help of the triggers in orchestrator
As and when robot is installed in service mode it is ready to run in unattended mode
Which means u can connect ur remote servers to orchestrator and enable schedule to run bots in unattended mode
As other members pointed community version does not support service mode
One option we can use is to use use login to console setting in the robot settings in orchestrator where when the user is not present aso the robot runs seemlessly on the rdp
And yes the vm or rdp shpuld be closed before the bot starts only or else the session where it interqcts with the ui would be closed
)
.