WSUS Syncs Timing Out? What Changed and How to Work Around It

3 Aug 2026
WSUS Syncs Timing Out? What Changed and How to Work Around It

If your Windows Server Update Services server has recently started taking far longer than normal to synchronise—or the sync simply times out—you may not be dealing with an ordinary WSUS maintenance problem.

In July 2026, Microsoft confirmed a service degradation affecting WSUS. Existing installations could accumulate a large amount of unwanted publishing metadata, causing synchronisations to slow down, time out or overload the WSUS application pool. Client scans could also fail because they needed too many round trips to process the inflated catalogue. 

Microsoft applied a service-side mitigation on 18 July 2026. New WSUS installations and rebuilt servers should now synchronise normally, but existing servers may still contain the problematic metadata and require manual cleanup. 

Here is what changed, how to confirm that you are affected and the safest order for restoring normal synchronisation.

What Changed?

The July 2026 problem was caused by a buildup of published test detectoids in the WSUS channel.

Detectoids are update-detection records used to determine whether a product or update applies to a device. The problematic entries followed a naming pattern similar to:

Product Detectoid for ProductName TestProduct%

Microsoft stated that these test records accumulated both in its publishing service and inside existing WSUS databases. As the number of entries grew, WSUS servers had to process much larger catalogues during synchronisation and client scanning. 

The heightened impact was observed from 13 July 2026 onwards. 

What Does an Affected Environment Look Like?

The symptoms may appear on the WSUS server, the managed clients or both.

Common server-side symptoms include:

  • Synchronisation taking much longer than usual
  • Syncs failing before completion
  • The WSUS console becoming slow or unresponsive
  • WsusPool consuming heavy processor or memory resources
  • HTTP 503 errors
  • SQL or WID query timeouts
  • Downstream or replica servers failing independently

Client symptoms may include Windows Update scans taking an unusually long time or failing with errors such as:

  • 0x80244010
  • 0x8024400E
  • 0x80244007
  • 0x80244022
  • 0x80240439
  • 0x80072EE2
  • HTTP 503

Microsoft identifies 0x80244010, or WU_E_PT_EXCEEDED_MAX_SERVER_TRIPS, as a key symptom. It means the client exceeded the permitted number of round trips while communicating with WSUS. 

Why Restarting IIS Usually Does Not Fix It

Restarting IIS, recycling WsusPool or rebooting the server may provide temporary relief, but it does not remove the underlying metadata from SUSDB.

The same oversized catalogue is still present when the services restart.

Similarly, increasing memory limits or timeout values may postpone the failure without solving the cause.

The real fix for affected existing installations is to:

  1. Back up SUSDB.
  2. Remove the unwanted detectoids from every WSUS database.
  3. Temporarily remove the XML request-size limit.
  4. Allow clients to complete their first catch-up scan.
  5. Restore the default XML limit.
  6. Reindex and maintain SUSDB.

Microsoft provides a specific cleanup procedure in KB5121986. 

First: Confirm That This Is the July 2026 Issue

Do not run a destructive database cleanup purely because a synchronisation failed once.

Check the timing and evidence first.

Review the WSUS synchronisation history

Open the WSUS console and check:

Synchronisations > Synchronisation Results

Look for failures beginning around the middle of July 2026.

Record:

  • Start time
  • Duration
  • Error details
  • Whether any sync eventually completed
  • Whether failures occur consistently

Review SoftwareDistribution.log

The main WSUS log is normally located at:

%ProgramFiles%\Update Services\LogFiles\SoftwareDistribution.log

Search for:

  • Timeout errors
  • Web-service exceptions
  • SOAP faults
  • HTTP 503 responses
  • Connection failures
  • Synchronisations that repeatedly retry

Check IIS

Open IIS Manager and review:

Application Pools > WsusPool

Look for:

  • Unexpected stopping
  • Frequent recycling
  • High processor consumption
  • Queue backlogs
  • Memory pressure

Check affected clients

