 TechNet Magazine May 2008

TechNet Magazine May 2008

Администрирование в Windows: Резервное копирование и восстановление Active Directory в Windows Server 2008

С появлением Windows Server 2008 и служебной программы «Архивация данных Windows Server» процедуры резервного копирования значительно изменились, причем в лучшую сторону. Эта статья представляет собой подробное руководство по резервному копированию и восстановлению службы Active Directory в новой версии операционной системы.

Gil Kirkpatrick Администрирование в Windows: Проектирование эффективной структуры подразделений

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

Ken St. Cyr Администрирование в Windows: Расширение схемы Active Directory

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

Vikas Malhotra System Center: Введение в System Center Mobile Device Manager

Новый диспетчер устройств System Center Mobile Device Manager предоставляет полный набор средств управления устройствами Windows Mobile через оснастку MMC или посредством Windows PowerShell. Познакомьтесь с тем, как это важное средство позволяет управлять мобильными устройствами, повышать безопасность и предоставлять возможности мобильных сетей VPN.

Matt Fontaine System Center: Новые функции в пакете обновления 1 (SP1) для System Center Essentials

В пакете обновления 1 (SP1) введены существенные усовершенствования для System Center Essentials 2007. Познакомьтесь с некоторыми из ключевых изменений, улучшающих обслуживание пользователей и упрощающих администрирование.

Pete Zerger От редактора: Теплый прием рубрики «SharePoint изнутри»

Joshua Hoffman Письма в редакцию: Мнения читателей

Инструментарий: Новые продукты для специалистов по информационным технологиям

Greg Steen Exchange в вопросах и ответах: Развертывание пакета обновления 1 (SP1) для Exchange Server 2007

В этом месяце мы отвечаем на вопросы, касающиеся пакета обновления 1 (SP1) для Exchange Server 2007.

Nino Bilic Обзор служебных программ: Планирование мощности SharePoint

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

Peter Skjøtt Larsen and Satish Mathew Sharepoint изнутри: Создание инфраструктуры SharePoint

Программа SharePoint предоставляет огромные возможности, но ее сложность может сделать разработку довольно сложной. Наша новая рубрика о SharePoint может в этом помочь. В этом первом выпуске представлен обзор инфраструктуры SharePoint и показана настройка основной инфраструктуры SharePoint при помощи WSS 3.0.

Pav Cherny Windows PowerShell: Автоматизация управления каталогом

Средства управления Active Directory, представленные в первой версии Windows PowerShell, не впечатляют. Автор статьи рассказывает о том, как с помощью надстроек можно расширить возможности работы с объектами Active Directory в Windows PowerShell.

Don Jones Эй, сценарист!: Поводя бровями на регулярные выражения

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

The Microsoft Scripting Guys На страже безопасности: Принципы квантовой безопасности

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

Jesper M. Johansson Материалы о рабочей среде: Расставаясь с администратором

Почему все работают в системе с правами администратора? Уэс Миллер рассматривает риски работы с правами администратора и изучает преимущества перевода пользователей (включая себя) на работу с правами пользователей.

Wes Miller Полевые заметки: Один компьютер, несколько мышей

Что делать, если студентов больше, чем компьютеров в аудитории? Отделение Microsoft Research в Индии нашло решение, которое называется MultiPoint и позволяет одновременно использовать несколько мышей одновременно на одном компьютере.

Kentaro Toyama О Windows из первых рук: Время 16-разрядных значков уже прошло

Рэймонд Чен объясняет, почему операционная система Windows Vista не поддерживает 16-разрядные значки, и интересуется, заметил ли это кто-нибудь.

Raymond Chen


 Администрирование в Windows: Резервное копирование и восстановление Active Directory в Windows Server 2008
Администрирование в Windows Джил Киркпатрик (Gil Kirkpatrick)

Резервное копирование и восстановление Active Directory в Windows Server 2008
Краткий обзор:
  • NTBACKUP или архивация данных Windows Server.
  • Средства и варианты резервного копирования.
  • Средства и варианты восстановления.
  • Основы построения разумной стратегии резервного копирования Active Directory.

Известно, что доменные службы Active Directory (ADDS) — один из компонентов, обязательных для функционирования инфраструктуры Windows. Если Active Directory выходит из строя, сеть, по большей части, становится бесполезной. Следовательно, планирование резервного копирования и восстановления Active
Directory является залогом безопасности, непрерывности бизнес-операций и соблющения всех норм и требований.
В Windows Server® 2008 появилось много новых функций, связанных с Active Directory®, две из которых имеют непосредственное отношение к планированию резервного копирования и восстановления: служебная программа «Архивирование данных Windows Server» и возможность использовать моментальные снимки Active Directory, сделанные при помощи службы теневого копирования томов. В этой статье мы расскажем о том, какие изменения произошли и каким образом новые функции упрощают резервное копирование и восстановление Active Directory.

NTBACKUP и архивация данных Windows Server
Параметры групповой политики
В программе «Архивация данных Windows Server» есть несколько параметров групповой политики, позволяющих отчасти контролировать процесс резервного копирования на серверах. Используя такие политики резервного копирования, можно устранить некоторые риски, связанные с несанкционированным созданием резервных копий для последующего доступа к данным. Варианты настройки:
Разрешить только арихивацию системы В этом случает программа архивации данных Windows Server включает в резервную копию только критические системные тома. Архивы томов не создаются.
Запретить архивацию данных в локальном хранилище. Этот вариант запрещает хранение резервных копий на локальном диске. Копии могут храниться только на сетевых ресурсах.
Запретить архивацию данных в общую сетевую папку В этом случае резервные копии нельзя хранить на сетевых ресурсах.
Запретить архивацию данных на оптические носители При таком варианте программа «Архивация данных Windows Server» не позволяет сохранять резервную копию на оптический носитель, к примеру записываемый диск DVD.
Запретить архивацию данных однократного запуска Этот параметр не позволяет выполнять в программе архивации незапланированное, одноразовое резервное копирование. Выполняться будут только те процедуры резервного копирования, которые запланированы через оснастку «Архивация данных Windows Server» консоли MMC.

Программа NTBACKUP, которую все знают и любят со времен выхода Windows NT® 3.5, ушла в прошлое. Ее заменила прогрмма архивации данных Windows Server. Новое средство – это не подлатанное средство NTBACKUP; в нем использована совершенно другая технология резервного копирования, которая заставляет по-новому подойти к вопросам резервного копирования систем.
Хотя «Архивирование данных Windows® Server» — единственная программа резервного копирования, поставляемая в составе Windows Server 2008, она по своей функциональности не является аналогом NTBACKUP. Главное отличие состоит в том, что программа архивирования данных не поддерживает резервное копирование на ленточные носители. Образы резервных копий можно записывать на локальные жесткие диски, на сетевые ресурсы, даже на внешние жесткие диски для порта USB и многотомные записываемые диски DVD. А на ленту нельзя. Впрочем, подключить ленту к серверу под управлением Windows Server 2008 и копировать на нее образ резервной копии Windows Server вы по-прежнему можете, но для этого придется использовать какие-то другие программы.
Программа NTBACKUP осуществляет резервное копирование и восстановление на уровне файлов, программа архивирования данных Windows Server — на уровне томов и блоков. Программа архивирования копируемый источник воспринимает как набор томов. Каждый том состоит из блоков диска. Такой метод гораздо эффективнее пофайлового резервного копирования системы. Кроме того, поскольку программа архивирования данных Windows Server работает на уровне блоков, она способна на основании снимков службы теневого копирования томов выполнять разностное резервное копирование, а также создавать мгновенные снимки для упрощения работы с несколькими резервными копиями (и в целях экономии места).
Но даже при полном резервном копировании программа архивирования данных позволяет оптимизировать расходование свободного пространства на тех дисках, где хранятся копии. Допустим, вы сохранили несколько полных резервных копий на один и тот же том. На тех дисках, где хранятся копии, программа архивирования данных Windows Server использует мгновенные снимки службы теневого копирования, а в мгновенных снимках регистрируются только те блоки, которые были изменены. Тем самым уменьшается суммарный объем нескольких полных резервных копий. Кроме того, не приходится проводить последовательные операции восстановления, как при работе с разностными резервными копиями. Хотя в мгновенном снимке хранится информация только об изменениях («разность» между резервными копиями), служба теневого копирования томов обрабатывает резервную копию таким образом, что система воспринимает ее как полную.
Однако нужно учитывать, что преимуществами службы теневого копирования томов можно будет воспользоваться только в случае резервного копирования на локальный жесткий диск. При копировании на диски DVD или сетевые ресурсы программа архивации данных работать со службой теневого копирования не может.
Еще одно преимущество программы архивации данных Windows Server состоит в том, что образы резервных копий хранятся в формате виртуального жесткого диска Microsoft® (VHD). Образ резервной копии, сделанный программой, можно подключить к виртуальной машине под управлением Microsoft Virtual Server 2005. То есть можно просто смонтировать образ VHD и найти нужный файл. При копировании на ленты пришлось бы восстанавливать их по одной, чтобы увидеть, на которой расположен нужный файл. (В качестве предупреждения: загрузить виртуальную машину с образа резервной копии не получится. Комплектация оборудования, зафиксированная в резервной копии, не соответствует настройке виртуальной машины, поэтому использовать программу архивации данных Windows Server в качестве средства для переноса из физической среды в виртуальную невозможно.)
Но у программы архивирования данных Windows Server есть и свои недостатки. Поскольку она воспринимает копируемый диск как набор томов и блоков, создать резервную копию отдельных файлов нельзя. Вы вынуждены копировать весь том целиком. И еще одна, более серьезная проблема: по умолчанию нельзя сохранить образ резервной копии ни на одном из архивируемых томов (правда, тут есть обходные вариснты настройки, см. support.microsoft.com/kb/944530). Это достаточно сильно отражается на резервном копировании состояния системы. Далее мы рассмотрим это подробнее.

Установка программы архивирования данных Windows Server
Программа «Архивирование данных Windows Server» — это один из компонентов системы Windows Server 2008, и по умолчанию он не установлен. Прежде чем программу использовать, ее нужно установить либо через диспетчер сервера, либо при помощи программы командной строки SERVERMANAGERCMD:
C:\> servermanagercmd -install Backup-Features
Программа архивирования состоит из двух частей: собственно программы «Архивирование данных Windows Server» и средств командной строки. Обратите внимание, что средства командной строки — это набор командлетов Windows PowerShellTM, а не средство WBADMIN.EXE. Если вы устанавливает обе части программы архивирования, необходимо также устрановить Windows PowerShell.
После установки программы в диспетчере сервера (в узле «Накопители») и в меню «Администрирование» появится соответствующая оснастка MMC. При установке программы архивирования данных Windows Server на Windows Server 2008 в варианте Server Core используйте команду OCSETUP (помните, что она зависит от регистра символов):
C:\> ocsetup WindowsServerBackup
Полное описание процесса установки приведено здесь: go.microsoft.com/fwlink/?LinkId=113146.
Программа архивирования данных Windows Server не может при восстановлении использовать образы, созданные программой NTBACKUP. На такой маловероятный случай Майкрософт предлагает загрузить программу NTBACKUP для Windows Server 2008 (go.microsoft.com/fwlink/?LinkId=113147).

Компоненты программы архивирования данных Windows Server
Приложение «Архивирование данных Windows Server» устроено совершенно новым образом. Оно состоит из четырех компонентов:
  • Пользовательский интерфейс MMC (WBADMIN.MCS).
  • Интерфейс командной строки.
(WBADMIN.EXE)
  • Служба резервного копирования (WBENGINE.EXE).
  • Набор командлетов Windows PowerShell.
При разбиении на клинтскую и серверную часть приложение обретает ряд преимуществ, главное из которых — повышенная надежность работы. Неважно, откуда вы инициируете резервное копирование, из клиента MMC или из интерфейса командной строки. И в том, и в другом случае вся нагрузка ложится на службу WBENGINE. Клиентская часть программы лишь оповещает о ходе выполнения резервного копирования. Если вы завершите работу клиента, операция копирования не прервется. Закроется только сам клиент — а служба продолжит выполнение операции. Конечно, при необходимости процедуру копирования можно тоже прервать, но сделать это нужно явным образом.
Еще одно преимущество клиент-серверной архитектуры — возможность управлять из клиента резервными копиями, хранящимися на удаленных компьютерах. Это особенно удобно при резервном копировании компьютеров с установками Windows Server 2008 Server Core.
Программа архивирования данных Windows Server поддерживает автоматическое восстановление системы. Для этого используется среда восстановления Windows (WinRE), которая поставляется вместе с другими компонентами на установочных дисках Windows Server 2008. Среда WinRE упрощает процесс восстановления сервера с нуля. Чуть ниже мы подробнее рассмотрим эту процедуру. Стоит отметить, что программа архивирования позволяет при управлении резервными копиями использовать несколько параметров групповой политики. Они перечислены на боковой полосе «Параметры групповой политики».

Служба теневого копирования томов
Программа архивирования данных Windows Server использует службу теневого копирования томов тремя способами. При запуске полного резервного копирования Windows Server 2008 программа первым делом создает теневую копию всех архивируемых томов. Это позволяет унифицировать представление файловой системы, с которой будет работать программа резервного копирования. (Примерно то же самое делала программа NTBACKUP.) Затем программа архивирования данных копирует блоки исходного тома, один за другим, в резервную копию, и в процессе создает по одному образу VHD на каждый архивированный том.
Если не указано обратное, программа архивирования также создает мгновенный снимок исходного тома, с тем чтобы служба теневого копирования могла отслеживать изменения блоков, входящих в него. Это позволяет программе архивирования данных Windows Server создавать разностные резервные копии на уровне блоков, для чего требуется считать лишь измененные блоки исходного тома. Программе не приходится считывать и записывать целый файл из-за одного изменившегося бита — она считывает и записывает только один блок.
Такой подход значительно повышает эффективность разностного копирования, но при этом увеличивается количество операций ввода-вывода для операций записи на исходном томе. Для наиболее активно используемых томов лучше отключить использование снимков службы теневого копирования на исходном томе, воспользовавшись ссылкой «Настройка параметров производительности» и затем отключив на этом томе разностное резервное копирование (см. рис. 1).
Figure 1 Disable incremental backups on busy volumes
Figure 1 Disable incremental backups on busy volumes
По завершении создания резервной копии программа архивирования данных Windows Server делает мгновенный снимок того тома, на котором хранится резервная копия (если копирование выполняется на локальный жесткий диск). Во время следующего резервного копирования старые файлы VHD заменяются. Но поскольку служба теневого копирования хранит теневые копии тома, на котором хранится резервная копия, в действительности в системе остается несколько версий каждого файла VHD, причем каждая представляет собой полную резервную копию. Для создания нескольких резервных копий вам нужно фактически создать одну полную копию, а потом сохранить информацию об изменении блоков.

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

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

Резервное копирование и восстановление состояний системы
Резервные копии состояний системы, в состав которых входят только отдельные файлы и некоторые базы данных (тома целиком в них не записываются), — средство весьма удобное, а порой даже необходимое. В первых сборках Windows Server 2008 резервное копирование и восстановление состояний не поддерживалось. Вместо этого можно было создать резервную копию важнейших томов системы (то есть тех томов, которые необходимы для восстановления и перезагрузки операционной системы и ключевых приложений). Такой вариант резервного копирования являлся аналогом резервного копирования состояния системы, только применялся он на уровне томов.
По просьбам пользователей разработчики Майкрософт добавили в программу архивирования данных Windows Server функцию резервного копирования состояния. Программа создает несколько файлов VHD по количеству томов, на которых хранятся данные о состоянии системы, но в файлы VHD копируются только необходимые файлы и базы данных. Во время резервного копирования состояния системы программа архивирования не создает моментальные снимки тома, на котором хранится резервная копия (в отличие от обычного резервного копирования). Вместо этого при каждом резервном копировании состояния создается совершенно новый набор файлов VHD, поэтому все преимущества с точки зрения экономии места на диске, которые дает использование мгновенных снимков, попросту пропадают.
Резервное копирование состояния системы осуществляется только при помощи программы командной строки WBADMIN.EXE. В оснастке MMC этой функции нет. Для создания резервной копии состояния системы используется следующая команда:
C:\> wbadmin start systemstatebackup
–backuptarget:e:
Программа WBADMIN копирует важнейшие системные файлы и базы данных приложений на указанный том в папку, предназначенную для резервных копий состояний системы. Одна такая резервная копия состояния контроллера домена под управлением 32-разрядной версии Windows Server 2008 при стандартном информационном дереве каталога (DIT) занимает чуть больше 6 ГБ — более чем на на 5 ГБ больше, чем для Windows Server 2003, отчасти из-за того, что программа архивирования данных Windows Server копирует основные файлы операционной системы, которые программа NTBACKUP не копировала.
Увеличилось и время резервного копирования состояния системы. Исходные значения, разумеется, были основаны на показателях предварительной версии операционной системы. Их необходимо проверить в рабочей среде, но скорее всего нужно быть готовым к тому, что резервные копии состояния будут занимать больше места (и отнимать больше времени) после перевода контроллеров доменов на Windows Server 2008.

Резервное копирование данных сервера при помощи оснастки MMC
При запуске оснастки MMC «Архивирование данных Windows Server» (см. рис. 2) вам предлагается либо запланировать резервное копирование, либо сразу же его выполнить. Мы проведем однократную архивацию.
Figure 2 Windows Server Backup MMC
Figure 2 Windows Server Backup MMC
Как видно из рис. 3, можно архивировать все тома сервера, а можно выбрать отдельные тома. Если выбрать вариант «Весь сервер», программа архивирования создаст резервную копию всех подключенных томов, но ее нельзя будет сохранить на жесткий диск, придется выполнять резервное копирование на записываемые диски DVD или на сетевой ресурс.
Figure 3 Using the backup configuration dialog to specify all or select volumes
Figure 3 Using the backup configuration dialog to specify all or select volumes
Мы собираемся провести резервное копирование на локальный жесткий диск, поэтому мы используем функцию выборочного копирования. После этого программа предлагает выбрать те тома, для которых будет создаваться резервная копия (см. рис. 4). По умолчанию флажок «Включить восстановление системы» уже установлен, и программа архивирования данных Windows Server включает в резервную копию загрузочный том, том операционной системы и другие тома, на которых имеются важные системные файлы и базы данных приложений. Для контроллера домена в копию также включается том, на котором размещен SYSVOL, информационное дерево каталога Active Directory и журналы Active Directory. Такое резервное копирование эквивалентно резервному копированию состояния системы с той лишь разницей, что в данном случае копируются тома целиком, а не только файлы. На самом деле, программа позволяет даже выполнить восстановление состояния системы на основании резервной копии, созданной в режиме включенного восстановления системы.
Figure 4 Selecting specific volumes to back up
Figure 4 Selecting specific volumes to back up
После выбора типа конечного носителя (локальный диск или сетевой ресурс) и собственно назначения программа архивирования данных предлагает выбрать режим резервного копирования: «Копирующая архивация VSS» или «Полная архивация VSS». На самом деле в обоих режимах все выбранные тома копируются целиком, хотя по названиям режимов можно предположить обратное. Разница между ними заключается в способе обработки исходных файлов после создания резервной копии. В режиме копирующей архивации программа архивирования оставляет файлы как есть. В режиме полной архивации выполняется перезагрузка архива.

Резервное копирование сервера из командной строки
Если нужно написать сценарий для процедуры резервного копирования (или создается резервная копия установки Server Core), можно воспользоваться программой командной строки WBADMIN.EXE. В программе WBADMIN имеется полный набор параметров, функции которых в основном совпадают с функциями оснастки MMC. В частности, планирование резервного копирование через командную строку тоже возможно.
Допустим, нам нужно запустить службу WBENGINE, которая выполнит резервное копирование. Для этого используется следующая команда:
C:\> wbadmin start backup –include:c:,d:
–backuptarget:e:
Для резервного копирования всех основных томов системы используется следующая команда:
C:\> wbadmin start backup -allcritical
–backuptarget:e:
После запуска резервного копирования программа WBADMIN продолжает работать, показывая ход выполнения процесса. Если завершить работу программы WBADMIN, резервное копирование продолжится в фоновом режиме. Чтобы снова подключить программу WBADMIN к выполняющемуся процессу копирования, мы используем следующую команду:
C:\> wbadmin get status
Чтобы завершить сам процесс создания резервной копии, нужно ввести в командной строке следующее:
C:\> wbadmin stop job

Планирование резервного копирования в оснастке MMC
Планировщик, встроенный в программу архивирования данных Windows Server, на самом деле имеет целью одно: упростить планирование ежедневного создания резервных копий, сохраняемых на локальный жесткий диск. Планировщик также позволяет организовать автоматическую смену томов, на которых хранятся резервные копии. Если вы используете жесткие диски, которые можно легко отключить от компьютера (к примеру, жесткие диски для порта USB), программу архивирования можно настроить таким образом, чтобы после сохранения копии можно было отключить диск, а на его место поставить другой — тот, на котором записана самая старая резервная копия.
Планировщик в программе архивирования данных Windows Server позволяет выполнять автоматически только ежедневное резервное копирование. Создать такое расписание, чтобы копии создавались, скажем, по понедельникам, средам и пятница, невозможно. Если не нужно архивировать данные ежедневно, придется работать непосредственно с планировщиком заданий Windows.
При запланированном резервном копировании на локальный диск всю подготовку диска берет на себя программа архивирования данных Windows Server: она форматирует диск, создает необходимую структуру папок и делает диск невидимым для проводника. Выбранные диск должен быть основным томом. Резервное копирование на динамический том не производится.
Запланировать резервное копирование через оснастку MMC несложно. В нашем примере нужно перейти ссылку «Расписание копирования», указать тип резервного копирования и архивируемые тома. После этого откроется диалоговое окно «Укажите время архивации» (см. рис. 5).
Figure 5 Specifying when daily backups should occur
Figure 5 Specifying when daily backups should occur
Выбрав время проведения архивации, мы указываем том (или несколько томов), на который будет производиться копирование. Мы выбрали том E: (см. рис. 6). Программа архивирования данных Windows Server пытается сама подобрать том, на котором будет храниться резервная копия, но если предложенный диск вам не подходит, можно нажать кнопку «Показать все доступные диски» и просмотреть список дисков, подключенных к компьютеру. Затем мы еще раз подтверждаем значения параметров в нескольких диалоговых окнах. Программа архивирования форматирует те тома, на которых будет храниться резервная копия, и создает расписание копирования при помощи планировщика заданий Windows.
Figure 6 Specifying the destination disk for a scheduled backup
Figure 6 Specifying the destination disk for a scheduled backup
После каждого резервного копирования по расписанию программа архивирования данных Windows Server создает мгновенный снимок тома, на который сохраняется копия. Каждые семь дней программа формирует новый базовый образ. Все операции фиксируются в журнале Microsoft/Backup/Operational. Там можно выяснить, успешно ли проведено резервное копирование. Можно также настроить событие, к примеру отправку сообщения по электронной почте, которое будет оповещать вас о результатах выполнения архивирования.

Планирование резервного копирования из командной строки
При планировании резервного копирования в установке Server Core, а также если нужно просто написать сценарий для процедуры архивирования, можно использовать программу командной строки WBADMIN. Чтобы создать расписание копирования, введите команду WBADMIN ENABLE BACKUP и укажите место хранения резервной копии, копируемые тома и время выполнения процедуры:
C:\> wbadmin enable backup –addtarget:e:
-include:c:,d: -schedule:06:00,12:00,18:00
Согласно приведенной команде, будет выполняться резервное копирование дисков C: и D: на диск E: три раза в день, в 6:00, 12:00 и 18:00 (обратите внимание, что время указывается в 24-часовом формате). Если нужно создать резервную копию всех важнейших томов системы (на основании которой можно будет потом автоматически востановить систему или восстановить состояние системы), замените параметр –include параметром –allcritical.
Программу WBADMIN можно также использовать для отмены запланированного резервного копирования:
C:\> wbadmin disable backup
При помощи этой команды можно удалить запланированные задания по резервному копированию, созданные планировщиком программы архивирования данных Windows Server, и высвободить тома, занятые под хранение резервных копий. Отметим, что для удаленного управления резервным копированием и восстановлением системы, установленной в режиме «ядра сервера» можно использовать оснастку MMC WBADMIN.

Восстановление системы контроллера домена на компьютере без ОС
Одно из самых значимых нововведений в средствах резервного копирования и восстановления связано с добавлением среды WinRE в процесс установки. При загрузке системы Windows Server 2008 с установочного диска программа предлагает вариант «Восстановление системы» (см. рис. 7). Его легко не заметить, если вы не ищете его целенаправленно.
Figure 7 The Repair your computer option is available on the installation screen
Figure 7 The Repair your computer option is available on the installation screen
Если в программе установки выбрать восстановление системы, Windows предложит указать вариант восстановления (рис. 8). Мы выберем вариант «Полное восстановление компьютера Windows», в результате чего будет вызвана среда восстановления.
Figure 8 Specifying system recovery options
Figure 8 Specifying system recovery options
После того как указана операционная система, которую нужно восстановить (обычно она всего одна), среда WinRE позволяет выбрать резервную копию, на основании которой будет выполняться восстановление. По умолчанию WinRE выбирает последнюю по времени создания полную резервную копию системы, но можно использовать и другую копию, хранящуюся на локальном диске или в файловом ресурсе на другом сервере.
Мы оставим последнюю полную копию. В следующем диалоговом окне (см. рис. 9) программа позволяет отформатировать диски и заново создать разделы. Это полезно в том случае, если причиной, приведшей к необходимости восстановления, был сбой диска, а также если вы подключили новые диски к серверу.
Figure 9 You can easily format and repartition disks before they're restored
Figure 9 You can easily format and repartition disks before they're restored
Затем идет несколько диалоговых окон, в которых вы подтверждаете выбранные параметры, после чего среда WinRE запускает процесс восстановления, и сервер перезагружается. Такой способ восстановления сервера на «голое» оборудование (без установленной ОС) довольно прост.

Восстановление состояния системы контроллера домена
Если восстановление требуется из-за того, что возникла какая-то проблема в работе Active Directory, к примеру нужно восстановить удаленное подразделение (OU), лучше восстановить предыдущее состояние доменных служб Active Directory, а не восстанавливать систему целиком. Несмотря на то что службы ADDS в Windows Server 2008 можно остановить, для восстановления состояния системы контроллера домена все равно придется загрузить сервер в режиме восстановления служб каталога.
Выбор режима загрузки в Windows Server 2008 стал несколько сложнее, чем раньше. Среда загрузки Windows полностью перестроена: теперь она поддерживает интерфейс EFI, файлы boot.ini не используются. Вместо них для контроля процесса загрузки в Windows Server 2008 применяются данные настройки загрузки (BCD).
Самый простой способ управления данными BCD предлагает программа командной строки BCDEDIT. Чтобы рассказать обо всех командах и параметрах программы BCDEDIT, потребовалась бы целая статья, так что здесь мы приведем лишь несколько полезных примеров.
Для перезагрузки контроллера домена под управлением Windows Server 2008 в режиме восстановления службы каталога используется следующая команда:
C:\> bcdedit /set safeboot dsrepair
Таким образом в записи начального загрузчика, используемой по умолчанию, указывается параметр safeboot. Если Windows Server 2008 устанавливается в первый раз, в нем есть только одна запись начального загрузчика, WINLOAD.EXE. Чтобы удалить параметр safeboot и загрузить систему в обычном режиме, используйте следующую команду:
C:\> bcdedit /deletevalue safeboot
Можно несколько упростить работу: настроить для контроллера домена две записи начального загрузчика, одну для обычной загрузки, а другую для загрузки в режиме восстановления службы каталога. После этого режим загрузки можно будет менять в диалоговом окне параметров загрузки и восстановления, доступ к которому можно получить через параметры системы. Для добавления новой записи начального загрузчика применяется следующая команда:
C:\> bcdedit /copy {default}
/d "Directory Service Repair Mode"
В этом случает новая запись создается путем копирования записи начального загрузчика, исопльзуемой по умолчанию. Программа BCDEDIT выдаст примерно такое сообщение:
The entry was successfully copied to
{c50d4710-a1f0-11dc-9580-0003ff402ae9}.
Выведенный идентификатор GUID присваивается новой записи. Чтобы включить в созданную запись параметр safeboot, используется следующая команда:
C:\> bcdedit /set {<GUID for new entry>}
safeboot dsrepair
После этого режим загрузки (обычный режим или режим восстановления службы каталога) можно будет выбирать в параметрах загрузки и восстановления (см. рис. 10).
Figure 10 Disable incremental backups on busy volumes
Figure 10 Disable incremental backups on busy volumes
Прежде чем запускать восстановление состояния системы при помощи WBADMIN, необходимо указать, на основании какой резервной копии оно будет проводиться. Программа WBADMIN позволяет выполнить восстановление состояния либо на основании полной резервной копии системы, либо на основании копии, содержащей основные тома, либо на основании резервной копии состояния. В каждом из этих случаев необходимо указать версию той резервной копии, которую вы намерены использовать. Версию копии проще всего узнать при помощи следующей команды программы WBADMIN:
C:\> wbadmin get versions
Программа WBADMIN отобразит список версий резервных копий примерно так, как показано на рис. 11. Для каждой копии указывается время создания, носитель назначения, идентификатор версии (представляющий собой, собственно говоря, дату и время начала процедуры копирования по универсальному среднему времени), а также список поддерживаемых типов операций восстановления.
Figure 11 Идентификация резервных копий, пригодных для восстановления (Close Figure 11)
wbadmin 1.0 - Backup command-line tool
(C) Copyright 2004 Microsoft Corp.
Backup time: 11/30/2007 3:47 PM
Backup target: Fixed Disk labeled E:
Version identifier: 11/30/2007-22:47
Can Recover: Application(s), System State
Backup time: 12/1/2007 10:46 PM
Backup target: Fixed Disk labeled Backup(E:)
Version identifier: 12/02/2007-05:46
Can Recover: Volume(s), File(s), Application(s), Bare Metal Recovery, System State
Backup time: 12/2/2007 5:58 PM
Backup target: Fixed Disk labeled Backup(E:)
Version identifier: 12/03/2007-00:58
Can Recover: Volume(s), File(s), Application(s), Bare Metal Recovery, System State
Backup time: 12/3/2007 11:25 AM
Backup target: Fixed Disk labeled E:
Version identifier: 12/03/2007-18:25
Can Recover: Application(s), System State
Мы выбрали последнюю по времени создания резервную копию и запустили восстановление состояния системы при помощи следующей команды WBADMIN:
C:\> wbadmin start systemstaterecovery
–version:12/03/2007-18:25
В этом случае происходит неполномочное восстановление. Если вы хотите выполнить принудительное восстановление каталога SYSVOL, нужно пометить восстановленную копию SYSVOL как доверенную, добавив параметр authsysvol в команду WBADMIN. Дополнительные сведения по этой процедуре приведены на странице go.microsoft.com/fwlink/?LinkId=113152.

