www.it-connect.fr
WSUS: Microsoft Releases a Manual Fix for Sync Slowdowns and Timeouts
For the past few days, synchronization issues have been affecting WSUS servers, causing slowdowns and even failures when syncing with Microsoft servers. Although the problem is now resolved, there are additional steps you can take to clean up your server. Here is what Microsoft recommends.
As a reminder, WSUS (Windows Server Update Services) is the Windows Server role that centralizes the distribution of Microsoft updates to an organization's workstations and servers. If you're just getting started with this tool, IT-Connect offers a complete course to install and configure a WSUS server. It is a service that Microsoft no longer develops since the announcement that development would stop starting with Windows Server 2025, yet it remains widely deployed in enterprises.
Since Friday, July 17, 2026, administrators have been reporting that their WSUS servers are taking an unusually long time to synchronize. In addition to being slow, synchronization can even fail. The issue is that without synchronization, it is not possible to retrieve the metadata associated with the latest Windows updates through WSUS (or Configuration Manager).
Microsoft first confirmed the issue before deploying an initial workaround in its Cloud. "On July 18, 2026, Microsoft deployed a server-side remediation that restores synchronization timing and normal synchronization operations for new WSUS installations and reinstalls. After this date, newly installed or reinstalled WSUS servers should no longer encounter this issue.", Microsoft states on its website.
Then, on July 20, 2026, Microsoft published a cleanup procedure for servers that were still affected. Let’s take a look at what this means in the rest of this article.
A buildup of test detectoids behind the blocking issues
According to Microsoft, and to use its exact wording, this incident is tied to a service degradation caused by the accumulation of test detectoids published in error to the WSUS channel. Behind this name are objects with titles such as Product Detectoid for ProductName TestProduct%. However, as they accumulate, they overload the metadata database that WSUS must process, to the point of dramatically increasing synchronization times and causing failures.
In its support document, Microsoft also explains that there are impacts on client machines, especially in Windows Update. Several error messages and codes are mentioned, and you may already have seen them if you've had some issues with your WSUS environment.
For example, you may encounter error 0x80244010 (WU_E_PT_EXCEEDED_MAX_SERVER_TRIPS), which indicates that the Windows Update scan exceeded the maximum number of round trips allowed with the WSUS server. Other codes may also appear, such as 0x80244022 (or HTTP 503) when the WsusPool application pool is overloaded, or 0x80072EE2 in the event of a network connectivity issue.
Microsoft's manual cleanup procedure
For servers still affected by these synchronization problems, Microsoft recommends following the instructions outlined in its remediation procedure (KB5121986). It was published on July 20, 2026, in the wake of this incident and applies to all versions of Windows Server.
Looking more closely at what Microsoft is proposing, it quickly becomes clear that this is a WSUS database cleanup. More importantly, the suggested cleanup will permanently delete update metadata. Here are the main steps to carry out:
- Back up each
SUSDBdatabase before taking any action, since deletion is permanent. - Run the cleanup query from SQL Server Management Studio against all
SUSDBdatabases, including those on replica servers. Deletions do not replicate from one server to another, so each catalog must be cleaned individually; otherwise, clients connected to an untreated server will continue to see the test detectoids. - Let the query remove the incorrect detectoids and set
MaxXMLPerRequestto0. This temporarily lifts the 5 MB limit and helps clients resynchronize properly. - Once WSUS is stable and clients have synchronized successfully, set
MaxXMLPerRequestback to its default value, which is5242880.
"It may be necessary to limit the maximum number of concurrent connections for the WSUS administration site in IIS, then increase it gradually to allow clients to complete the scan. The goal is to keep IIS CPU usage at around 80%.", Microsoft notes.
Once cleanup is complete, the vendor recommends reindexing the SUSDB database, running the WSUS Server Cleanup Wizard, and then running IISReset or recycling the WsusPool application pool to clear the catalog cache. So you have work to do on the WSUS server side, while things should proceed normally on the client side (otherwise, check the WindowsUpdate.log file).
Have your WSUS servers been affected by these synchronization slowdowns?
Mine it was. I am yet to follow up with the fix, but i before that i built a TestRun query to see how many of them are there and i was surprised to see 14409 of them. If you find it useful to add it to the article this is the query.
To execute the deletion DECLARE @testRun BIT = 1; — LIST ONLY. No deletions, no config changes. Safe to run anytime.
@testRun = 0 -> LIVE RUN. Runs Microsoft’s exact steps: deletes matching
detectoids AND sets MaxXMLPerRequest = 0.
Run this against EVERY SUSDB you manage, including replicas — deletions
do not propagate downstream.
BACK UP SUSDB before setting @testRun = 0. Example:
BACKUP DATABASE SUSDB
TO DISK = N’\SUSDB_PreDetectoidCleanup.bak’
WITH INIT, STATS = 5;
*/
SET NOCOUNT ON;
DECLARE @testRun BIT = 1; — <– change to 0 only when ready to actually delete
DECLARE @updateID uniqueidentifier;
DECLARE @retcode int;
DECLARE @deleted int = 0;
DECLARE @skipped int = 0;
DECLARE @found int = 0;
IF OBJECT_ID('tempdb..#DetectoidsToClean') IS NOT NULL
DROP TABLE #DetectoidsToClean;
— Identical SELECT to Microsoft's cursor query, captured into a temp table
— so it can be listed before (and reused during) the delete loop.
SELECT
u.UpdateID,
tlp.Title
INTO #DetectoidsToClean
FROM dbo.tbUpdate u
JOIN dbo.tbRevision r ON r.LocalUpdateID = u.LocalUpdateID AND r.IsLatestRevision = 1
JOIN dbo.tbProperty p ON p.RevisionID = r.RevisionID
JOIN dbo.tbLocalizedPropertyForRevision tbrp ON tbrp.RevisionID = r.RevisionID
JOIN dbo.tbLocalizedProperty tlp ON tlp.LocalizedPropertyID = tbrp.LocalizedPropertyID
WHERE p.UpdateType = 'Detectoid'
AND tbrp.LanguageID = p.DefaultPropertiesLanguageID
AND tlp.Title LIKE 'Product Detectoid for ProductName TestProduct%';
SELECT @found = COUNT(*) FROM #DetectoidsToClean;
PRINT CONCAT('Matched ', @found, ' detectoid(s) against the TestProduct naming pattern.');
— Result set showing the total count (visible in the Results grid, not just Messages)
SELECT @found AS TotalDetectoidsFound;
— Always show the full candidate list, in both modes
SELECT * FROM #DetectoidsToClean ORDER BY Title;
IF @testRun = 1
BEGIN
PRINT '— TEST RUN MODE —';
PRINT 'No rows deleted. MaxXMLPerRequest NOT changed.';
PRINT CONCAT('Would attempt to delete ', @found, ' update(s) if @testRun were set to 0.');
PRINT 'Note: some rows may still fail to delete in a live run if referenced';
PRINT 'elsewhere (e.g. still in a deployment) – spDeleteUpdateByUpdateID checks';
PRINT 'this internally and cannot be simulated from a read-only list.';
END
ELSE
BEGIN
PRINT '— LIVE RUN MODE —';
PRINT 'Proceeding with deletion and MaxXMLPerRequest change (per KB5121986). Make sure SUSDB was backed up first.';
UPDATE tbConfigurationC SET MaxXMLPerRequest = 0 –Update the MaxXMLPerRequest to lift the limit
DECLARE detectoid_cur CURSOR LOCAL FAST_FORWARD FOR
SELECT UpdateID FROM #DetectoidsToClean;
OPEN detectoid_cur;
FETCH NEXT FROM detectoid_cur INTO @updateID;
WHILE @@FETCH_STATUS = 0
BEGIN
BEGIN TRY
EXEC @retcode = dbo.spDeleteUpdateByUpdateID @updateID;
IF @retcode = 0 SET @deleted += 1; ELSE SET @skipped += 1;
END TRY
BEGIN CATCH
— Most common: "still referenced by other update(s)" – safe to skip and continue
SET @skipped += 1;
PRINT CONCAT('Skipped ', CONVERT(varchar(40), @updateID), ' : ', ERROR_MESSAGE());
END CATCH
FETCH NEXT FROM detectoid_cur INTO @updateID;
END
CLOSE detectoid_cur;
DEALLOCATE detectoid_cur;
PRINT CONCAT('Deleted: ', @deleted, ', Skipped: ', @skipped);
END
DROP TABLE #DetectoidsToClean;
/*
Reminder – after a successful LIVE run once things stabilize:
UPDATE tbConfigurationC SET MaxXMLPerRequest = 5242880;
Then: reindex SUSDB, run the WSUS Server Cleanup Wizard,
and IISReset / recycle WsusPool to clear cached catalog state.
*/