Löst: Problem med synkroniseringsåtgärder och tidsgränser för synkronisering i Windows Server Update Services

Ursprungligt publiceringsdatum: Juli 20, 2026
KB-ID: 5121986

Introduktion

Microsoft har identifierat en tjänsteförsämring på grund av en ansamling av publicerade testdetectoider i kanalen Windows Server Update Services (WSUS). De detectoider som är associerade med det här problemet kan identifieras med ett namngivningsmönster som liknar följande:

• Product Detectoid for ProductName TestProduct%

En problemdetectoid kan till exempel se ut så här:

• Produktdetectoid för ProductName TestProduct1272ad5c-e150-4370-b18d-7b940bd0e518

Organisationer kan uppleva längre synkroniseringstider eller tidsgränser för synkroniseringsåtgärden på WSUS-servrar. Det här problemet började nyligen, med ökad påverkan från och med den 13 juli 2026.

Microsoft har distribuerat en lösning för det här problemet den 18 juli 2026. Synkroniseringstider och synkroniseringsåtgärder på WSUS-servrar har återställts och fungerar normalt för nya WSUS-installationer och om-byggnationer. Den här åtgärden förhindrar att nyligen installerade eller ombyggda WSUS-servrar stöter på det här problemet.

På klientdatorer kan uppbyggnaden också orsaka att Windows Update -genomsökningar misslyckas eller överskrider tidsgränsen. Berörda klienter kan logga fel som följande:

Fel	Betydelse	Vad den visar
0x80244010	WU_E_PT_EXCEEDED_MAX_SERVER_TRIPS	Genomsökningen överskred det maximala antalet tur och retur-resor till WSUS. Detta är det viktigaste symptomet.
0x8024400E 0x80244007	WU_E_PT_SOAP_SERVER WU_E_PT_SOAPCLIENT_SOAPFAULT	Servern överskred tidsgränsen för bearbetningen av begäran eller så skickade klienten en överdimensionerad datauppsättning som WSUS avvisade.
0x80244022 HTTP 503	Tjänsten är inte tillgänglig	WSUS-programpoolen (WsusPool) är överbelagd.
0x80240439	WU_E_PT_INVALID_FORMAT	Överdimensionerade klient- eller serverdatauppsättningar som orsakar onormala IIS-fel.
0x80072EE2	WININET-timeout	Genomsökningen tog för lång tid och överskreds i tid.

Lösning

För WSUS-servrar som fortfarande påverkas av det här problemet rekommenderar vi att du kör följande steg för att återställa WSUS-servern till normal funktionalitet.

Steg 1: Säkerhetskopiera SUSDB:erna

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

Information om hur du skapar säkerhetskopian finns i Skapa en fullständig säkerhetskopia av databasen.

Steg 2: Kör rensningsfrågan

Den här frågan tar bort de felaktigt publicerade detectoids från ett WSUS-system. Värdet för MaxXMLPerRequest anges också till 0 (för att eliminera gränsen på 5 MB), vilket hjälper till att minska problemen med klienter som inte kan genomsökas på grund av att de maximala tur- och returresorna till WSUS överskrids när en synkronisering utförs.

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; 

Steg 3: Uppdatera MaxXMLPerRequest

När WSUS har stabiliserats och klienterna har genomsökts korrekt bör MaxXMLPerRequest-värdet uppdateras till standardinställningen genom att köra följande fråga:

UPDATE tbConfigurationC SET MaxXMLPerRequest = 5242880

När du har kört rensningen

• Klientåterställningen sker automatiskt Den första genomsökningen av varje klient efter rensningen gör en engångsåtgärd och kan ta längre tid än vanligt. Senare återgår skanningarna till normal tidtagning. Ingen åtgärd krävs för enskilda klienter.

• Bekräfta korrigeringen på en klient I klientens WindowsUpdate.log bör genomsökningsposten som läser evaluated appl. rules of X out of N deployed entities visa ett mycket lägre N efter nästa genomsökning. Sökning WindowsUpdate.log efter detectoid-ID:t returnerar inte matchningar, så använd antalet distribuerade enheter för att bekräfta lättnaden. Information om hur du skapar WindowsUpdate.log-filen finns i Generera WindowsUpdate.log.

• Underhålla servern En stor borttagning fragmenterar SUSDB-indexen. Efter rensningen indexerar du om SUSDB, kör guiden WSUS Server Cleanup och kör sedan IISReset eller återanvänder WsusPool-programpoolen för att rensa cachelagrat katalogtillstånd.

• DiskutrymmeDataStore.edb på klientsidan krymper inte automatiskt när detectoids har tagits bort. Detta är förväntat och påverkar inte genomsökningens prestanda.

Referenser

Den fullständiga guiden till WSUS- och Configuration Manager SUP-underhåll.