 TechNet Magazine April 2007

TechNet Magazine April 2007

Администрирование в Windows: Внутреннее устройство ядра Windows Vista: Часть 3

In this issue, we wrap up our in-depth discussion about what’s new in the Windows Vista kernel. In this final installment, we look at changes and new features pertaining to reliability, recovery, and security.

Mark Russinovich Администрирование в Windows: Аварийное восстановление пользователей и групп службы каталогов Active Directory

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

Gil Kirkpatrick Администрирование в Windows: Для чего нужна пользователю операционная система Windows XP Embedded

Хотя вы, возможно, и не догадываетесь об этом, операционная система Windows XP Embedded могла бы замечательно вписаться в структуру средств ИТ вашей организации. Узнайте о том, как Windows XP Embedded может снизить административные расходы, помочь сэкономить денежные средства и повысить уровень безопасности.

Don Jones Управление: Перспективное планирование при помощи System Center Capacity Planner

Недостаток оборудования ведет к увеличению времени ответа, а избыток — к повышенному расходу бюджета и административных ресурсов. Здесь вы узнаете, как использовать планировщик System Center Capacity Planner для моделирования вашей сети и точной оценки требований к инфраструктуре.

John Savill Управление: Улучшенные клиентские описи при помощи SMS

Microsoft Systems Management Server 2003, как он есть, собирает множество сведений, но не так много, как вам может понадобиться. Узнайте, как правильная комбинация сценариев, WMI и знания SMS может помочь вам расширить возможности описей SMS, чтобы собирать и отчитываться почти о любой крупинке информации.

Wes Dobry Управление: Развертывание обновлений пользовательского ПО с помощью SMS 2003 R2

Systems Management Server 2003 R2 позволяет использовать возможности управляемого обновления для развертывания пользовательских обновлений. Изучите два новых средства – средство учета пользовательских обновлений и средство публикации пользовательских обновлений – и посмотрите, как они могут помочь в развертывании как собственных обновлений, так и обновлений от сторонних разработчиков.

Steve Rachui От редактора: Мы можем ошибаться…

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

Greg Steen SQL: вопросы и ответы: Перестройка индексов, длина очереди диска и др.

Edited by Nancy Michell Обзор служебных программ: Autoruns

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

Lance Whitney Кабельщик: Параметры групповой политики беспроводной связи в Windows Vista

Узнайте, как можно использовать групповую политику для централизованной настройки и распространения параметров беспроводной сети для всех компьютеров в сети Active Directory.

Joseph Davies Windows PowerShell: Фильтрация и форматирование данных

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

Don Jones Эй, программист!: Простая работа с локальными пользователями и группами

Видимо, все давно интересовались этим. Теперь программисты (наконец-то) показывают использование сценариев для управления локальными пользователями и группами.

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

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

John Morello Файлы рабочего стола: Когда мне стукнет x64

Посмотрим на реализацию Windows XP и Windows Server 2003 в 64-разрядных системах, исследуя некоторые ожидаемые преимущества и трудности развертывания. Познакомимся с поддержкой и развертыванием 64-разрядной версии Windows Vista, а также с переходом на нее.

Wes Miller Microsoft.com изнутри: Службы федерации Active Directory

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

Jim Guthrie Заметки разъездного инженера: Радости (и горести) учения

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

Mark D. Scott Конфиденциальная информация Windows: Возможности ошибок

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

Raymond Chen


 Администрирование в Windows: Внутреннее устройство ядра Windows Vista: Часть 3
Администрирование в Windows Марк Руссинович

Внутреннее устройство ядра Windows Vista: Часть 3
Краткий обзор:
  • Надежность
  • Восстановление
  • Безопасность

До сих пор в этой серии освещались усовершенствования ядра Windows Vista, относящиеся к процессам, системе ввода и вывода, управлению памятью, запуску системы, завершению работы системы и управлению питанием. В данной третьей и последней
части будут рассмотрены компоненты и усовершенствования, относящиеся к вопросам надежности, восстановления и безопасности.
В компоненте управления учетными записями пользователей (UAC — User Account Control), который не рассматривается в этой серии, используется несколько разных технологий, включая виртуализацию файловой системы и реестра для устаревших приложений, согласие на повышение уровня для получения доступа к административным правам и механизм Windows® Integrity Level для изоляции процессов, работающих с административными правами, от процессов с низким уровнем привилегий, работающих в рамках одной и той же учетной записи. Подробное обсуждение структуры компонента UAC появится в будущем выпуске TechNet Magazine.
В операционной системе Windows Vista™ повышение надежности системы и расширение возможностей пользователя при диагностике неполадок системы и приложений достигается посредством ряда новых компонентов и усовершенствований. Например, модуль регистрации отслеживания событий ядра для Windows (ETW) всегда находится в активном состоянии, создавая в кольцевом буфере события отслеживания для операций с файлами, реестром, прерываний и операций других видов. При возникновении неполадки новая диагностическая инфраструктура Windows (WDI) делает моментальный снимок буфера и анализирует его локально или загружает в службу технической поддержки Майкрософт для поиска и устранения неполадки.
Новый монитор производительности и надежности позволяет пользователям соотносить ошибки, например, сбои и зависания, с изменениями, внесенными в настройку системы. Мощный инструмент восстановления системы (SRT) заменяет консоль восстановления для восстановления в автономном режиме систем, не подлежащих перезагрузке.
Три компонента основаны на изменениях системы, сделанных на уровне ядра, и поэтому они заслуживают более пристального рассмотрения в этой статье: диспетчер транзакций ядра (KTM), усовершенствованная обработка сбоев и поддержка предыдущих версий.

Диспетчер транзакций ядра
Одной из наиболее утомительных задач разработки программного обеспечения является обработка состояний ошибки. Это особенно верно, если в процессе выполнения операции высокого уровня приложение выполнило одну или несколько подзадач, приведших к изменениям файловой системы или реестра. Например, служба обновления прикладной программы может внести несколько изменений в реестр, заменить один из исполняемых модулей приложения, после чего ей может быть отказано в доступе при попытке обновить второй исполняемый модуль. Если в службе не предусмотрена возможность оставлять приложение в таком противоречивом состоянии, она должна отслеживать все вносимые изменения и иметь возможность их отменить. Проверка кода восстановления после ошибки является трудной задачей и, вследствие этого, часто опускается, поэтому ошибки в коде восстановления могут свести на нет все усилия.
Приложения, написанные для Windows Vista, при очень небольшой затрате усилий могут приобрести возможности автоматического восстановления после ошибок, используя для этого новую поддержку транзакций в NTFS и реестре, обеспечиваемую диспетчером транзакций ядра. Если приложению требуется выполнить ряд связанных изменений, оно может либо создать транзакцию координатора распределенных транзакций (DTC) и дескриптор транзакции KTM, либо напрямую создать дескриптор KTM и уставить связь между изменениями файлов и разделов реестра с транзакцией. В случае успешного завершения всех изменений приложение выполняет транзакцию, и изменения применяются, но в любой момент вплоть до этой точки приложение может выполнить откат транзакции, после чего изменения будут аннулированы.
Следующее преимущество состоит в том, что другие приложения не видят изменений, внесенных в транзакции, пока транзакция не будет завершена, а приложения, использующие DTC в Windows Vista и готовящийся к выпуску сервер Windows Server®, носящий кодовое название «Longhorn», могут координировать свои транзакции с помощью SQL Server™, сервера очереди сообщений Microsoft® (MSMQ) и других баз данных. Следовательно, служба обновления приложений, использующая транзакции KTM, никогда не оставит приложение в противоречивом состоянии. Именно поэтому как инструмент обновления Windows, так и инструмент восстановления системы используют транзакции.
Являясь основой поддержки транзакций, KTM обеспечивает диспетчерам транзакционных ресурсов, таких как NTFS и реестр, возможность координировать свои обновления в случае конкретного набора изменений, выполненных приложением. В Windows Vista файловая система NTFS использует для поддержки транзакций расширение TxF. Реестр использует аналогичное расширение с названием TxR. Эти диспетчеры ресурсов режима ядра работают совместно с KTM, координируя состояние транзакции, точно так же, как диспетчеры ресурсов пользовательского режима используют DTC для координации состояния транзакции в нескольких диспетчерах ресурсов пользовательского режима. Сторонние разработчики также могут использовать KTM для реализации своих собственных диспетчеров ресурсов.
Как TxF, так и TxR определяют новый набор интерфейсов файловой системы и реестров, аналогичных существующим, за исключением того, что в них включен параметр транзакции. Если приложению требуется создать файл в рамках транзакции, сначала используется KTM для создания транзакции, затем результирующая обработка транзакции передается интерфейсу API создания нового файла.
Как TxF, так и TxR основаны на быстро работающих функциях ведения журнала файловой системы, обеспечиваемых общей системой файлов журнала или системой CLFS (Common Log File System) (%SystemRoot%\System32\Clfs.sys), которая была введена в Windows Server 2003 R2. TxR и TxF используют CLFS для надежного хранения транзакционных изменений до завершения транзакции. Это позволяет им обеспечивать транзакционное восстановление и гарантии даже в случае сбоя в подаче питания. Кроме журнала CLFS расширение TxR создает набор связанных файлов журнала для отслеживания изменений в системном файле реестра в %Systemroot%\System32\Config\Txr, как показано на рис. 1, а также отдельные наборы файлов журналов для каждого пользовательского куста реестра. TxF хранит транзакционные данные для каждого тома в скрытом каталоге на томе с именем \$Extend\$RmMetadata.
Рис. 1 Файлы журналов, ведущихся расширением TxR для куста системного реестра
Рис. 1 Файлы журналов, ведущихся расширением TxR для куста системного реестра

Усовершенствованная поддержка при сбоях
В случае возникновения в Windows неустранимой ошибки режима ядра — из-за ошибок в драйвере устройства, сбоев оборудования или операционной системы — выполняется попытка предотвратить повреждение данных, хранящихся на диске, посредством остановки работы системы после отображения печально известного «синего экрана» и, если имеется соответствующая настройка, записи содержимого некоторого участка или всей физической памяти в файл аварийной копии памяти. Файлы аварийной копии памяти полезны, поскольку при перезагрузке после сбоя интерактивная служба Майкрософт для анализа сбоя (OCA — Online Crash Analysis) предлагает выполнить их анализ для поиска причины сбоя. При желании их можно проанализировать самостоятельно с помощью средств Майкрософт для отладки в Windows).
Однако в предыдущих версиях Windows поддержка файлов аварийной копии памяти оставалась не активированной до момента инициализации файлов страниц памяти процессом диспетчера сеанса (%Systemroot%\System32\Smss.exe). Это означало, что любые важные ошибки, возникавшие до этого момента, приводили к отображению синего экрана, а файл с копией памяти не создавался. Поскольку основная часть инициализации драйвера устройства происходит до запуска Smss.exe, сбои на раннем этапе никогда не сопровождаются аварийными копиями памяти, что крайне затрудняет выявление причин.
В Windows Vista период времени, в течение которого не создается файл копии памяти, сокращен благодаря инициализации поддержки файла копии памяти до загрузки драйверов этапа запуска системы, сразу после инициализации всех драйверов устройств, необходимых на этапе первоначальной загрузки. Вследствие этого изменения при возникновении сбоя на раннем этапе процесса первоначальной загрузки система может сделать аварийную копию памяти, наличие которой позволяет использовать OCA для разрешения возникшей проблемы. Кроме этого, Windows Vista сохраняет данные в файле копии памяти в виде блоков по 64 КБ, в то время как в предыдущей версии Windows файлы записывались с использованием блоков по 4 КБ. В результате этого изменения большие файлы копии памяти записываются в 10 раз быстрее.
В Windows Vista усовершенствована также обработка сбоев приложений. В предыдущих версиях Windows при возникновении сбоя приложения выполнялся обработчик необработанных исключений. Обработчик запускал процесс Майкрософт для создания сообщения об ошибках приложения (AER) (%Systemroot%\System32\Dwwin.exe), отображающий диалоговое окно с указанием программы, в которой возник сбой, и запросом об отправке сообщения об ошибке в Майкрософт. Однако, если во время сбоя повреждался стек основного потока процесса, при выполнении обработчика необработанных исключений возникал сбой, приводящий к завершению процесса ядром, мгновенному исчезновению окон программы и полному отсутствию диалогового окна с сообщением.
В Windows Vista обработка ошибок перемещена из контекста обработки сбоев в новую службу создания сообщений об ошибках Windows (WER). Эта служба реализуется посредством библиотеки DLL (%Systemroot%\System32\Wersvc.dll) в рамках процесса размещения службы. При возникновении сбоя приложения по-прежнему выполняется обработчик необработанных исключений, но обработчик отправляет сообщение службе WER, и служба запускает процесс создания сообщений об отказах WER (%Systemroot%\System32\Werfault.exe) для отображения диалогового окна с сообщением об ошибке. Если стек поврежден, и возникает сбой обработчика необработанных исключений, обработчик выполняется повторно и снова возникает сбой, то, в конце концов, исчерпывая весь стек потока (вспомогательная область памяти), и в этот момент вступает в игру ядро и отправляет службе сообщение с уведомлением о сбое.
Отличие этих двух подходов видны на рис. 2 и 3, где показана взаимосвязь процессов Accvio.exe, тестовой программы, в которой возник сбой, и процессов создания сообщений об ошибках, выделенных зеленым цветом, в операционных системах Windows XP и Windows Vista. Новая архитектура обработки ошибок в Windows Vista означает, что программы больше не будут молча заканчивать работу, не предлагая Майкрософт возможности получить сообщение об ошибке, и разработчики программного обеспечения смогут усовершенствовать свои приложения.
Рис. 2б Обработка ошибок приложений в Windows XP
Рис. 2б Обработка ошибок приложений в Windows XP
Рис. 2б
Рис. 3а Обработка ошибок приложений в Windows Vista
Рис. 3а Обработка ошибок приложений в Windows Vista
Рис. 3б

Теневое копирование тома
В Windows XP была внедрена технология теневого копирования тома для создания моментальных снимков томов дисков в конкретные моменты времени. Приложения резервного копирования используют эти моментальные снимки для создания непротиворечивых образов резервных копий, но моментальные снимки остаются все время скрытыми, за исключением периода работы процесса резервного копирования.
Эти моментальные снимки не являются, по существу, полными копиями томов. Скорее они представляют собой виды тома из некоторой предшествующей точки, содержащие оперативные данные тома, перекрытые копиями секторов тома, подвергавшихся изменениям с момента создания моментального снимка. Драйвер поставщика моментальных снимков томов (%Systemroot\%System32\Drivers\Volsnap.sys) контролирует операции, в которых участвуют тома, и, прежде чем разрешить изменение секторов, делает их резервные копии, сохраняя исходные данные в файле, связанном с моментальным снимком, в каталоге тома, содержащем системную информацию о томе.
В Windows Server 2003 администраторам предоставлялась возможность управлять моментальными снимками на сервере и пользователям — на клиентских системах посредством теневых копий общих папок. Эта функция обеспечивала постоянные моментальные снимки, доступ к которым пользователи получали с помощью вкладки «Предыдущие версии» из диалоговых окон свойств проводника для своих папок и файлов, находящихся на общих файловых ресурсах сервера.
Компонент «Предыдущие версии» операционной системы Windows Vista обеспечивает поддержку для всех клиентских систем, автоматически создавая моментальные снимки томов, как правило, один раз в день, доступ к которым можно получить из диалоговых окон свойств проводника с помощью того же интерфейса, который используется теневыми копиями общих папок. Это позволяет просматривать, восстанавливать и копировать старые версии файлов и каталогов, которые могли быть случайно изменены или удалены. Не являясь с технической точки зрения новой технологией, реализация теневого копирования томов в компоненте «Предыдущие версии» операционной системы Windows Vista оптимизирует аналогичную функцию, существовавшую в Windows Server 2003, для применения в клиентской рабочей среде.
В Windows Vista преимущества моментальных снимков томов используются также для того, чтобы объединить механизмы защиты пользовательских и системных данных и избежать сохранения избыточного объема данных резервного копирования. Если установка приложения или внесение изменений в конфигурацию приводят к неправильному или нежелательному поведению, можно воспользоваться средством восстановления системы — компонентом, введенным в линейку операционных систем Windows NT® в системе Windows XP, чтобы восстановить системные файлы до состояния, в котором они находились в момент создания точки восстановления.
В Windows XP средством восстановления системы используется драйвер фильтра системы файлов (драйвер этого типа различает изменения, сделанные на уровне файлов), чтобы резервные копии системных файлов создавались в момент их изменения. В операционной системе Windows Vista средством восстановления системы используются моментальные снимки томов. Если в операционной системе Windows Vista для возврата в точку восстановления применяется пользовательский интерфейс средства восстановления системы, то копирование предыдущих версий измененных системных файлов из моментального снимка, соответствующего данной точке восстановления, выполняется фактически на том, находящийся в рабочем режиме.

BitLocker
В настоящее время Windows Vista является наиболее защищенной версией среди операционных систем Windows. Помимо того, что в Windows Vista входит антишпионский модуль Windows Defender, в операционную систему интегрированы также многочисленные компоненты безопасности и глубокой защиты, включая средство шифрования всего тома BitLocker™, подписывание кода для кода режима ядра, защищенные процессы, рандомизация загрузки адресного пространства и усовершенствованные защита служб Windows и управление учетными записями пользователей.
Операционная система может применять свои политики безопасности, только когда она находится в активном состоянии, поэтому необходимо принять дополнительные меры для защиты данных в тех случаях, когда может быть нарушена физическая безопасность системы, и доступ к данным может быть получен, минуя операционную систему. Механизмы, основанные на использовании оборудования, например пароли BIOS и шифрование, являются технологиями, широко используемыми для предотвращения несанкционированного доступа, особенно на портативных компьютерах, вероятность потери или кражи которых наиболее высока.
В Windows 2000 была реализована шифрованная файловая система (EFS), и вариант EFS, реализованный в Windows Vista, содержит ряд усовершенствований по сравнению с предыдущими реализациями, включая повышение производительности, поддержку шифрования файла подкачки и хранение пользовательских ключей EFS на смарт-картах. Однако файловую систему EFS невозможно использовать для защиты доступа к уязвимым участкам системы, таким как файлы куста реестра. Например, если групповая политика допускает вход в систему портативного компьютера, даже если он не подключен к домену, то средства проверки учетных данных домена кэшируются в реестре, поэтому злоумышленник может воспользоваться программными инструментами для получения хэша пароля доменной учетной записи и использовать его для попытки получения пароля с помощью взломщика паролей. Пароль обеспечит злоумышленнику доступ к учетной записи и файлам EFS (в том случае, если ключ EFS не хранится на смарт-карте).
Для упрощения процедуры шифрования загрузочного тома (том, на котором находится каталог Windows), включая все его системные файлы и данные, в Windows Vista введен компонент шифрования диска Windows BitLocker, предназначенный для шифрования всего тома. В отличие от EFS, которая реализуется посредством драйвера файловой системы NTFS и работает на уровне файлов, BitLocker выполняет шифрование на уровне тома с помощью драйвера шифрования всего тома (FVE — Full Volume Encryption) (%Systemroot%\System32\Drivers\Fvevol.sys), как показано на диаграмме на рис. 4.
Рис. 4 Драйвер фильтра FVE компонента BitLocker
Рис. 4 Драйвер фильтра FVE компонента BitLocker
FVE представляет собой драйвер фильтра, поэтому он автоматически отслеживает все запросы операций ввода и вывода, которые система NTFS передает тому, шифруя блоки во время их записи и расшифровывая их во время чтения с помощью ключа шифрования всего тома (FVEK — Full Volume Encryption Key), назначенного тому во время его первоначальной настройки для использования компонента BitLocker. По умолчанию тома шифруются с использованием 128-разрядного ключа AES и 128-разрядного ключа рассеивателя. Поскольку шифрование и расшифровка выполняются на уровне системы ввода и вывода, находящейся ниже уровня системы NTFS, она воспринимает том как незашифрованный и не обязана знать о том, что компонент BitLocker активен. Однако при попытке чтения данных с тома без использования операционной системы Windows данные на томе выглядят как случайные.
Ключ FVEK шифруется с помощью главного ключа тома (VMK — Volume Master Key) и хранится на томе в области, специально отведенной для метаданных. При настройке компонента BitLocker предлагается ряд вариантов защиты ключа VMK, зависящих от возможностей оборудования системы. Если в системе имеется модуль доверенной платформы (TPM ), поддерживающий версию 1.2 спецификации TPM, и имеется соответствующая поддержка BIOS, ключ VMK может быть зашифрован либо с помощью TPM, когда система шифрует VMK с помощью ключа, хранящегося в TPM и ключа, хранящегося на флэш-устройстве USB, либо ключ может быть зашифрован с помощью ключа, хранящегося в TPM, и ПИН-кода, вводимого при загрузке системы. Для систем, в которых нет модуля TPM, BitLocker предлагает вариант шифрования ключа VMK с помощью ключа, хранящегося на внешнем флэш-устройстве USB. В любом случае необходим незашифрованный том емкостью 1,5 ГБ с системой NTFS, на котором хранятся диспетчер загрузки (Boot Manager) и база данных конфигурации загрузки (BCD).
Преимущество использования модуля TPM заключается в том, что в BitLocker используются функции TPM для гарантии того, что BitLocker не расшифрует ключ VMK и не разблокирует том, если BIOS или загрузочные файлы системы были изменены с момента активирования BitLocker. При первоначальном шифровании системного тома и при каждом обновлении любого из упомянутых компонентов BitLocker вычисляет хэши SHA-1 для этих компонентов и все хэши, называемые измерениями, сохраняет в разных регистрах конфигурации платформы (PCR) модуля TPM с помощью драйвера устройства TPM (%Systemroot%\System32\Drivers\Tpm.sys). Затем модуль TPM используется для запечатывания ключа VMK. При выполнении этой операции используется хранящийся в TPM закрытый ключ для шифрования VMK и значения, хранящиеся в регистрах PCR, наряду с другими данными, которые BitLocker передает модулю TPM. Затем BitLocker сохраняет запечатанный ключ VMK и зашифрованный ключ FVEK в области метаданных тома.
При загрузке системы она выполняет измерение своего собственного хэширования и кода загрузки PCR и записывает хэш в первый PCR модуля TPM. Затем она хэширует BIOS и сохраняет это измерение в соответствующем PCR. В свою очередь BIOS хэширует следующий компонент из последовательности начальной загрузки, основную загрузочную запись (MBR) загрузочного тома, и эта процедура продолжается до тех пор, пока не будет измерен загрузчик операционной системы. Каждый последующий фрагмент кода, который выполняется, отвечает за измерение загружаемого им кода и за сохранение измерения в соответствующем регистре модуля TPM. Наконец, когда пользователь выбирает загружаемую операционную систему, диспетчер загрузки (Bootmgr) считывает зашифрованный ключ VMK с тома и выдает модулю TPM запрос на его раскрытие. Только в том случае, когда все измерения совпадают с теми, которые были сделаны при запечатывании ключа VMK, включая дополнительный ПИН-код, TPM успешно расшифровывает ключ VMK.
Эту схему можно рассматривать как цепочку проверок, в которой каждый компонент последовательности начальной загрузки описывает следующий компонент модулю TPM. Модуль откроет свой секрет только в том случае, если все описания совпадут с теми, которые были исходно предоставлены модулю TPM. Таким образом, BitLocker защищает зашифрованные данные даже в том случае, если диск снят и перенесен в другую систему, если система загружается с использованием другой операционной системы или если на загрузочном томе скомпрометированы незашифрованные файлы.

Проверка целостности кода
Вредоносное программное обеспечение, реализованное в виде драйвера устройства режима ядра, включая программы захвата прав администратора, работает с использованием того же уровня привилегий, что и ядро, и поэтому его выявление и удаление является наиболее сложной задачей. Такие программы могут изменять поведение ядра и других драйверов таким образом, что становятся практически неуловимыми. Компонент Windows Vista, обеспечивающий целостность кода режима ядра, известный также под названием подписывания кода режима ядра (KMCS), допускает загрузку драйверов устройств только в том случае, если они опубликованы и снабжены цифровой подписью разработчиков, проверенных одним из нескольких центров сертификации (CA). По умолчанию компонент KMCS обязательно присутствует в 64-разрядных версиях Windows Vista.
Поскольку центры сертификации берут плату за свои услуги и выполняют основные проверки происхождения кода, такие как проверка подлинности предприятия, довольно сложно создать анонимное вредоносное программное обеспечение, работающее в режиме ядра в 64-разрядной версии Windows Vista. Более того, вредоносная программа, которой удается пройти процедуру проверки, может, в принципе, оставить следы, ведущие к ее автору, в случае ее обнаружения в поврежденной системе. У компонента KMCS есть дополнительные применения, такие как предоставление информации группе Майкрософт, занимающейся интерактивным анализом сбоя, в случае возникновения подозрения о том, что драйвер содержит ошибку, вызывающую сбои пользовательских систем и разблокирование мультимедийного содержимого высокой четкости. Эти применения будут кратко описаны.
В компоненте KMCS используются технологии шифрования с открытым ключом, применявшиеся более десяти лет в операционной системе Windows и требующие, чтобы в коде режима ядра содержалась цифровая подпись, созданная одним из доверенных центров сертификации. Если издатель передает драйвер в лабораторию Майкрософт, проверяющую качество оборудования Windows (WHQL), и драйвер проходит проверку надежности, тогда Майкрософт выступает в качестве центра сертификации, подписывающего код. Большинство издателей получают подписи с помощью WHQL, но если в драйвере нет тестовой программы WHQL, издатель не хочет проходить проверку WHQL или драйвер является драйвером этапа первоначальной загрузки, загружающимся на начальном этапе запуска системы, издатели могут подписывать код самостоятельно. Для этого им требуется сначала получить сертификат подписывания кода от одного из центров сертификации, которые Майкрософт признает доверенными для подписания кода режима ядра. После этого автор выполняет цифровое хэширование кода, подписывает хэш, шифруя его с помощью закрытого ключа, и предоставляет сертификат и зашифрованный хэш вместе с кодом.
Когда драйвер пытается загрузиться, Windows расшифровывает хэш, предоставленный вместе с кодом, с помощью открытого ключа, хранящегося в сертификате, затем проверяет хэш на совпадение с хэшем, входящим в код. Подлинность сертификата проверяется этим же способом, но с использованием открытого ключа, предоставляемого вместе с Windows.
Windows выполняет также проверку соответствующих цепочек сертификатов вплоть до одной из служб выдачи корневых сертификатов, встроенных в загрузчик Windows и ядро операционной системы. Попытки загрузить неподписанный 64-разрядный драйвер невозможны в рабочей системе, поскольку в отличие от диспетчера Plug and Play, отображающего диалоговое окно с предупреждением, когда ему передается команда загрузить драйвер, не имеющий подписи, подтверждающей, что драйвер проходил проверку WQHL, 64-разрядная версия Windows Vista, каждый раз, когда она блокирует загрузку неподписанного драйвера, безмолвно записывает событие в журнал событий приложения проверки целостности кода, аналогичное показанному на рис. 5. 32-разрядная версия Windows Vista также проверяет подписи драйверов, но допускает загрузку неподписанных драйверов. Их блокирование привело бы к нарушению модернизированных систем Windows XP, которым требуются драйверы, которые были загружены в Windows XP, а также допускает поддержку оборудования, для которого существуют только драйверы Windows XP. Однако при выполнении загрузки неподписанного драйвера 32-разрядная версия Windows Vista также записывает события в журнал событий целостности кода.
Рис. 5 События попытки загрузки неподписанного драйвера
Рис. 5 События попытки загрузки неподписанного драйвера
Поскольку подписывание кода обычно используется для пометки кода в качестве версии, прошедшей тщательную официальную проверку, издатели, как правило, не стремятся подписывать тестовый код. Поэтому в Windows Vista включен режим тестового подписывания, который можно включать и отключать с помощью инструмента Bcdedit (описан в моей статье в мартовском выпуске TechNet Magazine за 2007 г.) и в рамках которого выполняется загрузка драйверов режима ядра, имеющих цифровую подпись, сделанную тестовым сертификатом, созданным собственным центром сертификации компании. Этот режим предназначен для использования программистами во время разработки кода. Когда операционная система Windows находится в этом режиме, на рабочем столе отображаются маркеры, подобные показанным на рис. 6.
Рис. 6 Режим тестового подписывания в операционной системе Windows Vista
Рис. 6 Режим тестового подписывания в операционной системе Windows Vista

Защищенные процессы
Мультимедийное содержимое следующего поколения, такое как HD-DVD, BluRay и другие форматы, имеющие лицензию AACS (Advanced Access Content System), получат широкое распространение в течение ближайших нескольких лет. В Windows Vista используется ряд технологий под общим названием Protected Media Path (PMP), которые требуются стандартом AACS для воспроизведения такого содержимого. К технологиям PMP относятся PUMA (Protected User-Mode Audio) и PVP (Protected Video Path), совместное использование которых обеспечивает для аудио и видео драйверов, а также для приложений медиа-проигрывателей, механизмы, предотвращающие запись содержимого в формате высокой четкости несанкционированными программами или аппаратурой.
PUMA и PVP определяют интерфейсы и специальную поддержку для аудио и видео проигрывателей, драйверов устройств и оборудования, но PMP, кроме этого, основывается на общем механизме ядра, реализованном в Windows Vista, называемом защищенным процессом. В основе защищенных процессов лежит стандартная конструкция Windows, инкапсулирующая выполняющийся исполняемый образ, его библиотеки DLL, контекст безопасности (учетная запись, в рамках которой работает процесс, и ее привилегии безопасности) и потоки, выполняющие код в рамках процесса, но запрещающие определенные типы доступа.
Стандартные процессы реализуют модель управления доступом, обеспечивающую полный доступ владельцу процесса и учетным записям администраторов с привилегиями программ отладки. Полный доступ позволяет пользователю просматривать и изменять адресное пространство процесса, включая код и данные, внесенные в процесс. Пользователям разрешается также передавать в процесс потоки. Эти типы доступа противоречат требованиям PMP, поскольку они допускают получение несанкционированным кодом доступа к содержимому высокой четкости и ключам управления правами (DRM), хранящимся в процессе, воспроизводящем содержимое.
Защищенные процессы разрешают доступ к ограниченному набору интерфейсов управления информацией и процессами, включая запрос имени образа процесса и запрос завершения или приостановки процесса. Но ядро предоставляет диагностическую информацию о защищенных процессах посредством общих функций запросов о процессах, которые возвращают данные, относящиеся ко всем процессам в системе, и поэтому не требуют непосредственного доступа к процессу. Получение доступа, который может привести к компрометации носителя, разрешено только другим защищенным процессам.
Более того, для предотвращения повреждений извне весь исполняемый код, загруженный в защищенный процесс, включая его исполняемый образ и библиотеки DLL, должен быть подписан либо корпорацией Майкрософт (WHQL) с использованием флага защищенной среды (PE), либо, если это аудиокодек, он должен быть подписан разработчиком с использованием сертификата подписывания DRM, полученным от Майкрософт. Поскольку код режима ядра может получить полный доступ к любому процессу, включая защищенные, а 32-разрядная версия Windows допускает загрузку неподписанного кода режима ядра, ядро предоставляет интерфейс API для защищенных процессов. Этот интерфейс предназначен для выдачи запроса о «чистоте» среды режима ядра и использования результата для разблокирования высококачественного содержимого только в том случае, если среди загружаемого кода нет неподписанного.
Идентификация защищенных процессов
Не существует интерфейсов API, предназначенных специально для идентификации защищенных процессов, но имеется возможность выполнить косвенную идентификацию, основываясь на имеющейся ограниченной информации об этих процессах и невозможности выполнять их отладку даже при использовании учетной записи с административными правами. Процесс изоляции графа аудиоустройств (%Systemroot%\System32\Audiodg.exe) используется для воспроизведения дисков DVD, закодированных с помощью CSS, и в окне диспетчера задач его можно идентифицировать как защищенный процесс, поскольку диспетчер задач не в состоянии получить его командную строку, виртуализацию и состояние предотвращения выполнения данных, даже если он запускается с правами администратора.
Просмотр защищенного процесса audiodg с помощью диспетчера задач
Просмотр защищенного процесса audiodg с помощью диспетчера задач

