Windows update-feil (denne artikkelen kan være på engelsk) 80244022

for noen dager siden oppdaterte jeg min kontor laptop Til Windows 10 build 1703. Denne delen gikk bra. Men Etter omstart rapporterte Windows update en feil med kode 80244022. Forklaringen på denne feilen er uklar-noe gikk galt.

etter noen omstart, mange forsøk, selv sletting Av Programvaredistribusjonsmappen Fra Windows-mappen, søkte jeg På Nettet. Mange svar var som «det er bare borte». Som min feil er ikke bare borte med vinden, jeg visste at det er tid FOR HEV suite, brekkjern og dypdykk inn i verden av logger Og Windows-tjenester.

det er tid for den taktiske planen. Vi må trinnvis sjekke hele oppdateringsprosessen. Høyt nivå flyt av oppdateringsprosessen er som dette:

vår datamaskin ER EN wsus-klient, og den vil koble til den lokale wsus-serveren. At WSUS-serveren er en klient For Microsoft wsus-serveren.

hvis du er hjemmebruker eller firmaet ikke bruker wsus-serveren, vil datamaskinen være klienten For Microsoft wsus-serveren.

planen på høyt nivå

hvis du ikke kan laste ned de nyere oppdateringene, bør du prøve denne planen:

1. Finn wsus-serveren
2. Kontroller nettverkstilkoblingen
3. Kontroller oppdateringsklienten.
4. prøv å starte maskinen på nytt og prøv å oppdatere på nytt
5. prøv å stoppe AV-programmet.
6. Kontroller brannmurinnstillingene
7. Kontroller loggene på maskinen
8. (Eventuelt) slett alle tidligere nedlastede oppdateringer
9. Kontroller wsus-serveren

Kontroller wsus-innstillingene i Registret

DU kan kontrollere wsus-innstillingene for datamaskinen. Dette er viktig hvis du er hjemmebruker, da DU ikke ville bruke wsus-serveren. Du kan sjekke dette i nøkkelen HKLM \ SOFTWARE \ Policies \ Microsoft \ Windows \ WindowsUpdate, verdi WUServer.

Nå, bare hvis Du er sikker på at DU ikke bør bruke wsus-serveren, kan du slette verdiene fra denne nøkkelen. Start Windows update-tjenesten på Nytt. Dette kan løse problemet ditt.

Kontrollerer loggene

vi vil spole frem til 7. trinn. Som jeg alltid liker å si, loggene er mine beste venner. Vi bør starte Med Windows update-klientloggen. Denne loggen er vanligvis plassert på banen C:\Windows\SoftwareDistribution\ReportingEvents.logge.

jeg åpnet den, men det var ikke nyttig i det hele tatt:

jeg har bare feilkoden og den lengre meldingen om at oppdateringen mislyktes med feilen 0x80244022.

den gode nyheten er at det er en annen logg – C:\Windows\WindowsUpdate.logge. Inne bør du se en mer detaljert forklaring Om Windows update-prosessen.

I Windows 10 er denne filen tom. Men du kan generere den med powershell-kommandoen-Get-WindowsUpdateLog. Bare åpne powershell-vinduet og utfør kommandoen. Vær tålmodig.

etter en stund vil denne kommandoen generere denne loggen for deg på skrivebordet. Nå kan vi åpne den og analysere hvert trinn.

jeg analyserte alle disse linjene og identifiserte AT NETTADRESSEN TIL wsus-tjenesten er riktig. IMIDLERTID fant JEG HTTP-feilen 503-Tjenesten utilgjengelig. Dette er fremgang.

jeg kan konkludere med at MIN wsus-klient fungerer og at EN feil er PÅ WSUS-siden. Det er på tide å ta spillet til neste nivå.

Kontrollerer wsus-serveren

jeg logget PÅ wsus-serveren. Nå skal jeg sjekke tjenestene.

OK, alle tjenester kjører. Det ser bra ut. Det neste trinnet er iis-konsollen, da feilen er HTTP (Web) relatert.

jeg åpnet iis management console. Alt ser bra ut. Som første skritt sjekket Jeg Nettstedet WSUS Administration og dets bindinger. Det bør være bundet til port 8530 FOR HTTP-trafikk. DET bør være en binding for HTTPS på porten 8531, men denne er ikke så viktig nå.

jeg prøvde å åpne Nettsiden fra iis-konsollen. Jeg fikk samme feil som da jeg åpnet siden FRA IE-Tjenesten utilgjengelig.

nå husker jeg at denne applikasjonen også er. net-basert. Derfor byttet jeg til Siden applikasjonsbassenger og fant problemet.

wsus-programmet bruker sitt eget utvalg Kalt WsusPool. Dette bassenget ble stoppet. Jeg begynte på nytt og voila! WSUS-tjenesten kjører igjen.

Er dette slutten?

DENNE wsus-serveren er en DEL AV SCCM-serveren. Derfor kan problemet være i enhver tjeneste som fungerer på den serveren.

jeg møtte dette problemet et par ganger på rad og fant hvordan du manuelt fikser det. Jeg vil imidlertid ha en permanent løsning. Min første handling for den permanente løsningen er å forkorte idle time-out fra 20 til 5 minutter. Det er også lurt å øke bassengets interne minne.

Selv om dette problemet kan vises igjen, er det viktig at jeg har en veldig klar prosedyre for feilsøkingsprosessen. Videre har jeg nå en dokumentert løsning for dette problemet, som vil hjelpe OSS med å gjenopprette wsus-serveren mye raskere.

Vær systematisk og ikke gi opp for lett.

(Rediger 28.09.2017.) En permanent løsning er beskrevet i detalj i dette innlegget.

Følg med.