 TechNet Magazine February 2008

TechNet Magazine February 2008

SharePoint: Интеллектуальный подход ко сбору данных на предприятии

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

Keith Deshaies SharePoint: Создание эффективной инфраструктуры опросов

Сбор и анализ данных являются важной частью бизнеса, но для этого нужны средства, позволяющие независимым группам собирать нужные им данные в нужное время. Узнайте, как WSS 3.0, MOSS 2007 и InfoPath 2007 можно использовать для создания завершенного и гибкого решения опросов, которое можно использоваться в масштабах корпорации.

Jim Bradley SharePoint: Стандартизация управления данными с помощью пользовательских типов содержимого

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

Pav Cherny Office Communications Server: Каким образом присутствие увеличивает возможности OCS 2007

В Office Communications Server 2007 информация о доступности пользователя используется для определения маршрута передачи информации в наиболее подходящее место — будет ли это передача голосового вызова, видеоконференция, сообщение электронной почты или мгновенное сообщение. Рассмотрим, как система OCS 2007 использует присутствие для подключения конечных точек.

Rajesh Ramanathan Office Communications Server: Составьте план развертывания голосовых средств OCS 2007

Интеграция Office Communications Server 2007 с существующей системой УАТС может оказаться сложной задачей. Для нее необходимо уметь выбрать вариант интеграции, разбираться в маршрутизации вызовов, знать, как устанавливаются параметры пользователей, как работать с планами номеров и многое другое. Но беспокоиться незачем. Этот обзор покажет читателям все, что нужно знать в этой области.

Jochen Kunert and Rui Maximo Высокопроизводительные вычисления: Введение в Windows Compute Cluster Server

Вместо крупных специализированных систем в высокопроизводительных вычислениях используются кластеры стандартных систем. Такое распределение нагрузки представляет собой быстрое и экономичное решение сложных задач. В данной статье описываются возможности вычислительных кластеров, работающих под управлением Windows Compute Cluster Server 2003.

John Kelbley and Doug Lindsey Сетевое дополнение: Разверните систему 2007 Office со службами терминалов

В составе выпуска 2007 системы Microsoft Office имеются структурные изменения, о которых следует помнить перед развертыванием ее на ферме серверов служб терминалов. В этой статье дается обзор изменений.

James D. Silliman От редактора: Борьба с информационной перегрузкой

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

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

Greg Steen Вопросы и ответы по SQL : Некластеризованные индексы и сохранение полномочий

Saleem Hakani and Dan Carollo Обзор служебных программ: ADMX Migrator

С появлением Windows Vista формат шаблонов групповых политик превратился в структуру, основанную на XML. Средство ADMX Migrator может преобразовать устаревшие файлы ADM в новый формат ADMX, а также помочь в создании собственных, индивидуализированных файлов ADMX.

Lance Whitney Кабельщик: Проверка подлинности в проводных сетях стандарта IEEE 802.1X

Проверка подлинности IEEE 802.1X обеспечивает дополнительную защитную преграду на пути доступа в интрасеть. Рассмотрим, как Windows Vista и Windows Server 2008 молниеносно реализуют проверку подлинности IEEE 802.1X для проводной сети.

Joseph Davies Windows PowerShell: Полномочия Shell

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

Don Jones Эй, автор сценариев!: Начинаются Игры! И немножко XML заодно

Авторы сценариев Майкрософт все время говорят о чемпионате «Scripting Games 2008», а еще они показывают вам, как создавать, добавлять и изменять документы XML. Но слышали ли вы о чемпионате «Scripting Games 2008», кстати?

The Microsoft Scripting Guys На страже безопасности: Прыжки по островам: смягчение проблемы нежелательных зависимостей

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

Jesper M. Johansson Документы о рабочей среде: Двойная загрузка с Windows XP и Windows PE 2.0

Загрузка Windows PE 2.0 с того же раздела, что и Windows, имеет ряд преимуществ. Узнайте, как загрузить одновременно Windows XP и Windows PE 2.0 с одного раздела, и какие проблемы это поможет решить.

Wes Miller Заметки разъездного инженера: Пожертвуйте свой ПК

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

Jim Lynch Конфиденциальные сведения о Windows: Отдирание карманов

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

Raymond Chen


 SharePoint: Интеллектуальный подход ко сбору данных на предприятии
SharePoint Кит Дешайе (Keith Deshaies)

Интеллектуальный подход ко сбору данных на предприятии
Краткий обзор:
  • Сбор и обработка данных
  • Отделение логики представления от логики управления информацией
  • Использование технологий Microsoft Office 2007 для создания решения по сбору данных
Загрузить исходный код для этой статьи: DataGathering2008_02.exe (567KB)

Предприятия собирают массу информации с помощью ряда методов. Данные поступают по электронной почте, из опросов, веб-форм и других источников. В общем, данные – это хорошая
штука. Однако управлять набором средств сбора данных и массой различной информации непросто. Надежная интеграция и безопасный общий доступ к данным – постоянная забота организаций, работающих в сфере информационных технологий. Развиваются стандарты и архитектуры, ориентированные на службы, и специалистам по информационным технологиям становится проще более безопасно делать данные более доступными. Но даже располагая средствами и технологиями для создания эффективной архитектуры предприятия, очень легко попасться в сеть закрытых интерфейсов, и из-за этого решения получаются изолированными.
Например, возьмем технологии Microsoft® Office. С помощью Windows® SharePoint® Services 3.0 легко создать опрос для подразделения, но будет ли это решение стандартным, зависит от организации. Если организация использует ASP.NET и SharePoint как платформу для интеграции данных и совместной работы в Интернете, то этот опрос будет стандартным решением. Но если вы работает в такой среде, как я, SharePoint – всего лишь одна платформа из многих.
Конечно, SharePoint дает широкие возможности интеграции с системами от IBM, HP, Siebel и так далее. Это хорошо для опытных пользователей, которые хотят создать простое решение, позволяющее, тем не менее, направлять данные в несколько конечных систем. Но если вы архитектор решения, есть способ еще лучше – InfoPath® 2007.
С помощью InfoPath 2007, входящего в систему Office 2007, можно разделить в своем решении логику представления от логики управления информацией, находящейся на серверах. С помощью технологии InfoPath, основанной на XML, можно создавать решения для сбора данных для всего предприятия. И, главным образом, разработчики форм InfoPath не должны подробно знать XML, веб-службы, архитектуры решений, ASP.NET или объектную модель SharePoint.
В этой статье я расскажу, как создать гибкое решение для сбора данных с помощью InfoPath 2007, Office SharePoint Server 2007 и Forms Services. Я покажу вам, как XML позволяет разделить логику представления от логики организации в многоярусной архитектуре предприятия.
Заметьте, что под «сбором данных» я имею в виду процесс получения информации от людей. Конечно, есть другие способы собирать данные, такие, как обход источников данных, но эти автоматизированые методы выходят за рамки этой статьи.

Сбор и обработка данных
Требования к получению данных могут быть сложными, но эти процессы имеют кое-что общее. Пользуясь этими сходствами в централизованных модулях при выполнении уникальных требований в децентрализованных компонентах, можно ограничить избыточную работу, издержки поддержания и общую стоимость владения.
Например, требования соответствия нормативам для открытых акционерных обществ приводят к требованиям бизнеса, которые, в свою очередь, обуславливают политику управления информацией в масштабах компании. Эта политика влияет на решения для сбора данных с многих отделов и часто ведет к повторению одинаковых действий в разных отделах; например, правила сбора личных сведений, получаемых отделом трудовых ресурсов (оработка информации о сотрудниках) и отдел работы с клиентами (обработка информации о клиентах). Даже бизнес-процессы, происходящие между разными сходными, но не имеющими друг к другу отношения отделами позволяют унифицировать решения для управления информацией.
На рис. 1 приведен пример типичного бизнес-процесса. Сотрудник, который хочет обменяться задачей с коллегой, должен в первую очередь получить согласие коллеги, затем одобрение ответственного лица или координатора графика работы и, наконец, руководителя. Например, сотрудники могут меняться сменами. Хотя эти обмены происходят в различных отделах и могут принимать различные формы, рабочие потоки и логика управления информацией могут быть общие для различных решений в отделах.
Рис. 1 Пример процесса сбора данных, который может быть общим для различных отделов
Рис. 1 Пример процесса сбора данных, который может быть общим для различных отделов
Конечно, объединение избыточных компонентов – это трудная задача. Изменить организацию работы в компании непросто, но технологии системы Office позволят заложить надежную основу для таких изменений. InfoPath 2007 позволяет отделам создавать приложения на основе форм, которые интегрируются в централизованные, стандартизированные системы управления информацией. SharePoint 2007, между тем, позволяет отделам информационных технологий передавать административное управление наборами веб-узлов, веб-узлами и библиотеками документов определенным отделам и группам. Таким образом, группы могут создавать и развертывать собственные решения независимо от отдела информационных технологий, а этот отдел сохраняет контроль над всеми общими службами и компонентами, такими, как рабочие потоки, политика управления информацией и процедуры резервного копирования.

Централизация работы по сбору данных
Часто для групп создаются серверы приложений для удовлетворения локальных нужд управления информацией. Отдел информационных технологий просто отвечает за обеспечение работоспособности оборудования и операционной системы, а отделы сами занимаются всеми аспектами своих решений. Координация между отделами невелика, и обмен информацией затруднен.
Технические трудности при централизации сбора данных в основном касаются безопасности, производительности, поддержания и обеспечения работы пользовательских компонентов в общей среде. Например, если индвидуальные решения размещаются на серверах приложений отделов, эффекты неработающего компонента изолированы. Однако в общей среде неработающий компонент может привести к более масштбаным последствиям для бизнес-процессов. Следовательно, отдел информационных технологий должен устанавливать строгие ограничения на развертывание и поддержание пользовательских компонентов в централизованных системах.
Размещение решений SharePoint по отделам на центральной ферме серверов требует развертывания и поддержания всех пользовательских компонентов этих решений на центральных серверах приложений. Одно решение может зависеть от пользовательских типов полей, которые увеличивают пользовательский интерфейс решения за счет раскрывающихся списков, наполняемых из веб-служб, взаимодействующих с пользователем. Другое может использовать для той же цели веб-компоненты, а еще одно может использовать пользовательские рабочие потоки – и те, и другие написаны в управляемом коде и развертываются как сборки Microsoft .NET Framework.
Перемещение даже небольшого числа решений SharePoint на ферму центральных серверов приложений может привести к серьезным проблемам настройки и поддержки. Если сборки необходимо развертывать в глобальном кэше сборок (Global Assembly Cache, GAC), возникают проблемы с безопасностью, так как такие сборки работают с полным доверием. Плохо написанные компоненты могут открыть систему для атак с помощью введения SQL, межузловых сценариев или отказа в обслуживании. Необходимо обеспечить компонентам возможность выдерживать как стандартную, так и пиковую нагрузку и выполнение длительных операций. Следует убедиться, что компоненты не блокируют при одновременном использовании событий другие процессы и что компоненты выполняют надежную проверку ввода, чтобы пользователи не могли вставлять в колонки для обновления базы данных или удаленной веб-системы операторы SQL или сценарии.
Одним словом, задача состоит в создании надежной и масштабируемой серверной конфигурации на основе стандартных функций продукта. Опираясь на тщательно проверенные, универсальные решения, можно избежать ловушки многочисленных пользовательских компонентов. Логично держать клиентскую часть децентрализованной, а серверную – централизованной. Главное – интегрировать компоненты слабо связанным образом, позволяющим повторное использование существующих решений

Разделение бизнес-логики
Итак, как же создавать гибкие решения для сбора данных, которые можно настроить на своих серверах? Лучшая стратегия – разделить архитектуру решения на отдельные уровни, как показано на рис. 2: хранилище данных, бизнес-логикуи представление или пользовательский интерфейс. Сегодня пользовательские интерфейсы обычно основаны на обозревателях, а бизнес-логика располагается на серверах веб-приложений. Они, в свою очередь, используют базы данных и нереляционные хранилища даных.
Рис. 2 Типичное решение для предприятия, созданное на основе трехуровневой архитектуры
Рис. 2 Типичное решение для предприятия, созданное на основе трехуровневой архитектуры
В состав бизнес-логики часто входит логика транзакций, обеспечивающая элементарность выополнения транзакций между системами управления базами данных. В бизнес-логику могут также встраиваться различные службы среднего уровня через HTTP, очередь сообщений, RPC и так далее. Однако общая архитектура решения остается трехуровневой.
Но на рис. 2 не видна сложность бизнес-логики в условиях предприятия. Сервер приложений на этом рисунке как бы просто занят выводом формы на основе обозревателя и обработкой полученных данных; но ведь эта схема не принимает в расчет рабочие потоки, соответствие или требования управления информацией. Чтобы справиться с этим, придется разделить логику пополам – на логику представления и логику управления информацией. Это позволит перемещать и сопоставлять компоненты среднего уровня по желанию, не перестраивая заново компоненты для каждого решения.
Эта архитектура показана на рис. 3. В центре – содержимое или данные, окруженные логикой управления информацией, контролирующей содержимое все время его существования. Логика представления объединяется с логикой управления нформацией, чтобы обеспечить доступ к данным через пользовательский интерфейс.
Рис. 3 Отделение логики представления от логики управления информацией
Рис. 3 Отделение логики представления от логики управления информацией

Сбор и обработка XML
В средах приложений, ориентированных на службы (service-oriented application, SOA), XML – основной стандарт, использующийся для определения и совместного использования компонентами данных и стуктур данных. Поэтому XML – хороший вариант для связи компонентов представления и управления информацией.
Связь должна проходить в двух направлениях: необходимо перевести XML в документ, распознаваемый обозревателем, и в документ XML, создаваемый формой. До последнего времени создание приложений на основе форм в XML требовало большого опыта программирования. Это было особенно важно, когда данные в XML должны были соответствовать общей схеме предприятия, чтобы обеспечить внутренний обмен информацией.
Благодаря InfoPath 2007 разработка форм на основе XML стала гораздо проще. Хорошее знание XML определенно не помешает, но разработчики форм и пользователи не обязаны творить чудеса, чтобы создавать приложения на основе форм в XML. Разработчик формы просто импортирует документ или схему на XML в InfoPath, а затем устанавливает соответствие между отдельными узлами атрибутов и элементов этого источника данных и полей формы. Разработчик может также начать с веб-службы, базы данных SQL Server® или с чистого шаблона, создавая форму с нуля, а InfoPath автоматически в фоновом режиме создает схему и привязки данных.
Стандартизация форм с помощью InfoPath и схем XML имеет несколько преимуществ. Если у вас уже есть хорошо определенная схема на XML, проектировщики форм и разработчики рабочих потоков и компонентов управления информацией могут создавать решения с теми же структурами данных. Если проектировщик форм начинает с нуля, разработчикам приходится ждать, пока форма будет готова, чтобы знть, как она влияет на подлежащие структуры данных. После определения структур данных последующие решения, такие как новые шаблоны форм, могут использовать существующие рабочие потоки и компоненты управления информацией, если они опираются на те же структуры данных. А последующие рабочие потоки и компоненты управления информацией могут работать совместно с существующими формами и данными. Если создавать решения для сбора данных на основе устоявшихся отраслевых схем, результаты получаются еще более гибкими. Эти решения будут совместимы с решениями, создаваемыми другими компаниями, использующими те же схемы.
Я создал простую схему DirectReports, связывающую сотрудников с ответственными лицами. Ответственные лица могут использовать получаемые формы, чтобы рассчтывать прямые отчеты. Схему, форму и файл readme.htm с указаниями для создания формы можно найти в папке Direct Reports в загружаемом приложении к этой статье на странице technetmagazine.com/code08.aspx. Это простая форма, иллюстрирующая общий принцип.
Важная вещь: я не создавал логики проверки в InfoPath, но InfoPath требует, чтобы идентификатор пользователя и адреса электронной почты вводились в определенном формате (домен\учетная запись и recipient@domain.tld). В противном случае итоговый документ XML будет недопустимым. Это связано с тем, что схема XML определяет такие форматы. Форму с недопустимыми данными можно сохранить, но ее нельзя обработать; это показано на рис. 4. (Я добавил в форму заглушку вместо правила обработки, так что это можно проверить, не направляя в действительности данные в какое-либо место.) Проверка InfoPath 2007 автоматически гарантирует правильность заполнения формы.
Рис. 4а Ошибки проверки не позволяют пользователю отправить форму
Рис. 4а Ошибки проверки не позволяют пользователю отправить форму
Рис. 4б Создаваемое сообщение об ошибке
Рис. 4б Создаваемое сообщение об ошибке
Схема XML служит связующим звеном между лоигкой представления и логикой управления информацией. InfoPath блокирует схему, чтобы разработчик форм не мог изменить структуры данных. Это важно, так как изменение принятой схемы XML может нарушить работу существующих решений на предприятии, таких, как модули рабочих потоков, которые вы собираетесь использовать вместе с новым шаблоном форм.
InfoPath имеет множество функций, позволяющих реализовать сложную логику представления в приложениях на основе форм. Чтобы получить осмысленные значения по умолчанию, можно использовать данные из файлов XML, веб-служб, библиотек и списков SharePoint, баз данных и так далее. Можно изменять значения полей в зависимости от выбора пользователя (с помощью правил), добавлять управляемый код для выполнения сложнейших дополнительных условий и использовать службу форм для обеспечения доступа к формам через Интернет. В любом случае форма с данными в некий момент входит в логику управления информацией как документ XML, удовлетворяющий определению схемы.

Работа с XML или метаданными
Следует ли применять логику управления информацией прямо к отправленному документу XML или использовать анализатор, извлекающий нужную информацию в метаданные? SharePoint поддерживает оба варианта. Разработчики обычно используют документы XML, но метаданные дают больше гибкости.
Чтобы это проиллюстировать, я создал простую веб-службу, анализирующую документ XML, передаваемый из формы Direct Reports, показанной на рис. 4. (Исходный код, файлы установки и readme.htm с пошаговыми указаниями находятся в папке XMLParsingWebService folder в загружаемом приложении.) Веб-служба просто считывает идентификатор пользователя ответственного лица из документа XML, разделяет его на имя домена и имя пользователя, создает на их основе сообщение и затем вызывает стандартное исключение, отображающее обработанную информацию в виде псевдосообщения об ошибке в форме InfoPath. Это простой способ открыть в InfoPath диалоговое окно после отправки данных. Веб-служба работает отлично, но если изменить источник данных (например, переименовать в DirectReports.xsd элемент OrgPerson в Manager и обновить форму InfoPath при помощи новой схемы, согласно указаниям в файле readme.htm), веб-служба выдаст ошибку. Ничего удивительного. Документ XML изменился, и старое выражение XPath для доступа к элементу user-id стало неверным. Схемы OrgPerson и Manager практически одинаковы, формы InfoPath идентичны, ожидаемые результаты обработки те же, но несмотря на минимальные различия, придется разворачивать и поддерживать дублирующиеся веб-службы.
Если вы хотите уменьшить количество дополнительного кода на серверах приложений, этот подход плох. Напротив, если связать узлы XML с полями метаданных и проводить обработку на основе метаданных, можно использовать те же рабочие потоки и логику управления информацией для сходных структур данных, даже если схемы XML отличаются. Нужно лишь убедиться, что дочерный элемент соответствует правильному полю метаданных и что формат данных соответствует требованиям обработки; тогда можно использовать уже существующий код.
Связь узлов XML с полями метаданных устанавливается аналогично связи узлов XML с элементами управления пользовательского интерфейса в форме InfoPath form, как показано на рис. 5. В SharePoint поля метаданных соответствуют столбцам, определяемым на уровне веб-узла или списка и имеющим ссылки в определениях типов содержимого. Типы содержимого определяют свойства элементов содержимого, таких как поля метаданных, рабочие потоки и формы. Для синхронизации полей метаданных типа содержимого с соответствующими узлами документа XML, SharePoint использует встроенный анализатор XML, выполяющий внесение и извлечение свойств. При внесении свойств, анализатор XML извлекает значения узлов из документа XML в соответствующие столбцы библиотеки документа. Извлечение свойств – это обратный процесс, при котором значения столбцов извлекаются из библиотеки документа и записываются обратно в документ. Самое главное, что анализатор XML обеспечивает синхронизацию полей метаданных и связанных узлов XML.
Рис. 5 Связь схемы XML между InfoPath и SharePoint
Рис. 5 Связь схемы XML между InfoPath и SharePoint
При использовании модели объекта SharePoint веб-компоненты, рабочие потоки и логика управления информацией могут работать как с полями метаданных, так и с лежащими в основе документами XML. Изменение значения поля метаданных влечет за собой изменение значения узла в документе XML и наоборот. В то же время, работа напрямую с документом XML связывает бизнес-логику со схемой XML. Поля метаданных, напротив, увеличивают возможности повтороного применения кода. Конечно, всегда нужно решать, какой подход больше подходит в данной среде, но чаще всего решения SharePoint, использующие поля метаданных, дают больше гибкости и возможностей повторного использования кода.
Чтобы показать, как SharePoint связывает узлы XML с полями метаданных, я включил в сопровождающий материал функцию SharePoint, обеспечивающую пользовательскую библиотеку документа (см. файл OrgPersonContentType.xml в папке OrgPersonLib в загружаемом приложении). Тип содержимого OrgPerson содержит ссылки на четыре поля: UserID, FullName, EMail и Direct_x0020_Reports. FullName и EMail – встроенные поля. UserID и Direct_x0020_Reports – пользовательские поля, определяемые в OrgPersonSiteColumns.xml.
Определения полей довольно просты. В определениях полей можно привязывать поля прямо к узлам XML, но эту информацию можно также перезаписать в типах содержимого. Я выбрал второй вариант, так как он позволяет использовать пользовательские поля как в типах содержимого, не имеющих отношения к документам XML, так и в типах, использующих различные структуры XML. Тип содержимого OrgPerson привязывает поля метаданных к узлам XML, которые по своей организации соответствуют упомянутой ранее схеме OrgPerson. Также есть файл AdditionalContentTypes.xml, определяющий дополнительные типы содержимого, связывающие те же поля метаданных с другими узлами XML. Различия видны в выражениях XPath в атрибутах Node.
Библиотеки документов в типе OrgPersonLib могут хранить различные типы документов XML, а значения узлов отражаются в одних и тех же столбцах библиотеки. Этот простой прием сопоставления позволяет повторно применять рабочие потоки и логику управления инфорацией, так как четыре типа содержимого (OrgPerson, Manager, Supervisor и User) ссылаются на общий набор полей метаданных.
На рис. 6 показан элемент FieldRef из типа содержимого OrgPerson для Direct_x0020_Reports, который сопоставляет поле и узлы user-id прямых отчетов в соответствии с выражением XPath, /OrgPerson/direct-report/user-id. Так как документ XML может содержать несколько экземпляров прямых отчетов, важно указать атрибут Aggregation. Он определяет, как анализатор XML обрабатывает возвращаемый набор значений. Если опустить этот атрибут, анализатор XML извлекает только первое значение узла. Поддерживаемые значения объединения – sum, count, average, min, max, merge, plain text, first, и last.
Рис. 6 Поля метаданных, сопоставленные с выражением XPath
Рис. 6 Поля метаданных, сопоставленные с выражением XPath
Все приведенные типы содержимого используют стандартную страницу upload.aspx в качестве DocumentTemplate, так что файлы XML можно загружать в библиотеку докментов при нажатии кнопки «Создать» (New) в пользовательском интерфейсе SharePoint. Если вы загружаете файлы с расширением .xml, SharePoint автоматически вызовает встроенный анализатор XML (исключение – файлы WordProcessingML, для которых SharePoint вызывает анализатор WordProcessingML). Анализатор XML изучает загруженный файл .xml и определяет соответствующий тип содержимого. Так он может извлечь значения узлов из указанных в определениях полей мест и выполнить внесение свойств. (Этот процесс можно проверить, загружая файл OrgPerson.xml из папки OrgPersonLib\XMLFiles.) Структура этого документа XML соответствует выражениям XPath, указанным в определении типа содержимого OrgPerson. Таким образом, SharePoint извлекает данные из файла .xml, записывает данные в соответствующие столбцы библиотеки и отображает данные на странице EditForm.aspx, позволяя проверить и обновить те свойства документа, которые не помечены как «доступные только для чтения». На рис. 7 показана форма EditForm.aspx с данными, извлеченными из OrgPerson.xml.
Рис. 7 Форма EditForm.aspx с извлеченными данными
Рис. 7 Форма EditForm.aspx с извлеченными данными
При изменении значений User ID, Full Name или E-Mail в EditForm.aspx SharePoint выполняет извлечение свойств, изменяя значения узлов в подлежащем документе XML. Обратите внимание, однако, что SharePoint не применяет ограничений схемы XML, если вы сами не реализуете нужную логику в форме.
SharePoint также не применяет логику представления приложения на основе форм. Например, при изменении User ID, SharePoint не проверяет, соответствует ли новое значение правилам NetBIOS, и не обновляет автоматически поля Full Name и E-Mail, чтобы они соотвествовали новому выбору. Поэтому, если изменение отдельного поля может вызвать несоответствия, то этот столбец следует пометить как «только для чтения» в определении типа содержимого. Это вынуждает пользователя для обновления данных применять приложение на основе форм, такое как InfoPath, а анализатор XML перенесет любые изменения из документа XML в соответствующие поля метаданных в SharePoint.
В примере OrgPersonLibsample можно загрузить любой из файлов .xml из папки OrgPersonLib\XMLFiles. Файлы .xml используют очень разные структуры данных, но SharePoint распознает типы содержимого и вносит правильные значения узлов в столбцы веб-узла. Это связано с тем, что я применил в файлах XML инструкцию по обработке, предписывающую сопоставлять документы XML с соответствующими типами содержимого. Файл OrgPerson.xml, однако, не содержит этой информации, но это не беда. Если SharePoint не может сопоставить документ XML с типом содержимого с помощью инструкции по обработке или шаблона документа, SharePoint использует тип содержимого по умолчанию. В случае OrgPersonLib, это тип содержимого OrgPerson, таким образом, документ XML анализируется правильно.
На рис. 8 показано, как непосредственно связать документ XML с типом содержимого. Инструкция по обработке MicrosoftWindowsSharePointServices определяет ContentTypeID как 0x010100668E393E4F0EFF4294DBD202D5D8321D. Это идентификатор типа содержимого User, определяется это в AdditionalContentTypes.xml.
Рис. 8 Инструкции по обработке и данные XML файла User.xml
Рис. 8 Инструкции по обработке и данные XML файла User.xml
Анализатор XML обрабатывает инструкцию по обработке MicrosoftWindowsSharePointServices и записывает значение ContentTypeID с поле метаданных ContentType. Все типы содержимого SharePoint имеют это поле метаданных, так как оно определяется на корневом уровне в типе содержимого System. Если открыть файл fieldswss.xml на сервере SharePoint (в папке %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\) и выполнить поиск MicrosoftWindowsSharePointServices, можно увидеть, как SharePoint сопоставляет инструкцию по обработке с полем ContentType. Атрибут PITarget указывает на MicrosoftWindowsSharePointServices (это инструкция по обработке), а PIAttribute указывает на ContentTypeID (содержащий идентификатор типа содержимого User).

Сопоставления типов содержимого в InfoPath
Техническая сторона анализа XML и сопоставлений типов содержимого может затруднять многих разработчиков форм; но InfoPath 2007 позаботится о всех мельчайших деталях. Файл readme.htm, сопровождающий пример OrgPersonLib, включает инструкции для публикации в SharePoint шаблона формы Direct Reports и создания типа содержимого, который опять связывается ес теми же полями метаданных (UserID, FullName, EMail и Direct_x0020_Reports). В пользовательском интерфейсе SharePoint можно легко добавить новый тип содержимого в библиотеку документов OrgPersonLib. Но новый тип содержимого также указывает на шаблон формы InfoPath как на шаблон документа, вызывающего приложение на основе форм при обновлении существующих документов XML. На рис. 9 показано, как мастер публикации InfoPath упрощает сопоставление свойств между значениями узлов XML и столбцами веб-узла SharePoint. И, еще раз, если вы сопоставляете значения узлов с существующими столбцами веб-узла, можно повторно использовать существующие компоненты SharePoint.
Рис. 9 Сопоставление свойств в InfoPath 2007
Рис. 9 Сопоставление свойств в InfoPath 2007

Заключение
Дополнительные материалы в Интернете
  • Блог группы «InfoPath 2007»
  • Спецификации и разработка схемы W3C XML
  • Введение в схемы XML
  • Рабочие потоки в Office SharePoint Server 2007
  • Служба InfoPath 2007 Forms Services

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

Кит Дешайе (Keith Deshaies) -- внештатный автор технических текстов и аналитик по информационным технологиям в большой телекоммуникационной компании. Он специализируется на технологиях Microsoft Office и SharePoint и состоит членом общества технических коммуникаций.
© 2007 Корпорация Майкрософт и компания CMP Media, LLC. Все права защищены; полное или частичное воспроизведение без разрешения запрещено.


 SharePoint: Создание эффективной инфраструктуры опросов
SharePoint Джим Брэдли (Jim Bradley)

Создание эффективной инфраструктуры опросов
Краткий обзор:
  • Планирование и внедрение решения для опроса
  • Сбор и обработка результатов опроса в библиотеках SharePoint
  • Решение вопросов производительности и безопасности

Верные решения нельзя принять без информации. Догадки просто не годятся – тем более в случаях, когда от принимаемых решений зависит бизнес. Это верно и тогда, когда идет речь о том, где устроить корпоративную
вечеринку, или о перемещении 50% ресурсов компании с целью запуска нового продукта. Но как получить эту информацию?
Опросы предоставляют эффективный – и экономичный – способ сбора отзывов обо всем, от того, насколько удовлетворены клиенты предлагаемыми продуктами, до того, понравились ли сотрудникам бутерброды на последнем совещании. Опросы предоставляют содержание, необходимое для будущего улучшения и развития продуктов, систем или процессов. Вопрос состоит в том, как специалист в области информационных технологий может реализовать систему опроса сохраняющую данные, так, чтобы информацию можно было осмысленно использовать.
Вероятно, у вас уже есть одно или несколько средств, необходимых для сбора, структурирования и анализа такого рода данных. Выпуск 2007 системы Microsoft® Office предоставляет эти средства и делает их использование довольно простым. На практике, имеются многочисленные подходы к выполнению опроса. Главное – выбрать подход, соответствующий конкретным нуждам. Например, опросы на основе электронной почты являются хорошим выбором при импровизированном сборе данных в реальном времени, когда опрос охватывает небольшое число респондентов и не самые важные данные. Дополнительные сведения приведены на боковой панели ниже «Использование электронной почты для быстрых опросов». Опросы, управляемые с помощью баз данных, с другой стороны, являются лучшим выбором для более сложных инициатив, включающих большое число респондентов и относящихся к критически важным данным. Для получения дополнительных сведений см. боковую полосу «Создание решений для опросов, управляемых базами данных» ниже.
В этой статье я сосредоточусь на другом, более исчерпывающем и гибком решении: сетевых опросах на основе SharePoint®. Этот подход годится и для критически важных, и для обычных опросов любого уровня сложности. Поскольку опросы SharePoint основаны на Интернете, в них может участвовать любой человек, имеющий доступ к веб-обозревателю – поддерживаются даже мобильные устройства. В опросе SharePoint ответы могут быть поименными или анонимными, результаты доступны в реальном времени, и даже имеется доступ к средствам анализа.
Этот тип опроса реализуется с использованием либо Windows® SharePoint Services 3.0 (WSS) с сервером форм и InfoPath®, либо Microsoft Office SharePoint Server 2007 (MOSS) со службами форм и InfoPath® (описание каждой их этих технологий см. на Рис. 1). Поскольку оба варианта предлагают идентичные по сути возможности, я буду рассказывать преимущественно о втором сочетании. Исчерпывающее сравнение продуктов SharePoint и их функций приведено в загружаемом файле сравнения продуктов Microsoft Office SharePoint Server 2007 на office.microsoft.com/en-us/sharepointserver/HA101978031033.aspx.
Figure 1 Технологии Майкрософт, делающие возможными опросы SharePoint (Close Figure 1)

