Windows Server · Lesson 01

Windows Server Competition Workflow

Secure Windows Server by identifying its job first, mapping its dependencies, hardening carefully, and proving that every required role still works after your changes.

A server is valuable because other systems depend on it. The safest competition workflow protects that dependency while reducing unnecessary privilege, exposure, software, and persistence.

Lesson Snapshot

Workflow stages5

Primary focusDependencies

VerificationClient + server

GoalSecure + functional

Learning objectives

What this lesson should help you do

Explain why Windows Server must be hardened according to its assigned role rather than like a normal workstation.

Identify required server roles, services, users, shares, remote-management paths, and network dependencies before making changes.

Build a safe baseline using Server Manager, Services, Windows Security, Event Viewer, PowerShell, and role-specific consoles.

Prioritize changes by security impact, dependency risk, and scenario requirements.

Apply small defensive changes while preserving authentication, name resolution, address assignment, file access, and remote administration.

Verify the server from both the administrator and client perspective after meaningful changes.

Core idea

The server's job determines the safe hardening path

A domain controller, DNS server, DHCP server, and file server all expose different services because they perform different jobs. Security decisions must preserve those jobs.

Competition boundary

Scenario requirements override generic checklists

Do not disable a role, service, account, port, or feature simply because a checklist says it is usually unnecessary.

Understand the dependency first, then make the narrowest justified change.

Scenario questions

Ten questions to answer before touching the server

Is this server a domain controller, DNS server, DHCP server, file server, application server, or a combination?

Which roles are explicitly required by the scenario?

Which clients or users depend on this server?

Does the server host Active Directory Domain Services?

Does it provide DNS or DHCP to the network?

Are SMB shares required?

Is RDP or WinRM required for administration?

Are there required applications or third-party services?

Which accounts are administrators, service accounts, or ordinary users?

Which changes could interrupt authentication, networking, file access, or remote administration?

Tool map

Where to go in Windows Server

Server Manager

Start → Server Manager

Installed roles and features, server health, services, local server configuration, and role-specific management links.

Computer Management

Win + R → compmgmt.msc

Local users and groups, shared folders, Event Viewer, Task Scheduler, devices, storage, and service-related context.

Services

Win + R → services.msc

Required service state, startup type, dependencies, and whether a role relies on the service.

Event Viewer

Win + R → eventvwr.msc

System, Security, Application, and role-specific events that help explain failures or suspicious activity.

Windows Defender Firewall

Win + R → wf.msc

Firewall profiles, inbound and outbound rules, allowed programs, role-specific ports, and remote scope.

Windows Security

Start → Windows Security

Microsoft Defender Antivirus state, threat history, protection settings, and security intelligence.

PowerShell

Start → search PowerShell → Run as administrator when required

Fast read-only inventory, role/service checks, firewall review, event queries, share review, and verification.

Competition workflow

Five stages for safe server hardening

Read the scenario and identify the server's job

Before changing anything, determine what the server is supposed to provide.

Highlight every required role, service, user, share, application, and remote-access requirement.

Separate explicitly required functions from optional or unknown functions.

Write down anything that must not be interrupted.

Identify any forensic questions that require preserving the original system state.

Verify

You should be able to explain the server's purpose in one sentence before continuing.

Build a baseline

Record what exists before hardening so later changes can be compared against the original state.

Review Server Manager for installed roles and features.

Inventory local users and privileged groups.

Check whether the server belongs to a domain and whether it is a domain controller.

Review Defender, firewall, update state, services, shares, scheduled tasks, and recent event logs.

Record required remote-management paths such as RDP or WinRM.

Verify

Your notes should identify the major roles, security controls, users, services, and dependencies.

Prioritize high-impact findings

Fix the weaknesses that matter most while avoiding changes that could break critical roles.

Prioritize unauthorized privilege, disabled security controls, obvious unwanted software, suspicious persistence, and broad remote exposure.

Investigate unknown services, tasks, users, or rules before changing them.

Delay speculative tuning that has little security value.

Coordinate high-impact changes with teammates when they affect shared services.

Verify

Every planned change should have a clear security reason and a known verification method.

Harden one dependency-aware area at a time

Small controlled changes make troubleshooting and rollback easier.

Protect identity and privilege first.

Confirm Defender and firewall protections.

Review updates and required services.

Review remote administration, shares, scheduled tasks, and role-specific settings.

Preserve evidence before deleting or disabling suspicious items.

Verify

After each important change, confirm the affected role or service still functions.

Verify from the client perspective

A server can look healthy locally while clients are unable to use its services.

Test domain logon if Active Directory is required.

Test DNS resolution if DNS is required.

Test DHCP address assignment if DHCP is required.

Test file-share access if SMB is required.

