Frequently Asked Questions

About Machines

What does a standard machine include?

All standard machines that we provide are Microsoft Azure virtual machines of the type Standard_E2s_v4, which have sufficient computing power for basic automations.

In addition, all standard VMs come with:

• the UiPath Studio and Robot software preinstalled
• the supported web browsers you might need for running automations.

If you need additional software or to set up the VM in a certain way, you can further customize it.

What machine size should I choose?

When choosing the machine size, here are some things to consider:

• How large are your datasets?
• What kind of applications are you planning to run and what are their requirements?
• How many applications do you plan to leverage?
• Will you leverage ML Skills and AI Packages?
• What kind of jobs will the machine run - small routine tasks, heavy-duty, one-time setup, debugging?

Based on the answers, you may be able to use a small machine, or may require a more powerful machine.

The machines sizes that you can choose from have the following technical specifications:

Size	vCPU	Memory (GiB)	Max uncached disk throughput (IOPS/MBps)	Max burst uncached disk throughput (IOPS/MBps)	Expected network bandwidth (Mbps)
Small	2	16	3200/48	4000/200	5,000
Standard	4	32	6400/96	8000/200	10,000
Medium	8	64	12800/192	16000/400	12,500
Large	16	128	25600/384	32000/800	12,500

When are UiPath Studio and Robot updates applied?

We take care to update your VMs to use the latest version of UiPath Studio and Robot within approximately 2 weeks of a new version becoming available.

The update happens:

• when a machine needing an update first starts
• before a machine that was running jobs shuts down
• for machines that are in constant use and are not able to receive the update for 2 weeks since the update was available, we schedule a short maintenance window on the machine to apply the update.

Where are virtual machines created?

All virtual machines are created and hosted in our Microsoft Azure subscription.

In which region are virtual machines hosted?

All virtual machines are created and hosted in the tenant region.

Organization administrators can see what the region is for a tenant in Tenant Settings (Admin > Tenants).

About the Maintenance Window

Will the machine images that I created be automatically updated with the latest Windows version and updates?

No. If you want to install the latest Windows version and updates, you can:

• connect to the machine using RDP to manually update Windows.

  Then, if you want, you can also create an image of the customized machine and use it in other machine templates.

• configure a maintenance window for the template when you can push updates to all machines.

Does the maintenance window apply for all machines?

Only machines that belong to the machine template where the maintenance window was configured and for which Accept Jobs is Enabled enter the maintenance window.

Machines that are not running are automatically started for the maintenance window.

Are robot units consumed during the maintenance window?

The required robot units are consumed once per month, when the machine first starts. After that, it can run indefinitely for the whole month without consuming additional robot units.

Disabled Machines

Why do I have machines in a disabled state?

We automatically disable the most recently-created machines if they consume more robot units than you have available for your tenant.

How do I re-enable a disabled machine?

You must add sufficient robot units for that machine to the tenant. These will be consumed and your disabled machine will be automatically re-enabled within approximately 30 minutes.

If you do not allocate sufficient robot units to re-enable all of your disabled machines, only some machines are re-enabled. We start with the oldest machine and move up to the newest.

Note: After being re-enabled, a machine is in a stopped state. To use it to run jobs, you must start the machine.

Do disabled machines consume robot units?

Yes. If you have disabled machines and add robot units to your tenant, they are automatically consumed to re-enable your disabled machines.

How can I prevent disabled machines from consuming newly-added robot units?

If, for example, you want to allocate some more robot units to a tenant for Automation Cloud robots - serverless, you need to make sure that you don't have disabled machines that would consume the robot units.

To prevent this, you must delete the disabled cloud robots - VM machines before you allocate the robot units to the tenant.

Robot Units Consumption of Automatic VM Pools

When defining the automatic machine template, make sure you have enough robot units (RUs)on your machines.

If you do not have enough RUs, the following consumption restrictions apply:

• If your robot units do not match to the maximum number of VMs defined in the pool, we delete all machines in the pool and stop creating new ones until you allocate enough robot units to support the maximum number of machines.

  Note: Instead of adding more robot units, we recommend reducing the maximum number of VMs in the pool.
• A job running on a machine that does not have enough RUs generates the following alert "No VMs in <Pool_name> due to insufficient robot units."
• As soon as enough robot units become available, they are automatically consumed.
• If you have multiple pools in an overconsumption state, we allocate any available robot units to the last created pool subsets.

Example: You have five pools, each having a maximum of three machines, totaling 15 machines. Your RUs can support two machines, meaning all five pools are now in an overconsumption state, so you cannot use them.

• You add the required RUs to support five more machines. Now, you can use a total of seven machines.
• Two pools become available and they consume RUs for six machines (two pools of three machines each).
• Three pools remain in the overconsumption state, and the available RUs serve one machine. Therefore, the two pools are created last.

Releasing and reusing Robot Units

