Tw-city.info

IT Новости
1 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Wsus без домена

Wsus без домена

Имеется большая организация, большая локальная сеть, разбросанная по всему городу, свыше 2500 компьютеров.

Запущен WSUS сервер.

Вопрос в том, а можно ли как-то сделать, чтобы все компьютеры во всей сети автоматически стали с него обновляться?

Чтобы не к каждому компьютеру подходить и прописывать в реестр

А например, через DHCP как-то передав как дополнительные параметры это сделать?

(групповые политики не предлагать, так как компьютеры в организации не в домене, а все по-одиночке).

А если с помощью DHCP параметры на использование компьютерами локального WSUS сервера передать нельзя, то может быть тогда есть возможность на DNS сервере организации (а он у нас есть) подменить DNS-адреса серверов Microsoft откуда идёт обновление на локальный WSUS? Но тут не всё так просто, так как там служба обновлений Windows обращается не к одному адресу, а там их много. А есть ли у кого готовое, надёжное решение?

Yura12
так как компьютеры в организации не в домене, а все по-одиночке

. и на каждом свой собственный пароль локального администратора. Ага? В таком случае — только к каждому ехать. Если же пароль один или вы знаете его для каждого ПК (из двух с половиной тысяч), то вот вам средство: http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx

А если с помощью DHCP параметры на использование компьютерами локального WSUS сервера передать нельзя

DHCP не имеет ни малейшего отношения к WSUS и прочим прикладным сервисам. Нет, нельзя.

А есть ли у кого готовое, надёжное решение?

Есть. Называется Active Directory и придумано специально для решения таких задач, как у вас.

Lotto
. и на каждом свой собственный пароль локального администратора. Ага?

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

Есть. Называется Active Directory и придумано специально для решения таких задач, как у вас.

Понятно. Спасибо. Но оно в данном случае (разрозненных компьютеров, без домена, с разными «администраторами») не подойдёт.

А с подменой имён в DNS нет варианта?

Drunken
Выкладывайте reg на шару и говорите, чтобы запустили.

Это сделано с 2007 года, уже много лет говорится, да из-за лени пользователей толку нет.

Ненужные службы выключены? Если нет, то среди ненужных служб есть служба «Удалённый реестр», и она позволяет подключать редактор реестра к машине по сети. Надо только знать логин и пароль пользователя с админскими правами, да ещё файрвол должен быть настроен соответственно, либо погашен.

Yura12
Централизованный антивирус в организации развёрнут? Через Касперского, например, можно много чего понаделать, эдакие GP для бедных.

Это сделано с 2007 года, уже много лет говорится, да из-за лени пользователей толку нет.
Как вариант — прикрутить к какому-нибудь полезному ресурсу проверку NAP. Например, доступ в Интернет предоставлять, как некоторые провайдеры, через VPN only, а там — проверка через NAP на NPS-сервере на соответствие компа политикам, в частности — наличие последних заплаток. Нет заплаток — нет инета. Волшебным образом лень пройдёт через неделю.

Yura12
свыше 2500 компьютеров
Запущен WSUS сервер
Для чего? На сегодняшний день компьютеры наверняка обновляются непосредственно с MS. Или кто-то решил, что пришло время для централизованного управления? Так оно не с WSUS начинается, а с домена.

Чтобы не к каждому компьютеру подходить и прописывать в реестр
Вместо этого клиентам подкладывается файл Group Policy, но в Ваших обстоятельствах хрен редьки не слаще.

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

Yura12
даже если она и запущена, то всё равно надо знать имя и пароль локального администратора

А вы его не знаете, что ли? Тогда отправьте им обычный циркуляр под расписку, если власти хватит. (с) Musik

И вообще: если нет логина-пароля локального админа от каждой недоменной машины, то ни о каком дистанционном управлении речи быть не может. В принципе.

Yura12
Но оно в данном случае (разрозненных компьютеров, без домена, с разными «администраторами») не подойдёт.

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

