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

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

  • определить, какие модули коррекции установлены;
  • предотвратить «засорение» каналов связи распределенной сети трафиком, связанным с передачей файлов исправлений;
  • обеспечить бесперебойное использование компьютеров конечными пользователями в период установки исправлений;
  • тестирование исправлений перед их развертыванием.

Мы будем говорить, прежде всего, о проблемах, связанных с управлением исправлениями для операционных систем и приложений Microsoft. Управление исправлениями для продуктов сторонних производителей без использования таких инструментов, как диспетчер Microsoft System Center Configuration Manager (SCCM) 2007, связано с еще большими затруднениями.

Какие модули коррекции уже установлены?

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

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

Службы WSUS «знают» лишь о тех исправлениях, которые были предоставлены с их помощью. У них нет возможности фиксировать исправления, полученные по другим каналам. Возьмем такой пример. В течение нескольких недель пользователь ноутбука работает вне офиса и в это время для исправления своего программного обеспечения использует не WSUS, а центр обновления Windows Update. Службам WSUS ничего не известно об этих модулях коррекции, ибо они располагают сведениями лишь о тех исправлениях, которые сами же и распространяют. Кроме того, WSUS обладают данными лишь по тем компьютерам, которые обращались к этим службам. Вполне возможно, что службам WSUS ничего не известно о компьютерах в вашей сети, которые по той или иной причине так и не сумели успешно связаться с сервером WSUS.

Ответить на вопрос о том, какие исправления установлены, можно с помощью двух бесплатно распространяемых продуктов. При этом вам не придется вручную проверять все компьютеры на предмет наличия интересующего вас исправления, и вы сможете обойтись без такого продукта, как SCCM 2007, приобретение которого может нанести серьезный удар по бюджету ИТ-подразделения. Первый бесплатный инструмент, который можно использовать для выявления исправлений, не установленных на компьютерах, — это анализатор Microsoft Baseline Security Analyzer (MBSA). Его можно загрузить на сайте Microsoft по адресу www.microsoft.com/mbsa. Новейшая версия MBSA 2.1.1 обеспечивает сканирование компьютеров Windows 7 и Windows Server 2008 R2. С помощью MBSA можно выявлять все отсутствующие исправления по списку, публикуемому Microsoft, или по списку исправлений, утвержденному на сервере WSUS. Было бы целесообразно реализовать функции MBSA в системе WSUS, чтобы развертывание исправлений и проверка выполнялись с одной консоли, но по состоянию на сегодня Microsoft не имеет планов объединения этих двух продуктов.

Вместо средства MBSA вы можете воспользоваться новой составной командой Get-Hotfix, реализованной в версии Windows PowerShell 2.0. Эта команда дает администраторам возможность локально или дистанционно опрашивать компьютеры на предмет того, какие модули оперативной коррекции на них установлены. С помощью сценария PowerShell вы можете, опрашивая компьютеры по списку, определять, установлено ли на них то или иное исправление или заданный набор исправлений. Пример: следующий сценарий осуществляет проверку всех компьютеров, перечисленных в файле computers.txt, и вносит имена компьютеров, на которых не установлен модуль оперативной коррекции с идентификатором KB974332, в текстовый файл с именем Missing-KB974332.txt:

get-content computers.txt | foreach

{ if (! (get-hotfix -id KB974332

-computername $_ -ea 0))

{ add-content $_

-path Missing-KB974332. txt }}]

Текст этого фрагмента сценария разбит на несколько строк, но на самом деле его нужно размещать на одной строке. Код -ea 0 задает параметру error action значение silent, так что в ходе выполнения команды текст ошибки не отображается.

Предотвращение «захламления» каналов связи

