В одной из предыдущих статей мы подробно описали процедуру установки сервера WSUS на базе Windows Server 2012 R2 / 2016. После того, как вы настроили сервер, нужно настроить Windows-клиентов (сервера и рабочие станции) на использование сервера WSUS для получения обновлений, чтобы клиенты получали обновления с внутреннего сервера обновлений, а не с серверов Microsoft Update через Интернет. В этой статье мы рассмотрим процедуру настройки клиентов на использование сервера WSUS с помощью групповых политик домена Active Directory.
Групповые политики AD позволяют администратору автоматически назначить компьютеры в различные группы WSUS, избавляя его от необходимости ручного перемещения компьютеров между группами в консоли WSUS и поддержки этих групп в актуальном состоянии. Назначение клиентов к различным целевым группам WSUS основывается на метке в реестре на клиенте (метки задаются групповой политикой или прямым редактированием реестра). Такой тип соотнесения клиентов к группам WSUS называется client side targeting (Таргетинг на стороне клиента).
Предполагается, что в нашей сети будут использоваться две различные политики обновления — отдельная политика установки обновлений для серверов (Servers) и для рабочих станций (Workstations). Эти две группы нужно создать в консоли WSUS в секции All Computers.
В первую очередь необходимо указать правило группировки компьютеров в консоли 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 должен просто скачать доступные обновления на диск, отобразить оповещение о наличии новых обновлений в системном трее и ожидать запуска установки администратором (ручной или удаленной с помощью модуля 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.
Политика установки обновлений 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.winitpro.ru:8530, Set the intranet statistics server: http://srv-wsus.winitpro.ru:8530 –адрес корпоративного WSUS сервера.
В Windows 10 1607 и выше, несмотря на то, что вы указали им получать обновления с внутреннего WSUS, все еще могут пытаться обращаться к серверам Windows Update в интернете. Эта «фича» называется Dual Scan. Для отключения получения обновлений из интернета нужно дополнительно включать политику Do not allow update deferral policies to cause scans against Windows Update (ссылка).
Назначаем политики WSUS на OU Active Directory
Следующий шаг – назначить созданные политики на соответствующие контейнеры (OU) Active Directory. В нашем примере структура OU в домене AD максимально простая: имеются два контейнера – Servers (в нем содержаться все сервера организации, помимо контроллеров домена) и WKS (Workstations –компьютеры пользователей).
Чтобы назначить политику на OU, щелкните в консоли управления групповыми политиками по нужному OU, выберите пункт меню Link as Existing GPO и выберите соответствующую политику.
Точно таким же способом нужно назначить политику WorkstationWSUSPolicy на контейнер AD WKS, в котором находятся рабочие станции Windows.
Осталось обновить групповые политики на клиентах для привязки клиента к серверу WSUS:
gpupdate /force
Все настройки системы обновлений Windows, которые мы задали групповыми политиками должны появится в реестре клиента в ветке 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 на клиентах с помощью rsop.msc.
И через некоторое время (зависит от количества обновлений и пропускной способности канала до сервера WSUS) нужно проверить в трее наличие всплывающего оповещений о наличии новых обновлений. В консоли WSUS в соответствующих группах должны появиться клиенты (в табличном виде отображается имя клиента, IP, ОС, процент их «пропатченности» и дата последнего обновлений статуса). Т.к. мы политиками привязали компьютеры и серверы к различным группам WSUS, они будут получать только обновления, одобренные к установке на соответствующие группы WSUS.
wuauclt /detectnow
Также иногда приходится принудительно перерегистрировать клиента на сервере WSUS:
wuauclt /detectnow /resetAuthorization
В особо сложных случаях можно попробовать починить службу wuauserv так. При возникновении ошибки 0x80244010 при получении обновлений на клиентах, попробуйте изменить частоту проверки обновлений на сервере WSUS с помощью политики Automatic Update detection frequency.
В следующей статье мы опишем особенности одобрения обновлений на сервере WSUS. Также рекомендуем ознакомиться со статьей о переносе одобренных обновлений между группами на WSUS сервере.
Добрый день. А где следующая статья?
Вы не могли бы не делать картинки кликабельными, тем более, что это полноценные скриншоты, а не уменьшенные превьюшки, которые надо рассматривать в увеличенном масштабе при клике на них? Очень неудобно, когда возвращаешься в окно браузера из другого приложения и случайно тыкаешь на картинку только для того, чтобы окно стало активным.
Спасибо.
Спасибо за конструктивный отзыв! Вы правы, такое поведение не очень удобное.
Но совсем отказаться от кликабельных скриншотов не могу, довольно часто принудительно сжимаю ширину вставляемого изображения, чтобы можно было рассмотреть детали.
Поэтому решил все-таки настроить плагин для группировки изображений в статье в галерею. Так удобнее?
Честно говоря, лучше не стало. Да вы и сами видите 🙂 Плагин — это здорово и удобно, когда нужно маленькую картинку разместить и полноразмерный просмотр при клике. Но у вас идет сразу полноразмерная картинка. Зачем ее делать кликабельной? Вставьте просто картинку, без плагина и тега <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, в которых у вас находятся компьютеры.
«Мы предполагаем, что обновления на клиентские рабочие станции, в отличии от серверной политики, будут устанавливаться автоматически ночью сразу после получения обновлений.»
Подскажите, правильно ли я понял, что клиентские компьютеры должны быть для этого обязательно включены? Спасибо.