Test RDP or other required remote administration.

Check Event Viewer for errors created by recent changes.

Verify

Required functions should work end to end, not just appear enabled in the local console.

Baseline inventory

Know what exists before you change it

Server identity

What is the computer name?

Is the server domain-joined?

Is it a domain controller?

What Windows Server version and edition is installed?

Roles and features

Which roles are installed?

Which features are installed?

Which roles are explicitly required?

Which roles are unknown and need investigation?

Users and privilege

Which local users exist?

Who belongs to Administrators?

Are there domain administrators or delegated groups?

Do any services run under named user accounts?

Network services

Does the server provide DNS?

Does it provide DHCP?

Are SMB shares required?

Are RDP or WinRM required?

Protection

Is Defender healthy?

Are firewall profiles enabled?

Are broad exclusions present?

Are updates pending?

Persistence and evidence

Are there unusual scheduled tasks?

Are there unusual automatic services?

Are there suspicious startup entries?

Do logs or Defender history contain forensic clues?

Read-only PowerShell baseline

Build a fast server inventory

Computer and OS overview

Get-ComputerInfo | Select-Object CsName, WindowsProductName, WindowsVersion, OsArchitecture

Provides a quick overview of the server name and Windows version.

Installed Windows roles and features

Get-WindowsFeature | Where-Object {$_.Installed -eq $true}

Shows installed Windows Server roles and features when the ServerManager module is available.

Local administrators

Get-LocalGroupMember -Group "Administrators"

Reviews privileged local membership on systems where local accounts are applicable.

Services

Get-Service | Sort-Object Status, DisplayName

Provides a read-only view of service state.

Detailed service inventory

Get-CimInstance Win32_Service | Select-Object Name, State, StartMode, StartName, PathName

Adds startup mode, service account, and executable path for dependency review.

Firewall profiles

Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction, DefaultOutboundAction

Reviews the current firewall profile state.

Defender status

Get-MpComputerStatus

Reviews Microsoft Defender Antivirus health where Defender is installed and active.

SMB shares

Get-SmbShare | Select-Object Name, Path, Description, Special

Shows local SMB shares for file-service review.

Scheduled tasks

Get-ScheduledTask | Select-Object TaskPath, TaskName, State

Builds a broad inventory of scheduled tasks without changing them.

Recent System events

Get-WinEvent -LogName System -MaxEvents 30 | Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, Message

Provides recent system health and service evidence.

Prioritization

Decide what to fix, investigate, protect, or defer

Fix first

Unauthorized administrative access

Defender or firewall disabled without scenario justification

Obvious unwanted remote-access software

Known suspicious persistence

Broadly exposed required services

Investigate before changing

Unknown service

Unknown scheduled task

Unfamiliar domain or local account

Unrecognized firewall rule

Installed role not mentioned in the scenario

Protect carefully

Active Directory Domain Services

DNS

DHCP

Required SMB shares

Required RDP or WinRM

Defer unless justified

Large feature upgrades

Broad policy rewrites

Mass service disable scripts

Unverified ownership resets

Major configuration changes with no test plan

Dependency awareness

Required server roles are connected systems

Active Directory Domain Services

Depends on: DNS, authentication services, directory database, domain controller services, time consistency, and network connectivity.

Risk: Disabling an unfamiliar service on a domain controller can interrupt domain logon or directory operations.

DNS

Depends on: DNS Server service, zone configuration, network access, firewall rules, and correct records.

Risk: A firewall or service change may break name resolution even though the server itself is still reachable.

DHCP

Depends on: DHCP Server service, scope configuration, authorization when applicable, network access, and firewall rules.

Risk: Clients may lose address assignment after a service or firewall change.

File services

Depends on: Server service, SMB, share permissions, NTFS permissions, user/group identity, storage availability, and firewall rules.

Risk: A permission or firewall change can break access while the folder still appears healthy locally.

Remote administration

Depends on: Authorized users, user rights, Remote Desktop Services or WinRM, firewall, network reachability, and authentication.

Risk: Hardening too aggressively can lock the team out of the server.

Verification matrix

Prove the server still does its job

Active Directory

Use an authorized client or test account to confirm domain authentication works when AD DS is required.

DNS

Resolve required names from a client and confirm the server returns expected results.

DHCP

Confirm a client can obtain or renew an address when DHCP is required.

File sharing

Confirm authorized users can access the required share and unauthorized users cannot.

RDP

Confirm the authorized administrator can connect through the intended path when RDP is required.

Defender

Confirm protection is healthy and required applications still function.

Firewall

Confirm profiles and intended rules remain active while required server roles are reachable.

Services

Confirm every required role-related service changed during hardening is running as expected.

Applications

