🚧

Important!

Sign out of all RDP sessions on Robot machines before starting a job on them.

The Job Details window displays, among others, the errors that caused a job to fail.

Below is a list of frequently encountered errors, and what you can do when you encounter them:

An error occurred while loading the external identity provider. Please check the external identity provider configuration.

Thrown when trying to use OKTA authentication in Azure Web App deployments. This happens because the OKTA certificate cannot be added to the trusted root provider settings.

👍

Solution

Add AppSettings_Saml2ValidCertificateOnly to the Identity Server web app application settings and set it to false.

Could not create SSL/TLS secure Channel

This error is occasionally encountered when trying to get assets or queue items during workflow execution. This happens due to a Transport Layer Security failure for Windows devices attempting a TLS connection to a device that does not support Extended Master Secret. This is not an Orchestrator issue. Find here more details on the matter and how to mitigate it.

No robot available for user X

This error is encountered if the username provided for the Robot does not coincide with the one used on the Robot machine. For more information on how to connect the Robot or Orchestrator correctly, see the Connecting Robots to Orchestrator page.

Permission missing: Launcher

It can occur when you are trying to start a job directly from the Robot machine (from the tray or Studio), and the machine username is not the same as the one used to connect the Robot to Orchestrator. For example, if you connected the Robot to Orchestrator using the ABC username, you cannot start jobs on the Robot from the tray or Studio using a different user, such as XYZ.

If you are sure that the username with which you connected the Robot to Orchestrator is the same as the one on the machine, please use the Regutil.exe tool to deactivate the Robot license and reconnect to Orchestrator. Find more details here.

Logon failure: unknown user name or bad password

This occurs when you tried to start a job on a Robot for which the credentials (the username and/or password) provided in Orchestrator are incorrect.

📘

Note:

If the Robot username is in a domain, the username needs to be in the domain\username format.

Executor start process failed, reason System.UnauthorizedAccessException: Access is denied.

The error is thrown if the Robot password is not provided. To add the password, edit the Robot, as explained here.

Permission missing: Remote Execution

This error is displayed if you are trying to run a process on an Attended Robot from Orchestrator.

Executor start process failed, reason: A specified logon session does not exist. It may already have been terminated

There are two types of occurances:
A. Every time you try to start the Robot - This means that a logon session cannot be created at the moment. This happens if you are connected to the Robot machine with a different username with RDP. To avoid this error, sign off all the RDP connections on the Robot machine.
B. Randomly - In this case, you can attempt the following:

• Check if the Robot machine has enough resources (CPU, Memory).
• Check the connection time using the mstsc command-line function. If the 60 seconds timeout period expires, the error is displayed.

An existing connection was forcibly closed by the remote host “Ooops! We’re sorry! It seems Orchestrator is down.”

This issue can occur in the following cases:

• The server is restarted in Internet Information Services (IIS).
• The server is shut down.
• The connection to the server is suddenly lost.

Value cannot be null

Encountered if, in Orchestrator, you start and kill a job quickly, while the process is still being downloaded on the Robot machine.

Job not found

The issue occurs when the connection between the Robot and Orchestrator is lost for a scheduled job with the Terminate After option enabled.

The handle is invalid

This error is displayed in the following cases:
A. Projects containing UI Automation - when a RDP connection already exists in the background (minimized).
B. As a known Windows issue.

An attempt was made to reference a token that does not exist

This error is related to a known Windows issue. For more information, please use the enableLowLevel tracing option and provide the generated .etl file to our support team.

Desktop has been disconnected while performing UI actions

The issue occurs whenever the RDP connection to the Robot machine is lost. Learn how to avoid this by Executing Tasks in a Minimized RDP Window.

A device attached to the system is not functioning

This is caused by an external issue.
"An attached device is not working for one of these reasons: (1) it is switched off, or connected improperly; (2) the floppy disk and drive types are incompatible; (3) the floppy disk is not properly inserted in the drive; (4) the drive door is open; or (5) the floppy disk is not properly formatted."

Executor start process failed, reason System.Runtime.InteropServices.COMException (0x800700AA): The requested resource is in use

The issue is encountered if the logIntoConsole parameter in the UiPath.settings file is set to true while using High-Density Robots.

Execution error: System.UnauthorizedAccessException: Access to the path 'C:\ProgramData\UiPath…is denied

This error is encountered in the following situations:
A. If High-Density and regular Robots write or modify the same file. To avoid this, generate different files for Robots and unique user IDs.
B. If a Robot does not have write permissions for the target folder.
C. If the file has been created and the Robot cannot edit it.

Robot already running for user

This issue occurs when schedules overlap (2-3 schedules start at the same time).

Bad request and The remote host did not answer in a timely manner.

The issues occur when not all users on a machine are connected as Robots to Orchestrator.

Check the Robot LAN Settings for an enabled proxy server. If a proxy server is specified, check out how Redirecting Robots through a Proxy Server works.

📘

Note:

This only works over un-authenticated proxy connections.

The remote certificate is invalid

This occurs when the public key of the certificate is not imported or it is not imported in the trusted root certification authorities of the local machine. Read about Web Certificates for more information.

Cannot upgrade the legacy UiPath.Core.Activities package.

This error can occur when you execute processes created prior to 2018.3.

Processes created prior to 2018.3 depend on the legacy UI Automation package, namely Core.Activities. When you run them in the current version, you must use a Core.Activities meta-package that migrates the activities using the new System and UIAutomation packages.

By default, the legacy Core.Activities package is not published anywhere, so the migration meta-package is used. However, if the legacy Core.Activities was published on custom feeds or Orchestrator by users, the legacy package is installed, which exhibits this error.