Организации развертывают решения, подобные WSUS, не только для централизованной установки исправлений, но и с целью минимизации объема трафика, связанного с получением исправлений через Интернет. Если обновление размером в 100 Мбайт нужно установить на тысяче компьютеров, совсем не обязательно загружать его из Интернета на каждый такой компьютер. Это может сделать один сервер WSUS, и затем он же распределит файл по всем компьютерам сети. Данный процесс работает превосходно, пока мы не принимаем во внимание удаленные офисы филиалов компании и перегруженные каналы распределенной сети. Итак, при прочих равных условиях загружать объемное обновление из Интернета на каждый компьютер по отдельности нецелесообразно. Точно так же нет смысла по отдельности передавать это обновление по каналам распределенной сети с недостаточной полосой пропускания с сервера WSUS в штаб-квартире компании на каждый из 100 компьютеров, расположенных в удаленном офисе филиала.

Службы WSUS можно настроить таким образом, чтобы они содержали только список утвержденных исправлений, но не сами файлы исправления, вследствие чего клиентам WSUS придется загружать файлы исправлений из Интернета. Но это будет означать, что все клиенты данного сервера WSUS, а не только системы, расположенные в офисах филиалов, будут «тянуть» файлы модулей коррекции с серверов исправления Microsoft. Во многих организациях эта проблема решается следующим образом. В офисе каждого филиала создается отдельный сервер WSUS, и клиенты офисов получают исправления со своих локальных серверов WSUS. Однако при добавлении серверов WSUS возрастают административные накладные расходы. Правда, серверы WSUS можно настроить по технологии upstream/downstream, но, как бы то ни было, всякий дополнительный сервер, включенный в инфраструктуру, так или иначе увеличивает издержки.

Решение для компьютеров удаленных офисов состоит в том, чтобы использовать новую технологию BranchCache в сочетании со средствами однорангового кэширования существующей службы Background Intelligent Transfer Service (BITS) системы Windows. BranchCache — новое средство для компьютеров, работающих под управлением систем Windows Server 2008 R2 и Windows 7 (версий Enterprise или Ultimate). Это средство позволяет клиентам удаленных офисов автоматически обмениваться друг с другом контентом, когда они получают его с соответствующим образом настроенного удаленного сервера. Одноранговое кэширование BITS — современная сетевая технология Windows. При использовании в сочетании с BranchCache она обеспечивает повышение эффективности передачи по сети модулей коррекции.

Настройка BITS и BranchCache выполняется через групповую политику. Политики BITS и BranchCache размещаются в узле Computer ConfigurationAdministrative Templates

Network объекта Group Policy. BranchCache можно использовать в сочетании с WSUS только в том случае, если роль WSUS установлена на компьютере, функционирующем под Windows Server 2008 R2, а клиентские компьютеры — под управлением версий Enterprise или Ultimate системы Windows 7.

Преимущество применения Branch­Cache и BITS в сочетании с WSUS состоит в том, что, организации могут с помощью одного сервера WSUS развертывать исправления в сетях главного и удаленного офисов, не перегружая каналы связи распределенной сети трафиком, связанным с передачей исправлений. Модули исправления считываются по каналу связи одним клиентом офиса и затем передаются на другие расположенные там же клиенты. Достоинство этого метода: удаленный офис как будто получает сервер WSUS, но без дополнительных административных расходов. Подробную информацию о BranchCache можно найти в статье Microsoft «Server Configuration» (technet.microsoft.com/en-us/library/dd637785(WS.10).aspx).

Обеспечение бесперебойной работы пользователей

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

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

Эффект внезапности установки исправлений можно несколько сгладить с помощью соответствующих групповых политик. Так, используя политику Enabling Windows Update Power Management to automatically wake up the system to install scheduled updates в сочетании с политикой Configure Automatic Updates, администраторы получают возможность настраивать системы на выход из состояния «сна» для установки исправлений в заранее указанное время. Данный метод обеспечивает «пробуждение» компьютеров для установки исправлений, скажем, в три часа утра, когда ни один из находящихся в здравом уме пользователей не должен работать с открытыми документами. Этот метод функционирует, если система BIOS поддерживает средства вывода системы из режима «сна».

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

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

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

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

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

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

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

Принять как неизбежное

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

Орин Томас (orin@windowsitpro.com) — редактор Windows IT Pro, имеет сертификат Windows Security MVP