Musik
свыше 2500 компьютеров Запущен WSUS сервер Для чего? На сегодняшний день компьютеры наверняка обновляются непосредственно с MS.

Так да, компьютеры с Windows изначально обновляются непосредственно с MS.

А WSUS сервер запущен для того, чтобы разгрузить внешний Интернет-канал. Есть же разница, когда огромные обновления, да ещё на 2500 машин идут внутри сети на скорости 100 мегабит или 1 гигабит, или качаются на каждый компьютер с далёких серверов MS на медленной скорости, через внешний Интернет канал, перегружая его.

Yura12
Есть же разница
Разумеется, есть, но имеющаяся инфраструктура не готова к внедрению более выгодной технологии.

выход в Интернет у нас организован через прокси
2,500 компьютеров выходят в Интернет через единую точку? Вот это и создает перегруженность внешнего Интернет канала И каким образом делались настройки? Что сложного повторить процедуру уже для WSUS?

Musik
2,500 компьютеров выходят в Интернет через единую точку?

Практически все да. Ну некоторые через NAT или с внешнего IP в обход прокси.

И каким образом делались настройки?

Windows и браузеры сами всё делают автоматически (он берёт с DHCP имя домена и подставляет в http://wpad._имя_домена/wpad.dat а уже в скрипте wpad.dat на сервере прописано к IP диапазонам нашей сети и двух других Петрозаводских провайдеров идти напрямую, а к остальным — на прокси).

Yura12
Никаким
Скажем, DHCP сервер Вы все-таки подстраивали под WPAD.

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

Это сделано с 2007 года
Что сделано — выложены настройки для WSUS? Вы кто — новый человек в компании? Составьте два списка DHCP и WSUS клиентов, и по списку, не торопясь, подключайтесь к недостающим станциям, и т.д. Заодно узнаете все пароли локальных админов и поменяете их на один.

Добавление от 15.01.2015 20:59:

Да, в 2007 году .reg-файл с настройками WSUS был выложен в общую папку и сделано краткое руководство для пользователей, но им никто не интересуется.

Musik
Тогда кто обслуживает остальное, почему у них что-то не в норме

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

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

— Все они хирурги или костоправы. Нет из них ни одного терапевта. ©
Yura12
Да, в 2007 году .reg-файл с настройками WSUS был выложен в общую папку и сделано краткое руководство для пользователей, но им никто не интересуется.
А Вы чего хотите добиться? Я так понимаю, в данный момент у Вас интернет-канал под угрозой, так?
А WSUS сервер запущен для того, чтобы разгрузить внешний Интернет-канал.
Что создает дополнительное неудобство пользователям. Следовательно, Вам необходимо а) запретить обновляться через проксю напрямую, б) запретить работать на необновленных компьютерах. Логично?
Имхо, внедрение NAP — наиболее адекватный выход, в совокупности с запретом обновления напрямую решающий обе эти проблемы. Поймите, полумерами и уговорами лень Вы победить не сможете. С одобрения руководства принимайте жесткие меры, особенно против тех, кому «все равно». К таким людям, по идее, вообще должны применяться самые строгие меры безопасности, чтобы не навредили по безразличию. Их лень легко объяснима — им это не надо, это надо Вам (если это Ваша зона ответственности. Если нет — забейте ). Вот и избавляйте от лени техническими средствами.

Однажды Сисадмин пожаловался Учителю:
– Мы выдали всем нашим пользователям индивидуальные пароли, а они не желают хранить их в тайне. Записывают на листочках и приклеивают к мониторам. Что нам делать? Как заставить их?
Инь Фу Во спросил:
– Сначала скажи, почему они это делают.
Сисадмин подумал и ответил:
– Может быть, они не считают пароль ценным?
– А разве пароль сам по себе ценный?
– Не сам по себе. Ценна информация, которая под паролем.
– Для кого она ценна?
– Для нашего предприятия.
– А для пользователей?
– Для пользователей, видимо, нет.
– Так и есть, – сказал Учитель. – Под паролем нет ничего ценного для наших работников. Надо, чтоб было.
– Что для них ценно? – спросил Сисадмин.
– Догадайся с трёх раз, – рассмеялся Учитель.
Сисадмин ушёл просветлённый и сделал на корпоративном портале персональные странички для всех работников. И на тех страничках был указан размер зарплаты. Узнав об этом, все пользователи забеспокоились о своих паролях. На другой день в курилке обсуждали размер зарплаты Главбуха. На третий день ни у кого не было видно листочков с паролями.

