Sample PowerShell 2.0 Remoting Commands
The following are a list of commands that I demonstrated at TechEd 2010 in New Orleans. Actually I should say that I intended to demo these commands, but wasn’t able to complete the entire list due to a conference wide network outage. :-(
Many of these commands were intended to run against a real world web server in the Internet (https://wsman.msft.net). For one command (WS-Man ID), I’ll include the web server in the command syntax. Otherwise I’ll just use "<server name>" to specify the destination. In addition, my demo server is configured to respond to WS-Management from the original port 80 (rather than the new port 5985 which was changed in WinRM 2.0).
Note: If your client or end points are not Windows7 or Windows Server 2008 R2, then you will need to have PowerShell 2.0 installed on both systems. You can get the bits as Windows updates from https://download.microsoft.com .
Note: All commands are intended to be executed from PowerShell 2.0 or the PowerShell Integrated Scripting Environment (ISE).
Test WS-Man connectivity without authentication.
This is useful for making sure the network and the Windows Remote Manage service are operational and intentionally does not check credentials since that is usually another level of configuration can be tested on its own.
test-wsman -computername wsman.msft.net:80 -authentication none
Create a credential token to be used throughout the remaining commands.
$cred = get-credential <administrator account name on end point>
Test WS-Man connectivity with credentials (note version info is now displayed).
As mentioned above, it is helpful to be able to isolate authentication when troubleshooting management connectivity issues.
test-wsman -computername <server name>:<port if other than 5985> -authentication default -credential $cred
Enumerate status for all Services.
This is merely using WS-Man as the transport for accessing WMI providers. In the past, DCOM was the transport, but had many limitations due to its firewall unfriendly nature.
get-wsmaninstance -enumerate wmicimv2/win32_service -computername <server name>:<port if other than 5985> -authentication default -credential $cred
Enumerate status for IIS Service.
This demonstrates getting the state of a specific service (or element) by using the "selectorset" parameter.
get-wsmaninstance wmicimv2/win32_service -selectorset @{name="w3svc"} -computername <server name>:<port if other than 5985> -authentication default -credential $cred
Stop and Start the IIS Service.
Again, this is merely using WS-Man as the transport in order to manipulate WMI methods that have been around since the dawn of time.
invoke-wsmanaction -action stopservice -resourceuri wmicimv2/win32_service -selectorset @{name="w3svc"} -computername <server name>:<port if other than 5985> -authentication default -credential $cred
This will verify the state of the stopped service.
get-wsmaninstance wmicimv2/win32_service -selectorset @{name="w3svc"} -computername <server name>:<port if other than 5985> -authentication default -credential $cred
Now restart the IIS service.
invoke-wsmanaction -action startservice -resourceuri wmicimv2/win32_service -selectorset @{name="w3svc"} -computername <server name>:<port if other than 5985> -authentication default -credential $cred
Store Output into an Object.
WMI instrumentation and actions are now very easy to automate with the addition of WS-Man as a transport for remoting and PowerShell for scripting. The example here shows how the WMI information can be pulled into an object and properly formatted.
$operatingsystem = get-wsmaninstance -enumerate wmicimv2/win32_operatingsystem -computername <server name>:<port if other than 5985> -authentication default -credential $cred
Show the output for the Last Boot Time for the end point.
$operatingsystem.LastBootUpTime
Format this Boot Time data into a proper .Net DateTime object.
[datetime]$operatingsystem.LastBootUpTime.datetime
Query a VM Host
A good deal of Microsoft’s hypervisor’s (Hyper-V) as well as VMWare’s hypervisor’s instrumentation and management is exposed via WMI. The following command displays characteristics of the Hyper-V parent as well as all of its children.
get-wsmaninstance -enumerate wmi/root/virtualization/Msvm_computersystem -computername <server name>:<port if other than 5985> -authentication default -credential $cred
Create a persistent connection to a Remote System.
This is using WS-Man to create a connection to the remote system, not PowerShell. Note that the port is not used in-line with the "ComputerName".
Connect-WSMan -computername <server name> -authentication default -credential $cred -port <port if other than 5985>
This will show the configuration of the remote system, including the listener.
cd wsman:
The connection does need to be ended.
disconnect-WSMan -computername wsman.msft.net
Create and use a PowerShell Remoting Session.
Using PowerShell for remote management is much more powerful as it allows for the scripts (or script blocks) to be passed within the connection rather than requiring them to exist on the remote computer.
Note: If the script or script block that is being passed to the remote computer is using any special modules, they will need to exist on the remote computer (modules are note passed with the script).
$wsman = new-pssession -computername <server name> -port <port if other than 5985> -authentication default -credential $cred
This merely shows how to remotely execute a single PowerShell command on a remote machine and that the output is returned as a formatted object with the remote machine’s meta data attached to the results.
invoke-command -session $wsman -scriptblock {get-process}
We’ll then put the results into an object. Notice now nicely the data in the object is formatted. This is not the case when non-PowerShell commands are executed remotely (see below).
$output = invoke-command -session $wsman -scriptblock {get-process}
This shows how to tear down the remote session.
remove-pssession -session $wsman
Create and use a PowerShell Remoting Session on Several Servers
One of the most powerful features of PowerShell remoting is the ability to execute scripts on many servers simultaneously (knows as "fan out"). There is also the ability to throttle the number of servers that are simultaneously running scripts. The example below shows how to specify multiple servers within the command, but there are other (more programmatic) ways of doing this (see “get-help” for examples).
$several = new-pssession -computername <server name 1>,<server name 2>,<server name 3> -port <port if other than 5985> -authentication default -credential $cred
invoke-command -session $several -scriptblock {get-process}
$output = invoke-command -session $several -scriptblock {get-process}
The following example show how a "fan out" PowerShell command can also be executed in the background and monitored by using the “asjob” flag.
invoke-command -session $several -scriptblock {get-process} -asjob
get-job
receive-job -id <ID # listed from "get-job">
The following example shows how the output is formatted if the executed command is not a PowerShell script or cmdlet.
invoke-command -session $several -scriptblock {ipconfig /all}
When the results are placed in a PowerShell object, the object is essentially an array of single lines of text.
$output = invoke-command -session $several -scriptblock {ipconfig /all}
remove-pssession -session $several
Enter into a PSSession
The following examples show how to remote to a single end point and execute commands (in this case the commands will stop and restart the web service).
$wsman = new-pssession -computername <server name> -port <port if other than 5985> -authentication default -credential $cred
enter-pssession -session $wsman
net stop w3svc
net start w3svc
exit-pssession
remove-pssession -session $wsman