Windows update fel 80244022

för några dagar sedan uppdaterade jag min bärbara dator till Windows 10 build 1703. Denna del gick bra. Men efter omstart rapporterade Windows update ett fel med kod 80244022. Förklaringen av detta fel är oklart – något gick fel.

efter några omstart, många försök, till och med radering av Programvarudistributionsmappen från Windows-mappen, sökte jag på nätet. Många svar var som”det är bara borta”. Eftersom mitt fel inte bara är borta med vinden visste jag att det är dags för HEV-sviten, kofot och djupdykning i en värld av loggar och Windows-tjänster.

det är dags för den taktiska planen. Vi måste steg för steg kontrollera hela uppdateringsprocessen. Uppdateringsprocessens höga flöde är så här:

vår dator är en WSUS-klient och den kommer att ansluta till den lokala WSUS-servern. Den WSUS-servern är en klient för Microsoft WSUS-servern.

om du är en hemanvändare eller ditt företag inte använder WSUS-servern kommer din dator att vara klienten för Microsoft WSUS-servern.

högnivåplanen

om du inte kan ladda ner de nyare uppdateringarna bör du prova den här planen:

1. leta upp din WSUS-server
2. kontrollera din nätverksanslutning
3. kontrollera din uppdateringsklient.
4. försök att starta om datorn och försök att uppdatera igen
5. försök att stoppa AV-programmet.
6. kontrollera dina brandväggsinställningar
7. kontrollera loggarna på maskinen
8. (valfritt) ta bort alla tidigare nedladdade uppdateringar
9. kontrollera WSUS-servern

kontrollera WSUS-inställningarna i registret

du kan kontrollera WSUS-inställningarna för din dator. Detta är viktigt om du är en hemanvändare, eftersom du inte skulle använda WSUS-servern. Du kan kontrollera detta i nyckeln HKLM \ SOFTWARE \ Policies \ Microsoft \ Windows \ WindowsUpdate, värde WUServer.

nu, bara om du är säker på att du inte ska använda WSUS-servern, kan du ta bort värdena från den här nyckeln. Starta om Windows update-tjänsten. Detta kan lösa ditt problem.

kontrollera loggarna

vi kommer att spola fram till det 7: e steget. Som jag alltid vill säga, loggarna är mina bästa vänner. Vi bör börja med Windows update-klientloggen. Denna logg ligger vanligtvis på vägen C:\Windows\SoftwareDistribution\ReportingEvents.logga.

jag öppnade den, men det var inte till hjälp alls:

jag har bara felkoden och det längre meddelandet att uppdateringen misslyckades med felet 0x80244022.

den goda nyheten är att det finns en annan logg – C:\Windows\WindowsUpdate.logga. Inuti bör du se en mer detaljerad förklaring om Windows update-processen.

i Windows 10 är den här filen tom. Men du kan generera det med powershell command – Get-WindowsUpdateLog. Öppna bara powershell-fönstret och kör kommandot. Ha tålamod.

efter ett tag kommer det här kommandot att generera den här loggen för dig på skrivbordet. Nu kan vi öppna den och analysera varje steg.

jag analyserade alla dessa rader och identifierade att webbadressen till WSUS-tjänsten är korrekt. Jag hittade dock HTTP error 503-Tjänsten otillgänglig. Detta är framsteg.

jag kan dra slutsatsen att min WSUS-klient fungerar och att ett fel är på WSUS-sidan. Det är dags att ta spelet till nästa nivå.

kontrollera WSUS-servern

jag loggade in på WSUS-servern. Nu ska jag kolla tjänsterna.

OK, alla tjänster körs. Det ser bra ut. Nästa steg är IIS-konsolen, eftersom felet är HTTP (Web) relaterat.

jag öppnade IIS-hanteringskonsolen. Allt ser bra ut. Som det första steget kontrollerade jag webbplatsen WSUS Administration och dess bindningar. Den ska vara bunden till porten 8530 för HTTP-trafik. Det borde finnas ytterligare en bindning för HTTPS på porten 8531, men den här är inte så viktig nu.

jag försökte öppna webbsidan från IIS-konsolen. Jag fick samma fel som när jag öppnade sidan från IE – Tjänsten otillgänglig.

nu minns jag att den här applikationen också är.net-baserad. Därför bytte jag till sidan Applikationspooler och hittade problemet.

WSUS-applikationen använder sin egen pool som heter WsusPool. Denna pool stoppades. Jag började igen och … voila! WSUS-tjänsten körs igen.

är detta slutet?

denna WSUS-server är en del av SCCM-servern. Därför kan problemet vara i alla tjänster som fungerar på den servern.

jag mötte detta problem några gånger i rad och hittade hur man manuellt fixar det. Jag skulle dock vilja ha en permanent lösning. Min första åtgärd för den permanenta lösningen är att förkorta tomgångstiden från 20 till 5 minuter. Det är också klokt att öka poolens interna minne.

även om det här problemet kan visas igen är det viktigt att jag har en mycket tydlig procedur för felsökningsprocessen. Dessutom har jag nu en dokumenterad lösning för det här problemet, vilket hjälper oss att återställa WSUS-servern mycket snabbare.

var systematisk och ge inte upp till lätt.

(redigera 28.09.2017.) En permanent lösning beskrivs i detalj i det här inlägget.

håll ögonen öppna.