Всем привет сегодня заметка больше для себя, а именно список серверов Обновлений Windows Update. Для чего это может пригодиться, ну например если вы получили ошибку Обновление не найдено при установке WSUS роли, или наоборот по какой то причине хотите их забанить, для экономии трафика, если у вас нет WSUS, так как не все обновления Windows хорошие и особенно в современных ее версиях, думаю нет смысла напоминать про ошибку , хотя этот список можно продолжать очень долго. Причина не важна, главное чтобы знать, что такое есть и с этим можно как то работать. Ниже я вам покажу методы запрета адресов сервера обновлений microsoft, как универсальный, подходящий для отдельного компьютера, так и для централизованного управления в рамках предприятия.

Почему не устанавливаются обновления Windows

Вот скриншот ошибки если у вас недоступен адрес сервера обновлений microsoft. Как видите ошибка мало информативна. Ее я получаю на сервере несущим роль WSUS, кто не помнит, что это такое, то это локальный центр обновлений для предприятий, для экономии трафика, и вот тут как раз не устанавливаются обновления Windows по причине, не доступности серверов Microsoft.

Что делать если не ставятся обновления Windows

• Первым делом вы должны проверить есть ли у вас интернет, так как его наличие обязательно для большинства людей, если конечно у вас не домен Active Directory и вы их скачиваете с вашего WSUS
• Далее если интернет есть, смотрим код ошибки, так как именно по нему нужно уже искать информацию о решении проблемы (из последних проблем могу привести пример, как решается Ошибка 0x80070422 или Ошибка c1900101), но список можно так же вести очень долго.
• Проверяем у себя на прокси сервере, нет ли запрета до вот таких адресов сервера обновлений microsoft.

Сам список серверов обновлений microsoft

1. http://windowsupdate.microsoft.com
2. http://*.windowsupdate.microsoft.com
3. https://*.windowsupdate.microsoft.com
4. http://crl.microsoft.com/pki/crl/products/MicProSecSerCA_2007-12-04.crl
5. http://*.update.microsoft.com
6. https://*.update.microsoft.com
7. http://*.windowsupdate.com
8. https://activation.sls.microsoft.com/
9. http://download.windowsupdate.com
10. http://download.microsoft.com
11. http://*.download.windowsupdate.com
12. http://wustat.windows.com
13. http://ntservicepack.microsoft.com
14. https://go.microsoft.com/
15. http://go.microsoft.com/
16. https://login.live.com
17. https://validation.sls.microsoft.com/
18. https://activation-v2.sls.microsoft.com/
19. https://validation-v2.sls.microsoft.com/
20. https://displaycatalog.mp.microsoft.com/
21. https://licensing.mp.microsoft.com/
22. https://purchase.mp.microsoft.com/
23. https://displaycatalog.md.mp.microsoft.com/
24. https://licensing.md.mp.microsoft.com/
25. https://purchase.md.mp.microsoft.com/

С развитием интернета постоянное обновление операционной системы стало обычным явлением. Теперь разработчики могут исправлять и дорабатывать систему на протяжении всего срока её поддержки. Но частые обновления Windows 10 - это не всегда удобно. Именно поэтому хорошо бы уметь отключать их.

Причины отключения автоматического обновления

Причины могут быть самыми разными, причём только вы сами можете решить, насколько вам необходимо отключить обновления. При этом стоит учитывать, что вместе с улучшениями тех или иных возможностей поставляются важные исправления уязвимостей системы. И всё же ситуации, когда самостоятельные обновления стоит отключить, возникают довольно часто:

• платный интернет - порой обновление является весьма большим и его загрузка может дорого обойтись, если вы платите за трафик. В таком случае лучше отложить загрузку и скачать позже при других условиях;
• недостаток времени - после загрузки обновление начнёт устанавливаться в процессе выключения компьютера. Это может быть неудобно, если вам требуется быстро завершить работу, например, на ноутбуке. Но ещё хуже тут то, что рано или поздно Windows 10 потребует перезапустить компьютер, а если вы не сделаете этого, то через какое-то время перезапуск пройдёт принудительно. Всё это отвлекает и мешает работать;
• безопасность - хоть сами по себе обновления зачастую содержат важные правки системы, никто и никогда не может предусмотреть всего. В результате одни обновления могут открыть вашу систему для вирусной атаки, а другие просто нарушат её работу сразу после установки. Разумный подход в этой ситуации - обновляться через некоторое время после выхода очередной версии, предварительно изучив отзывы.

Отключение автоматического обновления Windows 10

Способов, как выключить обновление Windows 10, имеется немало. Некоторые из них весьма просты для пользователя, другие сложнее, а третьи требуют установки сторонних программ.

