If Windows Server Update Services suddenly started taking much longer to synchronise in July 2026—or stopped completing synchronisation altogether—you may not be dealing with an ordinary WSUS maintenance problem.

Microsoft confirmed a service degradation caused by a buildup of unwanted test detectoids in the WSUS publishing channel.

The result could include:

• very slow WSUS synchronisation
• synchronisation timeouts
• high WsusPool CPU or memory usage
• HTTP 503 errors
• client Windows Update scan failures
• excessive WSUS round trips
• poor console performance

Microsoft deployed a service-side mitigation on 18 July 2026, which prevents newly installed or rebuilt WSUS servers from receiving the problematic buildup.

But there is an important catch:

Existing SUSDB databases may still contain the unwanted metadata.

Those servers may need to be cleaned manually.

What Actually Happened?

The July 2026 incident involved published test detection metadata.

Microsoft identifies the affected detectoids using a title pattern similar to:

Product Detectoid for ProductName TestProduct%

A detectoid is essentially update-detection metadata used to determine whether a product or update applies to a device.

The problem was not simply that one bad update was published.

Large numbers of these test records accumulated in the WSUS catalogue.

That increased the amount of metadata that:

• WSUS servers had to process during synchronisation
• clients had to evaluate during update scans

Microsoft says the impact became particularly noticeable from 13 July 2026.

What Does an Affected WSUS Server Look Like?

Server-side symptoms may include:

• synchronisation taking dramatically longer
• synchronisation failing before completion
• WSUS console hanging
• WsusPool consuming excessive resources
• HTTP 503 errors
• SQL or Windows Internal Database timeouts
• downstream servers behaving differently from the upstream server

Client machines may experience errors including:

0x80244010
0x8024400E
0x80244007
0x80244022
0x80240439
0x80072EE2

Microsoft identifies:

0x80244010
WU_E_PT_EXCEEDED_MAX_SERVER_TRIPS

as one of the strongest indicators.

It means the Windows Update client exceeded the permitted number of round trips while communicating with WSUS.

Do Not Assume Every WSUS Timeout Is This Issue

This is the first thing I would strengthen in the article.

A WSUS synchronisation timeout can also be caused by:

• proxy problems
• TLS configuration
• certificate issues
• database fragmentation
• WsusPool configuration
• firewall restrictions
• Microsoft Update connectivity
• excessive catalogue size from ordinary product selections

Microsoft’s current WSUS troubleshooting guidance still recommends checking connectivity, firewall and proxy configuration when sync failures indicate communication problems with Microsoft Update.

So do not run database deletion queries simply because:

“WSUS is slow.”

Confirm the evidence first.

First: Confirm Whether You Have the July 2026 Detectoid Problem

Check:

Synchronisations > Synchronisation Results

in the WSUS console.

Look for:

• failures beginning around mid-July 2026
• synchronisations running far longer than normal
• repeated timeouts

Then inspect:

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

Look for:

• timeout errors
• SOAP errors
• HTTP 503
• failed Microsoft Update communication
• repeated retries

Also inspect:

IIS Manager > Application Pools > WsusPool

for:

• excessive CPU
• excessive memory
• stopped application pool
• frequent recycling

Finally, inspect one affected Windows client.

If several machines suddenly began generating:

0x80244010

at roughly the same time, the July detectoid issue becomes a strong possibility.

Why Restarting IIS Does Not Fix the Root Cause

Restarting:

• IIS
• WsusPool
• the WSUS server

may temporarily reduce pressure.

But it does not remove unwanted metadata from SUSDB.

The oversized catalogue remains.

Likewise, increasing:

• WsusPool memory
• timeout values
• IIS limits

may allow the system to limp along for longer without addressing the underlying cause.

For servers confirmed to be affected, Microsoft’s supported remediation is a database cleanup.

The Correct Recovery Order

The safe sequence is:

1. Back up every SUSDB.
2. Clean the detectoids from every WSUS database.
3. Temporarily remove the normal XML request-size limit.
4. Allow clients to perform their catch-up scan.
5. Restore the XML request-size limit.
6. Reindex and clean up SUSDB.
7. Recycle WsusPool or IIS.

The order matters.

Step 1: Back Up Every SUSDB

This is non-negotiable.

Microsoft explicitly warns that the cleanup permanently removes metadata and cannot be reversed without a backup.

For SQL Server:

BACKUP DATABASE SUSDB
TO DISK = N'C:\Backup\SUSDB_PreDetectoidCleanup.bak'
WITH INIT, STATS = 5;

Change the path to an appropriate protected backup location.

For Windows Internal Database environments, use a supported SQL administration method to create a verified backup.

Do not rely solely on:

“The VM has a snapshot.”

A proper database backup is much safer.

Step 2: Identify Every SUSDB in the WSUS Hierarchy

This is one of the easiest steps to miss.

Microsoft says deletion does not propagate between WSUS servers.

You therefore need to identify:

