windowsServer Windows Server Beginner Guide

Before you even open Server Manager, take a VM snapshot in whatever hypervisor is running the competition image:

• VirtualBox: Machine menu → Take Snapshot
• VMware: VM menu → Snapshot → Take Snapshot
• Hyper-V: right-click the VM in Hyper-V Manager → Checkpoint

Why this matters: A snapshot is a save point for the entire virtual machine — completely separate from Windows' own System Restore, which only covers system files and settings, not everything. If you accidentally break Active Directory or lock everyone out, a snapshot lets you roll back instantly instead of trying to manually undo hours of changes. Take one now, before your first change, and consider taking another one before any big/risky step (editing domain-wide policy, removing a server role, changing DNS/DHCP, or rebooting).

A server isn't just "a Windows computer" — it usually has one or more roles installed that make it act as infrastructure for other machines on the network. Common roles you'll see in competition:

• Read the README and note every role it says should be installed.
• Open Server Manager (usually opens automatically, or Start → Server Manager) and check the Roles (2008 R2) or Manage → Add/Remove Roles and Features (2012+) list to see what's actually installed.
• Compare the two lists. A role that's installed but NOT mentioned in the README is suspicious — it may be a "rogue role" planted for you to find and remove. But don't remove anything you're unsure about until you've read the rest of this section.

Tip: A server can have multiple roles at once — it's very common for one box to be a Domain Controller AND the DNS server AND the DHCP server simultaneously. Don't assume "one server, one job."

If you did the Windows Client checklist before, you're used to opening Local Security Policy (secpol.msc) to set password rules, account lockout, and other security options. On a Domain Controller, this mostly stops working — most of those settings will appear greyed out, or you'll change them and they'll silently revert.

Why: On a domain, security settings are pushed out from a central policy called the Default Domain Policy (and, for DC-specific settings, the Default Domain Controllers Policy). These domain-wide policies override whatever you set locally. You edit them using a different tool: Group Policy Management Console, or gpmc.msc.

This trips up literally every beginner the first time they touch a server image. If you spend 10 minutes clicking around secpol.msc on a DC wondering why your password policy change "isn't sticking," this is why. Close it and open gpmc.msc instead.

• On a Domain Controller, do NOT rely on secpol.msc for account/password/audit policy. Use gpmc.msc instead (covered in Section 4 below).
• On a server that is not a Domain Controller (a standalone or plain member server), secpol.msc works normally, just like on a client machine.

What it is: Active Directory Users and Computers (ADUC, opened via Win + R → dsa.msc) is where every domain user account lives. Think of it like Local Users and Groups on a client machine, except these accounts can log into any computer on the network, not just this one — which is exactly why unauthorized accounts here are more dangerous than on a single client.

• Open dsa.msc. Expand your domain in the left pane, then click into the Users folder (and any other custom folders/Organizational Units you see).
• Go through every account in the right-hand pane and check it against the README's list of authorized users.
  • Unauthorized account? Right-click → Disable Account (safer) rather than Delete, unless you're confident it should be removed entirely.
  • Guest account — should be disabled.
  • krbtgt account — this is a special built-in account AD needs to function. Never delete it. It's fine (and normal) for it to be disabled by default — leave it as-is.
• Double-click each authorized user → Account tab and check:
  • Password never expires should usually be unchecked.
  • Store password using reversible encryption should be unchecked.
• Check who's in the powerful groups. Double-click each of these groups → Members tab, and remove anyone who isn't supposed to be there:
  • Administrators
  • Domain Admins
  • Enterprise Admins (if present)

Tip: If you're not sure whether an account is legitimate, don't guess — cross-check it against the README's roster one more time, and when still unsure, disable rather than delete. You can always re-enable it later; you can't easily undo a delete.

What it is: Group Policy Management Console (GPMC, Win + R → gpmc.msc) is where domain-wide security settings actually live and get edited on a Domain Controller. This is the tool that replaces secpol.msc for anything domain-related (see Section 2).

📸 Snapshot checkpoint: A mistake here applies to the entire domain, not just one machine — a bad lockout policy or logon-rights change here can lock every account in the domain out at once. If you haven't taken a snapshot yet, take one now before editing anything in GPMC.

• Open gpmc.msc. Expand Forest → Domains → [Your Domain] → Group Policy Objects.
• Right-click Default Domain Policy → Edit.
• Navigate to Computer Configuration → Policies → Windows Settings → Security Settings → Account Policies:
  • Password Policy:
    • Minimum password length → 14 characters
    • Password must meet complexity requirements → Enabled
    • Enforce password history → 24 passwords remembered
  • Account Lockout Policy:
    • Account lockout threshold → 5 invalid attempts
    • Account lockout duration → 30 minutes
    • Reset account lockout counter after → 15 minutes
• Under Local Policies → Security Options, two easy wins:
  • Accounts: Rename administrator account → set a custom name.
  • Network access: Do not allow anonymous enumeration of SAM accounts and shares → Enabled.
• After making changes, force them to apply immediately instead of waiting:
  cmd

  Copy

  gpupdate /force
  

Tip: There's also a Default Domain Controllers Policy in the same list — that one holds settings specific to the DC itself (like who's allowed to log on locally). You generally won't need to touch it as a beginner, but know that it exists and is separate from the Default Domain Policy.

What it is: the DNS Management console (Win + R → dnsmgmt.msc) manages the service that translates computer names into IP addresses for the network. If DNS breaks, most other network services (including AD logins) break with it — so be careful and deliberate here, not aggressive.

