Beta 42

Research and Development

Menu

PowerShell - Remoting

The Windows PowerShell remoting features are supported by the WS-Management protocol and the Windows Remote Management (WinRM) service that implements WS-Management in Windows. Computers running Windows 7 and later include WinRM 2.0 or later. On computers running earlier versions of Windows, you need to install WinRM 2.0 or later as appropriate and if supported. Currently, remoting is supported on Windows Vista with Service Pack 1 or later, Windows 7, Windows Server 2008, and Windows Server 2008 Release 2.

Enable Remoting

You can verify the availability of WinRM and configure a PowerShell for remoting by following these steps:

  1. Start Windows PowerShell as an administrator by right-clicking the Windows PowerShell shortcut and selecting Run As Administrator.
  2. The WinRM service is configured for manual startup by default. You must change the startup type to Automatic and start the service on each computer you want to work with. At the PowerShell prompt, you can verify that the WinRM service is running using the following command:

    get-service winrm

    The value of the Status property in the output should be Running. 3. To configure Windows PowerShell for remoting, type the following command:

    Enable-PSRemoting -force

In many cases, you will be able to work with remote computers in other domains. However, if the remote computer is not in a trusted domain, the remote computer might not be able to authenticate your credentials. To enable authentication, you need to add the remote computer to the list of trusted hosts for the local computer in WinRM. To do so, type:

winrm s winrm/config/client '@{TrustedHosts="RemoteComputer"}'

When you are working with computers in workgroups or homegroups, you must either use HTTPS as the transport or add the remote machine to the TrustedHosts configuration settings. If you cannot connect to a remote host, verify that the service on the remote host is running and is accepting requests by running the following command on the remote host:

winrm quickconfig

This command analyses and configures the WinRM service.

To use Windows PowerShell remoting features, you must start Windows PowerShell as an administrator by right-clicking the Windows PowerShell shortcut and selecting Run As Administrator. When starting PowerShell from another program, such as the command prompt (cmd.exe), you must start that program as administrator.

One way of getting the advantage of Group Policy is to deploy a logon script. The script is a single line, saved in a .ps1 file:

Enable-PSRemoting -Force

Remoting Commands

You can work with remote computers using the following remoting cmdlets:

Invoking Remote Commands

One way to run commands on remote computers is to use the Invoke-Command cmdlet. With this cmdlet, you can do the following:

After completing any of the preceding actions, you can type the following command as a single line to run a Get-Process command remotely:

invoke-command -computername Server4, Server2, Server8 -scriptblock \`
{get-process}

By default, Invoke-Command runs under your user name and credentials. Use the -Credential parameter to specify alternate credentials, such as UserName or Domain\UserName. You will be prompted for a password.

Invoking Sessions

You can establish a local or remote session to create a persistent connection using the New-PSSession cmdlet. Unless you use the -ComputerName parameter and use it to specify the name of one or more remote computers, PowerShell assumes you are creating a session for the local computer. With New-PSSession, you must use the -Session parameter with Invoke-Command to run the command in the named session.

For example, you can establish a session by typing the following command:

$s = new-PSSession -computername Server24

Here, $s is a variable that sets the name of the session. Because you've used the -ComputerName parameter, PowerShell knows you are creating a remote session rather than a local session. PowerShell creates a persistent connection with the specified computer. You can then use Invoke-Command with the -Session parameter to run the command in the named session as shown in this example:

invoke-command -session $s -scriptblock {get-process}

You can just as easily establish a session with multiple computers. Simply establish the session and name all the computers. Generally, you might also need to specify your credentials using the -Credential parameter.

Sometimes, you'll want to execute an application or external utility on remote computers as shown in the following example:

$comp = get-content c:\\computers.txt
$s = new-pssession -computername $comp
invoke-command -session $s { powercfg.exe -energy }

Here, C:\Computers.txt is the path to the file containing the list of remote computers to check. On each computer, you run PowerCfg with the -Energy parameter. This generates an Energy-Report.html file in the default directory for the user account used to access the computer.

Working Remotely Without WinRM

Some cmdlets have a -ComputerName parameter that lets you work with a remote computer without using Windows PowerShell remoting. This means you can use the cmdlet on any computer that is running Windows PowerShell, even if the computer is not configured for Windows PowerShell remoting. These cmdlets include the following:

Add-Computer                    Clear-EventLog          Get-Counter
Get-EventLog                    Get-HotFix              Get-Process
Get-Service                     Get-WinEvent            Get-WmiObject
Limit-EventLog                  New-EventLog            Remove-Computer
Remove-EventLog                 Rename-Computer         Restart-Computer
Reset-ComputerMachinePassword   Set-Service             Show-EventLog
Stop-Computer                   Write-EventLog

Because these cmdlets don't use remoting, you can run any of these cmdlets on a remote computer in a domain simply by specifying the name of one or more remote computers in the -ComputerName parameter. However, Windows policies and configuration settings must allow remote connections, and you must still have the appropriate credentials.