Как получить мощное и надежное решение управления обновлениями

В прошлом для применения программ-исправлений было достаточно собственных импровизированных решений. Но в настоящее время опасные программы распространяются очень быстро, и администратору нельзя полагаться на самостоятельные посещения пользователями Web-узла Microsoft Windows Update, чтобы поддерживать приемлемый уровень безопасности предприятия. 14 июня 2005 г. компания Microsoft выпустила очередные ежемесячные обновления, среди которых — десять бюллетеней безопасности. Три уязвимых места были отнесены к критическим, и аналитики предсказывали, что вредоносные программы, нацеленные на эти лазейки, появятся в течение недели. К счастью, несколькими днями раньше компания Microsoft выпустила первые компоненты новой инфраструктуры развертывания обновлений, в состав которых вошло надежное решение для управления исправлениями, Windows Server Update Services (WSUS).

Наряду с обновлением Windows и исправлениями для системы безопасности, WSUS обеспечивает развертывание драйверов, инструментов, пакетов обновлений, пакетов дополнительных функциональных возможностей, Microsoft Office 2003, Windows XP, Microsoft SQL Server и Microsoft Exchange Server. Но перед развертыванием WSUS на предприятии необходимо составить проект с учетом ключевых факторов и выбрать соответствующую топологию. В данной статье объясняются этапы подготовки плана развертывания WSUS на предприятии, но не уточняются детали установки WSUS; эта процедура подробно описана в статье Дугласа Тумбса «WSUS решает проблемы» (Windows IT Pro/RE № 6 за 2005 год).

