Install Windows Server: from bare metal to first boot, step by step

What this tutorial covers — and what it doesn't

The scope is one physical server, installed from local media (USB or vendor virtual media), ending at a verified, remotely administrable first boot with a backup plan in place. It deliberately does not cover domain architecture, role design, Hyper-V clustering, or fleet imaging (PXE/WSIM) — those are separate workflows that build on top of what you produce here. If your job is to image twenty identical boxes, the preparation and post-install sections still apply to each one, but the media step moves to your imaging toolchain.

Which release, and why you should verify the current numbers

Microsoft publishes hardware minimums per release, and those numbers move between versions (memory minimums, disk space for the Desktop Experience versus the Core option, supported firmware features). Rather than freezing a spec sheet that goes stale, treat the table below as the shape of the requirement and confirm the exact figures for your release on Microsoft's published system requirements before you buy or rack anything. The same goes for your hardware: vendors maintain compatibility lists for server drivers and firmware, and a server that's "generic enough" can still be missing a storage driver the installer needs.

What you need before you begin

The requirements, with the practical production column on the right — the left column is "it will install," the right column is "you'll want to run workloads on it":

Then the preparation checklist for the session itself — copy it if you're working alongside someone who will take over later:

Windows Server install — session preparation
[ ] Server model, service tag and firmware version recorded
[ ] Target disk identified; its data backed up or confirmed expendable
[ ] ISO downloaded from an authorized source; edition matches the license
[ ] Bootable USB created for UEFI and verified with a test boot
[ ] Console access ready (monitor + keyboard, or iDRAC/iLO/KVM)
[ ] Network cable to the management network connected
[ ] Approved addressing details in hand (if a static IP is required)
[ ] Server name and NTP source decided

Inspect the chassis; confirm what's actually installed

1. Power and cooling. Confirm both power supplies are seated and powered (on redundant units) and that fan LEDs are green. A server that's about to run an installer for twenty minutes has no business running on one feed or with a degraded fan.

2. Drives and memory. Physically confirm which drive bays hold media — label the intended system disk on the face of the bay with tape. If you're adding RAM, install it now: installing the OS and then reseating memory is the worst possible order.

3. Console. Connect your console: monitor and keyboard locally, or the out-of-band management interface (Dell iDRAC, HPE iLO, Supermicro IPMI — the name varies, the capability is remote console, virtual media and power control). Connect one network cable to the management network; add workload NICs later. Power on last, so you're watching the POST.

Record what POST/firmware reports — CPU, memory, firmware version — in your asset notes. This is the baseline you'll compare against in Section 07, and it's the first thing a support engineer will ask for.

Firmware: the four settings that decide everything downstream

Enter the firmware setup (usually F2/Del at POST — vendor dependent) and check these. Menu names differ between vendors; the concepts don't.

Hardware RAID versus software storage — the distinction that matters here. With a hardware RAID controller, the controller presents virtual disks to the OS: the installer sees finished, striped/mirrored disks and knows nothing about the member drives. With an HBA or plain AHCI, the OS sees the raw physical drives, and any software storage (Storage Spaces, legacy dynamic disks) is built on top later. They are different layers with different failure behaviors, and they are not interchangeable after the fact.

Two rules keep this step safe. Never change a controller's RAID mode or initialize a virtual disk without knowing what's on it — both operations discard the existing layout and data, and "foreign configuration" messages in a controller UI often mean data from another system is present, not garbage to clear. And update firmware only for a known, documented problem: a firmware update during an installation window is two variables at once, and vendor firmware for servers can be slow to roll back. If the firmware is old but working and you have no reason to touch it, that's a post-install task.

Get the ISO from an authorized source — and match it to your license

Download the Windows Server ISO through the channel your license uses: the public Microsoft download center carries evaluation media (time-limited trial, no key needed), while production images come through Volume Licensing (for volume licenses) or your subscription management portal (for Microsoft 365 / active-channel customers); OEM and retail channels have their own. This matching matters more than people expect: an ISO from the wrong channel produces "wrong edition" screens, activation failures, or feature sets that don't line up with what you paid for. Note exactly which edition (Standard or Datacenter, and the year) the download is for, and verify the file — Microsoft's download pages and tools provide integrity information; a mismatched hash means a re-download, not a debugging session.

Make it UEFI-bootable — and know why a plain copy usually isn't enough

