80244008 ошибка обновления windows 7

Hi,

I’ve been all over every post I could find about this, and tried anything that applied to my situation.  The most common solution (specifying default port) is not applicable because it was specified as 8530 (and still is, in GPO and registry on the client) and was working for several months with no issues.

We have started to deploy images to workstations, however I am using sbs 2008 and WDS which requires sysprep to be run before the image can even be taken.

Here is a sample of the WindowsUpdate.log from a client:

2009-04-29 15:36:42:811  888 180 Agent *************

2009-04-29 15:36:42:811  888 180 Agent ** START **  Agent: Finding updates [CallerId = AutomaticUpdates]

2009-04-29 15:36:42:811  888 180 Agent *********

2009-04-29 15:36:42:811  888 180 Agent   * Online = Yes; Ignore download priority = No

2009-04-29 15:36:42:811  888 180 Agent   * Criteria = «IsInstalled=0 and DeploymentAction=’Installation’ or IsPresent=1 and DeploymentAction=’Uninstallation’ or IsInstalled=1 and DeploymentAction=’Installation’ and RebootRequired=1 or IsInstalled=0 and DeploymentAction=’Uninstallation’ and RebootRequired=1»

2009-04-29 15:36:42:811  888 180 Agent   * ServiceID = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}

2009-04-29 15:36:42:812  888 180 Agent   * Search Scope = {Machine}

2009-04-29 15:36:42:812  888 180 Setup Checking for agent SelfUpdate

2009-04-29 15:36:42:812  888 180 Setup Client version: Core: 7.2.6001.788  Aux: 7.2.6001.788

2009-04-29 15:36:42:812  888 180 Misc Validating signature for C:WindowsSoftwareDistributionSelfUpdatewuident.cab:

2009-04-29 15:36:42:815  888 180 Misc  Microsoft signed: Yes

2009-04-29 15:36:42:822  888 180 Misc Validating signature for C:WindowsSoftwareDistributionSelfUpdatewuident.cab:

2009-04-29 15:36:42:825  888 180 Misc  Microsoft signed: Yes

2009-04-29 15:36:42:827  888 180 Misc Validating signature for C:WindowsSoftwareDistributionSelfUpdatewsus3setup.cab:

2009-04-29 15:36:42:830  888 180 Misc  Microsoft signed: Yes

2009-04-29 15:36:42:834  888 180 Misc Validating signature for C:WindowsSoftwareDistributionSelfUpdatewsus3setup.cab:

2009-04-29 15:36:42:836  888 180 Misc  Microsoft signed: Yes

2009-04-29 15:36:42:877  888 180 Setup Determining whether a new setup handler needs to be downloaded

2009-04-29 15:36:42:877  888 180 Setup SelfUpdate handler update required: Current version: 7.2.6001.788, required version: 7.1.6001.65

2009-04-29 15:36:42:877  888 180 Setup Evaluating applicability of setup package «WUClient-SelfUpdate-ActiveX~31bf3856ad364e35~amd64~~7.1.6001.65»

2009-04-29 15:36:42:880  888 180 Setup Setup package «WUClient-SelfUpdate-ActiveX~31bf3856ad364e35~amd64~~7.1.6001.65» is already installed.

2009-04-29 15:36:42:881  888 180 Setup Evaluating applicability of setup package «WUClient-SelfUpdate-Aux-TopLevel~31bf3856ad364e35~amd64~~7.1.6001.65»

2009-04-29 15:36:42:905  888 180 Setup Setup package «WUClient-SelfUpdate-Aux-TopLevel~31bf3856ad364e35~amd64~~7.1.6001.65» is already installed.

2009-04-29 15:36:42:905  888 180 Setup Evaluating applicability of setup package «WUClient-SelfUpdate-Core-TopLevel~31bf3856ad364e35~amd64~~7.1.6001.65»

2009-04-29 15:36:42:941  888 180 Setup Setup package «WUClient-SelfUpdate-Core-TopLevel~31bf3856ad364e35~amd64~~7.1.6001.65» is already installed.

2009-04-29 15:36:42:941  888 180 Setup SelfUpdate check completed.  SelfUpdate is NOT required.