Once automatic pools are created, the allocated RUs are consumed based on their monthly distribution. Automatic renewal applies if RUs are available.

When a VM is deleted from a manual pool, or when an automatic pool is deleted, the corresponding RUs are released in the following 24 hours.

• For the remaining of the current contract month, you can reuse the released RUs in the same tenant.

• For the following months, remaining RUs can be used across tenants.

For example, you aquired a bundle of 72,000 RUs for one-year contract, which starts on January 1st and ends on December 31st. The following timeline enfolds:

• January 1st - you create VM1 in tenant T1, which consumes 6000 RUs.

• January 15th - you delete VM1 from tenant T1.

• January 16th - the 6000 RUs are released and you can reuse them to create VM2 in the same tenant T1.

• February 1st - you keep the same VM2 running in tenant T1, and this consumes another 6000 RUs from your bundle, based on the monthly distribution. You are left with 60,000 RUs (72,000 minus 6000 for January and 6000 for February).

• February 15th - you keep the same VM2 in tenant T1, but you create two more VMs in two different tenants, T2 and T3. This consumes 12,000 RUs from the remaining 60,000: one for the VM in tenant T2, and one for the VM in tenant T3. You are left now with 48,000 RUs.

Domain-joined Machines

To avoid managing different accounts on each VM, and to use a single set of credentials for authentication, you can join your VMs to a domain. This way you can integrate your machines with an existing identity infrastructure, and your cloud robots can run jobs under a domain user.

Note:

If you have domain-joined VMs, you cannot take a snapshot of those custom images.

There are three mainly used identity solutions, summarized in the following table, along with the corresponding domain connection approach and the current availability in UiPath:

Identity solution	Availability in UiPath	Connection to the domain
Active Directory Domain Services (AD DS) (*)	Available	via site-to-site VPN Gateway
Azure Active Directory Domain Services (Azure AD DS) (*)	Available	via site-to-site VPN Gateway
Azure Active Directory	Available	via a Windows Desktop machine See how you can set up a machine that runs Windows Desktop (step 9).

(*) [Preview capability] Active Directory Domain Services (on-prem AD) and Azure Active Directory Domain Services (Azure AD DS) support automatic domain join of the machines in the pool (see step 17 in the Creating the Cloud Robot pool procedure)

Active Directory Domain Services (AD DS)

Use this solution to manage identity and access in on-premises environments.

AD DS allows your cloud robots to authenticate and access on-premises network resources via on-premises domain controllers. The site-to-site connection to the domain controller is established through the VPN Gateway service. You continue to maintain all of the associated infrastructure and directory components.

Note: To integrate your on-premises Active Directory with Azure, connect your on-premises environment to an Azure AD domain in the cloud via site-to-site VPN Gateway.

Read the Azure documentation for more details.

Azure Active Directory Domain Services (Azure AD DS)

Use this solution to manage domain services such as domain join, group policy, LDAP, or Kerberos/NTLM authentication, the same as you would use for an on-premises Active Directory.

Azure AD DS allows your Automation Cloud robots to authenticate and access cloud network resources via Azure AD DS managed domains. Additionally, you can join and manage VMs in Azure. The site-to-site connection to the Azure AD DS managed domains is established through the VPN Gateway service.

You do not need to deploy or maintain the AD DS infrastructure for components such as VMs, Windows servers, or domain controllers.

To join an Automation Cloud Robot - VM to an Azure AD DS managed domain:

Note: The following procedure is the same for connecting a computer to an on-premises AD DS domain.

1. Sign in to your VM.
2. Access Server Manager.

3. On the left-side panel of the Server Manager, select Local Server, then select WORKGROUP.

   
   

   

   
   
4. In the System Properties > Computer Name tab, click Change. The Computer Name/Domain Changes window opens.
5. In the Domain field, specify the name of your managed domain. For example, aaddscontoso.com.
   
   

   

   
   
6. To join the domain, provide the credentials of a user that is part of the managed domain.
   Note:

   1: The user account must exist in your managed domain or in your Azure AD tenant. During domain joining, accounts from external directories associated with your Azure AD tenant cannot authenticate correctly.

   2: Account credentials can be specified either in the UPN format, which is the recommended format, or in an SAMAccountName format. For example, user "VMadmin" in UPN format is "[e-mail]", and in SAMAccountName format is "AADDSCONTOSO\vmadmin".

7. Click OK. Wait a few seconds until the VM is joined to the managed domain. If successful, a welcome message box is displayed.
8. Restart the VM to complete the domain-join process.

Moving to another tenant region

When you move to another tenant region, the existing cloud robot pools and VMs remain in the old region.

To run cloud robot VMs in the new region, you need to:

• Create a new pool in the new region.

• For manual pools, add new VMs.

• Set up a new VPN to access resources in the new region.

Important:

VMs added to existing pools (prior to region migration) continue to operate in the original region.