An ISO is a disc image; a UEFI bootable USB needs a specific on-media layout (an EFI system area the firmware can hand off to the Windows bootloader). Simply copying or extracting the ISO's files to a USB drive typically produces media that boots in Legacy BIOS mode at best — fine for older firmware, wrong for the UEFI setup you configured in Section 02. Use a bootable-media creation tool that supports UEFI/GPT output (Rufus is the common one; set it for UEFI), or your vendor's imaging tooling, and let the tool manage the partitioning — don't hand-format a working installer. Use a plain USB stick in the 16–32 GB range: unusually large or exotic drives occasionally confuse server firmware. After creation, do a test boot on any available machine — a two-minute check that pays for itself the first time it catches a bad stick.

Media options compared — and when the server won't see the USB

If the server doesn't recognize the USB, work the short list in order: is the drive in the firmware's one-time boot menu at all (if not — USB boot setting, try a rear USB 2.0 port, try a different stick; some firmware is picky about USB 3.0 during install)? Is the media itself valid (test-boot it elsewhere; re-verify the ISO hash)? Does the firmware show it but the setup doesn't start (recreate the media with the UEFI option — the classic symptom of a non-UEFI stick)?

From boot to the edition screen

1. Boot the media. Use the firmware's one-time boot option to start from the USB (or virtual media). You should see the "Windows Server Setup" loader, then the first language screen.

2. Language, time and keyboard. Set the input language, time/currency format, and keyboard layout to what your team will actually use — changing these later is possible but pointless friction.

3. Install now. On evaluation media the edition is already determined; on retail/volume media you'll enter a product key or select the matching SKU before the edition list appears.

4. Verify the edition you're about to install. The screen shows Standard and/or Datacenter — exactly which appear depends on your ISO and channel. Pick the one you intend (next topic), accept the license terms, and choose Custom: Install only Windows Server (advanced).

Standard vs Datacenter, and Server Core vs Desktop Experience

Two separate decisions, often confused. Standard vs Datacenter is about licensing economics, chiefly virtualization rights: Datacenter covers an unlimited number of guest VMs on that physical host under the applicable terms, while Standard covers a limited number (two). A box that will run many VMs often ends up cheaper on Datacenter; a single-purpose file, DNS or application server usually doesn't need it. Don't default to Datacenter out of habit — the delta is real money, and the answer depends on your workload and licensing, which only you know. Server Core vs Desktop Experience is about your management style: Core is PowerShell-first with no GUI, Server Manager or local desktop — smaller footprint, smaller attack surface, and every task done via PowerShell, Windows Admin Center or remote management; Desktop Experience is the full console. On current releases you can convert between the two after install by adding or removing the GUI management features (a reboot is required), so this choice is a starting point, not a life sentence. Pick Core if you'll live in PowerShell and remote tools; pick Desktop if your team (or your comfort) needs the console.

Identify the target disk positively — or stop

The disk list in setup shows each disk by number, size, and current partition count. Cross-check the target against at least two independent signals: the physical label you put on the bay in Section 02, the capacity, and (on a RAID controller) the virtual disk's identity and state in the controller UI. "Disk 0, 480 GB, 0 partitions" on a server where you know the 480 GB drive is in bay 2 and was confirmed empty is a target you can act on. "Disk 1, 960 GB, 2 partitions" that you can't map to a physical bay is not — stop and identify it before touching New, Format or Next. The cost of a wrong disk here is not a re-install; it's whatever data was on that disk.

Partitions: what setup creates, and why you don't hand-craft them

On a UEFI/GPT install, setup automatically creates the standard layout: a small EFI System partition (FAT32) holding the bootloader, a tiny Microsoft Reserved partition, the primary Windows partition (NTFS, most of the disk), and a Recovery partition (NTFS). In Legacy/MBR mode the shape differs — a System partition plus Windows and Recovery, no EFI or MSR. These differences are consequences of the firmware mode and the release, not mistakes: don't treat one layout as "the correct one" and don't resize or hand-build partitions during a standard install unless you have a specific, documented reason (storage virtualization, multi-boot, vendor requirement). For a normal install, select the disk and click Next; let setup partition it.

The installation itself — what to expect, and the failure patterns worth knowing

1. Start the install. Select the disk → Next. Setup copies files, then restarts the server automatically. Do not power off during any stage, and do not remove the USB until the system has clearly booted out of the installer.