Generate WindowsUpdate.log on a test client and review the scan failures.

The presence of 0x80244010 across several clients is particularly relevant to the detectoid issue. 

The Correct Recovery Order

Because the Microsoft cleanup permanently removes metadata, the order matters.

Step 1: Back Up Every SUSDB

Back up the SUSDB before making any changes.

Microsoft warns that the cleanup cannot be reversed without a database backup. 

For a SQL Server-backed WSUS deployment, Microsoft provides an example similar to:

BACKUP DATABASE SUSDB

TO DISK = N'C:\Backup\SUSDB_PreDetectoidCleanup.bak'

WITH INIT, STATS = 5;

Change the destination to a valid, protected backup location.

For Windows Internal Database installations, connect to the WID instance using a supported SQL administration method and create a verified backup.

Do not assume that a virtual-machine snapshot alone is an adequate database backup. A database-aware backup is safer, particularly in multi-server or replica environments.

Step 2: Identify Every WSUS Database in the Hierarchy

The cleanup must be run against all affected SUSDB databases.

This includes:

  • The upstream WSUS server
  • Autonomous downstream servers
  • Replica servers
  • Configuration Manager software update points using separate WSUS databases

Microsoft states that deletions do not propagate between WSUS servers. Each database must be cleaned directly. Clients pointing at an uncleaned downstream server may continue to experience the problem. 

Document the hierarchy before proceeding.

Step 3: Run Microsoft’s Cleanup Query

Microsoft’s published query performs two important actions:

  • It removes the test detectoids matching the affected naming pattern.
  • It sets MaxXMLPerRequest to 0, temporarily removing the 5 MB request-size limit. 

The query should be run using SQL Server Management Studio against each SUSDB.

The core selection targets detectoids whose title matches:

Product Detectoid for ProductName TestProduct%

Microsoft’s full supported query is published in KB5121986 and should be used exactly as documented rather than rewritten from an unofficial source. 

Why MaxXMLPerRequest is changed

An inflated catalogue can cause clients to exceed the allowed number of WSUS round trips or submit requests larger than the normal limit.

Temporarily setting MaxXMLPerRequest to 0 helps clients complete their initial catch-up scan after the cleanup. 

This should not be left at zero permanently.

Step 4: Control IIS Load While Clients Recover

After the metadata cleanup, many clients may attempt to scan again around the same time.

This can overwhelm WsusPool even though the catalogue itself has been corrected.

Microsoft notes that it may be necessary to limit the maximum concurrent connections for the WSUS Administration site and then increase them gradually. The aim is to keep IIS processor utilisation at roughly 80% rather than allowing the server to become saturated. 

You may also need to:

  • Stagger client scan schedules
  • Avoid forcing every client to scan immediately
  • Temporarily reduce rollout pressure
  • Monitor WsusPool memory and queue lengths
  • Check SQL or WID performance

Do not attempt to “prove the fix” by triggering several thousand scans simultaneously.

Step 5: Allow the First Client Scan to Take Longer

The first scan after cleanup can still take longer than normal.

Clients need to reconcile their existing local update database with the reduced server catalogue.

Microsoft states that this initial catch-up is automatic and that later scans should return to normal timing. No manual repair is normally required on individual clients. 

Avoid resetting every client’s Windows Update components unless there is separate evidence of a local fault.

Step 6: Confirm That the Client Catalogue Has Shrunk

On a test client, generate WindowsUpdate.log and look for an entry similar to:

evaluated appl. rules of X out of N deployed entities

The total number of deployed entities should be significantly lower after cleanup.

Microsoft advises using this count rather than searching the log for the removed detectoid IDs. 

Also confirm that:

  • The scan completes
  • 0x80244010 no longer appears
  • Updates are offered normally
  • Reporting returns to WSUS
  • The WSUS console updates the client status

Step 7: Restore MaxXMLPerRequest

Once the WSUS server is stable and clients have successfully scanned, restore the default 5 MB value:

