MHOSTMHOST

Windows Server updates

This article covers checking for and installing updates on an mHost Windows server through the Settings app (if the server has a desktop) or through sconfig (on Server Core), restarting safely afterward, tuning the automatic-update schedule to your needs, and why putting off patches on a server that's reachable from the internet is a bad idea.

What you'll need

  • An mHost Windows server on Windows Server 2016/2019/2022 (or the older 2012 R2) — either with a desktop (Desktop Experience) or Server Core with no GUI.
  • RDP access as the Administrator account — if you haven't connected yet, see "VNC console and first connection (SSH/RDP)".
  • Local administrator rights — Administrator has them by default.
  • Outbound internet access: Windows Update talks to Microsoft's servers over HTTPS. Outbound traffic on an mHost VPS isn't restricted by a firewall by default, so most servers need no extra configuration for this.
  • A free window for a restart — the server and anything running on it will be unreachable for a minute or two during the reboot.
Tip: if the server runs a localized (non-English) build of Windows, menu names will appear in that language instead — for example, "Центр обновления Windows" instead of Windows Update. The layout and logic of the menus stay the same.

Step 1. Check for and install updates

What to do next depends on the server's installation type. If you see a normal desktop and Start menu after logging in over RDP, you have Desktop Experience — use the first method below. If a console (PowerShell or sconfig) opens straight away instead of a desktop, you have Server Core — use the second method.

Through the Settings app (server with a desktop)

  1. Press Win + I, or open Start → Settings.
  2. Go to Update & Security → Windows Update.
  3. Click Check for updates.

📷 screenshot: the Windows Update page in the Settings app with the Check for updates button

  1. If updates are found, Windows downloads and installs them automatically — the status on the page changes to Downloading, then Installing. You don't need to wait for it to finish; you can minimize the window and keep working.
  2. If a restart is needed after installation, the page shows Pending restart — move on to Step 2.
Done: the status on the Windows Update page changed to "You're up to date" (or "Pending restart" if a reboot is needed) — the updates are installed.
Tip: check the list of already-installed updates (and any failed attempts) via the View update history link on the same page — useful for confirming a specific KB landed, or figuring out what went wrong.

Through sconfig (Server Core, no desktop)

Server Core has no graphical Windows Update — updates go through the built-in text tool sconfig, which starting with Windows Server 2022 launches automatically right after sign-in. On older versions (2012 R2/2016/2019), open it manually:

powershell
sconfig
  1. From the main menu, type 5 and press Enter — this opens the update mode setting: A (Automatic — the server checks for and installs updates on its own every day at 3:00 AM server time), D (Download only — updates are downloaded automatically but installed only manually; the default mode) or M (Manual — the server doesn't check for updates on its own at all).
  2. To install updates right now — regardless of the mode you picked — type 6 and press Enter to open Install updates. Pick a search category: 1 for all quality and security updates, 2 for Microsoft-recommended updates only, 3 for feature updates (not needed for routine patching).
  3. After the search, sconfig lists the updates it found. Type A and press Enter to install all of them, S to pick a specific update by number, or N to install none of them.

📷 screenshot: the sconfig main menu with the Update setting and Install updates entries

Done: sconfig reports the install finished — you can return to the main menu and move on to a restart if one is needed (Step 2).
Tip: you can check which updates are already installed without sconfig too — straight from PowerShell:
powershell
Get-HotFix | Sort-Object InstalledOn

Step 2. Restart the server safely

Most security updates need a restart to take effect — until then, the changed files just sit alongside the old ones, and the server keeps running the previous, vulnerable version. You can restart the server with any of three equivalent methods.

Through Settings: if a Restart now button appeared on the Windows Update page, click it right away, or pick Schedule the restart and set a convenient time — for example, overnight, outside business hours.

📷 screenshot: the Windows Update notification with Restart now and Schedule the restart buttons

Through sconfig: from the main menu, type 13 and press Enter, then confirm with Y.

From the command line or PowerShell (works the same way on both Desktop Experience and Server Core):

cmd
shutdown /r /t 60 /c "Restart after installing Windows updates"

Or the same result through the PowerShell cmdlet:

powershell
Restart-Computer

/t 60 gives you 60 seconds to save your work — including for other admins, if any are connected right now — before the server restarts.

Important: the restart will drop your RDP session — that's expected. Wait a minute or two and reconnect the way you normally would (see "VNC console and first connection (SSH/RDP)"). If the server doesn't respond for more than 5–10 minutes, open the graphical VNC console right in VMmanager 6 — the screen may still be processing updates ("Working on updates, X% complete. Don't turn off your computer").
Important: while the screen is processing updates during boot, don't force a power-off or hard restart from VMmanager 6 (the hard restart/shutdown action in the "⋮" menu). Cutting power at this stage can corrupt the system badly enough that it won't boot at all. Let the process finish on its own — this can take anywhere from a few minutes to a couple dozen, depending on how many updates were installed.
Tip: mHost VPS don't offer snapshots, so before installing a large cumulative update on an important production server, back up your important data and configuration first — that way, recovering from a problem takes far less time than untangling a broken system by hand.

On Server Core, where there's no Action Center notification, you can check whether the server is waiting on a restart like this:

powershell
Test-Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending"

True means a restart is needed.

Done: the server is responding over RDP again, and Get-HotFix (or the Windows Update page) shows a recent install date — you can get back to work.

Step 3. Configure update behavior

By default, Windows Update decides on its own when to download and when to install updates. You can tune this more precisely — through the GUI, or, for Server Core or centralized management of several servers, through Local Group Policy or the registry.

Through Settings → Advanced options

  1. On the Windows Update page, open Advanced options.
  2. Active hours — the hours during which the server shouldn't auto-restart after installing updates. Set this to the period when you expect load on the server (for example, your business's working hours) — outside of it, Windows will restart on its own if needed.
  3. Pause updates — a button on the main Windows Update page that delays installing new updates for a chosen period (typically in weeks, up to 35 days total). Once the pause expires, Windows resumes checking for and installing updates as usual.