Технология | Описание
Microsoft Office InfoPath 2007 | Microsoft Office InfoPath 2007 – средство создания форм и сбора информации. Дополнительные сведения приведены на office.microsoft.com/infopath.
Windows SharePoint Services 3.0 | Ранее известные как SharePoint Team Services, службы Windows SharePoint Services 3.0 служат основанием для создания расширенных приложений SharePoint. Дополнительные сведения приведены на microsoft.com/technet/windowsserver/sharepoint/techinfo/overview.mspx.
Microsoft Office SharePoint Server 2007 | Microsoft Office SharePoint Server 2007 (ранее известный как SharePoint Portal Server 2003) предоставляет серверную инфраструктуру, превращающую клиентов Office 2007 в создателей и потребителей содержимого приложений SharePoint. Дополнительные сведения приведены на microsoft.com/sharepoint.
Служба InfoPath Forms Services, Microsoft Office Forms Server 2007 | Служба форм InfoPath позволяет пользователям заполнять формы InfoPath в веб-обозревателе без предварительной установки InfoPath, делая опросы совместимыми с различными платформами и обозревателями. Forms Services требуют Windows SharePoint Services 3.0, хотя точно такие же функции доступны и в виде отдельного продукта, под названием Microsoft Office Forms Server 2007. Дополнительные сведения о службах форм приведены на microsoft.com/ms540731. Дополнительные сведения о Forms Server приведены на office.microsoft.com/en-us/formsserver/FX100490391033.aspx.

План и внедрение
При разработке опроса необходимо заранее обдумать ряд факторов. Это требует некоторого предварительного анализа, так что не забудьте уделить время выработке хорошо продуманного плана опроса. На стадии первоначального планирования следует определить пространство проблемы и искомые данные, технологии, которые необходимо использовать, а также бюджетные и административные требования. Затем можно переходить к реализации. Обычный рабочий поток заключается в разработке формы опроса, ее публикации, сборе и проверке ответов, сведении воедино и анализе данных, завершаясь отчетом о результатах.
Рабочий поток реализации опроса обычно требует, как минимум, его разработчика, респондентов и аналитика, как показано на Рис. 2). Само собой, рабочие потоки опросов могут серьезно различаться по сложности. Например, опрос в масштабах компании пройдет, вероятно, через несколько этапов правок проекта и одобрений начальством. Он, скорее всего, будет включать автоматические напоминания респондентам; различные формы поддержки и борьбы с неполадками; предоставление менеджерам результатов в реальном времени и четкий процесс определения и предоставления завершающего анализа. Сложный рабочий процесс такого рода определенно требует сетевую систему с поддержкой возможностей рабочего потока и отчетов.
Рис. 2 Рабочий процесс опроса от разработки формы до анализа данных
Рис. 2 Рабочий процесс опроса от разработки формы до анализа данных

Что требуется от исчерпывающего решения
Список требований, которым должно удовлетворять исчерпывающее решение опроса, весьма велик. Решение должно позволять отдельным группам и подразделениям создавать, распространять и собирать результаты опросов при минимальном участии отдела ИТ, то есть оно не должно требовать умений программиста. Средство создания форм должно предлагать простой в применении интерфейс WYSIWYG, а также богатый набор функций, способствующих применению передачи по конвейеру, ветвления и условной логики. И, само собой, средство создания форм опросов должно годиться для всех опросов, вне зависимости от размера и сложности.
Более того, опрос должен работать на веб-сервере и интегрироваться с центрально управляемой базой данных SQL Server®, устраняя необходимость содержать специальные базы данных SQL для каждого конкретного отдела. Любой респондент с доступом в Интернет должен иметь возможность участвовать в опросе при помощи любого обозревателя, отвечающего стандартам.
Процесс опроса должен быть легко связываемым с рабочими процессами и соответствовать нуждам бизнеса, не ослабляя при этом безопасность. Для многих организаций решение опроса должно также включать многоязыковую поддержку.
При использовании вместе MOSS 2007, WSS 3.0 и InfoPath 2007 создают интегрированное решение, отвечающее всем этим требованиям. На Рис. 3 показано, как различные компоненты соединяются на стеке SharePoint. Но прежде чем рассказывать о этом полном решении для опроса, я хочу кратко рассмотреть, что может быть достигнуто про помощи одного только WSS. Далее я продемонстрирую дополнительные преимущества, получаемые добавлением в рецепт MOSS и InfoPath.
Рис. 3 Компоненты стека SharePoint
Рис. 3 Компоненты стека SharePoint

Работа с одним WSS
WSS можно использовать для создания и применения опроса даже без других компонентов. Более того, WSS включает встроенный шаблон опроса, делающий этот процесс простым. Чтобы создать опрос, щелкните Пуск | Все программы | Администрирование и выберите SharePoint 3.0 Central Administration. Из развертывающегося списка выберите «Действия узла» и нажмите кнопку «Создать». Отобразится страница создания, показывающая заголовки для библиотек, связей, отслеживания, пользовательских списков и веб-страниц. Под каждым заголовком, имеются варианты шаблонов. Под «Отслеживание» выберите «Опрос».
На этом этапе WSS проводит пользователя через поэтапный процесс создания опроса. Можно создавать открытые или закрытые вопросы и указывать, может ли вопрос быть оставлен без ответа. Можно даже создавать опросы с ветвящейся логикой, ведущие респондентов по различным путям в зависимости от их ответов. Опросы могут быть анонимными или при необходимости идентифицирующими респондента. Есть также возможность назначения рабочего потока опросу.
Опрос основан на обозревателе, так что для его создания или участия в нем не требуется специальных программ. Для участия в опросе респонденту достаточной перейти на веб-узел SharePoint и заполнить форму. Разрешения на доступ наследуются от родительского узла, но могут изменяться прямо из меню действий SharePoint. Ответы на опрос сохраняются на веб-узле опроса SharePoint, а результаты могут быть просмотрены в форме списка, либо графических сводок, или экспортированы в Excel®.
Повторюсь, это решение (с процессом, показанным на Рис. 4) может быть создано с помощью одного лишь WSS. Предполагая, что основательно спроектированный веб-узел SharePoint уже существует, любой отдел должен быть в состоянии создать и применить опрос с минимальной помощью от отдела ИТ.
Рис. 4 Опрос, основанный на службах Windows SharePoint
Рис. 4 Опрос, основанный на службах Windows SharePoint
Одно ограничение процесса лишь на основе WSS становится очевидным, когда опрос требует настройки. WSS создает списки опроса, используя различные страницы ASPX по умолчанию (AllItems.aspx, DispForm.aspx, EditForm.aspx, NewForm.aspx, overview.aspx и summary.aspx). Хотя настройка страниц, выходящая за пределы параметров, присущих WSS, возможна, большая часть функций предоставляется малопригодными к настройке веб-компонентами. Более того, решение лишь на основе WSS лучше всего подходит для опросов, которые не нуждаются во встраивании внешних источников данных, таких как система ERP компании.
В случае необходимости расширить решение для опроса, включив нестандартный интерфейс пользователя или интеграцию с дополнительными источниками данных, стоит серьезно подумать о решении, сочетающем MOSS, WSS и InfoPath.

Завершенное решение для опроса
В состав MOSS входят многие функции, расширяющие WSS, но сейчас я хочу обратить внимание на один компонент – службу форм InfoPath. При наличии службы форм InfoPath только разработчику опроса необходимо установить InfoPath на своем компьютере. Остальные могут получить доступ к опросу через веб-обозреватель.
В InfoPath разработчик выбирает вариант, позволяющий заполнять формы в обозревателе. Тогда InfoPath создает форму, которую можно просматривать на любом соответствующем стандартам веб-обозревателе. Эта веб-форма работает так же, как форма InfoPath, за исключением некоторых расширенных возможностей InfoPath (таких как роли пользователей, вертикальный текст, действия диалогового окна и расширенные элементы управления). Затем форма публикуется в библиотеке SharePoint или списке. В то же время, другая функция InfoPath, именуемая проверкой макета, обеспечивает совместимость формы опроса со службами форм InfoPath.
Между библиотекой форм InfoPath и библиотекой форм с поддержкой веб-обозревателя нет никакой разницы. В обоих случаях, шаблоном формы является файл .xsn. Либо служба форм InfoPath отображает форму в веб-обозревателе, либо файл загружается на клиентский компьютер и отображается прямо в InfoPath. Если у разработчика опросов есть хотя бы полномочие участника для веб-узла SharePoint, он может использовать библиотеки документов SharePoint для публикации шаблонов форм.
Респондент с соответствующим стандартам веб-обозревателем может принять участие в опросе служб форм InfoPath, и его ответы без проблем возвращаются на сервер SharePoint. Внутри SharePoint данные можно безопасно хранить, перебирать, анализировать и распространять (используя Excel, SQL или другие средства, доступные в сети). Все это может быть выполнено с минимальной помощью от администраторов.

Обратная передача и проблемы производительности
Однако при этом существует несколько потенциальных проблем с производительностью. Например, формы с поддержкой обозревателя работают в контексте системной учетной записи на сервере SharePoint, а это значит, что если форма включает подключения к коду или данным (как показано на Рис. 5), эти подключения исполняются на сервере, а не на клиенте. Также, для сложных форм может быть необходима частая передача данных обратно на сервер, что увеличивает загрузку последнего.
Рис. 5 Решение для опроса на основе служб форм InfoPath с дополнительными подключениями к данным
Рис. 5 Решение для опроса на основе служб форм InfoPath с дополнительными подключениями к данным
Чем активнее опрос использует обратную передачу, тем выше нагрузка на серверы клиентского доступа. Однако в некоторых случаях, скажем при применении ветвления ответов, обратная передача неизбежна. В целях сведения к минимуму потенциального отрицательного влияния на систему разработчикам опроса стоит помнить о проблемах обратной передачи и знать, как лучше всего реализовывать опросы в случаях, когда без нее не обойтись. Например, разработчикам следует использовать опросы, подобные мастерам, которые передают данные обратно серверу при нажатии пользователем кнопки "Далее". Это помогает уменьшить число обратных передач.
Служба форм InfoPath должна поддерживать состояние каждой активной формы на сервере. По умолчанию время истечения сеанса равно 60 минутам, а значит если на заполнение сложного опроса уходит более 60 минут, и в течении этого времени не происходит обратных передач, сеанс на сервере будет закрыт. Введенные, но не переданные данные теряются, и респонденту нужно начинать с начала.
Подобные проблемы обостряются, когда большое число респондентов параллельно работает над формой опроса и когда опросы обладают большими источниками данных либо включают вложенные файлы. Дополнительные сведения приведены в статье «Improving the Performance of InfoPath 2007 Forms» («Повышение производительности форм InfoPath 2007») на msdn2.microsoft.com/bb380251.

Соображения безопасности
Хотя подробный рассказ о безопасности выходит за рамки этой статьи, важно подчеркнуть некоторые соображения. Для начала, SharePoint и InfoPath 2007 следуют инициативе доверенных вычислений, принятой Майкрософт в начале 2002 года. Формы InfoPath имеют три возможных уровня безопасности: ограниченный, доменный и полное доверие. По умолчанию, InfoPath автоматически определяет и применяет к форме рекомендуемый уровень безопасности.
Функция цифровой подписи помогает убедиться в том, что форма создана или заполнена определенным пользователем и что она не изменена. А служба управления правами на доступ к данным (Information Rights Management – IRM) может ограничить доступ к шаблонам и заполненным формам. Чтобы лишить пользователей-злоумышленников возможности загружать формы, содержащие вредоносный код, или использовать платформу SharePoint для запуска атак против других систем через подключения данных, InfoPath различает формы, развернутые пользователями и администраторами. Пользователи могут загружать формы, если эти формы не содержат никакого нестандартного кода и используют только доменный уровень безопасности, что ограничивает подключение к данным между доменами. Эти параметры достаточны для большинства решений для опросов.
Если проект опроса получает уровень безопасности «Полное доверие», чтобы допустить неограниченный доступ к ресурсам, публикация форм требует одобрения администраторов. По умолчанию, одобрение администраторов требуется, когда форма содержит управляемый код; когда в шаблоне формы определены междоменные подключения к данным; когда форма использует подключения к данным, определенные в централизованно управляемой библиотеке подключений к данным и когда был включен вариант поддержки отображения на мобильных устройствах.
Для уровня безопасности «Полный доступ» разработчик опроса создает форму InfoPath и сохраняет шаблон формы. Этот шаблон или файл .xsn отправляется администратору SharePoint вложенным в сообщение электронной почты или передается через общий сетевой ресурс. Администратор проверяет функции опроса и содержащийся в нем код, прежде чем сделать его доступным в производственной среде. Он завершает развертывание, загрузив шаблон опроса на семейство веб-узлов и активировав его. Оба процесса выполняются на странице управления приложениями центральной административной консоли WSS. Конечный результат состоит в том, что администратор может делегировать публикацию форм различным отделам, сохраняя возможность наблюдать за процессом публикации, если формы выходят за пределы базовых действий по сбору данных.
Наблюдение администратора необходимо в некоторых распространенных случаях: когда формы должны быть заполнены данными по умолчанию и когда результаты опроса предоставляются нескольким источникам данных. По умолчанию, шаблоны форм с доменным уровнем доверия не могут устанавливать междоменные подключения к данным, но есть ряд способов устранить это ограничение, включая:
  • Выдача форме разрешения «Полное доверие».
  • Использование подключений к данным из библиотеки подключений к данным.
  • Использование централизованно управляемой библиотеки подключений.
Варианты полного доверия и централизованно управляемой библиотеки подключений требуют одобрения администратора в ходе публикации формы. Однако библиотека подключений к данным (data connection library – DCL) позволяет опубликованным пользователями формам пересекать границы доменов, используя библиотеку DCL, поддерживаемую на уровне семейств веб-узлов. Эта библиотека DCL может быть под контролем определенного отдела. Однако важно понимать, что разрешение различным отделам определять их собственные подключения к данным может быть проблемой безопасности.
Наиболее безопасным вариантом является определение подключений к данным в централизованно управляемой библиотеке подключений и развертывание администратором расширенных форм опросов, использующих эти подключения. Централизованно управляемая библиотека подключений выгодна тем, что доступна на всех семействах веб-узлов и всей ферме серверов. Это позволяет администратору определить централизованные параметры проверки подлинности для доступа к источникам данных за пределами локального сервера SharePoint. Дополнительные сведенья см. в статье, озаглавленной "About Data Connections, Authentication, and Alternate Access Mapping" («О подключениях к данным, проверке подлинности и альтернативном сопоставлении доступа») на msdn2.microsoft.com/ms771995.

Заключение
Опросы являются эффективным способом сбора особо и не особо актуальной информации для каждого предприятия и на каждом уровне. Однако создание эффективного опроса требует верных средств, основательного плана и гармоничной смеси науки с искусством. Продуманное предварительное планирование поможет создать решение, позволяющее каждому отделу внутри организации создавать, хранить, отправлять, получать и анализировать данные опросов.
Наиболее эффективны те опросы, которые предоставляют своевременную и актуальную информацию. Чтобы собирать информацию, когда она нужна, решение должно обеспечивать простое создание и управление опросами на уровне отделов – не ослабляя при этом безопасность. InfoPath дает информационным работникам возможность создавать высококачественные опросы, предоставляя интуитивный интерфейс, который можно использовать после краткой подготовки. Также InfoPath позволяет собирать высококачественные данные опросов, не требуя лишнего администрирования.
InfoPath 2007 безупречно взаимодействует с WSS и MOSS, способствуя созданию насыщенных, комплексных решений опросов, совместимых с различными платформами и веб-обозревателями. А это позволяет предприятиям и организациям использовать в полной мере один из своих самых важных ресурсов: информацию.
Использование электронной почты для быстрых опросов
Импровизированные опросы являются важным средством быстрого сбора данных с небольшой группы респондентов. Опросы на основе электронной почты идеальны для такого рода исследований в реальном времени – они быстро создаются и не нуждаются в специальных серверах либо профессиональной помощи. Один из простейших подходов, кнопки для голосования, внедренные в сообщение Microsoft® Outlook®, позволяет отправлять, получать и представлять в табличной форме одномерные опросы.
После запуска опроса на основе кнопок для голосования респонденты получают сообщение электронной почты со строкой голосования, отображающей раскрывающийся список вариантов. Получатели отвечают, выбирая один из вариантов. После этого во всплывающем окне отображается сообщение: «Вы выбрали ответ: <выбранный вариант>» и предлагается исправить либо отправить ответ.
Разработчик опроса или назначенный им делегат получает отдельные ответы в сообщениях электронной почты и вручную сводит их в таблицу. Если опрос включает большое число респондентов, следует создать в Outlook правило (используя мастер правил), автоматически перенаправляющее ответы в специальную папку, как показано на Рис. A.
Рис. А Автоматическое перенаправление ответов в специальную папку.
Рис. А Автоматическое перенаправление ответов в специальную папку.
Однако возможности кнопок для голосования весьма ограничены. Формы опросов, вставленные в сообщения электронной почты, могут собрать намного больше данных, но ручное извлечение и сведение этих данных в таблицы может быть очень неудобным. К более сложной части спектра опросов, основанных на электронной почте, принадлежит использование VBScript для настройки опросов Outlook. Настраиваемые формы могут упростить сбор и анализ больших объемов более сложных данных. Чтобы получить доступ к функциям разработчика Outlook 2007, следует сперва отобразить вкладку разработчика, показанную на Рис. Б.
Рис. Б Вкладка разработчика в Outlook 2007
Рис. Б Вкладка разработчика в Outlook 2007
Создание индивидуализированных форм Outlook находится за пределами знаний обычного пользователя Outlook. Но InfoPath® 2007 предоставляет новые функции, которые упрощают реализацию индивидуализированных форм. Разработчики опросов, не имеющие специальных знаний, могут создавать формы и шаблоны InfoPath тремя способами:
  • Импорт существующих документов Microsoft Word или таблиц Excel®.
  • Загрузка предварительно разработанных шаблонов InfoPath и изменение их под конкретные нужды.
  • Разработка шаблонов с нуля путем использования функций разработки форм в InfoPath.
Во всех трех случаях шаблоны можно публиковать в Outlook и распространять по электронной почте. Располагая InfoPath 2007 и Outlook 2007, несколькими часами времени и минимальной помощью от отдела ИТ, информационный работник может создать опрос из двадцати пунктов, разослать его группе по электронной почте, получить результаты в Outlook и проанализировать данные в таблице Excel.
Единственным реальным требованием в данном случае является наличие InfoPath и Outlook на компьютерах всех участников. А поскольку InfoPath 2007 на практике расширяет функции Outlook 2007, получатели опроса могут ответить на него прямо внутри интерфейса Outlook.
Но InfoPath поддерживает гораздо больше, чем просто опросы на основе электронной почты. Имеется возможность создавать шаблоны, запрашивающие и отправляющие данные веб-службам и базам данных SQL Server®, а также можно использовать существующие документы XML и схемы XML как источники данных. Другими словами, минимальная подготовка и исчезающе малое количество добавленного кода позволяет пользователю задействовать широту и гибкость XML.
Как решение для опроса электронная почта имеет несколько заметных недостатков. Например, эти опросы не анонимны в силу доступности адресов электронной почты респондентов. Это может уменьшить откровенность и исказить результаты. Существуют также проблемы с безопасностью, такие как атаки с помощью фишинга, так что тип и глубина информации, которую можно собрать при помощи почтовых опросов, ограничены.

Создание решений для опросов, управляемых базами данных
Решения для опросов на основе электронной почты не подходят для более сложных исследований, включающих большие количества респондентов, – использования папки в Outlook® просто недостаточно для управления всеми данными и их анализа. Более основательное решение – направление ответов на опрос в базу данных. Расширенные возможности хранения, индексирования, обработки и отчетов, которые можно получить от базы данных, могут быть весьма полезны. Например, Microsoft® SQL Server® 2005 включает службы отчетов SQL Server, которые можно использовать для автоматической обработки данных отчетов.
Для создания шаблона формы InfoPath, направляющей ответы базе данных, сперва нужно создать базу данных Access® или SQL Server внутри сети. Затем можно начать процесс создания шаблона в InfoPath®, используя мастер создания шаблона формы. В результате откроется мастер подключения к данным, который проводит пользователя через процесс привязки формы к базе данных. InfoPath использует информацию в базе данных для создания запроса о источниках данных и полях данных.
Большинство работников знают достаточно, чтобы заполнить и отправить этот опрос при минимальной помощи и поддержке. Однако в данном случае (где данные передаются прямо базе данных) у респондентов должны быть установлены InfoPath и Outlook, а также они должны быть внутри корпоративного брандмауэра либо иметь доступ по VPN к корпоративной сети.
Мастер подключения к данным InfoPath взаимодействует только с Microsoft SQL Server 2000 либо более поздними версиями и базами данных Access со встроенным использованием ADOXML. Прямая отправка ответов базе данных не поддерживается для других баз данных. Прочие ограничения состоят в том, что InfoPath не допускает привязку элементов управления формата RTF к полям баз данных и не поддерживает крупные двоичные типы данных.
По мере того, как топология сети разрастается и становится более сложной, направление данных промежуточной веб-службе с последующей пересылкой базе данных дает все больше преимуществ. Отделение пользовательского доступа опроса от серверной части базы данных посредством веб-службы также способствует применению бизнес-логики на веб-сервере. А поскольку веб-служба выполняется по подключениям HTTP или HTTPS, участники могут отправлять данные через брандмауэры, как показано на Рис. В. Однако обратите внимание, что у респондентов все же должен быть установлен InfoPath 2003 или 2007.
Негативная сторона этого варианта – необходимость участия отдела ИТ в реализации. Подробное описание этого процесса выходит за рамки данной статьи, но я могу предупредить, что создание базы данных с нуля является значительным предприятием. Оно требует предварительного планирования, качественной разработки опроса, программирования веб-службы и разработки серверной части базы данных. InfoPath 2007 упрощает часть процесса, относящуюся к созданию формы, но полное решение требует твердых навыков программирования и разработки баз данных. А добавление дополнительных функция, таких как рабочий поток или многоязыковая поддержка, быстро увеличивает стоимость реализации.
Рис. C Поток данных InfoPath через веб-службу
Рис. C Поток данных InfoPath через веб-службу

Джим Брэдли (Jim Bradley) – владелец компании-публикатора технических материалов CoyoteTech LLC, специализирующейся на предоставлении документации для помощи пользователям по серверным продуктам Майкрософт. В число проектов документации входят "Microsoft Exchange Server 2007 Edge Transport and Messaging Protection" («Пограничный транспортный сервер Microsoft Exchange Server 2007 и защита системы обмена сообщениями»), "Going 64-Bit with Microsoft Exchange Server 2007" («Переход на 64-разрядные технологии в Exchange Server 2007)» и "Microsoft Exchange 2003 Technical Reference Guide" («Технический справочник по Microsoft Exchange 2003»).


 SharePoint: Стандартизация управления данными с помощью пользовательских типов содержимого
SharePoint Пав Черны (Pav Cherny)

Стандартизация управления данными с помощью пользовательских типов содержимого
Краткий обзор:
  • Управление жизненным циклом содержимого с помощью SharePoint
  • Создание областей сведений о документах
  • Правка документов Office и SharePoint посредством InfoPath
Загрузить исходный код для этой статьи: ContentTypes2008_02.exe (779KB)

The large number of documents and other content items typically found in an enterprise environment pose business and technical challenges for managing the documents, their
метаданными и их поведением. Microsoft® Office SharePoint® Server 2007 помогает совместной работе в масштабах компании, позволяя разнообразным группам внутри организации использовать общее рабочее пространство на веб-узлах, в библиотеках документов и списках.
SharePoint 2007 желает возможным стандартизацию многих аспектов содержимого и характеристик жизненного цикла посредством типов содержимого. Типы содержимого веб-узлов являются определениями метаданных, которые можно установить независимо от любого веб-узла, семейства веб-узлов, списка или библиотеки документов. Это позволяет последовательно устанавливать свойства, затрагивающие всю компанию, рабочие потоки, политики управления информацией и другие элементы, позволяя при этом каждому отделу или владельцу веб-узла настраивать типы содержимого для конкретных целей.
В этой статье я продемонстрирую, как использовать новую модель содержимого SharePoint, представленную службами Windows® SharePoint Services (WSS) 3.0 и Microsoft Office SharePoint Server (MOSS) 2007 для создания иерархий информационного содержимого предприятия, основанных на общих характеристиках. Эти иерархии содержимого делают возможным единообразное применение метаданных рабочих потоков и политик управления информацией на глобальном уровне, в то же время предоставляя гибкое удовлетворение уникальных потребностей в управлении содержимым на уровне семейств веб-узлов, веб-узлов, библиотек документов и списков.
Чтобы проиллюстрировать некоторые из низкоуровневых аспектов типов содержания SharePoint, я включил в сопровождающий статью файл ряд специальных средств, а также их исходный код на случай необходимости расширить эти средства в соответствии с теми или иными нуждами. Но помните, что эти средства не протестированы тщательно, и их не стоит использовать в производственной среде. Код можно загрузить с веб-узла журнала TechNet Magazine на technetmagazine.com/code08.aspx.

Жизненный цикл содержимого и определения типов содержимого
Материалы по SharePoint
  • Блог группы InfoPath
  • Рабочие потоки в Office SharePoint Server 2007
  • Веб-трансляция TechNet: Установка и настройка поиска в SharePoint Server 2007
  • Служба форм InfoPath

При управлении документами и прочим содержимым в организации необходимо помнить о множестве деталей. Помимо прочего, необходимо определять, какие действия следует выполнять каким сотрудникам или процессам в ходе создания, публикации, архивации и удаления содержимого. Для организации также часто необходимо разрабатывать специальные шаблоны создания содержимого, определять роли с целью назначения обязанностей и прав доступа к пользователям, обеспечивать контроль версий, отслеживать соответствие, сохранять и архивировать, определять метаданные и так далее.
Насколько бы сложным ни был жизненный цикл определенного содержимого, модель содержимого SharePoint опознает некоторые общие характеристики и типичные фазы, определяющие, как следует обрабатывать отдельные элементы содержимого. Например, можно структурировать создание содержимого через шаблоны и формы ввода, а его отображение и поиск через метаданные. Можно также использовать правку, одобрение и другие требования рабочего потока, требования архивирования, графики истечения срока годности и подходящие политики управления информацией для различения отдельных частей содержимого. Некоторое содержимое может не требовать никаких специальных шаблонов или не может быть заархивировано, но даже это является характеристиками жизненного цикла, выделяющими такие элементы.
Модель содержимого SharePoint позволяет определять индивидуальные типы содержимого и устанавливать иерархические отношения. В иерархическом отношении дочерние типы содержимого наследуют общие характеристики родительских, добавляя специальные характеристики по мере надобности.
Лучшей иллюстрацией к этому являются встроенные типы содержимого SharePoint. В состав WSS 3.0 и MOSS 2007 входит некоторое количество предварительно определенных типов содержимого для типичных элементов, которые можно сохранять в библиотеке или списке документов, включая документы и задачи. Определения этих стандартных типов содержимого можно найти на сервере SharePoint в папке %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Ctypes. Там можно найти файл манифеста, именуемый feature.xml. Взглянув на этот файл, можно понять, что SharePoint применяет стандартные типы содержимого как скрытую возможность (Hidden="TRUE"), в масштабе семейства веб-узлов (Scope="Site") и что файл манифеста элемента, содержащий собственно элементы типов содержимого – ctypeswss.xml (<ElementManifest Location="ctypeswss.xml" />).
Тем, кто хочет поближе познакомиться с функциями SharePoint, я рекомендуют прочесть выпуск рубрики Теда Паттинсона (Ted Pattison) «Пространство Office» в журнале MSDN® Magazine, озаглавленный «Функции для SharePoint» и доступный на msdnmagazine.com/issues/07/05/OfficeSpace.
Давайте теперь откроем файл ctypeswss.xml в блокноте, чтобы изучить стандартные типы содержимого вне зависимости от их видимости в интерфейсе пользователя SharePoint. Изменять ctypeswss.xml не следует. Если есть мысли о правке ctypeswss.xml с целью добавления новых полей к стандартным типам содержимого или превращения скрытых типов содержимого в видимые, чтобы пользователи SharePoint могли использовать их для вывода новых типов содержимого, обратите внимание, что обычно в этом нет необходимости. Вдобавок, это ведет к неподдерживаемым настройкам, а при последующей установке пакетов обновления эти изменения могут быть перезаписаны, и решения для управления содержимым будут разрушены.
Гораздо лучшим подходом является копирование всего, что нужно, в новый файл манифеста элемента, внесение изменений по мере необходимости и развертывание индивидуализированных типов содержимого как новой функции в масштабе семейства веб-узлов, чтобы они были доступны всем узлам в семействе.
Определение типа содержимого System («Системный») на основе языка CAML, указанное в ctypeswss.xml, раскрывается здесь:
<ContentType ID="0x"
    Name=$Resources:System
    Group="Hidden"
    Sealed="True"
    Version="0">
   <FieldRefs>
      <FieldRef ID="{c042a256-787d-4a6f-8a8a-cf6ab767f12d}" Name="ContentType"/>
   </FieldRefs>
</ContentType>
Атрибуты Group («Групповой») и Sealed («Заблокированный») показывают, что тип содержимого System скрыт и заблокирован, так что нельзя изменить в интерфейсе пользователя SharePoint. Тип содержимого System обладает только одним элементом FieldRef, ссылающимся на встроенный столбец узла, именуемый ContentType. Это высший уровень абстракции. Все прочие типы содержимого SharePoint наследуют это свойство от типа содержимого System. Таким образом, SharePoint обеспечивает, чтобы все элементы содержимого, хранящиеся в любой из библиотек или списков документов, использовали это свойство совместно.
На рис. 1 показан веб-компонент ContentTypeHierarchy, входящий в материал, сопровождающий данную статью; этот веб-компонент дает более интуитивную иллюстрацию иерархий. System является корнем всех прочих типов содержимого, за которым следует Item («Элемент») и так далее. В частности, тип содержимого Item устанавливает следующий уровень детализации. Если проверить ctypeswss.xml, то можно убедиться, что Item определяет единственное поле метаданных, ссылающееся на столбец веб-узла под названием Title («Заголовок»). Таким образом, у всех встроенных типов содержимого на нижних уровнях имеется свойство Title.
Рис. 1 Встроенная иерархия типов содержимого WSS 3.0
Рис. 1 Встроенная иерархия типов содержимого WSS 3.0
Удалить наследуемое поле также возможно, как показывает определение типа содержимого Document в ctypeswss.xml. Тип содержимого Document включает несколько соответствующих элементов RemoveFieldRef, однако поле Title может потребоваться оставить на месте в собственноручно созданных типах содержимого, поскольку столбец Title предоставляет доступ к раскрывающемуся меню окна правки элементов управления (Edit Control Box – ECB) в библиотеке документов SharePoint и отображениях списков.
Хорошим примером, показывающим, как переименовывать наследуемые поля, является тип содержимого Far East Contact в ctypeswss.xml. Проведите поиск 0x0116 (соответствующий ему идентификатор типа содержимого) и затем проверьте элемент FieldRef с атрибутом Name="Title", чтобы увидеть, как можно использовать атрибут DisplayName для переименования поля в интерфейсе пользователя. В данном конкретном случае, атрибут DisplayName изменяет имя поля Title в интерфейсе пользователя локализованным значением данных, на которое ссылается "$Resources:core,Last_Name;".
Если приглядеться к Рис. 1, можно увидеть, что атрибут идентификатора элемента ContentType уникальным образом идентифицирует тип содержимого и устанавливает иерархическое отношение. Все идентификаторы начинаются с идентификатора родительского типа содержимого, к которому добавлены дополнительные шестнадцатеричные значения. К стандартным типам содержимого обычно добавляется два дополнительных шестнадцатеричных значения для создания нового уникального идентификатора для дочернего типа содержимого. Другой прием – добавить "00" и шестнадцатеричный идентификатор GUID. В частности, именно этим способом типы содержимого Office Data Connection File и Universal Data Connection File выводятся из типа содержимого Document.
Пользователю важно помнить, что атрибут ID («Идентификатор») элемента ContentType не может превышать 1024. Это может стать проблемой в крупной иерархии, если все типы содержимого используют шестнадцатеричный прием адресации идентификаторов GUID. Однако начинать с более короткого приема – не лучший вариант, поскольку такие идентификаторы могут оказаться неуникальными.
Чтобы гарантировать уникальность, используйте прием идентификаторов GUID для основания глобального пространства имен своих корпоративных типов содержимого и переключитесь на более короткий прием внутри этого пространства. Подробные сведения об атрибуте ID и других элементах определений типов содержимого приведены в разделе "Content Type Definition Schema" («Схема определений типов содержимого») в SDK для WSS 3.0.

