Prof. Powershell

Get the Service You Need

Here's a cmdlet that will have you knowing -- rather than guessing -- what services you're running.

When working interactively through the PowerShell console on a local machine, you can easily work with services without having to reach for a GUI. You may be familiar with the CMD tool SC.EXE, which is certainly very handy. But as I'll show you, because PowerShell is object-based we have tremendous flexibility. To see the state of your current services use the Get-Service cmdlet:

PS C:\> get-service

You should get a three-column list of services and their state. If you want to see a specific service, all you need to do is specify the service name:

PS C:\> get-service vss

Status   Name   DisplayName
------   ----   -----------
Stopped  VSS    Volume Shadow Copy

If you're like me, you probably are more familiar with services by their displayname. No problem -- simply use the -displayname parameter:

PS C:\> get-service -displayname "Security Center"

Status   Name    DisplayName
------   ----    -----------
Running  wscsvc  Security Center

But there is more to this output than meets the eye. Remember, what you are seeing on the screen is the default display set. If you pipe one of these commands to Get-Member you'll see that we're working with objects. Try something like this to see all the current properties for a given service:

PS C:\> get-service spooler | select *

Name : Spooler
CanPauseAndContinue : False
CanShutdown : True
CanStop : True
DisplayName : Print Spooler
DependentServices : {Fax}
MachineName : .
ServiceName : Spooler
ServicesDependedOn : {RPCSS, HTTP}
ServiceHandle : SafeServiceHandle
Status : Running
ServiceType : Win32OwnProcess, InteractiveProcess
Site :
Container :

So, to find all running services we can pipe the output from Get-Service to Where-object:

PS C:\> gsv | where {$_.status -eq "running"} | Sort Displayname | Select Displayname

In this example, I'm using the alias, gsv, for Get-Service. The Where-Object cmdlet filters out any service that isn't running. That output is sorted by the Displayname property and finally the Select-Object cmdlet limits the final output to the Displayname property only.

The object model gives us the flexibility to write a function like this:

Function Get-DependOn {
   Param ([string]$s=$(Throw "You must specify a service name like lanmanworkstation"))

   write "The following services depend on $s :"

   Get-Service | foreach {
      foreach ($svc in $depend) {
         if ($ -match $s) {
         write $_.displayname


When you use this function and specify a service name, it will find all the services that depend on it. The function has to get each service, look at its ServicesDependOn property and then enumerate it to see if it matches the service:

foreach ($svc in $depend) {
   if ($ -match $s) {
   write $_.displayname

When you run it, you'll get a list of each dependent service by displayname:

PS C:\> get-dependon lanmanworkstation

The following services depend on lanmanworkstation :

Computer Browser


Terminal Services Configuration

There are some limitations to Get-Service. For example, the cmdlet doesn't show you the service account. However you can use WMI to get this information. You'll also need WMI if you want to query services on a remote machine.

Now that we have services, we most likely want to do something with them such as start or stop. We'll look at that next time.

About the Author

Jeffery Hicks is an IT veteran with over 25 years of experience, much of it spent as an IT infrastructure consultant specializing in Microsoft server technologies with an emphasis in automation and efficiency. He is a multi-year recipient of the Microsoft MVP Award in Windows PowerShell. He works today as an independent author, trainer and consultant. Jeff has written for numerous online sites and print publications, is a contributing editor at, and a frequent speaker at technology conferences and user groups.

comments powered by Disqus
Most   Popular