How to Set Up Windows Server 2019 Services Management

Windows services are long-running background processes that start automatically with the operating system and provide core functionality such as networking, security, event logging, and application hosting. Managing Windows services effectively on Windows Server 2019 — including configuring startup types, recovery actions, dependencies, service accounts, and monitoring — is a fundamental administration skill. PowerShell provides comprehensive service management capabilities that go far beyond what the Services.msc GUI offers.

Viewing and Querying Services

Query current service status using PowerShell’s Get-Service cmdlet or the older sc.exe command-line utility. PowerShell provides richer filtering and output formatting capabilities.

# List all services with their status
Get-Service | Select-Object Name, DisplayName, Status, StartType | Format-Table -AutoSize

# Find all stopped services that should be running automatically
Get-Service | Where-Object { $_.Status -eq "Stopped" -and $_.StartType -eq "Automatic" }

# Query a specific service
Get-Service -Name W3SVC | Select-Object *

# Query services on a remote server
Get-Service -ComputerName "WEBSVR01" | Where-Object { $_.Status -eq "Running" } | Select-Object Name, Status

# Get service by partial name (use wildcard)
Get-Service -Name "*SQL*" | Select-Object Name, DisplayName, Status

Starting, Stopping, and Restarting Services

# Start a service
Start-Service -Name W3SVC
Start-Service -DisplayName "World Wide Web Publishing Service"

# Stop a service
Stop-Service -Name W3SVC -Force  # -Force stops dependent services

# Restart a service
Restart-Service -Name W3SVC

# Restart a service with a delay confirmation
Stop-Service -Name W3SVC -Force
Start-Sleep -Seconds 5
Start-Service -Name W3SVC

# Suspend a service (if it supports it)
Suspend-Service -Name W3SVC

# Resume a suspended service
Resume-Service -Name W3SVC

# Stop and start multiple services
"W3SVC","WAS","WMSvc" | ForEach-Object {
    Stop-Service -Name $_ -Force -ErrorAction SilentlyContinue
    Start-Sleep -Seconds 2
    Start-Service -Name $_ -ErrorAction SilentlyContinue
    Write-Host "$_ restarted: $(Get-Service $_ | Select-Object -ExpandProperty Status)"
}

Configuring Service Startup Type

Windows services have four startup types. Automatic starts when Windows boots. Automatic (Delayed Start) starts a few minutes after boot to reduce boot-time resource contention. Manual starts only when explicitly called or when another service requires it. Disabled prevents the service from starting by any means.

# Set startup type
Set-Service -Name W3SVC -StartupType Automatic
Set-Service -Name W3SVC -StartupType Manual
Set-Service -Name W3SVC -StartupType Disabled

# Set delayed automatic startup (not directly supported in Set-Service — use sc.exe)
sc.exe config W3SVC start= delayed-auto

# Verify the startup type
Get-Service -Name W3SVC | Select-Object Name, StartType

# Alternatively use sc.exe to query
sc.exe qc W3SVC

Configuring Service Recovery Actions

Configure what Windows does if a service fails. You can specify different actions for the first, second, and subsequent failures, such as restarting the service, running a program, or rebooting the server. Recovery actions are configured with sc.exe — PowerShell’s Set-Service does not expose recovery settings directly.

# Configure service recovery actions using sc.exe
# restart/5000 means: restart the service after 5000 milliseconds (5 seconds)
sc.exe failure W3SVC reset= 86400 actions= restart/5000/restart/10000/restart/30000

# Parameters:
# reset=  how many seconds until the failure count resets (86400 = 24 hours)
# actions= action/delay format, one per failure:
#   restart = restart the service
#   run = run a program
#   reboot = reboot the computer
# Example above: restart after 5s on 1st failure, 10s on 2nd, 30s on 3rd

# To run a script on failure
sc.exe failure W3SVC reset= 86400 command= "C:ScriptsServiceRecovery.ps1" actions= run/0/restart/5000/restart/10000

# Verify recovery settings
sc.exe qfailure W3SVC

Configuring the Service Account