2009-04-29 15:36:45:323  888 180 PT +++++++++++  PT: Synchronizing server updates  +++++++++++

2009-04-29 15:36:45:323  888 180 PT   + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://sbs.syntapa.local:8530/ClientWebService/client.asmx

2009-04-29 15:36:45:413  888 180 PT WARNING: Cached cookie has expired or new PID is available

2009-04-29 15:36:45:413  888 180 PT Initializing simple targeting cookie, clientId = c76e43ac-29d2-465e-ab61-cfd1d090130d, target group = , DNS name = devwork4.syntapa.local

2009-04-29 15:36:45:413  888 180 PT   Server URL = http://sbs.syntapa.local:8530/SimpleAuthWebService/SimpleAuth.asmx

2009-04-29 15:36:45:424  888 180 PT WARNING: GetAuthorizationCookie failure, error = 0x80244008, soap client error = 8, soap error code = 0, HTTP status code = 200

2009-04-29 15:36:45:424  888 180 PT WARNING: Failed to initialize Simple Targeting Cookie: 0x80244008

2009-04-29 15:36:45:424  888 180 PT WARNING: PopulateAuthCookies failed: 0x80244008

2009-04-29 15:36:45:424  888 180 PT WARNING: RefreshCookie failed: 0x80244008

2009-04-29 15:36:45:424  888 180 PT WARNING: RefreshPTState failed: 0x80244008

2009-04-29 15:36:45:424  888 180 PT WARNING: Sync of Updates: 0x80244008

2009-04-29 15:36:45:425  888 180 PT WARNING: SyncServerUpdatesInternal failed: 0x80244008

2009-04-29 15:36:45:425  888 180 Agent   * WARNING: Failed to synchronize, error = 0x80244008

2009-04-29 15:36:45:475  888 180 Agent   * WARNING: Exit code = 0x80244008

2009-04-29 15:36:45:475  888 180 Agent *********

2009-04-29 15:36:45:475  888 180 Agent **  END  **  Agent: Finding updates [CallerId = AutomaticUpdates]

2009-04-29 15:36:45:475  888 180 Agent *************

2009-04-29 15:36:45:475  888 180 Agent WARNING: WU client failed Searching for update with error 0x80244008

2009-04-29 15:36:45:479  888 e74 AU >>##  RESUMED  ## AU: Search for updates [CallId = {A4F87745-DEB6-45CB-BB05-3887A2F96A10}]

2009-04-29 15:36:45:479  888 e74 AU   # WARNING: Search callback failed, result = 0x80244008

2009-04-29 15:36:45:479  888 e74 AU   # WARNING: Failed to find updates with error code 80244008

2009-04-29 15:36:45:479  888 e74 AU #########

2009-04-29 15:36:45:479  888 e74 AU ##  END  ##  AU: Search for updates [CallId = {A4F87745-DEB6-45CB-BB05-3887A2F96A10}]

2009-04-29 15:36:45:479  888 e74 AU #############

2009-04-29 15:36:45:479  888 e74 AU AU setting next detection timeout to 2009-04-30 00:36:45

2009-04-29 15:36:50:477  888 180 Report REPORT EVENT: {061A5CAB-395F-46F1-95C6-C7EFB6074BBA} 2009-04-29 15:36:45:475-0400 1 148 101 {00000000-0000-0000-0000-000000000000} 0 80244008 AutomaticUpdates Failure Software Synchronization Windows Update Client failed to detect with error 0x80244008.

This phrase «SelfUpdate handler update required: Current version: 7.2.6001.788, required version: 7.1.6001.65» confuses me, however the error seems to come later, but maybe it is related to that?

I have no issue getting updates from microsoft servers (ie not through local WSUS).

The last successful update check was April 14, 2009 @ 3:55PM, updates were last installed April 14, 2009 @ 1:09PM.

I am about to install the most recent updates manually but I don’t see anything in there that might resolve it (other than -maybe- SBS update rollup 2).

All of sudden, all Windows desktops at work started having this issue when trying to connect to WSUS server for Windows updates. On Windows 7, it states that

Windows could not search for new updates

Errors found: Code 80244008

On Windows 10, the error message is slightly different.