Создание мгновенных снимков Active Directory
Одно из наиболее значимых изменений, коснувшихся Active Directory, никак не связано с программой архивирования данных Windows Server. В Windows Server 2008 большим плюсом является то, что Active Directory позволяет делать мгновенные снимки службы теневого копирования томов. Снимок представляет собой компактную резервную копию работающей службы Active Directory. Кроме того, создание такой копии занимает всего несколько секунд! Снимки можно монтировать и использовать в обычных служебных программах на основе LDAP, таких как средство LDP.
Для создания мгновенного снимка доменной службы Active Directory или службы облегченного доступа к каталогам используется команда NTDSUTIL:
ntdsutil: snapshot
snapshot: activate instance ntds
Active instance set to "ntds".
snapshot: create
Creating snapshot...
Snapshot set {42c44414-c099-4f1e-8bd8-4453ef2534a4} generated successfully.
snapshot: quit
ntdsutil: quit
Данная последовательность команд NTDSUTIL создает мгновенный снимок в формате службы теневого копирования томов, в который включаются те тома, в которых хранится информационное дерево каталога Active Directory, журналы и каталог SYSVOL. Несмотря на то что Active Directory все еще обновляется, служба теневого копирования использует стратегию «копирования при записи»: это гарантирует правильную обработку сделанных мгновенных снимков. Обратите внимание, что мгновенный снимок не является полной копией информационного дерева каталога. В нем содержится лишь набор блоков диска, относящихся к информационному дереву каталога, которые изменились с момента создания предыдущего снимка. Состыковав эти блоки с текущей копией информационного дерева каталога, VSS может сформировать информационное дерево каталога на момент создания снимка. На рис. 12 показано, как можно удалить старые или ненужные снимки.
Figure 12 Удаление ненужных мгновенных снимков (Close Figure 12)
C:\> ntdsutil
ntdsutil: snapshot
snapshot: list all
 1: 2007/12/03:23:18 {42c44414-c099-4f1e-8bd8-4453ef2534a4}
 2:   C: {c0dd71ba-5bcd-4daf-9fbb-5cfbdd168022}
 3:   D: {2bbd739f-905a-431b-9449-11fba01f9931}
snapshot: delete 1
Snapshot {c0dd71ba-5bcd-4daf-9fbb-5cfbdd168022} mounted as C:\$SNAP_200712032318_VOLUMEC$\
Snapshot {2bbd739f-905a-431b-9449-11fba01f9931} mounted as C:\$SNAP_200712032318_VOLUMED$\
snapshot: quit
ntdsutil: quit
C:\>

Подключение мгновенных снимков Active Directory
Чтобы иметь возможность пользоваться сделанными мгновенными снимками, нужно сначала научить службу теневого копирования, как сделать снимки доступными для файловой системы. Делается это при помощи команды ntdsutil. Она выдает список имеющихся мгновенных снимков и позволяет подключить нужный снимок (см. рис. 13).
Figure 13 Подключение мгновенного снимка при помощи программы ntdsutil (Close Figure 13)
C:\> ntdsutil
ntdsutil: snapshot
snapshot: list all
 1: 2007/12/03:23:18 {42c44414-c099-4f1e-8bd8-4453ef2534a4}
 2:   C: {c0dd71ba-5bcd-4daf-9fbb-5cfbdd168022}
 3:   D: {2bbd739f-905a-431b-9449-11fba01f9931}
snapshot: mount 1
Snapshot {c0dd71ba-5bcd-4daf-9fbb-5cfbdd168022} mounted as C:\$SNAP_200712032318_VOLUMEC$\
Snapshot {2bbd739f-905a-431b-9449-11fba01f9931} mounted as C:\$SNAP_200712032318_VOLUMED$\
snapshot: quit
ntdsutil: quit
C:\>
Команда list all перечисляет все имеющиеся снимки Active Directory, поддерживаемые в данный момент времени службой теневого копирования томов. Команда mount 1 монтирует выбранные мгновенные снимки томов, содержащих информационное дерево каталога Active Directory и журналы, открывая файловой системе доступ к ним. Расопложены они в каталогах C:\$SNAP_200712032318_VOLUMEC$\ и C:\$SNAP_200712032318_VOLUMED$\.
Если открыть указанный каталог, вы найдете в них все содержимое копированных томов на момент создания мгновенного снимка. Нужно отметить, что смонтированные мгновенные снимки предназначены только для чтения; изменять файлы, содержащиеся в них, нельзя.

Восстановление данных на основании мгновенных снимков Active Directory
Монтирование мгновенных снимков томов, содержащих Active Directory, кажется фокусом. Каким образом можно получить данные Active Directory, хранящиеся в снимках? Разгадка кроется в команде DSAMAIN. Это исполняемый файл, запускающий ADLDS. По сути своей, это автономный сервер LDAP, большая часть кода которого используется совместно с доменными службами Active Directory. Программу DSAMAIN можно использовать для того, чтобы превратить подключенные мгновенные снимки в некое подобие сервера LDAP, доступного только для чтения и содержащего данные Active Directory на момент создания снимка.
Рассмотрим следующую команду:
C:\> dsamain –dbpath
c:\$snap_200712032318_volumed$\ntds\dit
\ntds.dit -ldapport 10000
Она подключает файл ntds.dit, лежащий в папке c:\$snap_200712032318_volumed$\ntds\dit, и делает его доступным для любых операций LDAP по протоколу TCP через порт 10000 (можно указать любой другой открытый порт). Программа DSAMAIN открывает порт LDAPS (порт, используемый для операций LDAP с шифрованием SSL) на порте, номер которого отличается от указанного на единицу (в нашем примере это порт 10001), порт GC (порт, используемый для подключения к глобальному каталогу) на порте, отличающемся на две единицы (10002), и порт GCS (подключение к глобальному каталогу с шифрованием SSL) на порте, отличающемся на три единицы (10003).
Для доступа к подключенному дереву каталога через указанный порт можно использовать любую программу LDAP (например, LDP). В Windows Server 2008 компоненты Active Directory «Пользователи и компьютеры», «Сайты и службы» и «Домены и доверие», а также программа ADSIEDIT, изменены таким образом, чтобы их можно было подключать к информационному дереву каталога, смонтированному при помощи программы DSAMAIN. Если щелкнуть правой кнопкой мыши узел самого верхнего уровня в области переходов ADUC и выбрать пункт «Сменить контроллер домена», появится диалоговое окно, показанное на рис. 14. Если в нем ввести имя или IP-адрес того сервера, на котором размещен смонтированный мгновенный снимок, и порт (в нашем примере это localhost:10000), компонент ADUC подключится к смонтированномуснимку, после чего можно выполнить обзор содержимого каталога на момент создания снимка. Впечатляет, не правда ли?
Figure 14 Connecting Active Directory users and computers to a mounted snapshot
Figure 14 Connecting Active Directory users and computers to a mounted snapshot
Возможность такого доступа к данным упрощает многие задачи, связанные с восстановлением данных. Например, чтобы восстановить удаленный объект, раньше нужно было выполнить неполномочное восстановление резервной копии на имеющийся контроллер домена, а затем — принудительное восстановление удаленного объекта. Если в той копии, на основании которой вы провели восстановление системы, нужных данных не было, приходилось все начинать с начала. Теперь, благодаря возможности восстановления объектов-захоронений и использования мгновенных снимков, можете быстро найти и восстановить удаленные файлы, причем даже не нужно отключать контроллер домена.
Правда, существует несколько ограничений. Например, каждый активный мгновенный снимок повышает количество операций ввода-вывода, связанных с операциями записи в каталог, так что на производственном контроллере домена лучше не активировать более одного–двух мгновенных снимков одновременно. Кроме того, чем дольше снимок остается активным, тем больше становится разностное содержимое, хранящееся в службе теневого копирования томом, что тоже влияет на производительность. Ну и наконец, восстановление удаленного объекта — это лишь первый этап решения проблемы. Весьма вероятно, что после этого нужно будет также восстановить атрибуты, связанные с объектом, к примеру указания на членство в той или иной группе. Мгновенный снимок поможет определить, в какие группы входил удаленный объект.

Стратегия резервного копирования и восстановления Active Directory
В Windows Server 2008 представлена совершенно новая система резервного копирования и восстановления. Некоторые изменения поначалу могут сильно раздражать, но после того как отдел ИТ освоит все нововведения и встроит новую технологию в каждодневные процедуры резервного копирования, эффективность такой схемы становится очевидна.
Несмотря на значительные перемены в технологиях резервного копирования серверов, введенные в Windows Server 2008, базовая стратегия резервного копирования и восстановления Active Directory не так уж сильно изменилась. При формировании стратегии нужно учитывать следующее:
  • Необходимо запланировать и периодически проводить полное резервное копирование системы, чтобы можно было ее восстановить в случае сбоя оборудования. Частота создания копий зависит от того, насколько часто обновляются данные контроллера домена, насколько терпима система к простоям и потере данных, насколько трудоемко восстановление контролера домена с нуля.
  • Необходимо запланировать резервное копирование состояния системы и фиксировать изменения в Active Directory. Частота создания копий зависит от того, насколько безболезненно может пройти потеря данных Active Directory. Как минимум раз в день такое копирование стоит выполнять. Если оборудование позволяет, лучше всего хранить одну или две резервные копии состояния на локальном диске, а все предыдущие — записывать на диск DVD или сетевой ресурс.
  • Резервное копирование состояния системы нужно проводить не менее чем для двух контроллеров в каждом домене. Так вы в какой-то мере будете застрахованы в том случае, если одна из копий окажется поврежденной или недоступной.
Резервное копирование контроллеров домена следует проводить с учетом разделов приложений, если они определены. Подумайте о том, чтобы создать раздел среды восстановления Windows на контроллере домена: это позволит быстро загрузиться в режиме WinRE, если какой-то из основных системных дисков даст сбой.

Джил Киркпатрик (Gil Kirkpatrick) — руководитель технологического отдела компании NetPro и разработчик программного обеспечения для Active Directory с 1996 г. Вместе с Гвидо Грилленмайером (Guido Grillenmeier) из компании HP он поставляет популярные средства для аварийного восстановления Active Directory. Джил также является основателем конференции Directory Experts (www.dec2008.com).
© 2007 Корпорация Майкрософт и CMP Media, LLC. Все права защищены. Запрещается воспроизведение статьи или ее части без разрешения.


 Администрирование в Windows: Проектирование эффективной структуры подразделений
Администрирование в Windows Кен Сент-Кир (Ken St. Cyr)

Проектирование эффективной структуры подразделений
Краткий обзор:
  • Ключевые принципы правильного проектирования структуры подразделений.
  • Распространенные модели проектирования структуры подразделений.
  • Документирование структуры подразделений.

Не стоит недооценивать важность (и сложность) процедуры проектирования надлежащей структуры подразделений. Специалисты по ИТ склонны впадать в крайности: они
либо слишком много внимания уделяют структуре подразделений, либо вообще о ней не думают. И в том, и в другом случае это чревато возникновением проблем в модели Active Directory®.
Если вы слишком много внимания уделяете структуре подразделений, вы забываете о других аспектах проектирования Active Directory: о планировании топологии сайтов, о распределении размеров контроллеров доменов. С другой стороны, если отодвинуть планирование подразделений на второй план, страдают групповая политика и делегирование.
Однажды в оправдание мне привели следующий довод: структура подразделений — система гибкая, и если впоследствии что-то в ней не устроит, ее можно будет изменить. Да, действительно, структура подразделений имеет достаточный запас гибкости, но нередко оказывается, что изменить ее в процессе использования гораздо сложнее, чем казалось изначально. В структуру можно добавлять новые подразделения, а вот старые удалить не так-то просто.
Плохо спланированная структура подразделений запросто может отбиться от рук и начать жить самостоятельной жизнью. Если администратор не знает, в какую часть структуры подразделений поместить объект, созданный в каталоге, он либо создает новое подразделение, либо помещает объект наобум. В каждом из этих вариантов есть свои опасности. Создать новое подразделение труда не составляет, но с течением времени их будет сложно отслеживать. Слишком частое создание новых подразделений приводит к формированию хаотичной структуры и облегчает попадание в каталог недокументированных данных. С другой стороны, если добавить объект в подразделение, к которому он на самом деле не принадлежит, к объекту могут быть применены неверные политики, а доступ к объекту могут получить те пользователи, которые работать с ним не должны.
При проектировании структуры подразделений следует помнить вот такое уравнение: простота + адаптируемость = поддерживаемость. Слишком простая структура плохо адаптируется, и ее приходится часто менять. Слишком легко адаптируемая структура, в которой предусмотрено слишком много подразделений, оказывается чересчур сложной.
Существует три ключевых принципа, касающихся групповой политики, делегирования и администрирования объектов, которыми следует руководствоваться при проектировании подразделений. Они сводятся к трем вопросам, которые помогают создать структуру подразделений, способную пройти испытание временем и перестройкой организации:
  1. Нужно ли создавать это подразделение, чтобы применить к его членам уникальный объект групповой политики (GPO)?
  2. Нужно ли организовать доступ к объектам данного подразделения для какой-то конкретной группы администраторов?
  3. Приведет ли создание нового подразделения к упрощению администрирования объектов, относящихся к нему?
Если хотя бы на один из вопросов вы ответили «да», то, скорее всего, новое подразделение следует создать. Если на все три вопроса вы ответили «нет», то стоит попробовать найти более удачный вариант структуры. Прежде чем мы перейдем к практике применения упомянутых принципов, я объясню, почему они так важны.

Принцип 1. Групповая политика
Первый приницип проектирования подразделений — учитывать объекты групповой политики, применяемые к ним. Объект групповой политики позволяет в принудительном порядке настроить параметры для пользователей и компьютеров. В Active Directory можно определить различные объекты групповой политики, а потом применять их ко всему домену, к отдельным подразделениями или даже отдельным сайтам. Объекты групповой политики делятся на две категории: одни для пользователей, другие для компьютеров.
Политики для компьютеров и для пользователей можно определить в одном объекте групповой политики. В части «Конфигурация пользователя» в основном определяются возможности работы пользователя после входа в систему. Параметры такого рода имеются и в части «Конфигурация компьютера», но кроме них в ней есть и другие параметры, связанные с безопасностью компьютера. Например, там указывается, кто может входить в систему компьютера локально и как шифруются данные.
Вот несколько основополагающих моментов, о которых следует помнить при определении поддержки объектов групповой политики. Во-первых, несмотря на то что политики для компьютеров и для пользователей можно определить в одном и том же объекте групповой политики, размещать объекты, соответствующие пользователям и компьютерам, в одном подразделении не рекомендуется. Подобное объединение усложняет поиск и устранение неполадок, связанных с объектами групповой политики. Это становится абсолютно очевидным, если включить политику замыкания на себя.
Во-вторых, многие забывают, что объекты групповой политики можно применять на уровне сайтов, то есть и структуру подразделений можно формировать в соответствии со структурой сайтов. Такая модель подразделений весьма распространена, ее называют географической моделью. Мы поговорим о ней подробнее. С моей стороны было бы несправедливо отрицать, что географическая модель играет определенную роль в проектировании подразделений, но я не думаю, что удобство применения объектов групповой политики должно становиться решающим аргуметом в пользу даннной модели.
Кроме того, с точки зрения оптимизации работы с объектами групповой политики структура подразделений не должна быть слишком сложной. Создаваемое подразделение всегда должно расширять схему наследования объектов групповой политики. Если оно содержит серверы, требующие применения такой же политики, что и к другим серверам, можно попытаться поместить объекты создаваемого подразделения в более широкую группу (подразделение «Серверы»), а уже в ней создать несколько подразделений для разных типов серверов (см. рис. 1). Это упростит применение политик, поскольку к каждому компьютеру, входящему во вложенное подразделение, будет применяться как политика для подразделения «Серверы», так и другие конкретные политики для конкретного типа серверов.
Figure 1 Creating multiple OUs for different server types
Figure 1 Creating multiple OUs for different server types
Не менее важно помнить о том, что не следует без нуждя создавать и связывать несколько объектов групповой политики. Объект групповой политики позволяет создать одну политику и применить ее к нескольким подразделениям. Иногда это удобно, иногда нет. Если нужно изменить параметры объекта групповой политики, то при наличии сложной системы взаимосвязанных объектов групповой политики вы можете случайно изменить не тот объект. Чем больше связей, тем сложнее оценить фактические параметры политики. По этой же причине не следует создавать лишние политики, дублирующие друг друга. Если вы ловите себя на том, что вы часто поступаете именно так, измените структуру подразделений и примените другую модель наследования объектов групповой политики.
И наконец, практически всегда следует создавать разные подразделения для объектов-пользователей и объектов-компьютеров. По умолчанию объекты-пользователи и объекты-компьютеры размещаются в контейнерах, и поэтому объекты групповой политики нельзя связать с ними напрямую. Они привязываются в домене к контейнерам «Пользователи» и «Компьютеры», но если наследование нигде не блокировано, политики применяются ко всем пользователям и ко всем компьютерам домена. В Windows Server® 2003 можно при помощи средств rediruser.exe и redircomp.exe изменить стандарное расположение объектов-пользователей и объектов-компьютеров так, чтобы они размещались в созданных для них подразделениях.

Принцип 2. Делегирование
Важно, чтобы структура подразделений не противоречила схеме делегирования полномочий в домене. Помните, что при делегировании полномочий в Active Directory изменения полномочий применяются только к объекту. Если вы предоставите пользователю полный контроль над объектом-компьютером, он сможет изменять атрибуты объекта, но права администратора данного компьютера этот пользователь не получит.
Вот несколько рекомендаций, касающихся делегирования при проектировании подразделений.
При проектировании учитывайте наследование полномочий. Например, вам нужно, чтобы администраторы первого уровня могли менять пароли для большинства учетных записей. Существует отдельная группа пользователей, для учетных записей которых администраторы не должны менять пароли. Менять отображаемые имена для учетных записей не нужно.
В этом случае есть два варианта. Во-первых, можно создать два отдельных подразделения и в одно из них поместить тех пользователей, для которых пароль менять можно, а в другое — тех, для кого менять пароль нельзя. Но в таком случае, если нужно будет изменить параметры делегирования для всех пользователей, их придется менять по отдельности. Кроме того, тут мы нарушаем правило, согласно которому не следует без нужды создавать лишние связи (см. рис. 2).
Figure 2 Maintaining two separate parallel OUs
Figure 2 Maintaining two separate parallel OUs
Второй вариант — создать вложенное подразделение и применить явную запрещающую политику к подразделению, в которое входят те пользователи, для которых нельзя менять пароль. Любой, кто разбирается в делегировании, скажет вам, что применять явные запрещающие политики не рекомендуется, но в данном случае мы из двух зол выбираем меньшее (см. рис. 3). Можно либо дублировать параметры и поддерживать два отдельных подразделения, либо применить запрещающую политику к одному из подразделений. В долгосрочной перспективе второй вариант выигрывает.
Figure 3 Using an explicit deny permission
Figure 3 Using an explicit deny permission
Будьте внимательны при работе с контейнером AdminSDHolder. Приведенные выше решения можно использовать в том случае, если те самые «особые» пользователи не принадлежат ни к одной группе администраторов («Администраторы домена», «Администраторы схемы», «Администраторы предприятия» и просто «Администраторы»), поскольку полномочия для указанных групп применяются иначе. Смысл в том, чтобы не предоставить полномочия администратора по ошибке.
Если вы создадите отдельное подразделение для администраторов, вы заметите, что полномочия, которые вы им выдаете, исчезают. Причина связана с контейнером AdminSDHolder. Это специальный контейнер, который применяет свой список управления доступом к каждую учетную записи администратора через указанный промежуток времени. В результате все связанные с делегированием изменения, внесенные в учетную запись администратора, отменяются — за исключением тех, которые были внесены в контейнер AdminSDHolder. Это означает, что не следует отделять учетные записи администраторов от всех остальных учетных записей для делегирования. А вот для целей групповой политики их действительно лучше разделить — тем более в Windows Server 2008, где можно настроить несколько политик паролей.

Принцип 3. Администрирование объектов
Каждое новое подразделение должно упрощать администрирование объектов. Часто объекты, сгруппированные в подразделения, проще изменять (если изменения касаются их всех). Оснастка «Пользователи и компьютеры Active Directory» позволяет изменять некоторые атрибуты сразу для нескольких объектов. Если вам часто приходится менять атрибут для целой группы объектов, их лучше объединить в подразделение.
Такой прием особенно удобен, если обновление выполняется при помощи сценария. Языки сценариев позволяют без труда перечислить все объекты, входящие в подразделение, и обработать их один за другим. Альтернативный вариант — отыскивать и изменять объекты по одному. Объединение объектов в подразделения с целью администрирования иногда позволяет сэкономить несколько часов в неделю.
Еще один способ упростить администрирование объектов — разбить их на подразделения по типу. Если создать отдельное подразделение для объектов-принтеров или опубликованных общих ресурсов, их не придется отбирать при администрировании других объектов, входящих в одно подразделение с ними. Кроме того, такая практика согласуется с правилом разнесения учетных записей пользователей и учетных записей компьютеров по разным подразделениям.

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

Плоская модель
Плоская модель называется так, потому что она действительно практически плоская. Есть несколько подразделений верхнего уровня, и большинство объектов содержится в них (см. рис. 4). Такая модель чаще всего встречается в небольших организациях, где отдел ИТ невелик, где подразделений мало, где пользователи исполняют несколько ролей одновременно. Обычно я рекомендую не использовать в иерархии подразделений более 10 уровней, хотя специалисты Майкрософт отмечали снижение производительность лишь при превышении предела в 15 уровней.
Figure 4 The Shallow Model has a few high-level OUs that contain the majority of objects
Figure 4 The Shallow Model has a few high-level OUs that contain the majority of objects
Если ваш кадровик является еще и расчетчиком, нет смысла создавать два отдельных подразделения для этих обязанностей. В плоской модели все объекты-пользователи могут быть объединены в одно большое подразделение под названием «Учетные записи». А можно и оставить их в контейнере «Пользователи», используемом по умолчанию. По крайней мере, объекты-пользователи следует отделить от объектов-компьютеров.
В этой модели я бы посоветовал также отделить рабочие станции от серверов. Тогда можно будет применить к ним разные групповые политики, не используя в объекте групповой политики запросы WMI для отделения рабочих станций от серверов.
Преимуществом такой широкой, но неглубокой структуры подразделений является то, что поиск в Active Directory выполняется быстрее. Я обычно рекомендую использовать не более 10 уровней в иерархии подразделений. Контроль объектов в этой модели не слишком детализирован, но в небольшой компании этого и не требуется. На больших предприятиях такую структуру будет сложно использовать, а вот для малых предприятий она вполне подходит.

Географическая модель
В географической модели разные подразделения создаются для географически удаленных объектов. Она лучше всего подходит тем компаниям, в которых нет централизованного отдела ИТ, а повышение стоимости обслуживания, связанное с эекспуатацией нескольких доменов, недопустимо (см. рис. 5).
Figure 5 The Geographic Model separates OUs by geographical region
Figure 5 The Geographic Model separates OUs by geographical region
Допустим, у вашей компании есть офисы в Атланте, Балтиморе и Сиэттле. С точки зрения делегирования хорошо, если в каждом офисе можно организовать отдельное управление пользователями и компьютерами. Но что произойдет в таком случае, если, допустим, пользователь из Сиэттла отправится в Балтимор на семинар и заблокирует свою учетную запись? Специалисты по ИТ в Балтиморе не смогут ему помочь, если у них не будет полномочий на доступ к его учетной записи. Когда в Балтиморе 8 часов утра, в Сиэттле еще только 5. Значит, пользователю придется прождать несколько часов, прежде чем в Сиэттле кто-то появится в офисе.
В ряде международных компаний применяется так называемый принцип «подсолнечника»: обращения в службу поддержки направляются в центр, расположенный в том часовом поясе, где звонок попадает в рабочее время. Ни в одном офисе служба поддержки не работает 24 часа в сутки, и тем не менее сотрудникам, работающим поздно вечером, может быть оказана необходимая помощь, к примеру по разблокированию учетной записи.
В этой модели формирование подразделений на основании географического положения объектов не всегда является лучшим решением с точки зрения эксплуатации системы. Вам придется отдельно делегировать полномочия каждой региональной службе поддержки для каждого подразделения, содержащего пользователей. Однако если в каждом офисе есть отдел ИТ, такая модель может оказаться эффективной.
Географическую модель сложно реализовать на одном домене — из-за основных пронципов работы домена. Зачастую модель безопасности одного домена отличается от модели безопасности остальных. Это становится очевидным на примере корпоративных приложений, таких как Microsoft® Exchange.
Сервер Exchange в Атланте может использовать какие-то свои политики обмена сообщениями, но скорее всего ко всем серверам Exchange в организации применяется один и тот же объект групповой политики. Если это действительно так, то при размещении серверов Exchange в разных подразделениях (по географическому принципу) вы один и тот же объект групповой политики привязываете к нескольким подразделениям, что не нужно. В терминах делегирования вы должны спросить себя, действительно ли администраторам серверов Exchange нужны уникальные полномочия на доступ к объектам-компьютерам, соответствующим серверам Exchange. В большинстве случаев объекты-компьютеры разделяются на подразделения по географическому признаку из соображений простоты работы с групповой политикой, а не по принципу делегирования.

Модель на основе типов
В модели на основе типов объекты классифицируются по назначению (см. рис. 6). Чем был последний созданный вами объект, учетной записью пользователя, учетной записью администратора или учетной записью службы? В модели на основе типов эти объекты обрабатываются по-разному.
Figure 6 The Type-Based Model groups objects according to their functions
Figure 6 The Type-Based Model groups objects according to their functions
В большинстве случаев следует различать разные классификации объектов-пользователей. Скорее всего, вы будете применять разные политики — в зависимости от типа учетной записи. Например, не стоит позволять пользователям входить в систему компьютера с использованием данных учетной записи службы. Пароль к учетной записи службы обычно знают многие, поэтому определить, кто именно вошел в систему, сложно. Если возникнут какие-то проблемы, выяснить, какой пользователь работал в это время в системе, будет непросто. Для учетных записей службы можно настроить политику, предотвращающую интерактивный вход в систему. Такой прием отлично вписывается в иерархическую модель, приведенную на рис. 3.
Здесь наследование объектов групповой политики может пойти на пользу. Например, можно создать политику «Все пользователи», соотносящуюся с политиками, применяемыми ко всем объектам-пользователям. Кроме того, можно создать отдельную политику для учетных записей служб, основывающуюся на политике «Все пользователи». Такой подход гарантирует, что для учетных записей служб будет применяться такой же набор политик, что и для всех остальных учетных записей, а кроме них — дополнительные ограничения на вход в систему.
Эта схема неплохо работает и с точки зрения делегирования, где вместо наследования объектов групповой политики имеет место наследование полномочий. Допустим, вам нужно, чтобы администраторы второго уровня могли менять пароли для всех учетных записей, кроме учетных записей админстраторов третьего уровня. В плоской структуре подразделений вам пришлось бы делегировать полномочия каждому подразделению, содержащему учетные записи пользователей. В модели на основе типов, имеющей более глубокую иерархическую структуру, вы можете группе администраторов второго уровня выдать полномочие на изменение пароля в подразделении «Учетные записи», а в подразделении третьего уровня просто применить наследование полномочий или явным образом установить запрет на изменение паролей по инициативе администраторов второго уровня.
Этот подход в равной степени хорош с точки зрения объектов-компьютеров. Серверы и рабочие станции можно отделить друг от друга, что позволит применить к ним разные политики. Серверы можно дальше разделить по функциям (см. рис. 1). При такой схеме вы можете настроить политику верхнего уровня для подразделения «Серверы», которая будет распространяться на все серверы организации, и дополнительные индивидуальные политики для подразделений более низкого уровня.
Допустим, у вас есть учетная запись службы Microsoft Operations Manager (MOM). В многоуровневой модели вы можете создать объект групповой политики для MOM и применить его к подразделению, содержащему серверы MOM. Затем в созданном объекте групповой политики вы можете выдать службе MOM право на вход в систему в качестве службы. Оно будет применяться только к тем серверам MOM, которые входят в данное подразделение. На серверы MOM будет распространяться объект групповой политики, настроенный для более широкого подразделения «Серверы», но кроме него будет действовать еще и специализированный объект групповой политики, созданный непосредственно для подразделения MOM.

Документирование проекта
Структура подразделений, способная пережить многочисленные изменения среды Active Directory, имеет немало преимуществ. Но необходимо также какое-то средство, позволяющее отслеживать динамические характеристики подразделений. Если такого средства нет, среда очень быстро может выйти из-под контроля. На тот случай, когда действительно требуется что-то изменить, добавить или удалить подразделение, должны существовать четкие руководства на предмет того, как гарантировать, что и после изменения модель будет соответствовать изначальному проекту и следовать трем упомянутым принципам. Вот по этой причине и нужно обязательно хорошо документировать проект.
В комплекте ресурсов для Windows Server имеются пособия по документированию. Они полезны в том случае, когда структура поразделений представляет собой устойчивую систему, которая вряд ли будет сильно меняться. В большинстве же организаций, напротив, структура подразделений отличается динамичностью и часто меняется. Здесь я привожу несколько советов, как документировать структуру подразделений, сохранив ее способность поддерживать динамичность среды.
Документируйте только ту информацию, которая имеет отношение с структуре подразделений. Я твердо уверен в том, что у каждого документа должно быть свое предназначение. Очень часто в документах содержится так много ненужных сведений, что сложно докопаться до сути. Не стоит увлекаться документированием ради документирования. Так ли уж нужно вам записать количество объектов в каждом подразделении, зафиксировать каждый элемент списка управления доступом? Для документирования подразделения обычно достаточно указать следующие сведения:
  • Название подразделения.
  • Краткое описание.
  • Имя человека, создавшего подразделение, или контактные данные человека, с которым можно связаться, чтобы получить дополнительную информацию или внести изменения.
  • Дата и время создания.
Не затрудняйте обновление. Если, к примеру, обновление какого-то сложного документа Microsoft Word отнимает слишком много сил и времени, вы скорее всего перестанете вносить в него изменения. Если вы не вписали какую-то незначительную информацию, потому что знаете, что скоро будет более значительное изменение файла, то это не страшно. Но к сожалению, мы нередко просто забываем о подобных незначительных обновлениях или бесконечно откладываем их. Процесс обновления должен быть простым, он не должен вызывать приступов пессимизма. В большинстве случаев подойдет таблица Microsoft Excel® в несколько столбцов.
Используйте комментарии к объектам. У объектов подразделений есть атрибут описания, в котором можно хранить комментарии. Примечания можно записывать не в документ проекта, а непосредственно в атрибут описания. Так можно будет проще определить, для чего используется данное подразделение. А дополнительную информацию, если она необходима, можно хранить в документе для подразделения.
Автоматизируйте документирование. Вы можете создать сценарий, который будет записывать сведения о структуре подразделений в текстовый файл, таблицу Excel, файл HTML. Такой сценарий можно запускать по расписанию каждую ночь. Такой подход очень удобен, если вы используете поле описания подразделения. Содержимое поля переписывается в файл, и у вас всегда под руками имеется полная, обновленная документация по подразделению. Если при запуске сценария каждый раз создается новый файл, а не перезаписывается старый, можно вести учет изменений структуры подразделений.
К сожалению, многие администраторы недооценивают важность хорошей документации по структуре подразделений — до тех пор, пока она им самим не понадобится. А в 3 утра бывает весьма сложно выяснить, какие подразделения случайно были удалены по ошибке и не восстановлены.
Лучше не ждать, пока с вами такое приключится. Я настоятельно рекомендую принять меры заранее: начать вести документацию по структуре подразделений и назначть человека, ответственного за ее обновление. Если соблюдать правило простоты обновления документов, особых сложностей эта процедура вызывать не должна.

Кен Сент-Кир (Ken St. Cyr) — консультант в корпорации Майкрософт. В области ИТ он работает уже 10 лет. С самого появления Active Directory Кен занимался разработкой и внедрением решений служб каталогов на основе этой технологии.


 Администрирование в Windows: Расширение схемы Active Directory
Администрирование в Windows Викас Мальхотра (Vikas Malhotra)

Расширение схемы Active Directory
Краткий обзор:
  • Общие сведения о схеме Active Directory по умолчанию
  • Добавление объектов classSchema или attributeSchema
  • Получение и использование идентификаторов объектов
  • Расширение схемы с помощью файлов LDIF
Загрузить исходный код для этой статьи: Schema2008_05.exe (151KB)

