Most Windows VPS hardening advice is written as a checklist you complete over a week. That is the wrong shape for the deadline that actually matters: the window between “the provider finished provisioning” and “the box is reachable from the internet.” If your RDP endpoint answers on a public address before you have done anything, you are already being scanned. This article is the concrete sequence for that window — roughly the first half hour — run in order, from a console session or a temporary management path. It is specifically about pre-exposure security work: firewall, account surface, RDP reachability, patch state, and logging. If you are looking for the setup steps you do after a box is already locked down — installing roles, arranging your admin tooling, tuning your daily remote workflow — that is a different job and is covered separately.
Two assumptions. First, you have console or out-of-band access (provider VNC/KVM, a serial console, or a private management network), so you can work even if you break RDP. Second, you have not yet published a DNS record or handed the IP to anyone. If either is false, stop and fix that first: doing firewall work over the only remote path you have is how people lock themselves out.
Step 1: Kill the public RDP exposure before anything else
The first action is not “enable the firewall” — it is “make the current exposure smaller.” Windows Server ships with RDP listening if the provider enabled it, and providers almost always enable it, because that is how they hand you the box. On a fresh VPS the Remote Desktop listener is usually bound to all interfaces on port 3389, discoverable within minutes by internet-wide scanners.
Open an elevated PowerShell console — via the provider console, not via RDP — and look at what is actually listening before you change it:
Get-NetTCPConnection -State Listen | Where-Object LocalPort -in 3389,5985,5986 | Select LocalAddress,LocalPort,OwningProcess
Get-NetFirewallRule -Enabled True -Direction Inbound | Where-Object DisplayGroup -like "*Remote Desktop*" | Select DisplayName,Action,ProfileIf RDP is reachable from anywhere and you have console access, the correct move is to restrict the listener now, not later. Either bind RDP to a private management NIC if the provider gives you one, or add an inbound firewall rule scoped to your own admin addresses and disable the broad built-in allow rules. Do not rely on “changing the port” as a security control — it is a noise filter at best, and it will break provider tooling that expects 3389.
Step 2: Establish the default-deny inbound posture
Once your own path in is constrained, set the perimeter. The goal in the first 30 minutes is not a perfect rule set — it is a state where nothing inbound is allowed except what you have deliberately opened. On a box that is not yet serving traffic, that set is small: your admin source addresses, and nothing else.
Set the profiles you actually use to block-by-default, and confirm you did not accidentally leave a profile off. A very common failure is hardening the Domain profile on a machine that is sitting in the Public profile, so none of the rules apply. Check with Get-NetFirewallProfile | Select Name,Enabled,DefaultInboundAction and set DefaultInboundAction to Block for Domain, Private and Public alike. Then re-test your admin path from a second session before you close the console — the console is your rollback.
If you are planning to publish a web role, resist opening 80/443 now “so it is ready.” Every port you open before the application is configured is a port the application has to defend before it is tuned. Open it in the same change window as the deployment, with the rule scoped as tightly as the design allows. For a broader discussion of what a Windows VPS should cost you in operational effort, see our notes on what Windows VPS hosting actually includes.
Step 3: Reduce the account surface to the minimum you will use
Fresh Windows images carry accounts you did not create. The local Administrator account is enabled, has a provider-set or blank-ish password, and is the single most targeted credential on any new VPS. Before the box is reachable, do three things: rename or disable the built-in Administrator, create a named admin account with a long unique password, and confirm that no other local accounts are enabled that you cannot account for.
Get-LocalUser | Select Name,Enabled,LastLogon
Get-LocalGroupMember -Group "Administrators"
Get-LocalGroupMember -Group "Remote Desktop Users"Pay attention to the last command. On many images, the provider’s automation account is a member of Remote Desktop Users, and sometimes of Administrators. If that account is not part of your intended operating model, remove it — but only after you have a working named admin account and have verified you can log in with it. Order matters: create and test first, remove second. Doing it the other way round is how the console session becomes permanent.
Step 4: Get the patch state honest before you expose anything
Provisioning templates are frequently weeks or months behind. Before the machine serves anything, bring it current and confirm where it stands. This is not the same discussion as “when should I reboot in production” — on a box with no traffic, reboots are free, and the correct answer is “now, as many times as it takes.”
Run Get-WindowsUpdate -MicrosoftUpdate (or the equivalent in your patch tooling), install everything, reboot, and repeat until a scan returns nothing. Check the build number afterwards with Get-ComputerInfo | Select OsName,OsVersion,WindowsBuildLabEx and record it. If you are on an evaluation or trial SKU, note the expiry date now rather than discovering it during a maintenance window. Then decide, deliberately, whether automatic updates stay on: for a server you administer, the practical answer is usually to let the OS download but control the install timing through your patch process — but that is a policy decision, not a first-30-minutes task, and it should be written down.
Step 5: Turn on the logs you will need next week
Logging is the one item people skip because it has no visible effect. It also has the shortest window: if you enable auditing after an incident, you get nothing. In the first 30 minutes, raise the Security log size, enable the audit subcategories that matter for authentication and process creation, and make sure the log is not going to roll over in an hour.
wevtutil sl Security /ms:268435456
auditpol /set /subcategory:"Logon" /success:enable /failure:enable
auditpol /set /subcategory:"Special Logon" /success:enable /failure:enable
auditpol /set /subcategory:"Process Creation" /success:enable
Get-WinEvent -ListLog Security | Select LogName,MaximumSizeInBytes,RecordCountIf you have a central collector, point Windows Event Forwarding at it now, while the machine is quiet and you can debug the subscription without pressure. If you do not, at minimum enable PowerShell script block logging and module logging via policy — these are cheap and they are the difference between “we know what ran” and “we have no idea.” Do not install a full endpoint agent in this window unless it is part of your standard image; agents added under time pressure are agents configured wrong.
Step 6: Record the state and hand it to a reviewer
The last fifteen minutes of the window are for making the state reproducible and reviewable. Export what you changed: firewall rules, local group membership, listening ports, installed updates, and the service list. A single transcript is enough — you are not producing a compliance artifact, you are producing something you can compare against in two weeks when something looks different.
Then get a second pair of eyes before the box goes public. A colleague reading a one-page diff of “what is listening, who is an admin, what inbound is allowed” catches the mistake you made at minute four. If there is no second person, sleep on it: publish the DNS record the next morning, not at the end of the session. The cheapest hardening control is not exposing the machine on the same day you configured it.
A locked-down image is also worth keeping: capture the state of this machine as your baseline before you install anything, so the next server starts from minute thirty rather than minute zero. For the follow-on work — the productivity and administration setup that happens once the box is secure — see our Windows VPS administration guides.