📷 screenshot: the Advanced options page with the Active hours setting

Verify: the exact set and placement of items on the Advanced options page varies slightly between Windows Server builds — if something isn't where you expect it, look a bit further up or down the same page.

Through Local Group Policy or the registry

For Server Core (which has no graphical policy editor) or when you want a more precise, reproducible setup, configure the behavior centrally.

Despite the name, the Local Group Policy Editor (gpedit.msc) works without an Active Directory domain — it edits the policies of this one server, not an entire organization. It's only available where there's a desktop (Desktop Experience); on Server Core, use the registry instead (below).

  1. Launch gpedit.msc.
  2. Go to Computer Configuration → Administrative Templates → Windows Components → Windows Update.
  3. Open the Configure Automatic Updates policy, enable it (Enabled), and pick a mode — the modes are explained below.
  4. Apply the policy immediately, without waiting for the scheduled Group Policy refresh:
cmd
gpupdate /force

📷 screenshot: the Local Group Policy Editor window with the Configure Automatic Updates setting

What the Configure Automatic Updates modes mean:

  • 2 — Notify for download and auto install — only notifies about updates it finds; an administrator has to start the download and install manually.
  • 3 — Auto download and notify for install — downloads automatically, but only notifies about installing.
  • 4 — Auto download and schedule the install — downloads and installs updates on a schedule (set right there, via the Scheduled install day/time fields) — essentially the same behavior as the Automatic mode in sconfig.
  • 7 — Notify for install and notify for restart (Windows Server 2016 and later only) — downloads automatically, but only starts the install and the restart with your confirmation — nothing happens without an explicit click from the administrator. A good choice for a single server that you manage yourself.

For Server Core (or to set the same thing without a GUI), you can set the same parameters through the registry:

powershell
$path = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU"
New-Item -Path $path -Force | Out-Null
New-ItemProperty -Path $path -Name "AUOptions" -Value 4 -PropertyType DWord -Force | Out-Null
New-ItemProperty -Path $path -Name "ScheduledInstallDay" -Value 0 -PropertyType DWord -Force | Out-Null
New-ItemProperty -Path $path -Name "ScheduledInstallTime" -Value 3 -PropertyType DWord -Force | Out-Null

This example turns on mode 4 (auto-download + scheduled install) with installs every day (ScheduledInstallDay 0) at 3 AM (ScheduledInstallTime 3) — that is, the same thing as the Automatic mode in sconfig, just set explicitly.

Active hours are set in a similar way, but under a different registry key — without the nested \AU:

powershell
$path = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate"
New-Item -Path $path -Force | Out-Null
New-ItemProperty -Path $path -Name "SetActiveHours" -Value 1 -PropertyType DWord -Force | Out-Null
New-ItemProperty -Path $path -Name "ActiveHoursStart" -Value 9 -PropertyType DWord -Force | Out-Null
New-ItemProperty -Path $path -Name "ActiveHoursEnd" -Value 21 -PropertyType DWord -Force | Out-Null
Important: values set through policy or the registry (as above) override whatever the local administrator picked through Settings or sconfig. If you remove these registry keys later, the manually chosen settings take effect again.
Tip: organizations managing updates across dozens of servers at once typically use WSUS (Windows Server Update Services) — a separate server that distributes approved updates itself. That's overkill for one or two VPS instances, so it's not covered here.

Why staying patched matters

RDP port 3389 on mHost Windows servers is open by default — the server is visible on the internet and regularly gets swept by automated scans from bots looking specifically for vulnerable Windows versions. The gap between a patch being published and a working exploit showing up in attackers' hands has been shrinking steadily in recent years — it's often a matter of days.

A classic example of what delaying patches leads to is MS17-010, the SMB vulnerability Microsoft fixed in March 2017. Two months after the patch shipped, the WannaCry ransomware worm spread using it, infecting hundreds of thousands of computers worldwide within a few days — almost exclusively ones where the March update had never been installed. The patch had already been available for two months by the time the attack hit.

A reasonable balance is checking for and installing security updates manually at least once every one to two weeks (or setting up the automatic mode from Step 3 and trusting it), and taking a backup (Step 2 above) before installing large cumulative updates on an important production server, so recovering from a problem takes minutes instead of an hour of untangling a broken system. For a broader baseline security checklist, see "Basic VPS security checklist" — it's written for Linux, but the principles of keeping the system patched, restricting access, and watching open ports apply to a Windows server too.

What's next

Learn how to install additional software on the server through VMmanager 6's ready-made recipes — the article "Installing Google Chrome on a Windows server using a ready-made recipe" walks through this with a concrete example. If you haven't set up backups yet as a safety net before risky changes (including large updates) — keep in mind mHost VPS don't offer snapshots, so back up your important data outside the server ahead of time.

Related articles

PreviousInstalling software on a Windows server