Server Setup & Provisioning Checklist Template

What the Server Setup Checklist Covers

1. 1
   Phase 1

   Phase 1: Request, Sizing & Approval

   6 tasks

   The platform answer in this phase drives the rest of the checklist. Choose physical, virtual or cloud before anything else is assigned.

   • Record the business owner and the service the server supports — a server with no named owner is the one nobody will agree to switch off in five years’ time
   • Select the platform: physical, virtual or cloud — this answer shows or hides the platform-specific tasks that follow
   • Size CPU, memory, storage and network from measured demand — use peak figures from the system being replaced or a load test, and record the headroom you added
   • Classify the data the server will hold — the classification sets the hardening profile, backup retention and who may log in
   • Reserve the hostname, IP address and VLAN or subnet — take them from the register now so two builds cannot claim the same name
   • Link the approved change or standard change record — the build is traceable to an authorisation from day one
2. 2
   Phase 2 — Physical Only

   Phase 2: Rack, Cable & Firmware

   5 tasks

   Shown only when the platform is physical. Virtual and cloud builds go straight to Phase 3.

   • Rack the server and connect power to two separate feeds — record the rack, U position and PDU ports
   • Cable and label network, storage and management ports — labels at both ends, matched to the patching record
   • Update BIOS or UEFI, RAID controller, NIC and BMC firmware — bring them to the approved versions before the OS goes on, when a reflash cannot hurt data
   • Harden the baseboard management controller — change the default credentials, place it on the isolated management network and disable protocols you do not use
   • Configure RAID and confirm disk health — record the array layout, hot spare and controller cache settings
3. 3
   Phase 3

   Phase 3: Build From the Approved Image

   7 tasks

   • Deploy the OS from the current approved image or template — record the image version; never build from an ISO someone downloaded
   • Virtual only: place the VM on the right cluster and datastore — apply resource reservations and anti-affinity rules for clustered pairs
   • Cloud only: launch into the right account, network and subnet — with encrypted volumes and every mandatory tag, including owner and cost centre
   • Cloud only: set each volume’s delete-on-termination flag deliberately — defaults vary by volume type and launch method, and this flag decides what survives when the server is retired
   • Set hostname, IP configuration, DNS and time synchronisation — against the reservations from Phase 1; wrong time breaks log correlation and Kerberos
   • Join the domain or configuration management tool — in the right OU or group, so baseline policies apply from the first boot
   • Bring the build to the current patch level before it leaves the build network — from then on it follows the normal patch cycle
4. 4
   Phase 4

   Phase 4: Harden to the Baseline

   6 tasks

   • Apply the hardening baseline for this OS — for example the CIS Benchmark Level 1 profile, or Level 2 where the data classification calls for it
   • Record every deviation from the baseline — with the reason and who approved it, so the next audit finds an answer instead of a finding
   • Remove the roles, packages, services and accounts the server does not need — every listening port should map to a stated purpose
   • Configure the host firewall — allow only the documented ports from the documented sources
   • Enable disk encryption where required and escrow the recovery key — a key nobody can find turns a failed boot into lost data
   • Run a configuration and vulnerability scan — fix findings above the agreed severity and attach the report as evidence
5. 5
   Phase 5

   Phase 5: Access, Logging, Monitoring & Backup

   7 tasks

   • Grant administrative access through groups, not named accounts — least privilege, with unique local administrator passwords managed centrally
   • Disable the build account and rotate every credential used during the build — build passwords end up in tickets and chat
   • Forward system and security logs to the central log platform — confirm events are arriving, not just that the agent is installed
   • Install endpoint protection and confirm the server reports to the console — a silent agent is not protection
   • Add the server to monitoring with thresholds and an alert route — CPU, memory, disk, key services and, for physical servers, hardware sensors
   • Enrol the server in the backup policy that matches its classification — run the first backup and confirm it completed
   • Add the server to its patch group or deployment ring — so next month’s cycle picks it up without anyone remembering
6. 6
   Phase 6

   Phase 6: Register & Acceptance Test

   6 tasks

   • Create the configuration item in the CMDB — owner, service, platform, location or cloud account, OS, image version, IP and its relationships to the services it supports
   • Physical only: record the asset in the asset register — serial number, purchase date, warranty end date and support contract
   • Reboot the server and confirm it comes back clean — every service starts, every mount returns and monitoring shows green
   • Run the application smoke test with the service owner — the server is only ready when the thing it exists for works
   • Test failover to the partner node — shown only for clustered or highly available servers
   • Restore a sample file from the first backup — proves the enrolment works before anyone depends on it
7. 7
   Phase 7

   Phase 7: Handover to Operations

   4 tasks

   Assigned to the operations lead, not the engineer who built the server. The server is not live until someone who will support it has accepted it.

   • Walk operations through the build record, runbook and approved deviations — the people who get paged need to know what is unusual about this server
   • Confirm the support model on the configuration item — on-call team, escalation path, maintenance window and patch ring
   • Attach the evidence and close the change record — scan report, acceptance results and the first backup confirmation
   • Operations accepts the server by name and date — from this point, routine care follows the operations schedule, not the build team