The World According to Mitch

“Hey Mitch, I always hear you talk about running PowerShell against remote computers. How do I do that?”

There are several different ways to do this, depending on what exactly you want to do.

Preparation

We cannot simply create a machine and start working on it remotely. We have to enable remote management by first enabling PowerShell Remoting. To do that, let’s log on to a computer against which we plan to run remote PowerShell cmdlets and do just that. Use the cmdlet Enable-PSRemoting –Force. This will enable remote PowerShell for you.

*CHEAT: On a Server Core system, you can use the sconfig menu to Enable Remote Management of your servers.

**Remember: There is a chance that you will have to enter your credentials to run any of these remote cmdlets. Of course, you have to have credentials on the remote system to do anything, and if your local account does not have them then you will need to authenticate.

A single cmdlet against a single remote system

When you want to simply run a cmdlet against another computer, a lot of cmdlets (although, as I was reminded recently, not all) support the switch –ComputerName. For example:

Get-WindowsFeature -Name *DNS* -ComputerName <RemoteComputerName> 

Yes, I have blurred out the name of my client’s server, but this clearly shows that I am able to run the cmdlet against a remote server.

A single cmdlet against a group of remote systems

You may have a cmdlet that you need to run against multiple systems. For that we are going to create a session for all affected machines… using that same –ComputerName parameter that we used before.

$session-New-PSSession -ComputerName <RemoteComputerName1>, <RemoteComputerName1>

Invoke-Command -session $session {Get-WindowsFeature -Name *DNS*}

Watch:

By creating the New-PSSession (which we are cleverly calling $session), we can then use the Invoke-Command cmdlet to run everything contained in the brackets against all servers listed.

Let’s just work remotely…

Of course, you may be working on a remote system, and you want everything to run against that machine. For that we are not just going to create the PSSession, we are going to actually enter that session.

Just like in the previous example, we used the New-PSSession to create the remote session. However, unlike the previous example, we are only adding a single remote computer to the session. We then use the Enter-PSSession –ComputerName cmdlet to connect to it.

New-PSSession -ComputerName <RemoteComputerName>

Enter-PSSession -ComputerName <RemoteComputerName>

Watch:

In this screen capture, we see that at the beginning of the bash that the computer name that we specified in the previous cmdlet is listed. We created and then entered the remote session, and until we actually exit the session, we are running remotely. I always tell people that PowerShell is structured quite logically, so the exit a session, the cmdlet is Exit-Session.

Security

I will freely admit that I am not an IT Security Specialist. Rather, I am an IT Professional who is security-minded. As such, I try to eliminate unnecessary security risks in every environment that I manage. One way that I do that is by replacing the servers with a GUI (or Desktop Experience) with Server Core systems. By doing that, my clients eliminate 95% of server logons, which so often is where our security risks originate. By removing the Graphical User Interface (GUI) from servers and forcing remote management and administration, we are eliminating server security holes and reducing the attack surface of our critical servers.

Conclusion

A strong knowledge of PowerShell will give you access to an incredible set of tools and capabilities to manage your environment. I freely admit that I do not have that strong knowledge. With that said, I do know enough to make my life much easier, and with tools like PowerShell Remoting I can run the tools I need both locally and remotely with ease.

In 2014 I wrote an article called Do IT Remotely in which I showed that you do not have to go into the office to get your work done. It was not prescience – I had no idea at the time that nearly 5.5 years later the entire world would be immersed in a global pandemic, and that without the tools to work remotely we would fall into a global crisis unheard of in a century. I simply knew that occasionally working from home was easier than always having to go into the office. Being able to address issues remotely – whether from another room or from another continent – means that we are no longer tied to geography, and that when something goes down or needs fixing at an inconvenient time I do not have to drop what I am doing and rush to the office; I can simply connect to my servers remotely to fix what needs to be fixed, and then go back to what I was doing. You can call it lazy (we don’t have to go into the office) or selfish (we don’t have to drop what we are doing and run) or whatever you like… it makes our lives as systems administrators better.