Отключение через центр обновлений

Использование центра обновления для отключения - не лучший вариант, хоть его и предлагают в качестве официального решения разработчики из Microsoft. Вы действительно можете выключить автоматическую загрузку обновлений через их настройки. Проблема тут заключается в том, что это решение так или иначе будет временным. Релиз крупного обновления Windows 10 изменит эту настройку и вернёт обновления системы. Но мы всё равно изучим процесс отключения:

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

Решая проблемы безопасности вычислительной системы, приходится учитывать целый комплекс проблем, одна из которых – своевременное обновление операционных систем и программного обеспечения.

Введение

Для поддержания актуального состояния операционных систем и ПО информационной системы компании следует осуществлять их регулярные обновления. Эти действия могут выполняться с сайта Microsoft Update каждым клиентским компьютером или посредством использования сервера/серверов Windows Server Update Services (WSUS). Если мы говорим о корпоративной сети, то рекомендованный вариант – использование сервера WSUS. При работе с вышеупомянутой службой достигается значительное снижение Интернет трафика и обеспечивается возможность централизованного управления процессом развертывания исправлений системы и ПО, получаемых от Microsoft.

Хотелось бы дополнительно отметить, что на 23 марта 2011 года компания Microsoft анонсировала выход нового продукта «Windows Intune», одной из функций которого будет выполнение тех задач, за которые раньше отвечал WSUS.

Для обеспечения возможности обновления компьютеров клиентов необходимо:

1. Выполнить проектирование решения

2. Осуществить развертывание сервера/серверов WSUS;

3. Обеспечить регулярную синхронизацию сервера WSUS с ресурсом Microsoft Update;

4. Настроить параметры работы сервера/серверов WSUS;

5. Создать целевые группы и поместить компьютеры клиентов в целевые группы на сервере WSUS.

6. Настроить клиентов на использование серверов WSUS;

7. Обеспечить безопасность сервера/серверов WSUS.

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

Настройка клиентов сервера обновлений без использования групповых политик

Настройка клиентов на использование сервера WSUS возможна тремя способами:

1. Использование групповой политики;
2. Использование локальной политики компьютера;
3. Непосредственное внесение изменений в реестр станций клиентов.

Наилучшим способом является использование Объектов Групповой Политики см. рис. 1, привязанных к требуемому контейнеру AD (для Windows 2003) или AD DS (для Windows 2008), однако этот вариант возможен только в случае, если в организации развернута служба каталога Active Directory. Возможности групповой политики по настройке взаимодействия с сервером управления и по управлению процедурами обновления клиентов полностью обеспечивают потребности администратора. В чем мы можем удостовериться взглянув на рис. 1. Перечень доступных настроек достаточно широк.

Рис. 1. Параметры настройки клиента WSUS.

Если служба каталога в организации не развернута, то реализовать возможность взаимодействия клиента с WSUS можно либо посредством локальной политики, либо путем «прямого» внесения изменений в системный реестр рабочей станции, или сервера, актуальность состояния которого мы хотим обеспечить. В сущности, политика есть ни что иное, как интерфейс к реестру.

Обстоятельства, при которых рабочие станции и серверы не являются клиентами AD, могут возникать в целом ряде случаев, например:

· Использование службы каталога третьих фирм, однако, в качестве серверов приложений, файловых серверов, рабочих станций клиентов используются решения на базе операционных систем Microsoft;

· Необходимость построения «гостевой» зоны для предоставления доступа «внешних» пользователей, к сети Интернет;

· Не достаточная «зрелость» компании, ввиду которой централизованная служба каталога не развернута, или отсутствие потребности в указанной службе.

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

В разделе реестра

потребуется указывать адрес, или имя сервера обновлений, к которому будет выполняться подключение клиента и номер порта, который избран для работы с сервером WSUS. По умолчанию подразумевается 80-ый порт.

«WUStatusServer»=http://192.168.1.100

Поскольку требуется помещение компьютеров клиентов в целевые группы, то мы должны указать в какую из целевых групп должен быть помещен компьютер:

«TargetGroupEnabled»=dword:00000001

В нашем варианте целевая группа называется «WSUS-Test-WKS». Для клиентов, имя целевой группы которых будет иным, в этом поле указывается другое значение. Параметр TargetGroupEnabled в данном случае обеспечивает управление помещением в группу со стороны клиента.

Для этого в разделе реестра

"TargetGroup"="WSUS-Test-WKS"

"TargetGroupEnabled"=dword:00000001

"WUServer"="http://192.168.1.100"

"WUStatusServer"="http://192.168.1.100"