There were some problems installing updates, but we’ll try again later…(0x8024401f)

What’s the cause?

I believe it’s this Windows update (KB4025336 – 2017-07 Security Monthly Quality Rollup for Windows Server 2012 R2 for x64-based Systems) that caused the issue. Basically, if your WSUS service is running on the default port 8530 you will likely have this issue on your network.

Solutions

Obviously, removing the troublesome KB4025336 should be able to rollback the WSUS server to the last working state.

But if that’s not the option, you can also run the following commands to reset WSUS’ IIS port.

wsusutil.exe usecustomwebsite true
wsusutil.exe usecustomwebsite false
iisreset /restart

Note that the command line wsusutil.exe is located in the following folder:

C:Program FilesUpdate ServicesTools

Once IIS server restarted, try Windows Update again on a workstation. If it fails again with a different error message like below,

Windows could not search for new updates

Errors found: Code 80072EE2

Check the Group Policy setting and specify the port number in the following group setting.

Specify intranet Microsoft update service location

Now everything should be back to normal now.

Время на прочтение
6 мин

Количество просмотров 254K

Windows 7 по-прежнему остается популярной операционной системой в корпоративной среде, несмотря на то, что уже вышли две новые версии клиентских ОС. Расширенная поддержка «семёрки» закончится лишь 14 января 2020 г., а это значит, что ближайшие 4 года для нее будут выходить обновления, исправляющие обнаруженные уязвимости.

Существует правило – если есть обновления, то есть и проблемы с их установкой. Давайте разберем, какие основные проблемы возникают при обновлении Windows 7 через Windows Server Update Services (WSUS) и как их исправить с наименьшими затратами.

Ошибка #1. Failed to find updates with error code 80244010

Эту ошибку вы практически гарантированно будете наблюдать на любой системе, впервые обратившейся к серверу WSUS. В WindowsUpdate.log также встретится предупреждение:
WARNING: Exceeded max server round trips

Причина проблемы в том, что список обновлений стал слишком большим, и клиент не может принять его за один заход. Подробности — blogs.technet.microsoft.com/sus/2008/09/18/wsus-clients-fail-with-warning-syncserverupdatesinternal-failed-0x80244010
Какое решение предлагает Microsoft? Если после ошибки запустить повторный поиск обновлений, то процесс загрузки метаданных продолжится с момента возникновения ошибки. Терпение господа, терпение. Три, пять попыток wuauclt /detectnow – и все образуется. Не забудьте при повторном поиске дождаться окончания предыдущего цикла поиска, иначе магия не сработает!

Ошибка #2. Не устанавливаются обновления Windows с ошибкой 0x80070308

Встречается эпизодически, и в одном случае из 100 у нее есть единственное и очень специфическое решение — удалить ключ
HKLMComponentsPendingRequired=1

Перезагрузиться. Здесь важно не переусердствовать, не следует удалять никакие другие ключи в этом разделе, даже если они вам очень не нравятся, потому что после этого обновления прекратят ставиться навсегда.

Ошибка #3. Все другие ошибки

Практически 100% других ошибок может решить System Update Readiness Tool (SURT) из статьи support.microsoft.com/en-us/kb/947821
Скачиваете пакет для вашей системы, устанавливаете, читаете лог %windir%LogsCBSCheckSUR.log и если он заканчивается примерно так:

Summary:
Seconds executed: 1164
Found 16 errors
Fixed 4 errors

то вы наш клиент.

Проблема заключается в том, что во время установки обновлений в системе могут появиться битые файлы. Что является причиной — неисправная сеть, диск, оперативная память, сам Windows Update – выяснить не получится, а исправить ошибки для установки последующих обновлений придется.

Как правило, повреждаются *.cat, *.mum, *.manifest файлы. У кого-то повреждаются *.dll, но я на практике не сталкивался. И вроде бы средство SURT должно само исправить ошибки, поскольку внутри него есть огромный каталог эталонных файлов. Только в последний раз SURT обновлялся в октябре 2014 года, а исправлений на операционную систему с тех пор вышло бесчисленное множество, и многих файлов в каталоге не хватает.

Ниже я опишу последовательность действий, необходимых для исправления ошибок установки обновлений на Windows 7 x64 с использованием SURT. Для редакции x86 просто потребуется другой пакет SURT из KB947821.