Рандомизация загрузки адресного пространства
Несмотря на такие меры, как предотвращение выполнения данных и усовершенствованная проверка ошибок компилятора, создатели вредоносного программного обеспечения продолжают находить уязвимости переполнения буфера, позволяющие им заражать процессы, ориентированные на работу в сети, такие как обозреватель Internet Explorer®, службы Windows и приложения сторонних разработчиков, с целью получения опорного пункта в системе. После удачного заражения процесса, однако, им необходимо использовать интерфейсы API Windows для выполнения своей конечной цели — чтения данных пользователя или обеспечения своего постоянного присутствия посредством изменения параметров пользовательской или системной настройки.
Подключение приложения к точкам входа интерфейса API, экспортированным посредством библиотек DLL, обычно обрабатывается загрузчиком операционной системы, но при таких типах инфицирования вредоносному программному обеспечению не удается получить преимущества служб загрузчика. Это не мешало вредоносным программам в предыдущих версиях Windows, потому что для любого конкретного выпуска операционной системы Windows системные исполнимые образы и библиотеки DLL всегда загружаются в одном и том же месте, что позволяет вредоносным программам исходить из предположения, что интерфейсы API имеют фиксированные адреса размещения.
Компонент рандомизации загрузки адресного пространства (ASLR) в операционной системе Windows Vista лишает вредоносные программы возможности выяснить местоположение интерфейсов API. Это достигается за счет того, что при каждой загрузке системы системные библиотеки DLL и исполняемые модули загружаются в новом месте. На раннем этапе процедуры первоначальной загрузки диспетчер памяти выбирает случайное смещение для загрузки образа DLL из одного из 256 адресов (выровненных на 64 кБ), имеющихся в области размером 16 МБ в верхней части адресного пространства пользовательского режима. Когда библиотеки DLL, в заголовке образа которых присутствует новый флаг динамического размещения, загружаются в процесс, диспетчер памяти размещает их в памяти начиная с адреса смещения загрузки образа и продолжает по направлению к меньшим адресам.
Исполняемые образы, в которых установлен данный флаг, проходят аналогичную процедуру загрузки в случайную точку, выровненную на 64 КБ, в области размером 16 МБ от базового адреса загрузки, хранящегося в заголовке их образа. Кроме того, если данная библиотека DLL или исполняемый образ снова загружается после того, как был выгружен всеми использовавшими его процессами, диспетчер памяти снова выбирает для загрузки случайное местоположение. На рис. 7 показан пример компоновки адресного пространства для 32-разрядной системы Windows Vista, включая области, из которых ASLR выбирает смещение для загрузки образа и адрес загрузки исполняемого образа.
Рис. 7 Влияние механизма ASLR на адреса загрузки исполняемых образов и библиотек DLL
Рис. 7 Влияние механизма ASLR на адреса загрузки исполняемых образов и библиотек DLL
Только образы, имеющие флаг динамического размещения, к которым относятся все библиотеки DLL операционной системы Windows Vista и исполняемые образы, можно размещать в новых местах, потому что перемещение устаревших образов может привести к нарушению внутренних допущений о месте загрузки образов, сделанных разработчиками. В пакете обновления Visual Studio® 2005 SP1 добавлена поддержка для установки этого флага, чтобы сторонние разработчики могли воспользоваться преимуществами механизма ASLR в полной мере.
Назначение адресов загрузки библиотек DLL, выбираемых случайным образом из 256 местоположений, не лишает вредоносные программы возможности угадывать правильное местоположение интерфейса API, но оно резко снижает скорость распространения сетевого червя и препятствует надежной работе вредоносной программы, получающей только один шанс в инфицированной системе. Кроме того, у стратегии ASLR по изменению местоположения есть дополнительное преимущество, заключающееся в том, что адресные пространства используются более эффективно, чем в предыдущих версиях Windows — создаются обширные участки свободной памяти для распределения памяти смежными областями, уменьшается число таблиц страниц, выделяемых диспетчером памяти для отслеживания компоновки адресного пространства, и минимизируются несовпадения в буфере TLB.

Повышение безопасности служб
Службы Windows являются идеальными целями для атак со стороны вредоносного программного обеспечения. Многие из них для расширения функциональных возможностей предлагают доступ в сеть, тем самым увеличивая уязвимость при удаленном доступе к системе. Большая часть служб выполняется с более высоким уровнем привилегий, чем у стандартных учетных записей пользователей, что дает шанс повысить уровень привилегий в локальной системе, если они будут затронуты вредоносным программным обеспечением. По этой причине в Windows расширялись изменения, сделанные в пакете обновления Windows XP SP2 и направленные на снижение назначаемого службам уровня привилегий и доступа до уровня, необходимого для выполнения их ролей. Например, в пакете обновления 2 для Windows XP введены учетные записи локальной службы и сетевой службы, содержащие только подмножество тех привилегий, которые были доступны учетной записи локальной системы, в рамках которой эти службы выполнялись ранее. Это сводит к минимуму права доступа, получаемые злоумышленником, использующим службу.
ASLR в действии
Влияние, оказываемое ASLR, легко оценить путем сравнения адресов загрузки библиотеки DLL для процесса в двух разных сеансах загрузки с помощью такого средства, как Process Explorer от Sysinternals (обозреватель процессов). На этих двух снимках экрана, сделанных в двух разных сеансах, сначала библиотека Ntdll.dll загружалась в проводник по адресу 0x77A30000, а затем по адресу 0x77750000.
Отличающиеся базовые адреса для библиотеки ntdll.dll
Отличающиеся базовые адреса для библиотеки ntdll.dll
Отличающиеся базовые адреса для библиотеки ntdll.dll
Отличающиеся базовые адреса для библиотеки ntdll.dll

В моей предыдущей статье было описано, как службы выполняются в их собственных сеансах изолированно от учетных записей пользователей, но в Windows Vista расширено также применение принципа наименьшего уровня привилегий путем дальнейшего уменьшения уровня привилегий и доступа к файлам, разделам реестра и портам брандмауэра, назначаемого большинству служб. В Windows Vista определена новая учетная запись группы, названная идентификатором безопасности службы (SID), уникальная для каждой службы. Служба может устанавливать разрешения на своих ресурсах, чтобы доступ к ним имелся только для идентификатора SID их службы, предотвращая, в случае компрометации службы, получение доступа другими службами, работающими в рамках этой же учетной записи. Идентификатор SID службы можно просмотреть, воспользовавшись командой sc showsid с указанием имени службы, как показано на рис. 8.
Рис. 8 Просмотр идентификатора SID службы
Рис. 8 Просмотр идентификатора SID службы
Идентификаторы SID служб защищают доступ к ресурсам, принадлежащим конкретной службе, но по умолчанию у служб имеется еще доступ ко всем объектам, к которым имеет доступ учетная запись пользователя, в рамках которой они работают. Например, служба, работающая в рамках учетной записи локальной службы, может не иметь доступа к ресурсам, созданным другой службой, работающей в качестве локальной службы в другом процессе, защищающем свои объекты с помощью разрешений, ссылающихся на идентификатор SID службы. Однако она по-прежнему может читать и записывать любые объекты, для доступа к которым имеет разрешения локальная служба (и любые группы, к которым принадлежит локальная служба, такие как группа «Служба»).
Поэтому в Windows Vista введен новый ограниченный тип службы, названный службой с ограничениями на запись, который разрешает службе доступ для записи только к объектам, доступным ее идентификатору SID, группе «Все» и идентификатору SID, назначенному сеансу работы. Для реализации этого подхода в системе используются ограниченные идентификаторы SID — тип SID, введенный ранее в Windows 2000. Если процесс, открывающий объект, является службой с ограничениями на запись, алгоритм проверки доступа изменяется таким образом, чтобы SID, который не был назначен процессу ни в ограниченной форме, ни в форме без ограничений, не мог использоваться для предоставления процессу доступа к объекту для записи. Следующая команда дает возможность выяснить, есть ли у службы ограничения:
sc qsidtype [service]
Еще одно изменение помогает службе предотвратить получение доступа к создаваемым ею объектам другими службами, выполняющимися в рамках этой же учетной записи. В предыдущих версиях Windows создатель объекта являлся также его владельцем, а у владельцев имеется возможность читать и изменять разрешения своих объектов, предоставляя им полный доступ к своим собственным объектам. В Windows Vista введен новый идентификатор SID прав владельца, который, если он представлен в разрешениях объекта, может ограничивать доступ владельца к его собственному объекту, вплоть до отмены права устанавливать и запрашивать разрешения.
Следующее усовершенствование модели безопасности служб в операционной системе Windows Vista позволяет разработчику службы при регистрации службы в системе точно указать, какие привилегии безопасности необходимы службе для работы. Например, если службе необходимо создавать события аудита, в список включается привилегия «Аудит».
Когда диспетчер управления службами запускает процесс, работающий с одной или несколькими службами Windows, он создает маркер безопасности (объект ядра, формирующий список, в который входят учетная запись пользователя процесса, членство в группах и привилегии безопасности) для процесса, содержащего только привилегии, необходимые службам данного процесса. Если служба указывает привилегию, которая недоступна учетной записи, в рамках которой она работает, то служба не сможет запуститься. Если, например, ни одной из служб, работающих в рамках процесса с учетной записью локальной службы, не требуется привилегия программ отладки, диспетчер управления службами снимает эту привилегию с маркера безопасности процесса. Соответственно, если процесс службы скомпрометирован, вредоносный код не может воспользоваться преимуществами привилегий, которые не были явным образом запрошены службами, работающими в рамках процесса. Команда sc qprivs служит для формирования отчета о привилегиях, запрошенных службой.

Заключение
На этом завершается состоящий из трех частей обзор изменений, внесенных в ядро операционной системы Windows Vista. Некоторые компоненты и усовершенствования не были рассмотрены или упомянуты, например, новый рабочий пул потоков для разработчиков приложений, новые механизмы синхронизации, такие как общие блокировки средств чтения и записи, разметка потоков служб, поддержка интерактивной проверки диска NTFS и изменение объема том, а также новый механизм IPC ядра, названный ALPC. Для получения дополнительных сведений об этих и других компонентах см. следующее издание Windows Internals (Внутренняя структура Windows), публикация которого запланирована до конца 2007 г.
Просмотр службы с ограничениями на запись
Только один процесс размещения служб в Windows Vista размещает службы с ограничениями. Его можно идентифицировать с помощью инструмента для просмотра процессов, такого как обозреватель процессов, имеющего интерфейс командной строки:
svchost -k LocalServiceNoNetwork
К службам, настроенным для работы в рамках этого процесса, относятся служба базовой фильтрации, служба политики диагностики, брандмауэр Windows, журналы и оповещения производительности и Windows Media® Center Service Starter.
На этом экране показан текстовый формат идентификатора SID службы базовой фильтрации, NT SERVICE\BFE, представленный один раз с флагом Restricted, и еще раз без него, поэтому у процесса есть доступ к ресурсам, доступ к которым имеется в рамках этой учетной записи. Однако у него не обязательно имеется доступ к другим объектам, доступным, как правило, для учетной записи локальной службы. Например, поскольку учетная запись NT AUTHORITY\SERVICE не представлена в маркере процесса с флагом ограничений, процесс не может изменять объекты, предоставляющие доступ для записи только этой учетной записи, но не другим учетным записям в маркере, имеющим флаг ограничений.
Службы, выполняющиеся в этом процессе, также ограничивают свои привилегии, поскольку привилегии, перечисленные в нижней части диалогового окна свойств, являются подмножеством тех, которые доступны учетной записи локальной службы.
Флаги SID для службы
Флаги SID для службы

Марк Руссинович занимает должность технического специалиста в подразделении Platform and Services корпорации Майкрософт. Он является одним из авторов книги Microsoft Windows Internals (Внутренняя структура ОС Microsoft Windows), вышедшей в издательстве Microsoft Press в 2004 г., и часто выступает на таких конференциях, как Microsoft Tech•Ed и PDC, предназначенных для специалистов по информационным технологиям и разработчиков. Марк Руссинович пришел в корпорацию Майкрософт в результате приобретения корпорацией компании Winternals Software, одним из основателей которой он являлся. Он также создал веб-ресурс Sysinternals, на котором опубликовал многие популярные служебные программы, такие как Process Explorer, Filemon и Regmon.
© 2007 Корпорация Майкрософт и компания CMP Media, LLC. Все права защищены; полное или частичное воспроизведение без разрешения запрещено.


 Администрирование в Windows: Аварийное восстановление пользователей и групп службы каталогов Active Directory
Администрирование в Windows Джил Киркпатрик (Gil Kirkpatrick)

Аварийное восстановление пользователей и групп службы каталогов Active Directory
Краткий обзор:
  • Механизм репликации и связи объектов
  • Использование NTDSUTIL для резервного копирования и восстановления
  • Полномочное и неполномочное восстановление

Active Directory — одна из самых критичных служб в сети Windows. Чтобы свести к минимуму время простоя и снижение производительности, очень важно иметь эффективные планы аварийного восстановления при неполадках в Active Directory. Это может показаться очевидным, но
просто поразительно, сколько администраторов не имеют плана восстановления при возникновении одной из наиболее вероятных проблем с Active Directory®: случайного удаления данных.
Случайное удаление объектов — одна из наиболее распространенных причин сбоя службы. Когда я провожу семинары или конференции, я часто спрашиваю, сталкивался ли кто-нибудь с неполадками в Active Directory из-за случайного удаления данных. И каждый раз почти все поднимают руку.
Чтобы понять, почему так сложно проходит восстановление данных, сначала следует понять следующее: как Active Directory хранит и реплицирует объекты, и в чем заключается механизм полномочного и неполномочного восстановления.

Хранение объектов
Active Directory — специальная база данных объектов, реализующая модель данных X.500/LDAP. Хранилище данных (называемое информационным деревом каталога — DIT) основано на механизме расширяемого хранилища (ESE), механизме базы данных на основе индексно-последовательного доступа (ISAM). Концептуально Active Directory хранит DIT в двух таблицах: таблице данных (которая содержит реальные объекты и атрибуты Active Directory) и таблице связей (которая хранит данные о связях между объектами).
Каждый объект Active Directory хранится в отдельной строке таблицы данных, один атрибут в столбце. Таблица данных содержит все элементы всех реплик, хранящихся на контроллере домена (DC). На обычном контроллере домена таблица данных содержит элементы из контекстов именования (NC) домена, конфигурации и схемы. В глобальном каталоге таблица данных содержит элементы для каждого объекта в лесу.
Для уникальной идентификации каждой строки таблицы данных Active Directory использует идентификатор различающегося имени (distinguished name tag, DNT) — 32-разрядное целое число. DNT, использующийся для внутреннего указания на объекты, меньше других идентификаторов, таких, как различающееся имя (DN) и идентификатор objectGUID (16-байтовая двоичная структура). Но, в отличие от идентификатора objectGUID, DNT является локальным идентификатором и отличается на разных контроллерах домена.

Как Active Directory связывает объекты
Active Directory управляет двумя видами отношений между объектами в информационном дереве каталога: отношения родитель-потомок (также называемые взаимоотношениями контейнера) и отношения ссылки (также называемые отношениями связи). Для реализации отношений родитель-потомок Active Directory содержит в таблице данных дополнительный столбец для идентификатора различающегося родительского имени (). Этот столбец всегда содержит DNT родителя объекта.
Каждый атрибут в Active Directory определяется объектом attributeSchema в контейнере схемы Active Directory. Некоторые атрибуты в Active Directory определяются как атрибуты ссылки и задаются четным ненулевым числом в атрибуте linkID объекта attributeSchema. Атрибуты ссылки устанавливают отношения между объектами в каталоге и могут иметь одно или несколько значений. Атрибут членства объекта группы — пример атрибута ссылки с несколькими значениями, устанавливающий связь между объектом-группой и объектом-участником.
Хотя кажется, что атрибут членства группы содержит различающиеся имена участников (как, например, показано в оснастке «Пользователи и компьютеры Active Directory»), на самом деле Active Directory хранит их другим способом. При добавлении различающегося имени объекта участника к атрибуту членства группы Active Directory сохраняет идентификатор различающегося имени объекта, а не само различающееся имя. Поскольку идентификатор различающегося имени не меняется даже при переименовании объекта, можно переименовать объект пользователя, и Active Directory не нужно будет выполнять сортировку по всем группам системы, чтобы обновить различающееся имя в каждом атрибуте участника. Так Active Directory поддерживает ссылочную целостность в информационном дереве каталога. На рис. 1 показано сильно упрощенное представление взаимоотношений таблицы данных и таблицы связей. На этих таблицах показано, что три объекта пользователей — Molly Clark, Alexander Tumanov и Makoto Yamagishi — являются членами группы старших инженеров.
Figure 1 Взаимоотношение таблицы данных и таблицы связей (Close Figure 1)

Таблица данных |  |  |
DNT | PDNT | Класс объекта | Cn
14529 | 14401 | Подразделение | Инженеры
14530 | 14529 | Группа | Главные инженеры
14531 | 14529 | Пользователь | Molly Clark
14532 | 14529 | Пользователь | Alexander Tumanov
14533 | 14529 | Пользователь | Makoto Yamagishi
Таблица связей |  |  |
Атрибут | DNT | Ссылка вперед (на следующий элемент) |
Член | 14530 | 14531 |
Член | 14530 | 14532 |
Член | 14530 | 14533 |
Эти ссылки называют ссылками на следующий элемент (ссылка вперед). Тем же образом Active Directory поддерживает атрибуты ссылки на предыдущий элемент (ссылка назад). Так обеспечивается связь между связанным объектом и объектом, который на него ссылается, то есть связан со следующим элементом. Атрибут memberOf для пользователей и групп — пример атрибута связи с предыдущим объектом. Объект attributeSchema, который описывает атрибут ссылки на предыдущий объект, имеет значение linkID на единицу большее, чем целочисленное значение linkID соответствующего атрибута ссылки на следующий элемент. Например, атрибут членства схемы Windows Server® 2003 R2 имеет значение linkID, равное 2; атрибут memberOf, который служит ссылкой на предыдущий элемент, имеет значение linkID, равное 3. В качестве дополнительных сведений на Рис. 2 показан список стандартных атрибутов ссылки схемы Windows Server 2003 R2.
Figure 2 Атрибуты ссылки в схеме Windows Server 2003 R2 (Close Figure 2)

Ссылка вперед (на следующий элемент) | linkID | Атрибут ссылки назад (на предыдущий элемент) | Связаны
член | 2 | memberOf | 3
менеджер | 42 | directReports | 43
владелец | 44 | ownerBL | 45
siteObject | 46 | siteObjectBL | 47
nonSecurityMember | 50 | nonSecurityMemberBL | 51
queryPolicyObject | 68 | queryPolicyBL | 69
privilegeHolder | 70 | isPrivilegeHolder | 71
managedBy | 72 | managedObjects | 73
hasPartialReplicaNCs | 74 |  |
hasMasterNCs | 76 | masteredBy | 77
syncMembership | 78 |  |
serverReference | 94 | serverReferenceBL | 95
bridgeheadTransportList | 98 | bridgeheadServerListBL | 99
netbootServer | 100 | netbootSCPBL | 101
frsComputerReference | 102 | frsComputerReferenceBL | 103
fRSMemberReference | 104 | fRSMemberReferenceBL | 105
fRSPrimaryMember | 106 |  |
siteLinkList | 142 |  |
siteList | 144 |  |
msCOM-PartitionLink | 1040 | msCOM-PartitionSetLink | 1041
msDS-NC-Replica-Locations | 1044 |  |
msFRS-Hub-Member | 1046 |  |
msCOM-UserPartitionSetLink | 1048 | msCOM-UserLink | 1049
msDS-SDReferenceDomain | 2000 |  |
msDS-HasInstantiatedNCs | 2002 |  |
msDS-NonMembers | 2014 | msDS-NonMembersBL | 2015
msDS-MembersForAzRole | 2016 | msDS-MembersForAzRoleBL | 2017
msDS-OperationsForAzTask | 2018 | msDS-OperationsForAzTaskBL | 2019
msDS-TasksForAzTask | 2020 | msDS-TasksForAzTaskBL | 2021
msDS-OperationsForAzRole | 2022 | msDS-OperationsForAzRoleBL | 2023
msDS-TasksForAzRole | 2024 | msDS-TasksForAzRoleBL | 2025
msDS-HasDomainNCs | 2026 |  |
msSFU30PosixMember | 2030 | msSFU30PosixMemberOf | 2031
msDS-hasMasterNCs | 2036 | msDs-masteredBy | 2037
msDS-ObjectReference | 2038 | msDS-ObjectReferenceBL | 2039
msDFSR-ComputerReference | 2050 | msDFSR-ComputerReferenceBL | 2051
msDFSR-MemberReference | 2052 | msDFSR-MemberReferenceBL | 2053
Атрибуты ссылки на предыдущий элемент всегда имеют несколько значений и обрабатываются Active Directory автоматически. На самом деле нельзя напрямую изменять атрибут ссылки на предыдущий элемент. Хотя кажется, что можно изменить атрибут memberOf пользователя или группы с помощью оснастки MMC «Active Directory – пользователи и компьютеры», на самом деле оснастка меняет атрибут членства соответствующей группы, и Active Directory «за кулисами» обновляет атрибут memberOf. Поэтому не требуются полномочия для объекта пользователя, чтобы добавить пользователя в группу; вы только меняете атрибут членства объекта группы. Поскольку каждый контроллер домена локально управляет атрибутами ссылки на предыдущий элемент, изменения ссылок назад никогда не реплицируются. Реплицируются только изменения атрибута ссылки на следующий элемент, такие, как атрибуты членства в группе.
На обычном контроллере домена таблица данных содержит элементы объектов домена, а также объекты контейнеров из конфигурации и схемы. Но некоторые типы групп могут содержать ссылки на объекты, расположенные в другом домене. Как Active Directory хранит идентификатор различающегося имени для объекта, отсутствующего в таблице данных? Ответ касается владельца роли хозяина инфраструктуры FSMO (Flexible Single Master Operations) и сущности, называемой фантомным объектом.

Фантомные объекты
При добавлении участника одного домена в группу, расположенную в другом домене, Active Directory автоматически создает специальный объект в таблице данных, называемый фантомом, и содержащий objectGUID, objectSid и различающееся имя нового участника. Таким образом создается идентификатор различающегося имени, который может храниться в атрибуте членства в группе. Если контроллер домена — глобальный каталог, нет необходимости создавать фантом, поскольку каталог уже содержит элемент в таблице данных для каждого объекта леса.
Контроллер домена, который поддерживает роль инфраструктуры FSMO, периодически проверяет элементы в своей таблице данных по отношению к глобальному каталогу, и если выясняется, что объект перемещен, переименован или удален, обновляет фантомные объекты в таблице данных, а также реплицирует изменения на другие контроллеры домена. А благодаря преимуществу счетчика ссылок хозяин инфраструктуры также может удалять фантомы, на которые больше не ссылаются никакие атрибуты ссылки на следующий элемент домена.
Фантомы позволяют контроллерам домена управлять ссылками на объект, расположенный в другом домене леса, но атрибуты ссылки вперед также могут указывать на объект, расположенный вне леса, например, в доверенном домене. В этом случае Active Directory создает объект, называемый участником внешней безопасности (FSP) в контейнере CN=ForeignSecurityPrincipals в NC домена. FSP содержит идентификатор безопасности (SID) внешнего объекта и атрибуты, идентифицирующие объект во внешнем домене, но не существует процесса, поддерживающего актуальность данных FSP. При восстановлении данных мы рассматриваем FSP как любой другой объект Active Directory.

Удаление объектов
Здесь я прежде всего сосредоточусь на восстановлении пользователей и их членства в группах. В то же время аналогичный подход применим к восстановлению других связанных атрибутов.
Когда Active Directory удаляет объект, он не удаляется из информационного дерева каталога физически. Вместо этого он помечает объект как удаленный путем установки значения «истина» для атрибута isDeleted, что делает объект невидимым для обычных операций в каталоге. Active Directory удаляет все атрибуты, не предназначенные для сохранения, как определяется схемой и меняет относительное различающееся имя (RDN) объекта на <old RDN>\0aDEL:<objectGUID>. Затем перемещает объект в контейнер CN=Deleted Objects для контекста именования. (Существуют некоторые классы объектов в контексте именования Конфигурация, которые Active Directory не может переместить в контейнер Deleted Objects.) Active Directory удаляет любые ссылки вперед на другие объекты, содержащие удаленные объекты, что снижает значение счетчика ссылок в таблице связей. Если существуют другие объекты, содержащие ссылки вперед на новые удаленные объекты, Active Directory также удаляет эти ссылки.
Получившийся объект носит название захоронения. Active Directory реплицирует это захоронение на другие контроллеры домена, где происходят аналогичные изменения. Учтите, что Active Directory не реплицирует изменения, произошедшие со ссылками вперед на удаленный объект. Каждый контроллер домена выполняет подобное действие локально, поэтому нет необходимости его реплицировать. Это имеет последствия для восстановления членства в группе, как будет рассмотрено в этой статье далее.
Active Directory обрабатывает объекты в информационном дереве каталога как определено атрибутом объекта tombstoneLifetime CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=<корневой домен>. Процессы «сборки мусора» на каждом DC удаляют объекты-захоронения, которые старше, чем настроенное для них время жизни. По умолчанию время жизни объектов-захоронений составляет 60 дней для Windows® 2000, Windows Server 2003, и Windows Server 2003 R2. Оно равно 180 дням для Windows Server 2003 SP1.
Время жизни захоронений играет большую роль в процессе восстановления. Невозможно восстановить из более ранней резервной копии, чем время жизни объекта-захоронения. Поскольку объекты, удаленные и затем убранные из домена при сборке мусора, больше не обладают захоронениями, операции удаления никогда не будут заново реплицированы на восстановленном контроллере домена. Удаленные объекты затем будут оставаться на восстановленном контроллере домена как устаревшие объекты, и восстановленный контроллер никогда правильно не интегрируется с другими контроллерами домена.

Репликация объектов
Когда контроллер домена выполняет любую операцию обновления, например, при добавлении объекта или изменения атрибута, контроллер присваивает операции уникальный 64-разрядный номер, называемый номером последовательного обновления (USN). Active Directory помечает с помощью USN обновляемые объекты и атрибуты, чтобы определить, следует ли их реплицировать.
Active Directory реплицирует объекты по принципу «атрибут за атрибутом». Поэтому при изменении атрибута объекта Active Directory будет реплицировать атрибут, а не объект целиком. Для этого Active Directory отслеживает изменения каждого атрибута при помощи метаданных репликации. Метаданные репликации атрибута включают:
  • Локальный USN, который идентифицирует операцию изменения на локальном DC.
  • InvocationID контроллера домена, на котором возникли изменения (особенно атрибут invocationID контроллера, соответствующего объекту nTDSSettings), который показывает отдельное появление информационного дерева каталога на контроллере домена.
  • USN исходной операции, если она существует на исходном контроллере домена.
  • Отметка времени, которая отражает системное время DC при выполнении изменения.
  • 32-разрядный номер версии, последовательно возрастающий при каждом изменении.
Когда контроллер домена назначения запрашивает изменения у исходного контроллера, он отправляет USN последнего успешно реплицированного изменения исходному контроллеру вместе с вектором синхронизации, который включает исходный USN, контроллер домена назначения, видимый каждому контроллеру домена, имеющему реплику реплицируемого контекста именования. Исходный контроллер домена использует эти данные, чтобы отправлять только те обновления, которые еще не видел контроллер домена назначения.
По мере обработки контроллером домена назначения входящих изменений атрибутов он проверяет номер версии каждого атрибута. Если номер версии поступающего атрибута больше номера, который хранится в контроллере, будет сохранено поступившее значение. Если номер версии поступающего атрибута равен существующему номеру, контроллер сравнивает отметку времени и использует атрибут с последней отметкой. Если отметки временисовпадают, контроллер домена назначения выбирает значение с наибольшим invocationID. Так обеспечивается синхронизация для каждого контроллера домена значение каждого реплицируемого атрибута.

Репликация связанных значений
В Windows 2000 Active Directory реплицирует атрибуты с множественными значениями так же, как и атрибуты с одним значением. Это вызывает проблемы для больших динамических групп объектов, имеющих атрибуты членства с несколькими значениями, которые могут часто меняться на разных контроллерах доменов. Если администратор добавил пользователя в группу на одном контроллере домена, а другой администратор добавил на другом контроллере другого пользователя в окне задержки репликации, Active Directory выберет последнее добавление, а предыдущее добавление будет полностью утрачено. Корпорация Майкрософт решила эту проблему в Windows Server 2003 с помощью процесса, называемого «репликация связанных значений» (LVR).
На функциональном уровне леса или внутреннего леса Windows Server 2003 Active Directory отдельно реплицирует индивидуальные значения атрибутов ссылок вперед с множественными значениями, при этом каждое значение имеет свои метаданные репликации. Это эффективно решает проблему, выявленную в Windows 2000, когда практически одновременные обновления членства в группах на различных контроллерах домена могут вызывать потерю данных.
В то же время существует один момент, который следует учитывать. При повышении функционального уровня леса не происходит одновременного исправления существующих атрибутов с множественными значениями новыми метаданными репликации. Новые метаданные будут присутствовать только для тех значений, которые были добавлены после повышения функционального уровня леса. Это оказывает заметное влияние на восстановление членства в группах, как вы сейчас увидите.

Резервное копирование
В состав Windows включена служебная программа начального уровня NTBACKUP, которую можно использовать для создания резервной копии состояния системы контроллера домена. Состояние системы контроллера домена включает его реестр, папку SYSVOL, файлы информационного дерева каталога Active Directory и критические системные файлы. Большинство сторонних программ резервного копирования также способны создавать резервные копии и восстанавливать состояние контроллера домена.
Для резервного копирования состояния в файл на диске используйте следующую команду:
NTBACKUP backup systemstate /F “<filename>”
Здесь <filename> — имя создаваемого файла резервной копии, который должен иметь расширение bkf .

Выполнение неполномочного восстановления
Восстановление удаленных объектов Active Directory из резервной копии идет в две стадии. Сначала контроллер домена перезагружается в режиме восстановления службы каталога, затем выполняется восстановление информационного дерева каталога Active Directory целиком с помощью служебной программы Windows NTBACKUP или аналогичной сторонней программы. При этом информационное дерево каталога полностью переписывается.
Существует два способа загрузки контроллера в режиме восстановления службы каталога. Если есть доступ к системной консоли контроллера, завершите работу и перезагрузите контроллер, затем нажмите F8 при появлении запроса на вывод меню загрузки Windows. Выберите в меню режим восстановления службы каталога и введите пароль для этого режима.
При удаленном управлении сервером меню загрузки Windows недоступно. Вместо этого можно изменить параметры загрузки системы, выбрав пункт «Настройка» в разделе «Мой компьютер», щелкнув вкладку «Дополнительно» и нажав кнопку «Параметры ниже надписи «Загрузка и восстановление». Нажмите кнопку «Правка» в разделе «Загрузка операционной системы» для внесения изменений в файл boot.ini, добавьте аргумент /SAFEBOOT:DSREPAIR к концу строки, как показано на рис. 3. (Дополнительные сведения об аргументах файла boot.ini см. microsoft.com/technet/ sysinternals/information/bootini.mspx.)
Рис. 3 Настройка параметров загрузки для режима восстановления службы каталога
Рис. 3 Настройка параметров загрузки для режима восстановления службы каталога
После перезагрузки сервера включится режим восстановления службы каталога. Помните, что нужно удалить аргумент /SAFEBOOT из файла boot.ini, если нужно перезагрузить контроллер домена в обычном режиме.
После входа в систему с паролем режима восстановления службы каталога восстановите состояние системы из резервной копии с помощью служебной программы NTBACKUP, но без каких-либо параметров. (Можно выполнить восстановление, набрав NTBACKUP в командной строке.) При появлении мастера выберите «Восстановление файлов и параметров» и нажмите кнопку «Далее». Выберите файл с резервной копией и проверьте состояние окна Состояние системы, как показано на рис. 4.
Рис. 4 Использование Мастера архивации и восстановления для восстановление состояния системы
Рис. 4 Использование Мастера архивации и восстановления для восстановление состояния системы
Если на этой стадии нужно загрузить контроллер домена в обычном режиме, процесс репликации Active Directory синхронизирует восстановленный контроллер с остальными контроллерами домена, и все восстановленные данные будут заменены на текущие. Разумеется, это не входило в ваши задачи. Вместо этого вам нужен способ принудительной репликации восстановленных данных на другие контроллеры домена.

Выполнение полномочного восстановления
NTDSUTIL также увеличивает номер версии каждого атрибута на 100 000 за каждый день промежутка между созданием архива и его восстановлением. Если не имеется атрибутов, которые меняются более 100 000 раз в день (очень маловероятно), номер версии восстановленных атрибутов будет значительно больше номера версии, хранящейся на других контроллерах домена. Полномочное восстановление реплицирует их на другие контроллеры. Другие объекты, которые были восстановлены из резервной копии неполномочно, будут обязательно заменены актуальными данными с других контроллеров домена.
После завершения неполномочного восстановления, но до перезагрузки используйте программу NTDSUTIL для выполнения полномочного восстановления объектов, которые хотите вернуть к первоначальному состоянию. Несмотря на название, полномочное восстановление объектов их не «восстанавливает», при этом Active Directory просто реплицирует объекты на другие контроллеры. Для этого NTDSUTIL присваивает следующий доступный USN локальному USN атрибутов объекта. Это приводит к тому, что объект будет отправлен для репликации партнерам при следующем сеансе синхронизации. Для восстановления единичного объекта убедитесь, что контроллер домена загружен в режиме восстановления службы каталога, и выполните следующие действия:
  1. Откройте окно командной строки и наберите:
    ntdsutil
  2. При появлении приглашения ntdsutil наберите:
    authoritative restore
  3. При появлении запроса на полномочное восстановление наберите:
    restore object “<DN of object to be restored>”
    Например, если нужно восстановить учетную запись Molly Clark в подразделении Eng домена DRNET, следует набрать:
    restore object “CN=Molly Clark,OU=Eng,DC=DRNET,DC=com”
    Если нужно полномочно восстановить все поддерево каталога, например подразделение, наберите вместо этого:
    restore subtree “OU=Eng,DC=DRNET,DC=com”
    В NTDSUTIL также имеется команда восстановления базы данных, которая полномочно восстанавливает весь домен, а также контексты именования конфигурации и схемы. Восстановление всего домена сопряжено с риском, и я не рекомендую использовать эту возможность. Если возникла необходимость восстановления всего домена, следует восстановить один контроллер домена и заново повысить роль остальных контроллеров домена, как описано на странице "Planning for Active Directory Forest Recovery",
  4. При появлении запроса подтвердите, что полномочное восстановление должно повысить номера версии соответствующих объектов и их атрибутов.
  5. Выйдите из программы ntdsutil (необходимо дважды набрать quit).
  6. Перезагрузите контроллер домена в обычном режиме Active Directory.
