Прежде чем я начну, я бы сказал, что я провел достаточно исследований для решения этой проблемы, и в прошлом я также поднимал вопрос в службу поддержки Microsoft, чтобы прийти к выводу по этой проблеме. На этот раз проблема в неожиданном повороте.
Постановка задачи: WSUS не может загрузить обновления; обратитесь к журналам просмотра событий и скриншотам ниже:
-> Ошибка 17-07-2018 12:29:39 Службы Windows Server Update Services 10032 7 Серверу не удается загрузить некоторые обновления.
-> Ошибка 17-07-2018 00:14:26 Службы Windows Server Update Services 364 2 Не удалось загрузить файл содержимого. Причина: Сервер не поддерживает необходимый протокол HTTP. Фоновая интеллектуальная служба передачи (BITS) требует, чтобы сервер поддерживал заголовок протокола Range. // ранее использовали службу поддержки Microsoft, чтобы определить, что проблема связана с некоторыми настройками прокси-устройства.
Исходный файл: /c/msdownload/update/software/secu/2018/07/pciclearstalecache_7b1e71fc5a81cd30e0a46338caa6fb1d2880f2c2.exe
Файл назначения: E: \ WSUS \ WsusContent \ C2 \ 7B1E71FC5A81CD30E0A46338CAA6FB1D2880F2C2.exe
Для меня странно то, что я не могу понять, почему статус загрузки отображается как завершенный, учитывая, что сами обновления не работают по отдельности. Я неоднократно пробовал, но усилия были напрасными.
Мои наблюдения: В прошлом у нас была проблема, заключающаяся в том, что WSUS полностью не мог загрузить обновление, и даже статус загрузки был нулевым.
В то время мы обратились в службу поддержки Microsoft и пришли к выводу, что в нашем прокси-сервере есть параметр, который имеет функцию сканирования антивируса и механизма защиты от вредоносных программ, из-за чего загрузка исправлений занимает значительное время или сеанс завершается. Изготовитель прокси подтвердил, что «файл большого и плотного размера, например ZIP-файл размером 200 МБ, содержащий инструменты разработчика программного обеспечения и т. Д., Может занять более 30 минут для полного сканирования ядром защиты от вирусов и вредоносных программ». Дело было закрыто после того, как мы исключили URL-адрес обновления Windows из функции сканирования прокси-сервера, и обновления были успешно загружены в WSUS.
К сожалению, на этот раз дело обстоит так же, за исключением того, что исправления отображаются как загруженные на панели мониторинга WSUS, но по отдельности отображаются как сбойные в представлении обновления. Мы подтвердили с прокси, что это сканирование настроек пакета было включено постоянно и не готовы к изменению без надлежащего обоснования. Они попросили нас проверить, почему это странное поведение отображается в WSUS.
Запросы:
Может кто-нибудь объяснить, почему WSUS показывает двойное поведение статуса загрузки патча? Я проверил, что WSUSContent (E: \ WSUS \ WsusContent) не показывает недавно загруженных обновлений.
Если я попробую сделать то же самое из браузера на сервере WSUS, загрузка файла займет слишком много времени. Но он завершает диалог из браузера для того же URl. К сожалению, похоже, что для WSUS есть какое-то значение тайм-аута, при котором не нужно ждать, пока прокси-устройство не просканирует весь пакет. Есть ли способ заставить его ждать загрузки патчей?
Почему сеанс поддерживается в браузере для загрузки всего пакета, но не в WSUS для загрузки того же обновления?
Спасибо, что ответили на весь вопрос. Если потребуется дополнительная информация, сообщите мне. Если вы можете внести свой вклад / предложить что-либо в отношении проблемы, я все уши.
В случае проблемы с загрузкой прокси вы можете попробовать запустить BITS в режиме переднего плана.
в PowerShell
$wsusServer = Get-WsusServer -name YourServerName -PortNumber 8530
$wsusConfig = $wsusServer.GetConfiguration()
$wsusConfig.BitsDownloadPriorityForeground = $true
$wsusConfig.save()
Устранение несоответствия статуса загруженных файлов
В командной строке перейдите к
% диск% \ Program Files \ Update Services \ Tools>
тип:
wsusutil сбросить
Это приведет к повторному сканированию файлов, требующих загрузки.