Windows Server · Lesson 17
Use PowerShell for defensive inventory, evidence collection, filtering, verification, and carefully controlled Windows Server administration.
PowerShell is most valuable when it helps you understand the server before you change it. Read-only inspection should come before broad automation.
Learning objectives
Use PowerShell as a defensive Windows Server administration and verification tool.
Differentiate inspection commands from high-impact change commands.
Build repeatable read-only inventories for roles, services, users, groups, shares, firewall, Defender, tasks, logs, DNS, and DHCP.
Filter and format PowerShell output so evidence is easier to interpret.
Use PowerShell carefully on member servers and domain controllers without assuming every cmdlet applies everywhere.
Verify every administrative change with both PowerShell and the required server function.
Read-only baseline
Get-WindowsFeature | Where-Object {$_.Installed -eq $true} | Select-Object DisplayName, Name, InstallStateShows installed Windows Server roles and features.
Get-CimInstance Win32_Service | Select-Object Name, DisplayName, State, StartMode, StartName, PathNameShows service state, startup mode, account, and executable path.
Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction, DefaultOutboundActionShows firewall profile state and default actions.
Get-MpComputerStatusShows Defender health and protection state.
Get-ScheduledTask | Select-Object TaskPath, TaskName, StateCreates a task inventory.
Get-WinEvent -LogName System -MaxEvents 30 | Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, MessageShows recent operating-system events.
Safer change patterns
Get-Service -Name "ExampleService"Confirm the current state before changing a service.
Remove-ADGroupMember -Identity "Domain Admins" -Members "exampleuser" -WhatIfPreview supported changes without applying them.
Get-ScheduledTask -TaskName "ExampleTask" | Select-Object TaskName, StateConfirm the expected result before moving on.
Deeper administration review
Decision cases
The script disables many services, removes accounts, changes firewall rules, and edits security settings in one run.
The commands may be defensive in isolation, but the script does not understand the current server role or scenario dependencies.
Response
Do not execute it as a block. Convert the script into an inspection checklist, verify each target, then apply only justified changes one at a time.
Get-Service shows the service as Stopped and its display name is unfamiliar.
Demand-start and trigger-start services can be legitimate, especially on Windows Server.
Response
Inspect startup mode, executable path, required/dependent services, server-role ownership, and recent events before deciding whether to change it.
A rule has a trusted-looking display name, but the actual remote scope and profiles have not been reviewed.
Display names do not prove the rule is narrowly configured.
Response
Inspect the rule plus its port, address, service, application, profile, and direction filters before changing it.
A local account-management cmdlet does not behave as expected on a domain controller.
A domain controller uses Active Directory identities rather than the normal member-server local account model.
Response
Switch to AD-aware tools and cmdlets rather than forcing the local-account workflow.
Troubleshooting
Situation
Check spelling, then use Get-Command and Get-Module -ListAvailable. The required management module may not be installed.
Situation
Confirm whether the operation truly needs elevation. Reopen PowerShell as administrator only if the task requires it.
Situation
Filter early with Where-Object, select only relevant properties, limit event time ranges, and sort results.
Situation
Investigate Group Policy, scheduled tasks, management agents, domain policy, replication, or application self-repair.
Situation
Use the before-state, Event Viewer, dependency information, and client-side verification to identify which change affected the required service.
Situation
Confirm you are viewing the same server, same policy scope, same firewall profile, same account context, and the effective rather than merely local setting.
Fictional defensive lab
Step 01
On fictional APP-SRV, record OS/build, installed roles, services, Administrators membership, shares, firewall profiles, Defender status, scheduled tasks, and recent System events.
Step 02
Inspect one unfamiliar service using Get-Service, Win32_Service, dependency information, and Service Control Manager events.
Step 03
Review the task principal, trigger, action path, state, and last-run information without executing it manually.
Step 04
Inspect RDP or WinRM firewall rules and compare them with the management path required by the scenario.
Step 05
Choose a clearly unnecessary or misconfigured item, record the original state, use the narrowest supported change, and avoid broad pipelines.
Step 06
Re-run the relevant PowerShell checks, review fresh events, and test the required application, share, role, or remote-management function.
Common mistakes
Running copied hardening scripts without reading each command.
Using elevated PowerShell for every task even when it is not required.
Using broad modification pipelines that can affect many objects.
Assuming a successful cmdlet means the server role is healthy.
Ignoring module availability and server-role differences.
Skipping a before-state baseline.
Verification checklist
The intended configuration change is visible in PowerShell.
The GUI or effective policy is consistent when applicable.
Required services are healthy.
Required roles remain installed.
Required accounts and privileges remain intact.
Required firewall, Defender, share, task, DNS, and DHCP settings still work.
No unexpected new Event Viewer errors appeared.
Client-side tests still succeed for required network services.
Before/after evidence is documented.
No unrelated objects were changed.
Reflection
Question 1
Why should read-only commands usually come before change commands?
Question 2
What does WhatIf help you understand?
Question 3
Why can a command behave differently on a member server and a domain controller?
Question 4
Why is a successful PowerShell command not enough to prove the server is healthy?
Question 5
What should you record before running a high-impact command?
Question 6
Why are PowerShell objects more useful than plain text output?
Final Windows Server lesson
Next, combine identity, policy, Defender, firewall, patching, roles, shares, remote administration, DNS, DHCP, tasks, logs, and PowerShell into one final server verification workflow.
Open Lesson 18 →