При следующем сеансе репликации контроллера домена с партнерами восстановленный пользователь будет реплицирован. Но восстановление объекта пользователя — только половина проблемы. Если представить себе связи объекта, например, между группой и ее членами, ситуация усложняется. В следующих разделах описывается некоторые фундаментальные проблемы, с которыми можно столкнуться при восстановлении.
Прежде всего рассмотрим, что происходит при удалении объекта, имеющего ссылки назад. Например, вы удаляете объект, который входит в состав одной или нескольких групп. Каждый контроллер домена, имеющий копию объекта пользователя, преобразует его в захоронение и удалит все ссылки в таблице связей, тем самым удаляя объект пользователя из всех групп домена. (Помните, что удаление пользователя из членов группы не реплицируется, каждый DC обновляет членство в группах локально. Номер версии и локальный USN атрибута члена группы остается неизмененным.) Спустя короткое время фантомные объекты будут удалены из таблиц ссылок в других доменах, снова без обновления метаданных репликации атрибута членства в группе.
При неполномочном восстановлении информационного дерева каталога на контроллере домена пользователя объект пользователь восстанавливается вместе с членством в группах по всему домену, поэтому восстановленный контроллер будет самосогласованным. После использования программы NTDSUTIL для полномочного восстановления пользователя объект пользователя реплицируется на все другие контроллеры домена.
Но поскольку метаданные репликации текущих групп домена не меняются, атрибуты членов групп восстановленного контроллера домена будут несогласованными с другими контроллерами домена. И не существует способа привести их в единое состояние. Таким образом, членство пользователей не будет восстановлено на других контроллерах домена.

Ситуация: Членство в группах домена не восстановлено
Полномочное восстановление объекта пользователя не восстанавливает членство пользователя в группах. Собственно, почему? Потому, что отношения членства сохраняются и реплицируются при помощи атрибута члена объектов групп (ссылки вперед), а не атрибута memberOf пользователя (ссылки назад). Проблема состоит в том, чтобы найти членство пользователей в старой группе и, узнав это, правильно их восстановить.
Корпорация Майкрософт постоянно вносит улучшения в процесс восстановления членства в группах, поэтому используемая методика зависит от версии Active Directory. Следующие разделы прежде всего применимы для Windows 2000 Active Directory.
Определить членство пользователя в старых группах достаточно просто: посмотрите атрибут ссылки назад на восстановленном контроллере домена — в данном случае это атрибут memberOf объекта пользователя. Атрибут memberOf будет содержать все сведения о членстве в локальных и глобальных группах домена пользователя. Для составления списка членства пользователя в группах можно использовать оснастку «Active Directory – пользователи и компьютеры» (ADUC), или программу LDIFDE, которая включена в состав Windows Server.
Следующая команда LDIFDE выведет список групп домена DRNET, членом которых состоит Molly Clark, сохранив результат в файле output.ldf:
C:\> ldifde –r “(distinguishedName=CN=Molly Clark,
OU=Engineering,DC=DRNET,DC=Local)” –l memberOf –p Base –f output.ldf
Помните, что для использования программы LDAP необходимо загрузить контроллер домена в обычном режиме и затем запретить входящую репликацию, иначе восстановленные данные будут переписаны. Простейший способ запретить входящую репликацию — использовать команду REPADMIN:
REPADMIN /options <dcname>+DISABLE_INBOUND_REPL
Здесь <dcname> — имя восстанавливаемого контроллера домена. Не забудьте после окончания заново включить репликацию с помощью параметра -DISABLE_INBOUND_REPL.
Если восстанавливаются только некоторые пользователи, можно просто вручную добавить пользователя в группы с помощью ADUC. Для восстановления большого числа пользователей существуют средства, позволяющие автоматизировать некоторые процессы. Служебная программа Microsoft GROUPADD (доступна через службу поддержки Microsoft) может использовать созданный файл LDIF для просмотра членства пользователя в старых группах и, в свою очередь, для создания файла LDIF, который восстанавливает это членство. Например, можно использовать команду GROUPADD для обработки файла LDIF, ранее созданного для пользователя Molly Clark:
C:\> groupadd /after_restore output.ldf
Эта команда создаст новый файл LDIF для каждого домена, в группы которого входит Molly Clark с именем groupadd_<domain>.ldf (где <domain> — полное доменное имя (FQDN) домена, в котором будут обновлены группы). Импортировать ранее созданный файл LDIF можно при помощи следующей команды:
C:\> ldifde –i –k –f groupadd_child.drnet.net.ldf
С выходом Windows Server 2003 корпорация Microsoft улучшила NTDSUTIL, добавив преимущества дополнительных метаданных, присутствующих в атрибуте членства для поддержки репликации связанных значений (LVR). Если восстанавливаемый объект пользователя являлся членом любых групп домена, а членство пользователя хранилось с метаданными LVR, служебная программа NTDSUTIL увеличивает номер версии соответствующего значения атрибута пользователя, что приводит к репликации восстановленного членства.
Служебная программа NTDSUTIL в составе Windows Server 2003 SP1 объединена с функциями GROUPADD и автоматически будет создавать файлы LDIF при полномочном восстановлении объекта пользователя. На рис. 5 показана новая версия NTDSUTIL, а на рис. 6 - содержимое автоматически созданного файла LDIF.
Figure 6 Содержание файла LDIF, созданного программой NTDSUTIL (Close Figure 6)
dn: CN=EngDL,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngDL,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngGG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngGG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngUG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngUG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
Рис. 5 Новая служебная программа NTDSUTIL со встроенными функциями GROUPADD
Рис. 5 Новая служебная программа NTDSUTIL со встроенными функциями GROUPADD
При восстановлении целого подразделения, содержащего ряд пользователей и групп, добавлять в эти группы пользователей вручную довольно утомительно. Другой способ возвращения членства для восстановленных групп — полномочное восстановление самих групп.
В то же время при полномочном восстановлении групп существуют две проблемы. Первая проблема очевидна: при восстановлении группы членство в ней будет отражать момент создания резервной копии. Это означает, что к группе необходимо заново применить любые изменения, произошедшие после создания архива. Вторая проблема не такая явная и связана с тем, как происходит репликация в Active Directory. После полномочного восстановления пользователей и групп нет гарантии, что репликация пойдет в нужном порядке. Если объект пользователя реплицируется позднее, он не будет добавлен в группу.
Простейшее решение этой проблемы — выполнить полномочное восстановление группы позже. После выполнения первого полномочного восстановления перезагрузитесь в обычном режиме и убедитесь, что репликация прошла правильно. Затем перезагрузитесь в режиме восстановления службы каталога и запустите программу NTDSUTIL, чтобы выполнить полномочное восстановление групп, членом которых является пользователь. При этом гарантируется, что при загрузке в обычном режиме объекты пользователей будут реплицированы до того, как объекты групп сошлются на их реплику.

Ситуация: Членство в группах других доменов не восстановлено
Проблема «членом каких групп является пользователь» на самом деле более сложная, чем я описал. Восстанавливаемый пользователь может быть членом локального домена и универсальных групп других доменов. Членство в этих группах не будет восстановлено при неполномочном восстановлении. Как узнать, в каких группах других доменов состоит пользователь? Ответ лежит в глобальном каталоге. Наряду с собственными данными о домене глобальный каталог содержит доступную только для чтения копию данных из других доменов леса.
Чтобы воспользоваться данными о лесе из глобального каталога, следует выполнить неполномочное восстановление в глобальном каталоге, что означает необходимость иметь архив глобального каталога. Теперь при запуске LDIFDE для определения членства пользователя в группах можно узнать о членстве пользователя в универсальных группах других доменов.
При просмотре членства в группах восстанавливаемого пользователя подключитесь к порту глобального каталога 3268 вместо стандартного 389 и выберите в качестве начала поиска корневой домен леса. LDIFDE покажет членство в группах восстанавливаемого пользователя, включая членство в универсальных группах всех доменов леса. Это делается следующим образом:
C:\> ldifde –r “(distinguishedName=CN=Don Clark,
OU=Engineering,DC=DRNET,DC=Local)” -t 3268 –l memberOf –p Base –f output.ldf
Если запустить программу GROUPADD или новую программу NTDSUTIL в глобальном каталоге, создается один файл LDIF для домена пользователя и один файл LDIF для каждого домена, в который восстанавливаемый пользователь был членом универсальной группы. При импорте этих файлов LDIF вы восстановите членство пользователя во всех группах. Или почти всех, как покажет рассмотрение следующей проблемы.

Ситуация: Восстановление членства в локальных группах других доменов
В среде Windows Active Directory существует три вида групп. Глобальные группы могут состоять только из членов своего домена, но которые могут использоваться как члены локальных групп того же домена или других доменов леса. Атрибут членства в глобальных группах не появляется в глобальном каталоге, но это не представляет проблемы, поскольку глобальные группы содержат только членов своего домена. Универсальные группы могут состоять из членов любого домена, которые могут выступать как члены других универсальных групп леса и локальных групп своего домена и других доменов леса. Атрибут членства в универсальных группах реплицируются в глобальные каталоги. Локальные группы домена могут состоять из членов любого домена леса, но которые не могут выступать как члены групп других доменов. Важнее то, что атрибут членства в локальных группах домена, как и в глобальных группах, не появляется в глобальном каталоге. В результате не существует простого способа восстановления членства пользователя в локальных группах других доменов.
До выхода Windows Server 2003 SP1 единственным способом восстановления членства в локальных группах других доменов было восстановление контроллера в каждом домене, ручной поиск в домене данных о любых локальных группах домена, содержащих восстановленного пользователя и затем добавление пользователя в найденные группы. В больших многодоменных средах этот способ требует непозволительно много времени.
В этом случае может помочь версия программы NTDSUTIL из Windows Server 2003 с пакетом обновления 1 (SP1). При запуске NTDSUTIL на контроллере домена создается текстовый файл, содержащий различающееся имя и идентификатор GUID восстановленных объектов пользователей. Затем для каждого внешнего домена можно неполномочно восстановить один контроллер домена, скопировать на него текстовый файл и запустить NTDSUTIL для создания нового файла LDIF для этого домена. Файл добавит восстановленного пользователя в локальные группы домена, членом которых он был ранее.
Для этого выполните следующие действия над контроллером домена в каждом внешнем домене:
  1. Загрузите контроллер внешнего домена в режиме восстановления службы каталога.
  2. С помощью программы NTBACKUP восстановите копию информационного дерева каталога, содержащую сведения о членстве в группах восстановленных пользователей.
  3. Скопируйте созданный NTDSUTIL TXT-файл на текущий контроллер домена.
  4. Откройте окно командной строки и наберите ntdsutil.
  5. Наберите authoritative restore (полномочное восстановление).
  6. Наберите create LDIF file(s) from <file name> (где <file name> имя текстового файла).
  7. Дважды наберите quit для выхода из программы ntdsutil.
  8. Перезагрузите контроллер домена в обычном режиме Active Directory.
  9. Наберите ldifde –i –f <ldif filename> (где <ldif filename> имя созданного только что файла LDIF).
Вы восстановили членство в группах всех удаленных пользователей.

Шаг за шагом
Восстановление пользователей Active Directory и их членства в группах, особенно в многодоменной среде — сложная задача. Конкретные действия, необходимые для правильного восстановления членства в группах, зависят от версии Windows.
При работе с Windows 2003 SP1 необходимы следующие действия:
  1. Загрузите глобальный каталог в режиме восстановления службы каталога и выполните восстановление состояния системы из архива, содержащего удаленных пользователей.
  2. С помощью программы NTDSUTIL выполните полномочное восстановление удаленного пользователя. NTDSUTIL создаст текстовый файл, содержащий различающееся имя и идентификатор GUID восстановленного объекта, и один или несколько файлов LDIF для восстановления членства пользователя в группах.
  3. Используйте команду LDIFDE –i –f <LDIF filename> (где <LDIF filename> имя файлов LDIF, созданных в шаге 2) для импорта членства в группах текущего и других доменов.
  4. Перезагрузите глобальный каталог в обычном режиме.
  5. В каждом внешнем домене загрузите какой-либо контроллер в режиме восстановления службы каталога и выполните восстановление состояния системы из архива, содержащего удаленных пользователей.
  6. Запустите программу NTDSUTIL с командой create ldif files (создать файлы ldif).
  7. Перезагрузите контроллер домена в обычном режиме.
  8. Используйте команду LDIFDE –i –f <filename> (где <filename> имя LDIF файла, созданного в шаге 6) для восстановления членства в группах внешнего домена.
  9. На этой стадии можно запустить репликацию командой REPADMIN /syncall.
Если запущена версия Windows Server 2003 без установленного пакета обновления 1 (SP1) или Windows 2000, необходимо выполнить ряд дополнительных действий. Поскольку более старая версия NTDSUTIL не создает файлы LDIF, используйте для их создания программу GROUPADD. Процедура выполняется так:
  1. Загрузите глобальный каталог в режиме восстановления службы каталога и выполните восстановление состояния системы из архива, содержащего удаленных пользователей.
  2. Отключите сетевую карту или отсоедините кабель для предотвращения входящей репликации.
  3. Перезагрузите глобальный каталог в обычном режиме.
  4. С помощью команды LDIFDE –r "(distinguishedName=<dn>)" -t 3268 -l memberOf –p Base -f membership.ldf создайте дамп членства пользователя с различающимся именем <dn>.
  5. Для создания файлов LDIF используйте команду GROUPADD /after_restore membership.ldf.
  6. Для импорта членства в группах текущего и других доменов используйте команду LDIFDE –i –f <filename> (где <LDIF filename> имя файла LDIF, созданного программой GROUPADD в шаге 5).
  7. Заново разрешите входящую репликацию с помощью команды REPADMIN /options <dcname> -DISABLE_INBOUND_REPL.
  8. В каждом внешнем домене загрузите какой-либо контроллер в режиме восстановления службы каталога и выполните восстановление состояния системы из архива, содержащего удаленных пользователей.
  9. Перезагрузите контроллер домена в обычном режиме.
  10. С помощью команды LDIFDE –i –f <filename> (где <filename> имя файла LDIF , созданного программой GROUPADD в шаге 5) восстановите членство в группах внешнего домена.
  11. На этой стадии можно запустить репликацию командой REPADMIN /syncall.
Единственное, что остается сделать в среде, предшествующей Windows Server 2003 с пакетом обновления 1 (SP1), — восстановить членство в локальных группах внешнего домена восстановленного пользователя. Можно вручную только восстановить членство в локальных группах домена или восстановить контроллер домена из резервной копии и полномочно восстановить локальные группы домена.

Заключение
Несмотря на то, что из Active Directory легко можно случайно удалить пользователей или даже подразделения, правильное восстановление удаленных пользователей и их членства в группах может оказаться неожиданно сложной, длительной и подверженной ошибкам задачей. Для уверенности в том, что вы сможете преодолеть эти трудности максимально быстро, следует понимать механизмы связи объектов, репликации, удаления и полномочного восстановления.
Сможете ли вы правильно выполнить эти действия в вашем окружении с первой попытки? Для уверенности в том, что в следующий раз вы действительно сможете восстановить объект Генеральный директор, приготовьте письменный план восстановления удаленных объектов. И потренируйтесь в выполнении этого плана один-два раза перед тем, как испытывать его на реальных данных. Ваш босс (и ваш генеральный директор) оценят это по достоинству.
Дополнительные источники
  • How to Restore Deleted User Accounts and Their Group Memberships in Active Directory
  • Центр справки и поддержки Майкрософт
  • Step-by-Step Guide to Managing Active Directory

Джил Киркпатрик (Gil Kirkpatrick) — руководитель технологического отдела компании NetPro и разработчик программного обеспечения для Active Directory с 1996 г. Вместе с Гвидо Грилленмайером (Guido Grillenmeier) из компании HP он поставляет популярные средства аварийного восстановления Active Directory. Джил также является основателем конференции Directory Experts (www.dec2007.com).


 Администрирование в Windows: Для чего нужна пользователю операционная система Windows XP Embedded
Администрирование в Windows Дон Джонс (Don Jones)

Для чего нужна пользователю операционная система Windows XP Embedded
Краткий обзор:
  • Внутренняя структура операционной системы Windows XP Embedded
  • Специализированное оборудование
  • Специальная настройка операционной системы Windows XP Embedded

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

Что представляет собой Windows XP Embedded?
Windows® XP Embedded является одной из трех компактных версий операционной системы Windows, наряду с Windows Embedded CE и Windows Embedded for Point of Service. Среди встроенных операционных версий Windows только Windows XP Embedded предлагает полный набор функций (или, по крайней мере, основу для обеспечения полного набора функций) для клиентского компьютера, работающего под управлением Windows XP Professional. В ее основе лежит Windows XP Professional с пакетом обновления 2 (SP2); однако Windows XP Embedded отличается от стандартной операционной системы Windows XP крайне высоким уровнем модульности своей структуры. У Windows XP Embedded нет того, что можно было бы назвать стандартным образом установки. Вместо этого набор средств под названием Windows Embedded Studio используется для создания специальным образом настроенной среды Windows XP Embedded для любого создаваемого устройства, и в эту среду включаются только необходимые устройству функциональные возможности. Если вам не требуется DirectX® или проводник Windows, просто не устанавливайте их. Такая модульность означает, что у каждого создаваемого и разворачиваемого образа Windows XP Embedded будет меньшее число составляющих, что приводит к уменьшению нагрузки на администраторов и повышению безопасности, а также появлению возможности работать более дешевом оборудовании. С некоторыми из существующих вариантов можно ознакомиться с помощью средства Target Designer (входит в состав набора Windows Embedded Studio), как показано на рис. 1.
Рис. 1 Выбор компонентов с помощью средства Target Designer
Рис. 1 Выбор компонентов с помощью средства Target Designer

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

Отличительные достоинства Windows XP Embedded
Операционная система Windows XP Embedded предлагает весьма ценные возможности, недоступные в полной версии Windows XP. Enhanced Write Filter (EWF) и Hibernate Once, Resume Many (HORM) — оба этих средства могут упростить выполнение задач по управлению Windows. EWF является дополнительным компонентом, добавляемым в развертывание Windows XP Embedded, который делает данный дисковый том доступным только для чтения. Любые операции записи, направленные на этот диск, перенаправляются в наложение, находящееся на другом диске или даже в памяти. Сама операционная система рассматривает наложение EWF и его родительский том как единое устройство, т.е. как обычный дисковый том. Тем не менее, фактически на родительском томе не выполняются реальные изменения; изменениям подвергается только наложение EWF. Это может являться преимуществом в нескольких случаях. Представим себе развертывание образа Windows XP Embedded на карте памяти Compact Flash (CF) (образы Windows XP Embedded могут иметь размер от 5 МБ и зачастую помещаются в объеме приблизительно 200 МБ, так что на CF достаточно места для хранения). Карту памяти CF можно вставить в адаптер и подключить к разъему IDE системной платы; при этом карта памяти CF воспринимается как обычный несъемный диск. У современных карт памяти CF ограниченный ресурс записи (приблизительно 100 000 операций записи), поэтому EWF используется для назначения CF томом, предназначенным только для чтения. Представим размещение наложения EWF в ОЗУ: если пользователь делает ошибку, достаточно просто выключить компьютер. Наложение EWF и любые изменения, сделанные в компьютере, мгновенно теряются. При перезагрузке вы возвращаетесь назад в исходную точку, хранящуюся на карте памяти CF. Одну и ту же настройку можно использовать для образа на основе компакт-диска или диска DVD; поскольку эти типы носителей исходно предназначены только для чтения, EWF вносит любую операцию записи в наложение. Даже если наложение хранится на небольшом внутреннем жестком диске, обеспечивается гарантия того, что исходный загрузочный том (на компакт-диске или диске DVD) никогда не подвергается изменениям; если возникает необходимость перезагрузить компьютер, чтобы получить исходную конфигурацию, для этого достаточно стереть наложение EWF.
HORM, в соответствии со своим именем, позволяет после однократного перевода компьютера в спящий режим многократно возобновлять его работу из точки перехода в спящий режим. Компьютер включается почти мгновенно. Достаточно настроить компьютер, запустить все необходимые приложения, а затем перевести его в спящий режим. После этого при каждом включении компьютера вам потребуется только подождать несколько секунд, чтобы обнаружить все приложения работающими.

Создание образа Windows XP Embedded
У корпорации Майкрософт существует программа Embedded Partner, объединяющая компании, специализирующиеся по работе с Windows XP Embedded (список этих компаний представлен на домашней странице Windows XP Embedded по адресу microsoft.com/embedded). Однако, несмотря на множество компаний, предоставляющих обычным производителям ПК предварительно созданные образы (включающие корпоративные приложения и специальные конфигурации), вам может потребоваться создать свои собственные образы Windows XP Embedded, которые впоследствии можно использовать совместно с участниками программы Embedded Partner, предоставляющими вам завершенные компактные системы. Набор Windows Embedded Studio, устанавливаемый в операционной системе Windows XP Professional, можно использовать для создания образов Windows XP Embedded и управления ими.
Для использования этого набора средств сначала следует установить полную версию Windows XP Pro на том оборудовании, которое предполагается использовать для системы Windows XP Embedded. Это позволяет использовать в полной мере процедуру установки Windows XP, чтобы добиться надлежащей работы всего оборудования. Затем устанавливается набор инструментов Windows Embedded Studio. Обычно при этом устанавливается база данных, используемая для управления встроенными образами, но на самом деле эта база данных может быть установлена в другом месте, предоставляющем центральное хранилище. Далее запускается служебная программа с интерфейсом командной строки, Tap.exe, создающая новый специальный компонент, который может использоваться операционной системой Windows XP Embedded. Обычно компоненты инкапсулируют такие наборы функциональных возможностей, как проигрыватель мультимедиа, файловая система или другие пользовательские приложения; в этом случае создается компонент, содержащий драйверы устройств для оборудования, необходимого вашей конкретной системе. Этот этап должен быть выполнен на целевом оборудовании, чтобы средство имело возможность обнаружить и включить соответствующие драйверы оборудования.
На следующем этапе запускается конструктор компонентов Windows XP Embedded и импортируется пакет компонентов, созданный служебной программой Tap.exe. Как показано на рис. 2, конструктор компонентов читает информацию об устройстве и собирает завершенный компонент Windows XP Embedded, который может служить основой для нового образа Windows XP Embedded. Это значительно упрощает процедуру точного определения драйверов устройств, необходимых для данной платформы. После создания компонента диспетчер базы данных компонентов используется для импорта нового компонента в базу данных компонентов Windows XP Embedded — хранилище, в котором хранятся все известные компоненты Windows XP Embedded. Присутствие компонента в базе данных делает его доступным для использования в образах Windows XP Embedded.
Рис. 2 Конструктор компонентов
Рис. 2 Конструктор компонентов
Теперь можно приступить к созданию новой целевой конфигурации с использованием средства Windows XP Embedded Target Designer, при помощи которого выполняется большая часть реальной работы. Как видно из рис. 1, добавляются любые компоненты, необходимые для создания набора функций, требуемых устройству. Потребуется также добавить некоторые основные компоненты Windows, например, проводник Windows (если устройству требуется графическая оболочка), файловую систему NTFS (или FAT32), загрузчик NT, поддержку для языка, ядро пользовательского интерфейса и т.д.. По умолчанию доступно более десяти тысяч компонентов.
Предусмотрена также предварительная настройка параметров каждого компонента. Например, компонент User Interface Core можно настроить на отображение конкретных элементов в меню Windows «Пуск», «Рабочий стол» и в других местах. Настройка параметров для каждого компонента гарантирует, что предварительная настройка каждого устройства будет удовлетворять конкретные потребности (см. рис. 3).
Рис. 3 Настройка параметров
Рис. 3 Настройка параметров
Самой замысловатой частью образа Windows XP Embedded являются зависимости. Например, невозможно добавить компонент DirectX к образу, не добавляя несколько компонентов, обеспечивающих основные возможности Windows по обработке графики. Отслеживание всех зависимостей может оказаться весьма сложной задачей, особенно для больших и сложных образов, у которых могут быть буквально тысячи зависимостей. Эта задача возлагается на базу данных компонентов. Простым нажатием клавиши F5 в средстве Target Designer выполняется проверка всех добавленных компонентов с автоматическим добавлением всех зависимостей, необходимых перечисленным компонентам. На рис. 4 показан процесс проверки; именно этот крайне важный этап обеспечивает такую высокую степень модульности операционной системы Windows XP Embedded. В отсутствие этих интеллектуальных средств, встроенных в Target Designer, было бы крайне трудно выполнить успешное создание образов, содержащих правильные зависимости.
Рис. 4 Проверка зависимостей
Рис. 4 Проверка зависимостей
После добавления всех компонентов и их зависимостей можно создавать образ Windows XP Embedded. Образы представляют собой просто файлы, которые необходимо скопировать на загрузочный том устройства Windows XP Embedded. Для их развертывания не требуются никакие специальные инструменты (хотя в набор инструментов Windows XP Embedded входит сервер удаленной первоначальной загрузки, функции которого аналогичны функциям служб удаленной установки; он позволяет выполнить развертывание образов Windows XP Embedded на совершенно новом оборудовании). После завершения этих этапов выясняется реальный размер образа. Я создал минимальный базовый образ, в который входит оболочка «Проводник» и несколько приложений, таких как текстовый и графический редактор, и созданный образ был менее 90 мегабайт. Безусловно, найдется не так много пользователей, заинтересованных в устройстве, на котором работают только текстовый и графический редактор, но это является иллюстрацией того, насколько небольшим может быть образ для конкретной задачи.

Сравнение Windows XP Embedded и Windows XP
Windows XP Embedded ни в коем случае не является урезанным вариантом операционной системы. Майкрософт предоставляет предварительно упакованные компоненты, позволяющие компьютеру, работающему под управлением Windows XP Embedded, иметь в большой степени такие же функциональные возможности, как и у полной версии Windows XP. К ним относятся возможность установки DirectX 9.0c, Microsoft® .NET Framework, Windows Media® Player 10 и многого другого. Существует также большой объем документации для разработчиков, описывающей способы создания пользовательских компонентов, например, пользовательской оболочки, заменяющей «Проводник», что позволяет создавать среду, соответствующую конкретному встроенному устройству
Однако операционная система Windows XP Embedded предлагает не каждый отдельный компонент, входящий в состав полной версии Windows XP. Например, защита файлов Windows (WFP — Windows File Protection) не входит в состав Windows XP Embedded; не входят в ее состав и некоторые из удобных компонентов, например Знакомство с Windows XP, начальные экраны приветствий и мастера, помогающие начинающему пользователю настраивать компьютер, или программа установки Windows. В Windows XP Embedded не используется активация Windows (образы Windows XP Embedded активируются с помощью ключа продукта этапа выполнения при работе инструментов Windows Embedded Studio). Наиболее примечательно то, что Windows XP Embedded совершенно не использует механизм обновления Windows, хотя может использовать в созданной среде сервер служб обновления программного обеспечения Microsoft. Наконец, в Windows XP Embedded нет MSN® Explorer, входящего в состав Windows XP Pro.
В перспективе обширный цикл разработки Windows XP Embedded продолжается: в настоящее время доступен Feature Pack 2007, в который добавлены новые компоненты, такие как загрузка с устройства USB, усовершенствование EWF, позволяющее направлять новые файлы на родительский том, не направляя наложение в целом, поддержка сжатия NTFS и многое другое. Эти усовершенствования увеличивают гибкость и количество вариантов операционной системы Windows XP Embedded, одновременно уравнивая ее по набору компонентов с операционной системой Windows XP Professional.

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

Дон Джонс (Don Jones) занимает должность заместителя директора по проектам и услугам компании SAPIEN Technologies и является соавтором книги Windows PowerShell: TFM (издательство SAPIEN Press). Связаться с Доном можно через его веб-узел www.ScriptingAnswers.com.


 Управление: Перспективное планирование при помощи System Center Capacity Planner
Управление Джон Савилл (John Savill)

Перспективное планирование при помощи System Center Capacity Planner
Краткий обзор:
  • Основы SCCP
  • Создание новой модели
  • Тонкая настройка модели
  • Имитация применения

Современные инфраструктурные компоненты очень важны для бизнеса, который поддерживают. В то же время по мере роста числа пользователей и диверсификации компаний точная оценка производительности и
числа серверов, необходимых для запуска компонентов, становится непростой задачей. Недостаток оборудования ведет к увеличению времени ответа для конечного пользователя, а избыток является пустой тратой денег и влечет за собой затраты на дополнительное управление. Поэтому корпорация Майкрософт создала планировщик System Center Capacity Planner (SCCP) 2006.
На верхнем уровне SCCP позволяет вводить сведения о топологии сети (расположение, скорости связи, задержки), используемом оборудовании и программном обеспечении и профилях использования (таких, как число отправленных сообщений). Затем SCCP запускает моделирование различных уровней использования и выясняет степень загрузки оборудования и сетевых компонентов. Такое моделирование помогает выяснить, будет ли соответствовать предлагаемая конфигурация вашим требованиям.
Для SCCP не требуется запускать какой-либо сервер или выполнять тестирование сети; это просто средство моделирования, которое может проверку ситуаций в моделируемой среде. Минимальные системные требования для работы SCCP: Windows® XP с пакетом обновления 2 (SP2), Windows Server® 2003 или Windows 2000 с пакетом обновления SP4, а также Microsoft® .NET Framework 2.0. Ожидается, что следующее поколение SCCP будет сильнее интегрировано с Systems Management Server (SMS) и Microsoft Operations Manager (MOM), и сбор ряда сведений автоматизируется, поскольку MOM собирает сведения о загрузке сервера, а SMS поддерживает сведения о конфигурации оборудования.
Установка SCCP 2006 несложна; стандартный мастер установки требует только согласиться с лицензионным соглашением и подтвердить папку для установки. После установки продукта в меню «Все программы» будет добавлена ссылка на него. При первом запуске SCCP экран приветствия Microsoft Capacity Planner предоставляет доступ к трем из четырех компонентов планировщика, как показано на Рис. 1.
Рис. 1 Запуск планировщика
Рис. 1 Запуск планировщика
Мастер моделирования задаст вопросы о желаемой среде, чтобы создать модель системной архитектуры (SAM). В состав SAM входят подробные сведения о филиалах, пользователях, сети, шаблонах использования и оборудовании.
Редактор моделей позволяет точно настроить и изменить модели SAM, ранее созданные с помощью мастера или редактора. Здесь можно проверить модели, показать имитацию использования и проверить другие ситуации, такие, как дополнительная нагрузка на почтовые серверы или присутствие удаленных пользователей.
Планировщик поставляется с набором типов оборудования, предопределенным для использования в SAM. В то же время если требуется что-то другое, редактор оборудования поддерживает пользовательские определения конфигурации оборудования.
После выбора модели имитатор планировщика дает возможность выполнить на выбранной модели различные тесты, чтобы определить ее стойкость в реальных условиях.
Использование этого средства — лучший способ взглянуть на компоненты и их взаимодействие. Начнем с мастера, затем выполним имитацию, после чего точно настроим архитектурную модель, добавляя пользовательское оборудование. В этом описании рассматривается среда Exchange, но процесс аналогичным образом выполняется и для MOM.