Зависимости типа содержимого
Теперь стоит обратиться к вопросу использования типов содержимого SharePoint для структуризации управления типами содержимого. Необходимо подумать о нескольких зависимостях, таких как взаимозависимости между библиотеками и списками документов, типами содержимого, столбцами веб-узла и типами полей. Библиотеки и списки ссылаются на типы содержимого, которые ссылаются на столбцы веб-узла, которые, в свою очередь, ссылаются на типы полей (такие как стандартные типы полей WSS – текст, заметка, выбор, номер, валюта и так далее), которые, в свою очередь, пребывают в сборках Microsoft .NET Framework, таких как центральная сборка WSS Microsoft.SharePoint.dll.
Для примера давайте вернемся к типу содержимого System, как он проиллюстрирован выше в определении CAML записи в файле манифеста о типе содержимого System. Как можно было увидеть, этот тип содержимого содержит элемент FieldRef, ссылающийся на встроенный столбец узла, именуемый ContentType. Обратите внимание, что определение типа содержимого не определяет собственно столбец веб-узла ContentType. ContentType – поле типа Text, определенное в манифесте элементов fieldswss.xml, находящемся в папке %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Fields. Тип поля Text, в свою очередь, определен в fldtypes.xml, а этот файл можно найти в %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\XML. Важный вывод, который следует сделать из этого дерева зависимостей, – необходимость обеспечить доступность всех ресурсов на серверах SharePoint.
Типы содержимого, которые надо использовать, должны быть созданы на уровне библиотек и списков документов не ниже в иерархии, чем уровень веб-узла. Аналогично, поля метаданных типов содержимого должны ссылаться на существующие столбцы веб-узла. Можно добавлять к своим типам содержимого стандартные или индивидуализированные столбцы веб-узла, основанные на стандартных или индивидуализированных типах полей, но необходимо убедиться, что эти столбцы существуют на локальном веб-узле. Вдобавок, если необходимо использовать индивидуализированные типы полей, необходимо обеспечить развертывание базовых сборок .NET на своих серверах SharePoint.
Аналогичные зависимости существуют для типов содержимого, ссылающихся на шаблоны документов, приемники нестандартных событий, рабочие процессы и иные компоненты. Например, определение типа содержимого может содержать элемент DocumentTemplate, указывающий на шаблон документов, связанный с этим типом содержимого. Определение типа содержимого может также содержать элемент XmlDocuments с одним или несколькими дочерними элементами XmlDocument, определяющими дополнительные характеристики типа содержимого, такие как определения пространств имен, определения областей сведений о документах или любую нестандартную информацию.

Создание глобальных типов содержимого
Пользователи с полномочиями на разработку могут создавать новые типы содержимого и столбцы веб-узлов прямо в интерфейсе пользователя SharePoint, но типы содержимого после этого будут доступны только на локальном веб-узле и веб-узлах ниже его в иерархии. Нестандартные столбцы веб-узла доступны только на локальном веб-узле. Этого недостаточно для создания глобальных типов содержимого. Необходимо обеспечить доступность глобальных типов содержимого на всех семействах веб-узлов в среде. Тут-то функции SharePoint и могут пригодиться. Установка и активация функций SharePoint на нескольких семействах веб-узлов с целью последовательного применения соответствующих столбцов веб-узлов и определений типа содержимого довольно проста.
В составе сопровождающего материала для этой статьи есть пример функции, именуемой AdventureWorks, которая демонстрирует установку глобального типа содержимого. Эта функция определяет общий тип содержимого, именуемый Customer Documentation («Клиентская документация»), который можно использовать для создания любых типов клиентских материалов, таких как предложения и письма с предложениями о продажах. Разумно предположить, что все эти типы документов должны быть связаны с информацией о клиентах, такой как имя компании, контактные сведения и адрес. Я специально создал новое поле, именуемое Customer Name («Имя клиента») для своего типа содержимого и добавил некоторые встроенные поля, такие как Department («Отдел») и Primary Phone («Основной телефон»). Тип содержимого и поля можно изменить, изменяя файл ContentTypes.xml, а ссылки полей – изменяя файл SiteColumns.xml в сопровождающем материале.
Если развернуть эту функцию согласно указаниям файла readme.htm, ее можно последовательно активировать на нескольких семействах веб-узлов. Тогда тип содержимого Customer Documentation будет доступен глобально. Это позволит различным отделам создавать специальную клиентскую документацию посредством производных типов содержимого, связанных с целевыми шаблонами документов. В составе сопровождающего материала имеются примеры шаблонов документов, которые можно использовать при продажах и консультациях. На Рис. 2 показаны получающиеся типы содержимого.
Рис. 2 Родительские и дочерние типы содержимого для клиентской документации
Рис. 2 Родительские и дочерние типы содержимого для клиентской документации
При создании функций для собственноручно созданных столбцов веб-узлов и типов содержимого вWSS 3.0 и MOSS 2007 можно воспользоваться одним из нескольких вариантов. Можно изучить комплект SDK для WSS 3.0 и писать файлы XML с нуля. Можно также выбрать использование SharePoint Designer для экспорта списка в персональный веб-пакет, переименовать получившийся файл .fwp в файл CAB, извлечь файл manifest.xml из файла CAB и найти определения ContentType в файле manifest.xml. К несчастью, оба подхода неудобны и подвержены ошибкам.
Напротив, создавать индивидуализированные столбцы и типы содержимого в интерфейсе пользователя SharePoint примечательно просто, однако интерфейс не предоставляет возможностей по правке файлов XML функции. Функции являются эффективным путем подготовки ресурсов SharePoint, но после предоставления ресурсы существуют только в базе данных содержимого . Может быть, в будущую версию WSS будет входить возможность экспортировать столбцы узлов и типы содержимого в файлы XML через интерфейс SharePoint, подобно экспорту веб-компонентов. Пока же приходится работать с тем, что есть.
В сопровождающем материале имеется веб-компонент, именуемый ContentTypeSchema, который может стать отправной точкой. В нем используется объектная модель SharePoint для извлечения свойства SchemaXML из выбранного типа содержимого. Через преобразования на основе XSLT веб-компонент извлекает определения Field или определения ContentType в зависимости от варианта, выбранного в интерфейсе пользователя перед нажатием на кнопку Display («Отобразить»).
На рисунке 3 показана работа этого веб-компонента. Он отображает тип содержимого Active Directory® Documentation, который я основал на типе содержимого Customer Documentation. Тип содержимого Active Directory Documentation связан с нестандартным шаблоном Microsoft Word (Active Directory Template.dot). Отметьте, что у этого типа содержимого нет дополнительных полей. Все поля наследуются от родительского типа содержимого.
Если есть планы использовать веб-компонент ContentTypeSchema в собственной среде, имейте в виду, что этот веб-компонент не протестирована тщательно. В моем веб-компоненте используется сравнительно сложное преобразование XSL для создания разности между свойством SchemaXML выбранного в настоящий момент типа содержимого и его родительским типом содержимого. Но XSLT 1.0 все же не создан для преобразований сложных документов XML. В нем нет встроенной функции сравнения узлов XML. Кроме того, пространства имен XML, также как и разделы CDATA, являются препятствиями, которые XSLT 1.0 не может эффективно преодолеть.
SharePoint сохраняет определение столбцов веб-узлов и типов содержимого веб-узлов, созданное путем использования интерфейса пользователя или объектной модели SharePoint, в базе данных содержимого в таблице, именуемой ContentTypes. На Рис. 3 можно посмотреть на идентификатор моего типа содержимого. Соответственно, нижеследующий оператор T-SQL предоставит точные результаты: SELECT Definition FROM ContentTypes WHERE ContentTypeId = <content type ID>.
Рис. 3 Определение типа содержимого, созданного пользователем в ContentTypeSchema Веб-часть
Рис. 3 Определение типа содержимого, созданного пользователем в ContentTypeSchema Веб-часть
Какой подход ни выбери, создание функций для типов содержимого в масштабе компании после получения столбца веб-узла и определений типов содержимого будет весьма простым. Я рекомендую использовать единую функцию для всех глобальных столбцов веб-узлов и типов содержимого отдела или компании. Таким образом, будет понятно, куда добавлять новые столбцы веб-узлов и определения типов содержимого.

Поиск созданных пользователями метаданных в масштабах предприятия
Непосредственным преимуществом иерархий типа содержимого является наследование полей метаданных родительского типа всеми дочерними типами. Поскольку у всех типов содержимого есть общие поля метаданных, пользователям довольно просто создавать собственные представления и фильтры в библиотеках документов.
Пример функции AdventureWorks показывает это весьма интуитивным способом. Вне зависимости от содержимого, создаваемого консультантом или продавцом, сохранение получающегося документа Word 2007 в библиотеке документов требует указания Customer Name, поскольку родительский тип содержимого Customer Documentation устанавливает необходимость этого поля метаданных. Группируя или фильтруя элементы в представлении библиотеки документов в соответствии с Customer Name, консультанты и продавцы могут быстро и с удобством найти всю существующую документацию по клиенту, как показано на Рис. 4.
Рис. 4 Группировка различных документов в библиотеке на основе общих метаданных
Рис. 4 Группировка различных документов в библиотеке на основе общих метаданных
Общие метаданные также делают несложным поиск содержимого по нескольким библиотекам документов и веб-узлам, путем использования поисковых возможностей WSS 3.0 и MOSS 2007. WSS поддерживает поиск по библиотекам, спискам и веб-узлам внутри одного семейства веб-узлов. MOSS 2007 выходит за пределы этих базовых возможностей, позволяя реализовать центр поиска в масштабах компании и управлять пользовательскими метаданными в пользовательском интерфейсе центральной администрации SharePoint 3.0. По этой причине, нижеследующее объяснение фокусируется на MOSS 2007.
При настройке поставщика общих служб (Shared Service Provider – SSP) в MOSS 2007 и обходе веб-узлов SharePoint MOSS 2007 может автоматически обнаруживать нестандартные поля метаданных, использованные в источниках содержимого. Соответственно, эти поля можно найти в списке обойденных свойств.
Поля метаданных, определенные в функциях SharePoint, обычно подпадают под категорию SharePoint. Чтобы найти ее положение в центральной администрации SharePoint Central Administration, в меню «Быстрый запуск», под пунктом «Администрирование общих служб», щелкните ссылку на SSP, затем параметры поиска, затем сопоставление свойств метаданных, затем обойденные свойства в меню «Быстрый запуск», а затем откройте категорию SharePoint.
Вот пример всего этого в действии. Поле метаданных, именуемое Customer Name, превращается в обойденное свойство, именуемое ows_Customer_x0020_Name. SharePoint снабжает обойденные свойства префиксами "ows_" и "_x0020_" в закодированной версии единого пространства. В случае отображения подробностей об обойденном свойстве можно обнаружить, что оно включено в индекс поиска по умолчанию, так что пользователи могут использовать его значения для выполнения поисков содержимого. Однако для повышения точности поиска может возникнуть желание не сопоставлять обойденное свойство с управляемым свойством, чтобы пользователи однозначно могли искать содержимое по имени клиента.
При сопоставлении обойденных свойств с управляемыми есть две возможности. Можно автоматически создавать по управляемому свойству на каждое обойденное свойство или их можно сопоставлять вручную. Первый вариант доступен при отображении параметров желаемого обойденного свойства (при отображении таких свойств в категории, вроде категории SharePoint, выберите пункт «Изменить категорию» в меню быстрого запуска). В области «Параметры свойств, используемых при обходе содержимого» необходимо установить флажок «Автоматически создавать новое управляемое свойство для каждого обойденного свойства, обнаруженного в этой категории». Однако SharePoint снабжает автоматически созданные управляемые свойства префиксами "ows" и избегает пробелов с помощью "x0020". Управляемое свойство для обойденного свойства ows_Customer_x0020_Name будет выглядеть как owsCustomerx0020Name. Однако это не очень удобное для пользователя имя свойства.
Возможно, лучшей стратегией будет сопоставление обойденных свойств с управляемыми свойствами вручную после развертывания типов содержимого масштаба предприятия. Обойденное свойство можно сопоставить с одним или несколькими управляемыми. Для создания нового управляемого свойства в центральной администрации SharePoint Central Administration, в меню «Быстрый запуск», под пунктом «Администрирование общих служб», щелкните ссылку на ваш SSP, затем Параметры поиска, затем Сопоставления свойств метаданных, затем выберите «Новое управляемое свойство» для указания необходимой информации и привязки его к нужному обойденному свойству.
Затем пользователи могут обнаруживать нужные элементы содержимого используя управляемые свойства либо в синтаксисе property:, либо в расширенном поиске. Например, если сопоставить обойденное свойство ows_Customer_x0020_Name с управляемым свойством, именуемым Customer, пользователи смогут искать все документы клиента просто указывая Customer: <Имя клиента> в стандартном окне поиска, например Customer: Contoso.
Хорошей мыслью также является включение управляемых свойств для наиболее важных полей метаданных ваших типов содержимого в список свойств на странице расширенного поиска. Чтобы выполнить это, отобразите страницу расширенного поиска, выберите действия на узле и затем команду правки страницы. Теперь можно нажать кнопку правки в окне расширенного поиска, чтобы выбрать вариант изменения общего веб-компонента. При расширении категории Properties и помещении курсора в соответствующее текстовое поле можно нажать на кнопку для правки документа XML Properties. Необходимо добавить определение свойств к элементу <PropertyDefs>, скажем <PropertyDef Name="Customer" DataType="text" DisplayName="Customer Name"/>, а также необходимо добавить ссылку на определение свойств под элементом ResultType (например, элементом <ResultType DisplayName="All Results" Name="default">), скажем <PropertyRef Name="Customer" />. На Рис 5a показан получившийся интерфейс расширенного поиска. На рис. 5б показаны результаты поиска.
Рис. 5a Поиск документации по ИТ-инфраструктуре на основе имени клиента
Рис. 5a Поиск документации по ИТ-инфраструктуре на основе имени клиента
Рис. 5б Результаты поиска имени клиента
Рис. 5б Результаты поиска имени клиента

Обеспечение согласованности информации
К этому моменту я успешно стандартизировал наиболее важные поля метаданных и типы содержимого, а также расширил возможности поиска по семействам веб-узлов в моей компании, основываясь на MOSS 2007. Теперь настало время обеспечить ввод пользователями верной информации в поля метаданных.
Сделать это можно двумя способами. Во-первых, можно заменить стандартную область сведений о документах в шаблонах документов на специально созданную форму InfoPath®, дающую пользователям заранее определенный набор вариантов ввода, подобный присутствующему в окне списка. Во-вторых, можно привязать получатель события к типу содержимого и затем проверять верность метаданных и прочей информации каждый раз, когда пользователи создают, изменяют или удаляют соответствующие элементы содержимого.
Эти варианты дополняют друг друга. Форма InfoPath, в первую очередь, предоставляет удобный способ правки типа содержимого SharePoint, тогда как получатель событий может обеспечить верность метаданных, даже если пользователи правят свойства типа содержимого вне формы InfoPath. Обработчики событий можно привязывать к определенному типу содержимого, что позволяет указывать события и их ответы на все документы, связанные с определенным типом содержимого во всех семействах веб-узлов вне зависимости от библиотеки документов. Дополнительные сведения о разработке и развертывании обработчиков событий можно найти на msdn2.microsoft.com/ms453149.
Вероятно, простейшим методом связывания типа содержимого с нестандартной областью сведений о документе является отображение параметров области сведений о документе типа содержимого в интерфейсе пользователя SharePoint на компьютере, где установлен InfoPath 2007. После этого можно щелкнуть ссылку "Создать новый пользовательский шаблон" в шаблоне области сведений о документе, чтобы запустить InfoPath 2007 в режиме создания. Однако, если в состав содержимого веб-узла входят столбцы без явного атрибута SourceID, можно столкнуться с ситуацией, при которой InfoPath не в состоянии создать верную схему XSD для формы области сведений о документе. Например, в тип содержимого Customer Documentation, представленный ранее, входят несколько специфических для каждого контакта столбцов, таких как Department, Office и адрес электронной почты, которые могут вызвать эту проблему, как показано на рис. 6.
Рис. 6 Несовместимости схемы XSD в InfoPath 2007
Рис. 6 Несовместимости схемы XSD в InfoPath 2007
На этом этапе при наличии данной проблемы есть два варианта. Можно либо удалить ссылки на столбцы веб-узла без явного атрибута SourceID из определения типа содержимого, либо заменить встроенные столбцы веб-узла, вызвавшие проблему, на измененные столбцы веб-узла, совместимые с InfoPath 2007. Помните, что невозможно изменить ссылки на поля в типе содержимого, основанном на CAML, после того, как он был предоставлен в базу данных содержимого, особенно если уже были созданы дочерние типы содержимого. Файл основанного на CAML определения типа содержимого больше нельзя обновить, а также нельзя свалить изменения на дочерние типы содержимого, посколькуWindows SharePoint Services не отслеживают изменения в определении родительского типа содержимого.
Чтобы свалить изменения, необходимо изменить родительский тип через интерфейс пользователя или объектную модель SharePoint, либо надо определить новый тип, порожденный от существующего. Последний прием позволяет удалять критические поля и добавлять столбцы. Пользователи затем могут выводить типы содержимого из нового типа. Чтобы пользователи не могли выбрать неверный тип, добавьте предыдущий тип содержимого к группе типов содержимого _Hidden.
Как я уже сказал, типы содержимого на основе CAML нельзя обновлять после их развертывания и активации. Поэтому очень важно тестировать глобальные типы содержимого перед развертыванием. Дополнительные сведения см. в статье MSDN "Updating Content Types" («Обновление типов содержимого») на msdn2.microsoft.com/aa543504.
После того, как тип содержимого с верными ссылками на поля создан, можно создать индивидуализированную область информации о документе в InfoPath 2007. Лучшая стратегия состоит в том, чтобы позволить владельцам веб-узлов создавать такие области для их дочерних типов содержимого. InfoPath 2007 предоставляет возможность публикации таких областей прямо в выбранный тип содержимого, что облегчает вариант развертывания. Но также возможно публиковать формы InfoPath из центральной точки, такой как библиотека документов, включая ссылку на область сведений о документе в тип содержимого. Такой вариант является лучшим, если планируется предоставить индивидуализированную область информации о документе вместе со своими типами содержимого CAML. На Рис. 7 показана архитектура реализации.
Рис. 7 Применение файла XSN из центрального местоположении в MOSS 2007
Рис. 7 Применение файла XSN из центрального местоположении в MOSS 2007
В состав файла для загрузки, сопровождающего эту статью, входит функция AdventureWorks_Update, расширяющая предыдущую функцию AdventureWorks путем добавления дополнительных столбцов веб-узлов, работающих с InfoPath 2007. Функция AdventureWorks_Update помечает оригинальный тип содержимого Customer Documentation как скрытый и производит новый тип содержимого Customer Docs, где унаследованные встроенные поля заменены специально созданной областью информации о документе.
Новый тип содержимого Customer Docs включает элемент XmlDocument, предоставляющий информацию о панели сведений о документе. Точнее говоря, элемент xsnLocation указывает на форму InfoPath http://companyresources/DIPs/customerDIP.xsn, которая применяет эту область. Подробные указания по применению функции AdventureWorks_Update приведены. в файле readme.htm папки AdventureWorks_Update.

Заключение
Типы содержимого SharePoint 2007 можно использовать для создания политик метаданных и их согласованного использования в масштабах компании. Иерархия типов содержимого позволяет стандартизировать характеристики, относящиеся к среде в целом, и применять из единообразно ко всем узлам путем наследования.
Среди прочего возможно расширить встроенные возможности поиска MOSS 2007, чтобы пользователи могли быстрее и с большим удобством обнаруживать конкретное содержимое. Также возможно применять информационную согласованность в области метаданных и создавать централизованные политики управления информацией. Лучшей стратегией является стандартизация глобальных типов содержимого на наиболее абстрактных характеристиках метаданных, чтобы свести к минимуму потребность в последующих изменениях. Основанные на тщательно разработанной модели содержимого типы данных SharePoint могут предоставлять новые возможности стандартизации жизненного цикла содержимого в компаниях и организациях.

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


 Office Communications Server: Каким образом присутствие увеличивает возможности OCS 2007
Office Communications Server Раджеш Раманатан (Rajesh Ramanathan)

Каким образом присутствие увеличивает возможности OCS 2007
Краткий обзор:
  • Авторизация и службы каталога
  • Режимы обмена сообщениями в OCS 2007
  • Использование присутствия для маршрутизации при связи

Система Microsoft Office Communication Server (OCS) 2007 основывается на сильных сторонах версии LCS (Live Communication Server) 2005. Сервер LCS 2005 предоставил систему обмена мгновенными сообщениями (IM) корпоративного уровня
и присутствие. В нем появилась также интеграция телефонии с существующими установками УАТС посредством RCC (Remote Call Control — удаленное управление звонками).
В системе OCS 2007 дополнительно усовершенствованы возможности присутствия и обмена мгновенными сообщениями, имевшиеся в LCS 2005, и добавлены расширенные возможности использования линий связи и телефонов, обеспечиваемые клиентом Office Communicator 2007, что делает ее завершенным «программным телефоном». В Майкрософт разработаны также серверы конференций и пограничные серверы для линий связи, позволяющие обеспечивать все потребности организации, касающиеся обмена информацией, параллельно с существующими УАТС или независимо, в виде завершенного самостоятельного решения.
Клиент Office Communicator 2007 обеспечивает возможности «программного телефона», позволяющие пользователям выбирать предпочитаемые устройства USB, и предоставляет конечному пользователю рабочую среду с широкими возможностями для обнаружения и удобного использования таких распространенных средств управления звонками, как удержание и перевод вызова. Пользователям больше не требуется запоминать номера телефонов или пользоваться клавиатурой для набора номера. Вместо этого, чтобы сделать вызов из приложения рабочей среды, достаточно нажать кнопку, а для организации конференции — перетащить в область беседы списки лиц или списки рассылки.
Если требуются реальные стационарные телефоны, версия Office Communicator Phone Edition (или телефон Tanjay) работает в точности как вторая оконечная точка для пользователя. В ней используются контекстные меню на сенсорных экранах и среда присутствия, знакомая по клиенту Office Communicator.
Эти возможности системы OCS строятся вокруг концепции присутствия пользователя. Для установления связи между лицами в любой момент времени с помощью оптимальной среды передачи данных в OCS 2007 используется доступность пользователя, оконечные точки связи и взаимоотношения пользователей. Поскольку система OCS связывает воедино пути передачи голосовых данных, данных электронной почты, мгновенных сообщений и других данных, с ее помощью можно маршрутизировать сообщения максимально эффективным способом.
В этой статье дается обзор решения OCS 2007 и обсуждаются способы объединения составляющих его компонентов. Рассматривается также использование присутствия как важного компонента в рецепте единой среды связи и способ его использования для максимально эффективной маршрутизации голосовых вызовов.

Авторизация и службы каталога
В голосовой системе предприятия должна быть предусмотрена возможность проверки учетных данных лиц, имеющих разрешение делать вызовы. Также должна быть обеспечена возможность применения ограничений или политик на основе порядка поступления вызовов. Для инициирования вызовов в системе VoIP (голос по IP) клиенты должны выполнять проверку подлинности для доступа к серверу. Подобно тому, как в традиционной системе УАТС для принудительной идентификации достаточно доступа к физической линии.
В системе OCS 2007, показанной на Рис. 1, для проверки подлинности и хранения политик доступа используется Active Directory®. OCS выполняет авторизацию вызовов посредством проверки их на соответствие политикам пользователя из Active Directory. Поскольку OCS использует те же сведения Active Directory, которые используется другими приложениями Майкрософт, например Exchange Server или Microsoft® Outlook®, для существующих в Active Directory пользователей можно без труда добавить голосовые возможности, расширив свойства пользователя и политики (посредством расширений схемы Active Directory) и обеспечив единый каталог, который можно использовать для таких приложений, работающих в режиме реального времени, как голосовые или мгновенные сообщения.
Рис. 1 Компоненты единой среды связи системы OCS
Рис. 1 Компоненты единой среды связи системы OCS
В Active Directory наиболее важным свойством, относящимся к единой среде связи, является адрес SIP (протокола начала сеанса), известный также как URI-адрес SIP, который по своей природе очень похож на адрес электронной почты пользователя. Например, пользователю из Active Directory, имеющему адрес электронной почты someone@contoso.com, в качестве адреса SIP был бы присвоен адрес someone@contoso.com. Поскольку адрес SIP связан с объектом пользователя, можно предоставить единственный идентификатор, в котором те же учетные данные, которые пользователь использует для входа в систему настольного компьютера или сервера Exchange, можно использовать для регистрации на сервере OCS.
Еще одним важным свойством является номер телефона пользователя. Чтобы иметь возможность маршрутизировать вызов, сервер OCS по внутренней сети перенаправляет вызовы, направленные на телефонные номера, на URI-адрес SIP соответствующего пользователя.
OCS 2007 предоставляет интерфейс ABS (Address Book Service — служба адресной книги), доступный в рамках организации для поиска в каталоге. Являясь автономной версией адресной книги, он позволяет клиентским конечным точкам избежать обращения к Active Directory всякий раз, когда выполняется операция поиска на стороне клиента.
В дополнение к ABS система OCS 2007 увеличивает полезность списков рассылки, предоставляя службу DLX (развертывание списка рассылки), позволяющую пользователям просматривать в Office Communicator тот же список рассылки, который доступен в Outlook, а также развертывать список рассылки в Communicator. Пользователи имеют возможность настраивать конференции с членами этих списков рассылки непосредственно из Office Communicator или запускать групповые переговоры с помощью мгновенных сообщений.

Службы голосовой связи и обмена сообщениями
Дополнительные материалы по OCS
Дополнительные сведения приведены в следующих источниках.
  • Мероприятия и веб-трансляции, посвященные единой системе связи
  • Технический центр Office Communications Server
  • Виртуальная лаборатория технического центра: активирование пользователей и установка Office Communicator 2007

Решение для корпоративной голосовой связи должно предоставлять возможности управления звонками, знакомые большинству пользователей. Помня об этом, создатели системы OCS 2007 предоставили популярные функции, такие как удержание звонка, перевод звонка и перевод звонка с созданием консультативного звонка, перенаправление и одновременный звуковой сигнал, а кроме этого — режимы без использования голосовой связи, например обмен мгновенными сообщениями.
OCS 2007 является центром маршрутизации голосовых вызовов и предоставляет функции маршрутизации как исходящих, так и входящих вызовов. В маршрутизацию исходящих вызовов входит преобразование номеров, применение касающихся пользователя политик (например, ограничение на международные вызовы) и направление вызова к соответствующим конечным точкам или вывод их в коммутируемую телефонную сеть общего пользования (КТСОП). Функции маршрутизации входящих вызовов обеспечивают выбранный пользователем вариант перенаправления вызовов и соответствие параметрам, указывающим время суток, или параметрам присутствия, и маршрутизируют вызовы надлежащим образом.
OCS не выполняет функцию завершения входящих вызовов. Выражаясь в терминах SIP, система выступает в роли регистратора SIP и прокси SIP. Передача сигналов в режиме точка-точка и среда передачи полностью обеспечиваются конечными точками клиента в системе. Конечные точки в системе, например Office Communicator 2007, предоставляют широкополосный аудиокодек (называемый RTAudio), обладающий свойствами адаптивности и отказоустойчивости в сетевой среде.
С помощью ролей сервера конференций OCS 2007 обеспечивает локальные веб-конференции для обмена всеми видами информации: аудио/видео, мгновенными сообщениями и данными. Серверы конференций, использующие OCS, дают возможность клиентским конечным точкам обеспечивать беспрепятственный переход от связи между равноправными узлами к мультимодальной связи нескольких участников с такими возможностями, как отключение звука, вывод участника и блокировка. Можно охватить до нескольких сотен участников запланированных конференций и до сотни в случае равноправных обсуждений. Можно осуществлять планирование конференций с помощью надстроек Outlook или выполнять подключение к конференции во время вызова. Решение, обеспечивающее конференции, предоставляет также такие средства, как совместное использование файлов, доска для рисунков и запись.
Безусловно, необходимо иметь возможность обеспечивать связь с внешними сетями КТСОП и телефонными номерами и федеративными предприятиями или существующими в рамках организации установками УАТС. OCS 2007 допускает интеграцию с предлагаемыми различными поставщиками шлюзами между SIP и КТСОП, обеспечивающими подключение к КТСОП или существующей УАТС. Сервер Mediation можно настроить для преобразования сигналов и кодека. Серверы Mediation являются дополнительными и настраиваются для шлюзов, не поддерживающих кодеки Майкрософт.
Единая система обмена сообщениями Exchange Server 2007 является решением голосовой почты для OCS 2007. Единая система обмена сообщениями Exchange обеспечивает ответ на вызов для входящих голосовых вызовов и вызовов факсимильной связи и помещает полученные сообщения в почтовый ящик Exchange пользователя. Кроме этого, единая система обмена сообщениями предоставляет корпоративного автосекретаря для внешних абонентов, разыскивающих конкретное лицо или подразделение.
В качестве альтернативы использованию голосовой связи OCS предоставляет обмен мгновенными сообщениями в режиме реального времени, а также дает пользователям возможность вступать в мультимодальные беседы с одновременным использованием голоса, видео и обмен мгновенными сообщениями. Более того, Office Communicator 2007 позволяет использовать в обмене мгновенными сообщениями формат RTF и средства форматирования. Кроме этого, к сеансу обмена мгновенными сообщениями в любой момент могут быть добавлены аудио и видео, плавно расширяющие обмен мгновенными сообщениями до аудиобеседы.
К дополнительным компонентам относятся ведение бухгалтерского учета, журналов и средства устранения неполадок. Возможность ведения бухгалтерского учета предоставляется посредством функций сервера OCS 2007, осуществляющих запись данных вызова. Для каждого вызова, сделанного в рамках системы, создается запись о времени поступления вызова, пункте ответа на вызов и других различных параметрах, например о том, осуществлялся ли перевод вызова. Кроме этого, с целью обеспечения нормативных требований OCS предоставляет серверы для архивирования, на которых регистрируются переговоры с помощью обмена мгновенными сообщениями. Сервер текущего контроля качества рабочей среды (QoE) хранит сведения о качестве сделанных вызовов и может использоваться для устранения проблем с качеством голосовой связи в сети.

Регистрация и инициализация
На первом этапе инициализации клиента каждая клиентская конечная точка в системе OCS должна зарегистрироваться (войти) в OCS. Регистрация состоит из процесса подключения к серверу OCS, и выполнение этого этапа информирует о существовании клиента. В процесс регистрации входит проверка сервером подлинности учетных данных пользователя; создается также сопоставление безопасности между экземпляром клиента и сервером. Сопоставление безопасности используется для последующих вызовов, выполняемых клиентом посредством сервера, и периодически обновляется клиентом посредством повторной регистрации. Длительность повторной регистрации зависит от топологии сервера. Например, клиентские конечные точки, зарегистрированные извне предприятия посредством пограничного сервера Microsoft AccessTM, обновляют свою регистрацию чаще, чем клиенты со внутренней стороны корпоративного брандмауэра.
Обратите внимание, что регистрация требуется только тем клиентским конечным точкам, которым требуется постоянный, прошедший проверку подлинности канал связи с OCS для приема входящих уведомлений, таких как уведомления о голосовых вызовах или изменениях присутствия. Live Meeting представляет собой клиентскую конечную точку, которой требуется подключение к OCS только для присоединения к собранию и, следовательно, ей не требуется регистрация в системе OCS.
Чтобы лучше понять детали взаимодействия клиентов в рамках OCS 2007, рассмотрим подробнее Office Communicator в качестве клиентской конечной точки. (Большинство потоков передачи сигналов, связанных с Office Communicator, идентичны потокам, используемым для других клиентских конечных точек, таких как Office Communicator Phone Edition или Office Communicator Mobile.) Как только регистрация завершается, Office Communicator извлекает данные о настройки, являющиеся критически важными для работы клиентской оконечной точки. К ним относятся следующие данные.
  • Идентифицирующие точку данные, такие как карта контакта, адрес электронной почты, URI-адреса SIP, имя дисплея и номер телефона.
  • Функции, активированные на клиенте, и политики.
  • Адреса серверов, например, адрес SIP пограничного сервера AV и адрес сервера голосовой почты.
  • Хранящийся на сервере список контактов.
  • Правила форматирования чисел для клиентского местоположения.