UPDATE tbConfigurationC

SET MaxXMLPerRequest = 5242880;

Microsoft specifically instructs administrators to return this setting to its default after recovery. 

Leaving the request size unlimited is not the intended permanent configuration.

Step 8: Reindex SUSDB

Deleting a large amount of metadata can leave the SUSDB indexes fragmented.

Microsoft recommends reindexing the database after completing the cleanup. 

This can improve:

  • Console responsiveness
  • Synchronisation processing
  • Client scan performance
  • Cleanup operations
  • Reporting queries

Use a tested WSUS database maintenance process appropriate for SQL Server or WID.

Schedule maintenance outside busy deployment periods where possible.

Step 9: Run the WSUS Server Cleanup Wizard

After reindexing, run:

Options > Server Cleanup Wizard

Review the available cleanup categories carefully.

These may include:

  • Unused updates and update revisions
  • Computers not contacting the server
  • Unneeded update files
  • Expired updates
  • Superseded updates

Large or poorly maintained environments may need cleanup in stages rather than selecting every option at once.

Microsoft recommends running the cleanup wizard as part of the post-remediation maintenance process. 

Step 10: Reset IIS or Recycle WsusPool

Once database maintenance is complete, run an IIS reset or recycle the WSUS application pool.

This clears cached catalogue state and allows the WSUS services to start against the cleaned database. 

An elevated command prompt can run:

iisreset

Alternatively, recycle WsusPool from IIS Manager if a full IIS reset would affect other hosted applications.

What About New WSUS Installations?

Microsoft’s service-side mitigation was deployed on 18 July 2026.

New WSUS installations and rebuilt servers after that point should not encounter the same detectoid buildup from the service. 

That does not mean rebuilding should be the first response.

A rebuild can require:

  • Recreating computer groups
  • Restoring approvals
  • Reapplying products and classifications
  • Reconfiguring synchronisation
  • Rebuilding downstream relationships
  • Repointing clients
  • Reconfiguring Configuration Manager SUP integration

For an established environment, cleaning the existing SUSDB may be less disruptive.

Do Not Confuse This With TLS Problems

WSUS synchronisation can also fail because of TLS or cipher configuration.

Microsoft Update’s main WSUS synchronisation endpoint is:

https://sws.update.microsoft.com

Microsoft states that the endpoint requires TLS 1.2 and that older WSUS servers or restrictive cipher policies can cause connection failures. 

TLS-related failures may produce errors about:

  • The underlying connection being closed
  • No common algorithm
  • The remote host forcibly closing the connection
  • Send or receive failures

If your problem predates July 2026, or the detectoid cleanup makes no difference, review:

  • TLS 1.2 support
  • .NET strong cryptography settings
  • Windows Server monthly rollups
  • SSL Cipher Suite Order Group Policy
  • Proxy inspection
  • Firewall access to Microsoft Update endpoints

Do not apply the July 2026 database cleanup as a substitute for correcting a TLS problem.

Check the Upstream Endpoint

Microsoft advises Windows Server 2012 and later WSUS installations to use:

https://sws.update.microsoft.com

Older endpoints such as sws1.update.microsoft.com or fe2.update.microsoft.com should not be relied upon for current synchronisation. 

Check the WSUS configuration, proxy and firewall rules to ensure the supported endpoint is reachable using TLS 1.2.

Review Product and Classification Selection

The July incident was caused by unwanted metadata, but ordinary WSUS performance can also be damaged by selecting far more products and classifications than the organisation needs.

Review:

Options > Products and Classifications

Remove unused categories such as:

  • Obsolete Windows versions
  • Products no longer deployed
  • Unrequired language packs
  • Drivers, where not needed
  • Preview content not used in production
  • Unrelated server products

Reducing the catalogue will not replace the detectoid cleanup, but it will improve long-term manageability.

Driver Synchronisation Needs Special Attention