• upstream WSUS server
• autonomous downstream servers
• replica servers
• Configuration Manager Software Update Points with separate SUSDB databases

Every affected database needs to be cleaned directly.

If you clean only the upstream server but clients talk to an uncleaned downstream server, the problem can continue.

Step 3: Run Microsoft’s Supported Cleanup Query

Do not use a random SQL script from a forum.

Microsoft has published the supported cleanup query in KB5121986.

The query does two main things:

• deletes the unwanted test detectoids
• sets MaxXMLPerRequest to 0 temporarily

The affected records are selected using the title pattern:

Product Detectoid for ProductName TestProduct%

Microsoft’s current query uses its own stored procedure to delete the affected updates and safely skips entries that are still referenced elsewhere.

I would not duplicate the entire SQL query in the blog.

Instead, link readers directly to KB5121986 so they use Microsoft’s current version.

Why MaxXMLPerRequest Is Temporarily Set to Zero

WSUS normally limits the size of XML requests.

During this incident, clients could need so many catalogue round trips that the normal limit contributed to scan failures.

The Microsoft cleanup temporarily changes:

MaxXMLPerRequest

to:

0

to remove the 5 MB limit while clients perform their initial recovery scan.

This is temporary.

Do not leave it unlimited permanently.

Step 4: Do Not Overload IIS During Client Recovery

Once the WSUS database is cleaned, many clients may try to scan again.

Ironically, that can overload WsusPool just as you finish fixing the original problem.

Microsoft says administrators may need to limit concurrent connections to the WSUS Administration site and increase them gradually, with the aim of keeping IIS around 80% CPU usage while clients recover.

So avoid:

cleanup complete → force every PC to scan immediately

Instead:

• allow normal scanning
• stagger forced scans
• monitor IIS
• monitor SQL/WID
• watch WsusPool memory and queueing

Let the environment settle.

Step 5: Expect the First Client Scan to Be Slow

A cleaned server does not mean every client instantly returns to normal.

The first post-cleanup scan may take longer because the client needs to reconcile its existing local update information against the corrected catalogue.

Microsoft says this catch-up happens automatically and later scans should return to normal.

That means you normally do not need to reset Windows Update components on every endpoint.

Avoid mass client surgery unless there is separate evidence that a client itself is broken.

Step 6: Confirm That the Fix Worked

Generate:

Get-WindowsUpdateLog

on a test client.

Microsoft recommends checking for the scan entry resembling:

evaluated appl. rules of X out of N deployed entities

After cleanup, the total:

N

should be substantially smaller.

Also confirm:

• scan completes successfully
• 0x80244010 disappears
• updates are offered
• WSUS reporting returns
• WsusPool remains stable

Do not search only for the deleted detectoid IDs—Microsoft says the deployed-entity count is the more useful validation method.

Step 7: Restore the XML Limit

Once clients are scanning successfully and WSUS is stable, restore the default value:

UPDATE tbConfigurationC
SET MaxXMLPerRequest = 5242880;

That restores the normal:

5 MB

setting.

Microsoft specifically instructs administrators to put this value back after recovery.

Leaving:

MaxXMLPerRequest = 0

is not the intended permanent configuration.

Step 8: Reindex SUSDB

Large metadata deletions can leave indexes heavily fragmented.

Microsoft therefore recommends reindexing SUSDB after the detectoid cleanup.

That can improve:

• WSUS console performance
• database queries
• synchronisation
• client scans
• cleanup operations

Use an established WSUS database-maintenance procedure suitable for:

• SQL Server
• Windows Internal Database

and schedule it outside busy update periods where possible.

Step 9: Run the Server Cleanup Wizard

After reindexing:

WSUS Console > Options > Server Cleanup Wizard

Review options such as:

• unused updates and revisions
• expired updates
• superseded updates
• obsolete computers
• unnecessary update files

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

For very neglected WSUS servers, run cleanup in stages rather than selecting everything at once.

Step 10: Recycle WsusPool or IIS

Finally, recycle:

WsusPool

or perform:

iisreset

if appropriate.

This clears cached WSUS catalogue state and lets IIS run cleanly against the maintained database.

If the WSUS server hosts other IIS applications, recycling only WsusPool may be less disruptive than resetting all of IIS.

What About New WSUS Servers?

Microsoft deployed its service-side mitigation on:

18 July 2026.

Microsoft says:

• new WSUS installations
• rebuilt WSUS installations

should not accumulate the same problematic metadata.

That does not mean rebuilding is automatically the best solution.

Rebuilding can mean recreating:

• approvals
• product selections
• computer groups
• synchronisation configuration
• replica relationships
• SUP integration
• client policy

For an established WSUS environment, cleaning SUSDB is often much less disruptive.

Do Not Confuse This With TLS Problems

WSUS can also fail to synchronise because of TLS.

Microsoft’s current primary WSUS metadata endpoint is:

https://sws.update.microsoft.com

and it requires TLS 1.2.

