Исправляем ошибки установки обновлений Windows 7

  • Tutorial
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 у нее есть единственное и очень специфическое решение — удалить ключ
HKLM\Components\PendingRequired=1

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

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

Практически 100% других ошибок может решить System Update Readiness Tool (SURT) из статьи support.microsoft.com/en-us/kb/947821
Скачиваете пакет для вашей системы, устанавливаете, читаете лог %windir%\Logs\CBS\CheckSUR.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:\windows\temp\Windows6.1-KB947821-v34-x64.msu" /quiet /norestart
pause

где BUHWKS02 – целевая машина.
Когда скрипт отработает и встанет на паузу, проверяем %windir%\Logs\CBS\CheckSUR.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:
winsxs\manifests\wow64_microsoft-windows-gdi32_31bf3856ad364e35_6.1.7601.19091_none_c19fa2719495aca9.manifest
winsxs\manifests\amd64_microsoft-windows-capi2-weakcrypto_31bf3856ad364e35_6.1.7601.23290_none_5e936c9c5ce2e8e6.manifest
winsxs\manifests\wow64_microsoft-windows-gdi32_31bf3856ad364e35_6.1.7601.23290_none_c22840d8adb43043.manifest
winsxs\manifests\amd64_microsoft-windows-gdi32_31bf3856ad364e35_6.1.7601.19091_none_b74af81f6034eaae.manifest
winsxs\manifests\amd64_microsoft-windows-capi2-weakcrypto_31bf3856ad364e35_6.1.7601.19091_none_5e0ace3543c4654c.manifest
winsxs\manifests\amd64_microsoft-windows-gdi32_31bf3856ad364e35_6.1.7601.23290_none_b7d3968679536e48.manifest
servicing\packages\Package_2_for_KB3123479~31bf3856ad364e35~amd64~~6.1.1.0.mum
servicing\packages\Package_2_for_KB3123479~31bf3856ad364e35~amd64~~6.1.1.0.mum
servicing\packages\Package_for_KB3123479_SP1~31bf3856ad364e35~amd64~~6.1.1.0.mum

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

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

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

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

*.mum and *.cat из C:\Windows\servicing\Packages складываются в %windir%\Temp\CheckSUR\servicing\packages
*.manifest из C:\Windows\winsxs\Manifests складываются в %windir%\Temp\CheckSUR\winsxs\manifests\

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

cls
$flag = $false
$destPC = "\\BUHWKS02"
$log=get-content $($destPC + "\admin$\Logs\CBS\CheckSUR.log")
$MUMCATSource = "C:\Windows\servicing\Packages\"
$MUMCATDest = $destpc + "\admin$\Temp\CheckSUR\servicing\Packages\"
$MANIFESTSource = "C:\Windows\winsxs\Manifests\"
$MANIFESTDest = $destpc + "\admin$\Temp\CheckSUR\winsxs\Manifests\"
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%\Temp\CheckSUR и заменить ими испорченные.
Если мы сделали все правильно, то %windir%\Logs\CBS\CheckSUR.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

set machine= BUHWKS02
psexec -i -s \\%machine% wuauclt /updatenow
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 "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v SusClientId /f
REG DELETE "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /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».

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

