Windows Server Hardening Checklist: Secure Your VPS Before Production

In short

Windows Server hardening is the work you do before a VPS becomes production. Start with the controls that reduce the most risk: audit local administrators, enforce account lockout policy, keep Windows Firewall enabled, limit RDP exposure, confirm Microsoft Defender is active, enable useful audit logging, and remove unused services. This checklist is built for practical SMB Windows VPS workloads, not regulated enterprise environments with hundreds of compliance controls.

Quick checklist

Do not apply every hardening setting blindly. Some controls can break applications, RDP access, authentication, printing, or management workflows. Snapshot first, then change one area at a time.

What we tested on Raff

We tested the audit and verification commands on a Raff Windows VPS running Windows Server 2025 Datacenter Evaluation.

Test environment:

On this VM, we verified:

• Windows Server version and hardware details
• Local users and Administrators group audit commands
• Account policy status with net accounts
• Firewall profile and RDP rule inspection
• Microsoft Defender preference checks
• Audit policy checks for logon, account lockout, user management, and process creation

We did not apply every hardening change on this test VM. Some changes should be applied only after taking a snapshot and confirming workload compatibility.

What you'll need

• A Raff Windows VPS running Windows Server 2022 or Windows Server 2025
• Local administrator access through RDP
• A fresh snapshot before making hardening changes
• 1-3 hours, depending on how many controls you apply
• A maintenance window if the server is already in production

Before changing authentication, firewall, RDP, or service settings, take a snapshot from the Raff dashboard. Some changes are easy to undo. Some are not.

Apply hardening in this order

Use this order:

1. Accounts and authentication
2. RDP and firewall exposure
3. Windows Update and Defender
4. Auditing and logs
5. Services and installed roles
6. Final verification

This order matters. Account, RDP, and firewall mistakes create the fastest path to compromise. Audit and logging controls help you detect problems after the fact.

1. Audit local users and administrators

Start by reviewing who can sign in locally and who has administrator rights.

Run PowerShell as Administrator:

powershellGet-LocalUser | Select-Object Name, Enabled, LastLogon

Then check the local Administrators group:

powershellGet-LocalGroupMember -Group "Administrators" | Select-Object Name, ObjectClass

What to look for:

For production, every admin account should have a reason to exist.

2. Disable the Guest account

The Guest account should not be enabled on a production Windows VPS.

Check it:

powershellGet-LocalUser Guest | Select-Object Name, Enabled

Disable it:

powershellDisable-LocalUser -Name "Guest"

This is safe for most VPS workloads. If an application depends on Guest access, that application design needs review.

3. Review the built-in Administrator account

The built-in Administrator account is a common brute-force target because attackers know the username.

You have two practical options:

To rename it:

powershellRename-LocalUser -Name "Administrator" -NewName "RaffAdmin01"

Do not run this casually on a production server unless your team knows the new admin username. Update documentation and password vault entries first.

4. Enforce account lockout policy

Account lockout slows down brute-force attempts against RDP and local accounts.

Check the current policy:

powershellnet accounts

A practical baseline for many SMB servers:

powershellnet accounts /lockoutthreshold:5 /lockoutduration:30 /lockoutwindow:30

This means:

Do not set the threshold too low. You can lock out real admins during busy support work.

5. Use a non-admin daily account

Do not use an administrator account for routine browsing, downloads, or daily work inside the server.

Create a standard user:

powershell$pw = Read-Host "Daily-user password" -AsSecureString
New-LocalUser -Name "user.daily" -Password $pw -PasswordNeverExpires:$false

Use administrator rights only when needed. For servers used by multiple staff, pair this with RDS Session Host planning and proper user access design.

6. Keep Windows Firewall enabled

Windows Firewall should stay enabled on a VPS.

Check firewall profiles:

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

Check RDP rules:

powershellGet-NetFirewallRule -DisplayGroup "Remote Desktop" |
Select-Object DisplayName, Enabled, Direction, Action, Profile |
Format-Table -AutoSize

Windows Firewall is a host-based firewall included with Windows and enabled by default on Windows editions. It helps filter traffic by profile, rule, application, port, and other conditions.

For production, keep the firewall enabled and open only the ports your workload needs.

7. Restrict RDP where possible