Последовательность действий будет следующая.

1. Запустить первый проход Windows6.1-KB947821-v34-x64.msu

Пользователя от работы отвлекать не потребуется, все сделаем удаленно. Создаем следующий командный файл и запускаем его:

set machine=BUHWKS02
xcopy Windows6.1-KB947821-v34-x64.msu \%machine%admin$temp
psexec -s \%machine% wusa "c:windowstempWindows6.1-KB947821-v34-x64.msu" /quiet /norestart
pause

где BUHWKS02 – целевая машина.
Когда скрипт отработает и встанет на паузу, проверяем %windir%LogsCBSCheckSUR.log
Если ошибок не найдено – дело не в битых обновлениях.
Если он заканчивается

Summary:
Seconds executed: 1164
Found 16 errors
Fixed 4 errors
CSI Manifest All Zeros Total count: 6
CSI Catalog Corrupt Total count: 3
Fixed: CSI Catalog Corrupt. Total count: 3
CBS MUM Corrupt Total count: 3
CBS Catalog Corrupt Total count: 3
CSI Catalog Thumbprint Invalid Total count: 1
Fixed: CSI Catalog Thumbprint Invalid. Total count: 1
Unavailable repair files:
winsxsmanifestswow64_microsoft-windows-gdi32_31bf3856ad364e35_6.1.7601.19091_none_c19fa2719495aca9.manifest
winsxsmanifestsamd64_microsoft-windows-capi2-weakcrypto_31bf3856ad364e35_6.1.7601.23290_none_5e936c9c5ce2e8e6.manifest
winsxsmanifestswow64_microsoft-windows-gdi32_31bf3856ad364e35_6.1.7601.23290_none_c22840d8adb43043.manifest
winsxsmanifestsamd64_microsoft-windows-gdi32_31bf3856ad364e35_6.1.7601.19091_none_b74af81f6034eaae.manifest
winsxsmanifestsamd64_microsoft-windows-capi2-weakcrypto_31bf3856ad364e35_6.1.7601.19091_none_5e0ace3543c4654c.manifest
winsxsmanifestsamd64_microsoft-windows-gdi32_31bf3856ad364e35_6.1.7601.23290_none_b7d3968679536e48.manifest
servicingpackagesPackage_2_for_KB3123479~31bf3856ad364e35~amd64~~6.1.1.0.mum
servicingpackagesPackage_2_for_KB3123479~31bf3856ad364e35~amd64~~6.1.1.0.mum
servicingpackagesPackage_for_KB3123479_SP1~31bf3856ad364e35~amd64~~6.1.1.0.mum

то будем исправлять.

2. Копируем эталонные файлы на целевую машину

Microsoft предлагает нам длинную, путанную процедуру с извлечением хороших файлов из обновлений и размещением их в определенные каталоги средства SURT. При этом пути в статьях неверные. Где-то и вовсе рекомендуют подкладывать оригинальные msu файлы.

Самый простой и правильный вариант следующий — скопировать эталонные файлы с рабочей системы:

*.mum and *.cat из C:WindowsservicingPackages складываются в %windir%TempCheckSURservicingpackages
*.manifest из C:WindowswinsxsManifests складываются в %windir%TempCheckSURwinsxsmanifests

Проблема в том, что битых файлов обычно десятки, и их очень сложно выбрать и скопировать. Тогда на помощь приходит следующий скрипт PowerShell (эталонной считается машина, с которой вы запускаете скрипт)

