Хотя в интернете есть статьи, детально и со скриншотами описывающие действия по включению RDP Remote Recording, для вновь установленных ОС в общем случае данных действий не достаточно. В этой заметке я приведу проверенный лично алгоритм включения Remote audio recording на WS2008R2 и Win7.

1. Включить Windows Audio Service. Актуально для WS2008R2, так как по умолчанию данная служба отключена. Для включения достаточно кликнуть правой кнопкой по громкоговорителю в углу экрана и вызвать свойства, далее система сама предложит запустить сервис.

2. Разрешить перенаправление аудио/видео и записи звука в свойствах RDP-сервера.

Сия настраивается доступна в следующих местах:

• MMC-оснастке Remote Desktop Session Host Configuration (не доступна в стандартной поставке Windows 7)
• Групповых политиках (доменных, либо локальных — gpedit.msc)

[Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Device and Resource Redirection]

Allow audio and video playback redirection
Allow audio recording redirection


3. Отредактировать реестр. Как выяснилось, даже если в политике нужные функции будут явно разрешены, передача аудио/видео работать начнет, а вот запись звука — нет. Для того, чтобы запись звука по RDP начала работать, нужно задать следующее значение в реестре:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp]

"fDisableAudioCapture"=dword:00000000

После этого в записывающих устройствах (Recording Devices) ОС Windows 7 появится Remote Audio.

4. Установить роль Remote Desktop Session Host на WS2008R2. В режиме Remote Desktop fot Administration, который настраивается при установке системы, перенаправление записи звука не работает.

Установщик роли Remote Desktop Session Host будет настоятельно предлагать установить фичу Desktop Experience, если отметить галочки Audio and video playback, Audio recording redirection. Рекомендую снять эти галочки и поставить роль RDSH без фичи Desktop Experience, так как она для работы записи звука по RDP не требуется, но при этом в систему добавляет много ненужного (полупрозрачные окна, нескучные обои и прочий BolgenOS).

5. Включить в RDP-клиенте функциональность Remote audio playback и Remote audio recording.

Ссылки

• Configure Audio Recording Redirection on an RD Session Host Server
• Enable Audio in Windows 2008 guest machines running on HyperV
• What’s New in Remote Audio for Windows 7?

Причина, по которой мне нужна ОС Windows Server 2008 R2 на ноутбуке — это возможность использовать Hyper-V. Однако, после установки данной роли выключаются столь полезные для ноутбука функции, как сон (sleep) и гибернация (hypernation).

Совместно использовать Hyper-V и функции энергосбережения на текущей версии ядра ОС никак нельзя (хотя, в Windows 8 это уж обещают). Но есть возможность исхитриться! Прописать в реестре «ручной» запуск службы hvboot:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\hvboot] "Start"=dword:00000003

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

net start hvboot

Данная команда активирует Hyper-V, но отключит энергосберегающие функции в операционной системе. К сожалению, остановить службу hvboot (со всеми вытекающими) можно только перезагрузкой ОС.

Полезная ссылка: Hyper-V: How to Run Hyper-V on a Laptop

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

Предложенные варианты схем основаны на личном проектном опыте и в результате анализа достоинств и недостатков в ИТ-инфраструктурах, которые приходилось встречать.

Я приведу аргументы практически для каждого решения, принятого при проектировании предлагаемых ниже схем. Буду рад увидеть альтернативные мнения в комментариях.

Содержание:

• Поиск по неполным данным
• Учетные записи пользователей
• Группы
• Сетевые устройства
• Организационные подразделения
• Другие объекты
• Годные ссылки

Поиск по неполным данным

Одной из замечательных возможностей AD является поиск по неполным данным. Прелесть его в том, что для выбора нужного нам объекта (пользователя, компьютера, группы) можно просто ввести несколько начальных символов из его имени. Если подходящих объектов будет найдено несколько, предоставят возможность выбрать тот объект, который нужен. Поиск по неполным данным может очень сильно облегчить выполнение регулярных задач по администрированию AD… Если атрибуты AD заполнены удобным, стандартизированным и структурированным образом.

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

Учетные записи пользователей

Логины

В среде AD в качестве логина могут использоваться 2 формата:

• User Principal Name (UPN) [userPrincipalName]: upnlogin@argnon.pro
• User logon name (pre-Windows 2000) [sAMAccountName]: argon\samlogin

Имеется возможность для учётки пользователя задать разные значения upnlogin и samlogin, однако это не практично, если того не требуют особые обстоятельства. Далее по тексту под словом «логин» я буду понимать одинаковое значение для атрибутов userPrincipalName и sAMAccountName.

Примечание

В неполном поиске участвует только sAMAccountName.

При создании схемы именования учетных записей пользователей разумно в первую очередь учитывать следующие критерии:

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

Всем вышеперечисленным требованиям удовлетворяет следующая схема:

• только латинские буквы — чтобы избежать проблем со сторонними (например, Linux Samba Server) и не очень (даже Remote Desktop Gateway, входящий в Windows Server 2008 R2 не работает, если встретит не латинские буквы в логине) приложениями, а также с аппаратурой (отсутствие русской раскладки, поддержки кодировки).
• не более 10 букв — для случаев ввода с не очень удобных устройств (мобильников, экранных клавиатур)
• содержать в себе фрагменты имени и фамилии хозяина — для удобства идентификации учётки с конкретным пользователем.

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

