Installing Windows Server 2025 is straightforward once the decisions that matter have been made before Setup starts. The risky part is rarely clicking Install. It is choosing the wrong edition, installing Desktop Experience when the server should have been Core, selecting the wrong storage device, or putting a new production server online before its networking, updates, drivers and backup strategy have been validated.
This guide covers a clean Windows Server 2025 installation from installation media. If you are replacing Windows Server 2016, 2019 or 2022 while retaining applications and settings, that is an upgrade or migration project rather than the clean-install workflow described here.
The goal is to finish with more than a bootable server. You should have a Windows Server 2025 system whose edition, installation option, firmware configuration, storage, networking, updates and management model all match the workload it is supposed to run.
Start by separating Microsoft’s minimum installation requirements from sensible production sizing.
Windows Server 2025 requires a 1.4 GHz or faster 64-bit processor that supports the x64 instruction set and several required processor features, including NX/DEP, SSE4.2, POPCNT and second-level address translation. Microsoft’s current baseline lists 2 GB of RAM for Server Core and 2 GB for Server with Desktop Experience, with 4 GB recommended for Desktop Experience. The minimum system partition is 32 GB, and Microsoft describes that figure as an absolute installation minimum rather than a realistic universal production size.
For networking, Microsoft specifies at least a 1 Gbps Ethernet adapter compliant with the PCI Express architecture. Actual requirements depend heavily on the server role, applications, VM count, storage design and operational requirements, so Microsoft explicitly recommends workload-specific sizing and test deployments rather than treating the minimum values as production recommendations.
A file server holding several terabytes, for example, has completely different storage requirements from a domain controller. A Hyper-V host running twenty VMs bears almost no resemblance to a small application server even though both can technically install from the same Windows Server media.
Do not confuse a feature requirement with a universal installation requirement.
Microsoft lists TPM and UEFI/Secure Boot requirements as scenario-dependent. TPM 2.0, Secure Boot and virtualization-based security are required when deploying a Secured-core server configuration, and TPM is required for certain capabilities such as BitLocker. They are not presented as a blanket statement that every possible Windows Server 2025 installation must have TPM 2.0 simply to install the operating system.
For new physical production hardware, however, using modern UEFI firmware, Secure Boot and TPM 2.0-capable equipment is generally the sensible design. A clean 2025 deployment is not a good time to build new infrastructure around firmware limitations that will restrict security options later.
On physical hardware, verify that the server vendor supports Windows Server 2025 on the exact model you intend to deploy.
Check BIOS/UEFI firmware, storage-controller firmware, RAID/HBA drivers, network adapters, GPU drivers where relevant and out-of-band management tools. A machine may meet Microsoft’s generic CPU and RAM requirements while still lacking a supported driver for an important controller.
For a virtual machine, verify that the hypervisor version supports Windows Server 2025 as a guest and confirm the virtual firmware, virtual TPM and Secure Boot configuration required by your environment.
Windows Setup needs to know which Windows Server image to install, so edition selection should happen before you boot the installer.
For many general-purpose physical servers and lower-density virtualization environments, Windows Server 2025 Standard is the natural edition to evaluate. Windows Server 2025 Datacenter is generally intended for virtualization-heavy and datacenter-oriented environments where its licensing model and additional capabilities justify the higher tier.
Do not choose Datacenter merely because the server is powerful, and do not choose Standard simply because the business is small. A small company operating a dense virtualization host may have a Datacenter-shaped requirement, while a large company can legitimately use Standard on a lightly virtualized branch server.
Also keep technical installation and licensing separate. Selecting a Windows Server edition in Setup does not establish that the server is correctly licensed. Core counts, virtualization requirements and client access licensing should already be understood before production deployment.
This decision deserves particular attention because you cannot simply switch between the two after installation.
Windows Server 2025 offers both Server Core and Server with Desktop Experience for Standard and Datacenter. Server Core omits the normal desktop GUI and is managed primarily through PowerShell, SConfig and remote management tools. Desktop Experience installs the familiar graphical Windows shell and graphical management tools.
Microsoft recommends Server Core unless you specifically require the additional graphical interface. Core has a smaller installation footprint and fewer installed GUI components, which also reduces the amount of operating-system surface that needs to be maintained.
Desktop Experience makes more sense when the application genuinely depends on graphical components, local administration is operationally important, or the staff responsible for the server cannot reasonably manage the workload remotely.
The important rule is this: you cannot convert an installed Server Core system into Desktop Experience later, or convert Desktop Experience to Core. Changing that choice requires a clean installation.
For a Hyper-V host, infrastructure server or remotely managed workload, Core deserves serious consideration. For an application whose vendor explicitly requires Desktop Experience, follow the application requirement rather than selecting Core purely for minimalism.
A clean installation is destructive, so know exactly which disk will contain the operating system before booting the installer.
If the server uses hardware RAID, configure the RAID controller before starting Windows Setup. If the storage controller requires a vendor driver that is not included in Windows Server media, have that driver available separately so Setup can access the target storage.
For production systems, avoid sizing the system volume at Microsoft’s 32 GB absolute minimum. Windows needs space for cumulative updates, logs, paging, crash dumps, temporary servicing files and future operational growth. Microsoft specifically notes that systems with more than 16 GB of RAM can require additional space for paging, hibernation and dump files.
Where the workload justifies it, separating OS storage from application or data volumes can also simplify backup, recovery and capacity management. The correct layout depends on the role; there is no universal rule that every Windows Server requires a particular number of partitions.
Networking should also be designed before installation. Record the intended server name, management IP address, subnet, default gateway, DNS servers and VLAN. If the machine will join Active Directory, its DNS configuration must allow it to resolve the appropriate domain controllers.
Use Windows Server installation media obtained through an appropriate source for your licensing channel. Microsoft identifies OEM, retail, Visual Studio subscription and volume licensing channels among the available sources for installation media. It also recommends having the correct license or product key available before installation.
For a USB installation, Microsoft documents an 8 GB or larger USB drive as the baseline media requirement. Mount the Windows Server ISO on an existing Windows machine and create the bootable USB using an approved imaging process or Microsoft’s documented DiskPart/PowerShell method.
One technical detail matters if you manually create UEFI-compatible FAT32 media: FAT32 cannot hold individual files larger than 4 GB. Microsoft’s current media-creation procedure therefore splits an oversized install.wim into .swm files when necessary. If you use a deployment tool that handles this automatically, you normally do not need to perform the split yourself.
For a virtual machine, physical USB media is usually unnecessary. Attach the Windows Server 2025 ISO directly to the VM’s virtual DVD drive and configure the VM to boot from it.
Insert the bootable USB or attach the ISO, then configure the machine to boot from that device.
On physical hardware, enter the system firmware configuration during startup. The exact key varies by vendor-commonly F2, F10, F12 or Delete-and either change the boot order or use the one-time boot menu.
Microsoft’s current installation documentation specifically requires the boot order to prioritize the chosen USB or optical media when installing from those devices.
For modern hardware, confirm UEFI mode and your intended Secure Boot configuration before installation rather than changing fundamental boot settings after production configuration has begun.
If the server contains multiple disks, pay close attention to disk enumeration. Microsoft’s documentation notes a particular problem with legacy BIOS systems where installing Windows Server 2025 to a secondary BIOS-enumerated disk can fail because the operating system needs to reside on the primary enumerated disk.
Once the server successfully boots from the installation media, the clean-install workflow is relatively short. Microsoft’s current Windows Server 2025 Setup follows this sequence.
Boot from the USB, DVD or attached ISO. On physical media you may need to press a key when prompted to boot from it.
Select language and regional settings. Choose the installation language, time/currency settings and keyboard layout appropriate for the environment.
Select Install Windows Server. For a clean installation, acknowledge that the destination’s existing files, applications and settings will be removed.
Choose the licensing method. Windows Server 2025 Setup can use a conventional product-key licensing path. Microsoft also exposes a pay-as-you-go option for eligible Windows Server 2025 scenarios tied to Azure subscription licensing; that method has separate prerequisites and should only be selected when it matches the organization’s intended licensing model.
Select the correct Windows Server 2025 image. Confirm Standard versus Datacenter and, critically, Server Core versus Desktop Experience. Do not select an image simply because its name appears first.
Review and accept the software terms.
Choose the installation disk. Verify the disk carefully before continuing. On a server with several identical drives or logical RAID volumes, use capacity and controller information to make sure you are not deleting the wrong storage.
Start the installation. Windows copies the files, configures the operating system and restarts the machine several times.
Configure the built-in Administrator account. After installation, set a strong Administrator password when prompted.
Complete the initial diagnostic-data selection and sign in.
A newly installed desktop does not mean the server is ready for production. At this point you have only completed the OS installation.
Before installing an application or server role, establish the basic identity and management configuration.
With Desktop Experience, Server Manager provides a convenient starting point. With Server Core, use SConfig, which supports computer naming, domain or workgroup membership, local administrators, remote management, update settings, Remote Desktop, networking, date/time configuration and Windows activation.
Launch SConfig from an elevated console with:
sconfig
A sensible initial sequence is to configure the permanent server name, networking and time settings before joining the domain. That avoids performing a domain join with a temporary randomly generated hostname or incorrect DNS configuration.
Give the machine a meaningful hostname that follows your organization’s naming standard.
Do this early because changing the name requires a restart and becomes more disruptive after applications and management systems have already discovered the machine.
For Server Core, SConfig provides the computer-name option directly. Desktop Experience administrators can use Server Manager or PowerShell.
Servers providing infrastructure or application services usually require predictable addressing.
Configure the intended IP address, subnet, default gateway and DNS servers. If the server is joining an Active Directory domain, the DNS servers should normally be capable of resolving that AD DNS namespace.
Test both IP connectivity and DNS name resolution before attempting the domain join. A server that can reach the internet but cannot resolve a domain controller is not correctly configured for an Active Directory deployment.
Accurate time is important for authentication and domain operations.
Check the server’s time zone, date and clock before joining Active Directory. SConfig includes date and time configuration, and Microsoft explicitly notes that DNS, networking and time may need to be configured before a successful domain join.
A freshly released ISO is rarely fully current by the time it is installed.
Apply current Windows Server updates before turning the system into a production application server, file server, Hyper-V host or domain controller. Server Core systems can configure and initiate update behavior through SConfig, while managed environments may use Windows Server Update Services, Azure Update Manager or their existing enterprise patch-management process.
Restart as required and repeat the update check until the server reaches the organization’s expected patch baseline.
This is also a good point to check whether your management environment intentionally delays specific updates. A production server should follow the organization’s tested update policy rather than an administrator improvising a separate patch strategy during installation.
Windows Server may provide functional inbox drivers for much of the hardware, but “Device Manager shows no obvious error” is not always sufficient for production.
On physical servers, install or validate vendor-supported drivers for the storage controller, network interfaces, chipset, GPU where relevant and server-management hardware. Check the hardware vendor’s tested Windows Server 2025 driver and firmware matrix instead of automatically installing the newest package intended for a different Windows release.
Windows can receive drivers and some firmware packages through Windows Update, and vendor utilities may handle additional platform firmware.
After driver installation, check Event Viewer and the hardware-management interface for controller, NIC, storage or firmware errors. Production validation should include actual network and storage activity rather than merely observing that the devices appear in the operating system.
Activation should be checked before deploying production workloads.
The exact activation method depends on the licensing channel. Environments may use retail/OEM activation, Multiple Activation Keys, Key Management Service, Active Directory-based activation or another supported licensing arrangement.
Do not confuse a KMS client key with a retail product key. Microsoft’s KMS documentation specifically warns that generic volume-license client keys are intended to work with an organization’s KMS infrastructure and do not themselves function as retail licenses.
Server Core administrators can access Windows activation from SConfig. Whatever activation mechanism is used, verify that the installed edition matches the intended license rather than discovering an edition mismatch after applications have been deployed.
Detailed activation troubleshooting belongs in a separate activation workflow; at installation time, the objective is simply to confirm that the target edition and expected activation method are consistent.
Not every server needs to join Active Directory, but many production member servers will.
Before joining, verify the permanent hostname, DNS configuration and system time. Microsoft notes that the system must be able to resolve a domain controller’s DNS address and that the administrator performing the join needs appropriate permissions.
On Server Core, the domain/workgroup option in SConfig can perform the join. Desktop Experience can use Server Manager or the graphical system settings.
After the server restarts, sign in using the intended administrative account and verify that its computer object appears where expected in Active Directory. Apply the appropriate Group Policy and organizational security baseline before deploying the workload.
For a new domain controller, do not simply treat domain membership as the finished configuration. AD DS deployment, DNS design, time synchronization and post-promotion validation require their own implementation process.
A clean Windows Server should not immediately become a collection of unrelated roles.
Use Server Manager or PowerShell to install the specific roles and features needed for its purpose. PowerShell can display the installed and available role set with:
Get-WindowsFeature
To show only installed roles and features:
Get-WindowsFeature | Where-Object Installed
Microsoft’s ServerManager PowerShell module supports Get-WindowsFeature for inspecting available and installed roles and Install-WindowsFeature for installing the required components.
For example, an IIS server should receive the specific IIS role services its application requires rather than every optional Web Server component. A Hyper-V host does not need unrelated application roles simply because they are available.
A smaller, purpose-driven configuration is easier to understand, patch, secure and troubleshoot.
Before handing the server to an application team or marking the build complete, validate the system as a whole:
The final reboot test is easy to skip and surprisingly valuable. A server that only works until the next restart is not a finished build.
One of the most expensive mistakes is choosing the wrong installation option. An administrator installs Desktop Experience because it feels familiar, or chooses Core without confirming application support, and later discovers that changing the choice requires a clean installation. Microsoft does not support switching between Core and Desktop Experience after setup.
Another common error is installing to the first disk Setup displays without confirming what that disk actually represents. On enterprise hardware, logical RAID volumes, SAN LUNs and locally attached drives can look similar. Know the intended OS volume before deleting or formatting anything.
Using minimum hardware values as production-sizing recommendations is another poor shortcut. Microsoft’s requirements describe what Windows needs to install, not what a busy SQL Server, file server, Hyper-V host or application platform needs to perform properly.
Finally, avoid immediately installing business applications on an unpatched server. First establish the operating-system baseline, drivers, management, networking, activation, monitoring and backup. Application deployment becomes much easier to troubleshoot when the underlying server is already known to be healthy.
Choose Server Core when the workload supports it, administrators are comfortable with PowerShell and remote management, and there is no application dependency on the Windows desktop. Microsoft itself recommends Core unless the graphical components of Desktop Experience are specifically required.
Choose Desktop Experience when the workload requires a GUI, the application vendor specifies it, or local graphical administration is an operational requirement that outweighs the smaller Core footprint.
Do not make this choice based on what looks easier during the first hour of deployment. Think about how the server will be administered for the next several years.
Windows Server Setup finishing is only the midpoint.
A production-ready Windows Server 2025 installation should have the correct edition and installation option, supported hardware and drivers, deliberate storage configuration, known networking, current updates, validated activation, secure administrative access, monitoring and a functioning backup path.
Only after that baseline is established should the server become a domain controller, Hyper-V host, IIS server, file server or application platform.
The installation procedure itself may take less than an hour. The quality of the deployment is determined by the decisions made before Setup and the validation performed afterward.
Learn how to upgrade Windows Server 2016 to 2025, including the direct upgrade path, compatibility checks, backups, migration options and post-upgrade validation.
Learn how to upgrade Windows Server 2019 to 2025 with compatibility checks, backup planning, in-place steps, migration alternatives and post-upgrade validation.
Upgrade Windows Server 2022 to Windows Server 2025 with a practical runbook covering compatibility, backups, in-place upgrade steps, rollback and post-upgrade checks.