После установки нового сервера WSUS в сети нашей компании многие клиенты не смогли получить новые обновления с сервера с ошибкой 0x80244010. Как оказалось, эта ошибка характерна не только для компьютеров, обновляющихся с внутреннего сервера WSUS, но и для устройств, получающих обновления напрямую с Windows Update. Рассмотрим, основные способы исправления ошибки 0x80244010 и восстановления работоспособности системы обновлений.
Если вы увидели ошибку получения или установки обнволения в графической Control Panel или панели Settings, нужно открыть лог агента WindowsUpdate.log. В старых версиях Windows 7 и 8 это файл
%Windir%\WindowsUpdate.log
. В современных Windows 10/11 и Windows Server 2022/2019 вы можете сгенерировать файл WindowsUpdate.log с помощью PowerShell:
Get-WindowsUpdateLog -logpath C:\PS\Logs\WindowsUpdate.log
В моем случае в журнале обновлений обнаружились такие ошибки:
PT WARNING: Exceeded max server round trips: 0x80244010 PT WARNING: Sync of Updates: 0x80244010 PT WARNING: SyncServerUpdatesInternal failed: 0x80244010 Agent * WARNING: Failed to synchronize, error = 0x80244010 Agent * WARNING: Exit code = 0x80244010 Agent ********* Agent ** END ** Agent: Finding updates [CallerId = AutomaticUpdates] Agent ************* Agent WARNING: WU client failed Searching for update with error 0x80244010 AU >>## RESUMED ## AU: Search for updates [CallId = {128CCEAD-F84D-405E-9BC2-607D1694894B}] AU # WARNING: Search callback failed, result = 0x80244010 AU # WARNING: Failed to find updates with error code 80244010
Обратите внимание на строку Exceeded max server round trips: 0x80244010. Эта ошибка говорит, что при обращении к серверу обновлений (в моем случае это WSUS) было превышено максимальное количество обращений. В результате чего сервер обновлений отключает клиента, который превысил лимит обращений (по умолчанию лимит — 200 обращений).
SUS_E_PT_EXCEEDED_MAX_SERVER_TRIPS
в таблице кодов ошибок Windows Update.Также в Windows Update есть ограничение в 200 Кб на максимальный размер XML файла, который клиент получает с сервера в рамках одного обращения. Чем большее количество обновлений на сервере для клиента нужно проверить, тем больший размер XML файла. Если клиент не смог получить необходимые данные с сервера обновлений за 200 сессий, он временно отключается от сервера и возвращает ошибку.
Чаще всего такая ошибка возникает из-за плохого или нестабильного сетевого соединения с сервером обновлений, или когда клиенту нужно получить слишком большое количество обновлений (новый клиент сервера WSUS или компьютер, на котором давно не устанавливались обновлений).
В большинстве случаев пользователю достаточно через несколько минут повторно нажать на кнопку Retry/ Check for Updates в панели управления или выполнить команду:
wuauclt.exe / detectnow
В большинстве случаев это решает проблему, но в том случае если клиентов в сети много, такой способ решения проблемы неприемлем.
По умолчанию клиент проверяет обновления на сервере каждые 22 часа. Вы можете изменить этот интервал с помощью параметров групповых политик компьютера. Откройте редактор локальной GPO (
gpedit.msc
) или отредактируйте доменные политику в консоли Group Policy Management Console (
gpmc.msc
). Перейдите в раздел Computer Configuration -> Administrative Templates -> Windows Components -> Windows Update.
Включите параметр Automatic Update detection frequency и увеличьте частоту синхронизаций клиента с сервером обновлений до 3 часов.
Также можно на стороне сервера WSUS убрать ограничение на максимальный размер XML файла, который может скачать клиент с сервера. Для этого откройте SQL Server Management Studio и подключитесь к базе данных SUSDB. Выполните выполнить следующую команду T-SQL.
USE SUSDB
GO
Проверьте и запомните текущее значение:
select MaxXMLPerRequest from tbConfigurationC
Отключите ограничение:
UPDATE tbConfigurationC SET MaxXMLPerRequest = 0
Чтобы не менять настройки в базе WSUS, можно выполнить очистку WSUS сервера с помощью встроенного мастера очистки (Консоль Update Service -> Options -> Server Cleanup Wizard -> все опции -> Next). Это удалит старые, неиспользуемые, и замененные обновления (особенно много мусора от обновлений MS Office), из-за которых может долго выполняться сканирование.
В результате такой операции, клиент Windows Update будет получать намного меньше мета-информации с WSUS сервера, и его взаимодействие должно уместиться в 200 сессий по 200кб.
Также попробуйте увеличить производительность пула WsusPool в IIS на сервере WSUS по рекомендация из стати Ошибка обновления Windows 80244022
WsusPool (Application Pools -> WsusPool -> Advanced settings):
- Private Memory Limit (KB) – 0 (убрать лимит 1.2 на использование RAM рабочим процессов WSUS)
- Queue Length — 25000 (увеличить длину очереди к пулу приложения с 10000)
- Limit Interval (minutes) — 15 (увеличить минут время для сброса счетчиков и выполнения CPU Throttling с 5 минут до 15)
- Service Unavailable Response — TcpLevel (при старом значение HttpLevel клиенту возвращается ошибка HTTP 503)
Отредактируйте файл config ( C:\Program Files\Update Services\WebServices\ClientWebService\web.config), заменив строку
httpRuntime maxRequestLength="4096"
на
httpRuntime maxRequestLength="204800" executionTimeout="7200"
Если все рассмотренные способы не помогли исправить ошибку обновления на клиенте, попробуйте полностью сбросить на нем настройки Windows Update и восстановить настройки по-умолчанию. После чего выполните несколько циклов поиска обновлений.
Интересное совпадение — буквально на днях разбирался с этой проблемой.
У меня с двух моих WSUS серверов клиенты (Win 7 и 8.1) стали плохо получать обновления. Началось это где-то месяца два или три назад одновременно на всех клиентах обоих серверов. Именно на всех клиентах, а не только на вновь установленных или давно не обращавшихся. Т.е. если раньше я одобрял обновления и на следующий день они разливались по всем клиентам, то теперь по прошествии недели после одобрения обновления были установлены не на всех машинах. Если же инициировать поиск обновлений вручную, то при первой попытке вылезала вот эта вот ошибка, а со второй уже (кстати 15 минут не ждал) всё находилось.
Зачем же я собственно пишу этот комментарий? В вашей статье указано решение, но не разъяснён механизм почему надо делать так и так.
Думаю стоит разъяснить.
Как уже написано — ошибка означает, что клиент за одну попытку не может выкачать весь список обновлений. По умолчанию интервал между поиском обновлений составляет 22 часа (на самом деле в интервале между примерно 17,5 ч до 22 часа). Среднестатистический рабочий компьютер выключается на ночь, а рабочий день его составляет явно меньше 17-и часов). Таким образом за рабочий цикл поиск обновлений совершается один раз и он заканчивается неудачей. И так изо дня в день. Вся фишка заключается в том, что если запустить поиск обновлений повторно, то список качается не с начала, а _докачивается_. Таким образом нам нужно добиться того, что бы компьютеры опрашивали WSUS несколько раз за свой рабочий цикл (до перезагрузки ОС). Говоря человеческим языком — несколько раз за рабочий день. Я поставил интервал опроса 3 часа (что даёт эффективный интервал ~2,5 — 3 ч), точно так же как Вы предложили. На следующий же день обновления поставились на всех компах.
Удачи!
Сергей, спасибо за ценный коммент. С Вашим уточнением логика почему компьютеры не закачивают обновления сразу становится совсем железнобетонной 🙂
В моем случае WSUS был интегрирован в SCCM в виде Software Update Point, сначала грешил на него.
PS. Забавно, что одновременно с одной и той же ошибкой WSUS бились и пришли к одинаковым, не совсем очевидным, резульатам.
Откуда такая информация? У меня WSUS 6.3, и опция MaxXMLPerRequest по умолчанию установлена в 5МБ.
Где-то находил эту инфу. Да и в сети гуглится быстро.
Возможно, конечно максимальный размер XML файла зависит от версии WSUS. У меня проблема была на WSUS 3.2
для подключения к встроенной базе нужно включить пользователя в группу «wsus администраторы» (изначально в ней нет доменных пользователей и в результате авторизация не проходит)
Наверно неплохо с скрипте перед последней строкой посмотреть текущее значение:
select MaxXMLPerRequest from tbConfigurationC
Ну и рассказать про sqlcmd и WID
Начну с того, что проблема у меня пропала до каких-то изменений описанных в этой статье каким-то чудом.
Заключалась проблема в том, что после IISReset на сервере WSUS через несколько минут и попытки запустить обновление Windows перестает отвечать страница «http://msk-wsus:8530/ClientWebService/client.asmx» и не важно с клиента пытаюсь зайти на нее или с самого сервера.
Изначально у меня стояло так:
Частота поиска автоматических обновлений — 1 час
MaxXMLPerRequest = 5242880 <— Это 5МБ
После статьи решил подправить:
Частота поиска автоматических обновлений — 3 час <—- Попробую немного уменьшить нагрузку на сервер.
MaxXMLPerRequest = 0 <— не думаю, что это мой случай, но пускай будет, т. к. ранее на Win 7 сталкивался с ошибкой описанной в статье.
Что делал перед тем как у меня наладилось:
1. Оптимизации из это статьи (практически все у меня так и были прописаны).
https://winitpro.ru/index.php/2017/06/01/oshibka-0x8024401c-v-windows-10-pri-poiske-obnovlenij-na-wsus/
2. К перечисленным в статье добавил еще два изменения:
3. После этих двух пунктов у меня ничего не изменилось на следующий день … И я решил попробовать последнее изменение из статьи в первом пункте:
И отключил два класса на сервере WSUS:
— Драйверы
— Комплект драйверов
Скорее всего что-то из этих двух изменений в 3 пункте помогло.
Отдельное спасибо автору блогу.🍻
Вырезает теги даже обернутые в тег код почему-то😅
Напишу без знаков больше / меньше.
Отредактируйте файл config ( C:\Program Files\Update Services\WebServices\ClientWebService\web.config ), заменив строку
httpRuntime maxRequestLength="4096"
наhttpRuntime maxRequestLength="204800" executionTimeout="7200"
Хорошо что помогло!
А в логе windowsupdate.log клиента была все таки ошибка Exceeded max server round trips или только 0x8024401c ?
В логах упоминался только 8024401C и были записи с вопросительными знаками … видимо проблема с кодировкой, но я не ковырял.
2022.10.21 20:00:52.6953012 5476 6064 ProtocolTalker *FAILED* [8024401C] CAgentProtocolTalker::GetCookie_WithRecovery failed
2022.10.21 20:00:52.6953109 5476 6064 ProtocolTalker *FAILED* [8024401C] GetCookie_WithRecovery failed
2022.10.21 20:00:52.6953161 5476 6064 ProtocolTalker *FAILED* [8024401C] RefreshCookie failed
2022.10.21 20:00:52.6953222 5476 6064 ProtocolTalker *FAILED* [8024401C] RefreshPTState failed
2022.10.21 20:00:52.6951974 5476 6064 WebServices WS error: ???????????? ???????????????????????????? ?? ???????????????? ???????????? ???? ???????????? http://077-spt1.local:8530/ClientWebService/client.asmx"."
2022.10.21 20:00:52.6952169 5476 6064 WebServices WS error: ?????? ?????????????????? HTTP-???????????? ?????????????????? ????????????.
2022.10.21 20:00:52.6952230 5476 6064 WebServices WS error: ???????????????? ???? ?????????????????? ?? ???????????????????? ???? ?????????????????? ????????????????.
2022.10.21 20:00:52.6952470 5476 6064 WebServices WS error: ?????????? ???????????????? ???????????????? ??????????????