Describes the system requirements and configuration requirements for running remote commands in PowerShell.
This topic describes the system requirements, user requirements, and resource requirements for establishing remote connections and running remote commands in PowerShell. It also provides instructions for configuring remote operations.
Some cmdlets get objects from remote computers RPC connections or WMI sessions for remote connections. They don't use the PowerShell remoting infrastructure. The requirements in this document don't apply to these cmdlets.
To find the cmdlets that have a ComputerName parameter but don't use PowerShell remoting, read the description of the ComputerName parameter of the cmdlets.
In Windows, PowerShell remoting uses Windows Remote Management (WinRM), which is provided by the Windows Management Framework (WMF). To run remote sessions on PowerShell, the local and remote computers must have the following:
- Windows PowerShell 3.0 or higher
- The Microsoft .NET Framework 4 or higher
- Windows Remote Management 3.0 or higher
To run remote sessions on Windows PowerShell 2.0, the local and remote computers must have the following:
- Windows PowerShell 2.0 or later
- The Microsoft .NET Framework 2.0 or later
- Windows Remote Management 2.0
To be fully supported, you should be using WMF 5.1. For more information about WMF support, see Windows Management Framework (WMF).
You can create a remote session between a computer running Windows PowerShell 2.0 and one running a newer version of PowerShell. However, features that run only on new versions of PowerShell, such as the ability to disconnect and reconnect to sessions, are only available when both computers are running Windows PowerShell 3.0 and higher.
To find the version number of an installed version of PowerShell, use the
$PSVersionTable automatic variable.
PowerShell 7 and higher also supports PowerShell remoting over SSH. PowerShell remoting over SSH allows you to connect to any Windows, macOS, or Linux host that is running SSH. For more information, see PowerShell Remoting Over SSH.
To create remote sessions and run remote commands, by default, the current user must be a member of the Administrators group on the remote computer or provide the credentials of an administrator. Otherwise, the command fails.
The permissions required to create sessions and run commands on a remote computer are established by the session configuration. The session configuration defines the configuration options for the connection endpoint on the remote computer. Specifically, the security descriptor on the session configuration determines who has access to the session configuration and who can use it to connect.
The security descriptors on the default session configurations, Microsoft.PowerShell and Microsoft.PowerShell32, only allow access to members of the Administrators group.
Members of the Administrators group on a computer can determine who has
permission to connect to the computer remotely by changing the security
descriptors on the default session configurations or create new session
configurations with different security descriptors. Users can use the
ConfigurationName parameter of
*-PSSession cmdlets to connect to
For more information about session configurations, see about_Session_Configurations.
Windows network locations
Beginning in Windows PowerShell 3.0, the
Enable-PSRemoting cmdlet can enable
remoting on client and server versions of Windows.
On server versions of Windows with private and domain networks, the
Enable-PSRemoting cmdlet creates firewall rules that allow unrestricted
remote access. It also creates a firewall rule for public networks that allows
remote access only from computers in the same local subnet. This local subnet
firewall rule is enabled by default on server versions of Windows on public
Enable-PSRemoting reapplies the rule in case it was changed or
On client versions of Windows with private and domain networks,
Enable-PSRemoting creates firewall rules that allow unrestricted remote
To enable remoting on client versions of Windows with public networks, use the
SkipNetworkProfileCheck parameter of the
Enable-PSRemoting cmdlet. This
option creates a firewall rule that allows remote access only from computers in
the same local subnet.
To remove the local subnet restriction on public networks and allow remote
access from all locations on client and server versions of Windows, use the
Set-NetFirewallRule cmdlet in the NetSecurity module. Run the following
Set-NetFirewallRule -Name "WINRM-HTTP-In-TCP-PUBLIC" -RemoteAddress Any
The name of the firewall rule can be different for different versions of
Get-NetFirewallRule to see a list of rules. Before enabling
the firewall rule, view the security settings in the rule to verify that the
configuration is appropriate for your environment.
In Windows PowerShell 2.0, on server versions of Windows,
creates firewall rules that permit remote access on all networks.
In Windows PowerShell 2.0, on client versions of Windows,
creates firewall rules only on private and domain networks. If the network
location is public,
Run as administrator
Administrator privileges are required for the following remoting operations:
- Establishing a remote connection to the local computer. This is commonly known as a "loopback" scenario.
- Managing session configurations on the local computer.
- Viewing and changing WS-Management settings on the local computer. These are the settings in the LocalHost node of the WSMAN: drive.
You must start PowerShell with the Run as administrator option even if you are a member of the Administrators group on the local computer.
When you start Windows PowerShell from another program such as
the Run as administrator option to start the program.
How to configure your computer for remoting
Computers running any supported version of Windows can establish remote connections and run remote commands in PowerShell without any configuration. However, to receive remote connections you must enable PowerShell remoting on the computer.
Windows Server 2012 and newer releases of Windows Server are enabled for
PowerShell remoting by default. If the settings are changed, you can
restore the default settings by running the
By default, the remoting features of PowerShell are supported by the WinRM service, which is the Microsoft implementation of the Web Services for Management (WS-Management) protocol. When you enable PowerShell remoting, you change the default configuration of WS-Management and add system configuration that allow users to connect to WS-Management.
To configure PowerShell to receive remote commands:
- Start PowerShell with the Run as administrator option.
- At the command prompt, type:
To verify that remoting is configured correctly, run a test command such as the following command, which creates a remote session on the local computer.
If remoting is configured correctly, the command creates a session on the local computer and returns an object that represents the session.
Id Name ComputerName State ConfigurationName -- ---- ------------ ----- ----- 1 Session1 localhost Opened Microsoft.PowerShell
If the command fails, see about_Remote_Troubleshooting.
When you work remotely, you use two instances of PowerShell, one on the local computer and one on the remote computer. As a result, your work is affected by the Windows and PowerShell policies on both the local and remote computers.
Before you connect and while establishing the connection, the policies on the local computer are in effect. When you are using the connection, the policies on the remote computer are in effect.