5 Best PowerShell Cmdlets for Remote Services

When managing a Windows environment being able to easily navigate Windows services only helps to strengthen the skills needed to keep the environment running efficiently and smoothly. Gone are the days of managing local services on one station via the Services console in the GUI.

Environments are growing and they may even be growing on Windows Server Core instances, which may cause some slight anxiety when asking the question: "How will I ever be able to view the services on all these servers without a desktop experience?"

Once you start to get a handle on how to manage services with PowerShell, you will then be asking: "Why didn't I start this years ago!?"  In fact, you'll be asking the very same question when you start our Windows Server training. It provides everything you need to know to level up your skills.

Let's discuss just a few cmdlets that allow you to work with Windows services.

1. View Services with Get-Service

Microsoft has a short and sweet explanation for what Get-Service does:

"Gets the services on the computer."

There's really no more to say about it from a foundational perspective. Get-Service can be run in a PowerShell console all by itself with no switches or parameters. It will output all the services that are installed on the local computer. The default output will have column headers like so:

Status     Name     DisplayName

———     ——     —————-

Undoubtedly, most servers and PCs will have quite a bit of services that fly down the console windows, so likely the last 10-15 services you actually see in the output. What is nice about Get-Service is that it has a handy parameter called -Name. If the service name is known and you want to know the status just type in the service name using the -Name parameter. For example, you may want to check on the Windows Update service like so:

Get-Service -Name wuauserv

Status        Name                DisplayName

———           ——       —————-

Running         wuauserv   Windows Update

You can also use Get-Service with the -DisplayName parameter to filter on the display name of the service. The Windows Update service is one of those oddball services where the actual name isn't really a good representation of what it actually is.

Suppose you don't know the 'official' name or display name of the service you are needing to check, but you know it probably has a specific term in one of the names. This is where the wildcard (*) is your best friend! For example, you may need to check a specific service that has to do with Hyper-V, but you can't quite remember the service name. Try something like this:

Get-Service -DisplayName Hyper-V*

This will return to you all the services in which the display name starts with 'Hyper-V'. Feel free to use Get-Service and wildcards to filter through both the names and display names to find the desired service. It is also quite okay to use multiple wildcards. You may know that a certain term is in the name, but you may not know where that term is in the name. Using our Hyper-V example, you can bookend your term or characters with wildcards to search:

Get-Service -DisplayName *Hyper-V*

2. Managing Services With Stop-Service and Start-Service

Both Start-Service and Stop-Service can be used in place of Get-Service to do exactly what they say for any particular service. If you know the service name or display name, you can just simply use that information to start/stop the desired service:

Stop-Service -DisplayName 'Windows Update'

Start-Service -Name wuauserv

It is also possible to use wildcards when using the -Name and -DisplayName parameters for Stop-Service or Start-Service, but it is advisable not to do this because it is possible to either start or stop multiple services at once that you may not intend to. It would be a best practice to use Get-Service to find the exact service name before proceeding with Stop-Service or Start-Service. It's worth noting that when using these cmdlets, there is no output by default if the command executes without error, which makes using wildcards that much riskier due to the fact that you get no feedback on what services were actually changed.

When using Start-Service or Stop-Service, if the service is already in the state that you are wanting to change it to, no error or message will display this. For instance, if the Windows Update service is already running, and you use Start-Service on it, the command will seem to execute without error. It is worth noting that there is also a Restart-Service cmdlet that may get you to the same ends with fewer commands, so check that out in Microsoft Docs.

3. Creating Services With New-Service

New-Service is a great way to create Windows services and may possibly get you lots of brownie points with your developer teams. Developers who write applications that run as Windows services have used so many third-party applications in years past that do exactly what New-Service does natively. Some developers may be a bit hesitant to move toward Windows Server Core platforms because they need their GUI apps to install services. Those days are now gone!

All that is required to use New-Service is an executable application. Traditionally, this would be an .exe application. Having the following parameters would be a good start when testing with this process:

• service name (-Name)

• service display name (-DisplayName)

• application path to run (-BinaryPathName)

• account service runs as (-Credential)

• description of the service (-Description)

• how the service will start (-StartupType)

For more detail on these parameters, please consult the Microsoft Docs entry linked above. By way of example, here's how to create a service using New-Service:

New-Service -Name “myawesomesvc” -DisplayName “My Awesome Service” -BinaryPathName “C:\Apps\awesome.exe” -StartupType Manual -Description “One service to rule them all!”

This command will set up a new Windows service that will be listed in with all the rest on the machine. Notice that the -Credential parameter wasn't used. This isn't required if the intention is the application will be run by the local System account. If the application needs to run as a specific user or even a domain user, then the -Credential parameter will need to be used to set that in place and store the password for the account.

If you start to test New-Service for any services you want to install, keep in mind that there is a Remove-Service cmdlet, but it was not introduced until PowerShell 6.0. If you need to remove services you have created and you are using a PowerShell version lower than 6.0, it would be best to use the legacy sc.exe utility to do so. Keep in mind that a reboot will be needed to fully remove the service, as you will still see it in any service listing even after using the utility to delete your service:

C:\> SC DELETE myawesomesvc

4. Managing Services on Remote Computers with Get-Service

Getting to know these foundational cmdlets not only helps with managing a local server/PC, but it will easily translate into managing services on remote machines. Nothing is more mundane than having to RDP to a remote server just to either run your new fancy cmdlets, or worse pull up the Services console to click Stop/Start/Restart on a particular service, and then sign out. These cmdlets we've discussed can do most, if not all, of these things right from your local machine, assuming your domain account has the administrative privileges on said remote machines.

Say you get a phone call from a peer saying that the My Awesome Service isn't running on Server02. Wouldn't it be nice to say, "No problem, give me just a few seconds…" as you type:

Get-Service -Name myawesomesvc -ComputerName Server02 | Start-Service

By the time it took you to type that line and press enter, it's already started. You then reply "OK, it's up and running!" You hopefully will get some positive feedback as to how quick you were able to do this.

Notice that in the scenario in which you are managing remote services, it is necessary to first retrieve the service with Get-Service and then pass it through the pipeline to the Start-Service cmdlet. There is no way to use Start-Service with the -ComputerName parameter, as the parameter doesn't exist with that cmdlet.

Keep in mind that all the discussion above for Get-Service can be used on remote machines, as long as you include the -ComputerName parameter.

Final Thoughts

Getting more familiar with these foundational cmdlets will certainly improve your PowerShell skills as you become more familiar with how they operate. Using these cmdlets for managing local and remote services will certainly make some aspects of your role a tad easier and more streamlined, especially in a Windows domain environment.

Just think about the possibilities of bulk managing services on multiple machines and creating services to deploy to a cluster of servers. What would be a very repeatable and mundane task can be crafted into a PowerShell script to not only allow this task to complete quickly, but also with less human error. Not knowing how to manage Windows services with PowerShell would be a…disservice!