Microsoft deprecated WSUS driver synchronisation in April 2025. Drivers remain available through the Microsoft Update Catalog and can be deployed through other management approaches, but WSUS driver synchronisation is no longer an area receiving active feature investment. WSUS itself is also deprecated, although Microsoft continues to support existing production use and deliver updates through it. 

If your environment still synchronises broad driver catalogues, review whether that is necessary.

Driver metadata has historically contributed heavily to catalogue growth and maintenance load.

WSUS Is Deprecated, Not Immediately Dead

Microsoft now describes WSUS as deprecated and no longer receiving new features.

However, it remains supported for production deployments and continues to receive security and quality updates according to the relevant Windows Server lifecycle. 

That means businesses do not need to remove WSUS overnight.

It does mean that organisations should start planning for alternatives, particularly where WSUS has become difficult to maintain.

Options may include:

  • Microsoft Intune update rings
  • Windows Autopatch
  • Windows Update for Business deployment services
  • Azure Update Manager for supported server scenarios
  • Microsoft Configuration Manager with a planned modern-management strategy

The right choice depends on device ownership, connectivity, compliance and control requirements.

A Sensible Diagnostic Order

When WSUS synchronisation starts timing out, work through this sequence:

  1. Check Microsoft’s Windows release-health pages for a current service issue.
  2. Review WSUS synchronisation history and SoftwareDistribution.log.
  3. Confirm whether clients show 0x80244010 or related errors.
  4. Check WsusPool health and IIS 503 responses.
  5. Establish whether the server was affected by the July 2026 detectoid buildup.
  6. Back up every SUSDB.
  7. Run Microsoft’s cleanup query against every SUSDB in the hierarchy.
  8. Control IIS concurrency while clients catch up.
  9. Confirm successful client scans.
  10. Restore MaxXMLPerRequest to 5 MB.
  11. Reindex SUSDB.
  12. Run the Server Cleanup Wizard.
  13. Recycle WsusPool or reset IIS.
  14. Investigate TLS, proxy or cipher problems if synchronisation still fails.
  15. Review products, classifications and the future of the WSUS platform.

What Not to Do

Avoid these common mistakes:

  • Rebuilding WSUS before confirming the problem
  • Running SQL deletion queries without a verified backup
  • Cleaning only the upstream server and ignoring replicas
  • Leaving MaxXMLPerRequest set to zero
  • Forcing every client to scan simultaneously
  • Resetting Windows Update components on every endpoint
  • Increasing IIS memory indefinitely without database maintenance
  • Deleting SUSDB manually
  • Using an unofficial cleanup script without comparing it to Microsoft’s KB
  • Assuming every timeout is the July 2026 issue
  • Ignoring TLS and cipher requirements
  • Treating WSUS deprecation as an immediate end-of-service announcement

How Hamilton Group Can Help

WSUS failures can leave business devices without current security updates, create false compliance reports and consume significant IT time.

Hamilton Group can help with:

  • WSUS synchronisation timeout investigations
  • SUSDB backup and maintenance
  • July 2026 detectoid cleanup
  • WID and SQL Server troubleshooting
  • WsusPool and IIS performance
  • Configuration Manager software update points
  • TLS and Microsoft Update connectivity
  • Product and classification rationalisation
  • Client scan and reporting errors
  • Windows Update policy
  • Intune update rings
  • Windows Autopatch migration planning

We can determine whether the fault is caused by the current metadata issue, database health, IIS capacity, network security or an ageing WSUS design.

Get Update Synchronisation Working Again

If WSUS has recently become slow or started timing out, do not assume that the server simply needs more memory.

The July 2026 issue was caused by unwanted publishing metadata that remained inside existing SUSDB databases even after Microsoft repaired the service side. A proper recovery therefore requires database backup, Microsoft’s cleanup query, controlled client recovery and post-cleanup WSUS maintenance. 

For help restoring WSUS synchronisation, cleaning SUSDB or modernising your Windows update management, call Hamilton Group on 0330 043 0069 or book a call with one of our experts today.


 

Previous