WSUS решает проблемы

Как использовать новую службу Microsoft для развертывания исправлений

Понедельник, 9:00. Microsoft выпустила критическое исправление для системы безопасности.

Вторник, 9:00. Исправление успешно развернуто на 2500 рабочих местах и 150 серверах.

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

Установка WSUS

Взяв за основу Software Update Services (SUS), разработчики WSUS предлагают для использования тщательно проработанный набор функций, возможности которого далеко выходят за рамки обычного SUS. Во врезке «Краткая история WSUS» рассказывается об эволюции службы обновлений Microsoft.

В частности, WSUS предоставляет возможность составления отчетов, поддерживает установку исправлений для приложений (Exchange, Microsoft Office, Microsoft SQL Server), умеет работать с группами компьютеров при развертывании исправлений и поддерживает концепцию предельного срока действия задания по установке исправлений (на усмотрение администратора). С выходом окончательной версии WSUS развертывание исправлений, по всей вероятности, перестанет отягощать жизнь системных администраторов. Загрузить WSUS можно по адресу http://www.microsoft.com/windowsserversystem/ updateservices/default.mspx.

Для установки WSUS необходимо выполнить некоторые требования, как на сервере, так и на клиенте. Во-первых, потребуется сервер Windows Server 2003 или сервер Windows 2000 Server и Microsoft IIS с поддержкой Background Intelligent Transfer Service (BITS) 2.0. Служба BITS 2.0 доступна для загрузки с сайта WSUS. И как практически для всех недавно выпущенных продуктов Microsoft, для нормальной работы WSUS необходимо установить последнюю версию Windows .NET Framework. После того как в целевой системе будут обновлены все перечисленные компоненты, можно приступать к установке WSUS и запустить программу установки, включенную Microsoft в загружаемый файл.

В самом начале установки требуется ответить на вопрос, будет ли WSUS хранить обновления, получаемые от Microsoft. Можно выбрать один из двух вариантов — хранить обновления на самом сервере WSUS или рассчитывать на то, что клиенты будут самостоятельно обращаться за ними на сервер Microsoft (см. экран 1). Мне представляется, что дисковое пространство — ресурс исключительно недорогой, в отличие от пропускной способности Internet. Если в организации насчитывается несколько тысяч рабочих станций, попробуйте себе представить, что произойдет, если все они одновременно попытаются загрузить свежие исправления по Internet. Предположим, что для хранения исправлений выбирается локальный каталог на сервере WSUS. Необходимо убедиться, что в указанном каталоге в вашем распоряжении имеется по крайней мере 6 Гбайт свободного дискового пространства. В момент публикации загрузка полного комплекта исправлений (включая поддержку всех языков) потребует около 2 Гбайт дискового пространства.

Экран 1. Указание места хранения исправлений

WSUS дополнительно нужно 2 Гбайт дискового пространства для размещения собственной базы данных SQL Server, которую WSUS использует для отслеживания служебной информации — например, какие исправления загружены, но не развернуты, каким образом сгруппированы машины, какие исправления (и на каких системах) были успешно развернуты и т. д. Для работы с этой базой данных полновесная система SQL Server в организации не нужна (хотя, конечно, если она уже есть, ею стоит воспользоваться); для WSUS можно задействовать настольный вариант SQL Server, как показано на экране 2.

Экран 2. Выбор базы данных для хранения исправлений

После нескольких экранов, где надо просто подтвердить согласие на установку WSUS, начинается собственно процедура установки. После ее завершения со WSUS можно начинать работать. При обращении к http://localhost/wusadmin пользователь получает доступ ко всем функциям WSUS (все они реализованы в Web-интерфейсе). Если WSUS работает правильно, на экране появляется страница, напоминающая ту, что представлена на экране 3.

Экран 3. Стартовая страница WSUS

Выбор параметров загрузки WSUS

