 TechNet Magazine November 2007

TechNet Magazine November 2007

Администрирование в Windows: Новые возможности работы с автономными файлами в Windows Vista

Типичная проблема: как обеспечить работу пользователей с файлами в сети при ненадежном подключении или его отсутствии, и при этом исключить проблемы с несоответствием версий? Постоянная готовность в этом случае крайне важна для обеспечения удобства работы. В этой статье мы обсудим улучшения, предлагаемые Windows Vista в совершенствовании подхода к работе с автономными файлами.

Jeremy Moskowitz Развертывание настольных систем: Простое масштабируемое развертывание средствами BDD 2007

У вас нет сервера SMS 2003? Не переживайте, существует другой способ создания простых решений развертывания настольных систем. Вашему вниманию предлагается подробное руководство по использованию BDD 2007 и SQL Server для создания масштабируемых решений развертывания, требующих минимального ввода информации вручную или не требующих его вообще.

Adam Shepherd Связь: Пограничные транспортные серверы Exchange в корпорации Майкрософт. Часть 2.

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

Kay Unkroth Сеть: Настройка удаленного VPN-доступа в ISA Server 2006

Виртуальная частная сеть предлагает улучшенное качество подключения и обеспечивает повышенную производительность, а ее настройка и управление не составят труда. Узнайте о возможностях использования ISA Server 2006 по двум типичным схемам подключения VPN.

Alan Maddison SQL Server: Оптимизация производительности запросов SQL Server

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

Maciej Pilecki От редактора: Экология и компьютеры

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

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

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

Nino Bilic and Scott Landry Обзор служебных программ: Командлеты SMS для оболочки Windows PowerShell

Узнайте, как начать использовать командлеты Windows PowerShell для управления клиентами SMS 2003 из командной строки.

Don Brown Кабельщик: Единый вход для беспроводных сетей

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

Joseph Davies Данные исследований: Использование высокоскоростных компьютеров в борьбе против ВИЧ

Узнайте, как группа eScience из исследовательского центра корпорации Майкрософт сотрудничает с медиками-исследователями и использует высокоскоростные компьютеры для поиска лекарства от ВИЧ.

Kristin Firth and Mia Matusow Windows PowerShell: Написание регулярных выражений

Благодаря хорошо написанному регулярному выражению сценарий Windows PowerShell сможет определить соответствие данных допустимому формату. Получите представление о возможностях использования регулярных выражений в Windows PowerShell.

Don Jones Эй, автор сценариев!: Управление настольными системами из преисподней

Ребята из Scripting Guys продемонстрируют, как использовать удаленное управление Windows для получения свойств и экземпляров классов на удаленном компьютере. Кстати, это еще и отличная головоломка.

The Microsoft Scripting Guys На страже безопасности: Безопасный доступ, где бы вы ни находились

Описание вопросов проектирования сетей и систем безопасности для организации доступа из любого места с помощью компонентов служб терминалов, а также советы и рекомендации по созданию подобного решения на базе Windows Server 2008.

John Morello Материалы о рабочей среде: Правда о дефрагментации

Из-за мифов о трудностях дефрагментации многие администраторы отказались от выполнения этой важной операции. Здесь мы расскажем, какие проблемы действительно могут возникнуть, а какие из них маловероятны. И как их избежать.

Wes Miller Заметки на полях: Кодекс поведения или треска-модератор

Когда сообщники берутся за дело, на помощь приходит… рыба! Давайте посмотрим, как прикладная социология помогла спасти узел Live QnA.

Betsy Aoki Конфиденциальная информация Windows: Парадокс файловой системы

Задавались ли вы вопросом, зачем нужен миниатюрный драйвер файловой системы, встроенный в основные загрузочные файлы?

Raymond Chen


 Администрирование в Windows: Новые возможности работы с автономными файлами в Windows Vista
Администрирование в Windows Джереми Московитц (Jeremy Moskowitz)

Новые возможности работы с автономными файлами в Windows Vista
Краткий обзор:
  • Непрерывность сетевой и автономной работы.
  • Доступность файлов
  • Эволюция автономных папок

Одной из наиболее трудноразрешимых проблем в управлении настольными системами является создание среды, в которой пользователи, не подключенные к сети, смогли бы работать так, как если бы им были доступны сетевые возможности. Эта необходимость острее, чем вы можете подумать — современные пользователи сегодня намного мобильней, чем были пять лет назад. Хотя существуют различные ситуации, когда необходимо работать
автономно. Три наиболее распространенных случая — это отключение переносного компьютера от офисной сети для поездки, подключение по медленной или ненадежной линии и потеря связи филиальной сети с сетью головного офиса.
Как в таких условиях можно работать с копией файла на отключенном от сети компьютере, если исходный файл находится на главном сервере? И что еще важнее, как обрабатывать конфликт, возникающий в результате изменения файла на сервере пользователем главного офиса, если другой находящийся в дороге пользователь также изменяет его? К счастью, решение этих проблем возложено на средство работы с автономными файлами, встроенное в Windows® 2000, Windows XP и Windows Vista®.

Кэширование — вот решение!
Модуль работы с автономными файлами — поистине мощный инструмент кэширования. На самом деле все (в том числе и в Майкрософт) называют это кэшированием на стороне клиента (CSC). Модуль работы с автономными файлами — настраиваемый и достаточно гибкий инструмент, позволяющий пользователям выбирать кэшируемые объекты, а также настраивать систему на кэширование необходимых файлов. Модуль обеспечивает как автономный, так и сетевой доступ к одним и тем же файлам, и пространство имен при этом не изменяется. То есть обращение к файлам происходит по тому же UNC-пути или букве диска, независимо от того, подключен компьютер к сети или нет.
Кэширование файлов можно настроить вручную или автоматически. Если известно, что с определенными файлами или папками вы часто работаете в поездках, можно просто определить файл или папку, которая везде будет «сопровождать» вас. Для этого пользователю Windows XP необходимо щелкнуть правой кнопкой мыши файл, расположенный на локальном диске или общем сетевом ресурсе, и затем выбрать соответствующий пункт, чтобы иметь доступ к файлам в автономном режиме (см. рис. 1). В Windows Vista этот пункт меню называется «Постоянно доступны автономно». Включение автономного доступа к файлу иногда называют «закреплением файла».
Рис. 1 Настройка доступа к файлу в автономном режиме
Рис. 1 Настройка доступа к файлу в автономном режиме
Рис. 1a Папка с автономными файлами
Рис. 1a Папка с автономными файлами
Используемый общий ресурс может быть подключен по UNC-пути или букве диска. По сути, файл совсем не обязательно должен находиться на компьютере под управлением Windows Server®. Он может располагаться на любом устройстве, поддерживающем протокол Server Message Block (SMB). Это может быть сервер Samba или устройство хранения данных (NAS) (за редким исключением), которые также работают по протоколу SMB.
При первом закреплении файла в Windows XP необходимо пройти шаги мастера для определения времени синхронизации. При принятии настроек по умолчанию и нажатии кнопки «Далее» на каждом экране мастера, синхронизация будет выполняться при каждом входе и выходе из системы, а также в фоновом режиме в состоянии простоя. По прохождении шагов мастера вы увидите, что значок файла изменился — файл теперь доступен автономно.
В случае отключения от сети все другие файлы общего ресурса становятся недоступными, за исключением выбранных для автономной работы. Иногда возникает следующая проблема: значок определяет файлы, доступные автономно, но пока компьютер подключен к сети — не очевидно, что все другие файлы будут недоступны. Мы подробно рассмотрим этот вопрос далее.
Настройка автономного доступа к файлам вручную имеет свои плюсы, но иногда требуется настройка в автоматическом режиме. Мы рассмотрим эту ситуацию ниже, и вы узнаете о так называемом автоматическом кэшировании.

Автоматическое кэширование против кэширования вручную
Автоматическое кэширование настраивается на сервере для каждого общего ресурса в отдельности. Например, если общий ресурс называется «Продажи», и необходимо, чтобы сотрудники отдела продаж могли работать со своими файлами, находясь в командировке, модуль CSC необходимо настроить соответствующим образом. Нарис. 2 изображено диалоговое окно «Настройка автономного режима», которое открывается при переходе на вкладку «Кэширование» в Windows Server 2003. Параметры настройки показаны на рис. 3.
Figure 3 Параметры автоматического кэширования (Close Figure 3)

Настройка | Описание
Только указанные пользователем файлы и программы будут доступны в автономном режиме. | Эта настройка позволяет пользователям вручную указать файлы, доступные автономно. Этот вариант выбран по умолчанию.
Все открывавшиеся пользователем файлы и программы будут доступны в автономном режиме. | Эта настройка включает автоматическое кэширование всех файлов и программ, к которым пользователь обращается через проводник Windows. Настройка «Оптимизировать быстродействие» используется при преимущественном кэшировании программ, а не документов, но, как правило, не влияет на производительность и в большинстве случаев может быть без последствий проигнорирована. В Windows Vista эта настройка совсем не оказывает никакого влияния.
Файлы и программы на этом общем ресурсе не будут доступны в автономном режиме. | Эта настройка запрещает пользователям изменять настройку «Сделать доступной автономно» при работе на клиентском компьютере с установленной операционной системой Windows 2000, Windows XP или Windows Vista.
Рис. 2 Диалоговое окно «Настройка автономного режима» в Windows Server 2003
Рис. 2 Диалоговое окно «Настройка автономного режима» в Windows Server 2003
Чтобы понять, как работает автоматическое кэширование, давайте предположим, что у нас есть общая папка «Продажи» с 10 файлами (начиная с Sales01.txt до Sales10.txt) и установлен флажок «Все открывавшиеся пользователем файлы и программы будут доступны в автономном режиме». Результаты сразу увидеть не удастся. Внешних признаков того, что большее число файлов сразу доступно пользователю автономно, не будет. Кроме того, только открываемые в Windows файлы (и, следовательно, помещаемые в кэш) будут впоследствии доступны автономно. Короче говоря, чтобы использовать файлы автономно, сначала, не отключаясь от сети, нужно непосредственно открыть каждый файл. Иначе, в случае необходимости, файлы не будут доступны автономно.
Более того, автоматически кэшированные файлы совсем не обязательно будут постоянно храниться в кэше. Windows XP и Windows Vista по-разному работают с областью временного хранения, но главная мысль в том, что файлы могут быть исключены из кэша в зависимости от ограничений на свободное пространство. Время хранения файлов зависит от факта работы с ними: файлы, не открываемые в течение определенного времени, исключаются из кэша, освобождая место для вновь открываемых файлов. Таким образом, несмотря на то, что вероятность нахождения недавно открытого файла в кэше достаточно высока, не следует предполагать, что автоматическое кэширование гарантирует их неприкосновенность. Чтобы гарантировать доступность файла, его необходимо закрепить. Являясь администратором, можно также использовать групповую политику для закрепления файлов путем определения автономных файлов, как заданных администратором.
Рассмотрим реальный пример. Предположим, что пользователь Windows XP с именем EastSalesUser1 открыл файл Sales05.txt, а пользователь Windows Vista с именем EastSalesUser2 открыл файл Sales05.txt в общей папке \\server\sales.
Поскольку для общего ресурса отдела продаж включено автоматическое кэширование, то при отключении пользователей EastSalesUser1 (в Windows XP) и EastSalesUser2 (в Windows Vista) от сети эти файлы будут по-прежнему доступны для работы. Windows хранит копии этих файлов в кэше автономных файлов. А как тогда обстоит дело с другими файлами, которые пользователи еще не открывали?
Windows XP и Windows Vista по-разному реагируют на файлы, оставленные в офисной сети, как это можно увидеть на рис. 4 и 5. В Windows XP ничто не указывает на то, что часть файлов не была помещена в кэш. При отключении от сети эти файлы просто исчезают, что может запутать пользователя. В Windows Vista, наоборот, на значке каждого файла, который не был кэширован, отображается серый символ X. Это значительное усовершенствование позволяет увидеть файлы, доступные автономно. Единственная проблема — понять, какие файлы будут доступны автономно, можно только отключившись от сети. Поэтому крайне желательным усовершенствованием была бы возможность видеть состояние файла более явно.
Рис. 4 В Windows XP доступные файлы отображаются только после отключения от сети
Рис. 4 В Windows XP доступные файлы отображаются только после отключения от сети
Рис. 5 В Windows Vista в автономном режиме работы отображаются недоступные файлы
Рис. 5 В Windows Vista в автономном режиме работы отображаются недоступные файлы

Вопрос доступности
Многие администраторы неохотно прибегают к работе с автономными файлами именно из-за невозможности точно понять, какие файлы в данный момент доступны автономно, а какие — нет. На рис. 5 кружок зеленого цвета на значке файла sales01.txt указывает на гарантированную доступность файла. (Опять же, когда файл закреплен — он точно будет доступен автономно.)
Однако, как я сказал, помещение файла Sales05.txt в Windows XP и Windows Vista в кэш для автономной работы не гарантирует его доступность. Необходимо помнить, что будут доступны только те файлы, к которым пользователь обращался. Поэтому было бы лучше, если в системе указывалась временная или возможная автономная доступность. А поскольку значки не различаются, определение доступных автономно файлов не может быть однозначным. Пользовательский интерфейс в Windows Vista в этом отношении лучше, но по-прежнему нужен острый глаз, чтобы заметить изменения. А вот свойство проводника в Windows Vista — Автономное состояние — позволяет получить сведения о доступности. Это свойство отображается в области просмотра при выделении элемента. Если элемент закреплен, свойство имеет значение «Доступен всегда». Если элемент не закреплен, но помещен в кэш, то свойству присваивается значение «Доступен».
Принцип временно доступных автономных файлов построен аналогичным образом в обеих рассматриваемых операционных системах, но его реализация несколько различна. На рис. 6 показано, как Windows XP и Windows Vista обращаются с автономными файлами.
Рис. 6 Области автономных файлов в Windows XP и Windows Vista
Рис. 6 Области автономных файлов в Windows XP и Windows Vista
Проще говоря, в Windows XP и Windows Vista отведена одна область для хранения автономных файлов, но в каждой из операционных систем хранение всегда доступных в автономном режиме и временно доступных автономно файлов осуществляется немного по-разному.
В Windows XP, всегда доступные автономно файлы (определяются по изменению вида значка — см. рис. 1) остаются таковыми навсегда. Если закрепить 10Гб файлов вручную, сделав их, таким образом, постоянно доступными в автономном режиме, все 10Гб будут доступны всегда. Ограничение на количество файлов, которые может закрепить пользователь, отсутствует (за исключением размеров дискового раздела). Однако в Windows XP, размер автоматически кэшируемых файлов не может превышать 2Гб. Смысл в том, что только открываемые в ходе работы файлы остаются в кэше, в то время как остальные (не открываемые в течение определенного времени) исключаются из кэша в случае необходимости. По умолчанию размер кэша временно доступных файлов составляет 10 процентов от свободного дискового пространства (см. рис. 7). Эта настройка доступна только администраторам Windows XP.
Рис. 7 Изменение настройки размера дискового пространства, выделяемого для автономных файлов в Windows XP
Рис. 7 Изменение настройки размера дискового пространства, выделяемого для автономных файлов в Windows XP
В Windows Vista файлы могут также храниться постоянно или временно. Однако есть одно отличие. Кэш временных файлов входит в структуру общего кэша. По умолчанию общий размер кэша (как для временно, так всегда доступных автономно файлов) ограничен 25 процентами свободного дискового пространства. Подобное изменение вызвано тем, что пользователь в Windows XP мог хранить кэшируемые вручную файлы (теоретически — десятки гигабайт), что приводило к недостатку свободного пространства на диске. По новой схеме, администратор выделяет определенный объем дискового пространства для всего кэша, поэтому подобные проблемы исключены. На рис. 8 можно увидеть, что 25 процентов свободного дискового пространства показано как 15,2 процента от общего размера диска, что может ввести в заблуждение. Также обратите внимание, что положение второго ползунка, контролирующего объем области временного хранения, никогда не может быть выше первого ползунка, определяющего максимальный размер хранения всех автономных файлов. Чтобы получить доступ к ползункам ограничения места на диске для автономных файлов, щелкните пункт «Изменить ограничение», после чего введите учетные данные администратора.
Рис. 8 Свободное пространство для автономных файлов Windows Vista
Рис. 8 Свободное пространство для автономных файлов Windows Vista

Предотвращение избыточного кэширования
Функция перенаправления папок в Windows позволяет настроить хранение ключевых папок (которые, как правило, находятся на локальном диске компьютера) на серверах. Смысл в том, что теперь не нужно беспокоиться в случае неисправности локальной системы — копия важных файлов будет находиться на общем ресурсе.
Предположим, вы перенаправили папку «Мои документы» (в Windows XP) или «Документы» (в Windows Vista). В этом случае (фактически при перенаправлении каждой папки) операционная система предполагает, что эти файлы должны быть доступны в автономном режиме, и вид значка всех находящихся в перенаправленной папке файлов изменяется (см. рис. 1). Недостаток при этом заключается в том, что при постоянном, надежном подключении к сети и переходе на другой компьютер происходит кэширование всего содержимого перенаправленной папки на новом компьютере — даже если она необходима один раз. Это не только неэкономное использование дискового пространства, но и риск в случае ненадлежащего использования.
Другой ситуацией, когда файлы автоматически кэшируются (и пользователю об этом неизвестно), является использование проводника Windows для работы с файлами в общей папке. Если просто просматривать, скажем, набор графических файлов, находящихся в общем сетевом ресурсе, при помощи проводника и при включенном режиме автоматического кэширования, существует большая вероятность того, что эти файлы будут автоматически загружены и помещены в кэш. Это происходит потому, что использование проводника для обращения к файлам уже означает необходимость их помещения в кэш временных автономных файлов. Часто обращение к общему файлу возникает при просмотре его метаданных (например размера файла) или при предварительном просмотре изображения. В условиях надежной, быстрой связи это не создает проблем. Windows быстро и незаметно кэширует файлы для последующего использования. Но при медленном подключении к общему сетевому ресурсу, можно столкнуться с большими трудностями. По сути, такое поведение по умолчанию определено для проводника в Windows XP и Windows Vista. Хорошо, что модуль автономного кэширования в Windows Vista может быть настроен на определение медленного подключения.

Автономные файлы и групповая политика
Автономные файлы в Windows Vista: ключевые изменения
Коллектив сотрудников, занятых развитием функциональных возможностей работы с автономными файлами, конечно, хотел бы рассказать пользователям о наиболее интересных изменениях, но рамки статьи не позволяют исследовать все функции. Поэтому я вкратце привожу список основных изменений в модуле работы с автономными файлами:
  1. Плавное переключение между режимами работы означает, что открытые дескрипторы более не блокируют возможность переключения.
  2. Модульность автономной работы с каждым файлом: один автономный ресурс не означает автономность всего сервера.
  3. Принудительный переход в автономный режим при помощи кнопки «Работать в сети/автономно» в проводнике Windows.
  4. Шифрование кэшируемого содержимого для каждого пользователя.
  5. Новый модуль синхронизации обеспечивает более быстрое обнаружение и оценку изменений.
  6. Интеграция с функцией поиска в Windows для возможности индексирования перенаправленных папок.
  7. Синхронизация между локальным и удаленным компьютером позволяет использовать функцию дифференцированной передачи точечных изображений (Differential Bitmap Transfer).
  8. Отложенное разрешение конфликтов через центр синхронизации.
  9. Всплывающие подсказки области уведомлений исчезли навсегда — теперь пользователи не отвлекаются.
  10. Новый универсальный интерфейс COM API и поддержка WMI для управления. Документацию см. в MSDN® по адресу msdn2.microsoft.com/bb530662.
  11. Поддержка сценариев через поставщик WMI (документация будет доступна в MSDN в ближайшее время).
  12. Новые свойства элементов оболочки «Автономный доступ» и «Автономное состояние».
  13. Фиктивные элементы области имен для представления недоступных элементов при работе в автономном режиме. В проводнике такие элементы представлены светлыми значками с серым символом X, что позволяет исключать радикальное изменение представления папок в оболочке при переходе из одного режима в другой.
  14. Новое приложение «Панель управления».
Обширную информацию об этих нововведениях можно получить из моей книги или документации Microsoft, если вы захотите изучить новые функции.

Как отмечалось, при каждом обращении пользователя (например, через проводник) к файлу, весь файл помещается в кэш. И если это файл Visio® или документ Word размером 80 Мб, то бог с ним. И Windows XP, и Windows Vista способны определить медленное подключение. Действительно, при настройках по умолчанию для Windows XP медленное подключение — 64 Кбит/сек. При более быстром подключении, и если на клиентских компьютерах установлена система Windows XP, файл переносится по медленной линии при входе в систему, что приводит пользователя врасплох. Поэтому лучше всего настроить Windows для оптимального использования такой медленной линии. Сейчас вы узнаете, как для этих целей можно использовать Групповые политики, и как создать объект групповой политики (GPO), связываемый с подразделением, где расположены целевые учетные записи —Windows XP и Windows Vista.
Если пользователь подключен по медленной линии, Windows XP использует находящиеся в локальном кэше файлы, прежде чем будет предпринята попытка загрузки копии из сети. В этом есть смысл. Но Windows XP также выполняет совсем неожиданное действие: если пользователь открывает большие файлы из сети или проводник обращается к ним, эти файлы загружаются, если они еще не были помещены пользователем в кэш. Вот так-то. И, в моем примере, если синхронизация запланирована на момент выхода из системы (по умолчанию), то остальные файлы загружаются впоследствии по медленной линии и помещаются в кэш. (Второе разочарование).
Windows Vista ведет себя по-другому. По умолчанию, для Windows Vista медленного подключения не существует. То есть, если для связи используется консервная банка и скорость при этом составляет 1 бит в секунду, Windows Vista считает это подключение быстрым и использует копию файлов в сети. Но в Windows Vista можно определить общие ресурсы, которые будут переноситься при медленном подключении. В этом случае ситуация немного улучшается. Windows Vista (после настройки при помощи Групповой политики) просто делает содержимое недоступным при обращении к нему по медленной линии с использованием обычных операций с файлами или через проводник.
Фоновая синхронизация, выполняемая службой автономных файлов, по медленному подключению не происходит. Однако следует отметить, что синхронизацию можно выполнить вручную через Центр синхронизации.
Настройка Windows Vista для изменения поведения работы с медленными подключениями выполняется через параметр Групповой политики «Настроить медленное подключение» (не следует путать с параметром в Windows XP с похожим названием «Настроить скорость медленного подключения»). Параметр «Настроить медленное подключение» может принимать следующие значения: имена серверов и общих ресурсов, которые необходимо автоматически перевести в автономный режим при медленном подключении, или значения скорости медленного подключения, при достижении которых сочетание «сервер\общий ресурс» будет использоваться в автономном режиме. Сочетание «сервер\общий ресурс» может представлять любое сочетание типа \\сервер\общий ресурс или просто один символ звездочки (*) для указания всех общих ресурсов на всех серверах. Вторым набором значений является указание пропускной способности (в килобитах) и задержки (в миллисекундах) при достижении которых подключение считается медленным. Но есть один подвох. Более полезное значение из этой пары (пропускная способность) не проверяется при загрузке файлов. Так, если размер файлов составляет 10Гб в перенаправленной папке «Документы» и используется медленное подключение, а на портативном компьютере этих файлов еще нет — приготовьтесь ждать. Долго. Однако при использовании обоих значений, когда время задержки падает ниже заданного уровня, общий ресурс становится автономным, избавляя пользователя от мучительного ожидания загрузки файлов.
Исправление для Windows Vista, описанное в статье Базы знаний №934202 (планируется включить в Пакет обновления 1 для Windows Vista), должно повысить производительность в среде некоторых медленных VPN-сетей. (См. статью по адресу support.microsoft.com/kb/934202.) Фактически, это исправление должно обеспечить проверку значения пропускной способности при загрузке по медленным линиям.

Конфликты синхронизации
Вы можете спросить, что происходит при изменении автономного файла пользователем (скажем, находящимся в самолете), в то время как другой подключенный к офисной сети пользователь изменяет тот же файл. Эта ситуация разбирается на уровне клиента. При переходе из автономного режима и подключении к сети, сразу происходит фоновая синхронизация автономных файлов в Windows Vista. Затем предлагается выбрать дальнейшие действия (путем входа в Центр синхронизации после появления значка в области уведомления панели задач). Пользовательский интерфейс претерпел определенные изменения: можно увидеть, что один файл — новее, и о конфликте указаны дополнительные сведения. Пользователь может сохранить конфликтующие файлы, путем переименования только того файла, который находится на его компьютере при переносе обратно на сервер (См. рис. 9).
Рис. 9 Уведомление о конфликте измененных файлов в Windows Vista
Рис. 9 Уведомление о конфликте измененных файлов в Windows Vista

Дополнительные сведения
Работа с автономными файлами — отличная возможность для всех. Действительно, использование перенаправления папок уже означает работу с автономными файлами, и в ваших интересах научиться работать с ними. Я рассказал о многих изменениях функциональных возможностей работы с автономными файлами, но не обо всех. Для получения дополнительных сведений, щелкните пункт «Автономные файлы в Windows Vista: ключевые изменения» в боковой панели.
Более подробную информацию можно найти на страницах go.microsoft.com/fwlink/?LinkId=98141 для Windows XP и go.microsoft.com/fwlink/?LinkId=98138 для Windows Vista.
Также, огромный раздел посвящен автономным файлам (включая детальное описание всех настроек Групповой политики) в моей книге (см. биографические данные в конце статьи). И, наконец, чтобы получить еще информацию и поделиться с другими пользователями опытом работы с автономными файлами, зайдите на форум сообщества GPanswers.com, где исключительно этой теме отведен целый раздел.

Джереми Московитц (Jeremy Moskowitz), обладатель сертификата MCSE и звания MVP по групповым политикам. Он ведет форум GPanswers.com, посвященный групповым политикам, а также серию семинаров интенсивного обучения групповым политикам. Его последняя книга — Group Policy: Management, Troubleshooting, and Security (Групповые политики: управление, разрешение вопросов и безопасность) (изд. Sybex, 2007). Обратиться к Джереми и получить дополнительные сведения можно в форуме www.GPanswers.com.
© 2007 Корпорация Майкрософт и компания CMP Media, LLC. Все права защищены; полное или частичное воспроизведение без разрешения запрещено.


 Развертывание настольных систем: Простое масштабируемое развертывание средствами BDD 2007
Развертывание настольных систем Адам Шеферд (Adam Shepherd)

Простое масштабируемое развертывание средствами BDD 2007
Краткий обзор:
  • Основные возможности BDD 2007
  • Интеграция с SQL Server
  • Создание решения масштабируемого развертывания

Большинство участников процесса развертывания Windows слышали о приложении Microsoft Solution Accelerator для Business Desktop Deployment. Известное также под именем BDD, оно представляет собой комплект рекомендаций и
средств, разработанных для помощи в развертывании Windows® на компьютерах клиентов. Windows Vista® содержит обновление Solution Accelerator в форме BDD 2007. Эта версия включает новую консоль управления Microsoft® и секвенсор задач из диспетчера System Center Configuration Manager 2007, который пришел на смену серверу Systems Management Server (SMS) 2003.
Одна из наиболее сложных для понимания функций BDD 2007 — это возможность данной системы действовать в качестве решения полного развертывания. В предыдущих версиях способ создания и поддержки образов настольных систем с помощью BDD был довольно прост и позволял повторно создавать образы. Теперь в BDD 2007 предусмотрена дополнительная возможность создания масштабируемого решения развертывания путем комбинирования BDD со службами развертывания Windows, SQL ServerTM и службой репликации распределенной файловой системы Windows Server® 2003.
Но постойте-ка... разве для развертывания Windows на клиентских компьютерах не рекомендуется использовать сервер SMS 2003 с пакетом дополнительных компонентов для развертывания операционной системы (OSD)?
Да, если у вас уже есть инфраструктура SMS 2003, вы можете выполнять развертывание с помощью BDD 2007, SMS 2003 и пакета OSD. На данный момент это наиболее эффективный метод автоматического развертывания, способный в значительной мере снизить затраты организации на настройку, установку и управление операционной системой Windows.
Однако не у всех заказчиков есть SMS 2003 или аналогичное решение развертывания программного обеспечения. На этот случай имеется другой вариант, на котором я подробно остановлюсь в этой статье.

Основные понятия в BDD 2007
BDD 2007 предлагает два основных метода развертывания. В первом методе, установке с незначительным участием пользователя, для развертывания используется только BDD 2007. Этот метод предполагает запуск комплекта мастеров во время установки для сбора информации по развертыванию, например: какое имя следует присвоить клиенту (см. рис. 1), какую раскладку клавиатуры и какой часовой пояс следует использовать и т.д. Данный метод называется «установка с незначительным участием пользователя», так как обычно требует лишь минимального ввода самим пользователем информации, необходимой для начала установки.
Рис. 1 Мастер развертывания BDD 2007 с незначительным участием пользователя
Рис. 1 Мастер развертывания BDD 2007 с незначительным участием пользователя
Второй метод, автоматическая установка, основан на возможностях SMS 2003 с пакетом дополнительных компонентов OSD и интеграции с BDD 2007. Такая конфигурация обеспечивает полностью автоматизированное, масштабируемое и управляемое решение развертывания без участия пользователя.
Во время установки, на одной из первых стадий развертывания клиентской ОС, BDD 2007 собирает информацию из множества различных источников. Эти источники включают обращения к WMI и файлы настроек BDD 2007 — Bootstrap.ini и CustomSettings.ini. Собранная информация хранится в виде переменных, которые используются в процессе развертывания. В методе установки с незначительным участием пользователя файлы Bootstrap.ini и CustomSettings.ini дают возможность предопределить всю информацию, которую иначе потребовалось бы вводить вручную в окнах мастеров развертывания.
Возможность предварительного определения всей необходимой информации позволяет вам автоматизировать весь процесс установки с незначительным участием пользователя и перейти к решению автоматической установки в средах, не поддерживаемых сервером SMS 2003. Вот примерная информация, которую вы можете предопределить: ComputerName=RDG0001VST — присваивает компьютеру имя RDG0001VDT или TimeZoneName=GMT Standard Time — настраивает часовой пояс компьютера на время по Гринвичу. Все доступные свойства, которые могут быть использованы во время развертывания посредством BDD, перечислены в справочнике по настройке на странице tech-net.microsoft.com/library/bb490302.aspx.
Для получения дополнительной информации о настройке и использовании BDD 2007 см. статью "Развертывание Windows Vista при помощи BDD 2007» в сентябрьском выпуске журнала TechNet Magazine (technetmagazine.com/issues/2007/09/BDD) за 2007 год.

BDD и SQL Server
В чем преимущества использования баз данных в BDD 2007? Все дело в динамическом способе предоставления информации в процессе развертывания, которая в противном случае должна вводиться вручную в окнах мастеров установки с незначительным участием пользователя. Как я уже отметил, это можно сделать с помощью файла CustomSettings.ini. Проблема заключается в том, что в реальном процессе установки эта информация может меняться в зависимости от того, на каком компьютере выполняется развертывание. Кроме того, файл CustomSettings.ini очень быстро может стать бесполезным, если вы пытаетесь определить конкретные параметры и настройки для 500 различных машин. Прикрепление серверной базы данных к консоли BDD позволяет сделать решение гораздо более удобным, динамичным и расширяемым.
Давайте немного подробнее остановимся на интеграции SQL Server с системой BDD 2007. Прежде всего, необходимо убедиться, что на вашем сервере развертывания установлен SQL Server (предпочтительно SQL Server 2005 или более поздняя версия). К счастью, создание базы данных в BDD 2007 не представляет никакой сложности: все, что вам нужно сделать — щелкнуть правой кнопкой узел Database в средстве BDD 2007 Deployment Workbench, выбрать команду New («Создать») и следовать инструкциям (см. рис. 2). Группа BDD проделала немалую работу по созданию мастеров, помогающих легко и быстро справиться с этой задачей.
Рис. 2 Настройка базы данных развертывания для BDD 2007
Рис. 2 Настройка базы данных развертывания для BDD 2007
После создания базы данных вы можете ознакомиться со всеми ее возможностями. Записи в базе данных делятся на четыре основных категории: «Компьютер», «Роль», «Расположение» и «Марка и модель». Каждая категория позволяет определять записи и заполнять каждую запись переменными BDD 2007, назначать приложения и выполнять другие важные настройки (см. рис. 3).
Рис. 3 Назначение свойств развертывания
Рис. 3 Назначение свойств развертывания
Очень интересно взглянуть на эти четыре категории в двух разных группах. Категории «Компьютер», «Расположение» и «Марка и модель» предоставляют вам различные способы идентификации компьютера во время установки. Затем каждый идентифицированный компьютер можно связать с определенной ролью в базе данных, подготовив его таким образом к выполнению задач в конкретной области, например торговля, маркетинг или финансы. Для каждой роли устанавливается соответствующий комплект бизнес-приложений.
Раздел «Компьютер» используется для идентификации машин по MAC-адресу, номеру ярлыка, универсальному уникальному идентификатору (UUID) или серийному номеру. Поскольку в этом разделе, скорее всего, будет большое количество записей (по одной на каждый компьютер в организации), рекомендую вводить в каждую запись только уникальные свойства, такие как имя компьютера.
Раздел «Расположение» используется для создания записей о конкретных географических местоположениях организации. Каждая запись идентифицируется по шлюзу, используемому по умолчанию для этого местоположения. Это особенно удобно, если в службе каталога Active Directory® имеются локальные структурные подразделения, и вы хотите, чтобы компьютеры, созданные в каком-либо расположении, были добавлены в домен структурного подразделения, соответствующего этому расположению.
Раздел «Марка и модель» используется для создания записей по каждому типу оборудования, который поддерживается вашим решением развертывания. BDD 2007 сравнивает эти данные с информацией, полученной посредством обращений к WMI. В средах разработки раздел «Марка и модель» используется для создания записи, посредством которой производится проверка, является ли компьютер виртуальной машиной Virtual PC 2007 или Virtual Server 2005 с помощью просмотра свойств «Корпорация Microsoft» и «Виртуальная машина» из раздела «Марка и модель» соответственно. Если эти свойства проверяются во время установки, вы можете сообщить BDD о том, что при развертывании необходимо установить приложение Virtual Machine Additions. Для этого просто добавьте данное приложение в запись «Марка и модель».
Теперь, когда методы идентификации машин определены, можно воспользоваться разделом «Роль», чтобы создать записи для всех требуемых ролей развертывания. В качестве примера можно привести запись для ролей Windows XP и Windows Vista, которые настраиваются путем добавления свойства BuildID, отвечающего сборке Windows XP или Windows Vista, определенной в BDD для каждой записи. Есть и другой подход: определить роли отделов, например «Бухгалтерия», «Продажи» или «Финансы». Я обычно стараюсь заполнить максимальное количество свойств BDD в этом разделе (часовой пояс, региональные настройки, организационная информация и т.п.). Это позволяет свести администрирование баз данных к минимуму, поскольку эти записи не привязаны к конкретным компьютерам, аппаратным устройствам или расположению.
Мы должны сообщить BDD 2007, что во время развертывания необходимо найти в базе данных все записи, соответствующие компьютеру, на котором производится развертывание. Чтобы настроить BDD на использование базы данных в процессе развертывания, щелкните правой кнопкой точку развертывания и выберите команду Configure DB («Настроить базу данных»). При этом вам будет предложено выполнить инструкции ряда мастеров, которые заполнят файл CustomSettings.ini записями, используемыми процессом установки с незначительным участием пользователя для запроса информации из базы данных.

