About PowerShell
PowerShell is scripting language and command-line shell/tool by Microsoft. It offers robust capabilities in automating complex and repetitive tasks, thus significantly increasing efficiency and productivity, and hence it's original intended use for the task automation and configuration management. But you can also use it for your day to day or ad-hoc work, which I often do.
It is built on the .NET framework or in other words it is a wrapper around .Net functions/methods, making it more user-friendly and simplified interface to underlying .NET framework functionalities.
For example, the PowerShell command to get current date and time is Get-Date, which is a wrapper method that maps to the System.Console.WriteLine(System.DateTime.Now) if you were writing a equivalent C# code to achieve the same.
And although many exceptional IT Administrators are also skilled developers, they are generally not recognized as expert programmers. PowerShell gives them with simpler and easier access to the powerful features of the .NET Framework.
In very simple terms, the .NET Framework is like a big library or collection of functions, methods, types, and more, all compiled and stored inside DLL (Dynamic Link Library) files. These DLLs provide a range of ready-to-use functionalities, making it easier for programmers to build and run software, especially on Windows systems. This framework helps avoid the need to write common functions from scratch, streamlining the software development process.
About PowerShell Remoting
PowerShell Remoting is a feature of PowerShell to run PowerShell commands or scripts on one or multiple remote computers from a local computer. It relies and depends on the Windows Remote Management (WinRM) service, Microsoft's implementation of the Simple Object Access Protocol (SOAP).
Setting Up PowerShell Remoting
Before using Remoting, it must be enabled on the remote computer you would like to run PowerShell commands remotely. Fortunately, on server versions of from Windows Server 2008 R2 and above, by default has been the remoting feature installed and enabled, except on Core editions, where this varies based on the specific roles and features.
Of course, organizations Group Policy Objects (GPO) can change whether remoting is enabled by default and even if it could be enabled at all, even manually.
On client versions of Windows like Windows 7, 8.x, 10, 11 etc. it is installed but not enabled by default for security reasons.
To manually enabled the PowerShell remoting on a remote computer:
- Launch PowerShell as an administrator.
- Type
Enable-PSRemoting -Force. This command starts the WinRM service, sets it to start automatically with the system, and creates a firewall rule to allow incoming connections.
How To Use Remoting to Run Commands Remotely
For one-off commands, you can use the Invoke-Command cmdlet:
Invoke-Command -ComputerName <ComputerName> -ScriptBlock { Get-Process }
Example 1: Basic Remoting to a Single Computer
# Start a remote session to remote computer
$session = New-PSSession -ComputerName "ComputerName"
# Execute a command on the remote computer
Invoke-Command -Session $session -ScriptBlock {Get-Process}
# Close the session
Remove-PSSession -Session $session
Example 2: Running a Script Block on a Remote Computer
Invoke-Command -ComputerName "ComputerName" -ScriptBlock `
Get-Service | Where-Object { $_.Status -eq 'Running' }
}
Example 3: Remoting with specific Credentials
Invoke-Command -ComputerName "ComputerName" -Credential $cred -ScriptBlock `
Get-WmiObject Win32_LogicalDisk
}
Example 4: Running a Local Script File on a Remote Computer
Invoke-Command -ComputerName "ComputerName" -FilePath "C:\path\to\your\script.ps1"
Example 5: Running Command On Multiple Computers
$computers = "Computer1", "Computer2", "Computer3"
Invoke-Command -ComputerName $computers -ScriptBlock `
Get-EventLog System -Newest 10
}
Example 6: Using Sessions for Multiple Invocations
# First command
Invoke-Command -Session $session -ScriptBlock `
# Second command
Invoke-Command -Session $session -ScriptBlock `
# End the session
Remove-PSSession -Session $session
Example 7: Copying Files to a Remote Session
$session = New-PSSession -ComputerName "ComputerName"
# Copy the file
Copy-Item -Path "C:\local\path\file.txt" -Destination "C:\remote\path\" -ToSession $session
# Execute a command to read the file on the remote computer
Invoke-Command -Session $session -ScriptBlock `
Get-Content "C:\remote\path\file.txt" -tail 10
}
# End the session
Remove-PSSession -Session $session
Example 8: Persistent Session for a Script
$session = New-PSSession -ComputerName "ComputerName" -Credential (Get-Credential)
# Reuse the session for various commands
$scriptBlock = {
# Series of commands to run
}
Invoke-Command -Session $session -ScriptBlock $scriptBlock
# When done, remove the session
Remove-PSSession -Session $session
Example 9. Interactive Session
Enter-PSSession -ComputerName "ComputerName"
# Now you are working directly on the remote computer's PowerShell prompt.
Exit-PSSession
PowerShell Remoting Over SSH
While WinRM is the default transport for PowerShell Remoting, it also supports SSH as a transport.
But why bother with SSH at all? Maybe not for the Windows computer (although you can), but to use PowerShell to manage Linux or macOS systems remotely in a secure manner. I so far have had no need to install SQL Server in a Linux environment, except in a lab/play environment for my own education.
To use SSH:
- Install OpenSSH client on local computer and OpenSSH server component on remote computers.
- You have SSH keys or credentials for authentication.
- Use the
-HostNameand-SSHTransportparameters withEnter-PSSessionorInvoke-Command.
Transport encryption and authentication
By default, all data sent over the network is encrypted using WSMan (the protocol underneath WinRM). When using SSH, the encryption is provided by the SSH protocol.
PowerShell Remoting uses the Kerberos protocol for authentication by default. If Kerberos isn't available, NTLM is used.
Other PowerShell commands that supports remoting
Get-Command -ParameterName ComputerName
Troubleshooting
Here are a few common issues and their solutions:
- Access Denied: Ensure the user has permissions to access the remote computer. If using Kerberos, ensure that the computer is domain-joined.
- Cannot connect: Check if WinRM is running on the remote computer and if there's a firewall rule allowing incoming connections.
- Double-hop issue: By default, credentials used in a remote session can't be passed to another remote session. Solutions include using CredSSP (with caution) or storing credentials securely and forwarding them.