Создание новой модели
Перед тем, как на планируемой инфраструктуре можно будет обработать ситуации проверки или «что будет, если», или если просто нужно запустить моделирование ситуаций, относящихся к развернутой инфраструктуре, для SCCP нужно описать среду. К сожалению, в существующей версии нельзя просто выполнить поиск в сети. Вместо этого необходимо описать инфраструктуру: физическое расположение и типы связи между объектами, расположение серверов, почтовых ящиков и пользователей, а также сведения об использовании среды пользователями.
Средство обладает рядом ограничений, которые подробно описаны в руководстве пользователя. Например, в модели Exchange поддерживается только один лес. Это значит, что домены из внешних лесов не войдут в состав модели, и считается, что любые серверы переднего плана хранят глобальный каталог и почтовые ящики в одном сайте. Моделироваться могут только 100 офисов, из которых до 10 могут быть узловыми офисами, до 300 серверных компьютеров, и поддерживаются только клиенты Outlook® 2003 (Веб- или локальные). Хорошая новость заключается в том, что SCCP поддерживает до 49 999 клиентов в центральном офисе и узловых офисах и до 10 000 клиентов в филиалах. Такие возможности подключения Exchange, как ActiveSync® и Outlook Mobile Access, не поддерживаются, также не поддерживаются такие традиционные способы подключения, как POP и IMAP. Не учитываются нагрузки на выполнение операций резервного копирования и восстановления, не моделируются кластерные конфигурации; в то же время планировщик имеет необходимую возможность точно моделировать типичные ежедневные задачи по использованию электронной почты.
Чтобы начать просмотр со страницы приветствия, выберите "Create a model with the Model Wizard" (Создание модели с помощью мастера) и опишите моделируемую инфраструктуру. Я собираюсь создать компанию, расположенную в трех местах — центр в Далласе, филиалы — в Хьюстоне и Остине, в каждом месте есть ряд пользователей электронной почты. В каждом офисе не обязательно должны существовать свои почтовые серверы, поэтому я вношу сведения о числе и типе пользователей электронной почты; SCCP рассчитывает, в каких местах должны находиться местные серверы Exchange и где пользователи подключаются к ним удаленно.
После создания базовой модели инфраструктуры предприятия мастер запрашивает число центральных офисов и филиалов, типы каналов связи между ними и доле пропускной способности, которую можно использовать для обмена сообщениями. Мастер приблизительно рассчитывает модель; позднее я точно настрою созданную мастером модель, тщательнее отрегулирую индивидуальные связи. В этом примере я могу подтвердить существование одного центрального офиса и двух филиалов (см. рис. 2). Между филиалами и центральным офисом установлен канал связи T1, половина пропускной способности может использоваться для передачи сообщений. Мне не требуется настраивать скорость связи между центральными офисами, потому что таковой только один.
Рис. 2 Настройка топологии WAN и пропускной способности подключения
Рис. 2 Настройка топологии WAN и пропускной способности подключения
Следующее окно мастера спрашивает о среднем количестве пользователей в филиалах, клиенте электронной почты (Outlook 2003 в режиме кэширования или веб-клиент Outlook) и числе пользователей центрального офиса. Это снова приблизительные данные, которые позднее можно настроить точнее с помощью редактора моделей. В данном случае я указал, что в каждом филиале есть 200 пользователей, 500 — в центральном офисе, все используют Outlook с кэшированием.
Мастер предусматривает три стандартных уровня использования электронной почты: High, Medium и Low (Высокий, Средний и Низкий). Для каждого уровня принимается свой средний объем почтового ящика, свое число принятых и отправленных сообщений и свой средний размер сообщения электронной почты. Если не один из стандартных встроенных типов не соответствуют параметрам вашей организации, можно индивидуально настроить каждую из четырех рабочих характеристик.
Следующий шаг состоит в настройке параметров оборудования, как показано на рис. 3. SCCP позволяет указывать до трех возможных конфигураций процессоров, что можно использовать для моделирования оборудования для различных ролей сервера. Диапазон конфигурации лежит от одного процессора 1 ГГц Pentium III Xeon до четырех процессоров 3,66 ГГц Xeon MP. Exchange 2003 состоит из различных ролей сервера: Хранилище почтовых ящиков, Сервер-плацдарм, и Сервер переднего плана, а также дополнительная роль глобального каталога Active Directory®. Если позволяет загрузка, есть возможность объединить роли на меньшее число серверов. Если объединение серверов не выбрано, настраиваются отдельные серверы для каждой роли, даже если загрузка не требует этого. Лучшие результаты получаются, если разрешить SCCP объединять серверы.
Рис. 3 Настройка профилей оборудования для серверов
Рис. 3 Настройка профилей оборудования для серверов
Наконец, можно выбирать доступные жесткие диски на основе интерфейса, объема и скорости. Число дисков указывать не требуется, это автоматически сделает сам планировщик. Планировщик также может выбрать сеть хранилища данных Storage Area Network (SAN), хотя возможность создавать кластеры пока недоступна.
Следующий шаг в работе мастера — сводка по расчетной модели, которая показывает оптимальное число серверов по расчету SCCP, роль каждого сервера и такие данные конфигурации, как процессор, объем памяти и жесткий диск. Если выбрано хранилище SAN, оно тоже будет отражено.
Обратим внимание, что поскольку было выбрано распределенное расположение, очень возможно, что серверы будут показаны только для части расположения. Причина этого в том, что программа SCCP определила, что устанавливать местные серверы Exchange в некоторых местах нецелесообразно, и вместо почтовых ящиков лучше использовать удаленный сервер почтовых ящиков Exchange, как в примере, показанном на рис. 4. В этом случае 400 служащих филиала не имеют своего хранилища почтовых ящиков Exchange, и вместо этого обслуживаются сервером-хранилищем в Далласе, который теперь обслуживает 500 пользователей.
Рис. 4 Итог начальной оценки планирования
Рис. 4 Итог начальной оценки планирования
Вплоть до этой стадии работы мастера можно было нажать кнопки Back (Назад) и Next (Далее) для изменения ответов и тонкой настройки модели (или напрямую переходить на нужные страницы мастера при помощи панели перемещения слева). Если конфигурация одобрена, я нажимаю кнопку Finish (Готово) на странице Model Summary (Сводка модели). В результате модель будет открыта в редакторе моделей, где можно выполнить более детальную настройку.

Тонкая настройка модели
Мастер создания моделей Model Wizard — великолепное средство для создания базовой модели. В то же время, пока различные местоположения одинаковы и уравнены в правах, наверняка потребуется некоторая подгонка модели, чтобы она была действительно полезна как основа для расчета нагрузки. Это обычная ситуация, если в разном расположении присутствует разное число пользователей или при сочетании разных почтовых клиентов, например, Outlook 2003 в режиме кэширования и веб-клиент Outlook. Если в мастере создания моделей невозможно получить такой уровень детализации, он рассчитывается в редакторе моделей. Это средство также полезно для выяснения последствия изменений среды, например, при добавлении дополнительных местоположений или типов пользователей.
Редактор моделей, показанный на Рис. 5 сохраняет и выбирает модели из SAM-файлов, собственного формата программы. Рекомендуется, как и при любой работе, сохранять модели в файл перед выполнением больших изменений и использовать описательное имя, чтобы избежать потери рабочих моделей. В меню File (Файл) существует меню Export (Экспорт), которое создает подробный сводный отчет в формате Excel® и диаграмму топологии модели в формате Visio®.
Рис. 5 Настройка конфигурации SAM в редакторе моделей
Рис. 5 Настройка конфигурации SAM в редакторе моделей
На левой панели редактора моделей существует область навигации с возможностью просмотра общей топологии, топологии сайта или сводки модели. Общая топология (Global Topology) показывает архитектуру модели с точки зрения сайтов с дополнительными сетями, например, Интернетом. Просмотр топологии сайтов (Site Topology) показывает сведения о выбранном сайте или сети. Сводка по модели (Model Summary) отображает текстовую сводку окружения в том же формате, что и показанная в конце работы мастера создания моделей.
Независимо от выбранного варианта подробности отображаются на центральной панели редактора моделей. Правая панель — в духе концепции новой версии консоли управления Microsoft Management Console (MMC), входящей в состав Windows Server 2003 R2, — область «действия». В свою очередь она разбита на две области: в верхней части отображаются контекстно-зависимые действия, которые меняются в зависимости от вида просмотра или выбора объекта, а в нижней части отображаются действия, которые выполняются всегда. Эти последние действия позволяют добавить новый файл, изменять профили использования пользователей и запускать имитацию.
При работе в центральной панели редактора можно выбирать любые пункты. После выбора элемента кроме обычных действий, зависящих от выбранного объекта, можно подробнее рассмотреть сведения об объекте. Например, при двойном щелчке сайта режим просмотра меняется на Site Topology, и появляются сведения об объектах, смоделированных для этого сайта. Таким образом, локально обслуживаемый сайт покажет один или несколько серверов, сети и пользователей этого офиса. В свою очередь можно дважды щелкнуть выбранный объект, просмотреть его подробные свойства и изменить их при необходимости.
Линии, соединяющие сайты, обозначают сети между офисами и могут быть изменены для точной подстройки конфигурации сети. Например, я могу указать разную пропускную способность для прямого и обратного каналов и процент доступной пропускной способности. Кроме того, можно настраивать задержку канала, параметр, очень важный для стабильной связи. Другие обычные изменения включают добавление пользователей разных типов. В этом примере можно сказать, что мы имеем смесь веб-клиента Outlook и Outlook 2003, обслуживаемых центральным расположением. После открытия Далласа в режиме топологии сайта я выберу «Add a client profile» (Добавить профиль клиента) и добавлю сведения для пользователей OWA, в число которых войдут сервер, обслуживающий клиентов OWA, сеть, через которую они подключаются, и доступная им пропускная способность канала, как показано на рис. 6.
Рис. 6 Добавление и изменение элементов модели — это очень просто
Рис. 6 Добавление и изменение элементов модели — это очень просто
После того как SAM максимально близко отразит существующую или планируемую инфраструктуру, сохраните ее и дайте соответствующее название, чтобы в дальнейшем легко было ее идентифицировать как начальную точку для любых последующих модификаций. На этой стадии я люблю запускать процесс имитации, чтобы посмотреть быстродействие модели с настроенными параметрами. На основе результатов теста я могу изменить модель, чтобы проверить разные ситуации «что будет, если»: например, добавить новый сайт и пользователей, добавить или удалить серверы, добавить новых пользователей в расположение, изменить тип подключения или клиентов электронной почты. После обновления модели за счет новых элементов я могу запустить другой процесс имитации, чтобы посмотреть, как будет вести себя новая конфигурация.

Имитация применения
Запустить имитацию так же просто, как выбрать Run simulation (Запустить имитацию) из общих действий или нажать кнопку на панели инструментов. Первой выполняется проверка исправности модели: до выполнения имитации будут показаны любые недочеты модели. Например, если ряд клиентов OWA добавлен к модели, в которой до этого не было клиентов OWA и сервера переднего плана, сообщение об ошибке подскажет вам, что сервер переднего плана не существует. Если существуют такие недочеты, они будут постоянно отображаться во время выполнения имитации.
После завершения имитации формируется отчет с подробными сведениями об использовании всех компонентов, и открывается представление Simulation Results (Результаты имитации). Сначала в нем отображаются общие сведения о пиковой нагрузке на центральный процессор, системы хранения и связи (что обычно являются узкими местами), а также время самой длительной операции и задержки, которые могут касаться конечных пользователей. Сведения о точной нагрузке на серверы, SAN, местные и внешние соединения можно увидеть, если выбрать ссылки на левой панели результатов имитации, как показано на рис. 7.
Рис. 7 Общий итог имитации для простой модели
Рис. 7 Общий итог имитации для простой модели
Удерживая указатель мыши над различными графическими элементами, такими, как анализ узких мест, можно увидеть сервер и его атрибуты, ставшие причиной появления узкого места. Обратите внимание на параметры Threshold (порог) на левой панели. Эта полезная функция позволяет указать, что считать заслуживающим внимания для появления предупреждения.
Подробный отчет о имитации очень важен не только для выбора решения о закупке аппаратуры, он также показывает объем сетевых ресурсов, которые будут использоваться приложением обмена сообщениями. Например, если пользователи подключаются через медленное соединение WAN, отчет покажет, достаточна ли скорость связи. Если это не так, можно выяснить, необходимо ли увеличивать скорость канала между расположениями или просто нужно добавить хранилище почтовых ящиков, заново запустить имитацию и получить результаты, соответствующие определенному требованию. Более того, если все серверы работают с нагрузкой на процессор, равной 5%, можно снизить требования к техническим характеристикам серверов. Благодаря возможности изменить простую модель и провести имитацию заново, я свободен в экспериментах с выбором различных решений. Обладая системой точных показателей по всем проверенным ситуациям, я могу с уверенностью идти на совещание по бюджету и планированию.

Заключение
Я познакомил вас с обзором того, как SCCP позволяет моделировать и анализировать развертывание Exchange. Помните, что SCCP работает на этом же уровне моделирования и имитации также для MOM. SCCP в настоящее время можно загрузить как часть MSDN® Premium downloads или TechNet Plus. ¦

Джон Савилл (John Savill) — заместитель директора компании Geniant по технической инфраструктуре. Он имеет сертификаты CISSP (сертифицированный специалист по безопасности информационных систем), Security и Messaging MCSE (сертифицированный системный инженер Майкрософт) по Windows Server 2003, является восьмикратным обладателем MVP и инструктором по Крав мага. Крое того, он является автором книгиWindows Server 2003 Active Directory Design and Implementation , выпущенной издательством Packt Publishing.


 Управление: Улучшенные клиентские описи при помощи SMS
Управление Уэс Добри (Wes Dobry)

Улучшенные клиентские описи при помощи SMS
Краткий обзор:
  • Применение агента инвентаризации оборудования SMS 2003
  • Расширение инвентаризации при помощи файлов MIF
  • Статические файлы MOF против динамических
Загрузить исходный код для этой статьи: DobrySMSInventory2007_04.exe (152KB)

В жизни любого администратора наступает момент, когда его начальник запрашивает информацию, которую невозможно собрать без изнурительной работы. Но представьте себе, что вы инициативный администратор,
который уже собирает эти данные. Вы могли бы мгновенно снабдить вашего начальника информацией, тем самым предотвращая необходимость простоя, избегая сверхурочной работы и, возможно, даже сохраняя компании немало денег. Вы могли бы стать героем.
Microsoft® Systems Management Server (SMS) 2003 собирает огромное количество информации. Но не всю, какая может понадобиться. К примеру, по умолчанию SMS 2003 не предоставляет сведений о локальных группах с их членами или локальных пользователях с их атрибутами. Отсутствие такой информации может стать проблемой, если, скажем, специалист включает группу Domain Users или, что еще хуже, группу Everyone в группу локальных администраторов на каждой системе, с которой он работает. Или, скажем, компания не имеет возможности узнать, каков список исключений для локальных файлов и папок в корпоративном антивирусном/антишпионском решении. Это может казаться незначительной проблемой – пока кто-нибудь из ИТ не обнаружит, что пользователи указывают в списке исключений c:\*.*.
При помощи соответствующего сочетания сценариев, инструментария управления Windows® (WMI) и знания SMS можно так расширить возможности описей SMS, чтобы они содержали практически любую информацию. Это стало возможным благодаря использованию файлов формата информации управления (Management Information Format, MIF) и формата объекта управления (Management Object Format, MOF).

Делаем опись
Применяя SMS, организации могут выполнять собственные развертывания, следить за целевыми системами и поддерживать развернутые системы. Расширяя возможности описей SMS, можно создавать значительно более настраиваемые цели и управлять ими. Например, вы можете обеспечить соблюдение локальных политик безопасности, развертывая ваши политики безопасности для систем, где политики изменены пользователем. Вы также можете отключить несанкционированные локальные учетные записи пользователей и удалить лишних локальных администраторов.
Конечно, организации полагаются на SMS для получения своевременной детальной информации о клиентских системах. Расширение описей позволяет создавать отчеты, содержащие полностью настраиваемую информацию, недоступную при пользовании только описями по умолчанию. И сведения могут быть очень детализированы. Например, можно создать отчет, содержащий число систем, в которых некоторый раздел системного реестра указывает на конкретную ферму серверов. Это позволит администратором прикинуть, сколько клиентов у каждой фермы в любое заданное время. Схожим образом группа безопасности сможет проверить, в каких из систем в сети выполняется конкретный процесс, являющийся известным шпионским ПО.
Важность файлов MIF и MOF состоит в возможности ввода информации практически из любого источника с незначительным преобразованием. Если информация основана на тексте, она может быть обработана и передана WMI в файле MOF, либо собрана в виде файла MIF и отправлена во время следующего цикла инвентаризации оборудования. Реализация расширения описи требует знания VBScript или JScript® наряду с пониманием, что именно необходимо собирать. Принимая во внимание то, что собрать можно практически что угодно, требуемые знания могут варьироваться от знания WMI до продвинутого знания SQL. Конечно же, понимание SQL обязательно независимо от типа собираемой информации, поскольку это знание потребуется, когда дело дойдет до отчетов по собранным данным.

Как работает инвентаризации
SMS содержит два типа процессов инвентаризации: оборудования и программного обеспечения. В описях программного обеспечения содержится только информация о файлах, такая как местоположение, версия, размер и прочие файловые атрибуты. Однако процесс инвентаризации программного обеспечения также позволяет собирать файлы и хранить их на основном сервере.
Расширенная инвентаризация оборудования делается легко, поскольку опись оборудования содержит наибольшее количество сведений о системе. Информация в описях оборудования поступает преимущественно от WMI, из системного реестра и BIOS.
Опись оборудования собирается по расписанию, указываемому в параметрах агента инвентаризации оборудования сайта SMS 2003. Сбор информации может производиться от раза в минуту до раза в несколько месяцев. Обычно хочется найти баланс между скоростью сбора информации, удовлетворяющей запросам начальства, и разумной нагрузкой на сеть, серверы узлов, точки управления или клиентов.
После первой установки агент инвентаризации оборудования компилирует файл sms_def.mof. Там содержится вся информация, которую SMS собирает изначально. Когда этот файл скомпилирован, пространства имен SMS и связанные классы, необходимые для агента инвентаризации оборудования, создаются в WMI. Большинство из низ размещены в пространстве имен \\.\root\CIMv2\SMS. После установки агент инвентаризации оборудования просматривает большую часть этих классов, чтобы скомпоновать сведения, которые затем передаются точке управления и, в конце концов, попадают в базу данных узла.

Файлы MIF
В дополнение к получению информации от этих классов WMI агент инвентаризации оборудования ищет файлы MIF в папках коллекций NOIDMIF и IDMIF. Все файлы MIF, найденные агентом, обрабатываются при следующей описи оборудования.
Файлы MIF предоставляют самый легкий способ расширить опись оборудования SMS. Файлы MIF бывают двух типов – NOIDMIF и IDMIF. Это статические файлы формата, похожего на XML, которые могут содержать практически любую информацию, которую пользователь хочет поместить в базу данных SMS. Они могут быть созданы любыми средствами для создания обычных текстовых файлов. Поэтому эти файлы могут быть созданы из большинства языков сценариев или просто вручную.
Обычно файлы MIF используются в ситуациях, когда информация не содержится в системном реестре и WMI или когда информацию необходимо вводить вручную. Эти файлы могут быть созданы, например, когда ваша группа по развертыванию оборудования устанавливает новую систему. Специалист по развертыванию может открыть в системе приложение HTML и ввести все сведения об оборудовании для обновления базы данных управления имуществом. Приложение динамически создает файл NOIDMIF и позволяет загрузить этот файл в папку коллекции NOIDMIF. Этот файл NOIDMIF может содержать всю введенную специалистом информацию, и его содержимое вливается в базу данных SMS.
Между файлами NOIDMIF и IDMIF всего несколько различий. Файл IDMIF содержит уникальный заголовок, предоставляющий данные об архитектуре, и уникальный идентификатор. Файлы IDMIF могут быть использованы для встраивания несистемных устройств в SMS в виде отдельных сущностей. Например, можно использовать сценарий для создания в SMS систем, которые на самом деле являются принтерами, и занести сведения о них в базу данных SMS.
Файлы NOIDMIF и IDMIF хранятся в стандартных местах, указанных в разделах системного реестра. Чаще всего это %SYSTEMROOT%\system32\ccm\Inventory\NOIDMIF и ...\IDMIF, в предположении, что агент SMS установлен в местоположение по умолчанию. Если агент был установлен в другое место, каталоги MIF должны быть %CCMAGENTINSTALLDIR%\Inventory\NOIDMIF и ...\IDMIF. Но если есть какие-либо сомнения по поводу местонахождения этих каталогов, вы можете проверить значения следующих параметров системного реестра:
HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\
Client\Configuration\Client Properties\NOIDMIF Directory

HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\
Client\Configuration\Client Properties\IDMIF Directory
Формат файлов MIF всегда одинаков, независимо от собираемой информации. Взглянув на файл MIF, показанный на рис. 1, вы увидите, что он включает один компонент, который содержит несколько групп и по одному атрибуту в каждой группе. Все разделы обязательны, хотя не требуется более одной группы или атрибута. Можно считать, что каждая группа в файле MIF соответствует строке в данных поименованного раздела описи оборудования, а каждый атрибут в группе является полем этой строки.
Figure 1 LocalAdmins.mif (Close Figure 1)
Start Component
  Name = “WORKSTATION”
    Start Group
        Name = “Local Admins”
        ID = 1
        Class = “Microsoft|LocalAdminsMIF|1.0”
        Start Attribute
            Name = “Account”
            ID = 1
            ACCESS = READ-ONLY
            Storage = Specific
            Type = String(100)
            Value = “Win32_UserAccount.Domain=’Contoso’,Name=’Domain Admins’”
        End Attribute
    End Group
    Start Group
        Name = “Local Admins”
        ID = 2
        Class = “Microsoft|LocalAdminsMIF”
        Start Attribute
            Name = “Account”
            ID = 1
            ACCESS = READ-ONLY
            Storage = Specific
            Type = String(100)
            Value = “Win32_UserAccount.Domain=’Contoso’,Name=’Technicians’”
        End Attribute
    End Group
    Start Group
        Name = “Local Admins”
        ID = 3
        Class = “Microsoft|LocalAdminsMIF”
        Start Attribute
            Name = “Account”
            ID = 1
            ACCESS = READ-ONLY
            Storage = Specific
            Type = String(100)
            Value = “Win32_UserAccount.Domain=’Example-PC’,Name=’Administrator’”
        End Attribute
    End Group
    Start Group
        Name = “Local Admins”
        ID = 4
        Class = “Microsoft|LocalAdminsMIF”
        Start Attribute
            Name = “Account”
            ID = 1
            ACCESS = READ-ONLY
            Storage = Specific
            Type = String(100)
            Value = “Win32_UserAccount.Domain=’Example-PC’,Name=’RandomUser’”
        End Attribute
    End Group
End Component
Пример LocalAdmin.vbs, показанный на рис. 2 – достаточно простой сценарий VBScript. Он просматривает каталог NOIDMIF, удаляет временный файл MIF, если он существует, создает временный файл MIF, рекурсивно записывает туда данные, полученные через простой запрос WMI, удаляет файл MIF из каталога коллекции NOIDMIF и, наконец, перемещает временный файл MIF в каталог коллекции NOIDMIF.
Figure 2 LocalAdmin.vbs (Close Figure 2)
On Error Resume Next

Const ForAppending = 8

Set objWshShell = CreateObject(“WScript.Shell”)
Set objFSO = CreateObject(“Scripting.FileSystemObject”)

strTempDir = objWshShell.ExpandEnvironmentStrings(“%TEMP%”)
strWinDir = objWshShell.ExpandEnvironmentStrings(“%WINDIR%”)
strComputerName = objWshShell.ExpandEnvironmentStrings(“%COMPUTERNAME%”)
strNoIDMifRegLocation = “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Client\Configuration\Client “ _
   & “Properties\NOIDMIF Directory”
strNoIDMifDirectory = objWshShell.RegRead(strNoIDMifRegLocation)
strMifFileName = “\LocalAdmins.mif”
strClassID = “Microsoft|LocalAdminsMIF|1.0”

If objFSO.FileExists(strTempDir & strMifFile) Then
   objFSO.DeleteFile(strTempDir & strMifFile)
End If

Set objMifFile = objFSO.OpenTextFile(strTempDir & strMifFileName, ForAppending, True)

objMifFile.Writeline “Start Component”
objMifFile.Writeline “ Name = “ & Chr(34) & “WORKSTATION” & Chr(34)

strWBEMQuery = “SELECT partcomponent FROM win32_groupuser WHERE groupcomponent = “ & Chr(34) _
   & “\\\\” & strComputerName & “\\root\\cimv2:Win32_Group.Domain=\” & Chr(34) & strComputerName _
   & “\” & Chr(34) & “,Name=\” & Chr(34) & “Administrators\” & Chr(34) & Chr(34)

Set objWBEM = CreateObject(“WbemScripting.SWbemLocator”)
Set objWBEMServer = objWBEM.ConnectServer(, “root\cimv2”)
Set colResults = objWBEMServer.ExecQuery(strWBEMQuery)

i = 1
For Each objItem in colResults
         objMifFile.Writeline “ Start Group”
         objMifFile.Writeline “ Name = “ & Chr(34) & “Local Admins” & Chr(34)
         objMifFile.Writeline “ ID = “ & i
         objMifFile.Writeline “ Class = “ & Chr(34) & strClassID & Chr(34)
         objMifFile.Writeline “ Start Attribute”
         objMifFile.Writeline “ Name = “ & Chr(34) & “Account” & Chr(34)
         objMifFile.Writeline “ ID = 1”
         objMifFile.Writeline “ ACCESS = READ-ONLY”
         objMifFile.Writeline “ Storage = Specific”
         objMifFile.Writeline “ Type = String(100)”
         strUserName = objItem.PartComponent
         strUserName = mid(strUserName, instr(1, strUserName, chr(58)) + 1)
         If Instr(1, strUserName, Chr(92), 1) > 0 Then
                  strUserName = Replace(strUserName, Chr(92), Chr(92) & Chr(92), 1, -1, 1)
         End If
         If Instr(1, strUserName, Chr(34), 1) > 0 Then
                  strUserName = Replace(strUserName, Chr(34), Chr(39), 1, -1, 1)
         End If

         objMifFile.Writeline “ Value = “ & Chr(34) & strUserName & Chr(34)
         objMifFile.Writeline “ End Attribute”
         objMifFile.Writeline “ End Group”
         i = i + 1
Next

objMifFile.Writeline “End Component”
objMifFile.Close

If objFSO.FileExists(strNoIDMifDir & strMifFileName) Then
   objFSO.DeleteFile(strNoIDMifDir & strMifFileName)
End If

objFSO.MoveFile strTempDir & strMifFileName, strNoIDMifDir & strMifFileName
Хотя файлы MIF предоставляют легкий способ расширить опись оборудования SMS, есть моменты, которые стоит принять во внимание, используя их. Файлы MIF обрабатываются в каждом цикле инвентаризации оборудованиия. Но, поскольку эти файлы создаются, собираются, анализируются и только потом попадают в опись, может происходить задержка на один цикл инвентаризации перед попаданием содержащейся в них информации в опись. Это означает, что, если у компании ежедневный цикл инвентаризации оборудованиия, данные в базе данных узла могут отставать на два дня. Поэтому вы должны тщательно продумать, когда объявлять программы, создающие файлы MIF, и когда выполнять цикл инвентаризации оборудования.
Пусть в компании Contoso ежедневный цикл инвентаризации запускается в полночь. В 01:00 в понедельник запускается сценарий VBScript, создавая файл NOIDMIF, содержащий информацию о средстве для поиска программ для захвата административных прав. Этот файл собирается в полночь и передается управляющей точке. Администратор SMS Contoso просматривает отчеты в среду вечером около 22:00 и обнаруживает, что информации уже 45 часов. Это произошло потому, что администратор SMS не подумал, когда стоит объявить программу, создающую файл NOIDMIF.

Файлы MOF
Файлы MOF сложнее по сравнению с файлами MIF. Преимущество файлов MOF перед файлами MIF в том, что сведения из них передаются напрямую в WMI, делая их частью стандартного процесса сбора данных агента инвентаризации оборудования. Поэтому вам не понадобится снова и снова объявлять сценарий VBscript для получения информации, что сохранит ваше время и усилия. Вместо этого можно единожды объявить для каждого компьютера файл MOF, который затем компилируется.
Другим преимуществом файлов MOF является то, что информация в них так же актуальна, как и остальная информация в описи оборудования. Каждый раз, когда агент инвентаризации оборудования отрабатывает свой цикл, опрашивается классы и поставщики, указанные в файле MOF, и информация выдается быстро. Когда вам срочно нужна информация, вы можете запустить пакет, содержащий ваши файл MOF и сценарий VBScript, инициируя инвентаризацию оборудования. Нужные вам сведения получаются всего за один цикл политики объявленных программ.
Файлы MOF подразделяются на три класса: файлы MOF для существующих классов и пространств имен WMI, файлы MOF для дополнительных классов с существующим поставщиком WMI, и файлы MOF для дополнительных классов, у которых нет поставщика WMI.
Файлы MOF состоят из двух частей. Первая часть – это раздел определения пространства имен. Это в нем указывается информация о поставщике WMI. Второй раздел содержит атрибуты учета SMS. В этом разделе агенту инвентаризации оборудования сообщается, где искать и обрабатывать информацию, содержащуюся в указанных классах WMI. Поскольку файлы MOF имеют непосредственное отношение к WMI, я рекомендую вам потратить время и разобраться с набором средств разработки программного обеспечения Microsoft WMI Software Development Kit (SDK), если вы планируете работать с этими файлами (обратитесь по адресу go.microsoft.com/fwlink/?LinkID=83121 за дополнительной информацией).
Файл MOF каждого из вышеупомянутых классов может быть статическим или динамическим. Например, у вас будет статический файл MOF, если процедура сборки в компании компилирует файл MOF, содержащий сведения о том, кто собирал систему, какой выпуск серверов использовался, каковы были изначальные версии сборки, когда компьютер был собран и т. д . Эта информация не нуждается в обновлении и поэтому может быть помещена прямо в файл MOF и скомпилирована в WMI при помощи mofcomp.exe. После этого, область поиска агента инвентаризации аппаратного обеспечения должна быть расширена путем добавления информации о группе и классе в файл sms_def.mof на сервере узла.
Динамический файл MOF похож на статический, разница в том, что вместо записи собранной информации напрямую в WMI данные собираются через поставщика WMI. Поставщик WMI – это подключаемый модуль, позволяющий приложению или службе вводить информацию в WMI напрямую. Поставщик допускает динамический доступ в другие области WMI и системы, такие как системный реестр, местоположение файлов и информация Windows Installer.
В смысле работы с файлами MOF самый легкий способ улучшить инвентаризацию оборудования – собирать больше информации, чем уже есть в WMI. Это может быть сделано расширением sms_def.mof или разрешением дополнительных классов учета, которые в настоящий момент отключены. Файл sms_def.mof file расположен в папке \\siteserver\SMS_<sitecode>\inboxes\clifiles.src\hinv. Все устройства в компании запросят новый файл sms_def.mof в следующем цикле обновления политики компьютера и начнут сбор и отправку информации.
Следующим по сложности является использование существующего поставщика WMI с новым классом. Пример такого подхода показан на рис. 3. В этом примере с использованием встроенного поставщика системного реестра создается класс CU_Desktop с динамическим свойством, опрашивающим HKEY_CURRENT_USER\Control Panel\Desktop\Wallpaper на локальном устройстве. После того, как этот файл MOF скомпилирован на клиенте, в файл sms_def.mof необходимо добавить информацию из файла SMS_Def_Extension.mof (см. рис. 4). Файл содержит: информацию, должен ли SMS вести учет по нему, название группы, идентификатор класса, к какому классу WMI должен обращаться за информацией агент инвентаризации оборудования и, наконец, собственно значения.
Figure 4 SMS_Def_Extentions.mof (Close Figure 4)
#pragma namespace ("\\\\.\\root\\CIMv2\\sms")
 [ SMS_Report    (TRUE),
  SMS_Group_Name ("Current User Desktop"),
  SMS_Class_ID   ("MICROSOFT|CU_Desktop|1.0") ]
class Power_Mgmt : SMS_Class_Template
{
    [SMS_Report(TRUE),key]
        string  index;
    [SMS_Report(TRUE)]
    sint32   CurrentUserDesktop;
};
Figure 3 CurrentUserDesktop.mof (Close Figure 3)
#pragma namespace(“\\\\.\\root\\CIMv2”)
// Registry property provider
instance of __Win32Provider as $PropProv
{
    Name    =”RegPropProv” ;
    ClsID   = “{72967901-68EC-11d0-B729-00AA0062CBB7}”;
    ImpersonationLevel = 1;
    PerUserInitialization = “FALSE”;
};
instance of __PropertyProviderRegistration
{
    Provider       =$PropProv;
    SupportsPut    =TRUE;
    SupportsGet    =TRUE;
};
[DYNPROPS]
class CU_Desktop
{
    [key]
    string  index = “current”;
    sint32 CurrentUserDesktop;
};
[DYNPROPS]
instance of CU_Desktop
{
     [PropertyContext(“local|HKEY_CURRENT_USER\\Control Panel\\Desktop|Wallpaper”),
        Dynamic, Provider(“RegPropProv”)]
        CurrentUserDesktop;
};
Файлы MOF также могут получать информацию, предоставляемую поставщиками WMI, не включаемыми в системы по умолчанию. Чтобы использовать этих поставщиков, поставщик WMI должен быть распространен и установлен на клиентах, прежде чем компилировать файл MOF и расширять файл sms_def.mof.

Краткое заключение
Файлы MIF и MOF являются мощными средствами быстрого и достоверного сбора информации. Формат этих файлов предоставляет платформу для удобного представления информации для базы данных SMS без изменения таблиц. При достаточном воображении практически все может быть описано и учтено. Более того, можно избежать проблемных ситуаций, поскольку администраторы могут в целях профилактики собирать важную информацию.
Понимание файлов MIF и MOF занимает некоторое время. Однако имеются полезные материалы, которые могут помочь в изучении способов применения этих файлов. Для начала ознакомьтесь с документацией и SDK к WMI, а также с Руководством по эксплуатации Systems Management Server 2003. Если вы приложите усилия к знакомству с этими концепциями, отдача от расширения описей SMS значительно перевесит затраченные усилия.

Уэс Добри (Wes Dobry) живет неподалеку от Орландо во Флориде, где он работает консультантом и администратором сети для крупной медицинской компании. Связаться с ним можно по адресу wesdobry@wesdobry.com.


 Управление: Развертывание обновлений пользовательского ПО с помощью SMS 2003 R2
Управление Стив Рачуи (Steve Rachui)

Развертывание обновлений пользовательского ПО с помощью SMS 2003 R2
Краткий обзор:
  • Новые возможности управления обновлениями в SMS 2003 R2
  • Средство публикации пользовательских обновлений
  • Средство учета пользовательских обновлений

Когда нужно развернуть пользовательские обновления для ваших систем, например приложений для специализированного оборудования или бизнес-приложений, у вас нет преимуществ управляемого автоматического процесса, которые есть при обновлении Windows. По крайней мере, раньше не было. Теперь, благодаря Systems Management
Server (SMS) 2003 R2, вы можете использовать те же возможности управления обновлениями для развертывания собственных пользовательских обновлений. SMS 2003 R2 содержит большое число новых возможностей, включая обновление для Device Management Feature Pack, ссылки на функциональный пакет Operating System Deployment (OSD) и многие другие возможности, расширяющие контроль безопасности. Продукт содержит средство проверки для оценки уязвимости, являющееся ключом к пониманию потенциальных уязвимых мест системы и сети, таких как недостатки в конфигурации ОС, пароли пользователей, настройки IIS и SQL Server™. Кроме того, он включает в себя средство учета пользовательских обновлений (ITCU) и средство публикации пользовательских обновлений (CUPT). Об этих двух средствах и пойдет речь в этой статье, чтобы помочь вам развертывать пользовательские обновления легко и эффективно.

