Enhancing Your Troubleshooting Toolset with PowerShell - SQL Server 2012 Internals and Troubleshooting - page 390

Working Remotely
In the i rst version of PowerShell users were constrained to working on a local computer. This was
OK if you had a single computer to manage, but many administrators work with multiple servers in
complex computing environments, and it is a major limitation to remote onto each computer in order
to use PowerShell. This was recognized and addressed in version 2.0, when WinRM was launched.
WinRM is a Windows service that runs on the target computer and allows a remote computer running
PowerShell 2.0 to communicate with it and execute PowerShell 2.0 scripts from the local computer.

From an administrator's perspective, this opens up a wealth of possibilities — from the simplicity of
now having a single management computer from which to operate, to being able to construct a full
monitoring framework within PowerShell.

To set up PowerShell remoting you must have PowerShell 2.0 installed on all the participating com-
puters. There are a couple of steps that you must perform to have everything running:

1.

On the target computer, run PowerShell as Administrator (this step won't work if you are
not running with elevated privileges). Run the Enable-PSRemoting -force cmdlet to set
up the WinRM (Windows Remote Management) service and the i rewall coni guration to
allow remoting commands to pass through:

PS WSMan:\localhost\Client> Enable-PSRemoting -force
WinRM already is set up to receive requests on this machine.
WinRM has been updated for remote management.
Created a WinRM listener on HTTP://* to accept WS-Man requests to any IP on
this machine.
WinRM firewall exception enabled.

2.

On the target computer, ensure that the computer from which you'll be executing scripts is a
trusted host by using the TrustedHosts command, as shown here:

PS C:\> cd wsman:\localhost\client
PS WSMan:\localhost\Client> Set-Item TrustedHosts SQL2012 -Force
PS WSMan:\localhost\Client> Get-Item TrustedHosts
WSManConfig: Microsoft.WSMan.Management\WSMan::localhost\Client

Name Value
---- -----
TrustedHosts SQL2012

After completing these steps you can run remote scripts. You can do this interactively with the
New-PSSession cmdlet and then enter the remote session with the Enter-PSSession cmdlet.
Alternately, you can invoke scripts on the remote machine with the Invoke-Command cmdlet. I like
to test the remote session using Invoke-Command and request the hostname to ensure that I've
connected to the remote computer correctly, as shown in the following example:

Invoke-Command -Session $sessions -ScriptBlock {Hostname}