Часть 2

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

Установка SUS в производственной среде

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

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

Для применения этого более сложного метода требуется подготовить два сервера SUS — назовем их SUSTest и SUSProd. Требуется настроить производственные компьютеры таким образом, чтобы они получали модули коррекции на сервере SUSProd. Необходимо отредактировать соответствующий объект групповых политик, который применим ко всем производственным компьютерам. Для этого нужно последовательно пройти по пунктам меню Computer Configuration, Administrative Templates, Windows Components, Windows Update, а в поле Set intranet update service for detecting updates ввести имя SUSProd. Затем следует создать еще один объект GPO, ассоциировать его с тестовыми компьютерами и ввести в поле Set intranet update service for detecting updates имя сервера SUSTest. Для проведения испытания корректирующей программы достаточно дать соответствующую санкцию на сервере SUSTest, после чего программа будет установлена на всех тестовых компьютерах. А убедившись в том, что данный модуль не представляет опасности и может быть развернут в более широкой среде, нужно зарегистрироваться на сервере SUSProd и санкционировать развертывание модуля.

Чтобы снизить вероятность ошибок (скажем, непреднамеренного санкционирования модуля на сервере SUSProd до получения соответствующего разрешения на сервере SUSTest), можно создать отдельные учетные записи пользователей, например SUSTestAdmin и SUSProdAdmin, и поместить каждого пользователя в группы Local Administrators на сервере SUS. Придет время, Microsoft внесет в службу SUS необходимые изменения, и администраторы получат возможность управлять с одного сервера как испытательной, так и производственной средой. Тогда можно будет средствами SUS обеспечивать такой порядок работы, при котором санкционирование развертывания модуля коррекции в производственной среде будет разрешено лишь при наличии санкции на его применение в тестовой среде. А пока нам придется довольствоваться методом с использованием двух серверов SUS — тем более что это очень неплохое решение. Тем, кому необходимо давать санкции на развертывание различных программ коррекции для используемых в рабочей среде компьютеров разных типов (серверов, рабочих станций, контроллеров доменов — DC), следует выделить различные SUS-серверы для каждого типа систем и настроить эти системы для получения модулей коррекции с соответствующего сервера SUS.

Несколько замечаний о пропускной способности

Передача модулей коррекции по каналам связи сети может обернуться снижением пропускной способности последних. К счастью, при разработке SUS специалисты Microsoft не оставили эту проблему без внимания. В процессе реализации службы SUS следует иметь в виду два обстоятельства, связанных с пропускной способностью. Во-первых, когда серверы SUS синхронизируют базы данных имеющихся в наличии модулей с серверами Microsoft Windows Update, это влияет на полосу пропускания канала связи с Internet. Во-вторых, когда клиенты AU загружают данные модули — с локальных серверов SUS или с сервера Windows Update, — снижается пропускная способность внутренней сети и соединения с Internet. Как первой, так и второй ситуацией можно управлять. Служба SUS всегда загружает каталог (т. е. список имеющихся в наличии модулей и их описания), но будет ли она при этом загружать на сервер SUS собственно исправления — решать администратору. Чтобы выбрать соответствующий вариант, нужно запустить браузер Microsoft Internet Explorer (IE), зайти на один из Web-узлов SUS, например на http://sustest/susadmin, и выбрать ссылку Set Options. В разделе Select where you want to store updates можно указать Maintain the updates on a Microsoft Windows Update server и ввести в поле Save the updates to a local folder имя локальной папки, в которой планируется хранить модули.

Указав настройку Maintain the updates on a Microsoft Windows Update server, вы избавляетесь от необходимости прогонять по каналам сети первоначальную порцию данных объемом в 500 Мбайт. Но если выбрать параметр Save the updates to a local folder, то в конечном итоге наверняка удастся снять остроту проблем, связанных с сокращением пропускной способности сети. Ведь по завершении первоначальной синхронизации каждый новый модуль придется загружать из Internet всего один раз — вне зависимости от того, на каком количестве компьютеров его нужно устанавливать или сколько серверов SUS имеется в сети. Правда, в подобной ситуации может встать вопрос о нехватке дискового пространства, поэтому я рекомендую использовать установку Maintain the updates on a Microsoft Windows Update server только в том случае, если в организации имеется множество филиалов и в каждом из них стоит лишь несколько компьютеров.