Средство публикации пользовательских обновлений
До установки и начала использования SMS 2003 R2 должен быть установлен пакет обновления 2 (SP2) для SMS 2003 для всей иерархии, включая клиентов. Для использования CUPT необходимо обновить Microsoft® Management Console (MMC) до версии 3.0. Не обязательно устанавливать средство CUPT на сервер узла SMS, но оно должно быть установлено по крайней мере на Windows® XP, также потребуется SQL Server 2005 для хранения базы данных; если SQL Server 2005 недоступен, то необходимо установить SQL Server Express Edition. CUPT – это ключ к представлению и управлению пользовательскими обновлениями в системе SMS, кроме того, CUPT дает возможность проверить созданные каталоги перед публикацией их в SMS.
Пользовательские обновления бывают двух видов – обновления, поставляемые сторонними производителями для своих продуктов, и обновления, созданные внутри компании, которые уникальны для конкретной среды. CUPT позволяет управлять обновлениями обоих типов. Начнем с более простого варианта пользовательских обновлений, предоставленных сторонним производителем. На момент написания статьи три компании производят каталоги обновления, которые могут быть использованы для поиска и распространения соответствующих исправлений с помощью SMS – Adobe, 1e и Citrix. Можно узнать об участвующих компаниях, выбирая каталоги пользовательских обновлений партнеров, как показано на рис. 1.
Рис. 1 CUPT в действии
Рис. 1 CUPT в действии
Использование поставляемых партнерами обновлений заключается в простой загрузке каталогов и добавления их на SMS. Сначала загружаются нужные обновления, а затем выбирается соответствующий пункт меню «Действие» для импорта обновлений. Мастер запрашивает путь к только что загруженному CAB-файлу. После завершения работы мастера новые обновления будут доступны в CUPT для дальнейшей настройки и публикации на сервере узла SMS. Тем не менее, следует обратить внимание, что каждое нужное обновление должно быть помечено как публикуемое. Если обновление не помечено, то оно не будет включено в запрос на публикацию. Можно публиковать несколько обновлений одновременно, как показано на рис. 2. Следует обратить внимание, что для публикации обновления должен стоять флажок в крайнем правом столбце.
Рис. 2 Установка флажка для публикации
Рис. 2 Установка флажка для публикации
При необходимости возможна дальнейшая настройка каждого загруженного обновления. Для этого достаточно выбрать обновление и выбрать «Правка». Тем не менее, при изменении обновления следует соблюдать осторожность, так как неподходящая настройка может привести к неожиданным и неудовлетворительным результатам.
После того, как флажки для обновлений установлены, наступает время их опубликовать. Это может быть сделано либо публикацией внешнего CAB-файла для использования позднее, либо синхронизацией выбранных обновлений с базой данных узла SMS для немедленного использования. В случае синхронизации с базой данных узла SMS потребуется предоставить конфигурационные сведения, такие как имя сервера узла и путь к исходному файлу пакета (см. рис. 3).
Рис. 3 Сведения о синхронизации
Рис. 3 Сведения о синхронизации
Найти этот экран можно, выбрав узел «Пользовательские обновления» и затем «Параметры» из меню «Действие». После предоставления средству публикации пользовательских обновлений имени сервера доступного узла и пути к исходному каталогу код и состояние узла будут обновлены.
После установки параметров синхронизации CUPT готово к синхронизации с сервером узла SMS. Чтобы осуществить синхронизацию, следует выбрать пункт публикации обновления из меню «Действие». Это приведет к запуску мастера публикации. В случае публикации обновлений в базу данных SMS для немедленного использования следует убедиться, что установлен параметр синхронизации с базой данных узла SMS. К счастью, этот шаг иллюстрирован: этот пункт будет серым, если параметры синхронизации не были настроены.
После завершения работы мастера пользовательские обновления доступны для работы из административной консоли SMS. Запуск мастера распространения обновлений ПО предоставляет возможность работы с любыми доступными пользовательскими обновлениями.
Теперь, когда вы познакомились с процессом развертывания и использования предоставленных поставщиком обновлений для продуктов сторонних производителей, перейдем к пользовательским обновлениям для поставляемого ПО, к которому нет предварительно упакованных обновлений. Тут средство CUPT особенно полезно. CUPT позволяет создавать пользовательские обновления вместе с полным набором критериев для практически любой ситуации.
Создать пользовательское обновление несложно, но это требует понимания администратором того, как исправлять ПО, какой критерий использовать для определения, применимо ли исправление, и какие целевые правила должны быть использованы при обновлении. Целевые правила определяются отдельно от процесса создания обновления. Они доступны через параметр «Управление правилами» из меню «Действие».
Создание пользовательского обновления начинается с выбора элемента «Создать обновление» из меню «Действие», приводящего к вызову мастера, в котором нужно будет указать детали пользовательского обновления. Подробное обсуждение создания пользовательского обновления выходит за рамки этой статьи, но для понимания, что требуется выбрать в каждом поле при создании собственного обновления, полезно будет посмотреть свойства импортированного обновления стороннего производителя. Свойства настроенного обновления от стороннего производителя показаны на рис. 4.
Рис. 4 Свойства обновления от стороннего производителя
Рис. 4 Свойства обновления от стороннего производителя
Используя процесс создания пользовательского обновления, можно пойти дальше обновлений и настраивать программное обеспечение для распространения в системах клиентов. Хотя это будет работать, важно отметить, что этот подход использовать не рекомендуется, и средство CUPT для этого не предназначено.

Средство учета пользовательских обновлений
Средство учета пользовательских обновлений (ITCU) – новое средство учета, работающее с каталогами пользовательских обновлений. Как и средства поиска до него, ITCU создает пользовательские коллекции, пакеты и объявления, которые используются для развертывания средств поиска для клиентов SMS в корпорации. Также как и предыдущие средства поиска, ITCU получит каталог, в данном случае каталог пользовательских обновлений, из доступной точки распространения SMS, произведет поиск, основываясь на данных каталога, поместит результаты поиска в инструментарий управления Windows (WMI) и сообщит результаты через реестр оборудования. Основная разница в процессе поиска в используемом каталоге.
С появлением SMS 2003 R2 к существующему арсеналу безопасности SMS добавляется мощное средство. Никогда раньше администраторы не могли использовать существующую инфраструктуру SMS для исправления пользовательских приложений и приложений сторонних производителей. Для администратора SMS R2 – желанное добавление к управлению исправлениями.
Теперь в вашем распоряжении два средства для работы с обновлениями ПО не от корпорации Майкрософт. Управляемость и удобство, предоставляемые средствами CUPT и ITCU, обеспечат выполнение пользовательских обновлений так же гладко, как и обновлений Windows, которыми вы уже пользуетесь.
Материалы по управлению обновлениями
  • TechNet: Управление обновлениями
  • Веб-презентация: IT's Showtime - SMS 2003 R2
  • Десять принципов Microsoft Patch Management

Стив Рачуи (Steve Rachui) – инженер по улучшению поддержки управляемости в группе службы поддержки продуктов корпорации Майкрософт. Он занимался поддержкой SMS начиная с версии 1.2. Связаться со Стивом можно по адресу steverac@microsoft.com.


 От редактора: Мы можем ошибаться...
От редактора
Мы можем ошибаться...

ОДНИМ ИЗ ГЛАВНЫХ ОТЛИЧИЙ между печатью и всемирной паутиной является то, что если что-то напечатано, то это навсегда. Когда вы размещаете какой-нибудь лакомый кусочек информации во всемирной сети, и затем хотите обновить, вы всего лишь заходите и изменяете то, что необходимо изменить. Ничего не поделаешь.
С печатью дело обстоит иначе. После того как мы отправили что-нибудь для печати, ничего не возвращается. Выпускается более ста тысяч копий, и что бы мы ни разместили на страницах, это будет находиться в вашей библиотеке до конца времен (или до наступления следующего дня переиздания). Кроме того, печать от месяца к месяцу дает нам естественное продвижение, и вам известно, что новейшее издание получит самые свежие новости и статьи.
Теперь мы целиком размещаем журналы в сети после их опубликования, и это создает новую проблему. С точки зрения пользователя, выполняющего поиск в сети, все содержимое, находящийся на нашем веб-узле, появляется одновременно. Поэтому как вы узнаете, ищете ли вы по самому современному руководству?
Для решения этой проблемы несколько лет назад мы сформулировали политику коррекции, которая однозначно улучшает нашу печатную продукцию с нашей возможностью добраться до читателей в интерактивном режиме. В журнале TechNet Magazine corrections page вы найдете полностью раскрытые публикации каждого изменения последующего опубликования, которое мы вносим в наши статьи. Мы отмечаем одну из пяти причин обновления статьи: техническая, от редактора, новая информация, устарелая и безопасность.
Например, в статье «Способы упрощения создания настольных изображений», которую мы опубликовали в мае 2006 г., упоминается сервисная программа, называемая CNIC, которая до сих пор была недоступна. Когда CNIC стала доступной, мы добавили обновление на страницу поправок и обновление редактора в статью опубликованную в сети. Щелкнув ссылку обновления редактора, вы будете перенаправлены прямо к новой информации.
Как можно видеть, несмотря на то, что каждое печатное издание журнала TechNet Magazine ежемесячно заменяется новой, наша политика внесения изменений помогает гарантировать, что статьи останутся достоверными долгое время. -ДЖОШУА ТРУПИН (JOSHUA TRUPIN)

Мы хотели бы поблагодарить следующих технических специалистов по продуктам корпорации Майкрософт: Луиса Ботера, Дерека дель Коние, Джона Дойла, Дэвида Фельдмана, Скотта Хинсли, Йеспера Йонанссона, Брайана Мора, Майкла Марголо, Джона Орефиса, Марка Руссиновича, Мэтта Стила, Фергуса Стюарта, Джейсона Столярчика, Джима Трухера и Алана фон Велтина.


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

Синхронизация файлов и каталогов
Allway Sync
allwaysync.com

Независимо от вашей специализации в области информационных технологий, скорее всего, вы тратите много времени на перемещение файлов и каталогов из одного места а другое — с настольного компьютера на накопитель USB или между серверами в сети. Часто очень важна синхронизация этих каталогов, чтобы избежать создания ненужных дубликатов и работать с последними версиями файлов. Иногда необходима синхронизация файлов и каталогов на множестве компьютеров, например, при развертывании статических файлов XML или HTML на нескольких веб-серверах. Программа Allway Sync компании Usov Lab является полезным инструментов для выполнения таких задач.
Allway Sync предоставляет подлинную многостороннюю синхронизацию, от однонаправленной репликации файлов и каталогов до двунаправленной синхронизации множества каталогов. Приложение позволяет не только выполнять синхронизацию локальных дисков и сетевых ресурсов, оно также поддерживает автоматическую синхронизацию на съемных устройствах, таких как накопители USB и перезаписываемые оптические диски. Можно установить автоматический запуск приложения Allway Sync при подключении устройства к компьютеру.
Другие варианты автоматического запуска для синхронизации включают запуск при обнаружении изменения файлов, при входе и выходе из системы, при запуске программы Allway Sync и через определенное время. Можно даже установить синхронизацию в качестве запланированной задачи через графический интерфейс пользователя приложения.
Синхронизация файлов и папок с помощью программы Allway Sync
Синхронизация файлов и папок с помощью программы Allway Sync
Все изменения и удаления файлов отслеживаются в локальной базе данных приложения, программа Allway Sync предоставляет множество возможностей управления версиями измененных файлов и удаления конфликтующих файлов, включая безвозвратное удаление элементов, перемещение в корзину или указанную папку.
Для каждого задания можно указать несколько включений или фильтров включений для получения необходимых файлов и игнорирования ненужных. Можно настроить действия программы Allway Sync при появлении предупреждений или возникновении ошибок, а также определить различные действия для каждого типа предупреждений или ошибок. Например, можно выбрать автоматический повтор копирования при возникновении ошибки и настроить не только количество автоматических попыток, но и временную задержку между ними, чтобы учесть случаи сетевых задержек и кратковременных проблем подключения.
Можно настроить уровень подробности ведения журнала приложения для обеспечения получения максимальной информации о заданиях. Параметры приложения можно импортировать и экспортировать в формате XML, что упрощает их резервное копирование и перенос на другой компьютер. И наконец, интересной возможностью для любопытных пользователей является простое в использовании окно статистики (в меню «Help» (Справка)). Это удобное средство позволяет выполнять синхронизацию моментально и вполне доступно.
Цена: бесплатно для личного использования. 29,99 долларов США для коммерческого использования.

Составление карты сети и наблюдение за ней
LANState Pro
10-strike.com/lanstate

Быстрый доступ к сведениям о состоянии и доступности ресурсов вашей сети является жизненно важным для обеспечения упреждающих действий специалистов по эксплуатации информационно-технической инфраструктуры. При возникновении проблемы вам необходимо знать об этом первым. Удобное средство отображения карты и наблюдения за сетью LANState Pro компании 10-Strike Software обеспечивает быструю визуализацию и возможности управления локальной сетью для сетей на основе Windows®.
При запуске приложения для наблюдения за сетью можно запустить мастер Network Mapping Wizard (Мастер картирования сети), позволяющий выполнить поиск подходящих узлов в сетевом окружении или диапазоне IP-адресов. При желании можно добавить узлы вручную. После создания карты сети программа LANState автоматически запускает настроенные проверки состояния, такие как проверка порта TCP или проверка ICMP по протоколу ping. Отвечающие на запросы узлы отмечаются цветом, а не отвечающие - затеняются. Затем можно упорядочить карту в логические группы в соответствии с конфигурацией, изменить любые отображаемые объекты и добавить необходимые описания.
Создание логических групп сети с помощью программы LANState Pro
Создание логических групп сети с помощью программы LANState Pro
Инструменты рисования и правки обладают незначительной детализацией, но после завершения создания карты ее можно сохранить в файл, и создавать ее заново не потребуется. Помимо проверок порта TCP и ICMP по протоколу ping, программу LANState Pro можно настроить на проверку наличия файла или папки, размера файла и свободного пространства на удаленном узле с настраиваемыми интервалом и тайм-аутом. При щелчке узла правой кнопкой мыши появляется контекстное меню, позволяющее получить дополнительную системную информацию об удаленном узле, проследить маршрут, отправить запрос, выполнить проверку по умолчанию и отправить сетевое сообщение.
В представлении системной информации показано все, от MAC-адресов сетевых адаптеров и связанных IP-адресов до сетевых папок общего доступа, служб и локальных учетных записей. Для получения большей части информации на уровне операционной системы необходимы соответствующие разрешения и открытые порты на удаленной системе, но значительную часть важной информации можно получить с помощью вызовов RPC. Наконец, при наличии таких разрешений также можно отправлять удаленным узлам сигналы удаленного включения и выключения.
Цена: 249,95 долларов США за лицензию для одного пользователя.
Создание сценариев командной строки
Обзор книги
www.syngress.com

Интерактивные мастера и программы настройки с графическим интерфейсом могут значительно упростить выполнение сложных задач. Но для вас, как специалиста по информационным технологиям, эти интерфейсы могут замедлить работу, к тому же они не всегда обеспечивают достаточную детализацию или управление выполняемой задачи. К счастью, необходимый уровень управления всегда можно получить с помощью интерфейса командной строки. Знакомство со средствами, входящими в состав Windows, и изучение настройки командной строки для упрощения выполнения административных задач могут сэкономить время, повысить эффективность и обеспечить более точное управление. Книга Павана К Бхардвая (Pawan K. Bhardwaj) How to Cheat at Windows System Administration Using Command Line Scripts (издательство Syngress Publishing, 2006) позволит в совершенстве изучить интерфейс командной строки и служебные программы операционной системы.
В этой книге описывается настройка командной оболочки, использование пакетных файлов для автоматизации и пакетной обработки, а также администрирование интерфейса командной строки для запланированных заданий. Помимо этого, в книге также рассмотрены служебные программы операционной системы Windows для управления дисками, файлами и каталогами. Кроме того, представлен обзор команд служб каталогов, таких как DSQuery и DSMod, которые в сочетании с пакетной обработкой помогут значительно сэкономить время, затрачиваемое на администрирование больших структур каталогов.
Также описываются доступные команды сетевой настройки Windows, от Netstat до Pathping, и средства удаленного подключения, такие как TFTP, RSH и RCP. И снова, использование этих средств в сочетании со знаниями автоматизации и запланированных задач, которые рассмотрены в первом разделе книги, определенно увеличит вашу производительность. В целом, хотя книга и не является исчерпывающим справочником по служебным программам Windows, она является полезным дополнением к вашему набору справочных материалов.
Цена: 39,95 долларов США, напрямую.

Проверка надежности оборудования
BurnInTest
passmark.com/products/bit.htm

Занимаетесь ли вы сборкой компьютеров на заказ, выполнением обновления компонентов оборудования для вашей клиентской базы или просто создаете новую мощную настольную систему для администрирования, важно убедиться в надежности работы компонентов до их предоставления пользователям. Программа BurnInTest компании PassMark Software выполняет именно это с помощью запуска ряда нагрузочных испытаний на указанных компонентах для проверки их надежности.
Как и все программные отбраковочные испытания, приложение осуществляет тестирование оборудования с нагрузкой выбранных системных компонентов для моделирования длительного цикла работы в короткий промежуток времени. Задачей этого является обнаружение скрытых ошибок до ввода системы или устройства в эксплуатацию. Программа BurnIn Test позволяет выполнить проверку любых компонентов, от процессоров и памяти графической платы до жестких дисков и устройств записи компакт-дисков.
Использование и настройка приложения осуществляются очень просто, что позволяет изменять рабочие циклы и параметры для тестирования каждого компонента в определенной конфигурации. После настройки тестовой конфигурации можно сохранить параметры для последующего использования, что позволяет ускорить следующее тестирование, которое может потребоваться через несколько месяцев.
Все тесты имеют настраиваемый рабочий цикл, что позволяет установить значение загрузки для каждого тестируемого компонента от 1 до 100. Например, можно выполнить тестирование математических операций процессора при загрузке в 75 процентов с одновременным тестированием системной памяти с загрузкой 90 процентов. Также можно установить завершение работы программы BurnInTest через определенное время или число рабочих циклов.
Приложение позволяет выполнять одновременное тестирование до 20 жестких дисков, дисководов и/или приводов оптических дисков, что допускает пакетное тестирование приводов до их установки в клиентских средах. Это может значительно сэкономить время при обновлении системных компонентов, поскольку можно выполнить одновременное тестирование всех новых компонентов, а не тестировать все системы по отдельности. Удобной функцией программы является проверка параметра SMART.
Версия Professional Edition поддерживает различные циклические тесты для портов USB 2.0, параллельных и последовательных портов. (Аппаратные заглушки можно приобрести в компании PassMark.) Эта версия программы BurnInTest может быть запущена с компакт-диска или накопителя USB, что увеличивает достоверность выполняемых тестов благодаря уменьшению влияния приложения на тестируемую систему.
Цена: Профессиональная версия – 49 долларов США; стандартная версия – 24 доллара США.

Грег Стин (Greg Steen) специалист по информационным технологиям, предприниматель и энтузиаст. Он находится в постоянном поиске новых инструментов и методов для облегчения работы специалистов по информационным технологиям и процесса разработки.


 SQL: вопросы и ответы: Перестройка индексов, длина очереди диска и др.
SQL: вопросы и ответы
Перестройка индексов, длина очереди диска и др.
Под редакцией Нэнси Митчелл (Nancy Michell)

В. Как перестраиваются индексы в SQL Server? Я хочу понять, почему при запуске команды DBCC DBREINDEX занимается все дисковое пространство, а если команду выполнить не удается, пространство не высвобождается. Размер базы данных 90 ГБ, размер самой большой таблицы — 70 ГБ.
Если команда DBCC DBREINDEX запускается при 10 процентах свободного пространства на диске, она использует все доступное пространство, и команду выполнить не удается. Хотя изначально размер базы данных составляет 90 ГБ, при сбое команды DBCC она разрастается до 160 ГБ, и эти лишние 70 ГБ не высвобождаются впоследствии. Мне несколько раз приходилось вручную сжимать базу данных, чтобы их вернуть.
Если же команда выполняется успешно, размер файла базы данных тоже увеличивается до 160 ГБ, но через несколько часов при автоматическом сжатии лишнее пространство высвобождается. Можно ли сократить использование дискового пространства, выполняя дефрагментацию вместо DBREINDEX? Кластеризованных индексов у меня нет, используется простой режим восстановления.
О. Если не вдаваться в подробности, индексы перестраиваются путем создания новой копии индекса и удаления предыдущей. Это означает, что в некоторый момент времени существуют две копии индекса. При создании новой копии под файл базы данных требуется столько же места, сколько и для исходного индекса, а если при перестройке выполняется сортировка, то на нее требуется еще 20 процентов от размера индекса.
Таким образом, в худшем случае при перестройке индекса требуется дополнительное дисковое пространство, в 1,2 раза превышающее размер старого индекса. Если у файла базы данных недостаточно свободного пространства, он увеличивается в ходе выполнения операции. Если автоматическое увеличение отключено или недостаточно места на дисковом томе, из-за недостатка свободного пространства перестройка может быть не выполнена.
Независимо от того, успешно была выполнена операция перестройки или нет, дополнительное дисковое пространство, выделенное под файл базы данных, не высвобождается по завершении операции. Предполагается, что это пространство будет использоваться для текущих операций базы данных.
При выполнении сжатия (будь то вручную или автоматически) практически наверняка приведет к фрагментации индекса: это обуславливается особенностью работы алгоритмов. Дополнительные сведения см. в блоге Модуль хранилищ SQL Server. Автоматическое сжатие может особенно пагубно сказаться на производительности, если под текущие операции при работе с базой данных требуется свободное пространство: можно попасть в цикл, в котором будет попеременно выполняться сжатие и расширение базы данных, что серьезно нарушит фрагментацию и снизит производительность.
Преимущество команды DBCC INDEXDEFRAG (или ALTER INDEX ... REORGANIZE в SQL Server™ 2005) в том, что для ее выполнения не требуется дополнительного свободного дискового пространства, однако она может занять больше времени, чем перестройка индекса, и породить больше записей в журналах транзакций. Все действия, связанные с командой DBCC INDEXDEFRAG, всегда полностью заносятся в журнал, независимо от того, какой режим восстановления выбран, в то время как при перестройке индекса в простом режиме восстановления выполняется неполное протоколирование. У обоих методов есть свои «за» и «против». Подробнее про них можно почитать в рекомендациях по дефрагментации индекса в SQL Server.
Но прежде чем выбирать способ борьбы с фрагментацией, подумайте, нужно ли это вообще. Эффективность будет зависеть от того, в каких операциях задействуется индекс. В некоторых случаях фрагментация никак не влияет на производительность, так что борьба с ней оказывается пустой тратой ресурсов. Все это в подробностях описывается в указанном выше документе.
Самое главное: убедитесь в том, что выбранный способ устранения фрагментации лучше всего подходит для данной среды и он действительно помогает повысить производительность выполнения запросов.

В. У меня настроено зеркальное отображение баз данных между двумя экземплярами SQL Server 2005. Приложение подключается к SQL Server через вход в сервер SQL. Создано оно при помощи ADO и собственного клиента SQL. Все данные в строке подключения и в настройках подключения правильные, сервер-партнер для обеспечения отказоустойчивости указан подходящий. На зеркальном сервере создано точно такое же имя входа, что и на основном сервере. При тестировании поведения при сбое базы данных зеркальный сервер благополучно берет на себя роль основного, и на первый взгляд кажется, что экземпляр SQL Server работает корректно. (Даже можно подключиться к зеркальному серверу с использованием имени входа Windows®.) Однако же повторно подключить приложение не удается. Возникает следующая ошибка:
Cannot open database "<db name>" requested by the login. The login failed.
Выясняется, что имя входа не связано ни с одним пользователем новой главной базы данных (изначально зеркальной). Я запускаю sp_change_users_login, чтобы синхронизовать пользователей и имена входа, и получаю сообщение о том, что было исправлено несколько пользователей, потерявших связь с учетной записью. После этого приложение подключается к новому главному серверу. Я несколько раз проверял работу при сбое и каждый раз сталкивался с таким поведением: терялась связь между пользователем и именем входа.
Есть ли способ настроить зеркальное отображение так, чтобы подобная проблема не возникала?
О. Да. Проблема возникает из-за того, что идентификаторы безопасности (SID) для имен входа на разных серверах SQL не совпадают, даже если совпадают сами имена входа. В случае с именем входа пользователя или группы для Windows или домена подобных сложностей нет, поскольку идентификаторы безопасности для этих имен входа создаются на основании идентификаторов безопасности пользователя или группы, следовательно, для данного пользователя или группы идентификатор будет одним и тем же, вне зависимости от того, к какому серверу SQL добавляется пользователь или группа.
Чтобы избежать этапа синхронизации sp_change_users_login, необходимо, чтобы не только имена входа, создаваемые на зеркальном сервере, совпадали с именами входа на главном сервере, но и совпадали присвоенные им идентификаторы безопасности. Добиться этого можно, указав идентификатор безопасности в инструкции CREATE LOGIN при создании имени входа на зеркальном сервере:
CREATE LOGIN <loginname> WITH PASSWORD = <password>,
SID = <sid for
same login on principal server>,...
Идентификаторы безопасности главного сервера можно получить при помощи представления каталога sys.sql_logins. Пример запроса, создающего фактическую инструкцию CREATE LOGIN для каждого имени входа на сервер SQL или в Windows на данном сервере показан на Рис. 1.
Figure 1 Создание инструкции CREATE LOGIN (Close Figure 1)
select 'create login [' + p.name + '] ' +
case when p.type in('U','G') then 'from windows ' else '' end +
'with ' +
case when p.type = 'S' then 'password = ' + master.sys.fn_varbintohexstr(l.password_hash) +
' hashed, ' + 'sid = ' + master.sys.fn_varbintohexstr(l.sid) + ', check_expiration = ' +
case when l.is_policy_checked > 0 then 'ON, ' else 'OFF, ' end + 'check_policy = ' +
case when l.is_expiration_checked > 0 then 'ON, ' else 'OFF, ' end +
case when l.credential_id > 0 then 'credential = ' + c.name + ', ' else '' end
else '' end +
'default_database = ' + p.default_database_name +
case when len(p.default_language_name) > 0 then ', default_language = ' + p.default_language_name else '' end
from sys.server_principals p
left join sys.sql_logins l
on p.principal_id = l.principal_id
left join sys.credentials c
on l.credential_id = c.credential_id
where p.type in('S','U','G')
and p.name <> 'sa'

В. Какой длины в среднем должна быть очередь диска? К примеру, если при конфигурации RAID 01 в сети областей хранения (SAN) 20 шпинделей, как вычислить среднюю длину очереди диска? Нужно поделить среднюю длину очереди диска на 20 или на 2?
О. Прежде чем тратить время на вычисление длины очереди диска в среде SAN, нужно узнать значение задержки диска. Хотя на самом деле это значение зависит от той величины, которую вы пытаетесь вычислить. Через минуту станет понятно, почему.
Описание этого счетчика (из служебной программы Perfmon) звучит следующим образом: «Средняя длина очереди диска — это среднее общее количество запросов на чтение и на запись, которые были поставлены в очередь для соответствующего диска в течение интервала измерения». Этот счетчик может относиться либо к физическому, либо к логическому диску, и отображаемое им значение зависит от того, как лежащее в основе него хранилище воспринимается операционной системой.
Рассмотрим ваш случай. У вас 20 шпинделей в конфигурации RAID 01, значит, они чередуются и зеркально отображаются (или зеркально отображаются и чередуются, смотря как прочитать, 01 или 10). Здесь нам важно знать, что в чередующемся наборе 10 шпинделей.
Нам не хватает важной информации: каков размер чередования, каковы объемы операций записи и какой тип ввода-вывода используется (чтение, запись, последовательный или произвольный).
Сейчас оставим это в стороне. Если счетчик «Средняя длина очереди диска» показывает значение 10, значит в данной операционной системе в дисковом массиве в очередь помещено 10 операций ввода-вывода. Теоретически, может быть по одной операции на каждый зеркальный набор в чередовании или все10 операций могут приходиться на один диск. Способа выяснить это нет.
Вот тут-то нам и понадобится та информация, которую мы упомянули. Допустим, размер чередования 64 Кбайт, объем операций записи 8 Кбайт, и будет выполнена полная цепочка последовательных операций записи. Такая ситуация является типичной для работы хранилища сервера SQL. В таком случае велика вероятность того, что восемь операций ввода-вывода придутся на первый диск, а оставшиеся две — на следующий. Таким образом, если мы попытаемся вычислить длину очереди для каждого диска, то получим 8 для первого диска, 2 для второго и 0 для остальных восьми дисков массива.
Теперь поменяем условия. Пусть размер чередования составляет 8 Кбайт, размера блока записи — 64 Кбайт, а длину очереди диска оставим прежней, 10. В таком случае каждый блок размером 64 Кбайт распределяется по 8 дискам, так что одна операция ввода-вывода приходится на 8 дисков, то есть 10 операций, помещенных в очередь, разбиваются на 80 операций записи на все 10 дисков массива. Если вычислять длину очереди для каждого диска массива, получим 8.
Однако, будем реалистами и добавим еще один уровень неопределенности в нашу задачу. В большинстве случаев для хранилища SAN подключается к серверу через один или несколько хост-адаптеров, хост-адаптеры подключаются к SAN через несколько волокон, на серверах переднего плана SAN используются несколько портов, возможно, к тому же есть какой-то переключатель волокон между сервером и SAN. Только после этого мы попадаем во внутреннюю архитектуру шин внутри SAN, и выясняем, как диски подключены к портам на серверах переднего плана.
Появление в программе Perfmon сведений о наличии какой-либо очереди может быть симптомом высокой задержки или постановки в очередь элементов в любом месте описанной архитектуры, между той точкой, в которой система измеряет длину очереди, и собственно поверхностью диска. Именно по этой причине стоит опираться на показания счетчика задержки диска, а не на значение длины очереди.

В. У меня используется репликация транзакций. Большое количество строк в таблице были изменены вручную на подписчике, и теперь при попытке издателя обновить строку, которая на подписчике больше не существует, выдаются ошибки.
Подскажите, есть ли способ в ходе репликации просто повторно инициализировать таблицу, чтобы не применять снимок целиком. Мне кажется, подойдет функция tablediff, только как она взаимодействует с репликацией?
Скажем, делает ли tablediff снимок таблицы издателя и сравнивает ли его с аналогичной таблицей подписчика? Нужно ли останавливать репликацию при использовании tablediff , чтобы гарантировать согласованность данных? О чем еще нужно помнить?
О. Прежде всего, tablediff не создает снимок в полном смысле этого слова ни для таблицы издателя, ни для таблицы подписчика. В вашем конкретном случае есть пара возможных решений.
Первый вариант — временно остановить репликацию и запустить служебную программу. Если вас беспокоит то, что пользователи в этот момент могут попытаться изменить данные, можно воспользоваться параметрами -sourcelocked и -destinationlocked — они создадут монопольную блокировку на обе таблицы на время работы служебной программы. Если такой вариант неприемлем, можно попробовать использовать параметры -rc и –ri, не останавливая репликацию. При этом служебная программа tablediff будет запущена один раз, а затем будет запускаться при обнаружении ошибок и устранять те из них, причиной которых могут быть задержки в выполнении репликации. Однако следует помнить, что во втором случае программа может обнаружить не все строки, измененные на подписчике — все зависит от задержки репликации.

Благодарим за технические консультации следующих ИТ-специалистов корпорации Майкрософт: Сунил Агарвал (Sunil Agarwal), Чэда Бойда (Chad Boyd), Дэвида Брауна (David Browne), Жиля Комо (Gilles Comeau), Эммануэля Дре (Emmanuel Dreux), Аманду Фут (Amanda Foote), Мэтта Холлингсворта (Matt Hollingsworth), Пола Местмейкера (Paul Mestemaker), Уттама Паруи (Uttam Parui), Пол Рэндэла (Paul Randal), Дениса Тая (Dennis Tighe) и Стивена Уорта (Steven Wort).


 Обзор служебных программ: Autoruns
Обзор служебных программ
Autoruns
Лэнс Уитни (Lance Whitney)
Загрузить исходный код для этой статьи: Autoruns (490KB)