Как сделать развертывание масштабируемым
Итак, теперь вы стали счастливым обладателем сервера развертывания, способного автоматизировать установку с незначительным участием пользователя и динамически подготовить любой компьютер к выполнению определенных функций в заданной бизнес-роли. Но как сделать это решение масштабируемым?
Архитектура данного решения основана на топологии «звезда», как показано на рис. 4. Прежде всего, необходимо создать концентратор и родительский сервер развертывания. Все дочерние серверы развертывания являются своеобразными «лучами звезды».
Рис. 4 Архитектура развертывания «звезда»
Рис. 4 Архитектура развертывания «звезда»
Чтобы активировать эту архитектуру, необходимо воспользоваться службой DFS-R для репликации дистрибутивного общего ресурса на каждом из серверов развертывания. Затем с помощью репликации моментальных снимков SQL Server вы подготавливаете копию базы данных развертывания BDD также для каждого дочернего сервера. Преимущество этого решения в том, что дочерние серверы развертывания имеют минимальные требования: для начала установки вам нужно лишь установить на каждой машине SQL Server Express, службы развертывания Windows и DFS-R.
Из-за больших объемов данных, которые могут храниться в дистрибутивном общем ресурсе BDD 2007, я предпочитаю использовать DFS-R в Windows Server 2003 R2, а не службы репликации файлов в более ранней версии Windows Server. Служба DFS-R использует удаленное разностное сжатие (RDC) для репликации только разностных изменений файлов элементов группы репликации. Это может сильно повлиять на объем трафика репликации в тех случаях, когда в пользовательский файл образа вносится небольшое изменение, например новый драйвер. При использовании службы DFS-R объем трафика репликации определяется только размером внесенных изменений, при этом повторное распространение всего файла образа не требуется.
На веб-узле Microsoft вы найдете предостаточно информации о распределенной файловой системе (DFS). Начать можно с microsoft.com/windowsserver2003/technologies/storage/dfs. Я, однако, расскажу об основных стадиях установки и настройки, чтобы дать вам общее представление об этом процессе в контексте развертывания на базе BDD.
Обратите внимание, что в случае если на ваших серверах используется служба Active Directory на базе установки Windows Server 2003 версии до R2, может понадобиться обновление схемы Active Directory до совместимости с DFS-R, поскольку службе репликации требуются новые классы объектов. Подробную информацию о расширении схемы Active Directory в Windows Server 2003 R2 можно найти на странице go.microsoft.com/fwlink/?LinkId=99936.
Первым делом вам нужно установить компоненты DFS на сервере развертывания Windows Server 2003 R2. Это можно сделать несколькими способами, самый простой из которых — воспользоваться стандартным мастером установки и удаления компонентов Windows. После этого необходимо установить группу репликации с помощью консоли управления DFS, которая изображена на Рис. 5.
Рис. 5 Консоль управления DFS
Рис. 5 Консоль управления DFS
Для масштабирования вашего решения развертывания BDD 2007 необходима репликация двух папок. Первая — это дистрибутивный общий ресурс BDD 2007, в котором содержатся все исходные файлы и файлы настройки BDD. Эти файлы должны быть доступны на всех серверах развертывания.
Вторая папка, которую следует реплицировать — это папка Boot. Она используется службой развертывания Windows для хранения файла LiteTouch_x86.wim. Именно среда загрузки BDD переносится службой развертывания Windows на клиентские компьютеры, чтобы можно было начать процесс развертывания. Репликация этого файла позволяет отразить во всей инфраструктуре развертывания все изменения, внесенные в среду загрузки на родительском сервере развертывания.
Итак, реплицировать нужно следующие папки: X:\Distribution (где Х: — диск, который вы указали во время установки BDD 2007) и Y:\RemoteInstall\boot (где Y: — том, в котором хранится общий ресурс службы развертывания Windows RemoteInstall).
Процесс репликации в DFS-R имеет несколько хозяев, и поэтому создать топологию односторонней репликации невозможно. По этой причине для разрешения централизованного управления дистрибутивным общим ресурсом необходимо активировать для папки ресурса на каждом дочернем сервере развертывания свойство «только для чтения». В этом случае сохранять информацию в данной папке сможет только служба репликации DFS-R (так как она обладает правами резервного копирования и восстановления). У клиентских машин, созданных с дочерних серверов, не будет необходимости сохранять информацию в этой папке, поэтому предоставлять им более высокие разрешения, чем только чтение, не имеет смысла.
Процесс репликации данных с помощью DFS-R завершается настройкой политики обновления хранилища данных конфигурации загрузки в службе развертывания Windows. Благодаря этому все изменения, произведенные в среде загрузки, отражаются на каждом дочернем сервере развертывания. Это изменение конфигурации должно быть выполнено на всех серверах службы развертывания Windows, и я рекомендую включить его в процесс создания и настройки для подготовки сервера развертывания.
Выполните следующую команду на всех серверах развертывания:
WDSUTIL /set-server /BCDRefreshPolicy /Enabled:yes /RefreshPeriod:<time in minutes>
Период обновления зависит от того, насколько часто обновляются данные на серверах развертывания. Если вы настраиваете службу DFS-R на репликацию через каждый час, имеет смысл и политику обновления хранилища также настроить на обновление через каждые 60 минут.

Репликация SQL Server
Итак, вы уже выполнили масштабирование BDD 2007 с целью репликации дистрибутивного общего ресурса и образа загрузки службы развертывания Windows с первичного сервера развертывания на все дочерние серверы. Теперь нужно завершить процесс и реплицировать базу данных BDD 2007 Deployment Workbench, чтобы она была доступна локально на каждом сервере развертывания.
Судя по описанию в документации, технология репликации, которую использует SQL Server, ничем не отличается от технологии публикации журналов. В примере с журналами у нас есть издатель, который издает журнал, распространители, которые распространяют журналы этого издателя, и подписчики, которые подписываются на получение журнала. Во встроенных возможностях репликации SQL Server используется та же терминология.
Обратите внимание, что сервер-издатель базы данных SQL Server не может работать с версией SQL Server Express Edition: на нем должна быть установлена полная версия SQL Server. Для первичного сервера развертывания я использовал SQL Server 2005 (хотя SQL Server 2000 тоже подойдет). Для дочерних серверов развертывания можно использовать версии SQL Server 2005 или SQL Server 2005 Express.
Перед началом настройки репликации SQL Server следует выполнить несколько действий, чтобы проверить правильность настройки SQL Server для поддержки репликации. При подготовке серверов развертывания убедитесь, что компоненты репликации включены в процесс установки SQL Server 2005 или SQL Server 2005 Express Edition. SQL Server Express по умолчанию не устанавливает эти компоненты.
Далее, в SQL Server необходимо активировать удаленные подключения, иначе среда загрузки для установки с незначительным участием пользователя не сможет удаленно подключаться к SQL Server. Чтобы настроить удаленные подключения в SQL Server, запустите средство настройки контактной зоны SQL Server, выберите вариант Surface Area Configuration for Services and Connections («Настройка контактной зоны для служб и подключений») и настройте сервер на принятие как локальных, так и удаленных подключений по протоколу TCP/IP и именованным каналам.
Затем создайте на первичном сервере развертывания общую папку для хранения данных о моментальных снимках репликации, откуда они будут считываться агентами репликации на дочерних серверах развертывания. Я еще вернусь к этой папке чуть позже. Я обычно размещаю ее в том же томе, что и остальное содержимое для развертывания.
Для последней стадии настройки вполне достаточно будет версии SQL Server Express Edition на дочерних серверах развертывания. По умолчанию служба обозревателя SQL Server отключена. Чтобы разрешить репликацию, вам потребуется настроить эту службу на автоматическую работу и запустить ее. Для настройки службы используйте диспетчер конфигураций SQL Server. Кроме того, нужно также создать на дочерних серверах, на которые будет выполняться репликация, базу данных. Рекомендую использовать для этой базы данных такое же имя, как для базы данных BDD 2007 на первичном сервере развертывания: это позволит уменьшить количество дополнительных настроек.

Настройка репликации
Итак, теперь вы полностью готовы к настройке репликации SQL Server. Для начала запустите среду SQL Server Management Studio на главном сервере развертывания, на котором должна быть установлена полная версия SQL Server 2005. Прежде всего, нужно создать и настроить распространение. Для этого перейдите к папке Replication на консоли управления, как показано на рис. 6. Чтобы запустить мастер распространения, щелкните правой кнопкой мыши эту папку и выберите команду «Настройка распространения».
Рис. 6 Сервер управления SQL Server: Репликация
Рис. 6 Сервер управления SQL Server: Репликация
В окне мастера подтвердите, что первичный сервер развертывания должен функционировать как собственный распространитель. Укажите, что корневая папка моментальных снимков является путем UNC для созданного ранее общего ресурса репликации SQL Server. Теперь укажите, что первичный сервер развертывания должен быть настроен как издатель.
После того как мастер успешно завершит настройку сервера в качестве издателя и распространителя, вы должны будете сообщить SQL Server, какую базу данных следует опубликовать. Для этого щелкните правой кнопкой папку Replication и выберите пункт «Свойства издателя». В диалоговом окне свойств щелкните «Базы данных публикации» и выберите базу данных BDD 2007 для транзакционной репликации, как показано на рис. 7. В данном случае транзакционная репликация фактически не используется, однако этот параметр выбирается независимо от предназначения — моментальный снимок или транзакционная репликация.
Рис. 7 Публикация базы данных
Рис. 7 Публикация базы данных
Теперь нужно создать публикацию, на которую смогут подписаться дочерние серверы развертывания. В папке Replication щелкните правой кнопкой «Локальные публикации» и выберите команду «Создать публикацию», чтобы запустить мастер публикаций. Выберите базу данных BDD в качестве базы данных для публикации. Выберите тип публикации «Репликация моментального снимка» и укажите все таблицы, хранимые процедуры и представления, которые необходимо реплицировать. Выберите вариант немедленного создания исходного моментального снимка. Что касается планирования работы агента моментальных снимков, для наших целей будет более чем достаточно запускать его по умолчанию один раз в день, если только вы не собираетесь обновлять базу данных очень часто.
Остался последний шаг: подписать все дочерние серверы развертывания на эту публикацию. В соответствии с этой подпиской SQL Server будет отправлять копию базы данных каждому дочернему серверу через определенные интервалы времени. В папке Replication откройте вложенную папку Local Publications и найдите там только что созданную вами публикацию. Щелкните ее правой кнопкой и выберите команду «Новые подписки», чтобы запустить мастер подписки. В окне мастера выберите созданную ранее публикацию BDD. Выберите вариант запуска всех агентов в распространении, активировав топологию репликации в качестве принудительной подписки. После этого добавьте каждый сервер развертывания в качестве подписчика и назначьте базы данных, созданные на всех серверах, на получение копии реплицированных данных (помните, что имена этих баз данных должны совпадать с именем базы данных на первичном сервере). И последнее: настройте учетную запись, которая будет использоваться для подключений, и создайте расписание для репликации. Оно должно повторять расписание, выбранное для агента моментальных снимков. Это был довольно краткий обзор подготовки и запуска репликации SQL Server. Теперь ваши данные будут реплицироваться в мгновение ока!

Настройка BDD 2007
Вы уже сконфигурировали BDD 2007 для использования базы данных и настроили репликацию этой базы и дистрибутивного общего ресурса BDD 2007 на дочерних серверах развертывания. Для завершения развертывания вам необходимо настроить BDD 2007 таким образом, чтобы при загрузке клиентом среды загрузки BDD система автоматически подключалась к серверу, который является его локальным сервером развертывания.
При загрузке в среду предустановки Windows с незначительным участием пользователя в том случае, если клиент выполнил загрузку с сервера службы развертывания Windows, в среде предустановки Windows задается значение реестра, содержащее имя сервера, с которого клиент загрузил среду загрузки. Начальные сценарии развертывания BDD 2007 получают и хранят это значение в переменной среды %WDSServer%.
Обратите внимание, что, если вы используете первый выпуск BDD 2007, это значение может оказаться некорректно заполненным в реестре среды предустановки Windows. На странице support.microsoft.com/kb/937191 вы можете загрузить обновление для решения этой проблемы.
Для настройки BDD 2007 нужно просто отредактировать файлы BootStrap.ini и CustomSettings.ini таким образом, чтобы все ссылки на сервер развертывания были заменены ссылкой %WDSServer%. Этот процесс обычно включает в себя замену значений для имени экземпляра SQL Server значением DeploymentRoot — сервера, на котором размещен дистрибутивный общий ресурс. Образец файла Bootstrap.ini и фрагмент файла CustomSettings.ini приведены на рис. 8 и рис. 9.
Figure 9 CustomSettings.ini (Close Figure 9)
[Settings]
Priority=MMSettings, MMApps, CSettings, CRoles, RSettings, RApps, Default
Properties=Manufacturer

[Default]
OSInstall=Y
DeployRoot=\\%WDSServer%\Distribution$
UserDomain=BUILDLAB
UserID=BddAdmin
UserPassword=Password1234

[CSettings]
SQLServer=%WDSServer%
Database=BDD_DB1
Netlib=DBNMPNTW
Table=ComputerSettings
Parameters=UUID, AssetTag, SerialNumber, MacAddress
ParameterCondition=OR

[CRoles]
SQLServer=%WDSServer%
Database=BDD_DB1
Netlib=DBNMPNTW
Table=ComputerRoles
Parameters=UUID, AssetTag, SerialNumber, MacAddress
ParameterCondition=OR
Figure 8 BootStrap.ini (Close Figure 8)
[Settings]
Priority=Default

[Default]
DeployRoot=\\%WDSServer%\Distribution$
UserDomain=BUILDLAB
UserID=BddAdmin
UserPassword=Password1234
SkipBDDWelcome=YES
Обращаю ваше внимание, что данное решение подразумевает размещение службы развертывания Windows на том же сервере, где хранится реплицированная база данных BDD 2007 и реплицированный дистрибутивный общий ресурс BDD 2007. Причины этого очевидны: в этом случае вы можете использовать переменную %WDSServer% в качестве простого и надежного способа сообщения клиентскому компьютеру о расположении его локального сервера развертывания и предотвращения его обращения в глобальную сеть.

Дополнительные соображения
Одним из самых главных достоинств системы BDD 2007 является ее расширяемость, поэтому существует еще очень много различных аспектов, заслуживающих рассмотрения в плане расширения данного решения. Например, встроенные возможности позволяют вести мониторинг SQL Server и DFS-R, разрабатывать методы внедрения в компьютеры вашей среды информации из базы данных управления лицензиями и даже использовать хранимую процедуру SQL для извлечения таких сведений. К сожалению, объем данной статьи не позволяет мне подробно остановиться здесь на этих вопросах, однако я надеюсь, что предоставил вам достаточно информации обо всех возможностях BDD и их использовании внутри организации.

Адам Шеферд (Adam Shepherd) — консультант в консультационной службе отделения корпорации Майкрософт в Великобритании. Работа Адама сосредоточена главным образом на развертывании, поддержке и управлении клиентом Windows. С Адамом можно связаться по адресу adamshep @microsoft.com.


 Связь: Пограничные транспортные серверы Exchange в корпорации Майкрософт. Часть 2.
Связь Кэй Анкрот (Kay Unkroth)

Пограничные транспортные серверы Exchange в корпорации Майкрософт. Часть 2.
Краткий обзор:
  • Использование журналов регистрации и трассировок пограничных транспортных серверов
  • Настройка защиты от нежелательной почты со сценариями
  • Тестирование типичных ситуаций при отправке и получении нежелательной почты
Загрузить исходный код для этой статьи: Edge2007_11.exe (161KB)

Как обеспечить пользователям организации возможность надежного и безопасного обмена сообщениями, учитывая, что Интернет переполнен нежелательной информацией и другим вредоносным содержимым? Один из способов, который я начал описывать в прошлом месяце в первой части этой серии, заключается в развертывании
пограничных транспортных серверов Exchange Server 2007 и приложения Forefront Security для Exchange Server в демилитаризованной зоне (пограничной сети), отделяющей Интернет и рабочую среду.
Во второй, завершительной части статьи, я расскажу, как выполняется анализ агентов пограничных транспортных серверов с помощью стандартных функций Exchange Server 2007, трассировки и записи агентов в журнал. Также я остановлюсь на пользовательском методе записи всех объектов событий из транспортного конвейера в файлы на основе XML. Далее я проиллюстрирую применение настроек защиты от нежелательной почты в лаборатории тестирования пограничного транспортного сервера в соответствии с конфигурацией, которую использует Microsoft в собственной корпоративной рабочей среде. И, наконец, в завершение темы я приведу несколько реалистичных и интересных тестовых сценариев, которые показывают, как агенты пограничных транспортных серверов действуют в различных ситуациях при получении нежелательной почты.
Дополнительную информацию по установке лаборатории тестирования пограничных транспортных серверов и их общей архитектуре можно найти в первой статье этой серии в октябрьском выпуске журнала TechNet Magazine за 2007 г., который доступен на веб-узле technetmagazine.com/issues/2007/10/Edge.
Я активно использовал сценарии и пакетные файлы для автоматизации наиболее важных задач настройки. Вы можете найти их в загружаемом приложении к этой статье (для этого зайдите на страницу technetmagazine.com/code07.aspx). Для более полного ознакомления с настройкой IT агентов пограничных транспортных серверов Майкрософт рекомендую техническое описание «Microsoft® Exchange Server 2007 Edge Transport and Messaging Protection» для Microsoft IT Showcase. Это описание можно загрузить на странице microsoft.com/technet/itshowcase/content/edgetransport.mspx.

Ведение журнала и трассировка
Exchange Server 2007 включает ряд функций ведения журнала и трассировки, в том числе журнал протокола, журнал агентов и трассировку конвейера. Эти функции упрощают диагностику и решение проблем с транспортными агентами. В этой статье я не буду подробно останавливаться на устранении неполадок с транспортными агентами, но приведенной здесь информации о ведении журнала и трассировке вполне достаточно для понимания принципов работы этих агентов.
Если вы хотите отслеживать информацию об операциях отправки и получения SMTP, необходимо активировать ведение журнала протокола для соединителей отправки и получения. С помощью тестовой среды, установка которой описана в первой части этой статьи (см. рис. 1), я активировал ведение журнала протокола посредством следующих настроек командлетов New-SendConnector и New-ReceiveConnector:
Рис. 1 Тестовая среда
Рис. 1 Тестовая среда
–ProtocolLoggingLevel: Verbose
Полученные файлы журнала SMTP по умолчанию сохраняются во вложенных папках, путь к которым выглядит следующим образом: %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\ProtocolLog.
Ведение журнала протокола очень удобно для анализа диалогов по протоколу SMTP, хотя агенты защиты от нежелательной почты не всегда влияют на SMTP-сеансы. Например, агент фильтра содержимого может помечать только входящие сообщения, устанавливая значение уровня вероятности нежелательной почты (SCL). Если уровень SCL ниже установленного порогового значения (по умолчанию оно равно 7), агент фильтра содержимого не активирует процесс отклонения сообщения пограничным транспортным сервером. Вот почему диалог по протоколу SMTP продолжается без каких-либо изменений.
Чтобы проанализировать действия, которые агенты защиты от нежелательной почты (агенты фильтра подключений, фильтра содержимого, правил пограничного сервера, фильтра получателей, фильтра отправителей и идентификатора отправителей) выполняют над сообщениями, проходящими через транспортный конвейер, вам понадобится просмотреть не журнал протокола, а журнал агентов. Ведение журнала агентов обычно активировано в соответствии с параметром AgentLogEnabled в файле EdgeTransport.exe.config. Журналы агентов по умолчанию сохраняются в папке %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\ProtocolLog. Открыть файлы журнала можно в Блокноте, хотя командлет Get-AgentLog отображает информацию из журнала на командной консоли Exchange более наглядно.
Трассировка конвейера — это еще одна полезная функция, которая позволяет делать моментальные снимки сообщений конкретного отправителя в процессе передачи этих сообщений по транспортному конвейеру. Идея относительно проста: процесс пограничного транспортного сервера создает моментальный снимок каждого сообщения до и после вызова агентов получения и маршрутизации SMTP, зарегистрированных для событий OnEndOfHeaders, OnEndofData, OnSubmittedMessage и OnRoutedMessage. Сравнивая эти снимки, вы можете увидеть, как различные агенты изменяют каждое сообщение. Конечно, сначала необходимо активировать эту замечательную функцию в среде тестирования.
Следующая последовательность действий с командлетом Set-TransportServer активирует трассировку конвейера для тестового пользователя. Параметр PipelineTracingEnable, установленный на значение $true, как вы уже, наверное, догадались, активирует трассировку конвейера. Адрес электронной почты тестового пользователя указывается в параметре PipelineTracingSenderAddress:
Set-TransportServer –Identity EDGE01
–PipelineTracingEnabled $true
-PipelineTracingSenderAddress Contoso.User@contoso.com
Когда трассировка конвейера включена, файлы моментальных снимков всех сообщений указанного отправителя (в данном случае это Contoso.User@contoso.com) сохраняются в папке %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\PipelineTracing\MessageSnapshots. Это папка по умолчанию. Файлы моментальных снимков каждого сообщения сохраняются в отдельном подкаталоге, названном в соответствии с идентификатором GUID, который присвоен данному сообщению. Обратите внимание, что исходное сообщение находится в файле Original.eml, а копии сообщения — в файлах EML, имя которых начинается на «SmtpReceive» или «Routing» в зависимости от имевших место событий и установленных агентов. Чтобы проанализировать обработку агентов защиты от нежелательной почты, зарегистрированных для событий получения SMTP OnEndofData и OnEndOfHeaders, просмотрите файлы SmtpReceive*.eml. Чтобы проанализировать обработку антивирусных и других агентов, зарегистрированных для событий маршрутизации OnSubmittedMessage и OnRoutedMessage, просмотрите файлы Routing*.eml.

Настройка записи данных конвейера
Стандартные функции ведения журнала и трассировки в Exchange Server 2007 удовлетворяют всем требованиям по поиску и устранению неисправностей, несмотря на то, что фактически стандартные функции не охватывают весь спектр событий, связанных с транспортом. Например, функция трассировки конвейера не может получить информацию о событиях OnConnectEvent, OnEhloCommand, OnMailCommand, OnRcptCommand, OnDataCommand и аналогичных событиях, поскольку узел отправки еще не передал никаких сообщений, которые могли бы быть записаны в папку %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\PipelineTracing. Если вы хотите получить подробную информацию об этих событиях, создайте пользовательский агент для записи сведений об этих событиях в файлы файловой системы.
В предыдущей статье мы уже выяснили, что создание пользовательских агентов не представляет никаких трудностей, поэтому вы легко сможете создать агент получения SMTP и агент маршрутизации для записи всех объектов событий с транспортного конвейера в XML-файлы. Соответствующий проект Microsoft Visual Studio® 2005 под названием PipelineXMLDump можно найти в загружаемом приложении к этой статье. Наибольшую важность представляют два файла: DumpAgents.cs, который создает агенты и фабрики агентов, и XMLDump.cs, который создает вспомогательный класс для записи полей источников событий и объектов аргументов событий в XML-файлы с помощью методов System.Re- flection. Скомпилировав исходный код и скопировав полученный файл PipelineXMLDump.dll в папку C:\PipelineXMLDump на тестовом пограничном транспортном сервере, вы получите возможность регистрировать и активировать пользовательские агенты с помощью сценариев RegisterPipelineXMLDump.ps1 и EnableDumpAgents.ps1. Эти сценарии включены в папку проекта PipelineXMLDump в загружаемом приложении. Приведенные мною пользовательские агенты годятся, конечно же, только для иллюстративных целей. Они не были должным образом протестированы, и их не следует устанавливать на производственном сервере. Используя эти агенты, вы действуете на свой страх и риск.
В файле DumpAgents.cs содержатся сведения о том, как создавать обработчики событий маршрутизации и получения SMTP, которые поддерживает транспортный конвейер. Эти сведения станут хорошей отправной точкой при создании собственных пользовательских агентов. Мои агенты записи записывают файлы XML во вложенные папки по адресу %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\PipelineXMLDump, который соответствует идентификатору сеанса SMTP (агент получения SMTP) либо идентификатору сообщения (агент маршрутизации). На рис. 2 показан пример передачи информации об аргументе события агенту получения SMTP в обработчике OnConnectEvent. В этом примере показана локальная конечная точка IP (IP-адрес и порт), которая принимает входящий запрос на подключение.
Рис. 2 Информация об аргументе записывается во время события OnConnect
Рис. 2 Информация об аргументе записывается во время события OnConnect

Подготовка тестовых запусков
Немного теории о ведении журналов, трассировке и записи. Итак, давайте сделаем несколько тестовых запусков, чтобы посмотреть на агенты защиты от нежелательной почты в действии. Ниже приведено краткое описание, отражающее настройку Microsoft IT так точно, насколько это возможно в среде тестирования. Как уже было сказано, дополнительную информацию можно найти в техническом описании «Microsoft Exchange Server 2007 Edge Transport and Messaging Protection».
Для начала следует деактивировать входящий агент перезаписи адресов, агент фильтрации вложений и исходящий агент перезаписи адресов путем выполнения сценария EDGE01_disable_agents.ps1 из загружаемого приложения. Перезапись адресов нам не нужна, поскольку получатели используют одни и те же электронные адреса внутри сервера и вне его. Я не использовал агент фильтрации вложений, поскольку в Forefront Security предусмотрены возможности фильтрации вложений с заменой.
Среда тестирования не подключается к Интернету. Это затрудняет тестирование агента фильтрации подключений. Для решения этой проблемы можно создать на Интернет-узле список заблокированных IP-адресов посредством запуска файла INTERNET01_create_IP_block_list.bat. Проверьте, установлены ли на вашем компьютере средства поддержки Windows®: это необходимо, так как они включают средство командной строки DNS (dnscmd.exe). В противном случае вам придется потратить много времени, вручную создавая DNS-записи с помощью консоли DNS.
Теперь можно настроить агент фильтрации подключений путем выполнения сценария EDGE01_add_block_list_provider.ps1. Этот сценарий добавляет поставщика списка заблокированных IP-адресов для ip-bl.consolidatedmessenger.com. Это список заблокированных IP-адресов Consolidated Messenger, уже созданный в среде тестирования путем запуска файла INTERNET01_create_IP_block_list.bat на Интернет-узле по описанной выше процедуре. Microsoft IT использует также локальный список заблокированных IP-адресов и список разрешенных IP-адресов, но эти функции, однако, не требуют настройки вручную. Важно отметить, что Microsoft IT не использует поставщики списков разрешенных IP-адресов.
Далее нужно настроить агент фильтра получателей: для этого выполняется сценарий EDGE01_recipient_filter.ps1, который блокирует сообщения, адресованные несуществующим получателям, а также сообщения для почтовых ящиков и списков глобальной рассылки, предназначенных только для внутреннего или внешнего использования.
Агент фильтра отправителей также нуждается в обновлении настроек. Microsoft IT использует фильтры отправителей как контрмеру против засорения почты огромным количеством сообщений, отправляемых с определенных адресов, а также для блокирования конкретных серверов рассылки и аналогичных источников, не имеющих отношения к бизнесу. Кроме того, Microsoft IT использует фильтры получателей для блокирования сообщений с неверной либо отсутствующей информацией об отправителе. Давайте попробуем применить эту настройку в среде тестирования; для этого мы должны выполнить сценарий EDGE01_sender_filter.ps1 на пограничном транспортном сервере.
Если вы хотите отразить конфигурацию Microsoft IT, вам понадобится также настроить записи инфраструктуры политик отправителя (SPF) в DNS. Для создания записи SPF, подтверждающей полномочия пограничного транспортного сервера относительно сообщений из вашего домена adventure-works.com, можно использовать мастер записи SPF системы кода отправителя Microsoft, доступный на странице microsoft.com/mscorp/safety/content/technologies/senderid/wizard. Попробуйте указать имя существующего домена в Интернете. В среде тестирования файл INTERNET01_create_SPF_record.bat можно запустить на Интернет-узле.
Вот и все! Больше никакие параметры настраивать не требуется, поскольку большинство агентов имеют вполне приемлемые настройки по умолчанию. Для быстрой проверки наиболее важных настроек по умолчанию для агентов правил пограничного сервера, идентификатора отправителя, анализа протокола и фильтра содержимого выполните сценарий EDGE01_check_defaults.ps1 на пограничном транспортном сервере.

Агенты пограничного транспортного сервера в действии
А теперь давайте посмотрим, как работают агенты пограничного транспортного сервера в некоторых реалистичных сценариях обмена сообщениями. Для отправки тестовых сообщений на пограничный транспортный сервер я использовал SMTP и службу POP3, исполняющую в Windows Server 2003 и Outlook® Express роль клиента обмена сообщениями. Изменять настройки по умолчанию почти не пришлось; я только проверил, активировано ли ведение журнала.
Однако прежде всего обратите внимание на следующее: не выполняйте никакие инструкции и не запускайте сценарии, описанные в этом разделе, если ваша среда тестирования подключена к каким-либо рабочим системам или Интернету. Выполняя тестирование, вы действуете на свой страх и риск.
Итак, для начала я протестирую агент фильтра подключений. Он удостоился чести быть первым, поскольку это самый «работящий» агент на пограничном транспортном сервере. В Майкрософт агент фильтра подключений блокирует около 88 процентов всех отправляемых в Интернете сообщений. За обычный рабочий день предпринимается порядка 13 миллионов попыток отправки сообщений, из них только 1,5 миллиона — от надежных отправителей.
Давайте попробуем отправить сообщение от имени Fabrikam.User@Fabrikam.com по адресу Administrator@adventure-works.com. Если все работает нормально, указанный адресат не получит наше сообщение. А пользователь Fabrikam.User получит уведомление о состоянии доставки (DSN), в котором будет сказано, что при доставке сообщения получателю произошла ошибка. Пользователь Fabri- kam.User проверяет адрес получателя, убеждается, что он введен верно, и заново отправляет сообщение. Но ему опять приходит то же самое уведомление DNS. Он звонит в службу поддержки и объясняет ситуацию. Оказывается, он не первый, кто столкнулся с такой проблемой. Фактически теперь никто из Fabrikam не сможет взаимодействовать с Adventure Works. Что-то явно изменилось. И эта проблема требует немедленного решения. Желая поскорее разобраться, в чем тут дело, вы проверяете журналы SMTP в папке %systemroot%\system32\Logfiles\SMTPSVC1 на INTERNET01, и сразу же обнаруживаете причину всех своих бед: она показана красным шрифтом на рис. 3.
Figure 3 Журнал SMTP отражает суть проблемы (Close Figure 3)
... 220 mail.adventure-works.com Microsoft ESMTP MAIL Service ready at Thu,
31 May 2007 12:21:33 -0700,
... EHLO, -, INTERNET01,
... 250-mail.adventure-works.com Hello [192.168.1.100],
... MAIL, -, FROM:<Fabrikam.User@fabrikam.com> SIZE=840,
... 250 2.1.0 Sender OK,
... RCPT, -, TO:<Administrator@adventure-works.com>,
... 550 5.7.1 E-mail rejected because your IP address is listed by
ip-bl.consolidatedmessenger.com. Please visit
http://www.consolidatedmessenger.com/ip-bl for more information.
If you still need assistance, contact cmipbl@adventure-works.com.,
... RSET, -, -,
... 250 2.0.0 Resetting,
... QUIT, -, -,
... 221 2.0.0 Service closing transmission channel,
Из сообщения об ошибке 550 вы узнаете, что Consolidated Messenger поместил IP-адрес вашего Интернет-узла в список заблокированных IP-адресов. Теперь все понятно. Вы связываетесь с Consolidated Messenger, чтобы удалить свой адрес из этого списка. Очень скоро вы узнаете, что попасть в список заблокированных адресов Consolidated Messenger намного проще, чем быть удаленным из него. Для этого вам потребуется несколько дней, если не недель.
В стремлении как можно быстрее разрешить возникшую ситуацию вы обращаетесь в Adventure Works по адресу cmipbl@adventure-works.com. В отправленном с адреса Fabrikam.Admin@Fabrikam.com сообщении вы описываете ситуацию и просите разблокировать IP-адрес вашего узла (в данном случае 192.168.1.100). После установления вашей личности Adventure Works разблокирует адрес с помощью приведенной ниже команды, предоставляющей временное исключение, срок действия которого истекает через 30 дней.
Add-IPAllowListEntry -IPAddress 192.168.1.100
-ExpirationTime (get-date).AddDays(30)
Тридцати дней вам вполне хватит на выяснение отношений с Consolidated Messenger, чтобы Adventure Works не приходилось каждый раз вручную поддерживать это исключение. Предоставляя исключения с автоматическим истечением срока действия, Adventure Works максимально снижает административные издержки, связанные с поддержкой списков разрешенных IP-адресов.