Microsoft also says older endpoints such as:

sws1.update.microsoft.com

should no longer be preferred, while:

fe2.update.microsoft.com

is no longer a working WSUS synchronisation endpoint.

TLS-related failures may show errors involving:

• underlying connection closed
• handshake/cipher failure
• remote host closing connection
• SSL inspection
• proxy problems

If your WSUS problems existed long before July 2026, investigate those first.

Check Which Microsoft Update Endpoint WSUS Uses

Microsoft provides a simple PowerShell method:

$server = Get-WsusServer
$config = $server.GetConfiguration()
$config.MUUrl

For Windows Server 2012 and later, Microsoft says the preferred endpoint should be:

https://sws.update.microsoft.com

If your WSUS environment still points somewhere else, update the configuration before blaming the detectoid issue.

WsusPool Configuration Still Matters

Even after the July incident is fixed, badly configured IIS settings can hurt WSUS performance.

Microsoft’s current WSUS best-practice recommendations for larger environments include settings such as:

• queue length: 2000
• idle timeout: 0
• ping: False
• private memory limit: 0
• regular time interval: 0

Microsoft notes that a WSUS catalogue containing around 17,000 updates may temporarily require more than 24 GB of RAM while its cache is being built.

That does not mean:

“Give every WSUS server unlimited memory and forget about maintenance.”

It means WsusPool configuration and catalogue size still matter after the incident-specific cleanup.

Review Products and Classifications

Another common WSUS problem is synchronising far more metadata than the business needs.

Open:

Options > Products and Classifications

Review whether you genuinely need:

• old Windows releases
• obsolete products
• unused server software
• unwanted language content
• broad driver catalogues

Reducing unnecessary products can make long-term WSUS maintenance considerably easier.

It does not replace Microsoft’s July detectoid cleanup.

It prevents ordinary catalogue bloat from creating another performance problem later.

WSUS Driver Synchronisation Is Deprecated

Microsoft deprecated WSUS driver synchronisation in 2025.

Drivers remain available through the Microsoft Update Catalog and other modern management mechanisms, but organisations should reconsider using WSUS as a broad driver-distribution platform.

That matters because driver metadata has historically contributed heavily to WSUS catalogue size.

If your environment still synchronises large driver classifications, this is a good time to review whether you still need them.

WSUS Itself Is Deprecated — But Still Supported

This distinction is important.

Microsoft has deprecated WSUS.

That means:

• no major new feature development
• Microsoft is steering customers towards newer update-management approaches

It does not mean WSUS suddenly stopped working or became unsupported overnight.

Microsoft continues to support existing WSUS deployments according to Windows Server lifecycle expectations.

So:

deprecated ≠ immediately dead.

But businesses maintaining difficult WSUS environments should start considering alternatives such as:

• Microsoft Intune update rings
• Windows Autopatch
• Windows Update for Business
• Azure Update Manager for suitable server scenarios

The right path depends on the organisation.

The Best Diagnostic Order

If WSUS synchronisation is timing out:

1. Check whether the problem began around 13 July 2026.
2. Review synchronisation history.
3. Check SoftwareDistribution.log.
4. Check WsusPool and HTTP 503 behaviour.
5. Check clients for 0x80244010.
6. Confirm the Microsoft Update endpoint.
7. Check proxy/TLS connectivity.
8. If the July detectoid incident fits, back up every SUSDB.
9. Run Microsoft’s KB5121986 cleanup against every SUSDB.
10. Allow clients to recover gradually.
11. Confirm successful scans.
12. Restore MaxXMLPerRequest to 5 MB.
13. Reindex SUSDB.
14. Run Server Cleanup Wizard.
15. Recycle WsusPool.
16. Review products, classifications and longer-term WSUS strategy.

The key principle is:

Do not treat every WSUS timeout as a generic IIS performance problem.

What Not to Do

Avoid:

• deleting SUSDB without a backup
• cleaning only one server in a WSUS hierarchy
• leaving MaxXMLPerRequest unlimited
• forcing every client to rescan simultaneously
• mass-resetting Windows Update clients
• repeatedly increasing WsusPool memory without database maintenance
• rebuilding WSUS before confirming the root cause
• running unofficial SQL scripts instead of checking KB5121986
• assuming a TLS error is the July detectoid incident
• assuming WSUS deprecation means immediate migration is mandatory

How Hamilton Group Can Help

Hamilton Group can help businesses diagnose and recover WSUS environments affected by:

• synchronisation timeouts
• July 2026 detectoid buildup
• SUSDB problems
• Windows Internal Database
• SQL Server
• WsusPool/IIS performance
• Configuration Manager Software Update Points
• TLS and Microsoft Update connectivity
• client scan errors
• product/classification bloat
• Windows Update strategy

We can also help plan a move towards:

• Microsoft Intune
• Windows Autopatch
• Windows Update for Business

where maintaining WSUS no longer makes operational sense.

Visit hgmssp.com or call 0330 043 0069.