Undocumented Mandatory Parameters in new Azure Deployment Script

Feedback Orchestrator
1

There are quite a few mandatory parameters that are required to execute the Publish-Orchestrator.ps1 PowerShell script that are not mentioned in the documentation… I’ve submitted an “edit suggestions” to the docs but for those of your that are curios, the following parameters must be included to execute the script:

[Parameter(Mandatory = $true)]
[string] $azureAccountApplicationId,

[Parameter(Mandatory = $true)]
[string] $azureAccountPassword,

[Parameter(Mandatory = $true)]
[string] $azureSubscriptionId,

[Parameter(Mandatory = $true)]
[string] $azureAccountTenantId,

[Parameter(Mandatory = $true)]
[string] $resourceGroupName,

[Parameter(Mandatory = $true)]
[string] $appServiceName,
2

Hey there! This page was created in the meantime - Orchestrator Script to describe all parameters, and also contains a few examples for single and multi-node scenarios.

Let us know what you think! And thanks for the feedback! Always welcomed! :smiling_face_with_three_hearts:

1 Like
3

The update script prompts for these values even if they are provided as part of the commandlet’s parameters.

Additionally, it should be mentioned in the documentation that the App Registration (service principle) that is used for the update requires the contributor" role on the subscription in which the app service resides. For most enterprises, this may be a touch pill to swallow. As you are granting a single principle the ability to change anything in a subscription. It would be better to require contribute on the resource group, or better yet, only the app service used for the orchestrator.

1 Like
4

Thanks for your suggestion. I merged the edits now.
In the future, there is a pretty cute :smiley: Suggest Edits button in the docs that enables you to send your edits directly in the page, in any page :scream:. Feel free to abuse it! (pretty pleaseeee)
I sent the feedback to our PMs regarding the permissions required for this type of installation. Thanks again! :grin:

5

I was incorrect above. If you provide the parameters you are not prompted. This was some issue with my IDE.

Here is an example of a working update script.

./Publish-Orchestrator.ps1 -action Update
-package “{path to the UiPath.Orchestrator.Web.zip file}” -azureAccountApplicationId "{ID GUID for the UiPath App Registration in Azure Active Directory}"
-azureAccountPassword “{the client secret of the Azure App registration}” -azureSubscriptionId "{Azure subscription ID GUID}"
-azureAccountTenantId “Azure tenant ID GUID” -resourceGroupName "{Resource group name in which the UiPath App service is deployed.}"
-appServiceName “{Name of the app service into which the UiPath orchestrator code is deployed.}” -packagesApiKey "{API KEY from Azure Publish Parameters}"
-activitiesApiKey “{Activities KEY from Azure Publish Parameters}”

Additional Notes:

As mentioned, the app registration referenced in the update script will need contribute permissions on the subscription in which the app service is deployed.

ALSO:

The SQL login in the web.config must have permission to make schema changes in the UiPath database BUT ALSO have permissions to the Master database. Otherwise, you will encounter a login error during the “database migrations” step.

6

The update script will prompt you to provide the -activitiesApiKey and the -packagesApiKey if they are not present in the orchestrator’s web.config file.

7

It turns out that it is impossible to preserve existing packages when upgrading using the Azure deployment script for version 19.10.16. This is true despite indications in the documentation that you can use combinations of:

-nugetRepositoryType
-storeageLocation
-storageType

to retain all the packages you’ve uploaded. However, there is a workaround.
You can make a change the web.config, after the update is complete, that redirects the orchestrator to the legacy packages path.

CHANGE 1:
Locate the web.config element
 <add key="NuGet.Repository.Type" value="Composite" />

Change the element to 
<add key="NuGet.Repository.Type" value="Legacy" />

CHANGE 2:
Locate the web.config element
<add key="Storage.Location" value="RootPath=.\Storage" />

Change the element to :
<add key="Storage.Location" value="RootPath=.\NugetPackages" />

The downside of this workaround is that you may not get the improved performance of the package search feature. But if you have a mature environment with dozens or hundreds of packages, libraries, and custom activities this is a small price to pay for a seamless update.