Надежные отправители
А теперь давайте протестируем функцию осведомленности о надежных отправителях при фильтрации содержимого. Это новое и интересное средство, позволяющее повысить точность фильтрации нежелательной почты. Служба EdgeSync распространяет информацию о надежном отправителе из внутренней среды на пограничные транспортные серверы в хэшированной и зашифрованной форме. Эта информация помогает агенту фильтра содержимого принимать правильные решения в процессе фильтрации. От вас требуется только ввести информацию о надежном отправителе (список надежных отправителей, список надежных получателей, список запрещенных отправителей и внешние контакты) в службу каталогов Active Directory® с помощью командлета Update-SafeList, а затем продублировать эту информацию на пограничном транспортном сервере, воспользовавшись командлетом Start-EdgeSynchronization. Microsoft IT регулярно запускает командлет Update-SafeList в нерабочее время. В нашей тестовой среде достаточно будет вручную запустить соответствующий сценарий (HUB-MBX-01_update_safelist.ps1).
Первым делом следует выполнить очистку среды тестирования, запустив сценарий EDGE01_clean_up.ps1 на пограничном транспортном сервере для удаления созданных ранее записей в списке разрешенных IP-адресов. Это необходимо сделать, так как агент фильтра содержимого не работает с сообщениями из источников, входящих в этот список. Затем необходимо удалить из списка заблокированных адресов Consolidated Messenger запись для 100.1.168.192.ip-bl.consolidatedmessenger.com путем запуска файла INTERNET01_clean_up.bat на Интернет-узле. Если этого не сделать, моделируемый Интернет-узел не сможет отправлять сообщения, как было показано ранее.
И, наконец, нужно отправить сообщение, которое агент фильтра содержимого почти наверняка примет за нежелательную почту. Это довольно сложная задача, поскольку агент фильтра содержимого использует в качестве порогового значения для отклонения сообщения уровень вероятности нежелательной почты (SCL) по умолчанию, что позволяет доставлять большинство сообщений пользователям с минимальным количеством ошибочных срабатываний. Методом проб и ошибок мне удалось найти такое сообщение, в котором уровень SCL достигает порога отклонения. Чтобы отправить такое сообщение с адреса Contoso.User@Contoso.com, запустите сценарий INTERNET01_contoso_msg.vbs на Интернет-узле.
Мои сценарии используют для отправки сообщения в службу SMTP на INTERNET01 анонимное SMTP-подключение. Для этого нужно настроить службу SMTP на ретрансляцию сообщений анонимным пользователям. В диспетчере служб IIS откройте свойства виртуального сервера SMTP по умолчанию. На вкладке «Доступ» нажмите кнопку «Ретрансляция», а затем выберите вариант «Все, кроме нижеперечисленных». Чуть позже я объясню, чем обусловлен выбор этого параметра.
После запуска сценария для отправки этого сообщения пользователь Contoso.User должен получить уведомление DNS об ошибке при доставке сообщения с указанием кода диагностики: smtp;550 5.7.1 Сообщение отклонено в связи с ограничениями по содержимому. Эту запись можно также найти в журнале SMTP на Интернет-узле, а если вы выполните команду Get-AgentLog | Select-Object -Last 1 на пограничном транспортном сервере для отображения последней записи из журнала агентов, вы увидите, что сообщение было отклонено из-за того, что его уровень SCL равен 7, как показано на рис. 4.
Рис. 4 Сообщение заблокировано в связи с ограничениями по содержимому.
Рис. 4 Сообщение заблокировано в связи с ограничениями по содержимому.
Отныне пользователь Contoso.User больше не является отправителем нежелательной почты. К сожалению, в этот раз сообщение не было отправлено, однако пользователь Contoso.User обычно имеет возможность связываться с получателями в Adventure Works. Итак, Contoso.User информирует администратора в другом сообщении о том, что его исходное сообщение было по ошибке заблокировано. Администратор знает пользователя Contoso.User и потому добавляет его в список надежных отправителей, чтобы сообщения этого пользователя больше не блокировались фильтрами нежелательной почты. В программе Office Outlook 2007 для этого нужно щелкнуть правой кнопкой полученное от пользователя Contoso.User сообщение, выбрать пункт «Нежелательная почта», а затем «Добавить отправителя в список надежных отправителей».
Командлет Update-SafeList запускается через определенные промежутки времени в целях обновления данных списка надежных отправителей в службе Active Directory, и после очередной синхронизации пограничного сервера Contoso.User сможет беспрепятственно общаться с администратором без ложных срабатываний. Для моделирования этой процедуры запустите сценарий HUB-MBX-01_update_safelist.ps1.
Теперь запустите сценарий INTERNET01_contoso_msg.vbs для повторной отправки сообщения пользователя Contoso.User. После этого проверьте журнал агентов на пограничном транспортном сервере, используя команду Get-AgentLog | Select-Object -Last 1, и в разделе ReasonData вы увидите, что фильтрация содержимого в этом случае не выполнялась. Отныне никаких ложных срабатываний для пользователя Contoso.User!

Нежелательная почта: атака
В завершение наших тестовых запусков давайте попробуем провести испытания в условиях, максимально приближенных к реальным. Как вы, конечно же, заметили, в ходе предыдущего тестирования я настроил Интернет-узел как открытый ретранслятор, превратив его тем самым в настоящую находку для отправителей нежелательной почты. Давайте посмотрим, что случится, если некий злоумышленник Spam.Sender@cohovineyards.com обнаружит это слабое место и использует его для своих неблаговидных целей — то есть для отправки тысяч нежелательных сообщений в Adventure Works. Сценарий INTERNET01_spam_msg.vbs отправляет всего одно нежелательное сообщение, но его можно отредактировать таким образом, чтобы он отправлял намного больше сообщений. Для этого нужно изменить значение max_loop.
Для моделирования атаки я отправил 1000 сообщений на свой взломанный узел для ретрансляции на пограничный транспортный сервер. Служба SMTP ограничивает количество сообщений на одно исходящее подключение числом 20, поэтому от начала ретрансляции нежелательных сообщений до активации агента анализа протокола может пройти некоторое время.
Агент анализа протокола помогает агенту фильтра подключений, автоматически обрабатывая записи в списке заблокированных IP-адресов на основе анализа протокола SMTP и обновлений службы репутации IP-адресов из центра обновлений Microsoft. В данном случае анализ протокола SMTP «отловил» нежелательные сообщения. Агент анализа протокола отслеживает уровень SCL каждого сообщения, чтобы вычислить среднее значение SCL, которое используется для определения уровня репутации отправителя (SRL). По мере поступления все большего и большего количества нежелательных сообщений уровень SRL Интернет-узла увеличивается до тех пор, пока не превысит порог блокировки. Тогда узел на 24 часа помещается в список заблокированных IP-адресов. Больше никакой нежелательной почты с этого адреса! Это действие выполняется автоматически. Участие администратора не требуется.
На рис. 5 показана конечная запись в списке заблокированных адресов и соответствующие изменения в обработке сообщений. Прежде чем блокировать узел, пограничный транспортный сервер отклоняет каждое нежелательное сообщение в течение события OnEndOfData, поскольку именно агент фильтра содержимого обрабатывает каждое сообщение на основании порогового значения SCL (см. рис. 4). Сообщение, хотя и не успешно, было отправлено. После блокировки узла подключение было отклонено агентом фильтра подключений в ходе события OnMailCommand. Теперь отправка сообщений невозможна. Это позволяет освободить полосу пропускания сети и ресурсы обработки благодаря отключению отправителей нежелательной почты до отправки сообщений.
Рис. 5 Блокирование нежелательного Интернет-узла
Рис. 5 Блокирование нежелательного Интернет-узла

Дополнительное тестирование
Помимо уже перечисленных, существует, разумеется, еще множество других сценариев и функций агентов, которые можно протестировать. Например, вы можете протестировать фильтрацию отправителей. Для этого нужно отправить сообщения с адреса Blocked.User@Contoso.com или Blocked.User@Fabrikam.com. Также вы можете протестировать фильтрацию получателей. Для этого отправьте сообщения на адрес Blocked.User@adventure-works.com. Кроме того, вы можете воспользоваться средством Telnet для моделирования атаки с целью сбора существующих адресов с различными интервалами искусственной задержки ответов. Microsoft IT использует интервал по умолчанию, равный 5 сек, для ответа SMTP с кодом 5YZ соединителю получения с выходом в Интернет. Этого вполне достаточно для того, чтобы атака по сбору существующих адресов стала нецелесообразной для отправителей нежелательной почты. Однако с помощью командлета Set-ReceiveConnector вы можете использовать другие значения, как показано в сценарии EDGE01_tarpitting.ps1.
Кроме того, вы можете пойти еще дальше и проверить файлы моментальных снимков, которые создаются при трассировке конвейера и отображают сообщения от пользователя Contoso.User@Contoso.com. Проверьте метки антивирусных средств, X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0, которые Forefront Security использует для маркировки сообщений как проверенных. Когда Forefront Security на транспортном сервере-концентраторе находит эту метку с информацией о последней версии, проверять сообщение второй раз уже не требуется. При попытке обмануть средство Forefront Security путем вставки в сообщения ложных меток вы получите возможность увидеть брандмауэр заголовков в действии: он удалит эти метки сразу же после события OnDataCommand, задолго до того, как активируется событие OnSubmittedMessage, вызывающее агент маршрутизации Forefront Security.
Просматривая заголовки сообщений в файлах моментальных снимков, вы, возможно, захотите создать тестовую запись инфраструктуры политик отправителя (SPF) для Contoso.com, идентифицирующую неверный IP-адрес как надежного отправителя. Одним из способов выполнения этого действия является запуск файла INTERNET01_wrong_SPF_record.bat на Интернет-узле. Затем следует отправить пробное сообщение с адреса Contoso.User@Contoso.com и посмотреть на заголовки X-MS-Exchange-Organization-SenderIdResult и Received-SPF:
X-MS-Exchange-Organization-SenderIdResult: SoftFail
Received-SPF: SoftFail (EDGE01.extranet.adventure-works.com: domain of transitioning
Contoso.User@Contoso.com discourages use of 192.168.1.100 as permitted sender)

Заключение
Как вы уже поняли из этой и предыдущей статей, пограничные транспортные серверы Exchange Server 2007 включают полный комплект транспортных агентов для реализации надежных и высокоточных возможностей борьбы с нежелательной почтой, включая фильтр подключений, анализ протокола и фильтр содержимого. Транспортная архитектура является расширяемой и поддерживает создание других агентов для выполнения дополнительных функций. Агент маршрутизации Forefront Security служит отличным примером такого дополнительного агента, интегрирующего Forefront Security для Exchange Server в транспортную архитектуру.
В совокупности с дополнительными функциями, такими как подключения искусственных задержек ответов, брандмауэр заголовков, TLS- шифрование и проверка подлинности, пограничные транспортные серверы обеспечивают все необходимые средства для достижения высокого уровня защиты обмена сообщениями на нескольких уровнях без единых точек отказа. Развертывание пограничных транспортных серверов и средства Forefront Security в демилитаризованной зоне, четко отделенной от внутренней организации Exchange Server позволит вам защитить среду обмена сообщениями от многочисленных атак отправителей нежелательной почты и в то же время обеспечит доставку сообщений от надежных отправителей с очень низким уровнем ложных срабатываний.

Кэй Анкрот (Kay Unkroth) — предприниматель, который более 15 лет работает в качестве инженера по технической поддержке, специалиста по разработке систем, консультанта, инструктора и пишет работы, посвященные главным образом серверным технологиям Майкрософт. Кроме того, Кэй является соучредителем и председателем корпорации Biblioso — эта компания занимается управлением документацией и услугами по локализации.


 Сеть: Настройка удаленного VPN-доступа в ISA Server 2006
Сеть Алан Мэдисон (Alan Maddison)

Настройка удаленного VPN-доступа в ISA Server 2006
Краткий обзор:
  • Протоколы VPN
  • Настройка VPN-подключения типа «сеть-сеть»
  • Настройка VPN-подключения для удаленного доступа
  • Новые возможности ISA Server 2006

Виртуальные частные сети (VPN) способны обеспечить высокий уровень адаптируемости, масштабируемости и контроля над работоспособностью сети. Помимо повышенной безопасности, эти сети способы значительно сократить уровень затрат
на обычные подключения типа «точка-точка». Плюс ко всему они обеспечивают гибкость.
Существует много типов сетей VPN. Некоторые из них используются для подключения мобильных пользователей к корпоративной сети, другие для связи двух географически разделенных сетей. Используемые такими сетями VPN-протоколы и обеспечиваемые ими функциональные возможности также различны. Одни сети предлагают функции защиты, например проверку подлинности и шифрование, в то время как другие могут быть совсем лишены таких возможностей. И очевидно, что какие-то сети проще в настройке и управлении, чем другие.
В этой статье я расскажу о возможностях внедрения сети VPN при помощи сервера Internet Security and Acceleration (ISA) Server 2006. В частности, я постараюсь сделать основной упор на использование функциональных возможностей ISA для VPN на основе типичных примеров: VPN для удаленного доступа пользователей и VPN-подключение типа «сеть-сеть». Оба варианта предусматривают реализацию функций безопасности, гарантирующих конфиденциальность данных и обеспечивающих защиту внутренних сетевых ресурсов.
По первому варианту (VPN-подключение для удаленного доступа) удаленный клиент инициирует VPN-подключение к серверу ISA Server через Интернет. Затем ISA Server подключает удаленного клиента к внутренней сети, предоставляя ему простой доступ к внутренним сетевым ресурсам, включая данные и приложения. Второй вариант VPN-подключения типа «сеть-сеть» является немного более сложным, поскольку здесь используется маршрутизатор, в роли которого может выступать сам сервер ISA. Но такое подключение позволяет тесно связывать различные офисы или филиалы друг с другом или центральным офисом.
Использование ISA Server 2006 для реализации VPN-подключения дает ряд дополнительных преимуществ. Одно из наиболее значимых преимуществ связано с интегрированностью сервера ISA Server, что означает возможность слаженной работы функций VPN и брандмауэра. К тому же, сервер ISA Server включает возможность карантина VPN с функцией Network Access Quarantine Control на Windows Server® 2003 для помещения удаленного компьютера в карантин до проверки его конфигурации сценарием сервера. Это дает дополнительный уровень защиты, позволяя выполнять проверку состояния баз антивирусных программ и локальных политик брандмауэра на удаленном компьютере, прежде чем он получит доступ к внутренним сетевым ресурсам.
Основные преимущества администрирования, предлагаемые сервером ISA Server и VPN-подключением, включают централизованное управление политиками, мониторинг, протоколирование и отчетность. При выполнении повседневных задач эти возможности могут оказаться неоценимыми. В частности, мониторинг в реальном времени и фильтрация журнала дают детальное представление трафика и подключений через ISA Server.

Протоколы VPN
Основные протоколы туннелирования, используемые в VPN-подключении через ISA, обеспечивают первую линию защиты для безопасных подключений. ISA Server поддерживает три протокола: протокол L2TP через IPsec, протокол PPTP и туннельный режим IPSec. Последний протокол поддерживается только подключениями типа «сеть-сеть» и главным образом используется для обеспечения взаимодействия между маршрутизаторами и другими операционными системами, не поддерживающими L2TP или PPTP.
Протокол L2TP совмещен с IPsec, поскольку в L2TP отсутствует собственный механизм защиты данных. Такое сочетание с туннелированием через IPsec, обеспечивающим надежные методы проверки подлинности и шифрования, образует превосходное решение. Протокол PPTP работает совместно с протоколом MS CHAP версии 2 или EAP-TLS для обеспечения проверки подлинности, и MPPE — как вы уже догадались — для шифрования.
Выбор протокола L2TP через IPsec или PPTP часто зависит от специфичных для организации факторов. Протокол L2TP через IPsec позволит применить более сложные и совершенные методы шифрования, а также поддерживает большее число сетей (включая IP, X.25, Frame Relay и ATM). Однако протокол PPTP проще реализовать и он, как правило, предъявляет меньше требований. И все-таки, в случаях, когда организационные ограничения отсутствуют, лучшим вариантом считается использование протокола L2TP через IPsec.