• личный — основанный на именах
• обезличенный — основанный на табельных номерах и прочих идентифицирующих данных

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

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

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

При формировании логина на основании имени и фамилии пользователя тоже возникают трудности. Ныне популярна такая схема именования:

<Имя>.<Фамилия> [Игорь Романовский → Igor.Romanovsky]

Согласен, выглядит красиво, однако, возникнут проблемы:

• с длинными именами и фамилиями [Иннокентий Петропавловский → Innokenty.Petropavlovsky]
• с трудностями однозначной транслитерации [Евгений Дряхлых → Eugene Dryakhlykh и еще массы вариантов]

Выход — сокращать логин, например, так:

<1я-буква-имени><часть-фамилии> [Евгений Баев → ebaev]

<часть-фамилии><1я-буква-имени> [Алексей Бармин → barmina]

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

Возможный выход из ситуации — как-то разделять фрагменты имени и фамилии, например, точкой:

<1я-буква-имени>.<часть-фамилии> [Игорь Романовский → i.rom]

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

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

На основе приведенных выше размышлений, я предлагаю следующую схему, которая меня полностью устраивает:

<часть-имени><часть-фамилии> [Алексей Волков → alvol, Фёдор Бондарчук → fbond, Феликс Бунин → felixb]

Прелесть схемы в том, что части имени и фамилии выбираются так, чтобы:

• выглядело благовидно
• избежать коллизии
• логин оставался кратким

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

Служебные логины

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

• на предприятии используются несколько обезличенных «ролевых» учетных записей типа Administrator, NetAdmin, WebAdmin, TechSupport…
• ими пользуется куча народа, исполняющего соответствующие роли

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

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

• использовать отдельные личные учетки для выполнении административных задач, с логинами вида a-login, где вместо login — обычный логин данного пользователя
• привилегии на выполнение административных операций всегда назначать на уровне ролевых групп безопасности

Display Name

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

При создании пользователя в Active Directory предлагается заполнить поля имени, инициалов и фамилии. На основе этих данных предлагается значение атрибута Display Name по следующей схеме:

<Firstname> <Initials>. <Lastname>

Примечание

Путем редактирования некоторых параметров в AD эту схему можно изменить (например, на Lastname, Firstname), но на то нет веских причин. Советские времена, когда к людям было принято обращаться тов. Фамилия прошли, в современном деловом обществе принято обращаться по Имя Фамилия.

Для Display Name можно задать произвольное значение, что удобно:

• для служебных учетных записей, которые не имеют имён и фамилий
• если в поле AD «имя» введено Имя Отчество(так как под отчество нет отдельного поля), а отображать нужно в формате Имя Фамилия

Full Name

В момент создания пользователя значение Display Name присваивается другому атрибуту пользователя — cn (Canonical Name, часто он упомиается как Full Name). Значение cn широко используется в Active Directory:

• является частью фундаментального атрибута distinguishedName, который представляет собой путь к объекту в пределах AD (CN=Firstname Lastname,OU=Test Accounts,DC=argon,DC=pro), из него же формируется Canonical Name (argon.pro/Test Accounts/Firstname Lastname)
• именно это имя отображается в поле Full Name в оснастке Active Directory Users and Computers
• по этому параметру выполняется неполный поиск объектов в AD

Стоит обратить внимания на следующие особенности:

• атрибуты Display Name и Full Name напрямую не связаны, и после создания учетки их можно редактировать как угодно
• значение Full Name должно быть уникальным в пределах своего Organization Unit, к Display Name таких требований не предъявляется
• оба значения Display Name и Full Name следует держать согласованными, если нет необходимости в обратном, для чего редактирования первого нужно аналогично отредактировать и второе значение.

Группы

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

• избегать нелатинских символов и пробелов
• стремиться к кратким названиям

В дополнение к вышеперечисленному, удобно, чтобы имена групп соответствовали следующим характеристикам:

• чем-то явно отличались от логинов
• отражали назначение группы (например, из имен Техподдержка и Бухгалтерия не понять, что есть группа безопасности, а что — группа рассылки)
• признаки, содержащиеся в имени, следовали в порядке значимости (например, ExchangeAdmins и ExchangeHelpdesk, а не Администраторы Exchange и Техническая поддержка Exchange)

При этом, включать в имя группы признак её области действия (локальная, глобальная, универсальная) нет необходимости по следующим причинам:

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

Итак, я предлагаю следующую схему именования групп:

g<p>-<Name>

где:

• g — признак отличия имени группы от логина
• p — назначение группы, принимает значения:
  • f — функциональная
  • r — ресурсная
  • d — распространения
  • a — административная
• Name — собственно, имя группы; при необходимости, содержит признаки принадлежности к области действия, например:
  • GlobHelpdesk
  • MscPrinters

Пример имён групп:

• gf-Operators
• gr-ProjectDocs
• gd-AllCompany
• ga-Helpdesk

Примечание

Назначение группы определяется ролевой моделью привилегий (также известной как UGLP), в которой:

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

Для групп рассылки есть замечательный атрибут Display Name, который позволяет отображать «человеческое» имя в адресной книге, а также произносить ее голосом в Exchange UM, и одновременно с этим не уходить от общей конвенции именования групп.

