Back in Part 1, we stood up a SQL Server database, Azure App Service, as well as an App Service Registration / Service Principal user to allow the distribution of Orchestrator to the Service. Let's continue.
PowerShell comes with Windows 10, but you may not have the required modules/plug-ins/components to connect to Azure.
Run PowerShell as Administrator. UIPath is still using the older
AzureRM PowerShell additions instead of the more recent
az based add-ons. This isn't too much of a concern, except to note that these don't play well with each other on the same machine.
- Run PowerShell as Administrator
- Check your release of PowerShell with
$PSVersionTable.PSVersion. you'll need to be at least in PowerShell 6.0 to install the AzureRM components.
- Install the AzureRM PowerShell component with
Install-Module -Name AzureRM -AllowClobber. Hit A to install all modules.
- To start, you'll have to log into Azure. Force a login box with
Connect-AzureRmAccount. This will bring up a window that will allow you to sign-in with your Azure directory account, including allowing for 2FA.
UIPath PowerShell Execution
Finally we're ready to get installing. Almost. You'll need to acquire the UIPathOrchestrator.zip file from UIPath. This isn't the same download as the standard .msi bundle or the Installer.exe file that is used with local PowerShell scripts.
You can reach out to UIPath for this Azure capable file. Once you receive a link, you can decode the path structure of the UIPath downloads and pull down the same file for other published versions. UIPath doesn't provide a single download page for these objects, so I'm not going to include one here.
- Unzip the UIPathOrchestrator.zip file and you'll see a few files:
.ps1 PowerShell command here is what we're going to use to install files to the Azure AppService and load the database. The installation document for UIPath 2019.x is available at the UIPath Website. These are mostly self-explanatory, but terminology can sometimes be a challenge so let's walk through a few of the mandatory parameters:
action: Deploy or Update: We'll use Deploy here as this is a new install.
azureAccountApplicationID: This is the application (client) ID of the App Registration. Found at App registrations --> App registration name --> Application (client) ID. This is a UUID.
azureAccountPassword: Not really a "password". This is value of the Client Secret that was created in the App Registration step of Part 1. If you did not capture it, you can delete the existing secret and create another for use here.
azureSubscriptionID: the UUID of the Subscription. Found at Subscriptions --> Subscription Name --> Subscription ID. This is a UUID.
azureTenantID: The UUID of the overall Azure tenant. The tenant is your account, basically. This is available under Tenant Properties in Azure (search for Tenant Properties), in a field called "Directory ID".
appServiceName: The name of the defined AppService from Part 1. In this example, we created app-internal-orch-dev-002.
resourceGroupName: Name of the Resource Group that will contain this AppService.
hostAdminPassword: Required for fresh Deployments. This is the password that will be used the host administrator of Orchestrator. Passwords need to be at least 8 characters and one lowercase character and one digit.
I've had really mixed results on complicated passwords injected via this script. My recommendation is to keep it simple, such as
12345qwert in the script, then after completion, login and modify the admin password via the browser to allow Orchestrator to accept the password and use its own syntax checking.
defaultTenantAdminPassword: Also required for fresh Deployments. Same password requirements as hostAdminPassword, so make it the same password as
package: The directory path to the UIPath Web.zip file. This file is in the same directory as the zip, so
nugetRepositoryType: There's more here to unpack, but for this simple scenario, we'll chose
Legacy to create a local repository on the filesystem.
unattended: include a flag to force an unattended installation.
verbose: include a flag for more output via the terminal.
stopApplicationBeforePublish: Ensure the AppService is stopped before we publish this package.
We are also not connecting to an ElasticSearch instance or connecting to an Azure Storage Blog for NuGet storage for this simple example. These options are defined on the UIPath documentation page.
Whew! We're almost there.
Here's what our script looks like for our single node, simple install on App Service:
-action "Deploy" `
-package ".\UiPath.Orchestrator.Web.zip" `
-azureSubscriptionId "d94d33c4-2ee6-4cd5-ab5d-6f243a1eb133" `
-azureAccountTenantId "a66a09ca-a9a3-4d8b-8538-d72476dc7ded" `
-azureAccountApplicationId "0d065ffa-e311-41f6-96c5-9f238dcbfb37" `
-azureAccountPassword "nx1_6o4VnNEd43.W.~AF8l0c3423hTIheWTAF_0X" `
-resourceGroupName "rg-shared-dev-002" `
-appServiceName "app-internal-orch-dev-002" `
-hostAdminPassword "12345qwert" `
-defaultTenantAdminPassword "12345qwert" `
-nugetRepositoryType "Legacy" `
Modify these values with your own, paste this into the PowerShell window (or create a new script to execute), and run. You should see verbose updates coming, including stopping the App Service, publishing the files from the Web.zip file, and finally a connection to the database and population of the tables. You should see a result like the following:
Okay! We have a process up and running and the App Service has been restarted. Go to the URL of the App Service (that url is available on the App Service details page) and open that in your browser. It may act like it's not responding, but the Orchestrator process is finishing up some setup items. Give it a minute or two and you should be rewarded with a login screen:
We didn't discuss utilizing a custom domain and SSL certificate, but this is pretty straight forward and can be done after install. Modify that information per this Microsoft article.
Try logging in with the Default tenant, user `Admin` and the simple password you created for
defaultTenantAdminPassword, and bam!
A bit complicated in documentation, but once laid out is pretty straight forward. Obviously, we're only capturing a very simple scenario, but if this is your first go at a more complex App Service deployment, I hope this was helpful.
Next up will be a more complicated example with multiple Orchestrator services, Redis, Azure Storage, SSL and other goodies that we use internally at Optezo to deliver RPA-as-a-Service for our clients.
Follow Optezo on Twitter or LinkedIn to be notified of future posts, or even better; reach out to speak with us on how you don't have to learn any of this and let Optezo deliver RPA success for your organization!