For the purpose of this guide, we assume a host machine represents a workstation (physical or virtual) on which a UiPath Robot is installed. In Orchestrator, a machine entity works as an API key generator, which authorizes the connection between the UiPath Robot and Orchestrator.
The Machines page enables you to provision and manage machine entities to further use them to connect UiPath Robots to Orchestrator. It displays the existing machines and their types. Machines are global resources, meaning they are available across folders.
Machine Template
Enables multiple users to connect their UiPath Robot to Orchestrator using the same key. The generated key works for any machine on which the UiPath Robot is installed, with no restrictions in terms of machine name, so this can be used for all types of setups, including those in which the name of the workstation changes every time a user logs on to it.
Common usage scenarios:
- Non-persistent Virtual Desktop Infrastructures (VDIs) - public workstations where the end-user changes frequently.
- Environments with arbitrary machine/user combinations.
Orchestrator Setup
A machine template (the name is irrelevant)
A floating robot for each user (it can be an AD user defined using the domain\username syntax, or a local user defined using the machine_name\username syntax)
The key of that machine template can be then used to connect the UiPath Robot to Orchestrator for any of those users as long as they do not connect to Orchestrator on multiple machines concurrently using the same username. You need to log out of one machine to connect the UiPath Robot to a different machine.
Standard Machine
Enables you to connect the UiPath Robot to Orchestrator on one workstation only. The standard machine key is generated for a single workstation with the same name as given to the standard machine. This is recommended if you want to restrict connecting the UiPath Robot to Orchestrator on a certain machine only, as it works in scenarios in which the machine name stays the same each time you connect to it.
Common usage scenarios:
- Persistent Virtual Desktop Infrastructures (VDIs) - private workstations where end users use the same workstations day after day.
- Environments with static machine/user combinations.
Orchestrator Setup
A standard machine (its name should be an exact match to the machine on which the UiPath Robot to be connected to Orchestrator is installed)
A standard robots for each user that uses that machine (it can be an AD user defined using the domain\username syntax, or a local user defined using the machine_name\username syntax)
The standard machine's key can be then used to connect the UiPath Robot to Orchestrator for any of those users on the workstation with the same name. If the name of the workstation ever changes, you are required to delete and recreate the standard robots using the new name.
Finding the Machine Name
There are multiple ways of finding your machine name. Here are the three most common:
- Open Command Prompt and type hostname.
- In the UiPath Assistant, on the Orchestrator Settings window.
- In Control Panel -
Control Panel\System and Security\System.
Standard Machines in Modern Folders
To easily migrate from classic folders to modern folders, standard machines can be associated with modern folders so that upon migrating, you do not need to change the machine key.
A standard machine cannot work in both classic and modern folders simultaneously, and as such the classic model takes precedence. A standard machine works in the classic folder as long as there are active robots defined. Disabling all robots that are using it in the classic context will render it usable in modern folders.
User-Machine Mappings
User-machine mappings enable you to tie unattended usage under particular users to specific machine templates. The gives granular control over the execution targets of your automation. User-machine mappings can be tenant-based (not tied to a specific folder), or folder-based (tied to a specific folder).
Enabling user-machine mappings
- At the tenant level, navigate to Settings > General.
- In the Modern Folders section, enable/disable the corresponding toggle.
- Tenant Mappings - You can configure tenant user-machine mappings on the Machines page in Orchestrator by linking the users who usually log in on specific host machines to the associated machine templates. You can do this on the User-Machine Mappings tab when creating a template or editing an existing one. The resulting user-machine mappings become the only supported pairs for execution.
Users are depicted on the User-Machine Mappings page using the Windows credentials (Domain\Username) of their unattended robot if one has been created.
- Folder Mappings - You can configure user-machine mappings on a per-folder basis, meaning that, in a particular folder, on a machine template, you can limit the execution to specific users only. The resulting user-machine mappings then become the only supported pairs for execution in that folder.
Folder mappings act as subsets of template mappings and allow you to achieve the utmost level of granularity possible. Not providing folder-level mappings leaves template-level mappings in place as the defaults.
Known Issue
Upon disabling the User-Machine Mappings feature, existing user-machine mappings will be kept when running jobs, even if the mappings are not visible in the UI.
Note
All changes made to tenant mappings are reflected at a folder level as follows:
- Inherit from tenant - all user configuration changes made for tenant mappings are reflected at a folder level, adding or removing users to tenant mappings adds/removes them from folder mappings as well.
- Specific user-machine mappings for this folder - adding a user to tenant mappings does not make them available for folder mappings; the user is excluded from folder mappings. Removing a user from tenant mappings removes them at the folder level as well.
Important!
Users added to a folder after user-machine mappings have been configured are not added to the existing mappings; hence, they will not be able to use that machine. Make sure to manually map the users to the machines in order to use it.
Important!
Users part of mappings that are employed in triggers cannot be deleted or unassigned from the folder the trigger resides in. Make sure the user is not set as an execution target in a trigger so you can delete them.
Machines Permissions
In order to be able to perform various operations on the Machines page, you need to be granted the corresponding permissions on Machines:
- Viewing a machine and machine-related details View on Machines
- Editing a machine - Edit on Machines
- Creating a machine - Create on Machines
- Deleting a machine - Delete on Machines
- Changing user-machine mappings at the tenant level - View on Machines, Edit on Machines OR View on Machines, Create on Machines
- Changing user-machine mappings at the folder level - Edit on Folders OR Edit on Subfolders
Read more about roles.
Note
You also need View permissions on Machines for creating Standard Robots.
Robot Versions
On the Machines page, you can also view your Robots' versions on the Installed Versions column. The version of a Standard Robot is obtained when the UiRobotSvc service is either started or restarted. The version of an Attended Floating Robot is obtained when the Robot connects to Orchestrator. The following may be displayed according to the various scenarios that may arise:
-
No Robots
- no Robots were ever provisioned on the machine
-
Unknown
- 1 or more Robots were created, but none of them has ever been connected
- 1 or more Robots were created after the Robot-Orchestrator connection had been established
-
[installed version]
- 1 Robot with a version later than 18.2.0 was registered and it is connected
- more Robots having a version later than 18.2.0 (the same one) were provisioned and they are all connected
For example, if you have provisioned one 18.2.4 Robot, which is connected, then 18.2.4 is displayed. If you provisioned a number of 18.3.0 Robots, say 11, and they are all connected, then 18.3.0 is displayed.
-
< 18.2.0
- 1 Robot with a version prior to 18.2.0 was provisioned and it is connected
- more Robots having a version prior to 18.2.0 were provisioned and they are all connected
For example, if you have provisioned one 18.1 Robot, which is connected, then <18.2.0 is displayed. Similarly, if you provisioned a number of 17.1.0 and 18.2.0 Robots, say 9 and 5, and they are all connected, then <18.2.0 is displayed.
-
[number of distinct known versions]
- 2 or more Robots having different versions were registered and they are all connected
For example, you have provisioned a total of 14 Robots (10 with 18.3.0, 2 with 18.2.4, 2 with a version prior to 18.2.0). In this case, 3 versions is displayed.
- 2 or more Robots having different versions were registered and they are all connected
To view the version of each and every Robot connected to a specific machine, click the More Actions button and then View Installed Versions. More details here.
Updated about a year ago