RDP is useful, but it should not be treated as a public front door.

If your office has a fixed IP, restrict RDP to that IP:

powershellSet-NetFirewallRule -DisplayName "Remote Desktop - User Mode (TCP-In)" -RemoteAddress "203.0.113.10/32"

Replace 203.0.113.10 with your actual office or VPN IP.

Before applying this, confirm your current public IP. If you set the wrong address, you can lock yourself out of RDP.

Safer options:

• Restrict RDP to office IPs
• Use a VPN or private access layer
• Use named admin accounts
• Use strong passwords
• Monitor failed logons
• Disable old test accounts

If you cannot restrict RDP by IP, at least keep the firewall enabled, use strong passwords, and review failed logon events.

8. Disable SMBv1

SMBv1 is legacy and should not be used on modern production Windows Server deployments.

Check SMBv1 server setting:

powershellGet-SmbServerConfiguration | Select-Object EnableSMB1Protocol

Disable SMBv1:

powershellSet-SmbServerConfiguration -EnableSMB1Protocol $false -Force
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart

Reboot during a maintenance window if Windows requires it.

9. Be careful with IPv6

Do not disable IPv6 just because you do not actively use it.

Microsoft warns that disabling IPv6 can cause issues with Windows components. Leave IPv6 enabled unless you have a documented reason and have tested the workload.

For most Raff Windows VPS customers, the practical rule is simple:

Do not touch IPv6 unless you know exactly why you are changing it.

10. Confirm Microsoft Defender status

Check Defender preferences:

powershellGet-MpPreference | Select-Object DisableRealtimeMonitoring, DisableBehaviorMonitoring, DisableScriptScanning

For a healthy baseline, these should normally be False:

Update Defender signatures:

powershellUpdate-MpSignature -Verbose

Microsoft Defender Attack Surface Reduction rules can block common attacker behavior such as credential stealing from LSASS, Office child processes, and executable content from email or webmail. Test ASR rules before enforcing them on production workloads, especially servers running Office, ERP clients, scripts, or legacy applications.

11. Use Controlled Folder Access carefully

Controlled Folder Access can help protect important folders against ransomware-style behavior.

Example:

powershellSet-MpPreference -EnableControlledFolderAccess Enabled
Add-MpPreference -ControlledFolderAccessProtectedFolders 'D:\BusinessData'

Do not enable it blindly on a production server. It can block legitimate applications that write to protected folders. Test first with your actual workload.

12. Enable useful audit policy

Audit policy determines what Windows records in the Security log.

Check key audit categories:

powershellauditpol /get /subcategory:"Logon"
auditpol /get /subcategory:"Account Lockout"
auditpol /get /subcategory:"User Account Management"
auditpol /get /subcategory:"Process Creation"

For production, enable at least:

powershellauditpol /set /subcategory:"Logon" /success:enable /failure:enable
auditpol /set /subcategory:"Logoff" /success:enable
auditpol /set /subcategory:"Account Lockout" /success:enable /failure:enable
auditpol /set /subcategory:"User Account Management" /success:enable /failure:enable
auditpol /set /subcategory:"Process Creation" /success:enable

This gives you better visibility into sign-ins, failed logins, account changes, and process execution.

13. Increase event log size

Default log sizes can roll over quickly on busy servers.

Set larger log sizes:

powershellLimit-EventLog -LogName Security -MaximumSize 1GB
Limit-EventLog -LogName System -MaximumSize 256MB
Limit-EventLog -LogName Application -MaximumSize 256MB

This helps preserve useful evidence during troubleshooting or incident review.

14. Check failed logon attempts

Failed logons are one of the simplest signals to monitor on an internet-facing Windows VPS.

Check recent failed logons:

powershellGet-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddHours(-24)}

Group failed logons:

powershellGet-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddHours(-24)} |
Group-Object {$_.Properties[5].Value} |
Sort-Object Count -Descending |
Select-Object Count, Name

If failed login attempts spike, review RDP exposure, firewall restrictions, account names, and password policy.

15. Enable PowerShell script block logging

PowerShell is powerful. That also makes it useful for attackers.

Enable script block logging:

powershellNew-Item -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging' -Force
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging' -Name 'EnableScriptBlockLogging' -Value 1