С момента выпуска службы Active Directory в составе Windows 2000 корпорация Майкрософт предоставила пользователям определение базовой схемы для реализации Active Directory.
Выпуск Active Directory® также обозначил изменение процесса написания множества приложений и их реализации в Windows®. До этого такие приложения, как Microsoft® Exchange 5.5, создавались с собственной структурой каталога. После появления Active Directory множество приложений (корпорации Майкрософт и других компаний) начали использовать преимущество предоставляемой базовой структуры вместо создания собственной схемы с нуля.
Первоначально использовалась предоставляемая Active Directory базовая архитектура, которая затем при необходимости расширялась. В Microsoft Exchange 2000, например, служба Active Directory использовалась для реализации систем обмена сообщениями, тем самым определяя будущее архитектуры системы обмена сообщениями Microsoft.
Сегодня работа множества приложений, созданных для работы в среде Active Directory, основывается на ее базовой схеме, во многих приложениях также определяются необходимые собственные изменения схемы. Для этого, разумеется, необходима схема с возможностью расширения, что и будет рассмотрено в данной статье. Более того, поскольку многие приложения зависят от базовых определений в Active Directory, постоянная стабильность основной схемы является исключительно важной. Так как многие приложения должны совместно работать в одной службе Active Directory, изменения одного приложения не должны воздействовать на другие приложения.

Что такое схема?
Для многих схема Active Directory является чем-то вроде «черного ящика», а идея самостоятельного изменения схемы может быть для них пугающей. Конечно, расширение схемы Active Directory необходимо выполнять не каждый день, но для некоторых приложений или предприятий необходимо именно это. Поэтому очень важно понимать сущность схемы и ее состав, поскольку Active Directory – это важный актив многих организаций, нарушение работоспособности которого из-за неверного обновления может иметь серьезные последствия.
В качестве стратегии множество организаций используют службы Active Directory облегченного доступа к каталогу (ADLDS) в Windows Server® 2008 (или режим Active Directory Application Mode (ADAM) в Windows Server 2003) как альтернативу для тестирования или прямой реализации пользовательских определений схемы вместо расширения схемы Active Directory.
Схема – это базовая структура, предоставляющая формат для службы каталога. Схема Active Directory определяет атрибуты и классы объектов, используемые в доменных службах Active Directory (ADDS). Основная схема содержит определения для множества хорошо известных классов (таких как user, computer и organizationalUnit) и атрибутов (например, telephoneNumber и objectSID). Объекты в определении основной схемы называются объектами категории 1, а добавляемые объекты называются объектами категории 2.
Схема Active Directory находится в контейнере, определенном по пути cn=Schema, cn=Configuration,dc=X, где X – пространство имен леса Active Directory. Имейте в виду, что лес Active Directory содержит только одну схему; внесение изменений в определение схемы в лесу влияет на все домены в этом лесу. На рис. 1 показано количество классов и атрибутов, добавленных к схеме Active Directory в различных версиях Windows Server.
Figure 1 Количество классов и атрибутов (Close Figure 1)

Версия | Количество добавленных атрибутов | Количество добавленных классов | Файлы расширения схемы
Windows Server 2003 | 208 | 49 | От Sch14.ldf до sch30.ldf
Windows Server 2003 R2 | 81 | 29 | Sch31.ldf
Windows Server 2008 | 136 | 10 | От Sch32.ldf до sch44.ldf
Обновление схемы для различных версий Windows Server осуществляется с помощью служебной программы Adprep. При обновлении до Windows Server 2003 R2 версия схемы обновляется до 31, а при обновлении до Windows Server 2008 она обновляется до 44.
Номер версии можно узнать, проверив значение атрибута objectVersion по адресу cn=Schema,cn=Configuration,dc=X в Active Directory с помощью такого средства, как ADSIEdit. Обратите внимание, что некоторые приложения, например, Exchange Server, System Management Server (SMS) и другие приложения, зависящие от Active Directory, могут изменять схему в соответствии с требованиями приложения.

Базовые составляющие
Active Directory состоит из двух типов объектов: classSchema (кратко – class) и attributeSchema (кратко – attribute). Обычно расширение схемы Active Directory рассматривается, если для организации необходимо сохранение данных в определенных атрибутах, недоступных в существующей схеме. Атрибут в схеме Directory создается путем указания объекта attributeSchema в контейнере схемы и последующим определением необходимых свойств нового объекта.
Список свойств объектов attributeSchema и сведений о них приведен на веб-узле go.microsoft.com/fwlink/?LinkId=110445. Как видите, для объектов attributeSchema можно определить большое количество свойств, некоторые из которых являются обязательными.
Помимо обычных атрибутов в схеме также присутствуют специальные атрибуты, называемые связанными и реализуемые по парам путем указания ссылок вперед и назад. В качестве примера рассмотрим членство в группах в Active Directory. Атрибут членства любой группы (например, группы ContosoEmployees с членом John Doe) – это ссылка вперед, а соответствующий атрибут memberOf объекта члена – это ссылка назад (чтобы при запросе атрибута memberOf члена John Doe вычислялось различающееся имя (DN) группы ContosoEmployees).
Ссылка вперед работает аналогично любым другим атрибутам. Значения могут быть однозначными и многозначными (как и атрибут членства, который может содержать несколько объектов как членов группы) и сохраняются в каталоге вместе с родительским объектом.
Ссылки назад, напротив, поддерживаются системой для обеспечения целостности данных. При запросе значения атрибута ссылки назад результат вычисляется на основе всех соответствующих значений ссылки вперед. Ссылки назад всегда многозначны.
Все классы объектов в ADDS определяются объектом classSchema в контейнере схемы. Список атрибутов, наиболее важных для успешного определения объекта classSchema, приведен на веб-узле go.microsoft.com/fwlink/?LinkId=110445.
Существует три типа классов, которые могут быть определены: структурные, абстрактные и вспомогательные. Тип класса определяется значением атрибута objectClassCategory. (В четвертую категорию, известную как 88, входят классы, определенные до стандартов X.500 1993 года. Этот тип классов указывается значением 0 в атрибуте objectClassCategory. Данный тип более не должен определяться.)

Получение и использование идентификаторов
Удостоверения всех объектов classSchema и attributeSchema в каталоге определяются с помощью обязательных идентификаторов объекта (OID), governsID – для объектов classSchema и attributeID для объектов attributeSchema. Это уникальные числовые значения, предоставленные определенными центрами для идентификации объектов. Нумерация ведется в соответствие с определением протокола LDAP (RFC 2251). Некоторые идентификаторы объектов в схеме Active Directory выпускаются международной организацией по стандартизации (ISO) и корпорацией Майкрософт. Идентификатор объекта в каталоге должен быть уникальным.
Идентификатор объекта – это строка чисел, например, 1.2.840.113556.1.y.z, как показано на рис. 2. Таким образом, идентификатор объекта пользователя classSchema – 1.2.840.113556.1.5.9.
Figure 2 Идентификатор объекта пользователя (Close Figure 2)

Значение | Значение | Описание
1 | ISO | Определяет корневой центр.
2 | ANSI | Обозначение группы, присвоенное ISO.
840 | США | Код страны/региона, присвоенный организацией.
113556 | Майкрософт | Обозначение организации, присвоенное страной/регионом.
1 | Active Directory | Присвоено организацией (в данном случае Майкрософт).
Y | Тип объекта | Число, обозначающее различные типы объекта (категории), например, classSchema или attributeSchema. Например, 5 означает класс объекта.
Z | Объект | Число, обозначающее определенный объект в категории. Например, классу пользователя может быть присвоено число 9.
Когда организация собирается расширить схему, она обеспечивает уникальность идентификатора объекта путем получения собственного корневого номера OID, используемого для создания уникальных идентификаторов новых атрибутов и классов объектов организации. Корень идентификатора объекта может быть получено непосредственно от национального управления регистрации ISO (в США – американский национальный институт стандартов (ANSI)).
Процедуру и тарифы на услуги для получения корневого идентификатора объекта можно узнать на веб-узле ansi.org. В других регионах обратитесь в соответствующую организацию-участник ISO, список которых представлен по адресу iso.org/iso/about/iso_members.htm.
Ранее организации получали идентификатор объекта от корпорации Майкрософт путем отправки сообщения электронной почты по адресу schemreg@microsoft.com. Однако сейчас это приводит к получению автоматического ответа с предложением загрузить и выполнить сценарий VBScript с веб-узла go.microsoft.com/fwlink/?LinkId=110453.
Идентификаторам объектов, выпущенных корпорацией Майкрософт, присваиваются номера числового пространства идентификаторов объектов Microsoft: 1.2.840.113556.1.8000.x, где x – уникальный номер, присвоенный организации. Организация может разделить эти идентификаторы для указания объектов. Так, можно использовать 1.2.840.113556.1.8000.x.1.y для новых объектов classSchema и 1.2.840.113556.1.8000.x.2.z для объектов attributeSchema (где x – уникальный номер организации, а y и z - номера, присвоенные определенным объектам classSchema и attributeSchema соответственно). Кроме того, в целях различения в именах этих объектов рекомендуется использовать уникальный префикс организации.

Определение связанных атрибутов
Важно, чтобы значение attributeSyntax ссылки вперед было 2.5.5.1, 2.5.5.7 или 2.5.5.14. Эти значения соответствуют синтаксисам, содержащим различающееся имя, например, синтаксису Object (DS-DN).
Значение attributeSyntax ссылки назад должно быть 2.5.5.1, что является синтаксисом Object (DS-DN). Обычно атрибуты ссылки назад добавляются к значению mayContain класса с наибольшей абстракцией. Это обеспечивает чтение атрибута ссылки назад из объектов любых классов, поскольку такие атрибуты не сохраняются в объекте, а вычисляются на основе значений ссылки вперед.
В Windows Server 2003 появилась функция, которую могут использовать организации для связывания двух объектов в схеме: автоматическое создание идентификаторов linkID. Эта функция обеспечивает автоматическое создание идентификатора linkID для нового связанного атрибута, если для linkID атрибута установлено значение 1.2.840.113556.1.2.50. Соответствующая ссылка назад создается путем установки для linkID значения attributeId или ldapDisplayName ссылки вперед. Кэш схемы должен быть перезагружен после создания ссылки вперед и до создания ссылки назад. В противном случае при создании ссылки назад не будут найден атрибут attributeId или ldapDisplayName. Кэш схемы перезагружается по запросу через несколько минут после изменения схемы или при перезагрузке контроллера домена.
Если служба Active Directory работатет на уровне Windows 2000, необходимо запросить идентификаторы linkID от корпорации Майкрософт, отправив сообщение электронной почты по адресу schemreg@microsoft.com. В автоматическом ответе будет следующая строка: "E-mails sent to schemreg@microsoft.com will be processed only if they are related to linkID registrations for legacy environments." (Сообщения электронной почты, отправленные по адресу schemreg@microsoft.com, будут обработаны только в том случае, если относятся к регистрации идентификаторов linkID для устаревших сред.). Для этого необходимо указать в сообщении электронной почты следующие сведения: название компании, имя контактного лица, адрес электронной почты, номер телефона, зарегистрированный префикс (при необходимости), зарегистрированный идентификатор объекта (при необходимости).

Можно приступать к расширению схемы
Предположим, вы решили расширить схему Active Directory. Решение может предполагать прекращение использования альтернативного каталога, реализованного с помощью служб ADLDS (или ADAM в Windows Server 2003), после подтверждения того, что он не будет соответствовать требованиям. Следующим этапом является определение новых объектов attributeSchema, которые необходимо добавить к схеме; при этом определяются все необходимые значения (такие как cn, ldapDisplayName и т.д.), указывающие эти новые объекты. При определении значений атрибутов для объекта также получен идентификатор объекта от корпорации Майкрософт или из другого источника. Указанные выше действия задокументированы в качестве бизнес-требований и технических спецификаций. Более того, реализована экспериментальная лабораторная среда, имитирующая работу Active Directory и готовая к тестированию.
Многие организации создают специальные комиссии для утверждения или отклонения подобных изменений и установления процесса их реализации. Такая система сдержек и противовесов крайне важна, поскольку служба Active Directory используется в качестве достоверного источника информации во многих организациях, важность поддержания которого в работоспособном состоянии после внесения изменений нельзя преувеличить.
После того, как организация решает приступить к осуществлению проекта, необходимо определить планы тестирования и реализации проекта. Можно расширить схему путем добавления новых объектов с помощью оснастки схемы Active Directory консоли управления Microsoft (MMC) или используя программные или полупрограммные способы (например, использование LDIFDE для импорта файлов LDIF; использование CSVDE для импорта файлов CSV; или использование сценариев для интерфейсов ADSI).
Независимо от выбранного метода эта функция должна быть выполнена на сервере, который имеет роль FSMO (Flexible Single Master Operations) хозяина схемы в лесе Active Directory или подключен к ней. Кроме того, учетной записи, используемой для обновления схемы, необходимы достаточные права администратора для выполнения обновления, поэтому ее необходимо включить в группу администраторов схемы. Наконец, необходимо разрешить обновление схемы для леса (по умолчанию отключено).
Если только изменение не является простым, оно должно быть выполнено автоматически для обеспечения стандартизации между фазами тестирования и реализации, а также для предотвращения возникновения ошибок, возможных при выполнении действий вручную. Предположим, вы решили реализовать изменение с помощью инструмента LDIFDE. Для установки обновлений при расширении схемы необходимо добавить новые атрибуты и классы, добавить к классам новые атрибуты, а затем запустить перезагрузку кэша. Ниже приведены несколько примеров.

Добавление атрибутов
Для наших рассуждений предположим, что организации с названием Contoso необходимо добавить в службу Active Directory атрибут, определяющий размер обуви всех сотрудников. В лесу Active Directory два домена: contoso.com и employees.contoso.com. Необходимо, чтобы все объекты, созданные с помощью определения класса пользователя, также содержали этот новый атрибут.
Важно помнить, что изменение схемы влияет на оба домена, поскольку они находятся в одном лесе. Предположим, от корпорации Майкрософт получен идентификатор объекта 1.2.840.113556.8000.9999, который разделяется на 1.2.840.113556.8000.9999.1 для объекта classSchema и 1.2.840.113556.8000.9999.2 для attributeSchema компании Contoso. Теперь необходимо определить все значения атрибутов для этого нового объекта, как показано на рис. 3.
Figure 3 Определение атрибута contosoEmpShoe (Close Figure 3)

Атрибут | Значение | Примечания
Cn | contosoEmpShoe |
lDAPDisplayName | contosoEmpShoe |
adminDisplayName | contosoEmpShoe |
attributeSyntax | 2.5.5.12 | Определяет строку в юникоде.
oMSyntax | 64 | Указывает строку в юникоде.
objectClass | top, attributeSchema |
attributeID | 1.2.840.113556.8000.9999.2.1 | Определено организацией.
isSingleValued | TRUE | Сохраняется только одно значение размера обуви.
searchFlags | 1 | Анализ показывает необходимость индексирования этого атрибута. Примечание. Будет выполнен анализ нагрузки в лабораторной среде.
isMemberOfPartialAttributeSet | TRUE | Этот атрибут должен быть доступен в глобальном каталоге.
Кроме того, хотя атрибут contosoEmpShoe должен быть доступным для всех объектов, созданных в качестве объектов класса пользователя, не рекомендуется изменять определение класса пользователя по умолчанию. Вместо этого следует определить вспомогательный класс contosoUser, для атрибута mayContain которого установлено значение contosoEmpShoe, как показано на рис. 4. После этого необходимо добавить к классу пользователя атрибуты, определенные для вспомогательного класса contosoUser.
Figure 4 Определение класса contosoUser (Close Figure 4)

Атрибут | Значение
Cn | contosoUser
lDAPDisplayName | contosoUser
adminDisplayName | contosoUser
governsID | 1.2.840.113556.8000.9999.1.1 (определенное организацией)
mayContain | contosoEmpShoe
possSuperiors | organizationalUnit, контейнер
objectClassCategory | 3 (определяет вспомогательный класс)
Теперь, когда выполнен анализ и определены значения, необходимо создать файл LDIF, который будет выглядеть примерно как код на рис. 5. Можно скопировать код на рис. 5 в блокнот и сохранить файл под именем contosoUser.ldif (включен в материалы для загрузки по адресу technetmagazine.com).
Figure 5 .Файл LDIF для расширения схемы (Close Figure 5)
#Attribute definition for contosoEmpShoe

dn: CN=contosoEmpShoe,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: top
objectClass: attributeSchema
cn: contosoEmpShoe
attributeID: 1.2.840.113556.1.8000.9999.2.1
attributeSyntax: 2.5.5.12
isSingleValued: TRUE
adminDisplayName: contosoEmpShoe
adminDescription: contosoEmpShoe
oMSyntax: 64
searchFlags: 1
lDAPDisplayName: contosoEmpShoe
systemOnly: FALSE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

# Classes

dn: CN=contosoUser,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: top
objectClass: classSchema
cn: contosoUser
governsID: 1.2.840.113556.1.8000.9999.1.1
mayContain: contosoEmpShoe
rDNAttID: cn
adminDisplayName: contosoUser
adminDescription: contosoUser
objectClassCategory: 3
lDAPDisplayName: contosoUser
name: contosoUser
systemOnly: FALSE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

dn: CN=User,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemamodify
add: auxiliaryClass
auxiliaryClass: contosoUser
-

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
После создания файла LDIF необходимо тщательно протестировать реализацию в экспериментальной лабораторной среде, проверить сквозную репликацию домена и леса и разрешить обновление схемы в лесе. Теперь необходимо войти в систему с использованием учетной записи, имеющей права администратора схемы. Возможно, потребуется отключить исходящую репликацию на хозяине схемы (где будет внесены изменения) и выполнить следующую команду, чтобы импортировать файл LDIF:
ldifde –i –f <Path>\contosoUser.ldif –b
<username> <domain> <password> -k –j. –c
"CN=schema,CN=Configuration,DC=X"
#schemaNamingContext
После внесения изменений разрешите исходящую репликацию на хозяине схемы и убедитесь, что репликация выполнена для всех контроллеров доменов.
Глубоко вздохните — все готово! Вы определили в схеме новый атрибут, который будет связан с объектами, созданными с помощью класса пользователя (т.е. с учетными записями пользователей).
Для проверки изменений откройте оснастку «Active Directory – пользователи и компьютеры», подключитесь к домену employees.contoso.com, выберите организационное подразделение пользователей и создайте новую учетную запись пользователя с именем ContosoTestUser. Теперь откройте консоль adsiedit.msc и подключитесь к разделу домена dc=employees,dc=contoso,dc=com, разверните подразделение Users, правой кнопкой мыши щелкните ContosoTestUser, затем откройте страницу Properties (Свойства). Найдите атрибут contosoEmpShoe. Можно изменить этот атрибут, чтобы ввести значение. Также можно использовать служебную программу Ldp.exe для проверки и изменения атрибутов.
Теперь рассмотрим пример определения и связи двух атрибутов и представим, что для компании Contoso очень важен размер обуви сотрудников и ей необходимо отслеживать годовую производительность специалистов, измеряющих размер обуви сотрудников компании. Хотя это может показаться смешным, предположим также, что компании Contoso необходимо отслеживать не только лиц, ответственных за измерение размера обуви сотрудников, но также сотрудников, чей размер был измерен, и их количество — все путем запроса одного атрибута. (Хотя вы, возможно, полагаете, что для хранения подобных данных более подойдут таблицы базы данных, в данном случае мы просто преследуем цель объяснения работы ссылок вперед и назад.)
Конечно, сначала вы проделаете анализ, сходный с тем, который я упоминал в предыдущем примере. Однако сейчас пойдем дальше и создадим файлы LDIF (linkids1.ldif и linkids2.ldif), как показано на рис. 6. Затем выполним следующую команду, чтобы импортировать файлы LDIF:
Figure 6 Файлы LDIF ссылок вперед и назад (Close Figure 6)

#linkids1.ldif
#Attribute definition for Forward Link Attribute

dn: CN=ContosoShoeSizeTaker,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: top
objectClass: attributeSchema
cn: ContosoShoeSizeTaker
attributeID: 1.2.840.113556.1.8000.9999.2.2
LinkID: 1.2.840.113556.1.2.50
attributeSyntax: 2.5.5.1
isSingleValued: TRUE
adminDisplayName: ContosoShoeSizeTaker
adminDescription: ContosoShoeSizeTaker
oMSyntax: 64
searchFlags: 1
lDAPDisplayName: ContosoShoeSizeTaker
systemOnly: FALSE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

#Reload schema

#linkids2.ldif

#Attribute definition for Backward Link Attribute

dn: CN=ContosoShoeSizesTakenByMe,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: top
objectClass: attributeSchema
cn: ContosoShoeSizesTakenByMe
attributeID: 1.2.840.113556.1.8000.9999.2.3
LinkID: 1.2.840.113556.8000.9999.2.2
attributeSyntax: 2.5.5.1
isSingleValued: FALSE
adminDisplayName: ContosoShoeSizesTakenByMe
adminDescription: ContosoShoeSizesTakenByMe
oMSyntax: 64
searchFlags: 1
lDAPDisplayName: ContosoShoeSizesTakenByMe
systemOnly: FALSE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

#Add ContosoShoeSizeTaker and ContosoShoeSizesTakenByMe Attribute as MayContain in
#contosoUser class

dn: CN= contosoUser,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemamodify
add: mayContain
mayContain: ContosoShoeSizeTaker
mayContain: ContosoShoeSizesTakenByMe

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

#Add Backward Link Attribute as MayContain in Top

dn: CN=Top,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemamodify
add: mayContain
mayContain: ContosoShoeSizesTakenByMe

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1

ldifde –i –f <Path>\linkedids<>.ldif –b
<username> <domain> <password> -k –j. –c
"CN=schema,CN=Configuration,DC=X"
#schemaNamingContext
Теперь при создании объекта пользователя он также будет иметь атрибуты ContosoShoeSizeTaker и ContosoShoeSizesTakenByMe. При создании объекта пользователя, например, для Джона, атрибут ContosoShoeSizeTaker заполняется различающимся именем лица, измерившего размер обуви, – Фрэнка. Если теперь перейти к свойствам объекта пользователя Фрэнка и запросить атрибут ContosoShoeSizesTakenByMe, результат будет содержать различающееся имя Фрэнка и других лиц, чей размер обуви Фрэнк измерил. В завершение нашего случая руководство может вознаградить Фрэнка на основе количества различающихся имен, существующих в атрибуте ContosoShoeSizesTakenByMe его учетной записи пользователя.

Система сдержек и противовесов
Критическое обновление, каким является изменение схемы, не может быть выполнено без проверки соответствия архитектурным требованиям. Эти проверки безопасности и согласованности используются Active Directory для подтверждения того, что изменения не вызывают несоответствий или иных проблем при расширении или изменении схемы Active Directory.
Прежде всего, значение governsID для каждого класса должно быть уникальным в схеме. При определении объекта schemaClass все атрибуты, определенные в списках systemMayContain, mayContain, systemMustContain и mustContain, уже должны существовать. Одновременно с этим все классы, определенные в списках subClassOf, systemAuxiliaryClass, auxiliaryClass, systemPossSuperiors и possSuperiors, тоже уже должны существовать.
Кроме того, атрибут objectClassCategory всех классов в списках systemAuxiliaryClass и auxiliaryClass должен быть классом 88 или вспомогательным классом. Аналогично, атрибут objectClassCategory всех классов в списках systemPossSuperiors и possSuperiors должен быть определен как класс 88 или структурный класс.
При определении различных классов абстрактные классы могут быть порождены только от других абстрактных классов, вспомогательные классы не могут быть порождены от структурных, а структурные классы не могут быть порождены от вспомогательных классов. Кроме того, указанный в rDNAttID атрибут должен быть однозначным и иметь синтаксис в виде строки юникода.
Эти некоторые из правил, относящихся к объектам classSchema. Как насчет правил для объектов attributeSchema? Как и значение governsID для классов, значение attributeID должно быть уникальным. Кроме того, должно быть уникальным и значение mAPIID (если таковое имеется). Далее, если присутствуют rangeLower и rangeUpper, значение rangeLower должно быть меньше значения rangeUpper. Значения attributeSyntax и oMSyntax должны совпадать. Если синтаксис атрибута является объектным (oMSyntax =127), он должен иметь верный oMObjectClass. Идентификатор linkID, если таковой имеется, должен быть уникальным. Кроме того, ссылка назад должна иметь соответствующую ссылку вперед.

Что, если произошла ошибка?
После расширения схемы и добавления к ней новых объектов (классы и атрибуты) они не могут быть удалены. Однако классы и атрибуты могут быть деактивированы путем установки для атрибута isDefunct объекта схемы значения TRUE. Деактивация объектов схемы, которые входят в состав схемы по умолчанию, поставляемой вместе с Active Directory (объекты категории 1), невозможна. Деактивировать можно только объекты, добавленные к схеме по умолчанию, т.е. объекты категории 2, и только после проверки того, что класс не используется в списках subClassOf, auxiliaryClass или possSuperiors какого-либо существующего действующего класса.
При попытке отключения любого атрибута Active Directory проверяет, не используется ли он в списках mustContain и mayContain какого-либо существующего действующего класса. Отключенные объекты могут быть снова включены путем установки для атрибута isDefunct значения FALSE. Если Active Directory работает на уровне Windows Server 2003, можно повторно использовать значения ldapDisplayName, schemaIdGuid, OID и mapiID отключенных объектов.

Заключение.
При добавлении или изменении определений класса или атрибута в схеме также осуществляется добавление или изменение соответствующего объекта classSchema или attributeSchema. Этот процесс сходен с добавлением или изменением любого объекта в Active Directory, за исключением выполнения дополнительных проверок того, что изменения не вызывают несоответствия и не могут быть причиной проблем в схеме в будущем.
Хотя изменение схемы Active Directory – несложный процесс, важно понимать структуру схемы и процесс реализации этих изменений. Все изменения схемы Active Directory должны быть тщательно спланированы и выполняться очень осторожно. Важно определить бизнес-требования и технические спецификации для новых объектов и осуществить всестороннее тестирование. Поскольку изменения могут иметь существенный эффект, рекомендуется расширять схему Active Directory только в случае крайней необходимости.

Викас Мальхотра (Vikas Malhotra) – сотрудник консультационной службы корпорации Майкрософт в Нью-Йорке. За 12 лет в этом бизнесе он работал с отделами ИТ множества компаний крупного и среднего размера, помогая в разрешении их проблем архитектуры инфраструктуры, таких как службы каталога, системы обмена сообщениями, безопасность и сети передачи данных. Он имеет степени бакалавра технических наук по электронике и телекоммуникациям и магистра наук по управлению телекоммуникациями (технологии). Связаться с ним можно по адресу vikasmal@microsoft.com.


 System Center: Введение в System Center Mobile Device Manager
System Center Мэтт Фонтейн (Matt Fontaine)

Введение в System Center Mobile Device Manager
Краткий обзор:
  • Типичная система Mobile Device Manager
  • Распространение Active Directory на Windows Mobile
  • Регистрация, инициализация и инвентаризация устройств Windows Mobile

Запуск Microsoft System Center Mobile Device Manager 2008 открывает замечательные перспективы для специалистов по ИТ, управляющих устройствами Windows Mobile в корпоративных сетях. Предоставляя возможности по управлению устройствами, управлению безопасностью и виртуальную частную сеть (Virtual Private Network – VPN) мобильных устройств
в одном продукте, это новое предложение может помочь в понижении административных нагрузок и способствовать повышению окупаемости (return on investment – ROI) для групп мобильных устройств.
Mobile Device Manager позволяет специалистам по ИТ использовать существующую инфраструктуру Active Directory® и групповых политик для принудительной установки параметров устройств. Возможности по беспроводному (Over-the-air – OTA) управлению устройствами позволяют специалистам по ИТ легко доставлять на устройства обновления и приложения, в то время как беспроводная самоподготовка упрощает развертывание и повышает его масштабируемость. Виртуальная частная сеть мобильных устройств дает конечным пользователям доступ к данным и приложениям за брандмауэром, в то же время предоставляя постоянно работающее подключение для контроля развернутых устройств администраторами. С учетом того, что все эти возможности входят в один расширяемый, настраиваемый и масштабируемый продукт, Mobile Device Manager является важным средством для сегодняшних специалистов по ИТ.

Потребность в управлении
В обозримом будущем ожидается продолжение быстрого роста числа сотрудников, пользующихся мобильными устройствами. Исторически мобильными устройствами было сложнее управлять, чем другим сетевым оборудованием, в силу самого факта их мобильности. Они подключаются к сети широким набором способов, и некоторые устройства не так защищены, как прочие, – они могут существовать вне брандмауэра, использовать иные операционные системы, чем клиентские устройства, а в силу их малого размера их легко забыть или потерять.
Расширенные возможности современных мобильных устройств заманчивы как для предприятий, так и для конечных пользователей, но также усложняют поддержку этих устройств. Это может открыть корпоративные данные и сети дополнительным угрозам, особенно когда устройства используются для доступа к важным бизнес-приложениям и клиентским данным. Такие устройства могут создать критические для безопасности ситуации в случае их утраты, кражи или неверного использования.
По мере сокращения разницы в возможностях мобильных устройств и традиционных сетевых клиентов возникает растущая потребность в управлении мобильными устройствами таким же образом, как и портативными или настольными компьютерами. Ее порождением и является Mobile Device Manager. По мере того, как популярность платформы Windows Mobile® среди бизнес-пользователей продолжает расти, Mobile Device Manager становится важным аспектом систем управления информационными технологиями на основе Windows®.
Mobile Device Manager разработан, чтобы предоставить полный набор средств управления устройствами Windows Mobile, позволяющий осуществлять его так же легко, как если бы они были настольными или портативными ПК, объединенными в сеть. У него имеется три ключевых функции:
Управление устройствами Централизованная функция инициализации устройств Windows Mobile, наблюдения за ними и управления ими, масштабированная до десятков тысяч пользователей на каждый сервер.
Управление безопасностью Улучшенные механизмы защиты конфиденциальных данных и отслеживания устройств.
Мобильная частная виртуальная сеть Лучший доступ к находящимся за брандмауэром данным и постоянно работающим приложениям.
Mobile Device Manager создан в ключе общей философии System Center, предусматривающей предоставление специалистам по ИТ средств для управления корпоративными ресурсами в качестве привилегированных компонентов сети – на одном уровне с настольными и портативными ПК. Он также предоставляет интерфейс пользователя, который будет знаком тем, кто уже использует другие продукты System Center.
Это также значит, что Mobile Device Manager разработан для хорошего взаимодействия с существующей инфраструктурой на основе Windows. Если обратиться к примерам, он использует Active Directory и групповые политики; работает с существующими средствами анализа и отчетов Майкрософт (такими как SQL Server®); и расширяем с помощью использования оснасток консоли управления Microsoft® Management Console, а также командлетов Windows PowerShellTM.

Система Mobile Device Manager
Mobile Device Manager высоко масштабируем – один его экземпляр может поддерживать десятки тысяч устройств, а также различные варианты настройки. Говоря в общем, на стороне сервера в Mobile Device Manager имеются четыре основных компонента системы: сервер-шлюз, сервер управления устройствами, сервер регистрации и базы данных SQL Server (см. рис. 1).
Figure 1 Typical Mobile Device Manager system
Figure 1 Typical Mobile Device Manager system
Сервер-шлюз обычно устанавливается в граничной сети. Он служит терминалом для сетевого подключения устройства, проверяет подлинность входящих подключений устройств, предоставляет стабильные IP-адреса для устройств и выполняет другие функции, относящиеся к сетевым подключениям и подключениям устройств.
Сервер управления устройствами является узлом администрирования и управления устройствами, включая применение групповых политик, распространение программного обеспечения по беспроводной связи и стирание памяти устройств. Он работает с существующими контроллерами доменов. Серверы управления устройствами выступают в качестве заменителей сетевых клиентов для устройств Windows Mobile, позволяя этим устройствам сообщаться с другими системами.
Сервер регистрации создает объекты доменных служб Active Directory, представляющие мобильные устройства в контроллере домена, позволяя управлять этими устройствами подобно остальным членам домена. Этот сервер также занимается запросами и получением сертификатов для мобильных устройств. Он использует Active Directory как основу для проверки подлинности устройств перед тем, как принимать или выпускать сертификаты регистрации. Базы данных SQL Server предоставляют хранилище для всей информации, относящейся к настройке устройств, задачам, параметрам состояния и так далее.
После установки и запуска инфраструктуры Mobile Device Manager производит три типа взаимодействий с мобильными устройствами: регистрацию устройств, установка подключений виртуальной частной сети мобильных устройств и управление устройствами. Регистрация устройств – это процесс, в результате которого устройство присоединяется к домену Active Directory. Mobile Device Manager использует «общий секрет» – одноразовый пароль с коротким сроком действия – чтобы сделать возможной регистрацию устройств через небезопасные подключения. После регистрации устройство может осуществлять подключение по виртуальной частной сети к серверу шлюза, через который маршрутизируется сетевой трафик от устройства. Используя подключение мобильной виртуальной частной сети, администратор может осуществлять управление устройствами, направляя на устройство программное обеспечение и параметры.

