- About the Tenant Context
- Searching for Resources in a Tenant
- Managing Robots
- Connecting Robots to Orchestrator
- Storing Robot Credentials in CyberArk
- Storing Unattended Robot Passwords in Azure Key Vault (read-only)
- Storing Unattended Robot Credentials in HashiCorp Vault (read-only)
- Storing Unattended Robot Credentials in AWS Secrets Manager (read Only)
- Deleting Disconnected and Unresponsive Unattended Sessions
- Robot Authentication
- Robot Authentication With Client Credentials
- Audit
- Settings
- About Processes
- Managing Processes
- Managing Package Requirements
- Recording
- Troubleshooting live streaming and remote control
Troubleshooting live streaming and remote control
These are some issues that you might occasionally experience when you live stream and/or take remote control of a running execution.
The live stream window shows Connecting..., but no connection is established
In all scenarios below, the Robot will not connect to the live streaming and remote control system, and the session will not start. The operation is retried for the maximum duration, which is approximately one minute, and then an error is displayed. Details about the failure are available in the Robot logs on the machine where the connection fails (not in job logs).
TightVNC is not installed
If TightVNC is not installed, the session cannot be started.Make sure to download and install it beforehand.Important: The Register TightVNC Server as a system service option (under TightVNC Service configuration) must not be selected. If it is, any request to start a session is ignored.
TightVNC does not have the correct version
The version we currently support is 2.8.75.
TightVNC is installed as a portable app
When TightVNC is installed as portable, the Robot is not able to detect it.
You can configure the path to the portable TightVNC by setting the
UIPATH_TIGHTVNC_EXE_PATH
environment variable with the full path that includes
tvnserver.exe
.
TightVNC is already started on the machine
When a live streaming and remote control session is finished, TightVNC is automatically closed. If you attempt to start a session, and the Robot detects that TightVNC is running, your request is ignored.
You need to close your currently opened instance of TightVNC.
Another user on the same high-density machine already has an open session
Machines running high-density robots only support one live streaming and remote control session at a time.If you try to open a session when another one is already running, your request is ignored.
In this case, you will only be able to access live streaming once the currently running process ends.
The live stream session connects after a delay
If you start a live streaming and remote control session immediately after a job is transitioned to the Running status, the Robot might not be ready to start it yet.
After a while, the Robot can handle the request and start the live streaming.
The live streaming image is lagging
This can be caused by a slow network connection between your machine and the robot one or when the screen resolution on the robot machine is large.
You see a blank screen
These are some reasons why you might see no image on your screen when you start the live stream.
The automation UI is not started
Some jobs perform certain actions prior to prompting the automation UI to open. If this happens, the live streaming session that opens is blank. This translates into the desktop being displayed for Windows Robots, and a black screen being displayed for Linux unattended robots and Automation Cloud Robots - serverless.
Try opening the session again.
You are using Linux robots
Linux unattended robots do not have the proper support for live streaming and remote control, so we do not recommend you use them for such operations.
Try using Automation Cloud Robots - serverless instead.
You are using a physical machine with no monitor connected
Live streams of processes executed on a physical machine are rendered on a physical monitor.
As such, you need to make sure that you have a monitor connected.
A running session is disconnected
Network communication issues can cause a live streaming session to stop. If this happens, the client automatically reattempts to connect. This should be reasonably fast, but you might see the loading screen for a very short while.
If you had also enabled remote control within that session, note that you will have to re-enable it once the connection is established again. This is because, upon reconnecting, the session is opened in its live streaming state.
After a while, the session is abandoned. However, if you close the window, you can manually restart the session from Orchestrator.
You get an error message stating that another user is already connected
Only one user can access the live stream and take remote control at once. If a user is already connected, you must wait for them to disconnect.
For example, if User 2 tries to open a live stream that is already opened by User 1, they are returned an error stating that the live stream cannot be started. Once User 1 closes the live stream, User 2 will shortly be able to open it.
- The live stream window shows Connecting..., but no connection is established
- TightVNC is not installed
- TightVNC does not have the correct version
- TightVNC is installed as a portable app
- TightVNC is already started on the machine
- Another user on the same high-density machine already has an open session
- The live stream session connects after a delay
- The live streaming image is lagging
- You see a blank screen
- The automation UI is not started
- You are using Linux robots
- You are using a physical machine with no monitor connected
- A running session is disconnected
- You get an error message stating that another user is already connected