Читать еще:  Перемещаемый профиль пользователя в домене

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

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

  • Главная
  • Устанавливаем и настраиваем WSUS.

Устанавливаем и настраиваем WSUS.

  • Автор: Уваров А.С.
  • 12.10.2010

Этим вы убьете сразу несколько зайцев: значительно уменьшите загрузку канала и потребляемый интернет трафик, а также получите в руки мощный инструмент для контроля и управления процессом обновлений. Отныне все локальные ПК будут обновляться с вашего сервера и устанавливать только выбранные вами обновления.

Внимание! Данный материал предназначен для устаревших версий Windows Server, рекомендуем также ознакомиться с актуальной статьей: Windows Server 2012 — установка и настройка WSUS.

Приступим. Перед установкой WSUS следует подготовить сервер, мы будем использовать Windows Server 2008 R2, однако с небольшими поправками все сказанное будет справедливо для других версий Windows Server. Что нам понадобится:

  • IIS 6 или выше,
  • .NET Framework 2.0 или выше,
  • Report Viewer Redistributable 2008 ,
  • SQL Server 2005 SP2 Express или выше.

WSUS может хранить обновления в собственной БД или использовать SQL-сервер, последнее более предпочтительно с точки зрения производительности. Если в вашей сети уже развернут SQL-сервер можно использовать его, иначе вполне подойдет бесплатный SQL Express.

Получить все необходимые компоненты можно на сайте Microsoft:

При скачивании обращаем внимание на разрядность, для 64-битной ОС скачиваем 64-битные версии продуктов.

Пока идет скачивание добавим роли сервера. Нам понадобятся Веб-сервер (IIS) и Сервер приложений (в предыдущих версиях Windows Server установите .NET Framework). Сервер приложений устанавливается со значениями по умолчанию, а в Веб-сервере необходимо добавить следующие опции:

  • ASP.NET
  • Windows — проверка подлинности
  • Сжатие динамического содержимого
  • Совместимость управления IIS6

Добавив необходимые роли, установим Report Viewer и SQL Server c параметрами по умолчанию. Все готово, можно устанавливать WSUS.

Запустив инсталлятор, выбираем установку сервера и консоли администрирования, папку установки. В параметрах базы данных указываем наш SQL-сервер. Остальные настройки можно оставить по умолчанию.

Сразу после установки запустится мастер начальной настройки. Все опции довольно просты и понятны. В параметрах синхронизации указываем откуда наш сервер будет получать обновления: с сервера Microsoft или с другого WSUS сервера. Последний вариант следует использовать если вам требуется развернуть дополнительный сервер обновлений, например, для филиала. В этом случае подчиненный сервер будет получать только одобренные вами обновления.

На следующей закладке, при необходимости, указываем параметры прокси-сервера, и выполняем первичное подключение. Будет загружена информация от вышестоящего сервера: списки продуктов, типов обновлений и т.д.

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

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

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

Открыв консоль (доступна в меню Администрирование), первым делом запустите ручную синхронизацию, чтобы скачать все имеющиеся на сегодняшний день обновления для выбранных продуктов. В зависимости от того, чего и сколько вы выбрали при настройке, а также скорости вашего подключения это может занять продолжительное время.

Пока идет синхронизация займемся настройкой клиентских ПК. Если у вас развернута Active Directory это можно сделать с помощью групповых политик. Откройте Управление групповой политикой, выберите необходимый объект и щелкнув правой кнопкой мышки нажмите Изменить. В открывшемся окне выберите Конфигурация компьютера — Политики — Административные шаблоны — Центр обновления Windows. Нас интересует параметр Указать размещение службы обновлений Microsoft в интрасети. Переводим его в положение Включено и указываем путь к нашему WSUS серверу в виде http:\ИМЯ_СЕРВЕРА.

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