Распространение Active Directory на Windows Mobile
Гибридные или специальные подходы к безопасности ИТ могут быть более рискованны, чем полностью интегрированный подход. Диспетчер Mobile Device Manager разработан, чтобы помочь в уменьшении подобных рисков, предоставляя способ управления мобильными устройствами, такими как ПК под управлением Windows, с использованием существующей инфраструктуры доменных служб Active Directory. Результатом является более простое управление идентификационными данными и доступом, более последовательный выбор целей для политик и выполнение всех настроек безопасности в одном месте.
Точно так же, как и в случае ПК или серверов, объекты групповой политики, относящиеся к устройствам Windows Mobile, могут быть выделены подразделениям, группам безопасности и фильтрам инструментария управления Windows (Windows Management Instrumentation). Администраторы могут также предотвратить получение параметров групповой политики определенными устройствами.
Существует свыше 130 параметров и политик для устройств Windows Mobile, что делает возможным детальный контроль над широким набором функций. Просто для примера:
  • В число параметров пароля входят требования к паролю; тип и минимальная длина; время истечения пароля и стирание памяти локального устройства после указанного числа неудачных попыток (включая уведомление пользователя о оставшемся числе попыток)
  • Параметры блокировки платформы позволяют администраторам включать или отключать по выбору функции устройств, включая камеры, беспроводные локальные сети, инфракрасные устройства, Bluetooth и съемные носители. Обмен сообщениями по протоколам POP и IMAP, а также службам SMS и MMS может быть отключен, равно как и служба обновления Windows для Windows Mobile.
  • Mobile Device Manager предоставляет детальный контроль над приложениями. Он может предотвратить запуск неподписанных приложений или приложений с неодобренными подписями на устройствах, либо допускать конкретные неподписанные приложения по усмотрению администратора.
  • Чтобы облегчить защиту данных, администратор может ввести принудительное шифрование файлов, хранящихся на съемных картах хранения (с ключом шифрования, привязанным к устройству). Для защиты важных данных на устройстве также доступно шифрование устройства. Помимо файлов, защищенных по умолчанию, администратор может указать дополнительные файлы, которые следует зашифровать.
  • Параметры виртуальных частных сетей мобильных устройств определяют уровень контроля пользователей над их подключениями к такой сети и также могут быть использованы для установки уровней шифрования данных.
  • Параметры ActiveSync® устанавливают формат сообщений, фильтры электронной почты, ограничения по размеру, параметры синхронизации и многое другое.
  • Параметры S/MIME могут требовать подписывания сообщений, шифрования сообщений или использования определенных алгоритмов.
Эти и другие параметры поддерживают широкий набор ситуаций. Они позволяют специалистам по ИТ решить, какие типы приложений могут работать на каких устройствах. Функции оборудования могут быть включены или отключены для беспроводной связи – например, камеры можно отключить, чтобы помочь в предотвращении случайной или намеренной компрометации важной информации. Шифрование данных может быть введено для устройств, съемных карт хранения либо и того, и другого, чтобы уменьшить риск попадания производственной информации в чужие руки через их потерю или кражу.
В Mobile Device Manager также входят другие средства безопасности. При наличии тысяч приложений, доступных для устройств Windows Mobile, для администраторов существует очевидная потребность в определении того, которые из них можно или нельзя установить. Mobile Device Manager позволяет создавать и обеспечивать соблюдение списков допуска и блокировки приложений именно для этой цели. Он также предоставляет широкие возможности по удаленному стиранию памяти. Благодаря постоянному подключению по виртуальной частной сети к устройствам память с устройств можно стирать немедленно, не ожидая их подключения к сети и синхронизации. При удаленном стирании памяти устройства оно удаляется из контроллера домена, и его сертификат отзывается. Если устройство затем восстанавливается, его можно установить на воссоединение с доменом после перерегистрации с помощью нового одноразового пароля.

Удержание мобильных устройств под контролем
Mobile Device Manager разработан, чтобы сделать управление устройствами Windows Mobile в сетях настолько простым, насколько это возможно, предоставляя полный набор функций по управлению мобильными устройствами в одном решении, включая беспроводную подготовку, беспроводное распространение программного обеспечения и обновлений, а также исчерпывающее и централизованное управление активами.
Беспроводная саморегистрация – свойство, которое может завоевать сердца занятых специалистов по ИТ и конечных пользователей. Пользователь вводит адрес электронной почты на устройстве Windows Mobile 6.1, которое пытается обнаружить сервер управления мобильными устройствами на основе этого адреса. Если сервер не найден, оно запрашивает пользователя ввести адрес сервера управления вручную. После того, как сервер найден и определено, что пользователь может зарегистрироваться, у пользователя запрашивается одноразовый секретный код, заранее созданный администратором.
Адрес электронной почты и секретный код используются для определения личности пользователя и регистрации его устройства на сервере управления. После того, как это сделано, устройству передаются определенные администратором параметры и политики. Подход с саморегистрацией разработан, чтобы повысить масштабируемость развертывания устройств Windows Mobile и сократить время и затраты, необходимые для ввода этих устройств в действие.
Возможности Mobile Device Manager по беспроводному распространению программного обеспечения основаны на службах обновления программного обеспечения Windows (WSUS) 3.0, наборе средств для обновления программного обеспечения, уже используемом многими специалистами по ИТ по всему миру. Как показано на рис. 2, WSUS 3.0 предоставляет функции выбора цели и комплектации пакетов приложений, необходимые для сложных потребностей ИТ. Программное обеспечение может автоматически доставляться на соответствующие устройства на основе правил и политик, установленных администратором. WSUS 3.0 позволяет автоматизировать обновления мобильных устройств, точно так же как обновления серверов и клиентов. И, что не менее важно, автоматически обновления можно отключить для планирования и тестирования развертывания.
Figure 2 Software distribution wizard
Figure 2 Software distribution wizard
Одной из крупнейших проблем при управлении мобильным оборудованием, развернутым в больших масштабах, является простое отслеживание всего. Mobile Device Manager централизует сведения о ресурсах и предоставляет гибкие, настраиваемые отчеты на основе SQL Server 2005 – опять же используя программное обеспечение, уже имеющееся у многих пользователей и знакомое им. Администраторы могут собирать более сотни элементов сведений о ресурсах, включая (но не ограничиваясь ими) сведения о операционной системе и ее версии, модели устройства, установленных приложениях и политиках безопасности. Список, создаваемый в результате инвентаризации, расширяем, что позволяет администратору добавлять элементы и параметры реестра.
Для дальнейшего повышения гибкости диспетчером Mobile Device Manager можно управлять с помощью оснастки консоли управления Майкрософт, если желателен графический интерфейс пользователя (см. рис. 3) или с помощью консоли Windows PowerShell, если предпочитается командная строка. В обоих случаях система расширяема и настраиваема – что важно для корпоративных пользователей, которым нужно, чтобы программное обеспечение подходило к запросам их организации.
Figure 3 Mobile Device Manager Console
Figure 3 Mobile Device Manager Console

Мобильная виртуальная частная сеть
Информационные работники уже не первый год обмениваются электронными письмами и сообщениями на мобильных устройствах. На данный момент одним из наиболее полезных нововведений в технологиях мобильных устройств является способность получения доступа к бизнес-данным и приложениям, защищенным брандмауэром. С повышением доступа возникают новые угрозы безопасности, так что необходимо тщательное управление добавленными функциями для предотвращения появления уязвимостей. Mobile Device Manager предоставляет самые современные возможности мобильной виртуальной частной сети, давая пользователям доступ к данным интрасетей от систем управления взаимоотношениями с клиентами (CRM) Microsoft DynamicsTM до SAP и Siebel. Модель построена для соответствия существующим стратегиям удаленного доступа для настольных и портативных ПК (см. рис. 4).
Figure 4 Mobile VPN settings
Figure 4 Mobile VPN settings
Виртуальная частная сеть подключает устройство к шлюзу при помощи функции безопасности двойного конверта, в которой данные передаются в зашифрованном с помощью SSL виде через зашифрованный с помощью IPsec туннель. После проверки подлинности устройства пользователь получает доступ к ресурсам в соответствии с указанным сочетанием политики отдельных ресурсов с учетными данными пользователя.
Технология мобильной виртуальной частной сети, используемая Mobile Device Manager, делает возможным создание постоянных подключений, которые не только дают пользователям улучшенный доступ, но и помогают специалистам по ИТ обновлять устройства последними параметрами и политиками – а также немедленно стирать память устройства в случае его кражи или потери. Даже в случае прерывания сеанса быстрое повторное подключение помогает обеспечить продолжение сеанса устройства без необходимости в повторной проверке подлинности. Mobile Device Manager обеспечивает плавный переход между Wi-Fi и сотовыми сетями, поддерживая при этом подключение.
Технология безопасности, используемая в мобильных виртуальных частных сетях Mobile Device Manager, основана на отраслевых стандартах, включая стандарт управления устройствами открытого сообщества производителей мобильной связи (OMA DM), версию 2 протокола IKE и стандарт объекта управления программным компонентом открытого сообщества производителей мобильной связи (SCOMO). Это помогает сделать систему более гибкой и приспосабливаемой к конкретным ситуациям, с которыми могут столкнуться специалисты по ИТ, работающие в сложных средах.

Полное решение
Mobile Device Manager предоставляет полный набор средств управления устройствами Windows Mobile, доступный через единый интерфейс. Он использует Active Directory и групповые политики для предоставления средств безопасности, которые помогают защищать данные, устройства и сеть. Управление устройствами упрощается посредством беспроводной регистрации, подготовки и обновления, а также разносторонними средствами инвентаризации. Частная виртуальная сеть мобильных устройств разработана для предоставления функций, необходимым предприятиям и пользователям, без ущерба для безопасности.
Все это является неотъемлемой частью идеи упрощения работы специалистов по ИТ посредством предоставления возможности управления мобильными устройствами как привилегированными компонентами сети. Mobile Device Manager дает специалистам по ИТ возможность предоставлять качественное обслуживание конечного пользователя, понижает административные издержки и предоставляет повышенную окупаемость вложений в управление – сочетание, заслуживающее внимания.
Я бы хотел выразить свою благодарность Брайану Хоскинсу (Brian Hoskins), Дереку Снайдеру (Derek Snyder), Притви Раджу (Prithvi Raj), Лаксу Мадапати (Lax Madapaty) и Катерине Холдсворт (Katharine Holdsworth) за их вклад в написание этой статьи.

Мэтт Фонтейн (Matt Fontaine) – внештатный разработчик технологической документации и консультант, работающий с компанией BuzzBee Company. Он оказывает услуги в широком наборе сфер, включая высокопроизводительные вычисления, корпоративное программное обеспечение, ведение страховой статистики, коммерческую недвижимость, проектирование, строительство и расфасованные товары. Мэтт является выпускником государственного колледжа Эвергрин и гордится этим.


 System Center: Новые функции в пакете обновления 1 (SP1) для System Center Essentials
System Center Пит Зергер (Pete Zerger)

Новые функции в пакете обновления 1 (SP1) для System Center Essentials
Краткий обзор:
  • Упрощенная установка с помощью интегрированного пакета установщика
  • Усовершенствованные переопределения для точной настройки пакетов управления
  • Поддержка рабочих групп
  • Новая задача повторного вычисления состояния работоспособности

Выпустив System Center Essentials 2007 в прошлом июле, корпорация Майкрософт выполнила свои обязательства перед предприятиями среднего бизнеса, заполнив разрыв между дорогостоящими, сложными корпоративными средствами и условно бесплатными
решениями, чтобы предоставить единое решение для управления эксплуатацией информационных систем. Пакет Essentials 2007 специально разработан для нужд среднего бизнеса, где специалисты по ИТ часто выполняют широкий набор задач.
Пакет Essentials прост в установке и настройке, что позволяет специалистам по ИТ проводить профилактическое наблюдение за клиентами и серверами и управление ими, а также отслеживать ресурсы оборудования и программ. Он разработан для решения традиционно сложных задач управления, например наблюдения за приложениями и службами ИТ, более простого и эффективного развертывания серверного и клиентского программного обеспечения, а также устранения проблем в настольных системах.
С момента первоначального выпуска корпорация Майкрософт собирала отзывы от пользователей, уже использующих пакет Essentials для управления своей информационной инфраструктурой, и эта информация включена в первый пакет обновления для него. Помимо простого устранения ошибок, в пакет обновления 1 (SP1) введены существенные улучшения, которые делают продукт более гибким при удовлетворении потребности клиентов в различных случаях развертывания. Более того, улучшения в производительности значительно улучшают обслуживание пользователя и упрощают администрирование.
В этой статье я рассмотрю ключевые улучшения, предоставляемые пакетом обновления 1 для Essentials 2007. Я также покажу, как они еще более упрощают управление средой.

Более простая установка
Интегрированный в пакет обновления 1 (SP1) установщик сводит воедино все исправления к Essentials на данный момент, делая установку простой задачей, требующей лишь нескольких действий. Пакет Essentials теперь можно также настроить на использование удаленного экземпляра 64-разрядного SQL Server® 2005, в то время как Essentials Server находится на 32-разрядном экземпляре Windows Server® 2003. Это дает администраторам повышенную гибкость в использовании существующей инфраструктуры сервера в их среде в распределенной топологии развертывания Essentials. Вдобавок, Windows Server 2008 будет поддерживаемой платформой для сервера, консоли и агента Essentials 2007 с пакетом обновления 1 (SP1). Полная поддержка Windows Server 2008 ожидается вскоре после выпуска новой ОС в производство.

Лучшая производительность консоли
Те, кто использовал окончательную первоначальную версию Essentials 2007, оценят значительно ускорившуюся реакцию на действия пользователя в интерфейсе консоли Essentials с пакетом обновления 1 (SP1). Производительность была улучшена в представлении предупреждений, событий, производительности, состояния и состояния задачи. Например, во всех представлениях предупреждений изменения в получении (извлечении) данных приводят к доходящему до трех раз ускорению выбора данных предупреждения. Действия и отчеты теперь получаются в фоновом режиме, что еще более поднимает производительность интерфейса пользователя. Аналогично, контекстно-зависимые задачи и отчеты (отображаемые на панели действий на правой стороне консоли операций) загружаются в фоновом режиме, позволяя представлениям быстрее отвечать на выборы пользователя.
Сведения ор разрешении проблем, связанные с предупреждением и отображаемые на панели сведений о предупреждении, теперь могут быть показаны или скрыты по выбору пользователя простым переходом по ссылкам Show Knowledge («Показать сведения о разрешении проблем») или Hide Knowledge («Скрыть сведения о разрешении проблем») (см. рис. 1). Выбор пользователя запоминается при просмотре будущих предупреждений. Также администраторы теперь могут выполнять копирование и вставку сведений о предупреждениях при помощи стандартных сочетаний клавиш (Ctrl+C и Ctrl+V).
Figure 1 Alert Details pane with Show/Hide Knowledge links
Figure 1 Alert Details pane with Show/Hide Knowledge links

Усовершенствования переопределений
Переопределения используются для настройки пакетов управления, отключения правил и мониторов, когда они не нужны, а также для коррекции различных пороговых значений. Внесено несколько существенных улучшений, относящихся к переопределениям, которые не только упрощают настройку правил и мониторов под нужды среды, но также предоставляют повышенную прозрачность переопределений, уже имеющихся в среде Essentials. Результатом является понижение потребности в создании новых правил и сокращение времени, уходящего на опознание имеющихся переопределений.
Например, после создания переопределения для любого объекта пакета управления теперь можно просмотреть сводку переопределения для типа объектов в поле сводки переопределений. Essentials 2007 с пакетом обновления 1 (SP1) гарантирует завершенность описания цели переопределения. Например, если создать переопределение для свободного пространства на логическом диске C:\ сервера Server1, в сводке отобразится 'server1/c:'. Важность этого изменения можно прояснить на примере.
Обратите на рис. 2 внимание на то, что в сводке переопределений для свободного пространства на логическом диске Windows Server 2003 в окончательной первоначальной версии Essentials 2007 невозможно сказать, на каком компьютере размещен диск C:\, являющийся целью переопределения. В той же сводке в пакете обновления 1 (SP1) можно обнаружить, что в столбце имени отображается не только экземпляр целевого диска, но также компьютер, на котором он находится (см. рис. 3).
Figure 2 Overrides Summary in Essentials 2007 RTM
Figure 2 Overrides Summary in Essentials 2007 RTM
Figure 3 The same Overrides Summary in Essentials 2007 SP1
Figure 3 The same Overrides Summary in Essentials 2007 SP1
Серьезность предупреждения может оказать значительное влияние на объем трафика предупреждений, собираемого администраторами. До настоящего момента, если правило Essentials в запечатанном пакете управления было настроено на создание критического предупреждения, не являющегося критическим на некоторых серверах, администраторы не могли изменить этот параметр, поскольку серьезность и приоритетность предупреждения не были открыты переопределениях правил. Единственным обходным путем было трудоемкое создание переопределений для отключения правила на некоторых компьютерах с последующим воссозданием правила в незапечатанном пакете управления, где параметрами предупреждения можно было манипулировать – явно не идеальная ситуация с точки зрения администратора.
Эта проблема прекрасно разрешается в пакете обновления 1 (SP1), где как серьезность, так и приоритетность предупреждения открыты как параметры переопределения во всех правилах запечатанного пакета управления, как показано на рис. 4. Таким образом, администраторы могут быстро и просто уменьшать или поднимать серьезность и приоритетность предупреждений, создаваемых правилами в Essentials 2007, при помощи переопределений.
Figure 4 Alert severity and priority rule overrides
Figure 4 Alert severity and priority rule overrides
Можно также заметить флажок Enforced («Принудительное») в рис. 4, отсутствовавший в интерфейсе консоли окончательной первоначальной версии Essentials. В случаях, когда для объекта включено несколько переопределений, большая приоритетность дается предупреждению с флажком Enforced. Это может быть полезным при установке одного переопределения для двух групп объектов и наличия у некоторых объектов членства в обеих группах. Выбрав режим Enforced для определения, которое должно иметь более высокий приоритет, можно быть уверенным в том, какой параметр переопределения будет применен.
Чтобы упростить создание новых пакетов управления, Essentials 2007 с пакетом обновления 1 (SP1) предлагает способность копировать представления из существующих пакетов управления в нераспечатанный пакет. Операция копирования поддерживается для всех типов представлений (таких как представления событий, предупреждений, производительности, цифровой панели и схем) и может быть выполнена в области наблюдения. Например, если создан пакет управления для переопределений Active Directory®, и необходимо использовать одно из представлений пакета управления Active Directory в пакете управления переопределений Active Directory, можно просто выбрать нужное переопределение и затем скопировать его в нужную папку пользовательского пакета на панели переходов в области наблюдения.

Новые отчеты о переопределениях
Также стоит упомянуть новый отчет о переопределениях в библиотеке Microsoft® Generic Reporting Library, расположенной на панели отчетов консоли Essentials. Этот отчет предоставляет точный способ описания переопределений с позиции пакета управления, в котором они хранятся, или соответственно пакету управления, к которому они применяются (см. рис. 5). Пользователи могут установить параметры отчета для исключения переопределений запечатанных пакетов управления из отчета. Это важный параметр фильтрации, поскольку запечатанные пакеты управления от Майкрософт и других поставщиков содержат много переопределений, которые не важны при создании отчетов об изменений в собственной среде пользователя.
Figure 5 Overrides Report parameters
Figure 5 Overrides Report parameters
Если следовать рекомендациям Майкрософт и создавать отдельный пользовательский пакет управления для каждого запечатанного пакета управления (один для пакета Active Directory, один для пакета Exchange и так далее), то появится возможность более эффективно сужать область отчета, чтобы просматривать переопределения, применяющиеся к определенному пакету управления.
После того, как выбран соответствующий незапечатанный пакет управления, можно запустить отчет, отображающий выходные данные, как показано на рис. 6. Обратите внимание, что отчет явно изображает правило монитора, к которому применяется переопределение (столбец элемента Affected («Затрагиваемые»)), а также даты и время установки и удаления, связанные с монитором. Это иллюстрирует тот факт, что отчет о переопределениях служит не только списком активных переопределений, но также и отчетом по журналу изменений настройки переопределений.
Figure 6 Overrides Report detail
Figure 6 Overrides Report detail
Наконец, внизу представления подробностей для каждого затрагиваемого правила или монитора можно найти ссылку, помеченную как представление настройки правила. Эта ссылка запускает отдельное представление правила или представление монитора с областью действия представления, уже ограниченной затрагиваемым типом объекта. Например, если щелкнуть ссылку настройки правила для переопределения, изображенного на рис. 6, которое является переопределением правила, целью которого является роль компьютера Active Directory Domain Controller Server 2003, обратите внимание, что получившееся представление правила отображает только правила, целью которых является этот тип объекта.

Поддержка компьютеров рабочих групп
Одним из важных пунктов в отзывах пользователей была необходимость в управлении серверами и рабочими станциями в топологиях рабочих групп. Во многих средах имеется минимум один сервер, расположенный в периферийной сети или в филиале, не включенном в домен. Поскольку Essentials требует взаимной проверки подлинности между сервером Essentials и управляемыми агентом компьютерами, машины в рабочих группах, находящихся вне границы доверия сервера Essentials, также выпадают за пределы развертывания агента Essentials. Во многих средах это означает оставление ключевых компонентов инфраструктуры ненаблюдаемыми и находящимися за пределами процесса управления исправлениями Essentials. Как безопасно управлять такими компьютерами?
В пакете обновления 1 вводится проверка подлинности на базе сертификатов для случаев, где проверка подлинности Active Directory или Kerberos недоступна. Для этого как на сервере Essentials, так и на управляемых компьютерах должен быть установлен цифровой сертификат X.509. Цифровой сертификат может быть выпущен самостоятельным или корпоративным корневым центром сертификации Windows®. Если таковой центр отсутствует в среде, его можно установить через установку/удаление программ на контроллере домена или сервере, являющемся членом среды, в том числе и на сервере Essentials. Дополнительные сведения о службах сертификатов и инфраструктуре общего ключа (Public Key Infrastructure – PKI) в Windows Server 2003 приведены на странице microsoft.com/windowsserver2003/technologies/pki.
Для настройки проверки подлинности на основе сертификатов в Essentials сперва запрашивается и выдается сертификат как для сервера Essentials, так и для компьютера, которым предстоит управлять. Запрос можно ввести через веб-узел на сервере, работающем как центр сертификации.
После того, как сертификат выдан и установлен, его необходимо «зарегистрировать» для использования при помощи Essentials, используя программу командной строки MOMCertImport. Для выполнения настройки сертификата его следует просто экспортировать в файл (формата PFX) и на локальном компьютере выполняется команда MOMCertImport со следующим синтаксисом:
MOMCertImport.exe <cert path \ name>
После исполнения всех этих действий на сервере Essentials и компьютере, которым предстоит управлять, эти системы могут взаимно проверить подлинность друг друга и затем безопасно обмениваться данными по зашифрованному каналу. Чтобы выполнить процесс развертывания агента, просто установите агент Essentials на целевой компьютер вручную.

Наблюдение за сетями и устройствами
Essentials 2007 предоставляет функции наблюдения за сетевыми устройствами, способные обнаруживать обычные атрибуты многих сетевых устройств, поддерживающих SNMP. Хотя SNMP версии 2c (SNMPv2c) является сегодня наиболее распространенной версией, сетевые устройства не созданы равными. С учетом этого в SP1 предоставлена поддержка SNMP версии 1 (SNMPv1), чтобы обеспечить наблюдение за рядом более старых сетевых устройств, включая некоторые ИБП, маршрутизаторы и серверы печати, не поддерживающие SNMPv2c. Как показывает рис. 7, администраторы могут сказать Essentials, какую версию SNMP использовать, через дополнительное раскрывающееся поле в мастере управления компьютерами и устройствами.
Figure 7 Enhanced interface for network device discovery
Figure 7 Enhanced interface for network device discovery

Усовершенствованное управление обновлениями
В пакете обновления 1 (SP1) также предоставлены значительные улучшения в управлении обновлениями. Правила автоматического утверждения служб Windows Server Update Services (WSUS) 3.0 позволяют указать различные классы продуктов и обновлений (например, автоматически утверждать все обновления определений для Microsoft Word).
В Essentials также добавлена поддержка нескольких правил автоматического утверждения, что доводит его функциональность до уровня платформы WSUS 3.0 (см. рис. 8). Это позволяет администраторам создавать автоматические утверждения для нескольких категорий обновлений, включая ключевые обновления Windows Vista® и пакеты обновления для выпуска 2007 системы Office. После этого правила автоматического обновления будут применяться ко всем текущим обновлениям на сервере WSUS. Как следствие, щелкнув задачу Run Rule(s) Now («Применить правило (-а) сейчас») в диалоге автоматических утверждений, администраторы могут немедленно применить изменения к существующим обновлениям, присутствующим в консоли Essentials.
Figure 8 Auto-Approvals in Update Management
Figure 8 Auto-Approvals in Update Management
Благодаря добавленной поддержке развертывания агентов на компьютерах в топологии рабочих групп администраторы смогут контролировать управление обновлениями для всей среды из консоли Essentials.

Вычисление состояния работоспособности объекта
Раньше при просмотре состояния мониторов в проводнике Health Explorer администраторам требовалось ожидать периодического обновления состояния монитора, чтобы определить, были ли успешными восстановления или другие действия по исправлению. В версии Health Explorer пакета обновления 1 (SP1) добавлена задача повторного расчета работоспособности, выполняющая повторный расчет работоспособности монитора по требованию (см. рис. 9). Это может существенно ускорить процесс устранения неполадок, устраняя минуты ожидания между действиями по исправлению, уходящие на ожидание возможности увидеть, вернулось ли состояние монитора к работоспособному.
Figure 9 Recalculate Health Task in Health Explorer
Figure 9 Recalculate Health Task in Health Explorer
Аналогично, задача сброса работоспособности (присутствовавшая уже в окончательной первоначальной версии) также претерпела значительные улучшения, чтобы гарантировать то, что каждый монитор реально ответит на запрос сброса его состояния работоспособности к работоспособному (зеленому). Это верно даже для запросов, исполняемых на самом сервере Essentials, который не всегда отвечал на запросы сброса в окончательной первоначальной версии.

Диагностика с помощью сценариев
Диагностика – это специальный тип встроенной задачи, новый для Essentials 2007, который делает возможным автоматическое или проводимое по требованию исполнение задач сбора данных при возникновении предупреждения. Автоматическая диагностика настраивается на выполнение при каждом переходе монитора в состояние ошибки. Результаты этой диагностики появляются в области сведений вкладки событий изменения состояния проводника Health Explorer. Диагностика по требованию появляется как гиперссылка в той же области и может быть выполнена путем простого перехода по ссылке. Результаты отображаются во всплывающем окне на локальном компьютере.
Как показано на рис. 10, в пакете обновления 1 расширены функции диагностики, что дает возможность использовать в ее задачах сценарии (в отличие от окончательной первоначальной версии, где использовались только ответы командной строки). Это предоставляет основу для исполнения более проработанных и разнообразных ответов для сбора данных при появлении условий ошибки. Обратите внимание, что для использования в этих задачах диагностики поддерживаются и VBScript, и JScript®.
Figure 10 Alert Details pane with Show/Hide Knowledge links
Figure 10 Alert Details pane with Show/Hide Knowledge links

Экспорт в Visio
Другой новой функцией в пакете обновления 1 является поддержка экспорта схем в формат Microsoft Visio® 2007 с помощью кнопки, появляющейся на панели инструментов при выборе пользователем представления схемы. Это предоставляет весьма удобную функцию документирования, поскольку в составе заводской поставки пакетов управления Active Directory и Exchange Server 2003 имеются детальные схемы топологии, что экономит ценное время администраторов, которое иначе ушло бы на написание документации. Более того, настройки компоновки схемы можно сохранить. Эти предпочтительные параметры будут запомнены консолью Essentials при следующем выборе представления схемы.

Улучшенное руководство по резервному копированию и восстановлению
Немедленно после установки Essentials 2007 с пакетом обновления 1 мастер установки автоматически предлагает пользователю создать резервную копию ключей шифрования сервера управления Essentials (см. рис. 11). Эта пара ключей используется сервером Essentials при безопасном хранении учетных данных запуска от имени в эксплуатационной базе данных. Эти ключи также требуется в случае необходимости восстановить сервер Essentials из резервной копии. Без этой пары ключей пакет Essentials потребуется установить заново и настроить с нуля.
Figure 11 Essentials encryption key backup
Figure 11 Essentials encryption key backup

Улучшенное качество пакетов управления
В добавление ко многим улучшениям для Essentials в пакете обновления 1 (SP1), группа разработчиков Essentials уверенно продвигается к улучшению качества пакетов управления для платформы Essentials с помощью более разнообразных и тщательных процедур тестирования, а также при помощи интенсификации взаимодействия с группами разработчиков других продуктов и специалистами по приложениям. Результаты отразятся в выпуске новых пакетов управления, которые будут пользоваться новыми функциями платформы наблюдения Майкрософт, включая самонастраивающиеся пороги, ориентированное на службы наблюдение, использующее модели распределенных приложений, а также многосторонний механизм отчетов.
Майкрософт начнет выпускать новые собственные пакеты управления, использующие новые функции Essentials, начиная с 2008 года. Пакеты управления для Essentials 2007 можно загрузить из каталога пакетов управления System Center на go.microsoft.com/fwlink/?LinkId=112399.

Попробуйте!
Пакет обновления 1 (SP1) предоставляет усовершенствования производительности, делающие System Center Essentials 2007 разумным объектом вложений для управления информационной инфраструктурой среднего бизнеса. Если в среде уже имеется Essentials 2007, загрузите копию пакета обновления 1 (SP1) и испытайте на себе улучшения в функциях и производительности. Если Essentials 2007 еще не развернут и имеется желание попробовать Essentials 2007 с пакетом обновления 1 (SP1), можно загрузить интегрированный с последним пакет установки. Оба пакета, а также дополнительные сведения о продукте можно найти на домашней странице Essentials 2007 по адресу microsoft.com/systemcenter/essentials.

Пит Зергер (Pete Zerger) работает консультирующим партнером в компании AKOS Technology Services и обладает девятью годами стажа в области ИТ. Он специализируется на проектировании и развертывании управления работой предприятий, служб каталогов и систем обмена сообщениями. Пит является сертифицированным системным инженером (MCSE) по обмену сообщениями (Messaging), сертифицированным специалистом (MCTS) по технологии SQL Server 2005 и обладателем звания MVP по Operations Manager. Он также является основателем популярного веб-узла сообщества systemcenterforum.org, посвященного Essentials 2007 и System Center Suite.


 От редактора: Теплый прием рубрики &#171;SharePoint изнутри&#187;
От редактора
Теплый прием рубрики «SharePoint изнутри»

