PowerShell Web Access: Is It Practical ?

PowerShell Web Access (PSWA) let administrators run PowerShell remotely from any browser, without needing a VPN. The feature was introduced in Windows Server 2012 and lived in the shadow of Remote Desktop Services for almost a decade. Microsoft has since deprecated PSWA — it’s no longer included in Windows Server 2025, and current guidance points to better alternatives.

This guide covers: what PSWA was, why it was deprecated, and what to use instead in 2026. If you still have a PSWA install running somewhere, this is your migration plan.

What PSWA actually did

PSWA was a Windows Server role that exposed PowerShell through a web interface over HTTPS. An admin could open https://pswa-server/pswa, sign in with Kerberos, and get a fully interactive PowerShell console in their browser — running on a remote server, piping results back in real time.

The typical setup:

# Install the PSWA role
Install-WindowsFeature -Name WindowsPowerShellWebAccess -IncludeManagementTools

# Configure with self-signed cert (lab only)
Install-PswaWebApplication -UseTestCertificate

# Grant one user access to localhost
Add-PswaAuthorizationRule `
  -UserName contosoadmin `
  -ComputerName localhost `
  -ConfigurationName Microsoft.PowerShell

It worked, but required IIS, per-user authorization rules, and Kerberos delegation for anything beyond localhost. Configuration drift was common.

Why Microsoft deprecated it

• Modern cloud-first management made the on-prem proxy less relevant. Azure Arc, Azure Automation, and Intune cover most “manage servers without a VPN” needs.
• Security posture. A public-facing admin interface is a large attack surface — credential stuffing against PSWA portals was a real threat.
• Kerberos double-hop configuration was fragile. If you ever spent a Saturday afternoon troubleshooting delegation, you know.
• Better alternatives exist now (see below).

What to use instead in 2026

Migrating off PSWA in practice

For a typical SMB that still runs PSWA, the migration is straightforward. Install Azure Arc on the servers you currently reach via PSWA, then run commands through Azure Cloud Shell:

# On each on-prem server: install the Azure Arc agent
# (Generated from Azure portal; paste as admin)
$wc = New-Object Net.WebClient
$wc.DownloadFile("https://aka.ms/AzureConnectedMachineAgent", "$env:TEMPAzureConnectedMachineAgent.msi")
msiexec /i "$env:TEMPAzureConnectedMachineAgent.msi" /qn

# Connect to Azure
& "$env:ProgramFilesAzureConnectedMachineAgentazcmagent.exe" connect `
  --resource-group "arc-servers" --tenant-id <tenant> --subscription-id <sub> --location westeurope

# From then on, run commands from anywhere via Cloud Shell:
Invoke-AzVMRunCommand -ResourceGroupName arc-servers `
  -VMName server01 -CommandId RunPowerShellScript -ScriptPath .script.ps1

You get browser access to PowerShell on your on-prem server, with MFA-enforced Entra ID auth, full audit logs in Azure Monitor, and no public-facing admin portal.

Wintive take: security considerations

• If you still have PSWA running, inventory it now. Check Get-WindowsFeature WindowsPowerShellWebAccess on every server. Most SMBs forget they had it installed during a long-ago lab test.
• Firewall audit. PSWA typically listens on port 443 or 8443. Any public-facing listener on those ports should be reviewed.
• Azure Arc isn’t free, but for most SMBs the Defender for Servers Plan 2 cost (~$10/server/month) is justified by the security posture improvement alone.

Conclusion

PSWA was a useful tool in its day. In 2026 it’s a liability: unmaintained code, public attack surface, and covered by better native alternatives. If you still have it in production, your migration path is Azure Arc + Cloud Shell — typically one afternoon of work per server.

Dig Deeper