Главная › Интернет › Типичные проблемы с синхронизацией ПО-обновлений через WSUS – как их определить

Типичные проблемы с синхронизацией ПО-обновлений через WSUS – как их определить

Каждый администратор осознает важность своевременных обновлений, особенно если это касается критических обновлений безопасности. Однако с ростом сети и увеличением числа программных продуктов это становится весьма непростой задачей. Значит самое время развернуть WSUS (Windows Server Update Services ) - локальный сервер обновлений в вашей сети.

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

Приступим. Перед установкой 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 для группы Рабочие станции.

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

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

Теги:

Please enable JavaScript to view the

Такую серверную роль как Windows Server Update Services (WSUS) целесообразно использовать как в мелких компаниях, насчитывающих от 10 компьютеров, так и в крупных корпорациях. В отличие от таких серверных ролей, как доменные службы или серверов электронной почты, для серверов обновлений WSUS вам не обязательно разворачивать отказоустойчивые сервера, так как автоматизация обновления клиентских компьютеров не является самой критичной задачей в бизнес процессах.

Сценарии развёртывания серверов обновлений:

Простое развертывание WSUS-серверов: Многие маленькие и средние организации в своей производственной среде для распространения обновлений, используют именно данную модель. Простые решения развертывания WSUS-серверов обычно представляют собой модель с развернутым сервером обновлений, который расположен внутри интрасети, защищенной межсетевым экраном и обслуживающим клиентские компьютеры интрасети. Для загрузки обновлений WSUS-сервер синхронизируется с серверами Центра обновления Microsoft.

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

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

Данная конфигурация развертывания серверов обновлений удобная для большинства производственных случаев, включая организации с филиалами. Модель иерархического развертывания WSUS-серверов рационально использовать для загрузки обновлений из Центра обновлений Microsoft и последующей установки этих обновлений посредством подчиненных серверов, тем самым разгружая широкополосное соединение с Интернетом. Целесообразно использовать такую конфигурацию в окружении, где один WSUS-сервер не в состоянии самостоятельно обеспечить развертывание обновлений в существующем парке компьютеров. По всем рекомендациям желательно использовать не более чем трехуровневую иерархию WSUS-серверов, так как при последующем распространении обновлений время задержки все время увеличивается. В любой модели и при любой конфигурации, подчиненный сервер обязан регулярно выполнять синхронизацию с вышестоящим сервером обновлений, образуя между собой неподдерживаемый замкнутый цикл. При изменении протокола соединений между серверами, для обеспечения максимальной защиты всей цепочки серверов обновлений, во время настройки иерархии WSUS-серверов, для настройки автоматических обновлений вам нужно указать наиболее удаленный подчиненный сервер. В том случае, если в вашей организации насчитывается несколько подчиненных серверов обновлений, вам не стоит настраивать на них синхронизацию с вышестоящими серверами обновлений в одно и то же время, что может привести к перезагрузке вышестоящего сервера. Для этой конфигурации лишь один WSUS-сервер загружает и управляет обновлениями непосредственно с серверов Microsoft, а все остальные серверы конфигурируются как реплики.

Группы компьютеров
Для всех моделей развертывания серверов WSUS, причем, модель простого развертывания не исключение, важнейшей частью при развертывании являются группы компьютеров. В большинстве организаций, одновременно все обновления не развертываются на все компьютеры. А для управления компьютерами, которые будут получать обновления, серверы WSUS позволяют настраивать группы компьютеров, а сами обновления уже развертывать для одной или нескольких групп одновременно. По умолчанию, в консоли WSUS вы можете найти две группы компьютеров: «Все компьютеры» и «Не назначенные компьютеры». По умолчанию, когда клиентский компьютер синхронизируется с WSUS-сервером, он автоматом добавляется в обе группы, созданные по умолчанию. Затем, из группы «Не назначенные компьютеры», вы можете переместить компьютеры в специально отведенную для них группу, так как данная группа содержит только те компьютеры, для которых не было назначено членство в созданных вами группах. В свою очередь, группа «Все компьютеры» позволяет распространять целевые обновления на все компьютеры вашей организации, независимо от того, членами каких групп являются компьютеры. Возьмём для примера случай простого развертывания WSUS с тремя настраиваемыми группами, которые называются «Тестирование», «Пилотная группа» и «Производство». Группа тестирования содержит несколько компьютеров, которые находятся в лабораторной среде и предназначены для проверки корректности работы механизма распространения обновлений. Если тестирование проходит удачно, то обновления будут развертываться в следующей группе. После тестирования обновления разворачиваются в пилотной группе, которая состоит из компьютеров ИТ-отдела, где квалифицированные специалисты могут устранить появившиеся после развертывания обновлений неисправности. Затем, если пилотное развертывание прошло без инцидентов, то вы можете развертывать обновления на производственных компьютерах, которые расположены в среде «Производство».