Комментарии 20

    +1
    Хорошая, годная статья.

    Добавлю из опыта:

    — Много пишут, что ошибка 0x800B0001 возникала в 2014-2015 году именно у windows 7 + криптоПРО 3.6
    https://www.cryptopro.ru/forum2/default.aspx?g=posts&t=7973
    http://remontka.pro/800b0001-error/
    http://www.tune-it.ru/web/fender/blog/-/blogs/%D0%BE%D1%88%D0%B8%D0%B1%D0%BA%D0%B0-%D0%BE%D0%B1%D0%BD%D0%BE%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F-windows-800b0001-80244018-cryptopro-vipnet?p_p_auth=B0lgkHFx
    http://bazanovv.livejournal.com/37371.html

    “Windows update error 800B0001 и Крипто-Про CSP 3.6
    Наступили на глупые грабли, тем более глупые, что уже второй раз. При автоматической установке обновлений со WSUS 3.0 на рабочих станциях всё ок, при ручном поиске обновлений оттуда-же — ошибка 800B0001. В логах — ошибка проверки подписи автообновления клиента Windows Update. CheckSUR ошибок не находит, проявилось достаточно массово. Уже и агент Windows Update проверил-обновил, там обновления были, и на WSUS последний патч накатил — безрезультатно. Как оказалось, это опять что-то протухло в Крипто-Про CSP 3.6. Подобная ошибка уже была с год назад, там истёк сертификат, которым был подписан код, и вот опять. Лечится обновлением Крипто-Про до v3.6.7777 (3.6 R4).”
      +1
      Спасибо. Есть целая группа проблем на предмет — то TLS не можем с WSUS согласовать, то прокси вдруг внезапно начали/прекратили использовать. Но тут обычно ничего не меняется, но каждый месяц кто-то да не может дальше обновляться.
        +1
        Да, попила крови эта ошибка, и ведь поди догадайся, из-за чего проблема...

        А знаете откуда ошибка? —
        Windows Update стал требовать поддержку sha256 от дефолтного криптопровайдера системы.

        А недешевая сертифицированная Крипто Про не умеет :(

        https://www.cryptopro.ru/forum2/default.aspx?g=posts&t=7973
        0
        А ошибку 0x80240020 при обновлении windows 7 pro x64 до windows 10 через WSUS (2012 R2) не подскажите как победить? Software distribution удалял. Все остальные обновления замечательно ставятся.
          0
          К сожалению, нет идей. У нас такие обновления суровее будут происходить, если конечно будут — все снесли, все поставили.
          +1
          А кто-нибудь в курсе, что за обновление может отправить семёрку на несколько часов в "Установка обновлений: 100%" или "Пожалуйста, подождите"?
          Такое эпизодически появляется последний год на разных компьютерах и во время сообщения что-то сильно нагружает диск. AppLocker не включен, так что хотфикс вряд ли поможет.
            +1
            Встречался с таким и возникло стойкое "очучение", что Windows в этот момент делает скан всех дисков на предмет вирусов. Хотя я совершенно в этом не уверен. Однако подругому нельзя объяснить, почему на support форуме полно постов, что у кого-то это заняло пару часов, а у кого-то реально шуршало пару дней. После чего всё прекрасно устанавливается.
            PS. Абсолютно не уверен, что дело именно в этом, однако на MS support тоже ни кто толком не объяснил.
              0
              С диском может быть ложный симптом, недавно словил такое на виртуалке и в мониторинге была 100% загрузка ЦП и лишь немного задействован диск.
              При этом никаких ошибок и необычных событий в журнале нет и профайлер не запустишь, так как после перезагрузки проблема уходит. Ещё вспомнил, как на паре компов после жесткой перезагрузки повредилась ФС.
                0
                Появилась безумная мысль: может быть загрузку блокирует клиент Windows Update, который может часами искать обновления, шурша диском и загружая ЦП?
                  0
                  Интересное предположение. Как-то пристально рассматривал машины с W7, на которых клиент «бесконечно» искал обновления. Так вот он процессор и память утилизировал с удовольствием (100% CPU, 1-1,2Gb RAM, плавает по ходу работы). А к диску обращений нет.

                  Есть ли такая проблема, любопытно, с свежим KB3138612 «Windows Update Client for Windows 7 and Windows Server 2008 R2: March 2016»
              0
              Пользуюсь вот таким файлом:

              sc sdset bits D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)
              net stop "Background Intelligent Transfer Service"
              net start "Background Intelligent Transfer Service"
              net stop "Фоновая интеллектуальная служба передачи (BITS)"
              net start "Фоновая интеллектуальная служба передачи (BITS)"
              net stop "BITS"
              net start "BITS"
              gpupdate
              gpupdate /force
              wuauclt /detectnow
                0
                Дополнение к пункту #4:
                Иногда даже этот вариант не помогает.
                Откройте и посмотрите лог cryptsvc: C:\Windows\System32\catroot2\dberr.txt
                У меня там была ругань с разнообразными ошибками, а остновка wuauserv не разблокировала SoftwareDistribution.
                Помогло в итоге:

                • загрузиться в безопасном режиме (для разблокировки SoftwareDistribution, некоторым может хватить просто остановки wuauserv и bits)
                • net stop cryptsvc
                • переместить C:\Windows\System32\catroot2 и C:\Windows\SoftwareDistribution
                • загрузиться в нормальном режиме и ждать, около часа

                Обновления обнаружились и я смог их установить.
                  0
                  Спасибо, интересно в чем причина проблемы с cryptsvc, и какая взаимосвязь с WU. У меня catroot2\dberr.txt пестрит ошибками, а нарушений целостности CheckSUR нет.

                  Пока "занятый" каталог SoftwareDistribution не встречался, возьмем на заметку.
                    0
                    Сегодня такую же штуковину провернули на 2008-R2 — полетели обновления.
                    Я еще не разобрался, но вроде бы не только обновления не ставились, но и новые роли.

                    А связь простая — вот описание сервиса: http://maximumpcguides.com/windows-7/what-is-the-cryptographic-services-cryptsvc-service/
                    Если нельзя верифицировать целостность обновления, то как вы её ставить будете? Причем, я подозреваю вопрос не столько в обновлении, сколько в списке обновлений — если нельзя верифицировать подпись списка обновлений, то качать нечего, что и наблюдаем.
                  0
                  И я вкину информации в базу знаний:
                  Если у вас на клиентах начали возникать ошибки 80072EE2, то вам придется переустанавливать WSUS, т.к. БД приказала долго жить.
                  Сама ошибка означает таймаут сервера обновлений.
                    0
                    У меня такие пока успешно лечатся iisreset. БД на другом сервер, по SQL Server Standard.
                      0
                      Если вы имеете ввиду перезапуск служб, то в таком случае помогала бы и просто перезагрузка всего сервера.
                      Если же она не помогает, то это БД, По крайней мере в случае с WID.
                        0
                        Да, это перезапуск служб. Сервер жалко перезагружать, он используется как вспомогательный файловый сервер.
                        Интересно, что там внутри SQL может сломаться, DBCC CHECKDB ничего интересного не пишет?
                          0
                          Не могу вам сказать, бекапов за то время уже нет.
                          Часть старых клиентов обновлялась нормально, новые и немного старых отказывались, ссылаясь на эту ошибку.
                          После переустановки WID все в норме.
                            +1
                            Увеличил память для App Pool WSUS. Ошибка ушла. Добавил в статью.

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое