Enable PSRemoting: Local and Remote Techniques

Even though on Windows, PSRemoting comes enabled by default, it’s not enabled all of the time. If you either need to test to see if PSRemoting is enabled or enable PSRemoting on Windows, this tutorial is for you.

This tutorial is going to walk you through many different ways to enable PSRemoting on local and remote computers running both Windows.

Let’s get started!

Related:PowerShell Remoting: The Ultimate Guide

Enabling PSRemoting Does A lot

If you’re first learning about PowerShell Remoting, you may think that enabling is just a single command. Perhaps you saw some references to the Enable-PSRemoting PowerShell cmdlet and think once you run that, it just flips a bit somewhere. You’d be wrong.

When you hear about enabling PSRemoting, a lot of tasks must go on in the background to make that happen. Since PowerShell Remoting depends on other systems to run properly, it has a few dependencies.

For example, on Windows, when you run the Enable-PSRemoting cmdlet with no parameters, it performs all of the following tasks:

1. The WinRM service is started and set to automatic startup.
2. Creates a listener on the default WinRM ports 5985 for HTTP traffic.
3. Enables the firewall exceptions for WS-Management.
4. Registers the PowerShell session configurations with WS-Management.
5. Enables the PowerShell session configurations.
6. Sets the PowerShell remote sessions to allow remote access.
7. Restarts the WinRM server to apply all of the changes.

Aren’t you glad you don’t have to do all of that manually? Why mention this if the Enable-PSRemoting cmdlet does it all? Because there will be times when something doesn’t work and you need to troubleshoot what happens.

Default PSRemoting Settings on Windows

Since PSRemoting was born in Windows, it comes enabled by default but not universally and also not for all Windows OS versions.

On all Windows client operating systems, PSRemoting is always disabled.

On Windows Server, PSRemoting is enabled sometimes but not all of the time depending on what network profile Windows is running under. Below you’ll find a handy table to help you determine if your Windows OS has PSremoting enabled or not.

Linux, on the other hand, is easy. PSRemoting isn’t even a thing! Not even PowerShell is installed by default. If you want to run PSRemoting on Linux, you’ll have to set it up.

Related:How to Set up PSRemoting with Windows and Linux

Enough talk, let’s show you how to actually start using PSRemoting!

Prerequisites

If you intend to follow along with the examples in this section, please be sure you have the following:

• A Windows Server 2008 R2 or later machine
• A local or Active Directory domain user in the local administrators group

Enabling PSRemoting Locally

One of the easiest ways to enable PSRemoting is to use the built-in Enable-PSRemoting command. This command, as you learned above, is a shortcut to configuring many different services to accommodate PowerShell Remoting.

Using the Enable-PSRemoting Cmdlet

When you run this command without any parameters it will take different actions depend on the OS you are running. On any current Windows OS, the same basic steps happen. PSRemoting gets enabled, the WinRM HTTP listener gets created, and the firewall rules are enabled. The key difference is the the way Public networks are handled.

On a Server OS, like Windows Server 2019, the firewall rule for Public networks allows on remote connections from other devices on the same network. On a client OS, like Windows 10, you will receive an error stating that you are a public network.

If you’re unsure what network profile Windows is running under, run the following command:

Get-NetConnectionProfile

You should only use PSRemoting on a trusted network since it is essentially running a web server to listen for remote connections.

If you’re OK with running PSRemoting on a network profile other than Private or Domain, you can skip the network profile check by using the SkipNetworkProfileCheck parameter. Using this parameter will open up WinRM ports on the Windows firewall.

Enable-PSRemoting -SkipNetworkProfileCheck

Using the SkipNetworkProfileCheck parameter will open up the Windows firewall for PowerShell remoting on your current network profile but will only allow remote connections from machines on the same subnet.

Two parameter that can be used with Enable-PSRemoting work hand in hand. They are the -Force and -Confirm parameters. You can use -Force to skip all of the prompts that running the Enable-PSRemoting command would normally give you. You can also use -Confirm:$false to get the same outcome.

Using the winrm quickconfig Command

The winrm quickconfig command used to be a popular way to setup PSRemoting before the Enable-PSRemoting cmdlet was create, but it does still have its place. If you run just winrm quickconfig it will enable the WinRM service, create an HTTP listener, and enable the firewall rules. These are all things that already get done by Enable-PSRemoting but this does not setup the machine to be able to handle remote PowerShell sessions.

Where the winrm commands come in handy is setting up HTTPS listeners. While you can do this manually, if you have an appropriate certificate for the HTTPS listener you can simply run winrm quickconfig -transport:https and the HTTPS listener and HTTPS firewall rules will be configured.

Enabling PSRemoting Remotely

So far, you’ve learned that you can enable PSRemoting by running a command on a local computer. This leads us to a chicken and the egg scenario. PSremoting allows you to run commands on remote computers but how do you run a command remotely without PSRemoting?

Three ways; the PSexec utility, WMI and Group Policy.

Using Psexec

PSExec is a handy utility that allows you to run remote commands like like PSRemoting does. However, PSexec uses a different communication method which you can use to your advantage!

