“Pingable” doesn’t mean “ready”
The most common mistake a systems administrator makes is assuming that a freshly deployed VM that answers ping is ready for production. It isn’t.
A “clean” server from a template is a digital newborn with no immune system. It’s vulnerable, anonymous, unconfigured, and probably living in the wrong time zone. Sending a server like that into production is like sending a soldier on a mission with no weapon, no map, and no radio.
The “firefighter admin” configures the server as they go, once something has already broken. The “architect of the future” runs a standardized commissioning process. This checklist is your Day 0: 10 steps that turn a vulnerable template into a battle-ready, secure, manageable unit of your infrastructure.
10 steps to production-ready
Split into Linux and Windows where the commands differ.
1. Hostname and DNS: “Who are you?”
The problem: a server named ubuntu-2204-lt-01 or WIN-SDF876G5 is useless — you have no idea what it is or what it’s responsible for.
The fix: the server needs a meaningful name reflecting its role and location (e.g. msk-web-prod-01). Right after that, its A and PTR records need to show up in DNS.
Bash
# Debian/Ubuntu and RHEL/CentOS — same command
hostnamectl set-hostname msk-web-prod-01
# If DNS doesn't pick it up right away, add a fallback in /etc/hosts:
# 127.0.0.1 localhost
# 127.0.1.1 msk-web-prod-01.yourdomain.com msk-web-prod-01
PowerShell
# Rename and reboot immediately
Rename-Computer -NewName "MSK-WEB-PROD-01" -Restart
2. Networking: a static IP
The problem: DHCP is for workstations. A server whose IP address can change out from under it is a disaster waiting to happen.
The fix: a server should always have a static IP, subnet mask, gateway, and explicit DNS servers.
YAML — Ubuntu, Netplan (/etc/netplan/01-netcfg.yaml)
network:
version: 2
renderer: networkd
ethernets:
ens160:
dhcp4: no
addresses: [192.168.1.10/24]
gateway4: 192.168.1.1
nameservers:
addresses: [8.8.8.8, 1.1.1.1]
After saving: sudo netplan apply.
PowerShell
# Find the index of the interface we need
Get-NetAdapter | Format-Table Name, InterfaceIndex, Status
# Assign a static IP (example for interface 12)
New-NetIPAddress -InterfaceIndex 12 -IPAddress 192.168.1.10 `
-PrefixLength 24 -DefaultGateway 192.168.1.1
Set-DnsClientServerAddress -InterfaceIndex 12 -ServerAddresses ("8.8.8.8", "1.1.1.1")
3. Time zone and NTP: “What time is it?”
The problem: servers with unsynced clocks are hell for logs (you can’t correlate events) and death for Kerberos: Active Directory refuses authentication once the drift exceeds 5 minutes.
The fix: set the correct time zone and force time synchronization on.
Bash
timedatectl set-timezone Europe/Moscow
timedatectl set-ntp true
systemctl restart systemd-timesyncd
PowerShell — on a domain, time comes down via GPO, but if the server sits alone in a DMZ:
Set-TimeZone -Id "Russian Standard Time"
w32tm /config /manualpeerlist:"pool.ntp.org,0x8" /syncfromflags:MANUAL
Restart-Service w32time
4. Security updates: “Close the holes”
The problem: that “clean” image you downloaded could have been built six months ago. Dozens of vulnerabilities have likely been found in it since.
The fix: the very first thing you do after connecting to the network is install every latest security patch.
Bash
# Debian/Ubuntu
apt update && apt upgrade -y
# RHEL/CentOS
yum update -y
PowerShell — the architect’s way, instead of hunting through the GUI:
Install-Module PSWindowsUpdate -Force
Install-WindowsUpdate -AcceptAll -AutoReboot
5. Remote access: “The steel door”
The problem: default SSH and RDP are the primary target for botnets scanning the internet non-stop.
The fix: harden the front door immediately, before the server sees a single byte of real traffic.
Ini — /etc/ssh/sshd_config, two golden rules:
# 1. Disallow root login — this forces the use of sudo,
# which leaves an audit trail.
PermitRootLogin no
# 2. Disallow passwords, allow only keys — brute-forcing
# becomes pointless.
PasswordAuthentication no
PubkeyAuthentication yes
Don’t forget to copy your key over first (ssh-copy-id) — otherwise you’ll lock yourself out of your own server.
For Windows: only enable RDP for people who genuinely need it, and firewall it off from everything except the Admin VLAN. For automation, WinRM is the architect’s choice:
Enable-PSRemoting -Force
6. Baseline security: “The alarm system”
The problem: SSH hardening alone isn’t enough. You need a basic firewall and brute-force protection.
The fix: set up ufw (simple) or firewalld (more flexible), and always fail2ban.
Bash
apt install ufw fail2ban -y
ufw default deny incoming
ufw default allow outgoing
ufw allow ssh
ufw allow http
ufw allow https
ufw enable
# fail2ban protects SSH out of the box right after install
systemctl enable --now fail2ban
For Windows: make sure the built-in Windows Firewall is enabled (it is by default, and it’s genuinely decent). For domain servers, deploy LAPS (Local Administrator Password Solution): it rotates local admin passwords, making lateral movement across the network practically impossible.
7. Monitoring: “What’s actually going on?”
The problem: a server that isn’t monitored doesn’t exist. You find out about a problem from a customer — and that’s already a failure.
The fix: install a monitoring agent (Zabbix, Prometheus Node Exporter, Nagios) BEFORE the server starts serving anything.
Bash — Zabbix Agent
# after installing from the repo, edit /etc/zabbix/zabbix_agentd.conf
# Server=YOUR_ZABBIX_SERVER_IP
# ServerActive=YOUR_ZABBIX_SERVER_IP
# Hostname=msk-web-prod-01
systemctl enable --now zabbix-agent
For the Prometheus stack — just download the Node Exporter binary, wrap it in a systemd.service, and run it on port 9100.
8. Backups: “Plan B”
The problem: data that isn’t backed up is temporary data.
The fix: install and configure the agent for your enterprise backup system (Veeam, Bacula, Acronis) before the first real data lands on the server — not after.
9. Logging: “The black box”
The problem: if a server gets compromised, the first thing an attacker does is wipe the local logs in /var/log.
The fix: set up centralized log shipping to a SIEM, an ELK stack, or Graylog. Logs should leave the server in real time, not live only locally.
- Linux: configure
rsyslogor a journald forwarder to ship to a collector. - Windows: set up WEF (Windows Event Forwarding) — a powerful, underrated native way to subscribe to events from workstations and servers with no third-party agent.
10. Joining the domain / configuration management system
The problem: a server living “in a vacuum” isn’t centrally managed — its configuration inevitably drifts from the standard within the first few months.
The fix: the final step — the server is ready, secure, and can now become part of the herd, not a pet.
PowerShell — joining the Active Directory domain:
Add-Computer -DomainName "yourdomain.com" -Credential (Get-Credential) -Restart
For Linux — apply an Ansible playbook, a Puppet manifest, or a Salt state: the single source of truth for configuration, not an admin’s memory.
The architect’s view: automate this
This checklist isn’t meant for manual work. An admin will spend an hour on these 10 steps, getting distracted and risking missing one halfway through. An architect spends a day turning this checklist into a spec for an automation script:
- For Windows — PowerShell DSC (Desired State Configuration) or a custom PowerShell orchestrator.
- For Linux — an Ansible playbook.
The goal is for “step 10” (running the playbook) to automatically perform steps 1-9 in five minutes with zero manual errors. An architect’s job isn’t to click — it’s to design the system that clicks for them.
Tags: #checklists #sysadmin #automation #security #windows #linux #day0
Want to become tomorrow’s architect instead of just an admin? This article is only the tip of the iceberg. On our Telegram channel “Admin Future” we publish systems-thinking guides, ready-to-use scripts, AI tips, and checklists every day that you won’t find on Google. We don’t just post commands — we’re building a knowledge library for people who want to grow from admin to architect. Subscribe and become the expert in the room: Admin Future
