How to Set Up PowerShell Web Access on Windows Server 2012 R2

How to Set Up PowerShell Web Access on Windows Server 2012 R2

PowerShell Web Access (PSWA) is a Windows Server feature introduced in Windows Server 2012 that provides a web-based PowerShell console accessible from any modern browser. It allows administrators to connect to and manage remote Windows servers without requiring PowerShell to be installed on the management workstation, and without needing a VPN or direct network access to WinRM ports on target servers. The web gateway acts as an intermediary, forwarding PowerShell commands and results between the browser and target machines.

This is particularly valuable for managing servers from locked-down client machines, mobile devices on corporate networks, or through jump hosts in segmented network architectures. Windows Server 2012 R2 includes PSWA as a built-in server role feature, and this guide covers the complete installation, configuration, SSL setup, authorization rules, and security hardening required for a production deployment.

Prerequisites

– Windows Server 2012 R2 designated as the PSWA gateway server
– Internet Information Services (IIS) will be installed automatically
– A valid SSL certificate (or self-signed for testing) for the gateway server
– Administrative credentials on the gateway server
– Target servers must have PowerShell Remoting enabled (WinRM configured)
– Network connectivity from the gateway to target servers on port 5985 or 5986
– DNS resolution working between gateway and target servers
– PowerShell 4.0 (included with WS2012 R2)

Step 1: Install the PowerShell Web Access Feature

Open PowerShell as Administrator on the server that will serve as the PSWA gateway. Install the Windows PowerShell Web Access feature, which automatically installs IIS as a dependency:

Install-WindowsFeature WindowsPowerShellWebAccess -IncludeManagementTools

Verify the installation completed successfully:

Get-WindowsFeature WindowsPowerShellWebAccess | Select-Object Name, InstallState, DisplayName

The output should show InstallState : Installed. The installation adds the IIS role with the required modules and creates the foundation for the web application.

Step 2: Configure the PSWA Web Application

After installation, configure the web application within IIS. There are two approaches: using an existing SSL certificate or generating a self-signed certificate for testing. For production environments, always use a certificate issued by a trusted Certificate Authority.

Option A — Install with a test certificate (development/lab only):

Install-PswaWebApplication -UseTestCertificate

Option B — Install using an existing SSL certificate by thumbprint:

# First, find the certificate thumbprint
Get-ChildItem -Path cert:LocalMachineMy | Select-Object Subject, Thumbprint, NotAfter

# Install PSWA using the specific certificate
Install-PswaWebApplication -WebApplicationName "pswa" -UseTestCertificate:$false
# Then bind the certificate to IIS (see Step 3)

The Install-PswaWebApplication cmdlet creates a new IIS web application named “pswa” under the Default Web Site, configures the necessary application pool, and sets the required permissions.

Step 3: Configure IIS SSL Binding

PSWA requires HTTPS. The test certificate option handles this automatically, but for production you must manually bind your SSL certificate to the IIS site. First, import your certificate into the Local Machine certificate store if not already present:

# Import a PFX certificate
$password = ConvertTo-SecureString -String "CertPassword123!" -AsPlainText -Force
Import-PfxCertificate -FilePath "C:Certsgateway.pfx" -CertStoreLocation "cert:LocalMachineMy" -Password $password

Bind the certificate to HTTPS port 443 in IIS using the WebAdministration module:

Import-Module WebAdministration

$thumbprint = (Get-ChildItem cert:LocalMachineMy | Where-Object Subject -like "*gateway*").Thumbprint

# Remove existing HTTPS binding if present
Remove-WebBinding -Name "Default Web Site" -Protocol https -Port 443 -ErrorAction SilentlyContinue

# Create new binding with certificate
New-WebBinding -Name "Default Web Site" -Protocol https -Port 443 -IPAddress "*"

# Assign the certificate to the binding
$binding = Get-WebBinding -Name "Default Web Site" -Protocol https
$binding.AddSslCertificate($thumbprint, "my")

Step 4: Add PSWA Authorization Rules

PSWA uses authorization rules to control which users can connect to which target computers using which session configurations. Without authorization rules, no one can log in — this is a deliberate security-first design. Add rules using the Add-PswaAuthorizationRule cmdlet.

Grant a specific user access to a specific server using the default session configuration:

Add-PswaAuthorizationRule -UserName "DOMAINAdminUser" -ComputerName "Server01" -ConfigurationName "Microsoft.PowerShell"

Grant a domain group access to all computers using any session configuration:

Add-PswaAuthorizationRule -UserGroupName "DOMAINServerAdmins" -ComputerName "*" -ConfigurationName "*"

Grant a user access to a computer group defined in a text file:

Add-PswaAuthorizationRule -UserName "DOMAINHelpDeskUser" -ComputerName "WebServer01","WebServer02","WebServer03" -ConfigurationName "Microsoft.PowerShell.Restricted"

List all current authorization rules:

Get-PswaAuthorizationRule | Format-Table RuleName, UserName, ComputerName, ConfigurationName -AutoSize

Step 5: Verify IIS Configuration

Verify the PSWA application is correctly configured in IIS:

