Managing remote servers and sessions in PowerShell

Software Development
#1

Hello Everyone,

We have arrived to the the last topic of PowerShell. In this will explore about Managing remote servers and sessions in PowerShell.

As with many system administration tools, PowerShell only provides so much benefit to your organization without being leveraged against multiple systems. In most scenarios this involves executing PowerShell cmdlets or scripts in such a way that the actions are performed against remote systems.

Let’s look at some of the different options PowerShell brings to the table in the way of remote management. We’ll also review some of the requirements needed for using this functionality, and some tips for getting the most out of PowerShell remote management.

Managing remote servers with PowerShell

The most basic method of using PowerShell to perform management tasks against remote servers, or Windows computers in general, is using the -ComputerName parameter. We discussed how to find cmdlets which accept the -ComputerName parameter in our post on using the PowerShell help features.

Many of the standard PowerShell cmdlets you’ll use every day (Get-Process, Get-Service, Get-EventLog, etc.) allow you to perform actions against remote computers in this manner. It’s also worth noting that -ComputerName will accept multiple hostnames, allowing you to simultaneously target a list of computers without having to execute the cmdlet multiple times. Managing remote computers using this method bypasses some of the requirements for persistent PowerShell remote sessions.

Enable PowerShell remote sessions

The big feature set introduced in PowerShell version 2.0 was the remoting feature. Using WinRM (Windows Remote Management) PowerShell remoting enables you to create a remote session to a computer. The functionality is similar to familiar remote administration tools such as telnet or SSH, but utilizes industry standard ports and protocols such as HTTP and SOAP.

Though most Windows systems on your network should have at least PowerShell 2.0 installed (it’s the default on Windows 7 and Windows Server 2008), PowerShell remoting is not enabled by default until Windows Server 2012. To enable PowerShell remoting the WinRM service must be started and set to start automatically, and a firewall rule must be enabled to allow communication to the server.

Fortunately, PowerShell remoting can be enabled in a single step using the Enable-PSRemoting cmdlet with the -Force switch from an elevated PowerShell prompt. Because Windows Server 2012 and later have PowerShell remoting enabled by default, there’s no need to run Enable-PSRemoting unless it has been disabled for some reason.

Why use remote sessions?

There are a couple of significant reasons why remote sessions should be used in some scenarios rather than individual cmdlets against remote computers, the first being performance. When you run a cmdlet like Get-Service against ten different computers, the local computer has to execute the command and process the information from each computer. When remote sessions are leveraged, each remote computer runs the command, spreading the workload across the ten computers. Once you start talking about PowerShell scripts that run against hundreds or thousands of computers, performance becomes one of your top priorities.

Another reason to use remote PowerShell sessions is the ability to use multiple cmdlets within the same session, allowing you to perform multiple actions against each server, or even run entire scripts remotely. The potential for using remote sessions in this manner ranges from automating the performance of software inventories, to periodically restarting services across an entire data center, or whatever process you can dream up.

Creating remote sessions

While the benefits for using remote PowerShell sessions are clear, they can be a little more complex to work with than simply using a cmdlet with the -ComputerName parameter. The simplest way to initiate a remote session is using the Invoke-Command cmdlet. Invoke-Command, along with the -ComputerName and -ScriptBlock parameters, allows you to define the remote servers to manage and the administrative commands to be run remotely.

For more comprehensive PowerShell remoting scenarios you can manage sessions as their own entity by first creating a session using the New-PSSession cmdlet. The upside to using New-PSSession is that the session persists throughout multiple Invoke-Command instances, allowing you to pass variables and objects to other cmdlets in your script. Persistent sessions can be created using the New-PSSession cmdlet and assigning it to a variable, which can later be referenced using Invoke-Command, and eventually closed using Remove-PSSession . This example illustrates the use of a persistent session, without which the second instance of Invoke-Command would fail:

$s = New-PSSession -ComputerName “SRV1” Invoke-Command -Session $s -ScriptBlock {$services = Get-Service} Invoke-Command -Session $s -ScriptBlock {$services | Where-Object {$_.Status -eq “Stopped”}} Remove-PSSession $s

Sessions and credentials

In the examples given above, the current user’s credentials are used to create the remote session and execute commands against the remote server. Both the Invoke-Command and New-PSSession cmdlets accept PowerShell credential objects, which are created using the New-PSCredential cmdlet. The benefit of using this method is that an administrator can require credentials be provided in support of specific actions targeting remote servers.

PowerShell provides numerous methods for efficiently managing a single local server or thousands of servers across the globe. Becoming familiar with the PowerShell toolset could be critical in remaining a valuable resource in your workplace.

Thankyou.