Как вы, вероятно, помните из заметки редактора в предыдущем выпуске журнала, после своего прощания с рубрикой «Кабельщик» я упомянул, что в этом выпуске TechNet Magazine состоится дебют новой рубрики. Итак, приветствуем ежемесячную рубрику «SharePoint изнутри», в которой будет рассказываться обо всем, что необходимо знать специалисту по ИТ об архитектуре, развертывании, защите, поддержке и обслуживании инфраструктуры SharePoint. Как и было обещано, Пав Черны вернется к основам и представит обзор ключевых элементов инфраструктуры SharePoint. В статье этой рубрике в следующем выпуске журнала речь пойдет об администрировании узла SharePoint. Наше предложение по-прежнему в силе: если вы хотите, чтобы были рассмотрены какие-либо конкретные вопросы SharePoint, сообщите нам о них по адресу tnmag@microsoft.com.
Также в этом выпуске Джил Киркпатрик представляет глубокий и всесторонний обзор процесса резервного копирования и восстановления Active Directory в Windows Server 2008. В многих (если не всех) сетях Windows служба Active Directory является достоверным источником данных о доступе и идентификационных данных (которые, как, наверное, все согласятся, имеют огромное значение). Это также ключевой элемент инфраструктуры любого развертывания Exchange, SharePoint, Configuration Manager ... можно продолжать очень долго. Однако когда я присутствовал на выступлении Джила на конференции Directory Experts в Чикаго в прошлом месяце, он спросил, у кого из присутствующих имеется исчерпывающий план аварийного восстановления для Active Directory, поднятые руки можно было пересчитать по пальцам, вернее одну руку. Этого уже достаточно, чтобы сказать, что статью Джила должен прочитать каждый.
Если Active Directory – не ваша сильная сторона, что очень маловероятно, не беспокойтесь, для вас все равно останется много интересного. Мэтт Фонтейн представляет диспетчер System Center Mobile Device Manager (новая технология, крайне необходимая, если вы занимаетесь управлением устройствами Windows Mobile в вашей организации), Пит Зергер рассказывает о новых возможностях в пакете обновления 1 (SP1) для System Center Essentials, а Джеспер Йоханссон применяет принцип неопределенности Гейзенбега к информационной безопасности. Программисты как всегда с нами, новая статья из рубрики «Exchange Queue — очередь за ответами» и многое другое.
Наконец, мы работаем над проектом нового модного веб-узла TechNet Magazine (по-прежнему находится по адресу technetmagazine.com). Некоторые из наших любимых авторов разрабатывают обучающие демонстрационные ролики — размещенные на веб-узле видеоматериалы, прилагаемые к нашим статьям для поэтапного изучения содержания. Мы будем рады, если вы сообщите, какие темы и технологии хотели бы увидеть в этих демонстрационных роликах. Снова повторим, пишите на адрес: tnmag@microsoft.com. Спасибо! Джошуа Хоффман


 Письма в редакцию: Мнения читателей
Письма в редакцию
Мнения читателей

Кластеры Windows
Чем Windows® Compute Cluster Server отличается от обычного кластера Windows?
— из блога blogs.technet.com/tnmag

Об этом спрашивают довольно часто. Да и вообще, когда я рассказываю о Windows Compute Cluster Server (CCS), мне много вопросов задают о повышении доступности при помощи кластеризации (отказоустойчивой кластеризации). Вычислительные кластеры отличаются от кластеров, используемых для повышения доступности служб в системах.
Вычислительный кластер при помощи очереди заданий или планировщика распределяет задания по системам, входящим в кластер. Планировщик (он располагается на головном узле кластера) получает запрос на задание и назначает вычислительный узел, который будет его выполнять. Короче говоря, CCS позволяет раздать работу компьютерам, а отказоустойчивая кластеризация применяется для обеспечения непрерывности работы служб.
— Джон Келбли (John Kelbley), старший технический руководитель

Графический интерфейс Robocopy
Хочу поблагодарить вас за статью про графический интерфейс Robocopy (ноябрь 2006 года, technetmagazine.com/issues/2006/11/UtilitySpotlight). Он здорово упрощает работу с Robocopy. Кроме того, он помог мне понять назначение многих параметров командной строки.
— Бифф М. (Biff M.)

Спасибо за вашу оценку. Мы очень рады, что это средство вам пригодилось. Если вы хотите, чтобы в журнале TechNet Magazine появились обзоры каких-то других программных средств, дайте нам знать. Пишите по адресу tntools@microsoft.com.

Драйверы для устройств
Естьли способ составить список всех файлов, относящихся к выбранному драйверу устройства?
— T.P.

Если вам нужен список файлов, поддерживаемых при использовании конкретного драйвера, то, к сожалению, тут никакого удачного решения не существует. Проще всего заглянуть в файл INF, прилагаемый к драйверу, а именно в раздел, помеченный *.copyfiles: в нем есть информация, связанная с идентификатором Plug-n-Play (PnPID). Там вы найдете список файлов, скопированных во время установки драйвера.
Немного сложнее ситуация с так называемыми драйверами CoInstallers, которые являются составляющими более крупных драйверов. Они могут извлекать и устанавливать еще и другие файлы. И все же, проанализировав раздел CopyFiles, вы сможете найти большую часть файлов, нужно только как следует разобраться в том, что написано в файле INF.
— Уэс Миллер (Wes Miller), ведущий рубрики «Материалы о рабочей среде»

Проверка подлинности Windows
Мы пытались найти статьи или какие-то официальные документы, содержащие информацию по проверке подлинности Windows. Точнее говоря, нам нужна информация о беспроводных способах работы со службой IAS в домене Windows 2000 Active Directory®. Не могли бы вы дать ссылки на такие статьи?
— Бретт М. (Brett M.)

Лучшм источником информации для вас станет, пожалуй, IAS TechCenter на веб-узле TechNet: technet.microsoft.com/network/bb643123. Там есть несколько статей и документов по проверке подлинности с применением службы IAS.
Еще один полезный интерактивный ресурс, где вы можете задать все интересующие вас вопросы, — это группа новостей по системе безопасности Windows 2000 (microsoft.com/technet/community/newsgroups/dgbrowser/en-us/default.mspx?dg=microsoft.public.win2000.security).

Благодарный читатель
Я прочел замечательную статью «Руководство по основам расследований на компьютерах» — она была в декабрьском выпуске журнала за 2007 год (technetmagazine.com/issues/2007/12/Forensics). Во-первых, здорово, что вы публикуете такую важную информацию. Во-вторых, я хотел бы поблагодарить Тома Кловарда, руководителя программ в Майкрософт, за то что он поделился своим опытом в области безопасности. И еще Франка Симурджи, технического руководителя и специалиста по вопросам безопасности, тоже работающего в Майкрософт. Вы работаете с системами безопасности и с готовностью делитесь своими знаниями в области решения проблем, связанных с атаками через Интернет. Это более чем похвально. Огромное вам спасибо.
— некто S.

Спасибо за ваше письмо, уважаемый S. Мы тоже считаем, что все это очень важно. Думаем, вы бедете рады узнать, что в ближайших выпусках журнала TechNet Magazine планируется опубликовать еще несколько статей на эту тему. Еще раз спасибо!


 Инструментарий: Новые продукты для специалистов по информационным технологиям
Инструментарий
Новые продукты для специалистов по информационным технологиям
Грег Стин (Greg Steen)

Анализ дискового пространства
FolderSizes
foldersizes.com
Как узнать, что именно поглощает все пространство на жестком диске компьютера клиента? Можно применить монитор дискового пространства, сообщающий, что компьютер приближается к своему пределу емкости, но определение того, как очистить диск, чтобы вернуться к разумному объему свободного пространства, порой может стать тяжким трудом. Одна из служебных программ, которая может помочь в определении, что именно занимает пространство на диске, – FolderSizes от компании Key Metric Software.
При первом запуске этого приложения оно дает краткое описание своего интерфейса пользователя, чтобы помочь приступить к работе (хотя и является весьма незамысловатым). Чтобы проанализировать диск или папку, достаточно дважды щелкнуть ее в иерархической панели обозревателя папок (Folder Browser). После того, как программа FolderSizes проанализировала цель, она предоставляет график использования диска и представление папки, показывающее, сколько места занимает содержимое каждой папки. Одного щелчка достаточно, чтобы изменить визуализацию папок между секторной диаграммой и гистограммой, чтобы получить понятие о том, куда девается пространство на диске. Лично я нахожу гистограмму наиболее полезной при работе с несколькими одноуровневыми каталогами.
Дважды щелкнув сегмент гистограммы, сектор или папку, можно войти в подпапку. Такой способ перехода делает простым и быстрым переход к потенциальным проблемным точкам, таким как «скрытый» каталог файлов mp3, который пользователь назвал «Представления продаж». Либо, при наличии пользователя с пунктиком на документах, желающего держать все и вся на своей машине, можно провести упорядочение по дате последнего изменения, чтобы увидеть, к каким файлам доступ не производился очень долго. Это является хорошим аргументам для пользователя в пользу того, что архивация этих файлов на компакт-диске или их удаление не причинит проблем.
Другая интересная функция – предоставляемая FolderSizes возможность настраивать число уровней, которые следует представить в диаграмме. Например, можно просмотреть диаграмму всех папок на диске разом, упорядоченных от самых больших к самым маленьким, что позволяет выявить проблемные точки. После обнаружения такой точки можно щелкнуть ее правой кнопкой мыши, чтобы вызвать действия "command prompt from here" («командная строка отсюда») и "explore this folder" («исследовать эту папку»). Это позволяет запускать любые другие служебные программы или проверки по мере необходимости.
В составе FolderSizes также имеется встроенный генератор отчетов, дающий еще один набор представлений содержимого целевой файловой системы. Здесь можно, например, найти самые большие файлы определенного типа или самые старые файлы в системе; можно найти временные или дублирующиеся файлы; можно найти все файлы только для чтения и можно определить все файлы, имеющие конкретного владельца на файловом сервере. И так далее, и тому подобное. А после создания отчета представление можно профильтровать, распечатать или даже экспортировать в форматы XML, HTML или CSV.
В дополнение к этому, FolderSizes также предлагает отличный способ упрощения резервного копирования, гарантирующий, что взяты для архивирования будут лишь те файлы, которые надо. Можно также использовать интерфейс командной строки приложения для создания сценариев и автоматизации проверок клиентских и серверных систем. Так что тем, кому нужен быстрый способ выявления того, куда девается дисковое пространство на серверных или клиентских компьютерах, стоит попробовать FolderSizes.
Цена: от 50 долларов США (за лицензию на одного пользователя).
FolderSizes offers chart visualization of system folders
FolderSizes offers chart visualization of system folders

Управление учетными записями пользователей
Inactive Users Tracker (Средство отслеживания неактивных пользователей)
netwrix.com/inactive_users_tracker_freeware.html
Чем больше организация, тем проще терять из виду неактивные учетные записи пользователей. И, в терминах безопасности, наличие процесса, гарантирующего возможность отследить эти неактивные учетные записи пользователей и отключить либо удалить их, устраняя потенциальную брешь в безопасности, не может быть плохой идеей. Inactive Users Tracker, бесплатная служебная программа от NetWrix Corporation, предоставляет простой способ сделать это.
Это средство периодически проверяет домены Active Directory® на предмет наличия неактивных пользователей и отправляет список неактивных учетных записей на выбранный адрес электронной почты администратора. В нем можно указать, каким доменом следует управлять, а также какая учетная запись имеет полномочие на проверку Active Directory на предмет неактивных учетных записей. Вдобавок, можно установить число дней, в течении которого учетная запись должна быть неактивной, чтобы оказаться помеченной как таковая и включенной в уведомление по электронной почти. И, само собой, можно создать расписание запуска процесса.
Не считая этого, сервер SMTP просто настраивается на передачу уведомлений на адрес администратора и указывается, следует ли служебной программе фильтровать неактивные учетные записи пользователей используя фильтр имен – например, все учетные записи консультантов могут начинаться с "c_".
Доступна также коммерческая версия программы (предложения с расценками ориентируются на клиентов, покупающих продукт). Эта версия позволяет модифицировать сообщения электронной почты, отправляемые пользователем, поддерживает автоматическое отключение неактивных записей пользователей и включает техническую поддержку.
Цена: распространяется бесплатно
Inactive Users Tracker notifies you about inactive users
Inactive Users Tracker notifies you about inactive users

Усовершенствование обмена сообщениями по электронной почте
Служебные программы электронной почты Exclaimer Mail Utilities 2007
exclaimer.com/MailUtilities2007.aspx
С одной стороны, в нынешнем, все более зарегулированном и сутяжническом мире для организаций крайне важна защита сообщений электронной почты. В тоже время, согласованное оформление связи и узнаваемая марка фирмы помогают организации строить отношения между собой и теми, с кем она общается. Набор служебных программ Exclaimer Mail Utilities 2007, созданный для работы с Exchange Server 2007, может помочь в обеих областях.
Приложение имеет три основные функции, помогающие объединять и защищать электронную почту организации: заявления об отказе от ответственности, настройку фирменного стиля и подписывание. Вдобавок, имеется возможность добавления модулей, помогающих бороться с нежелательной почтой и вирусами.
В плане заявлений об отказе от ответственности Exclaimer Mail Utilities помогает снизить риск судебного преследования и повысить соответствие нормативным требованиям, таким как Закон об отчетности в области медицинского страхования (HIPAA) и Циркуляр 230, добавляя индивидуализированное сообщение (появляющееся до или после текста электронного письма) к каждому письму, покидающему организацию. Что касается настройки фирменного стиля, можно легко добавить изображение и ярлык фирменной марки к каждому посылаемому сообщению, чтобы обеспечить единообразный вид всех сообщений, отправляемых клиентам. Что касается подписывания, можно обеспечить автоматическое применение подписи к каждому сообщению, отправляется ли оно со смарт-устройства, Microsoft® Outlook® Web Access или со стандартного клиента Outlook. Подпись автоматически создается из данных, которые, вероятно, уже хранятся в дереве Active Directory. Средство можно настроить на изменение этих подписей в соответствии с рядом факторов, включая то, отправляется ли электронное письмо внутреннему или внешнему получателю, кто является отправителем, кто является получателем и какова тема письма.
Расценки на Exclaimer Mail Utilities 2007 зависят от числа пользователей и начинаются от 245 долларов США за 25 пользователей, со скидками по мере роста их числа. Кроме того, модуль по борьбе с нежелательной почтой, модуль антивируса и техническая поддержка также увеличивают базовую стоимость. Техническая поддержка обязательна на первый год и стоит от 55 долларов США за 25 пользователей. По соображениям производительности, для использования Mail Utilities необходим компьютер, использующий 64-разрядный Windows Server® 2003 или Windows Server 2008. Для тех, кому нравится это приложение, но кто еще использует Exchange Server 2003, доступна другая версия.
Цена: от 245 долларов США за 25 пользователей.

Обзор книги
How to Cheat at Securing SQL Server 2005 («Уловки при обеспечении безопасности SQL Server 2005»)
syngress.com
Как специалисты по информационным технологиям все мы знаем, что безопасность должна быть основной задачей при создании инфраструктуры. Достаточно лишь задуматься о том, насколько взаимосвязаны современные среды и сколько конфиденциальной информации остается в системах. Это особенно верно для экземпляров SQL Server®, поскольку они обычно являются централизованными источниками конфиденциальной информации. Вдобавок, существующие нормативы по защите конфиденциальности пользователей, такие как закон Сарбейнса-Оксли и HIPAA, могут вызвать существенные юридические и финансовые проблемы в случае происшествия, ведущего к утечке конфиденциальных данных.
При обеспечении безопасности SQL Server 2005 стоит заглянуть в книгу «How to Cheat at Securing SQL Server 2005». Название книги до некоторой степени вводит в заблуждение – вместо «уловок» она предоставляет справку по всем этапам блокирования развертываний SQL Server 2005. Стратегия следует базовому принципу «минимального доступа», при котором допускается только то, что необходимо для удовлетворения нужд бизнеса, а все остальное отключается.
После введения книга начинает с изучения того, как уменьшить открытую для атак область экземпляра SQL Server 2005 с помощью средства настройки контактной зоны. Здесь можно найти полезную информацию, такую как службы по умолчанию с их вариантами запуска по умолчанию (ручным, автоматическим или отключенным) при установке SQL Server 2005. В следующей главе можно узнать о ролях SQL Server и о том, как они могут существенно упростить задачи администрирования. Например, книга показывает, как привязать роль к группе Windows®. В таком случае, если добавить в группу нового пользователя, ему автоматически дается доступ к ресурсам, доступным этой роли.
Глава о проверке доступа и детализированной модели доступа рассказывает о именах входа Windows и SQL Server и об их преимуществах и недостатках. Она также изучает рекомендации Майкрософт в отношении проверки подлинности. Затем рассказ перетекает к авторизации, охватывая доступный варианты точного указания того, что пользователи могут делать на экземпляре (или, на языке баз данных, разрешения принципов для защищаемых объектов). Здесь можно узнать о таких вещах, как выделенное подключение администратора (dedicated administrator connection – DAC), предоставляющее локальное, доступное только администратору подключение, позволяющее войти в экземпляр, когда запрос или процесс поглощают все ресурсы, делая сервер не отвечающим. Это весьма полезная функция, отсутствовавшая до SQL Server 2005.
В SQL Server 2005 схемы и пользователи разделены в отдельные объекты. В книге имеется глава по определению, обновлению и удалению схем через T-SQL и SQL Server Management Studio. В этом же разделе можно также найти некоторые интересные советы, такие как совет не использовать хранимую процедуру sp_adduser для создания новых пользователей SQL Server 2005, если не требуется создания новой схемы. Вместо этого следует использовать команду CREATE USER языка T-SQL для создания пользователя – и ничего более.
Само собой, важной частью обеспечения безопасности установки являются пароли, и в следующей главе подробно рассказано о политиках паролей, чтобы помочь читателю достичь единого уровня безопасности для всех учетных записей. Автор изучает различные варианты реализации, чтобы дать советы по выбору лучшей политики и типа политики для конкретной среды. Затем он переходит к триггерам ЯОД и тому, как они помогают защититься от ненамеренных структурных изменений, а также предоставляют журналы аудита для изменений в именах входа сервера.
В следующей главе раскрывается множество способов, которыми SQL Server 2005 может шифровать данные и схемы для защиты конфиденциальной информации. Наконец, в книге дан обзор служб отчетов SQL, служб анализа SQL и служб интеграции SQL Server (SSIS), включая рекомендации, относящиеся к безопасности. Два приложения также очень полезны, поскольку помогают лучше понять применение и обеспечение безопасности групповых политик и Active Directory применительно к SQL Server 2005.
В книге мне показались особенно полезными две вещи. Первая – это раздел «Быстрый путь решений» в каждой главе, дающий краткий, разбитый на пункты обзор компонентов, фактов и советов для элементов, охваченных главой. Вторая – это раздел часто задаваемых вопросов, предоставляющий краткие ответы на вопросы об администрировании экземпляра SQL Server 2005. Тем, кому нужен быстрый способ подтянуть свои знания в области администрирования SQL Server 2005 с точки зрения безопасности, стоит подумать о добавлении How to Cheat at Securing SQL Server 2005 на свою полку со справочниками.
Цена: $19.98 за книгу в электронном виде, $49.95 за книгу в бумажном виде

Эффективная запись изображения с экрана
ScreenHunter 5 Pro
wisdom-soft.com/products/screenhunter_pro.htm
Запись изображения с экрана является отличным способом документирования поэтапных указаний для пользователей, иллюстрирования сообщений об ошибках, появляющихся в приложениях, или быстрого создания презентации компонента. Само собой, у Windows есть собственные средства записи изображения (PrtScr для записи всего экрана, Alt-PrtScr для записи только активного окна). Однако встроенные в ОС возможности ограничены. Если необходим более детальный контроль над тем, какое изображение записывается и когда, либо если необходима запись экрана из проигрывающегося фильма, необходимо воспользоваться одной из многих доступных служебных программ записи изображения от сторонних производителей. Одно из таких средств – ScreenHunter Pro от компании Wisdom Software. Эта недорогая служебная программа обладает рядом полезных функций, позволяющих наилучшим образом адаптировать запись изображения к конкретным нуждам.
Интерфейс пользователя несложен. Просто выбирается, откуда должно происходить записанное изображение, после чего указывается, куда его следует направить, при помощи точно названных вкладок From («Из») и To («В»). Что касается объекта записи, приложение позволяет записывать корректируемую или фиксированную прямоугольную область, конкретный объект или окно, активное окно, конкретную часть активного окна, целый экран, источник DirectX® или экранной заставки, кадр из фильма или более сложную форму (эллиптическую, многоугольную или нарисованную от руки, как определяет пользователь). Также можно записывать несколько объектов окон или окон сообщений одновременно (что очень полезно для улавливания только активного приложения с его интерфейсами диалоговых или иных окон). Записанное изображение экрана можно сбросить в буфер обмена, в указанное средство просмотра или редактирования, на принтер или в файл. Можно даже отправить его по электронной почте.
Записанные изображения можно сохранять как изображения BMP, PNG, JPEG или TIFF различного качества. Вдобавок, приложение может автоматически масштабировать записанное изображение под определенный размер либо добавлять границу или водяной знак, уменьшая объем дополнительной работы, которую необходимо проделать с изображением. Можно даже установить приложение на автоматическую запись изображения экрана через указанные промежутки времени, по сути записывая действия на компьютере.
Другим полезным компонентом ScreenHunter Pro является поддержка функций автопрокрутки, позволяющая, скажем, записывать длинные веб-страницы, чья просматриваемая область уходит за пределы просматриваемой области на экране. Как и у многих специалистов по информационным технологиям, у меня есть несколько мониторов, и в силу этого мне нравится поддержка записи изображения на нескольких мониторах, позволяющая зафиксировать все сведения на экранах одной записью.
В этой программе даже есть встроенный редактор изображений, позволяющий править их в том же приложении. Если некоторые из более сложных функций, такие как автоматическая отправка по электронной почте, запись изображений по расписанию, водяные знаки и запись с нескольких мониторов не нужны, то можно поинтересоваться несколько более дешевой версией ScreenHunter Plus. Урезанная версия также доступна бесплатно.
Цена: 29.95 долларов США за ScreenHunter Pro
ScreenHunter Pro lets you specify when and what you capture
ScreenHunter Pro lets you specify when and what you capture

Грег Стин (Greg Steen)


 Exchange в вопросах и ответах: Развертывание пакета обновления 1 (SP1) для Exchange Server 2007
Exchange в вопросах и ответах
Развертывание пакета обновления 1 (SP1) для Exchange Server 2007
Нино Билич (Nino Bilic)

Вопрос. Действительно ли пакет обновления 1 для Exchange Server 2007 выпущен только в 64-разрядной версии? А если 32-разрядная версия есть, поддерживается ли она для рабочей среды?
Ответ. Тут никаких различий между исходной версией (RTM) и пакетом обновления 1 (SP1) нет. Пакет обновления 1 имеется как в 32-разрядной, так и в 64-разрядной версии. Правда, нужно учитывать, что в рабочей среде допускается использовать только 64-разрядную версию (такое же ограничение существовало и для RTM). 32-разрядная версия пакета обновления 1 (SP1) может использоваться для проведения различных полготовительных работ по установке и для управления 64-разрядными серверами.

Вопрос. Нужно ли ставить полную RTM-версию Exchange 2007 перед установкой пакета обновления 1 (SP1)?
Пакет обновления 1 (SP1) для Exchange 2007 устроен совсем не так, как пакеты обновления для предыдущих версий Exchange. В файлах пакета SP1 уже содержатся файлы RTM, то есть если вы устанавливаете серевер с нуля, вы можете не использовать DVD-диск с RTM-версией, а ставить сразу пакет обновления 1 (SP1) для Exchange 2007.
Таким образом, для создания нового сервера Exchange 2007 с пакетом обновления 1 (SP1) вам нужны только файлы пакета SP1. Даже если вы добавляете первый сервер Exchange 2007 в организацию Exchange Server 2003, все равно можно обойтись одним пакетом обновления.
Вопрос. У меня на сервере под управлением Windows Server® 2003 установлена RTM-версия Exchange 2007. Я устанавливаю пакет обновления 1 (SP1) для Exchange 2007 SP1. Майкрософт обещает, что Exchange 2007 с пакетом обновления 1 (SP1) поддерживается в Windows Server 2008, так что я планирую на месте обновить систему сервера до Windows Server 2008. Как вы думаете, правильное решение?
Ответ. К сожалению, не очень. При установленной RTM-версии Exchange 2007 обновить Windows Server 2003 до Windows Server 2008 не получится. Обусловлено это определенными техническими причинами. Вы должны понимать, что после такого обновления Exchange перестанет работать.
Подробную информацию по этому поводу вы найдете в статье «Миссия невыполнима: обновление Windows Server 2003 до Windows Server 2008 на месте при установленной системе Microsoft® Exchange Server 2007» на странице msexchangeteam.com/archive/2007/10/04/447188.aspx.

Вопрос. Для части лабораторных серверов я так и не ввел идентификатор продукта. Теперь, когда я запускаю консоль управления Exchange, появляется сообщение о том, что у меня «осталось 0 дней». Смогу ли я установить пакет обновления 1 (SP1) для Exchange 2007, не вводя ключ продукта?
Ответ. Да. Программа установки пакета обновления 1 (SP1) для Exchange 2007 (см. снимок экрана) не в состоянии проверить длину пробного периода сервера. Никакой функции блокировки на случай его окончания не предусмотрено.

Вопрос. Я установил Exchange 2007 с пакетом обновления 1 (SP1) на сервер почтовых ящиков. Теперь мне нужно добавить на него же роль сервера клиентского доступа. Что мне нужно использовать, файлы RTM-версии или файлы пакета обновления 1 (SP1) для Exchange 2007?
Ответ. Если пакет обновления 1 уже установлен, для добавления новых ролей нужно использовать файлы Exchange 2007 SP1. Как было сказано выше, пакет обновления 1 (SP1) для Exchange 2007 — это полноценный продукт, в котором содержатся все файлы, необходимые для работы сервера Exchange 2007, так что после успешной установки пакета обновления RTM-версия Exchange 2007 вам больше не понадобится.
Если вы устанавливаете пакет SP1 на сервер, выполняющий несколько ролей одновременно, обновляются все роли, установленные на сервере. Правда, есть несколько ролей, к которым пакет обновления 1 не применяется, если они установлены на одном физическом сервере.

Вопрос. У нас в организации Exchange несколько серверов Exchange 2007. Серверные роли распределены между ними. Какие роли нужно обновить в первую очередь?
Ответ. Прежде чем что-либо делать, загрузите и прочтите заметки о выпуске пакета обновления 1 (SP1) для Exchange 2007 (go.microsoft.com/fwlink/?LinkId=112364). В них содержится важная информация о том, как установить пакет обновления на работающий сервер.
В качестве ответа на ваш вопрос приведем отрывок из заметок о выпуске:

«Сервер почтовых ящиков лучше обновлять после сервера клиентского доступа, сервера единой системы обмена сообщениями, транспортного сервера-концентратора и пограничного транспортного сервера. Именно такой порядок обновления позволит избежать возможных перерывов в обслуживании. (В этом случае серверы, обеспечивающие «передний фронт» совокупности функций почтовых ящиков, могут без проблем обмениваться информацией с сервером почтовых ящиков, а если бы он был обновлен первым, могли бы возникать сложности.) Кроме того, серверы клиентского доступа, расположенные на узлах, имеющих непосредственный выход в Интернет, лучше обновить до того, как бедет обновлены все остальные серверы клиентского доступа.
Если в вашей организации есть пограничный транспортный сервер и вы создали пограничную подписку, все транспортные серверы, участвующие в процессе синхронизации (EdgeSync), должны работать под управлением одной и той же версии Exchange 2007. Вы должны обновить все пограничные транспортные серверы, для которых оформлена подписка, и все транспортные серверы-концентраторы сайта Active Directory®, на которые подписаны пограничные серверы, причем сделать это обязательно нужно в течение 15 дней с момента установки пакета обновления 1 (SP1) на первый транспортный сервер, участвующий в пограничной подписке».

Вопрос. У меня на RTM-версии Exchange 2007 установлено приложение ForefrontTM Security. Понадобятся ли какие-то дополнительные действия при установке пакета обновления 1 (SP1) для Exchange 2007?
Ответ. RTM-версия приложения Forefront Security для Exchange Server несовместима с пакетом обновления й. Вам нужно либо удалить Forefront Security, либо обновить его перед обновлением Exchange. Подробная информация приведена в заметках о выпуске SP1.
Кстати, в программе установки пакета обновления 1 (SP1) для Exchange 2007 выполняется предварительная проверка на предмет соответствия версий, и в вашей ситуации программа установки выдала бы предупрждение.

Вопрос. У меня на RTM-версию Exchange 2007 установлен накопительный пакет обновления. Нужно ли его удалить перед установкой пакета обновления 1 (SP1) для Exchange 2007?
Ответ. Нет, вручную его удалять не обязательно. Программа установки пакета обновления 1 (SP1) для Exchange 2007 сама избавится от всех обновлений, которые нужно удалить перед установкой пакета.

Нино Билич (Nino Bilic) — руководитель программы поддержки Exchange Server. Подрабатывает он тем, что исследует просторы космоса и колотит плохих парней в Mass Effect.


 Обзор служебных программ: Планирование мощности SharePoint
Обзор служебных программ
Планирование мощности SharePoint
Питер Скьятт Ларсен (Peter Skjatt Larsen) and Satish Mathew

Планирование крупных установок служб Microsoft® Windows® SharePoint® Services (WSS) и Microsoft Office SharePoint Server (MOSS) может оказаться довольно сложной задачей. При поиске оптимальной топологии, оборудования и требований к пропускной способности во внимание принимается множество различных факторов. Кроме того, вам всегда приходится выбирать из нескольких вариантов настройки — решение зависит от того, как будет использоваться система. Нередко администраторы и специалисты, отвечающие за ее планирование, размер будущей системы определяют исключительно собственным волевым решением.
К счастью, корпорация Майкрософт выпустила вторую версию планировщика мощности Microsoft System Center Capacity Planner (SCCP) 2007, универсального средства, позволяющего моделировать различные приложения и оценивать их работу в разных вариантах развертывания. В этой версии было добавлено средство планирования мощностей SharePoint, предлагающее еще две модели: WSS 3.0 и MOSS 2007.
Средство планирования мощности SharePoint, равно как и SCCP 2007, распространяется бесплатно через Центр загрузки Майкрософт: microsoft.com/systemcenter/sccp/default.mspx.
Средство планирования мощности SharePoint составляет список требований, предъявляемых организацией, на основании ваших ответов на вопросы, связанные с ожидаемой нагрузкой и условиями работы системы. Для создания предварительного проекта мастер просит вас предоставить информацию о структуре и предполагаемых требованиях к системе SharePoint, в частности нужно будет указать количество пользователей разных типов (прошедших проверку подлинности и анонимных), параметры сети, комплектацию оборудования, тип использования системы (например, публикация или сотрудничество), требования к хранилищам, требования к выполнению запросов и проведению индексации.
Results of a simulation in the SharePoint Capacity Planning Tool
Results of a simulation in the SharePoint Capacity Planning Tool
После этого средство формирует рекомендованную базовую топологию, используя имена в соответствии с вашими собственными настройками. Для предложенной топологии вы запускаете моделирование нагрузок и проверяете, сможет ли работать такая система в тех или иных условиях.
Изначальную топологию можно изменить в редакторе модели. После этого можно запустить условные ситуации и оценить влияние роста нагрузок, расширения офисной сети организации, подключения нового оборудования и увеличения пропускной способности сетей. Как видно на снимке экрана, при моделировании создается оценка загрузки сервера и составляются отчеты по работе пользователей. Эти данные позволяют оптимизировать настройку на основании таких параметров, как стоимость, производительность, характеристики оборудования. Подробный или краткий отчет можной экспортировать в таблицу Excel®, а диаграмму топологии — в файл Visio®.
Средство планирования мощностей SharePoint упрощает развертывание системы с нуля: оно позволяет заранее протестировать работу стартовой настройки в различных условиях. Кроме того, можно смоделировать имеющуюся топологию и, запустив ряд условных ситуаций, определить, какие изменения могут произойти в той системе, которая у вас установлена.

