Windows Server 2025 / How to Apply Updates and Verify a Restart

A Windows Server 2025 update is complete only after required restarts and service checks succeed. Record the original state, install the intended quality updates, restart in a planned window, and verify the operating system and client-facing services.

Prepare recovery and a maintenance window

Deferring all updates leaves known issues unresolved, while unplanned restarts interrupt services. Review service impact and a role-appropriate backup and recovery plan. Even a lab needs console access after restart.

• Record OS version, important roles, and normal service states.
• Check system disk free space and backup status.
• Prepare recovery procedures appropriate to roles such as domain controllers.
• Identify the update source and any required proxy or firewall path.

Get-ComputerInfo | Select-Object WindowsProductName,OsVersion,OsBuildNumber
Get-Volume -DriveLetter C
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 10

Get-HotFix is a useful reference, not a complete inventory of every update type. Compare it with update history and the update’s official documentation. A VM checkpoint should not be your only backup.

Update Desktop Experience

1. Open Settings → Windows Update and check whether organizational policy manages the settings.
2. Check for updates and review the offered categories. This lab applies quality updates to the existing Windows Server 2025 installation.
3. Wait for installation and record any error code.
4. If a restart is required, check active work, restart in the planned window, and verify boot and sign-in through the console.

An operating system version upgrade is separate from routine quality updates. Do not change the course’s target OS simply because another version is offered. Version changes require compatibility and recovery planning.

Use SConfig on Server Core

Open SConfig from the local PowerShell console and use its update settings and installation menus. Follow the displayed labels and choose the intended update category. See Microsoft’s Server Core servicing guide.

SConfig

Automatic, download-only, and manual modes need different operational follow-up. Manual mode requires an explicit owner and schedule. Do not rely on desktop notifications on Core.

On an isolated network, first establish whether the configured source is reachable. Use a controlled connection or verified official packages. Do not disable the firewall or obtain arbitrary third-party packages to bypass an update error.

Verify services after restarting

Successful administrator sign-in does not establish that server roles work. Compare builds and history, then test the actual function from a client: open a file share or query the DNS server, as appropriate.

Get-CimInstance Win32_OperatingSystem | Select-Object Caption,Version,LastBootUpTime
Get-Service | Where-Object Status -eq 'Stopped' | Select-Object Name,DisplayName
Get-WinEvent -FilterHashtable @{LogName='System'; Level=2; StartTime=(Get-Date).AddHours(-2)} -MaxEvents 20

Not every stopped service is faulty; some run only on demand. Compare against the normal baseline. For events, record the time, source, and event ID, and distinguish newly introduced errors from older ones.

Narrow down failures and recovery scope

• Download failure: check DNS, connectivity, proxy settings, and update source availability.
• Installation failure: record the error code and check free space and pending restarts.
• Service failure after reboot: examine new events and role health, then review known issues for the exact update.
• Recovery: establish whether the update supports removal and which settings or data a backup restore would affect.

Uninstalling an update is not always supported or sufficient. Avoid arbitrarily reverting a running domain controller to an old checkpoint. Record the applied updates, restart time, functional checks, and unresolved errors so later decisions have a clear basis.