Windows Server 2016 не скачивает обновления через прокси

Обнаружил одну интересную особенность в службе обновлений Windows Server 2016. В том случае, если у вас не используется внутренний WSUS сервер, и ОС должна обновляться напрямую с серверов Windows Update в Интернет, то при использовании прокси-сервера для доступа наружу, при попытке загрузить обновления через центр обновлений, в Windows Server 2016 процесс загрузки зависает на этапе скачивания апдейтов на 0% (Downloading Updates 0%).

Что интересно, клиенту Windows Update удалось отправить/загрузить метаданные обновлений (список необходимых обновлений успешно сформировался), но ни одно из них не загружается.
Сформируем и откроем журнал WindowsUpdate.log с помощью командлета Get-WindowsUpdateLog.

Как вы видите, BITS не может закачать файлы с ошибкой 80246008.

Как оказалось, простая установка параметров прокси-сервера для Internet Explorer в Windows Server 2016 RTM (10.0.14393) не работает так, как в предыдущих версиях Windows. Чтобы клиент Windows Update в Windows Server 2016 мог получать доступ в Интернет через прокси, нужно принудительно указать системный прокси для winhttp.

Выведем текущие настройки прокси-сервера для WinHTTP:

netsh winhttp show proxy

Direct access (no proxy server).

Как вы видите, параметры прокси-сервера для WinHTTP не заданы указаны.

Задать настройки системного прокси для WinHTTP можно так:

netsh winhttp set proxy proxy-server=»192.168.0.14:3128″ bypass-list=»*.winitpro.ru»

Или так, импортировав настройки из IE (настройки прокси в Internet Explorer нужно предварительно задать вручную или настроить через GPO):

netsh winhttp import proxy source=ie

После изменения настроек прокси службу Windows Update нужно перезапустить:

После того, как были указан прокси для WinHTTP, Windows Server 2016 начал закачивать обновления с узлов Windows Update.

Аналогичной проблеме подвержена RTM версия Windows 10.

Также не забудьте, что вы не сможете получать обновления через прокси сервер с авторизацией, т.к. клиент Windows Update не поддерживает возможность авторизации на прокси (в отличии от PowerShell). Чтобы корректно работала служба обновлений Windows, нужно на прокси сервере разрешить анонимный доступ к серверам обновлений Microsoft. Список URL указан ниже:

• update.microsoft.com
• * .update.microsoft.com
• download.windowsupdate.com
• * .download.windowsupdate.com
• download.microsoft.com
• * .download.microsoft.com
• windowsupdate.com
• * .windowsupdate.com
• ntservicepack.microsoft.com
• wustat.windows.com
• mp.microsoft.com
• * .mp.microsoft.com

Чтобы корректно работала служба обвинений (последнее слово точно должно быть таким?)

А то! Вы обвиняетесь в том, что давно не обновляетесь!

Скорее так:
Вы обвиняетесь в том, что используете процессор не последнего поколения и приговариваетесь к отключению от обновлений!

На самом деле это довольно логично. Ведь если на машине не залогинен никакой пользователь, то откуда брать настройки прокси? Если же мы говорим о сервере, то чаще всего там ситуация именно такая. Следовательно если настроить автоматическое получение обновлений, то работать оно не сможет т.к. нет залогиненого пользователя и нет настроек прокси. Другое дело, что я бы не стал на серверах настраивать автоматическое обновление, но это уже каждый сам решает.
По поводу списка доменов. После _долгих_ экспериментов я пришел к такому списку:
*.microsoft.com
microsoft.com
*.windowsupdate.com
windowsupdate.com
*.trafficmanager.net
trafficmanager.net

Открывать более детально по поддоменам не вижу смысла. Во-первых их там реально много. Во-вторых ну нет ничего страшного если будет доступ к *.microsoft.com, а вот жизнь сисадмину упростит сильно. Я прошу учесть, что такой список родился не на пустом месте, а в результате мониторинга сетевой активности. Дело в том, что система помимо собственно обновлений обращается еще к различным ресурсам (например проверяет списки отозванных сертификатов — CRL). Это тоже важные ресурсы наряду с обновлениями. И я рекомендую открыть анонимный доступ к этим доменам не только с серверов но и с рабочих станций.

И в догонку (хотя это уже не относится к обновлениям). Касаемо загрузки CRL. На машинах с которых идёт активная работа с интернетом (как правило это юзерские машины) системный компонент MicrosoftCryptoAPI постоянно обращается к различным доменам для скачивания CRL. Так вот если используется выход в интернет через прокси, то для корректной работы этого механизма тоже должен быть прописан системный прокси, это во-первых. Во-вторых MicrosoftCryptoAPI обращается к прокси тоже анонимно (за редким исключением). И в-третьих всё это усугубляется тем, что доменов куда он может обратится множество. Таким образом если прокся не выпустит анонимные обращения от MicrosoftCryptoAPI, то система проверки отзыва сертификатов функционировать не будет. Причём это не вызывает никаких видимых эффектов. Просто тихо не работает и всё. Чем это грозит и насколько критично каждый пусть сам додумает.

Грозит это «разными тупняками системы» при работе с сетью, локальной в том числе. Сам видел как ОС призадумываются, ожидая получения CRL или отбоя по таймауту. Причем пути по которым скачиваются эти списки, не только мракософтовские. По внутренним правилам службы ИБ к примеру эти компы вообще не должны иметь выход в инет, а работать (нормально, без тормозов) то надо. И это еще цветочки, бывает, что без этих списков , не работают какие-либо сервисы, что логично в принципе.

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

• Главная
• Устраняем ошибки Windows Update при работе через прокси-сервер Squid

Устраняем ошибки 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 Update через прокси-сервер