This helps preserve command activity for incident response.

16. Disable Print Spooler if the server does not print

Many VPS workloads do not need printing.

Check the service:

powershellGet-Service -Name Spooler

If the server does not print, disable it:

powershellStop-Service -Name Spooler -Force
Set-Service -Name Spooler -StartupType Disabled

Do not disable Print Spooler if the server provides printing, PDF workflows, or software that depends on it. Test first.

17. Review running services

List running services:

powershellGet-Service | Where-Object Status -eq 'Running' | Sort-Object Name | Format-Table Name, DisplayName

Do not disable services only because you do not recognize the name.

Use this process:

1. Identify the service.
2. Confirm whether Windows or your app needs it.
3. Search Microsoft or vendor documentation.
4. Disable only if you are confident.
5. Reboot and test the workload.

18. Keep Windows Update controlled

Hardening is not a one-time action. Patch management is part of it.

Use a controlled process:

• Check Windows release health.
• Take a Raff snapshot.
• Patch during a maintenance window.
• Reboot intentionally.
• Verify Windows and the application afterward.

For the full process, read Windows Update Strategy on Production Servers.

19. Snapshot before major changes

Before applying authentication, firewall, Defender, service, or audit changes, take a Raff snapshot.

Snapshot before:

• Restricting RDP source IPs
• Changing authentication settings
• Disabling services
• Applying security baselines
• Enabling ASR or Controlled Folder Access
• Large Windows Update cycles

A snapshot gives you a rollback path if the server stops working as expected.

20. Document every change

Keep a simple changelog.

Minimum fields:

Six months later, this record matters.

Recommended hardening order for SMB servers

Use this practical order:

This gives you the biggest security improvement without turning the server into a fragile compliance project.

Common mistakes

Hardening without a snapshot

Do not start with authentication or firewall changes unless you have a rollback path.

Restricting RDP to the wrong IP

This can lock you out. Confirm your public IP first, and keep dashboard recovery available.

Disabling services too aggressively

Some services look unnecessary but support real workloads. Disable slowly and test.

Enabling Defender controls without testing apps

ASR rules and Controlled Folder Access can block legitimate business software. Test before enforcing.

Ignoring failed logons

Failed logons are an early warning. Review them regularly on internet-facing servers.

Treating compliance baselines as copy-paste scripts

Microsoft, DISA, CIS, and NIST baselines are valuable, but they are broader than a simple SMB VPS checklist. Apply them with planning.

What Raff recommends

For most Windows VPS customers, Raff recommends a practical baseline:

• Snapshot before hardening.
• Keep Windows Firewall enabled.
• Restrict RDP where possible.
• Use named admin accounts.
• Remove old test users.
• Confirm Defender is active.
• Enable useful audit logging.
• Patch on a controlled schedule.
• Avoid exposing database and file-sharing ports publicly.
• Document changes.

The goal is a server that is safer and still usable.

Tested on

Tested on Raff Windows VPS, Windows Server 2025 Datacenter Evaluation, build 26100, 4 vCPU, approximately 8 GB RAM, 2026-05-24. We verified local user and administrator audit commands, account policy status, firewall and RDP rule inspection, Microsoft Defender preference checks, and audit policy checks. We did not apply every hardening change on this test VM. Tester: [ENGINEER NAME].

What's next

• Configure Windows Firewall on a Windows VPS - review firewall profiles, RDP rules, and custom inbound rules
• Windows Update Strategy on Production Servers - patch Windows Server safely with snapshots and maintenance windows
• Multi-User RDP: 2 Admin Sessions vs RDS Session Host - understand when default RDP is enough and when RDS is required
• Raff Windows Server Hub - browse Windows Server guides, commands, compatibility notes, and version comparisons
• Raff Windows VPS - deploy a Windows Server VPS for production workloads

Sources

• Microsoft Learn - Windows Firewall overview
• Microsoft Learn - Attack surface reduction rules reference
• Microsoft Learn - Configure IPv6 in Windows
• Microsoft Learn - Audit policy recommendations
• Microsoft Learn - Security Compliance Toolkit
• CIS Benchmarks - Microsoft Windows Server Benchmarks
• CISA - Known Exploited Vulnerabilities Catalog