Главная System Center, Новое Управление обновлениями в System Center Configuration Manager 2007 (Часть 1)
  • Управление обновлениями в System Center Configuration Manager 2007 (Часть 1)

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

    В первой части статьи мы с вами рассмотрим непосредственно процесс управления обновлениями. Этот процесс одинаков для любых систем. Во второй части мы рассмотрим механизм взаимодействия Windows Software Update Services и System Center Configuration Manager, а также управление распостранением обновлений в Configuration Manager 2007.

    Я постараюсь  своими словами описать процесс управления исправлениями рекомендованный компаний Microsoft. Мой рассказ будет базироваться на Microsoft Operations Framework 4.0 (MOF) и Microsoft Solutions for Managment 2.5 (MSM).

    Подробнее о процессе изменения вы можете узнать, ознакомившись со следующими документами:
    Microsoft Solutions for Managment 2.5 (
    http://www.microsoft.com/technet/itsolutions/msf/ )
    Microsoft Operations Framework 4.0 (
    http://technet.microsoft.com/en-us/library/cc506049.aspx)
    Введение в MOF на русском (
    http://www.itsmonline.ru/itsm/dictionary/mof.php)

    Процесс управления обновлениями (исправлениями), который рекомендует применять Microsoft, был представлен в Microsoft Solutions for Managment 2.5 и основан на функциях управления MOF-службами:

    • • Change Management (управление изменениями);
      • Release Management (управление выпуском);
      • Configuration Management (управление конфигурацией).

    Данный процесс основан на моделях MOF и состоит из 4х стадий управления обновлениями ПО:

    • • оценки (Assess);
      • идентификации (identify);
      • оценки и планирования (evaluatr & plan);
      • развертывания (deploy).

    mofРисунок 1. 4 стадии процесса управления изменениями

    Процесс начинается со стадии оценки. Событием, вызывающим переход на стадию идентификации, является уведомление о том, что появилось новое обновление. Событием, вызывающим переход к оценке и планированию, является подача формального запроса на изменение (Request for change – RFC). Получение ободрение на развертывание обновления ПО в промышленной среде вызывает переход на стадию развертывание. Завершение выпуска обновления ПО и начало нового циклического процесса вызывает переход на стадию оценки.

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

    Предварительная подготовка к управлению исправлениями

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

    Для начала нам необходимо определиться с тем, какие компьютеры мы будем обновлять. Например, необходимо ли обновлять компьютеры, которые предназначены для списания или которые выведены в резерв и лежат на складе? Необходимо составить реестр ПО, для которого необходимы исправления. Если у нас не используется BizTalk сервер, то, соответственно, обновления для него должны быть исключены из процесса управления обновлениями.

    Большинство необходимых данных мы можем получить с помощью SCCM, но, как и говорил – технические подробности будут в следующей части статьи.

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

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

    Для всех компьютеров мы проверяем саму возможность установки исправлений. В нашем случае это будет развернутая инфраструктура WSUS+SCCM. С другой стороны это может быть просто и возможность ручной установки обновлений.

    Задача создания хорошо функционирующей системы обновлений является одной из самых сложных. Поскольку ошибки при проектировании этой структуры в дальнейшем могут вызвать не только необходимость ее переделки, но и неправильное применение обновлений, и как следствие возможную неработоспособность обновляемых компьютеров. При развертывании системы управления обновлениями, желательно предварительно максимально привести все системы к некоему базовому показателю. Например, если в вашей организации никогда раньше не устанавливались обновления, то желательно провести предварительную установку пакетов обновлений (service pack). Это позволит вам более-менее «выровнять» требования к необходимым обновления, а кроме того покажет узкие места. Например, установка Windows XP SP3 покажет, использовались ли у вас нелицензионные копии программ, а установка Windows Server 2003 SP2, на некоторых серверах вызывала проблемы с сетевыми картами.

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

    Рисунок 2. Инфраструктура обновлений

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

    Четырех фазный подход к управлению обновлениями

    Напомню, что процесс управления обновлениями ПО состоит из 4х стадий:

    • • оценки (Assess);
      • идентификации (identify);
      • оценки и планирования (evaluatr & plan);
      • развертывания (deploy).

    Внутри каждой стадии можно выделить этапы, которые характеризуют процесс управления исправлениями:

    Оценка(assess) – во многом схожа со стадией оценки выполняемой при подготовке к запуску процесса управления обновлениями.

    • • Инвентаризация/обнаружение существующих вычислительных активов

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

    • • Оценка угрозы безопасности и уязвимости

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

    • • Определение наилучшего источника информации о новых обновлениях ПО

    Определитесь с источниками информации об обновлениях и угрозах безопасности. Это могут быть различные сайты посвященные проблемам информационной безопасности, либо рассылка от производителя ПО. Например для Microsoft это может быть сайт http://technet.microsoft.com/ru-ru/security/default.aspx

    • • Оценка существующей инфраструктуры распространения обновлений

    Со временем ваша организация может изменять свою структуру. Структура системы обновления так же должна претерпевать изменения.

    • • Оценка эффективности работы

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

    Идентификация(Identify) – стадия, на который вы стараетесь получить максимум информации о выпушенном обновлении.

    • • Обнаружение обновлений ПО надежным способом

    Используйте только доверенные источники для получения информации об обновлении. Отчет о новых обновлениях правильно настроенного сервера WSUS– это доверенный источник, а письмо с адреса security@microsoftupdate.com с прикрепленным файлом обновления – нет.

    • • Определение применимости данного обновления к вашему ПО

    Определитесь, нужно вам это обновление. Далеко не каждое обновление обязательно для установки в промышленной среде. Например, не нужно устанавливать обновление, которое исправляет какие-либо дополнительные функции, которыми вы сейчас не пользуетесь, поскольку при этом вы рискуете работой бизнес-приложений. И пусть этот риск мал, но он есть. Кроме того, вы повышаете плоскость атаки на вашу Ит-структуру.

    • • Получение и проверка исходных файлов обновлений

    Ни при каких случаях не пользуйтесь недоверенными источниками обновлений. Да, сервер вашего регионального провайдера – это недоверенный источник. Доверенным источником обновления может быть только производитель обновления. Для обновлений Microsoft это сайт update.microsoft.com. И даже при использовании доверенных источников обновления – всегда проверяйте происхождение файла. Это можно сделать, например, проверив цифровые подписи файла.

    • • Определение характера обновления и задача запроса на изменение

    Для каждого обновления можно определить его критичность и область применения. С классификацией компании Microsoft можно ознакомиться по следующей ссылке. Команда, управляющая изменениями, должна принимать во внимание серьезность обновления, а так же структуру сети. И вот почему это важно делать: допустим, выпушено некое критическое обновление – исправляющее уязвимость которую использует червь для рассылки спама через 25 порт. Казалось бы, это очень важное исправление и его необходимо установить немедленно. Но если в вашей организации используются персональные и корпоративные фаерволы, которые запрещают трафик через 25 порт для всех компьютеров, кроме почтового сервера (а этот сервер построен на другой ОС, которая не подвержена данной угрозе), то конкретно для вас это исправление превращается из критического просто в необходимое. Соответственно его можно установить во время штатной установки обновлений, а не немедленно.

    Оценка и планирование (Evaluate & Plan) – после того как вами получена и обработана информация о новом обновлении, вы должны решить – применимо оно к вам или нет. Если вы готовы применить обновление, то вы переходите на стадию «Оценки и планирования»

    • • Планирование реагирования

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

    Приоритет

    Рекомендуется, в течение

    Максимально допустимый

    Критический 24 часов Неделя
    Высокий Неделя Месяц
    Средний Месяц Полгода
    Низкий Полгода В течение года, или при выходе очередного пакета исправлений, либо не внедряйте

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

    • • Планирование выпуска обновлений

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

    • • Создание выпуска

    Как только выпуск подготовлен, создан график внедрения, вы можете приступить к созданию пакета выпуска. Форма выпуска будет сильно зависеть от используемой системы обновлений. В случае SCCM это будут пакеты и задания на установку обновлений.

    • • Проведение приемо-сдаточных испытаний

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

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

    • Подготовка развертывания

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

    • Развертывание обновления ПО на целевых компьютерах

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

    • Анализ результатов внедрения

    Анализ проводится после успешного или не успешного релиза обновлений. Зачем же проводить анализ неуспешного релиза обновлений? Дело в том, что не всегда неуспешный релиз может потребовать откат обновления. Он может запустить новый 4х фазный процесс управления обновлениями, например если обновление как-то конфликтует с вашей бизнес-прогаммой, то возможно можно установить исправление уже для этой программы, которое исправит функционал.
    В любом случае, мы должны оценить были ли достигнуты поставленные цели (исправлена ли уязвимость), как это сказалось на работе ИТ-структуры в целом, что из нашей работы можно улучшить.

     

    Сегодня я постарался описать процесс управления обновлениями. К сожалению его нельзя упростить до одного абзаца, слишком много проблем может принести вам неправильная схема работы. Данная статья ни в коем случае не может быть инструкцией к применению. Если вы решите взять ее за шаблон – очень важно подогнать ее под свои потребности.
    В следующей статье я расскажу о том, как управлять обновлениями в Configuration Manager, а так же о том, как SCCM взаимодействует с WSUS.

    При подготовке статьи использовались:

    1. Steven D. Kaczmarek – Administrator’s Companion SCCM 2007
    2. Microsoft System Management Server 2003 – Качмарек С.Д. – пер. с англ. Microsoft Corporations

    Алексей Тараненко

    MCP/MCTS: SCCM 2007

    altaranenco@gmail.com

    • Рубрика: System Center,Новое
    • Автор: Алексей Тараненко
    • Дата: Tuesday 07 Apr 2009

Комментарии

  1. А что делать в самом начале? От одно

  2. А что делать в самом начале? От одной до трех тысяч обновлений насколько реально обработать руками?

    Да и после выхода новых редакций обновлений в рамках одно

  3. Если вы про первоначальное приведение инфраструктуры к некоему общему знаменателю, то как я уже говорил я рекомендую вначале установить последние сервис-паки. Как их ставить, решать только вам. Если у нас 1000 компьютеров, то естественно все их руками ставить никто не будет. Автоматизируйте это дело: хоть тем же WSUS+SCCM. Для каждой организации будет свой сценарий. Я просто акцентирую ваше внимание на том, что если у вас в организации обновления вообще не применялись, то при внедрении системы обновлений (абсолютно неважно какой) у вас, с большой долей вероятности, возникнут проблемы. Это как если бы человек голодал две недели, а потом ему дали шампур шашлыка – тут и помереть не долго.

  4. Внедряем сейчас SCCM 2007 R2, практически со всем разобрался, кроме интеграции с WSUS. Дело не в том, что я не знаю как это делать, а в том как это вписать в уже существующую схему.
    Есть центральный всус в центральном офисе, который качает апдейты с MS. Дальше специально обученный человек их просматривает и одобряет. После этого они скачиваются на подчиненные WSUS сервера и от туда расползаются по клиентам. Так как мы пока внедряем SCCM только в центральном офисе, возникают следующие ньюансы:
    1) центральный WSUS трогать нельзя, он должен работать как и прежде
    2) при необходимости можем поставить дополнительные downstream sus сервера в центральном офисе (на данный момент уже есть один дополнительный)
    3) в идеале, апдейты хочется подтверждать один раз.

    Как быть в таком случае? Пробовал ставить SUP на downsteam – ругается: SMS WSUS Synchronization failed.
    Message: WSUS server not configured.
    Source: CWSyncMgr::DoSync.
    The operating system reported error 2147500037: Unspecified error

    Если поставить чистый сервер и синхронизировать его с MS, то все ок. При попытке перевести на upstream – ошибки:
    SMS WSUS Synchronization failed.
    Message: Failed to sync some of the updates.
    Source: Microsoft.SystemsManagementServer.SoftwareUpdatesManagement.WSyncAction.WSyncAction.SyncUpdates.

    Второй день бьюсь… Или я хочу нереального?

  5. вот это вроде как победил…

    SMS WSUS Synchronization failed.

    Message: Failed to sync some of the updates.

    Source: Microsoft.SystemsManagementServer.SoftwareUpdatesManagement.WSyncAction.WSyncAction.SyncUpdates

  6. Дело в том, что SUP главного сайта SCCM должна быть настроена на WSUS который непосредственно связывается с серверами Microsoft.

    WSUS Configured as a Replica Server
    When creating the active software update point site system role on a primary site server, you cannot use a WSUS server that is configured as a replica of the upstream server. When the WSUS server is configured as a replica, Configuration Manager will fail to configure the WSUS server and WSUS synchronization will fail. When an active software update point is created on a secondary site, the WSUS server is configured to be a replica server for WSUS running on the active software update point at the parent primary site. For troubleshooting information, see Troubleshooting Software Update Point Configuration Issues.

    http://technet.microsoft.com/en-us/library/bb693886.aspx

  7. Что бы не ломать вашу структуру, могу предложить вам такой вариант:
    1)Поднимите новый WSUS сервер (SRV-WSUS), он будет синхронизироватся с серверами интернет напрямую
    2)Настройте SUP центрального офиса для раздачи обновлений,
    3)Уберите параметры обновления из групповой политики! Чтобы клиенты получили с локальной политикой адрес нового сервера (SRV-WSUS)
    3)Ваш старый WSUS (SRV-oldWSUS) будет теперь использоваться только для управления филиалами
    Затем, по мере перехода филиалов на схему работы с SCCM вы можете переориентировать их уже существующие сервера на ваш корневой (SRV-WSUS). Естественно первое время придется проводить двойную работу по одобрению обновлений.

    Честно признаюсь, схему такую не тестировал, но должно получится по идее 🙂
    Удачи!(с) One

  8. Спасибо, подумаем стоит ли сейчас это в таком виде запускать.
    Жаль конечно что появляется двойная работа – качать те же обновления и одобрять их. Интернет трафик в Москве нам фиолетов, ибо анлим, а вот в регионе такая вещь ощутилась бы.

  9. А почему двойной трафик? Ну в Москве будет, пока все WSYS’ы не переведете на SCCM. А в регионе всегда будет один трафик. Вы региональный WSYS не удаляете, просто когда филиал готов в переезду на SCCM, прописываете на этом филиале апстрим сервер не SRV-oldWSUS, а новый SRV-WSUS.

  10. > > В журнале Windows IT Pro/RE #7 2009 вышла моя статья о процессе управления обновлениями

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

    Заранее Спасибо,
    буду благодарен если просветите в этом вопросе

  11. Просто послал им письмо со статьей 🙂

  12. Алексей,

    письмо то наверное с уведомлением было? 😉

    Полагаю вопрос был, как и куда послали?
    На первую часть ответили, вторая наверное секрет

    Да и зачем, теперь все профи на ИТБэнд статьи шлют 🙂

  13. >Да и зачем, теперь все профи на ИТБэнд статьи шлют
    Разве ж это плохо 😉

  14. Все, да не все 🙂