В документе «Deploying Microsoft Windows Server Update Services», который можно загрузить с Web-узла WSUS компании Microsoft (http://www.microsoft.com/ windowsserversystem/updateservices), намечены основные принципы проектирования. Во-первых, необходимо сформулировать план обновления, в том числе стратегию, цели, ресурсы и процедуры. Затем необходимо выбрать ядро базы данных для WSUS, определить оптимальное местоположение серверов WSUS, выбрать файлы с исправлениями, которые следует получить, и место их хранения, и наметить план обслуживания групп клиентов. Ответив на эти вопросы, можно приступать к проектированию топологии WSUS.

Этап 1. Формулируем план обновления

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

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

Этап 2. Выбор базы данных

WSUS загружает обновления из службы Microsoft Update. Они состоят из файла обновления, распространяемого клиентам для установки, и метаданных, в которых указаны имя обновления, дата выпуска, номер редакции, целевые продукты и требования к перезагрузке. Метаданные загружаются в базу данных, выделенную для сервера WSUS, в которой также хранятся параметры настройки WSUS. По мере того как клиенты связываются WSUS, сервер вводит основные инвентарные сведения в базу данных. Статус процесса обновления также сохраняется в базе данных.

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

  • Microsoft SQL Server 2000 Desktop Engine (MSDE) с пакетом Service Pack 4 (SP4) на сервере WSUS, работающем с Windows Server 2003 или Windows 2000 SP4.
  • Windows MSDE (WMSDE) на сервере WSUS с Windows 2003. WMSDE, поставляемая вместе с WSUS, представляет собой специальную усовершенствованную версию MSDE и эффективное решение для многих реализаций WSUS.
  • SQL Server 2005 или SQL Server 2000 SP4 на сервере WSUS или внутреннем сервере. Необходимо активизировать режим вложенных триггеров, а экземпляр SQL Server должен использовать проверку подлинности Windows Authentication. Данные WSUS могут храниться в экземпляре SQL Server на другой системе; подробности см. в документации по WSUS.

Выбор оптимальной базы данных для сервера обновления зависит от аппаратной платформы, числа клиентов, которое поддерживает сервер, и готовности предприятия платить за лицензии. Для каждого сервера WSUS требуется особый экземпляр SQL Server, MSDE или WMSDE; удаленная централизованная система SQL Server не обеспечивает работу нескольких серверов WSUS. Рекомендуется начать с WMSDE на системе Windows 2003 и отслеживать производительность.

Этап 3. Выбор местоположения серверов WSUS

WSUS может работать с Windows 2003 или Windows 2000 Server SP4, в том числе Small Business Server (SBS) 2003. Служба WSUS несовместима с 64-разрядными платформами Windows 2003. Такие системы могут получать обновления из WSUS, но не поддерживают развертывание обновлений для других клиентов. Специалисты Microsoft рекомендуют использовать Windows 2003 вместо Windows 2000 Server SP4, так как базовый исходный код Windows 2003 более надежно защищен и располагает WMSDE.

Для WSUS также необходимы инфраструктура Windows .NET Framework 1.1 с пакетом SP1, Background Intelligent Transfer Service (BITS) 2.0, Windows HTTP Services (Win-HTTP) 5.1, Microsoft Internet Information Services (IIS) 6.0 (for Windows 2003) или IIS 5.0 с IIS Lockdown (для Windows 2000 Server), Microsoft Internet Explorer (IE) 6.0 с SP1 и локальная база данных (за исключением конфигурации с удаленным SQL Server). Эти требования к программному обеспечению могут определить выбор сервера, так как влияют на ранее установленные службы и приложения на существующем сервере.

WSUS необходимо установить на автономном сервере, а не на контроллере домена (DC). Применение WSUS на DC приемлемо для малой компании или филиала, но при таком подходе на любом предприятии снижается производительность и возникают проблемы с безопасностью. Если WSUS установлен на контроллере домена Windows 2000, то следует изучить конкретные проблемы DC по документации. WSUS можно установить и на SBS, но при этом следует обратиться к документации, чтобы избежать конфликтов между WSUS, Web-сервером компании и Windows SharePoint Services. Лучший вариант — установить WSUS на автономном сервере.

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

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

Этап 4. Выбор файлов обновлений

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

Преимущество локального хранения файлов обновлений заключается в снижении нагрузки на внешние каналы связи: сервер WSUS загружает файлы обновления в сеть, а затем распространяет их среди клиентов. BITS 2.0, технология загрузки обновлений от Microsoft Update на сервер WSUS а затем на клиентские компьютеры, более эффективно использует пропускную способность сети, чем служба Microsoft Software Update Services (SUS). Если из-за местоположения клиента в сети процесс загрузки обновлений с WSUS-сервера неэффективен, можно настроить WSUS таким образом, чтобы клиенты получали список подтвержденных обновлений от сервера, но загружали обновления самостоятельно через службу Microsoft Update.

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

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

Этап 5. Подготовка группового плана

WSUS позволяет организовать целевые группы клиентов и применять исправления к конкретным группам. Состав групп должен соответствовать стратегии обновления на предприятии. Типовые стратегии группирования клиентов — по типу (серверы, настольные компьютеры, ноутбуки), роли (руководитель, разработчик), фазе применения исправлений (тестирование, пилотный этап, развертывание, не устанавливать исправления), конфигурации клиента (простая/управляемая, сложная/неуправляемая — компьютеры со сложной конфигурацией трудно диагностировать или вернуть в прежнее состояние) и приоритету обновления (критическая, нормальная, низкая).

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

Этап 6. Выбор топологии

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

Для реализации топологии следует обратиться на административный Web-узел WSUS, http://WSUSservername/WSUSAdmin (где WSUSservername — имя сервера WSUS) и выбрать пункты Options, Synchronization Options. В разделе Update Source представлены режимы получения исправлений. Первый режим, выбираемый по умолчанию, используется для загрузки обновлений от службы Microsoft Update. Такая конфигурация — основа односерверной топологии. Обновления можно получать и от вышестоящего (upstream) сервера WSUS.

Единственный сервер. Топология с одним сервером WSUS — самая простая. Если инфраструктура обновления на предприятии может функционировать только с одним сервером, то в качестве источника обновления следует выбрать службу Microsoft Update. После того как обновления будут загружены на сервер, их можно подтвердить и ориентировать на группу компьютеров, и клиенты будут загружать соответствующие исправления с сервера. Целевые группы, которые будут подробно описаны в будущей статье, можно использовать для передачи обновлений на определенные компьютеры. На рис. 2 показана односерверная топология.

Иерархические или цепочечные серверы. Если сайт обслуживает много клиентов, то можно развернуть несколько серверов WSUS, чтобы повысить производительность. Расположив несколько серверов в одном месте, можно обслуживать большое количество пользователей или пересылать обновления на серверы, расположенные в разных географических точках (рис. 3).

При использовании односерверной топологии WSUS-сервер получает обновления от Microsoft Update. Но в конфигурации с несколькими серверами обновления часто поступают от других WSUS-серверов. Сервер, предоставляющий обновления, — вышестоящий (upstream); серверы, которые получают обновления от вышестоящего сервера, называются нижестоящими (downstream). Технически глубина иерархической структуры не ограничена, но протестированная компанией Microsoft глубина составляет только пять серверов WSUS. Максимальная глубина иерархии определяется приемлемым временем задержки между подтверждением исправления на самом верхнем сервере и его установкой на серверах и клиентах нижнего уровня; увеличивать глубину сверх трех уровней не рекомендуется.

Для корректной реализации иерархической топологии необходимо понимать принципы настройки конфигурации и обработки исправлений. Конфигурация должна быть согласована по всей иерархии. Например, файлы обновлений должны храниться в одном месте во всех серверах — сервер не может хранить файлы обновлений в Microsoft Update, если вышестоящий или нижестоящий серверы хранят файлы локально, и наоборот. Фильтры контента (подписки на категории продуктов, классификации обновлений и языки) также должны быть унифицированы. Файлы экспресс-установки необходимо применять единообразно.

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

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

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

Серверы WSUS — тоже клиенты, и их также необходимо обновлять. В иерархической модели требуется направить WSUS-серверы на самый нижестоящий WSUS-сервер для получения обновлений. Такой метод кажется неестественным. Это сделано для того, чтобы иметь возможность в будущем применять исправления к WSUS-файлам. Если компания Microsoft выпустит исправление для WSUS и вышестоящий сервер применит ее таким образом, что нижестоящие серверы не смогут обращаться к вышестоящему, то обновление никогда не достигнет нижнего уровня, и весь процесс обновлений будет блокирован. Поэтому необходимо обеспечить распространение обновлений вниз перед тем, как серверы WSUS обновят себя. Кроме того, самый нижний сервер должен обновить себя последним. Рекомендуемый метод решения этой задачи — сделать данный сервер отдельной целью (поместить сервер в собственную целевую группу компьютеров) и одобрять WSUS-обновления после того, как они будут применены к существующим WSUS-серверам. И наконец, чтобы успеть передать обновления вниз до самообновления WSUS-серверов, следует ограничить число уровней модели.

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

Например, на предприятии может быть принята модель целевых компьютерных групп, в которые входят группы Test, Critical, Important, Low Risk и Do Not Update. Если используется топология репликации, то обновления, подтвержденные администратором и предназначенные для каждой группы, синхронизируются с каждым сервером-репликой. Каждый филиал или подразделение может иметь сервер-реплику WSUS. Серверы-реплики управляют членством в своих группах самостоятельно.

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

Отключенные серверы. WSUS позволяет использовать инструмент командной строки Wsutil для экспорта обновлений с одного сервера и их импорта на другой. Функция экспорта-импорта полезна для обновления клиентов, расположенных в области сети, отключенной от Internet или остальной части сети. Например, этот подход могут использовать организации с закрытыми сетями или администраторы скрытых сетей. Администратор экспортирует подтвержденные обновления из сетевого сервера WSUS, переносит их на сменном носителе в автономную сеть и импортирует обновления в отключенный WSUS-сервер.

Множественные серверы. Топология с несколькими серверами — это просто тиражирование топологии с одним сервером. Несколько WSUS-серверов получают обновления от службы Microsoft Update. Каждый сервер управляется отдельно и может иметь уникальную конфигурацию, уникальные параметры и списки подтверждения. Такую топологию имеет смысл реализовать на предприятии с высоким уровнем централизации, каждое подразделение которого отвечает за управление своими обновлениями.

Топология с несколькими серверами также необходима, если часть пользователей устанавливает коммутируемое соединение с сетью компании или работает через VPN-соединение. Пусть правила подтверждения и исправления хранятся локально на корпоративном WSUS-сервере. Внутренние клиенты получают подтверждения и исправления с этого сервера. Чтобы уменьшить нагрузку на каналы связи, рекомендуется направить удаленных пользователей на WSUS-сервер для подтверждения исправлений и передачи отчетов и в службу Microsoft Update для загрузки обновлений (рис. 5). Проблема возникает из-за того, что WSUS-сервер внутренних клиентов хранит файлы локально, а WSUS-сервер удаленных клиентов — нет. В нисходящей иерархической топологии и топологии с сервером-репликой все серверы должны хранить файлы обновления в одном месте. Таким образом, для удаленных пользователей необходим автономный WSUS-сервер. Администратор должен вручную подтвердить обновления на этом сервере отдельно от внутреннего WSUS-сервера — нельзя экспортировать и импортировать только подтверждения.

Компании Microsoft предстоит решить эту проблему в следующей редакции WSUS. Альтернативное решение — настроить внутренний сервер на загрузку файлов экспресс-установки. Благодаря эффективности инкрементного обновления и BITS 2.0 устраняется необходимость в отдельном WSUS-сервере для подтверждения обновлений для удаленных пользователей.

На старт, внимание...

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

Марш!

Развернуть WSUS на предприятии — сложная задача. В следующей статье я расскажу о том, как установить и настроить WSUS и клиент Automatic Updates в корпоративной среде.

Дэн Холм - Директор по учебной работе компании Intelliem, которая предоставляет обучение с акцентом на решении практических задач и консультации по внедрению Windows и Active Directory на предприятии. danh@intelliem.com

Описание проекта

Проблема: подготовка плана развертывания WSUS на предприятии.

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

Сложность: 2 из 5

Этапы проекта:

  1. Сформулировать план обновления.
  2. Выбрать ядро базы данных.
  3. Определить местоположение серверов WSUS.
  4. Определить необходимые файлы обновления и место их хранения.
  5. Подготовить план группового обслуживания.
  6. Построить топологию.