We've built an enterprise Microsoft Teams application, but setup currently requires an administrator to copy a PowerShell script, open PowerShell, and run it manually. We'd like to provide a smoother experience, ideally with a button in our Azure-hosted web dashboard. However, not every customer has an Azure subscription, so some administrators still need to run the script locally. Is there a secure way for a browser action to trigger a local PowerShell script, or should we package and deploy the application differently?
5 Answers
The professional approach is to package the installation as an MSI or another supported application installer, then let each customer deploy it through their existing management system. Common options include Intune and Company Portal, Group Policy, Configuration Manager, or an RMM platform. If the script changes Teams configuration rather than the endpoint itself, check whether it can be replaced with deployment through the Teams admin center or the app’s manifest.
PowerShell Universal or a similar automation dashboard can provide a controlled web interface for running scripts, but it is mainly useful when you manage the infrastructure where the scripts execute. It does not make it safe or appropriate for an external customer’s browser to launch arbitrary commands on their personal or corporate workstation.
A normal browser should not be able to launch arbitrary PowerShell on the local machine. If it could, any malicious or compromised website could execute code with the user’s privileges, and possibly administrative rights. That behavior would be treated as a serious security vulnerability, not a feature.
If the script must run on customer endpoints, provide a properly signed installer or a documented administrator-run command instead of asking users to paste code into PowerShell. An MSI gives enterprise administrators something they can audit, approve, roll back, and distribute through their normal software deployment process.
A browser button can call your backend, but that only triggers work on the server. To reach a customer’s machine, you would need an intentionally installed and authenticated agent or service, with tightly scoped permissions and auditing. That is essentially an endpoint-management product, so it’s usually better to integrate with Intune, an RMM tool, or another deployment system rather than build a hidden browser-to-PowerShell bridge.
That makes sense. The application is hosted in Azure, but some customers don’t use Azure, which is why we were looking for a local alternative to the Azure terminal.