Питер Скьятт Ларсен (Peter Skjatt Larsen) работает ответственным за продуктыв группе Microsoft Solution Accelerator. В корпорации Майкрософт он работает уже четыре года; занимался переходом с UNIX, обменом сообщениями и средствами организации совместной работы.
Satish Mathew работает ответственным за программу в группе Microsoft Solution Accelerator. В Майкрософт он пришел почти пять лет назад. Сначала работал в группе, отвечающей за Windows PowerShell.


 Sharepoint изнутри: Создание инфраструктуры SharePoint
Sharepoint изнутри
Создание инфраструктуры SharePoint
Пав Черны (Pav Cherny)
Загрузить исходный код для этой статьи: SharePoint2008_05.exe (412KB)

Так же, как электронная почта изменила деловое общение, совместная работа на основе веб-технологий меняет процесс взаимодействия людей и обмена информацией. В качестве хорошего примера рассмотрим возможности, предоставляемые технологией SharePoint. Службы Microsoft Windows SharePoint Services (WSS) 3.0 и сервер Microsoft Office SharePoint Server
(MOSS) 2007 позволяют создавать узлы групп, порталы, решения для управления веб-содержимым, библиотеки документов и центры поиска, не говоря уж об интеграции выпуска 2007 системы Microsoft® Office, формах на основе XML, потоках работ, поддержке мобильных устройств и т.д.
Однако приступить к работе с SharePoint® не всегда просто. Терминология может сбивать с толку. Архитектура системы может быть очень сложной, а для SharePoint необходимо использование множества компонентов, включая IIS, Microsoft .NET Framework, SQL Server® и, возможно, других технологий, таких как бизнес-аналитика, служба форм InfoPath®, служба управления правами (RMS), Exchange Server и ForefrontTM Security.
Вы можете быстро запутаться в настройке и интеграции со множеством подходов к созданию решений SharePoint, осуществляемых программно или с помощью встроенного пользовательского интерфейса. Более того, если приложение SharePoint не работает, устранение неполадок может быть очень сложным. Часто, чтобы понять задействованные компоненты и их взаимодействие, необходимо иметь склад ума разработчика приложений. Учитывая все эти проблемы, с чего начать разработку надежной, масштабируемой и управляемой инфраструктуры SharePoint?
В данной статье описано, как приступить к работе, создав сначала фундамент (здесь же будет обсуждаться архитектура высокого уровня), а затем углубившись в развертывание WSS, в том числе самые начальные индивидуальные настройки для компании. С помощью функции управления средствами самостоятельного создания узлов WSS 3.0 будет показано делегирование полномочий для создания и управления узлами SharePoint отдельным пользователям с сохранением централизованного административного управления архитектурой SharePoint.
Первоначальное рассмотрение архитектуры SharePoint упрощает ознакомление с действиями по развертыванию и настройке, необходимыми для реализации гибкой и масштабируемой инфраструктуры. Так что давайте взглянем на зависимости, а затем перейдем непосредственно к развертыванию WSS 3.0. Подробные указания по развертыванию приведены в сопровождающих справочных материалах. Их можно найти в разделе загрузок кода на веб-узле журнала TechNet Magazine по адресу technetmagazine.com.

Архитектура SharePoint
Применительно к SharePoint полезно подумать о технологии с точки зрения системного архитектора. Вам не нужно знать все мельчайшие детали, но если вы знакомы с общими зависимостями архитектуры SharePoint, вы будете быстрее находить нужные решения, так как сможете заранее определять, что необходимо настроить и почему.
SharePoint – это технология для подготовки веб-приложений и узлов. Это решение для веб-узлов на основе IIS, интегрированное с IIS посредством ASP.NET и использующее серверную часть базы данных SQL Server для хранения данных настройки и содержимого. Вкратце, SharePoint сочетает три различные архитектуры (IIS, .NET и SQL Server), как показано на рис. 1.
Figure 1 WSS 3.0 architecture based on IIS 6.0 and ASP.NET 3.0
Figure 1 WSS 3.0 architecture based on IIS 6.0 and ASP.NET 3.0
Не пугайтесь схемы. На первый взгляд архитектура может казаться огромной, если учитывать общее количество компонентов. Но все они укладываются в одну логическую схему, которая при систематическом изучении позволяет понять зависимости компонентов.
Как показано на рисунке, SharePoint полагается на службы IIS и платформу ASP.NET для обработки запросов и ответов HTTP. Стандартные компоненты служб IIS, такие как драйвер HTTP режима ядра (http.sys) и рабочий процесс (w3wp.exe), выполняют первоначальную постановку в очередь и маршрутизацию запросов, пока они не поступают фильтру ISAPI платформы ASP.NET (aspnet_isapi.dll). При установке .NET Framework библиотека aspnet_isapi.dll регистрируется в метабазе служб IIS (C:\Windows\System32\Inetsrv\metabase.xml) следующим образом:
InProcessIsapiApps="C:\WINDOWS\system32\inetsrv\httpext.dll
C:\WINDOWS\system32\inetsrv\httpodbc.dll
C:\WINDOWS\system32\inetsrv\ssinc.dll
C:\WINDOWS\system32\msw3prt.dll
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll"
После загрузки службами IIS фильтра ISAPI платформы ASP.NET все входящие запросы для веб-узла могут быть переданы платформе ASP.NET, что важно, поскольку SharePoint необходимо в конечном счете получить эти запросы через платформу ASP.NET. Для этого SharePoint расширяет настройку выбранного веб-узла the путем добавления сопоставления с подстановочными символами для приложений, маршрутизирующего все входящие запросы независимо от расширения имени файла к фильтру ISAPI платформы ASP.NET.
Это можно увидеть в диспетчере служб IIS после установки WSS 3.0 при выборе базовой установки. Программа установки WSS отключает существующий веб-узел IIS по умолчанию на сервере и создает новый веб-узел по умолчанию для порта 80 с определенным сопоставлением с подстановочными символами для приложений ASP.NET, как показано на рис. 2.
Figure 2 Wildcard application map for ASP.NET ISAPI filter
Figure 2 Wildcard application map for ASP.NET ISAPI filter
Чтобы платформа ASP.NET в свою очередь передавала запросы серверу SharePoint, SharePoint должен расширить конвейер обработки запросов HTTP посредством настраиваемого объекта HttpApplication, реализуемого с помощью класса SPHttpApplication сборки Microsoft.SharePoint. SharePoint определяет этот настраиваемый объект приложения в файле приложения ASP.NET (global.asax), который находится в корневой папке расширенных с помощью SharePoint веб-узлов в файловой системе. Ниже приведено содержимое такого файла global.asax:
<%@ Assembly Name="Microsoft.SharePoint"%>
<%@ Application Language="C#" Inherits="Microsoft.SharePoint.ApplicationRuntime.SPHttpApplication" %>
Платформа ASP.NET динамически обрабатывает и компилирует этот файл для создания экземпляра объекта приложения SharePoint.
Для каждого полученного запроса платформа ASP.NET запускает серию событий, которые может обработать веб-приложение, таких как BeginRequest, AuthenticateRequest, ProcessRequest и EndRequest. Подробная информация об обработке ошибок выходит за рамки развертывания и управления SharePoint, хотя важно знать, что помимо класса SPHttpApplication, указанного в файле global.asax, SharePoint также реализует настраиваемые обработчики данных и модули HTTP, определенные в файле web.config для узла. Например, SharePoint использует модуль HTTP на основе класса SPRequestModule, зарегистрированноый в качестве первого модуля HTTP до стандартных модулей ASP.NET. SPRequestModule инициализирует среду выполнения SharePoint путем регистрации компонента SPVirtualPathProvider в ASP.NET. Модуль SPRequestModule предназначен для внутреннего использования SharePoint, но разработчики решений SharePoint могут изменить файл web.config для регистрации дополнительных компонентов, таких как настраиваемые обработчики данных и модули HTTP. Настраиваемые и стандартные модули HTTP позволяют SharePoint использовать преимущества ASP.NET, сохраняя жесткий контроль над всеми запросами к приложениям SharePoint.
Имейте в виду, что при создании веб-приложения с помощью узла центра администрирования SharePoint 3.0 службы WSS добавляют к выбранному веб-узлу IIS сопоставление с подстановочными символами для приложений ASP.NET и создает в корневой папке веб-узла файлы global.asax и web.config. Каждое веб-приложение использует собственный набор файлов global.asax и web.config высокого уровня.
Для обработки запросов и возврата обозревателям значимых данных WSS 3.0 и MOSS 2007 используют стандартный анализатор страниц ASP.NET, который компилирует запрошенные страницы ASP.NET или обрабатывает их в режиме без компиляции. Но страницы ASP.NET, передаваемые службами SharePoint анализатору ASP.NET, не обязательно находятся там, где кажется. Например, файл default.aspx не удастся найти в корневой папке расширенного с помощью SharePoint веб-узла, такого как узла центра администрирования SharePoint 3.0, хотя файл default.aspx открывается при отображении домашней страницы этого веб-узла. Именно компонент SPVirtualPathProvider виртуализируюет среду путем загрузки содержимого страницы из локальной файловой системы или базы данных содержимого SQL Server и его передачи анализатору страницы ASP.NET в качестве виртуального файла. Для узла центра администрирования SharePoint загружает файл default.aspx из папки C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\SiteTemplates\CentralAdmin.
Домашняя страница, также как и большинство других страниц узлов SharePoint, связана с главной страницей ASP.NET (default.master), реализующей общий макет для меню и элементов управления переходами. Страница Default.master находится в папке C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Template\Global и имеет в своем составе именованные заглушки для других страниц содержимого в локальной файловой системе или базе данных содержимого SQL Server. Ключевой момент заключается в том, что при открытии узла SharePoint в веб-обозревателе на самом деле отображается информация коллекции страниц содержимого, которые могут быть размещены не на локальном веб-сервере и упорядочены в соответствии с макетом, определенным главной страницей.
Как правило, неизмененные страницы (или неиндивидуализированные страницы в терминологии SharePoint) являются шаблонами страниц локальной файловой системы каждого сервера SharePoint, а индивидуализированные страницы записаны в базе данных содержимого, чтобы для всех серверов SharePoint веб-фермы был доступен один и тот же набор страниц (см. рис. 3). Предполагается, что неиндивидуализированные страницы являются одинаковыми на всех серверах и узлах в веб-ферме. Однако при индивидуализации страниц содержимого или главной страницы узла SharePoint, возможно, с помощью Office SharePoint Designer 2007, SharePoint автоматически сохраняет индивидуализированные страницы в базе данных содержимого.
Figure 3 Uncustomized and customized ASP.NET pages in a SharePoint application
Figure 3 Uncustomized and customized ASP.NET pages in a SharePoint application
Помимо индивидуализированных страниц и другого содержимого веб-узла SharePoint также сохраняет данные настройки в базе данных SQL Server. SharePoint не сохраняет данные настройки в базе данных содержимого, поскольку эти данные имеют глобальную природу, а содержимое связано с отдельным веб-приложением и семейством узлов. Аналогично, веб-ферма может иметь только одну базу данных настройки, но несколько баз данных содержимого.
Все серверы WSS в веб-ферме используют одну базу данных настройки для хранения общих метаданных, параметров настройки и сведений обо всех веб-узлах IIS веб-фермы, расширенных с помощью SharePoint. Отдельные веб-приложения, напротив, могут быть связаны с одной или несколькими базами данных содержимого (хотя отдельная база данных содержимого может быть связана только с одним веб-приложением).
Взаимосвязь между веб-узлами IIS, веб-приложениями, семействами узлов и базами данных содержимого может казаться запутанной. В терминологии SharePoint «веб-приложение» – это веб-узел IIS, расширенный с помощью SharePoint. В составе веб-приложения может быть несколько семейств веб-узлов, в составе каждого из которых опять же может быть узел верхнего уровня и узлы подуровней, использующие одни параметры настройки.
Помимо прочего, создание нескольких семейств узлов позволяет делегировать администрирование семейством узлов различным пользователям и группам. В составе одного семейства узлов не может быть несколько баз данных содержимого, но веб-приложение может использовать несколько таких баз данных для увеличения масштабируемости и снижения отрицательного воздействия на производительность большого узла, выполняющего значительный объем операций с базой данных на других узлах SharePoint. Однако размещение всех узлов SharePoint в отдельных семействах узлов – не лучший вариант, поскольку подобное развертывание ограничивает межузловую функциональность.
WSS 3.0 не поддерживает контекстный поиск по нескольким семействам узлов. Для такого поиска необходим MOSS 2007 или Microsoft Search Server 2008. Например, можно создать веб-приложение и узел верхнего уровня для http://contoso, а администратор семейства узлов затем может создать узлы подуровней, используя пользовательский интерфейс SharePoint, например, http://contoso/info и http://contoso/events. Все эти узлы находятся в одной базе данных содержимого, поскольку принадлежат одному семейству узлов.
Вы, как администратор фермы, также можете использовать управляемый путь, такой как /sites, а затем определить дополнительные семейства узлов, например, http://contoso/sites/IT и http://contoso/sites/HR, в центре администрирования SharePoint 3.0. У этих трех семейств узлов (http://contoso, http://contoso/sites/IT и http://contoso/sites/HR) могут быть различные администраторы, параметры настройки и базы данных содержимого, но доступ к ним осуществляется через один веб-узел IIS (http://contoso), и все три семейства используют одно удостоверение пула приложений веб-приложения.
Конечно, существует гораздо больше деталей, но эта взаимосвязь IIS, ASP.NET и SQL Server особенно важна для понимания успешной работы со SharePoint. Тем, кто хочет поближе познакомиться с архитектурой SharePoint, я рекомендую статью Теда Паттинсона в журнале MSDN® Magazine, озаглавленную «Значительные улучшения служб SharePoint Services для разработчика» и доступную по адресу msdn.microsoft.com/msdnmag/issues/06/07/WSS30Preview.

Элементы инфраструктуры SharePoint
Теперь в рамках нашего краткого обзора архитектуры рассмотрим гибкую инфраструктуру SharePoint. Как вы наверняка заметили, нам необходимы Windows Server®, IIS, .NET Framework 3.0 (для ASP.NET и Windows® Workflow Foundation), WSS 3.0 или MOSS 2007 и SQL Server. Хотя вы можете рассчитывать использовать службы IIS 7.0 на Windows Server 2008, для наших целей мы будем использовать IIS 6.0 на Windows Server 2003, поскольку на момент написания данной статьи это наиболее распространенная развертываемая версия. Мы будем использовать WSS 3.0, поскольку для начального экспериментального проекта SharePoint не требуются функции MOSS 2007.
При минималистском подходе можно установить WSS 3.0 со всеми необходимыми компонентами на одном компьютере (как описано в файле WSS 3.0 on a single computer.pdf, входящем в состав сопровождающего материала для этой статьи), что достаточно для лабораторного сервера или среды небольшой рабочей группы. Однако если вашей целью для инфраструктуры SharePoint является гибкость, не следует начинать с отдельного развертывания в вашей рабочей среде. В целях обеспечения доступности и расширяемости в будущем лучше начать с многоуровневой архитектуры и добавить необходимое количество серверов.
На рис. 4 показана рекомендуемая инфраструктура SharePoint, если необходима простая и гибкая структура системы. В ее состав входит веб-ферма, состоящая из двух серверов SharePoint и отдельного компьютера с установленной базой данных SQL Server. Такая структура уменьшает затраты на обработку базы данных на веб-серверах, улучшает доступность и масштабируемость, а также упрощает обслуживание системы. Имейте в виду, что необходима служба Active Directory®, так как это требование к программному обеспечению WSS 3.0 в развертывании веб-фермы. Поэтапные указания по развертыванию приведены в файле Basic SharePoint Infrastructure.pdf в материале, сопровождающем данную статью.
Figure 4 Basic SharePoint infrastructure that can accommodate future growth
Figure 4 Basic SharePoint infrastructure that can accommodate future growth
Для учетной записи домена, используемой для развертывания SharePoint в такой сборке, необходимы права локального администратора на веб-серверах. Также необходимо добавить эту учетную запись к ролям создателя баз данных и администратора безопасности SQL Server, а также к роли владельца базы данных для главной базы данных SQL Server 2005, как показано в файле Basic SharePoint Infrastructure.pdf. После этого при установке WSS 3.0 можно использовать мастер настройки продуктов и технологий SharePoint для создания необходимой базы данных настройки для фермы веб-серверов и базы данных содержимого для узла центра администрирования SharePoint 3.0. В противном случае администратор SQL Server должен предоставить вам эти базы данных и добавить к роли владельца базы данных системные учетные записи WSS.
Важно помнить, что учетная запись пользователя, используемая для установки SharePoint, это не учетная запись, используемая SharePoint для доступа к базе данных настройки или содержимого для узла центра администрирования. Вместо нее SharePoint использует системную учетную запись, настроенную в качестве удостоверения пула приложения для узла центра администрирования SharePoint 3.0.
Мастер настройки продуктов и технологий SharePoint выдаст запрос на ввод сведений об учетной записи. Рекомендуется использовать специальную учетную запись пользователя домена, такую как CONTOSO\WssConfigAdmin. Обычно я использую специальные, выделенные учетные записи пользователей для всех создаваемых позже дополнительных веб-приложений. Использование отдельного пула приложений для каждого веб-приложения помогает обеспечить изоляцию процесса, а использование различных учетных записей пользователей для всех пулов приложений помогает поддерживать изоляцию безопасности. Тем не менее, следует обратить внимание на то, что это всего лишь один из возможных подходов, и необходимо оценить управляемость и возможное воздействие на производительность с точки зрения вашей среды и бизнес-требований.
Другая важная системная учетная запись, которая должна быть создана для вас администратором домена, – учетная запись службы поиска. Можно использовать учетную запись центра администрирования, но для обеспечения повышенной безопасности лучше использовать специальную учетную запись поиска, например, CONTOSO\WssSearch, которая не имеет прав администратора и не может изменять никакое содержимое. Разрешение на запись в базах данных содержимого не требуется, поскольку служба поиска выполняет обход содержимого только для целей индексирования и хранит данные поиска в отдельной базе данных.
При создании веб-приложения в ферме серверов можно связать базу данных содержимого с сервером поиска, который неявным образом добавляет соответствующую учетную запись службы поиска к политике «Чтение любых элементов» веб-приложения. Подобными серверами являются серверы SharePoint, на которых запущена служба поиска Windows SharePoint Services. Если вы выполнили поэтапные указания в файле Basic SharePoint Infrastructure.pdf, вы настроили оба веб-сервера в качестве серверов поиска таким образом, чтобы можно было распределить нагрузку на обход содержимого и индексирование нескольких баз данных содержимого. Однако также можно настроить специальный сервер поиска в веб-ферме, исключенный из балансировки сетевой нагрузки и клиентских подключений, чтобы действия по обходу содержимого не влияли на клиентские подключения.

Управление средствами самостоятельного создания узлов
После создания базовой инфраструктуры SharePoint можно делегировать администрирование узлами и семействами узлов отдельным пользователям или отделам без децентрализации административного контроля над службой Active Directory, фермой веб-серверов или базами данных SQL Server. Вы как администратор фермы сотрудничаете с администраторами Active Directory и SQL Server для предоставления учетных записей пула приложений и баз данных содержимого для ваших веб-приложений. Затем в этих веб-приложениях создаются семейства узлов, для которых назначаются администраторы с правами создания узлов подуровней. Благодаря этому администраторы семейств узлов в отдельных отделах могут управлять соответствующими ресурсами SharePoint при минимальном участии отдела ИТ, как показано на рис. 5.
Figure 5 Decentralized site administration in a centralized SharePoint infrastructure
Figure 5 Decentralized site administration in a centralized SharePoint infrastructure
Также можно предоставить пользователям возможность создания семейств узлов по управляемым путям (например, путям /sites или другим путям со включениями по подстьановочным символам, созданными в центре администрирования SharePoint 3.0). При включении функции управления средствами самостоятельного создания узлов в веб-приложении пользователи могут создавать собственные семейства узлов и управлять правами и группами узлов с помощью пользовательского интерфейса SharePoint. В отличие от узлов подуровней, семейства узлов не наследуют права от родительского узла.
Управление средствами самостоятельного создания узлов подходит не для всех сред SharePoint и по умолчанию отключено. Включение этой функции может привести к появлению большого числа редко используемых семейств узлов в базах данных содержимого. Однако она весьма наглядно демонстрирует гибкость администрирования SharePoint, и я рекомендую включить ее в экспериментальном развертывании. (Кроме того, в SharePoint существует возможности уведомления пользователей и/или администраторов о неактивных узлах, чтобы их можно было при необходимости удалить.) Необходимо включить управление средствами самостоятельного создания узлов в веб-приложении явным образом, как указано в файле Enabling Self-Service Site Management.pdf, входящем в материал, сопровождающий данную статью.

Индивидуализации SharePoint и включение стиля компании
Материалы по Sharepoint
  • Технический центр Windows SharePoint Services TechCenter
  • Центр разработчиков Windows SharePoint Services Developer Center
  • Блог группы «Продукты и технологии Microsoft SharePoint»
  • Компоненты логической архитектуры
  • Проектирование ферм серверов и топологий

В данный момент возникает естественное желание включить логотип, название и фирменную раскраску компании в пользовательский интерфейс SharePoint. Однако, необходимо учитывать, что это означает вывод проекта SharePoint на уровень разработчика ASP.NET. Как минимум, необходима система разработки, например, отдельный сервер WSS 3.0 с программой Microsoft Office SharePoint Designer 2007 (см. файл SharePoint Designer Installation.pdf в материале, сопровождающем данную статью), чтобы можно было внести и протестировать изменения, не влияя на рабочую среду. Также необходимо посетить центр разработчиков Windows SharePoint Services Developer Center по адресу msdn2.microsoft.com/sharepoint для получения дополнительных сведений о множестве вариантов настройки, предоставляемых SharePoint.
Хотя разработка While SharePoint не рассматривается в данной статье, я отмечу несколько моментов, которые необходимо учитывать. SharePoint сохраняет индивидуализированные страницы в базе данных содержимого соответствующего семейства узлов. Другими словами, все индивидуализациии, выполненные для страниц узла, страниц приложения, главных страниц, таблиц стилей и т.д. на узле SharePoint, применяются только на уровне узла или семейства узлов. Это очень существенно для администраторов отдельных семейств узлов, которым необходимо изменить вид и функции соответствующих узлов с помощью SharePoint Designer 2007, но не очень хорошо для администраторов ферм, которым необходимо применить фирменный стиль ко всем веб-приложениям, семействам узлов или узлам в веб-ферме.
Можно создать пользовательские темы или определения узлов на основе копии определения стандартной темы или узла SharePoint. Также можно создать пользовательские главные страницы и добавить их в галерею главных страниц. Однако ни один из этих вариантов не позволяет применить фирменный стиль компании глобально, если функция управление средствами самостоятельного создания узлов включена, поскольку пользователь с правами на создание узлов или семейств узлов может по-прежнему выбрать стандартный шаблон узла без фирменного стиля.
Для глобального применения стиля компании необходима замена компонентов SharePoint по умолчанию, чтобы вместо них использовались пользовательские компоненты. Разработчики далеко продвинулись в сторону выполнения этой задачи без изменения исходных файлов. Одним из подходов является изменение настройки виртуальных каталогов в диспетчере служб IIS и их указание на новые папки с настроенными файлами. Другой способ – реализация настраиваемого модуля HTTP или фильтра ISAPI, переписывающего URL-адреса для перенаправления запросов для отдельных страниц по умолчанию на индивидуализированннные версии.

Заключение.
В данной статье были рассмотрены основные моменты установки инфраструктуры SharePoint с WSS 3.0. Не рассматривались ни другие функции, такие как потоки работ, опросы, интеграция системы обмена сообщениями и антивирусы, ни специальные функции MOSS 2007, такие как порталы, каталоги узлов и бизнес-данных. Индивидуализация для администрирования узлов и фирменного стиля компании также рассматривалась только с помощью средств SharePoint. Дальнейшая индивидуализация может быть выполнена с помощью WSS 3.0 путем создания пользовательских приложений в Visual Studio®.
Инфраструктура достаточно надежна для поддержки будущего роста при добавлении дополнительных веб-серверов или серверов баз данных. А благодаря экспериментальной реализации нескольких изменений пользователи могут создавать отдельные узлы и получить общие сведения о SharePoint. Таким образом, устанавливаются основные компоненты одобрения пользователями, а также программное обеспечение и оборудование, достаточно гибкие для внесения изменений и выступающие в качестве основы для развертывания полноценного продукта.

Пав Черны (Pav Cherny) – специалист по информационным технологиям и автор, специализирующийся на технологиях совместной работы и единой среды связи от Майкрософт. В числе его публикаций статьи, руководства по продуктам и книги по эксплуатации информационных систем и системному администрированию. Пав – президент компании Biblioso Corporation.


 Windows PowerShell: Автоматизация управления каталогом
Windows PowerShell
Автоматизация управления каталогом
Дон Джонс (Don Jones)

Обидно, что на выпуск первой версии Windows PowerShell отвели так мало времени. Сроки поджимали: мы готовили — ни много ни мало — Exchange Server 2007, а он завязан на Windows PowerShell. В общем, специалистам по Active
Directory работы хватало (параллельно готовили еще одну безделицу — Windows Server® 2008). В итоге функции управления Active Directory® в Windows PowerShell, прямо скажем, оставляют желать лучшего.
Честно говоря, управление Active Directory вообще в Windows PowerShell® есть. Разработчики Windows PowerShell мужественно пытались в последние минуты добавить более или менее пристойную поддержку интерфейса служб Active Directory (ADSI) — технологии, поддерживающей языки создания сценариев и уже известной пользователям VBScript.

Путь ADSI
Интерфейс ADSI схож по принципу действия с инструментарием WMI. Вы выдаете запрос, используя особый синтаксис. Запрос передается удаленному компьютеру (контроллеру домена, к примеру) и выполняется. Результатом запроса является объект или коллекция объектов Active Directory (скажем, отдельный пользователь или целая группа). Вы получаете ссылку на этот объект и можете с ней работать. Можно менять свойства объекта, при помощи методов сохранять изменения, удалять объекты и т. д. Например, чтобы создать пользователя, вы запрашиваете подразделение (OU) или контейнер, в котором пользователь будет размещен. В ответ вы получаете метод Create, при помощи которого можно создать пользователя.
Пока вы выполняете самые простые операции, работа с ADSI в Windows PowerShell кажется абсолютно простой и прозрачной. К примеру, такая команда используется для получения имени пользователя и значения атрибута Company, указанного для него:
$user = [ADSI]"LDAP://cn=Ringo,ou=Singers,dc=company,dc=pri"
$user.Get("Company")
Пользователя можно подать на вход командлета Get-Member — это позволит узнать, какие свойства и методы у него есть. К сожалению, в Windows PowerShell 1.0 подобные объекты реализованы не самым лучшим образом. Как видно из рис. 1, оболочка не способна ни перечислить атрибуты каталога объекта, ни предоставить список методов, доступных для него, — в отличие от метода Get.
Figure 1 Piping the user to Get-Member to see its properties
Figure 1 Piping the user to Get-Member to see its properties
Поддержка этих функций улучшена в версии CTP консоли Windows PowerShell 2.0, но лишь отчасти. Все равно платформа Microsoft® .NET Framework, лежащая в основе, не позволяет администраторам видеть все то, что им нужно: платформа изначально создавалась для разработчиков. Еще одна проблема состоит в том, что специалисты по Windows PowerShell не всемогущи. Хорошую поддержку Active Directory можно реализовать только при участии тех, кто в ней разбирается. Другими словами, нужно подключить группу разработчиков Active Directory. Я уверен, через какое-то время именно так все и будет. В конце концов, оболочка Windows PowerShell появилась совсем недавно. Но что же нам делать до этого?
Возможно, вы помните, что в июньском выпуске журнала за 2007 год я рассказывал об использовании технологий ADSI в Windows PowerShell (technetmagazine.com/issues/2007/06/PowerShell). В ней можно найти дополнительную информацию об этой «встроенной» технологии. Здесь же я покажу вам несколько новых подходов.

Богатая экосиситема
Архитектор Windows PowerShell Джефри Сновер (Jeffrey Snover) нередко ссылается на богатство экосистемы, внутри которой оболочка существут. Под этим он подразумевает всю ту огромную работу, которую проделали разработчики, чтобы расширять оболочку Windows PowerShell могли не только сотрудники Майкрософт. Некоторые компании уже создают командлеты для Windows PowerShell, позволяющие управлять их продуктами из командной строки. Среди них VMWare, IBM, Citrix, Foundry.
Один из моих любимых примеров «богатства экосистемы» — программное обеспечение Quest. Эта компания предлагает ряд бесплатных командлетов для управления Active Directory. Загрузить их можно на веб-узле quest.com/powershell. Этой же компанией разработан бесплатный графический интерфейс PowerGUI (powergui.org), который надстраивается над Windows PowerShell, помогая работать с оболочкой тем, кто еще не до конца освоил командную строку. Интерфейс PowerGUI поможет изучить командлеты, предназначенные для управления Active Directory. И поверьте мне, вам захочется ими воспользоваться. По простоте и функциональности с этим набором командлетов не сравнится ни одно средство управления Active Directory. (Если вам нужны дополнительные сведения о PowerGUI, почитайте рубрику «Инструментарий» в январском выпуске журнала за 2008 год: technetmagazine.com/issues/2008/01/Toolbox.)

Путь Windows PowerShell
Любой прием, предполагающий использование командлетов, можно смело назвать «путем Windows PowerShell». Вам не приходится работать ни с классическими сценариями, ни с путаными объектами программирования. Вот мой самый любимый однострочник. Эта команда импортирует файл CSV и на основании данных, хранящихся в нем, создает десятки, даже сотни пользователей Active Directory:
Import-CSV 'C:\provision1.csv' |
ForEach-Object {New-QADUser -organizationalUnit 'company.pri/Singers' -name ($_.'First Name' + '.' + $_.'Last Name')
-samAccountName $_.'Logon name' -city $_.city -title $_.'Job title' -department $_.department}
Команда, конечно, длинная, но невероятно удобная. В начале стоит Import-CSV, внутренний командлет оболочки, который просто считывает содержимое файла CSV и возвращает объекты. Каждая строка файла воспринимается как отдельный объект, а столбцы — как свойства объекта. В файле Provision1.csv, который использовал я, столбцы называются Logon Name и First Name. Что любопытно, их названия не совпадают с названиями атрибутов пользователя в Active Directory. Я заметил, что в подобных файлах часто для столбцов выбираются более привычные для человеческого уха названия, нежели те, что используются в Active Directory. В конце концов, этот файл вы могли получить в отделе кадров, а там вряд ли знают, что фамилия в Active Directory записывается в атрибут sn.
После того как файл CSV импортирован и разбит на объекты, последние подаются на вход командлета ForEach-Object, который для каждого объекта выполняет тот фрагмент кода, который в тексте команды заключен в фигурные скобки. То есть сценарий запускается по одному разу для каждой строки файла CSV. В сценарии есть специальная переменная $_. Это ссылка на текущий объект, а именно на текущую строку файла CSV.
Для каждой строки я запускаю командлет New-QADUser. Это один из командлетов надстройки Quest — всего их там около десятка. Обратите внимание на имя командлета — QADUser. Буква Q — это, как вы, наверное, догадались, сокращение от Quest. Такое обозначение используется для того, чтобы избежать конфликтов с командлетом New-ADUser, который разработчики Microsoft Active Directory, вероятно, в ближайшем будущем выпустят. Так оба командлета можно будет загрузить в оболочку одновременно, и их будет проще различать.
Оставшаяся часть однострочника представляет собой набор параметров командлета New-QADUser. Вначале указывается подразделение (organizationalUnit), в котором будет располагаться новый пользователь. Затем идет имя атрибута, соответствующего столбцу First Name (Имя), потом точка, а после нее — атрибут, соответствующий столбцу Last Name (Фамилия).
Последнее, на что здесь нужно обратить внимание: параметр city в Active Directory будет заменен атрибутом l (или Locality-Name). Командлет тоже имеет параметр l, выполняющий практически те же самые функции. В большинстве случаев для параметров, соответствующих атрибутам Active Directory, можно использовать как имя атрибута, так и текстовую метку из средства «Пользователи и компьютеры Active Directory».

