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

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

    AlienAqua windows update В первой части статьи я постарался рассказать о процессе управления обновлениями. Пора переходить к практике. В это статье я постараюсь описать механизм  взаимодействия Windows Software Update Services и Configuration Manager 2007.

    Для работы с обновлениями корпорация Microosft предлагает бесплатное решение Windows Software Update Services (WSUS). На момент написания статьи последней актуальной версией был WSUS 3 SP1.

    WSUS полностью самодостаточное решение, которое может удовлетворить потребности большинства организаций. Помимо прочего WSUS поддерживает иерархические отношений, таким образом можно централизованно управлять обновлениями, как в главном офисе, так и на филиалах.
    Развертывание и использование WSUS на предприятии очень хорошо описано и в официальной документации? и во многих статьях в интернете, поэтому я не буду заострять на нем внимание, а сразу же перейду к рассмотрению взаимодействия WSUS и Software Update в System Center Configuration Manager (SCCM).

    Подробнее о WSUS можно узнать:

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

    Для работы с обновлениями в SCCM нам необходимо:

    • • WSUS сервер, собственно обновления с сайта Microsoft Update закачивает именно он;
      • Software Update Point – роль Configuration Manager’а;
      • свободное дисковое пространство под обновления (в зависимости от количества обновляемых продуктов).

    Теперь о каждом пункте поподробнее.

    WSUS сервер – отвечает за синхронизацию обновлений в вашей локальной базе с базой на серверах Microsoft Updates. Кроме этого именно с сервером WSUS клиенты сверяют необходимый список обновлений.
    Software Update Point  – роль SCCM, отвечающая за то, какие именно обновления будут загружены с сайтов Microsoft, за передачу обновлений на клиенты и их запуск на установку.
    Дисковое пространство – Microsoft рекомендует использовать как минимум 20Гб том для обновлений. Размер тома будет очень сильно зависеть от количества обновляемых продуктов. Так, обновления безопасности Windows  XP, Vista, Server 2003, Server 2008 (All x32)  занимают у меня порядка 4Гб. Однако SCCM дублирует все обновления, закаченные WSUS. Таким образом, нам нужно резервировать  двухкратное место на диске. Файлы обновлений будут храниться как в базе WSUS, так и в базе SCCM.

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

    Общие моменты мы вроде бы прояснили. Давайте рассмотрим два самых распространенных сценария:
    1) у нас никогда не стояло никакой системы обновлений, мы решили установить SCCM;
    2) у нас успешно использовался WSUS, но мы хотим расширить его функционал за счет SCCM.

    Сценарий 1 – чистая установка

    Воспользуйтесь пошаговым руководством по установке WSUS и установите базовый сервер WSUS. При этом Microsoft рекомендует не проводить настройку свежеустановленного WSUS сервера – поскольку его настройки все равно будут затерты настройками из SCCM. Однако, я все предпочитают провести первоначальную синхронизацию WSUS с серверами Microsoft. Но только синхронизацию! Таким образом, мы можем удостовериться, что установка WSUS прошла успешно, что настройки связи не препятствуют работе механизма обновлений. Следует отметить, что если в вашей организации применяется прокси-сервер производства не Microsoft (например Squid), то при определенных сценариях, у вас могут возникнут проблемы с аутентификацией WSUS-сервера на вашем прокси-сервере. Во WSUS такую проблему можно решить, установкой галочки «Разрешить обычную проверку подлинности (пароль передается открытым текстом)». В SCCM произвести такую аутентификацию невозможно, поэтому вам придется изменить настройки прокси-сервера так, чтобы он пропускал запросы от сервера WSUS+SUP SCCM без аутентификации.

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

    acl wsus scr ip_adress_wsus_server

    http_access allow wsus

    Очень важно! Не одобряйте для установки обновления, ни настраивайте групповую политику, не предпринимайте никаких действий по настройке WSUS окружения, кроме установки сервера и первоначальной синхронизации. Иначе вы  рискуете получить нерабочее решение, ошибки в работе которого будет очень сложно отследить. SCCM для настройки использует локальную политику компьютеров, настраиваемую агентом SCCM автоматически.  Поэтому все упоминания о WSUS из групповой политики (Group Policy) необходимо удалить.

    Сценарий 2 – модернизация уже работающего WSUS сервера

    Если у вас уже существует WSUS инфраструктура, и вы просто решили ее расширить за счет SCCM, то выполните следующие действия:

    • • снимите все выставленные вами одобрения для обновлений;
      • удалите из групповой политики все настройки WSUS.

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

    Теперь оба наших сценария приведены к общему знаменателю – у нас есть рабочий, не настроенный сервер WSUS. Пора расширить его возможности за счет установки Software Update Point SCCM.

    Установка Software Update Point

    Запустите консоль SCCM. Выберите:
    Site Management – Site Code – Site Settings – Site Systems – New Server или Server-New Role
    в зависимости от того, установлен WSUS сервер на сервер SCCM или находится на отдельном сервере.

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

    Введите короткое и FQDN имя сервера. Если установка производится на отдельный сервер, и при этом учетная запись сервера SCCM не внесена на WSUS-сервере в группу локальных администраторов, то укажите учетную запись для установки «Use another account for install this site system».

    capture_04132009_161414 Рисунок 1 Выбор сервера для установки роли

    Указываем для установки роль “Software update point

    capture_04132009_161425 Рисунок 2 Выбор роли Software Update Point (SUP)

    Задаем используемые порты. Должны быть выбраны порты,  указанные при установке WSUS сервера.

    capture_04132009_161529 Рисунок 3 Используемые порты WSUS

    Выбираем иерархию. Поскольку наш сервер, высший в локальной иерархии, – указываем синхронизацию с серверами Microsoft. Так же указываем, будут ли наши клиенты посылать оповещения на WSUS сервер. Я обычно ставлю пересылку всех событий “Create all wsus reporting events”. Хотя "отчеты в SCCM даюn более полное представление о судьбе обновлений, иногда бывает полезным получить эту же информации из консоли WSUS.

    capture_04132009_161537 Рисунок 4 Выбор иерархии обновлений

    Задаем расписание синхронизации. Большинство обновлений Microsoft выпускает во второй вторник месяца, однако критически важные обновления могут быть выпушены внепланово. Если количество генерируемого интернет трафика два вас критично, то выставьте синхронизацию раз в месяц, каждую вторую среду. Я предпочитаю ежедневную синхронизацию.

    capture_04132009_161549 Рисунок 5 Расписание синхронизации

    Выбираем необходимые нам типы обновлений. Подробнее о классификации обновлений.

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

    capture_04132009_161557 Рисунок 6 Выбор загружаемых классов обновлений

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

    capture_04132009_161611 Рисунок 7 Выбор обновляемых продуктов

    Выбираем язык обновлений. Если все продукты в вашей системе русскоязычные выбираем только русский язык, иначе выбираем дополнительные языки. Не в коем случае не выбирайте не нужные вам языки – размер обновлений в таком случае будет очень сложно предсказать.

    capture_04132009_161621 Рисунок 8 Выбор языка обновлений

    Проверяем страницу summary, Next-Finish.

    capture_04132009_161628 Рисунок 9 Итоговая страница

    После этого проверяем настройки агента
    Site Management – Site Code – Site Settings-Client Afents – Software Updates Client Agents
    Главное для нас это галочка «Enable software updates on clients”, и интервал сканирования.

    capture_04132009_164707 Рисунок 10 Настройки агента SCCM

    На этом настройку Software update point можно считать законченной. Следует дождаться синхронизации с серверами обновлений Microsoft и после этого назначать обновления для клиентов.
    Кстати, рекомендую настроить  в WSUS отправку оповещений о новых обновлениях на e-mail. В консоли WSUs выбираем Параметры – Уведомления на e-mail
    В следующей статье я расскажу, о том, как работать с обновлениями, назначать их на коллекции, а пока рассмотрим механизм взаимодействия WSUS и SCCM.

    Механизм взаимодействия WSUS-SCCM

    За загрузку обновлений отвечает WSUS. Именно он связывается с серверами Microsoft, производит закачку необходимых файлов в папку WSUSContent. Именно из этой папки обновления будут скопированы в каталоги распространения (Deployment Packeg) SCCM. Следует отметить, что если одно и тоже обновление будет входить в несколько таких пакетов, то физически оно будет скопировано один раз, в остальных папках будет храниться ссылка на него.  Именно файлы обновлений из папок Deployment Packeg будут передаваться на клиентов.

    схема обновлений Рисунок 11 Схема взаимодействия WSUS и SCCM

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

    Установка обновлений происходит примерно по следующему сценарию:

    • • получение информации об  обновления на сервере WSUS и передача это информации в базу SCCM;
      • одобрение, загрузка и назначение на установку Администратором;
      • информирование пользователя о выходе обновления;
      • период, когда пользователь может установить или не установить обновление по своему выбору;
      • обязательная установка обновления, по наступлению времени принудительной установки(deadline).

    Два последних пункта могут отсутствовать, в зависимости от настроек распространения обновления.

    И так,  что делает WSUS:

    • • получает обновления от сайтов Microsoft Update;
      • по запросу клиента проводит выдачу информации о применимых к клиенту обновлениях;
      • запускает и устанавливает полученные от агента SCCM файлы обновлений.

    Что  делает SCCM:

    • • запускает процесс синхронизации WSUS с серверами Windows Update в интернете, при этом определяет какие классы обновлений и для каких продуктов необходимы;
      • предоставляет Администратору возможность управлять обновлениями: загрузка, одобрение, расписание установки;
      • запускает процесс синхронизации клиентского компьютера с базой WSUS, таким образом мы получаем сведения о необходимых для клиента обновлениях;
      • передает файлы обновлений на клиентские компьютеры, в зависимости от настроек распространения обновления (по запросу\принудительно);
      • запускает Update Agent на клиентских машинах для установки обновлений;
      • строит все отчеты относящиеся к Software Update (необходимые обновления, процесс установки, отчет об установке).

    Заключение

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

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

    MCP/MCTS: SCCM 2007

    altaranenco@gmail.com

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

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

      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 Configuration Manager 2007 – решение для автоматизации управления ИТ инфраструктурой предприятия

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

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

        Чем же интересен Confguration Manager для ИТ?

        Службе технического обеспечения, он будет интересен своими инструментами отчетов и инвентаризации. Больше нет необходимости бегать по этажам с бумажками и отслеживать передвижение планки памяти. Вся история обновления железа будет сохранена в базе. Вы всегда сможете четко сказать, сколько процессоров Pentium IV 3ГЦм установлено на ваших компьютерах.

        capture_03272009_112357

        Рисунок 1 Вид таблицы отчетов

        Техподдержка, больше не будет требовать купить себе Radmin. В SCCM входит функционал Remote managmetn, который использует три компонента для обеспечения удаленного управления: Remote Tools (набор драйверов и ПО обеспечивающих возможность удаленной работы наподобие Radmin\VNC), Remote Assistance и Remote Desktop. Кроме того, можно забыть о суматохе при смене ПО – теперь установка ПО на сотни компьютеров, требует трех щелчков мыши. Когда в следующий раз AOL снова сменит протокол, новая версия QIP будет установлена на компьютеры наших горячо любимых менеджеров в течение часа. При этом 10 минут вы будете ее скачивать, 5 интегрировать в SCCM, и оставшиеся 45 посвятите чтению сайта itband.ru, ожидая отчетов об установке.

        Даже ваш отдел мотивации труда будет рад – вы можете показать им отчеты, на которых будет видно, что 90% рабочего времени менеджеры играют в косынку.

        И это далеко не все возможности Configuration Manager.

        Чтобы вам легче было ориентироваться в дальнейшем, определимся с основными терминами, которые используются при работе с Configuration Manager.>

        Сайт SCCM (Site system) – группа серверов выполняющих роли SCCM.

        Central site – верхний primary-сайт в иерархии сайтов.>

        Primary site – группа серверов, которые используют для работы собственную базу данных

        Secondaryт site – группа серверов, которые используют для работы базу данных родительского сайта.

        Branch distribution> point – хотя это не отдельный сайт, а роль сайта, все же стоит отметить отдельно. Данная роль предназначена для упрощения обслуживания особо маленьких филиалов организации. В таких филиалах сеть может представлять из себя 3 компьютера в рабочей группе. В отличие от primary\secondary сайтов Branch DP может устанавливаться и на рабочие станции. Обладает функционалом только точки распространения программ\обновлений.

        Границы сайта – IP подсети, диапазоны IP адресов, сайты AD и IPv6 Prefix определяющие зону управления того или иного сайта.

        Коллекция (collection) – группа объектов (пользователи, компьютеры, группы безопасности) объединенная, по какому либо признаку. Именно над коллекциями производится большинство действий, таких как установка программ\ОС\обновлений.

        Роль SCCM (role) – компонент SCCM обеспечивающий выполнение определенной функции, например, такой как установка ПО или создание отчетов. Все роли могут быть совмещены на одном сервере, либо разнесены на отдельные сервера.

        Client Agent – определенный функционал клиентской части SCCM. Часть агентов может быть отключена.

        Функциональность SCCM можно разделить на три больших класса:

        Инвентаризация и отчеты

        • Инвентаризация аппаратного обеспечения (Hardware inventarization)
          Инвентаризация  программного обеспечения (Software inventarization)
          Слежение за используемым ПО и лицензиями (Asset Intelligence)
          Отчеты (Reporting)

        Развертывание приложений и ОС

        • Развертывание операционных систем (OS Deploy)
          Распространение ПО (Software distribution)
          Распространение и управление виртуализированным ПО (Application virtualization management)
          Управление обновлениями (Software update)

        Управление клиентскими устройствами

        • Мониторинг используемых программ (Software metering)
          Удаленное управление клиентами (Remote management)
          Управление мобильными устройства (Modile device management)
          Управление клиентами Intel vPRO (Out  of band management)
          Поддержка заданной конфигурации (Desied configuration manager)
          Защита подключающихся к сети (Network access protection)

        roleSCCM

        Рисунок 2 Роли сайта SCCM R2 2007

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

        SCCM  совместима с большинством ОС Microsoft. table legend

        Рисунок 3 Поддержка ОС в Configuration Manager 2007

        Рассмотрим по отдельности некоторые основные возможности.

        Установка ОС (OS Deploy)

        Как часто вам приходится устанавливать ОС на компьютеры? Я думаю, что большинство системных администраторов использует ту или иную технологию (RIS\WDS) для облегчения установки. OSD в SCCM позволяет облегчить весь процесс установки до одного простого действия: подключения в сеть и включения компьютера. Далее запуститься мастер установки SCCM и на компьютер будет последовательно развернуты: ОС из файла wim, все драйвера необходимые для работы компьютера, заданный набор программ и все самые свежие обновления безопасности. Я не могу сказать, что по сравнению с WDS SCCM  совершил революцию, нет, это скорее эволюция. То, что при использовании WDS было ранее невозможно или требовало от системного администратора много времени и сил, теперь стало доступно по двум щелчкам мыши.

        OSD_WinPE_1

        Рисунок 4 Приветствие мастера установки ОС в OSD

        Установка приложений (Software distribution)

        Иногда бывает так, что пользователям приходится менять свои компьютеры. У кого-то эта ситуация ярко выраженная, у кого-то менее. Довольно часто случаются курьезные ситуации в стиле башорга: «А перенесите мне мой старый монитор, там у меня на рабочем столе важная программа осталась!». Можно конечно подойти и поставить все вручную. Но нужно ли? SCCM позволяет назначать установку программ на коллекции. При этом установка будет происходить в фоновом режиме, поэтому пользователь пересевший за новый компьютер, на котором установлено только базовое ПО, в течение часа получит все программы которые ему назначены. Причем в этот момент он будет продолжать работать с почтой, просматривать интернет страницы или раскладывать косынку – т.е. полноценно работать, а не стоять у вас над душой с криком: «У меня отчет! У меня сроки горят!»

        Рассмотрим другую ситуацию: в компании жестко определены наборы приложений, которые используют те или иные группы пользователей. Когда пользователь переходит из группы в группу ему необходимо добавлять эти приложения. Конечно, можно было бы воспользоваться групповой политикой, но тогда весь комплект программ будет установлен пользователю сразу. Действительно ли это так необходимо? Или же лучше ставить программы по запросу? SCCM позволяет пользователям с ограниченными привилегиями самостоятельно устанавливать на своих компьютерах необходимые и ободренные администратором программы. Причем только вы решаете – будет это шаблонная установка, или вы позволите продвинутому пользователю пройти весь мастер установки самостоятельно.

        Или бывает так: в 17:45 вас вызывает к себе начальство и говорит, завтра в 9:00 утра на всех наших пятистах компьютерах должна быть новая супер программа от наших партнеров. Не правда ли, знакомая ситуация? Раньше в такой ситуации приходилось до ночи засиживаться в офисе. С помощью SCCM можно спокойно уйти домой в 18:00. А SCCM ночью централизованно включит компьютеры (с помощью технологии WakeOnLan) и установит все необходимые программы, после чего снова выключит их. По-моему, это гораздо лучше, чем засиживаться на работе? 😉

        capture_03272009_134433

        Рисунок 5 Выбор ПО доступного для установки

        Управление обновлениями (Software Update)

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

        В SCCM, в отличие от WSUS нельзя установить автоматическое одобрение обновлений. Все обновления должны быть предварительно одобрены администратором. Я считаю такой подход оправданным, все изменения в системе должны проходить предварительное тестирование. В моей практике бывали случаи, когда одно исправление способно нарушить работу бизнес приложений. Но это не означает, что управление обновлениями усложнено. Для действий над группами обновлений существуют листы обновлений (update list). Благодаря им, администратор может оперировать не отдельными обновлениями, а целыми списками, к примеру всеми критическими обновлениями выпущенными в последний «вторник».

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

        • позволить пользователям самостоятельно принимать решение об установке того или иного исправления;
        • дать время пользователю «подумать», а по истечении определенного срока установить обновление принудительно;
        • либо же сразу устанавливать обновление принудительно, в том числе автоматически включая компьютер с помощью WakeOnLan технологии ночью.

        capture_03272009_134342

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

        Решение для филиалов и удаленных клиентов

        В России структура средних и больших компаний такова, что их офисы отделены друг на тысячи километров и несколько часовых поясов. Причем линии связи между филиалами могут быть абсолютно разными. Начиная от выделенных оптических линий от магистральных провайдеров, заканчивая городской Wi-Fi которая имеет «приятное» свойство зависать во время дождя. Некоторые филиалы могут не уступать в размере и качестве подготовки обслуживающих их ИТ специалистов головному предприятию, а в некоторых на большое количество «манагерского» состава, будет всего один эникей, ну а некоторые филиалы будут довольствоваться тремя компьютерами в каком-нибудь промышленном пригороде, куда даже студента старшего курса не заманишь для обслуживания этого хозяйства. Мне пару раз приходилось устанавливать 1С с использованием радмина, через спутник. Я получил просто массу «удовольствия» и убил на это не один час. Если мы используем SCCM, то даже в самых отдаленных и маленьких филиалах сможем использовать его возможности. Где то это будет полноценный сайт, где-то secondary сайт,  ну а в особо маленьких филиалах компьютер секретаря будет использован как Branch distribution point.

        Лицензирование и цены

        Разумеется, в вводной статье нельзя не затронуть такую тему как лицензирование. Как и для большинства продуктов SystemCenter, для Configuration Server 2007 нам понадобиться покупка нескольких типов лицензий.

        Управляющий сервер (Management Server)

        Configuration Manager 2007 R2 Server
        Лицензия нужна для каждого сервера (site server) запущенного в физической или виртуальной среде. Так же отдельная лицензия нужна, на каждый узел NLB-кластера сервера SCCM.
        Вам не требуется дополнительно покупать лицензии Management Server, если любая из перечисленных ролей установлена на сервере, отличном от сервера с ролью Site server:

        • Configuration Manager Console
          Configuration Manager Client
          Device Management Point
          Custom Updates Publishing Tool
          Distribution Point
          Fallback Status Point
          Inventory Tool for Microsoft Updates
          PXE Service Point
          Management Point
          Reporting Point
          System Center Update Publisher
          Secondary Site Server
          Server Locator Point
          Software Update Point
          State Migration Point
          System Health Validator Point
          Configuration Pack

        Вам так же не требуется лицензия Management Server для сервера SQL (role site database server), на котором будет храниться база данных сайта SCCM.
        Хочу обратить особое внимание на Secondary сайты. Для Secondary-сайта не требуется дополнительная лицензия Management Server, поскольку secondary сайт работает с базой главного сайта.
        http://technet.microsoft.com/en-us/library/bb632547.aspx

        Серверные лицензии на управление (Management Licenses for Managed Servers)

        Configuration Manager 2007 R2 Enterprise Server ML
        Управление экземплярами серверного программного обеспечения с использованием DCM:
        Конфигурации IT Compliance и Governance
        Основной нагрузкой операционной системы
        Все другие утилиты операционных систем, нагрузки служб, а также любые приложения, работающие в лицензионных операционных средах.
        Configuration Manager 2007 R2 Standard Server ML
        Управление экземплярами серверного программного обеспечения с использованием Desired Configuration Management (DCM) (Управление заданной конфигурацией) основной нагрузки операционной системы, работающей в лицензированной операционной среде, а также управление любыми приложениями, работающими в этой операционной среде, которые не требуют использования DCM.

        «Основные нагрузки операционной системы» включают:
        следующие служебные программы операционной системы:  диспетчер системных ресурсов, служба уведомлений о смене пароля, анализатор безопасности Baseline Security Analyzer, службы надежности и доступности;
        нагрузки следующих файловых служб и служб печати:  сервер печати, распределенная файловая система (DFS), служба репликации файлов (FRS), сетевая файловая система (NFS), протокол передачи файлов (FTP) и службы Windows Sharepoint Services;
        нагрузки следующих сетевых служб:  распределенная служба имен DNS, протокол динамической настройки сети DHCP и служба имен Windows Internet Naming Service (WINS).

        Для каждой серверной операционной среды (среда OSE) на одном устройстве, которым необходимо управлять, требуется лицензия на управление серверами (лицензия ML).  Если у вас имеется более одной среды OSE, для такого устройства потребуется эквивалентное количество лицензий ML.  Для управления любым количеством сред OSE на одном сервере можно использовать одну лицензию System Center Server Management Suite Enterprise.  Кроме того, серверные лицензии ML разрешают управление средами OSE на рабочих станциях.
        Важно помнить, что любые варианты лицензирования управляемых или обслуживающих устройств — с помощью отдельных ML не влияют на необходимость лицензирования управляющих серверов, и тем более не отменяют эту необходимость.

        Клиентские лицензии на управление (Management Licenses for Managed Clients)

        Configuration Manager 2007 R2 Client ML
        Хотя серверные ML можно использовать для лицензирования не-серверных сред, это вряд ли оправдано экономически. Для лицензирования не-серверных сред, существует клиентская лицензия Client ML. Client ML бывает трех видов:
        Client ML — per OSE привязываются аналогично серверным ML — к каждой среде (OSE) в отдельности. Таким образом, отдельная лицензия требуется для каждой запущенной среды с не-серверной ОС. При этом такой тип лицензии позволяет управлять не-серверной средой вне зависимости от того, сколько пользователей использует эту ОС.
        Client ML — per user дает возможность лицензировать управление не-серверными ОС по количеству пользователей, которые используют эти среды. Клиентская лицензия на управление такого типа позволяет управлять всеми средами, которые используются лицензированными пользователями.
        Client ML лицензия, включенная в наборы Core CAL и Enterprise CAL. В этом случае, она позволяет управлять любым количеством не-сервеных сред для любого количества пользователей, то есть лицензируется на устройство (per device).

        Для примера возьмем среднюю организацию, в которой 10 серверов и 150 рабочих станций. При этом у организации два офиса – основной и дополнительный. В основном расположены 100 пользователей, в дополнительном 50. 5 топ-менеджеров  используют в свой работе КПК на базе Windows Mobile. Тогда для внедрения SCCM нам понадобятся следующие типы лицензий:
        -клиентские лицензии (Client ML) – 155 = 150+5
        -лицензии на управление серверами (Server ML) – 10
        -лицензия на SCCM R2 – 1
        Если каналы между офисами более-менее стабильны, то вы можете развернуть в дополнительном офисе Secondary сайт. При этом, стоимость лицензий не поменяется.

        licensing

        Рисунок 7 Схема лицензирования

        Цены

        Configuration Manager Server 2007 R2 ~ 580$
        Enterprise ML ~430$
        Standard ML ~ 160$
        Client ML  ~ 40$

        Подробнее о лицензировании:
        http://www.microsoftvolumelicensing.com/userights/Downloader.aspx?DocumentId=2084
        http://www.microsoft.com/systemcenter/configurationmanager/en/us/pricing-licensing.aspx

        Вместо заключения

        SCCM это очень мощное и красивое решение для автоматизации управления компьютерами организации. Но за кажущейся простотой и красотой административной консоли не должна дарить вам чувство эйфории. Как подчинить этого «монстра» я расскажу в последующих статьях.

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

        MCP/MCTS: SCCM 2007

        altaranenco@gmail.com