PowerShell Remoting - setup and remote management

Here is a minimum of theory, mainly the practical part. Describes how to configure WinRM, how to change the network adapter profile, provides a script to add to TrustedHosts with filtering, explains why trusted hosts are needed, and consider superficially remote connections so that you can sit down and immediately admin remote machines.

The easiest way to configure remote control is to run Enable-PSRemoting in powershell with administrative rights. When this happens the following:

• WinRM service will start (if it is restarted)
• WinRM service goes into state - automatic start at start
• WinRM listener will be created for HTTP traffic on port 5985 for all local IP addresses
• a firewall rule will be created for the WinRM listener. Attention, this item will end with an error if any of the network cards has a network type of "public", because opening a port on such a card is not good. If you had such an error when configuring, change the profile of this network card with the Set-NetConnectionProfile cmdlet and then run Enable-PSRemoting again. If you need a network card with the “Public network” profile, run Enable-PSRemoting with the -SkipNetworkProfileCheck parameter in this case, firewall rules will be created only from the local network.

After that, you must allow to connect to the remote machine from the machine with which the control will take place. This is done for security reasons in order to reduce the risk of hacking a remote control session or DNS by substituting yourself for a remote machine and to prevent the execution of scripts on machines that you are not allowed to forcibly.

To check where you can connect use:

get-item wsman:\localhost\Client\TrustedHosts 

for permission to connect to all

 set-item wsman:localhost\client\trustedhosts -value * 

If you open access for all by specifying * then WinRM will connect to ALL machines without verification. Remember that you open yourself up for potential hacking from a local network. It is better to specify the addresses of the hosts where you need to connect, then WinRM will reject all other addresses or names. If the machine being managed is in the domain, it will trust all the machines in this domain. If it is not in the domain, or in another domain, then you need to specify in TrustedHosts the address or name of the machine we will connect to. Adding yourself to the machine to which we connect is not necessary.
')
in the help are specified commands, I slightly redid them into a script

 ###################################################################################### #  NewHost   TrustedHost        #          # .\Add-TrustedHost.ps1 192.168.2.1 ###################################################################################### param ( $NewHost = '192.168.2.89' ) Write-Host "adding host: $NewHost" $prev = (get-item WSMan:\localhost\Client\TrustedHosts).value if ( ($prev.Contains( $NewHost )) -eq $false) { if ( $prev -eq '' ) { set-item WSMan:\localhost\Client\TrustedHosts -Value "$NewHost" } else { set-item WSMan:\localhost\Client\TrustedHosts -Value "$prev, $NewHost" } } Write-Host '' Write-Host 'Now TrustedHosts contains:' (get-item WSMan:\localhost\Client\TrustedHosts).value 

he checks to see if there is such an entry, if not, he adds it to the list. You can call from the command line specifying the address or name.

There is a difference to indicate the name or address. If there is only an address in TrustedHosts, then opening the session by name will not work, and vice versa - if you specify a name, it will attach to the address and it will not work. Consider it.


Often there is a link to the team

 WinRM quickconfig 

it's not the same as Enable-PSRemoting

---

Remote connections
1. Sessions 1-to-1
are opened by the team

 Enter-PSSession -ComputerName Test 

You will get a shell on the remote machine. You can connect to yourself by specifying localhost. Alternative credits are specified with the -Credential parameter, the output is by the Exit-PSSession cmdlet

The limitations are as follows:

• you can not make a second jump - only 1 session, inside the session you can not connect further
• You cannot use commands that have a graphical interface. If you make the shell hang, press Ctrl + C to hang
• you cannot run commands that have your own, for example, nslookup, netsh
• you can run scripts if the launch policy on the remote machine allows them to run
• you can not cling to an interactive session, you go as a “network logon” , as if clinging to a network drive. Therefore, logon scripts will not start, and you may not get a home folder on a remote machine (an extra reason not to map home folders logon scripts)
• you cannot interact with the user on the remote machine even if he is logged in there. You won’t be able to show him the window or print it to him.

This method is best for simple operations, went in, pulled the server and disconnected. If you need to keep the variables in the osprey, you need a long operation (many hours or days), you need more administration capabilities, then you need to use the more advanced technique.

Comment.
objects transmitted over the network are cut off and stop being alive. Methods are removed from them, properties remain. Pull the object on your car, pokoldovat and shove back will not work. If you need to write more, I will add separately.

2. 1-to-many sessions

 Invoke-Command 

we define what we will execute so:

 $sb = {         } 

we transfer to remote machines Test1 and Test2

 Invoke-Command -ComputerName Test1, Test2 -ScriptBlock $sb 

at a time, you can throw in 32 cars. If alternative credits then use the -Credential parameter

To send the entire script instead of the -ScriptBlock parameter, we write -FilePath, the remote machine does NOT need to have access to the file, it will be parsed, transferred via HTTP and executed from that side.

Remember that on the other side there will be a new Osprey, so your script will not receive values ​​from your console, and the script variables may be on that side empty. Therefore, send immediately complete instructions and scripts with parameters.

To fully use Invoke-Command, you need to be able to turn strings into script blocks. For example, you have commands that depend on some list, you need to generate a string, turn it into a ScriptBlock and send it to a remote computer:

 $sb = [Scriptblock]::Create( $SomeString ) 

kuda78
The article missed a very important point - the transfer of parameters to the script on a remote machine.

$ deployRemote = {
param (
[string] $ targetEnvName,
[string] $ targetUsername)
$ Global: ErrorActionPreference = "Stop"
# ...
}

Invoke-Command-Session $ session -ScriptBlock $ deployRemote -ArgumentList ($ targetEnvName, $ targetUsername)

Yes indeed missed. I did it deliberately in order not to obstruct the review with parameters and descriptions. Thank. The -ArgumentList parameter works with both script blocks and scripts.

3. Sessions
This is when a copy of the poker constantly hanging in the memory is created on that side, and commands are sent to it. As a result, you can reconnect to it, run a long run for execution, cling from different scripts or different users. For example, you have a set of scripts solving one task in parts, each of them can connect in turn to one remote session, see the results of previous commands, have one loaded module, common variables, common environment, until the session is forcibly closed.

Creating a session is done by the New-PSSession cmdlet, the result can be put into a variable.

 $DC01 = New-PSSession -ComputerName DC01 $Controllers = New-PSSession DC01, DC02, DC03 

you can use the same connection parameters as in Invoke-Command

How to use:
if 1-to-1

 Enter-PSSession -Session $DC01 

if 1-to-many

 Invoke-Command -Sessions $Controllers -ScriptBlock {get-eventlog -logname security -newest 50} 

you can see which sessions are open using Get-PSSession, close Remove-PSSession
close all sessions altogether

 Get-PSSession | Remove-PSSession 

hook into the session, you can use Connect-PSSession, disconnect through Disconnect-PSSession

Invoke-Command can create a disconnected session immediately, it sends commands for execution and disconnects, you can later connect and download the results of the work. This is done with the -Disconnected option. Getting results through the Recieve-PSSession cmdlet.

Sessions have a lot of settings, perhaps even creating sessions with a truncated set of commands, modules, etc. Called custom endpoints