Сетевые устройства

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

Примеры неудачных имен с попыткой их расшифровать и комментариями:

• SR-PSSRV001 (сервер-принт-сервер-сервер-номер001) — слово «сервер» закодировано 3 раза, порядковый номер 3-разрядный, хотя таких серверов всего 2 штуки
• SR-msExch04 (сервер, почтовый сервер-эксчендж сервер-номер04) — многократно закодировано слово «сервер», но нет данных о его размещении
• W-430400764 (рабочая станция-43регион, офис 04, инвентарный номер 00764) — без таблицы — не найти!
• МАШЕНЬКА-ПК (без комментариев)

Для сетевых устройств (компьютеров, принтеров, роутеров, мобильников…) я предлагаю гибкую схему именования, которая основана на следующих правилах:

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

А вот и схема:

<Site>-<Class>-<[Type]Name[Number]>

• Site — признак расположения компьютера (определение сайта в терминологии AD вполне подходит), такие как HQ, NOC, MSC, KZN и прочее.
• Class — класс устройства, например:
  • SR — сервер
  • WS — рабочая станция
  • MB — мобильное устройство
  • DV — другое сетевое устройство
• Type — опциональное дальнейшее уточнение назначения устройства (зависит от класса), например:
  • DC — контроллер домена
  • PR — принтер
  • DT — десктоп
  • LT — ноутбук
• Name — имя устройства, краткое и описательное, например:
  • ExMB — сервер почтовых ящиков Exchange
  • Gate — шлюз
  • Proxy — …
• Number — опциональный номер, если подобных устройств несколько. Разрядность номера следует планировать заранее, но и фиксировать количество разрядов для абсолютно всех устройств не стоит, так большая разрядность уместна в редких случаях, а в большинстве случаев достаточно номера в пределах десятка.

Примеры имен, образованных по такой схеме:

• NOC-SR-DCLAB18 (сайт NOC, сервер, контроллер домена LAB, номер 18)
• MSC-SR-MONITOR (сайт MSC, сервер, занимается мониторингом)
• NOC-CL-HV4 (сайт NOC, кластер Hyper-V, номер 4)
• NOC-CL-HV4-N7 (сайт NOC, кластер Hyper-V номер 4, узел номер 7)
• HQ-SR-EXMB3 (сайт HQ, cервер, Exchange c ролью Mailbox, номер 3)
• KOS-WS-DTFIN06 (сайт KOS, рабочая станция, настольная, финансовый отдел, номер 06)
• EXT-WS-LTIROM (внешний сайт, рабочая станция, ноутбук пользователя с логином irom)
• NOC-DV-ROUTER12 (сайт NOC, устройство, маршрутизатор, номер 12)
• EXT-MD-WMIROM (внешний сайт, мобильное устройство, windows mobile пользователя с логином irom)

Организационные подразделения

Существующих несколько моделей построения структуры OU и делегирования. Здесь я не буду пытаться описать их все, это хорошо сделано в более серьёзной литературе.

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

• объединения объектов признакам
• делегирования полномочий
• назначения групповых политик
• эффективного использования возможностей наследования

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

• противоречива и изменчива
• не применима к управлению ИТ-инфраструктурой

Я предлагаю строить структуру OU по следующей концепции:

• Создавать структуру OU исходя в первую очередь из удобства делегирования полномочий.
• Для тонкого назначения групповых политик на пользователей, рабочие станции и сервера использовать ролевую модель, основанную на членстве в группах в безопасности. Не эффективно пытаться строить ролевую модель на OU. Непременно найдутся объекты, которые исполняют несколько ролей, но архитектура AD предусматривает членство объекта только в одном OU.

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

• в именах OU не использовать нелатинских символов и пробелов
• придерживаться принципов краткости и не избыточности
• умеренно использовать иерархию (глубокая вложенность замедляет выполнение некоторых операций)
• активно пользоваться полем Description
• избегать использования встроенных контейнеров Users и Computers для хранения в них объектов, назначения политик
• не создавать своих контейнеров (куда-то вложенных) с именами Users и Computers — могут быть проблемы совместимости

Пример структуры OU, который следует вышеизложенным рекомендациям:

• lab.argon.pro — домен
  • Company – сразу отделяем наше дерево иерархии от встроенных объектов AD
    • Global
    • Kazan
    • Kirov– уровень территориальной принадлежности
      • Services – служебные пользователи и группы, управляет которыми только IT-отдел
      • Comps – компьютеры: сервера и рабочие станции
      • Accounts – учетные записи и группы рядовых пользователей, управление которыми можно делегировать простым пользователям (конечно, через другие группы безопасности, прав на управление которыми у данного пользователя не будет)
    • Moscow

Другие объекты

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

• совместимость
• не избыточность и краткость
• простота и наглядность
• наличие признаков группировки, идущих в порядке значимости

[To be continued and edited...]

Годные ссылки

• The 12 Mighty Chores of Active Directory Administration in Depth
• Оптимизация AD: Cтруктура орг. подразделений(OU) служит для делегирования прав и назначения групповых политик
• RFC 2142 — Mailbox Names for Common Services, Roles and Functions

