blog-power-shell-remote-management-commands_sqUsing PowerShell for managing remote computers quickly and efficiently has been one of its main advantages. If you’re not familiar with it, these commands will get you up to speed.

Sure, you’ve heard about this PowerShell thing for years, but the OS is called Windows, not Shells, and the GUI and you have been friends for years. After all, you spent good money on your mouse and you’re going to get your money’s worth out of it. I get it, I too have resisted for years dropping to the prompt in Windows, which is strange considering I feel very comfortable in BASH.

To help you see the value in this, I wanted to share eleven very useful PowerShell commands you can use to remotely manage Windows machines. That’s right, you don’t have to RDP into a server and then open PowerShell. You can do it all from your desktop and still run PS cmdlets on remote systems. And some of those cmdlets are dead useful. So, if this sounds like something you could use, read on!

First things first

Of course, you should have PowerShell on your local machine, have your remote machine enabled for remote PowerShell, and have admin rights to the systems you want to remotely manage. And if you’re going to run scripts, you may want to adjust the execution policy. Here’s how to get that all lined up.

Download the latest version of PowerShell from Microsoft and install it. All current versions of Windows should have PowerShell, but the latest version is worth installing, and you can get that as a part of the Windows Management Framework 5.0 from

Make sure that for all computers you wish to manage remotely the WinRM service is set to start automatically and is running. You can do this in the services.msc GUI, or through local PowerShell (admin) using this cmdlet: set-service winrm -startuptype automatic

Enable remote PowerShell management on the machines to be managed using that same PowerShell (admin) session: Enable-PSRemoting -Force

If you need to set that on multiple computers, see our post for how to do this using a GPO.

The cmdlets

Remember that, in addition to the above, if you’re executing remote commands on a server (or workstation) you need to have admin rights on that remote system, as well as your local system where you will be opening the PS session as an administrative one. If your account on the local machine is not an admin on the remote one, you will have to provide the explicit credentials for an account that is admin on the remote machine.

1.      Enter-PSSession

The first cmdlet is really the most important one for us, as it is what enables you to start a PS session on the remote machine. Click the title for the MSDN page with all the details, but here’s an example to get you started.

Enter-PSSession -ComputerName RemoteServer -Port 5353 -Credential Domain\Username

The cool thing is that your prompt will be updated to reflect the remote hostname as a reminder of which box you’re on when executing commands. The title for each of the cmdlets below is linked to the online documentation in case you want more information.

2.      Invoke-Command

This very useful cmdlet lets you call scripts you have either saved to the remote machine, or can get to by drive or UNC path. You can use it instead of Enter-PSSession if you want to do a one-off, or use a comma-delimited list of computer names to run the same thing on multiple systems.

Invoke-Command -ComputerName RemoteServer -Credential Domain\Username -ScriptBlock {PScommand}

3.      Get-EventLog

Just like it sounds, this cmdlet lets you retrieve and view the Event Log from a remote system (or of course locally) and filter based on type, ID, keyword, etc.

Get-EventLog -LogName System -InstanceID c0ffee -Source “LSA

4.      Get-Process, Start-Process, and Stop-Process

Three cmdlets that are closely related, and let you see what processes are running, start new processes, and stop processes. These processes can be applications or scripts, and can be background or interactive on the Desktop.

Start-Process -FilePath “notepad” -Wait -WindowStyle Maximized

5.      Get-Volume and Set-Volume

Another set of cmdlets that are best together, with which you can query what volumes are attached to a system and manipulate them, including mounting/dismounting and changing drive letters. How often do you need to check free disk space across all your servers?

Get-Volume -DriveLetter C

6.      Get-ACL and Set-ACL

These two cmdlets can get and modify the ACL on any resource, be it file system or registry. This can simplify auditing, configuration, and specific settings for applications deployed on multiple systems.

Get-Acl -Path “HKLM:\System\CurrentControlSet\Control” | Format-List

7.      Restart-Computer and Stop-Computer

These two do exactly what it sounds like they do. Bounce or shutdown the remote machine as appropriate.

Restart-Computer -ComputerName “Server01”, “Server02”, “Server03”

8.      Test-Connection

Would not PING by any other name be just as good? Probably, and in this case, there are some useful parameters that you can use in scripts to first confirm a system is up before trying to do something else, or to just test a connection from a user’s workstation without having to first explain to them how to open a CMD prompt and then how to spell PING.

Test-Connection -ComputerName “Server01” -Count 3 -Delay 2 -TTL 255 -BufferSize 256 -ThrottleLimit 32

9.      Get-Service and Set-Service

Similar to cmdlets to manipulate processes, these two can query and set the services on the remote system, like using services.msc

Get-Service | Where-Object {$_.Status -eq “Running”}

10. Start-Job

This cmdlet can let you feed a number of lines into a run block, or invoke a PS1 script accessible on the remote machine by file path.

Start-Job -FilePath “c:\scripts\sample.ps1”

11. Set-RemoteDesktopConfig

And just in case you really need that GUI (I certainly do) you can use Set-RemoteDesktopConfig to enable and configure RDP on servers. This is very useful considering that it’s off by default, even with Server 2016.

Just one more thing, well two actually

Of course, there are a couple of alternatives to learning the PS names for the cmdlets that do the things you’ve done for years in the cmd prompt. The first is to use PSEXEC from Microsoft to simply run commands remotely on target computers. I’ve been doing that for years and have a hard time convincing myself to use PowerShell when PSEXEC works so well. But since PowerShell is the future, I am trying to do the right thing.

The second is to use the PowerShell cmdlet set-alias to create cmd prompt-like names for the PS cmdlets you are using, so at least you can work with familiar commands. There are a ton of aliases already set in PS. Just enter alias in a PS session to see what is already set. Either way, you have remote cmd-line management in the bag.