Ни для кого не секрет, что в том случае, если Ваш ПК с ОС Microsoft выходит в интернет с помощью прокси-сервера, то служба обновления системы Windows Update по-умолчанию не работает. Эта заметка о том, как можно настроить работу системы обновлений Windows на ПК, находящимся за прокси-сервером.

Служба обновлений Windows Update может использовать HTTP прокси-сервер. Однако указания прокси-сервера в настройках Windows Internet Explorer недостаточно для работы службы обновления через проксю. Дело в том, что Windows Update использует Windows HTTP Services (WinHTTP) для поиска обновления, а для загрузки обновлений используется BITS. Служба Windows Update по-умолчанию настроена так, что всегда пытается попасть на сервер обновлений Microsoft напрямую, не используя прокси-сервер, даже если в настройках Internet Explorer он указан.

Однако данная проблема решаема, достаточно настроить системный WinHttp прокси. В ОС Windows XP/2003 WinHttp прокси задавался с помощью утилиты proxycfg.exe. В новых ОС Windows Vista/7/2008 данная утилита упразднена и настройка WinHttp прокси выполняется при помощи команды netsh.

Настройка выполняется при помощи следующей команды: netsh winhttp set proxy : .

После того, как вы выполните данную команду, ваша ОС Windows 7 будет обновляться, даже находясь за прокси-сервером.

Как вариант, если вы хотите взять настройки прокси из Internet Explorer, можно воспользоваться командой:

Как вариант возможна также ситуация, когда необходимо перенаправить весь трафик, кроме трафика на Microsoft (системные обновления, активация) на прокси-сервер, тогда можно воспользоваться следующей командой обхода прокси для обновлений Windows.

Сделайте обход прокси для активации и обновлений вот так:

Текущие настройки WinHttp можно посмотреть командой:

Сбросить же настройки прокси сервера можно при помощи команды:

Сообщение об ошибке при использовании центра обновления Windows через прокси-сервер или брандмауэр

Проблемы

При доступе к сайту центра обновления Windows через прокси-сервер или брандмауэр могут возникнуть указанные ниже проблемы.

При попытке получить доступ к обновлениям продукта появляется сообщение об ошибке «не удается отобразить страницу».

При попытке загрузить компоненты появляется сообщение об ошибке «Загрузка и установка завершилась сбоем». При загрузке может не отображаться ход выполнения, прежде чем он перестанет работать.

Сайт перестает отвечать на запросы после «немного подождите. «. Откроется окно, и сайт пытается инициализировать каталог продуктов.

Причина

Эта проблема может возникать, если вы используете одну или несколько из перечисленных ниже программных продуктов.

Программное обеспечение WinProxy-OtitisЧисло конфликтов с WinProxy 3,0 отличается от более ранних версий WinProxy. Существует еще меньше конфликтов с прозрачными прокси-сервером, а не классическим прокси (применимо только к версии 3,0). Дополнительные сведения можно найти на веб-сайте WinProxy по адресу:

WinGate-Deerfield.com Большинство конфликтов возникают в версиях более ранних, чем 3.0. Дополнительные сведения можно найти на веб-сайте WinGate по адресу:

Шлюз Интернета — MaccaSoftMaccaSoft распространяет программное обеспечение шлюза через Интернет с помощью BMT Micro, Inc. и Indelible Blue, но поддержка предоставляется через MaccaSoft.

Такое поведение возможно в следующих случаях.

Прокси-сервер кэширует страницу центра обновления Windows и связанные с ней файлы. Это не позволит правильной установке и инициализации элемента управления ActiveX, который используется каталогом продуктов Windows Update для создания на клиентских компьютерах.

Порт 80 или 443 закрыт. Для центра обновления Windows требуются оба соединения HTTP и HTTPS.

Клиентские компьютеры не настроены для разрешения активных сценариев, а также загрузки и инициализации элементов ActiveX.

Способ

Для решения проблемы выполните следующие действия:

Очистите кэш прокси-сервера и настройте его, чтобы исключить сайт центра обновления Windows. Примечание. Если вам нужна помощь по настройке прокси-сервера или брандмауэра, обратитесь к документации по программному обеспечению или свяжитесь с производителем программного обеспечения.

Откройте порт 80.

Добавление центра обновления Windows в зону надежных сайтов.

Для правильной передачи файлов ActiveX на компьютер необходимо настроить параметры безопасности в Microsoft Internet Explorer на среднем или ниже. При уменьшении параметров безопасности вы влияет только на веб-сайты, которые указаны в зоне надежных сайтов Internet Explorer. Текущие параметры безопасности для всех веб-сайтов остаются настроенными на данный момент. Чтобы настроить параметры безопасности в Internet Explorer, выполните указанные ниже действия.

В Internet Explorer в меню Сервисвыберите пункт Свойства обозревателя, а затем — Безопасность.

Нажмите кнопку зона надежных сайтови выберите пункт сайты.

Снимите флажки требуется проверка серверов (HTTPS:). флажок «для всех сайтов в этой зоне «.

В текстовом поле Добавить этот веб-сайт в зону: введите http://*. Microsoft. comи нажмите кнопку добавить.

Нажмите кнопку ОК.

Нажмите кнопку другой уровеньи выберите включить для следующих элементов:

Скачивание подписанных элементов ActiveX.

Скачайте неподписанные элементы ActiveX.

Инициализировать и выполнять сценарии элементов ActiveX, не помеченных как безопасные.

Запускать элементы ActiveX и подключаемые модули.

Выполнять сценарии элементов ActiveX, помеченные как безопасные.

Дважды нажмите кнопку ОК , чтобы закрыть окно свойств Интернет.

Чтобы получить дополнительные сведения о настройке безопасности Internet Explorer, щелкните следующий номер статьи базы знаний Майкрософт:

174360 Использование зон безопасности в Internet Explorer