To help administrators or those of the DevOps persuasion better manage and automate core tasks involving the Power Platform, Microsoft has released two PowerShell modules that you can leverage - Microsoft.PowerApps.Administration.PowerShell and Microsoft.PowerApps.PowerShell. Using these, you can accomplish tasks such as:
- Getting details about each environment within your tenant or even doing things such as changing their name.
- Managing the various apps deployed to an environment - to the point where you can remove them entirely if desired.
- Administrating your Power Automate flows. You can enable or disable them or even modify their permissions.
- Work with advanced components such as connectors, their permissions and URL patterns for a DLP policy.
Many of these operations are available within the relevant area within Power Apps, Power Automate or the Power Platform Admin Center, meaning that you don’t necessarily need to turn to PowerShell as your tool of preference. However, if you’re looking to, say, call these operations as part of an Azure DevOps task or any custom scripts your author, the set of cmdlets on offer will start to become a real boon to you.
Installation is pretty straightforward, as this article attests to. But if you attempt this using PowerShell 7 and run the Add-PowerAppsAccount cmdlet to start working with your tenant, you will get an error similar to the below.
In my fruitless search online, I found some posts from people experiencing the same issue and others with solutions that didn’t work. In the end, the answer turned out to be surprisingly simple - use PowerShell 5 instead. And as we can see below, gets this cmdlet working all fine and dandy:
To add insult to injury, a quick check back to the requirements of the modules confirms this basic fact and also my complete inability to read simple instructions 😅:
The modules described in this document, use .NET Framework. This makes it incompatible with PowerShell 6.0 and later, which uses .NET Core.
A huge thank you to Raphael Pothin for pointing me in the right direction on this one - in retrospect, this was a pretty significant thing to overlook, but perhaps I was hoping too much that these tools would work on PowerShell 7. Hopefully, we may see future support for this, given the inherent advantages that .NET Core has from a cross-platform perspective.