📸 Snapshot checkpoint: DNS mistakes don't just affect this machine — every other computer on the network that relies on this DNS server for name resolution can be affected too. Snapshot before making changes here if you haven't recently.

• Open dnsmgmt.msc, expand the server, expand Forward Lookup Zones, right-click your domain's zone → Properties.
• On the General tab, set Dynamic updates to Secure only (never "Nonsecure and secure" — that lets anyone update DNS records without authenticating).
• On the Zone Transfers tab, this is the big one: uncheck "Allow zone transfers" (or, if the README says a secondary DNS server needs transfers, restrict it to "Only to servers listed on the Name Servers tab"). Leaving zone transfers open to "Any server" lets an attacker download your entire internal DNS map.
• Under the server's own Properties → Forwarders tab, it should generally be empty with "Use root hints if no forwarders are available" checked, unless the README says otherwise.

Tip: If DNS stops working after a change, the setting to double-check first is the zone transfer / dynamic update setting you just changed — a restart of the DNS service (not necessarily the whole server) is sometimes needed for a change to visibly take effect.

What it is: the DHCP console (Win + R → dhcpmgmt.msc) manages the service that automatically assigns IP addresses to other computers when they join the network. DHCP is a simple, mostly-unauthenticated protocol, so there isn't a long list of settings to lock down — mostly you're checking for tampering.

• Open dhcpmgmt.msc, right-click the server → Manage authorized servers… and confirm only the legitimate server is listed (unauthorize anything that looks rogue).
• Expand IPv4 → Scope → Scope Options and check:
  • 003 Router points to the real gateway.
  • 006 DNS Servers points to the real, internal DNS server (not something external/unfamiliar).
• Leave the address range/lease duration alone unless it's obviously been changed to something nonsensical.

Tip: Don't overthink DHCP — there usually isn't much to secure here beyond "make sure it's pointing clients at the right router and DNS server, and no rogue server is authorized."

Same idea as on a client machine, just make sure you don't accidentally block traffic this server needs to send/receive for its own roles (e.g., a DC needs DNS, Kerberos, and file-sharing ports open).

• Open Windows Defender Firewall with Advanced Security (or wf.msc) and confirm the firewall is On for all three profiles (Domain, Private, Public).
• Confirm the default is to block unsolicited inbound connections while allowing outbound.
• Skim the list of inbound rules for anything that looks obviously wrong or unfamiliar — but don't disable rules tied to roles this server actually provides (AD, DNS, DHCP, file sharing).

Tip: If you're not sure whether a firewall rule is needed, leave it enabled rather than guessing — a slightly-too-permissive firewall costs less than an outage caused by blocking a required service.

• Open services.msc and skim the list of running services.
• Disable anything obviously unnecessary and risky (Telnet, TFTP, Remote Registry) if it's not required by the README.
• Do not disable services tied to roles you've confirmed are required — for example, on a DC, leave Active Directory Domain Services, DNS Server, DHCP Server, and Netlogon-related services running.

Tip: If a service name matches a role you already decided to keep in Section 1, leave it alone. When you're not sure what a service does, it's safer to look it up before stopping it than to guess.

• Check whether updates are configured to install automatically, and whether any are currently pending.
• Many competition images are offline on purpose — don't assume you have internet access, and don't waste time waiting on an update check that will never finish. Check the README first.
• At minimum, make sure the Windows Update service itself hasn't been maliciously disabled.

What it is: Internet Information Services (IIS, opened via Win + R → inetmgr) is Microsoft's built-in web server software — it hosts websites, similar to how Apache or Nginx work on other platforms.

• First, open the site in a browser from your host machine (not inside the VM) just to see what it normally looks like. This gives you a baseline before you start changing settings.
• Open inetmgr, expand the server → Sites → click the site.
• Click Authentication in the middle pane. If the scenario doesn't require public/anonymous access, select Anonymous Authentication → Disable on the right. (If disabling this breaks something the site is supposed to do, re-enable it — test after you change it.)
• Click Handler Mappings — by default you should only see a small standard list (OPTIONSVerbHandler, TRACEVerbHandler, StaticFile). Anything unusual here is worth investigating.
• Consider blocking the TRACE and TRACK HTTP methods via Request Filtering → Verbs tab (these are rarely needed and are commonly abused).

Tip: Don't remove IIS or a website just because it "looks insecure" by default — if the README says a website needs to be up and working, your job is to lock it down without taking it down. Always re-test the site in a browser after each change.

Separate from the domain accounts in Section 3 — this is the server's own local account database (the same kind of thing you'd check on a client machine).

• Open Local Users and Groups (lusrmgr.msc) or Computer Management → Local Users and Groups.
• Disable the local Guest account if it's enabled.
• Rename the local Administrator account.
• Check the local Administrators group — remove any account that doesn't need admin rights on this specific machine (this is separate from the Domain Admins group you checked in Section 3).

• Re-read the README one more time and confirm every required role, account, and service is still working.
• Log in as one of the accounts the README says should have access, to confirm you haven't locked anyone out.
• Confirm the firewall is on, DNS still resolves names correctly, and (if applicable) DHCP is still handing out addresses.
• Take one more snapshot before you consider yourself finished, or before any reboot — if a later check reveals a problem, you want a recent safe point to fall back to rather than trying to manually undo everything.

You're ready for the full checklist. Once these basics feel routine, move on to the Windows Server Master Checklist in the parent folder — it covers Kerberos attacks (Kerberoasting, AS-REP Roasting), delegation abuse, AD Certificate Services, WinRM hardening, FSRM file screening, SYSVOL credential hunting, and a lot of PowerShell one-liners for doing all of the above faster once you're comfortable with the GUI.