Launch or test required server applications after related account, firewall, or service changes.

Logs

Review recent System, Application, Security, and role-specific logs for new errors caused by your changes.

First fifteen minutes

A practical opening checklist

Read the entire scenario before opening administrative consoles.

Identify the server's required role or roles.

Record whether the server is a domain controller.

Open Server Manager and inventory installed roles/features.

Record required users, administrators, shares, and remote-management paths.

Check Defender status.

Check firewall profile state.

Check recent Windows Update status.

Review Administrators and other privileged groups.

Review required services.

Review SMB shares.

Review scheduled tasks and obvious startup persistence.

Look at recent System and Security events for major warnings or clues.

Preserve forensic evidence before cleanup.

Create a prioritized change list with a verification plan.

Decision cases

How server context changes the decision

Unknown service on a domain controller

An automatic service has an unfamiliar name and runs under a privileged account.

The path and service account make it worth investigating, but domain controllers contain many specialized services.

Response

Inspect the executable path, vendor, dependencies, events, installed software, and scenario role before changing it.

Firewall rule looks too broad

A required DNS service is allowed inbound on more profiles or networks than necessary.

The service may be required while the exposure is excessive.

Response

Narrow the rule only after confirming which clients must reach the service, then test DNS resolution from an authorized client.

Unfamiliar administrator account

An account appears in Administrators but is not listed in the scenario.

The privilege is high-risk, but the account may support a required service or application.

Response

Inspect the account, service dependencies, logon evidence, and scenario authorization before removing privilege or disabling it.

Pending restart after updates

The server has installed updates and reports that a restart is required.

A restart may be necessary but can interrupt domain, DNS, DHCP, file, or application services.

Response

Coordinate the restart, preserve notes, verify the server returns cleanly, then test every required role afterward.

Fictional defensive lab

Build a baseline for DC-PRACTICE

Step 01

Read the fictional scenario

DC-PRACTICE is a domain controller that also provides DNS. Morgan is the authorized administrator. RDP is required for Morgan, and the TeamDocs share must remain available.

Step 02

Identify required dependencies

Mark Active Directory, DNS, authentication, the TeamDocs share, network connectivity, and Morgan's remote administration as required.

Step 03

Build the baseline

Use Server Manager, Services, Windows Security, Firewall, Event Viewer, and read-only PowerShell commands to record the current state.

Step 04

Prioritize findings

An unknown privileged scheduled task, one unexplained administrator, and a broad firewall rule become Investigate items before changes are made.

Step 05

Preserve evidence and harden

Document task properties, account evidence, and firewall scope before applying narrow, justified remediation.

Step 06

Verify the server

Confirm domain authentication, DNS resolution, TeamDocs access, Morgan's RDP access, Defender, firewall, services, and event logs.

Common mistakes

Server mistakes that create bigger problems

Treating the server like Windows 11

A server's roles and dependencies make many apparently simple changes much higher impact.

Disabling unfamiliar services

Unknown does not mean unnecessary. Server roles often rely on services students have never seen before.

Removing roles without understanding them

Installed roles may be required by the scenario or by another role.

Changing domain policy from the wrong place

Local policy may not control the effective setting on a domain-managed system.

Locking out remote administration

Changing user rights, firewall rules, services, or RDP settings without verification can cut off authorized access.

Testing only from the server

A role can appear healthy locally while clients cannot authenticate, resolve names, receive addresses, or access shares.

Reflection

Test your server reasoning

Question 1

Why should the server's role be identified before any hardening begins?

Question 2

Why can an unfamiliar service be more dangerous to disable on a server than on a workstation?

Question 3

What information should a baseline include?

Question 4

Why should a required server role be verified from a client instead of only from the server console?

Question 5

What kinds of findings belong in Investigate instead of Fix immediately?

Question 6

Why is preserving remote administrative access part of secure server hardening?

Competition checklist

Before leaving the workflow lesson

Scenario read completely.

Required server roles identified.

Domain-controller status identified.

Installed roles and features inventoried.

Local and domain privilege reviewed at the appropriate scope.

Required services identified.

Defender health checked.

Firewall profiles and required role rules checked.

Update and restart state checked.

Required shares inventoried.

RDP or WinRM requirements recorded.

Scheduled tasks and persistence reviewed.

Recent event logs reviewed.

Forensic evidence preserved before remediation.

High-impact findings prioritized.

Every planned change has a verification method.

Required roles tested from the client perspective.

Next Windows Server lesson

Server Manager & Role Inventory

Next, learn how to use Server Manager and supporting tools to identify installed roles, features, services, dependencies, and the server's real responsibilities before hardening.

Open Lesson 02 →

Back to Windows Server CyberPatriot Hub

Next Lesson →