Если ваша сеть имеет одноранговую структуру, то вам придется настраивать каждый ПК в отдельности. Делается это через Редактор локальной групповой политики (Пуск — Выполнить — gpedit.msc), сам процесс настройки полностью аналогичен вышеописанному.

Контролировать количество ПК и их статус вы можете в разделе Компьютеры консоли администрирования.

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

Также рекомендуем разбить ПК на группы, для каждой группы можно назначить свою политику обновлений. Так в отдельную группу можно выделить сервера, для которых автоматически устанавливать только критические обновления безопасности.

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

Здесь вы можете создавать свои правила и назначать их любой группе ПК. Например мы создали правило: автоматически одобрять все обновления MS Office группы Рабочие станции.

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

В качестве обслуживания сервера стоит время от времени (где-то раз в месяц) проводить очистку сервера. Это позволит избежать черезмерного увеличения размеров базы за счет удаления невостребованных, уже не нужных и неодобренных вами обновлений.

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

Настройка клиентов WSUS с помощью групповых политик

В одной из предыдущих статей мы подробно описали процедуру установки сервера 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) для начала установки. Это значит, что продуктивные сервера не будут автоматически устанавливать обновления и перезагружаться без подтверждения администратора (обычно эти работы выполняются системным администратором в рамках ежемесячных плановых регламентных работ). Для реализации такой схемы зададим следующие политики:

  • ConfigureAutomaticUpdates (Настройка автоматического обновления): Enable. 3 – Autodownloadandnotifyforinstall(Автоматически загружать обновления и уведомлять об их готовности к установке) – клиент автоматически скачивает новые обновлений и оповещает об их появлении;
  • SpecifyIntranetMicrosoftupdateservicelocation (Указать размещение службы обновлений Майкрософт в интрасети): 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 – запретить автоматическую перезагрузку при наличии сессии пользователя;
  • Enableclient-sidetargeting(Разрешить клиенту присоединение к целевой группе): Enable. Target group name for this computer (Имя целевой группу для данного компьютера): Servers – в консоли WSUS отнести клиенты к группе Servers.

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

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

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

  • AllowAutomaticUpdatesimmediateinstallation (Разрешить немедленную установку автоматических обновлений): Disabled — запрет на немедленную установку обновлений при их получении;
  • Allownon-administratorstoreceiveupdatenotifications (Разрешить пользователям, не являющимся администраторами, получать уведомления об обновлениях): Enabled — отображать не-администраторам предупреждение о появлении новых обновлений и разрешить их ручную установку;
  • Configure Automatic Updates:Enabled. Configure automatic updating: 4 — Auto download and schedule the install. Scheduled install day: 0 —Everyday. 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:

Все настройки системы обновлений Windows, которые мы задали групповыми политиками должны появится в реестре клиента в ветке HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdate.

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

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdate]
«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_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdateAU]
«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.

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

wuauclt /detectnow /resetAuthorization

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

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

Развертывание и использование WSUS сервера

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

Автор: Денис Васильев

Установка обновлений и патчей является очень важной составной частью обеспечения безопасности. Для всех специалистов по информационной безопасности основной необходимостью является мониторинг, анализ и устранение уязвимостей программного обеспечения. Компания Microsoft предоставляет бесплатную возможность использования сервиса обновлений своих программных продуктов в течение всего времени поддержки программного продукта. Необходимые обновления доступны через сеть интернет всем пользователям программных продуктов.

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

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

Установка WSUS

В рамках ОС Windows Server 2008 существует роль сервера Windows Server Update Services(рис. 1).

Для Windows Server 2003 следующие системные требования к установке WSUS 3.0 SP1:

  • Операционная система: Windows Server 2003 SP1 и выше.
  • Дополнительные роли сервера: IIS 6.0 и выше
  • Дополнительные обновления ОС: Microsoft .NET Framework 2.0, Microsoft Management Console 3.0.
  • Дополнительные программы: Microsoft Report Viewer, SQL Server 2005 SP1 (Служба WSUS способна установить внутреннюю службу Windows Internal Database).