Этот механизм извлечения всех данных для подготовки с помощью существующего канала SIP связи с сервером называется подготовкой входящей полосы (inband provisioning). Он позволяет клиентским конечным точкам выполнять автоматическую настройку и обновлять свою настройку в любой момент при регистрации клиента, а также извне сети или брандмауэра.
В последовательность регистрации входят этапы регистрации на сервере для инициализации, получения и настройки присутствия и, наконец, входа в состояние готовности (см. рис. 2). Отметим, что система OCS позволяет регистрировать несколько клиентских конечных точек для одного пользователя или URI-адреса SIP. Во время регистрации сервер возвращает уникальный адрес SIP клиента, чтобы любой входящий сигнал можно было направить конкретному клиенту. Этот адрес известен также под именем GRUU (Globally Routable User URI). Каждой клиентской конечной точке, зарегистрированной в системе OCS, сервер OCS присваивает отдельный адрес GRUU, однозначно определяющий клиентскую конечную точку.
Рис. 2 Процедура регистрации
Рис. 2 Процедура регистрации
Для контроля процесса регистрации предусмотрено ограничение, состоящее в том, что сервер разрешает только восемь активных регистраций каждому пользователю. Если для одного пользователя зарегистрировано несколько клиентов, такая настройки называется MPOP (multiple points of presence — несколько точек присутствия). Если зарегистрирован только один клиент, его называют SPOP (single point of presence — единственная точка присутствия).
Концепция MPOP является центральной в системе OCS. Она позволяет пользователю принимать входящие вызовы или уведомления IM из любой конечной точки, позволяя пользователю, по существу, иметь несколько телефонных оконечных точек или оконечнцых точек обмена мгновеными сообщениями. Она вносит интересную динамику в ответы с помощью мгновенных сообщений или даже описание присутствия в точности для одного пользователя.
Например, удаленный пользователь, который не в состоянии принимать мгновенные сообщения, мог бы зарегистрироваться на Communicator Phone Edition IP Phone (конечная точка SPOP). IP Phone публикует эту возможность конечной точки наряду с информацией о присутствии. Состояние присутствия пользователя на телефоне доступно по сети. Другой пользователь может просматривать состояние присуствия в сети и пытаться отправить мгновенное сообщение с помощью Communicator. Однако, поскольку присутствие уже опубликовало возможности устройства, отображается уведомление о том, что удаленный пользователь не представлен на устройстве, поддерживающем мгновенные сообщения, и, следовательно, может не получить сообщения.
Еще один пример касается автоматического приема мгновенных сообщений. Когда бы ни начался обмен мгновенными сообщениями, сообщение немедленно принимается автоматически, если удаленный пользователь представлен на единственном экземпляре Communicator (опять же, конечная точка SPOP). Но если удаленный пользователь зарегистрирован на двух экземплярах Communicator (скажем, на портативном и настольном компьютерах), тогда обеспечивается 10-секундная задержка, позволяющая пользователю принять мгновенное сообщение с одного устройства. Если ответа нет, мгновенное сообщение принимается автоматически на наиболее активном экземпляре Communicator.

Присутствие
В единой среде связи присутствию отведена важная роль. Оно позволяет пользователю заранее узнать о доступности удаленного пользователя для обмена информацией посредством заданного режима. Так, состояния OCS, например «занят — отвечает на вызов», связаны скорее с состоянием «занят» пользователя, чем с тем, что занято устройство или линия. Кроме этого, OCS 2007 предоставляет усовершенствованную инфраструктуру присутствия, позволяющую пользователю распространять такую информацию, как местоположение, часы работы и время встречи.
Кроме того, OCS позоволяет пользователю указывать разрешения, чтобы различные группы лиц имели доступ к разным наборам данных о присутствии, соответствующим их уровню доступа. В OCS также используется состояние присутствия пользователя, например «Не беспокоить», а также календарные часы работы и уровень разрешения, предоставленный абоненту для принятия решений о маршрутизации — будет ли вызов пользователя сопровождаться звуковым сигналом или будет отправлен на голосовую почту.
Номера телефонов для вызова, отображаемые в Office Communicator по нажатию кнопки, поступают из трех источников — два из них основываются на каталогах (глобальный список адресов/сервер адресной книги и контакты Outlook), а третий обеспечивается посредством присутствия. С помощью присутствия пользователи получают гибкость дли публикации номеров телефонов, которые они хотят сообщить другим.
Присутствие играет также ключевую роль во множестве задач маршрутизации голосовых вызовов. Например, если присутствие для удаленного пользователя указывает на состояние «Занят» и отображается текст «На собрании», то мала вероятность того, что пользователь ответит на голосовой вызов. В этом случае абонент может предпочесть использование IM или электронной почты. Аналогично, когда присутствие для удаленного пользователя имеет значение «Не беспокоить», это является указанием на то, что можно предпочесть альтернативные средства связи.
Присутствие несет также информацию о текущем названии и календарных данных собрания пользователя, и эти данные публикуются для пользователей в контейнере «Группа». Присутствие несет информацию о точке, являющейся предпочтительной для конкретного функционального средства, и это используется для выбора оконечной точки, выполняющей действие по умолчанию. Например, публикация календарных данных (которые, по существу, одинаковы для всех оконечных точек) будет выполнена только из оконечной точки, являющейся предпочтительной для функции календаря. В системе OCS предусмотрена логика выбора предпочтительной оконечной точки.
На рис. 3 выделены различные возможности, привносимые присутствием в систему OCS. Присутствие, как утверждалось ранее, является сочетанием доступности и готовности обмениваться информацией. Состояние «В сети» представляет состояние, в котором готовность пользователя обмениваться информацией является максимальной, а «Не беспокоить» является состоянием присутствия, в котором готовность пользователя обмениваться информацией является минимальной. За исключением состояния «Не беспокоить», которое устанавливается вручную, все другие состояния Communicator определяет автоматически, основываясь на различных условиях, таких как участие пользователя в собрании («занят») или нахождение вдали от компьютера («неактивен», затем «нет на месте»), как показано на рис. 4.
Figure 3 Способ установки сведений о присутствии (Close Figure 3)

Средство | Источник
Доступность и готовность («В сети», «Автономный», «Нет на месте», «Занят», «Не беспокоить») | Автоматически. На основе состояния собрания, состояния телефона и т.д. Можно задавать также вручную.
Состояние календаря («На собрании», «Место собрания») | Автоматически. На основе предпочтений пользователя.
Возможности устройства (обмен мгновенными сообщениями разрешен) | Автоматически. На основе устройства MPOP.
Номера телефонов | Автоматически На основе предпочтений пользователя.
Наиболее активная конечная точка | Автоматически На основе действий пользователя.
Примечание | Вручную. Переопределяется примечанием об отсутствии на рабочем месте.
Примечание об отсутствии на рабочем месте | Автоматически На основе календаря.
Рабочее время | Автоматически. На основе данных свободен/занят.
Расположение | Вручную. На основе выбора пользователя.
Рис. 4 Присутствие как сочетание доступности и готовности
Рис. 4 Присутствие как сочетание доступности и готовности
Обратите внимание, что доступность может определяться различными устройствами, на которых пользователь зарегистрирован в текущий момент. Поскольку для одного пользователя существует несколько устройств, и каждое устройство публикует данные о присутствии и данные пользователя с этого устройства, необходима объединяющая логика, которая обеспечивает для наблюдателей единую картину. В OCS имеется такая объединяющая логика, осуществляющая вычисление присутствия на основе различных параметров, устройств и входных данных, получаемых системой присутствия.
Прежде чем исследовать вопросы объединения, имеет смысл рассмотреть, каким способом объединенные данные публикуются для пользователей. В OCS 2007 появилась концепция контейнеров, которые в некотором смысле аналогичны уровням доступа, связанным с социальными кругами. Все контейнеры предоставляют разные объемы информации, и лица, добавленные к конкретному контейнеру, имеют доступ только к информации, которая доступна для этого контейнера. Каждое лицо, входящее в список контактов, должно быть представлено в одном из доступных контейнеров. Office Communicator дает пользователю возможность приписывать людей к контейнерам или перемещать их в другие контейнеры, основываясь на уровне взаимоотношений. В Office Communicator используется интеллектуальный эвристический подход для автоматического выбора контейнера по умолчанию (представлен на рис. 5).
Figure 5 Контейнеры присутствия (Close Figure 5)

Контейнер | Назначение
Заблокированный | Блокирует данные присутствия. Вызовы от заблокированных пользователей не разрешены. Однако заблокированные пользователи могут просматривать данные об имени и адресе электронной почты.
Общий | Предоставляет имя, название, компанию, адрес электронной почты и ограниченный доступ.
Компания | Предоставляет данные о рабочих контактах, основное расписание и доступность.
Группа | Предоставляет рабочие и мобильные номера, расписание, доступность и может прерывать пользователя в состоянии «Не беспокоить».
Личный | Можно просматривать все опубликованные данные контактов, включая домашние и мобильные номера.
В OCS объединение данных присутствия определяет правильное значение присутствия для пользователя на основе различных состояний присутствия, передаваемых на сервер устройствами. На рис. 6 показано объединение данных присутствия из различных источников. Отметим, что некоторая информация, например состояние присутствия и действия пользователя, отправляется посредством механизма OCS для объединения присутствия, а другие сведения, такие как данные контактов, добавляются к соответствующим контейнерам клиентскими конечными точками. Заблокированный контейнер отсутствует, поскольку в этом контейнере публикуется только информация о членстве.
Рис. 6 Объединение данных присутствия и публикация
Рис. 6 Объединение данных присутствия и публикация
В системе OCS отношение присутствия устанавливается, когда один пользователь добавляет другого в список контактов (список коллег). Но система OCS позволяет также наблюдать присутствие других пользователей в корпоративном каталоге без индивидуального добавления этих пользователей в качестве контактов.
Самый простой способ получить данные о чьем-либо присутствии заключается в поиске этого лица в Office Communicator. При этом создается единственный запрос на сервере и не осуществляется подписка на уведомления с сервера об изменениях состояния присутствия удаленных пользователей. Однако, когда пользователь добавляет другого пользователя в свой список контактов, он подписывается на уведомления об изменениях состояния присутствия, поэтому OCS автоматически отправляет предупреждения при каждом возникновении изменений.

Обмен мгновенными сообщениями и аудио
Мгновенные сообщения используют преимущества как регистрации, так и присутствия. В системе OCS сообщения перемещаются от узла к узлу, и сервер OCS работает как прокси, перемещающий сообщения между клиентами Office Communicator.
Важное значение имеет первое сообщение, отправляемое одним пользователем другому. Выражаясь в терминах SIP, оно устанавливает сеанс. Часть установления сеанса состоит в поиске подходящего клиента MPOP среди зарегистрированных клиентов, и именно здесь OCS играет важную роль в качестве прокси. Как только пользователь соглашается на входящий сеанс обмена мгновенными сообщениями, или одна из конечных точек MPOP пользователя автоматически откликается на сеанс, последующие сообщения спокойно перемещаются можду точками, не требуя от OCS поиска подходящего клиента.
Пользователи могут покидать окна обмена, открытые на их рабочих столах, и, если в течение 10-минутного периода не выполняются никакие действия, Office Communicator 2007 завершит сеанс SIP (хотя окно обмена мгновенными сообщениями останется открытым). Сеанс обмена мгновенными сообщениями может завершить также любая из сторон. Когда бы ни завершился сеанс обмена мгновенными сообщениями, Office Communicator 2007 автоматически создает для беседы элемент журнала, который записывает всю беседу в папке Outlook Conversation History. Это специальная папка, создаваемая в Outlook клиентом Office Communicator. Эта функция ведения журнала клиентской стороны является необязательной и отключена по умолчанию. Office Communicator использует журнал беседы при повторном запуске беседы с тем же пользователем; таким образом, пользователи, включившие эту возможность, получают более комфортную рабочую среду для продолжения беседы с помошью мгновенных сообщений после закрытия окна обмена мгновенными сообщениями.
Обратите внимание, что конструкции обмена мгновенными сообщениями, представленные здесь для forking и MPOP, в большой степени применяются также в случае голосовой связи. Вместо приглашения, содержащего описание сеанса обмена мгновенными сообщениями, содержится описание сеанса голосовой связи, указывающее на аудио функцию. OCS применяет forking для голосовых вызовов ко всем конечным точкам, аналогично тому, как это применяется в случае обмена мгновенными сообщениями.
Передача голосовых сигналов многое унаследовала от концепций IM, но в этом случае возникает необходимость управления носителем. Этот вопрос будет рассмотрен подробнее в будущей статье.

Раджеш Раманатан (Rajesh Ramanathan) работал в сфере передачи информации в течение 14 лет, и в настоящее время является главным менеджером программы в группе, занимающейся клиентом Office Communicator. С ним можно связаться по адресу rajeshra@microsoft.com.


 Office Communications Server: Составьте план развертывания голосовых средств OCS 2007
Office Communications Server Йохен Кюнерт and Руи Максимо

Составьте план развертывания голосовых средств OCS 2007
Краткий обзор:
  • Варианты интеграции телефонии
  • Настройка Office Communications Server
  • Пользователи, планы номеров и маршруты

Microsoft Office Communications Server (OCS) 2007 – это корпоративный продукт, интегрирующий средства коммуникаций со средствами отслеживания состояния пользователей, включая веб-конференции
(с общим доступом к данным, включая видео- и аудиофайлы), обмен мгновенными сообщениями и аудио/видеобеседы. Интеграция OCS 2007 с существующей системой УАТС может оказаться сложной. Office Communications Server 2007 не предназначен для работы в качестве УАТС, поскольку в наши дни сотрудники, занимающиеся обработкой информации, используют в своей повседневной работе широкий набор средств связи, включая электронную почту, системы мгновенного обмена сообщениями, телефон и голосовую почту, тогда как системы УАТС работают только с телефонными звонками.
С целью предоставления гибкости, необходимой администраторам для создания оптимальной стратегии интеграции телефонии, в индивидуальных масштабах или масштабах компаний, Office Communications Server 2007 предлагает три варианта настройки для интеграции с существующими средами телефонии. Это Remote Call Control («Удаленное управление звонками»), Enterprise Voice и Enterprise Voice с интеграцией УАТС.
В этой статье рассматриваются вопросы планирования развертывания телефонии OCS 2007, для которого может быть необходимым интеграция с существующей системой телефонии. Данная информация будет особо интересна системным архитекторам, а также администраторам, как системным, так и телефонии. В качестве дополнения мы предоставим обзор других вариантов, но основное внимание будет обращено на Office Communications Server 2007 Enterprise Voice.

Remote Call Control
Дополнительные материалы по OCS
  • Pro LCS: Live Communications Server Administration
  • Интеграция телефонии с Office Communications Server 2007
  • Руководство по планированию развертывания и развертыванию Enterprise Voice

В варианте Remote Call Control (RCC) у пользователей имеется существующая АТС, АТС с поддержкой IP или настольный телефонный аппарат временного уплотнения (Time-Division Multiplexing – TDM). Со своего клиента Office Communicator 2007 они могут звонить со своего настольного телефона и отвечать на звонки, не набирая номер и не поднимая трубки. Несмотря на то, что пользователи могут контролировать свой настольный телефон, используя Office Communicator 2007, звук по прежнему обрабатывается системой УАТС, не преобразуясь в передачу голоса по протоколу IP (Voice-over-IP – VoIP). Хотя Office Communicator 2007 может контролировать настольный телефон, звонки и ответы на них по-прежнему будут производиться с телефона УАТС вне зависимости от того, работает ли Office Communicator 2007.
Чтобы позволить RCC работать с Office Communicator 2007 и OCS 2007, необходимо развернуть шлюз SIP (Session Initiation Protocol – «Протокол инициализации сеанса»)/CSTA (Computer Supported Telephony Application – «Приложение телефонии с компьютерной поддержкой) в дополнение ко включению среды Office Communications Server 2007 для RCC. Шлюз SIP/CSTA должен взаимодействовать с используемым типом системы УАТС и быть совместимым с OCS 2007, поскольку он играет роль моста между этими двумя системами. Чтобы контролировать телефон УАТС, Office Communicator 2007 использует протокол CSTA. Этот протокол определяет схему XML для стыковки с телефонным коммутаторами (УАТС), как описано в стандарте ECMA (Европейской ассоциации производителей вычислительной техники) 269, который можно найти на www.ecma-international.org/publications/standards/Ecma-269.htm.
Office Communicator 2007 посылает команды CSTA для управления телефоном УАТС в виде полезных данных SIP, маршрутизируемых Office Communications Server 2007 к шлюзу SIP/CSTA. Office Communications Server 2007 не обязательно должен понимать CSTA. Достаточно информации о том, как его маршрутизировать. Затем шлюз SIP/CSTA преобразует команды в собственный протокол УАТС. Это проиллюстрировано на рис. 1.
Рис. 1 Вариант интеграции RCC
Рис. 1 Вариант интеграции RCC
Включение RCC выполняется в пять этапов. Первый из них – настройка SIP/CSTA на связь с УАТС. Далее –– настройка OCS 2007 на маршрутизацию запросов CSTA к шлюзу SIP/CSTA. Третий этап –– настройка пользователей для RCC. Четвертый –– настройка Office Communicator 2007. Последнее действие –– определение правил нормализации OCS 2007, которые также используются для нормализации телефонных номеров в адресной книге и отличаются от правил нормализации телефонных номеров, используемых в сочетании с Enterprise Voice.

Enterprise Voice
После того как пользователю дается возможность использовать Enterprise Voice, Office Communicator 2007 или Office Communicator Phone Edition становится его основным телефоном вместо его телефона УАТС. Office Communicator 2007 получит уникальный телефонный номер. (В целях тестирования существующий телефон УАТС может быть перенаправлен на новый добавочный номер, выделенный для Office Communicator 2007). Office Communicator 2007 в сочетании с рекомендуемым аудиоустройством USB будет обрабатывать как элемент управления вызовом (или сигнал), так и носители (аудио и видео).
В данном случае Office Communications Server 2007 маршрутизирует звонки между конечными точками Office Communicator 2007 в сети IP (звонки IP-IP), а также звонки, направляемые коммутируемой телефонной сети общего пользования (PSTN)/PBX (звонки IP-PSTN). OCS 2007 устанавливает ограничения на набор номера, для звонков, маршрутизируемых в КТСОП.
Для подключения среды Office Communications Server 2007 к УАТС или КТСОП необходимо развернуть медиашлюз, он же шлюз SIP/КТСОП или IP/КТСОП . Медиашлюз следует использовать в паре с сервером-посредником (серверная роль в OCS 2007) для подключения к среде Office Communications Server 2007, как показано на рис. 2. Физически сервер-посредник и связанный с ним медиашлюз должны быть расположены в одном месте.
Рис. 2 Вариант интеграции Enterprise Voice с КТСОП или существующей УАТС
Рис. 2 Вариант интеграции Enterprise Voice с КТСОП или существующей УАТС
Сервер-посредник делает возможным подключение медиашлюзов, поддерживающих стандартные и даже небезопасные реализации SIP, к Office Communications Server 2007, поскольку OCS 2007 допускает только зашифрованную и сопровождающуюся проверкой подлинности передачу данных. Другой задачей сервера-посредника является обработка перевода между стандартными кодеками (G.711, G.723 и т.д.) и работающим в режиме реального времени аудиокодеком Майкрософт. Список медиашлюзов, поддерживаемых Office Communications Server 2007, приведен в списке производителей оборудования – стратегических партнеров Майкрософт на странице technet.microsoft.com/bb735838.
Медиашлюзы можно подключать прямо к КТСОП или к магистральному подключению интерфейса первичного доступа (Primary Rate Interface – PRI) существующей УАТС. На рис. 2 показаны возможные варианты интеграции для варианта Enterprise Voice с КТСОП и существующей УАТС. Для развертывания Enterprise Voice не требуется контроллер (обычно Office Communications Server Standard Edition Server), однако его использование рекомендуется.
Включение Enterprise Voice выполняется в четыре этапа. Прежде всего, нужно развернуть и настроить медиашлюзы. Поскольку это партнерский продукт Майкрософт, воспользуйтесь документацией поставщика, так как каждый медиашлюз требует своих действий для развертывания.
Далее, следует развернуть сервер-посредник для каждого медиашлюза. На этом этапе необходимо настроить одну сетевую карту сервера-посредника на получение и отправку трафика медиашлюза, а другую его сетевую карту на получение и отправку трафика Office Communications Server 2007 (обычно контроллера в развертывании Enterprise Edition). Если медиашлюз не является усовершенствованным шлюзом, ему будет нужна помощь роли сервера-посредника OCS 2007 для взаимодействия с инфраструктурой OCS 2007 Enterprise Voice.
Третьим этапом является определение плана номеров. В него входит определение политик голосовой связи, телефонных маршрутов и профилей местоположения.
Далее настраиваются пользователи для Enterprise Voice. Кроме того, пользователи должны иметь доступ к Enterprise Voice, чтобы иметь возможность совершать и получать звонки от УАТС или КТСОП. Для этого требуется назначение уникального телефонного номера каждому пользователю.

Enterprise Voice с интеграцией УАТС
Эта конфигурация является расширением конфигурации Enterprise Voice. Разница заключается в том, что телефон УАТС пользователя синхронизирован с его клиентом Office Communicator. Эта конфигурация подобна варианту подключения Enterprise Voice к КТСОП посредством УАТС, как показано на рис. 2. Однако в данном случае вместо замены телефона УАТС пользователя на клиент Office Communicator 2007 существующий телефон УАТС и Office Communicator 2007 используют один и тот же номер.
Если на внутренний номер пользователя приходит звонок с другого телефона УАТС или с телефона КТСОП, система УАТС направит его и телефону УАТС пользователя и его клиенту Office Communicator 2007 через Office Communications Server 2007. Клиент Office Communicator 2007 и телефон УАТС пользователя зазвонят одновременно при получении входящего вызова. Аналогично, Office Communications Server будет ответвлять к УАТС звонки, исходящие от OCS 2007, через медиашлюз. Данный вариант невозможен при использовании Office Communicator Phone Edition. Эта конфигурация требует, чтобы голосовая почта обрабатывалась системой голосовой почты УАТС. Единая система обмена сообщениями Exchange Server 2007 не может быть использована как решение голосовой почты для подобных пользователей.
Включение Enterprise Voice с интеграцией УАТС включает в себя те же действия, что и развертывание Enterprise Voice, но с тремя дополнительными этапами. Первый дополнительный этап заключается в подключении медиашлюза прямо к УАТС. Затем УАТС следует настроить для поддержки этого варианта. (В зависимости от поставщика может потребоваться обновление ПО на УАТС.) Наконец, необходимо обеспечить возможность интеграции УАТС для пользователей.
Майкрософт работает над предоставлением поддержки прямого подключения сервера-посредника к АТС с поддержкой IP без посредничества медиашлюзов. Посетите technet.microsoft.com/bb735838, чтобы ознакомиться с последними известиями по этому вопросу.

Настройка Office Communications Server
Функции Enterprise Voice выполняются службами, работающими на Office Communications Server 2007 Enterprise Edition и Office Communications Server 2007 Standard Edition. На рис. 3 показаны службы, предоставляющие Enterprise Voice функции по маршрутизации входящих и исходящих звонков.
Figure 3 Службы Enterprise Voice (Close Figure 3)

Служба | Описание
Служба преобразования | Применяет правила нормализации, основываясь на профиле местоположения или контексте телефона.
Службы пользователя | Выполняют обратный просмотр номера на целевом телефонном номере.
Компонент маршрутизации входящих вызовов | Применяет настройки звонка целевого пользователя.
Единая система обмена сообщениями Exchange | Направляет запросы голосовой почте по мере надобности.
Компонент маршрутизации исходящих вызовов | Определяет оптимальный маршрут, основываясь URI-адресе и политике пользователя.
На рис. 4 показана работа каждого из этих компонентов над входящими звонками в ходе их маршрутизации OCS 2007 для звонка от компьютера к компьютеру. Входящие звонки могут происходить от связанных конечных точек, таких как Office Communicator 2007 или Office Communicator Phone Edition, либо от сервера-посредника, идущего от КТСОП/УАТС (звонок КТСОП-SIP). Исходящие звонки от одной из клиентских конечных точек Office Communications Server 2007, такой как Office Communicator 2007, отсылаются в пул Standard Edition Server или Enterprise, куда и направляется пользователь. Он называется домашним пулом пользователя.
Рис. 4 Взаимодействие служб, связанных с Enterprise Voice, на серверах клиентского доступа OCS
Рис. 4 Взаимодействие служб, связанных с Enterprise Voice, на серверах клиентского доступа OCS
На этом этапе, Office Communications Server 2007 обрабатывает звонок, чтобы определить, куда его маршрутизировать. Следующий прыжок может быть направлен к домашнему пулу вызываемого, серверу-посреднику или единой системе обмена сообщениями Microsoft® Exchange Server 2007 (см. рис. 5). Если звонок направляется другому домашнему пулу, OCS 2007 отсылает его всем активным конечным точкам адресата звонка. Office Communicator 2007 или Office Communicator Phone Edition адресата зазвонят и выдадут всплывающее окно уведомления на устройстве.
Рис. 5 Маршрутизация звонков
Рис. 5 Маршрутизация звонков
Если звонок отправляется серверу-посреднику, сервер настроен на перенаправление его конкретному медиашлюзу. Если медиашлюз подключен прямо к УАТС, УАТС перенаправляет звонок настольному телефону или в КТСОП. Однако если медиашлюз подключен прямо к КТСОП, звонок идет в КТСОП.
Если следующий прыжок – к единой системе обмена сообщениями Exchange Server 2007 Unified Messaging, то звонящий может оставить сообщение. Голосовая почта доступна вне зависимости от того, подписан ли адресат звонка на Office Communications Server 2007.
При ответе на звонок аудио посылается прямо из Office Communicator 2007 или Office Communicator Phone Edition звонящего к Office Communicator 2007 или Office Communicator Phone Edition отвечающего в виде звонка IP-IP. Если звонящий использует телефон УАТС или КТСОП, сервер-посредник направляет аудиотрафик прямо к Office Communicator 2007 или Office Communicator Phone Edition отвечающего в виде звонка IP-КТСОП. OCS 2007 обрабатывает только вызывные сигналы, в силу чего аудио и видео напрямую перемещаются между конечными точками и OCS 2007 не маршрутизирует их.

Настройка пользователей
Пользователям Enterprise Voice необходимо назначить телефонные номера, являющиеся уникальными в пределах организации. Эта настройка выполняется в Active Directory®. Она отлична от большинства систем телефонии, в которых телефонный номер назначается телефону. Преимущество этой схемы заключается в том, что пользователь может превратить любой компьютер, на котором установлен Office Communicator 2007, в свой рабочий телефон, подписавшись на OCS 2007 с клиента. Эта функция переносимости может быть заманчивой для сотрудников, работающих на дому или в удаленном офисе.
Телефонный номер пользователя указывается в Active Directory в формате E.164. Этот формат определяет план номеров международных общедоступных телекоммуникаций, схему номеров, позволяющую однозначно представлять уникальные номера. Формат E.164 указывает телефонный номер в следующем формате:
+<country code><area code><phone number>
У пользователя Enterprise Voice имеются два уникальных представления: URI-адрес SIP и телефонный номер E.164. При наборе номера Office Communications Server преобразует представление телефонного номера E.164 (+14255551212) в URI-адрес SIP пользователя (joe@contoso.com). Office Communications Server 2007 затем маршрутизирует звонок, основываясь на URI-адресе SIP адресата. Если телефонный номер нельзя преобразовать в URI-адрес SIP, OCS 2007 перенаправляет вызов УАТС/КТСОП через сервер-посредник.
При планировании развертывания Enterprise Voice, где каждому пользователю Office Communications Server необходимо назначить уникальный телефонный номер, следует учесть существующую систему телефонии. В случае подключения к КТСОП прямо через медиашлюз, вероятно, будут получены 2- и 3-значные добавочные для всего блока номеров, номера прямого входящего набора (Direct-Inward-Dialing – DID), которые можно распределить между пользователями OCS 2007. При подключении к КТСОП через УАТС, вероятно, будет получен блок номеров DID, предоставленный УАТС для назначения пользователям OCS 2007.

Планы номеров
Хотя телефонные номера в формате E.164 обеспечивают уникальное представление, их не слишком удобно набирать. Кроме того, номер в этом формате невозможно ввести в Office Communicator Phone Edition или стандартные телефоны УАТС/КТСОП. Как указать символ «+», используя номеронабиратель с 10 цифрами? Пользователям привычен набор более коротких добавочных номеров, которые могут быть уникальными для конкретного места, но, возможно, не для всей компании. Следовательно, необходимо сформулировать правила перевода для преобразования их в формат E.164.
Администратору следует определить профили их местоположения, указывающие правила нормализации для выполнения этих переводов номеров. После того как номер телефона расширен клиентом (Office Communicator 2007 или Communicator Phone Edition) либо службой преобразования Office Communications Server 2007 до формата E.164, службы пользователя могут выполнить обратный просмотр номера и сопоставить номер E.164 с соответствующим URI-адресом SIP. Правила нормализации, определенные в профиле местоположения, используют регулярные выражения для выполнения преобразования, если соответствие найдено. Например, если набрано 1234, нормализация, которая соответствует любому набору из четырех цифр, преобразующемуся в +1425555{4 цифры}, преобразует 1234 в +1425551234. Таким образом, профили местоположения позволяют пользователям набирать номера так, как они привыкли.
Администраторы могут назначать профили местоположения, используя три следующих способа:
  • Определение профиля местоположения для пользователей, использующих Office Communicator 2007, через групповую политику.
  • Предоставление пользователям возможности выбрать профиль местоположения из Office Communicator Phone Edition.
  • Назначение профиля местоположения домашнему пулу. Пользователям, направленным к данному пулу, будет автоматически назначаться этот профиль.
Определение плана номеров включает создание политик голосовой связи, телефонных маршрутов и профилей местоположения. Политики голосовой связи определяют доступный пользователям тип доступа по телефонному запросу. Office Communications Server 2007 определяет, как перенаправлять вызовы к УАТС/КТСОП посредством телефонных маршрутов. Поскольку телефонные номера можно набирать множеством способов, правила нормализации в профиле местоположения определяют, как преобразовывать набранный номер телефона в формат E.164, который затем можно маршрутизировать.
Каждый пользователь Enterprise Voice привязывается администратором к политике голосовой связи. Политика голосовой связи определяет привилегии телефонного вызова, назначенные пользователю. Эти привилегии определяют, какие маршруты дозволено использовать пользователю, а следовательно, и какие номера ему дозволено набирать. Каждый пользователь должен быть связан с единственной политикой голосовой связи. Число доступных политик создается администратором.
Каждая политика содержит параметр, позволяющий разрешить или запретить пользователям одновременные звонки, и упорядоченный список использований телефона. Политика голосовой связи, подобно политике собраний, является логическим контейнером параметров, определенных как документ XML, хранящийся в Active Directory. Ценность такой схемы заключается в том, что ее можно расширить в будущих версиях OCS 2007, устанавливая поддержку новых параметров политики без расширения схемы Active Directory. Например, если политика голосовой связи не связана с использованиями телефона, это воспрещает направление исходящих звонков к УАТС/КТСОП для пользователей, которым она назначена. Такие пользователи будут в состоянии производить лишь звонки IP-IP.

Использование телефона и маршруты
Использование телефона определяет выдаваемые пользователями привилегии при маршрутизации. Под термином «использование телефона» скрывается коллекция телефонных маршрутов. Оно является строкой, которая должна быть уникальным для каждого использования телефона ключевым словом. Администраторы могут создавать столько использований телефона, сколько нужно.
Хотя политика голосовой связи может быть прямо связана с маршрутом или набором маршрутов, вместо использования телефона, ключевое слово использования телефона является абстракцией, предназначенной для поддержания связи между политиками и маршрутами. Если бы политики были прямо связаны с маршрутами, по сути устраняя концепцию использований, а администратор изменил бы имя маршрута, то каждую политику, связанную с этим маршрутом, пришлось бы обновить. Посредством применения использования телефона, которое является атрибутом как политики, так и маршрута, для создания связи между политикой и маршрутом отношения политики и маршрута сохраняются даже при изменении имени последнего.
Маршрут содержит шаблон телефонного номера и список серверов-посредников, подключенных к медиашлюзам. Маршрут должен быть назначен как минимум одному использованию телефона. Эта связь между шаблоном и шлюзом указывает, как маршрутизировать телефонные номера, соответствующие данному конкретному шаблону.
Шаблон указывает диапазон телефонных номеров, которым он может соответствовать. Он определен как регулярное выражение, которое может включать и исключать телефонные номера. Средство Enterprise Voice Route Helper существует для упрощения создания этих регулярных выражений. Как следствие, если набранный телефонный номер соответствует шаблону регулярного выражения маршрута, то звонок перенаправляется одному из шлюзов, определенных в маршруте.
Маршрут может включать более одного сервера-посредника (и, следовательно, медиашлюза). Office Communications Server 2007 перенаправляет телефонный вызов серверу-посреднику в циклической манере, чтобы сбалансировать трафик между шлюзами. В случае сбоя шлюза или его отключения в целях обслуживания соответствующий сервер-посредник отправит ответ обратно на Office Communications Server 2007, а последний немедленно попытается перенаправить вызов другому серверу-посреднику (и, следовательно, другому медиашлюзу) в списке маршрута.
После 10 попыток перенаправить телефонные вызовы нефункционирующему медиашлюзу Office Communications Server 2007 уменьшит трафик к этому шлюзу, пока тот вновь не начнет отвечать. Если медиашлюз не возобновит работы после 10 дополнительных попыток, Office Communications Server 2007 прекратит перенаправление телефонных вызовов к этому шлюзу, пока тот вновь не начнет отвечать.
Список медиашлюзов, определенных в маршруте телефона, описан полным доменным именем шлюза и номером порта. Если телефонный номер не соответствует шаблону регулярного выражения, то проверяется следующий маршрут, связанный с назначенным пользователю телефоном, пока не будет найдено соответствие. Если соответствия не найдено, телефонный вызов не может быть маршрутизирован и не достигает своего назначения. Пользователь получает уведомление о том, что звонок не может быть выполнен.