2. Watch the reboots. Several automatic restarts are normal (setup runs in stages). The first restart should come from the system disk; if the server reboots straight back to the USB installer, the boot order is still pointing at the media — remove it or set the system disk first (Section 11, row 7 covers the loop).

3. Know the four common failures. No disks listed at all → the storage/RAID driver is missing (load the vendor driver at setup's "Load a driver" prompt) or the controller has no initialized virtual disk. "Windows cannot be installed to this disk" with a GPT/MBR message → firmware boot mode and disk partition style disagree — stop and resolve the mode question, never by converting a disk that holds data. A BSOD during driver installation (commonly INACCESSIBLE_BOOT_DEVICE) → the storage driver doesn't match this controller/firmware combination; remove it or use the vendor's correct one. Stalls at the same point in "installing updates" → suspect media integrity, RAM, or power: re-verify the hash, reseat memory, confirm both feeds are live.

The administrator password: the master key

On current releases, setup prompts for the local Administrator password before the first sign-in. Meet the complexity policy, and treat this credential as the highest-value secret the server will hold: store it in your team's credential manager, not on a sticky note on the chassis, not in a shared spreadsheet, not in your personal notes app. If this password leaks, every other control on the box is decoration. From here on, the habit that keeps servers safe is the same one everywhere: the default Administrator account is reserved for emergencies and break-glass work, and day-to-day administration happens from a named account (Section 09 covers setting that up).

The first screen — and what it does and doesn't mean

With the Desktop Experience, you sign in and Server Manager opens: the Local Server dashboard already shows the three facts you'll change in the next sections — the computer name (a temporary WORKGROUP\<name>), remote management status, and the firewall state. With Server Core, you get a PowerShell prompt: no desktop, no Server Manager, and — importantly — no loss of capability, because the same machine is managed through PowerShell, Windows Admin Center, and remote tools exactly as a desktop server is. Either way, note the difference this moment marks: a successful installation is not a configured server. The OS is running, but the name is a placeholder, the networking is whatever DHCP handed out, no roles are installed, nothing is backed up, and remote administration isn't verified. Everything from here to Section 10 is closing that gap.

Verify what was detected

On a Desktop Experience install, Device Manager is the quick visual: any device with a warning, or listed under "Other devices," is missing a driver. On any installation — including Core — PowerShell gives you the same answer without a GUI, and it's the form you can paste into your records:

# Read-only: devices with errors or missing drivers
Get-PnpDevice | Where-Object { $_.Status -eq 'Error' -or $_.Problem } |
  Format-Table FriendlyName, Status, Problem, Class -AutoSize

# Read-only: full device inventory for the asset record
Get-PnpDevice -PresentOnly | Format-Table FriendlyName, Status, Class -AutoSize

If the first query returns nothing, you're done with drivers. If it returns rows, get the driver from the server hardware vendor's support site (search by model or service tag) for the exact OS version — not a consumer driver, not a "similar" model. Server NIC and storage drivers in particular have firmware-adjacent behavior that generic versions get wrong. Install, reboot if prompted, and re-run the check: the goal state is an empty error list, and you verify that state rather than assuming it.

Record the system accurately

Support tickets, change documents, and your own future self all run on this baseline record. Capture it once, now, while the system is a known state:

# Read-only: record the installed system (baseline for support and change docs)
Get-CimInstance Win32_OperatingSystem |
  Select-Object Caption, Version, OSArchitecture, LastBootUpTime

Get-CimInstance Win32_ComputerSystem |
  Select-Object Manufacturer, Model, TotalPhysicalMemory

Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' |
  Select-Object ProductName, DisplayVersion, CurrentBuild

Get-HotFix | Select-Object -First 10 HotFixID, Description, InstalledOn

Keep this output with the asset record: product name, version and build confirm you installed the edition you intended (a mismatch here means the wrong ISO was used — stop and review before going further); LastBootUpTime becomes your reference for "has it rebooted since the last update?" in later sections.

Updates — and the reboot you're planning for

Run Windows Update and install what's offered, planning the reboot as a step rather than discovering it as a surprise: cumulative updates, .NET updates and feature updates on current releases all reboot. The sequence is the whole method: install → reboot → verify. Verification means re-checking Get-HotFix for the expected updates and comparing LastBootUpTime to confirm the reboot actually happened — a server that "still" shows yesterday's boot time after you installed a cumulative update is a server you haven't finished updating.

Name, time zone and clock source

Three identity settings, all change commands, all placeholders — use values approved for your environment. The name must be valid and unique in your DNS/Active Directory namespace (if you'll join a domain, the name is consumed there, so confirm it's free first); the rename reboots the machine. The time zone and NTP source matter far more than they look: logs, scheduled tasks, and — in any domain environment — Kerberos authentication all assume the clock is right, and "the server's time is five minutes off" is a classic source of auth failures that are very hard to trace. Set the approved NTP source now rather than discovering drift in a week.

# Changes configuration — all values below are PLACEHOLDERS.
# Use only the name, zone and NTP sources approved for your environment.

Rename-Computer -NewName 'SRV-FILE-01' -Force        # placeholder name; requires a reboot
Set-TimeZone -Id 'Eastern Standard Time'             # placeholder time zone

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\W32Time\Parameters' `
  -Name NtpServer -Value 'time1.example.com,time2.example.com'   # placeholder NTP servers
Restart-Service W32Time
w32tm /resync
w32tm /query /status                                   # verify: source + offset

Read what you have before you change anything

# Read-only: current network state, all adapters
Get-NetIPConfiguration | Format-List InterfaceAlias, InterfaceDescription,
  IPv4Address, IPv4DefaultGateway, DnsServer

Get-NetAdapter | Select-Object Name, Status, LinkSpeed, MacAddress

Read the output the way a network engineer would: which adapter is the management interface, what's its alias (you'll use that string in the next block), is the address from DHCP or manual, what gateway and DNS does it have, and is the link actually up at the speed you expect. This snapshot is your "before" — keep it, and re-run it after every change in this section.