Несмотря на то, что служба практически не требовательна к процессору и оперативной памяти, ей необходима изрядная доля дискового пространства. Желательно 40 Гб и более. В конечном итоге, размер занимаемого дискового пространства будет зависит от количества продуктов, которые необходимо обновлять, и количества требуемых обновлений в инфраструктуре.
Если при установке сервер не удовлетворяет системным требования, то появится окно предупреждения, в котором будет описано что необходимо установить (рис. 2).

Настройка сервера WSUS

Для нормальной работы сервера необходимо указать ряд параметров, которые делаются с помощью «Мастер настройки Windows Server Update Services»

В окне «Выбор вышестоящего сервера» необходимо указать пункт «Синхронизировать с Центром обновлений Майкрософт» (рис. 3).

При применении к корпоративной среде прокси-сервера в окне «Настройка прокси-сервера» необходимо указать IP адрес, номер порта и параметры аутентификации на прокси-сервере(рис. 4).

В окне «Выбор языков» необходимо выбрать пункт «Загружать обновления только на следующих языках» обязательно выбрать «Английский». Выбор остальных языков необходимо делать исходя из систем, установленных в компании, обычно ещё добавляют «Русский» (рис. 5). Нет необходимости выбирать «Загружать обновления на всех языках, включая новые», так как это увеличит количество обновлений, хранящихся на дисковом пространстве.

В окне «Выбор продуктов» необходимо указать продукты, установленные в рамках корпоративной среды. ВНИМАНИЕ! Никогда не устанавливаете все продукты, так как это может привести к увеличению размера хранимых обновлений, при этом обновления не будут использоваться. Необходимо методично и последовательно выбрать только те продукты которые используются в рамках корпоративной среды (рис. 6).

В окне «Выбор классов» необходимо указать только те классы которые требуют обновлений. Так как указание лишних классов в значительной степени увеличивает размер хранимых обновлений (рис. 7).

Читать еще:  Установка домен контроллера на server 2020

В окне «Настройка расписания синхронизации» необходимо выбрать время синхронизации (рис. 8). В рамках WSUS синхронизации не предполагает загрузку обновлений. В данном случае синхронизация будет производить только обновление информации с сервера Центра обновлений Майкрософт».

После первой синхронизации необходимо открыть консоль WSUS и выбрать «Параметры». В «Параметры» открыть пункт «Файлы и языки обновлений» ( рис. 9)

Во вкладке «Файлы обновлений» окна «Файлы и языки обновлений» необходимо указать каким образом будет осуществляться хранение файлов обновлений. Так как мы хотим уменьшить размер Интернет трафика, то необходимо выбрать «Хранить файлы обновлений локально на этом сервере» и ОБЯЗАТЕЛЬНО! выбираем пункты «загружать файлы обновлений на сервер только после одобрения обновления» и «Загружать файлы экспресс — установки» (рис. 10). Пункт «Загружать файлы обновлений на сервер только после одобрения обновления» необходим, так как по умолчанию сервер загрузить ВСЕ обновления, которые он посчитает необходимым для выбранных продуктов. Однако так как с течением времени очень многие обновления аккумулируются в Service Pack, то вероятнее всего они не будут нужны и займут дисковое пространство.

После всех настроек необходимо добавить компьютеры в службу WSUS.

Добавление компьютеров в службу WSUS

Если у Вас есть домен, то достаточно в его групповой политике прописать службу WSUS и выбрать правила обновления компьютеров.

Это делается следующим образом «Пуск – Администрирование – Управление групповой политикой». Выбираем ту политику, которая действует в домене (по умолчанию Default Group Policy). Кликаем правой кнопкой и выбираем «Изменить».

В окне «Редактор управления групповыми политиками» заходим «Конфигурация компьютера – Политики – Административные шаблоны – Компоненты Windows – Центр обновления Windows». Выбираем пункт «Указать размещение службы обновлений в Интрасети » (рис. 11)