На стандартном ПК под управлением Windows® при запуске загружается целый ряд элементов: файлов, драйверов, задач и служб. Велика вероятность того, что в какой-то момент возникнет необходимость просмотреть и, возможно, отключить часть из них — в целях разрешения конфликтов запуска, отслеживания вредоносных программ, попавших в список автозагрузки, сокращения времени загрузки Windows или высвобождения памяти и системных ресурсов.
Программа настройки системы (msconfig.exe) позволяет просмотреть и отключить некоторые файлы и службы, но есть еще большое количество элементов, которые она игнорирует: панели инструментов, объекты модулей поддержки обозревателя, расширения оболочки Windows Explorer. Кроме того, msconfig дает не слишком обширную информацию об объектах, загружаемых автоматически. Гораздо более удобным способом просмотра и управления ими является программа Autoruns от Sysinternals.
Программа Autoruns, разработанная Марком Руссиновичем (Mark Russinovich) и Брайсом Когсвеллом (Bryce Cogswell) — это бесплатная служебная программа, обнаруживающая все элементы списка автозагрузки компьютера под управлением Windows. Она позволяет увидеть все автоматически загружаемые элементы, скрывающиеся в папках автозагрузки, в реестре и где бы то ни было еще (см. рис. 1).
Рис. 1 Просмотр списка автозагрузки в программе Autoruns
Рис. 1 Просмотр списка автозагрузки в программе Autoruns
Autoruns отображает имя и расположение каждого элемента списка. Для файлов указывается путь к каталогу, для записей реестра — точное имя раздела. Кроме того, Autoruns указывает имя издателя и краткое описание на основании данных о версии элемента. Если дважды щелкнуть любой элемент списка, вы переходите к соответствующему каталогу или разделу реестра. Если щелкнуть правой кнопкой мыши, открывается контекстное меню, несколько расширяющее возможности. В частности, в нем есть команда Properties, открывающая стандартное окно свойств файла, содержащее полную информацию о его версии. Пункт Include Empty Locations (Включить пустые местоположения) позволяет увидеть все области, в которых могут содержаться автоматически загружаемые элементы, даже есть на данный момент в них ничего нет. Кроме того, можно выбрать другую учетную запись пользователя компьютера и посмотреть условия загрузки системы в ней.
Команда Verify позволяет проверить цифровую подпись любого элемента: при ее запуске выполняется запрос к веб-узлам, содержащим списки отзыва сертификатов и проверяется, есть ли у элемента цифровая подпись и действительна ли она. Пункт меню Hide Signed Microsoft Entries (Скрыть подписанные элементы Microsoft) позволяет убрать из списков элементы, имеющие подпись Microsoft, и все внимание обратить на элементы сторонних разработчиков.
Весь список автоматически загружаемых элементов можно экспортировать в текстовый файл: он может быть полезен, если вы планируете отключить какие-то элементы, и вам нужен снимок условий загрузки системы на момент, предшествующий настройке. Впоследствии можно будет сравнить экспортированный список с исправленной конфигурацией загрузки и выявить изменения.
Ниже приводится лишь часть категорий элементов автозагрузки, отображаемых в программе Autoruns.
Logon содержит папки автозагрузки данного пользователя и всех пользователей, а также разделы реестра Run.
Explorer содержит список расширений оболочки Explorer, панелей инструментов и элементов раздела Active setup.
Internet Explorer содержит объекты модуля поддержки обозревателя, а также панели инструментов и расширения Internet Explorer®.
LSA Providers содержит элементы локального администратора безопасности, отвечающие за проверку подлинности, уведомления и пакеты системы безопасности.
Программа Autoruns позволяет как отключить элемент, так и полностью удалить его. Интерактивный поиск помогает выяснить, какие элементы можно безболезненно отключить. При его запуске выполняется поиск веб-страниц, содержащих описание выбранного элемента или категории, и выдается совет по поводу возможности отключения автоматического запуска. При отключении элемента в программе Autoruns он перемещается в архив реестра или в резервную копию на жестком диске.
Программа Autoruns работает во всех версиях Windows, включая Windows XP 64-bit Edition и Windows Server® 2003 64-bit Edition. Программу можно загрузить на странице microsoft.com/technet/technetmag/code07.aspx.

Лэнс Уитни (Lance Whitney) — консультант по информационным технологиям, преподаватель и разработчик технической документации. За его спиной огромное число часов настройки рабочих станций и серверов Windows. Будучи журналистом, 15 лет назад он занялся изучением информационных технологий.


 Кабельщик: Параметры групповой политики беспроводной связи в Windows Vista
Кабельщик
Параметры групповой политики беспроводной связи в Windows Vista
Джозеф Дэвис (Joseph Davies)
Эта статья содержит предварительную информацию о Windows Server «Longhorn», которая может в дальнейшем измениться.

Ваша работа как администратора, возможно, стала бы чуть легче, если бы можно было централизованно настраивать и распространять параметры беспроводной сети для всех компьютеров в сети Active Directory. К счастью, Windows поддерживает специально предназначенное для этого расширение групповой политики для конфигурации компьютера. Оно
называется политиками беспроводной сети (IEEE 802.11) (Wireless Network (IEEE 802.11) Policies) и поддерживается операционными системами Windows Vista™, Windows® XP, Windows Server® 2003 и следующей версией Windows Server с кодовым именем «Longhorn».
Давайте посмотрим, как это работает на практике. Либо при присоединении к домену, либо при запуске (и после этого на постоянной основе) эти операционные системы автоматически загружают параметры беспроводного подключения этого расширения групповой политики и применяют их. Можно настраивать политики беспроводных подключений для доменного объекта групповой политики из следующего узла оснастки редактора объектов групповых политик: Конфигурация компьютера | Конфигурация Windows | Параметры безопасности | Политики беспроводной сети (IEEE 802.11).
На рис. 1 показано расположение узла политик беспроводной сети (IEEE 802.11)для домена Windows Server «Longhorn» или для домена Windows Server 2003, схема которого расширяется с помощью файлов расширения схемы 802.11Schema.ldf и 802.3Schema.ldf (описанных по адресу microsoft.com/technet/network/wifi/vista_ad_ext.mspx).
Рис. 1 Узел политик беспроводной сети (IEEE 802.11)
Рис. 1 Узел политик беспроводной сети (IEEE 802.11)
По умолчанию нет ни одной политики беспроводной сети (IEEE 802.11). Для создания новой политики щелкните правой кнопкой мыши узел политики беспроводных сетей (IEEE 802.11) в дереве консоли и затем выберите «Создать новую политику Windows XP» или «Создать новую политику Windows Vista». Можно создать только одну политику каждого типа, но каждая политика может содержать параметры для нескольких беспроводных сетей.
Параметры политики Windows XP очень похожи на описанные в статье за июль 2003 г. Тем не менее, добавлено несколько новых параметров для невещательных беспроводных сетей, методов проверки подлинности Wi-Fi Protected Access 2 (WPA2) и параметров быстрого роуминга для проверки подлинности WPA2. Для поддержки этих новых параметров на компьютере под управлением Windows XP с пакетом обновления 2 (SP2) должен быть установлен пакет обновления клиента беспроводной связи для Windows XP с пакетом обновления 2 (SP2), который можно найти по адресу support.microsoft.com/kb/917021.
Политика беспроводной связи Windows Vista содержит параметры политики, характерные для беспроводных клиентов Windows Vista и Windows Server «Longhorn». Если настроены оба типа политик беспроводной связи, то клиенты беспроводной связи Windows XP будут использовать только параметры своей политики, а клиенты беспроводной связи Windows Vista – своей. Если политика для Windows Vista не настроена, то клиенты беспроводной связи Windows Vista будут использовать параметры политики Windows XP. В этой статье описываются доступные параметры настройки политики беспроводной связи Windows Vista.
На вкладке «Общие» политики беспроводных сетей Windows Vista можно настроить имя и описание политики, определить доступность службы WLAN AutoConfig и настроить список профилей беспроводных сетей и их параметров в порядке предпочтения (см. рис. 2). Можно также экспортировать профиль в файл формата XML, если выбрать профиль и нажать на кнопку «Экспортировать». Для импорта профиля беспроводной связи из файла формата XML выберите «Импортировать» и укажите местоположение файла.
Рис. 2 Свойства политики беспроводных сетей
Рис. 2 Свойства политики беспроводных сетей
На рис. 3 показана вкладка «Сетевые разрешения» для политики беспроводных сетей Windows Vista с параметрами по умолчанию. Эта появившаяся в Windows Vista вкладка позволяет указывать имена беспроводных сетей и разрешать или запрещать доступ к ним. Например, можно создать список разрешений, содержащий имена беспроводных сетей, также известные как Service Set Identifiers (SSID), к которым разрешено подключение клиенту беспроводной связи Windows Vista. Это полезно для сетевых администраторов, которые хотят, чтобы переносные компьютеры организации подключались к указанному набору беспроводных сетей, в который могут входить беспроводная сеть организации и поставщики услуг Интернета.
Рис. 3 Вкладка «Сетевые разрешения»
Рис. 3 Вкладка «Сетевые разрешения»
В списке запретов можно указать набор имен беспроводных сетей, к которым клиенту беспроводной связи не разрешено подключаться. Это полезно для предотвращения подключения управляемых переносных компьютеров к другим беспроводным сетям, в зоне действия которых они находятся, например, когда организация занимает этаж в здании и существуют беспроводные сети организаций с соседних этажей. Используя запрещающий список, можно также предотвратить подключение управляемых переносных компьютеров к известным незащищенным беспроводным сетям. Для создания любого из этих списков или указания отдельных беспроводных сетей для разрешения или запрещения доступа к ним нажмите кнопку «Добавить», чтобы добавить имя беспроводной сети и указать, разрешен или запрещен доступ к ней.
На вкладке «Сетевые разрешения» также расположены параметры для предупреждения подключения к одноранговым или инфраструктурным беспроводным сетям. Кроме того, можно разрешить пользователям просматривать список беспроводных сетей, подключение к которым запрещено, и дать возможность любому пользователю создавать общий профиль для всех пользователей. Общий профиль может быть использован для подключения к определенной беспроводной сети любым пользователем с учетной записью на этом компьютере. Если эта возможность отключена, то только пользователи из группы администраторов сети или группы операторов сети могут создавать общие профили беспроводного доступа.

Свойства профиля доступа к беспроводным сетям
Для управления профилем беспроводной сети из вкладки «Общие» политики беспроводной связи Windows Vista следует выбрать существующий профиль и нажать кнопку «Изменить» или «Добавить» и указать, будет ли новый профиль для одноранговой или инфраструктурной беспроводной сети.
Для создания нового профиля введите имя профиля на вкладке «Подключение» и создайте список имен беспроводных сетей, к которым применим данный профиль (см. рис. 4). Новое имя можно добавить, введя его в поле «Имена сетей» (SSID) и нажав кнопку «Добавить». Также можно указать, будет ли использующий этот профиль клиент беспроводной связи автоматически пытаться подключиться к перечисленным в профиле беспроводным сетям, оказавшись в зоне их действия (зависит от порядка предпочтения в списке профилей на вкладке «Общие» политики Windows Vista). Дополнительно можно указать, должно ли происходить автоматическое отключение от сети, если компьютер оказывается в зоне действия сети с большим приоритетом, а также указать, что беспроводные сети в данном профиле не являются вещательными (также называемыми скрытыми сетями).
Рис. 4 Вкладка «Подключение»
Рис. 4 Вкладка «Подключение»
На вкладке «Безопасность», показанной на рис. 5, можно настраивать методы проверки подлинности и шифрования для беспроводных сетей, указанных в профиле. Выбор методов шифрования зависит от выбора метода проверки подлинности. Варианты выбора показаны на рис. 6.
Figure 6 Методы безопасности (Close Figure 6)

Методы проверки подлинности
Открытая
Совместная
WPA-Personal
WPA-Enterprise
WPA2-Personal
WPA2-Enterprise
Открытая с 802.1X
Методы шифрования
Wired Equivalent Privacy (WEP)
Temporal Key Integrity Protocol (TKIP)
Advanced Encryption Standard (AES)
Рис. 5 Вкладка «Безопасность»
Рис. 5 Вкладка «Безопасность»
Если в качестве метода проверки подлинности выбраны WPA-Enterprise, WPA2-Enterprise или Открытая с 802.1X, можно также настроить метод проверки подлинности сети (тип протокола Extensible Authentication Protocol [EAP] ), режим проверки подлинности (повторная проверка подлинности пользователя, проверка подлинности компьютера, пользователя или гостя), число неудачных попыток до отказа от проверки подлинности, а также кэшировать ли пользовательские данные для последующих подключений. Последний параметр определяет, будет ли удалены из реестра пользовательские учетные данные, когда пользователь выйдет из системы. Тогда при подключении следующего пользователя будут запрошены его учетные данные (такие как имя пользователя и пароль).
Для настройки дополнительных параметров безопасности для методов проверки подлинности WPA-Enterprise, WPA2-Enterprise или Открытая с 802.1X нажмите кнопку «Дополнительно». На рис. 7 показано стандартное диалоговое окно дополнительных параметров безопасности.
Рис. 7 Диалоговое окно дополнительных параметров безопасности
Рис. 7 Диалоговое окно дополнительных параметров безопасности
В разделе IEEE 802.1X можно указать количество повторных сообщений (EAPOL)-Start протокола EAP через LAN, отправляемых при отсутствии ответа на первое сообщение EAPOL-Start, и интервал времени между повторной отправкой сообщения EAPOL-Start при отсутствии ответа на предыдущее сообщение EAPOL-Start. Можно также установить период, в котором проходящий проверку подлинности клиент не будет предпринимать никаких действий по проверке подлинности 802.1X после получения отказа от проверяющего, а также время ожидания перед повторной отправкой клиентом любых запросов 802.1X после начала сквозной проверки подлинности 802.1X.
Единый вход (SSO) позволяет настроить, в какой момент по отношению к входу пользователя происходит проверка подлинности 802.1X, и интегрировать пользовательский вход и учетные данные проверки подлинности 802.1X на сервере входа Windows. В разделе SSO расположены настройки для осуществления проверки подлинности непосредственно до или сразу после процесса входа пользователя при беспроводном подключении и для указания задержки для установления связи перед началом процесса (в секундах). Можно также указать, выдавать ли пользователю дополнительные поля ввода, если метод проверки подлинности требует введения пользователем дополнительных учетных данных, и как долго показывать эти поля, а также используют ли беспроводные сети для этого профиля отдельную виртуальную локальную сеть (VLAN) для проверки подлинности пользователя или компьютера.
В разделе быстрого роуминга можно настроить кэширование парного мастер-ключа (Pairwise Master Key, PMK) и параметры предварительной проверки подлинности. Раздел быстрого роуминга появляется только в том случае, если выбран метод проверки подлинности WPA2-Enterprise. При включенном кэшировании PMK клиенты беспроводной связи и беспроводные точки доступа кэшируют результаты проверки подлинности 802.1X. Следовательно, доступ происходит гораздо быстрее, когда клиент беспроводной связи снова обращается к беспроводной точке доступа, где он уже прошел проверку подлинности. Можно указать максимальное время хранения записи и максимальное число записей в кэше PMK. При предварительной проверке подлинности беспроводной клиент может проходить проверку подлинности 802.1X на других точках доступа в зоне действия, поддерживая подключение к текущей беспроводной точке доступа. Если клиент беспроводной связи перемещается к беспроводной точке доступа, на которой он прошел предварительную проверку подлинности, время доступа значительно уменьшается. Можно настроить максимальное число попыток предварительной проверки подлинности на беспроводной точке доступа.
Для получения дополнительных сведений о поддержке беспроводных сетей в Windows посетите веб-узел microsoft.com/wifi. Для получения дополнительных сведений о групповой политике Windows ознакомьтесь с материалами по адресу microsoft.com/gp.

Джозеф Дэвис (Joseph Davies) работает техническим писателем в корпорации Майкрософт. Он занимается преподаванием и пишет о сетях Windows с 1992 года. Дэвис написал пять книг, опубликованных издательством Microsoft Press, и ведет ежемесячную рубрику Кабельщик в TechNet.


 Windows PowerShell: Фильтрация и форматирование данных
Windows PowerShell
Фильтрация и форматирование данных
Дон Джонс (Don Jones)

Без сомнения, Windows PowerShell может возвращать огромное количество полезной информации без больших трудозатрат с вашей стороны. Например, рассмотрим простой командлет Get-WMIObject, который используется для получения списка служб на локальном компьютере. Применяемое по умолчанию представление содержит состояния, имена и режимы запуска
работающих служб и фактически представляет собой представление консоли «Службы» для командной строки. Windows PowerShell™ значительно облегчает доступ к ней.
Но для служб доступно намного больше полезной информации, чем отображается по умолчанию. Выполните следующую команду:
$s = get-wmiobject win32_service
$s[0] | gm
Первая строка команды возвращает набор всех служб (или, точнее говоря, всех экземпляров класса Win32_Service из инструментария управления Windows®, также называемого WMI), сохраняя их в переменной $s. Вторая строка выбирает первую службу из этого набора (с нулевым порядковым номером number, указанным в квадратных скобках) и направляет ее командлету Get-Member, название которого было сокращено до аббревиатуры gm. В результате выводятся все свойства и методы, доступные для этого типа данных. Было решено использовать класс Win32_Service в WMI вместо встроенного командлета Get-Service cmdlet в Windows PowerShell, поскольку WMI предоставляет действительно больше информации, чем объект контроллера служб Microsoft® .NET, в том числе свойство StartName. Это свойство сообщает имя учетной записи пользователя, под которой выполняется служба. Проверить имя одного экземпляра, например первого, можно следующим образом:
PS C:\> $s[0].StartName
LocalSystem
Однако обращение к службам по порядковому номеру в наборе имеет мало смысла, поскольку службы не упорядочены никаким определенным образом. (Обычно они перечисляются в алфавитном порядке, но не всегда.) С точки зрения управления наиболее интересен, вероятно, список всех служб и учетных записей, используемых ими для входа в систему. Он полезен, например, при аудите соответствия нормативным требованиям. Поэтому прервемся на минуту и посмотрим, что предоставляет WMI по умолчанию. Будем использовать самый короткий псевдоним Get-WMIObject - gwmi (см. Рис. 1).
Figure 1 Использование gwmi (Close Figure 1)
PS C:\> gwmi win32_service

ExitCode  : 0
Name      : AcrSch2Svc
ProcessId : 1712
StartMode : Auto
State     : Running
Status    : OK

ExitCode  : 1077
Name      : Adobe LM Service
ProcessId : 0
StartMode : Manual
State     : Stopped
Status    : OK
Конечно, это всего лишь пример, но из него видно, что вывод недостаточно велик для управленческого отчета. Требуется знать имя службы и свойство StartName, представляющее собой учетную запись, под которой выполняется служба. Кроме того, хотелось бы видеть отчет в более удобном для чтения виде, чем подобный список. В этом могут помочь командлеты Windows PowerShell для сложного форматирования и фильтрации данных.

Получение нужных данных
Начнем фильтровать данные Get-WMIObject таким образом, чтобы отобразились нужные свойства. Для этого лучше всего использовать командлет Windows PowerShell Select-Object, имеющий простой псевдоним select. Select предназначен для приема набора объектов, например возвращенного Get-WMIObject, и отображения только нужных свойств этих объектов. Это означает, что можно направить выходные данные gwmi командлету select и указать два нужных свойства. На Рис. 2 показан результат вывода, содержащий свойства Name и StartName и представленный в виде таблицы.
Рис. 2 Просмотр только свойств Name и StartName в виде таблицы
Рис. 2 Просмотр только свойств Name и StartName в виде таблицы
Однако для аудита соответствия нормативным требованиям в этом отчете содержится слишком много информации. Некоторые службы отключены, и вряд ли читающим отчет будет интересно, какие учетные записи эти службы теоретически могли бы использовать. Поэтому следует отфильтровать все службы, тип запуска которых - «Отключено»; это свойство StartMode класса Win32_Service.
Windows PowerShell выполняет фильтрацию объектов с помощью командлета Where-Object, имеющего сокращенный псевдоним where. Командлет where принимает набор входных объектов и пропускает каждый из них через блок сценария для определения того, какие из объектов будут присутствовать в выходных данных командлета, на основе набора определенных критериев. Каждый объект, соответствующий критериям, в результате сравнения получает значение True (истина) и включается в выходные данные; объекты, получающие значение False (ложь), в выходные данные не включаются.
Нам нужны объекты, для которых свойство StartMode имеет значение «Отключено». В терминах Windows PowerShell это выглядит так:
$object.StartMode –eq “Disabled”
Конечно, $object – это только пример. На самом деле мы не пишем сценарий, поэтому переменной $object не существует. Однако в блоке сценария, используемом командлетом where, используется специальная переменная $_, представляющая объект, который обрабатывается командлетом в настоящий момент. Блок сценария для командлета where может выглядеть следующим образом:
$_.StartMode –eq “Disabled”
Проверить его довольно просто:
PS C:\> gwmi win32_service | where
{$_.StartMode -eq “Disabled”}

ExitCode  : 1077
Name      : Alerter
ProcessId : 0
StartMode : Disabled
State     : Stopped
Status    : OK
Выходные данные этой быстрой проверки снова отображаются в виде списка используемого по умолчанию стиля. И для экономии места сюда включена только одна служба. Можно заметить, что мы получили обратный результат. Он содержит все отключенные службы вместо того, чтобы исключить их. Причина это в том, что блок сценария написан наоборот: необходимо включить все службы, для которых свойство StartMode имеет значение, не равное «Отключено», как показано в следующей версии примера:
PS C:\> gwmi win32_service | where
{$_.StartMode -ne “Disabled”}

ExitCode  : 0
Name      : AcrSch2Svc
ProcessId : 1712
StartMode : Auto
State     : Running
Status    : OK
Теперь все верно. В выходных данных содержатся только нужные службы, и можно снова направить результат командлету select, чтобы выбрать только нужные свойства:
gwmi win32_service | where {$_.StartMode -ne “Disabled”} | select name,startname
Подобная работа с пересылкой данных от одного командлета к другому, а затем к следующему иллюстрирует действительные возможности Windows PowerShell. Сценарий по-прежнему не закончен, хотя нам удалось отфильтровать большое количество данных и получить только нужные.

Верное отображение
Необходимо помнить, что выходные данные командлета select представляют собой набор объектов. При получении отформатированной таблицы с помощью Windows PowerShell эти объекты отображаются с помощью PowerShell.exe. Другими словами, Windows PowerShell знает, что человек не может видеть объекты, и представляет их в виде текста. В этом случае объекты визуализуются в виде таблицы, содержащей столбец для каждого свойства, как показано на Рис. 2.
Этого может быть достаточно для целей аудита. Но может оказаться и иначе. У всех разные нужды, и Windows PowerShell не знает, что именно нужно вам. Зато она предоставляет средства для форматирования выходных данных наилучшим для вас образом. Четыре встроенных командлета — Format-List, Format-Custom, Format-Table и Format-Wide — могут принимать набор объектов (например набор, возвращенный командлетом select) и форматировать эти объекты различными способами. Format-Table представляет собой уже используемый Windows PowerShell командлет для форматирования выходных данных командлета select. Для отображения в другом виде воспользуемся командлетом Format-List:
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
select name,startname | format-list
Результат будет выглядеть примерно так:
name      : AcrSch2Svc
startname : LocalSystem

name      : Adobe LM Service
startname : LocalSystem
Командлет Format-Wide выводит список из нескольких столбцов, по умолчанию содержащих первое свойство каждого объекта. Рассмотрим, например, такую строку:
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
 select name,startname | format-wide
Выдается список имен служб, а нам нужно другое. В выходных данных отсутствует свойство StartName (см. Рис. 3), которое является важной частью сведений, нужных нам для аудиторского отчета.
Рис. 3 В выходных данных, отображенных с помощью командлета Format-Wide, отсутствует ключевая информация – свойство StartName
Рис. 3 В выходных данных, отображенных с помощью командлета Format-Wide, отсутствует ключевая информация – свойство StartName
Поскольку мы работаем только с двумя свойствами, вероятно, командлет Format-Table или Format-List подойдет. Но вряд ли аудитору понравится читать данные с экрана. Скорее всего, вариант данных в некотором файле будет удобнее.

Экспорт данных
Каким образом представить данные аудитору? Может оказаться достаточным вывести список служб и имен учетных записей в файл CSV (файл значений, разделенных запятой), поскольку такой файл можно легко открыть в Microsoft Excel®. Для создания файла CSV просто передайте выходные данные командлету Windows PowerShell Export-CSV:
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
select name,startname | export-csv c:\services.csv
Конечно, в современном мире файлы CSV выглядят несколько устаревшими. Возможно, аудитор предпочтет увидеть данные в качестве веб-страницы на сервере интрасети. Для этого сначала преобразуйте выходные данные в HTML с помощью командлета ConvertTo-HTML:
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
select name,startname | convertto-html
Необработанные данные в формате HTML сложно просматривать, поэтому их необходимо записать в файл:
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
select name,startname | convertto-html | out-file c:\services.html
В результате, как показано на Рис. 4, получается отформатированная страница HTML, которую можно поместить на веб-сервер без изменений.
Рис. 4 Отображение выходных данных в виде отформатированной страницы HTML
Рис. 4 Отображение выходных данных в виде отформатированной страницы HTML

Только (важные) факты
Windows PowerShell предоставляет быстрый доступ к широкому диапазону данных управления. Однако в необработанном виде эти данные не всегда полезны в деловом смысле.
Фильтруя данные (с помощью командлета where), выбирая нужные свойства объектов (с помощью командлета select) и применяя подходящий параметр форматирования (например Format-Table или Format-List), можно быстро превратить эти данные управления в полезную информацию с наименьшими усилиями. После этого, экспортировав данные в легко распространяемый файловый формат, можно передать эту информацию с вашего компьютера и обмениваться ценными сведениями с другими работниками вашей организации.

Дон Джонс (Don Jones) занимает должность заместителя директора по проектам и услугам компании SAPIEN Technologies и является соавтором книги Windows PowerShell: TFM (издательство SAPIEN Press). Связаться с Доном можно через его веб-узел www.ScriptingAnswers.com.


 Эй, программист!: Простая работа с локальными пользователями и группами
Эй, программист!
Простая работа с локальными пользователями и группами
Сотрудники группы Microsoft Scripting Guys
Загрузить исходный код для этой статьи: HeyScriptingGuy2007_04.exe (151KB)

Как осуществляется управление дескрипторами безопасности файлов и папок?

Хотите верьте, хотите нет, но когда-то... очень давно, конечно же, программисты не были настолько умными. Мы знаем, что в это трудно поверить...что значит совсем нетрудно? И что значит не могло быть настолько давно? Пожалуй, мы бы хотели, чтобы вы знали...ну хорошо. Видимо, недавно вы видели, как одним из программистов пытался подключить новый телевизор.
Хотя этот программист и мог в свое оправдание утверждать, что установка нового телевизора - не ракеты в космос запускать, на деле все оказалось гораздо сложнее. Простая установка телевизора означает, что необходимо подключить три видеокабеля и два аудиокабеля, установить на телевизор видеомагнитофон, DVD-проигрыватель и приставку Xbox®, не говоря уже о том, что потом надо будет ввести на «универсальном» пульте управления случайный набор цифр, чтобы заставить все это работать. По сравнению с этим, вывод спутника на орбиту Марса – плевое дело.
Поразительно, но программист смог установить все эти подключения абсолютно правильно. Однако когда он попробовал все включить, ничего не заработало. С сознанием своего долга он многократно проверил все подключения. Он прочитал все руководства пользователя, проверил в Интернете наличие каких-либо дополнительных сведений. Безрезультатно. И он уже был готов принести свой проигрыватель MP3 в жертву богу электроники, как заметил, что пропустил самый важный этап – подключение кабеля абонентской приставки к настенной розетке.
Примечание. Вы можете подумать, что если подключить всю технику семьи программиста настолько сложно, вероятно, техники очень много. Действительно, этот программист согласился бы с вами. Однако каждый раз, когда в семье программиста решался вопрос о приобретении новой техники, решение принималось с результатом 2-0 не в пользу программиста. Нет, не 2-1, а именно 2-0. По-видимому, по каким-то причинам при принятии семейных решений голос отца программиста никогда не учитывался, и какие-либо подтверждения его выбора отсутствуют.
Опережу ваш следующий вопрос, да, он пытался. Но ООН всегда отказывалась посылать своих наблюдателей на выборы в дом программиста.
Конечно, сейчас мы понимаем, что программисты (вернее тот, с новым телевизором) не столько глупые, сколько наивные. Например, когда они планировали выпуск руководства по программированию Microsoft® Windows® 2000 Scripting Guide, они попросили о помощи ряд...экспертов...когда пришло время написания глав книги. Одна из глав, написание которых затянулось, была посвящена управлению локальными группами и пользователями. «Управление локальными группами и пользователями?!?», сказали эксперты. «Это даже не обсуждается! Кому нужно управление локальными группами и пользователями?»
К нашему сожалению, потом мы узнали, что управление локальными группами и пользователями необходимо абсолютно всем (возможно, это не относится к нашим собственным «экспертам»). Каждую неделю мы получали тонны сообщений электронной почты от пользователей, спрашивающих как, например, добавить пользователя в локальную группу, удалить пользователя из нее или изменить локальный пароль администратора компьютера.
Разумеется, на странице Script Center Script Repository приведен ряд примеров сценариев выполнения этих задач, но большинство этих сценариев предназначено для работы только на одном компьютере. Это недоработка: пользователям необходимо знать о том, как одновременно выполнять эти действия на нескольких компьютерах. Изменение локального пароля администратора на жалких компьютерах. Вернитесь с облаков на землю — нам необходимо сделать это на всех наших компьютерах или на всех компьютерах в нашем отделе, или на всех наших почтовых серверах, или...ну вы поняли.
Учитывая, что руководство по программированию было выпущено в 2003 году, в течение почти четырех лет нам присылали одинаковые сообщения электронной почты. Недавно один программист заметил – «Еще один читать спрашивает, как узнать имена компьютеров из таблицы программы Excel®, и затем изменить локальный пароль администратора на всех этих компьютерах». «Что же мы можем с этим сделать?»
Нам потребовалось 4 года, и мы наконец-то поняли. На рис. 1 показано решение.
Figure 1 Наконец мы выяснили это (Close Figure 1)
On Error Resume Next

Set objExcel = CreateObject(“Excel.Application”)
Set objWorkbook = objExcel.Workbooks.Open(“C:\Scripts\Test.xls”)
objExcel.Visible = True

i = 2