…развитие клонирования ОС от кустарного секторного через флешку к промышленному файловому по сети…

Для клонирования операционных систем ранее я использовал платные программы Symantec Ghost или Acronis True Image. Они выполняли свои функции и устраивали меня… Пока я не познакомился с Windows Deployment Services — еще более мощным средством от Microsoft для централизованного развертывания ОС, которое доступно как роль в Windows Server начиная с 2008 версии.

В данной статье будут рассмотрены следующие темы:

• Способы клонирования
• Работа с WIM-образами
• Windows Deployment Services
• Загрузочные образы WDS
• Создание загрузочного носителя
• Пример использования WDS для централизованного развертывания ОС
• Полезные ссылки

Способы клонирования

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

Секторный

Традиционный способ, его используют такие программы как Symantec Ghost и Acronis True Image.

Достоинства:

• Универсальность — как правило, при клонировании тип операционной системы не важен, поддерживалась бы файловая система.
• Скорость — секторное копирование намного быстрее файлового (структура файловой системы и фрагментация сильно не влияют на скорость копирования).

Недостатки:

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

Файловый

При данном способе в реализации Microsoft образ ОС снимается на файловом уровне с помощью утилиты ImageX, результирующий файл образа имеет формат WIM.

Преимущества:

• Возможность подключать образ к файловой системе и редактировать его в оффлайн режиме. Можно даже устанавливать обновления и драйвера на поддерживающие эту функцию ОС (начиная с Vista).
• Открытость формата, с ним может работать и сторонний софт.
• Хорошее сжатие, ничего лишнего в процессе снятия образа в него не добавляется. Имеется возможность объединять несколько образов в один файл, при этом дублирующиеся файлы не занимают дополнительного места.

Недостатки:

• Низкая скорость работы (все особенности размещения файлов и фрагментация имеет значения).
• Ограниченная поддержка ОС и файловых систем (только Microsoft, начиная с Windows XP)

Работа с WIM-образами

Для создания, редактирования и развертывания WIM-образов операционных существует несколько стандартных средств, которые дополняют друг друга:

• ImageX — текстовая утилита для создания, редактирования и применения WIM-образов.
• Windows Automated Installation Kit — набор средств создания образов для автоматизированной установкой ОС, содержит Windows PE.
• Windows Deployment Services, о котором будет рассказано ниже.
• Microsoft Deployment Toolkit — продвинутый пакет для тонкой настройки установочных образов (скачать). Функциональность частично пересекается с WDS: работа с сетью ограничена файловой шарой, но шире возможности по настройке действий, выполняемых образами (Task Sequence).
• System Center Configuration Manager — мощнейшее средство для централизованного развертывания ОС без участия пользователя(zero-touch install), объединяет и использует перечисленные выше программы.

Windows Deployment Services

Эта роль доступна в Windows Server начиная с 2008 версии, роль-предшественница в Windows Server 2003 называлась RIS.

WDS позволяет:

• Систематизировано хранить в одном месте подготовленные WIM-образы операционных систем.
• Выполнять загрузку компьютеров по сети с загрузочных образов (Boot Images) при помощи PXE.
• Развертывать ОС семейства Windows (XP, Server 2003, Vista, 7, Server 2008/2008R2) из хранимых установочных образов (Install Images).
• Выполнять параллельное развертывание ОС на несколько компьютеров при помощи многоадресной рассылки.

Служба WDS достаточно проста и дружелюбна к пользователю, а встроенный хелп к ней краток и понятен. После установки WDS в мастере начальной конфигурации рекомендую выбрать Respond to all clients computers на этапе настройки PXE Response Policy. Это избавит нас от предварительного ручного создания объектов в Active Directory для каждого компьютера, загружаемого по сети.

После прохождения мастера начальной конфигурации WDS готова к работе. Начать освоение предлагаю с добавления на сервер стандартного установочного WIM-образа (Install Image) Windows 7, который можно взять с установочного диска по адресу \sources\install.wim. Для загрузки компьютеров по сети и развертывания на них установочных образов необходимо добавить загрузочные образы (Boot Images), о которых я далее расскажу подробнее.

Загрузочные образы WDS

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

Setup Boot Image — устанавливающий загрузочный образ

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

Для добавления Setup Boot Image на сервер WDS достаточно выполнить команду Add Boot Image и в качестве файла-источника указать \sources\boot.win от обычного установочного диска Win7/WS2008R2 нужного языка и разрядности.

Capture Boot Image — захватывающий загрузочный образ

Загрузившись с такого образа будет предоставлен графический интерфейс, позволяющий:

• Выбрать раздел на компьютере, который нужно «захватить» в WIM-образ.
• Задать имя и описание образа.
• Выбрать размещение создаваемого WIM-файла.
• Опционально отправить полученный WIM-образ на сервер WDS по сети.

Чтобы добавить Capture Boot Image на сервер WDS достаточно кликнуть правой кнопкой на уже существующем Setup Boot Image и выбрать в контекстном меню Create Capture Image.

Discover Boot Image — обнаруживающий загрузочный образ

Данный образ позволяет компьютерам, не поддерживающим загрузку по сети (PXE), загрузиться традиционным способом (с компакта или флешки) и подключаться к серверу WDS для развертывания с него доступных установочных образов, аналогично работе Setup Boot Image.