Дальнейшие шаги
Office Communications Server 2007 предоставляет три уровня интеграции телефонии При планировании развертывания телефонии необходимо определить, какой уровень наилучшим образом соответствует текущим и будущим нуждам. После этого можно планировать развертывание. Важным аспектом планирования является определение плана номеров для развертывания Office Communications Server Enterprise Voice. Этот вопрос следует тщательно рассмотреть.
Дополнительные сведения о Office Communications Server 2007 Enterprise Voice и связанных с ним технологиях приведены на боковой панели "Дополнительные материалы по OCS 2007".

Йохен Кюнерт обладает десятилетним опытом работы в сфере телекоммуникаций и в настоящий момент работает старшим руководителем программы в группе Office Communications корпорации Майкрософт. Он является соавтором готовящейся к изданию книги Microsoft Office Communications Server 2007 Resource Kit. С ним можно связаться по адресу jkunert@microsoft.com.
Руи Максимо является ветераном информационных технологий с 14 годами стажа и соавтором двух книг: Pro LCS: Live Communications Server Administration и Microsoft Office Communications Server 2007 Resource Kit. С ним можно связаться по адресу ruim@ruimaximo.com.


 Высокопроизводительные вычисления: Введение в Windows Compute Cluster Server
Высокопроизводительные вычисления Джон Келбли (John Kelbley) and Дуг Линдси (Doug Lindsey)

Введение в Windows Compute Cluster Server
Краткий обзор:
  • Использование кластеров для решения сложных задач.
  • Общие требования к вычислительным кластерам.
  • Настройка вычислительного кластера под управлением Windows.
  • Удаленный запуск команд.

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

Общие требования к вычислительным кластерам
Материалы по HCP
  • Сообщество Windows HPC.
  • Высокопроизводительные вычисления с использованием WCCS 2003.
  • Обзор 64-разрядных систем Майкрософт.
  • Домашняя страница раздела, посвященного серверам Майкрософт.
  • Compute Cluster Server TechCenter
  • Пошаговое руководство по установке и настройке высокопроизводительного вычислительного кластера

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

Кластеры на базе Windows Server
В 2006 году корпорация Майкрософт выпустила системы Windows Server 2003 Compute Cluster Edition (CCE) и Windows Compute Cluster Server 2003 (WCCS), призванные обеспечить выполнение требований широкого ряда HPC-приложений. Системы CCE и WCCS построены на базе одной и той же системы Windows Server 2003, с которой вы уже знакомы. CCE — это версия Windows Server 2003, лицензированная для применения в системах HPC. WCCS отличается от CCE только наличием пакета Microsoft® Compute Cluster Pack (CCP). Это означает, что для развертывания, управления, мониторинга и обслуживания кластера на базе Windows Server можно использовать те же средства, что используются для выполнения аналогичных задач в системах Windows Server 2003.
Важно отметить, что системы CCE и WCCS выпущены только в виде 64-разрядных версий — 32-разрядных версий (x86) этих продуктов нет. Требования к оборудованию для CCE и WCCS совпадают с требованиями для 64-разрядной версии Windows Server 2003 Standard. Для обеспечения работы высокопроизводительного оборудования (64-разрядной архитектуры) эти системы дополнительно включают поддержку RDMA для высокоскоростных подключений (Gigabit Ethernet, InfiniBand, Myrinet и др.)

Пакет Compute Cluster Pack
Как было упомянуто ранее, вычислительные кластеры предъявляют ряд базовых требования, которые выполняются путем установки пакета Compute Cluster Pack. CCP — это самостоятельный установочный пакет, включающий в себя следующие компоненты:
  • встроенный планировщик заданий;
  • поддержку интерфейса MPI для отраслевого стандарта MPICH2;
  • инструменты пользователя и средства управления ресурсами кластера.
Наличие пакета CCP — главное отличие систем CCE и WCCS. Возникает вопрос: почему пакет включен только в WCCS, если он содержит средства, необходимые для работы кластера. Дело в том, что в некоторых HPC-решениях используются другие планировщики заданий или специальные MPI-интерфейсы (а в некоторых случаях поддержка MPI вовсе не требуется). Для реализации таких решений необходима лишь опорная платформа — а именно Windows Server 2003. А поскольку CCP представляет собой совершенно самостоятельный пакет, его можно установить на любой 64-разрядной версии Windows Server 2003 (CCE, Standard, Standard R2, Enterprise и Enterprise R2).

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

Службы удаленной установки
Система WCCS предоставляет встроенный интерфейс для платформы развертывания образов Microsoft Remote Installation Service. Служба RIS применяется для развертывания образов операционных систем с головного узла на вычислительные узлы, ускоряя тем самым установку нового кластера. Отдельно ее использовать не приходится: служба RIS для удобства работы встроена в систему WCCS. Вы можете также использовать и другие распространенные технологии развертывания систем Windows Server, в том числе службы автоматического развертывания Windows Server 2003 (ADS), а можете устанавливать Windows Server 2003 вручную.
Если вы решили использовать службу RIS, перед установкой системы CCP на головной узел убедитесь в том, что вы определили как минимум два логических диска. Служба RIS требует наличия диска, отделенного от операционной системы, — для хранения образов сервера. Раздел, отведенный RIS, должен быть достаточно большим, чтобы вместить один или несколько полных образов системы Windows Server.
Для нового серверного оборудования, в особенности для сетевых устройств и хранилищ, могут понадобиться драйверы Plug and Play, не включенные в стандартный образ Windows Server 2003. Их придется добавить в образ вручную. Эта процедура описана в статье по адресу support.microsoft.com/kb/254078.

Установка кластера
Первый шаг в процедуре настройки нервной системы кластера — создание головного узла. Начните с установки одной из 64-разрядных версий Windows Server 2003, упомянутых выше. Во время установки вам будет предложено присоединить сервер к существующему домену (рекомендуется это сделать) и установить службу Active Directory на сервере (не рекомендуется для крупномасштабных кластеров).
После установки операционной системы обязательно загрузите и установите все рекомендованные исправления из центра обновления Майкрософт. Если вы планируете использовать службу RIS для работы с образами вычислительных узлов, вы должны воспользоваться служебной программой «Управление дисками» (в разделе «Управление компьютером») и убедиться в наличии хотя бы двух логических дисков. В целях экономии места установку с использованием RIS мы рассматривать не будем.
После того как вы успешно вошли в систему и обновили сервер, вы запускаете программу установки CCP. Программа либо установит сама, либо поможет вам загрузить и установить следующие файлы и обновления:
  • исправление для RIS (см. go.microsoft.com/fwlink/?linkid=55167);
  • консоль MMC 3.0 (см. go.microsoft.com/fwlink/?linkid=62400);
  • SQL Server Desktop Edition — как часть процесса установки головного узла Compute Cluster Server 2003;
  • Microsoft .NET Framework 2.0.
Программа установки CCP выполняет немалую работу по проверке готовности системы к установке. Она сообщает о том, какие компоненты требуются, какие будут установлены в ходе работы программы, и устанавливает их (см. рис. 1).
Рис. 1 Компоненты, необходимые для установки CCP
Рис. 1 Компоненты, необходимые для установки CCP

Список необходимых действий
После завершения установки CCP откроется консоль администратора и предъявит вам список необходимых действий. Как показано на рис. 2, список состоит из нескольких панелей, каждая из которых посвящена отдельной теме. В этот список включены задания, которые необходимо выполнить для полной настройки кластера.
Рис. 2 Список заданий, которые необходимо выполнить для настройки кластера
Рис. 2 Список заданий, которые необходимо выполнить для настройки кластера
Список необходимых действий помогает вам построить намеченную архитектуру кластера, в том числе выбрать и настроить топологию сети, процедуру установки узлов и модель управления. Задания в каждой панели перечислены в правой части. Каждое задание запускает свой мастер. Чтобы полностью настроить головной узел, с которого будут развертываться образы вычислительных узлов при помощи службы RIS, и который будет администрироваться и использовать определенным набором пользователей, выполните по очереди все перечисленные задания.
Топология сети WCCS поддерживает пять наиболее распространенных топологий, применяемых в системах HPC. По крайней мере, все вычислительные узлы и головной узел должны быть подключены к общей сети. В топологиях поддерживаются различные виды подключений между узлами. Они различаются набором преимуществ и объемами затрат.
Выбор топологии сети зависит от требований кластера к производительности, безопасности и развертыванию. Для работы ваших приложений, к примеру, может требоваться высокоскоростное подключение между узлами для обмена сообщениями, которые лучше не передавать через корпоративную сеть. Или вы можете предпочесть воспользоваться преимуществами встроенных функций автоматического развертывания на базе RIS. Или ваше оборудование допускает установку только одной сетевой платы. Или вы хотите установить на головном узле службу ICS, обеспечивающую управление разрешением имен и адресации вычислительных узлов. Мастер настройки топологии сети кластера, вызываемый из списка задач, предлагает вам на выбор пять топологий, обычно используемых в реализациях систем HPC, а также помогает настроить сетевые подключения и брандмауэр Windows на головном узле и на вычислительных узлах. Рис. 3 иллюстрирует одну из поддерживаемых топологий сети.
Рис. 3 Одна из топологий сети, поддерживаемых WCCS
Рис. 3 Одна из топологий сети, поддерживаемых WCCS
Службы удаленной установки Как отмечалось выше, служба RIS обеспечивает автоматическое развертывание узлов кластера.
Управление узлами Вы можете указать имена тех серверных машин, которые будут выступать в роли вычислительных узлов кластера. При запуске CCP на узле указывается головной узел кластера, к которому нужно присоединить настраиваемый узел.
Управление пользователями Здесь вы можете указать учетные записи пользователей или группы в службе каталогов Active Directory, которые будут выполнять функции системного администратора или пользователей кластера.

Установка узла
Вычислительные узлы можно развертывать автоматически при помощи служебной программы RIS или других поддерживаемых методов. Так же как и на головном узле, на каждом вычислительном узле необходимо установить CCP. Как видно из рис. 4, параметры настройки CCP для вычислительного узла гораздо проще. Настройка включает в себя следующие процессы:
Рис. 4 Установка пакета Compute Cluster Pack
Рис. 4 Установка пакета Compute Cluster Pack
  • Указать, что сервер будет выступать в роли вычислительного (а не головного) узла.
  • Указать имя головного узла, к которому нужно присоединить настраиваемый сервер.
  • Указать, нужно ли устанавливать инструменты пользователя и средства администрирования на данном вычислительном узле.

Консоль администратора
После подключения всех вычислительных узлов к головному большинство задач по управлению и администрированию систем выполняются через консоль администратора — она приведена на рис. 5. Консоль дает информацию о всем кластере: предоставляет список связанных узлов, дает доступ к основным операциям по администрированию и прочим элементам. В самой левой панели находятся главные элементы, используемые для перемещения по консоли, в том числе здесь можно получить доступ к модулю «Администратор кластера», в котором содержится общая информация о состоянии кластера и статистика по заданиям. Здесь же можно получить доступ к сеансам удаленного мониторинга компьютеров и системы в целом. Впрочем, основное время администратор проводит в модуле «Управление узлами».
Рис. 5 Информация о кластере в консоли администратора
Рис. 5 Информация о кластере в консоли администратора
Консоль администратора вы должны как следует изучить, поскольку она дает доступ к основным средствам и функциям, необходимым для централизованного администрирования системы Windows и вычислительных узлов. Если щелкнуть один раз узел кластера, указанный в центральной панели, в остальных окнах появится информация о выбранном узле и вы сможете ознакомиться с его функциями.
Команды, включенные в контекстные меню, упрощают централизованное администрирование вычислительных узлов. В модуле «Управление узлами» вы можете остановить и запустить узел; утвердить добавление узла и удалить узел из кластера; запустить удаленный рабочий стол, системный монитор или просмотр событий; извлечь лоток компакт-диска (так очень удобно находить нужную машину в большом кластере).

Функция ClusRun
Самая, пожалуй, удобная функция в этом списке — команда «Выполнить». Она дает возможность удаленно запускать любую произвольную команду, как будто вы ее вводите в командной строке соответствующего компьютера. В WCCS имеется версия этой функции для командной строки — программа Clusrun.exe. ClusRun называется и графическая версия, и версия для командной строки.
Преимущества служебной программы ClusRun сложно переоценить — особенно если вы имеете дело с большими кластерами. Она позволяет здорово сэкономить время при выполнении повторяющихся задач с применением командной строки, а также порой устраняет необходимость в более сложных сценариях администрирования.
Чтобы открыть программу, выделите в списке компьютеры, для которых вы хотите запустить ту или иную команду, щелкните правой кнопкой мыши и выберите команду «Выполнить». Появится диалоговое окно, показанное на рис. 6. Теперь вам нужно просто ввести необходимую команду, запустить ее и дождаться появления выходных данных в окне результатов. При первом запуске программа ClusRun попросит вас указать учетные данные, и вы можете их кэшировать для дальнейшего использования.
Рис. 6 Запуск команды для нескольких узлов
Рис. 6 Запуск команды для нескольких узлов
Для установки исправлений для кластеров или программ, предусматривающих возможность автоматической установки, из обычно помещают в общий файловый ресурс, а потом при помощи программы ClusRun запускается одна команда для всех вычислительных узлов. Перезагрузить все вычислительные узла кластера можно одной командой:
CLUSRUN SHUTDOWN –R –F –T 0

Пакет инструментов
В мае 2007 группа HPC выпустила пакет Compute Cluster Pack Tool Pack (его можно загрузить по адресу windowshpc.net/resources/Pages/default.aspx). Этот пакет включает поддержку Windows PowerShellTM, средство MPIPingPong для диагностики работоспособности подключений и простенький, но очень полезный графический монитор кластера.
Как видно из рис. 7, монитор отображает в одном окне все узлы кластера, показывает число ядер в каждом узле, загрузку каждого ЦП (ярко-зеленый индикатор), использование памяти (желтый индикатор), процент активности диска (красный индикатор) и загрузку пропускной полосы сети (оранжевый индикатор). Это довольно удобное средство, позволяющее администратору получить общие сведения о работе кластера.
Рис. 7 Контроль нескольких узлов в мониторе кластера
Рис. 7 Контроль нескольких узлов в мониторе кластера
Монитор кластера обладает свойством «удаляемости». Первый экземпляр монитора должен быть запущен на головном узле. После того как вы его запустили, вы можете запустить другой экземпляр монитора на рабочей станции, привязать его к головному узлу и получить те же самые данные.

Так и чего вы ждете?
Теперь вы полностью готовы к встрече с HPC и Windows Server 2003 Compute Cluster Server. Вы знаете, как установить CCP, вы познакомились с центральной консолью администратора, вы получили в распоряжение новые команды и графические средства, способные потрясти не только пользователей, но и ваших коллег. Дополнительные источники информации по высокопроизводительным вычислениям вы найдете на врезке «Материалы по HPC».

Джон Келбли (John Kelbley) — технический менеджер по продукции в отделе разработки глобальных решений Майкрософт, расположенном на северо-востоке США. Связаться с Джоном можно по адресу Johnkel@microsoft.com
Дуг Линдси (Doug Lindsey) — руководитель программы в группе высокопроизводительных вычислений корпорации Майкрософт. Кроме этого, он администрирует рабочие вычислительные кластеры (включая тот, что значится под номером 116 в ноябрьском списке www.top500.org за 2007 год). Связаться с Дугом можно по адресу Dougli@microsoft.com.


 Сетевое дополнение: Разверните систему 2007 Office со службами терминалов
Сетевое дополнение Джеймс Д. Салливан

Разверните систему 2007 Office со службами терминалов
Краткий обзор:
  • Развертывание для системы 2007 Office
  • Управление параметрами пользователей
  • Новая панель быстрого доступа
  • Средство настройки для 2007 Office

В выпуске системы 2007 Microsoft Office внесены важные структурные изменения, с которыми следует ознакомиться перед развертыванием или обновлением предыдущих версий на ферме серверов служб терминалов. В том числе стоит познакомиться с глобальным шаблоном, панелью быстрого доступа,
оснастками файла .adm для групповых политик и средством настройки Office (Office Customization Tool – OCT). Знакомство с этими средствами упростит развертывание. Начнем наш обзор существенных изменений с рассмотрения Microsoft® Word.

Развертывание Word 2007
Word всегда использовал файл глобального шаблона, и в системе 2007 Office этот файл называется normal.dotm. В среде служб терминалов возможны три различных подхода к развертыванию Word и файла normal.dotm. Можно не трогать файл на всех серверах служб терминалов, где установлен Office, так что пользователи получат стандартное представление Word по умолчанию. Можно открыть файл на каждом сервере терминалов и изменить его своими силами, внося нужные изменения, так что пользователи не получат представление по умолчанию в Word. Можно и вовсе переименовать файл, так что пользователи получат свой собственный файл (изменяющийся, когда пользователь меняет параметр в Word и нажимает на кнопку «По умолчанию»).
Какой бы выбор ни был сделан, его лучше сделать до развертывания. Если не внести изменений в стандартную настройку, у пользователей не будет возможности сохранять изменения глобального шаблона, поскольку файл глобального шаблона, находящийся на серверах служб терминалов, будет перезаписывать файлы в их индивидуальных профилях. Если не открыть файл шаблона и не внести в него поправки, Word 2007 будет представлять пользователям только параметры по умолчанию.
Возможна, однако, правка файла на каждом сервере в ферме служб терминалов, если есть такая необходимость. Чтобы пойти этим путем и поддерживать идентичные параметры Word для каждого пользователя (такие как стандартные шрифт, размер, интервал между абзацами и разметка), необходимо оставить данный файл глобального шаблона в его папке по умолчанию. Затем, чтобы изменить любые параметры, которые необходимо развернуть глобально для пользователей, будет достаточно открыть этот файл на каждом компьютере служб терминалов, внести нужные изменения в разметку Word 2007 (нажав на кнопку «По умолчанию») и сохранить их, записывая тем самым изменения в стандартный файл normal.dotm.
Не забудьте сохранить копию изначального файла перед внесением изменений, в противном случае, чтобы получить его обратно, может потребоваться переустановка Word 2007. Обратите внимание, что при внесении изменений в панель быстрого доступа при правке файла normal.dotm эти изменения не будут сохранены в файле шаблона. Я кратко расскажу о панели быстрого доступа и ее поведении чуть ниже.
Что если нужно предоставить пользователям возможность управлять собственными глобальными параметрами внутри Word? Это возможно, но требует переименования файла normal.dotm во что-нибудь вроде normal.dotm.old на всех серверах в ферме. Я рекомендую этот путь как лучший, поскольку пользователи могут столкнуться с ошибками шаблона при закрытии Word, если шаблон открыт другими приложениями.
Если переименовать этот файл, Word 2007 учтет, что пользователям надо предоставить возможность управлять их собственными параметрами вместо установки глобальных параметров и, как следствие, позволит им изменять и сохранять свои параметры. Word 2007 теперь помещает индивидуализированный файл normal.dotm по пути профиля каждого пользования. При использовании перемещаемых профилей (в зависимости от того, как устанавливать пути) файл шаблона сохраняется для каждого пользователя в следующей папке: \\domain\sharename\%username%\Application Data\Microsoft\Templates.
Предпочтительными параметрами одного пользователя, не сохраняемыми в файле normal.dotm, являются изменения, внесенные в панель быстрого доступа . Эта панель является новой функцией выпуска 2007 системы Office, отдельной от основной панели-ленты (также новой). Панель быстрого доступа – это крохотная панель, по умолчанию расположенная в верхнем левом углу экрана системы 2007 Office. Эта панель существует для приложений внутри выпуска 2007 системы Office, как показано на рис. 1. Дополнительные сведения приведены на странице support.microsoft.com/kb/926805.
Figure 1 Файлы панели быстрого доступа (Close Figure 1)

Приложение Office | Область функции | Имя файла
Access 2007 | Все | Access.qat
Excel 2007 | Все | Excel.qat
Outlook 2007 | Контакты Календарь Список рассылки Запись в журнале Почта Поместить в папку Задачи | Olkaddritem.qat Olkapptitem.qat Olkdistitem.qat Olklogitem.qat Olkmailitem.qat Olkpostitem.qat Olktaskitem.qat
PowerPoint 2007 | Все | PowerPoint.qat
Word 2007 | Все | Word.qat
Как можно увидеть на рис. 1, панель быстрого доступа использует файлы с расширением .qat для хранения индивидуализированных параметров. Файлы не перемещаются и хранятся в следующей папке на каждом сервере служб терминалов в ферме: C:\Documents and Settings\<username>\Local Setting\Application Data\Microsoft\Office (или C:\Users\<username>\AppData\Local\Microsoft\Office на компьютере, использующем Windows Vista®).
Если внимательно рассмотреть путь, можно заметить, что файлы .qat расположены в подпапке Local Settings («Локальные параметры») локально кэшированного профиля пользователя служб терминалов. Эта подпапка не синхронизируется с перемещаемым профилем пользователя при выходе из системы, поскольку папка Local Settings не существует в стандартной структуре пути перемещаемого профиля. Увы, это ведет к тому, что если выкинуть локально кэшированные профили на серверах служб терминалов, включив данный параметр объекта групповой политики (Group Policy Object – GPO), будут утрачены индивидуализированные файлы .qat пользователей (дополнительные сведения приведены в статье базы знаний на support.microsoft.com/kb/274152).
Но факт состоит в том, что удаление кэшированных профилей широко практикуется администраторами служб терминалов с целью реорганизации локальных профилей при выходе пользователя из системы, так что это изменение в системе 2007 Office существенно, поскольку затрагивает как кэшированные профили, так и панель быстрого доступа. Одно из очевидных решений – позаботиться, чтобы параметр объекта GPO, о котором рассказывается в только что упомянутой статье базы знаний, не был установлен. Если удаление кэшированных профилей при выходе из системы не включено, а пользователей много, то будет расходоваться ценное место на локальном диске %systemroot% каждого из серверов служб терминалов, и для отслеживания этого придется установить какой-либо другой процесс, иначе сервер может израсходовать все доступное пространство. Это довольно обычно, поскольку локальные профили могут сильно разрастись.
Какой бы подход ни был выбран, следует, как минимум, добавить подпрограмму к сценарию входа в систему с целью выполнения периодического резервного копирования файлов .qat пользователей, чтобы их можно было восстановить при исчезновении или случайном удалении. Храня резервные копии этих файлов, можно избежать отчаянных звонков в местную службу поддержки за помощью по их восстановлению.
Слишком мало администраторов служб терминалов создают резервные копии этих локально кэшированных профилей, вместо этого они копируют перемещаемые по сети профили, которые, как я уже упомянул, не содержат копий файлов .qat. Другой альтернативой является подбор программного продукта от стороннего производителя, позволяющего развернуть обязательный профиль для каждого пользователя, а затем перенести изменения локальных параметров каждого пользователя в отдельную папку в сети.

Оснастки групповых политик
Уже в течение некоторого времени существуют файлы групповых политик .adm для Office 2003, обеспечивающие улучшенный административный контроль над политиками Office и обслуживанием пользователей. Аналогично, в выпуске 2007 системы Office существуют новые файлы .adm, которые можно использовать для выполнения ряда личных настроек, включая отключение диалогового окна первого запуска, изменение параметров автосохранения и другие предпочтения.
Если групповые политики Office 2003 уже развернуты в момент перехода на выпуск 2007 системы Office, в первую очередь следует удалить существующие файлы .adm Office 2003 из объектов GPO, а лишь затем добавлять файлы .adm системы 2007 Office. Не забудьте создать резервную копию своих объектов GPO, используя интерфейс консоли управления групповыми политиками (Group Policy Management Console – GPMC), чтобы в случае возникновения ошибок после добавления новых оснасток можно было вернуться к исходному состоянию. Я знаю как минимум про одного администратора служб терминалов, столкнувшегося с фантомными записями политик, созданными удалением оснасток Office 2003 с последующем добавлением файлов .adm выпуска 2007 системы Office в свои объекты GPO.
Как я упомянул в своей статье «A Guide to Deploying Terminal Services» («Руководство по развертыванию служб терминалов») (technetmagazine.com/issues/2007/05/TerminalServices) за май 2007 года, пользователей служб терминалов не следует запрашивать о необходимости выполнить некоторые действия, такие как автоархивация Outlook® или допуск диалоговых экранов «Первый запуск». Стоит помнить, что по умолчанию, при первом запуске Outlook 2007, пользователям предоставляется два экрана «Первый запуск»: первый для параметров конфиденциальности, а второй для поиска на рабочем столе. Первый экран, показанный на рис. 2, можно отключить несколькими способами: изменив параметры объекта GPO (используя новые файлы .adm Outlook 2007) при помощи средств настройки Office или внеся поправки в реестр.
Рис. 2 Диалог параметров конфиденциальности в системе 2007 Office
Рис. 2 Диалог параметров конфиденциальности в системе 2007 Office
Экран, показанный на рис. 3, появляется немедленно после экрана параметров конфиденциальности (если последний не отключен) и во всех прочих приложениях выпуска 2007 системы Office.
Рис. 3 Диалог функции мгновенного поиска в выпуске 2007 системы Office
Рис. 3 Диалог функции мгновенного поиска в выпуске 2007 системы Office
Чтобы отключить запрос Windows® Search для приложений Office, загрузите шаблоны ADM для системы 2007 Office со страницы go.microsoft.com/fwlink/?LinkId=78161 и поместите их на жесткий диск контроллера домена. В папку «Групповая политика» необходимо загрузить шаблон Office Outlook 2007 (Outlk12.adm) – в «Конфигурация компьютера» или «Конфигурация пользователя», «Добавление оснастки». Далее, перейдите на Конфигурация пользователя\Административные шаблоны\Microsoft Office Outlook 2007\Tools | Параметры\Предпочтения\Параметры поиска и включите параметр "Prevent Installation prompts when Windows Desktop Search component is not present" («Не выдавать запросов о установке, если отсутствует компонент Windows Desktop Search»).
В выпуске 2007 системе Office имеется много параметров групповой политики, предназначенных для управления обслуживанием пользователя, но файлы .adm для каждой из них, такие как файлы политик Word (Word12.adm) и Excel® (Excel12.adm), надо будет добавить к объектам GPO. На рис. 4 показан пример того, как выглядит шаблон ADM Outlook 2007 (Outlook12.adm) после добавления к групповой политике.
Рис. 4 Шаблон ADM Outlook 2007 в групповой политике
Рис. 4 Шаблон ADM Outlook 2007 в групповой политике

Дополнительные изменения
Обратите внимание, что в Office 2003 можно также загрузить и использовать мастер настройки пользователей для создания пользовательских преобразований. Новый OCT в системе 2007 Office не требует отдельной загрузки. Он запускается путем использования "Setup /admin" из команды «Выполнить», выполняемой для на носителя или источника установки выпуска 2007 системы Office. При выполнении этой команды на исходных файлах установки с последующим изменением индивидуальных параметров по выбору создается файл .msp (а не файл .mst, как в Office 2003), при этом следует указать любые параметры командной строки, которые следует включить в последующее развертывание. Автоматическое развертывание настроенного по выбору файла .msp вместе со всеми нужными параметрами выполняется простом помещением его в папку Updates («Обновления») в корень точки сетевой установки.
У Outlook 2007 есть еще одно преимущество перед предыдущими версиями: он автоматически обнаруживает серверы Exchange 2007, посылая запрос точки подключения службы (Service Connection Point – SCP) напрямую Active Directory® при запуске внутри локальной сети. Этот запрос позволяет легко подключить его к развернутой инфраструктуре Exchange 2007. Дополнительные сведения приведены на странице go.microsoft.com/fwlink/?linkid=76177.
Корпорация Майкрософт внесла некоторые значительные структурные изменения в методы работы выпуска 2007 системы Office в среде служб терминалов, упростив ее средства развертывания, добавив новые оснастки в форме файлов .adm и оптимизировав интерфейс. Ознакомление с некоторыми из вышеизложенных ключевых концепций перед развертыванием или обновлением приложений Office позволяет достичь существенно лучшего знакомства с сутью обновления, позволяя заранее принять важные решения по проекту. Если немедленное обновление не планируется, можно подумать о том, чтобы просто загрузить пакет совместимости Compatibility Pack для выпуска 2007 системы Office, чтобы пользователи могли открывать прикрепленные файлы, отправленные им теми, кто уже выполнил обновление Пакет совместимости можно найти на go.microsoft.com/fwlink?LinkID=77512.
Владение этой информацией позволяет приготовиться к успешному развертыванию выпуска 2007 системы Office. Не забывайте создавать резервные копии своих политик и тестировать все рекомендуемые параметры в лабораторной среде перед развертыванием их в своем сообществе пользователей.

Джеймс Д. Салливан, обладатель сертификата MCSE, – технолог, специализирующийся на продуктах корпорации Майкрософт, а конкретнее на развертывании служб терминалов. В настоящий момент он работает на поставщика услуг ASP, занимаясь разработкой ИТ-решений для малого бизнеса. Связаться с ним можно по адресу jsilliman@gmail.com.


 От редактора: Борьба с информационной перегрузкой
От редактора
Борьба с информационной перегрузкой
Джошуа Хоффман (Joshua Hoffman)

Когда я думаю о двух наших основных темах в этом месяце (SharePoint и Office Communications Server), меня отнюдь не удивляет, что у нас часто возникают проблемы с донесением своих мыслей до коллег и окружающих. Видите ли, в тот момент, когда я пишу эту заметку (приблизительно за месяц до того как ее увидят читатели), Нью-Йорк находится в предельном праздничном режиме. И так уж вышло, что редакция журнала TechNet Magazine находится в эпицентре нью-йорскских праздников: Рокфеллеровском Центре. Во многих отношениях это просто чудесный район города, но каждый год жить в нем примерно на месяц становится... ну, скажем так, проблематично. Население разрастается (сильнее обычного) за счет туристов со всей страны и из-за границы, желающих закупиться, посмотреть шоу или покататься на коньках на фоне величественных небоскребов. Многие нью-йоркцы, однако, разбегаются кто куда.
Некоторые заявляют, что причиной тому раздражение туристами, которые останавливаются посреди тротуара, чтобы сделать снимок, вынуждая тех, кто за ними, остановиться или врезаться в них. Но это не так (правда, мы рады, что вы здесь – щелкайте, сколько хотите). Я думаю, что это просто перегрузка. Посреди и так уже многолюдных, спешащих по своим делам толп туристы становятся последней каплей.
Помня это, я бросаю взгляд на нашу отрасль и вижу во многом подобную тенденцию. Наши организации продолжают расти (на что мы, вероятно и надеемся), вследствие чего мы создаем все больше и больше информации изо дня в день. Наши общие файловые ресурсы забиты. Наши базы данных забиты. Про электронную почту и говорить не стоит. Не так уж давно гигабайт был значительным объемом информации. Сегодня обычными являются терабайты – даже в домашних ПК. Многие центры данных в наше время планируются с расчетом на петабайты. Думаю, все согласятся с тем, что нас окружает масса информации. Но полезная ли это масса или просто подавляющая? Структурирована ли она? Просто ли ее анализировать? Просто ли использовать ее совместно?
И опять, учитывая подавляющий объем информации, я не удивлен тем, что нам сложно доносить свои мысли друг до друга. Но это может стать куда проще, о чем мы и рассказываем в этом месяце. Внутри этого выпуска можно узнать, как поставить себе на службу возможности SharePoint, чтобы сделать сбор данных в своей компании проще и организованнее. Узнайте, как быстро составлять опросы для сбора данных от пользователей (или клиентов). Узнайте, как определять нестандартные типы содержимого, что позволит сделать собранную информацию куда более осмысленной. И наконец, узнайте, как использование Office Communications Server может позволить доносить информацию до других в нужный момент. В конце концов, что толку в данных, если ими не с кем поделиться? Джошуа Хоффман (Joshua Hoffman)

