Introduction
I’ve been spending time lately doing proof of concepts with Microsoft’s Hosted RPA Bots (preview) and I absolutely love how cool these things are. I like them so much I even quoted myself to share what makes them great:
“Microsoft Hosted RPA Bots are awesome. VMs get spun up, as needed, to execute unattended jobs, which scale effortlessly, only utilize resources when you need them, and keep you out of the business of managing virtual machines.”
Me (Matt Jimison)
Now, while they’re inevitably very cool, there’s one caveat to them; since you’re not managing virtual machines, you’re likely going to be using a default VM image that may not have everything you want and/or need on it. If you do find yourself with a use case where there’s a lot you need to change about the image utilized, have no fear, as custom VM images are available, and will allow you to setup your image exactly how you need it.
Having said that, if you only need a little customization, such as installing PowerShell modules, going the custom image route may seem like a lot of unnecessary work, and that’s exactly what this article is here to do: to help you avoid having to go that route. Specifically, we are going to cover how you can make additional modules available to you when utilizing the “Run PowerShell Script” activity in Power Automate Desktop.
The Details
There’s secret sauce below in the code, which I hope will save you countless hours (assuming you found this post relatively soon after choosing to venture down this path). Also, keep in mind that since these machines spin up as needed, essentially resetting back to the default VM image whenever one is spun (back) up, you can’t count on a module always being installed just because a job ran once, so we’re going to put some additional logic in here to make sure it’s not already available before going the route of installing it (again).
Specifically, there are 3 things you’re going to need to do to install a module that you can utilize in the “Run PowerShell Script” activity, which runs in the background, and can’t rely on any user input to ensure it progresses.
- You need to install NuGet (scoped to the current user). At this time the base VM image doesn’t have it, and without it, you’re going nowhere fast. If you try and do Step 2 before this one, you’ll even see an error stating that we need a minimum version of 2.8.5.201, so we’ll specify that as well when installing.
- You need to set the PSGallery as trusted, because the script running in the background can’t ask a user if they agree to utilize an “untrusted” source.
- When installing your module (scoped to the current user), you’ll want to decorate it with many fail safes, including turning off confirmation, turning off warnings about multiple versions (clobbering), and turning off warnings about potential installation conflicts (force).
Just in case this particular VM has already been spun up, and has the module available, however, we want to make sure we’re not wasteful in needlessly installing things again, so we’ll do a check first to see if it’s already available, and will only follow the previous 3 steps when it isn’t.
The Code To Make it Work
if ((Get-Module -Name 'Az.Storage' -ListAvailable) -eq $null) {
Install-PackageProvider -Name "NuGet" -MinimumVersion "2.8.5.201" -Scope CurrentUser -Force > $null
Set-PSRepository -Name "PSGallery" -InstallationPolicy Trusted > $null
Install-Module -Name 'Az.Storage' -Confirm:$false -Force -AllowClobber -Scope CurrentUser > $null
}
…and that’s it! While my example is installing ‘Az.Storage’, you can quickly adapt this code to install whatever module(s) you need (if you need to install multiple modules you still only do need to steps 1 and 2 once and then repeat step 3 as needed). You can also feel free to omit the > $null statements at the end of each line – I just like to suppress unnecessary information when running a script.
As always, I hope you’ve found this post helpful and have a great day!
Cheers,
Matt