Для создания Discover Boot Image нужно кликнуть правой кнопкой на уже существующем Setup Boot Image и выбрать Create Discover Image. Результатом данной операции будет загрузочный WIM-образ. О том, как создавать загрузочные ISO-образы и флешки с WIM-файлами я расскажу далее.

Создание загрузочного носителя

Далеко не всегда есть возможность загружать компьютер по сети с сервера WDS, поэтому может возникнуть необходимость локально загружать Setup и Capture образы с компакта или флешки.

Для создания таких носителей предварительно необходимо установить Windows Automated Installation Kit (WAIK, загрузить можно здесь) и выполнить следующие действия.

1. От имени админа запустить Deployment Tools Command Prompt.

2. Выполнить

где вместо x86 можно выбрать другую разрядность (x86, amd64, ia64).

3. Скопировать в папку c:\Deploy\WinPE_x86\ISO\sources нужный вам загрузочный WIM-образ (Setup, Capture, Discover) и назвать его boot.wim.

4. Теперь по адресу c:\Deploy\WinPE_x86\ISO лежит заготовка для создания загрузочного носителя.

Создание загрузочного ISO-образа

Из Deployment Tools Command Prompt выполнить

В результате будет создан загрузочный ISO-образ image.iso, готовый для записи на болванку или подключению к виртуальным машинам.

Создание загрузочной флешки

1. Отформатировать флешку в FAT32, сделать этот раздел активным.

2. Взять утилиту bootsect.exe из папки \boot установочного диска Win7/WS2008R2 нужной разрядности.

3. Выполнить от имен администратора

где e: — буква диска флешки.

4. Скопировать содержимое c:\Deploy\WinPE_x86\ISO в корень флешки.

Загрузочная флешка готова.

Пример использования WDS для централизованного развертывания ОС

1. Добавляем на сервер WDS стандартный установочный образ Windows 7 (из \sources\install.wim установочного диска).
2. Загружаем образцовый компьютер по сети в устанавливающий образ Setup Boot Image, и разворачиваем Windows 7 из стандартного образа.
3. Настраиваем установленную ОС как нам нужно.
4. Готовим ОС для клонирования с помощью SysPrep.
5. Клонируем с помощью Capture Boot Image и загружаем полученный WIM-образ на сервер WDS.
6. Развертываем образцовый WIM на нужные компьютеры по сети с помощью Install Boot Image или с других носителей (флешек, компактов).

Полезные ссылки

• Deployment TechCenter
• Deploying Windows 7 — серия из 29 статей Митча Туллоча, автора многих книг Microsoft Press

Я использую 2 средства удаленного выполнения консольных команд: PsExec и WinRM, у каждого из них есть свои преимущества.

PsExec

Одним из отличных решений поставленной в заголовке задачи является использование программы PsExec от великого Марка Руссиновича.

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

Если PsExec запускается от имени администратора, который входит в тот же домен, что и удаленны компьютер, то никаких учетных данных даже вводить не нужно. В противном случае, их можно указать в командной строке, либо PsExec сама их запросит. PsExec работает на ОС начиная с Windows 2000 и заканчивая 64-битным Windows Server 2008 R2.

Очень полезными в PsExec являются следующие возможности:

• Выполнение команды на группе компьютеров. Пример: следующая команда позволяет принудительно применить самые свежие групповые политики:
  psexec @group.txt gpupdate /force
• Выполнение команд от имени системной учетной записи. Пример: следующая команда заставит удаленную систему принудительно проверить обновления:
  psexec \\computer -s wuauclt /detectnow
• Копирование выполняемой программы на удаленный компьютер перед выполнением. Пример: следующая команда позволит обновить членство данного компьютера в группе безопасности Active Directory (токен доступа) без перезагрузки:
  psexec \\computer -c -s klist.exe purge

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

Windows Remote Management

Изначально это была серверная технология для удаленного управления оборудованием, которая появилась в Windows Server 2003 R2 как часть компонента Hardware Management, но недавно Microsoft выпустили пакет Windows Management Framework, который включает в себя PowerShell 2.0 и WinRM 2.0 и устанавливается на клиентские ОС как обновление. Подробности можно прочитать в статье KB968929.

Прелесть WinRM заключается в простоте развертывания в доменной среде через WSUS в качестве факультативного обновления ОС и мощи, которую даёт совместное с PowerShell применение.

Использование WinRM происходит через 2 команды.

winrm.cmd служит для конфигурирования настроек и диагностики клиента и сервера WinRM.

Для того, чтобы сервер WinRM начал принимать команды, должна быть запущена служба Windows Remote Management и произведена её начальная конфигурация. Используйте команду

winrm quickconfig на локальной машине, либо финт ушами
psexec -s \\servername winrm quickconfig по сети, используя PsExec от имени системной учетной записи.

Будет предложено автоматически запускать службу WinRM и разрешить уделенные подключения, соглашайтесь ;)

Чтобы успешно подключаться к WinRM серверу (имеется в виду серверная часть, принимающая команды), не входящему в тот же домен, что и ваш клиентский компьютер, необходимо на клиенте этот целевой сервер добавить в «доверенный список» следующей командой:

