У меня Windows Server 2016 с WSUS (база данных WID). Все узлы в моей системе - это Windows 10 Professional. Они настраиваются с помощью групповой политики для проверки наличия обновлений на сервере 2016. В любом случае узлы и сервер не находятся за прокси.
На основе консоли WSUS он показывает, что все узлы проверяются, когда я нажимаю «Проверить наличие обновлений». Когда вы смотрите на узел, он выдает следующее сообщение:
При установке обновлений возникли проблемы, но мы попробуем позже. Если вы продолжаете видеть это и хотите выполнить поиск в Интернете или обратиться в службу поддержки для получения информации, это может помочь: (0x8024401c)
Я погуглил эту ошибку, и я нашел мало информации или вообще никакой информации об этой ошибке. Я пробовал все предложения, которые мог найти, но ничто не помогло решить эту проблему. Что я могу сделать из последнего файла .ELT, когда открываю его словом:
Произошла ошибка связи с конечной точкой в http: // FQDN: 8530 / ClientWebService / client.asmx. При получении ответа HTTP произошла ошибка. Операция не была завершена в отведенное время.
Когда я делаю Get-WindowsUpdateLog в PowerShell я просто получаю длинный список обновлений, которые он не может найти. Нет актуальной коммуникационной информации.
Я могу перейти по этой ссылке, если введу ее в браузер и брандмауэр не блокирует WSUS. Что мне не хватает? Может ли кто-нибудь предоставить мне любую другую информацию. Я также все еще учусь, как на самом деле читать файлы ELT, используя правильную процедуру.
РЕДАКТИРОВАТЬ 1: Попытка запустить символы и WDK10 на клиенте, чтобы лучше интерпретировать файлы ELT.
РЕДАКТИРОВАТЬ 2: Запуск tracefmt.exe инструмент дает мне следующую ошибку:
Невозможно открыть файл журнала для чтения
Это случается со всеми. Я действительно вижу из TraceView из набора инструментов SDK, что все события показывают системное время и информация о формате не найдена. Он подключен и не получает эти данные или просто ищет все эти обновления?
Я внес следующие изменения в пул приложений IIS для страницы WSUS:
Это позволяло Windows 10 дольше подключаться и проверять наличие обновлений, сбрасывать соединения для всех машин и выделять больше памяти для обработки обновлений, что было предложением, которое я нашел в поиске в Google.
Все мои Windows 10 1607 и Server 2016 1607 имели ошибку 0x8024401c.
Некоторые советы по настройке пула приложений IIS не помогли.
Запуск сценария PowerShell 3 Адама "Clean-WSUS" на сервере WSUS решил проблему:
http://community.spiceworks.com/scripts/show/2998-adamj-clean-wsus
Я создал совершенно новый домен Windows 2016, добавил несколько рядовых серверов и сделал один из них ролью WSUS, просто чтобы попробовать. После настройки объектов групповой политики и проверки наличия обновлений одним из серверов WSUS постоянно аварийно завершал работу с кодом 0x80244022, что, как я предполагаю, означало, что рабочий процесс потерпел крах и служба была недоступна. Сколько ни пробовал, результат один и тот же. Мне просто пришлось изменить ограничение частной памяти в настройках перезапуска пула приложений с 1800 МБ на 4096 МБ, перезапустить пул приложений, ПРОБЛЕМА РЕШЕНА! Затем я увидел, что один сервер Windows 2016 может использовать до 2,5 ГБ этого пула приложений при первоначальном сканировании. Таким образом, значения по умолчанию для пула приложений WSUS для Windows 2016 устарели и требуют обновления.
В пул приложений IIS для страницы WSUS внесены следующие изменения:
28 августа 2017 г. - KB4039396 (OS Build 14393.1670)
Улучшения и исправления:
Устранена проблема с обработкой метаданных обновления WSUS, из-за которой у некоторых клиентов время ожидания превышалось с ошибкой 0x8024401c.
Увеличьте время ожидания ASP.NET
Сделайте копию \Program Files\Update Services\WebServices\ClientWebService\Web.Config.
открыто \Program Files\Update Services\WebServices\ClientWebService\Web.Config.
<httpRunTime». Это будет выглядеть так (в неизмененном виде web.config): <httpRuntime maxRequestLength="4096" /><httpRuntime maxRequestLength="4096" executionTimeout="3600" />После IISReset нужно быть действительно терпеливым и заставить некоторых клиентов связываться с WSUS, чтобы перестроить кеш. После стабилизации размера кеша он будет работать