Представители Microsoft утверждают, что система SUS требует порядка 500 Мбайт дискового пространства в расчете на офис. А как быть, если в сети функционируют системы различных типов или имеется несколько серверов SUS, которые обслуживают тестовые и производственные фазы процесса развертывания программ коррекции? Если каждый сервер SUS будет загружать с серверов Microsoft одни и те же модули, это приведет к большой нагрузке на каналы связи с Internet. Поэтому лучше пойти по другому пути: выбрать настройку Select which server to synchronize content from. В этом случае сервер SUS будет синхронизировать каталоги и модули с содержимым другого сервера SUS внутри сети. К примеру, можно использовать параметр Synchronize directly from the Microsoft Windows Update servers при настройке сервера SUSProd и параметр Synchronize from a local Software Update Services server — при настройке SUSTest. В последнем случае в качестве имени локального сервера, с которым следует синхронизировать данные, необходимо указать имя SUSProd. Нужно настроить систему так, чтобы тестовый сервер SUS получал модули с производственного сервера, а не наоборот. Тогда производственная среда не будет зависеть от среды испытательной, что могло бы послужить причиной отказа. Даже если на тестовом сервере SUS возникнут какие-то проблемы, это не станет препятствием для выдачи санкций на использование модулей коррекции в производственной среде и их развертывание. Когда клиенты AU фиксируют появление нового модуля, они начинают загружать его с локального сервера SUS или с сервера Windows Update. При этом клиенты AU используют «интеллектуальную» службу передачи данных в фоновом режиме Background Intelligent Transfer Service (BITS), которая управляет загрузкой так, чтобы данный процесс не влиял на выполнение других задач в сети. С более подробной информацией о службе BITS заинтересованные читатели смогут ознакомиться по адресу: http://msdn.microsoft.com/library/default.asp?url=library/en-us/bits/bits/bits_start_page.asp. В комплект поставки Windows XP входит BITS 1.0, а в пакеты обновлений XP Service Pack 1 (SP1) и Windows 2000 SP3 — BITS 1.2. Если планируется ограничиться установкой клиента AU на компьютеры Windows 2000 (см. первую часть настоящей статьи), SUS тоже установит службу BITS.

Использование нескольких серверов SUS

С помощью нескольких серверов SUS можно обслуживать большое число клиентов и сокращать нагрузку на каналы связи между узлами. Представители Microsoft утверждают, что один сервер SUS на базе процессора Pentium III с тактовой частотой 700 МГц, оснащенный 512 Мбайт оперативной памяти, в состоянии обслуживать 15 тыс. клиентов. Если же количество клиентов превышает 15 тыс., могут понадобиться дополнительные серверы SUS. Для разделения клиентов на группы и для прикрепления соответствующего числа клиентов к каждому серверу SUS необходимы различные объекты групповых политик.

Рассмотрим такой пример. Допустим, организация со штаб-квартирой в Нью-Йорке имеет крупные офисы в Сан-Франциско и в Лондоне. Чтобы каждый расположенный в Сан-Франциско и в Лондоне клиент не «тащил» модули коррекции с сервера SUS в Нью-Йорке, т. е. через всю региональную сеть, можно организовать серверы SUS в каждом филиале. Достаточно ассоциировать с каждым узлом особый объект GPO, который при необходимости загрузки модулей коррекции будет обеспечивать обращение клиентов данного узла к локальным серверам SUS, и настроить серверы SUS в Сан-Франциско и в Лондоне так, чтобы они синхронизировали свое содержимое с содержимым сервера SUS в Нью-Йорке. После этого каждый модуль перед развертыванием в локальной сети будет передаваться по каналам WAN только один раз. Если желательно, чтобы администраторы каждого узла сами принимали решения о том, какие из модулей необходимо развертывать в сети, им нужно дать право санкционировать распространение тех или иных модулей на их локальных серверах SUS. Но если требуется, чтобы санкционирование модулей осуществлялось централизованно, лучше выбрать настройку Synchronize from a local Software Update Services server с именем сервера SUS в Нью-Йорке, а затем выставить флажки Synchronize list of approved items updated from this location (replace mode) (как показано на Экране 1) в настройках серверов SUS, расположенных в Сан-Франциско и в Лондоне. После этого, когда будет выдано разрешение на развертывание того или иного модуля на сервере в Нью-Йорке, другие серверы SUS тоже пометят его как получивший санкцию. Если каналы связи с Internet-офисов в Сан-Франциско и Лондоне загружены не так интенсивно, как линия WAN, связывающая их с офисом в Нью-Йорке, локальные серверы SUS могут загрузить из Нью-Йорка лишь список получивших санкцию модулей, а создающие нагрузку на линии связи коды модулей получить непосредственно по каналам Internet. Но если выставить флажок Synchronize from a local Software Update Services server, придется также выставить флажок Save the updates to a local folder. Впрочем, это ограничение не будет создавать проблем, поскольку после выполнения первоначальной синхронизации программы коррекции будут поступать небольшими порциями — по мере их выпуска.