DHCP vs static — and the rule about addresses you don't own

Whichever the design calls for, the rule is the same: get the approved addressing details before you assign a static address. Guessing an address inside a range you don't manage doesn't create a problem on your server — it creates a silent outage for the machine that already owns it, and the conflict can be confusing to trace from both ends. If your environment uses DHCP reservations for servers, that's a legitimate "static in effect" — the address is still deliberately owned, just assigned by the DHCP server.

Apply the addressing (PowerShell) — then verify it behaves

Every value in this block is a placeholder; replace with your approved details before running. New-NetIPAddress adds an address — if the adapter currently has a DHCP address you want gone, use -RemoveOtherIPAddresses; Set-DnsClientServerAddress replaces the DNS list for that interface. Then verify three independent things: the configuration reads back correctly, the gateway answers, and DNS actually resolves — a server that "has" an IP but can't resolve names is only half configured.

# Changes configuration — ALL values below are PLACEHOLDERS.
# Use only the interface alias, address, prefix, gateway and DNS
# servers approved by your network team.

$if = 'Ethernet 2'                     # placeholder interface alias
New-NetIPAddress -InterfaceAlias $if -IPAddress '10.0.20.45' `
  -PrefixLength 24 -DefaultGateway '10.0.20.1'
Set-DnsClientServerAddress -InterfaceAlias $if `
  -ServerAddresses @('10.0.20.2','10.0.20.3')

# Verify (read-only):
Get-NetIPConfiguration -InterfaceAlias $if
Test-NetConnection -ComputerName '10.0.20.1' -InformationLevel Ping  # gateway reachable
Resolve-DnsName -Name 'dc.example.com' -Server '10.0.20.2'           # DNS resolves (placeholder name)

Choose the remote path deliberately

Windows Server gives you more than one way in, and they're not interchangeable: Remote Desktop (TCP 3389) is the built-in graphical path — fine for administration on a trusted management network; PowerShell remoting (WinRM, TCP 5985/5986) is the scriptable path that automation and Windows Admin Center build on; and your vendor's out-of-band console (iDRAC/iLO) is the last resort that works even when the OS is down. The default posture: enable RDP on the management network, keep WinRM at its secure defaults, and treat out-of-band as emergency access. The line you should never cross: exposing 3389 (or any admin service) directly to untrusted networks or the internet. If you need reach across untrusted networks, the answer is a VPN or a jump host in front — not a wider firewall hole.

# Changes configuration: allow Remote Desktop connections on this server
Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server' `
  -Name fDenyTSConnections -Value 0

# Read-only: confirm the setting took effect (0 = RDP allowed)
Get-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server' |
  Select-Object fDenyTSConnections

Firewall: verify and scope — don't disable