И/или программного обеспечения, установленного на дочерних терминалах, с относительно недавнего времени может выполняться при помощи специального инструмента, получившего сокращенное название в виде аббревиатуры WSUS. Что это такое? По сути, данное программное обеспечение представляет собой уникальный релиз, позволяющий отказаться от использования каждым компьютером, входящим в локальную сеть, самостоятельного интернет-канала для установки апдейтов. О том, как это все работает, и какие нужно установить настройки, далее и пойдет речь.

Windows Server Update Services: что это и зачем нужно?

Если говорить об этом сервисе простым языком, его можно описать как программное обеспечение для автоматического обновления ОС и ПО, устанавливаемое исключительно на сервер, к которому подключаются остальные пользовательские терминалы, объединенные в единую локальную или виртуальную сеть.

Поскольку обновления корпорация Microsoft для своих продуктов выпускает с завидной регулярностью, устанавливать их нужно на всех машинах в сети, что достаточно проблематично, если их более десятка. Чтобы не заниматься подобными вещами на каждом отдельно взятом терминале, можно использовать функцию WSUS Offline Update, когда основное обновление устанавливается только на сервер, а потом «раздается» на все остальные компьютеры.

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

Требования к установке

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

В качестве приоритетов можно выделить следующие компоненты:

ОС модификации Windows Server не ниже 2003 (хотя бы с первым сервис-паком);
платформа.NET Framework версии не ниже 2.0;
роли сервера IIS 6.0 или выше;
Report Viewer от Microsoft модификации 2008;
SQL Server версии 2005 со вторым сервис-паком;
Management Console от Microsoft модификации 3.0.

Процесс инсталляции

Собственно, установка WSUS предполагает также резервирование свободного дискового пространства на сервере в размере порядка 100 Гб (расположение папки хранения обновлений указывается на первом шаге после запуска основного инсталлятора).

Параметры баз данных веб-сервера

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

В данном случае нужно будет самостоятельно прописать его сетевое имя, соответствующее идентификатору терминала в сети. Первые два варианта можно использовать либо для получения апдейтов с сервера Microsoft, либо с внутреннего сервера. Правда, есть еще и третий вариант - установка баз данных на удаленном терминале. Но такая схема применяется в основном только в тех случаях, когда нужно распределять апдейты по удаленным филиалам с дополнительного сервера обновлений.

Выбор порта

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

Обратите внимание, что по умолчанию к использованию предлагается 80-й порт. Можно, конечно, оставить и его, но лучше (и это подтверждается практикой) использовать порт под номером 8530 (8531). Но такой подход применим только в том случае, когда требуется ручная настройка прокси.

Выбор обновлений

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

Тут есть два варианта: либо производить синхронизацию с сервером обновления Microsoft, либо с другим удаленным терминалом. Лучше использовать первый вариант.

Настройка WSUS в домене

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

Выбор продуктов

Теперь для WSUS Offline Update следует указать, какие именно программные продукты подлежат обновлению. Как считает большинство специалистов, при выборе желательно не жадничать и отметить максимально возможное количество пунктов в списке.

Но и увлекаться тоже не стоит. Лучше отметить только то, что действительно необходимо. Например, если ни на одной машине в сети версия «Офиса» 2003 не установлена, то и указывать ее обновление не стоит.

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