winrm set winrm/config/client @{TrustedHosts="servername"}, где вместо servername можно указать IP-адрес, либо * (звёздочку).

Для пользователей Windows Vista и Windows 7, работающим не от имени встроенного администратора (обычно так и бывает), нужно выполнить следующую команду

reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f

По умолчанию, установлено ограничение на 5 одновременных соединений WinRM от клиента, для увеличения этого числа выполните команду

winrm s winrm/config/winrs @{MaxShellsPerUser="X"}

winrs.exe — клиент для отправки запросов к серверной части. Пример: следующая команда принудительно перезагрузит удаленную систему…

winrs -r:servername shutdown /r /t 0

В доменной среде при отправке команд используются учетные данные запустившего пользователя. Для посыла команд от имени другого пользователя используются ключи -u:user -p:pass. Пример: следующая команда очистит локальный кэш DNS-имён на удаленной системе

winrs -r:servername -u:user -p:pass ipconfig /flushdns

Будут рассмотрены следующие темы:

• Описание возможностей
• Сильные и слабые стороны продукта
• Установка серверных компонентов Forefront Client Security
• Развертывание клиентских компонентов Forefront Client Security
• Советы и хитрости
• Полезные ссылки

Описание возможностей

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

Client Security состоит из клиентской и северной частей.

Клиентская часть называется Forefront Client Security Agent и состоит из трех легких компонент:

• Antimalware Service — антивирусное ядро
• State Assessment Service — средство проверки текущего состояния безопасности
• Microsoft Operations Manager (MOM) 2005 Agent — агент для связи с сервером управления

Агент Client Security заточен на быстрое развертывание и централизованное управление, поэтому для конечного пользователя предоставляет только необходимый минимум функций, таких как

• сканирование по требованию
• расписание автоматического сканирования
• проверка обновлений
• настройка исключений
• отключение сканирующих модулей

Серверная часть называется Forefront Client Security Management Console, представляет собой панель управления, на которой отображается текущее состояние системы, настраиваются политики безопасности и представлены возможности для формирования разнообразных отчетов. Консоль управления для своей работы использует следующие технологии:

• Active Directory для централизованного распространения настроек (политик безопасности)
• Windows Server Update Services (WSUS) для централизованного распространения программных модулей и обновления антивирусных баз
• Microsoft Operations Manager 2005 (подпиленная версия) для сбора данных о состоянии клиентов
• SQL Server 2005 Database Engine для хранения базы данных
• SQL Server 2005 Reporting Services для формирования отчетов

Сильные и слабые стороны

Сильные стороны продукта:

• Высокая эффективность: авторитетные независимые тесты (Virus Bulletin, AV-Comparatives) неоднократно давали максимальный рейтинг этому антивирусу. Продукт сертифицирован для государственного применения.
• Производительность: антивирусный агент, работающий на клиентах, потребляет сравнительно немного памяти и не содержит ненужных в корпоративной среде модулей, такие как «оптимизаторы» ОС, брандмауэры и т. п.
• Широкая совместимость с платформами: агент поддерживает клиентские и серверные ОС начиная с Windows 2000 и заканчивая Windows 7 / Server 2008 R2.
• Централизованное управление и мониторинг: позволяет централизованно контролировать все настройки антивирусов, в соответствии с гранулярно создаваемыми политиками. Информация о состоянии контролируемых систем централизованно собирается и анализируется.
• Интеграция со службами Microsoft: продукт по полной использует технологии Microsoft, которые позволяет сравнительно легко внедрять его в существующую инфраструктуру. Это очень важно для больших сетей.
• Масштабируемость: одиночный сервер управления может поддерживать работу порядка десяти тысяч клиентов, а сами серверы управления можно централизованно объединить с помощью Client Security Enterprise Manager.
• Низкая стоимость: одна лицензия клиента стоит около 13 зелёных в год. Лицензия на сервер управления — около 2,5 тысяч зелёных в год, что сравнительно недорого, в случае больших инсталляций.

Все слабые стороны относятся к серверным компонентам и вытекают из сильных сторон…

• Специфические требования к инфраструктуре: для серверных компонентов поддерживаются только 32-х разрядные операционные системы, причем официально — только Windows Server 2003. Полная установка продукта довольно сложна, требует выполнения многих предварительных условий в текущей информационной инфраструктуре. Все серверные компоненты Forefront Client Security можно установить на одну ОС, однако чем-либо дополнительным эту систему лучше не нагружать.
• Высокие системные требования: в моей инсталляции на 50 клиентов сервер управления начинает нормально работать с 2 гигабайтами памяти и весьма неслабым двухъядерным процессором, занимая 50 гигабайт места на диске.
• Общая громоздкость системы: так как серверная часть продукта состоит из многих компонентов, которые могут быть распределены по разным компьютерам, общая надежность системы понижается из-за возможности отказов отдельных компонентов.
• Требование платной версии SQL Server 2005: продукт не может использовать БД Windows Internal Database, у которой нет ограничения на размер баз данных.

Я считаю, слабые стороны в основном проявляют себя в небольших инсталляциях, а на целевом рынке продукта, корпоративных сетях средних и крупных размеров, эти особенности оправданы.

Установка серверных компонентов Forefront Client Security