Интерфейс WSUS содержит пять зон, которые показаны вверху справа как пять значков: Home, Updates, Reports, Computers и Options. Понятно, что, когда WSUS запускается впервые, нет еще никаких обновлений, которые можно было бы принять или отклонить (если только не была произведена модернизация от SUS). В списке обновлений на начальной странице везде должны стоять нули (экран 3). Следовательно, прежде всего требуется настроить WSUS на получение всех необходимых обновлений. Но прежде чем нажимать на Synchronize now, следует настроить параметры WSUS.

WSUS по умолчанию сама устанавливает некоторые параметры, и одна из этих настроек подразумевает, что будут загружаться все доступные исправления для всех возможных языков. Это приведет к исключительно длительной загрузке на начальном этапе работы WSUS. Если развертываются все языковые версии Windows 2003, Windows XP и Windows 2000, эта настройка может оказаться полезной. Но для большинства сайтов это не так и, следовательно, приведет к бесполезной трате огромного объема дискового пространства (не говоря уже о пропускной способности сайта Microsoft WSUS). Итак, следует выбрать для своей организации только необходимые языки. Для этого нужно щелкнуть значок Options, а затем выбрать Synchronization Options. Пролистайте секцию Update Files and Languages и щелкните Advanced — появится окно, как на экране 4.

Экран 4. Указание языковых настроек при загрузке

В Synchronization Options также можно установить, какие типы исправлений надо загрузить и сделать доступными для использования — например, исправления для системы безопасности, пакеты обновлений, драйверы, критические исправления, а также какие программные продукты требуется поддерживать. После того как все параметры будут настроены, следует вернуться на страницу Home и щелкнуть Synchronize now для запуска процесса синхронизации. Если поначалу не все продукты становятся доступными, не стоит беспокоиться; все, что пока недоступно, должно проявиться после начальной синхронизации с Windows Update — оперативной службой загрузки обновлений Microsoft.

Начальная синхронизация WSUS займет некоторое время, в зависимости от пропускной способности канала и числа загружаемых исправлений. Я был свидетелем процессов начальной загрузки, на которые уходило от часа до целого вечера. После завершения процесса синхронизации можно приступать к распространению одобренных исправлений (исправлений, установку которых администратор одобрил) по всей организации. При выполнении начальной синхронизации WSUS загружает только детальную информацию о каждом исправлении. На самом деле исправление не загружается до тех пор, пока администратор не санкционирует его развертывание. Чтобы увидеть все доступные для загрузки исправления, а также те, что уже были одобрены для загрузки на сервер WSUS, сначала нужно щелкнуть значок Updates (экран 5).

Экран 5. Просмотр загруженных исправлений

Архив, в котором WSUS хранит всю информацию, — это база данных, а значит, все исправления и пакеты обновлений обладают необходимыми атрибутами, по которым можно осуществлять быстрый поиск. Когда вы в первый раз смотрите на страницу Update, то видите поля, связанные с каждым исправлением, например Classification (классификация) и Approval (одобрение). Это всего лишь два из расширенных атрибутов, хранящихся вместе с каждым исправлением, которое прошло через WSUS. Рекомендую найти время, просмотреть список исправлений и определить, что следует одобрить для распространения в организации, а что нет. Чтобы изменить статус Approval исправления, необходимо выделить нужный элемент на виде Update и щелкнуть параметр Change approval в левой части окна. На экране должно появиться диалоговое окно, как на экране 6.

Экран 6. Одобрение исправлений для установки WSUS

По умолчанию для всех обновлений статус одобрения имеет значение Detect, если только в политике синхронизации не было установлено, что изменения получают автоматическое одобрение. Исправления со статусом одобрения Detect будут просто инспектировать целевые системы для проверки, требуется ли в системе то или иное исправление, и результат этой проверки будет фиксироваться. Чтобы одобрить исправление для распространения, нужно выбрать Install вместо Detect, и исправление начнет распространяться по всей организации. Для некоторых исправлений разработчики Microsoft даже обеспечили возможность удаления, для чего из списка Approval достаточно выбрать параметр Remove. Вместе с тем WSUS не может автоматически удалить исправления, которые не поддерживают возможности удаления (обратите внимание на экран 6); для таких исправлений параметр Remove не отображается.