VPN-подключение типа «сеть-сеть»
Выход ISA Server версии 2006 ознаменовал значительный прорыв в упрощении настройки VPN-подключения типа «сеть-сеть». В прежних версиях настройка включала гораздо большее число шагов. В этом примере мы рассмотрим одну удаленную сеть, подключенную к центральному офису по протоколу L2TP через IPsec и ISA Server в обеих точках. Сначала необходимо выполнить настройку сервера ISA Server в центральном офисе, а затем — на удаленном компьютере.
Первым делом нужно настроить локальные учетные записи пользователей на обоих серверах ISA Server. Подобное удостоверение пользователей обеспечит безопасную среду для подключения удаленного или основного сервера ISA Server. Имя такой учетной записи должно совпадать с именем VPN-подключения, создаваемого в консоли администрирования ISA. Например, в рамках соглашения об именовании хорошим именем пользователя будет «Site VPN» на сервере ISA Server в головном офисе (с указанием на удаленную сеть) и «HQ VPN» на удаленном сервере ISA Server. После того, как эти действия будут выполнены, откройте свойства учетной записи, перейдите на вкладку «Dial In» (Удаленное подключение), и установите флажок «Allow Access» (Разрешить доступ).
Следующим шагом после создания локальной учетной записи пользователя будет создание сертификата инфраструктуры открытых ключей (PKI), который будет использоваться для проверки подлинности между двумя сетями. Можно также использовать предварительный ключ, но использование сертификата всегда более предпочтительно. Самый простой способ установки сертификата для VPN-подключения заключается в непосредственном подключении к центру сертификации предприятия и запросе сертификата через веб-узел сервера сертификатов. Но для этого может потребоваться создание правила доступа, разрешающего подключение вашего сервера ISA Server к серверу сертификатов через HTTP.
Если вы работали в предыдущих версиях ISA Server, то заметите, что интерфейс ISA Server 2006 (см. рис. 1) намного более интуитивно понятен. Если выделить VPN-подключение в левой панели, то в центральной и правой областях открываются контекстные параметры конфигурации и задач.
Рис. 1 ISA Server 2006 имеет более интуитивно понятный интерфейс
Рис. 1 ISA Server 2006 имеет более интуитивно понятный интерфейс
Запустите мастер создания сетей VPN типа «сеть-сеть», щелкнув задачу «Создать VPN-подключение типа "сеть-сеть"» в правой панели. В окне запущенного мастера введите имя сети типа «сеть-сеть». Это имя должно совпадать с именем учетной записи пользователя, созданной ранее. После ввода имени нажмите кнопку «Далее». В следующем окне (см. рис. 2) выберите VPN-протокол — в нашем примере это L2TP через IPsec. Нажмите кнопку «Далее» и мастер предупредит, что должно быть доступным сопоставление учетной записи пользователя с именем сети. Так как это мы уже учли, можно просто нажать кнопку «ОК», чтобы перейти к следующему экрану.
Рис. 2 Выберите необходимый VPN-протокол
Рис. 2 Выберите необходимый VPN-протокол
Теперь нужно создать пул IP-адресов. Здесь можно пойти двумя путями. Можно создать пул статических адресов на сервере ISA Server, или же использовать существующий DHCP-сервер для выполнения назначения адресов. Поскольку можно принять оба способа, ваше решение должно зависеть от политики компании по отношению к конкретному варианту. В открывшемся окне теперь необходимо ввести имя удаленного сервера. Укажите полное доменное имя (FQDN) удаленного сервера и затем введите учетные данные пользователя для подключения. Помните, что указываемые данные должны соответствовать учетной записи пользователя, созданной на удаленном сервере ISA Server. В нашем примере это будет учетная запись пользователя HQ VPN (см. рис. 3.
Рис. 3 Введите полное доменное имя (FQDN) на удаленном сервере
Рис. 3 Введите полное доменное имя (FQDN) на удаленном сервере
В следующем окне, выберите метод исходящей проверки подлинности. (Как сказано выше, лучше всего всегда использовать сертификат.) Затем укажите диапазон IP-адресов, используемый для удаленной внутренней сети.
После этого, в версии ISA Server 2006 Enterprise Edition, мастер позволит настроить балансировку сетевой нагрузки по назначенным IP-адресам удаленной сети. В версии ISA Server 2006 Standard Edition, пропустите шаг настройки балансировки сетевой нагрузки и перейдите непосредственно к следующему экрану (см. рис. 4), и создайте сетевое правило для маршрутизации трафика от удаленной сети в локальную сеть.
Рис. 4 Создайте сетевое правило для маршрутизации трафика
Рис. 4 Создайте сетевое правило для маршрутизации трафика
Также, в следующем окне необходимо создать правило доступа. При настройке этого правила будут доступны три варианта использования протоколов: можно разрешить весь исходящий трафик, весь исходящий трафик за исключением выбранного по определенному протоколу или только трафик по выбранным протоколам. В большинстве случаев потребуется разрешить весь исходящий трафик.
Теперь почти все готово. На этом этапе мастер представит сводку настроек, и после нажатия кнопки «Готово» VPN-подключение типа «сеть-сеть» будет создано. Откроется диалоговое окно с предложением включения правил системной политики для загрузки списка отзыва сертификатов, где нужно нажать кнопку «Да», чтобы включить это правило. Затем мастер выводит сведения о любых дополнительных шагах настройки, которые могут потребоваться. По завершении настройки сервера ISA Server для основной сети, нужно проделать все те же шаги для настройки удаленной сети. После этого пользователи обеих сетей смогут связываться по сети VPN.

VPN-подключения для удаленного доступа
Настройка VPN-подключения для клиентского доступа намного проще (см. рис. 5). В левой панели консоли администрирования ISA щелкните VPN-подключение. Затем выберите пункт «Включить доступ VPN-клиентов» в правой панели. Откроется окно с предупреждением о том, что применение этих настроек может привести к перезагрузке службы маршрутизации и удаленного доступа. (Так как в связи с этим могут возникнуть проблемы сети, возможно, вы решите выполнить эти изменения во время запланированного обслуживания.) Нажмите «ОК», чтобы закрыть окно с предупреждением. Сервер ISA Server применяет системную политику, разрешающую трафик VPN-клиентов через ISA Server. Чтобы просмотреть это правило, в консоли администрирования ISA Server выберите «Политика межсетевого экрана» и затем задачу «Отображать правила системной политики».
Рис. 5 Настройка VPN-подключения для удаленного доступа
Рис. 5 Настройка VPN-подключения для удаленного доступа
Также применяется сетевое правило по умолчанию, разрешающее маршрутизацию между внутренней сетью и двумя VPN-сетями (VPN-клиенты и VPN-клиенты, помещенные в карантин). Чтобы просмотреть или изменить это сетевое правило, выберите пункт «Сети» в левой панели и перейдите на вкладку «Сетевые правила» в центральной области.
Теперь нужно настроить доступ VPN-клиентов. Здесь необходимо задать три дополнительных параметра: группы безопасности Windows, которым разрешен доступ, протоколы, доступные клиентам и сопоставление пользователей. Диалоговое окно для настройки этих параметров показано на рис. 6.
Рис. 6 Настройка доступ VPN-клиентов
Рис. 6 Настройка доступ VPN-клиентов
На вкладке «Группы» нужно просто выбрать группы Windows, которым будет разрешен удаленный доступ через VPN. С точки зрения администрирования, мне кажется разумным создание одной группы, которой будет присвоено разрешение. Управление удаленным доступом в этом случае будет очень простым.
На вкладке «Протоколы» по умолчанию включен только протокол PPTP. Абсолютно точно нужно включить протокол L2TP через IPsec, если это вообще возможно в вашей среде.
На вкладке «Сопоставление пользователей» необходимо сопоставить учетные записи пользователей из областей имен, таких как RADIUS (Remote Authentication Dial-In User Service), с учетными записями Windows, чтобы гарантировать правильное применение политик доступа. После того как эти параметры настройки будут заданы и применены на сервере ISA Server, можно считать, что все готово. Теперь клиенты должны иметь возможность свободного доступа к данным и приложениям внутренней сети по VPN.

Усовершенствования в ISA Server 2006
В ISA Server 2006 представлен ряд усовершенствований, обеспечивающих расширенные возможности и повышенную производительность по сравнению с предыдущими версиями. Новые функции (среди которых сжатие HTTP, поддержка фоновой интеллектуальной службы передачи (BITS) и качество обслуживания (QoS)) дают различные возможности оптимизации использования сети. Безусловно, несмотря на эти возможности, не следует отказываться от использования привычных технологий оптимизации пропускной способности, образующих основу ISA Server, а также кэширования.
Сжатие HTTP поддерживается различными продуктами Microsoft уже на протяжении определенного времени. Оно было реализовано в обозревателе Internet Explorer®, начиная с версии 4, и Windows Server с версии Windows® 2000. Однако поддержка сжатия HTTP (включая отраслевые стандарты GZIP и алгоритмы Deflate) была впервые реализована в этой версии ISA Server.
Что это значит? Благодаря сжатию HTTP, любой веб-обозреватель, поддерживающий стандарт HTTP 1.1, может получать сжатое содержимое с любого веб-узла. Однако следует помнить, что сжимается только входящий трафик — сжатие для исходящих подключений не используется.
Сжатие HTTP представляет собой общие параметры HTTP-политик, действующие для всего HTTP-трафика, проходящего через ISA Server, и не может ассоциироваться с определенным сетевым правилом. Тем не менее существует возможность включения сжатия HTTP для каждого прослушивателя. Это можно настроить в мастере веб-прослушивателя.
Сжатие HTTP, настроить которое можно в области параметров «Общие» в левой панели, по умолчанию включено. Но, как видно на рис. 7, необходимо задать элементы сети, для которых будет использоваться сжатие. Если говорить о примере настройки VPN-подключения типа «сеть-сеть», то здесь необходимо перейти на вкладку «Возвращать сжатые данные» и добавить элемент сети VPN, созданный ранее. Кроме того, можно также настроить тип сжимаемого содержимого. ISA Server 2006 уже включает список стандартных типов содержимого, но вы можете добавить другие типы содержимого на панели задач «Политики межсетевого экрана» на вкладке «Инструментарий». Помните, что на вкладке «Возвращать сжатое содержимое» сжатие содержимого сервером ISA Server можно настроить для данных, прежде чем они будут возвращены клиенту. Сжатие веб-сервером данных до их отправки на ISA Server можно задать на вкладке «Запрашивать сжатые данные».
Рис. 7 Настройте сжатие HTTP
Рис. 7 Настройте сжатие HTTP
Фоновая интеллектуальная система передачи представляет собой службу асинхронной передачи файлов для HTTP и HTTPS-трафика. Windows Server 2003 включает службу BITS версии 1.5, в которой реализована поддержка загрузки и отправки, хотя для отправки необходимы службы IIS версии 5.0 или выше. Являясь интеллектуальной службой передачи файлов, служба BITS способна анализировать сетевой трафик и использовать только свободную часть пропускной способности сети. Кроме того, передача файлов осуществляется динамически и служба BITS реагирует на «всплески» сетевого трафика, сокращая собственную нагрузку на сеть. Служба BITS в этом случае дает возможность загрузки или отправки файлов большого размера, что не скажется негативно на использовании другой сети. Для администратора это означает меньшее число обращений с жалобами на низкую производительность сети. А это хорошо!
У службы BITS также есть другие плюсы: она гарантирует удобство работы пользователей и положительно влияет на производительность сети. Например, служба BITS передает файлы в виде двоичных данных, что означает возможность возобновления передачи (без необходимости запуска загрузки с начала), которая была прервана в результате перебоев в сети. А еще в ISA Server 2006 реализована встроенная поддержка функции кэширования для центра обновлений Microsoft, которая использует кэширование BITS для оптимизации обновлений.
Протокол дифференцированных служб (DiffServ) обеспечивает приоритезацию пакетов (или QoS) для HTTP и HTTPS-трафика. Другими словами, в зависимости от настроек в ISA Server, приоритет будет отдаваться определенному типу трафика. Эта функция полезна для сетей с ограничением пропускной способности, например по объему трафика или скорости сети. По спецификации инженерной группы по развитию Интернета (IETF), протокол DiffServ представляет собой механизм управления трафиком на основе классов. Таким образом, протокол DiffServ способен различать трафик по типам и осуществлять соответствующее управление, отдавая предпочтение в первую очередь трафику с высоким приоритетом.
Для реализации этой возможности ISA Server работает совместно с маршрутизаторами, поддерживающими QoS. Важно обеспечить, чтобы биты DiffServ в ISA Server соответствовали приоритетам, заданным для маршрутизаторов, если необходимо, чтобы пакеты передавались с одинаковой приоритезацией.
Будучи реализованным в ISA Server, этот тип приоритезации пакетов представляет собой общие параметры HTTP-политик, которые применяются ко всему HTTP-трафику, проходящему через ISA Server 2006 с помощью веб-фильтра DiffServ. Это означает, что ISA Server не поддерживает DiffServ для других протоколов и фактически может пропускать существующие биты DiffServ в отличном от HTTP трафике.
Как показано на рис. 8, службы DiffServ реализованы в виде веб-фильтра, который можно выбрать в поле «Надстройки» в левой панели. Важно не изменять настройки по умолчанию или порядок приоретизиации фильтра DiffServ, поскольку серверу ISA Server необходимо измерять запрос или ответ в момент обработки.
Рис. 8 Вид веб-фильтра DiffServ
Рис. 8 Вид веб-фильтра DiffServ
Если внимательно посмотреть на рис. 8, можно заметить, что фильтр DiffServ по умолчанию отключен. Чтобы включить фильтр, просто щелкните «Включить выбранные фильтры» на панели задач и затем настройте фильтр. Поскольку приоритезация пакетов DiffServ в ISA Server основана на определенных URL-адресах или доменах, эти сведения необходимо добавить в настройки DiffServ. Для этого в левой панели консоли управления перейдите на закладку «Общие», а затем в области «Общие параметры HTTP-политики» выберите «Указать настройки DiffServ». После изменения настроек определите приоритеты, а также URL-адреса и домены для приоритезации. ISA Server 2006 включает новые мощные возможности настройки удаленного доступа VPN-клиентов или создания сетей VPN типа «сеть-сеть». Это решение должно стать первым кандидатом на использование при реализации сетей VPN.

Алан Мэдисон (Alan Maddison) — старший консультант по технологической практике Майкрософт в корпорации MTI Technology Corporation. Его основной специализацией являются Active Directory, Exchange Server и виртуализация.


 SQL Server: Оптимизация производительности запросов SQL Server
SQL Server Мацей Пилеки (Maciej Pilecki)

Оптимизация производительности запросов SQL Server
Краткий обзор:
  • Анализ планов выполнения
  • Оптимизация запросов
  • Определение запросов, нуждающихся в настройке

В процессе оптимизации сервера базы данных требуется настройка производительности отдельных запросов. Это так же (а может быть, и более) важно, чем настройка других элементов, влияющих на производительность сервера, например конфигурации аппаратного и программного обеспечения.
Даже если сервер базы данных использует самое мощное аппаратное обеспечение на свете, горсточка плохо себя ведущих запросов может плохо отразиться на его производительности. Фактически, даже один неудачный запрос (иногда их называют «вышедшими из-под контроля») может вызвать серьезное снижение производительности базы данных.
Напротив, тонкая настройка набора наиболее дорогих или часто выполняемых запросов может сильно повысить производительность базы данных. В этой статье я планирую рассмотреть некоторые технологии, которые можно использовать для идентификации или тонкой настройки самых дорогих и плохо работающих запросов к серверу.

Анализ планов выполнения
Обычно при настройке отдельных запросов стоит начать с рассмотрения плана выполнения запроса. В нем описана последовательность физических и логических операций, которые SQL ServerTM использует для выполнения запроса и вывода желаемого набора результатов. План выполнения создает в фазе оптимизации обработки запроса компонент ядра базы данных, который называется оптимизатором запросов, принимая во внимание много различных факторов, например использованные в запросе предикаты поиска, задействованные таблицы и условия объединения, список возвращенных столбцов и наличие полезных индексов, которые можно использовать в качестве эффективных путей доступа к данным.
В сложных запросах количество всех возможных перестановок может быть огромным, поэтому оптимизатор запросов не оценивает все возможности, а пытается найти «подходящий» для данного запроса путь. Дело в том, что найти идеальный план возможно не всегда. Даже если бы это было возможно, стоимость оценки всех возможностей при разработке идеального плана легко перевесила бы весь выигрыш в производительности. С точки зрения администратора базы данных важно понять процесс и его ограничения.
Существует несколько способов извлечения плана выполнения запроса:
  • В Management Studio есть функции отображения реального и приблизительного плана выполнения, представляющие план в графической форме. Это наиболее удобная возможность непосредственной проверки и, по большому счету, наиболее часто используемый способ отображения и анализа планов выполнения (примеры из этой статьи я буду иллюстрировать графическими планами, созданными именно таким способом).
  • Различные параметры SET, например, SHOWPLAN_XML и SHOWPLAN_ALL, возвращают план выполнения в виде документа XML, описывающего план в виде специальной схемы, или набора строк с текстовым описанием каждой операции.
  • Классы событий профайлера SQL Server, например, Showplan XML, позволяют собирать планы выполнения выражений методом трассировки.
Хотя XML-представление плана выполнения не самый удобный для пользователя формат, эта команда позволяет использовать самостоятельно написанные процедуры и служебные программы для анализа, поиска проблем с производительностью и практически оптимальных планов. Представление на базе XML можно сохранить в файл с расширением sqlplan, открывать в Management Studio и создавать графическое представление. Кроме того, эти файлы можно сохранять для последующего анализа без необходимости воспроизводить их каждый раз, как этот анализ понадобится. Это особенно полезно для сравнения планов и выявления возникающих со временем изменений.

Оценка стоимости выполнения
Первое, что нужно понять — это как генерируются планы выполнения. SQL Server использует оптимизатор запроса на основе стоимости, то есть пытается создать план выполнения с минимальной оценочной стоимостью. Оценка производится на основе статистики распределения доступных оптимизатору на момент проверки каждой использованной в запросе таблицы данных. Если такой статистики нет или она уже устарела, оптимизатору запроса не хватит необходимой информации и оценка, скорее всего, окажется неточной. В таких случаях оптимизатор переоценит или недооценит стоимость выполнения различных планов и выберет не самый оптимальный.
Существует несколько распространенных, но неверных представлений о приблизительной стоимости выполнения. Особенно часто считается, что приблизительная стоимость выполнения является хорошим показателем того, сколько времени займет выполнение запроса и что эта оценка позволяет отличить хорошие планы от плохих. Это неверно. Во-первых, есть много документов касающихся того, в каких единицах выражается приблизительная стоимость и имеют ли они непосредственное отношение ко времени выполнения. Во-вторых, поскольку значение это приблизительно и может оказаться ошибочным, планы с большими оценочными затратами иногда оказываются значительно эффективнее с точки зрения ЦП, ввода/вывода и времени выполнения, несмотря на предположительно высокую стоимость. Это часто случается с запросами, где задействованы табличные переменные. Поскольку статистики по ним не существует, оптимизатор запросов часто предполагает, что в таблице есть всего одна строка, хотя их во много раз больше. Соответственно, оптимизатор выберет план на основе неточной оценки. Это значит, что при сравнении планов выполнения запросов не следует полагаться только на приблизительную стоимость. Включите в анализ параметры STATISTICS I/O и STATISTICS TIME, чтобы определить истинную стоимость выполнения в терминал ввода/вывода и времени работы ЦП.
Здесь стоит упомянуть об особом типе плана выполнения, который называется параллельным планом. Такой план можно выбрать при отправке на сервер с несколькими ЦП запроса, поддающегося параллелизации (В принципе, оптимизатор запроса рассматривает использование параллельного плана только в том случае, если стоимость запроса превышает определенное настраиваемое значение.) Из-за дополнительных расходов на управление несколькими параллельными процессами выполнения, связанными с распределением заданий, выполнением синхронизации и сведением результатов, параллельные планы обходятся дороже, что отражает их приблизительная стоимость. Тогда чем же они предпочтительнее более дешевых, не параллельных планов? Благодаря использованию вычислительной мощности нескольких ЦП параллельные планы обычно выдают результат быстрее стандартных. В зависимости от конкретного сценария (включая такие переменные, как доступность ресурсов с параллельной нагрузкой других запросов) эта ситуации для кого-то может оказаться желательной. Если это ваш случай, нужно будет указать, какие из запросов можно выполнять по параллельному плану и сколько ЦП может задействовать каждый. Для этого нужно настроить максимальную степень параллелизма на уровне сервера и при необходимости настроить обход этого правила на уровне отдельных запросов с помощью параметра OPTION (MAXDOP n).

Анализ плана выполнения
Теперь рассмотрим простой запрос, его план выполнения и некоторые способы повышения производительности. Предположим, что я выполняю этот запрос в Management Studio с включенным параметром включения реального плана выполнения в примере базы данных Adventure Works SQL Server 2005:
SELECT c.CustomerID, SUM(LineTotal)
FROM Sales.SalesOrderDetail od
JOIN Sales.SalesOrderHeader oh
ON od.SalesOrderID=oh.SalesOrderID
JOIN Sales.Customer c ON oh.CustomerID=c.CustomerID
GROUP BY c.CustomerID
В итоге я вижу план выполнения, изображенный на рис. 1. Этот простой запрос вычисляет общее количество заказов, размещенных каждым клиентом в базе данных Adventure Works. Глядя на этот план, вы видите, как ядро базы данных обрабатывает запросы и выдает результат. Графические планы выполнения читаются сверху вниз, справа налево. Каждый значок соответствует выполненной логической или физической операции, а стрелки — потокам данных между операциями. Толщина стрелок соответствует количеству переданных строк (чем толще, тем больше). Если поместить курсор на один из значков оператора, появится желтая подсказка (такая, как на рис. 2) со сведениями о данной операции.
Рис. 1 Пример плана выполнения
Рис. 1 Пример плана выполнения
Рис. 2 Сведения об операции
Рис. 2 Сведения об операции
Глядя на операторы, можно анализировать последовательность выполненных этапов:
  1. Ядро базы данных выполняет операцию сканирования кластеризированных индексов с таблицей Sales.Customer и возвращает столбец CustomerID со всеми строками из этой таблицы.
  2. Затем оно выполняет сканирование индексов (не кластеризированных) над одним из индексов из таблицы Sales.SalesOrderHeader. Это индекс столбца CustomerID, но подразумевается, что в него входит столбец SalesOrderID (ключ кластеризации таблицы). Сканирование возвращает значения обоих столбцов.
  3. Результаты обоих сеансов сканирования объединяются в столбце CustomerID с помощью физического оператора слияния (это один из трех возможных физических способов выполнения операции логического объединения. Операция выполняется быстро, но входные данные приходится сортировать в объединенном столбце. В данном случае обе операции сканирования уже возвратили строки, рассортированные в столбце CustomerID, так что дополнительную сортировку выполнять не нужно).
  4. Затем ядро базы данных выполняет сканирование кластеризированного индекса в таблице Sales.SalesOrderDetail, извлекая значения четырех столбцов (SalesOrderID, OrderQty, UnitPrice и UnitPriceDiscount) из всех строк таблицы (предполагалось, что возвращено будет 123,317 строк. Как видно из свойств Estimated Number of и and Actual Number of Rows на рис. 2, получилось именно это число, так что оценка оказалась очень точной).
  5. Строки, полученные при сканировании кластеризованного индекса, передаются оператору вычисления стоимости, умноженной на коэффициент, чтобы вычислить значение столбца LineTotal для каждой строки на основе столбцов OrderQty, UnitPrice и UnitPriceDiscount, упомянутых в формуле.
  6. Второй оператор вычисления стоимости, умноженной на коэффициент, применяет к результату предыдущего вычисления функцию ISNULL, как и предполагает формула вычисленного столбца. Он завершает вычисление в столбце LineTotal и возвращает его следующему оператору вместе со столбцом SalesOrderID.
  7. Вывод оператора слияния с этапа 3 объединяется с выводом оператора стоимости, умноженной на коэффициент с этапа 6 и использованием физического оператора совпадения значений хэша.
  8. Затем к группе строк, возвращенных оператором слияния по значению столбца CustomerID и вычисленному сводному значению SUM столбца LineTotal применяется другой оператор совпадения значений хэша.
  9. Последний узел, SELECT — это не физический или логический оператор, а местозаполнитель, соответствующий сводным результатам запроса и стоимости.
В созданном на моем ноутбуке плане выполнения приблизительная стоимость равнялась 3,31365 (как видно на рис. 3). При выполнении с включенной функцией STATISTICS I/O ON отчет по запросу содержал упоминание о 1,388 логических операциях чтения из трех задействованных таблиц. Процентное значение под каждым оператором — это его стоимость в процентах от общей приблизительной стоимости всего плана. На плане на рис. 1 видно, что большая часть общей стоимости связана со следующими тремя операторами: сканирование кластеризованного индекса таблицы Sales.SalesOrderDetail и два оператора совпадения значений хэша. Перед тем как приступить к оптимизации, хотелось отметить одно очень простое изменение в моем запросе, которое позволило полностью устранить два оператора.
Рис. 3 Общая приблизительная стоимость выполнения запроса
Рис. 3 Общая приблизительная стоимость выполнения запроса
Поскольку я возвращал из таблицы Sales.Customer только столбец CustomerID, и тот же столбец включен в таблицу Sales.SalesOrderHeaderTable в качестве внешнего ключа, я могу полностью исключить из запроса таблицу Customer без изменения логического значения или результата нашего запроса. Для этого используется следующий код:
SELECT oh.CustomerID, SUM(LineTotal)
FROM Sales.SalesOrderDetail od JOIN Sales.SalesOrderHeader oh
ON od.SalesOrderID=oh.SalesOrderID
GROUP BY oh.CustomerID
Получился другой план выполнения, который изображен на рис. 4.
Рис. 4 План выполнения после устранения из запроса таблицы Customer
Рис. 4 План выполнения после устранения из запроса таблицы Customer
Полностью устранены две операции — сканирование кластеризированного индекса таблицы Customer и слияние Customer и SalesOrderHeader, а совпадение значений хэша заменено на куда более эффективную операцию слияния. При этом для слияния таблиц SalesOrderHeader и SalesOrderDetail нужно вернуть строки обеих таблиц, рассортированные по общему столбцу SalesOrderID. Для этого оптимизатор кластера выполнил сканирование кластеризованного индекса таблицы SalesOrderHeader вместо того, чтобы использовать сканирование некластеризованного индекса, который был бы дешевле с точки зрения ввода/вывода. Это хороший пример практического применения оптимизатора запроса, поскольку экономия, получающаяся при изменении физического способа слияния, оказалась больше дополнительной стоимости ввода/вывода при сканировании кластеризованного индекса. Оптимизатор запроса выбрал получившуюся комбинацию операторов, поскольку она дает минимально возможную примерную стоимость выполнения. На моем компьютере, несмотря на то, что количество логических считываний возросло (до 1,941), временные затраты ЦП стали меньше, и приблизительная стоимость выполнения данного запроса упала на 13 процентов (2,89548).
Предположим, что я хочу еще улучшить производительность запроса. Я обратил внимание на сканирование кластеризованного индекса таблицы SalesOrderHeader, которое теперь является самым дорогим оператором плана выполнения. Поскольку для выполнения запроса нужно всего два столбца, можно создать некластеризованный индекс, где содержатся только эти два столбца. Таким образом, вместо сканирования всей таблицы можно будет просканировать индекс гораздо меньшего размера. Определение индекса может выглядеть примерно так:
CREATE INDEX IDX_OrderDetail_OrderID_TotalLine
ON Sales.SalesOrderDetail (SalesOrderID) INCLUDE (LineTotal)
Обратите внимание, что в созданном индексе есть вычисленный столбец. Это возможно не всегда — все зависит от определения такого столбца.
Создав этот индекс и выполнив тот же запрос, я получил новый план, который изображен на рис. 5.
Рис. 5 Оптимизированный план выполнения
Рис. 5 Оптимизированный план выполнения
Сканирование кластеризованного индекса таблицы SalesOrderDetail заменено некластеризованным сканированием с заметно меньшими затратами на ввод/вывод. Кроме того, я исключил один из операторов вычисления стоимости, умноженной на коэффициент, поскольку в моем индексе уже есть вычисленное значение столбца LineTotal. Теперь приблизительная стоимость плана выполнения составляет 2,28112 и при выполнении запроса производится 1,125 логических считываний.

Индекс покрытия
Упражнение. Запрос заказа покупателя
Вопрос. Вот пример запроса заказа покупателя. Попробуйте получить определение индекса: выясните, наличие каких столбцов превратит его в индекс покрытия данного запроса и повлияет ли порядок столбцов на производительность.
Ответ. Я предложил рассчитать оптимальный индекс покрытия для создания таблицы Sales.SalesOrderHeader на примере запроса из моей статьи. При этом нужно в первую очередь отметить, что запрос использует только два столбца из таблицы: CustomerID и SalesOrderID. Если вы внимательно прочли эту статью, то заметили, что в случае с таблицей SalesOrderHeader индекс покрытия запроса уже существует, это индекс CustomerID, который косвенно содержит столбец SalesOrderID, являющийся ключом кластеризации таблицы.
Конечно, я объяснял и то, почему оптимизатор запроса не стал использовать этот индекс. Да, можно заставить оптимизатор запроса использовать этот индекс, но это решение было бы менее эффективным, чем существующий план с операторами сканирования кластеризованного индекса и слияния. Дело в том, что оптимизатор запроса пришлось бы принудить либо выполнить дополнительную операцию сортировки, необходимую для использования слияния, либо откатиться назад, к использованию менее эффективного оператора совпадения значений хэша. В обоих вариантах приблизительная стоимость выполнения выше, чем в существующем плане (версия с оператором сортировки работала бы особенно плохо), поэтому оптимизатор запроса не будет их использовать без принуждения. Итак, в данной ситуации лучше сканирования кластеризованного индекса будет работать только некластеризованный индекс в столбцах SalesOrderID, CustomerID. При этом нужно отметить, что столбцы должны идти именно в таком порядке:
CREATE INDEX IDX_OrderHeader_SalesOrderID_CustomerID
ON Sales.SalesOrderHeader (SalesOrderID, CustomerID)
Если вы создадите этот индекс, в плане выполнения будет использовано не сканирование кластеризованного индекса, а сканирование индекса. Разница существенная. В данном случае некластеризованный индекс, который содержит только два столбца, заметно меньше всей таблицы в виде кластеризованного индекса. Соответственно, при считывании нужных данных будет меньше задействован ввод/вывод.
Также этот пример показывает, что порядок столбцов в вашем индексе может существенно повлиять на его эффективность для оптимизатора запросов. Создавая индексы с несколькими столбцами, обязательно имейте это в виду.

Индекс, созданный из таблицы SalesOrderDetail, представляет собой так называемый «индекс покрытия». Это некластеризованный индекс, где содержатся все столбцы, необходимые для выполнения запроса. Он устраняет необходимость сканирования всей таблицы с помощью операторов сканирования таблицы или кластеризованного индекса. По сути индекс представляет собой уменьшенную копию таблицы, где содержится подмножество ее столбцов. В индекс включаются только столбцы, которые необходимы для ответа на запрос или запросы, то есть только то, что «покрывает» запрос.
Создание индексов покрытия наиболее частых запросов — один из самых простых и распространенных способов тонкой настройки запроса. Особенно хорошо он работает в ситуациях, когда в таблице несколько столбцов, но запросы часто ссылаются только на некоторые из них. Создав один или несколько индексов покрытия, можно значительно повысить производительность соответствующих запросов, так как они будут обращаться к заметно меньшему количеству данных и, соответственно, количество вводов/выводов сократится. Тем не менее, поддержка дополнительных индексов в процессе модификации данных (операторы INSERT, UPDATE и DELETE) подразумевает некоторые расходы. Следует четко определить, оправдывает ли увеличение производительности эти дополнительные расходы. При этом учтите характеристики своей среды и соотношение количества запросов SELECT и изменений данных.
Не бойтесь создавать индексы с несколькими столбцами. Они бывают значительно полезнее индексов с одним столбцом, и оптимизатор запросов чаще их использует для покрытия запроса. Большинство индексов покрытия содержит несколько столбцов.
С моим примером запроса можно сделать еще кое-что. Создав индекс покрытия таблицы SalesOrderHeader, можно дополнительно оптимизировать запрос. При этом будет использовано сканирование некластеризованного индекса вместо кластеризованного. Предлагаю вам выполнить это упражнение самостоятельно. Попробуйте получить определение индекса: выясните, наличие каких столбцов превратит его в индекс покрытия данного запроса и повлияет ли порядок столбцов на производительность. Решение см. в боковой панели "Упражнение. Запрос заказа покупателя".

Индексированные представления
Если выполнение моего примера запроса очень важно, я могут пойти немного дальше и создать индексированное представление, в котором физически хранятся материализованные результаты запроса. При создании индексированных представлений существуют некоторые предварительные условия и ограничения, но если их удастся использовать, производительность сильно повысится. Обратите внимание, что расходы на обслуживание индексированных представлений выше, чем у обычных индексов. Их нужно использовать с осторожностью. В данном случае определение индекса выглядит примерно так:
CREATE VIEW vTotalCustomerOrders
WITH SCHEMABINDING
AS
SELECT oh.CustomerID, SUM(LineTotal) AS OrdersTotalAmt, COUNT_BIG(*) AS TotalOrderLines
FROM Sales.SalesOrderDetail od
JOIN Sales.SalesOrderHeader oh
ON od.SalesOrderID=oh.SalesOrderID
GROUP BY oh.CustomerID
Обратите внимание на параметр WITH SCHEMABINDING, без которого невозможно создать индекс такого представления, и функцию COUNT_BIG(*), которая потребуется в том случае, если в нашем определении индекса содержится обобщенная функция (в данном случае SUM). Создав это представление, я могу создать и индекс:
CREATE UNIQUE CLUSTERED INDEX CIX_vTotalCustomerOrders_CustomerID
ON vTotalCustomerOrders(CustomerID)
При создании этого индекса результат запроса, включенного в определение представления, материализуется и физически сохраняется на указанном диске. Обратите внимание, что все операции модификации данных исходной таблицы автоматически обновляют значения представления на основе определения.
Если перезапустить запрос, то результат будет зависеть от используемой версии SQL Server. В версиях Enterprise или Developer оптимизатор автоматически сравнит запрос с определением индексированного представления и использует это представление, вместо того чтобы обращаться к исходной таблице. На рис. 6 приведен пример получившегося плана выполнения. Он состоит из одной-единственной операции — сканирования кластеризованного индекса, который я создал на основе представления. Приблизительная стоимость выполнения составляет всего 0,09023 и при выполнении запроса производится 92 логических считывания.
Рис. 6 План выполнения при использовании индексированного представления
Рис. 6 План выполнения при использовании индексированного представления
Это индексированное представление можно создавать и использовать и в других версиях SQL Server, но для получения аналогичного эффекта необходимо изменить запрос и добавить прямую ссылку на представление с помощью подсказки NOEXPAND, примерно так:
SELECT CustomerID, OrdersTotalAmt
FROM vTotalCustomerOrders WITH (NOEXPAND)
Как видите, правильно использованные индексированные представления могут оказаться очень мощными орудиями. Лучше всего их использовать в оптимизированных запросах, выполняющих агрегирование больших объемов данных. В версии Enterprise можно усовершенствовать много запросов, не изменяя кода.

Поиск запросов, нуждающихся в настройке
Как я определяют, что запрос стоит настроить? Я ищу часто выполняемые запросы, возможно, с невысокой стоимостью выполнения в отдельном случае, но в целом более дорогие, чем крупные, но редко встречающиеся запросы. Это не значит, что последние настраивать не нужно. Я просто считаю, что для начала нужно сосредоточиться на более частых запросах. Так как же их найти?
К сожалению, самый надежный метод довольно сложен и предусматривает отслеживание всех выполненных запросов к серверу с последующий группировкой по подписям. При этом текст запроса с реальными значениями параметров заменяется на замещающий текст, который позволяет выбрать однотипные запросы с разными значениями. Подписи запроса создать тяжело, так что это сложный процесс. Ицик Бен-Ган (Itzik Ben-Gan) описывает решение с использованием пользовательских функций в среде CLR и регулярных выражений в своей книге «Microsoft SQL Server 2005 изнутри: запросы T-SQL».
Существует еще один метод, куда более простой, но не столь надежный. Можно положиться на статистику всех запросов, которая хранится в кэше плана выполнения, и опросить их с использованием динамических административных представлений. На рисунке 7 есть пример запроса текста и плана выполнения 20 запросов из кэша, у которых общее количество логических считываний оказалось максимальным. С помощью этого запроса очень удобно быстро находить запросы с максимальным количеством логических считываний, но есть и некоторые ограничения. Он отображает только запросы с планами, кэшированными на момент запуска. Не кэшированные объекты не отображаются.
Figure 7 Поиск 20 самых дорогих с точки зрения ввода/вывода при считывании запросов. (Close Figure 7)
SELECT TOP 20 SUBSTRING(qt.text, (qs.statement_start_offset/2)+1,
        ((CASE qs.statement_end_offset
          WHEN -1 THEN DATALENGTH(qt.text)
         ELSE qs.statement_end_offset
         END - qs.statement_start_offset)/2)+1),
qs.execution_count,
qs.total_logical_reads, qs.last_logical_reads,
qs.min_logical_reads, qs.max_logical_reads,
qs.total_elapsed_time, qs.last_elapsed_time,
qs.min_elapsed_time, qs.max_elapsed_time,
qs.last_execution_time,
qp.query_plan
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) qp
WHERE qt.encrypted=0
ORDER BY qs.total_logical_reads DESC
Обнаружив запросы с плохой производительностью, рассмотрите их планы и найдите способы оптимизации с помощью технологий индексирования, которые я описал в этой статье. Вы не зря потратите время, если добьетесь успеха.
Удачной настройки!

Мацей Пилеки (Maciej Pilecki) — младший преподаватель компании Solid Quality Mentors, глобальной организации, которая специализируется на обучении и предоставлении консультационных услуг. Он является сертифицированным преподавателем Майкрософт (MCT) и ценнейшим специалистом по SQL Server (MVP), часто ведет курсы и читает лекции по многим аспектам SQL Server и разработки приложений.


 От редактора: Экология и компьютеры
От редактора
Экология и компьютеры

Диалог, начатый в предыдущем номере, на тему создания экологичного центра обработки данных, который, как я надеялся, будет непрерывным, развеял мои надежды. На самом деле, эта тема по-прежнему четко не определена. (А что такое «экологичный»? Если мой автомобиль способен проехать на 10 литрах топлива на 20 километров больше других, он экологичный? Не думайте, машины у меня нет. Я живу в Нью-Йорке, а здесь ходят пешком.)
К тому же кажется, что в качестве своих достоинств каждая компания пытается поставить знак «экологичности» на своих продуктах или услугах. Хотя для этого есть причина. Ведь именно поэтому эта тема заняла обложку прошлого номера — потенциал поразительный.
Все мы знаем, что получение дохода связано с помощью окружающей среде. Фактически, соответствие экологическим нормам оправдает реальные результаты продаж. («Это экономика, понял?!») Если компания-производитель автомобилей сможет продать больше автомобилей, сделав их более эффективными в эксплуатации, так отлично. В конце концов, есть надежда, что мы сможем построить крепкую экономику в здоровой устойчивой среде.
Так как же это может повлиять на ИТ-специалиста? Доктор Джонатан Куми (Jonathan Koomey), штатный научный сотрудник Национальной лаборатории Лоуренса в Беркли, и занимающий должность профессора-консультанта в Стенфордском Университете, в результате недавно проведенного исследования рассчитал объемы потребления энергии серверами в США и по всему миру. За 2005 год центрами обработки данных (серверами со вспомогательной инфраструктурой, например системами охлаждения) было потреблено 1,2 процента от общего объема потребления электроэнергии в США, что представляет собой полную нагрузку пяти электростанций мощностью 1000 мегаватт и образует стоимость равную 2,7 миллиардам долларов. В мировом масштабе цифра достигает 7,2 миллиардов долларов (полная нагрузка 14 электростанций мощностью 1000 МВт). Это огромные деньги и объемы электроэнергии, которые необходимо экономить, и центры обработки данных могут стать отправной точкой для решения этой задачи.
Как спланировать производственную мощность центра обработки данных? Как оптимизировать мощность под потребности без необходимости постоянной работы при полной нагрузке? (Подсказка: виртуализация). Мы контролируем производительность сетевой серверной среды, использование памяти и так далее, но кто задумывается о потреблении электроэнергии? Потребляют ли старые серверы существенно меньше электроэнергии, чем современное оборудование? Больше ли эти дополнительные затраты, чем затраты на замену оборудования?
В ближайшие месяцы один из наших постоянных авторов, специалист Дейв Охара (Dave Ohara) (автор статьи в последнем номере, опубликованной на веб-узле technetmagazine.com) расскажет о работе, выполняемой сейчас корпорацией Майкрософт в направлении строительства собственных экологичных центров обработки данных в г. Куинси, штат Вашингтон и Сан-Антонио, штат Техас, и даст ответы на ряд волнующих нас вопросы. Нам также будет интересно узнать, как вы справляетесь с решением этих вопросов (или если вы не хотите отвечать, сообщите почему). Пишите на адрес tnmag@microsoft.com или посетите блог blogs.technet.com/tnmag. Джошуа Хоффман

Мы хотели бы поблагодарить следующих технических специалистов корпорации Майкрософт: Тим Кэрролл (Tim Carroll), Омеш Десай (Omesh Desai), Стив Дженнис (Steve Jenness), Сэм Круненбург (Sam Kroonenburg), Мутлу Куртоглу (Mutlu Kurtoglu), КейСи Лемсон (KC Lemson), Тим Минтнер (Tim Mintner), Джим Труэр (Jim Truher), Бак Вуди (Buck Woody) и Сударшан Ядав (Sudarshan Yadav).


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

Видеосъемка с экрана
Программное обеспечение My Screen Recorder Pro
deskshare.com/msrpro.aspx
Представьте себе, что через 20 минут состоится совещание, а вам нужно скомпоновать презентацию о новой конфигурации системы. Или что вам нужно почти каждый день учить разных пользователей, как работать с одним и тем же приложением. Звучит знакомо? Тогда последуйте моему совету: воспользуйтесь программным обеспечением My Screen Recorder Pro компании DeskShare.
Из названия приложения понятно, что оно позволяет делать видеозапись всего, что происходит на рабочем столе. Это приложение значительно облегчает создание импровизированных презентаций или многократно используемых учебных материалов для клиентов. Программное обеспечение My Screen Recorder Pro также поддерживает запись звука, позволяя добавлять к видеозаписи речевое сопровождение. (Небольшая хитрость: до начала записи советую вам создать структуру или сценарий.)
Новая видеозапись создается очень просто. Выберите область, запись которой необходимо произвести (это может быть весь рабочий стол, определенная или фиксированная область рабочего стола или окно определенного приложения), и нажмите кнопку записи.
Приложение поддерживает возможность записи в форматах AVI, Windows Media® Video (WMV) или Flash, что позволяет относительно легко распространять сделанные записи и даже включать видеоматериалы в веб-страницы или передавать их в потоковом режиме для широкой аудитории. Кроме того, поддерживается возможность создания исполняемых файлов для воспроизведения видеозаписи в локальном режиме на большинстве ПК, работающих под управлением ОС Windows®. Видеозапись встраивается в исполняемый файл, что значительно упрощает распространение видеоматериалов и делает воспроизведение интуитивно понятным для конечных пользователей.
Если учебные материалы или презентация состоят из нескольких частей, можно скомпоновать несколько кадров в одну видеозапись. А если вам нужно отредактировать видеоматериалы, можно разделить или вырезать запись в соответствии с поставленными задачами.
В большинстве случаев настроек приложения по умолчанию оказывается достаточно. Однако в зависимости от ваших требований вы можете изменить частоту кадров, качество звука и настройки сжатия. Эти функции могут быть полезны при ограничениях размера видеозаписи или полосы пропускания. Используя режим простого изменения скорости записи, можно также создавать видеоматериалы со сжатием продолжительных периодов отснятого материала (например, медленно изменяющегося индикатора выполнения). Другая удобная функция позволяет использовать для записи курсор мыши, привлекая внимание к происходящим действиям при помощи эффектов указателя курсора и одновременно с этим записывая происходящее. Например, можно увеличить указатель или обвести круг вокруг области рабочего стола, в центре которой вы нажмете кнопку мыши. Кроме того, в архивных целях к записи можно добавить заголовок и метку времени.
Для трусливых, подозрительных или сверхпредусмотрительных сотрудников в приложении My Screen Recorder Pro имеется возможность выполнять запись по расписанию. Программу можно запустить из командной строки и тщательно следить за действиями, выполняемыми на рабочей станции. Наконец, в приложение встроены функции, позволяющие размещать видеозаписи на FTP-узле. В сочетании с планировщиком эта функция может оказаться полезной при выполнении аудита.

Цены: 99 долларов США (прямые продажи) за одну лицензию.
Создавайте презентации, записывая происходящее на рабочем столе вашего компьютера
Создавайте презентации, записывая происходящее на рабочем столе вашего компьютера

Дефрагментация диска
ПО PerfectDisk 8
raxco.com/products/PerfectDisk2k
Дефрагментация жесткого диска крайне важна для любого ПК под управлением ОС Windows. Если вы работаете с компьютером как я, вы постоянно устанавливаете и удаляете приложения, функции и обновления программного обеспечения. Сегодня пользователям предлагается неограниченное количество средств дефрагментации жесткого диска, и одно из них я начал использовать в прошлом месяце. Дефрагментация — это одна из важнейших операций, и утилита PerfectDisk 8 компании Raxco Software безусловно заслуживает пристального внимания. Хотя все версии ОС Windows поддерживают средство дефрагментации, иногда требуется служебная программа, позволяющая более тщательно управлять операцией дефрагментации. В этом случае обратите внимание на программу PerfectDisk.
Как и следует ожидать от любого средства дефрагментации, работающего в ОС Windows, программа PerfectDisk 8 поддерживает дефрагментацию жестких дисков с файловыми системами FAT16, FAT32 и NTFS, а также жестких дисков RAID-массивов. Программа PerfectDisk 8 выпускается в версиях для настольных ПК и для серверов, а также сертифицирована для работы на ПК под управлением ОС Windows Vista® и поддерживает другие версии ОС Windows, в том числе Windows Server® 2003 и Windows 2000. Имеется даже версия для решения Exchange.
По информации компании, решение построено на технологии SMARTPlacement, которая используется для организации структуры файлов на жестком диске, позволяя уменьшить время доступа к файлам. Например, в ПК под управлением ОС Windows XP технология the SMARTPlacement отвечает за управление загрузкой и файлами layout.ini, размещая их в порядке, позволяющем уменьшить время поиска файлов на диске при загрузке системы. В программе имеется возможность дефрагментации не только жесткого диска целиком, но и отдельного файла, что весьма удобно, например, при загрузке большого файла ISO.
Чтобы выполнить дефрагментацию файлов, до которых обычно трудно добраться во время работы операционной системы, в приложении используется автономный режим, который запускается при следующей загрузке системы, или, при определенных условиях, для выполнения дефрагментации приложение может попробовать отсоединить жесткий диск. Другая функция программы PerfectDisk — это режим дефрагментации при включении экранной заставки, при котором дефрагментация начинается автоматически при появлении заставки.
Программа PerfectDisk также включает возможность работы из командной строки, позволяющую с легкостью запланировать дефрагментацию при помощи предпочтительного планировщика заданий и запускать дефрагментацию в удаленном режиме посредством агентов управления, работающих на компьютере. Для работы со многими компьютерами я бы посоветовал вам загрузить бесплатное дополнение PerfectDisk Command Center, с которым вы сможете в удаленном режиме производить развертывание, обновление, планирование и настройку приложений для рабочих станций предприятия.

Цены: PerfectDisk 8 Professional (для настольных ПК) – от 39,99 долларов США за одну лицензию. PerfectDisk 8 Server – от 239.99 долларов США за одну лицензию.
Программа PerfectDisk поддерживает различные параметры конфигурации
Программа PerfectDisk поддерживает различные параметры конфигурации