Еще один путь Windows PowerShell
Active Directory представляет собой иерархическое хранилище, а одна из сильных сторон Windows PowerShell — возможность представить любое иерархическое хранилище как диск и использовать хорошо знакомые команды управления хранилищами: Dir, Del, Ren, Copy и т. д. К сожалению, в Windows PowerShell 1.0 нет поставщика PSDrive для Active Directory, и поэтому Active Directory представить в виде диска не получится.
Но тут снова на выручку приходит богатство экосистемы: PowerShell Community Extensions. Это бесплатная надстройка, которую можно получить на веб-узле codeplex.com/powershellcx. После установки PowerShell Community Extensions вы сможете указать оболочке ваше доменное имя и затем управлять Active Directory так, словно это обычный диск:
CD COMPANY:
CD SINGERS
DIR
Эта команда переводит вас в домен COMPANY, в подразделение Singers OU и выдает список объектов (см. рис. 2). Теперь можно при помощи команды Del удалить пользователя, при помощи команды Md создать новое подразделение и т. д. В поставщике Community Extensions PSDrive есть подводные камни. Некоторые функции в нем могут давать неожиданные результаты — из-за того, что они просто не согласуются с принципами работы Active Directory. Кроме того, вы должны быть предельно внимательны: если вы перейдете в корень домена и запустите команду del * -recurse, вы удалите все объекты в домене (если у вас есть соответствующие полномочия). И по умолчанию никто вас переспрашивать не будет, действительно ли их нужно удалить. Но несмотря на это, приведенная команда позволяет сделать очень многое, так что нужны просто некоторые навыки и осторожность.
Figure 2 Using the PowerShell Community Extensions to direct the shell and manage the directory
Figure 2 Using the PowerShell Community Extensions to direct the shell and manage the directory

Приступайте к работе
На занятиях меня часто спрашивают, для чего можно сейчас использовать Windows PowerShell. Ведь далеко не каждый продукт Майкрософт задействует эту оболочку. Создается впечатление, что Windows PowerShell еще не готова к полноценной работе.
А на самом деле она уже работает на полную. Пусть в Майкрософт не создали набора средств для управления Active Directory из командной строки, зато другие разработчики взяли эту задачу на себя и отлично с ней справились. Windows PowerShell помогает выполнять задания по администрированию, в том числе позволяет администрировать самые трудоемкие из них, например создание большого количества пользователей. Нужно просто познакомиться с тем, что делает сообщество, чтобы оболочка Windows PowerShell стала действительно полезной. (Зайдите, к примеру, на веб-узел PowerShellCommunity.org, одним из спонсоров которого является Майкрософт. Я участвую в его администрировании.) Если в Windows PowerShell загрузить хороший инструментарий, можно будет создать сценарии для некоторыз задач администрирования, отнимающих много времени, и повысить эффективность работы администратора при одновременной экономии времени.

Дон Джонс (Don Jones) является соавтором книги Windows PowerShell: TFM, 2nd Edition, автором книги VBScript, WMI, and ADSI Unleashed и руководителем проекта PowerShellCommunity.org.


 Эй, сценарист!: Поводя бровями на регулярные выражения
Эй, сценарист!
Поводя бровями на регулярные выражения
Программисты корпорации Майкрософт
Загрузить исходный код для этой статьи: HeyScriptingGuy2008_05.exe (150KB)

В ноябре прошлого года сценаристы провели день в Париже по дороге на конференцию по информационным технологиям Tech•Ed IT Forum, проходившую в Барселоне. В ходе этой однодневной остановки мы воспользовались возможностью посетить Лувр, самый знаменитый музей искусств в городе.
Спрашиваете, как мы нашли Лувр? Все просто: вышли из собора Нотр-Дам и повернули налево.
Ой, вы имели в виду, понравился ли нам Лувр? В основном да. Единственная проблема была в том, что Лувр, подобно многим музеям, работает по принципу «смотри, но не трогай». Всем ясно, что Мона Лиза смотрелась бы лучше, будь у нее брови, но по какой-то причине сотрудникам музея очень не нравятся попытки исправить какую-нибудь из картин.
Примечание: на самом деле обоим сценаристам понравилась Мона Лиза. Это, кстати, было приятным сюрпризом – после всей шумихи и накрутки мы боялись, что это окажется просто еще одной картиной. Но нет, все оказалось очень клёво. (Хотя ей могло бы пригодиться немного бровей.) Что интересно, столь же разрекламированная Венера Милосская нас разочаровала. Нам обоим она показалась не столь уж искусно сделанной, и сценарист, пишущий эту статью, был озадачен самой идеей Венеры Милосской. Статуя безрукой женщины? Чем же она должна мыть полы или тарелки!?!
Примечание для наших читательниц (если кто-то из них еще читает): это была явная опечатка. Мы хотели сказать следующее: статуя безрукой женщины? И она, тем не менее, может выполнить вдвое больше работы, чем любой мужчина, да еще и сделать ее правильно.
Сценаристы извиняются за любые недопонимания, которые могло вызвать первоначальное заявление.
Так или иначе, в тот момент, когда нашему взгляду предстали величайшие сокровища Лувра, обеим сценаристам пришла в голову одна и та же мысль: где здесь туалет? В ходе поиска автору этой статьи пришла в голову еще одна мысль: наша группа лицемерна. В конце концов, нас обидело, что Лувр не позволил нам исправить Мону Лизу. А в то же время мы и сами не без подобного греха. В выпуске журнала TechNet Magazine за январь 2008 года мы написали статью о использовании регулярных выражений в сценариях. Эта статья – превосходный пример «смотри, но не трогай»: мы показали, как использовать регулярные выражения для определения проблем в текстовом файле, но не показали, как решать эти проблемы. Шьорт побьери!
Примечание: так если сценаристы из группы Scripting Guys посетили Лувр в ноябре 2007 года, как могла у того из них, что пишет эту статью, возникнуть неожиданная мысль в статье, которая появилась в TechNet Magazine лишь в январе 2008 года? Ничего себе загадка, да? Должно быть, дело в разнице часовых поясов между Редмондом и Парижем.
К счастью (и в отличие от сотрудников Лувра), мы умеем признавать свои ошибки. Мы были неправы, показав только как искать что-либо с помощью регулярных выражений, нам следовало показать и как это что-либо заменять с помощью регулярных выражений,. По сути, нам следовало показать читателю сценарий, подобный приведенному на рис. 1..
Figure 1 Найти и заменить (Close Figure 1)
      Set objRegEx = _
    CreateObject("VBScript.RegExp")

objRegEx.Global = True
objRegEx.IgnoreCase = True
objRegEx.Pattern = "Mona Lisa"

strSearchString = _
    "The Mona Lisa is in the Louvre."
strNewString = _
    objRegEx.Replace(strSearchString, _
                     "La Gioconda")

Wscript.Echo strNewString
Впрочем, по правде говоря, это довольно-таки заурядное использование регулярных выражений: все, что мы здесь делаем, это заменяем все экземпляры строкового значения Mona Lisa на La Gioconda («Так, куда я дел эти брови?» по итальянски). Надо заметить, эту замену было бы куда легче произвести, используя функцию Replace («Заменить») VBScript. Но не бойтесь: мы используем этот нехитрый маленький сценарий, чтобы объяснить читателям, как выполнять операции поиска и замены с помощью регулярных выражений, а когда это будет сделано, мы продемонстрируем некоторые из более хитрых вещей, которые можно проделать с помощью этих выражений.
Как можно заметить, этот сценарий весьма прост. Мы начинаем с создания объекта VBScript.RegExp, нечего и говорить, что именно этот объект позволяет нам использовать регулярные выражения внутри сценария VBScript. После создания объекта мы присваиваем значения трем из свойств объекта:
Global («Глобальный») Установив это свойство на True, мы указываем сценарию найти (и заменить) каждый экземпляр Mona Lisa в целевом тексте. Если свойство Global установлено на False (значение по умолчанию), сценарий будет искать и заменять только первый экземпляр Mona Lisa.
IgnoreCase («Игнорировать регистр») Устанавливая IgnoreCase на True, мы указываем сценарию, что хотим выполнить не зависящий от регистра поиск, другими словами, мы хотим, чтобы mona lisa и Mona Lisa воспринимались одинаково. По умолчанию, VBScript выполняет зависящий от регистра поиск, а это значит, что благодаря строчным и прописным буквам mona lisa и Mona Lisa рассматриваются как совершенно различные значения.
Pattern («Шаблон») Свойство Pattern содержит искомое значение. В данном случае мы без затей ищем простое строковое значение: Mona Lisa.
Далее мы присваиваем текст, который следует искать, переменной, именуемой strSearchString:
strSearchString = "The Mona Lisa is in the Louvre."
Затем мы вызываем метод регулярного выражения Replace («Заменить») и передаем этому методу два параметра: целевой текст, который следует искать (переменная strSearchString), и текст-замену (La Gioconda). Что мы здесь и делаем:
strNewString = objRegEx.Replace(strSearchString, "La Gioconda")
Вот и все. Измененный текст сохраняется в переменной strNewString. Если вывести значение strNewString, то должно получиться следующее:
The La Gioconda is in the Louvre.
Грамматика может быть несколько сомнительной, но основная идея понятна.
Как мы уже отмечали раньше, все это замечательно, но избыточно; точно того же можно достигнуть, используя следующие строки кода (на самом деле, при желании можно было бы уместить все в одну строку):
strSearchString = "The Mona Lisa is in the Louvre."
strNewString = Replace(strSearchString, "Mona Lisa", "La Gioconda")
Wscript.Echo strNewString
Другими словами, давайте посмотрим, можно ли сделать с регулярными выражениями что-либо интересное, что нельзя сделать с помощью функции Replace в VBScript.
Хм, ни у кого никаких идей? Ну, вот одна, для примера. Часто нам, сценаристам, приходится копировать текст из одного типа документа в другой. Порой это работает неплохо, порой нет. Когда это не работает, часто возникают проблемы с интервалами между словами, приводящие к тексту, который выглядит примерно следующим образом:
Myer Ken, Vice President, Sales and Services
Кошмар, только взгляните на все эти лишние пробелы! И в этом случае полезность функции Replace ограничена. Почему, спросите вы? Ну, у нас имеется кажущееся случайным число лишних пробелов: между словами их может быть 7 или 2, или 6. Это делает сложным исправление проблемы с помощью Replace. Например, при попытке искать два последовательных пробела (заменяя их одним пробелом между словами), мы получим следующее:
Myer Ken, Vice President, Sales and  Services
Это лучше, но не намного. Есть способ, которым можно было бы сделать это, но он требует поиска случайного числа пробелов (скажем, 39), выполнения замены; вычитания единицы из начального числа, поиска 38 пробелов, выполнения замены, и т.д., и т.п. В качестве альтернативы можно использовать этот гораздо более простой (и гораздо более надежный) сценарий с регулярными выражениями:
Set objRegEx = CreateObject("VBScript.RegExp")

objRegEx.Global = True
objRegEx.Pattern = " {2,}"

strSearchString = _
"Myer Ken, Vice President, Sales and Services"
strNewString = objRegEx.Replace(strSearchString," ")

Wscript.Echo strNewString
Ключом к этому сценарию (как и к большинству сценариев с регулярными выражениями) является Pattern:
objRegEx.Pattern = " {2,}"
Здесь производится поиск 2 (или более) последовательных пробелов. Из чего можно понять, что этот Pattern ищет 2 (или более) последовательных пробела? Ну, внутри наших двойных кавычек имеется единственный пробел, за которым следует такая конструкция: {2,}. В синтаксисе регулярных выражений это означает искать как минимум два последовательных экземпляра предыдущего символа (в данном случае, пробела). А что если последовательных пробелов 3, или 4, или 937? Ничего страшного, все они тоже будут уловлены. (Если, по какой либо причине, нам нужно было бы уловить минимум 2 пробела, но не более чем 8, мы бы использовали синтаксис {2,8}, где 8 указывает максимальное число совпадений.)
Другими словами, при каждом обнаружении 2 или более пробелов одного за другим все эти последовательные пробелы будут заменены на единственный пробел. Что получится из нашего начального значения строки, полного лишних пробелов? Вот что:
Myer Ken, Vice President, Sales and Services
Видите? Сценаристы действительно могут вносить улучшения. Жаль, что парни в Лувре не дали нам добраться до Моны Лизы.
Вот еще одна интересная и достаточно частая ситуация. Предположим, что у вашей компании имеется каталог телефонов, и все номера телефонов в нем отформатированы следующим образом:
555-123-4567
Но теперь босс решил, что все номера телефонов должны быть отформатированы, чтобы выглядеть следующим образом:
(555) 123-4567
Как предполагается переформатировать все эти телефонные номера? Ну, если нам будет позволено, мы можем предложить сценарий, подобный следующему:
Set objRegEx = CreateObject("VBScript.RegExp")

objRegEx.Global = True
objRegEx.Pattern = "(\d{3})-(\d{3})-(\d{4})"

strSearchString = "555-123-4567"
strNewString = objRegEx.Replace _
(strSearchString, "($1) $2-$3")

Wscript.Echo strNewString
Здесь мы ищем последовательность из 3 цифр (\d{3}), за которой следует тире, за которым следуют еще 3 цифры, тире и 4 цифры. Другими словами, мы ищем следующее (где каждый знак Х представляет число от 0 до 9):
XXX-XXX-XXXX
Примечание: так откуда мы знаем, что \d{3} укажет сценарию искать три числа, стоящие рядом друг с другом? Ну, насколько можно вспомнить, мы прочитали об этом где-то. То ли в шокирующей финальной главе «Кода Да Винчи», то ли в справке по языку VBScript из интерактивной версии MSDN® (см. go.microsoft.com/fwlink/?LinkID=111387).
Возможность искать случайные телефонные номера с помощью регулярных выражений – это замечательно. Но у нас все еще остается крупная проблема. В конце концов, мы не можем этот заменить этот случайный телефонный номер на другой случайный телефонный номер, нам нужно использовать тот же самый номер, лишь немного иначе отформатированный. Как же мы можем эту сделать?
Само собой, используя следующий заменяющий текст:
"($1) $2-$3"
$1, $2 являются $3 примерами «обратной ссылки» регулярного выражения. Обратная ссылка – это просто часть найденного текста, которую можно сохранить и использовать повторно. В данном конкретном сценарии мы ищем три «под-совпадения»:
  • Набор из 3 цифр
  • Еще один набор из 3 цифр
  • Набор из 4 цифр
Каждому из этих под-совпадений автоматически назначается обратная ссылка: первому один доллар; второму два и так далее, вплоть до девяти. Другими словами, в этом сценарии трем частям нашего телефонного номера автоматически назначаются обратные ссылки, показанные на рис. 2..
Figure 2 Обратные ссылки телефонного номера (Close Figure 2)

Часть телефонного номера | Обратная ссылка
555 | $1
123 | $2
4567 | $3
В строке замены мы используем эти обратные ссылки, чтобы гарантировать повторное использование верного телефонного номера. Наш заменяющий текст просто говорит следующее: взять первую обратную ссылку ($1) и заключить ее в кавычки. Оставить пробел, затем вставить вторую обратную ссылку ($2), за которой следует тире. Наконец, добавить третью обратную ссылку ($3).
Что это все даст нам? Это даст нам телефонный номер, выглядящий следующим образом:
(555) 123-4567
Неплохо, совсем неплохо.
Вот вариант сценария для телефонных номеров. Предположим, что организация установила совершенно новую телефонную систему, и, как часть этого изменения, все телефонные номера теперь имеют один префикс; тогда как ранее номера могли начинаться с 666, 777 или 888, все они теперь начинаются с 333. Можем ли мы переформатировать телефонные номера и изменить их префиксы одновременно? Конечно, можем:
Set objRegEx = CreateObject("VBScript.RegExp")

objRegEx.Global = True
objRegEx.Pattern = "(\d{3})-(\d{3})-(\d{4})"

strSearchString = "555-123-4567"
strNewString = objRegEx.Replace _
(strSearchString,"($1) 333-$3")

Wscript.Echo strNewString
Видите, что мы здесь сделали? Мы просто удалили старый префикс (обратная ссылка $2) в нашем замещающем тексте; на ее место мы поместили жестко закодированное стандартное значение префикса 333. Как будет выглядеть телефонный номер 555-123-4567 после выполнения этого измененного сценария? Он должен выглядеть сильно похожим на следующее:
(555) 333-4567
Вот еще одно распространенное использование обратных ссылок. Предположим, что у нас имеется значение строки, выглядящее следующим образом:
Myer, Ken
Есть ли у нас способ перевернуть это значение и отобразить имя вот так:
Ken Myer
Ну, мы бы выглядели довольно глупо, если б у нас его не было, верно? Вот сценарий, который делает именно это:
Set objRegEx = CreateObject("VBScript.RegExp")

objRegEx.Global = True
objRegEx.Pattern = "(\S+), (\S+)"

strSearchString = "Myer, Ken"
strNewString = objRegEx.Replace _

strSearchString,"$2 $1")

Wscript.Echo strNewString
В данном конкретном сценарии мы ищем слово, (\S+), за которым следует запятая, за которой следуют пробел и еще одно слово. (В данном случае мы используем \S+ чтобы представить «слово»). Конструкция \S+ значит любой последовательный набор любых символов, отличных от разделителя. Другими, словами, это может быть буква, число, символ; на деле, практически что угодно, кроме пробела, знака табуляции или символа возврата каретки. Как можно заметить, здесь мы ожидаем найти два подсовпадения: представляющее фамилию ($1) и представляющее имя ($2). В силу этого мы можем отобразить имя пользователя как FirstName LastName, используя следующий синтаксис:
"$2 $1"
Где запятая? Ну, она здесь явно не нужна, так что мы ее выкинули.
Примечание: что забавно, отчего-то мы задумались и о редакторе сценариев тоже. Хм...
Теперь покажем вам еще одну вещь, и рабочий день окончен. (Ну ладно, рабочий месяц.) Она не на 100% надежна; в конце концов, мы не хотим слишком усложнять вводную статью вроде этой. (А регулярные выражения потенциально могут стать очень сложными.) Так или иначе, вот сценарий, который в большинстве случаев удаляет ведущие нули из значений вроде 0000.34500044:
Set objRegEx = CreateObject("VBScript.RegExp")

objRegEx.Global = True
objRegEx.Pattern = "\b0{1,}\."

strSearchString = _
"The final value was 0000.34500044."
strNewString = objRegEx.Replace _
strSearchString,".")

script.Echo strNewString
Как обычно, это работает только благодаря шаблону: "\b0{1,}\." Мы начинаем с поиска границы слова (\b); это гарантирует, что мы не удалим нули в значении вроде 100.546. Мы затем ищем один или несколько нулей – 0{1,} – за которыми следует знак десятичной дроби (\.). Если этот шаблон найден, мы заменяем эти нули (и знак десятичной дроби), на единственный знак десятичной дроби ".". Если все пойдет по плану, это преобразует нашу строку в следующее:
The final value was ..34500044.
Все время, отведенное нам на этот месяц, истекло. Прежде чем расстаться, мы можем заметить, что не успела краска на картине высохнуть, как Мона Лиза стала предметом существенных споров. Кто эта таинственная женщина? Почему она так улыбается? Почему у нее нет бровей? Некоторые из историков искусства даже предположили, что Мона Лиза вообще не женщина, а картина на деле является автопортретом Леонардо да Винчи. (Если это верно, ему бы стоило найти нового портного.) Между тем, образовательный фонд Unarius Educational Foundation пошел еще дальше, утверждая, что картина на деле является изображением «родственной души» Леонардо в «высшем мире» и что эта родственная душа направляла руку Леонардо. По примечательному совпадению, выпуск «Эй, сценарист!» за этот месяц был написан точно так же.
Это значит, что все претензии следует отправлять родственной душе сценариста, написавшего эту статью, пребывающей в отделении Майкрософт в высшем мире. Спасибо.

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

Май 2008 года: Сценарий-доку
В этом месяце мы играем в судоку, но с неожиданным поворотом. Вместо числе от 1 до 9 в сетке расположены буквы и символы, составляющие командлет Windows PowerShell™. В итоговом решении одна из строк, читаемых поперек, составит имя командлета.
Примечание: если вы еще не знаете, как играть в судоку, в Интернете существует, наверное, несколько тысяч веб-узлов, где можно найти правила, так что, извините, мы не будем повторять их здесь.

Головоломка-сценарий доктора Скрипто.
Ответ: сценарий-доку, май 2008 года

Программисты корпорации Майкрософт работают... ну хорошо, получают зарплату в корпорации Майкрософт. Когда они не играют в бейсбол, не тренируют бейсбольную команду, не смотрят бейсбол и не занимаются другими делами, они заведуют центром сценариев TechNet. Веб-узел проекта находится по адресу www.scriptingguys.com..


 На страже безопасности: Принципы квантовой безопасности
На страже безопасности
Принципы квантовой безопасности
Йеспер М. Йоханссон (Jesper M. Johansson)

Появление в обсуждении чего-либо неожиданного, но ценного может доставить массу удовольствия. С некоторых пор я использую для объяснения концепций безопасности принцип неопределенности Гейзенбега. (Те, кому довелось услышать мою историю про единорога, знают, что я люблю использовать фундаментальные теории из других дисциплин, чтобы доказывать свои положения.) Как это ни странно,
фундаментальные концепции из других областей науки порой накладывают отпечаток на сферу информационной безопасности.
Принцип неопределенности Гейзенберга, происходящий из квантовой физики, основан на соотношении, показанном на рис. 1. Сам принцип утверждает, что положение (p) и импульс (x) элементарных частиц соотносятся таким образом, что при повышении точности измерения позиции понижается точность измерения импульса. Нижней границей произведения точностей измерения двух факторов является результат умножения постоянной Планка на небольшую фиксированную величину. Выражаясь более общим языком, этот принцип утверждает, что нельзя абсолютно точно измерить несколько определенных величин для одной и той же частицы одновременно.
Figure 1 Heisenberg Uncertainty Principle
Figure 1 Heisenberg Uncertainty Principle
Это напрямую относится к предсказанию областей неопределенности, которые, по сути, позволяют предсказать, насколько неопределенным является состояние ряда величин для частицы. Хотя предсказать области еще нельзя (пока), важен тот факт, что невозможно точно предсказать, как две переменных в одной компьютерной сети повлияют на безопасность этой сети.
Также возникает необходимость компромисса. Хотя в области защиты информации и не действует постоянная Планка, но добиться всего и сразу нельзя и тут. Наиболее очевидный из компромиссов – между безопасностью и удобством использования либо полезностью. Если на секунду забыть о доступности (и, честно говоря, я думаю, что сотрудники, работающие над безопасностью, не должны отвечать еще и за доступность, если речь не идет об атаках типа «отказ в обслуживании»), то простейшим способом обезопасить устройство является его отключение. Тут уж в него не влезешь. Полезность, однако, бодро стремится к нулю.
Подобным образом, хотя это и обойдется существенно дороже, утечки конфиденциальных данных можно гораздо надежнее предотвратить, применив недешевую программу предотвращения потери данных, чем рассылая раз в год сотрудникам электронные письма, предупреждающие, что приложения обмена мгновенными сообщениями не следует применять на работе. Но готова ли организация заплатить за средство предотвращения потери данных? Как можно заметить, квантовая физика ближе к безопасности, чем может показаться.

Кошка Шредингера
Родственная, но отличающаяся концепция квантовой физики объясняется в притче о кошке Шредингера. Известно, что Эрвин Шредингер, выдающийся физик двадцатого столетия, вел долгий спор с Альбертом Эйнштейном (как вы знаете, тоже выдающимся физиком того времени) о концепции суперпозиции. Шредингер считал абсурдными области квантовой механики, предусматривавшие суперпозицию (наложение друг на друга) двух различных состояний.
Чтобы обосновать свою мысль, Шредингер предложил мысленный эксперимент, в котором кошка запиралась в герметичный ящик. Другим предметом в ящике был контейнер с ядом, открытие которого контролировалось распадом некоего (воображаемого) радиоактивного атомного ядра. Если оно распадалось, яд высвобождался и кошка умирала.
Атомное ядро, управляясь, как и все объекты микромира, законами квантовой механики, существует в суперпозиции состояний. Определенно являющаяся объектом макромира кошка, поскольку ее состояния целиком зависит от состояния объекта атомного ядра, также существует в суперпозиции состояний. Только пронаблюдав за реальным состоянием кошки, мы наконец помещаем ее в определенное состояние «живости» или «мертвости».
Шредингер, само собой, придумал это как иллюстрацию абсурдности некоторых законов квантовой механики при применении к макромиру. Тем не менее, его пример часто считается породившим то, что на языке дилетантов именуется «эффектом наблюдателя». Эффект наблюдателя, когда он применяется не только к системам микромира в квантовой механике, представляет интерес для нас, специалистов по безопасности. Попросту говоря, акт наблюдения над чем-либо меняет это «что-то».
Эффект наблюдателя
Если немного подробнее, то представьте себе чашку с чаем. Чтобы узнать температуру чая, в чашку помещают термометр. Предположим, что чай нагрет до 80 градусов Цельсия, а температура самого термометра – 22 градуса (комнатная). В момент помещения термометра в чай он начинает поглощать тепло из чая, и чай отдает часть своего тепла на нагрев термометра. В скором времени температура чая и термометра станет одинаковой. Однако она не будет равна ни 80, ни 22 градусам, а будет равной какому-то среднему значению. Таким образом, измерение температуры чая изменило ее.
Эффект наблюдателя тоже имеет отношение к безопасности информации. При каждой попытке сделать что-либо для уменьшения проблемы с безопасностью происходит изменение средств обеспечения безопасности в силу изменения системы. За отсутствием лучшего термина, я назову это «эффектом текучести средств обеспечения безопасности» (SPFE).
Один из простейших примеров находится в случае зависимости учетных записей служб. В главе 8 книги Protect Your Windows Network («Защитите свою сеть Windows») (protectyourwindowsnetwork.com) я рассматриваю установку службы обнаружения вторжения (Intrusion Detection Service – IDS) на компьютерах для обнаружения атак. Однако IDS ведет журнал на центральной системе и требует высокопривилегированного доступа к наблюдаемым системам. Обычно это значит, что служба работает через высокопривилегированную учетную запись службы.
Если любая из этих систем оказывается взломанной, злоумышленник может получить доступ к данным учетной записи службы и получить доступ ко всем остальным системам, помимо отключения самой IDS. Это идеальный пример SPFE. Установка программы обеспечения безопасности создает новую потенциальную угрозу для нее.
В других примерах SPFE нет недостатка. Сделанное Стивом Райли (Steve Riley) описание причин, по которым 802.1x сталкивается с определенными проблемами в проводных сетях (microsoft.com/technet/community/columns/secmgmt/sm0805.mspx), дает еще один отличный пример. Очевидно, что использование брандмауэров на узлах весьма желательно во многих средах. Однако в сочетании с 802.1x это делает определенный тип атак возможным там, где ранее он возможен не был. Опять-таки, технология безопасности изменяет средства обеспечения безопасности в среде и делает возможной невозможную в противном случае атаку.
Это не значит, что упомянутые выше меры бесполезны по своей сути и что их следует избегать. Это значит, что необходимо рассматривать последствия своих действий для системы безопасности в целом. При управлении рисками следует оценивать реальное влияние действий и предотвращений на степень риска. При решении проблемы нельзя заканчивать все на простом применении контрмер. Безопасность – это процесс в самом буквальном смысле. Необходимо использовать стратегию глубокой защиты, не забывая при этом, как добавляемые средства защиты изменят средства обеспечения безопасности и как надо бороться с новыми угрозами, возникающими из-за этой стратегии.

Совершенствующаяся стратегия усиления защиты
Я работал над руководствами по усилению защиты в течении более чем 10 лет. Глядя на первые несколько руководств, над которыми работал, я теперь вижу, что они были просто списками параметров, которые стоило включать согласно моему мнению и мнению моих коллег. В то время общая стратегия безопасности была наивной – руководствуясь, по сути, стремлением включать все, что предназначалось для обеспечения безопасности. О том, что оно могло быть отключено по умолчанию по каким-либо весомым причинам, думали не слишком часто.
Со временем я понял, что для эффективного усиления защиты необходимо его тщательное обдумывание, а также оценка угроз, которым подвержена система. Это откровение привело к ситуациям, которые можно увидеть в руководстве по усилению защиты Windows 2000 (go.microsoft.com/fwlink/?LinkID=22380). Естественным развитием этого было разбиение руководства на части, посвященные различным уровням угрозы, что можно увидеть в руководстве по безопасности Windows Server 2003 (go.microsoft.com/fwlink/?linkid=14846).
Все это время меня беспокоил факт, что даже после установки и включения всего, что предусматривало руководство, проникновение в систему через взлом было все же возможно. Это обычно вызывалось пропущенными исправлениями, пропускавшей меня эксплуатационной практикой или небезопасным программным обеспечением от сторонних производителей.
Получается, что усиление защиты, описанное в этих руководствах, не особенно увеличивало средства обеспечения безопасности в целом. Оно свелось лишь к нескольким ключевым вещам. На деле, самая защищенная система из созданных мною (msdn2.microsoft.com/library/aa302370) использовала только четыре-пять изменений из этих руководств безопасности, причем ни одно из них на деле не остановило ни одной атаки. К несчастью, пользователи хотят просто получить большую синюю кнопку «Обеспечить безопасность», автоматически защищающую системы, но увы, на деле безопасность устроена несколько сложнее.

Как подходить к риску
Чтобы получить защищенную систему (в отличие от конечного состояния безопасной системы), необходим разумный подход к риску. Следует знать, с какими рисками сталкивается система, решить, которые из них следует уменьшить, и затем понять, как их уменьшить, чего редко можно добиться, переводя переключатели.
Обычно переключатели безопасности разрабатываются для конкретных ситуаций, и создаваемая ими настройка не обязательно идеальна для случая пользователя. Вместо этого они дают хорошее основание для начала и доступны в основном потому, что значительная часть рынка требует этих быстро усиливающих безопасность изменений. Большая их часть уже включена по умолчанию в современных программах, а те, что не включены, скорее всего имеют значительные побочные эффекты.
Более того, включение многих переключателей может создать неподдерживаемую и нестабильную систему, которая не способна выполнить свои задачи – только лишь ради ослабления еще не оцененных угроз. SPFE и квантовая физика советуют нам повторить анализ после наладки безопасности, но слишком многие организации забывают про это. На самом деле они забывают про анализ угроз вообще. Если начать с реального анализа угроз, то выяснится, что реальное значение имеют отнюдь не безликие ограничения на перечисление имен учетных записей и радикальные изменения списка управления доступом.
На деле реальное значение имеет определение того, должна ли система предоставлять определенную службу, если да, то кому, и последующее обеспечение этой политики. Значение имеет допуск к связи с системой только тех систем и пользователей, которым это совершенно необходимо. Значение имеет обеспечение работы всех приложений и пользователей с минимальным возможным уровнем полномочий. Короче говоря, значение имеет разумный подход к безопасности и выполнение сложного анализа, позволяющего каждой системе быть ответственной за собственную безопасность.
Именно по этой причине в составе современного подхода к безопасности есть такие средства, как изоляция серверов и доменов (microsoft.com/sdisolation), мастер настройки безопасности (SCW) в продуктах Windows Server® и средства диспетчера серверов для управления ролями в Windows Server 2008. Эти средства проводят пользователя через процесс формулировки ситуаций, которые необходимо поддерживать, и затем помогают ему запереть свои системы нужным образом. Конечно, эти средства не предлагают требуемой всеми панацеи, но они создают поддерживаемые настройки, реально выполняющие задачи, для которых покупалось программное обеспечение.

