## TL;DR
A Server 2022 machine stuck at checking for updates usually has a wedged update datastore, a servicing stack that needs its latest update first, or a scan being fed by a WSUS source with catalog problems. Give a genuinely long first scan a chance, check WindowsUpdate.log to see if the scan is progressing or looping, then rebuild the local datastore if it is looping. Confirm the servicing stack update for the current cumulative update is installed, because a missing stack update can stall detection.

```text
windows update stuck on checking for updates windows server 2022
```

## Use this when
- Windows Server 2022 shows checking for updates for hours with no result list.
- WindowsUpdate.log shows the same scan starting and failing or restarting repeatedly.
- The server was recently built, restored, or pointed at a new WSUS server.

## Not for this skill when
- The scan completes and offers updates, but one install fails. Use that install error code.
- All servers scanning the same WSUS are stuck at once. Check WSUS catalog and pool health first.

## Steps
1. Determine whether the scan is slow or stuck: note when it started, then read the newest WindowsUpdate.log entries twice, fifteen minutes apart. Progressing scans write new entries and change the counts they report; a looping scan repeats the same failure or restart pattern, and that distinction decides whether you wait or intervene. Verify: you can say with log evidence whether the scan is progressing or looping, and how long it has actually run
2. Check the basics that silently stall server scans: system time accuracy, free space on the system drive, and that the Windows Update, BITS, and Cryptographic services are running and not disabled by a hardening baseline. Servers with drifted time or a disabled service can appear to scan while never completing detection. Verify: time, disk space, and service states are all confirmed healthy in writing
3. If the scan is looping, rebuild the local update datastore: stop the update services, rename the SoftwareDistribution folder, restart the services, and start a fresh scan. Expect the first scan after a rebuild to take significantly longer, since it downloads full metadata, and judge it by log progress rather than the clock alone. Verify: a new datastore is created and the fresh scan writes steadily progressing log entries
4. Verify servicing stack currency: compare the installed servicing stack version against the stack update that accompanies or precedes the latest cumulative update for Server 2022, and install the stack update first if the machine is behind. Detection for newer cumulative updates depends on a current stack. Verify: the servicing stack is current for the target cumulative update, confirmed by installed updates history
5. Let the repaired scan finish, install the offered updates in a maintenance window, and confirm a second scan completes quickly afterward, which proves detection is healthy and not just rescued once. Record how long the healthy scan takes as your baseline for this server class. Verify: a second scan completes in normal time and the server reports up to date or pending restart

## Why it happens
Detection on a server is heavier than on a client: the catalog is large, scans are often against WSUS, and the first scan after a build, restore, or datastore rebuild downloads full metadata instead of a delta. That makes genuinely slow scans common, while a damaged local datastore or a stale servicing stack makes truly stuck scans look identical from the console - the screen just says checking. The update log separates the two, because a working scan keeps recording progress against the catalog, while a broken one repeats the same failing cycle. Rebuilding the datastore and updating the servicing stack address the two local causes that produce the loop.

## Variants and edge cases
### Stuck checking after pointing the server at a new WSUS
The client may hold metadata from the old server. Rebuild the datastore and force a full detect so the server catalog is learned from scratch.

### Stuck checking only on the first scan after imaging
Image builds often ship a stale stack and datastore. Bake stack updates and a datastore reset into the build checklist rather than fixing each deployed server.

### Scan completes overnight but never during the day
Daytime WSUS load can stretch scans past observation windows. Check software update point health and stagger server scan schedules by collection or group policy.

Compatibility: Applies to Windows Server 2022 with Windows Update or WSUS, and the same method applies to Windows Server 2019 and 2025.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_nu8qbKUUXtuZj01kjC0_Ow