Services run under a security account that determines their access to system resources and the network. Common service accounts include Local System (full local privileges), Local Service (limited privileges, network access as anonymous), Network Service (limited privileges, network access with machine credentials), and custom domain accounts. Using Group Managed Service Accounts (gMSA) is recommended for services that need domain privileges without manual password management.

# Change a service's logon account
# This requires the account to have "Log on as a service" rights
$ServiceName = "MyAppService"
$AccountName = "CORPSvcMyApp"
$Password = "ServiceAccountPassword123!"

# Grant "Log on as a service" right to the account
$Policy = [System.Security.AccessControl.SecurityIdentifier]
$SID = (New-Object System.Security.Principal.NTAccount($AccountName)).Translate([System.Security.Principal.SecurityIdentifier]).Value
ntrights +r SeServiceLogonRight -u $AccountName

# Change the service account
sc.exe config $ServiceName obj= "$AccountName" password= "$Password"

# Use Group Managed Service Account (recommended)
# First create the gMSA in Active Directory
New-ADServiceAccount -Name "gMSA_MyApp" -DNSHostName "myapp.corp.local" `
    -PrincipalsAllowedToRetrieveManagedPassword "WEBSVR01$"

# Install the gMSA on the target server
Install-ADServiceAccount -Identity "gMSA_MyApp"

# Configure the service to use the gMSA (no password needed)
sc.exe config MyAppService obj= "CORPgMSA_MyApp$"

Managing Service Dependencies

Services can declare dependencies on other services. A service with a dependency will not start until all its dependencies are running. View and modify dependencies with sc.exe.

# View service dependencies
sc.exe qc W3SVC
# Shows: DEPENDENCIES : HTTP / WAS

# Get dependencies in PowerShell
(Get-Service W3SVC).DependentServices
(Get-Service W3SVC).ServicesDependedOn

# Add a dependency to a service
sc.exe config MyAppService depend= W3SVC/EventLog

# Remove dependencies
sc.exe config MyAppService depend= ""

Creating a New Windows Service

Register a new application as a Windows service using New-Service or sc.exe. The application must be a Windows service executable (using .NET ServiceBase or similar framework).

# Create a new service
New-Service `
    -Name "MyAppService" `
    -DisplayName "My Application Service" `
    -Description "Long-running application service for MyApp" `
    -BinaryPathName "C:MyAppMyApp.exe --service" `
    -StartupType Automatic `
    -Credential (Get-Credential "CORPSvcMyApp")

# Create a service that wraps a script using NSSM (Non-Sucking Service Manager)
# Download nssm.exe from https://nssm.cc/
# nssm install MyScriptService "C:WindowsSystem32WindowsPowerShellv1.0powershell.exe" "-NonInteractive -File C:ScriptsLongRunning.ps1"

# Create via sc.exe
sc.exe create MyAppService binPath= "C:MyAppMyApp.exe" start= auto DisplayName= "My Application"

Monitoring Service Health

# Monitor services and alert on failures
$CriticalServices = @("W3SVC", "MSSQLSERVER", "DNS", "NTDS", "EventLog", "Spooler")

foreach ($Service in $CriticalServices) {
    $Status = Get-Service -Name $Service -ErrorAction SilentlyContinue
    if (-not $Status) {
        Write-Warning "Service $Service not found on this server"
    } elseif ($Status.Status -ne "Running") {
        Write-Warning "CRITICAL: Service $Service is in state: $($Status.Status)"
        # Attempt auto-restart
        try {
            Start-Service -Name $Service
            Write-Host "Successfully restarted $Service"
        } catch {
            Write-Error "Failed to restart $Service : $_"
        }
    } else {
        Write-Host "$Service : Running"
    }
}

Conclusion

Windows services management on Windows Server 2019 through PowerShell provides complete control over service lifecycle, startup configuration, recovery actions, security accounts, and dependencies. Configuring recovery actions ensures services automatically restart after failures, reducing manual intervention. Using gMSA accounts for service identity eliminates password management overhead for domain-connected services. Regular monitoring of critical service states, combined with automatic restart attempts, maintains server uptime in production environments.