Мы хотели бы поблагодарить следующих технических специалистов корпорации Майкрософт: Эда Банти (Ed Banti), Сьюзен Брэдли (Susan Bradley), Байрона Хайнса (Byron Hynes), Майкла Мёрголо (Michael Murgolo), Кена Оайна (Ken Oien), Джима Трухера (Jim Truher) и Кэя Анкрота (Kay Unkroth).


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

Доступность службы установщика ActiveX
Я прочитал статью за июль 2007 " Служба установщика ActiveX в Windows Vista " (в Интернете technetmagazine.com/issues/2007/07/AxIS). Скажите, пожалуйста, доступна ли теперь эта служба?
—Юджин И. (Eugene Y.)

Да, теперь служба установщика ActiveX® доступна. Ее нетрудно включить с помощью параметра "Включение и отключение компонентов Windows" на панели управления Программы и компоненты в Windows Vista®.
Служба установщика ActiveX – дополнительный компонент только в выпусках Windows Vista Ultimate, Enterprise и Business. Список узлов, позволяющих устанавливать ActiveX с помощью службы установщика контролируется через групповую политику. Список хранится в разделе Конфигурация компьютера | Административные шаблоны | Компоненты Windows | Служба установщика ActiveX редактора объектов групповой политики.

Инструменты Active Directory
Большое спасибо за статью "11 незаменимых средств управления Active Directory " (сентябрь 2007). Я пытался удалять пользователей из Active Directory® с помощью служебной программы dsrm, описанной в статье, применяя следующую команду:
          dsquery user -samid <samid> | dsrm
Я получаю сообщение об ошибке, что ввод "dsrm" имеет неправильный формат. Однако, выполнить команду отдельно удается без проблем. В чем дело?
—Кейт Е. (Keith E.)

Мы передали Ваш вопрос автору этой статьи, Лоре Хантер (Laura Hunter). Лора отмечает, что при направлении результатов запроса dsquery в dsrm, dsrm требует переключателя -noprompt. Таким образом, нужно использовать такую командную строку:
dsquery user -samid <samid> | dsrm -noprompt
Мы сожалеем, что эта информация не попала в исходную статью; версия в Интернете будет исправлена.

Различные решения головоломки
Я думаю, вы понимаете, и другие наверняка уже на это указывали, Головоломка-сценарий доктора Скрипто (ноябрь 2007) успешно решается двумя различными способами. Головоломка соберется правильно, если 4-символьная переменная в первой и второй строках будет nnde, а 5-символьная в третьей и пятой строках – iamex. (Я согласен, что разница невелика, а имена в вашем решении делают сценарий более удобочитаемым.)
Спасибо за интересную головоломку, мне понравилось.
—Стэн А. (Stan A.)

Благодарим за ваш вариант решения, Стэн! Мы рады, что вам нравятся новые головоломки авторов сценариев, и с удовольствием сделаем их регулярным разделом журнала TechNet Magazine.

Решение о переходе на Windows Vista
Статья " Новые возможности работы с автономными файлами в Windows Vista" в выпуске журнала TechNet Magazine за ноябрь 2007 (по адресу technetmagazine.com/issues/2007/11/Offline) очень хорошо демонстрирует преимущества Windows Vista в сфере работы с автономными файлами. Эта статья помогла нам принять решение о переходе на Windows Vista, так как у нас были проблемы с автономными файлами при использовании Windows® XP Professional.
—Дэниел З. (Daniel Z.)

Спасибо, Дэниел! Приятно узнать, что статья пригодилась вашей организации.

Пропущенные страницы
Ваш журнал содержателен и интересен. Но в моем экземпляре выпуска за декабрь 2007 не было страниц 49-64. Я хотел прочесть статью о компьютерных расследованиях ("Руководство по основам расследований на компьютерах ") Тома Кловарда (Tom Cloward) и Фрэнка Сайморджей (Frank Simorjay), которая должна была быть на странице 60. Может быть, ваша группа расследований в области печати может найти потерянные страницы? Если эта статья есть в Интернете, я с удовольствием прочту ее там, если вы вышлете мне URL.
—Дейв С. (Dave S.)

К сожалению, у нас действительно были проблемы с печатью выпуска за декабрь 2007; в результате читателям было отправлено несколько экземпляров без страниц 49-64. Команда журнала TechNet Magazine и наша типография приносит свои искренние извинения за доставленные неудобства.
Статья, о которой Вы говорили, как и весь остальной декабрьский выпуск, доступны в Интернете по адресу technetmagazine.com/issues/2007/12.


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

Разблокировка файлов
Unlocker
ccollomb.free.fr/unlocker
Это уже бывало с каждым из нас – какой-нибудь автоматизированный процесс зависает на середине операции, к файлу прилипает блокировка записи, в результате чего другая операция терпит сбой из-за неспособности скопировать, переместить или удалить файл. И порой совершенно непонятно, кто виновен в поддержании блокировки, зато известно, какой файл был заблокирован. Так что же делать?
Есть много способов выйти из такой ситуации. Включая бесплатное средство Unlocker («Разблокировщик»), предоставляющее простое и быстрое, интегрированное с Windows® решение проблем блокировки файлов, которое написал Седрик Колломб (Cedrick Collomb). Благодаря его интеграции с проводником Windows виновника блокировки можно найти. просто щелкнув правой кнопкой мыши заблокированный файл (или даже набор файлов) и выбрав Unlocker из контекстного меню. Затем, в случае обнаружения блокировки, можно выбрать один из нескольких вариантов, включая снятие виновного процесса, разблокировку файла (с закрытием дескриптора), удаление файла, его перемещение или переименование. Заблокированный файл можно также переместить в его текущем состоянии.
Unlocker обладает полноценной программой установки, устраняющей необходимость регистрировать или удалять какие бы то ни было библиотеки DLL вручную, и его запуск не требует перезагрузки системы. Он также поддерживает автоматическое уведомление об обновлениях (если пользователя не волнует, что он будет время от времени «звонить домой») с целью гарантировать наличие последней версии.
Unlocker даже поддерживает исполнение из командной строки, что сильно помогает при автоматизации. Это, для примера, означает возможность легко настроить процесс доставки журнала на автоматическое закрытие дескриптора и ликвидацию процесса сжатия в случае обнаружения заблокированного файла .zip при попытке доставить журналы, возможно, спасая пользователя от необходимости вскакивать ни свет ни заря, чтобы исправить проблему вручную.
Данная служебная программа также имеет средство панели задач, именуемое Unlocker Assistant («Помощник разблокировщика»). Оно может автоматически запустить интерфейс Unlocker при попытке переместить переименовать или удалить заблокированный файл, экономя пользователю несколько щелчков на обнаружение файла и выбор Unlocker из контекстного меню правой кнопки. Unlocker совместим с большинством версий Windows, включая Windows Vista®.

Цена: Распространяется свободно
С помощью Unlocker можно быстро находить и разблокировать заблокированные файлы
С помощью Unlocker можно быстро находить и разблокировать заблокированные файлы

Анализ сетевого трафика
Wireshark
wireshark.org
Хороший анализатор сетевых протоколов позволяет добраться до основ сетевого трафика на конкретной инфраструктуре, чтобы увидеть, что на деле происходит подо всеми слоями взаимосвязанных приложений. Вероятно, наиболее известным из анализаторов с открытым исходным кодом является Wireshark, использующий открытую библиотеку записи пакетов WinPcap для Windows и являющийся наследником такого продукта, как Ethereal. Его созданием также руководил Джеральд Комбс (Gerald Combs).
С помощью Wireshark можно без труда записывать трафик, проходящий через сетевой интерфейс, и подробно исследовать каждый пакет в несложном графическом интерфейсе. Запуск нового сеанса записи пакета требует всего лишь выбора интерфейса и нажатия на кнопку пуска. Графический интерфейс пользователя отображает записанные пакеты в ячейках в условных цветах, детально описывающих время, источник, цель, протокол и предварительно определенное описание события почти в реальном времени. При выборе передачи выделяется определенная деталь и интерпретируются пакетные данные в легко отслеживаемую панель подробностей. Под ней можно увидеть необработанные пакетные данные в шестнадцатеричном формате и ASCII.
После того, как получен необходимый для анализа набор данных, можно также сохранить или экспортировать сеанс для последующего анализа Средство Wireshark может декодировать много различных протоколов и должно удовлетворить большинство потребностей в области устранения неполадок.
Сети кишат данными, и для того, чтобы помочь в отборе среди них нужных, это приложение обладает превосходной возможностью фильтра, основанного на выражениях и позволяющего сузить область поиска по каждому параметру протокола. Например, можно отсеивать весь трафик, кроме относящегося к получаемому и отправляемому BitTorrent на определенный IP-адрес в сети. Также фильтры могут позволить с легкостью вынюхивать компьютеры, сеющие хаос в сети путем рассылки гор фиктивных вещательных сообщений.
Интерфейс также позволяет без труда помечать флажками пакеты данных, которые следует обозревать, и устанавливать специальное сообщение как ссылку на время записи. Одной из моих любимых функций Wireshark является возможность отслеживать поток TCP, выбирая соответствующий вариант в контекстном меню, появляющемся при щелчке пакета TCP правой кнопкой мыши. В результате выводится окно с отформатированным отображением содержимого потока TCP в условных цветах, что очень помогает в обнаружении ошибок веб-приложений, фальшивых заголовков HTTP и других проблем связи по TCP, с которыми можно столкнуться. Отсюда можно быстро распечатать или сохранить диалог для последующего изучения или демонстрации.
Здесь я набросал только контуры возможностей этого приложения. Wireshark выпущен под лицензией GPL; помимо версии для Windows, он также содержит скомпилированные двоичные файлы для большинства версий Linux и FreeBSD.

Цена: Распространяется свободно
Wireshark позволяет анализировать завершенные сетевые протоколы
Wireshark позволяет анализировать завершенные сетевые протоколы

Подкрепите Windows PowerShell
PowerShell Community Extensions
codeplex.com/PowerShellCX
Те, кто имел возможность как следует поработать с Windows PowerShellTM, вероятно, заметили несколько повторяющихся шаблонов исполнения, для которых не помешало бы иметь командлет или псевдоним. С этой целью группа пользователей и поборников Windows PowerShell из сообщества, посвященного открытому коду, создала проект PowerShell Community Extensions («Расширения PowerShell от сетевого сообщества»), помещающий наиболее желанные функции в распространяемый набор командлетов, псевдонимов, средств доступа, функций, фильтров и сценариев
Среди командлетов, вошедших в пакет, находятся Get-Clipboard и Write-Clipboard, которые позволяют добавлять и извлекать данные буфера обмена. В то же время, Get-DomainController получает список доступных контролеров домена в текущем домене, а Write-GZip и Write-Zip позволяют записывать файлы GZIP или ZIP.
В Windows Vista или Windows Server® 2008 теперь можно создать новую символическую связь или точку соединения, с помощью New-Symlink и New-Junction соответственно. Тут имеется полезный поставщик DirectoryServices, дающий доступ к серверам LDAP, таким как Active Directory®, и AssemblyCache, делающий возможным доступ к глобальному кэшу сборок Microsoft .NET Framework и сборкам внутри него.
Также здесь есть ряд отличных сценариев. Сценарии Set-Writable и Set-ReadOnly позволяют быстро изменить состояние файла «только для чтения». Get-Url создает WebRequest и возвращает WebResponse в виде строки, а Export-History сбрасывает журнал команд в файл .clixml для последующего повторного использования. Теперь можно перехватывать информацию о использовании диска посредством сценария Get-DiskUsage и даже заставить свой компьютер заговорить с помощью забавной команды Out-Speech. Пакет включает немало и других полезных функций, таких как Quote-List, экономящий время при вводе в командную строку и Add-PathVariable, который может добавить набор путей к указанной среде.
Этот проект добавляет весьма полезный набор расширений к стандартной среде Windows PowerShell. Ну а что касается крутых знатоков Windows PowerShell, то я убежден, что в проекте найдется место их собственному вкладу.

Цена: Бесплатная программа
PowerShell Community Extension предоставляет часто запрашивавшиеся функции
PowerShell Community Extension предоставляет часто запрашивавшиеся функции

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


 Вопросы и ответы по SQL : Некластеризованные индексы и сохранение полномочий
Вопросы и ответы по SQL
Некластеризованные индексы и сохранение полномочий
Салим Хакани (Saleem Hakani) and Дэн Каролло (Dan Carollo)

Некластеризованные индексы и области их применения
В: Что такое некластеризованные индексы? Каковы преимущества и недостатки их использования?
О: Некластеризованный индекс подобен указателю в конце книги. Вся информация, содержащаяся в книге, представлена в указателе по разделам вместе с адресами в форме номеров страниц, указывающих на одну или несколько частей книги, где ее можно найти. Вдобавок, данные в книжном указателе перечислены не в том порядке, в котором они появляются в тексте книги. Таковы же и некластеризованные индексы. При наличии кластеризованного индекса на таблице можно определить порядок элементов. В ином случае нет способа убедиться, каким будет этот порядок.
Кроме того, у некластеризованных индексов есть два ограничения: в индекс могут быть включены только 16 столбцов, и максимальный размер ключа индекса не может превышать 900 байтов. Так что это значит? Давайте взглянем, что произойдет, при попытке проиндексировать следующие столбцы в таблице Movie из примера базы данных MovieList: MovieTitle NVarchar(50), DirectorName NVarchar(50), ShortStory NVarchar(400).
Предположим, что для создания таблицы выдается следующий оператор:
Use MovieList;
CREATE INDEX Movie_IDX ON Movie(MovieTitle, DirectorName, ShortStory);
При этом появится следующее сообщение об ошибке: «Предупреждение! Максимальная длинна ключа равна 900 байтам. Индекс 'Movie_IDX' имеет максимальную длину 1000 байтов. Для некоторых комбинаций больших значений операция вставки/обновления закончится сбоем." Будет выдано приведенное выше сообщение, поскольку тип данных "nvarchar" расходует 2 байта на каждый символ, и индекс, содержащий три предыдущих столбца, выйдет за лимит в 900 байтов.
После выпуска SQL Server® 2005 появилась возможность преодолеть эту проблему путем добавления столбцов к предложению INCLUDE. Это очень полезная функция, если необходимо преодолеть ограничения и по размеру и по столбцам. Все это можно сделать, выполнив следующий оператор:
CREATE INDEX Movie_IDX ON Movie(MovieTitle, DirectorName) INCLUDE (ShortStory);
Важно помнить, что при использовании предложения INCLUDE в ходе создания индекса механизм СУБД не рассматривает неключевые столбцы при вычислении числа ключевых столбцов индекса или размера ключа индекса.
Более полезную информацию о некластеризованных индексах можно найти на страницах "Non-clustered Indexes" («Некластеризованные индексы») на msdn2.microsoft.com/aa174537 и "Using Non-clustered Indexes" («Использование некластеризованных индексов») на msdn2.microsoft.com/aa933130. Советы по оптимизации индексов приведены на странице sql-server-performance.com/optimizing_ indexes.asp.

Сохранение данных полномочий
В: Как можно избежать потери полномочий при повторной инициализации подписки? Я несколько раз сталкивался с проблемой потери всех данных полномочий при повторной инициализации снимка.
О: По умолчанию, все объекты в базе данных подписки сбрасываются и создаются заново при повторной инициализации подписки. Но из этой ситуации можно выйти двумя способами.
Во-первых, можно заново применить все полномочия после повторной инициализации. При установке полномочий вручную следует внести все полномочия уровня объекта/оператора в сценарий и сохранить их отдельно так, чтобы их можно было немедленно применить после повторной инициализации подписки.
Во-вторых, можно настроить подписку, чтобы она не сбрасывала объекты при повторной инициализации. Чтобы сделать это, можно использовать системную хранимую процедуру SP_CHANGEARTICLE с целью настройки значения PRE_CREATION_CMD для параметра @PROPERTY и значения NONE, DELETE или TRUNCATE для параметра @Value.
Кроме того, в диалоговом окне «Свойства статьи» в разделе конечного объекта следует выбрать значение "Keep existing object unchanged, delete data. If article has a row filter, delete only what matches the filter. Truncate all data in the existing object.". «Оставить существующий объект без изменений, удалить данные. При наличии фильтра строк удалить только совпадающие с фильтром. Усечь все данные в существующем объекте.» Не забудьте испытать это в тестовой среде, а при необходимости дополнительных пояснений ознакомьтесь с последней версией электронной документации по SQL Server на предмет свежих сведений.

Салим Хакани (Saleem Hakani) – старший инженер по базам данных, старший специалист по решению проблем и руководитель всемирного сообщества Microsoft SQL Server, обладающий 14-летним стажем в области систем баз данных. Он ведет внешний веб-узел сообщества SQL Server sqlcommunity.com , связаться с ним можно по адресу Saleem@sqlcommunity.com.
Дэн Каролло (Dan Carollo) – инженер-эксплуатационник и администратор базы данных SQL Server, работающий с группой изучения вредоносного программного обеспечения в среде Windows и реагирования на него в корпорации Майкрософт. Он является сертифицированным преподавателем Майкрософт (MCT) по SQL Server.


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

Те из читателей, кто применяют групповые политики, без сомнения, знакомы с использованием административных шаблонов для настройки операционных систем и параметров приложений. Файлы ADM, входящие в Windows® и ключевое программное обеспечение, такое как Microsoft® Office, охватывают наиболее распространенные параметры рабочего стола. Однако время от времени возникает потребность в создании собственных шаблонов ADM, включающих индивидуальные параметры. Разработка шаблонов ADM с нуля может быть тяжкой задачей, поскольку они обладают собственным уникальным синтаксисом и для создания их требуется текстовый редактор. Но благодаря времени и опыту многие специалисты в области групповых политик стали весьма умелыми в кройке собственных файлов ADM.
С появлением Windows Vista® корпорация Майкрософт поменяла формат шаблонов групповых политик на структуру, основанную на XML. Этот новый формат, именуемый ADMX, предлагает несколько преимуществ по сравнению со старыми файлами ADM, таких как многоязыковая поддержка и центральная точка хранения, в которой можно управлять всеми имеющимися шаблонами.
Это, конечно, хорошо, но как быть тем, кто хочет создавать собственные файлы ADMX, однако не знает XML? Что не менее важно, какова теперь будет судьба всех тех индивидуализированных ADM, на создание которых ушли годы? К счастью, служебная программа ADMX Migrator приходит на помощь. Это бесплатное средство, разработанное FullArmor Corporation и лицензированное Майкрософт, предлагает два ключевых преимущества: оно позволяет создавать собственные файлы ADMX и преобразовывать старые файлы ADM в ADMX.
Графический интерфейс ADMX Migrator
Графический интерфейс ADMX Migrator
Для создания шаблонов в новом формате ADMX Migrator предоставляет редактор ADMX, обладающий графическим интерфейсом – текстовый редактор больше не нужен. Шаблоны создаются с помощью выпадающих меню и раскрывающихся списков внутри аккуратного и несложного интерфейса (см. рисунок). Для начала работы выберите команду New Template («Новый шаблон»), назовите свой файл шаблона и введите категорию, по которой его классифицировать. Далее создается собственно параметр политики путем введения ключа реестра, к которому она будет прилагаться, имени значения реестра и класса, на который она будет действовать (пользователь, машина или оба). Можно также описать, что делает политика.
Когда работа закончена, сохраните новый шаблон в формате ADMX. Он сохраняется сразу как файл ADMX и файл ADML. Файл ADMX содержит собственно параметры политики, а файл ADML предоставляет информацию о политике на определенном языке. Теперь оба файла можно скопировать в нужные каталоги своего домена и включить их в групповую политику.
Те, у кого уже есть файлы ADM, вероятно, пожелают преобразовать их в ADMX, чтобы воспользоваться преимуществами нового формата. ADMX Migrator предоставляет два метода преобразования: через редактор или программу командной строки. В редакторе ADMX выберите вариант Generate ADMX from ADM («Создать ADMX из ADM»). Укажите свой файл ADM, и средство быстро преобразует его автоматически. Затем можно открыть преобразованный файл в редакторе, чтобы изучить его значения и свойства, изменяя их при желании. Командное окно ADMX Migrator несколько более замысловато и требует введения длинной командной строки для выполнении преобразований. Однако оно более гибко и включает больше вариантов, чем графический редактор.
ADMX Migrator является оснасткой консоли управления Майкрософт (MMC), так что он требует MMC 3.0 помимо Microsoft .NET Framework 2.0. ADMX Migrator работает под Windows XP SP2, Windows Server® 2003 SP1 и Windows Vista. Эту программу можно загрузить с go.microsoft.com/fwlink/?LinkId=77409.

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


 Кабельщик: Проверка подлинности в проводных сетях стандарта IEEE 802.1X
Кабельщик
Проверка подлинности в проводных сетях стандарта IEEE 802.1X
Джозеф Дэвис (Joseph Davies)
Эта статья основана на предварительной версии Windows Server 2008. Содержащиеся в ней сведения могут быть изменены.

С ростом популярности проверки подлинности IEEE 802.1X для беспроводных сетей стандарта IEEE 802.11 у сетевых администраторов возникла потребность использовать этот стандарт также и для подключений к проводным сетям. Точно так же, как беспроводный клиент, прежде чем в беспроводной сети будет получено разрешение переслать кадры данных в интрасеть, вынужден отправлять набор подвергаемых проверке учетных данных,
клиент проводной сети IEEE 802.1X должен выполнить проверку подлинности, прежде чем будет получено разрешение использовать соответствующий порт коммутатора. Проверка подлинности IEEE 802.1X обеспечивает дополнительную защитную преграду для интрасети — не прошедшие успешную проверку подлинности гостевые, мошеннические или неуправляемые компьютеры не смогут подключиться к вашей внутренней сети.
Возможно, проверка подлинности IEEE 802.1X уже поддерживается вашими проводными коммутаторами, и ее требуется всего лишь активировать и настроить. С целью проверки подлинности и авторизации проводного подключения коммутаторы, поддерживающие стандарт 802.1X, используют обычно протокол RADIUS (Remote Authentication Dial-In User Service) для передачи на сервер RADIUS данных запроса на подключение, например, на сервер политики сети (NPS — Network Policy Server), работающий под управлением Windows Server® 2008, или сервер службы проверки подлинности в сети Интернет (IAS — Internet Authentication Service), работающий под управлением Windows Server 2003.
После настройки коммутаторов для работы с протоколом RADIUS, но до того, как понадобится проверка подлинности 802.1X, придется активировть и настроить проверку подлинности 802.1X на компьютерах, входящих в проводную сеть. Проверка подлинности IEEE 802.1X для подключений к проводной сети поддерживается операционной системой Microsoft® Windows® с момента появления Windows XP. Однако в Windows XP и Windows Server 2003 необходимо вручную выполнять настройку параметров проверки подлинности 802.1X на каждом отдельном компьютере, входящем в проводную сеть (это выполняется на вкладке «Проверка подлинности» свойств сетевого подключения в папке «Сетевые подключения»). К сожалению, для этих первых операционных систем не существует способа централизованно настроить или включить в сценарий параметры для проводной сети 802.1X.
К счастью, наличие поддержки параметров проводной сети в групповой политике и поддержка сценариев, обеспечиваемая инструментом Netsh в Windows Vista® и Windows Server 2008, означают, что развертывание параметров проводной сети 802.1X стало значительно проще, чем это было раньше.

Параметры проводной сети в групповой политике
Использование службы автонастройки проводной сети
В Windows XP и Windows Server 2003 поведение 802.1X на проводных подключениях управляется службой автонастройки беспроводной связи. В этих операционных системах данная служба была активирована по умолчанию, и сетевые подключения переводились в режим пассивного прослушивания и находились в ожидании запуска проверки подлинности коммутатором.
В противополжность этому, в Windows Vista and Windows Server 2008 поведением 802.1X на проводных подключениях управляет служба автонастройки проводной сети, но она по умолчанию отключена. Поэтому вкладка «Проверка подлинности» для свойств сетевых подключений отображается только после запуска службы автонастройки проводной сети.
Для конкретного проводного клиента, работающего под управлением Windows Vista или Windows Server 2008, можно использовать оснастку служб для запуска службы автонастройки проводной сети и настройки ее на автоматический запуск при загрузке. После запуска службы автонастройки проводной сети подключения проводной сети работают в режиме активного прослушивания, при котором сетевое подключение выполняет попытку запустить проверку подлинности с использованием коммутатора.
В случае домена Active Directory для целей настройки службы автонастройки проводной сети на автоматический запуск при загрузке можно воспользоваться групповой политикой. Для использования режима автоматического запуска при загрузке выполняется настройка параметра Конфигурация компьютера | Параметры Windows | Параметры безопасности | Системные службы | Проводная автонастройка с помощью оснастки редактора управления групповой политикой.

В операционных системах Windows Server 2008 и Windows Server 2003 с целью централизации и автоматизации настройки параметров проводной сети службы домена Active Directory® в рамках групповой политики поддерживают параметры политики проводных сетей. Эти параметры позволяют настраивать параметры проводной сети как часть групповой политики конфигурации компьютера для доменного объекта групповой политики.
С помощью параметров политики проводных сетей можно указать метод проверки подлинности и другие параметры 802.1X для проводных клиентов, работающих под управлением Windows Server 2008 или Windows Vista. При присоединении к домену, при запуске или периодически после запуска эти операционные системы автоматически загружают и применяют параметры политики проводной среды. Отметим только, что для поддержки этих новых политик домен Active Directory в среде Windows Server 2003 необходимо расширить. Для получения дополнительных сведений о расширении домена Active Directory в среде Windows Server 2003 загляните в документ technet.microsoft.com/bb727029.
Настройка политик проводной сети выполняется в оснастке редактора управления групповой политикой, в узле Конфигурация компьютера | Конфигурация Windows | Параметры безопасности | Политика проводной сети (IEEE 802.3). По умолчанию не предусмотрена ни одна политика проводной сети (IEEE 802.3). Для создания новой политики щелкните правой кнопкой мыши узел политики проводных сетей (IEEE 802.3) в дереве консоли, затем выберите «Создать новую политику Windows Vista».
Диалоговое окно свойств политики проводных сетей Windows Vista содержит вкладки «Общие» и «Безопасность». На рис. 1 показан вид вкладки «Общие» по умолчанию. На вкладке «Общие» настраивается имя и описание политики и указывается, должна ли использоваться служба автонастройки проводной сети, управляющая поведением 802.1X на проводных подключениях. Для получения дополнительных сведений см. боковую панель «Служба автонастройки проводной сети» для данной статьи.
Рис. 1 Вид по умолчанию вкладки «Общие» политики проводных сетей Windows Vista
Рис. 1 Вид по умолчанию вкладки «Общие» политики проводных сетей Windows Vista
На рис. 2 показан вид по умолчанию вкладки «Безопасность» политики проводных сетей Windows Vista. На вкладке «Безопасность» можно включать или отключать проверку подлинности 802.1X, выбирать и настраивать метод проверки подлинности протокола EAP (Extensible Authentication Protocol), выбирать режим проверки подлинности (повторная проверка подлинности пользователя, проверка подлинности компьютера, пользователя или гостя), настраивать допустимое число неудачных попыток до прекращения проверки подлинности, а также указывать, требуется ли кэшировать пользовательские данные для последующих подключений. Если кэширование отключено, по выходе пользователя из системы Windows учетные данные пользователя удаляются из реестра. Результатом этого является то, что у следующего подключающегося пользователя запрашиваются учетные данные (например, имя пользователя и пароль).
Рис. 2 Вид по умолчанию вкладки «Безопасность» политики проводных сетей Windows Vista
Рис. 2 Вид по умолчанию вкладки «Безопасность» политики проводных сетей Windows Vista
При нажатии кнопки «Дополнительно» на вкладке «Безопасность» предоставляется возможность настройки дополнительных параметров для 802.1X и режима единого входа. На рис. 3 показан вид по умолчанию диалогового окна с дополнительными параметрами безопасности для политики проводных сетей Windows Vista. В диалоговом окне с дополнительными параметрами безопасности выполняется настройка параметров 802.1X, показанных на рис. 4.
Figure 4 Параметры 802.1X в диалоговом дополнительных параметров безопасности (Close Figure 4)

Параметр | Описание
Максимум сообщений EAPOL-Start | Число последовательных сообщений (EAPOL)-Start протокола EAP по сети LAN, отправленных при отсутствии ответа на первое сообщение EAPOL-Start.
Период задержки | Промежуток времени между последовательными сообщениями EAPOL-Start, отправленными при отсутствии ответа на предыдущее сообщение EAPOL-Start.
Период запуска | Промежуток времени, в течение которого выполняющий проверку клиент не выполняет никаких операций по проверке подлинности по стандарту 802.1X после получения сигнала о сбое проверки подлинности от средства проверки подлинности.
Период проверки | Промежуток времени, в течение которого выполняющий проверку клиент не выполняет никаких действий до момента повторной передачи запросов 802.1X после инициализации сквозной проверки подлинности по стандарту 802.1X.
Сообщение EAPOL-Start | Момент отправки проводным клиентом сообщения EAPOL-Start.
Рис. 3 Диалоговое окно с дополнительными параметрами безопасности для политики проводных сетей Windows Vista
Рис. 3 Диалоговое окно с дополнительными параметрами безопасности для политики проводных сетей Windows Vista
Проводные клиенты, работающие под управлением Windows Server 2008, поддерживают режим единого входа для проводных подключений. Эта возможность предусмотрена также в будущем выпуске пакета обновления 1 для Windows Vista. Дополнительные сведения доступны на на веб-узле по адресу technetmagazine.com/issues/2007/11/CableGuy.
Существуют параметры режима единого входа, позволяющие выполнять проверку подлинности 802.1X непосредственно до или сразу после входа пользователя в систему, и параметры, обеспечивающие до начала процедуры входа пользователя в систему ожидание в течение заданного количества секунд выполнения проверки подлинности 802.1X для учетных данных пользователя. Предусмотрена также возможность указать необходимость отображения диалоговых окон для проверки подлинности учетных данных пользователя после отображения полей ввода на заставке входа в Windows. Например, если типу методов EAP необходимо, чтобы пользователь подтвердил сертификат, отправленный сервером RADIUS во время проверки подлинности, тип методов EAP может отобразить диалоговое окно.
Кроме этого, предусмотрена возможность указать, что после выполнения проверки подлинности учетных данных пользователя система должна инициировать обновление протоколом DHCP конфигурации TCP/IP проводного адаптера. Этот вариант следует выбрать, если для проверки подлинности по учетным данным клиентского компьютера и пользователя используются отдельные виртуальные локальные сети (VLAN) и если такие сети VLAN являются разными подсетями IPv4 или IPv6.

Поддержка сценариев с помощью средства Netsh
Windows Server 2008 и Windows Vista поддерживают команды в контексте netsh lan средства Netsh с целью настройки параметров проводных сетей и экспорта или импорта профиля проводной сети, являющегося именованным набором параметров проводной сети в формате XML. Настройка параметров проводной сети с использованием интерфейса командной строки облегчает развертывание проводных сетей посредством создания автоматизированных сценариев для параметров проводной сети без использования групповой политики. Параметры групповой политики для политик проводных сетй (IEEE 802.3) применяются только в домене Active Directory. В среде без инфраструктуры групповой политики сценарий, автоматизирующий настройку проводных подключений посредством профиля проводной, можно запускать вручную или автоматически, включая его в виде части сценария входа в систему.
Для настройки с помощью командной строки проводных клиентов, работающих под управлением Windows Vista или Windows Server 2008, следует запустить команды netsh lan с соответствующими параметрами. Например, следующая команда активирует режим единого входа для сетевого подключения с именем «Local Area Connection» и настраивает режим единого входа для выполнения проверки подлинности пользователя до входа пользователя в систему.
netsh lan set profileparameter interface="Local Area Connection" ssomode=prelogon
Дополнитеьльные сведения о синтаксисе команд netsh lan приведены на веб-странице по адресу technet.microsoft.com/aa905084.
Средство Netsh дает возможность экспортировать из проводного клиента Windows Server 2008 или Windows Vista профили в формате XML для проводных сетей и затем импортировть их в проводной клиент Windows Server 2008 или Windows Vista. Для экспорта профиля проводной сети используется команда netsh lan export profile. Для импорта профиля проводной сети используется команда netsh lan add profile. На веб-странице по адресу msdn2.microsoft.com/aa816372 представлено несколько полезных примеров профилей проводных сетей.
Использование поддержки интерфейса командной строки и профиля в формате XML дает возможность обеспечить самонастройку проводного клиента в корпоративной проводной сети с проверкой подлинности по стандарту 802.1X. Компьютер проводного клиента, не входящий в домен, не может подключиться к проводной сети с помощью учетных данных компьютера. Кроме этого, компьютер не может присоединиться к домену до тех пор, пока он не будет подключен к проводной сети. Однако поддержка интерфейса командной строки и профиля в формате XML позволяет подключить проводной комьютер к корпоративной проводной сети с помощью учетных данных пользователя и затем подключить компьютер к домену. Дополнительные сведения приведены на веб-странице по адресу technet.microsoft.com/bb727031.

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


 Windows PowerShell: Полномочия Shell
