Microsoft Shares Fix for WSUS Sync Delays and Timeout Issues

Microsoft has confirmed a known issue affecting Windows Server Update Services (WSUS) that causes slow synchronization times and sync timeouts. The problem stems from a buildup of publishing metadata on existing WSUS servers as well as on the service side.

The issue became more noticeable around July 13, 2026, and Microsoft deployed a service-side fix on July 18, 2026, which restored normal sync performance for new or rebuilt WSUS installations. However, existing WSUS servers may still experience delays and require manual cleanup.

Organizations with existing WSUS server installations that are experiencing long sync times should understand that this issue is related to a buildup of publishing metadata, which is present on existing WSUS server installations as well as from the service side.

Errors associated with WSUS Update Scans

On client computers, the buildup can also cause Windows Update scans to fail or time out. Affected clients may log errors such as the following:

Microsoft’s Recommended Fix for WSUS Sync Delays and Timeout Issues

For existing WSUS server installations, Microsoft outlines a three‑step manual remediation process to fix the sync delays and timeout issues.

1. Back up the SUSDB databases

The first step is to back up each SUSDB database. A full backup is required because the cleanup permanently deletes update metadata. For information about creating the backup, see Create a full database backup.

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

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

2. Run a cleanup SQL query

Microsoft offers a SQL query (listed below) that does the following:

1. Deletes mis‑published detectoids causing sync issues.
2. Sets MaxXMLPerRequest = 0 to remove the 5 MB limit that can cause client scan failures.

The query should be run on every SUSDB, including replicas.

SET NOCOUNT ON;

UPDATE tbConfigurationC SET MaxXMLPerRequest = 0  --Update the MaxXMLPerRequest to lift the limit 

DECLARE @updateID uniqueidentifier;
DECLARE @retcode  int;
DECLARE @deleted  int = 0;
DECLARE @skipped  int = 0;

DECLARE detectoid_cur CURSOR LOCAL FAST_FORWARD FOR
    SELECT u.UpdateID
    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%';

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;

SET NOCOUNT ON;

UPDATE tbConfigurationC SET MaxXMLPerRequest = 0  --Update the MaxXMLPerRequest to lift the limit 

DECLARE @updateID uniqueidentifier;
DECLARE @retcode  int;
DECLARE @deleted  int = 0;
DECLARE @skipped  int = 0;

DECLARE detectoid_cur CURSOR LOCAL FAST_FORWARD FOR
    SELECT u.UpdateID
    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%';

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;

3. Restore MaxXMLPerRequest to default

Once WSUS is stabilized and clients have scanned successfully, the MaxXMLPerRequest value should be updated to its default setting by running the following query:

UPDATE tbConfigurationC SET MaxXMLPerRequest = 5242880

UPDATE tbConfigurationC SET MaxXMLPerRequest = 5242880

Microsoft also suggests adjusting IIS concurrent connections to keep CPU usage around 80%, helping clients complete scans. For more information, see Limits for a Web Site.