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.
- Install Ansible on Windows - Thu, Jul 20 2023
- Use Azure Bastion as a jump host for RDP and SSH - Tue, Apr 18 2023
- Azure Virtual Desktop: Getting started - Fri, Apr 14 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!
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.
Hi Tim,
Your command:
Needs a colon after WsMan:
Cheers,
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,
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.
If you want to enable PowerShell remoting through Group Policy, you can read this article.
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.