Мониторинг операций загрузки и установки

После выполнения всех процедур, связанных с настройкой инфраструктуры SUS, самое время подумать об организации мониторинга этой службы. Администратор должен быть уверен в том, что новые модули своевременно загружены с серверов Microsoft, и знать наверняка, на каких компьютерах операция по установке этих модулей завершена успешно. Для отслеживания процесса синхронизации нужно выбрать пункт View synchronization log в меню Other Options. Как показано на Экране 2, в журнале синхронизации Synchronization Log отображаются все события синхронизации, осуществленные как в автоматическом, так и в ручном режиме. Кроме того, в журнале указывается, выполнила ли служба SUS загрузку программ коррекции, а если да, то каких именно. Наконец, журнал синхронизации извещает администратора о проблемах, возникающих при получении сервером SUS модулей коррекции с сервера Windows Update или с внутреннего сервера сети. Далее, выбрав в меню пункт View approval log, можно уточнить, развертывание каких именно модулей было санкционировано. Как показано на Экране 3, в журнале учета санкционированных модулей документируются все внесенные в список санкционированных модулей изменения, в том числе записываются сведения о том, когда и кем было сделано изменение, а также отображается список получивших санкцию модулей. Более подробную информацию о функционировании SUS и о диагностике можно получить в системном журнале Windows 2000 System log.

