We have the dev robot setup on a VM, we create a job in orchestrator via an API call. Robot Starts and Closes remote desktop to the VM. If we recreate the connection quick enough we can witness the bot working.
Is this behaviour because the bot is unattended when triggered by orchestrator? the Bot is setup as unattended. Is it this that causes us to be booted out of the VM?
We only want to be able to see the bot working as we are creating a demo using another piece of software and uipath together on the VM.
If we start the job manually directly from the Bot itself we do not get boot out of the remote desktop
I’m not sure to answers your question, but I have made a similar observation.
Namely, if you happen to be “on” your VDI via RDP while ORCH sends a job to it (and you have logged on with the exact same account ORCH uses), when in 4 out of 5 instances you will experience the robot running while you are watching (as if in Attended Mode). After the robot ends the session is maintained beause it was already active when the robot waqs starting up.
If you are logged on as a different account than the ORCH starts the job with, you will be forced out (suspended, if lucky enough) while the robot is executing the package.
As mentieond, there is a 1/5 chance that you will be bumped even if you are logged on the correct account. I have not figured out why. Perhaps it’s a feature in Windows, or the correct (after all it is meant to be UN-attended) behaviour of the robot kicks in. Maybe it’s something configurable in the VM milieu.
Anil_G
ashokkarale
jinal.shah
Gautham_Pattabiraman
postwick
chandreshsinh.jadeja
vrdabberu
Ajay_Mishra
sven.wullum1
Vyshnavi_Nalumachu