В окне «Свойства: Указать размещение службы обновлений в Интрасети» указываем параметр «Включен» и в строке «Укажите службу обновление в интрасети для поиска обновлений» прописываете строку вида: http:// [ip адрес или DNS имя сервера обновления в сети]. Копируете адрес в окно «Укажите сервер статистики в интрасети» (рис. 12). В рамках редактора групповой политики есть подсказки в окне объяснений (рис. 12).

Также необходимо определить политику обновлений. Это делается через пункт «Настройка автоматических обновлений» (рис. 13).

В окне «Свойства: Настройка автоматических обновлений» указываем параметр «Включен» и параметры «Настройка автоматического обновления», «Установка по расписанию – день», «Установка по расписанию – время». В окне «Объяснение» есть описание всех параметров для серверов и желательно устанавливать параметр «2 –уведомления о загрузке и установке», что позволит администраторам выбирать время установки обновлений на сервера(рис. 14).

Если в рамках инфраструктуры присутствуют рабочие места которые не входят в состав домена (например мобильные рабочие места), но служба обновлений для этих рабочих мест необходима, то существует возможность указания этой службы в «Локальной политике безопасности».

В командной строке набираем gpedit.msc и проделываем те же операции, которые были описаны выше для групповой политики в домене.

Через некоторое время компьютер появится в окне «Компьютеры – Все компьютеры – Не назначенные компьютеры» при «Состояние: Любой» (рис. 15).

Управление обновлениями

Для того чтобы увидеть и одобрить необходимые обновления нужно в «Обновления – Все обновления» выбрать следующие пункты фильтра: «Одобрение: Неодобренные» и Состояние: Требуется» и нажать «Обновить»(рис. 16). ВНИМАНИЕ! для проверки необходимых обновлений всегда обращайте внимание, чтобы настройки фильтра стояли в положениях «Одобрение: Неодобренные» и Состояние: Требуется», иначе вы рискуете загрузить ненужные вам обновления, или не загрузить их вообще. В случае, если фильтр в настройках «Одобрение: Неодобренные» и Состояние: Требуется» показал пустое поле, то все необходимые обновления для компьютеров уже одобрены и находятся на сервере.

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

Достаточно часто существует необходимость принудительной проверки обновлений на сервере обновлений со стороны компьютера. Для этого существует программа wuauclt.exe, которая запускается через командную строку. Для проверки обновлений её необходимо запускать с ключом /detectnow (wuauclt.exe /detectnow). Для посылки отчета о состоянии (очень часто необходимо при первом подключении к серверу обновлений) необходимо запускать с ключом /reportnow (wuauclt.exe /reportnow).

Господа, удачных вам обновлений

Подписывайтесь на каналы «SecurityLab» в Telegram и Яндекс.Дзен, чтобы первыми узнавать о новостях и эксклюзивных материалах по информационной безопасности.

Настройка получения обновлений через WSUS на клиенте

Народ, подсажите плиз, поднял на прокси (Windows 2008 Enterprise) роль сервер обновлений (WSUS). До этого клиентские компы сами скачивали обновления через интернет. Теперь хочу, чтобы качали через WSUS. Не получается добавить клиентские компьютеры в консоли WSUS. На примере своего компа (Windows 7 x64 Prof), сделал как в этой инструкции:

В редакторе реестра идем в ветку: HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdate
Но там нету раздела WindowsUpdate. Его нужно создать через контекстное меню. Далее в новом разделе WIndowsUpdate два Строковых параметра:
— WUServer со значением http://wsus:8530
— WUStatusServer со значение http://wsus:8530
Чтобы параметры сразу применились нужно перезапустить службу обновлений. Для этого в командной строке вводим:
net stop wuauserv
net start wuauserv
wuauclt.exe /resetauthorization /detectnow
После этого данный компьютер должен отобразится в списке машин на сервере WSUS.

