80244021 ошибка обновления windows 2008

Category:

• Компьютеры
• Cancel

Про борьбу с ошибками 0x801901f6 и 0x80244021, вылезающими при попытках WindowsUpdate обновлять систему с WSUS в интернетах написано достаточно много, но в большинстве случаев проблемы у людей связаны с прокси-сервером. В нашем случае между сервером и клиентом никаких прокси не было, а ошибки вылезали.

Помогли приседания и пляски с бубном.

Приседания (очень может быть, что эта часть не является обязательной, но, несомненно, полезна):

Установить более свежий (3.0) клиент Windows Update: x86; x64; Itanium

Бубен: в WUServer и WUStatusServer (находятся в ветке HKLMSOFTWAREPoliciesMicrosoftwindowsWindowsUpdate) вместо FQDN имени WSUS вбил только имя хоста.

По неизвестной причине помогло. FQDN в имени сервера у нас использовался всегда (reg-файл с настройками датируется 2005 годом), что вдруг сдряслось — загадка.

Ошибка 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 нет ветки реестра WindowsUpdateAU и код 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 у нее есть единственное и очень специфическое решение — удалить ключ
HKLMComponentsPendingRequired=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%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

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

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

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

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

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

Проблема в том, что битых файлов обычно десятки, и их очень сложно выбрать и скопировать. Тогда на помощь приходит следующий скрипт 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».

Источник

I’ve searched and searched and searched Google and nothing really applies or works so I’m becoming desperate before I reimage the machine.

I have ONE machine out of 30 that is receiving this error when connecting to my internal WSUS server.  All others update correctly.  The WSUS parameters are distributed by GPO therefore there shouldn’t be an issue with the configuration.

A clip from the WindowsUpdate.log file is shown below.

+++++++++++  PT: Synchronizing server updates  +++++++++++
+ ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http:/ Opens a new window/challenger:8530/ClientWebService/client.asmx
WARNING: SyncUpdates failure, error = 0x80244021, soap client error = 10, soap error code = 0, HTTP status code = 502
WARNING: PTError: 0x80244021
WARNING: SyncUpdates_WithRecovery failed.: 0x80244021
WARNING: Sync of Updates: 0x80244021
WARNING: SyncServerUpdatesInternal failed: 0x80244021

I do not use a proxy server.  There was an issue with this machine a while back and I did delete the SoftwareDistribution folder but it has since been recreated.  I can go to the Windows/Microsoft Update site and download and install the updates there.  I seem affected with just the internal WSUS system.  I’ve used the wuauclt /resetauthorization /detectnow switches to no avail.  I’ve also removed the system from the WSUS snap-in.  It does get detected again and reappears but no updates.  And it doesn’t report; it only contacts.  I’ve done ipconfig /flushdns to ensure there wasn’t an issue with DNS.  I can ping my server correctly and do get a lovely general message when accessing http:/ Opens a new window/myserver:8530/SimpleWebAuthService/SimpleWebAuth.asmx.  I’ve run the WSUS clientdiag utility with a PASS at every step.

Does anyone have some direction before I drop-kick this machine?  What about removing it from the domain and rejoining?  Are there any other tricks?