Enable PowerShell Remoting

• Author
• Recent Posts

Timothy Warner

Timothy Warner is a Microsoft Cloud and Datacenter Management Most Valuable Professional (MVP) who is based in Nashville, TN. Check out his Azure and Windows Server video training at Pluralsight, and feel free to reach out to Tim via Twitter.

Latest posts by Timothy Warner (see all)

• Azure PowerShell vs. Azure CLI - Wed, Mar 15 2023
• Use Azure Storage for backup - Thu, Feb 23 2023
• Azure Data Studio vs. SQL Server Management (SSMS) - Wed, Feb 8 2023

As you probably know, Windows PowerShell version 3 greatly enhanced remoting capabilities in the product. A somewhat little-known fact is that the PowerShell commands that use the –ComputerName parameter don’t use true PowerShell remoting at all; instead, this parameter employs use of legacy DCOM and RPC calls.

In this blog post, I’m going to teach you how to enable “true” PowerShell remoting, by which I mean one-to-one and one-to-many Windows PowerShell remoting that uses the industry standard WS-Management protocols. We’ll assume that your computers run at least Windows PowerShell version 3. If you’re brave, you should check out Windows PowerShell version 5, which is now available in public preview mode.

How does remoting work?

As I stated earlier, the term “PowerShell remoting” for our purposes does not refer to using the –ComputerName parameter with a command like this:

Get-Process –ComputerName pc1, pc2, pc3

Although the above command works well enough, it executes the remote command serially (one computer after another), and on non-standard network ports to boot. By contrast, a command like this:

Invoke-Command –name pc1, pc2, pc3 –ScriptBlock {Get-Process}

sends the Get-Process command in scattergun fashion, hitting all target machines in parallel and over traditional web- and firewall-friendly ports.

Recall that we can also take advantage of session-based remoting in Windows PowerShell. For instance, I can issue the following statement in order to access a remote PowerShell console session on a server named mail1 from my administrative workstation:

Enter-PSSession –ComputerName mail1

This article isn’t a comprehensive overview of why you should leverage Windows PowerShell remoting. Rather, if you need that information, I’ll point you to my colleague Don Jones’ wonderful (free) eBook, Secrets of PowerShell Remoting.

Instead, what we’re concerned with here is how to enable PowerShell remoting both in domain and in workgroup environments. Windows Server 2012 and 2012 R2 have PowerShell remoting enabled by default, but you’ll need to do some work to get your downlevel servers and client machines configured for remoting.

Enabling PowerShell remoting in a domain

Windows PowerShell remoting is infinitely easier to configure in a domain environment because all domain member computers trust each other implicitly. Thus, turning on PowerShell remoting on a Windows client or server computer is simply a matter of opening an elevated PowerShell console session and issuing the following statement:

Enable-PSRemoting –Force

The –Force parameter is technically optional, but I recommend that you use it; otherwise, you’ll be stuck passing through confirmation prompts, as shown below:

Enable PowerShell remoting without -force

Specifically, the Enable-PSRemoting command makes the following changes to your system:

• Starts the Windows Remote Management (WinRM) service and sets it for automatic startup
• Creates a listener to accept remote requests on any IP address
• Enables a firewall exception for WS-Management
• Makes some additional under-the-hood changes to support PowerShell remoting sessions and workflows

NOTE: You might wonder what the difference is between Enable-PSRemoting and, say, winrm quickconfig. Technically speaking, not much. In fact, running Enable-PSRemoting performs all the work of winrm quickconfig but includes additional Windows PowerShell-specific environment changes. Long story short: If you run Enable-PSRemoting, you don’t need to run winrm quickconfig.

Sadly, Windows PowerShell versions 3 through 5 don’t include an easy method to verify whether or not PowerShell remoting is enabled on a box. Here, try the following:

Get-Command *remoting*

However, Windows PowerShell expert Lee Holmes wrote a new cmdlet called Test-PSRemoting that does exactly that. Check it out!