Related:PSExec: The Ultimate Guide

With PSexec, you can run Enable-PSRemoting from your local computer using the following command. The command below is calling psexec and connecting to the ServerB server. It then starts a PowerShell process and executes the Enable-PSRemoting command with the -Force switch to skip the usual prompts.

.\psexec.exe \ServerB -h -s powershell.exe Enable-PSRemoting -Force

This option is good for one off instances where you need to enable PSRemoting on a remote system, but is not great for having to enable PSRemoting on a lot of systems and does require you to download psexec.

Using WMI

Sometimes PSexec won’t work. Many pieces of security software block psexec but don’t be worried, you have WMI too!

Using PowerShell and the Invoke-CimMethod cmdlet. Using the Invoke-CimMethod cmdlet, you can instruct PowerShell to connect to the remote computer over DCOM and invoke methods.

Lucky for you, WMI has a Win32_Process classes that allows you to invoke processes. By invoking a Create method against the Win32_Process, Invoke-CimMethod connects to the remote computer, invoking PowerShell and running Enable-PSRemoting as shown below.

The below example is creating a hash table for the session connection where the server name, credentials and protocol are specified. Then in the following hash table, the parameters for the Invoke-CimMethod are being set. Once these are run a CIM session is being created over the DCOM protocol that starts a PowerShell process than in turn runs the Enable-PSRemoting command.

$SessionArgs = @{
     ComputerName  = 'ServerB'
     Credential    = Get-Credential
     SessionOption = New-CimSessionOption -Protocol Dcom
 }
 $MethodArgs = @{
     ClassName     = 'Win32_Process'
     MethodName    = 'Create'
     CimSession    = New-CimSession @SessionArgs
     Arguments     = @{
         CommandLine = "powershell Start-Process powershell -ArgumentList 'Enable-PSRemoting -Force'"
     }
 }
 Invoke-CimMethod @MethodArgs

In the case, you are using this in a domain environment, and the user that is executing the commands has administrative rights on the destination server, the Credential = Get-Credential line can be excluded.

Using Group Policy

The last, and arguably the best option for enabling WinRM across a wide range of computers is through group policy. When using Group Policy, you can create a single Group Policy Object and apply that policy across thousands of computers at once.

All computers must be in an Active Directory domain to use Group Policy.

To use Group Policy to enable WinRM across many computers at once, you’re going to need to set three different configuration items:

1. Enable the WinRM service.
2. Open the Windows Firewall port for WinRm.
3. Creating the WinRM listener and allow connections to it.

First, RDP to a domain controller or, better yet, install the remote server administrator tools (RSAT) package on a domain-joined workstation. You should now have the Group Policy Management Console (GPMC) available.

Enabling the WinRM Service

To enable the WinRM service on all target computers:

1. Open up the GPMC and create a GPO. While in the new GPO, navigate to Computer Configuration —> Windows Settings —> Security Settings —> System Services
2. Select Windows Remote Management (WS-Management).
3. In the configuration panel check the box for Define this policy setting.
4. Select the radio button for Automatic to set the WinRm service to start automatically on boot.
5. Click OK to confirm the setting.

Opening the Windows Firewall Port

Next, you need to open the WinRM port on all of the target computers. While still editing the GPO created above:

1. Navigate to Computer Configuration —> Windows Settings —> Security Settings —> Windows Defender Firewall with Advanced Security.

2. Click on the New Inbound Rule to create a new inbound rule.

3. On the first page select Predefined and select Windows Remote Management as shown below.

4. On the next page, check the box for the Domain/Private network rule unless you know that Public networks are used in your environments and you will need to allow remote connections from them.

5. On the next page leave the default of Allow the connection and click Finish to create the rule.

Create the WinRM Listener and Filter List

The final configuration item to add to your GPO is creating the WinRM listener ad allowing connections to that WinRM listener. This setting creates the WinRM listener for HTTP and allows connections to it from the specified IPs or IP ranges.

While still editing the WinRM GPO:

1. Navigate to Computer Configuration —> Administrative Templates —> Windows Components —> Windows Remote Management (WinRM) —> WinRM Service.

2. Select Enabled for the setting Allow remote service management through WinRM.

3. Under the Allow remote server management through WinRM setting, provide an asterisk (*) for both the IPv4 filter and IPv6 filter as shown below.

Note that you can specify multiple hosts separated by a comma in each filter list if you know ahead of time which hosts will be connecting to all target computers.

4. Click OK to confirm the newest GPO setting.

Applying the GPO

At this time, the GPO should be created and ready to go. The final task you now must do is to apply this GPO to all of the target computers you wish to enable WinRM on. You will not learn how to assign a GPO to target computers in this tutorial.

If you don’t know how to assign a GPO to a set of computers in Active Directory, you should check out this article.

Next Steps

In this tutorial, you have learned how to enable PSRemoting many different ways. How you enable PSRemoting will greatly depend on your environment and I hope I’ve covered your scenario here.

Now take what you’ve learned, get out there and start using PSRemoting in your environment!