Finally! Full-On Remote Computer Finally! Full-On Remote Computer Management (with PowerShell v2)Management (with PowerShell v2)Don JonesDon JonesConcentratedTech.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 InstructorAbout 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 RemotingPowerShell 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 TechnologiesUnderlying 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 MechanismTransport 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 SecurityWinRM 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 SecurityMore 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 RemotingPowerShell 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 RequirementsGeneral 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 DomainConfiguring 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-MachineConfiguring Per-Machine

Run Set-WsManQuickConfig– Starts the service, enables a firewall exception,

and allows WinRM listening

Non-Domain EnvironmentNon-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 StepsWorkgroup 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 StepsWorkgroup 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 WinRMWorkgroup 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 SettingsWinRM Service Settings

EnableEnable

Enable if you have

pre-WinRM 2.0

listeners

Enable if you have

pre-WinRM 2.0

listeners

Remember, this configured WinRM 2.0!

Remote Shell SettingsRemote Shell Settings

Enable(Default if setting is

not configured)

Enable(Default if setting is

not configured)

Good ideaGood idea

Only useful is Windows PowerShell v2 is installed and if WinRM is enabled for listening

TroubleshootingTroubleshooting

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

TroubleshootingTroubleshooting

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 IssuesOther 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

PSSessionsPSSessions

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-PSSessionNew-PSSession

Numerous parameters allow customization– Authentication mechanism– Alternate credential– Etc

Read Help New-PSSession for all the details

Session ManagementSession 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 TipsSession 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 SessionsUsing 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 Remoting1: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-Demand1: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 Remoting1:many Remoting

Use Invoke-Command to specify a command

Either specify computer names… …or pass it an array of PSSession

objects

Why Sessions?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 ResultsInvoke-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 ComputersMultiple 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 TricksInvoke-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!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!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!

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