We are using Orchestrator to run workflows on remote VDI’s (backoffice, unattended).
We are unable to get either the UiPath screenshot activity nor custom code to take a screenshot to work. Note we have used both in other environment configurations.
How can you capture a screenshot running a workflow on an unattended VDI?
Hi @Scott,
When you have a third party application like snagit in VDI. And try to take screenshot, it opens up a window to drag an area on screen(same as snipping tool).
Request you to check the VDI if it is the issue.
Nothing out of the ordinary as far as I know. I am simply running the code that was provided. That code works fine on my local machine. And it works fine on our VDI’s as long as someone is connected to it. But if you disconnect, to let a robot run in unattended mode, it fails to generate the screenshot.
I will say this again.
I am using the code that was provided in the sample above.
That code does not use a selector and so takes a screenshot of the entire screen (which is fine).
This code WORKS (and does not generate any errors) locally or when a VDI is open.
This code does NOT WORK when a VDI is closed (not logged into).
I am adding some logic to capture error information and will post it.
I appreciate your thoughts.
Important detail, when you say you run the workflow when VDI is open and it is working, do you use system tray or Studio?
in case you would be using studio, very likely what could be happening is that you are saving the screenshot using a relative path (.screenshot\untitled.png). When you are running it from studio, it will save the screenshot on the project location as it is the current context of the workflow execution.
However when you publish your project and trigger it from orchestrator or system tray, the context will become the package is stored after it is synced with the orchestrator (on 2017.1 it will be attempted to be as saved %programdata\UiPath%ProjectName&Version\lib\net45\untiltled.png and fail because you cannot save file at this location.
A simple way to spot the location for a relativepath is to log something like under
new FileInfo(“Untitled.png”).FullName
if you do not have any try catch, running from the system tray should be showing your an error related to the path.
If you do not use relative path you have no error occuring from system tray with TryCatch, the problem is elsewhere
is there an active desktop for the robot (code) to work on when in unattended mode?
I’ve had a similar problem and it was solved by setting the attribute Interactive Logon =True for the AD-account used by the robot. Check with your AD-team, maybe it’s the same problem.
Thanks, Klaus.
I’m not sure abou the AD settings, but will investigate.
The uipath.settings file has “logintoconsole” set to false as a recommendation for managing screen resolution.
Klaus ~ I don’t have an answer from support on this… but I’m pretty sure if this was set incorrectly we would not be running on the VDI’s at all. We have a well established infrastructure and run bots all the time. The only thing we seem to be having a problem with is this image capture. And the only variance is in whether the VDI is “open” or not.
Since there’s no actual video output, I’m trying to understand if there is something in the way an unattended execution handles its video that makes grabbing a screen capture not work… and if so, if there might be something we could code to address that. It is quite vexing…
Hi @Scott
I have been using unattended robots and capturing screenshots like when a fault occurs, and that is without the Launch Interactive. It seems to work fine for me.
If you are talking about Image recognition then yeah, we had issues with that until I discovered the Launch Interactive activity and got the resolution set correctly. Everything works now for the processes that required it - OCR, Image clicks, Clipping Regions, etc
I don’t know if that will help answer any issues but just letting you know that we haven’t had any issues like you are describing.
Interestingly enough, I tried one time to record video while the unattended robot ran and it only recorded a black blank screen.
Thanks, Clayton… that is helpful to know. That’s exactly what we are trying to do… just without consistent success. It is becoming apparent to me that there must be something about our VDI’s that is non-standard…
I have the same issue on unattended robot on disconnected VDI when doing screen capture.
Any further update from you or other experts here?
I wonder if the graphic session of the VDI is destroyed once it is disconnected (as i read from other thread about RPA on VM/VDI/RDP) so it is not possible to capture the screen into picture.
But same, I need a solution for this too, I require to use screenshot to capture any exception encountered by the bot.
Unfortunately, we never found a work around for this. Ultimately, we are scrapping VDI’s and transitioning to an RDP solution where this doesn’t seem to be a problem.
In general, we have had a MUCH better experience with the server solution.
Hi Scott,
the word “resolution” keeps popping up. Maybe it’s “just” that…
One of my collegueas was working on a Navision/PDF process where everything worked fine locally, but after moving to ORCH 2018 it failed. After some frustrating days he was able to figure out that the resolution was too low in runtime and this cramped all his windows to a minimum.
He found out, that when an unattended robot (at least in his case) was called into action the screen resolution was set to 640 x 400 (or similar crazy (default?) setting). This of course made FUBAR in his full-screen robot. He was able to see this in action by shadowing the robot using TeamViewer or a similar remote tool.
The solution was to make sure the screen resolution was the set to the expected 1920x1080. This was done on the robot in ORCH which now has a runtime-tab where you can specify a desired resolution for this particular robot.