cls
$flag = $false
$destPC = "\BUHWKS02"
$log=get-content $($destPC + "admin$LogsCBSCheckSUR.log")
$MUMCATSource = "C:WindowsservicingPackages"
$MUMCATDest = $destpc + "admin$TempCheckSURservicingPackages"
$MANIFESTSource = "C:WindowswinsxsManifests"
$MANIFESTDest = $destpc + "admin$TempCheckSURwinsxsManifests"
If ((Test-Path -Path $MUMCATDest -PathType Container) -eq $false) {New-Item -Path $MUMCATDest -ItemType directory }
If ((Test-Path -Path $MANIFESTDest -PathType Container) -eq $false) {New-Item -Path $MANIFESTDest -ItemType directory}
foreach ($line in $log) {  
    if ($flag -eq $True){
        if ($line.trim().Length -ne 0) {        
            $fileArray=$($line.Split(""))
            $file = $FileArray[$FileArray.Length-1]
            $extArray = $file.split(".")
            $ext = $extArray[$extArray.length-1]
            if ($ext -eq "manifest") {
                Write-Warning $("Copying " + $($MANIFESTSource+$file)+" to " + $MANIFESTDest)
                Copy-Item $($MANIFESTSource+$file) $($MANIFESTDest+$file)
            }
            if (($ext -eq "mum") -or ($ext -eq "cat") ) {
                Write-Warning $("Copying " + $($MUMCATSource+$file)+" to " + $MUMCATDest)
                Copy-Item $($MUMCATSource+$file) $($MUMCATDest+$file)
            }
        }
    }
    if ($line -eq "Unavailable repair files:") {$flag = $true}    
} 

Как видите, скрипт прост и может быть легко заточен напильником под вашу инфраструктуру.

3. Запускаем второй проход Windows6.1-KB947821-v34-x64.msu

После копирования файлов мы повторно запускаем SURT, используя командный файл из первого шага. При повторном запуске средство сможет подхватить скопированные нами эталонные файлы из %windir%TempCheckSUR и заменить ими испорченные.
Если мы сделали все правильно, то %windir%LogsCBSCheckSUR.log примет следующий вид:

=================================
Checking System Update Readiness.
Binary Version 6.1.7601.22471
Package Version 26.0
2016-03-03 09:15
Checking Windows Servicing Packages
Checking Package Manifests and Catalogs
Checking Package Watchlist
Checking Component Watchlist
Checking Packages
Checking Component Store
Summary:
Seconds executed: 1435
No errors detected

Теперь можно продолжить установку обновлений на целевую машину, например, следующими командными файлами:
set machine= BUHWKS02
psexec -i -s \%machine% wuauclt /detectnow
pause

Ошибка #4. Если SURT отработал нормально, а обновления все равно не ставятся

Попробуйте прибегнуть к старому приему – сбросить службу Windows Update в исходное состояние. Для этого необходимо удалить каталог %windir%SoftwareDistribution.

Создаем файл WU-cleanupCMD.cmd:
net stop wuauserv
rmdir /s /q %windir%SoftwareDistribution
net start wuauserv
wuauclt /detectnow

Запускаем:
set machine= BUHWKS02
psexec -c -s \%machine% WU-cleanupCMD.cmd
pause

После этого возникнет Ошибка #1, но как бороться с ней мы уже знаем.

Ошибка #5

Клиент исчезает из консоли WSUS. Любопытная ошибка, связанная с неправильным клонированием машин и задвоением (затроением и т.д.) идентификаторов клиентов. Решается так:

net stop wuauserv
REG DELETE "HKLMSOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdate" /v SusClientId /f
REG DELETE "HKLMSOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdate" /v SusClientIdValidation /f
net start wuauserv
wuauclt /resetauthorization /detectnow /reportnow

Ошибка #6

GetCookie failure, error = 0x8024400D, soap client error = 7, soap error code = 300, HTTP status code = 200
SyncUpdates failure, error = 0x80072EE2, soap client error = 5, soap error code = 0, HTTP status code = 200
Windows Update Client failed to detect with error 0x80072ee2

Ошибка связана с нехваткой ресурсов в AppPool WSUS. Решение — снять лимит на потребляемую память. Как это сделать — статья.
Коротко: Открываем IIS, Application Pools, WsusPool, Advanced Settings.
Параметр Private Memory Limit устанавливаем в 0.

Продолжение темы настройки WSUS — в моей следующей статье: https://habrahabr.ru/post/329440/

PS:
Многие ошибки решены в новом клиенте WSUS:
1. KB3125574 «Windows 7 post SP1 Convenience Rollup Update». Внимательно ознакомьтесь с разделом Known issues!

Предварительно необходимо установить KB3020369 «April 2015 servicing stack update for Windows 7 and Windows Server 2008 R2».

Удачного администрирования!