Windows PowerShell
Полномочия Shell
Дон Джонс
Загрузить исходный код для этой статьи: PowerShell2008_02.exe (151KB)

Когда речь заходит о Windows PowerShell, меня часто спрашивают о полномочиях, особенно о том, позволяет ли оболочка автоматизировать изменения полномочий и если да, то как. Чаще всего эти вопросы относятся к полномочиям на доступ к файлам, но полномочия для каталогов и реестра также всплывают довольно часто. Что касается полномочий
и любого интерфейса командной строки либо сценариев (включая Windows PowerShellTM и VBScript), то тут у меня есть и хорошие и плохие новости.
Плохие новости заключаются в том, что полномочия Windows® сложны по своей природе, и Windows PowerShell мало что может здесь сделать. Проблема вытекает из того, что в операционной системе Windows присутствуют несколько объектов, когда речь заходит о полномочиях, рассматриваем ли мы файловую систему, Active Directory®, реестр или почти всё прочее.
Во-первых, это сам ресурс – например, объект каталога, файл или папка. Далее, это объект списка управления доступом (Access Control List – ACL), которые присоединен к ресурсу. ACL состоит из одной или нескольких записей управления доступом или объектов ACE. Элемент ACE, по сути, связывает вместе участника безопасности (пользователя или группу, то есть еще один объект) с полномочием (таким как «Чтение» или «Полный контроль») и состоянием наличия и отсутствия последнего. Это не менее пяти объектов: ресурс, ACL, ACE, участник безопасности и полномочия.
Полномочия дополнительно усложняются фактом наличия различных типов полномочий у каждого типа ресурсов. Объекты каталогов, например, имеют сложные полномочия, управляющие доступом к отдельным атрибутам объекта. По сравнению с ними полномочия на доступ к файлам относительно просты.
А с технической точки зрения все это удваивается, когда дело доходит до аудита. У каждого ресурса на деле есть два списка ACL. Во-первых, это список управления доступом на уровне пользователей (DACL), который управляет доступом к ресурсу. Но существует также список управления доступом на уровне безопасности (SACL), который контролирует аудит на ресурсе. Попытка работать с этими полномочиями означает продирание через кучу довольно хитро выглядящих программных объектов, и возможности оболочки, вроде Windows PowerShell, по упрощению этого довольно ограничены.

Ограничена .NET Framework
Полученного недостаточно?
Дополнительные материалы по Windows PowerShell, включая библиотеку командлетов с возможностью поиска, а также связь с Доном Джонсом и другими экспертами по Windows PowerShell предоставляются сообществомwww.PowerShellCommunity.org.

Суть Windows PowerShell также несколько усложняет дело. Будучи построенной на основе Microsoft® .NET Framework, Windows PowerShell использует базовые классы .NET Framework для представления полномочий и работы с ними. Эти базовые классы .NET Framework разработаны с целью предоставления разработчикам возможности детализированного и точного управления полномочиями. Конечно «детализированность и точность» подразумевает большой объем информации и часто значит «крайняя сложность».
Вдобавок, .NET Framework предоставляет классы, представляющие полномочия, не для всех типов ресурсов Windows. Например, хотя .NET Framework предоставляет классы, позволяющие управлять безопасностью файлов, она не предоставляет классов, позволяющих работать с безопасностью общих папок. Как следствие, Windows PowerShell не может управлять полномочиями на некоторых типах ресурсов Windows. Попросту говоря, Windows PowerShell ограничена возможностями, которые предоставляет .NET Framework.

Полномочия в оболочке
Управление полномочиями в Windows PowerShell вытекает из двух командлетов: Get-ACL и Set-ACL. Как можно догадаться, Get-ACL получает список ACL от ресурса. Затем список ACL можно изменить в соответствии с потребностями и использовать Set-ACL для записи его обратно на ресурс. Оба командлета являются общими и полагаются на систему поставщиков PSDrive в Windows PowerShell. Следовательно, эти два командлета ACL теоретически могут работать с любым типом ресурса при наличии поставщика PSDrive, способного понимать такой тип ресурса и изменять полномочия на нем. Поставщики PSDrive FileSystem и Registry, поставляемые в комплекте с Windows PowerShell, поддерживают управление полномочиями через два командлета ACL. (Другие поставщики PSDrive могут и не поддерживать его.)
Пример сценария, показанный на Рис. 1, позволяет определить начальный каталог, участника безопасности и полномочие. Затем сценарий применяет указанное полномочие для этого участника ко всем файлам и папкам внутри указанного каталога. Сценарий также выполняет рекурсивный просмотр подкаталогов.
Figure 1 Выдача участнику полномочия на доступ к файлам и папкам в каталоге (Close Figure 1)
#ChangeACL.ps1
$Right="FullControl"

#The possible values for Rights are
# ListDirectory, ReadData, WriteData
# CreateFiles, CreateDirectories, AppendData
# ReadExtendedAttributes, WriteExtendedAttributes, Traverse
# ExecuteFile, DeleteSubdirectoriesAndFiles, ReadAttributes
# WriteAttributes, Write, Delete
# ReadPermissions, Read, ReadAndExecute
# Modify, ChangePermissions, TakeOwnership
# Synchronize, FullControl

$StartingDir=Read-Host "What directory do you want to start at?"
$Principal=Read-Host "What security principal do you want to grant" `
"$Right to? `n Use format domain\username or domain\group"

#define a new access rule.
#note that the $rule line has been artificially broken for print purposes.
#it needs to be one line. the online version of the script is properly
#formatted.
$rule=new-object System.Security.AccessControl.FileSystemAccessRule
($Principal,$Right,"Allow")

foreach ($file in $(Get-ChildItem $StartingDir -recurse)) {
  $acl=get-acl $file.FullName

  #Add this access rule to the ACL
  $acl.SetAccessRule($rule)

  #Write the changes to the object
  set-acl $File.Fullname $acl
  }
Основная часть этого сценария – фрагмент, где он определяет новое правило доступа в переменной $rule. Чтобы сделать это, я использую «сырой» класс .NET Framework, что вероятно, является наиболее сложной частью управления полномочиями в Windows PowerShell. Затем сценарий получает список ACL от каждого файла и папки по очереди, используя Get-ACL, применяет новое правило, используя метод SetAccessRule списка ACL и записывает измененный список ACL обратно на ресурс, используя Set-ACL.
На практике это не так уж сложно, хотя более сложные операции вроде удаления элемента ACE из списка ACL, требуют большего вложения сил. По моему мнению, сложным этот процесс заставляет казаться количество этапов: получение списка ACL, определение правила, изменение списка ACL и запись списка ACL. Он не является единственной, ясной командой, делающей все сразу. А поскольку мне было нужно изменить списки ACL на нескольких файлах, все это пришлось поместить в цикл foreach, используя Get-ChildItem для реального доступа к файлам и папкам.

Мы пойдем простым путем
Командлет месяца: Get-QADUser
Данный командлет совершенно необходим при управлении Active Directory. Он не встроен в Windows PowerShell, но доступен как бесплатная загрузка в составе оболочки управления ActiveRoles Management Shell для Active Directory от компании Quest Software (www.quest.com/activeroles-server/arms.aspx).
После установки оснастки Get-QADUser можно использовать для получения объектов пользователей из каталога. Само собой, простое выполнение командлета возвращает всех имеющихся пользователей, а это не то чтобы полезно для большинства административных задач. Но командлет позволяет указать критерии фильтрации, применяемые на контроллере домена, чтобы в Windows PowerShell возвращались только нужные пользователи. Этот прием гораздо быстрее получения всех пользователей с последующей их фильтрацией посредством командлета Where-Object. Например, Get-QADUser -l Redmond вернет только тех пользователей, чей атрибут "l" содержит "Redmond". (Между прочим, атрибут "l" означает местоположение и перечислен как город в графическом интерфейсе пользователя.) Затем можно передать этих пользователей по конвейеру другим командлетам для создания отчета в формате HTML, поместить их в группу и даже удалить их.

Мои примеры не кажутся мне сложными, но я знаю, что многие администраторы предпочли бы более простой способ работы с полномочиями. Возможно, им нужно разом удалить определенную группу пользователей из набора папок, но не хочется писать многоэтапный сценарий, подобный показанному на рис. 1.
К счастью, Windows PowerShell предлагает упрощенный способ работы с полномочиями, с которым читатели, вероятно, уже знакомы.
Windows PowerShell не заставляет пользователя отказаться от его проверенных методов. Средства командной строки, такие как Dsacls.exe, Cacls.exe и Xcacls.exe, специально разработанные для упрощения работы с различными типами полномочий, по-прежнему можно использовать. Хотя их синтаксис совершенно не похож на стандартизированный синтаксис, используемый командлетам Windows PowerShell, эти служебные программы командной строки более не обязательно использовать специально подобранными для каждого случая способами, как они использовались под старой оболочкой cmd.exe. Кроме того, Windows PowerShell можно использовать для их автоматизации.
Я сталкивался с некоторыми, скажем так, пуристами, настаивающими на том, что использование старых служебных программ командной строки в Windows PowerShell отчего-то является неправильным. Я не вполне улавливаю их логику. Я рассчитываю на то, чтобы выполнять свою работу, и если простейший способ ее выполнения – использование служебной программы командной строки десятилетней давности, то её я и использую. Я не намерен тратить дополнительные часы, пытаясь проделать что-либо определенным способом, только потому, что он кажется «более чистым». Аналогично относятся к делу и разработчики Microsoft Windows PowerShell. Если существующее средство выполняет свою задачу, Windows PowerShell позволяет использовать его. Зачем изобретать велосипед?
На рис. 2 показан короткий сценарий, взятый из моей книги Windows PowerShell: TFM (изд-во SAPIEN Press, 2006 г.), который использует Windows PowerShell для автоматизации Cacls.exe. Этот сценарий является просто демонстрацией, и чтобы сделать из него реальное средство автоматизации, потребуется дополнительная работа. Но он показывает, как сценарий Windows PowerShell может собирать информацию и использовать ее для запуска Cacls.exe, как если бы Cacls.exe был «собственной» командой Windows PowerShell. (Хотя этот сценарий собирает информацию, запрашивая пользователя, параметры также можно считывать с файла или базы данных.)
Figure 2 Автоматизация Cacls.exe (Close Figure 2)
#SetPermsWithCACLS.ps1
# CACLS rights are usually
# F = FullControl
# C = Change
# R = Readonly
# W = Write