Но комп так и не появляется в оснастке WSUS и через поиск в данной консоле также не находится.
Подскажите в какую сторону копать, плиз

судя по тому , что АД нет.
надо ручками прописать имя wsus в DNS или WINS.

и добиться что бы он пиновался и открывался с локальных машин.

(10) Это потомуч то осознание необходимости AD приходит раньше, чем потребность в WSUS 🙂

Никаких веб-сервисов нет на proxy?
Поменяй порт у клиента (где ты в реестре правил) на 80.

До кучи и WSUS Server Debug Tool та тоже где-то должен быть.

победил наконец то эту хрень )) если кому интересно, вкратце:

1) ставим WSUS, при установке указываем Создать веб-сайт Windows Server Update Services 3.0. По умолчанию пользовательский веб-сайт WSUS использует для протокола HTTP порт 8530, а для протокола HTTPS (SSL) — порт 8531.
2) на клиентских машинах правим реестр:
В редакторе реестра идем в ветку (если ее нет, создаем): HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdate
создаем параметры:
WUServer со значением :8530″ target=»_blank» ref=»nofollow» class=»extralink»>http:// :8530
WUStatusServer со значение :8530″ target=»_blank» ref=»nofollow» class=»extralink»>http:// :8530
создаем подраздел AU и в нем параметр «UseWUServer»=dword:00000001

ммммммдааа. нафига в реестр лазить. и гуглом пользоваться тоже надо уметь.

настройка wsus на клиентской машине делается через gpedit.msc
Там найти ветку Административные шаблоны в ней ветку Windows Update Центр обновления и им подобные.

З.Ы.Хочешь ещё геморроя? Подыми на этом сервере ещё AD до кучи.

(29)хотелось бы услышать доводы, когда есть необходимость в АД.
Сколько пользователей (не ПК) в сети? Сколько из них с разными полномочиями?

Сколько раз ты проделал (24)? 15+7?

(30) по поводу доводов: 1) я так понимаю желательно иметь выделенный сервак под AD, а у меня прокси еще в качестве рещервного SQL Server настроен, на нем рабочая база каждую ночь поднимается из архива; 2) полномочия пользователей особым разнообразием не отличаются, у операторов, порезано все кроме 1С, у менеджеров и бухгалтеров почти полный доступ, но они у меня дрессированные )) не лезут куда попало; 3) различные политики доступа настроеные через разрешения на уровне доступа к отдельным папкам на сервере; 4) новых рабочих мест в ближайшей перспективе пока не предвидеться, так что один раз настроил существующие и забыл.
Таким образом, паока не вижу необходимости в моем случае в AD

С подсказки (25) теперь настройка проще, через шаблон безопасности ). Проделываю на каждой рабочей машине

(31)Да, человеку со словом «Admin» в нике открыть для себя оснастку GPO наверное приятно 🙂

Ключевая фраза:
>>Проделываю на каждой рабочей машине

Но запуск всуса — занятие разовое, а есть в работе админа и много перманентно плановых.
Как показвает практика — 15 ЭВМ — это фирма имеет, как min, директора, буха и выделенную секретаршу + работяги. Итого 4 роли + роль админа, естественно. Да и если работяг больше 3-х, то кто-то из них прокачан до начальнега. И правильнее его бы тоже стоило выделить правами.

По поводу доводов:
1) Да, но сама железяка без претензий на полноценный сервак (тем более для ваших двух десятков).
2) Это уж кто какому богу поклоняется, я бы разрулил. Дресировка дрессировкой, но в стаде из дюжины зверьком рано или поздно заведется какой-нить продвинутый, прочитавший методичку с хакер.ру и жаждущий применить «знания» в бою — так пусть портит только своё.
3)А тут других вариантов нет. Права на шару настраиваются на шарах, хоть АД, хоть не АД. Просто учетки не надо бегать клонировать на серверах.
4) Улыбок тебе. 😉
Опять же при апгрейдах или когда зверек бегает с места на место, или у дира коллекция ноутов — перемещаемые профили добавляют радости.

Ссылка на основную публикацию
Adblock
detector