Настройка исправлений

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

Возможность создавать группы компьютеров — новая функция WSUS, одна из тех, которых так не хватало SUS. Администраторы SUS, как правило, старались не распространять один и тот же набор исправлений на серверы и рабочие станции (например, большинству серверов не нужен медиаплейер — Windows Media Player, WMP, и, соответственно, исправления для него), поэтому все изобретали свои пути выхода из этой ситуации — часто в организации просто создавалось несколько SUS-серверов. WSUS избавляет от необходимости использовать несколько серверов SUS, позволяя администраторам группировать компьютеры в соответствии с выбранными критериями. После того как исправление одобрено для установки, для разных групп компьютеров можно описать различные параметры установки. Например, для серверов можно настроить только инспекцию систем для выяснения, нужно им одобренное исправление или нет, тогда как для рабочих станций указать автоматическое развертывание исправления. Для каждого исправления, хранящегося в WSUS, может быть назначено множество подобных действий с привязкой к определенным группам компьютеров.

Помимо описания нужной настройки — detect, install или remove, можно установить дату и время, когда WSUS и Automatic Updates начнут принудительную установку, если она до сих пор не произошла. К этой возможности обычно прибегают в том случае, когда хотят гарантировать, что самые свежие исправления для системы безопасности будут развернуты на всех системах организации за отведенное время. Чтобы назначить для исправления предельный срок действия (deadline), требуется щелкнуть справа от поля Deadline параметр None (экран 6). На экране появится диалоговое окно Edit Deadline (экран 7).

Экран 7. Задание конечного срока для установки

При назначении конечного срока для развертывания исправления в распоряжении администратора есть три возможности: позволить пользователю применить исправление в любое время (на его усмотрение); позволить пользователю применить исправление в любое время, но по истечении заданной даты и времени приступить к принудительной установке; установить исправление немедленно. Чтобы пользователь мог установить исправление в любое время, нужно просто оставить в поле Deadline значение None. Чтобы гарантировать, что к указанному времени пользователь обязательно установит исправление, необходимо ввести в окне Edit Deadline нужную дату. После того как время назначенного срока истекло, от пользователя в обязательном порядке потребуется установка исправления. И наконец, если исправление нужно развернуть по всей организации в максимально сжатые сроки, просто задайте текущую дату и время, и тогда на всех системах начнется установка обновлений.

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

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

Даже если прежде вы занимались настройкой Automatic Updates, у вас может возникнуть вопрос — а где же я добавлял или изменял имя нужного сервера? Все правильно, при внесении изменений надо обратиться к реестру. Следует запустить редактор реестра и перейти в раздел HKEY_LOCAL_MACHINE SOFTWAREPoliciesMicrosoftWindows. Здесь уже может находиться подраздел WindowsUpdate. Если его там нет, ничего страшного, в некоторых системах этот раздел по умолчанию не создается и его надо создать вручную. Создайте раздел HKEY_LOCAL_ MACHINESOFTWAREPoliciesMicrosoftWindows WindowsUpdate, если его нет в реестре. Этот раздел будет контейнером для двух параметров, которые также придется создать: один сообщит Automatic Updates, что нужно отыскать сервер WSUS, а другой — где именно WSUS может быть найден.

Итак, в разделе WindowsUpdate создайте новый раздел с названием AU, а в нем параметр UseWUServer (тип данных REG_DWORD) и присвойте ему значение 1 (true). Новый параметр сообщит Automatic Updates, что в организации используется сервер WSUS вместо стандартного сервера Windows Update, который поддерживает Microsoft. Не покидайте раздел AU и создайте еще один параметр с именем AUOptions (тип данных REG_DWORD). Этот параметр определяет поведение клиента Automatic Updates: клиент принимает к сведению информацию о наличии исправлений, клиент получает оповещение и загружает исправления или же выполняет полную установку исправления. Рекомендую для начала установить параметр AUOptions равным 3 (извещение и загрузка); позднее его можно будет изменить.

