2021.10.4
Release date: 7 April 2022
After some recent back and forth in the area of queue triggers, we are readdressing the way queue triggers launch jobs with - what we hope to be the final and best - implementation of them all.
Problem statement: Whenever your queues contained fewer new items than items in progress, no jobs were launched despite robots being idle. This happened because the number of running jobs (actively processing queue items) would exceed the number of target jobs (jobs needed to process the new items).
Initial fix: Orchestrator accounted for both new and in-progress queue items when computing the number of target jobs, instead of only new items. Sounded good. Didn't work.
Brand new, shiny fix: Orchestrator accounts for new items when computing the number of target jobs, but looks at the number of pending jobs when deciding whether to launch a new job or not.
- Say you have 2 new items in a queue, and 2 pending jobs exist => then no new jobs are launched.
- Say you have 2 new items, and 1 pending job exists => then 1 new job is launched.
This ensures Orchestrator launches enough jobs to process all new items without going overboard.
We once again come bearing gifts for those of you who installed Orchestrator on an Azure VM or Azure App Service: we now offer support for Azure AD. You can use this authentication method to connect Orchestrator to SQL Server. For details, see our documentation.
-
We know your Ledger database tables can get quite crowded, thus requiring frequent cleanup. For this, we provide you a new cleanup script, allowing you to delete Ledger data every 7 days and to apply a batch size of 1,000 entries. Discover the new script in our documentation:
- standalone Orchestrator installation
- Automation Suite installation
- The Platform Configuration Tool no longer verifies the certificate host name when upgrading from a version prior to 2020.4. This change is due to the check not being applicable in this upgrade scenario.
- When upgrading Orchestrator, you are now prompted with a warning if an Insights version older than 2021.10 is enabled. This message is meant to remind you that Insights hardware requirements changed significantly starting with version 2021.10. Before an Orchestrator upgrade, you must ensure you meet the new Insights requirements.
-
As a host, trying to end a maintenance window through Swagger UI may fail. This happens because Swagger UI uses cookies for authentication, which are lost when you close the browser.
To end the maintenance mode via API, use one of the following workarounds:
- Do not close the browser and make the POST request to
/api/Maintenance/Endfrom the Swagger UI. -
Use an API testing application (for example, Postman) to:
-
retrieve an access token by exchanging your credentials to the
/api.Account/Authenticateendpoint, and then -
make a POST request to the
/api/Maintenance/Endendpoint using theAuthorization: Bearer {access_token}header.
-
-
Run the following PowerShell script:
- Do not close the browser and make the POST request to
$orchestratorUrl="https://localhost:6234"
$hostTenant="host"
$hostUser="admin"
$hostPassword=""
$tenantId="" #number
# Authenticate
$body=@{
"tenancyName"="$hostTenant";
"usernameOrEmailAddress"="$hostUser";
"password"="$hostPassword"
}
$response = Invoke-WebRequest -Uri "$orchestratorUrl/api/account/authenticate" -Method Post -Body ($body | ConvertTo-Json) -ContentType "application/json"
$token = "Bearer " + ($response | ConvertFrom-Json).result
# End maintenance mode
$headers=@{
"Authorization"="$token"
}
$res = Invoke-WebRequest -Uri "$orchestratorUrl/api/maintenance/end?tenantId=$tenantId" -Headers $headers -Method Post -ContentType "application/json" -ErrorAction Stop
if ($res -and ($res.StatusCode -eq 200)) {
Write-Host "Maintenance mode ended successfully for tenant $tenantId"
}$orchestratorUrl="https://localhost:6234"
$hostTenant="host"
$hostUser="admin"
$hostPassword=""
$tenantId="" #number
# Authenticate
$body=@{
"tenancyName"="$hostTenant";
"usernameOrEmailAddress"="$hostUser";
"password"="$hostPassword"
}
$response = Invoke-WebRequest -Uri "$orchestratorUrl/api/account/authenticate" -Method Post -Body ($body | ConvertTo-Json) -ContentType "application/json"
$token = "Bearer " + ($response | ConvertFrom-Json).result
# End maintenance mode
$headers=@{
"Authorization"="$token"
}
$res = Invoke-WebRequest -Uri "$orchestratorUrl/api/maintenance/end?tenantId=$tenantId" -Headers $headers -Method Post -ContentType "application/json" -ErrorAction Stop
if ($res -and ($res.StatusCode -eq 200)) {
Write-Host "Maintenance mode ended successfully for tenant $tenantId"
}-
An issue was fixed that would allow an attacker with privileged access to a robot to retrieve the LicenseKey (MachineKey) of other robots within the same tenant by brute forcing API calls to Orchestrator. This would theoretically allow the attacker to access resources restricted only to that robot.
Read the security advisory for UiPath - Robot Account Takeover.
- Occasionally, job executions of long running workflows would get stuck in a Running state without being transitioned to a Suspended state. Upon killing those jobs, the jobs transitioned to and got stuck in a Terminating state. The underlying issue has been fixed and long running jobs are now transitioned to the different states as expected and are executed without issues.
- We made a typo on the Assign roles to a robot account window. Instead of Search for a robot account, the field said Seach for a robot account. The field name is now spelled correctly.
- The names of manually uploaded packages were not displayed in the audit details. This issue affected packages uploaded both individually and in bulk. Now, the names of all uploaded packages are successfully logged in the audit details.
- Users who did not have a Surname specified in Active Directory could not log in.
- Credential asset
retrieval failed for CyberArk credential store when setting
Plugins.SecureStores.CyberArk.UsePowerShellCLItotruein Orchestrator'sUiPath.Orchestrator.dll.configfile. - When the
Orchestrator and Identity databases used Turkish-specific collation, upgrades from
version 2020.10 to 2021.10 failed. When opting for Latin1-based SQL collation, the
same behavior occurred if Turkish (
tr-tr) culture was used on the application server. To fix this issue, switch toen-usculture and re-attempt the installation.
