Windows Server 2025 / How to Install Server Core and Configure It with SConfig

Windows Server 2025 Server Core runs server roles without the standard desktop. Install an image without the Desktop Experience label, then use SConfig for initial configuration and PowerShell to verify the result.

Prepare a separate VM

This exercise does not convert an existing Desktop Experience server. Changing installation options requires a clean installation. Create a new VM named CORE1 and keep disks containing data separate from its installation disk. CORE1 is distinct from the domain controller DC1.

• Use an official Windows Server 2025 ISO and an empty virtual disk.
• Keep the VM console available and store the Administrator password securely.
• Connect to the isolated lab network and reserve an unused address; this example uses 172.24.50.21/24.

Check application and role support before choosing Core. A program requiring local graphical components may need a different installation option. Management tools can also run on a separate management PC.

Install the Core image

1. Boot the new VM from the ISO and select language and keyboard settings. Confirm that this is a clean installation on the lab disk.
2. Select the required Windows Server 2025 edition without Desktop Experience in its image name.
3. Review the terms, check the target disk capacity and partitions, and start installation.
4. After the restart, set the Administrator password and sign in through the VM console. If setup starts again, change the boot order to use the installed disk.

A text based management screen is expected. When entering a password, characters may not be shown; check the focused window and keyboard layout before assuming that input has failed.

Configure initial settings with SConfig

SConfig, the Server Configuration tool, provides menus for common setup tasks. It can start automatically after Core sign-in. To open it from a local PowerShell console, run the command below. See Microsoft’s SConfig documentation for menu behavior.

SConfig

1. Set the computer name to CORE1 and restart when required, keeping console access available.
2. Select the connected network adapter by its current state and address; do not assume its interface number is 1.
3. Configure the reserved IPv4 address and /24 subnet mask. Do not invent a gateway on a network with no router.
4. Check date, time, and time zone. Enable only the management paths required; Remote Desktop and PowerShell remoting are separate settings.

Setting DNS to 172.24.50.10 does not make name resolution work before DC1 actually runs DNS. Distinguish initial external DNS access from the working domain DNS needed later for domain joining.

Verify the installation from PowerShell

Leave SConfig for its command environment and run these queries. Check CORE1 as the computer name, the intended adapter address, the Core installation type, and the time zone.

hostname
Get-NetIPConfiguration
Get-ComputerInfo | Select-Object WindowsProductName,WindowsInstallationType
Get-TimeZone

A pending rename may not appear in hostname until the server restarts. If addressing is wrong, check whether you configured a different adapter. Losing a remote connection after an IP change should still leave you a working console recovery path.

If you selected the wrong installation option, reinstall the correct image in the empty lab VM. Correcting the choice before adding roles and data is simpler than migrating a configured environment.

Define a successful result

• You can restart and sign in to the server named CORE1.
• The intended virtual switch and adapter have the correct static IP.
• Time settings are correct and SConfig can be reopened.
• The planned role supports Core and a management PC or recovery console remains available.

An update search failure on an isolated network is different from installation failure. Provide a controlled update route or verified official packages rather than connecting the lab directly to the office network.