Although it’s much easier to set up Windows PowerShell remoting in an Active Directory domain, you can also implement PowerShell remoting in a workgroup. In this blog post, I’ll show you how both procedures work, step by step.
Update: Read our new guide that explains all aspects of enabling PowerShell remoting. You will learn how to enable remoting remotely with various tools, how to allow non-admins to use remoting, and to configure remoting in workgroup environments.
Avatar
Latest posts by Timothy Warner (see all)

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

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

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

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

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

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!

avataravatar
6 Comments
  1. Avatar
    Umang Mehta 8 years ago

    Question – I want to enable- Psremoting in my company.
    1.How can i do it without using a gpo. i,e enable psremoting to all wks. All wks are in Domain.
    2. I want only my team to do Psremoting i.e (group name Pc-support). How to do that. My group is in all wks Administrators group. What security group should i add them.
    3. security – If you can give me a simple understandable explaination so i can present it to my managers.

  2. Avatar
    Chris 7 years ago

    Hi Tim,

    Your command:

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

    Needs a colon after WsMan:

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

    Cheers,

  3. Avatar

    Hi Timothy,

    I was enabling PowerShell remoting on Windows Server 2016 but I am getting ‘Access is denied’ error. Although, I have run the PowerShell with administrative privileges.

    Thank you,

  4. Avatar
    Nikhil John 6 years ago

    Hi Timothy,

    I have created GPO for powershell Remoting, firewall configuration and automatic startup of WinRM service and applied my company AD, can I automate these GPO creation via powershell, I have tried but I cant create that GPO via powershell. Please help me.

  5. Avatar

    Enter-PSSession and Test-PSRemoting (from Lee HOLMES) test the whole end to end connection including the credentials.

    If you just want to test the WinRM configuration you can use the built-in Test-WSMan cmdlet.

Leave a reply

Your email address will not be published. Required fields are marked *

*

© 4sysops 2006 - 2023

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending

Log in with your credentials

or    

Forgot your details?

Create Account