Import-Module WebAdministration
Get-WebApplication -Site "Default Web Site" | Select-Object path, applicationPool, PhysicalPath

Check that the application pool for PSWA is running:

Get-WebConfigurationProperty -Filter "system.applicationHost/applicationPools/add[@name='pswa']" -Name processModel

Verify the IIS service is started and set to automatic startup:

Get-Service W3SVC | Select-Object Name, Status, StartType
Set-Service W3SVC -StartupType Automatic
Start-Service W3SVC

Step 6: Configure Firewall Rules for PSWA

The PSWA gateway needs HTTPS traffic allowed inbound from users’ browsers. The gateway server also needs outbound WinRM access to target servers:

# Allow HTTPS inbound for browser clients
New-NetFirewallRule -DisplayName "PSWA HTTPS Inbound" -Direction Inbound -Protocol TCP -LocalPort 443 -Action Allow -Profile Domain,Private

# Allow WinRM outbound to target servers (if host firewall is restrictive)
New-NetFirewallRule -DisplayName "WinRM Outbound to Targets" -Direction Outbound -Protocol TCP -RemotePort 5985,5986 -Action Allow

Step 7: Test the PSWA Interface

Open a web browser and navigate to the PSWA URL. If accessing from the gateway server itself:

https://localhost/pswa

From a remote machine, use the gateway server’s hostname or IP address:

https://PSWAGateway.domain.com/pswa

The login page presents three fields: User Name, Password, and Connection Settings. In the Connection Settings area, enter the target computer name or IP address, and optionally specify a port and session configuration name. After authenticating, you will have a full PowerShell session in the browser window.

Step 8: Managing Authorization Rules

Regularly review and audit authorization rules. Remove rules that are no longer needed:

# List all rules with IDs
Get-PswaAuthorizationRule | Select-Object Id, RuleName, UserName, ComputerName

# Remove a specific rule by ID
Remove-PswaAuthorizationRule -Id 3

# Remove a rule by name
Remove-PswaAuthorizationRule -Name "Rule01"

Test whether a specific user would be authorized to connect to a target computer:

Test-PswaAuthorizationRule -UserName "DOMAINAdminUser" -ComputerName "Server01" -ConfigurationName "Microsoft.PowerShell"

Step 9: Configure Session Timeouts and Limits

PSWA sessions can consume significant server resources if left open. Configure timeouts in the web.config file to automatically terminate idle sessions. Locate the web.config file for the PSWA application:

# Typical location
notepad "C:WindowsWebPowerShellWebAccesswwwrootweb.config"

Within the web.config, modify the session timeout value (in minutes) in the system.web/sessionState element. You can also configure this via PowerShell using the WebAdministration module:

Set-WebConfigurationProperty -PSPath "IIS:SitesDefault Web Sitepswa" `
    -Filter "system.web/sessionState" `
    -Name "timeout" `
    -Value "00:20:00"

Step 10: Security Hardening for PSWA

Apply security hardening measures to reduce the attack surface of the PSWA deployment. Disable the test certificate and ensure only trusted CAs are accepted. Restrict access to the PSWA URL by IP address using IIS IP Address restrictions:

# Add IP address restriction - allow only admin subnet
Add-WebConfigurationProperty -PSPath "IIS:SitesDefault Web Sitepswa" `
    -Filter "system.webServer/security/ipSecurity" `
    -Name "." `
    -Value @{ipAddress="10.0.1.0"; subnetMask="255.255.255.0"; allowed="true"}

# Set default to deny
Set-WebConfigurationProperty -PSPath "IIS:SitesDefault Web Sitepswa" `
    -Filter "system.webServer/security/ipSecurity" `
    -Name "allowUnlisted" `
    -Value "false"

Enable IIS logging to capture all authentication attempts and sessions:

Set-WebConfigurationProperty -PSPath "IIS:" -Filter "system.applicationHost/sites/site[@name='Default Web Site']/logFile" -Name "enabled" -Value "true"

Troubleshooting Common Issues

If users cannot log in, verify authorization rules first:

Test-PswaAuthorizationRule -UserName "DOMAINUser" -ComputerName "Server01" -ConfigurationName "Microsoft.PowerShell" -Verbose

Check IIS logs for HTTP errors:

Get-Content "C:inetpublogsLogFilesW3SVC1*.log" -Tail 50 | Where-Object { $_ -match " 40[0-9] | 50[0-9] " }

Verify the PSWA application pool identity has access to connect outbound:

Get-WebConfiguration "system.applicationHost/applicationPools/add[@name='pswa']" | Select-Object processModel

Summary

PowerShell Web Access on Windows Server 2012 R2 delivers browser-based PowerShell management without requiring client-side software installation. By installing the feature, configuring HTTPS with a trusted SSL certificate, establishing granular authorization rules, and applying appropriate security hardening, organizations can provide secure remote management access through web browsers alone. The authorization rule system provides excellent access control, allowing administrators to grant users access only to specific servers and session configurations that match their job function. Combined with IP address restrictions and session timeouts, PSWA becomes a secure and auditable management gateway suitable for enterprise production environments.