"NoAutoUpdate"=dword:00000000

"AUOptions"=dword:00000004

"ScheduledInstallDay"=dword:00000000

"ScheduledInstallTime"=dword:00000009

"UseWUServer"=dword:00000001

"RescheduleWaitTime"=dword:00000001

" NoAutoRebootWithLoggedOnUsers"= dword:00000000

Обеспечив доставку и выполнение указанного файла, мы сможем настроить клиентов сервера WSUS, не прибегая к использованию групповых политик. Описание всех переменных реестра, которые могут быть использованы для работы с сервером обновлений и их возможных значений приводится в Windows Server Update Services 3.0 SP2 Deployment Guide.

Для обеспечения безопасности самого сервера обновлений имеет смысл выполнить ряд простых рекомендаций:

1. Если нам требуется обеспечить безопасный информационный обмен между клиентами и серверами и/или между серверами WSUS, то предусматривается возможность использования протокола SSL. См. раздел «Securing WSUS with the Secure Sockets Layer» в Windows Server Update Services Deployment Guide (). При отсутствии сетевого обмена между серверами перенос данных обеспечивается посредством внешнего носителя. Альтернативным способом защиты, при невозможности использования SSL, является применение протокола IPsec. См. «Overview of IPsec Deployment» http://go.microsoft.com/fwlink/?LinkId=45154.

2. Сервер WSUS, который синхронизируется с Microsoft Update, следует размещать за брандмауэром и предоставлять доступ к нему только тем узлам, которые действительно в этом нуждаются. См. раздел «Configure the Firewall» в Windows Server Update Services Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=79983).

3. Что касается, файлового доступа, то не следует предоставлять избыточных разрешений на ресурсы, описание требований к правам доступа приводится в разделе «Before You Begin» в Windows Server Update Services Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=79983).

4. Если сервер обновлений имеет доступ в Интернет (в ряде случаев этого может и не быть, например, выполняется синхронизация с другим сервером WSUS, который обладает такой возможностью), то его БД рекомендовано размещать на другом компьютере, доступ из вне к которому невозможен. См. «Appendix B: Configure Remote SQL» в the Windows Server Update Services Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=79983).

5. Для управления сервером WSUS, разумно использовать встроенную группу WSUS Administrators, которая будет создана при развертывании.

Леонид Шапиро.

Список литературы.

Anita Taylor Windows Server Update Services 3.0 SP2 Deployment Guide.

Anita Taylor Windows Server Update Services 3.0 SP2 Operations Guide

[i] DMZ - demilitarized zone

Здесь рассматриваются не все, а только основные параметры настройки клиента WSUS.

Указать путь к искомым серверам можно как с помощью адреса, что было сделано в приведенном примере, так и с помощью имени сервера, предусмотрев при этом возможность разрешения имени сервера в его IP-адрес.

Здесь приводится абстрактное имя тестовой группы.

В одной из предыдущих статей мы подробно описали процедуру . После того, как вы настроили сервер, нужно настроить Windows-клиентов (сервера и рабочие станции) на использование сервера WSUS для получения обновлений, чтобы клиенты получали обновления с внутреннего сервера обновлений, а не с серверов Microsoft Update через Интернет. В этой статье мы рассмотрим процедуру настройки клиентов на использование сервера WSUS с помощью групповых политик домена Active Directory.

Групповые политики AD позволяют администратору автоматически назначить компьютеры в различные группы WSUS, избавляя его от необходимости ручного перемещения компьютеров между группами в консоли WSUS и поддержки этих групп в актуальном состоянии. Назначение клиентов к различным целевым группам WSUS основывается на метке в реестре на клиенте (метки задаются групповой политикой или прямым редактированием реестра). Такой тип соотнесения клиентов к группам WSUS называется client side targeting (Таргетинг на стороне клиента).

Предполагается, что в нашей сети будут использоваться две различные политики обновления — отдельная политика установки обновлений для серверов (Servers ) и для рабочих станций (Workstations ). Эти две группы нужно создать в консоли WSUS в секции All Computers.

Совет . Политика использования сервера обновлений WSUS клиентами во многом зависит от организационной структуры OU в Active Directory и правил установки обновлении в организации. В этой статье мы рассмотрим всего лишь частный вариант, позволяющий понять базовые принципы использования политик AD для установки обновлений Windows.

В первую очередь необходимо указать правило группировки компьютеров в консоли WSUS (targeting). По умолчанию в консоли WSUS компьютеры распределяются администратором по группам вручную (server side targeting). Нас это не устраивает, поэтому укажем, что компьютеры распределяются в группы на основе client side targeting (по определенному ключу в реестре клиента). Для этого в консоли WSUS перейдите в раздел Options и откройте параметр Computers . Поменяйте значение на Use Group Policy or registry setting on computers (Использовать на компьютерах групповую политику или параметры реестра).

