Yes @Pablito Robot does sign out every time it finishes off its process run. For the next session to kick off it would do a RDP connection to the machine and runs the process.
Please check EventViewer for both sign-in and sign-out. Sometimes it happens that sessions is not logged off correctly and hangs out still. So next run can’t log to the machine because session is still taken.
Hi @Pablito, I’m facing this same issue as well. We have large number of processes deployed on different schedules, and intermittently fails with this error and no logging for the fault. Since it happens only 1-2 times per 50 job runs, and not specific to any particular process, I think your suspicion that it is a sign out issue is probably correct.
Want to clarify on your suggested action. From what I know, the robots are supposed to sign out by default after each job, but probably sometimes the sign out is delayed and the next job is already trying to start. So are you suggesting that we include a “sign out” action in the scripts?
Also, is there any way to set up alerts for when this error happens? Thanks.
You can use for example Try Catch activity inside which you can catch exception or issues and for example use send mails activity or something what will trigger alert for you so for example administrator will be able to manually log out session.
Additionally (I assume that this is AD environment with roaming profiles) I suggest to check how big is user’s profile used to work as a robot. My experience tell me that sometimes problems with logout of user session may be caused because profile was huge (in GBs).
Thanks! I do implement try catches for other errors like you have suggested. But these faults happen even without the job starting, likely because the previous job hasn’t logged out yet. So the try catch method for alerts will not work.
Is there a way to delay the start of the next job by few more seconds to allow for the previous session log off to happen?
To answer your other question, yes this is a shared server VM with multiple user accounts setup. Each user account takes up about 2-3GB of space, but sufficient space is still left over. Thanks!
Just a thought - You could use something to recognize that user is logged in before start to perform job. For example Element exist activity and point it to start menu or something . Then loop it so it will not start anything before this element will be visible.
Current issue is that the new session does not even start, I don’t think it’s even logging in. It’s faulting before that (likely because the previous session hasn’t logged out as you and some others have also suspected). So in this case, even if I add in the “Element exist” activity it won’t be executed, right?
Thanks for writing it out in detail. In this case, when Step 7 happens and previous logon still persists, then the job immediately faults with below error. So Step 8 won’t be executed, and task two will be skipped. Task three which is queuing behind will start running (assuming that by then the task one logout has been completed), followed by task four and so on. So few hours later when I come in to work, I find that task two was skipped. This is my current situation anyway! Do you still think the logon check will work? I could still try it, but based on this sequence I am thinking it won’t help.
Sorry… I completely forgot that job with checking this will not start as user session will be locked. I needed to realize that. My bad. Based on this I have in my mind that you could try include at the end of your process the command for force logoff:
shutdown /l /f /t 00
l - logoff
f - force
t 00 - time in seconds (00 means “now”)
Force logoff can be faster than normal wat because it’s not waiting until background processes will end their run or response. But to be honest I’m not sure how it will behave with use of Workflow.
Thanks for the suggestion. I’m going to try this out on a test process and see if the workflow ends normally when you put a force log off at the end (successful on orchestrator).
I tried using your command manually in in cmd prompt, doesn’t seem to log off. Am I missing any argument?
Based on the suggestion in the link below, I have enabled the login to console option yes in the ROBOT settings and it has solved the issue. This enables bot to disconnect existing session before login to the console everytime it executes a process.
You may also try to get your windows profiles cache deleted (ask your AWS or AVD team to do it for you). This will result in faster logout of your windows session (As you are staring the session for the first time).
Make sure you backup all the settings and files saved on profile locally before deletion.
. Then loop it so it will not start anything before this element will be visible.