Затем следует вернуться в HKEY_LOCAL_MACHINE SOFTWAREPoliciesMicrosoftWindowsWindowsUpdate, добавить в раздел WindowsUpdate два новых параметра, WUServer и WUStatusServer (тип данных обоих REG_SZ). Присвойте обоим параметрам URL сервера WSUS (см. экран 8). Эти значения сообщают Automatic Updates, по какому адресу можно найти сервер WSUS.

Экран 8. Настройка Automatic Updates на использование WSUS

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

Находясь в реестре, можно изменить и некоторые другие стандартные параметры клиента Automatic Updates. Эти параметры приведены в таблице и расположены в реестре по адресу HKEY_LOCAL_MACHINESOFTWAREPolicies MicrosoftWindowsWindowsUpdateAU.

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

Дуглас Тумбс - Редактор журнала Windows IT Pro.help@toombs.us

История WSUS

В январе 2003 года Microsoft объявила об инициативе Trustworthy Computing, в соответствии с которой компьютеры, операционные системы и приложения должны быть безопасными с точки зрения проектирования, настроек по умолчанию и развертывания (secure by design, secure by default, secure by deployment). Последний пункт — безопасность развертывания (secure by deployment) — термин Microsoft, описывающий системы, для которых легко устанавливаются исправления и выполняется аудит. Такие системы помогают организации управлять рисками безопасности, связанными с использованием компьютерных сетей.

Легкость при распространении исправлений и проведении аудита — это ключ к успеху концепции secure by deployment, поскольку затраты, связанные с ручной установкой исправлений в масштабе всей организации, имеют тенденцию экспоненциального роста с увеличением числа используемых в организации устройств. Установка исправлений вручную для большинства организаций становится просто нежизнеспособным принципом работы: развертывание исправлений вручную в рамках организации превращается в очень дорогостоящую затею из-за высокой частоты выпуска исправлений. Анализ подхода, при котором исправления устанавливаются вручную, со всей очевидностью показывает, что взломанные системы были бы защищены, если бы на них своевременно были установлены необходимые исправления. Недавнее исследование Университета Карнеги—Меллона показывает, что в 99% всех отчетов о взломах систем речь идет об использовании известных уязвимых мест или ошибках в настройках, для которых контрмеры уже существовали.

Для того чтобы решить проблему заказчиков с поддержанием систем в актуальном состоянии с точки зрения установленных исправлений, Microsoft выпустила Software Update Services (SUS), продукт, который позволяет администраторам установить в организации собственный сервер Windows Update. Благодаря тесной интеграции SUS с клиентом Automatic Updates, установленным на каждом сервере и рабочей станции компании, для развертывания новых исправлений для Windows и связанных с ней компонентов достаточно просто поставить галочки напротив исправлений, которые требуется установить. Серверы и рабочие станции воспринимали переданную информацию, и либо начиналась многоэтапная процедура развертывания исправлений, либо исправления устанавливались немедленно — все зависело от настроек.

Администраторы, приступившие к работе с SUS, через какое-то время начинали удивляться — как они до сих пор могли обходиться без SUS! Тем не менее было несколько областей, где служба SUS обычно не помогала, — при развертывании исправлений в зависимости от классификации системы (например, серверы, настольные системы), при установке исправлений, написанных не для операционных систем, а, скажем, для офисных приложений, и при попытке вывести отчет о проделанной работе.

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

Управление исправлениями без WSUS

