Robot & Proxy Working Details

How can one set it up? How does the proxy work when the Robot is not installed as a service? Is it enough to have the Proxy set up for the user only?

  1. How Robot and Proxy work separately ?

Robot Architecture

Below illustration is how the Robot architecture works on a Windows machine:

When Robot is installed with the default option of having a central service, the architecture looks like this:

A central Windows service (Robot Service) is installed and it handles the session handling, Orchestrator connection, process installment, etc. for all the Robots present on that machine. It runs with the Local System (a predefined local account) permissions.

The NuGet service that goes on the package feeds and downloads processes/activities packages. Same as the Robot Service, it runs in the Service session (Session 0) and as Local System.

A Robot Executor for each Robot is defined on that machine. This is the component that executes the UiPath processes. It takes the workflows from the Robot Service and it executes them with the same permissions as the User it is defined for. Also, it runs in the User’s Windows session.

For specific attended use cases, the Robot can also be installed in User mode. This means that the Robot Service will not be added as a Service anymore and all the components will run as the User and inside the User’s Windows session.

Proxy fallback

After excessive oversimplification, the way Proxies work on Windows:

Whenever an application tries to retrieve something from the internet it uses the first proxy that it finds configured. It checks them in this order: firstly, it checks if it has a specific proxy for itself. If not, it goes to the proxy set up per user. If the user proxy is not set up either, it uses the machine settings. If neither of them is set up, then it retrieves the resource by directly accessing it. No proxy used.

Whenever a User Proxy is set up, it affects all the apps opened in the user’s session. When the Machine Proxy is set up, all the users are affected, including both normal Windows Users and Local System user.

  1. How Robot and Proxy work together ?

Now, understanding all the background details, let’s put everything together.

In these diagrams, it is possible to know how proxies configurations are spread across users and Robot sub-components. For service mode, NuGet and Robot Service are under the Local System User, while the Executor runs under a different user.

For the user mode, all three components are running as the same user.

Whenever UiPath Robot is required to work well through a proxy, first consider what are the requirements in terms of granularity. If it’s OK for all the communication to go through the same proxy, then just set up the Machine or User Proxy and sufficient to go. This can be performed through Internet Explorer.
If more granularity is desired to redirect the traffic to different proxies according to the operation type, the following options are present:

  • For directing the Service ↔︎ Orchestrator communication (connecting the Robot to Orchestrator, sending the heartbeat, getting the list of processes, etc.) , set up the proxy for the Robot Service. Do this in the UiPath.Service.Host.exe.config (%ProgramFiles(x86)%\UiPath\Studio file.
  • For Orchestrator activities (managing queue items, getting credentials, etc.) and HTTP request from the UiPath process, set up a proxy for the Executor. Do this in the UiPath.Executor.exe.config (%ProgramFiles(x86)%\UiPath\Studio file.
  • If only the package download is to be redirected, modify the NuGet proxy config. This can be found in C:\Windows\System32\config\systemprofile\AppData\Roaming\NuGet(when installed in Service mode) and %userprofile%\.nuget\packages(when installed in User mode).

Of course, on top of this comes the fallback mechanism, that can be made use of. For example, if the NuGet and Robot Service is required to go through a proxy, set up the Local System User Proxy and both of them will use it.

You do not need Robot for a normal proxy. You need it for corporate VPNs.