To solve or avoid this issue, simply remove the legacy Core.Activities package from any custom feed before trying to execute the process again. Also, remember to check out how to Open Projects Created with Previous Versions.

System.Runtime.InteropServices.COMException: Licence permission missing

This issue occurs on Studio v2018.3.2 and above, when executing projects that are using the 18.3.6864.20582 version of the UiPath.UIAutomation.Activities package.

If you have projects created with Studio v2018.3.1 which were using the UiPath.UIAutomation.Activities dependency version 18.3.6864.20582 you must open them in Studio and the UiPath.UIAutomation.Activities dependency must be updated to the 18.3.6877.28298 version.

If you have projects created in versions prior to v2018.3.1 and weren't opened with this version, but v2018.3.1 is already installed, you must perform the following steps to prevent compatibility issues with future versions of the UiPath Platform. You must delete the 2018.3.6864.20598 version of the UiPath.Core.Activities dependency from the following locations:

• The Orchestrator feed
• The default packages location - %Program Files (x86)%\UiPath\Studio\Packages
• The NuGet cache - %userprofile%\.nuget\packages\uipath.core.activities

If Studio/Robot v2018.3.1 was NOT previously installed and the 18.3.6864.20582 version of UiPath.UIAutomation.Activities package is not deployed locally or on your Orchestrator feed, then you can upgrade to v2018.3.2 without any risks.

📘

Important:

If you ever installed other 2018.3 versions than the Enterprise Studio v2018.3.1 edition (eg. Community Stable v2018.3.0 or any prior beta versions for both Enterprise and Community), the above applies as well. Do not use any UiPath.UIAutomation.Activities with version less or equal than 18.3.6864.20582, and UiPath.Core.Activities with version less or equal than 2018.3.6864.20598.

Bad Request - Request Too Long

This error can occur when trying to access Orchestrator, due to a browser persistent cookies issue.

To solve or avoid this issue, clear the cookies in your browser. For example, for Chrome browsers, follow these instructions to clear the cookies, making sure you select All time as time range. Internet Explorer or Firefox browsers also have detailed instructions on how to delete the cookies.

If you are getting a Bad Request - Request too long - HTTP Error 400. The size of the request headers is too long. response, it is likely that the token signing certificates don't match on each node in a high availability configuration.

Invalid identity access token authentication options. Please check web.config

This error can occur if you've not installed Identity Server along with Orchestrator while using the Azure App Service installation script. Orchestrator only works with Identity Server, thus both have to be installed.

To solve or avoid this issue, perform all the steps listed here to install Identity Server along with Orchestrator.

Too Many Redirects

This error can occur in several situations:

Certificate URL Mismatch

The Too Many Redirects error can occur if the Identity Server's SSL certificate doesn’t match the URL used for Orchestrator and Identity Server.

Check if this is your case by getting the values for ExternalAuth.System.OpenIdConnect.Authority and IdentityServer.Integration.Authority keys in Orchestrator's web.config file and opening them in a Chrome browser. The browser indicates if there’s something wrong with the certificate.

Faulty ASP.NET Core Web Hosting Bundle Installation

The Too Many Redirects error can occur if ASP.NET Core Web Hosting Bundle is not installed properly.

Check if this is your case by opening https://localhost/identity in a browser. The 500.19 Error Code: 0x8007000d error indicates a missing or malformed web.config file.

The obvious solution for this issue is to reinstall the ASP.NET Core Web Hosting Bundle.

Mismatched URLs Between Orchestrator and Identity Server

The Too Many Redirects error can occur if the Host name and the Orchestrator public URL fields within the UiPath Orchestrator Setup wizard had different values. During installation, make sure to enter the same URL for Host name in the Orchestrator IIS Settings step of the wizard, and for Orchestrator public URL in the Identity Server Settings step of the wizard.

Pay special attention to the Orchestrator public URL field, because it is auto-populated with the local server's URL, which might not match with the Host name for Orchestrator.

As a workaround for the Identity Server misconfiguration described above, you should perform changes in Orchestrator's web.config file and in Identity Server's [identity].[ClientRedirectUris] database table, changing the wrong, possibly local server URL, with Orchestrator's Host name value.

After performing the changes required by this workaround, restart IIS using the IISReset command-line utility and restart your browser. You should be able now to log in to Orchestrator.

Changes Needed in web.config

Update the following keys in Orchestrator's web.config file to the value used for Orchestrator's Host name:

• IdentityServer.Integration.Authority
• ExternalAuth.System.OpenIdConnect.Authority
• ExternalAuth.System.OpenIdConnect.RedirectUri
• ExternalAuth.System.OpenIdConnect.PostLogoutRedirectUri

<add key="IdentityServer.Integration.Authority" value="https://Orchestrator/Identity" />
<add key="ExternalAuth.System.OpenIdConnect.Authority" value="https://Orchestrator/Identity" />
<add key="ExternalAuth.System.OpenIdConnect.RedirectUri" value="https://Orchestrator/signinsystemopenidconnect" />
<add key="ExternalAuth.System.OpenIdConnect.PostLogoutRedirectUri" value="https://Orchestrator" />

📘

Note:

Replace all occurrences of https://Orchestrator with your own Orchestrator's Host name value.

Changes Needed in [identity].[ClientRedirectUris]

Update the incorrect entries in Identity Server's [identity].[ClientRedirectUris] database table with the value found in web.config's ExternalAuth.System.OpenIdConnect.RedirectUri key.

For example, if a RedirectUri pointed incorrectly to a local server's URL, change it to point to https://Orchestrator/signinsystemopenidconnect.

📘

Note:

Replace https://Orchestrator with your own Orchestrator's Host name value.