Теперь можно создать GPO для настройки клиентов WSUS. Откройте доменную консоль управления групповыми политиками (Group Policy Management) и создайте две новые групповые политики: ServerWSUSPolicy и WorkstationWSUSPolicy.

Групповая политика WSUS для серверов Windows

Начнем с описания серверной политики ServerWSUSPolicy .

Настройки групповых политик, отвечающих за работу службы обновлений Windows, находятся в разделе GPO: Computer Configuration -> Policies -> Administrative templates -> Windows Component -> Windows Update (Конфигурация компьютера -> Административные шаблоны -> Компоненты Windows -> Центр обновления Windows).

В нашей организации мы предполагаем использовать данную политику для установки обновлений WSUS на сервера Windows. Предполагается, что все попадающие под эту политику компьютеры будут отнесены к группе Servers в консоли WSUS. Кроме того, мы хотим запретить автоматическую установку обновлений на серверах при их получении. Клиент WSUS должен просто скачать доступные обновления на диск, отобразить оповещение о наличии новых обновлений в системном трее и ожидать запуска установки администратором (ручной или удаленной с помощью ) для начала установки. Это значит, что продуктивные сервера не будут автоматически устанавливать обновления и перезагружаться без подтверждения администратора (обычно эти работы выполняются системным администратором в рамках ежемесячных плановых регламентных работ). Для реализации такой схемы зададим следующие политики:

• Configure Automatic Updates (Настройка автоматического обновления): Enable . 3 – Auto download and notify for install (Автоматически загружать обновления и уведомлять об их готовности к установке) – клиент автоматически скачивает новые обновлений и оповещает об их появлении;
• Specify Intranet Microsoft update service location (Указать размещение службы обновлений Майкрософт в интрасети): Enable . Set the intranet update service for detecting updates (Укажите службу обновлений в интрасети для поиска обновлений): http://srv-wsus.сайт:8530 , Set the intranet statistics server (Укажите сервер статистики в интрасети): http://srv-wsus.сайт:8530 – здесь нужно указать адрес вашего сервера WSUS и сервера статистики (обычно они совпадают);
• No auto-restart with logged on users for scheduled automatic updates installations (Не выполнять автоматическую перезагрузку при автоматической установке обновлений, если в системе работают пользователя): Enable – запретить автоматическую перезагрузку при наличии сессии пользователя;
• Enable client -side targeting (Разрешить клиенту присоединение к целевой группе): Enable . Target group name for this computer (Имя целевой группу для данного компьютера): Servers – в консоли WSUS отнести клиенты к группе Servers.

Примечание . При настройке политики обновления советуем внимательно познакомиться со всеми настройками, доступными в каждой из опций раздела GPO Windows Update и задать подходящие для вашей инфраструктуры и организации параметры.

Политика установки обновлений WSUS для рабочих станций

Мы предполагаем, что обновления на клиентские рабочие станции, в отличии от серверной политики, будут устанавливаться автоматически ночью сразу после получения обновлений. Компьютеры после установки обновлений должны перезагружаться автоматически (предупреждая пользователя за 5 минут).

В данной GPO (WorkstationWSUSPolicy) мы указываем:

• Allow Automatic Updates immediate installation (Разрешить немедленную установку автоматических обновлений): Disabled - запрет на немедленную установку обновлений при их получении;
• Allow non -administrators to receive update notifications (Разрешить пользователям, не являющимся администраторами, получать уведомления об обновлениях): Enabled - отображать не-администраторам предупреждение о появлении новых обновлений и разрешить их ручную установку;
• Configure Automatic Updates: Enabled . Configure automatic updating: 4 - Auto download and schedule the install. Scheduled install day: 0 - Every day . Scheduled install time: 05:00 – при получении новых обновлений клиент скачивает в локлаьный кэш и планирует их автоматическую установку на 5:00 утра;
• Target group name for this computer: Workstations – в консоли WSUS отнести клиента к группе Workstations;
• No auto-restart with logged on users for scheduled automatic updates installations: Disabled - система автоматически перезагрузится через 5 минут после окончания установки обновлений;
• Specify Intranet Microsoft update service location : Enable. Set the intranet update service for detecting updates: http://srv-wsus.сайт:8530 , Set the intranet statistics server: http://srv-wsus.сайт:8530 –адрес корпоративного WSUS сервера.