Процедура развертывания системы описана на русском языке в документации на TechNet, однако она довольно громоздка, уныла и местами устарела… Текст далее призван помочь установить и настроить Forefront Client Security без выкуривания официальных мануалов.

Management Console состоит из нескольких ролей, которые можно разносить по разным серверам:

• Management Server — сервер управления
• Collection Server — сервер сбора данных (MOM)
• Collection Database — база данных (SQL Server 2005 Database Engine)
• Reporting Server and Database — сервер отчетов (SQL Server 2005 Reporting Services)
• Distribution Server — сервер распространения (WSUS)

Требования к этим ролям описаны в документации на TechNet. Следует обратить особое внимание на то, что в качестве платформы для всех ролей официально поддерживается только 32-битная Windows Server 2003. На деле же, WSUS прекрасно работает и на Windows Server 2008 64 bit, также на эту платформу можно установить и 64-битную редакцию SQL Server 2005. Также я успешно устанавливал все серверные компоненты Forefront Client Security на Windows Server 2008 32 bit, особых подводных камней, помимо отмеченных далее, не заметил.

В этой записи я рассмотрю процесс установки всех ролей, кроме WSUS, на 32-битный Windows Server 2003. Сервер должен быть членом домена, на нем должны быть установлены следующие стандартные компоненты: IIS, ASP.NET, .Net Framework 2.0 (для Reporting Services и WSUS). Дополнительно необходим Group Policy Management Console (для Management Console), и желательно обновить .Net Framework до последней версии.

Теперь можно перейти к установке SQL Server 2005. Тут меня ждала огромная неприятность и разочарование: необходима платная редакция SQL Server 2005, не ниже Standard. Казалось бы, в бесплатном SQL Server 2005 Express Edition with Advanced Services имеются все компоненты, заявленные в официальных требованиях (конечно кроме ограничения на объем БД, что, в общем-то, можно обойти созданием нескольких баз). Если следовать такой логике, то в процессе установки серверных компонентов Forefront Client Security обнаруживается, что не хватает компонента Integration Services, который входит в поставку SQL Server 2005, начиная с редакции Standard…

Устанавливая SQL Server 2005 Standard необходимо выбрать компоненты Database Engine, Reporting Services и проклятые Integration Services, необходимость которых мне не ясна. Стандартная версия SQL Server 2005 распространяется на дисках и на текущий момент уже устарела, поэтому сразу после её установки необходимо установить SP3. Чтобы избежать перезагрузки системы, на последней странице диалоговых окон установщика SP3 (где предлагается отравлять отчет об установке в Microsoft) нужно остановить службы SQL Server и SQL Server Reporting Server.

Чтобы проверить, корректно ли установились Reporting Services, пробуем зайти IE (с отключенным режимом Enhanced Security) на адрес http://localhost/Reports/. Если ошибок нет, то продолжаем. Если есть, пишите в комментарии. До начала установки Client Security настраиваем службу SQL Server Agent на запуск автоматически и запускаем (проверяется при установке).

В Active Directory создаём пользователя и наделяем его административными правами (группа Domain Admins) на всех компьютерах, на которых будут работать любые компоненты Forefront Client Security.

Наконец, настало время запустить установку серверных компонентов Forefront Client Security. Нас спросят ввести данные для учетной записи DAS, от имени которой будет работать система на всех компьютерах — это именно тот пользователь, которого мы создавали в AD. Обратите внимание на настройки начальных размеров баз данных! Не изменяйте их в меньшую сторону, иначе скоро у вас начнутся проблемы, подтверждено моим горьким опытом. Если предполагается работа с тысячами агентами, обязательно ознакомьтесь со статьями «Размеры баз данных» и «Влияние на системные ресурсы сервера». Если все предыдущие шаги проделаны правильно, дальнейших проблем возникнуть не должно. Установка долгая, что типично для продуктов Microsoft.

По окончании установки предложат пройти Configuration Wizard (также доступно в меню Action → Configure из консоли Forefront Client Security), делаем это обязательно. Затем в консоли Forefront Client Security переходим на вкладку Policy Management и создаем политику.

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

Развертывание клиентских компонентов Forefront Client Security

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

Все клиентские компоненты и описания вирусов распространяются через WSUS. Если в вашей сети такая служба не развернута, то позор вам, быстрее разворачивайте. На компьютере, на котором установлена последняя версия WSUS (на момент написания статьи 3.0 SP2), запускать установку роли Distribution Server не нужно, так как эта роль была рассчитана на работу с WSUS версии 2.0.

Вместо установки роли Distribution Server проделайте следующие шаги в консоли WSUS:

• в Options → Products and Classifications включить Forefront Client Security, на вкладке Classifications должны быть отмечены как минимум Critical Updates, Definition Updates и Updates
• произвести синхронизацию WSUS
• найти поиском последнюю версию обновления «Client Update for Microsoft Forefront Client Security» и сделать Approve for installation для нужных групп компьютеров.
• создать правило Automatic Approvals для продукта Forefront Client Security с классификацией Definition Updates
• настроить автоматическую синхронизацию минимум пару раз в день

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

Советы и хитрости

Ускорение развёртывания Forefront Client Security

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

gpupdate /force для немедленного применения групповой политики
wuauclt /detectnow для немедленной проверки обновлений

