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\

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

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, но как бороться с ней мы уже знаем.

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

Комментарии (10)


  1. whiplash
    03.03.2016 15:09
    +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. gotch
      03.03.2016 16:10
      +1

      Спасибо. Есть целая группа проблем на предмет — то TLS не можем с WSUS согласовать, то прокси вдруг внезапно начали/прекратили использовать. Но тут обычно ничего не меняется, но каждый месяц кто-то да не может дальше обновляться.


    1. galaxy
      03.03.2016 22:27
      +1

      Да, попила крови эта ошибка, и ведь поди догадайся, из-за чего проблема...

      А знаете откуда ошибка? —

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

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

      https://www.cryptopro.ru/forum2/default.aspx?g=posts&t=7973


  1. fido_max
    03.03.2016 15:44

    А ошибку 0x80240020 при обновлении windows 7 pro x64 до windows 10 через WSUS (2012 R2) не подскажите как победить? Software distribution удалял. Все остальные обновления замечательно ставятся.


    1. gotch
      03.03.2016 16:13

      К сожалению, нет идей. У нас такие обновления суровее будут происходить, если конечно будут — все снесли, все поставили.


  1. navion
    03.03.2016 19:50
    +1

    А кто-нибудь в курсе, что за обновление может отправить семёрку на несколько часов в "Установка обновлений: 100%" или "Пожалуйста, подождите"?
    Такое эпизодически появляется последний год на разных компьютерах и во время сообщения что-то сильно нагружает диск. AppLocker не включен, так что хотфикс вряд ли поможет.


    1. Wayfarer15
      03.03.2016 20:09
      +1

      Встречался с таким и возникло стойкое "очучение", что Windows в этот момент делает скан всех дисков на предмет вирусов. Хотя я совершенно в этом не уверен. Однако подругому нельзя объяснить, почему на support форуме полно постов, что у кого-то это заняло пару часов, а у кого-то реально шуршало пару дней. После чего всё прекрасно устанавливается.
      PS. Абсолютно не уверен, что дело именно в этом, однако на MS support тоже ни кто толком не объяснил.


      1. navion
        04.03.2016 13:06

        С диском может быть ложный симптом, недавно словил такое на виртуалке и в мониторинге была 100% загрузка ЦП и лишь немного задействован диск.
        При этом никаких ошибок и необычных событий в журнале нет и профайлер не запустишь, так как после перезагрузки проблема уходит. Ещё вспомнил, как на паре компов после жесткой перезагрузки повредилась ФС.


  1. eevdokimov
    04.03.2016 14:48

    Пользуюсь вот таким файлом:

    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


  1. Gendalph
    07.03.2016 16:19

    Дополнение к пункту #4:
    Иногда даже этот вариант не помогает.
    Откройте и посмотрите лог cryptsvc: C:\Windows\System32\catroot2\dberr.txt
    У меня там была ругань с разнообразными ошибками, а остновка wuauserv не разблокировала SoftwareDistribution.
    Помогло в итоге:

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

    Обновления обнаружились и я смог их установить.