Hosting

Various hosting methods for PowerShell Universal.

You can host PowerShell Universal as a Windows Service, in IIS, as a Azure Web App or just as a stand alone application. If you are running on Windows, we suggest either a Windows Service or IIS.

Hosting as a Windows Service

To host as a Windows Service, you can download and install the PowerShell Universal MSI. The MSI will automatically install the PowerShell Universal service and start it. Jobs will run under the system account by default but you can configure the service to run under another account after installation.

After the MSI has finished setup, your default web browser will open to http://localhost:5000 for login. The default login credentials are set to Admin and any password.

Configuring a Windows Service Manually

You do not need to use the MSI to configure Universal as a Windows Service. You can also do it manually with the following PowerShell script.

New-Service -Name "PowerShellUniversal" -BinaryPathName "Universal.Server.exe --service" -Description "PowerShell Universal server service." -DisplayName "PowerShell Universal" -StartupType Automatic
Start-Service PowerShellUniversal

Hosting in Azure

Read our Azure hosting guide.

Hosting Manually

You can also host the Universal server as a stand alone application. Simply run the Universal.Server.exe from the binary directory to utilize the Kestrel web server implementation in ASP.NET Core to start the web server.

Web Server Configuration

This section applies to Universal when it is hosted outside of IIS.

Setting the Port and Listening Address

You can set the port of the Universal server by modifying the appsettings.json file. We recommend that you create an appsettings.json file in the default configuration folder.

Windows

%ProgramData%\PowerShellUniversal

Linux

%HOME%/.PowerShellUniversal

To set the port, change the Kestrel endpoints section of the appsettings.json. By default, the configuration is defined to listen on port 5000 and on any address.

    "Kestrel": {
    "Endpoints": {
      "HTTP": {
        "Url": "http://*:5000"
      }
    }
  },

Configuring HTTPS

To configure HTTPS, you can adjust the appsettings.json file to use a particular certificate and port. The below configuration uses the testCert.pfx file and testPassword and listens on port 5463.

PFX Certificates

{
  "Kestrel": {
    "Endpoints": {
       "HTTP": { "Url": "http://*:5000" },
           "HTTPS": {
              "Url": "https://*:5463",
              "Certificate": {
                  "Path": "testCert.pfx",
                  "Password": "testPassword"
              }
          }
    }
}

Certificate Store

To configure a certificate in a particular location and store, you can use a configuration such as this. When selecting the certificate by subject name, ensure you use the common name with out CN= prefix.

{
  "Kestrel": {
    "Endpoints": {
      "HTTPS": {
         "Url": "https://*:443",
           "Certificate": {
             "Subject": "windows-server.ironman.local",
             "Store": "My",
             "Location": "LocalMachine",
             "AllowInvalid": "true"
           }
      }
   }
}

Location can be either CurrentUser or LocalMachine.

Certificate Store by Thumbprint

You can use thumbprint rather than subject in version 3.4 and later.

{
  "Kestrel": {
    "Endpoints": {
      "HTTPS": {
         "Url": "https://*:443",
           "Certificate": {
             "Thumbprint": "SDFSDFSDFSDFSDFSDFSDFFSD",
             "Store": "My",
             "Location": "LocalMachine",
             "AllowInvalid": "true"
            }
         }
      }
   }
}

PEM And Key Certificates

Some providers, like Let's Encrypt and GoDaddy, will issue certificates as PEM and key text files. You can use these types of certificates directly with the Kestrel web server. You will need to specify the HttpsFromPem section within the Endpoints for Kestrel.

{
  "Kestrel": {
    "Endpoints": {
      "HTTP": {
        "Url": "http://*:5000"
      },
      "HttpsFromPem": {
        "Url": "https://*:5001",
        "Certificate": {
          "Path": "C:\\Users\\adamr\\Desktop\\cert.pem",
          "KeyPath": "C:\\Users\\adamr\\Desktop\\key.pem"
        }
      }
    },
    "RedirectToHttps": "true"
  },
}

Permissions

On Windows, the user running the PowerShell Universal service will need access to the certificate in order to properly provide HTTPS support. This is typically an issue if the service uses a Group Managed Service Account. You can use the following PowerShell script to provide the proper permissions.

$thumbprint = "<<THUMBPRINT>>"
$certPath = "C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys"
$cert = Get-ChildItem -Path Cert:\LocalMachine\My\$thumbprint
$acl = Get-Acl -Path (Join-Path $certPath $cert.PrivateKey.CspKeyContainerInfo.UniqueKeyContainerName)
$gmSaAccount = "Domain\<<GMSA_Account>>$"
$accessRule = New-Object System.Security.AccessControl.FileSystemAccessRule($gmSaAccount, "Read", "Allow")
$acl.SetAccessRule($accessRule)
Set-Acl -Path (Join-Path $certPath $cert.PrivateKey.CspKeyContainerInfo.UniqueKeyContainerName) -AclObject $acl

Protocol

By default, Universal will listen on HTTP1 and HTTP2. You can adjust the protocols that the server listens to by setting the Protocols property. For example, you can specifically set HTTP1 and HTTP2 support with the following setting.

"Kestrel": {
  "Endpoints": {
    "HTTP": {
      "Url": "http://*:5000",
      "Protocols": "Http1AndHttp2"
    }
  },
  "RedirectToHttps": "false"
},

Some versions of Windows Server (like 2012R2), do not support HTTP2. To disable HTTP2 support, set the listener to only listen on HTTP1.

"Kestrel": {
  "Endpoints": {
    "HTTP": {
      "Url": "http://*:5000",
      "Protocols": "Http1"
    }
  },
  "RedirectToHttps": "false"
},

For a full set of listening options, you can refer to the ASP.NET Core Documentation.

Security Headers

Organizations may require that PowerShell Universal provides certain security headers in HTTP responses coming from the server, these may include:

• Strict-Transport-Security

• Content-Security-Policy

• X-Frame-Options

• X-Content-Type-Options

• X-XSS-Protection

• Referrer-Policy

You can use the Kestrel \ Headers section to define these values.

{
    "Kestrel" : {
       "Headers": {
          "X-Content-Type-Options": "nosniff",
          "Content-Security-Policy": "default-src 'self';",
          "X-XSS-Protection": "block",
          "X-Frame-Options": "DENY"
       }
    }
}

Be careful when configuring these headers as they change the behavior of every web request returned by PowerShell Universal.

Example: Self-Signed Certificate

In this example, we'll show how to create a self-signed certificated and use it with PowerShell Universal.

First, create a self-signed certificate and store it into your local machine store. You will need to run PowerShell as administrator. The local machine store is required because PowerShell Universal may be running as service and not as your account.

New-SelfSignedCertificate -DnsName localhost -CertStoreLocation cert:\LocalMachine\My

Next, you'll need to configure PowerShell Universal to use the certificate. This can be accomplished by editing or creating the appsettings.json file in %ProgramData%\PowerShellUniversal. This file should already exist if you installed with the MSI installer. The contents of the file should include the DNS name of your certificate and the location.

For self-signed certificates, you will need to include the AllowInvalid option.

{
  "Kestrel": {
    "Endpoints": {
      "HTTPS": {
         "Url": "https://*:443",
           "Certificate": {
             "Subject": "localhost",
             "Store": "My",
             "Location": "LocalMachine",
             "AllowInvalid": "true"
           }
      }
   }
}

Once you have updated the appsettings.json file, restart the PowerShell Universal service. You should now be able to access your PowerShell Universal web site at https://localhost.