PowerShell Remoting

Finally! Full-On Remote Computer Management (with PowerShell v2) Don Jones ConcentratedTech.com Pre-requisites for this presentation: 1) Strong understanding of basic Windows administration 2) Basic understanding of Windows PowerShell v2 use Level: Advanced

This slide deck was used in one of our many conference presentations. We hope you enjoy it, and invite you to use it within your own organization however you like. For more information on our company, including information on private classes and upcoming conference appearances, please visit our Web site, www.ConcentratedTech.com . For links to newly-posted decks, follow us on Twitter: @concentrateddon or @concentratdgreg This work is copyright ©Concentrated Technology, LLC

About the Instructor Don Jones Contributing Editor, technetmagazine.com IT author, consultant, and speaker Co-founder of Concentrated Technology Seven-time recipient of Microsoft ’s Most Valuable Professional (MVP) Award Author and Editor-in-Chief for Realtime Publishers Trainer for www.CBTNuggets.com

PowerShell Remoting Connects two copies of Windows PowerShell over the network The “client copy” (where you sit) sends commands to one or more “server copies” (remote machines) Remote machines execute the commands locally, and send back the resulting objects

Underlying Technologies Relies on PSSessions , an object that represents an authenticated connection between two computers Persist the connection in a variable Persist multiple connections in an array “ Persist” does not mean “constantly send traffic;” it re-connects on-demand and invisibly

Transport Mechanism Communications are handled by Windows Remote Management (WinRM), a service that implements Web Services for Management (WS-MAN) WinRM 2.0 uses HTTP and HTTPS as the underlying transport, on port 5985 (by default)

WinRM Security WinRM must be allowed to listen for requests Incoming requests are tagged with an application; this lets WinRM route requests to the correct app – like PowerShell Apps must be allowed to register as listeners with WinRM Local firewalls must obviously allow the traffic

More WinRM Security By default, WinRM uses Kerberos Doesn ’t transmit passwords at all Ensures mutual authentication of client and server Allows your credential to be delegated to the remote server Allows the use of alternate credentials WinRM can use HTTPS, which encrypts all traffic sent to and from WinRM

PowerShell Remoting “ Remote Shell” registers PowerShell as a WinRM listener PowerShell automatically applies encryption to the traffic it submits to WinRM PowerShell acts both as a client (where you sit) and a server (on the remote machine) Normally only Administrators can remotely invoke the shell

General Requirements Windows PowerShell v2 .NET Framework v2 WinRM Service v2 Win2008R2 and Win7 initial appearance Integrated in PowerShell v2 install for older OSs

Configuring in a Domain You will typically configure WinRM and Remote Shell in a domain environment GPO settings exist to do this – and the domain provides a common authentication mechanism (via Kerberos) Super-simple, super-easy – no need for manual configuration on a per-machine basis

Configuring Per-Machine Run Set-WsManQuickConfig Starts the service, enables a firewall exception, and allows WinRM listening

Non-Domain Environment Trickier! Some terms: Client: The machine you ’re sitting in front of Server: The remote machine you want to manage You ’ll need to run several steps to make this work

Workgroup WinRM Steps Server: Enable-PSRemoting -force Won ’t work if network card is set to “Public” (vs. “Office” or “Home” or whatever) Administrator account must have a password

Workgroup WinRM Steps Client: Enable-PSRemoting WinXP only: Set-ItemProperty –Path HKLM:\System\CurrentControlSet\Control\Lsa –Name ForceGuest –Value 0 (zero) Set-Item WSMan:\localhost\Client\TrustedHosts –Value server –Force -concat

Workgroup WinRM Caution: You are sending a credential from your client to server without verifying the server ’s identity; only do this in a trusted environment For more info, see http://blogs.msdn.com/wmi/archive/2009/07/24/powershell-remoting-between-two-workgroup-machines.aspx .

WinRM Service Settings Enable Enable if you have pre-WinRM 2.0 listeners Remember, this configured WinRM 2.0!

Remote Shell Settings Enable (Default if setting is not configured) Good idea Only useful is Windows PowerShell v2 is installed and if WinRM is enabled for listening

Troubleshooting Ensure PowerShell is being run as Administrator Caution: With UAC enabled, explicitly run as Administrator! No config needed to send remote commands; config needed to receive them Set-WSManQuickConfig or Enable-PSRemoting

Troubleshooting Ensure WinRM service starts automatically Default on server OS Disabled by default on client OS Use Set-Service cmdlet with –computerName to remotely change startup mode on multiple computers

Other Issues See help about_remote_troubleshooting : Administrators in other domains Remoting for non-administrators Using an IP address vs. a computer name Connecting from a workgroup-based computer Adding computers to the “trusted hosts” list Alternate ports for remoting Proxy servers with remoting Etc

PSSessions Use New-PSSession to create a new remoting session Pass an array of computer names to -computerName to create multiple new sessions Save the session(s) in a variable for later re-use

New-PSSession Numerous parameters allow customization Authentication mechanism Alternate credential Etc Read Help New-PSSession for all the details

Session Management Remove-PSSession : Close connection and delete session object No need to do this when you ’re completely finished – just close the shell Sessions do consume memory on both ends – so don ’t leave them sitting idle for no reason Get-PSSession : Get all of your currently-defined PSSessions No way to access others ’ sessions, even on the same machine

Session Tips Setting –throttleLimit on New-PSSession limits the number of sessions active at once – helps conserve resources Use New-PSSessionOption to create a new “option object” that sets various advanced options; pass the resulting object to –sessionOption to apply those options when creating new sessions

Using Sessions Two ways: 1:1, or interactive 1:many, or batch Both techniques require that you establish the session first Trick: If you have multiple sessions in a $sessions variable… $sessions[0] is the first $sessions[1] is the second (and so on)

1:1 Remoting Use Enter-PSSession and provide a session object Prompt changes to show which computer ’s shell you’re now using Exit-PSSession exits and returns you to your local shell

1:1 Remoting On-Demand Enter-PSSession also provides parameters to create a new session on-demand Useful for creating one-off, ad-hoc remote sessions Session is automatically deleted when you run Exit-PSSession

1:many Remoting Use Invoke-Command to specify a command Either specify computer names… … or pass it an array of PSSession objects

Why Sessions? You ’re always using a session with Enter-PSSession or Invoke-Command If you use –computerName , the session is created ad-hoc and deleted immediately If you use –session , you can pass session objects that have already been created Pre-create the sessions if you will use them more than once in a sitting – saves typing credentials and stuff over and over

Invoke-Command Results PowerShell tacks on a “PSComputerName” property which contains the computer that the result came from Makes it easy to separate and distinguish the results Output is serialized into XML on the remote computer, and the de-serialized back into objects in your copy of PowerShell (why? XML transmits across the network easily)

Multiple Computers Invoke-Command automatically throttles how many computers it sends commands to in parallel -ThrottleLimit lets you modify the default throttle Helps improve performance; means you may have to wait a bit when doing a large number of computers

Invoke-Command Tricks -command is an alternate name for –scriptblock , which is the real parameter name -scriptblock takes a {script block} -filePath uses a local script file (.PS1) -hideComputerName – hides computer name in output (it ’s still accessible as a property of the output objects) Read help for more!!

More! You can also have Invoke-Command run as a background job ( -asJob parameter); look up Help *-Job for details on working with jobs Quick example…

Thank You! Please feel free to pick up a card if you ’d like copies of my session materials I ’ll be happy to take any last questions while I pack up Please complete and submit an evaluation form for this and every session you attend!

PowerShell Remoting

In this document