We are using orchestrator 2018.2.6. (enterprise version).
Issue: we have many scheduled jobs for citrix. But all jobs are failing.
But when are logged into backoffice server and when command is send through
orchestrator to run job as per schedule, its working.
Steps taken : We tried making changes in resolution and making login into console “false”.
But nothing worked.
What we observe that workflow has no issues. But when command is sent to backoffice robot
to run that job in backoffice server, it’s not able to execute workflow.
We have parallel login enabled for our backoffice account.
Do we need to disable that.
Do we need to make changes in " login into console : false " in both orchestrator backoffice account and backoffice machine.
Also is it necessary to update resolution in both orchestrator backoffice account and backoffice machine.
I guess if you are doing Citrix automation then the screen resolution needs to be same as Dev machine or else it is a no go. And I am not sure as to why someone needs to log in while unattended bots are running.
Also, try getting screenshots after every step. The citrix Env. might be running minimized and during a user when s/he logs in it is maximized (just taking a wild guess here) you can debug using those images.
Finally, if you have an enterprise license for UiPath contact Product support by raising a ticket…!
Thanks for replying. We have already raised a case with UiPath vendor. Team is working on that.
The screen resolution is same as Dev machine. It was working two weeks back with no error.
But now all of sudden we are getting this kind of issue.
No changes made in backoffice machine nor orchestrator.
You are correct. Citrix environment is running in minimized and it’s same in our current scenario.
We tried taking screenshots at every step and verified logs as well. But error logs keep varying.
It sees backoffice robot is not able to generate session in backoffice machine when orchestrator is sending command. Can you help with some immediate resolution steps.
As per Uipath team this is resolution issue and they are working on it.
And we logged in while unattended bots are running because it was giving error and not generating any session. So as a part of troubleshoot only we use the same backoffice account to login
It depends on what the error you are getting. Typically, a resolution problem will give you a Timeout exception whenever it gets to a step that requires a GUI or Image.
You can simply change these settings per Robot in Orchestrator, without needing to change it on the servers. Go to Orchestrator > Robots > Edit Robot > Runtime settings. You can set the Logontoconsole to false (if it’s true, then multiple robots can not run at the same time on the machine) and you can set the width and height and color depth. The typical resolution used with Monitors will be 1920 width, 1080 height, 32 depth. Also, keep in mind that if you are working from a laptop with no monitor, your resolution will change so ensure that you connect to a RDP connection with custom resolution settings to keep it consistent, or use a Monitor that supports the resolution.
Also i have updated the same settings which you told in Backoffice robot runtime.
But still i am not able to run job through orchestrator.
in server do i need to update same resolution and login into console as no.
Please help me with this.
Can you please help more to get resolution issue fixed.
Workflow was developed in office pc . But when I am running job from that also , its giving timeout issue.
Now i am running job through orchestrator in my laptop, still getting timeout error.
Is there any specific KB article in which how to control resolution is explained while developing workflows.
This is happening in case of backoffice robot only. When orchestrator is sending command to backoffice robot, it will automatically generate a session in backoffice server. But after few minutes it will give timeout error.
By restoring our backoffice server , can we get all things fixed. Everything was running fine 15 days back. Now we are getting these issues.
I am sure you know this but just to be sure I am mentioning this. Any RDP connection will take the resolution of the system you are logging in from.
If it was running fine 15 days back, can you check for any changes made by your IT dept. or use one ore layer like VM inside a VDI and keep the VDI resolution same as Dev.
If it is a time out, then the image/surface automation techniques you have used (except keystrokes) is clearly not working. Has the application look and feel changed on which you have used image UI automation? has the location/co-ordinates of the app in question is changing? when surface automation is involved there are many issues like this.
Have you tried building workflows using computer vision? (I know if it is a massive project rebuilding it is a pain but CV activities in UiPath has shifted the paradigm in Citrix automation.)
personally these are the things I would check first:
Resolution of the VDI through which the VM is connected
Application behaviour (sometimes clients make changes to their environments without informing the services/dev/support team)
Login before the schedule and see what actually is happening, and sometimes due to poor internet connection the image quality on the VM might also be lesser than what you planned for so might have to tweak the percentage match parameters.
If it was running fine 2 weeks back then better to start from there, also see whether some code fixes were done and the packages that were updated have any issues (better to check the version control just in case)
If logs are varying and the error is inconsistent then can you share them here? I am just throwing it out there, but why is it being run minimized? Was it the same before?
First I will suggest to do a small rework on the flow in order to understand the activity that throw the error.
In order to do that the project should be split in small flows which should be invoked from a main Process flow.
This invokes should be encapsulated in Try Catch activities. Inside the small flows the Try Catch should be present only where you know the error and usually you transform the error in a recognised one. Else don’t use Try Catch inside those small flows.
Having this structure you can obtain the name given by you to the activity that is throwing the error, then combine this with a screen shot to see what was the situation before the error was thrown.
You can also perform a small verification with a flow containing few activities like Take Screenshot and saving it to a specific location where you have access. In this way you can check that the settings done via the Orchestrator are transmitted to the VDI. If this doesn’t work try and check the video memory allocated to the VDI. Sometimes this is to small and the target machine can’t set the desired resolution.
Having the activity that is throwing the time out and the screen shot you can check then if the interface was modified or not.
mkankatala
ashokkarale
Yoichi
sven.wullum1
chandreshsinh.jadeja
sharazkm32
sonaliaggarwal47
Ankit_Kumar2
SorenB
fanmixco