Обзор книги
Сетевой воин (Network Warrior)
oreilly.com
Если вы используете решения компании Cisco, вас, возможно, заинтересует книга Гари Донахью (Gary Donahue) Network Warrior (издательство O'Reilly, 2007 г.). Эта книга подходит для широкого круга читателей, в том числе для читателей, впервые проявляющих интерес к сетевым решениям, специалистов, недавно получивших сертификат CCNA, или опытных системных администраторов, желающих усовершенствовать свои навыки работы.
Лично мне особенно нравится, что в этой книге описываются сетевые решения, используемые в реальной жизни, и что в ней содержится краткий обзор многих распространенных задач, которые каждый день приходится решать администраторам сети. Книга начинается с объяснения базовых понятий и определения сети на самом общем уровне. Далее автор переходит к обзору концентраторов, коммутаторов, виртуальных локальных сетей, магистральной передачи и протокола VTP, а также к описанию топологии составного дерева на базе протокола STP и технологии EtherChannel компании Cisco System.
В книге Network Warrior приводится множество понятных примеров, в которых фигурируют система Internetwork Operating System (IOS) компании Cisco и команды интерфейса командной строки CatOS (CLI). В примерах приводятся объяснения применяемых методов и технологий. Мне понравилось, что автор приводит исторические факты о современных методах, расширяя кругозор читателей. Например, из книги можно узнать, почему интерфейс командной строки называется CatOS, а не просто IOS.
Книга содержит раздел, посвященный маршрутизаторам и маршрутизации, из которого читатели узнают об основных понятиях маршрутизации, от метрик до понятия административного расстояния для различных протоколов маршрутизации. Кроме того, в книге содержится обзор протоколов, в том числе протоколов OSPF, BGP и RIP.
В разделе, посвященном разработанному компанией Cisco протоколу HSRP, автор обсуждает вопросы отказоустойчивости и рассматривает несколько основных конфигураций, позволяющих сократить время простоя сетевой инфраструктуры. За этим разделом следует обзор функциональных возможностей некоторых многоуровневых коммутаторов Cisco, в том числе Cisco 6500 и Catalyst 3750, и рассматриваются возможные основные конфигурации.
Для меня информация из области телекоммуникаций оказалась весьма полезной. Из книги можно извлечь профессиональные знания, которые помогут читателям избежать монотонной работы при выполнении сетевого администрирования. Читатели получат достаточно полное представление об устройствах обслуживания каналов и данных (CSU/DSU), настройке соединений DS3 и ретрансляции кадров с поддержкой нескольких узлов. Все это позволит свободно решать задачи в области телекоммуникаций.
Интересный раздел книги посвящен вопросам безопасности и брандмауэрам. Из него читатели узнают, как создавать и настраивать списки управления доступом, а также как работать с промежуточными подсетями, использовать проверку подлинности и определенные параметры конфигурации брандмауэра PIX. Мне понравился краткий раздел по теории брандмауэров, в котором подчеркиваются основные принципы работы с сетью: «запрещайте все; разрешайте лишь то, что нужно» и «безопасность — это компромисс между удобством и паранойей».
Последний раздел книги знакомит читателей с проектированием сетей, в частности, с созданием типичной сетевой инфраструктуры, например трехуровневой конфигурации сетей, поддерживающих решения электронной коммерции, и малых базовых сетей без уровня распределения. Автор особо подчеркивает важную роль документации и соглашений об именах.

Цены: 44,99 доллара США

Устраняйте блокировку файлов
Программа WhoLockMe
dr-hoiby.com/WhoLockMe
Как было бы приятно, если бы каждое приложение корректно закрывало файлы. К сожалению, так бывает не всегда. Нарушения совместного доступа могут сильно испортить впечатление от работы, а поиск процесса, блокирующего файл, может оказаться достаточно трудоемким делом. Не знаю как вы, а я терпеть не могу закрывать одно приложение за другим, просто чтобы выполнить нужную операцию с файлом. К счастью, существует бесплатное простое расширение Windows Explorer под названием WhoLockMe, которое поможет справиться с этой проблемой.
Это приложение, работающее в операционных системах Windows NT®, Windows 2000, Windows Server 2003 и Windows XP, позволяет узнать, какое приложение в данный момент блокирует нужный вам файл. Для этого нужно всего лишь щелкнуть правой кнопкой мыши и выбрать соответствующий пункт в контекстном меню Windows Explorer.
Программа WhoLockMe отобразит название процесса, блокирующего файл, идентификатор процесса, путь к открытому файлу, домен и пользователя контекста выполнения процесса, а также полный путь к виновнику. Если хватит смелости, процесс можно уничтожить непосредственно из пользовательского интерфейса.
К сожалению, для программы WhoLockMe давно не создавались обновления, поэтому она не поддерживает работу в ПК под управлением ОС Windows Vista. Но если вы используете другие версии ОС Windows, это приложение быстро и эффективно справляется с поставленной задачей, выясняя, кто или что заблокировал файл, который вам нужно переместить, удалить или изменить.

Цены: Бесплатная программа

Средства DNS
DNSStuff.com
www.dnsstuff.com
Если по работе вы часто сталкиваетесь с Интернет-приложениями или сетями, вы, разумеется, не сможете обойтись без службы DNS, которая необходима, чтобы управлять приложениями или сетями, обеспечить эффективность их работы и предоставлять рядовым пользователям информацию о том, где находятся нужные приложения. Чтобы разрешить эти вопросы, лично я использую набор инструментов с веб-узла DNSstuff.com. Этот набор веб-инструментов представляет собой отличный ресурс, который можно использовать для устранения неисправностей и проверки конфигурации инфраструктуры.
На этом веб-узле размещены инструменты для решения самых разных задач, в том числе для работы с доменами, протоколом IP, именем узла, электронной почтой, веб-узлами и сетями в целом. Более 45 различных средств запросов помогут вам решить любые задачи, от проверки конфигурации почтового сервера до мониторинга скорости хостинга DNS. Наверняка в вашем распоряжении уже есть похожие инструменты, но при проведении внешней проверки может выявиться важная информация, которая и поможет устранить возникшую неисправность. К тому же, теперь вам не придется просить коллегу из компании по соседству выполнить обратный просмотр DNS.
Один из наиболее эффективных и полнофункциональных инструментов с этого веб-узла называется DNSreport. Просто введите доменное имя, нажмите кнопку и вы получите подробную информацию о сделанных настройках. Для отображения того или иного состояния в пункте строки теста используется определенный цвет, за счет чего можно быстро просмотреть результаты проверки на наличие возможных проблем. В отчете содержится информация о проверке родительских зон домена, в том числе записи сервера имен и сведения о том, производится ли рассылка IP-адреса и имени узла. Кроме того, в отчете содержится информация о проверке возможных слабых мест в системе безопасности, определяется, не являются ли ваши DNS-серверы открытыми, одинаковы ли их записи сервера имен и не происходит ли утечка скрытых записей сервера имен по запросам, поступающим не с сервера имен.
Кроме того, можно получить также определенную информацию о доступности настроек, так как при проверке наличия единой точки, сбой которой приведет к сбою всей системы, инструмент DNSreport проверяет различные серверы имен, общедоступные привязки IP и недостающие серверы имен. В дополнение к этому, инструмент DNSreport проверяет начальную запись зоны, выводя информацию о серийном номере начальной записи зоны, значениях обновления, истечения времени, повторных попыток и минимального срока жизни, а также выполняет проверку записей MNAME и RNAME.
Функция проверки записей Mail Exchange проверяет аннулированные записи доменных имен, сообщая о наличии или отсутствии повторяющихся записей, а также о допустимости имен узлов в записях. Далее, этот инструмент подключается к почтовому серверу и проверяет следующие параметры: указывается ли имя узла почтового сервера в приветствии, принимает ли он сообщения abuse@yourdomain (в соответствии с RFC) и поддерживают ли настройки SMTP-сервер открытую ретрансляцию (что делает его магнитом для отправителей нежелательной почты со всего мира). Наконец, инструмент DNSreport сообщает вашу запись www A, проверяет, являются ли все протоколы IP общедоступными, и определяет, может ли конфигурация CNAME вызвать дополнительный поиск DNS.
Если возможностей инструмента DNSreport для вас недостаточно, вы можете воспользоваться другим инструментом с этого веб-узла, который поможет вам определить, содержится ли ваш почтовый сервер в хорошо известных базах данных рассылок нежелательной почты. Другой инструмент, размещенный на этом веб-узле, поможет найти информацию об источнике нежелательной почты, поступающей в адрес домена. Вы можете определять, кому принадлежат IP-адреса, отслеживать маршруты и выполнять проверку связи, производить общий и кэшированный поиск DNS по крупным поставщикам услуг Интернета. Если вы зарегистрируетесь на веб-узле, у вас даже появится возможность выполнять поиск NETGEO IP, проверку MAC-адресов и полный сброс файлов. Так или иначе, этот веб-узел содержит весьма полезные инструменты.

Цены: Подписка для одного пользователя: 3 доллара в месяц (полный доступ и неограниченные возможности поиска).
Веб-узел DNSstuff.com предоставляет полный набор удобных инструментов для мониторинга.
Веб-узел DNSstuff.com предоставляет полный набор удобных инструментов для мониторинга.

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


 Exchange в вопросах и ответах: Безопасные протоколы электронной почты, таинственные нежелательные сообщения и многое другое
Exchange в вопросах и ответах
Безопасные протоколы электронной почты, таинственные нежелательные сообщения и многое другое
Нино Билич (Nino Bilic) and Скотт Лэндри (Scott Landry)
В этой статье используются сведения, относящиеся к предварительной версии Windows Server 2008, которые могут быть изменены.

Вопрос: Я хочу использовать безопасный протокол SMTP. Как мне настроить Exchange Server на прослушивание порта 465 по протоколу SMTP?
Ответ: К сожалению, это невозможно. Любой виртуальный SMTP-сервер или соединитель получения можно настроить на прослушивание порта 465, однако это не приблизит вас к достижению конечной цели — использованию безопасного протокола SMTP (SMTPS).
Почему? Давайте немного подумаем. Существует два типа протоколов SSL: явные и неявные. Изначально в большинстве случаев связь по SSL-протоколов была неявной. Это означает, что для SSL использовался выделенный порт. Например, для протокола HTTP по умолчанию используется порт 80, а для HTTPS (HTTP с SSL) — порт 443. Так было до тех пор, пока несколько лет назад Интернет-сообщество не решило, что теперь для SSL не требуется выделенный порт. Так на свет появился явный SSL.
В качестве порта SMTPS для Netscape уже выбран порт 465, а Exchange Server не имел функциональных возможностей SSL в протоколе SMTP. Однако группа Exchange обратила внимание на преимущество явного протокола SSL (его могут использовать в равной мере и клиенты, и серверы) и приняла решение о поддержке явного SSL для SMTP.
В случае SMTP явный протокол SSL с помощью команды STARTTLS ESMTP сообщает о том, что существующий сокет становится безопасным. Подавляющее большинство других SMTP-серверов и производителей клиентов также используют команду STARTTLS, поэтому острой необходимости в поддержке порта 465, который к тому же не является официальным Интернет-стандартом, никогда не было.
До настоящего времени ни одна версия Exchange Server не поддерживала неявный протокол SSL для SMTP. И настройка соединителя получения Exchange или виртуального SMTP-сервера на прослушивание порта 465 нисколько не меняет эту ситуацию. В связи с этим возникает необходимость использования клиента, поддерживающего команду STARTTLS для порта 25. Если этот порт недоступен для использования, логика подсказывает, что следующим выбором должен стать порт 587 — стандартный порт для отправки сообщений клиентами по протоколу SMTP. В настоящее время осталось не так уж много клиентов, которые не поддерживают команду STARTTLS для порта 25, поэтому включать поддержку неявных SSL было необязательно.
Кстати, протоколы Exchange POP3 и IMAP4 всегда поддерживали неявный SSL. Но в Exchange Server 2007 для них добавлена еще и поддержка явного SSL. Однако в связи с тем, что этот новый стандарт поддерживают пока лишь немногие клиенты, неявный протокол SSL, скорее всего, не оставит своего лидирующего положения в обозримом будущем.

Вопрос: В моей очереди накопилось очень много сообщений для отправки в различные домены, но мои пользователи не отправили ни единого сообщения. Что происходит и каков выход из этой ситуации?
Ответ: Вы не первый, кто сталкивается с такой проблемой. Она может возникнуть у любого владельца Интернет-сервера. В общем случае ее появление может быть обусловлено двумя причинами. Во-первых, вы могли каким-либо образом открыть доступ к своему серверу для ретранслятора (см. support.microsoft.com/kb/304897). Но вы ведь не делали этого, не правда ли? (Открытые ретрансляторы отключаются по умолчанию, начиная еще с версии Exchange Server 2000.) Поэтому, скорее всего, вы имеете дело с так называемой нежелательной почтой, содержащей отчеты о недоставке. Отправители нежелательной почты часто отправляют нежелательные сообщения на несуществующие адреса вашего домена. Сервер предпринимает попытку уведомить отправителя, что данный пользователь не существует, однако указанный обратный адрес отправителя, конечно же, не является настоящим. Отправитель нежелательной почты может указать несуществующий обратный адрес (в этом случае отчет о недоставке может «зависнуть» на некоторое время, пока не истечет период ожидания) либо попытаться заставить ваш сервер отправить нежелательное сообщение в другой домен от своего имени в качестве вложения в сообщение о недоставке, созданное вашим сервером.
Вы можете отключить отчеты о недоставке, однако в этом случае, если существующий пользователь совершит опечатку и ошибочно отправит сообщение на ваш адрес, он не получит никакого уведомления об этом, и все его важные сообщения могут быть потеряны. Но не спешите огорчаться, есть более удачное решение.
Во-первых, убедитесь, что ваш сервер закрыт для ретрансляторов. (Я просто обязан напомнить вам об этом.) Затем активируйте доступную функцию защиты от нежелательной почты, например интеллектуальный фильтр сообщений (IMF) или фильтр содержимого Exchange Server 2007, а также несколько списков заблокированных адресов реального времени (RBL). Это можно сделать либо в роли пограничного транспортного сервера, либо в роли транспортного сервера-концентратора, но в любом случае как можно раньше, поскольку свыше 90 процентов всех сообщений электронной почты несут в себе нежелательную информацию, а загружать свой сервер всеми этими «непрошенными гостями» вам вряд ли захочется.
И последнее: активируйте фильтр получателей на первом сервере Exchange, который принимает сообщения, поступающие в вашу среду. Это позволит серверу отклонять сообщения до того, как они попадут в вашу сеть. При этом существующий отправитель, по ошибке отправивший сообщение не по тому адресу, получит отчет о недоставке; единственное отличие будет в том, что этот отчет генерируется сервером отправителя.

Вопрос: На одном моем сервере был установлен Exchange Server 2000, а на другом — Exchange Server 2003, и оба они отлично справлялись с отправкой почты в Интернет. Затем я установил Exchange Server 2007, и теперь почтовые ящики обоих серверов не могут отправлять сообщения.
Ответ: Если в прошлом вы имели дело только с одним Exchange Server, вы можете не знать всю специфику работы соединителей. Соединители Exchange — это объекты настройки логической маршрутизации, сообщающие серверу, куда следует направлять электронную почту. При внедрении Exchange Server 2007 в действующую организацию маршрутизация почты будет невозможна без соединителей групп маршрутизации и соединителя SMTP.
Вам понадобятся два соединителя групп маршрутизации: один для направления из группы маршрутизации Exchange Server 2007 в группу маршрутизации Exchange Server 2003 и наоборот. Эти соединители можно настроить в процессе установки, но если вы не уверены, что не пропустили соответствующий шаг, проверьте это с помощью командной консоли Exchange и при необходимости исправьте свое упущение. Если этого не сделать, обмен сообщениями между вашими серверами будет невозможен. Сообщения будут заканчивать свое существование в очередях с недопустимым адресатом.
Для маршрутизации Интернет-почты необходим всего один соединитель SMTP, также известный в Exchange Server 2007 как соединитель отправки. В Exchange Server 2000 и Exchange Server 2003 тоже использовался один соединитель, однако можно было обойтись и без него. Адресное пространство должно иметь вид SMTP:* для всех доменов, а для доставки почты можно указать использование либо промежуточных узлов, либо DNS. Вам нужно решить, хотите ли вы, чтобы сервер с Exchange Server 2007 или с одной из предыдущих версий обрабатывал всю исходящую Интернет-почту, или необходима установка Exchange Server 2007 для обеих групп маршрутизации, чтобы каждый сервер обрабатывал свою почту. Эти действия можно выполнить в ходе процесса Edgesync, если вы установили роль пограничного транспортного сервера.
Если вы уже успели поместить на виртуальный SMTP-сервер промежуточный узел, сейчас самое время удалить его. Промежуточный узел должен находиться на соединителе SMTP, но никак не на виртуальном сервере, поскольку это повредит соединитель группы маршрутизации.
Не следует также забывать о том, что входящие сообщения управляются вашей MX-записью либо IP-адресом, используемым для переадресации брандмауэром. Хотя Exchange и не требует сложной настройки, в следующем документе вы найдете всю необходимую информацию, если у вас вдруг возникнут какие-либо вопросы: msexchangeteam.com/archive/2006/11/17/431555.aspx.

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

Вопрос: Куда пропала функция переадресации неразрешенных сообщений на узел в Exchange Server 2007? И как мне без нее быть?
Ответ: Ее съела злая собака.
А если серьезно, эта функция никогда не отличалась надежностью в тех случаях, когда установлено более одного сервера Exchange Server. Но в Exchange всегда был альтернативный способ выполнения той же задачи, причем гораздо более эффективный. В частности, это возможность совместного использования индивидуальных доменов SMTP с другими системами. Таким образом, функция переадресации неразрешимых сообщений была упразднена, а идея совместного использования доменов выведена на первое место и упрощена. Просто зайдите в раздел Организация | Транспортный сервер-концентратор | Обслуживаемые домены в Exchange Server 2007 и измените тип домена с «Доверенный» на «Внутренний ретранслятор». Эта операция немного сложнее, чем в некоторых других средах, и в настоящее время мы работаем над усовершенствованием документации. Но она работает.

Вопрос: Я пытаюсь подготовить свой корневой домен к установке Exchange Server 2007. На сервере, с которого я хочу установить Exchange Server 2007, установлен диспетчер Exchange Server 2003, и при установке происходит сбой. В чем тут дело?
Ответ: Все очень просто. Выполнение любых шагов установки Exchange Server 2007 на машине, где установлены какие-либо компоненты Exchange Server 2000 или 2003, не поддерживается. Процесс установки Exchange Server 2007 обнаружит, что на компьютере установлен диспетчер Exchange Server 2003, и проверка предварительных условий не будет пройдена. Вы увидите сообщение «На этом компьютере уже установлена предыдущая версия Exchange Server. Запустите установку Exchange Server 2007 с другого компьютера или удалите предыдущую версию Exchange Server».
Наверное, самый простой способ решить эту проблему — это выполнить установку Exchange Server 2007 с другого сервера в корневом домене и таким образом подготовить свой домен. Если это трудноосуществимо, компонент Exchange Server 2003 придется удалить, в противном случае установка Exchange Server 2007 будет невозможна.
Помните, что для подготовки домена можно использовать 32-битную версию Exchange Server 2007, поэтому подойдет любой 32-битный сервер в корневом домене. Дополнительные сведения по этой теме см. в статье по адресу: technet.microsoft.com/library/bb232170.aspx.
Это также означает, что вы не можете установить диспетчер Exchange Server 2003 и консоль управления Exchange Server 2007 Exchange на одном компьютере, поскольку совместное существование средств управления Exchange Server 2003 и Exchange Server 2007 на одной машине не поддерживается. Установка Exchange Server 2007 будет прервана, если на машине, на которую вы пытаетесь установить эту версию, уже установлены какие-либо компоненты Exchange Server 2000 или 2003.
И, наконец, обратите внимание, что не следует пытаться установить на одной и той же машине средства управления Exchange Server 2007, а затем средства Exchange Server 2003. Это может привести к возникновению ситуации, которая не тестировалась, и, как следствие, получению неожиданных результатов при попытке управления серверами. Если вам приходится управлять двумя версиями сервера с одного компьютера, можно подключиться к одному из них с помощью удаленного рабочего стола либо использовать виртуальную машину для размещения другой версии средств управления в изолированной среде.

Вопрос: Когда уже наконец я смогу запустить средства управления Exchange Server 2007 на своей рабочей станции Windows Vista®?
Ответ: Официальная поддержка средств управления Exchange Server 2007 операционной системой Windows Vista имеется в выпуске Exchange Server 2007 с пакетом обновления 1 (SP1). Пакет, содержащий средства управления Exchange Server 2007 SP1, будет доступен для загрузки сразу после выхода данного выпуска.

Вопрос: А как насчет диспетчера Exchange Server 2003 на Windows Vista или Windows Server 2008? Смогу ли я использовать их?
Ответ: Нет, к сожалению, это невозможно. Средства управления для любой версии Exchange Server до Exchange Server 2007 SP1 не поддерживаются операционной системой Windows Vista или Windows Server 2008. Это означает, что даже после выхода Windows Server 2008 установка диспетчера Exchange Server 2003 на нем поддерживаться не будет. Управление серверами Exchange Server 2003 возможно только с Windows Server 2003 или рабочих станций Windows XP; альтернативный вариант — использовать подключение к удаленному рабочему столу с любой ОС.

Вопрос: В моем домене установлено несколько серверов Exchange Server 2003. Могу ли я обновить контроллеры домена до версии Windows Server 2008?
Ответ: Да, безусловно. Работа Exchange Server 2003 с пакетом обновления 2 (SP2) в домене с контроллерами Windows Server 2008 поддерживается. Пожалуйста, обратите внимание, что Exchange Server не может использовать контроллеры домена Windows Server 2008 с доступом только для чтения или серверы глобального каталога Windows Server 2008 с доступом только для чтения. Программирование вручную сервера Exchange Server на использование контроллеров домена или серверов глобального каталога Windows Server 2008 с доступом только для чтения может привести к непредвиденным последствиям.

Нино Билич (Nino Bilic) — руководитель программы поддержки Exchange Server. Он проводит все свое свободное время за изучением удивительных возможностей межсерверной связи, для чего ежедневно перед сном просматривает невероятное количество трассировок Netmon.
Скотт Лэндри (Scott Landry) , инженер по улучшению поддержки управляемости для Exchange Server, никогда не отправляется в поездку без любимого полотенца, копии Руководства пользователя и старого доброго мобильного телефона с Windows Mobile.


 Обзор служебных программ: Командлеты SMS для оболочки Windows PowerShell
Обзор служебных программ
Командлеты SMS для оболочки Windows PowerShell
Дон Браун (Don Brown)
Загрузить исходный код для этой статьи: Utility2007_11.exe (1211KB)

Раньше невозможно было осуществлять управление клиентами Microsoft System Management Server (SMS) 2003 из командной строки. К счастью, в числе современных технологий, которые используются администраторами для управления конфигурацией, изменениями и сложностью инфраструктуры, появилась и оболочка Windows PowerShell, которая позволяет решить эту проблему.
Чтобы воспользоваться новыми возможностями, я написал небольшую служебную программу SMS2003PowerShellSnapinSample (которую вы найдете в загрузке кода, приложенной к данной статье, или в Интернете по адресу technetmagazine.com/code07.aspx). По сути, эта служебная программа представляет собой набор из шести командлетов, объединенных в едином подключаемом модуле для оболочки Windows PowerShellTM. Используя эти командлеты, можно настроить локальную политику клиента SMS в Windows PowerShell для локального компьютера или группы удаленных компьютеров.
Чем больше я экспериментировал с локальной политикой клиента SMS, тем больше понимал, что к чему. Приятным побочным эффектом стало то, что я лучше разбирался в том, как работает SMS. Я понял, что если корректно использовать локальную политику клиента SMS, им можно управлять совершенно по-новому: компьютеры, направляющие отчеты на один узел, могут быть настроены по-разному. Поток идей разрастался: можно настроить некоторые компьютеры так, что для удаленного управления не нужно будет разрешение, или установить, как часто клиентский ПК будет проводить проверку на предмет наличия новой политики, или отключать определенные компоненты в заданное время суток. Возможности использования локальной политики клиента SMS показались мне поистине безграничными. Давайте рассмотрим их поподробнее.

О локальной политике расширенного клиента SMS
Программные ресурсы
  • Представляем Windows PowerShell Введение в Windows PowerShell (для всех специалистов, начинающих работать с Windows PowerShell)
  • Форум TechNet: настройка SMS с использованием локальных политикИспользование локальной политики расширенного клиента SMS на базе MOF
  • Создайте свой первый командлет
  • Как создать подключаемый модуль для оболочки Windows PowerShell
  • Защита доступа к сети (NAP) для Windows Server 2008
  • Руководство для разработчиков решений для оболочки Windows PowerShell Руководство для тех, кто хочет получить более подробную информацию о создании командлетов, подключаемых модулей, узлов и другую информацию по созданию программных решений для оболочки Windows PowerShell
  • Пошаговое руководство по версии бета 3 Windows Server 2008

Все расширенные клиенты SMS 2003 поддерживают политику конфигурации, которая представляет собой список настроек, отвечающих за управление различными компонентами клиентов. В такие политики конфигурации входят, в числе прочего, все настройки клиентов, наборы средств инвентаризации и распространения программного обеспечения. Сами политики создаются на сервере и передаются расширенным клиентам через узел управления SMS.
Основная часть политики SMS похожа на файл MOF: в ней также содержится набор экземпляров, которые компилируются в пространства имен \\.\root\CCM WMI (Инструментария управления Windows®) расширенного клиента. Затем разные агенты осуществляют чтение этих настроек, расположенных в пространстве имен \\.\root\ccm\policy\machine\requestedconfig. Однако при использовании локальной политики на базе MOF поддерживается компиляция файла MOF только на одном компьютере в локальном режиме (вернее, при работе непосредственно на этом компьютере). В то же время Инструментарий управления Windows® поддерживает работу в распределенном режиме. Так как доступ к нему может осуществляться и в локальном, и в удаленном режиме, это значительно расширяет возможности работы администраторов SMS. Это значит, что при наличии соответствующих прав администратора подключиться к Инструментарию управления Windows® на удаленном компьютере так же просто, как и на локальном.
Политика клиента SMS состоит из настроек конфигурации для различных компонентов клиента, но может включать и инструкции по выполнению содержимого программных пакетов. Как и в случае с групповой политикой Active Directory®, политика расширенного клиента SMS 2003, полученная через узел управления SMS, может быть переопределена локальной политикой клиента SMS. Нельзя переопределить все составляющие политики, но можно изменить некоторые действительно интересные свойства. Таким образом администраторы SMS могут лучше управлять конфигурацией и операциями клиента SMS за счет создания исключений из стандартной политики, действующей для узла SMS.
В качестве примера рассмотрим безопасную консолидированную среду, в которой администраторы SMS управляют серверами и рабочими станциями как клиентами одного основного узла SMS. В этой воображаемой среде в соответствии с положениями политики безопасности специалисты технической поддержки смогут осуществить удаленное управление компьютером пользователя только после того, как ему будет направлен запрос о получении соответствующего разрешения. Такое положение дел превращается в проблему, если специалистам технической поддержки требуется в удаленном режиме подключить компьютер к серверу: обычно пользователи не зарегистрированы на серверах, поэтому предоставить такое разрешение на удаленный доступ просто некому. Если корректным образом применить локальную политику, для некоторых клиентов можно переопределить требование, связанное с получением разрешения пользователя. Вы наверняка можете представить себе еще десятки ситуаций, в которых локальная политика SMS может оказаться полезной с точки зрения настройки исключения в конфигурации конкретного агента клиента SMS.

Принцип работы подключаемого модуля Windows PowerShell
Ознакомившись в общих чертах с оболочкой Windows PowerShell и добавив образец исходного кода, прилагающегося в конце данной статьи, вы сможете расширить возможности работы с локальной политикой клиента SMS из командной строки. Прежде чем сделать политику доступной в оболочке Windows PowerShell, следует применить определенные атрибуты к классу. Необходимо заранее решить, какой командлет вам нужен и какие действия должны выполняться с его помощью. Это называется сопоставлением объекта и действия. Наиболее распространенные действия, выполняемые при использовании оболочки Windows PowerShell, это «добавить», «получить» и «установить». Под объектом понимается объект, по отношению к которому будет выполняться необходимое действие. Командлеты обычно поддерживают параметры, которые объявляются в классе кандлетов как общие свойства разных типов. Наконец, большая часть работы будет производиться с использованием функции ProcessRecord. На Рис. 1 представлен общий шаблон, который можно использовать для создания собственных командлетов.
Figure 1 Шаблон командлета (Close Figure 1)
[Cmdlet( "Verb", "Noun", SupportsShouldProcess = true )]
public class Verb_Noun : PSCmdlet
{
    [Parameter( ValueFromPipeline = true, ValueFromPipelineByPropertyName = true,
        HelpMessage = "Parameter" )]
    [ValidateNotNullOrEmpty]
    [Alias( "param" )]
    public string Parameter
    {
        get { return MyParameter; }
        set { MyParameter = value; }
    }
    private string MyParameter;

    protected override void ProcessRecord( )
    {
        //Do your stuff here!
    }
}
После компиляции подключаемого модуля необходимо зарегистрировать его в оболочке Windows PowerShell, включив класс в проект с набором атрибутов RunInstaller и несколькими определенными свойствами. Конкретная информация содержится в исходном коде, прилагающемся в конце данной статьи. Для регистрации подключаемого модуля следует использовать средство InstallUtil.exe, входящее в состав платформы Microsoft® .NET Framework. На Рис. 2 представлен синтаксис, используемый для регистрации подключаемого модуля. В ОС Windows Vista® для выполнения этой операции требуется повышение уровня привилегий. Чтобы открыть оболочку Windows PowerShell, необходимо использовать параметр «Открыть как администратор» или программу Script Elevation PowerToys для ОС Windows Vista (которую можно загрузить на веб-узле technetmagazine.com/issues/2007/06/UtilitySpotlight).
Figure 2 Установка подключаемого модуля оболочки Windows PowerShell (Close Figure 2)
PS> set-alias installutil $env:windir\Microsoft.NET\Framework\v2.0.50727\installutil
PS> installutil C:\MySMSTools\SMS2003PowerShellSnapinSample.dll
Microsoft (R) .NET Framework Installation utility Version 2.0.50727.42
Copyright (C) Microsoft Corporation. All rights reserved.
Running a transacted installation.
...
The transacted install has completed.
Далее необходимо выяснить, распознает ли оболочка Windows PowerShell ваш подключаемый модуль. При помощи командлета Get-PSsnapin с параметром Registered оболочка Windows PowerShell получает сводные данные о загруженных подключаемых модулях, а также о списке зарегистрированных подключаемых модулей, которые необходимо добавить. Ваш подключаемый модуль должен быть в этом списке:
PS> Get-PSsnapin -registered
Теперь можно добавить подключаемый модуль Windows PowerShell к оболочке при помощи командлета Add-PSsnapin:
PS> add-pssnapin SMS2003PowerShellSnapinSample
Если операция произведена успешно, командлет можно будет выполнить в подключаемом модуле Windows PowerShell.
Чтобы просмотреть все командлеты, доступные при использовании подключаемых модулей Windows PowerShell, просто укажите определенный подключаемый модуль при помощи командлета Get-Command, задав название подключаемого модуля как значение параметра PSsnapin. В подключаемом модуле, представленном в конце данной статьи в качестве образца, отображается шесть командлетов, в том числе шаблон командлета объекта и действия (см. Рис. 3).
Рис. 3 Отображение командлетов в подключаемом модуле
Рис. 3 Отображение командлетов в подключаемом модуле
В образце исходного кода, прилагающегося в конце данной статьи, я написал справку только для командлета Get-SMSServerConnection, чтобы продемонстрировать, как он построен. Если вам требуется дополнительная справка, воспользуйтесь приведенным далее примером модели в файле XML. На Рис. 4 показаны выходные данные справки.
Figure 4 Полученный результат образца Get-Help (Close Figure 4)
PS > get-help Get-SMSServerConnection

NAME
    Get-SMSServerConnection

SYNOPSIS
    This cmdlet establishes a connection to the specified SMS primary site server using your current credentials. An object of type "SMSProvider" is returned through the pipeline.

SYNTAX
    Get-SMSServerConnection [-SMSServerName] [<string>] [<CommonParameters>]

DETAILED DESCRIPTION
    This Cmdlet makes a connection to the specified SMS primary site server.  An object of type "SMSProvider" is returned. The "SMSProvider" object is not serializable and is used only to forward on through the pipeline to other cmdlets.

RELATED LINKS
Теперь, когда вы знаете, как устанавливать подключаемые модули Windows PowerShell, как выяснять, какие команды поддерживаются в подключаемом модуле, и как получить справку об обычном командлете, пришло время приступить к работе с командлетами. Используйте следующую команду, чтобы вывести список всех наборов основного сервера узла SMS:
PS > Get-SMSServerConnection -server MYSMSSERVER | Get-Collections | Format-Table Name
Не забудьте о механизме. Это основная составляющая работы оболочки Windows PowerShell, которая является очень мощным инструментом. Всего в одной строке в оболочке Windows PowerShell можно сделать практически все, что угодно. Командлет Get-SMSServerConnection устанавливает соединение с сервером SMS. Так как командлет Get-Collections поддерживает только один тип входного параметра, который возвращается командлетом Get-SMSServerConnection, можно просто передать данные, полученные в командлете Get-SMSServerConnection, для командлета Get-Collections. Вот как работает этот механизм. Этот пример удачно демонстрирует, как сложные объекты передаются из одного командлета в другой. Кроме того, можно хранить объекты в переменных. Если использовать для этого оболочку Windows PowerShell, это может выглядеть примерно следующим образом:
$SMS = Get-SMSServerConnection
     -server MYSMSSERVER
Get-Collections -SMSServerProvider $SMS
Полученный результат не всегда легко прочитать без соответствующего форматирования, так как командлет Get-Collections возвращает объект типа SMSCollections (который представляет собой массив объектов типа SMSCollection). Вкратце, выглядит он не слишком красиво, если не включить фильтр для наборов, которые вас не интересуют, или не отформатировать представление так, чтобы в виде таблицы выводились только необходимые свойства. Для этого необходимо перенести полученный результат из командлета Get-Collections через механизм в командлет Format-Table, который может отображать только указанные вами свойства. Например, можно добавить свойства | Format-Table Name, Members.
Да, но ведь есть более эффективный способ представления всех элементов определенного набора. В приведенном образце такой командлет называется Get-CollectionMembers. Как вы, наверное, уже догадались, именно этот командлет используется для передачи необходимых данных следующему командлету механизма.
До этого момента мы еще не работали с локальной политикой расширенного клиента SMS. Мы только создавали соединения с основным сервером узла SMS и перечисляли наборы и элементы наборов. В этом образце подключаемого модуля Windows PowerShell содержатся два последних командлета, Enable-SoftwareDistribution и Disable-SoftwareDistribution, соответственно. Именно они используются для работы с локальной политикой клиента SMS. Эти два последних командлета используются для управления локальной политикой клиента SMS для компонента, представляющего собой агент клиента по распространению программного обеспечения. Как вы наверное уже догадались по части названия командлета, обозначающей действие, командлет, в названии которого есть слово «Disable», позволяет переопределить локальную политику клиента так, чтобы отключить агент клиента по распространению программного обеспечения. Аналогичным образом, командлет, в названии которого есть слово «Enable», отменяет переопределение локальной политики клиента, возвращая агент клиента по распространению программного обеспечения в нормальное состояние, которое определяется политикой SMS, передаваемой через узел управления SMS. На Рис. 5 показано, как может выглядеть оболочка Windows PowerShell, содержащая одну строку и переопределяющая локальную политику клиента SMS для агента клиента по распространению программного обеспечения. Такая политика отключает агент для всех элементов настраиваемого набора Windows Server 2003. Указана также строка, отменяющая переопределение локальной политики клиента SMS для агента клиента по распространению программного обеспечения в отношении этого набора. Если у вас всего несколько компьютеров, для которых требуется управлять локальной политикой клиента SMS, командлеты Disable-SoftwareDistribution и Enable-SoftwareDistribution можно использовать по отдельности.
Figure 5 Сборка командлетов: примеры (Close Figure 5)
PS >Get-SMSServerConnection -server MYSMSSERVER | Get-Collections | where-object {$_.Name -eq "Windows Server 2003 Systems"} | Get-CollectionMembers | Disable-SoftwareDistribution
PS >
PS > Get-SMSServerConnection -server MYSMSSERVER | Get-Collections | where-object {$_.Name -eq "Windows Server 2003 Systems"} | Get-CollectionMembers | Enable-SoftwareDistribution
PS >
PS >Disable-SoftwareDistribution –hosts SMSCLIENT1, SMSCLIENT2, SMSCLIENT3
PS >
PS >Enable-SoftwareDistribution –hosts SMSCLIENT1, SMSCLIENT2, SMSCLIENT3

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

Дон Браун (Don Brown) работает в корпорации Майкрософт в должности старшего специалиста по эксплуатации. Он занимается решениями по поддержке SMS (гм, SCCM) всю свою сознательную жизнь. Связаться с ним можно по адресу donbrown@microsoft.com.


 Кабельщик: Единый вход для беспроводных сетей
Кабельщик
Единый вход для беспроводных сетей
Джозеф Дэвис (Joseph Davies)

Установка беспроводного подключения с необходимостью проверки подлинности в частной сети может оказаться очередной задачей, как для пользователя, так и администратора. Входящий в домен Active Directory и подключенный по беспроводной связи клиентский компьютер под управлением Windows должен пройти проверку подлинности IEEE 802.1X, чтобы установить
защищенное беспроводное подключение и войти в домен. Поскольку при проверке подлинности необходимы учетные данные пользователя или компьютера, и так как вход в домен зависит от работоспособности сети, определение порядка, по которому будет выполняться проверка подлинности, а также требований к вводимым учетным данным, может быть проблематичным. Все это может повлиять на процессе входа в домен, и у пользователя могут несколько раз запрашиваться его учетные данные.
К счастью, возможность единого входа для беспроводных сетей, реализованная в Windows Vista®, позволяет задать выполнение проверки подлинности IEEE 802.1X для типа Wi-Fi Protected Access 2 (WPA2)-Enterprise, WPA-Enterprise и проверки подлинности 802.1X с WEP (Wireless Equivalency Privacy) до входа пользователя в систему. Это позволит решить проблемы с входом в домен в определенных конфигурациях. В едином входе для беспроводных сетей также сочетается проверка подлинности при беспроводном подключении по типу входа в Windows®, что гарантирует удобство для пользователей. По этим причинам, в этом номере я хотел бы рассмотреть возможности функции единого входа для беспроводных сетей, порядок настройки и действий при входе пользователя в систему.

Единый вход: Основы
Клиентский компьютер под управлением Windows и подключаемый по беспроводной связи может пройти проверку подлинности в беспроводной сети только на основе учетных данных компьютера или пользователя, или и того и другого. Если используются только учетные данные компьютера, Windows проходит проверку подлинности 802.1X, прежде чем отображается заставка входа в систему. Это позволяет подключенному по беспроводной связи клиентскому компьютеру просто получить доступ к сетевым ресурсам, например контроллерам домена Active Directory®.
При использовании только учетных данных пользователя, в Windows без единого входа выполняется проверка подлинности 802.1X после входа пользователя в систему. На Рисунке 1 показана временная шкала загрузки и входа в систему по описанному сценарию.
Рис. 1 Временная шкала при использовании только учетных данных пользователя для проверки подлинности в беспроводной среде
Рис. 1 Временная шкала при использовании только учетных данных пользователя для проверки подлинности в беспроводной среде
Использование только учетных данных пользователя для проверки подлинности в беспроводной среде приводит к тому, что пользователь не может выполнить начальный вход в домен с компьютера, поскольку локально кэшируемые учетные данные для его учетной записи пользователям отсутствуют, а связи с контроллером домена для проверки подлинности новых учетных данных для входа нет. Более того, некоторые операции входа в домен выполнить не удастся, так как подключение к контроллеру домена Active Directory в данный момент не установлено. Не удастся использовать и сценарии входа в систему, изменения групповой политики и изменения профиля пользователя – это приведет к записи ошибок в журнале событий Windows.
При использовании сочетания учетных данных пользователя и компьютера, в Windows выполняется проверка подлинности 802.1X по учетным данным компьютера, прежде чем отображается заставка для входа. После входа пользователя в систему, в Windows выполняется еще одна проверка подлинности 802.1X по учетным данным пользователям. В некоторых сетевых инфраструктурах используются разные виртуальные локальные сети (VLAN) для компьютеров, проходящих проверку подлинности с учетными данными компьютера, и для компьютеров, проверяемых по учетным данным пользователя. Если проверка подлинности беспроводной сети выполняется по учетным данным пользователя и после входа пользователя в систему происходит переключение в сеть VLAN с проверкой по пользователю, то клиентский компьютер под управлением Windows, подключаемый по беспроводной связи, не будет иметь доступа к сетевым ресурсам в VLAN с проверкой пользователя, таким как контроллеры домена Active Directory, во время процесса входа пользователя в систему. И снова это приводит к неудавшимся попыткам входа в домен.
Другая проблема возникает, когда проверка подлинности в беспроводной среде по учетным данным пользователя основывается на наборе учетных сведений, отличных от учетных данных пользователя для входа. В таких ситуациях, Windows предлагает ввести дополнительные учетные данные пользователя в начале проверки подлинности беспроводной сети, что может озадачить.
Функция единого входа в Windows Vista была разработана для решения проблем с входом в домен, отдельные VLAN-сети с проверкой по учетным данным пользователя или компьютера и обращениями к пользователю с требованием каждый раз указывать разные учетные данные. Используя функцию единого входа, администратор сети может настроить проверку подлинности беспроводной сети по учетным данным пользователя до процесса входа пользователя в систему. Если учетные данные пользователя, необходимые для входа в систему и проверки подлинности беспроводной сети различаются, все требуемые учетные данные запрашиваются и собираются на экране входа в систему.
Благодаря функции единого входа, клиентский компьютер под управлением Windows Vista, подключаемый по беспроводной связи, можно настроить на прохождение проверки подлинности в беспроводной среде по учетным данным пользователя до процесса входа в систему. На Рисунке 2 показана новая временная шкала загрузки и входа в систему.
Рис. 2 Временная шкала: проверка подлинности беспроводной сети по учетным данным пользователя происходит после входа в систему
Рис. 2 Временная шкала: проверка подлинности беспроводной сети по учетным данным пользователя происходит после входа в систему
При этом возможны конфигурации, когда используются только учетные данные пользователя или сочетание учетных данных пользователя и компьютера для отдельных сетей VLAN без потери функциональности. Поскольку беспроводный клиент подключен к сети или VLAN с проверкой пользователя до начала процесса входа в систему, операции входа в домен будут выполнены успешно. Пример приведен в статье «Присоединение беспроводного клиента под управлением Windows Vista к домену» по ссылке microsoft.com/technet/network/wifi/vista_bootstrap_wireless.mspx.
На основе настроек профиля беспроводной сети, при едином входе выполняется «консолидация» полей ввода для учетных данных пользователя для проверки подлинности беспроводной сети, и их отображение на заставке входа в систему. Следовательно, все учетные данные пользователя для входа в систему и проверки подлинности в беспроводной среде по учетным данным пользователя вводятся пользователем одновременно.
Методы EAP (Протокол расширенной проверки подлинности), написанные для новой архитектуры EAPHost в Windows Vista могут использовать интерфейс EAP Pre-Logon Authentication Provider (PLAP) Support API для включения полей ввода, необходимых для проверки подлинности, в заставку входа в систему. Дополнительные сведения см. в описании функции SSO и PLAP API по адресу msdn2.microsoft.com/bb530584.
Чтобы привести пример сеанса единого входа, возьмем клиентский компьютер под управлением Windows Vista, настроенный на проверку подлинности только по учетным данным пользователя, а также имени пользователя и пароля как для входа в домен, так и для проверки подлинности 802.1X. При нажатии пользователем сочетания клавиш Ctrl+Alt+Del на первом экране Windows Vista, функция единого входа определяет, что до входа в систему необходимо провести проверку подлинности 802.1X. После того, как пользователь вводит имя и пароль, функция единого входа сначала выполняет проверку подлинности беспроводной сети по ученым данным пользователя, и выводит сообщение о подключении к беспроводной сети по имени. После проверки подлинности беспроводной сети, в Windows Vista выполняется вход в систему и отображается рабочий стол пользователя.

Настройка единого входа.
За сценой
Чтобы дополнить картину понимания процесса проверки подлинности беспроводной сети, давайте подробнее рассмотрим что происходит, когда пользователь активно пытается войти в систему. После того, как пользователь нажимает сочетание клавиш «Ctrl+Alt+Del» для входа в систему Windows Vista в беспроводной среде, выполняются следующие действия:
  1. Средство автоматической настройки беспроводной сети определяет используемый профиль беспроводной сети. Если клиентский компьютер уже успешно прошел проверку подлинности по учетным данным компьютера, используется подключенный на тот момент профиль беспроводной сети. Если выбранный профиль беспроводной сети настроен на выполнение проверки подлинности только по учетным данным компьютера, дополнительная проверка подлинности беспроводной сети по учетным данным пользователя не требуется. На шагах со 2 по 6 предполагается, что выбранный профиль беспроводной сети настроен на проверку подлинности по учетным данным пользователя, функция единого входа включена и выбрана настройка «Выполнять непосредственно перед входом пользователя».
  2. Пользователь вводит учетные данные пользователя для входа в систему и проверки подлинности беспроводной сети (в случае необходимости) и входит в систему.
  3. Windows сообщает пользователю о попытке подключения к имени беспроводной сети.
  4. Windows пытается выполнить проверку подлинности беспроводной сети по учетным данным пользователя. Если установлена настройка «Разрешить отображение дополнительных окон при едином входе» и типу методов EAP требуется отображать дополнительные диалоговое окна для пользователя, в Windows выводятся соответствующие диалоговые окна. Если проверку подлинности в беспроводной среде не удалось выполнить в течение времени, заданного в настройке «Макс. задержка подключения (сек):», проверка подлинности прерывается. Если установлена настройка «Эта сеть использует разные виртуальные локальные сети для проверки подлинности с учетными данными компьютеров и пользователей», Windows выполняет обновление DHCP конфигурации IP-адресов беспроводного сетевого адаптера при успешном выполнении проверки подлинности беспроводной сети.
  5. В Windows проходит процесс входа в систему.
  6. Отображается рабочий стол Windows.
Если установлена настройка «Выполнять сразу после входа пользователя», Windows проходит шаги в следующем порядке: 1, 2, 5, 3, 4, 6.

Чтобы включить и настроить функцию единого входа, можно использовать расширение групповой политики «Политики беспроводной сети (IEEE 802.11)» и настроить параметры расширенной безопасности для профиля беспроводной сети политики Windows Vista. Для получения дополнительных сведений о настройке, см. статью «Параметры групповой политики беспроводной связи в Windows Vista» по ссылке technetmagazine.com/issues/2007/04/CableGuy.
В диалоговом окне «Дополнительные параметры безопасности» установите флажок «Включить единую регистрацию для сети» и настройте параметры «Единая регистрация». На Рисунке 3 показан пример включенной единой регистрации с настройками по умолчанию.
Рис. 3 Настройки единой регистрации по умолчанию
Рис. 3 Настройки единой регистрации по умолчанию
Существуют настройки SSO для осуществления проверки подлинности 802.1X непосредственно до или сразу после процесса входа пользователя при беспроводном подключении и для указания задержки для установления связи перед началом процесса входа в систему. Можно также задать отображение диалоговых окон перед отображением полей ввода на заставке входа в систему. Например, если типу методов EAP необходимо, чтобы пользователь подтвердил сертификат, отправленный сервером RADIUS (Remote Authentication Dial-in User Service) во время проверки подлинности, тип методов EAP может вызвать отображением диалоговых окон.
Можно также определить запуск клиентом беспроводной сети обновления протокола DHCP конфигурации TCP/IP беспроводного адаптера после выполнения проверки подлинности с учетными данными пользователя. Следует выбрать эту настройку, если используются отдельные сети VLAN для проверки подлинности по учетным данным клиентского компьютера и пользователя, и такие сети VLAN используют разные подсети IPv4 или IPv6.
После создания профиля беспроводной сети с настройками SSO в рамках политики, клиентские компьютеры под управлением Windows Vista можно настроить путем экспорта профиля в виде XML-файла и его импорта на клиентские компьютеры с Windows Vista.
Чтобы создать XML-профиль беспроводной сети с SSO, создайте профиль с соответствующими настройками единой регистрации. На вкладке «Общие» настроек беспроводной политики Windows Vista, щелкните профиль беспроводной сети с настройками единого входа, и нажмите кнопку «Экспорт». По запросу укажите имя XML-файла с профилем и его расположение.
Чтобы использовать XML-профиль SSO для настройки другого клиентского компьютера под управлением Windows Vista, импортируйте XML-профиль при помощи следующей команды:
netsh wlan add profile filename=
    "[FileName].xml"
Чтобы определить, включен ли единый вход в профиле беспроводной сети, введите:
netsh wlan show profile=[ProfileName]
Параметры единого входа указываются в области «Настройки безопасности» после выполнения команды «netsh wlan show profile» и в описании событий беспроводных подключений в журнале событий Windows. Можно также воспользоваться оснасткой Просмотр событий для просмотра событий в папке Microsoft\Windows\WLAN-AutoConfig журнала «Приложения и службы» с источником «WLAN-AutoConfig» и номерами событий 13001, 13002, 13003 и 13004.
Дополнительные сведения содержатся на веб-странице «Беспроводные сети» по адресу microsoft.com/wifi. Также щелкните ссылку «За сценой» на боковой панели, чтобы получить дополнительные сведения о процессе единого входа.

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


 Данные исследований: Использование высокоскоростных компьютеров в борьбе против ВИЧ
Данные исследований
Использование высокоскоростных компьютеров в борьбе против ВИЧ
Кристин Ферт (Kristin Firth) и Миа Мэтьюсоу (Mia Matusow)

Думая о медиках-исследователях, вы, наверное, представляете себе мужчин и женщин в белых халатах с пробирками и микроскопами? Возможно, они вам видятся как группа химиков из университета или фармацевтической компании? Это распространенное и, конечно, вполне соответствующее действительности представление о медицинских исследованиях, но это
всего лишь одна сторона работы медиков. В действительности некоторые медицинские исследования проводятся совершенно иначе.
Возможно, вы будете удивлены, когда узнаете, что исследовательский центр корпорации Майкрософт играет ключевую роль в попытках изготовить вакцину против вируса иммунодефицита человека (ВИЧ). Более того, при этом в корпорации нет ни единой спиртовой горелки. Отдел исследований выглядит точно так же, как и любое другое офисное помещение со столами и большим количеством компьютеров.
Так какова же роль корпорации Майкрософт в этих исследованиях? Ученые в белых халатах, работающие в различных университетах и исследовательских центрах, включая госпиталь MGH в Бостоне, университет Британской Колумбии, Вашингтонский университет, Центр исследования рака Фреда Хатчинсона и университет Мердока из Австралии, накопили за время своей работы огромный объем данных. А группа eScience из исследовательского центра корпорации Майкрософт, состоящая из шести человек, из которых пятеро находится в Редмонде, штат Вашингтон, а один — в Нью-Мексико, помогает исследователям обрабатывать и анализировать эту информацию. Исследовательский центр корпорации Майкрософт впервые принял участие в этой программе в 2003 году. Сейчас группа eScience сотрудничает с учеными в рамках самых различных проектов, затрагивающих проблемы общества. Группа работает в тесном контакте с учеными из других организаций, создает специальные программные решения, собирает числовые данные и анализирует результаты.
В рамках одного из приоритетных проектов корпорация помогает анализировать данные по схемам мутации ВИЧ. Дэвид Гекерман (David Heckerman), профессор медицины, кандидат наук, старший научный сотрудник корпорации Майкрософт, рассказывает, что под воздействием иммунной системы зараженного человека ВИЧ быстро мутирует. «В процессе исследований мы пытаемся выяснить, как именно ВИЧ мутирует под воздействием иммунной системы носителя. При этом мы ищем взаимосвязи между типом иммунной системы конкретного пациента и белковыми последовательностями вируса».
Типы иммунных систем и последовательности ВИЧ ученые определяют по образцам, взятым у зараженных людей. Именно на этом этапе происходит обработка числовых данных. Исследование предусматривает поиск взаимозависимостей между тремя тысячами аминокислот ВИЧ и сотнями типов иммунных систем людей. «Мы разработали статистические тесты, дающие больше достоверных взаимосвязей и уменьшающие количество ошибочно положительных или отрицательных результатов, — говорит Карл Кади (Carl Kadie), кандидат наук, ведущий инженер-разработчик исследовательского программного обеспечения корпорации Майкрософт. — Однако эти тесты требуют огромных компьютерных мощностей, причем тем больше, чем больше задействовано образцов. Смысл в том, чтобы создать миллионы моделей и определить максимально достоверные взаимосвязи».

Использование высокоскоростных компьютеров в борьбе против ВИЧ
Всего несколько лет назад ограниченные возможности обработки данных сильно замедляли исследования. Участвующие в проекте исследователи корпорации Майкрософт, вооруженные всего шестью компьютерами, не обладали достаточными мощностями для выполнения анализа в разумные сроки. Анализ всех позиций генома вакцины и различных типов иммунной системы всего лишь 200 образцов занял бы целый год. Даже если бы исследователи использовали исключительно для этого анализа 20 компьютеров, они все равно столкнулись бы со сложной проблемой запуска тестов вручную на 20 отдельных ПК, получения 20 отдельных наборов результатов и обязательного использования дополнительной программы (и времени) для сведения результатов. Управление несколькими заданиями, сбор информации из разных источников и прочие задачи заняли бы слишком много времени. Поэтому они обратились к группе высокоскоростных вычислений (High-Performance Computing, HPC) корпорации Майкрософт.
В 2006 г. исследователи внедрили Windows® Compute Cluster Server 2003. Это решение HPC позволило исследователям объединить мощности многочисленных компьютеров. Фактически сервер Windows Compute Cluster Server позволяет распределять работу между параллельно работающими узлами сервера. Задачи распределения данных по узлам, управления данными и объединения результатов выполняются автоматически. В решение включены процедуры настройки, набор средств управления и встроенный планировщик заданий.
Наконец, оно позволило преодолеть наиболее существенные технические трудности: сняло ограничения по вычислительной мощности и полностью автоматизировало процессы распределения работы и управления данными.

Установка
Специалисты исследовательского центра корпорации Майкрософт полагали, что кластерный подход будет оптимальным решением в данной ситуации. Сервер Windows Compute Cluster Server 2003 хорошо подходит для проектов, где используются приложения, многократно выполняющие одну и ту же операцию (например, в случаях, когда решение проблемы и анализ можно ускорить с помощью параллельного выполнения задач). Однако развертывание такого решения представляет собой не самую простую задачу, поскольку создание систем для высокоскоростных вычислений требует серьезных расходов, особенно на электропитание и системы охлаждения. Системы для высокоскоростных вычислений включают множество серверов, которые могут неделями работать в режиме стопроцентной загрузки процессора.
На следующих этапах нужно определить максимальный размер кластера, который может себе позволить организация, а также место его установки. Если текущая среда построена на базе Windows с Active Directory®, то у администраторов уже есть инфраструктура, необходимая для установки, развертывания и поддержки кластера. В средах, где служба каталогов Active Directory еще не используется, потребуются дополнительные этапы конфигурации.
Кроме всего прочего нужно решить, каким образом создавать узлы внутри кластера. Можно выбрать использование средств, которые входят в пакет Windows Compute Cluster Server 2003, или остановиться на собственных технологиях развертывания. Необходимо установить саму ОС Windows Compute Cluster Server 2003, а также программные приложения, которые будут запускаться в кластере. Кроме того, необходимо предоставить доступ к кластеру пользователям, то есть дать им возможность подключаться и отправлять задания с помощью графического интерфейса или командной строки.
Windows Compute Cluster Server 2003 — это 64-разрядная операционная система (типичная архитектура среды Windows Compute Cluster Server 2003 изображена на рисунке 1). На момент написания этой статьи (июнь 2007 г.) исследовательский центр корпорации Майкрософт запускал самые различные приложения в кластере из 25 серверов IBM eServer 326. В каждом из этих серверов было установлено по два процессора AMD Opteron с частотой 2,6 ГГц.
Рис. 1 Построение высокопроизводительной вычислительной среды на базе Windows Compute Cluster Server 2003
Рис. 1 Построение высокопроизводительной вычислительной среды на базе Windows Compute Cluster Server 2003
Развернув Windows Compute Cluster Server, группа обновила приложение для поиска генетических взаимосвязей, чтобы его можно было запускать в кластерной среде. Развертывать приложения для кластеров не всегда одинаково сложно. Объем необходимого программирования обычно зависит от самого приложения.
Сначала группа разработала универсальный интерфейс пользователя с помощью встроенных средств Windows Compute Cluster Server. Но это было лишь временное решение. Вскоре было разработано собственное веб-приложение, которое было более гибким и поддерживало доступ к некоторым узлам кластера специалистам, находящимся за пределами офиса Майкрософт. Дело в том, что корпорация Майкрософт участвует в форуме по распределенным вычислениям (Open Grid Forum), и некоторые кластеры исследовательского центра Майкрософт открыты пользователям из университетов, расположенных по всему миру. Это позволяет исследователям сотрудничать и распределять рабочую нагрузку.
Помимо графического интерфейса сервер Windows Compute Cluster Server поддерживает интерфейс командной строки, что дает пользователям возможность создавать сценарии. Кроме того, сервер имеет множество различных интерфейсов API, которые можно использовать для разработки программ, взаимодействующих непосредственно с планировщиком заданий Windows Compute Cluster. Центр исследований корпорации Майкрософт выбрал именно эту технологию.

Получение результатов
Использование высокоскоростных вычислений позволило группе eScience из исследовательского центра Майкрософт достичь значительных успехов на пути к созданию вакцины против ВИЧ. «Благодаря высокоскоростным компьютерам мы стали получать результаты гораздо быстрее, — говорит г-н Гекерман. —. Несколько других научных групп, с которыми мы на данный момент сотрудничаем, используют наши статистические технологии и делятся своими открытиями. В итоге ученые уже почти сформулировали новую гипотезу, которую мы будем проверять. Если бы мы до сих пор использовали старые технологии, каждый этап процесса получения результатов занял бы целый год. Теперь для этого нужен всего один день».
До внедрения Windows Compute Cluster Server исследовательский центр корпорации Майкрософт вынужден был бы использовать непрактичные, отнимающие много времени методы анализа. «После появления Windows Compute Cluster Server, — говорит г-н Кади, — выполнение 50 задач по 200 000 образцов в каждом занимает у нас столько же времени, сколько раньше занимало выполнение одной задачи».
Теперь, когда у группы eScience появились огромные вычислительные мощности, она может проводить тесты, включающие многократную обработку смоделированных данных. Результаты тестирования смоделированных данных имеют решающее значение при определении наборов реальных, представляющих наибольший интерес. Чем больше создано моделей, тем надежнее результат.

Извлеченные уроки
Безусловно, исследовательский центр корпорации Майкрософт выиграл от использования ОС Windows Compute Cluster Server, но симбиоз оказался еще важнее. Разработчики из группы высокоскоростных вычислений, работающие над второй версией Windows Compute Cluster Server, по-прежнему получают и используют отзывы группы eScience.
В частности, в процессе наблюдения за работой кластера исследовательского центра сотрудники группы HPC очень многое узнали о распределении ресурсов и нашли оптимальный способ распределения ресурсов кластера между пользователями. Например, в данном проекте средний пользователь обычно создавал по одному заданию за раз, в среднем по 50 задач в каждом задании. Пользователь отправлял задание, а планировщик заданий Windows Compute Cluster выделял достаточное количество ресурсов для выполнения всех 50 задач. Для этого он незамедлительно привлекал к выполнению задач все доступные узлы. Такой сценарий не создал бы проблем в однопользовательской среде, но при наличии нескольких пользователей, для которых очень важна одновременная работа над проектами, реализовать его достаточно сложно.
Теперь после завершения 10 из 50 задач не происходит освобождение 10 серверов. Перед тем как переключить ресурсы серверов на выполнение другого задания, диспетчер ожидает выполнения всех 50 задач. Разработчики из группы HPC ищут способ перераспределения ресурсов после завершения каждой задачи, а не всего задания.
Кроме того, исследовательский центр корпорации Майкрософт ожидает, что группа HPC поможет устранить определенные проблемы, относящиеся к удобству взаимодействия с сервером Windows Compute Cluster Server пользователей. Исследователи особенно хотят реализовать такой механизм обеспечения безопасности, чтобы учетные данные пользователей автоматически передавались в вычислительный кластер с пользовательского компьютера с веб-интерфейсом. Это решение должно работать с Microsoft® .NET Framework и дополнять проверку подлинности на основе форм ASP.NET, чтобы веб-приложения могли передавать узлам кластера все учетные данные пользователей при каждой отправке задания.
Теперь члены группы eScience исследовательского центра Майкрософт и их коллеги со всего мира могут сосредоточиться на наиболее важных элементах своей работы и передать обработку данных и управление заданиями компьютерам. «Мы может и дальше работать в одной команде, — считает г-н Гекерман. — Мы расширяем границы знаний о ВИЧ и успешно двигаемся вперед в борьбе с этой болезнью».

Кристин Ферт (Kristin Firth) и Миа Мэтьюсоу (Mia Matusow), сотрудники Blue Line Writing & Editing, в течение последних десяти лет занимались разработкой стратегических материалов для государственных и частных корпоративных организаций, действующих на трех континентах.


 Windows PowerShell: Написание регулярных выражений
Windows PowerShell
Написание регулярных выражений
Дон Джонс (Don Jones)

192.168.4.5. \\Server57\Share. johnd@contoso.com. Безусловно, вы узнали три этих элемента: это IP-адрес, путь универсального имени (UNC) и адрес электронной почты. Распознать их форматы для вас не представляет труда. Сочетание цифр, обратной косой черты, символа @ и других условных знаков определяет тип данных, представленных
символами строки. Немного подумав, вы сможете быстро понять, что 192.168 представляет собой допустимый IP-адрес, что 7\\Server2\\Share — это допустимый UNC-путь, а joe@contoso — правильный адрес электронной почты.
Компьютерам, к сожалению, приходится «думать» намного больше, чтобы «понять» сложные форматы, подобные этим. Именно в этом могут помочь регулярные выражения. Регулярное выражение — это строка кода, написанного на особом языке регулярных выражений, который помогает компьютеру идентифицировать строки определенного формата, такие как строки IP-адреса, UNC или адреса электронной почты. Хорошо написанное регулярное выражение способно обеспечить использование сценария Windows PowerShellTM для принятия допустимых или отклонения недопустимых данных, формат которых не отвечает заданному.

Простое совпадение
Оператор –match в Windows PowerShell сравнивает сроку с регулярным выражением (regex) и затем возвращает значение «Истина» или «Ложь» в зависимости от совпадения строки с выражением. Самое простое регулярное выражение даже может не иметь какого-то специального синтаксиса — буквенных символов будет достаточно. Пример:
"Microsoft" –match "soft"
"Software" –match "soft"
"Computers" –match "soft"
При выполнении в Windows PowerShell, первые два выражения возвращают «Истина», а третье — «Ложь». В каждом случае после строки указывается оператор –match, за которым следует регулярное выражение. По умолчанию, регулярное выражение перемещается по строке для получения совпадения. Слово «soft» является частью слов «Software» и «Microsoft», но находится в разных позициях. Также обратите внимание, что по умолчанию регулярное выражение не учитывает регистр — «soft» определяется в слове «Software» несмотря на прописную букву «S».
Но в случае необходимости можно использовать другой оператор –cmatch, который осуществляет сравнение с учетом регистра. См. пример:
"Software" –cmatch "soft"
Это выражение возвращает значение «Ложь», поскольку строка «soft» не совпадает с «Software» при сравнении с учетом регистра. Следует отметить, что также существует оператор imatch, явным образом определяющий отсутствие необходимости учета регистра, хотя это является стандартным поведением для оператора –imatch.

Подстановочные знаки и знаки повторения
Регулярное выражение может содержать ряд подстановочных знаков. Точка, например, соответствует одному экземпляру любого символа. Вопросительный знак соответствует пустому или одному экземпляру любого символа. Ниже приводятся некоторые примеры.
"Don" –match "D.n" (True)
"Dn" –match "D.n" (False)
"Don" –match "D?n" (True)
"Dn" –match "D?n" (True)
В первом примере, точка заменяет один символ, поэтому совпадение имеет значение «Истина». Во втором примере, точка не соответствует одному символу, поэтому результат — «Ложь». Вопросительный знак в третьем и четвертом выражении может соответствовать одному неизвестному символу или вообще не определять символы. Наконец, в четвертом примере, получен результат «Истина», поскольку и «D» и «n» были найдены без символа между ними. Таким образом, вопросительный знак можно рассматривать как заменяющий необязательный символ, так что совпадение будет по-прежнему иметь значение «Истина», если в этой позиции символ отсутствует.
Регулярное выражение также может использовать символы * и + как знаки повторения. Эти знаки должны следовать за каким-либо символом или символами. Знак * соответствует нулевому или большему числу указанных символов, в то время как + соответствует одному или более указанным символам. Вот несколько примеров.
"DoDon" –match "Do*n" (True)
"Dn" -match "Do*n" (True)
"DoDon" -match "Do+n" (True)
"Dn" -match "Do+n" (False)
Обратите внимание, что и *, и + соответствуют «Do», только не «o». Это происходит потому, что знаки повторения служат для сопоставления с рядом символов — не только одним символом.
А что если необходимо добиться совпадения с самими знаками точки, *, ?, или + ? В этом случае перед ними нужно просто указать обратную косую черту, которая служит управляющим символом для регулярного выражения:
"D.n" -match "D\.n" (True)
Обратите внимание, в Windows PowerShell используется другой управляющий символ (обратный апостроф), но это соответствует отраслевому синтаксису регулярных выражений.

Классы символов
Класс символов — расширенная форма подстановочных знаков, представляющая целую группу символов. Windows PowerShell распознает немного классов символов. Например:
  • \w соответствует любой букве и цифре.
  • \s соответствует любому символу разделителя, такому как символ табуляции, пробела и т.д.
  • \d соответствует цифровому символу.
Также существуют классы символов отрицания: \W соответствует любому символу, кроме буквы, \S соответствует любому символу, отличному от разделителя, и \D соответствует нецифровым символам. После этих классов можно указать * или +, чтобы определить возможность нескольких совпадений. Вот несколько примеров.
"Shell" -match "\w" (True)
"Shell" -match "\w*" (True)
Командлет месяца
Командлет Write-Debug очень помогает при записи объектов (например строк текста) в конвейер Debug. Однако использование этого командлета в оболочке может немного разочаровать, поскольку кажется, что он ничего не делает.
Смысл в том, что конвейер Debug закрывается по умолчанию — переменной $DebugPreference присваивается значение «SilentlyContinue». Задайте значение «Continue», и все отправляемые данные с командлетом Write-Debug появится в консоли в виде текста желтого цвета. Это отличная возможность трассировки кода для сценариев, которая позволяет следить за выполнением сложного сценария. Желтый цвет позволяет различать трассировку и нормальные результаты сценария, а отладочное сообщение можно отключить в любой момент без необходимости удаления всех выражений Write-Debug. Просто присвойте переменной $DebugPreference значение "SilentlyContinue" еще раз и отладочный текст будет отключен.

Несмотря на то, что оба выражения возвращают значение «Истина», они совпадают с абсолютно разными строками. К счастью, можно понять, что скрывает в себе оператор –match: при каждом совпадении, специальная переменная $matches заполняется результатами совпадения, т.е. независимо от того, с какими символами в строке, оператором было обнаружено совпадение с регулярным выражением. Переменная $matches возвращает собственные результаты до положительного совпадения оператора –match. На рис. 1 показана разница между двумя только что описанными выражениями. Как видите, оператор \w вызвал совпадение с «S» в слове «Shell», а повторяющийся оператор \w* — со всем словом.
Рис. 1 Возможность использования знака *
Рис. 1 Возможность использования знака *

Группы символов, диапазоны и значения размера
Регулярное выражение может также включать группы или диапазоны символов, заключенные в квадратные скобки. Например [aeiou] означает, что любой из заключенных в скобки символов — a, e, i, o или u — является допустимым совпадением. Группа [a-zA-Z] означает, что любой из символов в диапазоне a-z или A-Z допустим (хотя, если использовать не учитывающий регистр оператор –match, будет достаточно указать только a-z или A-Z). Приведем пример:
"Jeff" -match "J[aeiou]ff" (True)
"Jeeeeeeeeeeff" -match "J[aeiou]ff" (False)
При помощи фигурных скобок можно также указать минимальное или максимальное число символов. {3} означает, что необходимо получить только три указанных символа, {3,} означает, что нужно от трех символов, и {3,4} что нужно от трех до четырех символов. Этот оператор дает отличную возможность создания регулярного выражения для IP-адресов:
"192.168.15.20" -match "\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}" (True)
Приведенное регулярное выражение будет запрашивать четыре группы цифр, от одной до трех в каждой группе, разделенной символом точки. Рассмотрим следующий пример:
"300.168.15.20" -match "\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}" (True)
Здесь определены пределы регулярного выражения. Хотя форматирование этой строки напоминает IP-адрес, очевидно, что это недопустимый IP-адрес. Регулярное выражение не может определить фактическую допустимость данных — возможно установить только правильность представления данных.

Исключение перемещения
Ошибки регулярного выражения определить не так просто. Например, ниже приведено регулярное выражение, проверяющее UNC-путь в формате \\Server2\Share:
"\\Server2\Share" -match "\\\\\w+\\\w+" (True)
Здесь само регулярное выражение сложно прочитать, поскольку для каждой обратной косой черты, которую нужно проверить, требуется указать управляющий символ в виде второй обратной косой черты. Хотя выражение может показаться рабочим, на самом деле это не так:
"57\\Server2\Share" -match "\\\\\w+\\\w+" (True)
Второй пример, очевидно (по крайней мере, нам с вами), не может быть допустимым UNC-путем, но регулярное выражение сработало. Почему? Помните, что регулярное выражение по умолчанию будет «перемещаться» по строке. Это регулярное выражение просто выполняет поиск двойной косой черты, одной или нескольких букв и цифр, еще одной косой черты и других букв и цифр. Такой шаблон присутствует в строке вместе с другими цифрами в начале, что делает его недопустимым именем UNC. Теперь в регулярном выражении нужно указать поиск совпадения с начала строки — без перемещения. Это можно сделать следующим образом:
"57\\Server2\Share" -match "^\\\\\w+\\\w+" (False)
Символ ^ указывает с какой позиции начинается строка. Добавив этот символ, недопустимый UNC-путь пропускается, поскольку регулярное выражение выполняет поиск двух символов (двойная обратная косая черта), а в этом случае они отсутствуют.
Подобным образом, символ $ можно использовать для обозначения конца строки. Однако этот символ не будет очень полезным в случае в UNC-путем, поскольку UNC-путь может содержать дополнительные сегменты, например \\Server2\Share\Folder\File. Но я уверен, во многих случаях может возникнуть необходимость указывать конец строки.

Справка по регулярным выражениям
В Windows PowerShell, разделы справки about_regular_expressions включают основное описание синтаксиса языка регулярных выражений, но дополнительные сведения можно найти в Интернете. Например, на одном из моих любимых веб-узлов — www.RegExLib.com, находится бесплатная библиотека регулярных выражений, написанных для различных целей другими пользователям. Чтобы быстро найти подходящее регулярное выражение, можно воспользоваться поиском по ключевым словам «e-mail» или «UNC» — этого будет достаточно для начала. Если вам удастся создать отличное регулярное выражение, вы можете поделиться им, поместив его в библиотеку, чтобы им могли воспользоваться и другие пользователи.
Мне также нравится ресурс RegexBuddy (www.RegexBuddy.com). Здесь можно загрузить недорогой инструмент — графический редактор регулярных выражений. RegexBuddy упрощает сборку сложных выражений и тестирование регулярных выражений, что гарантирует должную обработку допустимых строк и отклонение недопустимых. Группа других разработчиков программного обеспечения также предлагает бесплатную, пробную и коммерческую версии редакторов регулярных выражений и инструментов тестирования, которые точно будут полезны пользователям.

Использование регулярных выражений
Возможно, вам интересно узнать, в каких случаях могут понадобиться регулярные выражения. Предположим, вы считываете данные из CSV-файла и используете полученную информацию для создания новых пользователей в Active Directory®. Если CSV-файл создан другим пользователем, необходимо убедиться, что указанные в нем данные верны. Регулярные выражения идеально подходят для этого. Простое выражение типа \w+, например, поможет убедиться, что имена и фамилии пользователей не содержат каких-либо специальных символов или знаков, а более сложное выражение позволит установить соответствие адресов электронной почты принятому корпоративному стандарту. Например, можно использовать такое выражение:
"^[a-z]+\.[a-z]+@contoso.com$"
Это выражение определяет форму адреса электронной почты — don.jones@contoso.com, где имя и фамилия могут содержать только буквы и должны быть разделены точкой. Кстати, адреса электронной почты сложнее всего описывать в регулярном выражении. Если удастся ограничить поиск определенным корпоративным стандартом, то будет проще.
И не забывайте указывать начальные и конечные символы привязки (^ и $), чтобы гарантировать, что после сочетания «contoso.com» нет символов, и до него не указано имя пользователям, также представленное символами.
В принципе, использование подобного регулярного выражения в Windows PowerShell не представляет труда. Предположив, что переменная $email содержит адрес электронной почты, считываемый из CSV-файла, следующее выражение поможет проверить его допустимость:
$regex = "^[a-z]+\.[a-z]+@contoso.com$"
If ($email –notmatch $regex) {
  Write-Error "Invalid e-mail address $email"
}
Кстати, в этом примере представлен новый оператор. Оператор -notmatch возвращает значение «Истина», если строка не соответствует указанному регулярному выражению. (Также существует оператор –cnotmatch для сравнения с учетом регистра.)
Можно еще очень много рассказать о регулярных выражениях — дополнительные символы классов, расширенные операции или даже оператор или два. А еще есть тип объекта [regex], поддерживаемый Windows PowerShell. Но в общем того, о чем мне удалось рассказать в этой ознакомительной статье, о синтаксисе регулярных выражений, должно быть достаточно для начала. Можете смело обращаться ко мне на форуме www.ScriptingAnswers.com, если крайне сложную головоломку в виде регулярного выражения решить не удается.

Дон Джонс (Don Jones) — пишущий редактор журнала TechNet Magazine и соавтор книги Windows PowerShell: TFM (издательство SAPIEN Press). Он обучает работе с Windows PowerShell (www.ScriptingTraining.com) и с ним можно связаться через веб-узел ScriptingAnswers.com.


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

По многочисленным просьбам, мы подумали, что в этом месяце могли бы сделать кое-что другое: вместо того чтобы начать рассказывать о написании сценариев для системного администрирования, мы начнем — слышите зловещий мотив? — со страшной истории!
Примечание. В общем, с технической точки зрения, если бы мы действительно хотели сделать что-то необычное в этом месяце, мы бы начали разговор о написании сценариев системного администрирования, для разнообразия. Но подыграйте нам, хорошо? Спасибо!
Давным-давно умерла одна из пра-пра-прабабушек «автора сценариев». После того как прабабушка была положена в простой деревянный гроб, прадедушка стал видеть жуткие ночные кошмары, в которых его любимая супруга отчаянно пыталась выбраться из могилы. После нескольких кошмаров и многочисленных молитв прадедушка наконец убедил местные власти эксгумировать тело. Когда гроб был открыт, взору присутствующих предстала страшная картина: ногти прабабушки были поломаны, а внутренняя часть гроба была исцарапана!
В общем-то, эта история могла быть не совсем правдивой. В принципе, чем больше мы о ней думаем, тем больше понимаем, что в этой истории нет и доли правды. Тем не менее, этот рассказ научил нас важному уроку. Мы не знаем, что это, но оно где-то есть.
А, минутку, мы вспомнили! Изначально гробы делали таким образом, чтобы защитить усопших от воздействия окружающей среды и предотвратить разложение. К сожалению, в гробу (ну, теоретически) можно неумышленно похоронить человека заживо так, что он никогда оттуда не выберется. Как ясно свидетельствует рассказ о пра-пра-прабабушке «автора сценариев», даже идеально построенные планы людей могут привести к страшным последствиям — захоронению людей заживо! (Зловещий мотив повторяется.)
Примечание. Если конечно вы не выберете Безопасный гроб, изобретенный Францем Вестером в 60-х годах XIX века. Этот гроб был оснащен нитью, соединенной с колокольчиком, расположенным на поверхности земли; и в случае «преждевременных похорон» «умерший» мог просто позвонить в колокольчик и тем самым позвать на помощь. Конструкция Безопасного гроба также предусматривала наличие складной лестницы, хотя не совсем понятно, как подобная лестница поможет выбраться из гроба, находящегося на глубине 2 метров под землей. Если бы вас похоронили на крыше чьего-нибудь гаража, то конечно, складная лестница помогла бы. А так...
Именно это (то, что идеально построенные планы могут привести к страшным последствия) справедливо для брандмауэров Интернета. (Ну, или что-то вроде того.) Изначально задача брандмауэров заключалась в защите от злоумышленников: блокировка входящего сетевого трафика, обеспечивающая отказ в доступе хакерам к компьютерам. Это здорово, но подобно опасности быть похороненным заживо, здесь также напрашивается неумышленное действие: брандмауэры могут также заблокировать и надежных пользователей. Это в особенности справедливо для инструментария управления WMI, который в выполнении административных задач на удаленных компьютерах опирается на DCOM. Брандмауэры имеют тенденцию блокировать весь входящий трафик DCOM, что очень усложняет (если вообще не делает невозможным) программное управление компьютерами через Интернет. Фактически, без открытия дополнительных портов в брандмауэре, и тем самым повышения уязвимости к действиям хакеров и взломщиков, это абсолютно невозможно. Если конечно не использовать WinRM — удаленное управление Windows (складная лестница в комплект не входит).

Что такое удаленное управление Windows?
Согласно SDK WinRM (msdn2.microsoft.com/aa384426), удаленное управление Windows представляет собой «реализацию корпорацией Майкрософт WS-Management Protocol — стандартного, основанного на SOAP, работающего с брандмауэром протокола, который обеспечивает взаимодействие оборудования и операционных систем различных производителей». Впечатляет, правда? Мы не станем вдаваться в детали протокола WS-Management Protocol в этой статье, поэтому рекомендуется обратиться к SDK для WinRM для получения дополнительной информации. Пока все что нас волнует, это наличие WinRM на Windows Server® 2003 R2, Windows Vista® и Windows Server 2008, и то, что он позволяет управлять компьютерами через Интернет. Для этого WinRM использует порт 80, стандартный порт служб Интернета, открытый у большинства брандмауэров. (Однако порт, используемый WinRM и механизм передачи, заданный по умолчанию (HTTP) можно изменить при желании.)
Также в нашей рубрике в этом номере мы не станем рассматривать порядок установки и настройки службы WinRM. По этому вопросу уже имеется достаточно сведений (msdn2.microsoft.com/aa384372). Однако мы подчеркнем один важный момент: чтобы использовать службу WinRM для получения данных с удаленного компьютера (в чем, собственно говоря, в первую очередь и заключается смысл использования службы WinRM), служба WinRM должна выполняться в обеих системах.
Что это значит? В общем, это означает, что если вы не установили Windows Vista (скажите, что это не так!) на своих клиентских компьютерах или Windows Server 2003 R2 или Windows Server 2008 на серверах, вы не сможете воспользоваться преимуществами службы WinRM, по крайней мере, сегодня. Однако нет необходимости говорить, что этого может не произойти и завтра. (И, конечно, предположив, что ваш брандмауэр позволяет это, вы всегда можете использовать WMI и DCOM для управления удаленными компьютерами.)

Получение всех свойств и экземпляров класса
Кого вообще волнуют предостережения и заявления об отказе от ответственности, правда? Вместо таких пустяков, давайте разберем пример сценария с использованием возможностей WinRM. Как раз кстати у нас оказался простой, небольшой сценарий, который по HTTP-протоколу и через порт 80 позволяет подключаться к компьютеру с именем atl-fs-01.fabrikam.com и затем возвращать исчерпывающие сведения обо всех службах, установленных на этом компьютере. Сценарий во всех его красе смотрите на рис. 1.
Figure 1 Компоненты проекта Silverlight (Close Figure 1)

Файл | Описание
CreateSilverlight.js | Это сценарий JScript (в исходном выпуске Silverlight поддерживает только сценарии JScript), используемый для определения исходных параметров запуска Silverlight, включая XAML-файл, нужный для настройки пользовательского интерфейса и графических объектов.
SampleProject.js | Это просто чистый файл, где можно разместить функции JScript.
Silverlight.js | Этот файл используется для инициализации элементов управления Silverlight.
SampleProject.html | Здесь происходит все веселье. SampleProject.html — это просто HTML-файл, в котором есть код для чтения трех js-файлов. Также в нем есть код для создания экземпляра элементов управления Silverlight.
SampleProject.xaml | А это зачем? Чтобы это узнать, придется вернуться к основному тексту статьи.
Figure 1 Получение списка служб удаленного компьютера (Close Figure 1)
strComputer = "atl-fs-01.fabrikam.com"

Set objWRM = CreateObject("WSMan.Automation")
Set objSession = objWRM.CreateSession("http://" & strComputer)

strResource = "http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_Service"

Set objResponse = objSession.Enumerate(strResource)

Do Until objResponse.AtEndOfStream
    DisplayOutput(objResponse.ReadItem)
Loop

Sub DisplayOutput(strWinRMXml)
    Set xmlFile = CreateObject("MSXml2.DOMDocument.3.0")
    Set xslFile = CreateObject("MSXml2.DOMDocument.3.0")
    xmlFile.LoadXml(strWinRMXml)
    xslFile.Load("WsmTxt.xsl")
    Wscript.Echo xmlFile.TransformNode(xslFile)
End Sub
Как видите, для начала мы присваиваем DNS-имя компьютера (atl-fs-01.fabrikam.com) переменной strComputer. Кроме того, можно было установить подключение по IP-адресу компьютера (или даже адресу IPv6). Пример.
strComputer = "192.168.1.1"
После присвоения значения переменной strComputer мы создаем экземпляр объекта WSMan.Automation, затем вызываем метод CreateSession для подключения к удаленному компьютеру, используя для этого HTTP-протокол (что мы и собирались сделать):
Set objSession = objWRM.CreateSession _
    ("http://" & strComputer)
Как было сказано, нам необходимо получить сведения о службах, установленных на удаленном компьютере. Так же, хотя бы для этого первого примера, нам нужны сведения обо всех свойствах всех служб. Что все это значит? Это значит, что нам нужно указать ресурс URI, привязанный к классу Win32_Service на удаленном компьютере:
strResource = _
  "http://schemas.microsoft.com" & _
  "/wbem/wsman/1/wmi/root/cimv2" & _
  "/Win32_Service"
Хорошо, это не самый лучший URI, который мы когда-либо видели. (Хотя, если подумать, мы не уверены, что когда-либо видели приличный URI.) Однако к счастью, большая часть URI это просто заготовка. На что нужно обратить внимание, так это путь WMI в самом конце:
http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_Service
Это все должно быть довольно просто. А что если нужно подключиться к классу root/cimv2/Win32_Process? Для этого нужно просто изменить путь URI соответствующим образом:
http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_Process
Нужен класс root/default/SystemRestore? И опять, просто измените класс URI, указав при этом область имен по умолчанию (вместо области имен cimv2):
http://schemas.microsoft.com/wbem/wsman/1/wmi/root/default/SystemRestore
И так далее. Кроме того, не хотелось бы включать часть пути http://schemas.microsoft.com/wbem/wsman/1/wmi ресурса URI, но...
Теперь можно попробовать получить некоторые данные. Для этого нужно просто вызвать метод Enumerate, указав переменную strResource в качестве отдельного параметра метода:
Set objResponse = _
  objSession.Enumerate(strResource)
Сможет ли эта срока кода действительно заполнить объект objResponse сведениями о службах, установленных на компьютере atl-fs-01? Еще бы. Однако в отличие от стандартных сценариев WMI, ряд объектов, каждый с собственными свойствами и методами свойств, получен не будет. Вместо этого будет получен большой XML-файл двоичных данных, содержимое которого немного напоминает данные, изображенные на рис. 2.
Figure 2 Красивые цвета (Close Figure 2)
<Canvas
 xmlns="http://schemas.microsoft.com/client/2007"
 xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
 Width="800"
 Height="300">

 <Canvas.Background>
 <LinearGradientBrush>
 <GradientStop Color="Blue" Offset="0.0" />
 <GradientStop Color="Black" Offset="1.0" />
 </LinearGradientBrush>
 </Canvas.Background>

</Canvas>
Figure 2 Большой старый массив двоичных данных в XML (Close Figure 2)
<p:Win32_Service xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:p="
http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_Service" xmlns:ci
m="http://schemas.dmtf.org/wbem/wscim/1/common" xsi:type="p:Win32_Service_Type"
xml:lang="en-US"><p:AcceptPause>false</p:AcceptPause><p:AcceptStop>false</p:Acce
ptStop><p:Caption>Windows Media Center Service Launcher</p:Caption><p:CheckPoint
>0</p:CheckPoint><p:CreationClassName>Win32_Service</p:CreationClassName><p:Desc
ription>Starts Windows Media Center Scheduler and Windows Media Center Receiver
services at startup if TV is enabled within Windows Media Center.</p:Description
><p:DesktopInteract>false</p:DesktopInteract><p:DisplayName>Windows Media Center
Если вы мастерски владеете языком XML, то тогда ничего сложного не будет. Знакомства с языком XML достаточно, чтобы разобрать и понять эту информацию без особого труда (даже так, говоря словами SDK для WinRM, эти сведения «не доступны для чтения»). Но что если вы не разбираетесь в XML? В этом случае у вас есть два пути. Первый. Можно подождать до следующего месяца, когда мы будет говорить о приемах работы с XML для WinRM. И второй. Сделать то же, что мы сделали в примере сценария: использовать инструмент преобразования XSL, устанавливаемый вместе с WinRM.

Что такое XSL
Преобразование XSL — это ни что иное как шаблон, описывающий представление XML-файла. Полное обсуждение XSL-файлов выходит далеко за рамки того, что мы можем себе позволить в этом номере, и даже краткое обсуждение XSL-файлов не поместится в этой статье. Следовательно, мы не станем пытаться объяснять, как работает WsmTxt.xsl (имя встроенного преобразования). Вместо этого мы просто продемонстрируем, как можно использовать такое преобразование для вашего сценария.
При вызове метода «Enumerate» WinRM отправляет поток XML-данных. Для работы с этими данными лучше всего настроить цикл Do Until, выполняющийся до конца потока данных. Вот что мы делаем:
Do Until objResponse.AtEndOfStream
    DisplayOutput(objResponse.ReadItem)
Loop
Как видите, внутри цикла мы вызываем подпрограмму с именем DisplayOutput. После вызова этой подпрограммы мы указываем значение метода ReadItem потока в качестве параметра подпрограммы. (При использовании такого подхода, поток XML возвращается отдельными частями вместо одного большого массива двоичных данных. Наш сценарий, в свою очередь, считывает по одной части или одному элементу XML-данных за раз.)
Тем временем подпрограмма DisplayOutput выглядит следующим образом:
Sub DisplayOutput(strWinRMXml)
  Set xmlFile = _
    CreateObject("MSXml2.DOMDocument.3.0")
  Set xslFile = _
    CreateObject("MSXml2.DOMDocument.3.0")
  xmlFile.LoadXml(strWinRMXml)
  xslFile.Load("WsmTxt.xsl")
  Wscript.Echo xmlFile.TransformNode(xslFile)
End Sub
Короче говоря, сначала мы создаем два экземпляра объекта MSXml2.DOMDocument.3.0, загружаем поток XML-данных (strWinRMXML) в один объект, и затем загружаем XSL-файл (WsmTxt.xsl) в другой объект. После этого мы вызываем метод TransformNode, чтобы использовать сведения в XSL-файле для форматирования и просмотра данных, извлеченных из XML-потока.
Согласен, не так просто, как хотелось бы. Но хотя бы результат (пусть далекий от идеального) намного проще понять (см. рис. 3).
Figure 3 Раскраска текста (Close Figure 3)
<TextBlock
 Name="Test"
 FontSize="40"
 FontFamily="Georgia"
 FontWeight="Bold"
 Canvas.Top="20"
 Canvas.Left="20"
 Text="The TechNet Script Center">

 <TextBlock.Foreground>
 <SolidColorBrush Name="test_brush" Color="red"/>
 </TextBlock.Foreground>

</TextBlock>
Figure 3 Более аккуратная версия XML (Close Figure 3)
Win32_Service
    AcceptPause = false
    AcceptStop = true
    Caption = User Profile Service
    CheckPoint = 0
    CreationClassName = Win32_Service
    Description = This service is responsible for loading and unloading user profiles. If this service is stopped or disabled, users will no longer be able to successfully logon or logoff, applications may have problems getting to users' data, and components registered to receive profile event notifications will not receive them.
Как мы сказали, все это хорошо, но не обязательно отлично, что и будет причиной для обсуждения в следующем номере, когда мы будем рассматривать способы самостоятельной обработки результатов в XML.

Получение выбранных экземпляров и свойств класса
Нет необходимости говорить, что все это здорово, если бы не одна вещь: все это может не совсем соответствовать привычному порядку вашей работы. Да, будут моменты, когда необходимо возвратить все свойства всех экземпляров класса. Но может также возникнуть необходимость (возможно, намного чаще) только в выбранных свойствах или экземплярах класса. Например, могут потребоваться только сведения о запущенных службах. Это можно сделать в обычном сценарии WMI при помощи схожего кода:
Set colItems = objWMIService.ExecQuery _
  ("Select * From Win32_Service " & _
   "Where State = 'Running'")
Отлично. Так как же, в конце концов, добиться, чтобы срока Resource приобрела нужный вид?
Ну, по правде говоря, строка Resource не должна быть похожа на инструкцию ExecQuery. Безусловно, строку Resource нужно изменить, но при этом необходимо выполнить ряд других действий.
В этой связи, посмотрим на рис. 4. На нем показан сценарий WinRM, возвращающий сведения о службах, запущенных на компьютере (вместо списка всех установленных служб).
Figure 4 Приемы работы с TextBlock (Close Figure 4)
<TextBlock.Triggers>
 <EventTrigger RoutedEvent=
     "TextBlock.Loaded">
 <BeginStoryboard>
 <Storyboard>
 <DoubleAnimation
 Storyboard.TargetName="Test"
 Storyboard.TargetProperty="Opacity"
 From="0.0" To="1.0"
 Duration="0:0:5" />
 </Storyboard>
 </BeginStoryboard>
 </EventTrigger>
</TextBlock.Triggers>
Figure 4 Поиск выполняемых служб (Close Figure 4)
strComputer = "atl-fs-01.fabrikam.com"

Set objWRM = CreateObject("WSMan.Automation")
Set objSession = objWRM.CreateSession("http://" & strComputer)

strResource = "http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/*"
strFilter = "Select * From Win32_Service Where State = 'Running'"
strDialect = "http://schemas.microsoft.com/wbem/wsman/1/WQL"

Set objResponse = objSession.Enumerate(strResource, strFilter, strDialect)

Do Until objResponse.AtEndOfStream
    DisplayOutput(objResponse.ReadItem)
Loop

Sub DisplayOutput(strWinRMXml)
    Set xmlFile = CreateObject("MSXml2.DOMDocument.3.0")
    Set xslFile = CreateObject("MSXml2.DOMDocument.3.0")
    xmlFile.LoadXml(strWinRMXml)
    xslFile.Load("WsmTxt.xsl")
    Wscript.Echo xmlFile.TransformNode(xslFile)
End Sub
На первый взгляд может показаться, что приведенный сценарий почти полностью идентичен первому сценарию WinRM, но очень важные отличия в нем присутствуют. Прежде всего, обратите внимание на значение, присвоенное строке Resource:
strResource = _
  "http://schemas.microsoft.com" & _
  "/wbem/wsman/1/wmi/root/cimv2/*"
Заметьте, при написании фильтрованного запроса, мы не указываем фактическое имя класса (Win32_Service), который нам необходим. Вместо этого мы просто подключаемся к пространству имен (root/cimv2), в котором находится этот класс. Не забудьте добавить звездочку (*) в конце. Если этого не сделать, произойдет ошибка сценария и будет выдано сообщение: «... имя класса должно быть "*" (звездочка)», что просто-напросто означает необходимость добавить символ * к имени класса.
Кроме того, нужно определить фильтр (Filter) и Диалект (Dialect):
strFilter = _
  "Select * From Win32_Service " & _
  "Where State = 'Running'"
strDialect = _
  "http://schemas.microsoft.com" & _
  "/wbem/wsman/1/WQL"
С фильтром проблем возникнуть не должно: здесь используем запрос языка WMI (WQL) («Select * From Win32_Service Where State = 'Running'»). А диалект представляет собой язык запросов, который используется при создании фильтра. На данный момент допустим только один язык запросов: WQL. Как бы то ни было, диалект нужно указать, в противном случае произойдет ошибка сценария и будет выдано сообщение: «диалект фильтра ... не поддерживается».
Примечание. Самое интересное, что сообщение об ошибке предлагает удалить диалект при вызове метода Enumerate. Этого делать не следует. При выполнении фильтрованного запроса, диалект WQL должен быть указан. Точка.
Единственное изменение необходимо при вызове метода Enumerate. На этом этапе необходимо указать переменные, представляющие фильтр (strFilter) и диалект (strDialect), а также переменные, представляющие ресурс (strResource):
Set objResponse = _
  objSession.Enumerate _
  (strResource, strFilter, strDialect)
Попробуйте и посмотрите, что получится.
Может, теперь попробуем получить только выбранные свойства класса? Для примера предположим, что нам нужно имя и отображаемые имена всех служб, запущенных на компьютере. Что тогда делать?
Ну, в таком случае можно также прибегнуть к XML и вывести на экран только имя и отображаемое имя. Это можно сделать, но это непросто. Для этого проще будет при назначении фильтра указать именно необходимые свойства:
strFilter = _
  "Select Name, DisplayName " & _
  "From Win32_Service " & _
  "Where State = 'Running'"
После этих действий будет получено только имя и отображаемое имя каждой службы, как показано ниже:
XmlFragment
    DisplayName = Windows Event Log
    Name = EventLog

XmlFragment
    DisplayName = COM+ Event System
    Name = EventSystem
Согласен, форматирование никуда не годится. (Что же делать с XmlFragment?) Еще одна причина, по которой это нужно обсудить в следующем месяце.

Сейчас все будет
Немного удачи — этого вполне достаточно, чтобы начать исследовать дикий и замечательный мир WinRM. Конечно же, мы не могли закончить статью о WinRM, не упомянув о так называемых «моргах ожидания», которые некогда были распространены в Германии. В городах с моргами ожидания, погибших хоронили не сразу. Вместо этого тела помещали в теплое помещение, после чего к пальцам ног и рук привязывали нити. Смысл, естественно, заключался в том, что малейшее движение служило сигналом о помощи. Тела хранились в подобных моргах ожидания до тех пор, пока не было уверенности, что у погибших уже нет надежды, и они больше никогда ничего не смогут сделать.
А теперь представляете большое сходство моргов ожидания с группой Scripting Guys? Конечно, люди никогда не возвращались к жизни в моргах ожидания, а вот ребята из команды Scripting Guys...

Головоломка-сценарий доктора Скрипто
В июне 2007 года группа Scripting Guys посетила конференцию Tech•Ed 2007, проходившую в г. Орландо, штат Флорида. Просто приехать на конференцию не проблема, поэтому мы решили немного повеселиться. К тому же мы подумали, что и другим это тоже будет интересно. С этой целью мы выпустили «Книгу развлечений Доктора Скрипто» – брошюру, наполненную связанными со сценариями головоломками и другой информацией. Мы объединились с журналом TechNet Magazine (то есть уговорили их выделить нам небольшой уголок у выставочного стенда в зале), и раздавали «Книги развлечений» всем проходящим мимо посетителям.
Как оказалось, «Книга развлечений» стала очень популярной (может быть не настолько популярной как куклы-болванчики Доктора Скрипто, но близко к тому). Добрые и отзывчивые люди из журнала TechNet Magazine, увидев еще один способ заработать на успехе группы Scripting Guys (так как Scripting Guys никогда не умели пожинать плоды собственного успеха), попросили нас придумать несколько головоломок. Пока «автор сценариев» Джин Росс (Jean Ross) отвернулась на секунду, «автор сценариев» Грег Стемп (Greg Stemp) сказал: «Конечно, сделаем!» И вот, пожалуйста. Головоломка-сценарий доктора Скрипто. Развлекайтесь.

Сборка сценария
В этой головоломке, все буквы вверху разбросаны и образуют сценарий (в VBScript). Но не волнуйтесь, вам не нужно разбирать их все. Вместо этого нужно просто расположить их в нужном порядке по одному столбцу за раз. Буквы в каждом столбце в верхней области должны заполнять пустые клетки в том же столбце нижней области. Приведем пример:
Как видите, в столбце 1 у нас есть буквы S, C и T. Эти три буквы нужно разместить в том же столбце нижней таблицы в определенном порядке. И когда все буквы будут выстроены в нужном порядке, нижняя таблица при чтении слева направо обретает некоторый смысл. Взгляните на решение.
Видите, буквы S, C и T в столбце 1 перенесены вниз в порядке T, S и C. Они стали первыми буквами каждого слова фразы «The Script Center». Фактическая головоломка немного сложнее, поскольку она больше и в конце должен получиться полный сценарий.
Подсказка: в окончательном сценарии в начале указан полный путь к файлу, затем происходит синтаксический разбор и указывается только имя файла.
Удачи!

Головоломка-сценарий доктора Скрипто.
Ответ: Сборка сценария, ноябрь 2007 г.
В этой головоломке необходимо используя буквы из столбцов заполнить ими соответствующие клетки, так чтобы в нижней области получился сценарий. Получается следующий сценарий:
name = "C:\Scripts\Test.txt"
arr = Split(name, "\")
index = Ubound(arr)
Wscript.Echo "Filename: " _
& arr(index)
Так он выглядит в таблице головоломки:

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


 На страже безопасности: Безопасный доступ, где бы вы ни находились
На страже безопасности
Безопасный доступ, где бы вы ни находились
Джон Морелло (John Morello)

Мало кто ставит под сомнение тот факт, что одним из основных приоритетов в развитии технологий современных компаний является обеспечение максимальной доступности и мобильности сотрудников. Во многих организациях люди работают из удаленных офисов, из дома или часто ездят в командировки к заказчикам. Обеспечение удобного доступа к приложениям и данным вне зависимости от их местонахождения
делает работу таких сотрудников более продуктивной. До недавнего времени безопасный удаленный доступ часто предполагал установку клиентского программного обеспечения, ввод секретных команд и длительную установку соединения.
Но за последние несколько лет появилось несколько новых подходов, позволяющих упростить удаленный доступ. Например, веб-клиент Outlook® Web Access (OWA) предоставляет пользователям удобный доступ к электронной почте, календарю и списку контактов из обозревателя без сложностей, связанных с полноценной виртуальной частной сетью (VPN) уровня 3. Хотя такие технологии, как OWA, позволяют сформировать значительную часть решения для «доступа из любого места», ключевые приложения многих организаций не поддерживают работу с помощью обозревателя. В таких случаях эффективным способом предоставления пользователям удаленного доступа к приложениям становятся решения, подобные службам терминалов.
В Microsoft Windows Server® 2008 стандартный набор функций служб терминалов был заметно расширен. Теперь в службы терминалов включена поддержка удаленных окон, функция RemoteApp, обеспечивающая доступ к отдельным приложениям, универсальный драйвер принтера EasyPrint и веб-портал TS Web Access. Кроме того (и это особенно важно для доступа из любого места), в Windows Server 2008 входит шлюз служб терминалов, выполняющий SSL-инкапсуляцию для протокола удаленного рабочего стола (RDP) и позволяющий легко и безопасно проходить через брандмауэры и устройства трансляции сетевых адресов (NAT). Шлюз служб терминалов интегрируется с еще одной новой технологией Windows Server 2008 — защитой доступа к сети (NAP) — и позволяет выполнять проверку работоспособности конечного клиента. Используя все эти компоненты, организации смогут создавать решения, предоставляющие пользователям простой и безопасный доступ к приложениям и данным из любого места.
Данная статья посвящена различным аспектам проектирования сети и системы безопасности в решениях доступа из любого места, и в ней нет подробного описания управления компонентами служб терминалов. Методы и рекомендации по созданию таких решений будут объясняться на примере технологий Windows Server 2008.

Что нас не устраивает в виртуальных частных сетях уровня 3?
При изучении каких-либо новых технологий очень важно понимать их преимущества в сравнении с текущими подходами, чтобы можно было точно оценить ценность новых моделей. Для классических сетей VPN уровня 3 наиболее характерны две проблемы: недостаточный уровень безопасности и сложность в применении.
Упоминание о безопасности как о проблеме в случае со многими современными VPN уровня 3 может на первый взгляд показаться удивительным. Разве основная идея технологии VPN не заключается в прокладывании безопасного туннеля через Интернет? Чтобы это понять, давайте выясним, что обычно понимают под угрозами VPN. Я не утверждаю, что при передаче данных в сетях VPN возникает опасность перехвата или вмешательства; большинство современных VPN уровня 3 используют отличные методы шифрования потока данных. Но давайте попробуем представить, какую угрозу создают удаленные компьютеры, получающие полный доступ ко всем портам и протоколам сети вашей организации. Проблема не в потоке данных, который VPN уровня 3 шифрует и передает по сети, а в удаленных клиентах, которые подключаются по этим туннелям и увеличивают риски вашей внутренней сети. Вспомните, что большинство организаций, пострадавших от таких вредоносных программ, как Slammer или Blaster, получили их не от компьютеров внутренней сети или хакеров, проникших через брандмауэр. Вирус пришел от удаленных сотрудников, которые подключались к сетям организаций через VPN с помощью зараженных компьютеров. Если такие VPN создают подключения уровня 3 с полноценной маршрутизацией, то удаленные компьютеры получают практически полный доступ к ресурсам компании наравне с внутренними компьютерами организации. И доступ этот может быть равно полезен и опасен.
Более того, использование VPN уровня 3 часто дорого обходится, поскольку предполагает установку и настройку программного обеспечения на компьютерах, которыми не занимается ИТ-группа данной организации. Например, при установке клиента VPN на домашнем компьютере иногда приходится создавать пользовательские пакеты установки, давать пользователю подробные инструкции по установке и устранять конфликты с установленными приложениями. А при возникновении потребности в развертывании новых версий клиента или изменении данных конфигурации (например, при добавлении новой конечной точки VPN) расходы на управление могут еще более увеличиться. Для пользователя работа через VPN тоже редко оказывается удобной и интуитивно понятной. Поскольку предоставляется только подключение уровня 3, бизнес-приложения и данные невозможно сделать легкодоступными и видимыми.

Решение проблем с помощью служб терминалов
Службы терминалов и прочие так называемые технологии VPN уровня 7 (или уровня приложений) устраняют эти две проблемы и позволяют осуществлять более тонкую настройку доступа пользователей к ресурсам и протоколам, а также значительно упрощают работу пользователя и делают ее интуитивно более понятной.
С точки зрения безопасности наиболее заметная разница между VPN уровня 3 и VPN с использованием служб терминалов и шлюза служб терминалов состоит в том, что подключение к внутренней сети не полностью открыто. В частности, если на уровне 3 создается виртуальный интерфейс локального компьютера с полноценной маршрутизацией во внутреннюю сеть, то шлюз служб терминалов пропускает во внутреннюю сеть только пакеты на базе RDP. Таким образом существенно сокращается уязвимая для атак область и появляется возможность более избирательного контроля RDP. Например, протокол RDP поддерживает переадресацию дисков, но организации могут интегрировать шлюз служб терминалов и NAP и заблокировать эту функцию, в случае если антивирусное программное обеспечение удаленного компьютера устарело.
Что касается конечных пользователей, то для них наиболее очевидными преимуществами служб терминалов станут заметно упростившаяся процедура настройки (зачастую настройка вообще не требуется) и облегченный, более интуитивный доступ к приложениям и данным. Поскольку клиент подключения к удаленному рабочему столу встроен в Windows (и обновляется автоматически с помощью обычных служебных технологий, например через центр обновления Windows®), в большинстве случаев клиентское программное обеспечение устанавливать не приходится. Кроме того, благодаря веб-доступу к службам терминалов, пользователи могут ввести один адрес URL и найти там все свои приложения и данные. Достаточно щелкнуть значок соответствующего приложения, и шлюз служб терминалов установит безопасное туннельное соединение через Интернет, а на компьютере пользователя откроется окно с этим приложением. Иными словами, приложение будет выглядеть и работать так, как будто оно установлено локально, вплоть до возможности копировать и вставлять данные или сворачивать окно в панель задач. Благодаря возможностям быстрого доступа к данным и приложениям и простой настройке, удаленный доступ на базе служб терминалов значительно снижает расходы на техническую поддержку, а работа пользователей становится более удобной.

Варианты архитектуры сети
Существует два основных варианта дизайна сети, позволяющих обеспечить доступ к серверу шлюза службы терминалов через Интернет. В первом случае шлюз службы терминала размещается в демилитаризованной зоне между двумя брандмауэрами уровня 3/4. Во втором случае шлюз остается во внутренней сети, а во внешней сети размещается проверяющий входящие фреймы HTTPS брандмауэр (например, Microsoft® ISA Server, Microsoft Intelligent Application Gateway или решение стороннего производителя). Пакеты передаются на внутренний сервер шлюза служб терминалов только после анализа на входе.
Если в организации есть только брандмауэры уровня 3/4 и функция базовой проверки пакетов с отслеживанием состояния, шлюз службы терминалов можно разместить непосредственно в демилитаризованной зоне, как показано на рисунке 1. В таком случае брандмауэр с выходом в Интернет ограничивает возможности подключения к шлюзу и пропускает только внешний трафик HTTPS. При этом брандмауэр не проверяет трафик на уровне приложений — он только передает его шлюзу. После этого сервер шлюза службы терминалов извлекает из пакетов HTTPS фреймы RDP и передает их соответствующему серверу внутри сети. Такие серверы часто отделяет от демилитаризованной зоны второй брандмауэр, пропускающий фреймы RDP, идущие от шлюза службы терминалов к соответствующим внутренним серверам.
Рис. 1 При наличии брандмауэра уровня 3/4 шлюз служб терминалов размещается в демилитаризованной зоне.
Рис. 1 При наличии брандмауэра уровня 3/4 шлюз служб терминалов размещается в демилитаризованной зоне.
Такой сценарий полностью поддерживается и может быть реализован во многих организациях, но у него есть два основных недостатка. Во-первых, шлюз служб терминалов, получающий трафик непосредственно из Интернета, подвергается довольно большому риску атаки со стороны злоумышленников. Например, они могут попытаться атаковать шлюз с использованием сеанса SSL, а поскольку брандмауэр первого уровня проверяет только заголовки, не анализируя остальные данные, такой трафик достигнет шлюза. Это не означает, что шлюз служб терминалов является уязвимым компонентом; его система безопасности прорабатывалась и тестировалась так же строго, как и остальные элементы Windows Server 2008. Однако относительный уровень риска данной конфигурации достаточно высок просто потому, что в ней происходит обработка нефильтрованного трафика, идущего непосредственно из Интернета. Второй серьезный недостаток такой архитектуры — возможное увеличение трафика между шлюзом и внутренним брандмауэром. При проверке подлинности пользователей шлюзу служб терминалов приходится обмениваться данными со службой каталогов Active Directory®. Для реализации такого взаимодействия необходимо настроить во внутреннем брандмауэре исключения не только для HTTPS, но и для многих других портов и протоколов. Такое увеличение числа исключений также делает такую конфигурацию более уязвимой.
Более удачное решение состоит в том, чтобы использовать брандмауэр уровня 7 (уровня приложения), который будет обрабатывать входящие сеансы HTTPS до того, как они достигнут шлюза ( рисунок 2). В такой конфигурации для формирования демилитаризованной зоны также можно использовать традиционные брандмауэры уровня 3/4. Однако при этом вместо шлюза служб терминалов на периметре будет находиться брандмауэр уровня 7. Внешний брандмауэр отфильтровывает весь входящий трафик за исключением фреймов HTTPS, которые передаются брандмауэру уровня 7. Брандмауэр уровня 7 прерывает сеанс SSL, проверяет нешифрованное содержимое потока, блокирует злонамеренный трафик и переправляет фреймы RDP через внутренний брандмауэр к шлюзу служб терминалов. Обратите внимание, что при желании брандмауэр уровня 7 может заново зашифровать фреймы перед передачей их шлюзу. Возможно, такой подход не пригодится в частных сетях организаций, но он может оказаться очень полезным для центров обработки данных или общих сетей.
Рис. 2 Использование брандмауэра уровня приложений со шлюзом служб терминалов
Рис. 2 Использование брандмауэра уровня приложений со шлюзом служб терминалов
Такая архитектура устраняет оба недостатка предыдущего решения. Риск атаки из Интернета снижается, шлюз служб терминалов получает трафик от брандмауэра уровня 7. Брандмауэр уровня 7 выполняет фильтрацию пакетов и отправляет шлюзу только чистый, проверенный трафик.
Второе серьезное преимущество этого решения заключается в том, что шлюз расположен во внутренней сети. Поскольку поступающий из Интернета трафик сначала проверяется брандмауэром уровня 7, шлюз можно оставить во внутренней сети и сохранить для него прямой доступ к контроллерам домена (для проверки подлинности) и узлам RDP (для пользовательских сеансов). Кроме того, на внутреннем брандмауэре можно настроить больше запрещающих политик. Вместо того чтобы разрешать RDP-трафик и трафик проверки подлинности через каталог, достаточно разрешить сеансы RDP от брандмауэра уровня 7 к шлюзу служб терминалов. Использование брандмауэра уровня 7 для защиты шлюза служб терминалов является более безопасным решением, которым легче управлять без необходимости изменения архитектуры существующей демилитаризованной зоны.

Интеграция с NAP
Ресурсы служб терминалов
  • Службы терминалов в Windows Server 2008
  • Форум TechNet по службам терминалов Windows Server 2008
  • Блог группы разработки служб терминалов
  • Microsoft Intelligent Application Gateway 2007
  • Защита доступа к сети (NAP) для Windows Server 2008
  • Блог по защите доступа к сети (NAP)
  • Пошаговое руководство по бета-версии 3 Windows Server 2008

Хотя удачная архитектура демилитаризованной зоны является ключевым элементом решения для доступа из любого места, не менее важно обеспечить безопасность и для конечных устройств. Поскольку протокол поддерживает различные типы перенаправления устройств (например, RDP-сеансы или принтеры), крайне важно, чтобы подключающиеся к сети клиенты соответствовали политикам безопасности организации. Например, даже при наличии безопасной топологии сети, созданной с использованием оптимальных методов наподобие тех, которые обсуждались выше, подключение незащищенного компьютера к серверу терминалов может привести к потере конфиденциальных данных и попыткам выложить на сервер терминалов вредные файлы. Несмотря на то, что возможности подключения и потенциальный риск намного меньше, чем при подключении пользователей через VPN уровня 3, очень важно снизить вероятность потери данных и обеспечить выполнение политик компании в области ИТ.
Защита доступа к сети (NAP) — это новая технология в составе Windows Server 2008, позволяющая определить не только то, кто может подключаться к сети, но и с каких типов систем можно подключаться. Например, с помощью NAP можно разрешить подключение к сети только с компьютеров с работающими брандмауэрами и обновленной антивирусной программой. NAP — это расширяемое решение, которое можно распространить не только на внутреннюю сеть организации, но и на удаленных пользователей, которые подключаются через VPN уровня 3 или шлюз служб терминалов. Интеграция NAP в архитектуру шлюза служб терминалов дает возможность разрешить подключение только системам, которые соответствуют принятым в компании политикам безопасности. Дополнительные сведения о NAP см. в моей колонке «На страже безопасности» в выпуске журнала TechNet за май 2007 г., который можно найти по адресу technetmagazine.com/issues/2007/05/SecurityWatch.
Включение NAP в процессе развертывания шлюза служб терминалов представляет собой достаточно простую процедуру, предусматривающую добавление всего одной службы. Эту службу, сервер сетевых политик, можно установить на самом сервере шлюза служб терминалов или в отдельном экземпляре операционной системы. После этого с помощью консоли управления MMC шлюза следует создать политики авторизации подключений, определяющие допустимые функции RDP в заданном состоянии. При попытке установления нового подключения сервер шлюза служб терминалов сверяется с сервером сетевых политик и состояние работоспособности подключения этому серверу. Сервер сетевых политик сравнивает состояние работоспособности со своими политиками и сообщает шлюзу, можно ли разрешить подключение. Решение принимается на основе текущего состояния клиента.
Как видно из рисунка 3, если система не использует центр обновления Windows, а политика организации требует наличия автоматического обновления, то при попытке подключиться к шлюзу она создается и отправляется сообщение о состоянии работоспособности. Оно будет выглядеть примерно так: «Мой брандмауэр и антивирусные программы обновлены, но автоматическое обновление отключено». Шлюз службы терминалов просто передаст это сообщение серверу сетевых политик (в шлюзе не предусмотрено механизмов, позволяющих самостоятельно расшифровать такое сообщение), а сервер сетевых политик сравнит его с политиками, установленными администратором. Поскольку автоматические обновления отключены, сервер сетевых политик определит, что подключение не отвечает критериям политики, и проинформирует шлюз, что подключение разрешать не следует. Шлюз прервет подключение и сообщит пользователю о том, что его компьютер не соответствует политикам безопасности организации. После этого пользователь может принять соответствующие меры (например, просто включить автоматическое обновление) и повторить попытку. Будет создано новое сообщение о состоянии работоспособности, сервер сетевых политик определит, что компьютер соответствует политикам, и шлюз службы терминалов позволит установить соединение.
Рис. 3 Подключаться могут только системы, удовлетворяющие политикам безопасности компании
Рис. 3 Подключаться могут только системы, удовлетворяющие политикам безопасности компании

Заключение
В Windows Server 2008 входят ключевые элементы для создания безопасного решения доступа из любого места. Шлюз служб терминалов — это безопасный механизм создания туннельного сеанса связи с удаленным компьютером в Интернете, предоставляющий организациям широкий выбор вариантов интеграции в существующие сети. Шлюз служб терминалов можно разместить непосредственно в демилитаризованной зоне или защитить с помощью брандмауэра уровня 7, например сервера ISA Server или Intelligent Application Gateway. К шлюзу служб терминалов можно добавить службу NAP с возможностью проверки состояния конечной точки. Проверка конечной точки позволяет компании убедиться, что удаленные подключения осуществляются пользователями, имеющими достаточные полномочия, с устройств, отвечающих политике безопасности компании. Вместе эти технологии предоставляют организациям более безопасные, эффективные и удобные для конечных пользователей возможности удаленного доступа. Более подробную информацию можно найти на веб-страницах, перечисленных под заголовком «Ресурсы служб терминалов» на боковой панели.

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


 Материалы о рабочей среде: Правда о дефрагментации
Материалы о рабочей среде
Правда о дефрагментации
Уэс Миллер (Wes Miller)

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

Дефрагментация и ОС Windows NT
В ОС Windows NT® не было встроенной программы дефрагментации диска. В то время считалось, что такая программа и не нужна. В конце концов, файловая система NTFS создавалась с расчетом на оптимизацию, и для жесткого диска с этой файловой системой фрагментация была не столь вредна, как для жесткого диска с файловой системой FAT. Но со временем даже производительность жесткого диска с файловой системой NTFS может пострадать от неоптимального размещения файлов на диске. Потребность в дефрагментации стимулировала формирование рынка средств дефрагментации, созданных сторонними разработчиками. У ИТ-специалистов большой популярностью пользовалось программное обеспечение Diskeeper компании Executive Software (в настоящее время сменившей название на Diskeeper Corporation). Когда с появлением ОС Windows 2000 в операционной системе появилась поддержка средств дефрагментации, корпорация Майкрософт приобрела у компании Executive Software лицензию на используемую технологию. В ОС Windows® 2000 программа дефрагментации представляла собой подключаемый модуль для консоли управления Microsoft® (dfrg.msc), который можно было вызвать, щелкнув значок диска кнопкой мыши или вручную запустив файл defrag.exe из командной строки. Программа не позволяла запускать дефрагментацию по расписанию. Тем не менее, многие ИТ-специалисты создавали сценарии по автоматизации дефрагментации, используя встроенные в операционную систему средства. По сравнению с более ранней версией файл Defrag.exe в ОС Windows XP и Windows Server® 2003 был несколько усовершенствован и поддерживал некоторые возможности автоматизации. Но все равно для автоматизации процесса необходимо было написать соответствующий сценарий.
Некоторые компании, в том числе компания Winternals Software (где я работал раньше), разрабатывали корпоративное программное обеспечение для дефрагментации. Большинство таких программ работают сходным образом. Они включают централизованную консоль, агент, который работает с клиентскими ПК (все время или только по требованию) и схему, определяющую время и характер выполнения операции дефрагментации.
В ОС Windows Vista® средства дефрагментации жесткого диска компьютера продолжают традиции предыдущих операционных систем. В этой операционной системе оптимизирован дефрагментатор и поддерживаются новые возможности, например дефрагментация небольших фрагментов файлов (не более 64 МБ), что сокращает продолжительность дефрагментации, так как в этом случае не тратится время на большие фрагменты файлов. Механизм дефрагментации в ОС Windows Vista и Windows Server 2008 превосходит по мощности механизм дефрагментации, использованный в более ранних версиях ОС Windows. Кроме того, дефрагментация запускается автоматически, не требуя настройки расписания вручную. Однако если вы работаете в большой организации или хотите оптимизировать работу компьютеров, и для поставленных целей вам не хватает встроенных возможностей дефрагментации, вам, возможно, придется приобрести программное обеспечение другого разработчика. Как и в более ранних версиях, при дефрагментации больших томов, для которых активно используется сжатие NTFS, могут возникнуть некоторые трудности. В этом случае также стоит воспользоваться средствами дефрагментации других разработчиков.

Почему происходит фрагментация?
Фрагментация происходит, потому что со временем файлы претерпевают изменения. В идеале файлы ОС Windows сами по себе не меняются. Ну или, по крайней мере, они меняются не так уж часто, только в случае выхода пакета обновлений и установки обновлений программного обеспечения. В остальном — системные файлы не изменяются. Внесение значительных изменений в систему, например установка пакета обновлений, неизбежно приводит к фрагментации, так как обновляемые файлы чаще всего не удается записать на то же место, которое они занимают на жестком диске. Кроме того, при таких серьезных изменениях может потребоваться перезагрузка, которая приводит к дальнейшей фрагментации.
В отличие от системных файлов, пользовательские файлы и данные (и реестр Windows) постоянно меняются. Операции чтения, записи, изменения, копирования и удаления файлов значительно увеличивают фрагментацию, особенно по мере уменьшения свободного места на диске.
Представьте себе жесткий диск, на котором файлы организованы безупречным образом и расположены вплотную друг к другу, не оставляя в промежутках между собой свободного места на диске. Допустим, вы открываете файл, редактируете его и затем собираетесь его сохранить. Если объем файла увеличился, ОС Windows может либо сохранить целый файл в другом месте на диске (например, после файла N), либо сохранить после файла N только новые данные. В последнем случае файл 2 становится фрагментированным. Если далее изменить файл 1, получится уже два фрагментированных файла. Так постепенно, по мере редактирования других файлов, жесткий диск становится в значительной степени фрагментированным, и для доступа к определенному файлу приходится собирать такой файл по фрагментам, сохраненным в разных местах жесткого диска. Фрагментация типична для жестких дисков, на которых хранятся большие файлы баз данных, объемные файлы жесткого диска, используемые в виртуальной среде, и большое количество видео- и аудиофайлов. Конечно, фрагментация не так ощутима при использовании жестких дисков большой емкости, но сама по себе проблема фрагментации при увеличении объема жесткого диска не исчезает. Кроме того, в результате фрагментации заметно замедляется работа переносных компьютеров предыдущего поколения с жесткими дисками небольшой емкости: падает быстродействие системы, увеличивается продолжительность загрузки, а чтобы открыть или сохранить файл, требуется все больше времени.
Основная проблема даже не в том, насколько фрагментированным является жесткий диск в целом, а в том, насколько фрагментированными становятся отдельные файлы. С момента появления первых дефрагментаторов жестких дисков с цветными диаграммами, каждый пользователь мечтал, чтобы представленная диаграмма представляла собой прямоугольник одного цвета. Но самом деле пользователям нужно совсем не это. Некоторые решения дефрагментации пытаются привести жесткие диски в состояние двух монолитных блоков: цветной блок (данные файлов) и белый блок (свободное место на диске). К сожалению, это весьма неудачный результат, если вы преследуете цель максимально сократить частоту и затраты на дефрагментацию. Если вы произвели сжатие всех файлов, разместив их в одной части диска, практически не оставив там свободного места, при редактировании файлов изменения будут сохраняться в конце данных файла. Поэтому такая дефрагментация фактически приводит к фрагментации сразу же при следующем редактировании любого файла. Вместо двух четко организованных блоков жесткого диска, качественная дефрагментация не всегда представляет собой идеальную картинку. На рис. 1 представлена тестируемая система до дефрагментации. Теперь посмотрите на рис. 2, на котором изображена та же система после дефрагментации, выполненной ОС Windows.
Рис. 1 Жесткий диск до дефрагментации
Рис. 1 Жесткий диск до дефрагментации
Рис. 2 Жесткий диск после дефрагментации
Рис. 2 Жесткий диск после дефрагментации
Обратите внимание, что ОС Windows не столько производит фрагментацию файлов на жестком диске, сколько устраняет фрагментацию отдельных файлов (см. рис. 3, раздел отчета о фрагментации, в котором содержится информация о наиболее фрагментированных файлах до фрагментации жесткого диска).
Рис. 3 Отчет о дефрагментации
Рис. 3 Отчет о дефрагментации
В этом случае даже после дефрагментации ОС Windows не покажет компактный набор данных файлов, сгруппированный в одной части жесткого диска. Обратите внимание на большой раздел данных, представленный зеленым цветом, на рис. 1 и 2. Это файл подкачки Windows, о котором я скажу несколько слов. Если у вас в ОС Windows включен спящий режим, в процессе дефрагментации он будет представлен аналогичным образом.

Важно проводить дефрагментацию регулярно
Как и в случае с зубной нитью, важно помнить, что самое главное — это проводить дефрагментацию регулярно. Особенно важно регулярно проводить дефрагментацию для интенсивно используемых систем, например для серверов. Если затянуть с дефрагментацией, процесс может занять слишком много времени, что приведет к недоступности серверов или уменьшению их быстродействия (дефрагментация может занять довольно много времени, а некоторые ее этапы подразумевают интенсивное использование ресурсов процессора).
Даже самые лучшие сетевые дефрагментаторы не могут дефрагментировать все. Например, им не всегда удается дефрагментировать открытые или заблокированные файлы (в том числе файл подкачки или файлы реестра) и приходится обходить файл спящего режима, если он существует (его размер соответствует объему оперативной памяти вашего компьютера). В следующем разделе я расскажу о хитростях дефрагментации, которые помогут оптимизировать заблокированные файлы.
Думаю, важно разобраться в мифах и фактах, связанных с дефрагментацией. На рис. 4 и рис. 5 перечислены распространенные вопросы, которые упоминаются в связи с дефрагментацией, и указывается вероятность возникновения той или иной проблемы.
Figure 5 Мифы о дефрагментации (Close Figure 5)

Миф | Вероятность
Произойдет сбой системы. | Маловероятно. Сбой системы чаще всего вызывает проблема, связанная с драйверами или аппаратным обеспечением (повреждение памяти, перегрев, вызывающий перезагрузку системы, или сбой диска, вызванный недостаточным охлаждением).
Произойдет сбой приложения. | Маловероятно. Как и в отношении системы в целом, нормально функционирующее приложение не должно выйти из строя из-за фрагментации. Если только само приложение не является причиной сбоя, нет оснований предполагать, что сбой вызвала фрагментация.
Произойдет повреждение реестра. | Маловероятно (см. выше). Фрагментация не приводит к повреждению реестра.
После дефрагментации визуальное представление жесткого диска должно напоминать цельный блок. | Маловероятно. Не следует помещать все файлы в одной части жесткого диска, за исключением случаев, когда вы планируете создать образ системы при помощи специальных средств, представляющих жесткий диск по секторам, что не исключает наличие свободного места на диске, сжатия или разбивки разделов. Необходимо разместить файлы в одной части жесткого диска. В противном случае консолидация файлов приведет к еще более интенсивной фрагментации.
Figure 4 Распространенные проблемы дефрагментации (Close Figure 4)

Проблема | Вероятность
Снижение производительности системы. | Высокая. Степень снижения производительности зависит от использования системы.
Проблематичность или невозможность восстановления случайно удаленных файлов. | Высокая. Работа большинства средств восстановления файлов зависит от эвристики (необходимой для определения типа данных) и расстояния между файловыми кластерами. Если фрагменты файла расположены друг от друга далеко, операция восстановления может быть затруднена или невозможна.
Дефрагментация является дорогостоящей операцией. | Средняя. Существует прямая пропорциональная зависимость между интенсивностью использования системы и объемом изменений файлов, происходящих с течением времени. Например, если пользователи часто редактируют файлы, но сохраняют их только в общих ресурсах сервера, фрагментация будет достаточно умеренной.
Может произойти повреждение жесткого диска. | Низкая. Такое маловероятно. Чем интенсивнее вы используете компьютер (никогда не выключаете компьютер, часто редактируете, изменяете или удаляете файлы), тем больше вероятность, что это может произойти. Но уровень современного аппаратного обеспечения позволяет исключить вероятность повреждения жесткого диска просто из-за редактирования файла.

Дефрагментация как компонент инфраструктуры
Необходимо серьезно обдумать необходимость регулярной дефрагментации для всех компьютеров. Вы можете использовать дефрагментатор, встроенный в ОС Windows, или выбрать решение стороннего разработчика. В основном, выбор зависит от того, сколько дополнительной работы вы намерены выполнить. В ОС Windows XP и в более поздних версиях операционной системы можно добавить файл defrag.exe в качестве назначенного задания. В статье базы знаний support.microsoft.com/kb/555098 описывается, как это сделать. Дефрагментация переносного компьютера имеет ряд особенностей. С одной стороны, лучше проводить дефрагментацию жесткого диска, когда переносной компьютер включен (в идеале, когда он работает от сети). В то же время, нежелательно занимать ресурсы процессора или жесткого диска, когда пользователь работает. К сожалению, если пользователь не работает за переносным компьютером, компьютер, скорее всего, отключен от сети и находится либо в ждущем, либо в спящем режиме (при этом управление питанием и выполнение назначенных заданий невозможно). В компании Winternals (как, наверное, и в любой другой компании), мы потратили много времени, стараясь создать идеальный сценарий дефрагментации для пользователей переносных компьютеров. Если вы используете ОС Windows Vista, решением проблемы может выступить встроенный дефрагментатор и назначенные задания с улучшенным энергосбережением по сравнению с предыдущими версиями. Если этого недостаточно, придется воспользоваться решениями сторонних разработчиков для мобильных ПК. Некоторые из таких решений просто запускают операцию дефрагментации, уведомляют пользователя о том, что операция была выполнена, сообщают, когда она была выполнена (и как часто выполняется) и сколько времени для этого потребовалось.
Кроме выполнения дефрагментации жестких дисков мобильных ПК, иногда приходится решать проблемы фрагментации не только на уровне файловой системы. Эта проблема не возникает при работе с настольными или переносными ПК, но для серверов, Microsoft Exchange, SQL ServerTM или других хранилищ данных тоже может потребоваться дефрагментация. В этом случае надо решить, выполнять ли ее до или после дефрагментации файловой системы.
Если вы используете дефрагментатор другого разработчика, убедитесь, что он использует прикладной программный интерфейс дефрагментации Windows. Начиная с ОС Windows NT 4.0, в ОС Windows используется собственный программный интерфейс дефрагментации, позволяющий предотвратить непредвиденную потерю данных. Например, если в процессе перемещения файла отключается питание системы, мало приятного в том, что перемещение фрагмента не будет завершено и может привести к потере данных или даже невозможности загрузить операционную систему.
Наконец, если вы используете решения виртуализации, возникает вопрос, как проводить дефрагментацию виртуальных дисков. Виртуальные диски подвержены фрагментации так же, как и физические жесткие диски, и в определенном смысле это еще хуже в связи с ограничениями их емкости. Кроме того, если используемое решение виртуализации позволяет сжимать диски или разделы, возможно, сначала следует их дефрагментировать, чтобы освободить место на диске (или, по крайней мере, сократить продолжительность операции сжатия).

Дополнительные средства
Теперь вы уже наверняка признали важность и ценность дефрагментации. Даже если вы не используете средства дефрагментации сторонних производителей, возможно, вас заинтересует средство PageDefrag, разработанное Марком Русиновичем (Mark Russinovich), которое можно загрузить на веб-узле Microsoft Sysinternals (см. microsoft.com/technet/sysinternals/FileAndDisk/PageDefrag.mspx). Как уже отмечалось выше, файл подкачки Windows нельзя дефрагментировать во время работы операционной системы. Точно так же дело обстоит с файлами реестра Windows и журналами событий. При помощи небольшого драйвера средство PageDefrag позволяет дефрагментировать эти заблокированные файлы до того, как ОС Windows закончит загрузку и заблокирует их. Чтобы воспользоваться этим драйвером, просто запустите средство PageDefrag и установите запуск средства при следующей загрузке или при каждой загрузке. При перезагрузке системы (в том месте, где раньше проводилась проверка диска) будет произведена дефрагментация файлов, указанных в списке (см. рис. 6).
Рис. 6 Файлы, дефрагментируемые при помощи средства PageDefrag
Рис. 6 Файлы, дефрагментируемые при помощи средства PageDefrag
После завершения работы средства PageDefrag операционная система продолжит загрузку в нормальном режиме. Если вы хотели бы узнать больше о средстве PageDefrag, Лэнс Уитни (Lance Whitney) писал об этом средстве в сентябрьском выпуске «Обзора служебных программ» (см. technetmagazine.com/issues/2007/09/UtilitySpotlight). Средство PageDefrag поддерживается только в ОС Windows NT 4.0, Windows 2000, Windows XP и Windows Server 2003. В настоящее время оно не поддерживается в ОС Windows Vista.
Кроме средства PageDefrag, на веб-узле Sysinternals можно также загрузить другое средство Contig, которое позволяет вручную дефрагментировать конкретный файл (см. microsoft.com/technet/sysinternals/FileAndDisk/Contig.mspx). Оно может быть полезно, если при выполнении стандартной операции дефрагментации не удалось дефрагментировать определенный файл, или если после выполнения операции дефрагментации он снова стал фрагментированным, в отличие от остальных файлов тома.
Средство Contig также можно использовать для дефрагментации целого каталога или подкаталога, используя специальные шаблоны. Таким образом можно выполнить дефрагментацию всех файлов в каталоге ОС Windows, независимо от местоположения файлов.
Contig –s c:\Windows\*.*
При выборе параметра –v операция дефрагментации будет проходить явно, а при выборе команды –q она будет производиться в фоновом режиме.

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


 Заметки на полях: Кодекс поведения или треска-модератор
Заметки на полях
Кодекс поведения или треска-модератор
Бетси Аоки (Betsy Aoki)

Иногда проблема заключается вовсе не в том, что сервер слабоват, а пользователи начинают приставать с вопросами именно в пятницу вечером, когда вы собираетесь уйти домой пораньше... Она заключается даже не в отладке кода. Иногда нам не хватает чего-то большего.
Около года назад я работала в команде модераторов узла Live QnA (qna.live.com). Мы выискивали хамов и идиотов и нещадно удаляли их сообщения... Нашим оружием были кнопка «Delete», специальные средства и внешние политики. Иногда нам попадались настоящие психи, засорявшие узел всякой гадостью.
И мое терпение подходило к концу. Ведь именно я отвечала за дружелюбную атмосферу в сообществе. Именно я участвовала в разработке кодекса, устанавливающий правила общения в сообществе. И именно мне приходилось следить за тем, чтобы все посетители вели себя прилично и были вежливыми.
Но они почему-то не были. Люди есть люди — от них можно ожидать чего угодно, и если один пользователь обозвал другого болваном, то это воспринималось как потрясающая сдержанность.
И вот однажды я сидела на кухне и в очередной раз обдумывала наш кодекс поведения. Пока я машинально выводила на бумаге какие-то закорючки, в голове у меня возникла неожиданная идея. Что, если за соблюдением этого кодекса будет следить треска [«code» — «кодекс», «cod» — «треска»]? Оставалось решить, как она будет выглядеть и действовать. Я выросла в Новой Англии, где люди постоянно едят треску. Белую, чешуйчатую и уже порядком всем надоевшую. И вот такими же скучными и неинтересными правилами я пыталась убедить участников сообщества вести себя хорошо. Я поняла, что надо забыть про кнопку «Delete», которую я пускала в ход слишком часто, и решила, вооружившись колким юмором, заставить всех вместе посмеяться над теми, кто мешает людям общаться. Так на свет появилась треска Норберт — первая в мире треска-модератор. Я хотела дать ему в зубы трубку, но потом решила, что хватит и галстука-бабочки.
Норберт — треска-модератор
Норберт — треска-модератор
Я загрузила нарисованную рыбку в новую учетную запись Live, дала ей имя пользователя QnA, и Норберт, новый модератор узла QnA, присоединился к нашей команде. Вы, наверное, догадались, что им не всегда была я. Иногда другие члены группы перевоплощались в личность Норберта и наставляли нарушителей на путь истинный. Вы хотите знать, кто прятался под его маской? Зайдите на go.microsoft.com/fwlink/?LinkId=99044. Оскорбляет ли треска-модератор человеческие чувства? Зайдите на go.microsoft.com/fwlink/?LinkId=99045.
Члены сообщества QnA потянулись к нему, как рыба стремится к воде. Они подшучивали над ним, обвиняли его, сердились на него. Он обучал новичков, работал с пользователями, которых, по нашему мнению, еще можно было переманить на сторону света, и предлагал легкий и непринужденный способ просмотра правил взамен чтения скучных официальных веб-страниц.
Правила — будь то политика компании, семейные традиции или порядки в детских играх — всегда зависят от отношения к ним тех, для кого они созданы и кто ощущает на себе их силу. Персонал ИТ или разработчики веб-узлов сообщества могут сколько угодно придумывать разные средства, способствующие выполнению этих правил, но в некоторых ситуациях наилучшим средством будет чисто человеческое чувство, скрывающееся в глубинах сознания — личного или коллективного. Прикладная социология может оказаться гораздо более эффективной, чем прикладное программирование. А обычная треска справится с нарушителями общественного порядка лучше, чем формальные правила.

Бетси Аоки (Betsy Aoki) — руководитель общественных программ группы Xbox корпорации Майкрософт. Ее эмоциональная натура ярко проявляется в сообщениях электронной почты, блогах и, надо надеяться, в XNA Framework.


 Конфиденциальная информация Windows: Парадокс файловой системы
Конфиденциальная информация Windows
Парадокс файловой системы
Рэймонд Чен (Raymond Chen)

Если вы интересовались расположением файлов на жестком диске, вы наверняка замечали, что не так уж мало файлов операционной системы находятся в корневом каталоге загрузочного диска. Если присмотреться к этим файлам, можно заметить интересную вещь: файлы boot.ini, NTLDR и NTDETECT.COM являются основными загрузочными файлами, а файл hiberfil.sys — это файл спящего режима. Все эти файлы используются на наиболее важных первых этапах загрузки операционной системы или, в случае с файлом hiberfil.sys, на этапах восстановления после спящего режима. Эти файлы должны входить в корневой каталог загрузочного диска. Почему их нельзя переместить в какой-либо другой каталог?
Мой коллега, Эдриан Онэй (Adrian Oney), дает следующее объяснение: для чтения загрузочных файлов, находящихся не на диске, нужен драйвер файловой системы, но драйвер файловой системы находится на диске, чтение которого невозможно, если драйвер файловой системы не загружен. Замкнутый круг.
Чтобы разорвать его, используется миниатюрный драйвер файловой системы, встроенный в основные загрузочные файлы. Этот миниатюрный драйвер «знает» ровно столько, сколько необходимо для поиска файлов в корневом каталоге и загрузки этих файлов в память. В свою очередь, эти файлы обеспечивают загрузку операционной системы до такого уровня, когда может использоваться настоящий драйвер файловой системы, который способен находить файлы даже в таких удаленных уголках, как подкаталоги.
При спящем режиме используется приблизительно та же схема. Когда операционная система находится в спящем режиме, все содержимое памяти отправляется в файл спящего режима. При восстановлении после спящего режима содержимое извлекается обратно в память, как будто бы ничего не происходило. И снова возникает замкнутый круг: чтобы загрузить файл спящего режима, нужен драйвер файловой системы, но драйвер файловой системы находится в файле спящего режима. Если файл спящего режима находится в корневом каталоге загрузочного диска, можно использовать миниатюрный драйвер файловой системы.
Пользователям ранних версий MS-DOS® хорошо знакома проблема, связанная с местоположением загрузочных файлов операционной системы. Старая команда SYS превращала ничем не примечательную дискету в магическую загрузочную дискету. Однако попытки использовать дискету, на которой хранятся данные, могли с большой долей вероятности закончиться неудачей, потому что для ранних версий MS-DOS загрузочные файлы должны были занимать определенное место на дискете, чтобы загрузочный сектор мог их найти. В более поздних версиях MS-DOS программа начальной загрузки была усовершенствована, что несколько упростило процесс загрузки. И все же даже в улучшенных версиях системные файлы должны были находиться в корневом каталоге.
Один клиент как-то спросил «Можно переместить файл спящего режима в подкаталог?» В конце концов, какая разница, где расположен файл? Списки управления доступом останутся прежними, куда бы файл ни был перемещен. Поскольку пользователи хотели переместить файл на жесткий диск, который не являлся загрузочным, пришлось объяснить им, что этого нельзя делать. Они не совсем поняли причину запрета, поэтому не сразу отказались от своей идеи: если переместить файл в подкаталог, то можно создать каталог и использовать его как соединение, позволяющее указать размещение файла спящего режима. Ура! Мне удалось переместить файл спящего режима!
Разумеется, миниатюрный драйвер файловой системы ничего не знает о точках подключения, потому что точки подключения подразумевают взаимодействие со службой управления дисками, а на момент загрузки операционной системы компьютер еще даже не загрузил саму операционную систему, не говоря уже о сложной службе, которая знает, как сопоставить буквы, обозначающие жесткие диски, и пути ARC. И даже если каким-то образом вам удастся запустить эту службу, все равно придется найти драйверы устройств для других жестких дисков и загрузить соответствующие драйверы файловой системы.
Когда-нибудь нас обязательно спросят, можно ли переместить файл спящего режима в узел DFS. Это лишь вопрос времени.

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