Настройки консоли

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

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

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

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

Установка параметров обновления в групповых политиках

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

Для этого нужно использовать который проще всего вызвать через консоль «Выполнить» (Win + R) командой gpedit.msc, а не использовать «Панель управления» или раздел администрирования.

Здесь нужно через конфигурацию компьютера и политики добраться до административных шаблонов, где найти «Центр обновления». В нем нас интересует параметр, отвечающий за указание расположения службы обновления в интрасети. Вызывав двойным кликом меню редактирования, службы нужно включить и указать адрес сервера, который обычно выглядит как http://SERVER_NAME, где SERVER_NAME - имя сервера в сети. Можно не использовать такую комбинацию, а просто прописать IP сервера. По завершении настройки через некоторое время дочерние машины начнут получать пакеты апдейтов.

Возможные ошибки

Ошибки WSUS чаще всего связывают с тем, что для серверов включено слишком много ненужных обновлений, о чем было сказано выше.

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

Наконец, если не производить полный сброс настроек WSUS, после чего всю процедуру установки параметров придется производить заново, настоятельно рекомендуется хотя бы раз в месяц делать очистку сервера (для этого предусмотрена одноименная функция в виде «Мастера»). Такие шаги помогут удалить из системы невостребованные апдейты, а также существенно уменьшить размер самой базы данных (понятно ведь, что чем боле база, тем большее время требуется на обращение к ней, плюс - чрезмерная нагрузка на вычислительные способности сервера и распределение обновлений по сети).

В некоторых случаях может помочь установка политик не по умолчанию (Default Group Policy), а создание нового типа со всеми активированными параметрами из списка доступных с вводом сетевого адреса сервера (при задействованном порте 8530).

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

Вместо итога

Собственно, на этом рассмотрение вопроса о настройке службы автоматического апдейта WSUS можно и закончить. Чтобы все заработало и не вызывало беспокойства у системного администратора в дальнейшем, следует обратить внимание на начальные условия, связанные с установкой дополнительных компонентов. Как считается, серверную версию ОС лучше использовать не 2003, а 2008 R2 или выше, а также обратить внимание на платформу.NET Framework четвертой версии, а не 2.0). Кроме того, особо внимательно следует отнестись к настройкам прокси и выбору портов, поскольку порт 80 по умолчанию может и не работать. Наконец, одним из самых важных аспектов настройки является выбор групп терминалов и устанавливаемых на них обновлений. В остальном же, как правило, проблем быть не должно, хотя при загрузке тяжеловесных апдейтов большого размера при плохом качестве связи кратковременные сбои и ошибки распределения обновлений по сети наблюдаться все-таки могут. Кстати, и чистить сервер время от времени тоже нужно. Если автоматический инструмент по каким-то причинам положительного эффекта не возымеет, можно попытаться хотя бы удалить временные файлы вручную из директории SDTemp. По крайней мере, даже такой тривиальный шаг позволит сразу же снизить нагрузку не только на сам сервер, но и на дочерние терминалы, и на сеть в целом.

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

Вторая ошибка это Многие клиентские компьютеры не сообщали информацию на сервер за последние 30 дней.

Погуглив ошибку я нашел решение, оно заключалось в том, что нужно было установить обновления KB2734608 , мне они к сожалению не подошли так как они рассчитаны на WSUS 3, а в Windows Server 2012 R2 идет уже WSUS 6. Но поискать в инете обновления я не поленился. В итоге получил аж 82, устанавливаем их.

После перезагрузки я обнаружил еще ошибку Консоли администрирования WSUS не удается подключиться к базе данных сервера WSUS, причин этому несколько идет режим обновления скриптов. При установке WSUS я использовал встроенную базу данных, WID (Windows Internal database) - встроенная база Windows. База WID по умолчанию называется SUSDB.mdf, расположена в каталоге windir%\wid\data\. Поддерживается только Windows аутентификация (не SQL). Именем инстанса базы данных WSUS: server_name\MicrosoftWID. Логи WSUS смотрим в каталоге windir%\wid\