Применяйте безопасность там, где необходимо
Все это значит, что в обеспечении безопасности нельзя полагаться на другие сущности или простые изменения. Каждый ресурс должен быть способен защищать себя, поскольку такие концепции, как «периметр» или «внутренняя сеть», в наше время лишены смысла.
Подавляющее большинство сетей организаций следует рассматривать как, в лучшем случае, полувраждебную среду. Необходимо понимать это и предпринимать соответствующие действия, не полагаясь исключительно на запоздалые советы по усилению защиты. Для начала следует осознать свои потребности и искать совета от тех, кто также их осознает.
Недавно я наблюдал гостя на веб-трансляции, рекомендовавшего пользователям из сферы малого бизнеса посетить веб-узел Министерства национальной безопасности, чтобы загрузить руководство по усилению защиты для Internet Explorer®. С какой стати ожидать, что правительственное учреждение, в задачи которого входит защита вооруженных сил и органов охраны общественного порядка, предоставит разумное руководство по защите веб-обозревателя для малого бизнеса? Это идеальный пример неудовлетворительной логики, все еще господствующей в сфере компьютерной безопасности. Предполагается, что раз руководство выпущено правительственным учреждением, называемым трехбуквенной аббревиатурой, то оно должны обеспечить высокую безопасность.
Выбирать обычно предлагается из двух вариантов: можно иметь «высокую безопасность» или «низкую безопасность». Вернее было бы сказать, что выбирать приходится между «высокой безопасностью» и «подходящей безопасностью». Безопасность, как и одежда, имеет свой размер.
На самом деле, высокая безопасность не подходит всем – и обычно даже не большинству! Это не конечная цель, к которой следует стремиться. Это специализированная настройка для систем, защищенность которых является вопросом жизни и смерти. Если это соответствует профилю риска и модели угроз, используйте высокую безопасность.
Если это не соответствует профилю риска и модели угроз, используйте что-либо более подходящее. Скорее всего, большинство параметров, которые можно настроить, уже установлены соответственно уровню профиля среднего риска по умолчанию. Это состояние по умолчанию, используемое в большинстве нынешних продуктов Майкрософт, предоставляет разумный компромисс между безопасностью с одной стороны и удобством использования, полезностью и производительностью – с другой. Что же до усиления защиты, оно обычно делается за пользователя.
Теперь следует рассмотреть другие меры безопасности. Хорошим местом для старта будет центр безопасности TechNet (microsoft.com/technet/security) и, само собой, книги вроде Windows Server 2008 Security Resource Kit.

Все дело в управлении рисками
К этому моменту читатели уже вероятно поняли, куда я клоню: управление рисками. Принцип неопределенности Гейзенберга здесь был при том, что добиться сразу и всего нельзя. Эта часть принципа – не формула Циолковского.
Однако смысл истории с кошкой Шредингера слишком часто проходит мимо внимания людей. Важно не только проанализировать все стороны проблемы и выработать компромиссное решение, необходимо также проанализировать изменения, вносимые решениями. Основательная стратегия управления рисками оценивает влияние этих изменений на систему и то, были ли эти изменения применены как часть стратегии уменьшения рисков либо по любой другой причине.

Ожидаемый ущерб в годовом исчислении
Распространенным способом измерения риска и методом, преподаваемым на многих сертификационных курсах по безопасности, является уравнение ожидаемого ущерба в годовом исчислении (ALE), показанное на рис. 2. Стандартное уравнение ALE просто. Определяется вероятность происшествий и издержки, причиняемые каждым случаем, после чего два значения перемножаются. Это дает сумму, которую, вероятно, отнимут происшествия в сфере безопасности за год. Если стоимость риска достаточно высока, реализуется ее снижение.
Figure 2 ALE is the probability of a loss, multiplied by the cost of the loss per incident
Figure 2 ALE is the probability of a loss, multiplied by the cost of the loss per incident
Проблема в том, что стандартное уравнение ALE не оценивает стоимость снижения. Оно не просто стоит денег само по себе, многие меры по уменьшению риска имеют побочные эффекты, также влекущие затраты.
Взгляните на одну из самых стандартных настроек безопасности: блокировку учетной записей. Многие организации применяют блокировку учетных записей якобы для того, чтобы не давать злоумышленникам угадывать пароли. Вероятность такого угадывания можно подсчитать математически. При наличии изобретательности можно также высчитать среднюю стоимость ущерба, причиняемого успешным угадыванием пароля злоумышленником. Основываясь на этих двух цифрах, многие организации заключили, что результаты уравнения ALE неприемлемы и, следовательно, необходима блокировка учетных записей.
Однако эта конкретная мера по уменьшению риска связана с затратами, которые порой не принимают во внимание. Прежде всего это стоимость ее собственного применения, хотя в этом случае она практически минимальна. Но чтобы быть верным, уравнение также должно включать стоимость побочных эффектов, вызываемых снижением риска.
В первую очередь это затраты, связанные с разблокировкой учетных записей пользователей службой поддержки. Если учетная запись блокируется лишь на короткий период времени, скажем 15 минут, утрата производительности в этот период все же сопряжена с издержками. Этот фактор подсчитывается как издержки от каждого происшествия, умноженные на вероятность этого происшествия в данный период времени. В данном случае издержки умножаются на ожидаемое число событий блокировки – число, которое могут предоставить журналы событий.
Также необходимо оценить фактор раздражения пользователей. Много отдельных примеров свидетельствуют о том, что пользователи, если им надо опасаться блокировки учетной записи, начинают использовать более простые пароли, потому что при их наборе сложнее ошибиться. В силу этого вероятность происшествия, которого мы хотели избежать, не падает до нуля после применения мер снижения риска.
Наконец, сами эти меры могут ввести новые уязвимости, которых ранее в системе не было. В случае блокировки учетных записей злоумышленник может использовать ее для отключения всех учетных записей в сети просто путем многократных попыток неверно угадать их пароли. Вероятность этого существует, и каждый случай добавляет свои издержки.
Принимая все это во внимание, ясно, что уравнение ожидаемого ущерба надо скорректировать. Во-первых, нужно изменить вероятность происшествия. Оно будет менее вероятным, чем ранее, но вероятность, как показано выше, не опустилась до нуля. Стоимость каждого происшествия также могла измениться. К этому результату надо добавить издержки на снижение риска. Они состоят из затрат на реализацию плюс суммы издержек всех побочных эффектов в годовом исчислении. Каждая из этих издержек является производной от вероятности побочного эффекта и затрат, вызываемых каждым из его проявлений. Если немного упростить представление уравнения, теперь получается более точное уравнение анализа риска, показанное на рис. 3.
Улучшенное уравнение на рис. 3 предлагает гораздо более точный способ анализа риска, связанного с определенной проблемой. Многие организации уже проанализировали свои риски этим способом. Но слишком многие все еще придерживаются упрощенных воззрений на риски, которые не указывают должным образом на необходимость анализа влияния мер по их снижению. Использование измененного уравнения ALE помещает эту необходимость на первый план.
Figure 3 Considering the additional costs of mitigation
Figure 3 Considering the additional costs of mitigation

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

Йеспер М. Йоханссон (Jesper M. Johansson)является архитектором программного обеспечения, который работает над программами безопасности, и пишущим редактором журнала TechNet Magazine. Он имеет докторскую степень по информационным системам управления, обладает более чем 20-летним опытом в области безопасности и званием наиболее ценного специалиста (MVP) Майкрософт по безопасности предприятий. Его последняя книга – Windows Server 2008 Security Resource Kit («Набор ресурсов безопасности Windows Server 2008»).


 Материалы о рабочей среде: Расставаясь с администратором
Материалы о рабочей среде
Расставаясь с администратором
Уэс Миллер (Wes Miller)

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

Как мы дошли до этого?
Мой вызов читателям: прочувствуйте все на себе
Тем, кто еще не начал думать о переводе администраторов в пользователей, следует начать. И я рекомендую начать с эксперимента на себе. Не на вспомогательной машине – это жульничество. Попробуйте это на своей основой системе, той, которую вы используете каждый день. Я также предлагаю сделать это, не используя контроль учетных записей пользователей, если используется Windows Vista®. Прежде чем проповедовать необходимость изменений или какой-либо работы в организации, неплохо бы попробовать все самому. Я полагаю, что читатели найдут работу не в качестве администратора не такой уж сложной – и то, что повышенная безопасность этого позволит реально уменьшить открытую для атак область организации.

То, что большинство пользователей действуют как администраторы, коренится в истории Windows®. В первых версиях Windows, до Windows NT® 3.1, каждый из интерактивных пользователей имел те же права, что и остальные – безопасности, по сути, не существовало. Для домашних систем это было не столь уж ужасно; это просто значило, что все программное обеспечение устанавливается одинаково. Предположение состояло в том, что пользователь владел компьютером и что все ПО устанавливалось для всех пользователей на этом компьютере.
При первом появлении Windows NT она явно не смогла сразу завладеть корпоративным рынком (не говоря уж о потребительском). А в силу совместимости Win32® между 32-разрядной версий Windows и Windows NT большинство поставщиков приложений не перестраивали свои приложения лишь ради инфраструктуры безопасности Windows NT. По сути, лишь с появлением Windows 2000 многие из ориентированных на потребителя независимых поставщиков ПО начали обращать внимание на Windows NT. Проблему вывела на первый план Windows XP, закончившая семейство Windows 9х.
Но приложения по-прежнему выпускались исходя из предположения, что каждый пользователь в системе имеет разрешение на запись в Program Files (пользователи не имеют), а также HKEY_LOCAL_MACHINE (HKLM) в реестре (пользователи не имеют) и HKEY_CLASSES_ROOT (пользователи не имеют). Особенно плохо в плане предположений о наличии доступа дело обстоит у игр; см. статью Мэтта Клэпэма (Matt Clapham) на эту тему по адресу technetmagazine.com/issues/2007/02/Gaming.
Это представляет проблему, поскольку многие межсистемные приложения хранят свои файлы и параметры реестра в этих местах, и для их установки необходим доступ на чтение и запись в эти места. Увы, некоторые приложения настаивают на записи в эти разделы после установки. Например, у моей дочери есть игра на основе Flash. Она пытается установить нестандартный проигрыватель при каждом запуске – а это значит, что когда моя дочь работает как пользователь, а не как администратор, приложение не запускается, выдавая неустранимую ошибку. Хотя это и крайний пример, да и речь идет о потребительском приложении, в реальности большинство непотребительских приложений не работают как следует при использовании пользователями, не являющимися администраторами. На самом деле, те, кто принял мой вызов (см. врезку «Мой вызов читателям: прочувствуйте все на себе»), могут обнаружить, насколько сама Windows нетерпима к работе в качестве пользователя.
Если взглянуть на рис. 1, можно увидеть, как выполнение IPConfig /release в качестве пользователя выглядит на Windows XP. Если сравнить это с рис. 2, можно заметить, что та же команда под Windows Vista выглядит немногим лучше, но, по крайней мере, можно понять причину ее сбоя. Отметьте, что средства работы с сетью в целом улучшены, чтобы позволить пользователям обновлять свои IP-адреса. Аналогично, попытка запуска окна управления компьютером (compmgmt.msc) в качестве пользователя позволяет выполнять ограниченный набор задач в обеих версиях – но обычно приводит к раздражающим тупикам, как показывает рис. 3. Хотя в Windows Vista изначально многие из средств в этом окне отсутствуют изначально, она предоставляет более четкие сообщения об отказе в доступе.
Figure 1 Running as a user under Windows XP
Figure 1 Running as a user under Windows XP
Figure 2 Running as a user under Windows Vista
Figure 2 Running as a user under Windows Vista
Figure 3 Misleading message after running compmgmt.msc as a user on Windows XP
Figure 3 Misleading message after running compmgmt.msc as a user on Windows XP

Почему это имеет значение
Так зачем об этом волноваться? Потому, что мы как специалисты по информационным технологиям должны начать приспосабливать приложения к пользователям с наименьшим уровнем прав вместо того, чтобы, наоборот, предполагать, что интерактивный пользователь владеет системой.
Увы, те же приложения, которые позволяют администраторам вести запись в разделы реестра, также дают любым вредоносным программам, запущенным в их пользовательском контексте, полный доступ ко всему, к чему он не закрыт напрямую через списки контроля доступа (ACL). В мире UNIX участники следуют правилам относительно избежания работы в качестве пользователя root (функционального аналога учетной записи администратора Windows) в основном потому, что экосистема программного обеспечения, требующая расширения границ модели безопасности, настолько мала, что практически незаметна.
Все же лучшее, что можно сделать – это быть предусмотрительным и работать в качестве администратора, только если это требуется прямо. Или, что еще лучше, запускать в качестве администратора лишь отдельные приложения. Это позволяет создать внутрисистемный брандмауэр, о котором я упоминал ранее. В результате, когда вредоносные или шпионские программы пытаются сделать что-либо неположенное, им это не удается – поскольку они не могут вести запись в реестр или места в файловой системе, где это необходимо для того, чтобы реально заразить систему (скажем, устанавливая службу или драйвер либо проводя установку для всех пользователей). Вдобавок, это позволяет ПО, борющемуся с вредоносными программами, сдерживать обнаруженные вредоносные программы, не подвергая перед этим риску всю систему.
Обратите, однако, внимание, что пользователи не являются неуязвимыми для атак. Хотя подобный класс вредоносных программ еще не распространен широко, есть программы, обладающие потенциальной возможностью успешно инфицировать контекст отдельного пользователя или уничтожать его данные. Но направления атаки таких программ ограничены. Как следствие, то же явление, которое делает число вредоносных программ низким на Linux или Macintosh (меньшее число потенциальных жертв, делающее их менее притягательным полигоном для авторов вредоносных программ) может сейчас помочь обеспечить общую безопасность ваших конечных пользователей и вашу собственную.

Устранить опытных пользователей?
Когда мы разрабатывали Protection Manager, одним из комментариев от клиентов было: «На Windows XP у нас все пользователи работают как опытные пользователи, а не как администраторы, так что мы в безопасности». На деле, однако, опытные пользователи стоят лишь в нескольких шагах от администраторов. Существует несколько потенциальных дыр, которые при небольшом усилии позволяют опытному пользователю Windows XP стать администратором. В реальности группа опытных пользователей была устранена на Windows Vista и Windows Server® 2008; она будет иметься только в системе, обновленной с предыдущей версии Windows. В общем, использования группы опытных пользователей всегда следует избегать, даже если используется Windows XP.

Полномочия с потерями
Те, кто читал мою мартовскую статью о тонких клиентах Windows (technetmagazine.com/issues/2008/03/DesktopFiles), могут вспомнить, что я выступал против идеи утончения Windows XP для сохранения места. В том же ключе, существует обычная практика перевода администраторов в пользователи, которую необходимо будет рассмотреть, причем рассмотреть внимательно. Это практика изменения списков контроля доступа на реестре и файловой системе с предоставлением пользователям возможности записи в места, куда они обычно производить ее не могут – что делает возможной работу проблемных приложений.
Очевидно, что лучший выбор – достать обновленную версию приложения, не требующую такого изменения, но это не всегда возможно. Если необходимо изменить полномочия (то есть избавиться от них), действуйте очень осторожно. Помните, что брандмауэр между пользователем и администратором определяется в основном полномочиями для реестра и файловой системы. Открытие их понижает защиту и потенциально расширяет область, уязвимую для вредоносного программного обеспечения – так что подходите к этому вопросу рассудительно.

Как насчет UAC?
Рассказ о переводе администраторов в пользователи не может быть полон без обсуждения контроля учетных записей пользователей (User Account Control – UAC) в Windows Vista. UAC, подобно похожим функциям в Mac OS X, позволяет работать «как администратору», но не подвергая себя настолько большому риску.
Как это осуществляется? Взгляните на рис. 4, на котором в проводнике по процессам показана программа cmd.exe. Экземпляр cmd.exe справа был запущен без повышения прав, когда я работал как администратор. Как следствие, хотя пользователь справа идентичен пользователю слева (где cmd.exe был запущен с повышением прав), само приложение не содержит необходимых прав и маркеров для того, чтобы оно (и пользователь, использующий этот экземпляр) могло выполнять задачи, требующие административных прав. UAC работает, понижая область, открытую для атак, внутри интерактивного контекста пользователя. Единственная проблема состоит в том, что системеWindows должно быть как-то указано, что этой задаче требуются административные права и что пользователь согласен с повышением прав, необходимым для ее выполнения.
Figure 4 Two instances of cmd.exe with different privileges
Figure 4 Two instances of cmd.exe with different privileges
Маленькие щиты в Windows Vista показывают, какие именно задачи требуют повышения прав (см. рис. 5). Эти задачи требуют повышения прав при каждом их запуске – и это одно из больных мест, которые пресса решила выделить в случае Windows Vista. Альтернатива, допуск более «постоянных» учетных данных, является потенциальной угрозой безопасности, которую можно использовать для упрощения использования брешей в безопасности системы.
Figure 5 Shields in Windows Vista indicate the need for elevation
Figure 5 Shields in Windows Vista indicate the need for elevation
Если UAC включен и пользователи работают просто как пользователи, у них будет запрошен набор административных учетных данных, когда приложение запросит административные права. Отметьте, что в данном случае, как и в случае использования runas либо psexec, приложение буквально работает в контексте пользователя, который запустил его, а не под UAC, как если бы его запустил администратор. В таком случае задачи работают в его контексте, но с повышенными правами.

Работа на Windows Vista в качестве пользователя?
При работе на Windows Vista лично я предпочитаю работать как пользователь, а не как администратор с UAC, поскольку я верю, что это лучший вариант для среднестатистического предприятия. В конце концов, пользователи полностью контролируют свои системы и, возможно, уменьшили возможные лазейки для вредоносных программ.
Вдобавок, если необходимо управлять пользователями с помощью групповой политики и ПО по борьбе с вредоносными программами, и если требуется централизованный контроль над тем, выполняются ли эти задачи, ключевым моментом является обеспечение того, что конечные пользователи – не администраторы. Если они администраторы, они могут останавливать службы, добавлять и удалять драйверы и так далее. Конечно, хитрый конечный пользователь и работая как пользователь может использовать Windows PE для обхода части препятствий, создаваемых безопасностью. BitLocker® может усложнить это, но, опять же, помните, что конечные пользователи с физическим доступом к своей машине могут при наличии времени, знаний и упорства сделать с ней все, что захотят.
Работа на Windows Vista в качестве пользователя не так уж отличается от работы на Windows XP в качестве пользователя. Я использую те же средства – PSExec, RunAs (а теперь и UAC) для выполнения задач в качестве администратора по мере необходимости. Здесь хорошо то, что немало задач, требовавших административных прав в Windows XP, более не требуют их. Например, пользователь Windows Vista может установить локальный принтер. (Сетевые принтеры могут быть установлены пользователями в Windows XP, но установка локального принтера требует административных прав.) В Windows Vista, пока пользователь физически сидит за машиной, а в хранилище драйверов находится драйвер принтера, он может установить принтер и управлять печатью на нем (дополнительные сведения приведены на странице go.microsoft.com/fwlink/?LinkId=111534). Обратите внимание, что в Windows Server 2008 эта функциональность отключена.
Само собой, пользователей изумляет функциональность часов (точнее, ее недостаток) при работе в качестве пользователя в Windows XP – попробуйте дважды щелкнуть часы, работая как пользователь (порой люди делают это, чтобы узнать дату вне зависимости от того, был ли этот компонент разработан для подобного использования или нет) – появится ошибка, показанная на рис. 6. Не слишком дружелюбно по отношению к пользователю. В Windows XP можно изменить политику, чтобы пользователи могли сделать это, но Windows Vista изменена, чтобы работать так изначально. Так что в целом работа в качестве пользователя, используется ли при этом UAC или работа ведется в качестве формального пользователя, а права повышаются в качестве другого, более терпима на Windows Vista, чем была на Windows XP.
Figure 6 In Windows XP, non-admins couldn't change the time
Figure 6 In Windows XP, non-admins couldn't change the time

Помните ограничения
Помните, что вывод пользователей из числа администраторов – не панацея. Выделенные конечные пользователи по-прежнему физически расположены на собственных ПК, и они могут довольно усердно работать над использованием брешей в безопасности собственных систем, особенно если политика или права пользователя создают для них неудобства либо не дают им выполнять свою работу.
Если пользователи работают как администраторы, обход любой групповой политики не составляет труда. Само собой, приложив небольшие дополнительные усилия, пользователи могут загрузится в Windows PE и изменить полномочия, для изменения которых у них обычно нету прав – хотя использование BitLocker либо другого шифрования диска/тома может сделать это невозможным или, как минимум, более сложным.
Самое важное, что можно сделать, если организация еще не начала перевод конечных пользователей на работу в качестве пользователей – познакомиться с причинами, по которым вам лично и организации следует тратить время, деньги и усилия на уход от работы пользователей в качестве администраторов.
Конечно, избавиться от старых приложений может быть непросто, – но если имеется приложение, которое просто нельзя запустить в качестве пользователя, лучше расстаться с ним, чем пожертвовать безопасностью организации. Можно вместо этого обдумать виртуализацию приложения – буквальное перемещение его на виртуальную машину, где пользователь является настоящим администратором. Это позволяет использовать приложение по мере необходимости и одновременно обезопасить остальную часть системы, превращая администраторов в пользователей.
Отметьте, что за всю статью я ни разу не использовал слова «блокировка» или производных от него. Многие считают превращение администраторов в пользователей частью задачи, часто описываемой с помощью этого слова. Возможно, дело в моем психологическом образовании или в моих текущих занятиях маркетингом, но я считаю, что лучше не использовать слова, которые заставляют конечных пользователей чувствовать, что у них отнимают права (хотя на уровне семантики так оно и есть).
Вместо этого обьратите основное внимание на преимущества для безопасности организации и убедитесь, что у вас имеется основательный план для особых случаев, когда либо конкретный пользователь совершенно не может работать в качестве пользователя, либо имеется определенная задача, требующая прав администратора. Будете ли вы использовать что-то сделанное вручную, вроде моего сценария Run.vbs (который можно найти на technetmagazine.com/issues/2007/03/DesktopFiles) или коммерческое решение, помогающее осуществлять перевод (которое позволяет скрывать подробности от конечных пользователей, заставляя все «просто работать»), но начинать движение к избавлению от администраторов следует как можно скорее. Постоянный автор статей для журнала TechNet Magazine, Аарон Маргосис (Aaron Margosis) является настоящим проповедником работы не в качестве администратора. Тем, кто еще не знаком с его блогом, следует с ним познакомиться – это лучшее место для получения подробных сведений по этой теме (см. blogs.msdn.com/aaron_margosis)

Уэс Миллер (Wes Miller) на данный момент является старшим техническим руководителем продуктов компании CoreTrace (www.CoreTrace.com) в г. Остин, штат Техас. Ранее Уэс работал в компании Winternals Software, а также в корпорации Майкрософт в должности руководителя программы. Связаться с Уэсом Миллером можно по адресу technet@getwired.com.


 Полевые заметки: Один компьютер, несколько мышей
Полевые заметки
Один компьютер, несколько мышей
Кентаро Тояма (Kentaro Toyama)

В настоящее время Индия – страна контрастов. С одной стороны, это суперсовременные ИТ-технологии и очень хорошо образованные сотрудники, которые занимаются разработкой компьютерных технологий для всего мира. С другой стороны, 70% населения страны живет менее чем на 2 доллара в день. Эти две противоположности встречаются в компьютерном классе в бедных государственных школах, где можно найти не более десятка компьютеров. Эти компьютеры – как правило, пожертвования, посколько у школ нет средств на их приобретение.
В подобных ситуациях учеников всегда больше, чем компьютеров. Как правило, вокруг одного компьютера можно найти около десяти детей, место за ним частенько получает сильнейший. Разумеется, слово «персональный» в словосочетании «персональный компьютер» подразумевает его использование одним человеком. Отделение Microsoft Research в Индии задумалось над тем, что можно сделать для того, чтобы доступ компьютеру получило большее количество детей.
Решение оказалось на удивление простым: MultiPointTM позволяет подключать к компьютеру несколько USB-мышей, и каждой из них соответствует отдельный курсор на экране (research.microsoft.com/users/udaip/multipoint.htm). В результате создается многопользовательская среда – наподобие игровой консоли, – и образовательные программы, написанные для парадигмы из нескольких мышей, позволяют многим ученикам работать на одном ПК одновременно.
Парадигма сразу же понравилась школьникам несмотря на беспокойство взрослых о том, что на экране будет полный хаос. После проведения серьезных исследований по сравнению настроек MultiPoint-PC, рассчитанной на пять человек, с настройками одного персонального компьютера для одного пользователя были получены следующие данные. Прежде всего, дети взаимодействуют с ПК и друг с другом в течение более длительных периодов времени, когда у них есть доступ к мыши, вероятнее всего, благодаря тому, что это веселее. Во-вторых, важно создавать программные приложения, которые способствуют взаимодействию, а не конкуренции, иначе некоторые дети, в особенности мальчики, вместо обучения устроят соревнование «кто быстрее». Кроме того, если предложение создано с учетом взаимодействия, школьники получают при работе с приложением MultiPoint те же навыки, что и за отдельным ПК, хотя бы в плане овладения терминологией. Дополнительные сведения об этом исследовании можно получить, перейдя по приведенной выше ссылке на MultiPoint.
При оптовой закупке каждая из мышей стоит всего лишь несколько долларов, а это значит, что при обеспечении школ приложениями MultiPoint стоимость компьютерного оборудования на ребенка значительно уменьшается. Например, ПК стоимостью 500 долларов США с пятью мышами для работы пятерых школьников стоит 105 американских долларов на ребенка — а все, что снижает стоимость оборудования на человека, очень приветствуется теми, кто занимается бюджетом на образование.
Отделы, посвященные неограниченному потенциалу развития (microsoft.com/unlimitedpotential) и образованию (microsoft.com/education) в корпорации Майкрософт признали значимость приложения MultiPoint для школ с низким бюджетом. Чтобы способствовать быстрому и повсеместному распространению приложения, был выпущен набор средств для разработки ПО, который позволяет специалистам, которые занимаются содержимым, беспрепятственно применять парадигму использования нескольких мышей для приложений на C#. Этот набор можно загрузить для бесплатного использования на любой компьютер с установленной системой ® для использования приложений MultiPoint по адресу (microsoft.com/downloads).
Целью этого набора MultiPoint как одной из программ под заголовком «Unlimited Potential» (Неограниченный потенциал) является расширение возможностей до максимально возможного числа учеников, а для этого нам нужна ваша помощь. Если захотите принять участие в создании образовательного приложения с помощью MultiPoint, дайте нам знать. На веб-узлах MultiPoint будут размещены ссылки на лучшие разработки в этой области.
Далее отделение Microsoft Research в Индии и India отдел служб терминалов рассматривают еще один способ общего доступа к ПК: Split Screen, где на один ПК и один монитор приходятся две мыши, две клавиатуры и две мыши. Монитор разделен пополам, и на каждой из половин запущен отедльный сеанс операционной системы.

Кентаро Тояма (Kentaro Toyama) – помощник директора по управлению в отделении Microsoft Research в Индии (research.microsoft.com/india) и руководитель группы исследований технологий в отделе растущих рынков (research.microsoft.com/research/tem), которая занимается разработкой технологий для экономически бедных сообществ по всему миру.


 О Windows из первых рук: Время 16-разрядных значков уже прошло
О Windows из первых рук
Время 16-разрядных значков уже прошло
Рэймонд Чен (Raymond Chen)

Как было отмечено в статье из рубрики «О Windows из первых рук» в номере за февраль 2008 г., из операционной системы Windows® исчезают некоторые функции. Обычно это происходит медленно и почти незаметно, а команда разработчиков каждый раз тихо празднует такое событие. Еще одна функция, не попавшая в операционную систему Windows Vista® - возможность доступа 32-разрядного кода к значкам, сохраненным в 16-разрядных модулях (по большей части в 16-разрядных EXE-файлах и библиотеках DLL).
Пока вы приводите все свои системы в соответствие с этим, помните о том, что 16-разрядный код по-прежнему имеет доступ к значкам, сохраненным в 16-разрядных модулях; все процессы происходят в 16-разрядном слое эмуляции. Пропала только возможность доступа к этим значкам из 32-разрядного кода, если более точно, возможность функций извлечения 32-разрядных значков, например, ExtractIcon, загружать эти значки из 16- разрядных библиотек DLL.
32-разрядный код, извлекающий значки из 16-разрядных модулей, не пользуется преимуществами функций ядра, например, FindResource, для поиска значков в файле. Вместо этого в коде должен реализовываться собственный мини-загрузчик, который анализирует заголовок 16-разрядного модуля, выполняет поиск таблицы ресурсов, а затем анализирует ее, чтобы найти нужные ресурсы значков. Только после выполнения всех этих операций 32-разрядный код преобразует пиксели в значок.
Как вы можете представить, выполняющий этот процесс код очень старый и несовершенный. Существует множество возможностей возникновения ошибок при анализе двоичных файлов, случайно или умышленно. Отдел производительности запросит изменение способа открытия файлов для улучшения производительности сетей, поскольку различные режимы открытия и совместного доступа имеют различные последствия эффектов кэширования сети. А специалисты, отвечающие за обеспечение надежности, могут запросить переписать код анализа, чтобы не использовать размещенные в памяти файлы. В конечном итоге стоимость обслуживания подобного кода начинает превышать предоставляемую ценность. Я имею в виду, разве кто-нибудь еще пишет 16-разрядные программы, так ведь?
Сейчас работа ваших 16-разрядных программ зависит исключительно от наличия 16-разрядного слоя эмуляции. (Да, в 64-разрядных версиях Windows Vista отсутствует 16- разрядный слой эмуляции, но это не шаг назад по сравнению с Windows XP; в 64-разрядных версиях Windows XP тоже нет 16-разрядного слоя эмуляции. Отсутствуют улучшения, но и ухудшения тоже.)
В Windows Vista теряется только одна возможность – выполнение функции ExtractIcon для 32-разрядных программ и получение значков из 16-разрядных библиотек DLL. Если в меню «Пуск» присутствует ярлык для 16-разрядной программы, теперь значок этого ярлыка будет выглядеть как общий значок программ, поскольку проводник Windows Explorer больше не может извлекать значки 16-разрядных программ из главного EXE-файла. Не большая потеря. Но если это вас настолько беспокоит, можно изменить свойства ярлыка и указать значок из 32-разрядного модуля.
Единственное, где эта утраченная функция, как мне кажется, создает проблемы, это библиотеки значков, созданные одним конкретным средством редактирования значков. По некоторым причинам по умолчанию программа сохраняет значки как ресурсы в 16-разрядных библиотеках DLL, что означает, что доступ к этим значкам из 32-разрядного кода более недоступен. Простым решением проблемы, конечно же, является повторное сохранение этих библиотек значков как ресурсов в 32-разрядных библиотеках DLL.
Я уверен, что в конечном счете будет написана (если еще не написана) простая программа для извлечения всех значков из 16-разрядной библиотеки DLL и создания 32-разрядной библиотеки ресурсов DLL с этими значками, чтобы люди, имеющие старые значки в 16- разрядных библиотеках DLL, смогли использовать их в ярлыках меню «Пуск». Но я должен предупредить, что если вы напишите такую программу, то, скорее всего, не найдете людей, которым она действительно нужна. Количество запросов подобной программы, полученное группой пользовательского интерфейса Windows: ноль.

Рэймонд Чен (Raymond Chen)на своем веб-узле The Old New Thing (Хорошо забытое старое) и в одноименной книге (издательство Addison-Wesley, 2007 г.) рассказывает об истории развития Windows и касается вопросов программирования в среде Win32. Он не пытается успеть попасть в закрывающиеся двери.