Ошибка 80244019 и ошибка 84B20001 при обновлении в Windows Server 2008 R2
Ошибка 80244019 и ошибка 84B20001 при обновлении в Windows Server 2008 R2
Ошибка 80244019 при обновлении в Windows Server 2008 R2
Всем привет сегодня расскажу из-за чего появляется ошибка 80244019 и ошибка 84B20001 при обновлении в Windows Server 2008 R2 и как она решается, сразу хочу отметить, что ее повстречать вы сможете и в современных версиях операционной системы, хоть в десятке или Windows Server 2016. Решение будет везде одинаковым. Вообще странно, что данных глюк, тянется уже лет семь, и я уверен, и дальше мы его будем наблюдать, так как вирусы будут всегда, да и пользователи будут засирать систему, не менее интенсивно, чем сейчас.
Ошибка 80244019 в виндовс
Давайте разбираться, как исправить ошибку 80244019, более детально как она выглядит представлено на скриншоте, как видите у меня обе эти пакости 80244019 и 84B20001. Вообще забавная формулировка у 84B20001 (произошла неизвестная ошибка Windows Update)
Ошибка 80244019 при обновлении в Windows Server 2008 R2-01
Самые распространенные причины, из-за которых может возникать данная ошибка 80244019 и ошибка 84B20001 это:
- Вирус
- Не работает служба Bits и Обновление Windows
- И нужно почистить реестр от старых и не верных ключей.
- блокирует firewall
- проверить есть ли интернет
- проверить ваши dns
- перезапуск службы BITS
Первое что нужно сделать это проверить работают ли службы. Для этого мы нажимаем Win+R откроется окно выполнить и вводим services.msc,
Ошибка 80244019 при обновлении в Windows Server 2008 R2-02
откроется оснастка службы. Делаем все по алфавиту и смотрим в самом низу, чтобы были запущены Центр обновления Windows и Фоновая интеллектуальная служба передачи (BITS).
Ошибка 80244019 при обновлении в Windows Server 2008 R2-03
- Если со службами все отлично то чистим реестр Windows с помощью Ccleaner или privazer.
- Если не помогает, то просканируйте вашу систему на вирусы в безопасном режиме.
- Еще можно поправить значение реестра.
Для этого нажмите WIN+R и введите Regedit
Если раздела не будет, то можно его создать, такое встречается, например, в Windows 8.1 и выше.
- Иногда помогает выполнение команды wuauclt /reset, через командную строку cmd
- Если у вас в сетевых настройках, dns сервера указаны в ручную, то проверьте их доступность.
- Еще на одном форуме видел, что помогает удаление программы проксисвич, если она у вас есть.
Исправляем 80244019 ошибка обновления windows 8.1
Например в Windows 8.1 нет ветки реестра WindowsUpdate\AU и код 80244019 в windows 8.1 очень часто выскакивает, когда у вас зависла служба BITS, попробуйте ее перезапустить. Для этого откройте командную строку от имени администратора и введите команды:
и net stop wuauserv
net start wuauserv
Снимаем галку » Обновлять другие продукты Microsoft «
Если кто не в курсе, то существуют два типа обновлений:
- Обновления безопасности и исправляющие баги
- Для дополнительных продуктов
Если обновление windows выдает код ошибки 80244019, то можно попробовать отключить галку «При обновлении Windows предоставить обновления для других продуктов Microsoft»
Находится она по пути (Для Windows 7 и Windows 8.1)
Вот так вот просто решается ошибка 80244019 и ошибка 84B20001 при обновлении в Windows Server 2008 R2. Обязательно проверьте, что у вас есть интернет и сервера Microsoft у вас не блокируются на внешнем firewall, про это тоже не нужно забывать.
Для других версий Windows от 7 до 10 алгоритм действий при 84B20001 и 80244019, тот же. Да прибудет с вами победа.
Записки IT специалиста
Технический блог специалистов ООО»Интерфейс»
Устраняем ошибки Windows Update при работе через прокси-сервер Squid
При работе с прокси-сервером Squid вы можете столкнуться с ситуацией, когда служба Windows Update или WSUS перестанут получать обновления. Ситуация действительно неприятная и проявляется она чаще всего уже «по факту», когда клиентские машины перестают получать обновления и нужно срочно принимать меры. Однако такое поведение службы обновления давно известно и отражено в документации. Сегодня мы разберем подробно причину возникновения ошибки и покажем возможные действия по ее устранению.
Внешнее проявление неисправности сводится к тому, что служба Windows Update не может загрузить обновления и сопровождается одним из кодов ошибки:
- 0x80244017
- 0x80244018
- 0x80244019
- 0x8024401B
- 0x80244021
Для ее возникновения требуется сочетание нескольких факторов: наличия в сети прокси-сервера с аутентификацией пользователей и службы WPAD. Неподготовленного администратора данная ошибка застает врасплох, однако существует статья KB896226, которая подробно проливает свет на проблему и способы ее решения:
Чтобы устранить эту проблему, убедитесь, что прокси-сервер или брандмауэр настроены для анонимного доступа к веб-сайту Центра обновления Windows.
Если коротко, то суть происходящих событий следующая: для доступа к серверам Центра обновлений система использует службу Windows HTTP (WinHTTP), которая в свою очередь поддерживает автоматическое получение настроек прокси через WPAD. Т.е. все запросы к серверам обновлений будут автоматически направлены на прокси, это не доставляет проблем до тех пор, пока прокси-сервер не начинает требовать аутентификации клиентов. Службы Windows Update не могут пройти аутентификацию и возникает проблема с получением обновлений.
Чтобы избавиться от этой ошибки следует выполнить рекомендации Microsoft и обеспечить анонимный доступ к серверам обновлений. Сделать это можно достаточно просто и несколькими способами. Рассмотрим их подробнее.
Squid
Система контроля доступа Squid дает в руки администратора мощный инструмент управления и этим следует пользоваться. Тем более что стоящая перед нами задача ничем не отличается от URL-фильтрации по спискам, о которой мы рассказывали ранее.
Создадим отдельный список для служб Windows Update:
и внесем в него следующие записи:
За его основу мы взяли список из KB896226 который актуализировали и дополнили исходя из собственного опыта и наработок коллег.
Теперь создадим элемент ACL для работы со списком:
Для того, чтобы обеспечить анонимный доступ к указанным ресурсам следует создать список доступа и разместить его раньше списков, требующих аутентификацию или производящих авторизацию, лучше всего сделать его одним из первых.
После чего перезапустите прокси-сервер и проверьте доступ к серверам обновлений, он должен восстановиться.
Существует также еще один вариант — направить трафик к серверам обновлений минуя прокси-сервер. В этом нам поможет протокол WPAD, точнее специальные правила в PAC-файле. На наш взгляд этот метод менее предпочтителен, но вполне имеет право на существование.
Для его реализации добавьте в файл wpad.dat следующие инструкции:
Изменения вступают в силу сразу, перезапускать службы не требуется.
При использовании данного метода следует принять во внимание еще один момент — если вы принимали меры по запрету обхода прокси, например, при помощи iptables, то следует явно разрешить соединения к серверам обновлений. На текущий момент указанным серверам соответствуют следующие IP-адреса:
Собственно, поэтому не рекомендуем данный способ, так как поддерживать один список доменных имен для Squid проще, чем два, тем более что соответствие доменных имен IP-адресам может меняться. В любом случае теперь вы понимаете источник проблемы и можете самостоятельно выбрать наиболее предпочтительный способ ее решения.
Исправляем ошибки установки обновлений Windows 7
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. Все другие ошибки
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
Пользователя от работы отвлекать не потребуется, все сделаем удаленно. Создаем следующий командный файл и запускаем его:
где 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
то будем исправлять.
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 (эталонной считается машина, с которой вы запускаете скрипт)
Как видите, скрипт прост и может быть легко заточен напильником под вашу инфраструктуру.
3. Запускаем второй проход Windows6.1-KB947821-v34-x64.msu
=================================
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. Любопытная ошибка, связанная с неправильным клонированием машин и задвоением (затроением и т.д.) идентификаторов клиентов. Решается так:
Ошибка #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».