На Экране 4 показано, как может выглядеть журнал регистрации событий SUS. Полный список событий приведен в приложении В «Software Update Services Event Log Messages» к «белой книге» Software Update Services Deployment (http://www.microsoft.com/windows2000/ windowsupdate/sus/susdeployment.asp). События SUS содержат исключительно подробное описание событий, дополненное рекомендациями по действиям пользователя при возникновении того или иного события. Читатели, желающие ознакомиться со всеми событиями, которые могут регистрироваться службой SUS, найдут их перечень в приложении B упомянутого руководства по развертыванию.

Экран 4. Журнал событий SUS.

Для отслеживания процесса установки модулей коррекции на клиентах AU модули нужно сконфигурировать таким образом, чтобы отчеты об их функционировании передавались в регистрационный журнал Microsoft IIS на заданном сервере IIS. Журналы IIS обычно располагаются в каталоге winntsystem32logfilesw3svc1. Чтобы обеспечить передачу данных о функционировании клиентов AU от клиентов серверу IIS, необходимо последовательно выбрать в меню пункты Computer Configuration, Administrative Templates, Windows Components, Windows Update и задать для объекта GPO параметр Set the intranet statistics server (об этом рассказано в первой части статьи). Обычно в данной настройке в качестве принимающего отчеты сервера указывается тот же сервер SUS. Если же указать другой сервер ISS, придется скопировать файл wutrack.bin из папки Vroot Web-узла SUS в папку Vroot на другом сервере IIS. По завершении настройки клиенты AU начнут передавать отчеты о своих действиях с модулями коррекции в журнал регистрации указанного сервера IIS, выполняя URL-запросы к wutrack.bin. К сожалению, формат этих данных почти не поддается расшифровке; очевидно, что они предназначены не для глаз оператора, а для анализа с помощью программы. Надо сказать, что это серьезная недоработка, поскольку упомянутые сведения имеют чрезвычайно важное значение в процессе развертывания программ коррекции. Администратор может воспользоваться программой HFNetChk, но сканирование сети с помощью этого инструмента будет сопровождаться гораздо более интенсивным трафиком и потребует больше времени, нежели в случае, если бы система SUS была наделена надежным механизмом генерирования отчетов.

На Экране 5 приводятся данные по инициализации (&A=n), самообновлению (&A=s) и обнаружению (&A=d), переданные клиентом AU (10.0.0.41) серверу SUS (10.0.0.68). Разобраться в информации, которая содержится в регистрационном файле wutrack.bin, непросто, но надо сказать, что авторами руководства по развертыванию предпринята попытка разъяснить читателям смысл регистрационных записей (приложение C «Client Status Logging»). В журнале регистрации содержатся записи, отличные от сообщений wutrack.bin. Кроме того, в приложении C показано, как путем отключения функции регистрации на уровне Web-сайта и активизации регистрации только в файле wutrack.bin перевести IIS в режим регистрации исключительно сообщений wutrack.bin.

Экран 5. Данные по инициализации SUS.

Выполнять мониторинг операций по обработке модулей коррекции можно с помощью файлов \%windir%update.log, имеющихся на всех клиентах. Эти файлы регистрации содержат легко читаемые записи со сведениями о модулях. Как показано на Экране 6, компьютер направил на сервер Windows Update запрос на предоставление новых модулей, загрузил их, затем установил полученные модули и выполнил повторную инициализацию. Если системный администратор в настройках клиента указал, что получение модулей осуществляется с внутреннего сервера SUS, эта конфигурация найдет отражение в регистрационном журнале.

Пресечение несанкционированных действий

Скорее всего, администратор захочет принять меры к тому, чтобы пользователи не могли вмешиваться в процесс обработки службой SUS модулей коррекции и загружать с сервера Windows Update программы, не получившие санкции на развертывание. Взять подобные действия под контроль можно с помощью групповых правил. Достаточно выставить флажок Remove access to use all Windows Update features (доступ к нему осуществляется через пункты меню User Configuration, Administrative Templates, Windows Components, Windows Update) в настройках любого объекта групповых правил, и на всех компьютерах Windows XP, к которым применим данный объект, в приложении System панели управления Control Panel доступ к папке AU будет заблокирован. Однако упомянутая настройка не лишает пользователей Windows XP возможности применять функцию Keep your computer up-to-date with Windows Update приложения Help and Support Center и вообще не влияет на функционирование компьютеров Windows 2000. Чтобы заблокировать указанные возможности, следует выставить флажок Remove links and access to Windows Update (доступный через пункты меню User Configuration, Administrative Templates, Windows Components, Start Menu, Taskbar).

Получение извещений по электронной почте

Чтобы получать по электронной почте извещения о выпуске компанией Microsoft важнейших модулей коррекции для имеющихся продуктов, можно зарегистрироваться по адресу: http://go.microsoft.com/fwlink/?linkid=6931. Тем, кто подпишется на эту услугу, не придется ежедневно заходить на сервер SUS, чтобы выяснить, нужно ли давать санкцию на развертывание новых модулей. Ответ на этот вопрос предоставит служба электронного оповещения. Различие между такими оповещениями и службой рассылки бюллетеней по вопросам безопасности состоит в том, что последняя предусматривает извещения по всем проблемам безопасности для всех продуктов Microsoft. Что же касается службы почтовых извещений SUS, то ее подписчики получают информацию лишь по вопросам безопасности, имеющим отношение к SUS-совместимым изделиям (Windows XP, Windows 2000, браузер IE 5.0 и более поздних версий), а также по тем проблемам, для решения которых Microsoft выпустила важнейшие модули коррекции, устанавливаемые средствами SUS. Подписавшись на обе услуги, можно сразу же определиться, какие модули устанавливаются с помощью SUS, а какие — другими средствами.

Служба SUS не обеспечивает автоматическое применение к системам самых последних программных исправлений; она не совместима с другими продуктами Microsoft Office или Microsoft BackOffice. И все же использование данной службы в сочетании со средствами Software Installation групповых правил позволит администраторам, автоматически устанавливая самые современные пакеты обновлений и оперативные модули коррекции, поддерживать операционные системы на гребне технологической волны, а также избавиться от необходимости постоянно «латать дыры». Не следует забывать, что, после того как будет санкционировано развертывание модуля коррекции и служба SUS установит его, автоматически удалить этот модуль будет уже нельзя: SUS не располагает такими средствами. В групповой политике Computer ConfigurationWindows SettingsScripts (Startup/Shutdown) придется создать короткий сценарий запуска, удаляющий данный модуль, и развернуть этот сценарий на всех компьютерах, где он установлен.

Рэнди Франклин Смит — редактор Windows & .NET Magazine и президент компании Monterey Technology Group, которая занимается обучением и консалтингом в области защиты Windows NT. Связаться с ним можно по адресу: rsmith@montereytechgroup.com.