$StartingDir=Read-Host "What directory do you want to start at?"
$Right=Read-Host "What CACLS right do you want to grant? Valid choices are F, C, R or W"
Switch ($Right) {
  "F" {$Null}
  "C" {$Null}
  "R" {$Null}
  "W" {$Null}
  default {
    Write-Host -foregroundcolor "Red" `
    `n $Right.ToUpper() " is an invalid choice. Please Try again."`n
    exit
  }
}

$Principal=Read-Host "What security principal do you want to grant?" `
"CACLS right"$Right.ToUpper()"to?" `n `
"Use format domain\username or domain\group"

$Verify=Read-Host `n "You are about to change permissions on all" `
"files starting at"$StartingDir.ToUpper() `n "for security"`
"principal"$Principal.ToUpper() `
"with new right of"$Right.ToUpper()"."`n `
"Do you want to continue? [Y,N]"

if ($Verify -eq "Y") {

 foreach ($file in $(Get-ChildItem $StartingDir -recurse)) {
  #display filename and old permissions
  write-Host -foregroundcolor Yellow $file.FullName
  #uncomment if you want to see old permissions
  #CACLS $file.FullName

  #ADD new permission with CACLS
  CACLS $file.FullName /E /P "${Principal}:${Right}" >$NULL

  #display new permissions
  Write-Host -foregroundcolor Green "New Permissions"
  CACLS $file.FullName
 }
}

Успешная работа с полномочиями?
Мне приходилось слышать, что Windows PowerShell неадекватна в плане полномочий, поскольку не предоставляет собственного командлета, дающего упрощенное, универсальное управление полномочиями. Я не согласен. Во-первых, это обвинение часто выдвигается администраторами, привыкшими к UNIX, а система полномочий Windows намного более сложна, чем та, которую использует UNIX. Работа Windows PowerShell также будет непростой. Однако это не порок Windows PowerShell.
Вдобавок, Windows PowerShell позволяет использовать упрощенные средства в форме старых, добрых служебных программ командной строки, как я и показал выше. Действительно, .NET Framework требуется некоторое расширение для более полного охвата управления полномочиями в платформе Windows. Но в целом Windows PowerShell дает преимущества с обеих полюсов: упрощенное управление полномочиями вместе с доступом к детализированным и точным средствам управления.

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


 Эй, автор сценариев!: Начинаются Игры! И немножко XML заодно
Эй, автор сценариев!
Начинаются Игры! И немножко XML заодно
Программисты корпорации Майкрософт
Загрузить исходный код для этой статьи: HeyScriptingGuy2008_02.exe (151KB)

Так получается, что всякий раз, когда люди говорят о легендах спорта, все время всплывают одни те же имена: Бейб Рут. Пеле. Мохамед Али. Уолтер Пайтон. ScooterK и MrRat. Джони—
Ха, это забавно... что, вы серьезно?! Вы и в самом деле не знаете, кто такие ScooterK и MrRat? Что ж, объясняем для тех, кто не следит за зимним чемпионатом «Scripting Games» (С 15 февраля по 3 марта в Скрипт-Центре TechNet по адресу microsoft.com/technet/scriptcenter/funzone/games), ScooterK и MrRat – настоящие легенды, спортсмены, заработавшие максимальные очки по меньшей мере в одной номинации на зимнем чемпионате «Scripting Games 2007».
Теперь перейдем к удивительному: вы можете, начистоту, расчитывать стать легендой футбола, как Пеле? Вряд ли. Можете ли вы надеяться стать чемпионом мира по боксу в супертяжелом весе? Ну, некоторые авторы сценариев определенно справляются по части супертяжелого веса, но вот история с чемпионством по боксу дается с куда большим трудом. Но вы -- да, да, вы – легко можете стать следующими ScooterK или следующими MrRat.
Примечание: вообще-то, следующим Бейб Рут стать тоже можно. Все, что нужно – съедать 24 хот-дога между спаренными матчами в бейсбол.
Спокойно. Сейчас мы расскажем, как можно стать следующими ScooterK или MrRat (или даже следующими Bizzy или H2Data). Все, что нужно – зайти в Скрипт-Центр и принять участие в чемпионате «Scripting Games». 15 февраля мы опубликуем 10 разных событий (10 задач для создания сценариев) и предложим вам выполнить какие-нибудь или все из них. Напишите сценарий, решающий поставленную проблему и отправьте его нам. (Полные инструкции можно найти на главной странице чемпионата «Scripting Games».) Мы протестируем ваш сценарий и, если он работает, присудим вам очки. Выполните все 10 задач и тоже станете легендой спортивного мира. По крайней мере, мира спортивного написания сценариев, а это почти одно и то же.
Чемпионат «Scripting Games» (С 15 февраля по 3 марта) – это весело и интересно. Что самое главное, это для всех. Вы недавно взялись за сценарии системного администрирования? Начните с номинации для начинающих; у нас отдельные соревнования для начинаюших по VBScript, Windows PowerShellTM и (впервые в этом году) Perl. Номинация для начинающих кажется слишком легкой? Тогда попробуйте номинацию для профессионалов, где также есть соревнования по VBScript, Windows PowerShell и Perl.
Чемпионат (мы не забыли упомянуть, что они проходят с 15 февраля по 3 марта?) – однозначно, событие сезона сценариев, и его не стоит пропускать. Зайдите на главную страницу Скрипт-Центра, где есть подсказки и советы для тренировки перед соревнованиями, а потом приходите снова 15 февраля, когда мы официально откроем чемпионат.
С 15 февраля по 3 марта. Мало ли, вы не обратили внимания.
Что, простите? Вообще-то, мы согласны: новая статья Эй, автор сценариев! с официальным объявлением о чемпионате «Scripting Games» -- это, пожалуй, слишком круто для одного месяца. Но чтобы хорошие ребята, читающие журнал TechNet Magazine, были рады (не нужно говорить, что это главная задача нашей жизни), мы решили рискнуть и все равно ее написать.
Ровно год назад (ух ты, неужели уже так давно?) мы опубликовали статью, где объясняли, как использовать сценарий для чтения файла XML. В той статье, впрочем, не было сказано, как использовать сценарий для создания, записи и изменения файла XML. Сейчас мы исправим эту ошибку. Вы говорите, что хотите знать, как написать сценарий, создающий файл XML? Нужно было толко спросить! Что ж, спраишвайте, а потом подождите годик, пока мы соберемся. Сценарий показан на рис. 1. Нет спору, выглядит замысловато, но мы расскажем, как он работает.
Figure 1 Создание файла XML (Close Figure 1)
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

Set objRoot = _
  xmlDoc.createElement("ITChecklist")
xmlDoc.appendChild objRoot

Set objRecord = _
  xmlDoc.createElement("ComputerAudit")
objRoot.appendChild objRecord

Set objName = _
  xmlDoc.createElement("ComputerName")
objName.Text = "atl-ws-001"
objRecord.appendChild objName

Set objDate = _
  xmlDoc.createElement("AuditDate")
objDate.Text = Date
objRecord.appendChild objDate

Set objIntro = _
  xmlDoc.createProcessingInstruction _
  ("xml","version='1.0'")
xmlDoc.insertBefore _
  objIntro,xmlDoc.childNodes(0)

xmlDoc.Save "C:\Scripts\Audits.xml"
Для начала, создадим экземпляр объекта Microsoft.XMLDOM. Как вы могли догадаться, это объект, позволяющий нам работать с файлами XML. Наша задача – создать простой файл XML, вроде того, что на рис. 2.
Рис. 2 Наша цель: простой файл XML
Рис. 2 Наша цель: простой файл XML
Чтобы создать этот файл XML, нам сперва надо сделать корневой узел (ITChecklist). Как это сделать? Вот так:
Set objRoot = _
  xmlDoc.createElement("ITChecklist")
xmlDoc.appendChild objRoot
Правда, нетрудно? Все, что было нужно -- создать метод createElement, передав ему имя, которое мы хотим дать корневому узлу. Затем мы просто вызываем метод appendChild method, передавая ссылку на объект новому элементу (objRoot) как единственный параметр метода. Теперь у нас есть корневой узел.
Но это еще не все. Дальше мы создадим узел ComputerAudit node, дочерний узел узла ITChecklist, который представляет информацию для одного компьютера. Как можно видеть, код для создания этого узла похож на код для создания корневого узла:
Set objRecord = _
  xmlDoc.createElement("ComputerAudit")
objRoot.appendChild objRecord
Единственно отличие в следующем: когда мы создавали корневой узел, мы вызывали appendChild на сам документ XML. (Отметьте ссылку на объект xmlDoc.) Чтобы добавить к корню дочерний узел, мы вызываем appendChild на корневой узел (objRoot), а не на документ XML. Все просто.
Ничуть не сложнее добавить в качестве дочерних узлов ComputerAudit узлы ComputerName и AuditDate. Для этого проделаем сходную процедуру: вызовем для создания нового узла createElement, а затем вызовем appendChild, чтобы прикрепить этот новый узел к файлу.
(Проверь себя: Где мы вызывали последнее время appendChild? Совершенно верно: из objRecord, материнского узла (ComputerAudit), который мы только что создали.)
Да, так как узлы ComputerName и AuditDate должны содержать значения, важно указать значение свойства Text каждого из этих узлов, прежде чем добавлять их к документу.
Все станет ясно, если взглянуть на код, который создает узел ComputerName:
Set objName = _
  xmlDoc.createElement("ComputerName")
objName.Text = "atl-ws-001"
objRecord.appendChild objName
Как нетрудно догадаться, код для создания AuditDate практически идентичен. Нужно только лишь указать другое имя узла, вызывая createElement и определить другое значение свойства Text.
Не слишком ли легко все получается, народ?
Закончив создавать узлы для нашей первой (а в данном случае, и последней) записи, мы выполним вот этот славный кусочек кода:
Set objIntro = _
 xmlDoc.createProcessingInstruction _
  ("xml","version='1.0'")
xmlDoc.insertBefore _
  objIntro,xmlDoc.childNodes(0)
Он просто вставляет тег <?xml version="1.0" ?> в начало файла, чтобы получился XML-документ правильного формата.
Теперь все, что нам осталось сделать, это вызвать метод Save и сохранить наш новый файл как C:\Scripts\Audits.xml:
xmlDoc.Save "C:\Scripts\Audits.xml"
Вот и все! Мы получили новенький, с иголочки, документ XML.
Что ж, это очень полезно: теперь вы знаете, как сделать совершенно новый файл XML с помощью сценария. Конечно, велика вероятность, что по большей части вам не нужно создавать новехонькие файлы XML, а, скорее, вам захочется добавлять новые данные в существующий файл. Покажут ли авторы сценариев всему миру, как это сделать?
Знаете, сначала мы решили, что ответ будет «нет». Нет, мы не будем показывать, как добавлять данные в существующий файл XML. Но ведь мы добрые и щедрые люди, и мы решили попробовать заключить с читателями журнала TechNet Magazine сделку: если все, кто читает этот журнал, согласятся принять участие в зимнем чемпионате «Scripting Games 2008», тогда, так и быть, мы покажем вам всем, как с помощью сценария добавить данные в файл XML. Ну, все согласны участвовать в чемпионате «Scripting Games?»
Эй, мы тебя ждем. Да, да, тебя – парень в Химках, МО.
Вот, это совсем другое дело. И поверьте нам, вам понравится на чемпионате «Scripting Games»; всем всегда нравится. Мы обещаем.
А теперь, так как слово надо держать, мы покажем вам сценарий, который может добавлять данные в существующий файл XML. Взгляните на рис. 3.
Figure 3 Добавление в файл XML (Close Figure 3)
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

xmlDoc.Async = "False"
xmlDoc.Load("C:\Scripts\Audits.xml")

Set objRoot = xmlDoc.documentElement

Set objRecord = _
  xmlDoc.createElement("ComputerAudit")
objRoot.appendChild objRecord

Set objFieldValue = _
  xmlDoc.createElement("ComputerName")
objFieldValue.Text = "atl-ws-100"
objRecord.appendChild objFieldValue

Set objFieldValue = _
  xmlDoc.createElement("AuditDate")
objFieldValue.Text = Date
objRecord.appendChild objFieldValue

xmlDoc.Save "C:\Scripts\Audits.xml"
Как видно, он не так уж ужасно отличается от сценария, который создал файл XML. Мы начинаем с создания экземпляра объекта Microsoft.XMLDOM, затем присваиваем свойству Async значение False, которое говорит сценарию, что мы хотим загрузить документ синхронно, а не наоборт. Что нам это дает? Ну, если бы мы загрузили докмент асинхронно, сценарий мог бы продолжать, даже если бы документ загрузился не полостью. Не нужно объянять, что в спешке можно наломать дров, если попытаться выполнить задачу с документом, который еще не существует. Убедившись, что наш файл XML загружается синхронно, мы обеспечиваем полную загрузку файла перед тем, как сценарий продолжит работу.
И кстати о полной загрузке – впрочем, ладно, в другой раз. Лучше мы вызовем метод Load, чтобы открыть файл C:\Scripts\Audits.xml. Когда файл откроется, мы используем вот эту строку кода, чтобы создать экземпляр класса documentElement, который в итоге привяжет нас к корню документа. В нашем случае это, разумеется, узел ITChecklist:
Set objRoot = xmlDoc.documentElement
Дальше всю дорогу вниз. Мы создаем новый экзмепляр узла ComputerAudit, добавляя этот новый узел в файл с помощью метода appendChild. Затем мы создаем новые экземпляры узлов ComputerName и AuditDate, указывая подходящие значения (atl-ws-100 и текущая дата, соответственно) для каждого нового узла. Мы запихиваем эти две вещи в наш новый узел ComputerAudit, вызываем метод Save, чтобы сохранить файл и радостно возвращаемся к работе над сценариями к чемпионату «Scripting Games».
Который, если мы забыли упомянуть, будет проходить в Скрипт-Центре TechNet с 15 февраля по 3 марта.
Пока все идет нормально. Мы можем создавать новый файл XML и мы можем добавлять туда записи. Все это здорово, но ведь есть еще масса всякого, как, например, изменить запись в файле? Что ж, вот, по крайней мере, один из способов это сделать, на рис. 4.
Figure 4 Mодификация файла XML (Close Figure 4)
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

xmlDoc.Async = "False"
xmlDoc.Load("C:\Scripts\Audits.xml")

Set colNodes=xmlDoc.selectNodes _
  ("/ITChecklist/ComputerAudit " & _
   "[ComputerName = 'atl-ws-100']/AuditDate")

For Each objNode in colNodes
   objNode.Text = Date
Next

xmlDoc.Save "C:\Scripts\Audits.xml"
Важный момент с этим сценарием происходит, когда мы вызываем метод selectNodes, который определяет записи, возвращаемые по нашему запросу. Как можно видеть, вызывая selectNodes мы аккуратно указали два критерия: мы хотим только записи, у которых атрибут ComputerName равен atl-ws-100, и только ограниченые атрибутом AuditDate.
Примечание: Вам, говорите, непонятно, как это работает? Почитайте нашу первую статью о работе с файлами XML (technetmagazine.com/issues/2007/02/HeyScriptingGuy); синтаксис запроса selectNodes там обсуждается более подробно.
Как всегда, selectNodes возвращает набор всех записей XML , соответсвующих выбранным критериям. Это значит, в свою очередь, что мы можем обновить значение атрибута AuditDate(единственного, о котором мы спрашивали), запустив для всех элементов набора петлю For Each, а затем, внутри этой петли, присвоить AuditDate новое значение:
For Each objNode in colNodes
   objNode.Text = Date
Next
Что, простите? Вы спрашиваете, нельзя ли изменять более одного атрибута за раз? Конечно, можно. Но, к сожалению, не сегодня. Об этом мы поговорим в другой раз.
Но у вас, кажется, есть еще вопрос: Как обновить дату аудита для всех компьютеров в файле? Это просто: воспользоваться сценарием на рис. 5.
Figure 5 Изменение даты аудита (Close Figure 5)
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

xmlDoc.Async = "False"
xmlDoc.Load("C:\Scripts\Audits.xml")

Set colNodes=xmlDoc.selectNodes _
  ("/ITChecklist/ComputerAudit/AuditDate")

For Each objNode in colNodes
   objNode.Text = Date
Next

xmlDoc.Save "C:\Scripts\Audits.xml"
В чем единственное отличие этого сценария от предыдущего, изменяющего XML? В этом мы не говорим, что хотим видеть только записи, для которых ComputerName равен atl-ws-100. Опустив этот критерий, мы получаем все записи по умолчанию.
Давайте посмотримпод конец на еще один сценарий. Допустим, наш добрый товарищ atl-ws-100 отыграл свою роль в этой жизни и отправился на вечный покой в компьютерные небеса.
Техническое замечание: Куда отправляются компьютеры после смерти? Оказывается, их обычно отдают кому-нибудь из авторов сценариев. Например, автор сценариев, который пишет эту колонку, однажды получил ноутбук, потому что, дескать, «Ты сделал для Майкрософт много хорошего и вполне заслужил ноутбук». Какое щедрое предложение! Что же не так? Компьютер был сломан и его было невозможно включить. Впрочем, это, может, и к лучшему. Потому что жесткого диска у него тоже не было.
Чтобы завершить великий цикл силиконовой жизни, нам нужно удалить atl-ws-100 из нашего файла XML. Как бы это сделать? Посмотрите на рис. 6.
Figure 6 Удаление из файла XML (Close Figure 6)
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

xmlDoc.Async = "False"
xmlDoc.Load("C:\Scripts\Audits.xml")

Set colNodes=xmlDoc.selectNodes _
  ("/ITChecklist/ComputerAudit " & _
   "[ComputerName = 'atl-ws-100']")

For Each objNode in colNodes
  xmlDoc.documentElement.removeChild _
    (objNode)
Next

xmlDoc.Save "C:\Scripts\Audits.xml"
Нетрудно увидеть, что все это похоже на предыдущий сценарий, который изменял свойство AuditDate. Здесь есть два отличия. Во-первых, мы не стали тратить время на указание значений свойств в запросе selectNodes; таким образом, мы получаем всю запись XML для atl-ws-100:
Set colNodes=xmlDoc.selectNodes _
  ("/ITChecklist/ComputerAudit " & _
   "[ComputerName = 'atl-ws-100']")
А затем в нашей петле For Each мы просто вызываем метод removeChild и удаляем все записи, где ComputerName равен atl-ws-100:
xmlDoc.documentElement.removeChild _
  (objNode)
Вот и все. Прощай, atl-ws-100; пусть земля тебе будет пухом.
Так, кто-нибудь из редакторов журнала TechNet Magazine еще читает эту статью? Что? Все ушли решать головоломку, связанную со сценариями, за этот месяц? Отлично. Теперь, когда никто не подглядывает через плечо, мы можем сказать вам следующее: бросьте всякие глупости (например, чтение этого журнала) и отправляйтесь в Скрипт-Центр готовиться к чемпионату «Scripting Games». В конце концов, журнал TechNet Magazine никуда не денется. А чемпионат «Scripting Games» -- только раз в году, причем недолго (если быть точным, с 15 февраля по 3 марта, чтобы вы знали). Не пропустите!
Примечание: А ведь и точно, мы сказали вам прекратить читать журнал TechNet Magazine только после того, как вы прочитали свю нашу статью, не так ли? И как только так получилось?..

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

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

Головоломка-сценарий доктора Скрипто.
Ответ: Таинственные знаки, февраль 2008

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


 На страже безопасности: Прыжки по островам: смягчение проблемы нежелательных зависимостей
На страже безопасности
Прыжки по островам: смягчение проблемы нежелательных зависимостей
Йеспер М. Йоханссон

В выпуске «На страже безопасности» за последний месяц я рассказал о первом этапе атаки на сеть с использованием флэш-накопителя USB. Атака началась со вставки инфицированного флэш-накопителя USB в компьютер. Затем был исполнен вредоносный код, либо автоматически, либо с минимальной помощью от пользователя (получаемой путем применения нехитрой
«социальной инженерии»). Атака не вышла за пределы рабочей станции, но было ясно, что вредоносные программы могли распространиться по всей сети. Я подробно рассказываю о такой форме атаки на сеть в моей (готовящейся к изданию) книге «Windows Server 2008 Security Resource Kit» («Набор ресурсов безопасности Windows Server 2008») (изд-во Microsoft Press®, 2008 г.), и для этой статьи используются части соответствующей главы этой книги.
Очевидно, что одним из вариантов защиты является запрет на съемные носители. Хотя такой запрет и может показаться благоразумным, его автору стоит опасаться встречи со справедливо разгневанными пользователями в темном переулке. Более приемлемым вариантом для всех сред, кроме самых чувствительных, будет попытка управления связанным риском и ограничения уязвимой зоны.
Вдобавок, съемные носители являются далеко не единственным способов взлома клиентского компьютера. Помните о «10 непреложных законах безопасности» (доступных на microsoft.com/technet/archive/community/columns/security/essays/10imlaws.mspx)? Основная идея закона 3 по-прежнему верна: «Если у злоумышленника есть неограниченный физический доступ к вашему компьютеру – это уже не ваш компьютер». В контексте данной темы, если у хакера имеется доступ к вашему компьютеру, компьютер следует считать взломанным. Это может быть осуществлено и с удаленного компьютера, если пользователь запустит его код на своем компьютере. В этом можно узнать первый из непреложных законов: «Если злоумышленник убедил вас запустить его программу на вашем компьютере – это уже не ваш компьютер».
Можно с уверенностью предположить, что непреложные законы остаются верными – они продемонстрировали примечательную устойчивость, и значительные изменения в них маловероятны, пока способы работы компьютеров не будут фундаментально изменены. Следовательно, учитывая, как эти законы соотносятся с описанной ситуацией, важно «надеть намордник» на съемные носители. И это можно сделать посредством нескольких изменений в реестре.
Само собой, необходимо также использовать дополнительные уровни защиты. Разумно предположить, что многие из клиентских компьютеров либо уже подверглись взлому, либо принадлежат пользователям, не всегда думающим о безопасности вашей организации. Следовательно, необходимо уменьшить их воздействие на остальную часть сети, что повышает важность знания, анализа и смягчения зависимостей безопасности.

Определение зависимости безопасности
Зависимость безопасности возникает, когда безопасность одного компьютера зависит от безопасности другого. Нередко говорится, что если взломан контроллер домена (domain controller – DC), то взломана и вся сеть. Это упрощенный способ заявить, что безопасность всех членов домена зависит от DC. Если не обеспечена безопасность DC, невозможно обеспечить безопасность их компьютеров. Если злоумышленник может изменять настройку безопасности домена, он может взять под контроль любой компьютер в домене, например, добавляя новые записи к группе администраторов на компьютере его члена. Уязвимости, допускающие вредоносные действия со стороны администратора, просто неинтересны. Предполагается, что у администратора имеется полный доступ ко всему, что он администрирует.
Зависимости в компьютерных системах неизбежны. На деле, они распространены и часто желаемы, но это не значит, что все зависимости приемлемы. В этом выпуске рубрики я расскажу, какие типы зависимостей приемлемы, а какие нет, после чего проанализирую типы зависимостей и способы их смягчения. В Windows Server 2008 Security Resource Ki я рассмотрю конкретные зависимости и управление ими более подробно.

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

Неприемлемые зависимости
Учитывая мое объяснение приемлемых зависимостей, определение неприемлемой зависимости должно быть очевидно. По сути, более важная система никогда не должна зависеть в плане безопасности от менее важной.
Если взлом рабочей станции означает брешь в безопасности DC, то налицо серьезная проблема. Невозможно защитить сеть, если защищенность ее в целом зависит от защищенности каждого конкретного компьютера в ней.
Рассмотрим это с точки зрения статистики. Если каждый компьютер в сети надежно защищен в течение 99,999% от времени своей работы, может показаться, что сеть отлично защищена. На деле, такой процент вероятно совершенно нереален во всех современных сетях, кроме мельчайших. Но предположим теперь, что в сети имеется 40,000 компьютеров, из которых каждый уязвим в течение 0,001% от времени своей работы. Можно отметить, что сеть в целом будет потенциально уязвима на протяжении 40% времени своей работы.
И, само собой, при наличии неуправляемых зависимостей один компьютер, атакованный в тот самый 0,001% времени, может открыть для таки всю сеть. Насколько защищенной она тогда является? Ясно, что защита более важных систем от менее важных совершенно необходима.
То же можно сказать об учетных записях пользователей и ПО. Например, новый клиент служб терминалов для Windows® позволяет хранить имена пользователей и пароли для практически прозрачного входа через службы терминалов. Эти учетные данные хранятся с использованием интерфейса API управления учетными данными, защищенного учетными данными, использованными основным сеансом входа в систему.
Это может создать зависимость безопасности. Рассмотрим случай сетевого администратора, входящей в систему с личной рабочей станции. Она использует эту рабочую станцию для электронной почты, просмотра страниц в Интернете и прочих обычных задач информационного работника. Естественно, в этих целях она использует учетную запись домена с низким уровнем привилегий.
В какой-то момент этот администратор подключается к одному из DC для выполнения некоторых управленческих задач. Для этого она использует клиент служб терминалов и решает сохранить свой пароль, чтобы упростить будущие подключения. Результатом становится минимум одна, а возможно две неприемлемых зависимости безопасности. Первая из них заключается в том, что ее учетные данные администратора домена теперь защищены ее учетными данными информационного работника с низким уровнем привилегий. Взлом этой учетной записи с низким уровнем привилегий дает доступ к учетной записи администратора домена и, следовательно, всему домену.
Вторая зависимость вытекает из факта ввода учетных данных администратора домена на компьютере, не являющемся контроллером домена. Если ее персональная рабочая станция не защищена так же хорошо, как DC, что маловероятно, то возникает зависимость защищенности DC от защищенности этой рабочей станции. Если, например, недовольный сотрудник в этом же офисе установил на ее рабочей станции программу, фиксирующую нажатия клавиш, то учетные данные администратора домена теперь у него в руках. При каждом вводе учетных данных администратора домена на компьютере, не являющемся контроллером домена, весь домен разделяет любые недостатки защиты этого компьютера.
Теперь предположим, что злоумышленник вставил съемный накопитель в компьютер, в систему которого вошел, входил когда-либо или войдет когда-либо администратор домена. Это откроет для действий злоумышленника администратора домена и, как следствие, весь домен. Крайне важно осознавать эту опасность, чтобы ее можно было избежать. И, само собой, та же ситуация возникает с ПО, когда защищенное приложение полагается на функции менее защищенного для выполнения определенной задачи.

Анализ атаки
Ранее я описал, что может произойти при вставке вредоносного съемного накопителя в компьютер. Однако возможно, что очевидны только последствия для компьютера, в который вставлен накопитель. Так что предположим, что этот компьютер присоединен к домену, как показано на Рис. 1.
Рис. 1 Идеальные зависимости домена
Рис. 1 Идеальные зависимости домена
Проиллюстрированная на нем ситуация изображает идеальную зависимость. Стрелки указывают, откуда наследуется зависимость. Например, безопасность рабочей станции зависит от безопасности DC, а безопасность пользователя зависит от безопасности рабочей станции. Злоумышленнику может удаться проникновение на рабочую станцию, что поставит под угрозу любую хранимую на ней пользователем информацию, но этим угроза и будет ограничена.
Но предположим, что пользователь, входящий в систему рабочей станции, является членом группы администраторов местного сервера. И предположим, что администратор домена часто входит в систему на сервере. Теперь возникают зависимости, показанные на рис. 2.
Рис. 2 Рискованные зависимости домена
Рис. 2 Рискованные зависимости домена
Простое изменение того, кто работает на каком из компьютеров, поставило под угрозу безопасность всей сети. Поскольку администратор домена входит в систему на сервере, безопасность DC и, следовательно, безопасность всего домена зависит от безопасности этого сервера.
Это было бы приемлемым, если б сервер управлялся настолько же безопасно, как и DC. Но в данном случае пользователь, входящий в систему рабочей станции, является членом группы администраторов этого сервера. Таким образом, безопасность сервера зависит от безопасности этой рабочей станции. А это значит, что безопасность всего домена зависит от безопасности этой рабочей станции. Теперь сюрприз: пользователь рабочей станции только что, не подумав, запустил средство злоумышленника.
В современном мире безопасности информации вряд ли найдется много концепций, осознавать которые важнее, чем концепцию зависимостей безопасности. Если начать анализировать свою сеть и попытаться понять, каковы зависимости в ней, часть из них почти наверняка окажется неприемлемыми. В худшем из возможных случаев (встречающемся куда чаще, чем можно подумать) защищенность всей сети зависит ото всей сети – другими словами, защита каждого компьютера, так или иначе, зависит от защиты всех до единого прочих компьютеров.. Такая среда делает создание сколь либо разумной и реалистичной стратегии управления риском невозможным, поскольку отношения невозможно проконтролировать, и сложность выходит за рамки понимания. Решение заключается в анализе зависимостей и управлении ими.
В этой статье я представил только короткий обзор зависимостей, управления ими и их смягчения. Дополнительные сведения можно будет найти в моей книге, Windows Server 2008 Security Resource Kit. Она включает целую главу, посвященную вопросу обеспечения безопасности среды посредством анализа зависимостей и управления ими с использованием как изощренных методик, скажем изоляции серверов и доменов, так и более привычных методов, таких как управление учетными записями администраторов.
Я хотел бы поблагодарить Дэвида ле Бланка (David LeBlanc), который помог обрести форму зародышам идей, из которых выросла эта статья.

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


 Документы о рабочей среде: Двойная загрузка с Windows XP и Windows PE 2.0
Документы о рабочей среде
Двойная загрузка с Windows XP и Windows PE 2.0
Уэс Миллер (Wes Miller)
Загрузить исходный код для этой статьи: Desktop2008_02.exe (151KB)

В предыдущих выпусках документов о рабочей среде я упоминал о том, что Windows PE стало средством восстановления, и объяснял, как ее можно использовать со второго раздела. Недавно я получил вопрос, который заставил меня задуматься, не написать ли о новом варианте – использование Windows PE 2.0 вместе с Windows XP.
В конце концов, многие давно используют Windows® XP, а Windows PE 2.0 – версия, развитие которой корпорация Майкрософт поддерживает (заметьте, что обновлений Windows PE 1.x больше не будет).
Одно важное отличие Windows PE 1.x от 2.x состоит в том, что Windows PE 2.x может загружаться через стандартный интерфейс загрузки (а не специальным методом, который использует Windows PE 1.x). Windows PE 1.x или 2.x можно загружать со второго раздела, но загружать их с того же раздела, что и операционная система, очень удобно; я расскажу об этом чуть ниже.

Две загрузки для Windows
Windows NT® всегда была относительно терпима к двойной загрузке. Но из-за того, что компьютеры на основе расширяемого интерфейса микропрограмм (EFI) начали замещать старые на основе IBM PC AT BIOS, Майкрософт изменила механизм загрузки, для лучшей работы с EFI и унификации механизма загрузки для всех архитектур. Новый механизм загрузки, использующийся начиная с Windows Vista®, называется базой данных конфигурации загрузки (BCD) (см. microsoft.com/whdc/system/platform/firmware/bcd.mspx). Но говорим ли мы о старом boot.ini или о новом механизме BCD, Windows обычно может загружать другие операционные системы, даже если это требует передачи процесса загрузки другому загрузчику.
Прежде чем мы начнем, важно вспомнить, что Windows PE 2.0 работает только на системах, полностью совместимых со стандартом Advanced Configuration and Power Interface (ACPI) и имеющих 384MБ (лучше 512MБ) ОЗУ. Как я отмечал в статье за май (technetmagazine.com/issues/2007/05/DesktopFiles), системы, не совместимые с ACPI не загружают Windows PE 2.0 и, так как Windows PE 2.0 загружается на RAMDisk, требуется достаточно ОЗУ для RAMDisk, какое-нибудь рабочее пространство и весь объем ОЗУ для работы среды. Если у вашей системы менее 384 МБ ОЗУ, даже не думайте об этом; используйте Windows PE 1.6. Даже опытный мастер уменьшения размера Windows PE не сможет заставить ее нормально работать на 256MБ.

Да, какие же проблемы это решит
Давайте посмотрим, с какими проблемами вы справитесь, загрузив Windows PE 2.0 с того же раздела, что и Windows XP.
Полное восстановление системы Это только одна задача, реализуемая засчет загрузки Windows PE прямо с раздела Windows XP. Так как Windows PE 2.0 (и более ранняя Windows PE 1.6) может полностью загружаться на RAMDisk, можно восстановить весь димк, или воспользоваться ImageX для восстановления самих файлов Windows XP, веьд нет необходимости в восстановлении всего раздела.
Если пользователи могут загрузить Windows PE при запуске, они могут восстанавливать свои системы даже при удаленной работе. Образ может быть на вторичном разделе, общей папке в сети (если пользователи не мобильны), DVD или жестком диске USB для восстановления или, если используется ImageX, даже на восстанавливаемом разделе. Такой тип восстановления с диска – отличное решение многих проблем (за исключением физического повреждения диска). Этот вариант, очевидно, плох для восстановления данных, если они сначала не защищены и не восстанавливаются затем в комплексе. Запомните: всегда всегда использовать перемещаемые профили и создавать резервные копии данных с компьютера, чтобы предотвратить такую потерю. Также следует убедиться, что используемый механизм восстановления может справиться с потерей данных по вине пользователя (в том числе с потерей из-за сброса ключей шифрования EFS).
Восстановление файлов Windows PE также позволяет запустить систему, даже если основная установка Windows не загружается. В этом случае вам удастся загрузиться и восстановить данные пользователя либо на другую систему (если для пользователей подготовлены резервные системы), либо в другое место, чтобы пользователь мог вскоре продолжить работать.
Ремонт системы Наконец, загрузка Windows PE поверх Windows XP позволяет ремонтировать систему, запуская набор сценариев диагностики и устранения неполадок или простое приложение ремонта или восстановления под управлением пользователя. Этот процесс похож на полное восстановление системы, но несколько уже (и не подвергает риску данные пользователя).
Теперь, представляя себе, что можно сделать, загрузив Windows PE на разделе Windows XP, посмотрим, что происходит за кулисами, чтобы уметь воспользоваться этим в любом собственном решении.

До Windows Vista.
Вот как загружались системы на основе BIOS/Master Boot Record (главной загрузочной записи, MBR) до прихода Windows Vista. BIOS указывал на загрузочное устройство (MBR в случае жесткого диска). MBR выполнял код, указывающий на раздел, с которого следует загружаться. Заметьте, что флаг активности устанавливается для первого раздела. В ранних версиях diskpart было невозможно сделать раздел неактивным (то есть нельзя было снять флаг активности). Это было исправлено добавлением в diskpart переключателя, иначе флаг активности устанавливался для первого раздела в таблице разделов. Раздел содержит загрузочный сектор, который говорит, какой код выполнять следующим. С Windows NT по Windows Server® 2003, этот код находится в файле ntldr, без расширения. Если вы когда-нибудь форматировали диск, не устанавливали Windows, а потом пробовали загрузиться, то вы видели сообщение об ошибке "NTLDR not found".
Интересно отметить, что ntldr полностью обратно совместим (но, конечно, не совместим вперед). Это значит, что ntldr Windows XP может загружать Windows 2000, но не наоборот. Поэтому, если планируется двойная загрузка, важно сперва установить более старую операционную систему. Это тем более важно, что ntldr не сопровождается номером версии.
Ntldr – 16-битное приложение, в реальном времени запускающее NTDetect.com, выполняющее поиск основных устройств и запускающее ядро, ntoskrnl.exe (это может быть один из нескольких файлов, всегда переименованных в ntoskrnl.exe). Ядро – главный компонент процесса загрузки Windows.
Это несколько упрощенный обзор процесса загрузки, я полностью опустил инциализацию Win32®, но это не имеет отношения к нашей теме. Если вы хотите узнать об этом больше, я рекомендую почитать книгу Windows Internals, Fourth Edition (Внутренняя структура Windows, четвертое издание) Марка Руссиновича (Mark Russinovich) и Дэвида Соломона (David Solomon) (Microsoft Press®, 2004) (имеется русский перевод: Внутреннее устройство Microsoft Windows: Windows Server 2003, Windows XP и Windows 2000, СПб, 2006).
Еще одна важная вещь – когда происходит загрузка с компакт-диска, Windows Setup и Windows PE используют не ntldr, а setupldr.bin. Этот файл содержит несколько другой код загрузки, чтобы загружаться с компакт-диска (этого не может делать ntldr). Вот почему для загрузки Windows PE 1.x вам пришлось переименовать setupldr.bin в ntldr и записать его на жесткий диск. Поэтому же он не может загрузить файл boot.ini (setupldr.bin разработан для загрузки компакт-диска, поэтому boot.ini не представлялся нужным).

После Windows Vista
В Windows Vista многие детали этого процесса изменились. Windows Server 2008 еще изменяет его, включая IA32 (поддержка 32-битных систем) для загрузки с EFI, раньше это было возможно только в системах на основе Itanium. Для систем на основе BIOS, первые шаги процесса загрузки не очень отличаются. Ключевое отличие в том, что инициализируется загрузчик BOOTMGR, который выполняет следующие действия.
Он ищет в папке загрузки файл BCD, который является собственным кустом реестра. BCD содержит записи для загрузки (включая используемые по умолчанию). На рис. 1 указаны типы образов (типы исполнимых файлов, а на рис. 2 типы запускаемых приложений. Одна (или несколько) этих записей может быть ссылкой на ntldr. Только одна может сслыться на известный GUID, используемый для загрузки ntldr (пятый ряд рис. 3). Затем bootmgr решает, какую запись загружать следующей, в зависимсоти от того, загружается ли система, выходит из спящего режима или загружает ntldr или другой диспетчер загрузки (в этом случае он укажет на другой загрузочный сектор и запустит этот загрузчик). Это обычная ситуация, если вы делаете двойную загрузку с операционной системой не на основе Windows. Узнать больше можно на странице microsoft.com/whdc/system/platform/firmware/bcd.mspx.
Figure 3 Стандартные объекты приложений (Close Figure 3)

Описание | BCDEdit ID | GUID
Диспетчер загрузки Windows | {bootmgr} | 9dea862c-5cdd-4e70-acc1-f32b344d4795
Микропрограммный диспетчер загрузки | {fwbootmgr} | a5a30fa2-3d06-4e9f-b5f4-a01df9d1fcba
Тестер памяти Windows | {memdiag} | b2721d73-1db4-4c62-bf78-c548a880142d
Приложение возобновления Windows | Нет псевдонима | 147aa509-0358-4473-b83b-d950dda00615
Загрузчик старых версий Windows | {ntldr} | 466f5a88-0af2-4f76-9038-095b170dc21c
Текущая запись загрузки | {current} | fa926493-6f1c-4193-a414-58f0b2456d1e
Запись загрузки по умолчанию | {default} | нет предопределенного GUID
Figure 2 Типы приложений (Close Figure 2)

Описание | Значение | Описание
Микропрограммный диспетчер загрузки | 0x1 | Применимо только к системам EFI.
Диспетчер загрузки Windows | 0x2 | Контролирует поток загрузки. В системе с двойной загрузкой, выдает пользователю меню с выбором загрузки.
Загрузчик Windows | 0x3 | Загружает определенную версию или конфигурацию Windows.
Приложение возобновления Windows | 0x4 | Возобновляет работу Windows после выхода из спящего режима.
Тестер памяти Windows | 0x5 | Приложение диагностики памяти.
Ntldr | 0x6 | Применимо только к системам PC/AT BIOS. Загружает версии Windows до Windows Vista.
Загрузочный сектор | 0x8 | 16-битное приложение в реальном времени. Применимо только к системам PC/AT BIOS. Может использоваться для перезапуска процесса загрузки и загрузки операционной системы не на основе Windows.
Figure 1 Типы образов (Close Figure 1)

Описание | Значение
Приложение микропрограмм | 0x1
Приложение загрузки | 0x2
Объект загрузчика на основе ntldr | 0x3
Приложение в реальном времени | 0x4
Вы заметите, что переработанная инфраструктура загрузки Windows Vista более организована, чем предыдущие версии: весь код загрузки, кроме bootmgr, содержится в папке \boot на корневом уровне и выдается специфическим двоичным файлам Windows по указанию BCD.

Загрузка Windows XP и Windows PE 2.0
Вы уже могли увидеть, как Windows PE, с помощью диспетчера загрузки Windows Vista, может выступать посредником, позволяющим продолжать загружать Windows XP или более ранние версии, добавляя в смесь Windows PE 2.0 в качестве встроенного средства восстановления.
Конечно, придется добавить еще один шаг в процесс загрузки, но этот шаг был запланирован корпорацией Майкрософт. Новая инфраструктура bootmgr должа была иметь обратную совместимость с ntldr и другими сторонними диспетчерами загрузки, поэтому bootmgr создан с расчетом на такие решения.
Теперь мы знаем, как загружается Windows и как работает новый BCD. Как связать их вместе и запустить Windows PE 2.0 поверх установленной Windows XP? Есть два способа записать загрузочный сектор Windows Vista, ту часть загрузочного кода, которая говорит системе запустить bootmgr. Один – использовать diskpart и создать и отформатировать новый раздел с Windows PE 2.0. Но здесь это не годится, ведь у нас уже есть установка Windows XP, которую нельзя двигать или повреждать. Вместо этого, сделайте так:
  1. Убедитесь, что на загрузочном компакт-диске Windows PE 2.0 есть копии bootsect.exe и bcdedit.exe (их можно найти на DVD установки Windows Vista).
  2. Загрузите систему Windows XP на компакт-диск Windows PE 2.0.
  3. После загрузки выполните эту команду:
    bootsect.exe /NT60 ALL
Теперь загрузочный сектор будет совместимым с сектором Windows Vista, который знает, как запустить bootmgr.
4. Скопируйте диспетчер загрузки на жесткий диск:
    xcopy BOOTMGR C:\BOOTMGR /I
5. Скопируйте файл boot.SDI в папку \BOOT на жестком диске. Перед загрузкой придется сделать его копию, так как при работе Windows PE он будет заблокирован для копирования:
    xcopy BOOT.SDI C:\BOOT\
Поправьте путь по необходимости.
6. Скопируйте boot.WIM на жесткий диск. Как и с SDI, понадобится вторая копия, скопировать исполняющийся файл будет невозможно:
    xcopy BOOT.WIM C:\BOOT\BOOT.WIM
Поправьте путь по необходимости.
7. Создайте новое хранилище BCD:
    bcdedit /createstore
8. Затем создайте записи BCD для загрузки Windows PE:
    bcdedit /create {ramdiskoptions} /d
    "Boot Windows PE"
    bcdedit /set {ramdiskoptions}
    ramdisksdidevice partition=c:
    bcdedit /set {ramdiskoptions}
    ramdisksdipath \boot\boot.sdi
    bcdedit /create /d "Windows PE" /
    application
    OSLOADER
9. Последняя строка вернет GUID. Замените {YOURGUID} фактически возвращеннымGUID. Это записи на RAMDisk, которые загрузят Windows PE с жесткого диска, см. рис. 4.
Figure 4 Записи на RAMDisk, загружающие Windows PE с жесткого диска (Close Figure 4)
bcdedit /set {YOURGUID} device ramdisk=[c:]\boot\boot.wim,{ramdiskoptions}
bcdedit /set{YOURGUID} path \windows\system32\winload.exe
bcdedit /{YOURGUID} osdeviceramdisk=[c:]\boot\boot.wim,{ramdiskoptions}
bcdedit /set{YOURGUID} systemroot \windows
bcdedit /set{YOURGUID} winpe yes
bcdedit /set {YOURGUID} detecthal yes
10. Теперь создайте записи bootmgr, чтобы запустить диспетчер загрузки:
    bcdedit /create {bootmgr} /d
    "Boot Manager"
    bcdedit /set {bootmgr} device boot
11. Наконец, заведите запись BCD для существующей установки Windows (замените текст Windows XP на любой, который вы хотите видеть в меню диспетчера загрузки. Последняя команда делает ее первой (по умолчанию) строкой в меню загрузки:
    bcdedit /create {ntldr} /d "Windows XP"
    bcdedit /set {ntldr} device partition=C:
    bcdedit /set {ntldr} path \ntldr
    bcdedit /displayorder {ntldr} /addfirst
12. Теперь нужно перезагрузить систему и запустить старую установку Windows или Windows PE 2.0, выбирая соответствующую запись меню загрузки. На рис. 5 показан пример вывода из bcdedit /enum all. Эта команда перечисляет все записи в BCD после добавления записей (из-под Windows PE 1.6).
Пример ввода
Я работал над сценарием, который может делать это автоматически. Пока что он может только копировать загрузочные файлы на жесткий диск и выставлять записи в BCD. Он не может выставить в загрузочном секторе новое значение Windows Server 2008 при работе Windows, это придется делать под Windows PE. Сценарий можно найти в разделе с загружаемым кодом веб-узла журнала TechNet Magazine по адресу technetmagazine.com. Чтобы запустить сценарий, в той папке, где работает VBScript, понадобятся следующие объекты:
  1. BCDEdit
  2. BOOTMGR
  3. Папка \BOOT\ (с источника Windows Vista или Windows PE 2.0)
  4. Папку \SOURCES\ с рабочим загрузочным файлом Windows PE 2.0 BOOT.WIM
Он создаст BCD и копии нужных загрузочных файлов. После загрузки Windows PE и запуска bootsect, вы сможете сделать двойную загрузку.

Отмена двойной загрузки
Отменить двойную загрузку еще проще, чем сделать. Нужно просто восстановить загрузочный сектор до его до- Windows Vista состояния, выполнив следующие команды:
bootsect.exe /NT52 ALL
После восстановления можно удалить bootmgr и папку \boot. При следующей загрузке загрузочный сектор запустит ntldr и полностью удалит Windows PE 2.0 и все загрузочные двоичные файлы Windows Vista из потока загрузки.

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


 Заметки разъездного инженера: Пожертвуйте свой ПК
Заметки разъездного инженера
Пожертвуйте свой ПК
Джим Линч (Jim Lynch)

Многолетнее общее мнение относительно наиболее экономичного способа утилизации компьютеров лучше всего отображает научная статья, опубликованная в 2003 Фрэнсисом О'Брайеном из Gartner Group под названием "PC Disposal: TCO's Last Surprise" («Утилизация ПК: последний сюрприз совокупной стоимости владения»). Этот сравнительный анализ технологий утилизации ПК показал, что пожертвование на благотворительность было наиболее дорогостоящим вариантом (из шести возможных) из-за времени, уходившего на обнаружение подходящих благотворительных организаций, принимающих пожертвования в такой форме.
Советы по благотворительности
TechSoup.org предлагает дополнительные советы в области пожертвований на благотворительность, а также получения помощи в виде пожертвований на techsoup.org/recycle. Некоторые соображения для желающих пожертвовать что-то на благотворительность:
  • Не стоит цепляться за информационное оборудование после перехода на новое. Компьютерное оборудование теряет пригодность для использования по истечении пяти лет. Аналогично, мобильные телефоны обычно достигают конца жизненного цикла по истечении трех лет.
  • Жертвуйте информационное оборудование, которое моложе пяти лет, восстановителям, а не напрямую некоммерческим организациями или школам.
  • Упаковывайте вспомогательные средства и дополнительные принадлежности (клавиатуру, мышь, принтер, модем, диски с ПО и инструкции к оборудованию) вместе с оборудованием.
  • Храните у себя список пожертвованного и возьмите расписку. В случае пожертвования некоммерческому восстановителю нередко можно рассчитывать на налоговые льготы. В США компании-жертвователи могут вычесть из налогооблагаемой базы изначальную (необесцененную) стоимость компьютера, а физические лица – его текущую рыночную стоимость. Чтобы определить реальную рыночную стоимость компьютера, воспользуйтесь бесплатным канадским средством оценки стоимости использованных компьютеров (servlets.edeal.com/servlets/PcEval).

Сегодня обстоятельства стали иными. Как известно, Управление по охране окружающей среды США недавно выдвинуло инициативу под названием "Do the PC Thing" («Поступай с ПК политкорректно»), нацеленную на обучение пользователей подготовке их старого оборудования к повторному использованию и предлагающую список соответствующих материалов. Эта инициатива является частью веб-узла Управления, посвященного привлечению внимания публики к утилизации и повторному использованию электроники, Plug-In To eCycling (epa.gov/plugin/). Щелкните ссылку "Reuse It!" («Использовать повторно!») для просмотра статей, предназначенных потребителям или компаниям.
На этом веб-узле можно узнать, что наиболее важной проблемой при пожертвовании или утилизации оборудования является собственная защита. В литературе, предлагаемой инициативой "Do the PC Thing", приводятся базовые указания по части очистки жестких дисков, а также правовые нормы, связанные с безопасностью данных и конфиденциальностью. Независимо от того, ведет ли избавление от компьютера к утилизации или повторному использованию, необходимо предварительно удалить с него важные данные, такие как пароли, документы, информацию о кредитных картах, сообщения электронной почты и блоги.
Большинство утилизаторов, восстановителей и компаний по распоряжению имуществом предоставляют услуги безопасности, либо разрушая жесткие диски, либо используя программы очистки диска, которые исключают восстановление данных. Учтите, что если компьютеры зарезервированы для повторного использования, оборудование лучше оставить целым.
Хорошо себя зарекомендовавшие программы очистки дисков используют спецификации Министерства обороны США 5220.22-M. Этот тип удаления данных на основе ПО систематически перезаписывает все адресуемые блоки на жестком диске, используя какой-либо символ, подтверждает перезапись и затем снова перезаписывает все адресуемые блоки, используя случайные символы. В 2004 году, Агентство Национальной Безопасности США (в бюллетене NSA Advisory LAA-006-2004) заключило, что единственная перезапись с использованием ПО Министерства обороны делает электронные файлы невосстановимыми.
Очистку данных теперь достаточно просто выполнить самому. Имеются зарекомендовавшие себя бесплатные приложения, такие как Active@ Kill Disk Hard Drive Eraser (killdisk.com/eraser.htm) или Darik's Boot and Nuke (dban.sourceforge.net). Если необходимо очистить несколько компьютеров от данных, можно подумать о более надежных коммерческих приложениях, таких как Blancco Data Cleaner (blancco.com) или WipeDrive (whitecanyon.com).
Если информационное оборудование старше пяти лет или безнадежно поломано, можно использовать еще один из шести вариантов Гартнера: утилизацию электроники. Сейчас в США существуют более 900 компаний, работающих в этой области. Для правильной утилизации старого информационного оборудования обратитесь к кому-либо из списка ответственно подходящих к делу утилизаторов от Electronic TakeBack Coalition (www.computertakeback.com/the_solutions/recyclers_map.cfm).

Джим Линч (Jim Lynch) является руководителем программы переработки и повторного использования компьютеров в компании TechSoup.org из Сан-Франциско, некоммерческой высокотехнологичной организации. Ее задачей является поставка для благотворительных организаций по всему миру дешевого оборудования, программного обеспечения и технологий.


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

Это происходит нечасто , но порой старая функция удаляется – что вызывает ликование в команде разработчиков. Например, в Windows® XP был удален интерфейс для установки рисунка фона рабочего стола. Базовые функции остаются на месте, для тех, кто может написать программу, вызывающую SystemParametersInfo(SPI_SETDESKPATTERN), но у них больше нет встроенного интерфейса. Почему рисунок фона был удален из панели управления рабочим столом?
Наши исследования показали, что практически никто уже не использовал рисунки фона. Они были более популярны во времена более дорогой памяти и пользователей, не желающих выкидывать четверть оперативной памяти компьютера на точечный фоновый рисунок в 1 МБ. Крохотный монохромный рисунок размера 8Ч8, повторяющийся по всему экрану, придавал некоторую степень индивидуальности экрану 640Ч480 при намного меньших издержках.
Однако накапливающиеся изменения делали рисунки фона все менее и менее притягательными. Во-первых, само собой, компьютеры теперь несут куда больше памяти, чем в 1983 году. Во-вторых (также само собой), мониторы сейчас работают на куда более высоких разрешениях, чем тогда. Милый рисунок гусиной лапки размером 8Ч8 на мониторе1600Ч1200 является не более чем серой кляксой.
Это не единственная старая функция, оказавшаяся на свалке. Еще один пример – карманы. Представленные в Windows 95 карманы представляются как фрагменты документа, записанные в файл. Этот фрагмент файла на деле является объектом OLE. Смысл карманов заключался в возможности, для примера, выделить какой-нибудь текст в текстовом процессоре и перетащить его на рабочий стол, где создавался карман. Потом можно было взять этот карман и перетащить его обратно в текстовый процессор или какую-нибудь другую программу, вставляя текст, использованный для создания кармана, в новый документ. Это напоминает копирование и вставку, за исключением того, что вместо временного сохранения данных в буфере обмена они сохранялись в файле.
После создания такого файла кармана с ним практически ничего нельзя было сделать, кроме как сбросить его в другой документ, подобно тому, как содержимое буфера обмена можно только вставить куда-нибудь. В один прекрасный день некто добавил возможность, позволяющую открывать файл кармана в приложении, изначально создавшем его, посредством двойного щелчка. (Содержимое кармана могло быть чем угодно, так что единственным путем его отображения был запрос к изначально создавшей его программе.)
Я не знаю, была ли эта возможность добавлена как средство отладки или чтобы предоставить пользователям возможность видеть содержимое кармана, не создавая для этого пустой документ. Так или иначе, создатели вирусов полюбили эту функцию «открытия приложения, изначально создавшего карман», поскольку она позволяла им создать карман и наполнить его данными говорящими «Изначальное приложение – cmd.exe, фрагмент документа – этот пакетный файл». При двойном щелчке такого файла кармана с целью просмотра его содержимого средство просмотра карманов передавало пакетный файл командному процессору и говорило «Пожалуйста, откройте это и покажите содержимое пользователю».
Учитывая историю карманов, группа, работавшая с оболочкой, нацелилась на удаление этой функции Windows Vista®. Чтобы сделать это, группе пришлось исследовать, насколько популярны были карманы на самом деле. Так что группа разработчиков оболочки обратилась к группе службы поддержки продуктов с просьбой поднять записи и выяснить, сколько людей задавали вопросы о карманах. Теория заключалась в том, что служба поддержки не получает запросов о непопулярных функциях (поскольку никто их не использует). Поскольку карманы не то чтобы попадали в разряд «совершенно интуитивных» функций, то небольшое число звонков не могло быть объяснено тем что: «Но эта функция настолько очевидна, что кому тут может быть нужна справка!»
Ответ от службы поддержки пришел За последний год эта группа получила всего четыре звонка. И все из них были в стиле «Я тут создал странный файл. Что это такое и как от него избавиться?»

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