Do Until objExcel.Cells(i, 1).Value = “”
    strComputer = objExcel.Cells(i, 1).Value
    Set objUser = GetObject(“WinNT://” & strComputer & “/Administrator”)
    If Err = 0 Then
         objUser.SetPassword “egTY634!alK2”
         objExcel.Cells(i, 2).Value = Now
    End If
    Err.Clear
    i = i + 1
Loop
Примечание. Как вы видите, написание этого сценария заняло года не потому, что это было настолько сложно, а потому, что все это время мы были заняты всеми остальными делами. Поэтому вы непременно посещаете все празднования программистами нового года, несмотря на то, что никогда не знаете, или знаете, когда произойдет следующий праздник.
Здесь приведен сценарий получения имен компьютеров из электронной таблицы и изменения локальные пароли администратора на всех этих компьютерах. Чтобы выполнить эти невероятные вещи, мы начали с простого: предположили, что имеется небольшая и простая электронная таблица, например такая, как изображена на рис. 2. (Если у вас не такая таблица, создайте именно такую прямо сейчас.)
Рис. 2 Необходимый список компьютеров
Рис. 2 Необходимый список компьютеров
Как видите, здесь нет ничего сложного. В столбце 1 (столбец A) мы перечислили имена всех компьютеров, пороли для которых необходимо изменить. В столбце 2 (столбец B) мы просто указали дату и время последнего изменения пароля администратора на каждом компьютере. Это упрощает ваше отслеживание синхронизации паролей администратора.
Что касается самого сценария, какие-либо действия при формулировке «On Error Resume Next» отсутствуют. Обычно мы не утруждаем себя включением в наши сценарии обработки ошибок. Не потому, что мы против самой обработки ошибок, скорее потому, что мы стремимся сделать наши сценарии максимально короткими и простыми для выполнения. Однако в этом случае формулировка On Error Resume Next является важной. Посудите сами, наш сценарий будет пытаться подключиться к множеству различных компьютеров. Что произойдет при включении одного из этих компьютеров? Ну, при наличии обработки ошибок ничего не произойдет. Конечно, произойдет ошибка, но сценарий сможет проигнорировать ее и продолжить свое выполнение. Без обработки ошибок вы столкнетесь с почти такими же трудностями, с какими столкнулся программист при первом включении нового телевизора: ничего не происходит.
Далее, мы использовали следующий блок кода для создания экземпляра объекта Excel.Application, отображения этого экземпляра Excel на экране и открытия электронной таблицы C:\Scripts\Test.xls:
Set objExcel = CreateObject _
    (“Excel.Application”)
Set objWorkbook = objExcel.Workbooks.Open _
    (“C:\Scripts\Test.xls”)
objExcel.Visible = True
И последняя, но, конечно же, не менее важная часть, переменной счетчика i мы присвоили значение 2. Эта переменная будет использоваться для отслеживания текущей строки таблицы.
Примечание. Итак, почему переменной i было присвоено значение 2? Это просто. Если вы внимательно взгляните на электронную таблицу, вы заметите, что данные начинаются со строки 2. Строка 1 - это просто заголовок.
Видите? Может быть, мы и не специалисты по подключению кабелей YPbPr1, но о создании сценариев мы точно что-то знаем.
Ну, во всяком случае иногда.
Теперь можно начать работу. Во-первых, мы настроили цикл Do Until, выполняющийся до появления пустой ячейки в столбце 1. Да, то есть что бы вы ни делали, в столбце 1 не должно быть пустых строк. Если при выполнении сценария будет обнаружена пустая строка, будет предполагаться завершение данных, и цикл (и сценарий тоже) завершит свою работу. И пока не будет найден способ обойти это, гораздо проще не использовать пустые строки в таблице.
Внутри цикла прежде всего значение ячейки строки i столбца 1 присваивается переменной под названием strComputer. (Помните, что при первом выполнении цикла переменной i присвоено значение 2; поэтому работа будет начата со значения ячейки строки 2, столбца 1.) Затем эта строка кода будет использована для создания ссылки (objUser) на локальную учетную запись администратора компьютера, указанного в переменной variable strComputer:
Set objUser = GetObject(“WinNT://” & _
    strComputer & “/Administrator”)
При возникновении каких-либо ошибок сценария, работа завершится прямо здесь. Например, предположите, что возникли проблемы с сетью, компьютер был выключен или один из программистов неправильно подключил свой проигрыватель DVD, и вся западная часть США осталась без электричества. Если что-либо из этого произойдет, подключиться к компьютеру будет невозможно. Поэтому необходимо немедленно проверить значение объекта VBScript Err:
If Err = 0 Then
Если значение объекта Err – 0, можно без каких-либо проблем установить подключение к компьютеру (и к учетной записи администратора). Если значение объекта Err какое-либо другое, это означает только одно: произойдет сбой подключения. В этом случае мы даже не будем пытаться изменить пароль компьютера, нет необходимости говорить, что если невозможно установить подключение, мы не сможет изменить пароль.
Предположим, что все идет хорошо и проблем не возникло, будут выполнены две следующие строки кода:
objUser.SetPassword “egTY634!alK2”
objExcel.Cells(i, 2).Value = Now
В строке 1 мы использовали метод SetPassword для назначения локальной учетной записи администратора нового пароля (например, TY634!alK2). (Да, мы знаем, что вы не будете использовать имя вашего ребенка в качестве пароля.) В строке 2 мы записали текущую дату и время (с помощью функции Now VBScript) в ячейку строки i столбца 2. Обратите внимание, что столбец Password Changed обновляется только при возможности подключения к удаленному компьютеру и изменения пароля. При невозможности установления подключения к компьютеру соответствующее поле Password Changed никогда не будет обновлено, таким образом указывается успешность выполнения операций.
Что все это значит? Это означает, что после первого выполнения цикла наша электронная таблица будет выглядеть примерно так, как показано на рис. 3.
Рис. 3 Список компьютеров после изменения первого пароля
Рис. 3 Список компьютеров после изменения первого пароля
Так много для первого компьютера. Перед продолжением нам необходимо дать некоторые пояснения.
Err.Clear
i = i + 1
Обе эти максимально короткие строки кода очень важны. (Будто бы программисты станут писать маловажные строки кода!) В первой строке для объекта Err восстанавливается значение 0. Если ошибок не произошло, это излишне, объект Err и так будет иметь значение 0. Если произошла ошибка, значение объекта 0 будет каким-либо другим. В этом случае необходимо восстановить значение объекта Err вручную. Зачем это необходимо сделать? Потому что это объект Error (Ошибка): он отслеживает только ошибки, а не успешное выполнение. Например, предположим, что на компьютере возникла проблема и установить подключение не удалось. Пусть в результате этого для объекта Error было установлено значение 99.
Далее, предположим, что выполнение цикла продолжено и подключение к компьютеру 2 было успешно установлено. Каким, по вашему мнению, будет значение объекта Err? Правильно, нравится вам это или нет, значение объекта Err будет по-прежнему равно 99. Это объясняется тем, что значение объекта Err изменяется только при возникновении ошибок, однако при отсутствии ошибок значение этого объекта сохраняется неопределенно долго.
Имеет ли это для нас значение? Ну, должно иметь значение. Ведь технически пароль на компьютере не изменяется при успешной установке подключения; он изменяется, только если для объекта Err установлено значение 0. И...подождите, мы сходим за калькулятором...да, вы правы, 99 не равно 0 (конечно же, за исключением выборов в семье программиста, где 99 голосов отца программиста означают 0). Это является важным для нас, поскольку даже при установке подключения к компьютеру 2 значение объекта Err не равно 0. А поскольку объект Err не равен 0, мы даже не будем пытаться изменить локальный пароль администратора.
Другими словами, при всех изменениях значения объекта Err необходимо восстановить значение 0; в противном случае, начиная с этого момента сценарий будет считать, что произошла ошибка. Как восстановить для объекта Err значение 0? Верно, просто вызвать процедуру Err.Clear.
Далее, значение i увеличивается на 1. Почему? При первом выполнении цикла переменная i имела значение 2, поскольку необходимо было установить подключение к компьютеру, указанному в ячейке строки 2 столбца 1. При последующем выполнении цикла необходимо установить подключение к компьютеру, указанному в ячейке строки 3 столбца 1. А как всем известно, 2 + 1 = 3. (Хорошо, что калькулятор по-прежнему работает, не правда ли?) Только потом выполнение цикла продолжается, и процесс повторяется для следующего компьютера в электронной таблице.
Здорово, но...сейчас мы не настолько наивные, какими привыкли быть... мы хорошо понимаем, что только один этот сценарий не является ответом на полученное сообщение электронной почты. «Пример с программой Excel это здорово,- скажет пользователь, - но мне также необходимо изменить локальный пароль администратора на всех компьютерах в отделе или на всех компьютерах в текстовом файле. Или может быть мне необходим всплывающий список компьютеров, чтобы можно было выбрать необходимый. Или может быть на самом деле необходимо...».
Не волнуйтесь. Ваше желание – приказ для программистов. (То есть, если вы готовы четыре года ждать исполнения вашего желания.) Оказалось, что в центре сценариев доступно множество шаблонов для компьютера, значительно упрощающих запуск сценария на нескольких компьютерах. Например, предположим, что вам необходимо изменить локальный пароль администратора на всех компьютерах в отделе. Нет проблем. На рис. 4 показано, как выглядит шаблон для запуска сценариев на всех компьютерах в отделе.
Figure 4 Запуск сценария на всех компьютерах отдела (Close Figure 4)
On Error Resume Next

Set objOU = GetObject(“LDAP://OU=Finance,dc=fabrikam,dc=com”)
objOU.Filter = Array(“Computer”)

For Each objComputer in objOU
    strComputer = objComputer.CN

    ‘
=====================================================================
    ‘ Insert your code here
    ‘
=====================================================================

    Set objComputer = GetObject(“WinNT://” & strComputer & “”)
    objComputer.Filter = Array(“User”)
    For Each objUser in objComputer
        Wscript.Echo objUser.Name
    Next

    ‘
=====================================================================
    ‘ End
    ‘
=====================================================================

Next
Видите часть шаблона, помеченную как «Вставьте сюда ваш код»? Все, что вам необходимо сделать, - удалить образец кода в этом разделе и вставить код (который можно скопировать из этой статьи) для изменения локального пароля администратора. Другими словами, замените образец кода следующим кодом:
Set objUser = GetObject(“WinNT://” & _
    strComputer & “/Administrator”)
If Err = 0 Then
    objUser.SetPassword “egTY634!alK2”
End If
Err.Clear
В этом примере не регистрируются результаты, но можно просто добавить необходимый код. Замените образец кода, затем измените строку подключения LDAP://OU=Finance,dc=fabrikam,dc=com, чтобы она указывала на один из ваших отделов, и сценарий готов к использованию.
Честно говоря, на самом деле мы разместили эти шаблоны более года назад и указали, что они станут самыми популярными материалами центра сценариев. Мы ошибались: едва ли они когда-либо использовались, хотя почти каждый день нам приходили письма пользователей с вопросами о запуске сценариев на нескольких компьютерах. Вероятно, никто не знал о существовании этих шаблонов. Но теперь вы знаете. Или, по крайней мере, будете знать, если мы скажем, где они находятся: microsoft.com/technet/scriptcenter/scripts/templates. Хм... может быть, поэтому эти шаблоны никогда и не использовались...
Теперь, когда программисты не такие наивные, какими они привыкли быть, означает ли это также то, что они не такие глупые, какими привыкли быть? Скажем так, Не так давно один программист решил потратить выходные на то, чтобы сделать некоторый ремонт дома. В понедельник он пришел на работу с разбитым большим пальцем, который постоянно кровоточил, и большим порезом на ноге.
Что, если подумать, не настолько уже и плохо. По крайней мере, для программиста.

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


 На страже безопасности: Мастер настройки безопасности
На страже безопасности
Мастер настройки безопасности
Джон Морелло (John Morello)
Эта статья содержит предварительную информацию о Windows Server «Longhorn», которая может поменяться в дальнейшем.

Эффективные и последовательные меры по обеспечению безопасности — важнейшая задача для многих организаций, особенно обладающих большим парком компьютеров и разделенных географическими и организационными границами. Если обеспечение безопасности одного сервера может быть сравнительно простой задачей для опытного администратора, безопасность десятков, сотен или
даже тысяч серверов — совсем другая задача. С годами многие организации составляют собственные требования или стандарты к безопасности серверов или совмещают руководства корпорации Майкрософт, Национального института стандартов и технологии или других внешних источников. Хотя эти документы крайне полезны, одной документации для обеспечения наилучшей работы сети организации недостаточно. Поэтому многие предпочитают придерживаться параметров по умолчанию при установке или тратить усилия и время на создание собственных сценариев и политик для укрепления безопасности.
С появлением Мастера настройки безопасности (Security Configuration Wizard — SCW) в Windows Server® 2003 с пакетом обновления 1 (SP1) корпорация Майкрософт предлагает простой и поддерживаемый метод обеспечения безопасности серверов и сокращения атакуемой поверхности на основе выполняемых ими ролей. Благодаря сочетанию преимуществ SCW и возможностей централизованного развертывания и управления групповой политикой SCW можно масштабировать до размера крупнейших предприятиях информационной отрасли. В этой колонке я покажу, как организации, работающие в области информационных технологий, могут использовать SCW и групповую политику для управления своими серверами более безопасным и согласованным способом при одновременном снижении затрат на развертывание и эксплуатационных расходов.

Что такое SCW?
SCW — это дополнительный компонент, устанавливаемый с помощью средства Установка и удаление компонентов Панели управления Windows®, доступный для всех продуктов семейства Windows Server 2003 с пакетом обновлений SP1, включая Windows Server 2003 R2. Администратор должен запустить SCW на целевом сервере и выяснить роли, которые этому серверу поручены. Затем SCW поможет администратору создать политику безопасности, которая увеличит устойчивость компьютера с помощью схемы минимизации привилегий. Другими словами, SCW помогает выбрать только те службы, приложения и порты, которые необходимы для выполнения выбранной роли; все службы, не требующиеся для этих ролей, будут отключены. Такой подход сокращает подверженную атакам поверхность целевого сервера. При запуске служб, которые не нужны для выполнения роли, назначенной серверу, вы повышаете риск атак на сервер по сети, не наращивая при этом его возможности или функциональность. Отключение этих служб снижает риск и может повысить производительность сервера.
Хотя корпорация Майкрософт внесла много преимуществ в безопасность Windows Server 2003, значительно снизив атакуемую поверхность по сравнению с предыдущими версиями Windows Server, ядро его отличается от высоко компонентизованного ядра Windows Vista™ и ожидающейся версии Windows Server с кодовым именем "Longhorn". Таким образом, при стандартной установке Windows Server 2003 оказываются включенными и работающими службы, не требующиеся для данной роли сервера. Например, служба «Диспетчер очереди печати» включена по умолчанию, но не нужна машине, которая работает исключительно как сервер базы данных.

Реализация безопасности на основе ролей
За последние несколько лет корпорация Майкрософт выпустила большое количество документации, которая помогает администраторам понять, какие службы требуются для различных ролей сервера, и готовых шаблонов для стандартных ролей, например для веб-серверов. В то же время такие руководства, как Windows Server 2003 Security Guide, трудно применить в больших средах, особенно, если в этих средах используются более сложные приложения, чем стандартно установленные IIS или SQL Server. Еще более усложняют ситуацию многочисленные развернутые на предприятии сторонние приложения, многие из которых зависят от нескольких ролей сервера и требования для приложений и служб которых не всегда достаточно объяснены.
SCW служит для решения этой проблемы, концентрируя все знания о зависимостях и достижении наилучших результатов в руководствах, включенных в мастер-помощник администратора. Например, если администратор разворачивает новое отраслевое приложение, которое требует наличия SQL Server™ и IIS, ему больше не требуется тратить время, разбираясь с руководством по безопасности или разрабатывая свой список пользовательских зависимостей. Вместо этого он может установить приложение на сервере и запустить SCW. SCW определит, какие службы работают в данный момент, и предоставит администратору список ролей, которые можно выбрать для этого сервера. В зависимости от этого выбора SCW формирует политику, которая отключит все службы, не являющиеся необходимыми, на основе таблицы ролей. Кроме того, SCW предложит способы укрепления безопасности реестра, блокировки ненужных сетевых подключений и применения эффективной политики аудита. После запуска SCW администратор может сохранить политику SCW в виде файла XML и применить ее к любым другим серверам, на которых запущено это отраслевое приложение.
Таким образом, применение SCW дает три важных преимущества по сравнению с традиционным ручным подходом к настройке безопасности Windows Server. Во-первых, он значительно снижает (если не устраняет полностью) необходимость для администратора непрерывно сверяться с документацией по программе, чтобы определить, какие службы и настройки необходимы для работы. Эти сведения встроены в состав SCW, и основанный на вопросах интерфейс упрощает для администратора поддержку необходимых тонких настроек. Далее, SCW объединяет руководства из разных областей, включая повышение надежности работы, снижение риска атак по сети, повышение устойчивости работы служб LDAP и SMB и ограничение возможностей IIS. Ранее выполнение этих задач настройки требовало наличия отдельных служебных программ, каждая из которых имела свой интерфейс и свой подход. Наконец, поскольку SCW сохраняет параметры в файле политик формата XML, его можно использовать по принципу «один раз сделал, много раз применил». Независимо от того, разворачиваете ли вы один или сто серверов для работы отраслевого приложения, одна политика SCW легко может быть применена ко всем. Это делает более согласованными параметры безопасности и снижает эксплуатационные расходы. Кроме того, упрощается откат политик.

Компоненты средства SCW
Несмотря на все преимущества и возможности, SCW - очень простое средство, состоящее из трех основных частей: интерфейса мастера, интерфейса командной строки и базы данных настройки безопасности (SCD). Администраторы малых и средних предприятий могут ограничиться работой только с интерфейсом мастера. В больших и сложных средах администраторы могут использовать интерфейс командной строки для помощи в автоматизации таких задач SCW, как преобразование политик SCW в объект групповой политики (GPO). Обычно править SCD требуется только опытным администраторам, которые хотят создать свои роли SCW.
Интерфейс мастера, показанный на рис. 1, позволяет администраторам создавать, изменять, применять и откатывать параметры безопасности целевого сервера. Он предоставляет администраторам возможность выбора в последовательном рабочем потоке, который вначале проверяет службы и параметры, затем сетевые подключения, затем политики аудита безопасности, и, наконец — параметры IIS.
Рис. 1 Интерфейс SCW
Рис. 1 Интерфейс SCW
Интерфейс командной строки SCW предоставляет три основные функции. Это дает возможность администраторам анализировать и координировать несколько серверов (локально или удаленно) и применять политики. Его можно использовать для автоматического преобразования файла XML политик SCW в объект GPO, который можно обычным образом использовать в стандартных средствах управления групповыми политиками, таких как консоль управления групповой политикой. Наконец, средство командной строки SCW, показанное на рис. 2, используется для регистрации любых новых расширений базы данных настроек безопасности.
Рис. 2 Средство командной строки мастера SCW
Рис. 2 Средство командной строки мастера SCW
SCD - это просто набор файлов формата XML, содержащих сведения о конкретных службах и параметрах, необходимых для каждой роли SCW. Эти файлы располагаются в каталоге %windir%\security\msscw\kbs. В стандартной поставке SCW идет в комплекте с набором основных ролей Windows Server, а также с 12 предопределенными прикладными ролями, включая: BizTalk®, Commerce Server, Exchange Server, Host Integration Server, Internet Security and Acceleration Server, Microsoft Identity Integration Server, Microsoft Operations Manager, Small Business Server, SharePoint® Portal Server, SharePoint Team Services, SQL Server, and Systems Management Server. Для каждой роли имеется свой файл XML (см. рис. 3). При каждом создании определения роли в этот каталог помещается соответствующий файл XML. Формат файлов — стандартный XML, они могут читаться в любом текстовом редакторе или приложении, поддерживающем XML (см.рис. 4).
Рис. 3 Предопределенные роли
Рис. 3 Предопределенные роли
Рис. 4 Файл настройки роли
Рис. 4 Файл настройки роли

Сочетание SCW и групповой политики
SCW сам по себе является замечательным средством, но его истинная мощь не проявляется до применения в сочетании с групповой политикой. С момента выхода Windows® 2000 рекомендации корпорации Майкрософт по настройке безопасности серверов Windows сосредотачиваются на использовании групповой политики, что обеспечивает постоянное согласованное применение политик с централизованным управлением. Группируя серверы подразделения по их ролям, администраторы получают возможность развертывания стандартных конфигураций безопасности по всему предприятию, а не на каждой машине индивидуально. На основе логики сбора и применения стандартной групповой политики организации могут разрабатывать иерархию уровней ролей серверов, где набор основных правил может обеспечивать безопасность сотен и тысяч отдельных серверов. Если уникальные роли сервера требуют отступления от базовой политики, в иерархии подразделения ближе к серверам можно создать ориентированные на роли малые изменения политики. Это позволяет вносить небольшие изменения для обеспечения ориентированной на роль функциональности без полного дублирования главной политики, что дает большим предприятиям преимущество централизованного управления политикой в сочетании с гибкостью настройки для отдельных применений при необходимости.
Основная трудность такого подхода - его реализация. Для больших организаций с множеством различных применений и ролей серверов создание правильного набора политик трудоемко и продолжительно, но это было до появления SCW. При использовании SCW для создания политик и их приложения к нужным подразделениям можно значительно сократить время на развертывание ориентированной на каталоги безопасности на основе ролей как для существующих рабочих процессов, так и для будущих. Чтобы проиллюстрировать, как организация может выполнить эту работу, посмотрим, как в большой организации применены SCW и групповая политика на основе ролей.

SCW на предприятии
В этом примере используется сеть вымышленного предприятия Contoso. Contoso — большое, сложное географически рассредоточенное предприятие отрасли информационных технологий. В надежде снизить эксплуатационные издержки и повысить безопасность серверов Contoso следует рекомендациям Майкрософт по созданию иерархии подразделения с ориентацией на роли, при этом серверы делятся и классифицируются на основании выполняемых ими задач. Для создания применимых к подразделениям политик Contoso использует SCW.
Поскольку SCW не установлен по умолчанию, Contoso необходимо отдельно включить компонент SCW в образ для автоматической установки. Для этого добавляется новая строка SCW=On в раздел [Components] файла Unattend.txt. После этого все новые системы, установленные с этого образа, будут устанавливаться вместе с компонентом SCW. Учтите, что сама по себе настройка для установки SCW не применяет никаких политик к машинам, на которые устанавливается.
Для применения политики по умолчанию при установке в компании Contoso изменили раздел [Commands] файла cmdlines.txt в образе, чтобы вызвать команду scwcmd со следующими параметрами:
scwcmd configure /p:ContosoBaselinePolicy.xml
Как текстовый файл, так и файл XML должны находится в каталоге $OEM$ образа. Почему Contoso применяет базовую политику при установке вместо того, чтобы ориентироваться на политики, примененные к ведущему подразделению в каталоге? Применяя политику во время установки, Contoso создает прочную базу независимо от того, подключена ли машина к Active Directory®. Например, если сервер строится для целей тестирования, применение базовой политики во время установки гарантирует, что он будет соответствовать стандартам политики безопасности организации, даже если никогда не будет подключен к Active Directory. Если сервер в дальнейшем будет подключен к Active Directory, приложение групповой политики и алгоритм приоритетов заменят локальные параметры параметрами уровня домена или подразделения (помните, что приоритеты расположены в следующем порядке: локальные, сайт, домен, подразделение).
После установки SCW Contoso может начать формирование базовой политики. Базовая политика — это политика, которая должна быть развернута на верхнем уровне безопасности на основе ролей иерархии подразделения; обычно она является наиболее запретительной политикой в иерархии. Идея состоит в том, чтобы обеспечить максимально возможную безопасность, затем открыть только те службы и порты для отдельных задач, которые требуются для данных ролей сервера. С этой целью базовая политика должна создаваться на простом заново построенном сервере путем добавления стандартного для Contoso набора средств управления и служебных программ с последующим запуском SCW. Например, после завершения установки Windows Contoso устанавливает на сервер (вручную или через файл cmdlines.txt) свой стандартный антивирус, средства резервного копирования, управления и наблюдения. Поскольку каждое из этих средств обычно создает свои службы Windows, установка их на сервер перед применением базовой политики позволяет SCW учитывать их на стадии блокировки служб.
После установки сервера Contoso запускает на нем SCW. SCW можно запустить локально или удаленно, в любом случае тот, кто его запускает, должен входить в локальную группу администраторов этой машины. При удаленном запуске SCW существует возможность выбрать учетную запись, от имени которой он будет запущен на удаленной машине, при локальном запуске для этой цели можно использовать программу runas.exe. Первая задача, которую выполняет SCW — выявить службы, запущенные на локальной машине, и отобразить установленные на данный момент роли (см. рис. 5).
Рис. 5 Выбор и просмотр ролей сервера
Рис. 5 Выбор и просмотр ролей сервера
На базовом сервере Contoso не следует выбирать никаких ролей, поскольку для машины планировались максимальные запреты. Когда выбраны роли, которые должен выполнять сервер, следующим шагом будет выбрать необходимые возможности клиента для обеспечения таких функций, как автоматическое обновление, Active Directory или клиент FTP. Для большинства организаций принятие стандартных параметров SCW (как показано на рис. 6) обеспечивает необходимую функциональность (например, входить в домен) с одновременным запретом менее критичных функций (таких, как клиент FTP).
Рис. 6 Установленные возможности
Рис. 6 Установленные возможности
Затем SCW продолжит работу, позволяя выбрать, какие административные средства и нестандартные службы можно разрешить. Эти нестандартные функции – причина того, что SCW следует запускать после установки стандартного пакета управления сервером Contoso. Когда установлены антивирус, программа резервного копирования и связанные приложения, SCW узнает об этих службах и включит их в параметры окончательной политики.
Последний вопрос, касающийся усиления безопасности служб, - что делать с неуказанными службами. Это службы, которые можно встретить на компьютерах, к которым применяется политика SCW, хотя они не были запущены на машине, где эта политика изначально создавалась. Например, если базовая политика применяется к новому серверу с установленными сторонними приложениями, любые установленные этими приложениями службы будут обрабатываться по установленным администраторами правилам. SCW позволяет администраторам не менять режим запуска этих служб или отключить их. Отключение повышает безопасность, но должно использоваться с осторожностью, поскольку все явно не включенные службы будут отключены. Поэтому данная функция наиболее подходит для сред с хорошим управлением и высокой степенью безопасности. Для других частей организации рекомендуется не менять режим запуска. Поэтому в примере Contoso был выбран именно этот вариант. Перед завершением процесса укрепления безопасности служб SCW представляет администратору отчет со списком изменяемых служб.
После завершения укрепления безопасности служб SCW предоставляет возможности ограничить доступ извне по сети. Вместе со списком служб, необходимых для этой роли, список необходимых для указанной работы портов включается в базу данных SCW формата XML.
Администраторы при необходимости могут настраивать дополнительные порты или создавать правила для отдельных портов и служб, как показано на рис. 7. Для базового сервера Contoso нужно разрешить только самые основные службы, такие, как удаленный рабочий стол. Все другие исключения будут настроены в политике на основе ролей ниже в иерархии подразделения.
Рис. 7 Просмотр и разрешение портов
Рис. 7 Просмотр и разрешение портов
После этого SCW позволяет администратору выбрать параметры реестра, такие как файл подписи и трафик печати. И еще раз, по опыту, лучшим выбором в базовой конфигурации будет выбор параметров по умолчанию с максимальной безопасностью.
Следующий набор параметров для выбора касается политики аудита системы. Для большинства систем лучшим вариантом является выбор аудита успеха; аудит всех действий занимает больше ресурсов процессора и создает значительный объем записей в журнале аудита. При подозрении на атаку или при необходимости более подробного анализа на отдельной машине можно включить аудит отказов.
Наконец, SCW предоставит администратору возможности для упрочения безопасности IIS. Эти возможности аналогичны возможностям, имеющимся в средстве IIS Lockdown, и сейчас включены непосредственно в состав политики SCW.
После завершения всех этапов SCW выдает администратору запрос на сохранение файла XML. Сохраненный файл затем должен быть преобразован в формат, непосредственно доступный для групповой политики. Для преобразования файла XML в GPO используется программа Scwcmd.exe. Нужно вести следующую команду:
scwcmd configure /p:ContosoBaselinePolicy.xml
Эта политика автоматически создается в Active Directory и может быть применена к вершине укрепленной на основе ролей иерархии подразделений Contoso.
После применения этой политики к высшему уровню иерархии любые машины, добавляемые в иерархию подразделения, будут наследовать эти параметры. Когда добавляется машина, требующая внесения изменений в эту политику (такая, как сервер IIS, требующий, чтобы работала служба W3SVC), администраторы Contoso вновь запустят SCW для новой роли сервера, преобразуют новую политику в GPO и затем применят GPO к новому субподразделению, где установлен сервер (серверы). Поскольку приоритет имеют наиболее близкие к серверу GPO, в конечном результате все базовые параметры останутся неизменными, кроме тех, что потребовали изменения для обеспечения желаемой ролевой функциональности для этого подразделения (см. рис. 8).
Рис. 8 Применение политики в компании Contoso
Рис. 8 Применение политики в компании Contoso
Истинная мощь такого подхода становится очевидной в больших организациях или при развертывании большого числа серверов. После создания и применения к подразделению базовой политики OU следующие серверы необходимо только добавить к подразделению, и они автоматически унаследуют необходимую политику безопасности. Таким образом, после создания политики и применения ее к Active Directory процесс развертывания новых серверов или замены существующих становится простым и быстрым.

Взгляд в будущее
В следующем выпуске Windows Server «Longhorn» Майкрософт значительно повысил компонентизацию операционной системы, что привело к упрощению и сокращению атакуемой поверхности даже при настройке по умолчанию. Вместо того, чтобы сосредоточится на ограничении минимально стандартной установки, администраторы будут использовать средство Server Manager, чтобы добавить роли и задачи, которые требуются для каждого сервера. Server Manager работает во многом подобно SCW, а именно, в нем имеется встроенная база данных зависимостей, позволяющая установщику добавлять только новые функциональные возможности, необходимые для желаемой роли сервера. Более того, рассмотренная в этой статье централизованно управляемая безопасность на основе ролей с использованием групповой политики в дальнейшем расширится путем значительного расширения возможностей, управляемых с помощью GPO. Короче, в Windows Server «Longhorn» концепция SCW переходит на следующий уровень за счет повышенной гибкости и еще более усиленной безопасности без дополнительной настройки.
Материалы по SCW
Начать работу с SCW помогут следующие материалы в Интернете:
  • Security Configuration Wizard Documentation
  • Security Configuration Wizard for Windows Server 2003
  • Windows Server «Longhorn»

Джон Морелло (John Morello) окончил Университет штата Луизиана и в течение шести лет занимает различные должности в корпорации Майкрософт. Работая в должности старшего консультанта, он разрабатывает решения в сфере безопасности для предприятий, входящих в рейтинг Fortune 100, а также для клиентов из гражданских и оборонных федеральных ведомств. В настоящее время является руководителем программы в группе по разработке операционной системы Windows Server, занимающейся вопросами обеспечения безопасности и технологиями удаленного доступа.


 Файлы рабочего стола: Когда мне стукнет x64
Файлы рабочего стола
Когда мне стукнет x64
Уэс Миллер (Wes Miller)

Операционная система Windows XP выпускается в версии со встроенной поддержкой 64-разрядных архитектур уже больше пяти лет. Но, если только вы не были в числе рано перешедших на использование процессора Intel Itanium (Windows XP для Itanium вышла в один день с Windows XP), вероятнее всего, вы слышали об этом не так давно с выходом версий Windows XP и Windows
Server 2003 для систем x64. x64 – также упоминаемое в индустрии как x86-64 – общее название для архитектур AMD64 и EM64T разработки компаний AMD и Intel. Если вы приобрели новый ПК в течение последнего года или около того, то велики шансы, что он поддерживает 64-разрядный режим, даже если сейчас ведет 32-разрядное существование (как, вероятно, происходит с большинством).
Сейчас я работаю в небольшой начинающей компании в г. Остине, штат Техас. Из-за архитектуры одного из наших продуктов мы заинтересованы в использовании некоторых очень специфических преимуществ архитектуры x64 – почти как команда по разработке Microsoft® Exchange 2007, которая провела черту и начала поставки исключительно для архитектуры x64. Аналогично, команда по разработке и тестированию, которой я руковожу, использует только 64-разрядные версии Windows® XP и Windows Server® 2003 на рабочих станциях разработчиков, портативных компьютерах, серверах и серверах эксплуатации. Более того, на моем личном портативном компьютере установлена операционная система Windows XP Professional (64-разрядная версия), чтобы проверять и отлаживать наш продукт.
Интересно, что первая реакция многих людей, когда я говорю, что пользуюсь 64-разрядной Windows – в особенности на портативном компьютере – весьма озадаченный вид. Если они знакомы с 64-разрядной вычислительной техникой, то это что-то вроде смеси недоверия, удивления и отвращения – из-за бытующего мнения, что тяжело подобрать драйверы устройств для 64-разрядных систем. В статье этого месяца я объясню, как и почему я использую Windows XP и Windows Server 2003 в 64-разрядном режиме на системах x64, а также опишу некоторые ожидаемые преимущества и трудности развертывания. Я также остановлюсь на деталях поддержки, развертывания и перехода на 64-разрядную версию Windows Vista™.

Немного истории
Как я отметил ранее, началом поддержки 64-разрядности в Windows явилась поддержка процессора Intel Itanium. (Хотя существовала версия Windows для 64-разрядного процессора Alpha, при работе на Alpha Windows никогда не была полностью 64-разрядной). В Windows XP и Windows Vista не включена поддержка Itanium, поэтому в настоящий момент архитектура x64 является основной для 64-разрядной версии Windows. Сейчас для x64 доступно большее число выпусков Windows Server 2003, чем для Itanium (предназначаемого исключительно под нагрузку информационных центров сверхвысокого уровня) – тенденция, которая, как мне кажется, продолжится в следующей версии Windows Server с кодовым именем «Longhorn», когда начнутся ее поставки.
Поддержка Windows для платформы x64 стала доступной с момента начала поставок пакета обновления 1 (SP1) для Windows Server 2003. Хотя это и слегка сбивает с толку, но в то же самое время стала доступной версия Windows XP для x64, что означает, что 32-разрядная и 64-разрядная версии Windows XP происходят от разных деревьев кода семейства Windows. В то время как для 32-разрядных версий существует второй пакет обновления, технически для 64-разрядной версии Windows XP пакетов обновления нет вовсе (или можно считать, что в нее уже заложен пакет обновления 1 (SP1) для Windows Server 2003).
Для использования 64-разрядной версии Windows – Windows XP, Windows Server 2003, Windows Vista или Windows Server «Longhorn» – требования совершенно одинаковы. Очевидно, для начала нужен 64-разрядный процессор. В случае AMD это означает подбор одно-, двух- или четырехъядерной системы, для которой анонсирована совместимость с AMD64 (см. amd.com/us-en/Processors/ProductInformation/0,,30_118,00.html). Для Intel это означает подбор одно-, двух- или четырехъядерной системы с поддержкой архитектуры EM64T или Intel 64 (см. intel.com/technology/intel64). Обратите внимание, что здесь все дело в деталях. Например, система Intel Core Duo не поддерживает 64 разряда. А система Intel Core 2 Duo поддерживает – хотя может называться просто Centrino Duo (как в случае с моим портативным компьютером).

Существование с x64
Определившись, поддерживает ли ваша система 64-разрядную версию Windows, вам предстоит разобраться с поддержкой устройств. К сожалению, несмотря на усилия корпорации Майкрософт поощрять производителей и сборщиков систем (как минимум два года проводились конференции по разработке аппаратного обеспечения под Windows – WinHEC) создавать и сертифицировать драйвера для своих устройств и систем, наиболее проблематичным при использовании 64-разрядных версий Windows является поиск драйверов для оборудования или программного обеспечения. По моему опыту, наиболее легко эксплуатировать 64-разрядные системы на серверах, где необходимость поддержки устройств ограничена и выигрыш от 64 разрядов наиболее логичен.
Тяжелее всего найти драйверы для настольных и портативных систем. Обычно лучше обстоят дела у крупных изготовителей систем или с системой, собранной из компонентов корпоративного класса, где вероятность применения в бизнесе поощряет поставщика или изготовителя создавать и подписывать драйверы, поддерживающие 64-разрядные ОС.
К счастью, в Windows Vista ситуация значительно улучшается. Вместо мира, где x86 является предпочитаемой архитектурой, а x64 - игнорируемая архитектура с драйверами с ограничениями для большей части оборудования, здесь все происходит наоборот. Для проверки совместимости устройства с Windows Vista производитель должен предоставить 64-разрядные драйверы устройства. На самом деле, драйверы для x86 необязательны вовсе, но могут быть включены. Концептуально это означает что некоторое оборудование – в особенности устройства, использующие новые возможности Windows Vista, – может поддерживаться только в Windows для x64 и не поддерживаться в x86.
На деле драйверы являются только одной из проблем, с которыми придется столкнуться при попытке использовать 64-разрядную версию Windows. Начать можно с того, что более крупной проблемой является установка (переход), но это мы обсудим позднее.

Зачем нужны 64 разряда?
Конечно же, AMD, Intel и Майкрософт перешли на 64-разрядную архитектуру не просто так. У перехода на 64 разряда несколько ключевых преимуществ. Как можно видеть на рис. 1, наиболее важным улучшением, предоставляемым архитектурой x64, является возможность адресации значительно большей памяти – до 16 терабайт (ТБ) по сравнению с 4 ГБ, которые может использовать 32-разрядная версия Windows. Обратите внимание, что, хотя 64-разрядные указатели могут содержать адрес до этого предела в 16 ТБ, приложениям доступно около 8 ТБ.
Figure 1 Размеры адресуемого пространства памяти (Close Figure 1)

Пространство | 64-разрядная Windows | 32-разрядная Windows
Виртуальная память | 16 ТБ | 4 ГБ
Файл подкачки | 512 ТБ | 16 ТБ
Выгружаемый пул | 128 ГБ | 470 МБ
Невыгружаемый пул | 128 ГБ | 256 МБ
Системный кэш | 1 ТБ | 1 ГБ
Кроме того, версии Windows для x64 предоставляют аппаратно поддерживаемое предотвращение выполнения данных (Data Execution Prevention, DEP), также доступное в системах x86 с поддержкой NX (No Execute – не выполнять). Это создает аппаратное решение, используемое в Windows для предотвращения переполнения буферов. Оно предотвращает выполнение кода из области данных в памяти – для получения дополнительных сведений ознакомьтесь со статьей по адресу support.microsoft.com/kb/875352.
Версии Windows для x64, как и версии Windows для x86, предоставляют встроенную поддержку многопроцессорной и многоядерной архитектуры. Но одна из самых больших сложностей создания образов системы Windows XP устранена путем использования единого слоя абстрагирования оборудования (HAL) во всех вариантах Windows x64 – больше никаких усилий для определения используемого HAL на однопроцессорных или несовместимых с ACPI системах.
По существу, Windows x64 как архитектура позволяет использовать существующую инфраструктуру управления и существующие 32-разрядные приложения (в режиме эмуляции), а также 64-разрядные приложения с возможностью доступа к значительно большей памяти. На самом деле, немногими неприятными побочными эффектами при переходе на Windows x64 являются: полное отсутствие поддержки 16-разрядных приложений (включая шедевры вроде 32-разрядных приложений с 16-разрядными программами установки); проблемы с приложениями, не работающими корректно, когда включена аппаратная поддержка DEP (хотя DEP можно отключить для конкретных процессов, и команда по совместимости приложений Windows подправляет работу некоторых приложений, работающих неправильно с включенной DEP); и наконец, то, что в 64-разрядной Windows Vista все драйверы должны иметь цифровую подпись.
Последнее требование было добавлено для предотвращения манипуляций с ядром Windows в памяти,что часто делается программами захвата прав администратора. Поскольку корпорация Майкрософт поощряет производителей разрабатывать драйверы в первую очередь для x64 (чтобы драйверы прошли проверку качества оборудования Windows), ожидается, что это не будет таким суровым требованием, как могло бы оказаться исторически.
Есть еще две детали, на которые стоит обратить внимание, рассматривая Windows для 64-разрядных систем. Нет версий Windows XP для систем x64, обладающих возможностями, включенными в Windows Media® Center Edition и Windows Tablet PC Edition. В Windows Vista это меняется, и версии Windows для x64 обладают теми же возможностями, что и версии для x86.

Виртуализация
Я еще не упоминал виртуализацию. Я не имею в виду продукты для виртуализации Microsoft Virtual PC и VMWare; речь идет о виртуализации в операционной системе для 32-разрядных приложений. В 32-разрядных версиях Windows 16-разрядные приложения работают в контексте NTVDM – виртуального компьютера MS-DOS®. Как я уже упоминал раньше, в 64-разрядных версиях Windows нет поддержки 16-разрядных приложений. Вместо этого, хотя большая часть компонентов Windows работает как полностью 64-разрядные приложения, часть компонентов и многие программные продукты сторонних разработчиков выполняются как 32-разрядные приложения.
Windows предоставляет совершенно новый слой эмуляции, называющийся Windows On Windows (WOW), чтобы у этих 32-разрядных приложений было отдельное представление операционной системы – как будто выполнение осуществляется в 32-разрядной версии Windows. В WOW приложения x86 видят Program Files (X86) как просто Program Files. Аналогично, %WINDIR%\SysWOW64 виден приложениям x86 как %WINDIR%\System32, а раздел системного реестра HKLM\SOFTWARE\Wow6432Node как HKLM\SOFTWARE.
Используя средство Process Explorer, можно взглянуть на виртуализацию с другой стороны. Поскольку многие 32-разрядные приложения рассчитывают на взамодействие со встроенными программами 32-разрядной версии Windows, многие из этих программ поставляются в 64- и 32-разрядном вариантах. Это можно легко увидеть, включив дополнительный столбец в окне Process Explorer. На рис. 2 можно видеть два экземпляра cmd.exe – 32-разрядную версию и 64-разрядную версию. Обратите внимание, в выделенном 32-разрядном экземпляре можно видеть несколько библиотек DLL wow64*, подгруженных в 32-разрядный процесс. Их наличие свидетельствует о работе виртуализации, позволяющей 32-разрядным приложениям работать в 64-разрядной версии Windows. Также обратите внимание на рабочий каталог (Path), используемый 64- и 32-разрядной версиями cmd.exe.
Рис. 2 Process Explorer показывает 32-разрядную и 64-разрядную версии cmd.exe
Рис. 2 Process Explorer показывает 32-разрядную и 64-разрядную версии cmd.exe
Последнее замечание к соображениям на тему виртуализации – хотя explorer.exe выполняется в Windows как полностью 64-разрядное приложение, у этого есть за и против. Самый сильный аргумент против – то, что все расширения проводника должны быть перекомпилированы для x64, чтобы работать (большинство не перекомпилированы).
С обозревателем Internet Explorer® все наоборот – по умолчанию выполняется 32-разрядная версия. Так сделано в первую очередь для того, чтобы обилие элементов управления ActiveX®, уже использующихся в Интернете, успешно продолжало работать как есть. Без этого, поскольку 64-разрядные приложения не могут подгружать 32-разрядные библиотеки и драйверы внутрь процесса, не существует способа загружать 32-разрядные элементы управления ActiveX, то есть практически все имеющиеся, в 64-разрядную версию обозревателя, что означает, что значительная часть содержимого Интернета станет недоступна. Чтобы увидеть это на практике, попробуйте запустить C:\Program Files\Internet Explorer\iexplore.exe в 64-разрядной системе Windows и посетить любой веб-узел, загружающий содержимое ActiveX (даже Windows Update) – результатом будут разнообразные ошибки. Веб-узел Windows Update (см. рис. 3) был обновлен, чтобы в такой ситуации запускалась 32-разрядная версия Internet Explorer. В будущем, несомненно, часть содержимого ActiveX будет обновлена, чтобы воспользоваться преимуществами 64-разрядной версии Internet Explorer. Но, поскольку большинство систем на сегодня использует только 32-разрядные версии Windows, необходимость обновления содержимого ActiveX не является критически важной. Я ожидаю, что ситуация не изменится еще долго.
Рис. 3 Ошибки 32-разрядных элементов управления ActiveX в 64-разрядной версии обозревателя Internet Explorer
Рис. 3 Ошибки 32-разрядных элементов управления ActiveX в 64-разрядной версии обозревателя Internet Explorer

64-разрядные версии Windows в компании Pluck
В начале статьи я отметил, что в компании Pluck мы начали переход на 64-разрядные версии Windows. Мы проделали это для трех различных версий Windows: Windows XP Professional (64-разрядная версия), Windows Server 2003 Enterprise (64-разрядная версия) и Windows Vista (64-разрядная версия).
Наша организация сравнительно невелика, так что, начав разрабатывать наш самый новый продукт, мы смогли начать переход на 64-разрядную версию Windows, чтобы воспользоваться ее преимуществами. Это означало, что все заказываемое оборудование должно было быть совместимым с x64. По сути, увеличение размеров памяти в x64 вкупе с виртуализацией являются фактором, позволяющим нам запускать наш продукт так, как мы это делаем. Все наши физические серверы выполняются как 64-разрядные виртуальные серверы на 64-разрядном сервере размещения. В каждом сервере размещения установлено 16 ГБ оперативной памяти, разделяемой между запускаемыми на нем виртуальными серверами (обычно по 2 ГБ для каждой виртуальной машины для разработки и по 3 ГБ для каждой производственной виртуальной машины).
Используя полностью поддерживаемые системы (системы 1 уровня) и виртуализованное оборудование, мы добиваемся практически 100% поддержки устройств. В моем портативном компьютере, например, есть три устройства, для которых нет драйверов для 64-разрядных Windows. Устройства эти относятся к фоновым ресурсам материнской платы, не особо важны, и система отлично работает без них. Интересно, что при установке 64-рахзрядной версии Windows Vista RC1 ничего не поменялось с точки зрения поддержки устройств, хотя, поскольку система снабжена эмблемой Windows Vista Capable, наверняка производитель вскоре выпустит отсутствующие драйверы.
Поскольку наше использование систем сводится к запуску Microsoft Office, Visual Studio® и нескольких дополнительных средств, применяемых нами в процессе разработки и сборки, мы не обременены старыми приложениями, могущими вызвать проблемы совместимости при переходе. Пока значительная часть нашей организации продолжает пользоваться 32-разрядными версиями Windows, мы начали переход на 64 разряда на новом оборудовании, и это происходит сравнительно легко.

Развертывание 64-разрядных версий и переход на них
Необходимо учесть несколько соображений относительно развертывания. Корпорация Майкрософт предоставляет версию среды предустановки Windows (Windows PE) специально для архитектуры x64. Однако, поскольку в системах x64 есть совместимость с x86, вы можете принять решение использовать Windows PE для x86, особенно если вы используете решение с образами. Если вы развертываете Windows XP, используя автоматическую установку, версия Windows PE должна соответствовать архитектуре, поскольку приложение winnt32.exe должно выполняться в той же архитектуре, которая развертывается. Поскольку в Windows PE нет 32-разрядного слоя совместимости, а winnt32.exe для x64 является 64-разрядным приложением, для развертывания 32-разрядных версий Windows необходима 32-разрядная версия Windows PE. Это справедливо и для 64-разрядных версий Windows, которым необходима 64-разрядная версия Windows PE.
Служба удаленной установки (Remote Installation Services, RIS) в этом плане отличается, поэтому мы в компании Pluck используем RIS. Начиная с версии Windows Server 2003 SP1, RIS может развертывать 64-разрядную версию Windows в дополнение к архитектурам x86 и Itanium. Когда к серверу RIS подключается система x64, в конфигурации по умолчанию сервер предложит версии образов RISetup и RIPrep как для x86, так и для x64. RIS также можно настроить предлагать клиентам x64 исключительно образы для x86 или исключительно образы для x64. Был оставлен выбор по умолчанию, чтобы предоставить наилучшие возможности работы для оборудования x64.
Обратите внимание, что я еще не упомянул процесс обновления. Тому есть причина. К сожалению, обновление всей ОС с x86 на x64 является сложным предприятием. Поэтому с учетом ограниченного развертывания 64-разрядной версии Windows XP Pro невозможно обновить версию Windows для x86 на 64-разрядную версию Windows XP, и также невозможно обновить Windows XP (32- и 64-разрядные версии) на 64-разрядную версию Windows Vista. 64-разрядную версию Windows Vista, так же как и 64-разрядную версию Windows XP Pro до нее, можно только устанавливать с нуля. Поэтому многие организации рассматривают переход на x64 только в связи с планируемыми обновлениями оборудования. Ожидается, что многие организации воспользуются схожим подходом к переходу на Windows Vista (логично совмещая два обновления).
Но это вовсе не означает, что пользователям или организациям, переходящим с 32-разрядной версии Windows на 64-разрядную, не доступны никакие готовые средства. Версии средства переноса файлов и параметров пользователя (USMT) для Windows XP и для Windows Vista были дополнены возможностью поддержки перехода (а не обновления ОС) с одной установки Windows на другую. Все равно это наиболее часто встречающийся способ, используемый большинством компаний для развертывания Windows – удалить и установить заново, даже на тот же самый компьютер – поэтому использование того же механизма для перехода на Windows для совершенно новой архитектуры не должно стать большим препятствием, чем раньше.

Заключение
Хотя постепенный переход на x64 в нашей небольшой компании может быть значительно легче, чем сложный процесс перехода, предстоящий более крупным организациям, каждый специалист по информационным технологиям должен раньше или позже начать задумываться о переходе на архитектуру x64. Соль в том, что, хотя архитектура x86 и версии Windows для нее все еще будут активно использоваться в следующем десятилетии, архитектура x64 определенно является будущим корпоративного использования компьютеров. Поскольку корпорация Майкрософт полностью переходит на 64-разрядные мощности в Exchange Server и других продуктах, вам стоит понять, где место 64-разрядных систем в вашей архитектуре и плане перехода на Windows Vista, а также используете ли вы Windows XP и Windows Server 2003 в полностью 64-разрядном режиме.

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


 Microsoft.com изнутри: Службы федерации Active Directory
Microsoft.com изнутри
Службы федерации Active Directory
Джим Гатри (Jim Guthrie)

Корпорация Майкрософт поддерживает экстрасеть, чтобы обеспечить своим деловым партнерам доступ к важным внутренним ресурсам. Архитектура экстрасети требует, чтобы в этом пространстве у каждого внешнего по отношению к организации участника имелась уникальная доменная учетная запись. По вполне очевидным причинам такая учетная запись создается и поддерживается сотрудниками Майкрософт, а не
партнерами. Однако во время эксплуатации экстрасети может оказаться, что пользовательская рабочая среда не вполне удовлетворительна, а ложащаяся на Майкрософт нагрузка по управлению всеми пользователями партнеров требует больших затрат ресурсов.
Перейдем к рассмотрению принципов работы экстрасети. Когда клиент или партнер регистрируется в приложении, ему необходимо ввести учетные данные. Если в рамках одного сеанса пользователю требуется получить доступ к другому ресурсу, ему снова выдается запрос на ввод учетных данных. Это повторяется столько раз, сколько он будет переходить от одного ресурса к другому. Если бы пользователь зарегистрировался в приложении, использующем несколько ресурсов, например, финансовой базе данных, ему пришлось бы проходить проверку подлинности для каждого ресурса отдельно. Все это создавало бы громоздкую и раздражающую пользователей рабочую среду.
К счастью, использование служб федерации Active Directory® (ADFS) позволяет очень просто разрешить проблему многократной проверки подлинности, что вполне по силам и вам. ADFS является компонентом Windows Server® 2003 R2, упрощающим установление доверия между двумя или несколькими организациями, что позволяет им совместно использовать несколько ресурсов, одновременно сохраняя для каждой из этих организаций возможность самостоятельного управления своими пользователями. В данной заметке я покажу, как Майкрософт планирует использовать ADFS для разрешения проблемы экстрасети, связанной с использованием нескольких ресурсов; полученные сведения потребуются вам в случае, если потребуется реализовать аналогичное решение. Однако перед тем, как перейти к подробному обсуждению, рассмотрите рис. 1, чтобы ознакомиться с некоторыми основными терминами служб ADFS.
Figure 1 Терминология, относящаяся к ADFS (Close Figure 1)

Термин | Определение
Федерация | Пара областей или доменов, установившая доверие федерации Active Directory.
Ресурс служб федерации (FS-R — Federation Service Resource) | Направляет входящий запрос проверки подлинности серверу FS-A и требуемым ресурсам.
Учетные записи служб федерации (FS-A — Federation Service Accounts) | Предоставляет маркер учетной записи для проверки на подлинность на сервере FS-R.
Прокси служб федерации (FS-P — Federation Service Proxy) | Обеспечивает слой, изолирующий серверы FS от входящего трафика Интернета.
Заявка | Заявление, которое делает сервер (например имя, удостоверение, ключ, группа, привилегия или способность) о пользователе.
Обнаружение области | У каждого сервера FS-A имеется домен или область, в которой хранятся учетные данные для входа в систему. Операция обнаружения области определяет, какой FS-A используется для сеанса ADFS.

Решение ADFS
Когда пользователь пытается получить доступ к приложению, поддерживающему ADFS, обозреватель направляется к ресурсу служб федерации (FS-R — Federation Service Resource) для обнаружения области. В этот момент пользователь выбирает, какой набор учетных данных будет использоваться в течение этого сеанса. На основе выбранной клиентом области он перенаправляется на сервер учетных записей служб федерации (FS-A — Federation Service Accounts). Именно на этом сервере пользователь получает действительный маркер учетной записи (посредством файла «cookie»), основывающийся на учетных данных, введенных пользователем в форме удостоверения Windows Live™ ID (которое раньше называлось учетной записью цифрового паспорта), встроенной проверки подлинности Windows или проверки подлинности SSL (см. рис. 2). В этой модели забота об обслуживании своего сервера учетных записей федерации ложится на каждую отдельную организацию. В случае серверов партнеров Майкрософт это освобождает корпорацию от нагрузки по управлению каждой учетной записью среды. Конечно, устанавливая такой уровень ответственности, необходимо тщательно выбирать организации при объединении в федерацию и иметь гарантию того, что они активно управляют своей учетной информацией.
Рис. 2 Поток ADFS
Рис. 2 Поток ADFS
Следующей остановкой на этом маршруте является возврат на сервер FS-R для обмена маркера учетной записи на маркер ресурса. В нашей конфигурации этот маркер содержит полный список разрешений, предоставленных пользователю посредством процедуры сопоставления заявок, выполняемой на сервере FS-R. После получения маркера пользователь получает возможность единого входа (SSO) в приложения, поддерживающие взаимодействие с ADFS, на весь период сеанса, по умолчанию достигающего 24 часов (это окно допускает настройку). В результате у вас есть включенный единый вход в приложения, поддерживающие ADFS, что обеспечивает повышенную безопасность и эффективность рабочей среды пользователя. Для ознакомления с полным разбором процедуры проверки подлинности ADFS см. статью Мэта Стила под названием «Simplify Single Sign-on with ADFS» (Упрощение единого входа в систему при помощи служб ADFS) в июльском выпуске TechNet Magazine за 2006 г.
Для поддержания безопасности корпоративных ресурсов Майкрософт сторона экстрасети, обращенная к сети Интернет, была изолирована от корпоративной стороны. Это означает, что каждый сервер является потенциально двухсетевым. Разрешено одностороннее доверие со стороны внутренних корпоративных пользователей, и серверы используются для обеспечения необходимого уровня защиты. Кроме того, у нас есть отдельный домен для пространства экстрасети, на котором внешним пользователям предоставляется доступ к необходимым ресурсам.
Наиболее важные вопросы при реализации заключались в балансировке нагрузки и изменении файлов политик ADFS. Балансировка нагрузки являлась сложной задачей как на глобальном, так и на локальном уровне. В производственной среде сначала будет использоваться глобальная балансировка со стороны наших партнеров по сети доставки содержимого (CDN — Content Delivery Network) Akamai или Savvis для кластеров интерфейсного веб-сервера в двух регионах. Это обеспечит доступность системы для конечных пользователей даже при маловероятном событии перехода в автономный режим пары региональных серверов. Это реализуется посредством автоматизации перехода на другой ресурс, основанной на службах проверки состояния сервера, предоставляемых сетями CDN. Кроме этого, имеется возможность легко и быстро добавить кластеры впоследствии. С целью сокращения затрат в наших подготовительных развертываниях было решено не использовать службу CDN.
На региональном уровне мы объединяли серверы в пары для обеспечения отказоустойчивости посредством кластеризации балансировки сетевой нагрузки (NLB). Мы не используем никаких специальных компонентов для балансировки нагрузки, настолько это легко осуществляется посредством аппаратных средств; однако, из соображений экономии мы снова используем NLB. Эта конфигурация обеспечивает гарантированную стабильность более чем на 99,9 процентов периода работоспособности во всех поддерживаемых рабочих средах.
Другой сложной задачей, с которой мы столкнулись, было обеспечение правильного распространения по всей рабочей среде файла политик ADFS, являющегося основой ADFS, и обеспечения репликации изменений, сделанных в этом файле. Для достижения этого используется еще один компонент Windows Server 2003 R2 — служба репликации распределенной системы файлов (DFS-R — Distributed File System-Replication), новый, основанный на состоянии, модуль репликации с несколькими хозяевами. На каждом фоновом сервере активировалось членство в группе DFS-R с 24-часовой репликации полной сетки. После этого не имеет значения, где возникает изменение файла политик — оно будет распространено на все серверы. До тех пор, пока сохраняется контроль за тем, кому разрешается изменять файл, служба остается стабильной и высокодоступной.
Была сделана попытка обеспечить выполнение всех изменений посредством оснастки ADFS. Однако на практике выяснилось, что время от времени приходится обновлять этот файл вручную. При обновлении вручную важно помнить, что ADFS отслеживает версию этого файла. Поэтому необходимо при расширении файла отражать эти изменения в рабочей среде:
<TrustPolicyEntryUri>urn:federation:parttestint</TrustPolicyEntryUri>
<TrustPolicyVersion>127
</TrustPolicyVersion>
Следует помнить также о том, что как и весь XML, файл XML с описанием политик чувствителен к регистру. В пределах файла XML с описанием политик имеется множество ссылок на приложения или другие серверы ADFS, и во всех случаях необходимо выполнять их дословное копирование с сервера на сервер. Обратите внимание на следующие распространенные примеры, где первый, RevocationCheckFlags, была введен вручную, а второй является адресом URL доверенного приложения, измененного с помощью пользовательского интерфейса:
<RevocationCheckFlags>None
</RevocationCheckFlags>
<TrustPolicyEntryUri>https://adfstest.parttest.extranettest.microsoft.com/NTApp/
</TrustPolicyEntryUri>
В качестве дополнительного уровня защиты используется еще один компонент ADFS — прокси служб федерации (FS-P — Federation Service Proxy), который обеспечивает изоляцию слоя серверов FS-R от непосредственного доступа со стороны входящих запросов из Интернета. Уникальный метод реализации прокси в Microsoft.com состоит в использовании отдельного набора прокси для размещения нескольких рабочих сред ADFS в нашей подготовительной области. Интересно, что в период начального перевода технологии на рабочий режим было обнаружено, что для этого требуется внести небольшие изменения в раздел реестра. Раздел находится в HKLM\Software\Microsoft\WebSSO. Простым изменением значения исходного каталога в этом разделе обеспечивается возможность использовать прокси для нескольких сред. По умолчанию использовался следующий вариант:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebSSO]
“InitialDirectory”=”E:\\\\ADFS\\\\parttestint”
Для переключения сред раздел следует изменить следующим образом:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebSSO]
“InitialDirectory”=”E:\\\\ADFS\\\\parttest”
Управление этой процедурой можно упростить, создав пакетный файл. К сожалению, текущая версия оснастки MMC для ADFS не поддерживает переключение сред, поскольку в ней между прокси и сервером ресурсов или учетных записей устанавливается отношение «один к одному». Это единственная возможность наиболее эффективного использования прокси-серверов. В результате достигается очень значительная экономия средств, поскольку при этом ограничивается необходимое число физических серверов независимо от того, сколько разных рабочих сред выбрано для размещения.
С архитектурной точки зрения наша подготовительная среда запускается посредством виртуальных машин — это еще одна возможность экономии средств. При этом отпадает необходимость в приобретении и размещении шести дополнительных серверов. До настоящего времени у нас не было проблем, связанных с производительностью. Однако, чтобы соответствовать значительно более высоким требованиям производственной рабочей среды, мы решили использовать реальные компьютеры с высокой производительностью.

Не только для службы Active Directory
Не только Microsoft.com использует учетные записи Active Directory для проверки подлинности, но и мы тоже успешно внедрили учетные записи Windows Live ID. Было выяснено, что применение удостоверения Windows Live ID (WLID) 4.5 позволяет использовать учетную запись пользователя для делегирования прав доступа к ресурсам Майкрософт с помощью преобразования заявок пользователей. Это серьезная победа на пути к проверке подлинности типа единого входа, поскольку теперь нет необходимости в специальной доменной учетной записи.

Оставшиеся задачи
Основная задача, стоящая перед нами, заключается в управлении ADFS для обеспечения общего доступа к сертификатам подписывания маркера. Мы используем стандартные сертификаты, обычно остающиеся действительными в течение одного года, после чего требуется их обновление. При наступлении момента обновления все соответствующие серверы необходимо обновить согласованным образом, что окажет значительное влияние на серверы FS-R. При минимальной степени управляемости в случае 15 или 20 федераций хотелось бы обсудить масштаб, соответствующий сотням, если не тысячам. При таком масштабе потребовалось бы выделять специальный персонал для управления сертификатами SSL единой рабочей среды. У нас имеется несколько групп, рассматривающих методы автоматизации этого решения, но пока путь решения еще не найден.
Еще одна нерешенная задача состоит в том, что не все приложения поддерживают ADFS с момента установки. Для того чтобы узлы могли использовать преимущества ADFS, потребуется выполнить некоторую работу по программированию. Мы тесно сотрудничаем с группой служб Microsoft® Office SharePoint®, чтобы следующее поколение SharePoint поддерживало все, что необходимо для реализации ADFS.

Заключение
Принимая решение о переходе на модель ADFS, следует учитывать ряд факторов. Одним из них является число ресурсов, к которым будут получать доступ пользователи. Процедура настройки федеративного доверия между организациями может быть тривиальной задачей, но на нее требуется затратить время и усилия по написанию, проверке и выполнению приемлемых политик доступа. Поэтому, если у вас имеется только один ресурс, к которому будут получать доступ пользователи, вы придете к выводу, что он не стоит таких усилий. Однако с ростом числа ресурсов возрастают и преимущества.
Для получения дополниетльных сведений см. статьи ADFS Overview (Обзор ADFS) и Active Directory Federation Services: A Path to Federated Identity and Access Management (Службы федерации Active Directory: путь к федеративному удостоверению и управление доступом).

Джим Гатри (Jim Guthrie) работает в группе эксплуатации Microsoft.com в корпорации Майкрософт, где, помимо деятельности, связанной с ADFS, он выполняет функции системного инженера в группе поддержки платформы портала предприятия.


 Заметки разъездного инженера: Радости (и горести) учения
Заметки разъездного инженера
Радости (и горести) учения
Марк Д. Скотт (Mark D. Scott)

Я помню, как это было, когда появлялось что-то новое – испытываешь трепет от того, что получил в свои руки новейшую технологию раньше других, рассматриваешь продукт со всех сторон, изучаешь, как он работает, заставляешь его работать. Я расцветал, будучи в числе первых, одним из знающих, кудесником, к которому другие приходят за тайным знанием.
Но постепенно чувство радости притупилось. Я не совсем понимаю, что случилось. Возможно, я потерял его из-за разочарования от попыток заставить работать критически важное приложение в 3:00 утра. Может быть, я оставил его на полу вместе с неправильно истолкованной документацией, когда корпоративный почтовый сервер сошел с ума (в те времена, когда хватало одного сервера). А может, я просто становлюсь старым и циничным. Не важно. Уже не так увлекательно засиживаться допоздна, как это было лет десять назад. Но это не значит, что можно перестать учиться. Не так давно я укрепился в этом мнении.
Недавно я обновил Microsoft® Outlook® до версии 2007, и она мне действительно нравится. Но я также подписан на MSN® Premium; мой поставщик услуг Интернета предоставляет мне эту подписку как часть услуг. В предыдущих версиях Outlook мне было нужно специальное ПО, называемое «соединитель», для доступа к моему адресу электронной почты MSN. Этот «программный разъем» не работал с Outlook 2007, поэтому я связался с MSN. В MSN мне посоветовали обратиться к поставщику услуг Интернета, где мне в конечном счете сказали, что они не поддерживают этот соединитель MSN Outlook в Outlook 2007. Туда-обратно, электронная почта, интерактивная переписка и телефонные переговоры – получение этой информации заняло почти вечность.
А потом мне вдруг пришло в голову – может быть, «соединитель» мне вообще больше не нужен. Я запустил Outlook 2007 и настроил новое подключение к MSN без использования «программного разъема». Outlook подключился к Интернету, нашел сервер и настроил учетную запись без малейших проблем. Так же гладко это было сделано для других моих учетных записей POP3. Так я получил доступ к своей электронной почте и узнал о новой великолепной возможности продукта.
Теперь – мораль всего сказанного. Если бы кто-нибудь из службы поддержки потрудился повозиться с новым продуктом, то, скорее всего, он смог бы мне сказать, что «соединитель» больше не нужен, и это сэкономило бы нам обоим кучу времени.
Более того, если бы я сразу сам поиграл с этим продуктом, я бы, вероятно, нашел решение. Вместо этого, я хотел, чтобы кто-нибудь просто сказал мне ответ, а поскольку никто из нас не потратил времени на исследование вопроса, важного для нашей повседневной жизни, мы оба потеряли больше времени, чем если бы каждый из нас докопался до решения проблемы самостоятельно – что я в результате и сделал.
Технический прогресс побеждает нашу самонадеянность. Чтобы быть специалистами по информационным технологиям, нам нужно оставаться свободными от предвзятости. Новые технологии неизбежно вытесняют знания, над получением которых мы тяжко трудимся, потому что замена этих знаний и есть то, что делает технологию удобной в использовании. Мы не можем бесконечно использовать это тайное знание в качестве преимущества перед конкурентами. Настоящее преимущество не в сборе устаревающих фактов о том, как технология работала, но, скорее, в возможности осваивать новые концепции и приемы. Постоянно учась, сделав учение частью заведенного порядка, мы оттачиваем эти навыки. Поскольку бесконечно появляется огромное множество новых продуктов, учение должно оставаться нашим образом жизни.
Если вы хотите связаться со мной, не стесняйтесь прислать мне письмо на любой из моих адресов, Microsoft или MSN – в своем Outlook 2007 я могу читать почту с обоих.

Марк Д. Скотт (Mark D. Scott) – старший консультант в консалтинговой службе корпорации Майкрософт. Он работает в тесном сотрудничестве с клиентами, помогая проектировать и создавать крупномасштабные приложения для работы с данными. С Марком можно связаться по адресу granddaddy2002@msn.com или mascott@microsoft.com.


 Конфиденциальная информация Windows: Возможности ошибок
Конфиденциальная информация Windows
Возможности ошибок
Рэймонд Чен (Raymond Chen)

В операционной системе Windows 95 Можно перейти на страницу «Устранение неполадок» и установить флажок «синхронной записи содержимого буфера на диск». Но знаете ли вы, для чего предназначен этот флажок? Или зачем он необходим?
Обычным поведением функции Commit операционной системы MS-DOS® являлось сохранение всех незаписанных данных в определенный файл на диске и последующее ожидание подтверждения записи данных для продолжения. При установленном флажке «синхронной записи содержимого буфера на диск» вызов возвращался немедленно без ожидания записи данных. Конечно, это являлось нарушением функциональной спецификации, в соответствии с которым вызов возвращался только после записи данных. Это увеличивало опасность того, что в статье базы знаний 139669 было мягко названо «проблемами целостности файлов», поскольку программа, отправившая запрос на сброс, предполагала наличие данных на диске, в то время как их там не было.
Программа базы данных может использовать функцию Commit для установки точек, в которых состояние файлов на диске соответствовало предположению программы. При отключении питания компьютера во время обновления программа базы данных может использовать информацию, записанную в последней точке сброса, для восстановления целостности базы данных. При немедленном возврате Commit до выполнения сброса эта контрольная точка целостности будет утеряна. Результатом являлось повреждение базы данных.
Почему, несмотря на столь ужасные последствия, этот флажок был доступен? Причина: ошибка Windows® 3.11.
Рис. 1 Разрешение ошибочного поведения в Windows Server 2003
Рис. 1 Разрешение ошибочного поведения в Windows Server 2003
В операционной системе Windows 3.11 появился «32-разрядный доступ к файлам», который являлся 32-разрядной реализацией низкоуровневого интерфейса ввода/вывода файлов. Но в реализованной функции Commit содержалась ошибка игнорирования запросов на сброс буферов файлов. При запуске программы, сбросившей буферы файлов, в операционной системе Windows 3.11 запрос на сброс не действовал. В результате при отключении питания в неподходящий момент происходило повреждение базы данных.
В операционной системе Windows 95 эта ошибка была исправлена, но начали появляться новые отчеты об ошибках. Затем эта ошибка повторилась в другой программе базы данных. Что происходило?
Оказалось, что эти программы постоянно осуществляли вызовы на сброс. Программисты заметили, что запросы на вызовы вWindows 3.11 выполнялись довольно быстро, поэтому они свободно использовали их в своих программах. Запись байта, сброс. Запись строки, сброс. Поскольку сбросы осуществлялись так быстро, приложение могло сохранять данные на диск после каждой операции без заметной потери производительности. Но после исправления этой ошибки в Windows 95 работа таких программ сильно замедлилась, поскольку вызовы функции Commit неожиданно стали фактически выполняться.
Конечно, если бы отдел, занимающийся файловой системой, ничего не сделал, эти программы продолжали бы работать так же медленно, а пользователи решили бы, что проблема заключается в Windows 95. «Windows 95 работает ужасно», - сказали бы они другим пользователям. С другой стороны, при возврате поведения старой файловой системы Windows 3.11 снова могла появиться ошибка, приводящая к ужасным «проблемам целостности файлов».
В итоге было найдено решение, оставить эту ошибку исправленной, но добавить флажок, хоть и на страницу «Устранение неисправностей», возвращающий поведение Windows 3.11 для пользователей, использующих программы, в которых происходили сбои из-за исправления ошибки.
Оказалось, что история повторилась. В Windows Server® 2003 программисты, занимающиеся операциями ввода/вывода, обнаружили ошибку, при которой запросы с тегом Forced Unit Access (FUA) теряли этот тег и выполнялись как обычные запросы ввода/вывода. Это оказалось современной версией игнорирования запросов на сброс! Ошибка была исправлена, но была предусмотрена возможность возврата к старому поведению с возникновением ошибки. Версия этого флажка в Windows Server 2003 называется «Выполнить повышенную производительность», но вы то знаете, что на самом деле это означает «Возврат старого поведения с ошибкой».

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