Обнаружил одну интересную особенность в службе обновлений Windows Server 2016. В том случае, если у вас не используется внутренний WSUS сервер, и ОС должна обновляться напрямую с серверов Windows Update в Интернет, то при использовании прокси-сервера для доступа наружу, при попытке загрузить обновления через центр обновлений, в Windows Server 2016 процесс загрузки зависает на этапе скачивания апдейтов на 0% (Downloading Updates 0%).
Что интересно, клиенту Windows Update удалось отправить/загрузить метаданные обновлений (список необходимых обновлений успешно сформировался), но ни одно из них не загружается.
Сформируем и откроем журнал WindowsUpdate.log с помощью командлета Get-WindowsUpdateLog.
2018/06/04 16:24:21.8312332 588 4116 DownloadManager BITS job initialized: JobId = {E3AA21C9B-4BC2-443E-2342-8F693CE1443E} 2018/06/04 16:24:21.8436054 588 4116 DownloadManager Downloading from http://download.windowsupdate.com/c/msdownload/update/software/defu/2017/09/nis_engine_1af0e4b80bf4028f8dac56ebf186b392e4e72486.exe to C:\Windows\SoftwareDistribution\Download\f71ddf93ec2d087c819cf75c55ddfda2\1af0e4b80bf4028f8dac56ebf186b392e4e72486 (full file) 2018/06/04 16:24:21.8452605 588 4116 DownloadManager New download job {E3AA21C9B-4BC2-443E-2342-8F693CE1443E} for UpdateId F608EDA4-2E84-433A-A8C9-8117411F91A8.200 2018/06/04 16:24:21.8545291 588 4116 DownloadManager Download job E3AA21C9B-4BC2-443E-2342-8F693CE1443E resumed. 2018/06/04 16:24:21.8734449 588 4116 DownloadManager Failed to connect to the DO service; (hr = 80040154) 2018/06/04 16:24:21.8734462 588 4116 DownloadManager GetDOManager() failed, hr=80246008, hrExtended=80040154 2018/06/04 16:24:21.8734472 588 4116 DownloadManager Failed creating DO job with hr 80246008 2018/06/04 16:24:21.8772521 588 4116 DownloadManager DO download failed with error 80246008[Extended: 80040154], falling back to BITS and retrying with new Download Job.
Как вы видите, 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 нужно перезапустить:
Restart-service wuauserv
После того, как были указан прокси для 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 или отбоя по таймауту. Причем пути по которым скачиваются эти списки, не только мракософтовские. По внутренним правилам службы ИБ к примеру эти компы вообще не должны иметь выход в инет, а работать (нормально, без тормозов) то надо. И это еще цветочки, бывает, что без этих списков , не работают какие-либо сервисы, что логично в принципе.
В общем-то да, согласен можно остановится на *.microsoft.com, *.windowsupdate.com.
Но бывает, что натукаешь на идиотскую упертость безопасников. У меня был случай, когда требовали ссылки на официальную документацию MSFT. У них в доках имеено этот список.
А кто такой trafficmanager.net? телеметрия?
С CRL на изолированных системах беда. Но с другой стороны таким компьютеры и наружу не должы выходить.
Дело еще в том, что этот список уже несколько устарел. Там реально используются не все домены, а некоторые уже и не существуют вовсе. Прям вот сейчас точно ничего утверждать не буду, т.к. давно уже занимался этим вопросом и на память не помню уже. Список брал не с Технета, а встроенный по умолчанию в TMG2010 (но он там по моему такой же был). А мониторил активность Windows Server 2012 R2. И оказалось, что далеко не на все домены из этого списка он обращается, зато обращается на другие которых в нём нет. В том числе и на trafficmanager.net. Но что именно это такое я не скажу сейчас потому, что опять же не помню. Но я проверял и это точно какой-то сервис MS (в принципе это всё гуглится). Мой внутренний безопасник (других нет 🙂 решил, что раз ОС хочет туда ходить, то пусть ходит. В конце концов если так не доверять MS, то смысл тогда вообще пользоваться их продуктами?
Про CRL я даже больше писал применительно к обычным рабочим станциям которые ходят в интернет. Но ходят через проксю с авторизацией. И в этом случае MicrosoftCryptoAPI не сможет грузить списки отзывов. В моей сети правда это не вызывало никаких видимых проблем (как выше писал shadow999), но всё равно это потенциальная уязвимость. На совсем изолированных от интернета машинах это конечно не проблема, но на частично изолированных это играет роль. Скажем есть неких сервер который в интернет имеет доступ только к обновлениям [по какой-то неведомой причине мы его не обновляем через WSUS]. В этом случае система всё равно будет грузить CRL, что бы проверить отзыв сертификатов серверов обновлений. И вот грузить она их будет с доменов не входящий в список из статьи, а с *.microsoft.com. Но справедливости ради можно заметить, что надо иметь довольно большую степень паранойи, что бы рассматривать вариант взлома через поддельный сервер обновлений с украденным сертификатом MS 🙂
Но открытие доступа к скачке CRL это еще не так страшно. Самая веселуха начинается если используется Microsoft Security Essentials 🙂 Он тоже не умеет авторизовываться на проксе, а обновления качает вообще хрен знает откуда. Сегодня так, завтра эдак.
в 2016 серв помогло !
а если нет прокси и при этом обновления не идут? Инет есть
политики надо настраивать