Learn PowerShell - Working with Services & Processes

#Introduction

In episode 14 you learned to control many computers via remoting — the power to run commands anywhere. The next question: what needs controlling inside those computers? The answer is almost always the same: running services, living processes, scheduled tasks, and the traces left behind.

This episode covers four core domains of Windows administration with PowerShell: services and their control, processes and their properties, scheduled tasks, and event logs — reading system traces with modern cmdlets.

#Windows Services: Get-Service and Friends

Services are programs that run in the background without an interface — like a building's receptionist who's always on standby. Get-Service lists all services along with their status:

Get-Service

The output Status column contains Running, Stopped, or StartPending. Filtering running services:

Get-Service | Where-Object Status -eq 'Running'

Services are referenced by their name, not display name. Use the -DisplayName parameter if you're searching by display name.

#Controlling Services

The control commands are simple: Start-Service, Stop-Service, Restart-Service, and Set-Service.

Restart-Service -Name W3SVC

Set-Service -Name W3SVC -StartupType Automatic

Set-Service changes the service configuration, not just status. -StartupType accepts Automatic, Manual, Disabled, and others. Disabling unused services is a common hardening practice.

#Dependencies

Services don't stand alone — one depends on another, like building floors supporting the floor above. PowerShell shows this relationship directly:

(Get-Service -Name Spooler).DependentServices

DependentServices are the services that depend on this service; ServicesDependedOn are the services it needs. Before stopping a service, check DependentServices first so you don't kill other services unknowingly.

#Processes: Get-Process and Friends

If services are permanent building residents, processes are temporary visitors — born, work, then leave. Get-Process lists active processes with important properties:

Get-Process | Sort-Object CPU -Descending | Select-Object -First 5 Name, CPU, WorkingSet64

CPU is the total CPU seconds used; WorkingSet64 is the physical memory used in bytes. To read memory in megabytes:

Get-Process | Sort-Object WorkingSet64 -Descending |
    Select-Object -First 5 Name, @{n="MemoriMB"; e={[math]::Round($_.WorkingSet64/1MB)}}

These properties are the basis of monitoring: scripts that check when WorkingSet64 crosses a certain threshold can trigger alerts or restart applications.

#Controlling Processes

Start-Process notepad

Stop-Process -Name notepad

Wait-Process -Name installer -Timeout 60

Stop-Process can use -Name or -Id. Wait-Process makes a script wait until a process finishes or times out — very useful when running an installer that must complete before the script continues. Start-Process also supports -Wait to block execution until the application closes.

#Scheduled Tasks

Scheduled tasks are "assistants that work on a schedule" — running scripts at certain times or events without intervention. The four main cmdlets: Get-ScheduledTask, New-ScheduledTask, Register-ScheduledTask, and Unregister-ScheduledTask.

Get-ScheduledTask

Creating a new task involves three parts: the action (what to run), the trigger (when), and the principal (as whom):

$action  = New-ScheduledTaskAction -Execute "powershell.exe" `
    -Argument "-File C:\Scripts\backup.ps1"
$trigger = New-ScheduledTaskTrigger -Daily -At "02:00"
$principal = New-ScheduledTaskPrincipal -UserId "NT AUTHORITY\SYSTEM" `
    -RunLevel Highest
 
Register-ScheduledTask -TaskName "Backup Malam" `
    -Action $action -Trigger $trigger -Principal $principal

This separation is like writing a command letter: the action is the command's content, the trigger is its delivery time, the principal is its sender. Separating the three makes recombination easy — the same action can be triggered at different times without rewriting everything.

To run with a specific user's credentials (not SYSTEM), use -User and -Password on Register-ScheduledTask. Credentials are stored encrypted by Task Scheduler, but still avoid writing plaintext passwords inside scripts.

#Event Logs: Get-EventLog vs Get-WinEvent

Every application and service leaves traces in the event log — the system's diary. PowerShell has two cmdlets:

• Get-EventLog — the old (legacy) cmdlet, easy to read, but only for classic log formats and abandoned by Microsoft.
• Get-WinEvent — the modern cmdlet, supports new logs, much faster, and required for new scripts.

Get-WinEvent -LogName System -MaxEvents 10 |
    Where-Object LevelDisplayName -eq 'Error'

#FilterHashtable

The -FilterHashtable parameter makes queries far more efficient than filtering results in the pipeline:

Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    ID        = 4624
    StartTime = (Get-Date).AddDays(-1)
}

The filter hashtable is evaluated at the source — far faster than fetching all events then filtering them in the pipeline. Common keys: LogName, ID, Level, StartTime, and EndTime.

#XPath Queries

For complex queries, -FilterXPath accepts XPath expressions — the structured query language for XML documents. Event logs are essentially XML, so XPath can filter combinations of conditions:

$xpath = "*[System[EventID=4625 and TimeCreated[timediff(@SystemTime) <= 86400000]]]"
Get-WinEvent -LogName Security -FilterXPath $xpath -MaxEvents 5

XPath brings queries to a high level of precision — suitable for combining event IDs, levels, and time ranges in one expression. For everyday needs, FilterHashtable is enough; XPath is needed when the combined conditions get complex.

#Writing Events

Besides reading, you can also write events so your scripts' activity is recorded:

$evt = New-Object System.Diagnostics.EventLog('Application')
$evt.WriteEntry("Backup selesai: 120 file", 'Information', 1001, 1)

Reading and writing events makes your scripts part of the system's audit trail — a combination highly valued during incident investigations.

#Conclusion

This episode completes the daily administration toolbox: services with Get-Service, Start-Service, Stop-Service, Restart-Service, and Set-Service along with dependency relationships; processes with Get-Process, Start-Process, Stop-Process, and Wait-Process plus CPU and memory properties; scheduled tasks assembled from action, trigger, and principal; and event logs read efficiently with Get-WinEvent and FilterHashtable.

Key takeaways:

• Check DependentServices before stopping a service.
• WorkingSet64 and CPU are the raw materials of process monitoring.
• A scheduled task = action + trigger + principal, separated and combinable.
• Use Get-WinEvent, not Get-EventLog, for new scripts.
• FilterHashtable filters at the source — fast and concise.

Services and processes are the application layer; beneath them is a deeper system information layer. Episode 16 opens access to that system data repository: WMI & CIM — Get-CimInstance, Win32 classes, WQL queries, and relationships between classes. See you in episode 16!