О том, как запускать команды по сети на группе компьютеров, я недавно написал.

В зависимости от настроек Windows Update в вашей групповой политике, клиентские компоненты Forefront Client Security могут установиться мгновенно, могут быть запланированы на установку в определенное время, а могут и просто быть предложены пользователю.

После установки обновления агент MOM регистрируется на сервере MOM и какое-то время висит в его очереди на утверждение, бездействуя. Чтобы ускорить этот процесс, клиентов можно утверждать вручную в Administrator Console сервера MOM, в узле Administration → Computers → Pending Actions.

Объём базы данных Forefront Client Security

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

Чтобы избавиться от причин этих ошибок, увеличьте размеры БД, используя средство SQL Server Management Studio. Рекомендуемые размеры даны в статье «Влияние на системные ресурсы сервера».

Исключения для серверов

Если вы установили антивирус на сервера, в основном нагруженные каким-то определенным сервисом (таким как сервер БД, виртуальные машины, IIS, резервное копирование), то советую добавить исполняемые файлы сервера и/или области действия в файловой системе в исключения антивируса, чтобы не тормозило лишний раз. Более подробно рекомендую почитать в статье KB943556. Менее подробно, но более сжато и понятно — в этой записи блога Алексея Максимова.

Обновление

Для серверных компонентов Forefront Client Security выпущен Service Pack 1 и несколько обновлений. Не забудьте в своём WSUS одобрить эти обновления, либо загрузите их через Microsoft Update.

Развертывание Forefront Client Security на компьютеры рабочей группы (вне домена)

Все, что нужно для корректной установки Forefront Client Security на клиентский компьютер — это сформированные групповой политикой записи в реестре. Если нет возможности распространять настройки на компьютеры через групповую политику, то можно в Management Console сделать Deploy политики в файл. Затем скопировать этот файл и программу cslocalpolicytool.exe из дистрибутива FCS на клиентские компьютеры и выполнить команду

fcslocalpolicytool.exe /f /i имя_файла для применения политики.

После этого клиенты сами запросят и установят агент Forefront Client Security через WSUS. Также можно и просто запустить ClientSetup с диска, но зачем? Без правильного получения обновлений от WSUS вам все равно не получится пользоваться этим программным продуктом полноценно.

Установка Forefront Client Security без сервера управления

Такой вариант тоже возможен, если вы захотели установить агент Forefront Client Security на домашнем компьютере. Достаточно запустить

ClientSetup /NOMOM

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

Но есть и другой путь! Microsoft недавно выпустила бесплатный антивирус Microsoft Security Essentials, который представляет собой тот же агент Forefront Client Security, только лишенный централизованного управления. Для дома — самое то!

Ручная локальная установка обновлений Forefront Client Security

И такое возможно. Следуйте ссылкам в статье KB935934 для соответствующей разрядности ОС. Для локального обновления антивирусных баз агента Forefront Client Security достаточно просто запустить загруженный файл.

Принудительное обновление антивирусных баз Forefront Client Security

Можно форсировать установку обновлений с WSUS помимо стандартного цикла автообновления следующей командой:

"%ProgramFiles%\Microsoft Forefront\Client Security\Client\Antimalware\MpCmdRun.exe" -SignatureUpdate

Полезные ссылки

• Официальная документация
• Русский ТехЦентр
• Английский FAQ
• Блог разработчиков
• Блог поддержки
• Английский форум
• Русский форум линейки продуктов Forefront
• Error message when you open the Operator Console in Microsoft Operations Manager 2005: «Error connecting to server: localhost»
• Issues that you may experience after you install MOM 2005 on a computer that is running Windows Server 2003 with SP1
• Ознакомительная версия (120 дней) Forefront Client Security

Надежные источники сообщают, что новая версия продукта, которая будет называться Forefront Endpoint Protection 2010, запланирована к выпуску во второй половине 2010 года и будет основана на System Center Configuration Manager.

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

PS: Я часто использую полное название Forefront Client Security не потому, что плохо владею синонимами, а для облегчения поиска роботами. Слава роботам ;)

Начиная с Windows Server 2008 значительно повышена безопасность подключения к службам терминалов за счет использования двух технологий: SSL и NLA.

SSL

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

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

NLA

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

Совместимость с клиентами

Чтобы успешно подключаться к терминальному серверу, на котором активированы обе технологии, необходим терминальный клиент, поддерживающий протокол RDP 6.1. Этот протокол поддерживается клиентами, идущими в комлекте с ОС начиная с Windows Vista. Для Windows XP необходим установленный SP3 (либо обновление KB952155 для SP2) и кое-какая дополнительная настройка, описанная в статье KB951608.

Для включения поддержки CredSSP (через которую работает NLA) в RDP клиенте Windows XP необходимо внести следующие изменения в реестр:

• в параметре
  HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Control\ Lsa\ Security Packages
  добавить строку со значением
  tspkg
• в параметре
  HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Control\ SecurityProviders\ SecurityProviders
  в строку значений дописать
  credssp.dll

Для вступления изменений в силу нужно перезагрузить компьютер.

В недавно вышедшем Windows Server 2008 R2 протокол RDP обновлен до версии 7.0. Полная его поддержка встроена в Windows 7, для Windows Vista и Windows XP необходима установка обновления KB969084.