Windows Defender Firewall is on by default on all three profiles, and it stays on. The one rule that matters for remote administration is the Remote Desktop rule, which is evaluated per profile (Domain, Private, Public) — so "RDP is blocked" is usually a profile mismatch, not a broken firewall. Check the state with the read-only block below, and enable the RDP rule only for the profile(s) that match how this server's network is classified in your environment (typically Private and/or Domain — not Public, unless your network design explicitly says so). The anti-habit worth naming: disabling the firewall to "test whether it's the firewall" is a scoped, temporary, last-resort diagnostic — never a standing state, and never the fix.

# Read-only: firewall profiles (all three should be Enabled)
Get-NetFirewallProfile | Select-Object Name, Enabled

# Read-only: Remote Desktop rule state per profile
Get-NetFirewallRule -DisplayName 'RemoteDesktop*' |
  Select-Object DisplayName, Enabled, Profile

Accounts, logs, and the first safety net

Least privilege in practice: create a named administrator account for your own day-to-day work, keep the default Administrator for emergencies and break-glass, and don't run workloads or services under admin accounts. (When the server later joins a domain, group policy takes over much of account management — that's a change, not a replacement, of these habits.) Give the logs a first look now, while the system is a known baseline: the System and Security logs are where driver faults, service failures, and logon events show up, and knowing what "normal" looks like on day one is what makes day thirty diagnosable.

# Read-only: first look at the two most useful logs
Get-WinEvent -LogName System -MaxEvents 15 |
  Format-Table TimeCreated, LevelDisplayName, ProviderName, Id

Get-WinEvent -LogName Security -MaxEvents 15 |
  Format-Table TimeCreated, LevelDisplayName, ProviderName, Id

Finally, the backup. Install the Windows Server Backup feature and take a first image now — a clean, pre-workload baseline is the most valuable backup you'll ever take, and the restore procedure gets documented while the install is still fresh in your head (vendor or third-party backup is an equally valid plan; the requirement is a tested plan, not a specific product).

# Changes configuration: install the Windows Server Backup role
Install-WindowsFeature Windows-Server-Backup

# Read-only: confirm the role is present
Get-WindowsFeature Windows-Server-Backup | Select-Object Name, InstallState

The verification pass

1. Boots from the system disk. Remove the USB (or unmount virtual media) and reboot. The server comes up on its own. If it loops back to the media, the boot order was never finalized — set the system disk first in firmware.

2. Edition and version as intended. Re-run the identification block from Section 07. Product name, version, build and architecture match the ISO you meant to install — and the record is in the asset file.

3. Storage is healthy and complete. All expected disks are present (Get-Disk, Get-PhysicalDisk), volumes are mounted (Get-Volume), and — on a RAID controller — the controller UI reports the virtual disk optimal, not degraded.

4. Drivers are complete. The error-device query from Section 07 returns nothing.

5. Network is working, not just configured. Get-NetAdapter shows the management link up at the expected speed; the address, gateway and DNS read back as approved; Test-NetConnection reaches the gateway and a known host; DNS resolves.

6. Time is correct and synchronized. w32tm /query /status shows the approved source and a small offset.

7. Updates are applied and verified. Get-HotFix shows the expected updates and LastBootUpTime confirms the post-update reboot happened.

8. Administrative access works as designed. RDP (or your chosen path) connects from the workstation with the named admin account — not just the console, not just the default account.

9. Firewall posture is right. All profiles enabled; the RDP rule scoped to the intended profiles; nothing admin-facing exposed to untrusted networks.

10. Logs are readable and a backup exists. System and Security events are visible; the first image backup has been taken and the restore procedure is documented somewhere your team can find it.

One command block that produces most of this snapshot in a single screen — read-only, safe to run at any time:

# Read-only: one-screen readiness snapshot
Get-CimInstance Win32_OperatingSystem | Select-Object Caption, Version, LastBootUpTime
Get-NetAdapter | Select-Object Name, Status, LinkSpeed
Get-NetIPConfiguration | Select-Object InterfaceAlias, IPv4Address, IPv4DefaultGateway, DnsServer
w32tm /query /status

Installed vs production-ready — the gap this tutorial deliberately leaves

Passing the ten checks means the machine is a reliable, administrable server. "Production-ready" adds what your environment requires on top: domain join and group policy (if applicable), the roles and features the workload actually needs, monitoring agents, a patch cadence, out-of-band management access confirmed from the network side, and documentation — asset record, addressing record, where the credentials live, and the recovery procedure. A fresh install is a foundation, not a building; the checklist below signs off the foundation, and the rest is the deployment that sits on it.