Для централизованной настройки параметров получения и установки обновлений на рабочих станциях и серверах Windows можно использовать групповые политики. В этой статье мы рассмотрим базовые параметры GPO, которые позволяют управлять установкой обновлений на компьютерах, получающих обновления от локального сервера WSUS или напрямую с серверов Windows Update в интернете.
Настройка параметров получения обновлений клиентам WSUS через GPO
Если у вас развернут собственный сервер обновлений Windows Server Update Services (WSUS), вы должны настроить рабочие стации и сервера в вашем домене AD для получения обновлений с него (а не с серверов Microsoft Update через Интернет).
В нашем случае мы хотим создать две разные политики установки обновлений для рабочих станций и серверов. Для этого откройте консоль управления WSUS (
wsus.msc
) на сервере и создайте в разделе Computers -> All Computers две группы компьютеров:
- Workstations
- Servers
Затем перейдите в раздел настройки сервера WSUS (Options), и в параметре Computers измените значение Use Group Policy or registry setting on computers (Использовать на компьютерах групповую политику или параметры реестра).
Теперь откройте консоль управления доменные групповыми политиками (Group Policy Management) и создайте две новые групповые политики: ServerWSUSPolicy и WorkstationWSUSPolicy.
Начнем с описания серверной политики ServerWSUSPolicy.
Настройки параметров службы обновлений Windows, находятся в разделе GPO: Computer Configuration -> Policies-> Administrative templates-> Windows Component-> Windows Update (Конфигурация компьютера -> Административные шаблоны -> Компоненты Windows -> Центр обновления Windows).
Мы хотим, чтобы продуктивные сервера не устанавливали обновления автоматически и не перезагружались без подтверждения администратора. Для этого настроим GPO так, чтобы сервера автоматически скачивали доступные обновления, но не устанавливали их. Администраторы будут запускать установку обновлений вручную (из панели управления или с помощью модуля PSWindowsUpdate) в согласованные окна обслуживания.
Настроим следующие параметры политики:
- 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.winitpro.ru:8530, Set the intranet statistics server (Укажите сервер статистики в интрасети):http://srv-wsus.winitpro.ru: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
Для рабочих станций мы хотим включить автоматическую загрузку и установку Windows Update сразу после получения новых обновлений. Компьютеры после установки обновлений должны перезагружаться автоматически в нерабочее время (с предварительным предупреждением пользователей).
В настройках WorkstationWSUSPolicy указываем:
- Allow Automatic Updates immediate installation (Разрешить немедленную установку автоматических обновлений):
Disabled— запрет на немедленную установку обновлений при их получении; - Allow non-administrators to receive update notifications (Разрешить пользователям, не являющимся администраторами, получать уведомления об обновлениях):
Enabled— отображать не-администраторам предупреждение о появлении новых обновлений и разрешить их ручную установку; - Configure auto-restart reminder notifications for updates и Configure auto-restart warning notifications schedule for updates – показывать пользователям уведомления о перезагрузке
- 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 утра; - Enable client-side targeting:
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.winitpro.ru:8530, Set the intranet statistics server:http://srv-wsus.winitpro.ru:8530–адрес WSUS сервера. - Включите опции Do not allow update deferral policies to cause scans against Windows Update (ссылка) и Do not connect to any Windows Update Internet locations. Это позволит предотвратить обращение клиента к серверам Windows Update в интернете.
- Turn off auto-restart for updates during active hours –
Enabled. Отключить авто перезагрузку после установки обновлений в рабочее время (задать интервал рабочего времени в политике Active Hours Start и Active Hours End. Например, с 8 AM до 5 PM)
В обеих GPO включите принудительный запуск службы Windows Update (
wuauserv
) на компьютерах. Для этого в разделе Computer Configuration -> Policies-> Windows Setings -> Security Settings -> System Services найдите службу Windows Update и задайте для нее автоматический запуск (Automatic).
Назначить групповые политики WSUS на OU с компьютерами
Затем в консоли управления GPO прилинкуйте созданные вами политики к соответствующим контейнерам (подразумевается что для серверов и рабочих станций в AD созданы отдельные контейнеры OU).
Щелкните в консоли GPMC по нужному OU, выберите пункт меню Link as Existing GPO и привяжите нужную политику WSUS.
Аналогично назначьте политику для компьютеров на OU с рабочими станциями.
Применение групповых политик Windows Update на клиентах
Дождитесь применения новых настроек GPO на клиентах или обновите их вручную:
gpupdate /force
Чтобы с клиента ускорить процесс регистрации и сканирования состояния на сервере WSUS, выполните команды:
$updateSession = new-object -com "Microsoft.Update.Session"; $updates=$updateSession.CreateupdateSearcher().Search($criteria).Updates
wuauclt /reportnow
wuauclt /detectnow /resetAuthorization
Полностью сбросить настройки службы Windows Update на компьютере.
Все настройки Windows Update, которые мы задали групповыми политиками должны появится на клиентах в ветке реестре HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate.
Настройки из этой ветки можно экспортировать в REG файл и использовать его для переноса настроек WSUS на другие компьютеры, на которых нельзя задать параметры обновления с помощью GPO (компьютеры в рабочей группе, изолированных сегментах, DMZ и т.д.)
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]
"WUServer"="http://srv-wsus.winitpro.ru:8530"
"WUStatusServer"="http://srv-wsus.winitpro.ru:8530"
"UpdateServiceUrlAlternate"=""
"TargetGroupEnabled"=dword:00000001
"TargetGroup"="Servers"
"ElevateNonAdmins"=dword:00000000
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU]
"NoAutoUpdate"=dword:00000000 –
"AUOptions"=dword:00000003
"ScheduledInstallDay"=dword:00000000
"ScheduledInstallTime"=dword:00000003
"ScheduledInstallEveryWeek"=dword:00000001
"UseWUServer"=dword:00000001
"NoAutoRebootWithLoggedOnUsers"=dword:00000001
Через некоторое время все клиенты появятся в назначенных группах компьютеров в консоли WSUS. Здесь будут видны имена компьютеров, IP адреса, версии ОС, процент их пропатченности и дата последнего сканирования.
Клиенты скачивают CAB файлы обновлений в каталог
%windir%\SoftwareDistribution\Download
. Логи сканирования, загрузки и установки обновлений можно получить из файлов WindowsUpdate.log.
GPO для получения и установки обновлений Windows Update через Интернет
Если у вас отсутствует собственный сервер WSUS, вы можете использовать рассмотренные выше групповые политики для настройки параметров получения и установки обновлений на компьютеры из интернета (с серверов Windows Update).
В этом случае задайте в Not configured все параметры GPO, которые задают получение обновлений с WSUS:
- Specify Intranet Microsoft update service location: Not set
- Target group name for this computer: Not Set
- Do not allow update deferral policies to cause scans against Windows Update: Disabled
- Do not connect to any Windows Update Internet locations: Disabled
Такоие настройки GPO позволяет вам управлять тем, как компьютеры скачивают и устанавливают обновления Windows.
Добрый день. А где следующая статья?
Вы не могли бы не делать картинки кликабельными, тем более, что это полноценные скриншоты, а не уменьшенные превьюшки, которые надо рассматривать в увеличенном масштабе при клике на них? Очень неудобно, когда возвращаешься в окно браузера из другого приложения и случайно тыкаешь на картинку только для того, чтобы окно стало активным.
Спасибо.
Спасибо за конструктивный отзыв! Вы правы, такое поведение не очень удобное.
Но совсем отказаться от кликабельных скриншотов не могу, довольно часто принудительно сжимаю ширину вставляемого изображения, чтобы можно было рассмотреть детали.
Поэтому решил все-таки настроить плагин для группировки изображений в статье в галерею. Так удобнее?
Честно говоря, лучше не стало. Да вы и сами видите 🙂 Плагин — это здорово и удобно, когда нужно маленькую картинку разместить и полноразмерный просмотр при клике. Но у вас идет сразу полноразмерная картинка. Зачем ее делать кликабельной? Вставьте просто картинку, без плагина и тега <a> 🙂
Сорри за оффтоп 🙂
Вот что там рассматривать? И так все видно, не пудри голову автору! Прям как в картинной галерее.
Автору большое спасибо!
Похожим образом настроен WSUS на Win Server 2012 R2,
GPO выглядит следующим образом:
Настройка автоматического обновления Включено
Настройка автоматического обновления: 3 — авт. загрузка и уведом. об устан
Разрешить клиенту присоединение к целевой группе Включено
Имя целевой группы для данного компьютера Office
Указать размещение службы обновлений Майкрософт в интрасети Включено
Укажите службу обновлений в интрасети для поиска обновлений: _http://srv.local:8530
Укажите сервер статистики в интрасети: _http://srv.local:8530
Но клиенты ведут себя как-то странно, периодически на некоторых клиентах вываливается сообщение о том что компьютер будет перезагружен через 10 мин., и кнопка «отложить» заблокирована.
Может быть знаете из за чего может быть такое поведение?
Возможно пользователи сами запускают установку обновлений? Найдите в журнале системы событие установки обновлений и посмотрите кто его инициатор.
Спасибо за статью.
Почему политики AD для серверов и клиентских компьютеров не сделать разными за счет WMI фильтров по типу ОС. Таким образом сделать более простую схему управления без обязательной привязки к определенной OU ?
В общем-то все верно, можно разделить таргетинг политик на клиенты и сервера за счет WMI фильтров GPO. С точки зрения управления это будет довольно удобно и универсально.
Но для больших доменов с несколькими WSUS серверами и делегацией прав управления на разные контейнеры, такая схема не всегда будет эффективнее.
Доброго времени суток!
Спасибо за полезную статью, все разложено по полочкам и доступно для понимания начинающим!
Проблема такого рода, после настройки GPO для серверов и клиентских машин не обновляется список компьютеров в WSUS. Компьютеры остаются в группе «неназначенные компьютеры», может что-то не донастроено?
Как вы таргетируете клиентов? Через групповые политики или вручную?
Учтите, что политики применяются не сразу, т.е. компьютеры появятся в нужной группе WSUS не сразу.
Проверьте применяются ли политики на клиентов. Понять применилась ли политика и установлено ли правильное значение группы WSUS можно через реестр. Смотрите в ветке [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\windows\WindowsUpdate] значение ключа «TargetGroup»
Добрый вечер!
Таргетирование производится по политикам. На машине в домене по пути в регистре стоит группа для рабочих машин пользователей, но в в списке WSUS также по прежнему одна группа «Неназначенные».
Подскажите, а влияет ли название группы каким алфавитом задано латынь или кириллица?
Спасибо!
Проверьте, что в настройках WSUS сервера указано как в статье Use Group Policy or registry setting on computers.
На кириллице группы WSUS называть не приходилось, не знаю насколько корректно система будет их обрабатывать. Переименуйте их лучше в англ версии.
Могу только поддержать коллегу. Таже фигня — ПК из АД попадают только в Неназначенные. И не важно как WSUS-e настроенo таргетирование(.
Никогда не сталкивался с проблемами таргетинга. Скорее всего у вас не правильно настроены / не назначены политики WSUS, либо неверные настройки сервера обновлений.
Проверьте на ПК, на который действует политика с настройкми WSUS, в ветке HCKL\Software\Policies\Microsoft\Windows\WindowsUpdate значение ключа Servers . В нем должно быть указано имя группы, которую вы создали во WSUS. Это выполняется?
Можно я зайду с другой стороны?) Политики настроены, клиенты распределены по группам домена. Те же группы на сервере WSUS создаются сами или их надо сделать руками? У меня вот второе. Только тогда в нее попадает клиент.
Да, группы WSUS нужно создать вручную.
Посоветуйте, как лучше настроить обновления ПК в офисе? Хотелось бы, чтобы обновления устанавливались автоматически, начиная с 12 дня (как раз обед), но без авто-перезагрузки.
Я так понимаю, надо выбрать:
Настройка автоматического обновления Опция 4 (авт. загрузка и установка по расписанию),
Не выполнять автоматическую перезагрузку при автоматической установке обновлений, если в системе работают пользователи Enabled,
Разрешить Windows Update автоматически пробуждать систему для установки запланированных обновлений Enabled.
Повторный запрос для перезагрузки при запланированных установках. Enabled 120 мин (например).
Разрешить немедленную установку автоматических обновлений — уже лишнее, если устанавливаем в 12 часов?
Указать сервер обновлений — это понятно…
В основном все? Заранее благодарен!!
Нужно еще бы настроить таргетинг на группу WSUS, если у вас их несколько. Политика «Разрешить клиенту присоединенеи к целевой группе» (Enable client-side targeting) = Имя_группы_на_WSUS.
Ну и в политике «Настройка автоматического обновления» выберите конкретный день установки обвнолений (либо 0 — ежедневно) и время (Установка по расписанию).
В остальном все ОК.
«автоматически пробуждать систему» — не забыть предупредить юзера, что ПК по его приходу может быть включеным.
Непонятка — автоутв только на тестовую группу. Но апдейты получают и те ПК кто эту грп не входят.
Почему так?
Так не бывает. Проверяйте политику автоапрува и значение ключа Servers в HCKL\Software\Policies\Microsoft\Windows\WindowsUpdate на проблемных клиентах.
Доброго времени суток! Спасибо за отличную статью, как в общем и все другие.
А по теме вопрос следущий: имеет ли смысл разбивать обновления WSUS на таргетинг группы по таким признакам как: версия ОС (XP, W7, 8, 10), разрядность ОС?
Или сделать это через фильтры WMI? Было бы интересно узнать кто какие, так сказать, «best practics» использует?
Еще было бы здорово почитать (наверное тема отдельной статьи) про методики отбора обновлений, категорий, автоутверждений. Кто как тестирует, как избавиться от рутинных действий при выполнении повседневных задач в администрировании WSUS. Возможно тоже в формате «best practics»
Доброго дня.
В большинстве случаев нет — все продуктивные обновления можно валить в одну кучу. А вот при тестировании, если у вас очень разношерстный состав ОС с критическими бизнес приложениями, может быть и имеет смысл тестировать обнвления по версиям ОС и т.д.
Про апрув обновлений руки никак не дайдут полноценную статью написать. Сейчас и меня стоит автоапрув новых обновлений на тестовые группы. Через 7-10 дней если нет проблем, переношу их на продуктививные (в статье есть ссылка на автоматизацию переноса ододренных обновлений между группами WSUS на Powershell).
Спасибо!
Я, признаться, до недавнего времени иногда делил по таким признакам сразу в продуктив. Может параноидально, но так как я практически не тестирую работу обновлений через (!!!), мне казалось что в случае чего, проще будет отловить где собака порылась. И так я делаю последние лет 10, каюсь грешен )). Сети у меня в основном малые, максимум 100-150 компов с серверами. Трудовые ресурсы администрирования ограниченные, поэтому совершенно не представляю когда и как заниматься подробным тестированием и анализом и т.п. «разбором полетов» как полагается «по инструкции».
Но, надо признаться, никогда не замечал каких-то фатальных проблем связанных как с кривым и не отловленным обновлением, так и с самим криво настроенным или работающим WSUS. В моем случае было несколько раз, что приходилось тупо сносить и переустанавливать WSUS с нуля, по разным причинам (в основном забитость и переполненность базы обновлений). Если были какие-то неустранимые проблемы на клиенте, что в итоге приходилось переустанавливать ОСь, не замечал что это было связано с кривыми обновлениями. Да и проще было, не тратя драгоценное время, перезалить ОСь у клиента. На серверах просто ставил самые рекомендуемые обновления, пока проблем ни разу не замечал. Но, при этом все что можно бэкапилось. Как мне казалось, такая методика в моем случае более оправдана и рентабельна по трудозатратам — обновлять все и вся что ни попадя, самое главное бэкапить важные данные, если что все переустановим и восстановим :).
Последнее время понимаю, что такое отношение к инфраструктуре не профессионально, как минимум (хотя работает ведь — не трожь, черт возьми! )) ). Ну и просто не спортивно что-ли .. поэтому и задал такой вопрос , вообщем.
PS: Прошу прощения за портянку и такой монолог в духе клуба анонимных алкоголиков: «здравствуйте, я системный администратор и я не тестирую обновления WSUS ))»
Понятно, что у всех разные ситуации. Можно ведь и тестирование упрощать: обновления с автоупрувом ставятся на 3-4 компьютера адекватных пользователей или IT-шников и пару некритичных серверов. Если 3-4 дня вс живут — выкатываете на всех.
Ну уж если не тестируете и автоапрув обновлений, то хотя бы нужно не ставить их сразу, а выждать 7-10 дней, если будут реальные жалобы от других пользователей, Майксрософт отзовет или заменит проблемные обновы.
Добрый день.
Скажите, может ли клиент тянуть настнойки обновлений и списки обновлений из сервера WSUS, а сами обновления из интернета?
Не очень понимаю зачем вообще такая конфигурация нужна. Экономи места на WSUS и ручной апрув апдейтов?
Но теоретически можно попробовать решить за счет поднятий WSUS сервера с настройкой «Do not store update files locally». Но какие трудности вас будут подстерегать на этом пути я даже представить не могу 🙂
Спасибо за Ваш ответ. Мне это нужно для уменьшения трафика между сервером и клиентом. Инфраструктура поднята в Azure и там трафик по VPN платный. Вот и хочу попробовать чтобы обновы тянулись из интернета, а не по VPN между клиентом и сервером. И не обязательно ставить только в ручном режиме. Еще одно уточнение. У меня обновления ставятся из SCCM и похоже я не могу сделать так как Вы предложили. Возможно у Вас есть еще мысли как можно это сделать?
Нужно поднимать точку обновления у себя (on premises). И SCCM и WSUS это позволяют. В SCCM вы можете вроде бы назначить точку обновления на любой компьютер (даже рабочую станцию).
Кроме того, в WIndows 10 есть функция получения обновления с соседних компьюютеров в локальной сети (а-ля пиринг):Обновление и безопасность -> Дополнительные параметры -> Выберите, как и когда получать обновления -> Обновления из нескольких мест -> Компьютеры в локальной сети
Но на деле я не пробовал этот функционал.
Да, пожалуй это разумный компромисс.. В общем то подобный сценарий я в каком то смысле применял. Единственно, это все было без обратной связи, поэтому трудно в дальнейшем было понять, если были какие то глюки — то от чего они?
А за отзывчивость, спасибо! Приятно пообщаться с адекватными людьми! Мало того что ваши статьи отличные, еще и очень много адекватных комментариев от опытных коллег по цеху!
@itpro
Прежде всего, позвольте поблагодарить за доходчивый и отлично структурированный материал 🙂
Ознакомился со всем циклом ваших материалов по WSUS, но так и не нашёл ответа на вопрос, можно ли сделать так (через GPO или как-то иначе), чтобы на отдельные группы компьютеров устанавливались не все «подходящие» обновления (в соответствии с версией ОС и другими установленными продуктами Microsoft), а только желаемые? Например, чтобы обновлялся только Office, но не сама ОС, или, напротив, всё (в том числе и прочие продукты Microsoft, например, SQL Server), кроме Office?
Спасибо.
Как вариант, можно создать отдельную группу на WSUS, на которую нужно апрувить только те обновление, которые вам необходимы (либо настроить правило автоматического одобрения обновлений только для выбранных продуктов, например Office). Останется настроить WSUS таргетинг на клиентах через GPO или переносом компьютеров данную группу WSUS.
Но главная проблема — один компьютер не может быть одновременно в двух разных группах WSUS. Это ограничение частично можно обойти с помощью SCCM SUP, но управление им на порядок сложнее.
Верно ли я понимаю, что в данном контексте «или» касается только лишь варианта одобрения обновлений — вручную ИЛИ автоматически? А собственно установка обновлений будет происходить в соответствии с правилами, определёнными через GPO?
Спасибо.
1) Да, речь о ручном и автоматическом одобрении обновлений.
2) Все верно — как ставить эти обновления вы настраиваете в собственных групповых политиках для разных групп WSUS.
Спасибо 🙂
Подскажите, в скрипте:
"WUServer"="http://srv-wsus.winitpro.ru:8530"
"WUStatusServer"="http://srv-wsus.winitpro.ru:8530"
"UpdateServiceUrlAlternate"=""
"TargetGroupEnabled"=dword:00000001
"TargetGroup"="Servers"
нужно поменять параметры WUServer» и «WUStatusServer» на IP адрес своего сервера WSUS?
Что за параметр «TargetGroup»?
Спасибо.
WUServer и WUStatusServer меняете на IP адрес вашего WSUS сервера.
TargetGroup — имя группы компьютеров в консоли сервера WSUS, для которой вы одобряете обновления.
а если нет доменной структуры? т.е. в AD нет компьютеров и соответственно в WSUS не созданы группы, то что в этом случае надо делать? необходимо ли вообще создавать группу ПК в WSUS? и указывать её в скрипте?
Спасибо.
Группы компьютеров на WSUS нужны, если вы хотите использовать разные настройки одобрения и установки обновления для разных групп компьютеров. В теорее можно создать только одну группу, через реестра настроить все компьютеры на нее и апрувить обновления только на эту группу.
Здравствуйте и спасибо за хорошую статью. Сделал все по Вашей инструкции. Однако компьютеры не получили в реестре настройки (только сам WSUS получил). Знаю что это происходит не сразу, но прошли сутки — также без изменений. Скажите, примерно, за сколько время компы подтягиваются в эти категории во WSUS?
Или же вероятно я что-то упустил и сделал все-таки что-то не то. Расскажу вкратце собственными словами мои действия.
1. Установка и настройка WSUS: установил на ново созданную машину Hyper-x ОС Server 2012R2 со всеми обновлениями. Дальше добавил роль WSUS. Дальше настроил его по мастеру: выбрал языки, продукты, категории обнов, время синхронизации и т.д. Синхронизировался, после чего создал группы машин Servers и Workstations. Дальше отметил в настройках «Использовать на компьютерах групповую политику или параметры реестра»
2. Настройка политик: создал два объекта групповой политики по адресу — Управление групповой политикой\МОЙ_ЛЕС\Домены\МОЙ_ДОМЕН\Объекты групповой политики\ServerWSUSPolicy и WorkstationWSUSPolicy, соответственно. Отредактировал их точно по вашим рекомендациям. Прям один в один. Дальше создал два подразделения по адресу: Управление групповой политикой\МОЙ_ЛЕС\Домены\МОЙ_ДОМЕН\Servers и Workstations соответственно, которых связал с соответствующими политиками: Servers с ServerWSUSPolicy и Workstations с WorkstationWSUSPolicy. Также с политикой ServerWSUSPolicy связал и подразделение Domain Controllers. Задействовал новые политики через gpupdate /force.
C тех пор прошли больше суток, и никаких особых изменений. В WSUS добавились только 3 машины: контроллер домена и его дубль в правильной категории Servers. В неназначенные — одна «мертвая душа». Проверил в реестре на других рабочих станциях и серверов – не добавились необходимые значения. Что я сделал не так? Ткните, пожалуйста, куда копать?
Возможно целевые компьютеры находятся в OU, на которые не применены политики WSUS. Я бы проверил применилась ли политика на клиенте через gpresult. Заодно посмотрел бы приехавшие настройки обновлений.
Все машины находятся в корень домена. Связал корень домена с политиками ServerWSUSPolicy и WorkstationWSUSPolicy. На всех машинах применилась WorkstationWSUSPolicy. И на рабочих станциях и на серверах. Обновления пошли, только в WSUS серверы попали в группу workstation. Поменял вручную в реестре каждого сервера таргет с воркстейшена на сервер, однако все также сидят в группу workstation на wsus.
Проблема решилась перемещением машин вручную из дефолтной Computers в ново-созданные OU Servers и Workstations. Правда, так и не понял почему когда были в одной кучи, применялась именно политика воркстайшенов. Спасибо за помощь!
Доброго времени суток!
WSUS показывает только часть компьютеров, допустим если общее количество компов 150, то показывает лишь 90. Сталкивался ли кто с такой ПРОБЛЕМОЙ?
В Unassigned Computers смотрели?
Как вы назначаете настройка WSUS на клиентов? Какой тип таргетинга? Ручной или через групповые политики?
После применения настроек нужно подождать 1-2 дня, чтобы клиенты отрапортовали на сервер.
Ну и версия WSUS сервера должна поддерживать новые версии клиентов. Т.е wsus на server 2003 не будет нормально видеть компьютеры с windows 10
1. Смотрел. Там так же 90 компов
2. этого я вам не скажу ибо незнаю, как можно проверить?
3. ОС Windows Server 2016, так что дело видимо не в этом.
Как вы нацеливаете клиентов на WSUS? Проверьте настройки в консоли WSUS -> Options -> Computers. Что там?
Внимательно прочитайте эту статью, здесь описан способ нацеливания через групповые политики.
Если у вас тоже настройка через GPO, убедитесь что политика WSUS привязана ко всем контейнерам (OU) в AD, в которых у вас находятся компьютеры.
«Мы предполагаем, что обновления на клиентские рабочие станции, в отличии от серверной политики, будут устанавливаться автоматически ночью сразу после получения обновлений.»
Подскажите, правильно ли я понял, что клиентские компьютеры должны быть для этого обязательно включены? Спасибо.
Доброго вечера! Все выполнил как в инструкции, ПК не в домене, поэтому выполнил ручное редактирование реестра. Но ПК так и не появился на сервере. wsus настраивал на Windows server 2022. подскажите, пожалуйста, как можно проверить, все ли правильно настроено со стороны сервера? смотрю в реестре сервера данных настроек, которые делал на клиенте нет
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]
«WUServer»=»10.30.70.80:8530»
«WUStatusServer»=»172.16.100.1:8530»
«UpdateServiceUrlAlternate»=»»
«TargetGroupEnabled»=dword:00000001
«TargetGroup»=»Servers»
«ElevateNonAdmins»=dword:00000000
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU]
«NoAutoUpdate»=dword:00000000 –
«AUOptions»=dword:00000003
«ScheduledInstallDay»=dword:00000000
«ScheduledInstallTime»=dword:00000003
«ScheduledInstallEveryWeek»=dword:00000001
«UseWUServer»=dword:00000001
«NoAutoRebootWithLoggedOnUsers»=dword:00000001
Из практики:
чтобы заставить клиента быстро отстучаться на WSUS сервер, нужно выполнить:
$updateSession = new-object -com "Microsoft.Update.Session"; $updates=$updateSession.CreateupdateSearcher().Search($criteria).Updates
wuauclt /reportnow
В течении пары минут клиент появится в консоли WSUS
Вот эта команда почему то уже не эффективна на Windows 10:
wuauclt /detectnowЗдравствуйте.
Попробовал вашу методу, выдаёт
Исключение из HRESULT: 0x8024000D.
Гугл говорит, что в XML, который клиент получает от сервера, не содержатся какие-то данные. А вот какие нужны данные и как посмотреть этот самый XML, не понял.
Смотрите подробные логи агента обновления Windows Update (https://winitpro.ru/index.php/2015/10/08/novyj-format-logov-agenta-obnovlenij-windows-10/)
Обычно там можно найти более подробную информацию о проблеме
wsus version 10.0.20348.2582 (стоят все самые последние апдейты на сервере)
Ни один клиентский компьютер никогда не обращался к серверу.
Тем временем на клиентах:
Центру обновления Windows не удалось проверить наличие обновлений, код ошибки: 0x8024401C.
Уже три дня бьёмся с проблемой, все статьи перевернули. Все настройки на IIS сделали так же, расширили лимиты, увеличили таймауты.
Через браузер все открывается, как положено
_http://wsus:8530/SimpleAuthWebService/SimpleAuth.asmx
Скрипты по очистке кэшей предыдущего wsus тоже запускали, ни чего не помогает.
В сети около 120 клиентов ни один не пробился до сервера.
сколько RAM/CPU на WSUS сервере?
Т.е. из статьи все рекомендации сделали и не вылезли за лимиты ресурсов?
https://winitpro.ru/index.php/2017/06/01/oshibka-0x8024401c-v-windows-10-pri-poiske-obnovlenij-na-wsus/
Параметр GPO Automatic Update detection frequency изменили до 3-4 часов, чтобы увеличить частоту синхронизаций клиента с сервером обновлений?
https://winitpro.ru/index.php/2018/04/26/0x80244010-ispravlyaem-oshibku-obnovleniya-windows-update/
В логах windowsupdate.log клиентов что-то еще есть?
https://winitpro.ru/index.php/2015/10/08/novyj-format-logov-agenta-obnovlenij-windows-10/
Сервер: 4 vCPU / 16 GB RAM
Т.е. из статьи все рекомендации сделали и не вылезли за лимиты ресурсов?
Сделали ресурсы жрет но служба не падает
Параметр GPO Automatic Update detection frequency изменили до 3-4 часов, чтобы увеличить частоту синхронизаций клиента с сервером обновлений?
Сделали
В журналах 0x8024401F | 0x80240440 | 0x8024401C.
Добрый вечер, кто нибудь сможет подсказать? в общем по wsus непонятная ситуация, компы добавляются в wsus, я их закидываю вручную в группы, но через 10-20 мин их всус раскидывает в другие группы самостоятельно, при этом у компов айпишник меняется а хостнейм остается прежним к примеру: был добавлен комп в группу тестировщики с именем тест1 айпи 192.168.1.1, через некоторое время этот же хост находится в группе боевые с именем тест1 а айпи сменился на 10.10.1.1, хотя в самом всус правила ничего так не настраивал, в чем может быть причина? а иногда вообще компьютер теряется из всех групп, но на самом компе обновления все скачивает устанавливает с всуса, по гпо таргет неймы по группам не настроено
1) WSUS будет раскидывать по группам, если настроена соотвествующая GPO политика нацеливания на конкретную группу. Либо что-то прописано непосредвенно в реестр на клиенте
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]«TargetGroupEnabled»=dword:00000001
«TargetGroup»=»Servers»
2) у компов реально несколько IP, включая возможные VPN интерфейсы?
.
Может сталкивался кто, все настройки серверов выполнены стандартно, 3 пункт, не перезагружать автоматически. Обновления висят, но не инсталлируются. Но прилетает очередное критическое секьюрное обновление после апрува и начинается сущий кошмар, все сервера начинаю хаотично его инсталлить и перезагружать прямо в рабочее время, чего в принципе быть не должно..
Здравствуйте, очень полезные статьи, использую в своей работе постоянно. Есть одна непонятная ситуация — компьютеры назначаются по группам с помощью групповых политик и в целом все работает как надо, но есть один комп, который висит в группе «неназначенные компьютеры», хотя должен быть в целевой группе. Политика, которая распределяет компы по группам и задает прочие настройки обновлений, на этом компе применяется, судя по логам из gpresult, но в реестре установлены только параметры WUServer и WUStatusServer, TargetGroup и TargetGroupEnabled там почему-то вообще нет.
Есть подозрение он у вас находится не в том контейнере (скорее, находится в Computers, который по умолчанию).
Нет, специально перепроверил сейчас, это было бы слишком просто)
У меня именно в этом была причина пару раз))
Я бы попробовал удалить его в ручную из WSUS, затем перевводить в домен. Где-то политики не применяются. По какой причине, сложно сказать. Ну, или может кто по опытней кто сталкивался с похожим что подскажет.
В общем, наверное какой-то глюк и ваш способ повторно ввести в домен скорее всего бы сработал, но я просто на том компе в реестре руками добавил TargetGroup и TargetGroupEnabled и комп этот сразу залетел в нужную целевую группу, а сегодня уже и обновления прилетели, которые ему полагаются в этой группе.