The following screenshot shows the extra confirmation-related work we’ll be required to do if we leave out the –Force parameter when enabling PSRemoting on a Windows box.

Enable remoting without the Force parameter

Naturally, we don’t want to run Enable-PSRemoting on every one of our servers and/or client boxes, especially if the number of said boxes runs into the hundreds. Instead, we can turn to good ol’ Group Policy to make this configuration change.

Sadly, even in Windows Server 2012, there is no “turnkey” Group Policy setting to enable PowerShell remoting. Instead, we have to configure the WinRM service directly and make Windows Firewall exceptions manually.

Remote server management through WinRM

First, open your Group Policy Editor (I’m using a Windows Server 2012 R2 domain controller) and navigate to the following path:

Computer Configuration\Policies\Administrative Templates\Windows Components\Windows Remote Management (WinRM)\WinRM Service

As you can see in the following screenshot, the policy that we enable is called Allow remote server management through WinRM, and we should both enable the policy and set the IPv4/IPv6 filters to all (*).

Allow remote server management through WinRM

Set WinRM service to automatic startup

Second, we need to ensure that the WinRM service is set for automatic startup. Navigate to:

Computer Configuration\Policies\Windows Settings\Security Settings\System Services

Select the Windows Remote Management (WS-Management) service and set it for automatic startup.

Windows Remote Management (WS-Management) automatic startup

Configure Windows Firewall

Third, and finally, we need to set Windows Firewall rules by navigating to:

Computer Configuration\Policies\Windows Settings\Security Settings\Windows Firewall with Advanced Security\Windows Firewall with Advanced Security

You’ll want to set inbound and outbound allowances for the Windows Remote Management predefined rule as shown in the following figure.

Allow WinRM in Windows Firewall

Cool! Now push out the Group Policy, reboot all affected computers, and you’re done.

Enabling PowerShell remoting in a workgroup

When your computers exist outside of an Active Directory domain, PowerShell remoting is certainly possible, but it is quite a bit more tedious to set up. One approach involves the use of digital certificates; the other, which we’ll use here, implements the TrustedHosts list.

The TrustedHosts list records the hostnames of any other systems that you want to grant remote access permissions to the local machine. First, you should verify that your workgroup computer’s TrustedHosts list is empty by running the following command:

Get-Item –Path WSMan:\localhost\Client\TrustedHosts

To grant another computer permission to establish a PowerShell remoting session with the localhost, run the following:

Set-Item –Path WSMan\localhost\Client\TrustedHosts –Value "computername"

A few things can go wrong here. If any of your NICs have a location set to “Public,” you’ll get a failure. One way around this problem is to set the problematic NIC to use the Private location profile; this shouldn’t be a problem assuming that you are secure inside your network perimeter.

Set-NetConnectionProfile –InterfaceIndex <nic_index> -NetworkCategory Private

Note that the Set-NetConnectionProfile cmdlet is available only in Windows PowerShell 4 running on Windows 8.1 and Windows Server 2012 R2. Also, you can run Get-NetAdapter to obtain your NIC interface index values.

Of course, you’ll also need to ensure that PowerShell remoting is enabled on all your relevant workgroup computers. Don’t forget about that!

Enable-PSRemoting -Force

Testing Remote Access

To verify PowerShell remoting, try to enter a PowerShell session from the other computer:

Enter-PSSession –Computername <hostname>

If you see an “Access Denied” error, the most likely explanation is that you aren’t running from an elevated Windows PowerShell session. Another possible reason is that you need to specify remote credentials that work on the remote computer:

Enter-PSSession –Computername "host2" –Credential "host2\administrator"

Conclusions

First of all, in my humble opinion, all your computers—both server and client—should be running the latest released version of Windows PowerShell possible in order to take advantage of all this remoting goodness.

Second, I think you’ll find the convenience factor that you gain in enabling PowerShell remoting is tremendous. Even in my home workgroup network, I’m able to automate so much otherwise tedious work by using Windows PowerShell.

How do you use Windows PowerShell remoting in your work? Please let me know in the comments. Thanks for reading!