Research and Development
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.
You can verify the availability of WinRM and configure a PowerShell for remoting by following these steps:
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
You can work with remote computers using the following remoting cmdlets:
-ComputerName
parameter. To run a series of related commands that share data, create a PowerShell session (PSSession) on a remote computer, and then use the -Session
parameter of Invoke-Command
to run the command in the PSSession.Get-PSSession Gets the PowerShell sessions (PSSessions) that were created in the current session. Without parameters, this cmdlet returns all of the PSSessions created in the current session. You can use the parameters of Get-PSSession
to get the sessions that are connected to particular computers or identify sessions by their names, IDs, or instance IDs. For computers, type the NetBIOS name, IP address, or fully qualified domain name. To specify the local computer, type the computer name, localhost
, or a dot (.
). For IDs, type an integer value that uniquely identifies the PSSession in the current session. PSSessions can be assigned friendly names with the -Name
parameter. You can specify the friendly names using wildcards. To find the names and IDs of PSSessions, use Get-PSSession
without parameters. An instance ID is a GUID that uniquely identifies a PSSession, even when you have multiple sessions running in PowerShell. The instance ID is stored in the RemoteRunspaceID property of the RemoteRunspaceInfo object that represents a PSSession. To find the InstanceID of the PSSessions in the current session, type:
get-pssession | Format-Table Name, ComputerName, RemoteRunspaceId
Enter-PSSession Starts an interactive session with a single remote computer. During the session, you can run commands just as if you were typing directly on the remote computer. You can have only one interactive session at a time. Typically, you use the -ComputerName
parameter to specify the name of the remote computer. However, you can also use a session that you created previously by using New-PSSession
for the interactive session.
Get-Command
can find in the other session. To import commands, first use New-PSSession
to connect to the session from which you will import. Then use Import-PSSession
to import commands. By default, Import-PSSession
imports all commands except for commands that exist in the current session. To overwrite a command, specify the command in the -CommandName
parameter. PowerShell adds the imported commands to a temporary module that exists only in your session, and it returns an object that represents the module. Although you can use imported commands just as you would use any command in the session, the imported part of the command actually runs in the session from which it was imported. Because imported commands might take longer to run than local commands, Import-PSSession
adds an -AsJob
parameter to every imported command. This parameter allows you to run the command as a PowerShell background job.Add-Module
cmdlet to add the commands to the local session so that they can be used. To export commands, first use New-PSSession
to connect to the session that has the commands that you want to export. Then use Export-PSSession
to export the commands. By default, Export-PSSession
exports all commands except for commands that already exist in the session. However, you can still use the -PSSnapin
, -CommandName
, and -CommandType
parameters to specify the commands to export.One way to run commands on remote computers is to use the Invoke-Command cmdlet. With this cmdlet, you can do the following:
-ComputerName
parameter to specify the remote computers to work with by DNS name, NetBIOS name, or IP address.-ScriptBlock
parameter to specify the command or commands to run.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.
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.
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.