• Наши друзья

    • Рубрика: Новое
    • Автор: Алексей Тараненко
    • Дата: Wednesday 15 Apr 2009

    Хотим порекомендовать вам замечательный блог по продуктам виртуализации VMware

    Все о виртуализации от VMware

    VMware VI Wiki

    • Версия Схемы Active Directory

      • Рубрика: Windows,Новое
      • Автор: Илья Рудь
      • Дата: Tuesday 14 Apr 2009

      adТрудно недооценить важность «Схемы Active Directory»  для сетей, построенных на базе доменной среды Active Directory. Это основа технологии «AD» и очень важно правильно понимать принципы ее функционирования. Большинство системных администраторов не уделяют схеме должного внимания по причине того, что иметь дело с ней приходится достаточно редко. В данной статье я расскажу, что такое версия схемы, для чего нам необходимо ее знать и самое главное как посмотреть текущую версию. Прежде всего, пару слов о самой схеме, каждый объект, созданный в Active Directory, будь то пользователь или компьютер, имеет определенные параметры, называемые атрибутами. Самым простым примером может служить атрибут «Фамилия» у объекта пользователь. Схема определяет, какие объекты мы можем создавать в Active Directory, и какие атрибуты они будут иметь.

      Active Directory допускает использование в рамках одной организации несколько контроллеров домена, построенных на базе разных версий ОС Windows. А именно – на базе Windows Server 2000, Windows Server 2003, Windows Server 2003 R2, Windows Server 2008. Поскольку данные версии выпускались в разные годы, и каждая новая версия несет больший функционал, чем предыдущая, понимание схемы у каждой операционной системы свое. Поэтому при добавлении нового контроллера на базе Windows Server 2008 в организацию, где существующие контроллеры построены на Windows Server 2003, вам приходилось запускать утилиту «Adprep». Тем самым вы обновляли схему вашей организации до того уровня, с которым работает Windows Server 2008.

      Процесс обновления схемы выполнялся до установки первого контроллера Windows Server 2008 и собственно сама процедура установки нового контроллера, могла и не выполняться. Если вы только начинаете работать с какой-то организацией Active Directory и не знаете, какие действия осуществлялись до вашего прихода, вам для понимания полноты структуры, будет нужно знать, на каком уровне работает Схема текущей организации.

      Возможные версии схемы:

      13 – Windows 2000 Server
      30 – Windows Server 2003 RTM, Windows 2003 With Service Pack 1, Windows 2003 With Service Pack 2
      31 – Windows Server 2003 R2
      44 – Windows Server 2008 RTM

      Даже если все контроллеры в вашей организации работают на Windows Server 2003 R2, а версия схемы показывает «44» не стоит удивляться, это говорит о том, что уже было осуществлено обновление схемы до уровня Windows Server 2008 RTM, но сам контроллер по какой-то причине устанавливать не стали.

      Посмотреть версию схемы можно несколькими способами. Самым простым является способ с использованием утилиты «DSQuery». Для этого в командной строке необходимо ввести команду со следующими параметрами:

      “dsquery * cn=schema,cn=configuration,dc=domainname,dc=local -scope base -attr objectVersion”

      Естественно в части «dc=domainname,dc=local» вы должны подставить имя собственного домена. (Пример: dc=microsoft,dc=com)

      Результатом ввода команды является получение атрибута «ObjectVersion», который и будет являться номером версии схемы:

      image

      Рис. 1 Получение версии схемы через утилиту «DSQuery».

      Второй способ более длинный и подразумевает использование оснастки «ADSIEdit.msc». Для просмотра версии схемы вам придется подключиться к разделу Active Directory схема.

      "CN=Schema,CN=Configuration,DC=domain,DC=local"

      И найти значение атрибута "objectVersion".

      image

      Рис.2 Получение версии схемы через оснастку «ADSIEdit.msc».

      Зная версию схему, вы всегда можете с уверенностью сказать нужно ли схему обновлять и если нужно то, до какого уровня.

      Следует отметить, что обновления схемы могу производиться программным обеспечением тесно интегрированным с Active Directory. Самый яркий пример Microsoft Exchange Server. И зачастую в организации, планирующей внедрение Exchange Server, необходимо выяснить, была ли осуществлена подготовка схемы? И если была, то какой версией Exchange Server. На текущий момент существуют три версии Exchange, работающие с Active Directory, но вариантов модификации схемы существует шесть.

      Понять была ли изме
      нена Схема Active Directory Exchange сервером можно по атрибуту «rangeUpper», который принимает следующие значения:

      4397    – Exchange Server 2000 RTM
      4406    – Exchange Server 2000 With Service Pack 3
      6870    – Exchange Server 2003 RTM
      6936    – Exchange Server 2003 With Service Pack 3
      10628  – Exchange Server 2007
      11116  – Exchange 2007 With Service Pack 1

      Как можно заметить обновление схемы происходит и при установке набора обновлений SP3 для Exchange Server 2000/2003 и SP1 для Exchange 2007.

      Посмотреть значение атрибута «rangeUpper» можно через утилиту DSQuery:

      "dsquery * CN=ms-Exch-Schema-Version-Pt, cn=schema, cn=configuration, dc=domainname, dc=local -scope base -attr rangeUpper"

      image

      Рис. 3 Получение атрибута «rangeUpper» через утилиту DSQuery.

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

      Процесс обновления схемы является очень важным моментом для каждой организации Active Directory, поэтому следует избегать лишних, неоправданных действий. Понимая сути атрибутов «objectVersion» и «rangeUpper» дает специалисту преимущество при работе с Active Directory в незнакомой организации, а также является вспомогательным инструментом при решении проблем.

      MCT\MCSE

      Рудь Илья

      me@rudilya.ru

      • Виртуальные машины и сети

        • Рубрика: Virtualization,Новое
        • Автор: Александр Косивченко
        • Дата: Monday 13 Apr 2009

        vn-4Для грамотного управления виртуальной инфраструктурой необходимо иметь представление о том, как организуется сетевое взаимодействие виртуальных машин между собой, с хостовой ОС (parent partition в терминологии MS), и с самой локальной сетью. В этой статье я постараюсь объяснить в меру своих возможностей тонкости работы виртуальных машин с сетью. Тем, кто уже работал с другими платформами виртуализации (VMWare, Virtual Server, etc.) все, о чем я буду писать, скорее всего, уже известно, тем не менее, на уровне терминологии вполне возможны некие различия.

        • Управление обновлениями в 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

          • Пока гром не грянет…

            • Рубрика: Windows,Новое
            • Автор: Александр Косивченко
            • Дата: Thursday 09 Apr 2009

            pesets

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

            • Управление обновлениями в 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

              • Юридические аспекты информационной безопасности

                • Рубрика: Security,Новое
                • Автор: Владимир Безмалый
                • Дата: Tuesday 07 Apr 2009

                law Сегодня я хотел бы поговорить с вами о весьма волнующей меня проблеме. Думаю, что в  большинстве предприятий весьма и весьма актуальной является задача контроля электронной переписки своих сотрудников. Тема не простая. Обеспечить ее техническими средствами, создав архив входящих/исходящих писем и обеспечив его целостность, не так уж и сложно.
                Однако здесь мы с вами упираемся в законность своих пожеланий, а именно. Конституция Украины гарантирует тайну переписки. Заметьте, не частной, а переписки вообще! Что это значит для нас с вами?
                Формально – мы не можем читать почту сотрудников, так как нарушаем Конституцию. Более того, даже если вы обнаружите доказательства преступлений, то формально это доказательством не является, ведь добыто с нарушением закона. Что делать?
                На разных форумах предлагают брать расписки с сотрудников, о том, что они не возражают против чтения электронной почты. Простите, но охарактеризовать это другим термином кроме БРЕД, причем в тяжелой форме, я не могу! В любой момент сотрудник может отказаться  от этой бумаги, а так как вы нарушаете Конституцию, то виноваты вы! Это однозначно и в дополнительных доказательствах не нуждается!
                Однако, а что же все таки делать? Вразумительного ответа украинские, впрочем, и российские юристы, увы, не дают!
                На мой взгляд, можно в инструкции при приеме на работу указывать, что вся информация, обрабатываемая на компьютерах фирмы информация принадлежит фирме, а следовательно, руководство компании может в любой момент времени ознакомиться с этой информацией само или поручить это соответствующему сотруднику.
                Таким образом, в любой момент времени компьютер ЛЮБОГО сотрудника может быть изъят на проверку. Соответственно, просмотрено может быть содержимое электронного почтового ящика любого сотрудника.
                Так как информация принадлежит фирме, то и просматривать СВОЮ информацию руководство может в любой момент времени. А вы как считаете?

                • Восстановление контроллера домена Active Directory в Windows Server 2008 (Часть 1)

                  • Рубрика: Windows,Новое
                  • Автор: Илья Рудь
                  • Дата: Monday 06 Apr 2009

                  ad   В предыдущей статье я рассказывал, как правильно восстанавливать удаленные объекты Active Directory. Сейчас хотелось бы поговорить о полном восстановлении контроллера домена Active Directory, ведь зачастую проблемы системных администраторов гораздо более сложные, чем потеря одного объекта. Угрозу стабильности может представлять вирусная активность, испортившая реестр на контроллере, вышедший из строя жесткий диск, на котором хранились системные файлы, полная или частичная потеря папки SYSVOL c групповыми политиками. Этот страшный список можно продолжать.

                  Поскольку на дворе 2009 год речь пойдет о контроллерах домена под управлением Windows Server 2008, благо восстановление предыдущей версии ОС описано неоднократно. Начнем.

                  Первое, что бы должны хорошо уяснить, знакомой утилиты NTbackup уже нет, на смену ей пришло новое решение ” Система архивации данных Windows Server “. Это именно новое решение, а не обновленный NTbackup. Также с Windows Server 2008 поставляется новая утилита командной строки Wbadmin.exe, она расширяет и дополняет возможности графической “Системы архивации данных Windows Server “.

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

                  Организация первая: Один сервер.

                  Довольно распространенное явление. Фирма имеет небольшое количество компьютеров, как правило, до 30-40 и в сети присутствует единственный сервер под управлением ос Windows Server 2008. Он же и является контроллером домена Active Directory, вдобавок несет на себе роль файлового сервера и возможно некоторые сетевые приложения. Да у Microsoft есть рекомендации говорящие о том, что любая организация Active Directory должна иметь как минимум два контроллера домена и сам контроллер не должен иметь дополнительных ролей. Но будем смотреть правде в глаза, в малом бизнесе фирм с одним сервером очень и очень много. Как же будет выглядеть система восстановления в такой ситуации?

                  Прежде все давайте сразу определимся. Наш сервер должен иметь минимум два раздела на жестком диске, а в идеале два раздела на RAID массиве. Объясню почему, “Система архивации данных Windows Server ” осуществляет резервное копирование только разделов (есть одно исключение, но о нем позже), выбрать резервное копирование одной или нескольких папок мы не можем.

                  Поэтому:

                  1) Раздел 1 будет содержать – Операционную систему Windows с реестром, файлы загрузки, включая файл Bootmgr, базу данных Active Directory (Ntds.dit), журналы базы данных Active Directory и папку SYSVOL с групповым политиками.

                  2) Раздел 2. Второй раздел будет использоваться под хранение резервных копий.

                  Примечание: У нас есть возможность создавать резервные копии на:

                  а) Раздел жесткого диска (то, что я и предлагаю)

                  б) На сетевом ресурсе,

                  в) DVD-дисках.

                  Microsoft рекомендует хранить резервную копию на внутреннем или внешнем жестком диске.

                  Будем считать, что наш сервер был установлен, следуя вышестоящей рекомендации.

                  Теперь давайте посмотрим, как застраховаться от непредвиденного “падения” сервера. Используем Windows Complete PC Restore.

                  1. Для начала необходимо установить программу “Система архивации данных Windows Server “. К сожалению, в борьбе за минимальный набор устанавливаемых По-умолчанию компонентов система архивации проиграла и изначально не стоит. Я считаю это правильным решением, те, кому она нужна, ее установят, а люди, использующие сторонние решения, сэкономят немного ресурсов. Установка идет по классическому сценарию для Windows 2008 через “Диспетчер Сервера”

                  image

                  Рис. 1 Установка системы архивации

                  2. После установки системы архивации нам необходимо настроить расписание задачи, которая будет делать архивную копию нашего Раздела 1 (Напоминаю на нем находится Windows Server 2008 и Active Directory ). Я предлагаю делать такой архив раз в неделю в воскресенье, дальше вы поймете почему. Для этого запускаем оснастку “Системы архивации данных Windows Server ” и запустить расписание архивации.

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

                  image

                  Рис.2 Запуск расписания Архивации

                  После этого пропустить приветствие и нажать “Далее”. Перед нами встанет выбор, как осуществлять резервное копирование (Весь сервер или настраиваемый). Поскольку в наш архив должен попадать только Раздел 1, мы выбираем “Настраиваемый”.

                  image

                  Рис.3 Выбор конфигурации архивации.

                  После открывается список разделов нашего сервера на котором мы должны снять “галочки” на всех разделах кроме того который содержит нашу систему. (В статье он называется Раздел 1)

                  image

                  Рис. 3 Выбор разделов.

                  Выбрав, что бы будем архивировать, переходим к настройке расписания. Из данного окна тонко настроить расписание задачи мы не сможем, поэтому выбиваем время Ежедневно 21:00. В дальнейшем мы изменим это расписание.

                  image

                  Рис.4 Расписание.

                  image

                  Рис. 5 Выбор места хранения резервной копии

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

                  image

                  Рис. 6. В Процессе форматирования.

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

                  image

                  Рис. 7 Планировщик Заданий

                  Теперь заходим в свойства задачи и меняем расписание. Нам нужно сделать запуск задачи “Ежевоскресной”

                  image

                  Рис. 8 Измененное расписание

                  Подведем итог. Теперь каждое воскресенье в 21:00 на отдельный раздел жесткого диска будет делаться резервная копия нашего “Раздела 1” содержащего системные файлы и базу Active Directory. В случае падения вашего сервера вы всегда сможете его восстановить. Это и есть Windows Complete PC Restore. Только не забывайте, время от времени переносить архивы для хранения за пределы вашего сервера и серверной, дабы не остаться в случае пожара или других крупных неприятностей без сервера и архива одновременно.

                  Перейдем к этапу восстановления.

                  Запустить восстановление сервера, мы можем несколькими путями, самый простой взять установочный диск Windows Server 2008 и загрузиться с него. На этапе приглашения к установке, необходимо выбрать “Восстановление системы”. После чего будет запущена среда “Windows RE” .

                  image

                  Рис. 9 Запуск процесса восстановления.

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

                  image

                  Рис.10 Выбор ОС

                  image

                  Рис.11 Запуск Windows Complete PC Restore.

                  Остается запустить “Восстановление архива Windows Complete PC Restore “. После запуска он предложит нам самую свежую копию архива. Если вы не планируете использовать последний архив, выберите “Восстановить другой архив”. У меня такая задача не стоит, и я выбираю последний доступный.

                  image

                  Рис.12 Этап выбора архива.

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

                  image

                  Рис.13 Процесс восстановления.

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

                  Некоторые из вас могут сказать “Все это здорово, но как быть в ситуации, если сервер сломался в пятницу, а ближайшая копия пятидневной давности. Что будет с новыми пользователями созданными в течении недели? и.т.д”

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

                  Это конечно личное дело каждого, но на текущий момент мне кажется правильным следующее:

                  1.Если ваш системный раздел содержит только операционною систему и базу Active Directory c системными файлами, то создание ежедневной копии системного раздела является оптимальным.

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

                  Архив состояния системы. Тут главное не путать архив раздела и состояние системы. Состояние системы это архив самых важных для операционной системы вещей.

                  В нашей ситуации в него попадут:

                  • Системный реестр
                  • База данных регистрации класса COM+
                  • Файлы загрузки
                  • База данных доменных служб Active Directory
                  • Папка SYSVOL
                  • Системные файлы, защищенные с помощью средства защиты ресурсов Windows

                  Соответственно используя этот набор вы можете восстановить ваш сервер, если произошло повреждение вышеперечисленного. А также выполнить восстановление базы Active Directory в актуальное состояние. Но при полностью уничтоженном сервере только “Состояния системы” будет явно недостаточно. Как минимум потому, что “Состояния системы” контроллера можно восстановить только через “Режим восстановления службы каталогов”, т.е сервер должен в нем загрузиться.

                  При этом хотелось бы заметить, что Архив состояния системы со времен Windows 2003 сильно изменился. Если в Windows 2003 он весил порядка 600-700 мегабайт, то создав его в Windows 2008, вы будете сильно удивлены размером в 9 гигабайт. Это происходит за счет включения в архив дополнительных файлов системы. Разница в размерах между архивом раздела и архивом состояния системы  будет видна, если у вас на системном диске хранятся какие-то дополнительные файлы.

                  Осуществить создание состояния системы можно только из командной строки используя утилиту Wbadmin.exe

                  Синтаксис будет следующий:

                  wbadmin.exe start systemstatebackupbackupTarget:Z:

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

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

                  Путь: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\wbengine\SystemStateBackup\
                  Ключ: Name: AllowSSBToAnyVolume
                  Data type: DWORD
                  Value data: 1

                  image

                  Рис.14 Создание состояния системы

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

                  Сценарий первый. У нас полностью вышел из строя системный раздел и операционная система не загружается. Для восстановления нам придется пройтись по описанной выше процедуре и вернуть наш раздел с системой в рабочее состояние. Естественно для этого будет использоваться загрузочный дистрибутивный диск Windows Server 2008 и последний воскресный архив. Когда этот этап восстановления окончится, будет необходимо перезагрузиться в особый режим работы контроллера домена под название “Режим восстановления службы каталогов”.

                  В этом режиме служба Active Directory Domain Services основлена и мы сможем воспользовавшись архивом со свежим состоянием системы обновить базу AD до актуального. (например пятничного).

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

                  Для начала перезагружаем наш контроллер домена в режим восстановления службы каталога (DSRM), при этом помним, что для входа на контроллер домена в этом режиме нам нужно знать пароль администратора DSRM режима. (Вы задавали его при поднятии контроллера домена). Для выбора этого режима при запуске компьютера жмем “F8

                  image

                  Рис.15 Загрузка в DSRM

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

                  wbadmin.exe get versions

                  Найдя нужное состояние системы копируем “Идентификатор версии”. В моей ситуации он выглядит как “04/05/2009-13:49“. Идентификатором является дата и время создания архива. (Рис.16)

                  image

                  Рис.16 Поиск нужного архива состояния системы.

                  Теперь мы готовы запустить восстановление состояния системы.

                  Выполняем команду: wbadmin start systemstaterecovery -version: 04/05/2009-13:49

                  image

                  Рис.17 Процесс восстановления состояния системы.

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

                  А теперь давайте подведем итоги:

                  Мы рассмотрели процесс восстановления контроллера домена Active Directory на базе Windows Server 2008 в ситуации когда этот контроллер единственный в сети.

                  Для того чтобы спать спокойно, вам будет необходимо:

                  1. Выделить раздел жесткого диска под резервные копии.

                  2. Создать расписание создания архива раздела с установленной системой. (Выполнение еженедельно)

                  3. Создать пакетный файл с командой “wbadmin.exe start systemstatebackupи запускать его с помощью планировщика ежедневно. (Кроме дня, когда запускается создание архива системного раздела)

                  4. Держать под рукой дистрибутивный диск с Windows Server 2008.

                  5. Помнить пароль администратора “Режима восстановления службы каталогов”

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

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

                  Рудь Илья

                  MCSE/MCT

                  me@rudilya.ru

                  • Эксперимент: Виртуализация и виртуальные жесткие диски

                    • Рубрика: Virtualization,Новое
                    • Автор: Александр Косивченко
                    • Дата: Wednesday 01 Apr 2009

                    Безымянный  Довольно часто, в системе “слабым местом” оказывается дисковая подсистема, что вполне понятно: ведь быстродействие жесткого диска всегда намного меньше, чем оперативной памяти или процессора. При виртуализации же, когда несколько виртуальных машин используют один и тот же жесткий диск (или массив) – вопрос быстродействия встает особенно остро.

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

                    Рассмотрим работу с жесткими дисками в среде Hyper-V.

                    1. VHD-файлы

                    Наиболее известный способ, выбираемый по дефолту: использование в качестве дисков для виртуальной машины – файлов *.vhd (Virtual Hard Disk). Этот способ имеет три преимущества:

                    • VHD-файлы могут храниться где угодно и могут быть легко перемещены;
                    • Удобство создания резервных копий: копирование одного большого файла – намного легче и быстрее, чем копирование всего содержимого жесткого диска (VHD-файл может быть легко скопирован средствами VSS, без остановки самой виртуальной машины, а в случае бэкапа содержимого физического диска – может потребоваться перезагрузка как минимум гостевой ОС);
                    • Рациональное использование дискового пространства: на одном физическом диске может храниться множество VHD-файлов, и каждой виртуальной машине можно отвести ровно столько дискового пространства, сколько ей необходимо

                    Минус – один: меньшее быстродействие по сравнению с прямой работой с диском. Далее будет показано наглядно.

                    2. Прямое обращение к физическому диску

                    Hyper-V, помимо использования VHD-файлов – предоставляет возможность использования виртуальной машиной физических дисков. Плюс тут один: более высокое быстродействие в сравнении с VHD-файлами. Минусов же больше:

                    • Немного сложнее создавать резервные копии и переносить информацию в другое место;
                    • Менее рациональное использование дискового пространства (весь объем диска используется одной виртуальной машиной, не может регулироваться динамически и распределяться между несколькими виртуалками);

                    Ну а теперь – перейдем от теории к практике.

                    Эксперимент.

                    В качестве экспериментального стенда использовался сервер HP ML150G5, снабженный четырёхъядерным процессором Intel® Xeon® E5420 2,5 ГГц и 4Гб оперативной памяти. Дисковая подсистема представлена двумя дисками объемом 72Гб с интерфейсом SAS, объединенными в массив RAID1 и двумя SATA-дисками объемом 250Гб, так же объединенными в RAID1. На сервере установлена ОС Microsoft Windows Server 2008 Std. 64bit с поддержкой Hyper-V. Других задач, помимо виртуализации у него нет. Далее – все эксперименты, о которых я буду писать в этом блоге – будут проводиться именно на этом сервере.

                    Для чистоты эксперимента все действующие ВМ были остановлены, и создана новая ВМ с 512Мб ОЗУ и двумя жесткими дисками: один – для установки гостевой ОС, другой – для эксперимена. На ВМ была установлена ОС Microsoft Windows Server 2003 32bit, были установлены компоненты интеграции. Для создания нагрузки на диски и измерения параметров быстродействия была использована бесплатная утилита IOMeter. Параметры доступа к диску в IOMeter были заданы следующие:

                    • Объем страницы: 64Кб;
                    • 75% – случайный доступ, 25% – линейный;
                    • 75% – чтение, 25% – запись.

                    Опыт первый: VHD-файл.

                    Как я уже писал выше, экспериментальная ВМ имеет два виртуальных жестких диска: на один устанавливается ОС, другой – используется для измерения быстродействия. В первом моем опыте я использовал VHD-файл фиксированного размера 10Гб. Файл размещался на зеркале из двух 250Гб SATA-дисков. Я получил следующие результаты:

                    • Total I/O per sec: 111,5
                    • Total MB per sec: 6,92
                    • Average I/O Response Time: 9,0152 ms
                    • Maximum I/O Response Time: 526,0630 ms

                    Результаты сильно удручают: 7Мбайт в секунду – это очень и очень мало. Для примера, в хостовой ОС, копирование файла с одного массива на другой показывало скорость порядка 37-40Мбайт/c. Правда, это показания самой ОС, которые могут и не соответствовать действительности. Увы, судя по сайту разработчиков – последняя версия IOMeter’а вышла 27 июля 2006 года, так что не удивительно, что под Windows Server 2008 она хоть и запустилась, но корректно не работала: она просто не “видела” жесткие диски. Если кто-нибудь посоветует мне более новую утилиту, аналогичную IOMeter и нормально работающую под Windows Server 2008 – с меня пиво 🙂

                    Время отклика – тоже очень и очень плохое: 9 миллисекунд в среднем, и 526 миллисекунд (просто вдумайтесь в это: больше, чем пол-секунды!) максимум. Вобщем – для, к примеру, веб-сервера вполне бы сгодилось, но устанавливать с таким быстродействием, к примеру, сервер БД какой-нибудь ERP-системы я бы не рискнул.

                    Опыт второй: прямое обращение к диску.

                    Теперь я удалил злосчастный VHD-файл и перевел наш 250Гб массив в режим Offline через консоль Computer Management (это – необходимое условие, чтобы Hyper-V “увидела” наш диск и его можно было бы подключить к ВМ). После этого – в свойствах тестовой ВМ вместо VHD-файла был подключен наш физический диск и так же – запущен IOMeter c теми же параметрами. Результаты получились следующие:

                    • Total I/O per sec: 126,7
                    • Total MB per sec: 7,9
                    • Average I/O Response Time: 7,9362 ms
                    • Maximum I/O Response Time: 96,1755 ms

                    Сказать честно – результаты меня удивили. Я не ожидал такой маленькой разницы в iops и в mbps. Чем это вызвано – самому интересно. Вполне возможно, что здесь мы уперлись в потолок быстродействия SATA-дисков. А вот время отклика уже – намного лучше: 8 миллисекунд в среднем и 96 в максимуме, против 9 и 526 соответственно. Как видно, среднее время отклика улучшилось ненамного, возможно, что не улучшилось и вовсе: одна миллисекунда вполне укладывается в погрешность измерения. А вот максимальное время отклика – уменьшилось почти в 60 раз, что не может не радовать.

                    Вывод.

                    Из всего этого напрашивается следующий вывод: если планируется виртуализировать какие-либо задачи, требующие активного доступа к дискам – нужно использовать прямой доступ к диску. Во всех же остальных случаях я настоятельно рекомендую использовать, как и обычно, VHD. В случае, если использование прямого доступа необходимо – “соломоновым решением”, наверное, будет использование двух виртуальных дисков у одной ВМ: один – в виде VHD – для установки ОС и приложений, а другой – с использованием прямого доступа – для хранения данных.

                    P.S. У меня имеются подозрения, что на эксперимент сильно повлиял потолок быстродействия SATA-дисков. Недавно у нас в распоряжении оказалась дисковая полка HP MSA2000 с интерфейсом SAS. Завтра – попробую подключить эту полку к серверу, собрать на ней RAID10 и повторить эксперимент. О результатах – обязательно отпишусь. Оставайтесь на канале!

                    Александр Косивченко

                    • Использование в работе «GP Preferences»

                      • Рубрика: Windows,Новое
                      • Автор: Илья Рудь
                      • Дата: Wednesday 01 Apr 2009

                      sec21 На современном этапе у компании Microsoft есть продукты и технологии, которые становятся козырной картой в игре за внимание пользователей и администраторов. Одним из «джокеров» является технология групповых политик, позволяющая достаточно просто и эффективно управлять тысячами windows-компьютеров. Корпорация Microsoft это прекрасно понимает и с каждой версией новой операционной системы увеличивает количество параметров доступных для конфигурирования через GP. (Давайте сразу договоримся, групповые политики или Group Policy здесь и дальше по тексту просто GP).

                      Если в Windows 2003 SP1 мы могли настроить через GP порядка 1800 параметров, то в Windows Vista и Windows Server 2008 это количество выросло до 2500. С использованием групповых политик в среде, построенной на Windows 2003 и Windows XP, можно было сделать много, но не все. Часть задач перекладывалась на скрипты, которые можно было создавать самому и применять вместе с GP.

                      Скрипты это конечно здорово, но есть одна проблема, далеко не все умеют их писать. А поскольку «свято место пусто не бывает» на рынке появились компании, которые предлагали свои разработки позволяющие расширить стандартные групповые политики. Одной из таких компаний была «Desktop Standard». Видимо их разработка показалась софтверному гиганту достаточно интересной, поскольку в 2006-м году по старой корпоративной традиции компания была куплена Microsoft . С точки зрения ИТ-администраторов данное поглощение однозначно прошло со знаком «+». То, что стоило отдельных денег, теперь является частью доменной сети под управлением Windows Server 2008 и не требует дополнительного лицензирования.

                      В данной статье я буду рассказывать об изменениях в групповых политиках, которые произошли после выхода Windows Server 2008 с акцентом на «GP Preferences». Ну а теперь обо всем по порядку.

                      Как было в Windows Server 2003.

                      Для начала я предлагаю освежить в памяти групповые политики в классическом виде, т.е так как они выглядят в Windows Server 2003. При создании объекта групповой политики мы могли воздействовать на компьютеры или пользователей несколькими способами:

                      1. Сценарии – синий блок на рисунке 1. Сценарии давали возможность выполнить скрипты, написанные на Visual Basic Scripting Edition (VBS-файлы) и JScript (JS-файлы). При этом данные скрипты могли применяться в четырех случаях: при загрузке, при входе пользователя в систему, при выходе пользователя из системы, при выключении компьютера.

                      2. Установка программ – красный блок на рисунке 1. Компонент «Установка программ» позволял развертывать программное обеспечение из msi-файлов и в ряде ситуации отойти от ручной установки программ.

                      3. Параметры безопасности – оранжевый блок на рисунке 1. Параметры безопасности содержали целый ряд настроек безопасности компьютера. Список достаточно большой, могу привести примеры того что мы могли сделать: настроить NTFS права на файлы и папки, разрешить или запретить выключение питания компьютера, регулировать запуск служб, контролировать принадлежность пользователяк группам безопасности и многое другое.

                      4. Административные шаблоны – черный блок на рисунке 1. Непосредственная настройка самой операционной системы и ее компонентов ложилась на административные шаблоны. Фактически они являлись текстовыми файлами, в которых было прописано, какие параметры реестра должны быть применены на клиенте. Сразу после установки мы уже имели пять различных шаблонов, каждый из которых отвечал за свои параметры. Например, шаблон «Inetres.adm» позволял конфигурировать параметры обозревателя Internet Explorer.

                      image

                      Рис. 1 Объект групповой политики Windows Server 2003

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

                      Как стало в Windows 2008.

                      В принципе данная логика остается и в Windows Server 2008, за одним исключением, при создании объекта групповой политики в Windows Server 2008 у вас появляется новый блок, в русских версиях ОС он звучит как «Настройка». (Рис.2).

                      Собственно говоря, это и есть решение бывшей «Desktop Standard» интегрированное в новой серверной операционной системе. Данный блок «Настройка» предназначен для расширенного администрирования компьютеров без использования скриптов.

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

                      image

                      Рис.2 Новый блок при создании GP (англ. – GP Preferences)

                      Для начала давайте ответим на вопрос: В какие моменты происходит применение групповых политик?

                      Первым моментом является загрузка компьютера, второй это вход пользователя на компьютер, третий фоновое обновление (когда человек уже работает, раз в 90-минут происходит обновление и новые параметры вступают в силу, за исключением параметров требующих выхода из системы или перезагрузки) и последний момент при выполнении команды «gpupdate».

                      Примечание: 90 минут является значением по-умолчанию для параметра фонового применения GP, значение этого параметр можно менять.

                      Применение нового блока (давайте называть его GP Preferences) осуществляется точно также.

                      Разница заключается в следующем. Если GP применяется каждый раз в вышеописанных ситуациях и при изменении параметров на клиентском компьютере приводит все в соответствии с политикой, то параметры «GP Preferences» можно настроить на выполнение как постоянно, так и только один раз.

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

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

                      т.к повторного применения не будет. Плюс к этому отключение политики, где настроены «GP Preferences» не приведет к возвращению на параметры По-умолчанию.

                      Не стоит забывать, что «GP Preferences» делятся на часть, которая применяется к пользователям и часть, которая применяется к компьютерам. Т.е здесь все, как и у классических политик. Рис.3

                      image

                      image

                      Рис.3 Часть «GP Preferences» применяемая для объектов компьютер (слева) и часть, применяемая для объектов пользователь. (справа)

                      Следующей особенностью является ориентация нового блока «GP Preferences» на выполнения действия, то, что изначально делалось только скриптами: создать папку, создать ярлык, открыть общий доступ к папке, создать локального пользователя и тому подобное.

                      Попробуем в «GP Preferences» в деле.

                      Я предлагаю для лучшего понимания данной темы, решить практическую задачу с использованием «GP Preferences».

                      Вводная информация для задачи такая:

                      На сервере «Win2008-DC», который является контроллером домена, есть папка с общим доступом «Intro Docs», в этой папки находятся документы, которые должны прочитать сотрудники в первый рабочий день. Нужно, чтобы при первом входе на компьютер, у нового сотрудника на диск «C:» была скопирована данная папка, на рабочий стол пользователя добавлен к ней ярлык. После ознакомления сотрудник должен иметь возможность удалить и папку и ярлык. Вот и все. Может быть данная ситуация не совсем логична с жизненной точки зрения, но для проверки работы «GP Preferences» этого будет достаточно.

                      Прежде чем приступить к выполнению задачи, давайте уясним одну вещь. С помощью «GP Preferences» можно управлять следующими операционными системами:

                      · Windows XP with SP2

                      · Windows Vista

                      · Windows Server 2003 with SP1

                      · Windows Server 2008

                      И на каждой из управляемых систем (кроме Windows Server 2008) нужно установить клиентскую часть «Group Policy preferences clientside extension» или сокращенно CSE. Для всех из данного списка операционных систем доступна своя версия CSE. Скачать CSE можно с сайта Microsoft

                      Важно: Пока CSE не установлены на управляемом компьютере параметры «GP Preferences» применяться не будут.

                      Итак, переходим к выполнению задачи:

                      1. В первую очередь я скачал CSE для Windows Vista и установил на все компьютеры.

                      2. После этого на сервере «Win2008-DC» создал папку «Intro Docs» , открыл к ней общий доступ и наполнил документами.

                      3. Поскольку «GP Preferences» являются частью объекта групповой политики, нам будет необходимо создать и применить такой объект. В моем тестовом домене создано организационное подразделение «Moscow», в которое вложены два других организационных подразделения. «Computer» – где хранятся объекты компьютеров и «User» с объектами пользователей. (Рис.4)

                      image

                      Рис.4 Структура организационных подразделений.

                      4. Используя оснастку «Управление групповой политикой» я создаю объект групповой политики и связываю его с организационным подразделением Moscow.

                      Назову его «TEST GP Pref». Политика создана, остается ее настроить. (Рис.5)

                      image

                      Рис.5 Создание GPO

                      5. Открываем «TEST GP Pref» для редактирования и перед нами встает вопрос: «Какую часть GP Preferences редактировать? Для пользователя или для компьютера». Я считаю, что в нашей ситуации будет правильно редактировать «Конфигурацию пользователя». В зависимости от того что мы выберем наша политика будет действовать по-разному. Если применим настройки в «Конфигурации пользователя», то на первый же компьютер, на который зайдет пользователь, будет скопирована папка «Intro Docs» и создан ярлык. В последующие заходы данного пользователя на этот или другие компьютеры ничего создаваться не будет. Если применим настройки в «Конфигурации компьютера» то при первой загрузке будет создана папка «Intro Docs» и ярлык и абсолютно не важно, будет ли кто на него входить или нет. Я надеюсь, разницу вы поняли.

                      image

                      Рис.6 Редактирование GPO

                      6. Разворачиваем «Конфигурацию пользователя – Настройка – Конфигурация Windows –Файлы». Щелкаем правой кнопкой мыши на пустом месте и выбираем «Создать» – «Файл». Сейчас перед нами стоит задача настроить копирование папки «Intro Docs» на клиента при первом его входе. Для этого в появившемся окне выбираем действие «Создать» (Рис.7) , в поле «Исходные файлы» вводим путь к папке на сервере, по окончанию пути ставим звездочку, это говорит о том, что из папки нужно копировать все файлы. В поле пути конечной папки указываем, в какой папке на клиенте должны появиться эти файлы. Если папка в момент применения политики не существует – она будет создана! Обратите внимание, что я при указании конечной папки использовал переменную %SystemDrive% которая означает что папка должна находиться в корне на системном диске, т.е на диске где стоит Windows. Если вы не помните, какие переменные используются в Windows, достаточно поставить курсор в поле ввода и нажать клавишу «F3» , перед вами появится окно с переменными, где можно будет выбрать нужную. (Рис.8) Указывая переменные вместо жесткого указания пути, (т.е C:\Intro Docs) вы страхуете себя от нештатных ситуаций. (Например, отсутствие раздела с буквой C:)

                      image

                      Рис.7 Создание действия в «GP Preferences»

                      Но это еще не все, нам необходимо убедиться, что данное действие будет осуществлено только единожды для каждого пользователя. Поэтому переходим на закладку «Общие параметры» (Рис.9) и ставим галочку напротив настройки «Применить один раз и не применять повторно» и нажимаем «Ок»

                      Что произойдет в результате применения данной настройки?

                      При первом входе пользователя на компьютер будет проверено, существует ли на системном диске папка «Intro Docs», если ее нет, она будет создана и после чего в нее будут скопированы файлы с общей папки по адресу «\\Win2008-DC\Intro Docs\». После применения политики и создания файлов и папки, пользователь сможет сделать с ней все что угодно в рамках данных ему прав, повторно папка создаваться не будет.

                      image

                      Рис.8 Меню с переменными.

                      image

                      Рис.9 Настройка закладки общие параметры.

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

                      image

                      Рис. 10 Создание ярлыка.

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

                      «Конечный путь» – путь, к которому будет вести наш ярлык. Прописываем здесь %SystemDrive%\Intro Docs, т.е ярлык будет указывать на папку «Intro Docs» на системном диске клиента.

                      В поле «Путь к значку файла» можете нажать на троеточие «» и выбрать иконку для вашего ярлыка. После чего нажимаем «Ок»

                      Задача выполнена. Остается обновить политику на клиенте и проверить появление ярлыка на рабочем столе и папки Intro Docs на системном диске клиента.

                      На что еще следует обратить внимание при создании действия.

                      Когда вы создавали файлы, то при выборе действия у вас было 4 варианта.

                      «Создать» – «Заменить» – «Обновить» – «Удалить»

                      Если по первому и последнему все я думаю понятно. На нашем примере «Создать» создает файлы путем копирования с сервера, а «Удаление» позволило бы очистить папку Intro Docs.

                      То действия «Заменить» – «Обновить» не столь очевидны.

                      Особый интерес представляет фильтрация применения «GP Preferences».

                      Если вы помните, в Windows Server 2003 мы могли фильтровать применение групповой политики несколькими способами, самой распространенной была и остается фильтрация путем применения GP к разным организационным подразделениям. Если же мы хотели фильтровать применение GP в рамках одного организационного подразделения, то могли использовать WMI-фильтры или запрещать применение политики путем фильтров безопасности. Осуществлять фильтрацию, по каким-то признакам клиента можно было только с помощью WMI-фильтров и было это достаточно сложно.

                      В Windows 2008 фильтрация «GP Preferences» выглядит поистине сказочно. Кто не верит на слово, предлагаю взглянуть на Рис.11

                      image

                      В «Нацеливании» (а именно так называется фильтрация «GP Preferences») есть если не все, то очень многое. Добавьте к этому «Нацеливание» по каждому элементу, а на всей политики разом и вы получите «Мечту системного администратора». Подробнее в видео-приложении.

                      Вывод.

                      Инструмент для работы получился отменный. Когда смотришь на подобные решения, действительно веришь в снижении стоимости обслуживания новых версии операционных систем от Microsoft. Следует заметить что «GP Preferences» можно установить и на контроллер домена под управлением Windows Server 2003, после чего задействовать данную возможность для управления сетью. Позвольте ответить на вопрос: Почему ты до этого об этом молчал?

                      На последней встрече с архитекторами Microsoft зашел разговор о «GP Preferences» и я поинтересовался, почему они умалчивают возможность использования «GP Preferences» без покупки Windows Server 2008, на что я получил конкретный ответ: «Да, установить данную вещь на Windows Server 2003 можно и это будет работать. Но, работа «GP Preferences»на Windows Server 2003 компанией Microsoft не поддерживается, мы это выпустили, а вы хотите, используйте, хотите, нет». Вот собственно и причина моего молчания.

                      Некоторые моменты в статье я осознанно опустил. Данная статья является экспериментальной. Она состоит из данного документа и видео-приложения.

                      Скачать видео-демонстрацию.

                      Рудь Илья

                      MCSE/MCT

                      me@rudilya.ru