Studio & Unattended Robots

Two questions: First, I am wondering if Studio needs to be installed on both our local workstation and the “virtual” machine (or just work from the virtual machine/server) in order to run unattended bots while offline? Second, I tried pulling down our Production license but it failed, saying I had more than the allotted amount of Non-Production licenses on the current machine. Do we need to have the Production license installed on the virtual machine and the Non-Production license installed on the local machine? Lastly, do we need to be logged in to Orchestrator on the virtual machine at all times, in order for the unattended bots to run?

Hi Ashley,

Regarding 1: Studio is not required on the production server / machine in order to execute unattended processes.
Regarding 2: Not sure, if I understood this correctly but yes production (unattended license) is supposed to be assigned to the production machine or if you are using a new orchestrator version the license will be assigned to the respective machine template.
Regarding 3: if Robot is installed properly as unattended and “service” it will connect with orchestrator automatically when executing a process on prod machine.
You can check here Introduction (

I hope this helps.

Thank you for your quick reply. We were able to change the Robot Installation Type from User Mode to Service Mode, however, I still don’t see an Unattended license available in the host tenant. I tried installing it using the license key but it said I had too many NonProduction licenses installed already. If it’s already installed, why can’t I see it in the License tray? When setting up the machine template for the virtual machine, it only gives me the option for a NonProduction license. How do I get the Unattended license?? I was hoping switching to Service Mode would fix this.

Hi @ashley.n.andres,

Which environment you are trying to do this one?

For Uat/non prod environment, non prod license should be fine, these work as unattended license only.

Is there a specific reason on why you specifically need unattended license?

Usually, it goes like this — for non prod environments, non prod licenses are allocated for unattended executions and for prod environments, unattended licenses are allocated.


Thank you. We have figured it out. We weren’t aware that we need to install 2 different instances of Orchestrator (Prod & NonProd). That is why only our “Non prod” licenses were showing up.


Ohh yes, 2 different instances of orchestrator are required for prod and non prod environments.

Once done, accordingly, licenses will also be allocated.

Good you have got clarity now:)


Thanks for confirming! One last question - will Orchestrator need to be installed in “Service” mode in order to run the unattended bots on the Production server?

Hi @ashley.n.andres,

Yes, that’s right.

Sharing below links as well for your reference:

  • User Mode - All the Robot’s components(Service, Executor, Tray) live on the user’s session and run with current user’s permissions. Also, the Service is not started automatically. It’s started whenever you first open the Tray and it’s using the same authorization as the Tray . When you click to start a process, the Tray goes to the Service and the Service spawns an Executor (with the same permissions as the Service) and instructs it to execute the process. So, as you see: the Executor will run with the same permissions as the Tray . I think that’s why you (@codemonkee) could access resources that require elevation. The bad part about the User Mode is that it cannot create User Sessions (cannot log in) thus it can’t really be used in unattended. You have to be logged in on that Machine before being able to start a process from Orchestrator.
  • Service Mode - For this setup, the Robot Service is running as a Windows Service in Session 0 under the Local System user. It always runs and it always keeps the connection with Orchestrator open. Whenever Orchestrator says a process needs to run, the Service creates a new Windows Session for the User (set up in Orchestrator’s Robot) and in that Session, it spawns the Executor with normal user rights. From unattended we don’t and we’ll never support running processes with elevated rights. It’s too big of a security risk. If Orchestrator gets compromised, it means the attacker would also have admin access to all the machines connected to it.


This isn’t accurate. A single [Prod] Orchestrator instance can license multiple Robot Types [Unattended, Attended, Non-Production, Studio, Testing, RPA Developer Pro, etc.], this is tied to the license applied to Orchestrator

(Current Licensing Example)

(Legacy Licensing Example)

Orchestrator can be configured in multiple ways
Single Orchestrator with One or more Tenants and each Tenant have one or more Folders. The license applied to Orchestrator can be at the host level or split up for each tenant.

You can also choose to have Standard Orchestrator for Production and a Non-Prod Orchestrator license for non-production. To my knowledge you can still have all the licenses applied to a Standard Orchestrator, but I assume UiPath would not provide a Non-Prod Orchestrator with Production (aka Unattented) license claims. (New licensing model is new to me as we’re still using legacy licensing until the end of our term contract).

You’d want to review the licensing for example Orchestrator - Basic can only have a single tenant with a limited number of licenses but also supports Non-production tenants on the same instance. I’m not aware of any limitations with Orchestrator Standard.