Windows Server Update Services (WSUS) — прекрасное решение, позволяющее автоматизировать и упростить развертывание исправлений Microsoft на системах под управлением Windows 2000 или более новых версий Windows. Когда Дункан Эрб, старший консультант ИT-провайдера Keane, и его партнер получили задание по проектированию, построению и обслуживанию сети WAN из 1500 узлов Windows NT 4.0 для авианосцев военно-морских сил США, им потребовалось найти метод развертывания исправлений по сети WAN примерно для 3500 пользователей, разбросанных по району в 100 квадратных миль. Старший редактор Windows IT Pro Анне Груб побеседовала с Дунканом Эрбом, о том, каким образом ему удалось решить задачу управления исправлениями и другие административные задачи с учетом ограничений сети NT.

Мой партнер Роджер Роббинс и я работаем по контракту. Авианосцы заходят в порт Нортроп-Груман для тщательного осмотра каждые 3,5 года. Судно полностью «раздевается», включая кабельные сети. Мы обеспечиваем WAN-доступ для персонала судна на все время ремонта. В нашем управлении два домена: один для подрядчиков и персонала, которые постоянно находятся здесь, в порту, как я или мой партнер, и домен самого судна. Это в основном и составляет нашу сеть. Так что нам приходится работать с теми операционными системами, с которыми имеют дело наши пользователи, иначе при возвращении на корабль в свою сеть у них могут возникнуть трудности. В настоящий момент 90% компьютеров заказчиков используют NT 4.0. Военно-морские силы в некотором отношении отстают от веяний времени. Проблема заключается в том, что флот не может просто перейти на новые версии, поскольку у военных «на вооружении» слишком много унаследованного (устаревшего) программного обеспечения, которое требуется сначала протестировать и убедиться, что все работает нормально в новой среде, потом еще нужно разобраться с безопасностью...

Что касается управления исправлениями на платформе NT, то это практически невозможно сделать, если только не задействовать сценарии регистрации или Microsoft Systems Management Server (SMS). Я вообще-то не специалист по написанию сценариев, я сетевой инженер. Мы занимаемся всем — от прокладки волокна до настройки коммутаторов, маршрутизаторов, рабочих станций и серверов. После тщательного отбора мы остановились на продукте ScriptLogic, поскольку с его помощью удалось упростить процесс написания настраиваемых сценариев регистрации. Эти сценарии работают на порядок быстрее старых сценариев, используемых на флоте, — 15 секунд, а не 15 минут, как было раньше.

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

Для управления исправлениями мы используем сценарии регистрации в том случае, когда у нас есть исправление, которое нужно веером распространить по всему домену. Проблема в том, что все рабочие станции NT настроены по-разному. Например, на некоторых стоит Internet Explorer (IE) 5, где-то — IE 6.0. Я могу создать пакет при помощи Application Launcher и разослать все исправления за один раз. Можно указать программе, чтобы пакет запускался на станции только один раз или более, причем на разных операционных системах и с различной загрузкой процессора.

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

Gartner считает, что по состоянию на конец 2004 года более 20% установленных серверов Windows все еще работают под NT. К этому сроку Microsoft прекратила поддержку данной операционной системы. Я думаю, что и наши читатели в той же пропорции оказались в аналогичной ситуации — когда технологии, которыми они располагают, уже устарели и приходится искать альтернативные методы распространения исправлений.

Надеюсь, что это не так. Хотя, принимая во внимание экономический фактор, приходится в это поверить. Пользователи не спешат с обновлением своих систем.

Мы сэкономили очень много времени. Сценарии могут составляться для каждого пользователя, каждого рабочего места и департамента, на все теперь уходит минут 10, тогда как раньше для этого требовались часы работы. Я могу создать профили для каждого департамента, а затем назначить эти профили пользователям. Что-то вроде Active Directory (AD) для NT. Даже после перехода на Windows Server 2003, где можно работать с групповыми политиками и AD, мы все еще используем ScriptLogic для автоматизации таких вещей, как настройки Outlook, принтеры, пути доступа и подключение сетевых дисков — то, с чем приходится иметь дело каждый день.