В Windows 10 1607 и выше, несмотря на то, что вы указали им получать обновления с внутреннего WSUS, все еще могут пытаться обращаться к серверам Windows Update в интернете. Эта «фича» называется Dual Scan . Для отключения получения обновлений из интернета нужно дополнительно включать политику Do not allow update deferral policies to cause scans against Windows Update ().

Совет . Чтобы улучшить «уровень пропатченности» компьютеров в организации, в обоих политиках можно настроить принудительный запуск службы обновлений (wuauserv) на клиентах. Для этого в разделе Computer Configuration -> Policies-> Windows Setings -> Security Settings -> System Services найдите службу Windows Update и задайте для нее автоматический запуск (Automatic ).

Назначаем политики WSUS на OU Active Directory

Следующий шаг – назначить созданные политики на соответствующие контейнеры (OU) Active Directory. В нашем примере структура OU в домене AD максимально простая: имеются два контейнера – Servers (в нем содержаться все сервера организации, помимо контроллеров домена) и WKS (Workstations –компьютеры пользователей).

Совет . Мы рассматриваем лишь один довольно простой вариант привязки политик WSUS к клиентам. В реальных организациях возможно привязать одну политику WSUS на все компьютеры домена (GPO с настройками WSUS вешается на корень домена), разнести различные виды клиентов по разным OU (как в нашем примере – мы создали разные политики WSUS для серверов и рабочих станций), в больших распределенных доменах можно привязывать , или же назначать GPO на основании , или скомбинировать перечисленные способы.

Чтобы назначить политику на OU, щелкните в консоли управления групповыми политиками по нужному OU, выберите пункт меню Link as Existing GPO и выберите соответствующую политику.

Совет . Не забудьте про отдельную OU с контроллерами домена (Domain Controllers), в большинстве случаев на этот контейнер следует привязать «серверную» политику WSUS.

Точно таким же способом нужно назначить политику WorkstationWSUSPolicy на контейнер AD WKS, в котором находятся рабочие станции Windows.

Осталось обновить групповые политики на клиентах для привязки клиента к серверу WSUS:

Все настройки системы обновлений Windows, которые мы задали групповыми политиками должны появится в реестре клиента в ветке HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate .

Данный reg файл можно использовать для переноса настроек WSUS на другие компьютеры, на которых не удается настроить параметры обновлений с помощью GPO (компьютеры в рабочей группе, изолированных сегментах, DMZ и т.д.)

Windows Registry Editor Version 5.00

"WUServer"="http://srv-wsus.сайт:8530"
"WUStatusServer"="http://srv-wsus.сайт:8530"
"UpdateServiceUrlAlternate"=""
"TargetGroupEnabled"=dword:00000001
"TargetGroup"="Servers"
"ElevateNonAdmins"=dword:00000000

"NoAutoUpdate"=dword:00000000 –
"AUOptions"=dword:00000003
"ScheduledInstallDay"=dword:00000000
"ScheduledInstallTime"=dword:00000003
"ScheduledInstallEveryWeek"=dword:00000001
"UseWUServer"=dword:00000001
"NoAutoRebootWithLoggedOnUsers"=dword:00000001

Также удобно контролировать применённые настройки WSUS на клиентах с помощью rsop.msc.

И через некоторое время (зависит от количества обновлений и пропускной способности канала до сервера WSUS) нужно проверить в трее наличие всплывающего оповещений о наличии новых обновлений. В консоли WSUS в соответствующих группах должны появиться клиенты (в табличном виде отображается имя клиента, IP, ОС, процент их «пропатченности» и дата последнего обновлений статуса). Т.к. мы политиками привязали компьютеры и серверы к различным группам WSUS, они будут получать только обновления, одобренные к установке на соответствующие группы WSUS.

Примечание . Если на клиенте обновления не появляются, рекомендуется внимательно изучить на проблемном клиенте лог службы обновлений Windows (C:\Windows\WindowsUpdate.log). Обратите внимание, что в Windows 10 (Windows Server 2016) используется . Клиент скачивает обновления в локальную папку C:\Windows\SoftwareDistribution\Download. Чтобы запустить поиск новых обновлений на WSUS сервере, нужно выполнить команду:

wuauclt /detectnow

Также иногда приходится принудительно перерегистрировать клиента на сервере WSUS:

wuauclt /detectnow /resetAuthorization

В особо сложных случаях можно попробовать починить службу wuauserv . При возникновении , попробуйте изменить частоту проверки обновлений на сервере WSUS с помощью политики Automatic Update detection frequency.

В следующей статье мы опишем особенности . Также рекомендуем ознакомиться со статьей между группами на WSUS сервере.

Программы