Июль 2008 Июль 2008
IIS: Начало эксплуатации с IIS 7.0
Выход служб Internet Information Services 7.0 устанавливает новые стандарты, предлагает фундаментальные улучшения и приносит новые возможности по консолидации веб-сред. Познакомьтесь с наиболее значительными усовершенствованиями и получите подробное руководство по тестированию, размещению и переносу веб-приложений на IIS 7.0. Фергус Страхан (Fergus Strachan)
Связь и совместная работа: Планирование перехода на единую систему обмена сообщениями
Переход от устаревшей системы голосовой почты на платформу единой системы обмена сообщениями может быть выполнен без труда и с небольшим перерывом в обслуживании конечных пользователей, если у вас готов надежный план. Ознакомьтесь с тем, что необходимо знать для планирования перехода, тестирования новых систем и внедрения единой системы обмена сообщениями в вашей организации. Джеф Гудвин (Jeff Goodwin)
Связь и совместная работа: Каким образом голосовая связь увеличивает возможности OCS 2007
Microsoft Office Communication Server вносит важные изменения в корпоративную телефонию. Изучите уровни выполнения голосовых вызовов, узнайте, как можно маршрутизировать вызовы к различным оконечным точкам и оцените важность бесед для связи с помощью OCS. Раджеш Раманатан (Rajesh Ramanthan)
Связь и совместная работа: создание многофункциональных подключений при помощи Groove и SharePoint
Вместе Microsoft Office Groove и SharePoint Server предоставляют многочисленные возможности для совместной работы. Сравните, чем они отличаются друг от друга и как дополняют друг друга, и узнайте, как интеграция Groove и SharePoint приводит к простому и гибкому решению проблемы взаимодействия пользователей, далеко находящихся друг от друга. Алан Мэдисон (Alan Maddison)
Администрирование в Windows: Представляем отказоустойчивую кластеризацию Windows Server 2008
Не один год пользователи жаловались, что кластеризация в Windows Server слишком сложна. С выходом Windows Server 2008 кластеризация подверглась полному обновлению. Познакомьтесь с некоторыми из самых значительных усовершенствований, содержащихся в новой отказоустойчивой кластеризации, и узнайте, как эта новая реализация упрощает установку и обслуживание кластеров. Чак Тимон (Chuck Timon)
Columns
От редактора: Печать мертва: | Письма в редакцию: Мнения читателей: | Панели инструментов: Новые продукты для специалистов по информационным технологиям:
Exchange в вопросах и ответах: Балансировка нагрузки, пограничный транспорт и прочее: Есть вопросы об Exchange? В этом выпуске рубрики мы отвечаем на вопросы по использованию Exchange с SharePoint, работе с резервной непрерывной репликацией, установке серверов почтовых ящиков Exchange 2007 на Windows Server 2008 и прочему.Хенрик Вальтер (Henrik Walther) | Обзор служебных программ: Microsoft SharedView: Ищите способ быстрой совместной работы с пользователем в другом городе? Посмотрите, как бесплатная служебная программа Microsoft SharedView позволяет просто обмениваться файлами и экранами с участниками небольшой группы, даже через физические границы.Грег Стин (Greg Steen) | Sharepoint изнутри: интеграция приложений Office: Ознакомьтесь с интеграцией и связью приложений Microsoft Office со SharePoint и способами интеграции приложений сторонних разработчиков со SharePoint на основе этих же принципов.Пав Черны (Pav Cherny)
Язык сценариев Windows PowerShell: коробка для промежуточных результатов: Дон Джонс рассматривает функции фильтрации, конвейер, пользовательские объекты, а также ключ к знакомству с Windows PowerShell с помощью шаров для настольного тенниса.Дон Джонс (Don Jones) | Эй, сценарист!: Адреналиновая лихородка: Сценаристы обсуждают волнующую процедуру написания сценария и демонстрируют, как с помощью сценариев можно получить доступ к новому хранилищу данных настройки загрузки операционных систем Windows Vista и Windows Server 2008.Сценаристы корпорации Майкрософт | Документы о рабочей среде: сетевая загрузка Windows: Узнайте об истории служб удаленной установки (RIS) и других технологиях, основанных на протоколе PXE, которые используются корпорацией Майкрософт.Уэс Миллер (Wes Miller)
На страже безопасности: пароли и кредитные карты, часть 1: В первом из трех выпусков рассматриваются устаревшие распространенные рекомендации по вопросам безопасности и общепринятая практика, фактически препятствующие обеспечению безопасности.Йеспер М. Йоханссон (Jesper M. Johansson) | Полевые заметки: Ensure Election Accuracy: Изучите уязвимости в современной системе проведения выборов в США и узнайте о том, как можно использовать шифрование для обеспечения полностью проверяемых результатов выборов.Джош Беналох (Josh Benaloh) | О Windows из первых рук: история занимает место: Microsoft Bob гораздо более материален, чем вы можете думать. Рэймонд Чен рассказывает о том, какой путь проделал Microsoft Bob, чтобы попасть в миллионы домов.Рэймонд Чен (Raymond Chen)


IIS
Начало продуктивной эксплуатации IIS 7.0
Фергус Страхан (Fergus Strachan)
Краткий обзор.
  • Развертывание IIS 7.0 в среде веб-фермы
  • Улучшения безопасности и производительности
  • Перенос веб-приложений ASP.NET с IIS 6.0 на IIS 7.0
  • Перенос веб-приложений PHP на IIS 7.0

Содержание
Подготовка, установка, тестирование
Настройка моего теста
Важные усовершенствования для администраторов отделов ИТ
Архитектура IIS
Интегрированный и классический режимы
Модули и функции
Перенос веб-приложений
Заключение
Группа разработчиков IIS корпорации Майкрософт заявляет, что службы Internet Information Services (IIS) 7.0 являются самым крупным выпуском за всю историю IIS. Эта версия устанавливает новые стандарты, предлагает фундаментальные улучшения и
приносит новые возможности для консолидации веб-сред. Службы IIS 7.0, входящие в состав Windows Server® 2008 и Windows Vista® SP1, уже сейчас обеспечивают работу Microsoft.com, а несколько компаний, поставляющих услуги размещения веб-узлов, уже начали предоставлять услуги по размещению под IIS 7.0 веб-дизайнерам и разработчикам, желающим перенести свои существующие веб-приложения на платформу нового веб-сервера.
В этой статье я исследую ключевые улучшения в IIS 7.0, которые наиболее важны для специалистов по ИТ, после чего подробно раскрою вопросы переноса веб-приложений ASP.NET и PHP. Но сперва я хотел бы дать краткий эскиз лаборатории тестирования, схожей с базовой производственной средой.
Это важная задача. Перед развертыванием IIS 7.0 на рабочих серверах необходимо провести некоторое время, выполняя тщательное тестирование в лабораторной среде, чтобы обеспечить беспроблемную работу своих веб-приложений на новом веб-сервере.

Подготовка, установка, тестирование
В состав моей лаборатории тестирования входят системы, работающие на Windows Server 2003 и IIS 6.0, на которых размещены приложения ASP.NET, а также серверы, на которых работает дистрибутив Linux Ubuntu 7.10 и сервер HTTP Apache 2.2, размещающие веб-приложения на основе PHP. Моей конечной целью является развертывание Windows Server 2008 на промежуточных и производственных системах, а затем перевод сложных веб-приложений с целью замены экземпляров IIS 6.0 и Apache на IIS 7.0.
У меня имеются два ключевых веб-приложения: DotNetNuke 4.7 и osCommerce 3.0a4. DotNetNuke – платформа веб-приложений, основанная на ASP.NET 2.0 и Microsoft® SQL Server®. Другое приложение, osCommerce, является последней альфа-версией полнофункционального решения электронной коммерции, построенного на PHP и MySQL. Так что давайте перенесем эти современные приложения на IIS 7.0!
Я хотел бы пояснить, что в мои намерения не входит сравнение версий программного обеспечения, продуктов или платформ. Однако использование Windows Server 2008 и IIS 7.0 в качестве стандарта дает ряд преимуществ, на которые следует указать. А именно, уменьшаются административные сложности и появляется возможность свести к минимуму общее число используемых веб-серверов.
На рис. 1 предоставлен обзор лаборатории тестирования, которую я использую для этой статьи. Если вы хотите последовать моим объяснениям в собственной тестовой среде, ссылки на требуемые компоненты программного обеспечения, а также подробные поэтапные руководства по установке можно найти в сопровождающем материале, доступном в отделе загрузок кода веб-узла журнала TechNet Magazine на .com.
Рис 1. Среда тестирования для развертывания IIS 7.0 (щелкните изображение, чтобы увеличить его)
Стоит отметить, что когда я завершал работу над этой статьей, Майкрософт выпустила средство командной строки (MSDeploy.exe) для поддержки развертывания IIS 6.0 и 7.0 клиентами, их синхронизации и переноса на них веб-приложений. Я рекомендую познакомиться с этим средством. Подробные сведения можно найти в блоге группы веб-развертываний Майкрософт по адресу go.microsoft.com/fwlink/?LinkId=118272.

Настройка моего теста
Во время написания этой статьи Windows Server 2008 все еще находился в состоянии предварительной версии, так что я не стал заменять Windows Server 2003 на контроллере домена или серверах базы данных. После официального выпуска Windows Server 2008 можно подумать о переносе заодно и инфраструктуры Active Directory®. Перенос баз данных SQL Server® 2005 и MySQL на SQL Server 2008 также выходит за рамки этой статьи.
Я развернул SQL Server 2008 на моем промежуточном сервере в основном потому, что это требует меньше усилий, чем установка SQL Server 2005 с пакетом обновления 2. DotNetNuke может без проблем работать с базой данных SQL Server 2008. Установка MySQL 5.0 на Windows Server 2008 также была незамысловатым процессом безо всяких сложностей.
Хотя службы IIS 7.0 доступны в варианте установки Server Core, я не использовал Server Core из-за определенных требований к моему тестированию. Мой промежуточный сервер требовал полной установки, поскольку являлся моей основной тестовой системой. Вдобавок, Microsoft .NET Framework отсутствует на Server Core.
PHP работает на Server Core без проблем, но моей целью является объединение приложений ASP.NET и PHP, так что Server Core совершенно исключен. Пока .NET Framework не будет поддерживается Server Core, для поддержки приложений ASP.NET будет необходимо выполнять полную установку. Детальное, поэтапное руководство по установке тестовой среды можно найти в файле the 01_install_testlab.htm сопровождающего материала.
Я решил выполнить чистую установку Windows Server 2008 (а не обновлять существующие серверы). Помимо прочего, чистая установка упрощает применение поэтапного варианта переноса, подобного показанному на рис. 2. Базовая стратегия состоит в том, чтобы поддерживать работу существующих веб-ферм, пока все значимые компоненты веб-приложения не прошли успешное тестирование на промежуточном сервере и не перемещены на веб-ферму IIS 7.0.
Рис 2. Организация перехода на IIS 7.0 (щелкните изображение, чтобы увеличить его)
Можно переместить все существующие веб-приложения разом или делать это постепенно в зависимости от сложности среды. Для каждого веб-приложения или узла после выполнения окончательного приемочного тестирования на новой веб-ферме можно проделать переход, изменив соответствующие записи DNS, чтобы направить обозреватели на новую веб-ферму IIS 7.0. Это позволяет свести к минимуму простои и перерывы в работе.

Важные усовершенствования для администраторов отделов ИТ
В журнале MSDN® Magazine есть превосходная статья Майка Володарского (Mike Volodarsky), озаглавленная "Explore the Web Server for Windows Vista and Beyond" («Рассмотрим веб-сервер для Windows Vista и далее») (доступна по адресу msdn2.microsoft.com/magazine/cc163453.aspx), которая позволяет быстро ознакомиться с улучшениями, имеющимися в IIS 7.0.
Также стоит прочитать запись в блоге группы Microsoft.com, названную "The Tasty Morsels Found in Dogfood" («Вкусные кусочки, найденные в собачьем корме») (доступна на go.microsoft.com/fwlink/?LinkId=117436). Запись сводит воедино первоначальные впечатления членов группы от IIS 7.0. Вкратце, они выстроили основные улучшения следующим образом:
  1. Упрощенная установка.
  2. Отличная совместимость
  3. Ликвидация метабазы.
  4. Централизованная настройка через файл applicationHost.config, помещенный в общей папке с адресом в формате UNC.
  5. Делегированная настройка посредством файлов web.config в каталогах приложений
  6. Улучшенные средства управления.
  7. Отслеживание неудачных запросов.
  8. Запрос фильтрации без необходимости в URLScan.
  9. Упрощенная доступность синхронизации содержимого через общие папки с адресами в формате UNC.
  10. Кэширование исходящих данных динамического содержимого.
Упрощенная установка определенно находится в моем списке. В своей записи в блоге группа Microsoft.com показывает, как можно развернуть все компоненты IIS 7.0 (или само собой, только нужные пользователю компоненты) с помощью единственной командной строки. Я с радостью включил этот подход в инструкции для моей лаборатории тестирования с помощью командной строки, показанной на рис. 3.
Следует признать, что эта команда довольно длинна. (Если требуется скопировать эту команду, я рекомендую скопировать ее с веб-узла TechNet Magazine и вставить, а не набирать вручную.) Хотя эта команда помещает все доступные модули на компьютер IIS 7.0, она не включает PHP. В составе IIS 7.0 отсутствует PHP, и мысль о загрузке и установке пакетов Debian через Интернет является чуждой концепцией для диспетчера пакетов Windows® (pkgmgr.exe). Тут-то и появляется на сцене пакет автоматической установки Windows (Automated Installation Kit – AIK).
Рис. 3. Развертывание компонентов IIS 7.0 с помощью единственной командной строки
start /w pkgmgr.exe /iu:IIS-WebServerRole;IIS-WebServer;IIS-CommonHttpFeatures;IIS-StaticContent;IIS-DefaultDocument;IIS-DirectoryBrowsing;IIS-HttpErrors;IIS-HttpRedirect;IIS-ApplicationDevelopment;IIS-ASPNET;IIS-NetFxExtensibility;IIS-ASP;IIS-CGI;IIS-ISAPIExtensions;IIS-ISAPIFilter;IIS-ServerSideIncludes;IIS-HealthAndDiagnostics;IIS-HttpLogging;IIS-LoggingLibraries;IIS-RequestMonitor;IIS-HttpTracing;IIS-CustomLogging;IIS-ODBCLogging;IIS-Security;IIS-BasicAuthentication;IIS-WindowsAuthentication;IIS-DigestAuthentication;IIS-ClientCertificateMappingAuthentication;IIS-IISCertificateMappingAuthentication;IIS-URLAuthorization;IIS-RequestFiltering;IIS-IPSecurity;IIS-Performance;IIS-HttpCompressionStatic;IIS-HttpCompressionDynamic;IIS-WebServerManagementTools;IIS-ManagementConsole;IIS-ManagementScriptingTools;IIS-ManagementService;IIS-IIS6ManagementCompatibility;IIS-Metabase;IIS-WMICompatibility;IIS-LegacyScripts;IIS-LegacySnapIn;IIS-FTPPublishingService;IIS-FTPServer;IIS-FTPManagement;WAS-WindowsActivationService;WAS-ProcessModel;WAS-NetFxEnvironment;WAS-ConfigurationAPI

# Command provided by the Microsoft.com team (blogs.technet.com/mscom).
С помощью AIK можно создать специальный установочный диск DVD для Windows Server 2008, в составе которого есть IIS 7.0 и PHP 5. Можно также включить туда MySQL, файлы веб-приложений и любые другие компоненты, необходимые при развертывании. Все компоненты могут быть частью установки Windows Server 2008, что позволяет применить модификации по единому образцу на все своих веб-серверах. При этом нет необходимости в командных строках или во внесении изменений в файл настроек.
Можно даже создать специальный диск DVD для полностью автоматических установок. В AIK имеются документация и средства для создания файла AutoUnattend.xml, который можно затем поместить в корневую папку диска DVD. В файле Custom Image Deployment.htm в сопровождающем материале имеются поэтапные указания.
Многие администраторы также согласны, что совместимость является ключевым улучшением. Приступая к работе, я ожидал некоторых проблем совместимости с DotNetNuke и osCommerce, но переход на IIS 7.0 оказался довольно безболезненным, несмотря на то, что оба эти веб-приложения содержат расширенные возможности, такие, как проверку подлинности на основе форм и удобные для поисковиков URL-адреса.
В случае DotNetNuke я не встретил никаких проблем, пока не перешел к случаю сложной веб-фермы с общим использованием содержимого папок с адресами формата UNC на 64-разрядной платформе. Но и тогда проблема была довольно мелкой. В конечном счете, эта улучшенная совместимость означает, что меньше времени уходит на приспособление веб-приложений к работе на IIS 7.0.
Если же вдруг возникнут проблемы совместимости с веб-приложениями, то, без сомнения, будет оценена новая возможность встроенной поддержки диагностики и отслеживания. Подробная диагностическая информация содержит глубокий смысл, а предлагаемые пути решения полезны и реально работают.
На рис. 4 показана диагностическая информация, которая будет получена при запуске DotNetNuke 4.7 на IIS 7.0 в интегрированном режиме. В данном примере имеются три варианта (показанные в разделе «Что можно предпринять»). Изменение приложения для поддержки интегрированного режима является, вероятно, лучшим выбором для разработчиков DotNetNuke. Игнорирование ошибки – вероятно, плохая идея. Мне нравится третий вариант, в котором включается классический режим путем переключения веб-приложения на Classic .NET AppPool, поскольку мне нужно использовать неизмененный DotNetNuke 4.7 на IIS 7.0.
Рис. 4 Диагностическая информация для DotNetNuke, работающего в интегрированном режиме (щелкните изображение, чтобы увеличить его)

Архитектура IIS
Может возникнуть вопрос о том, что из себя представляют эти интегрированный и классический режимы и почему они влияют на приложение ASP.NET (DotNetNuke), но не на приложение PHP (osCommerce). Чтобы лучше понять это, необходимо сперва взглянуть на архитектуру IIS 7.0. В предыдущих версиях среда выполнения ASP.NET была интегрирована в центральный веб-сервер в основном через расширение ISAPI (aspnet_isapi.dll). IIS 7.0, с другой стороны, позволяет подключать модули ASP.NET напрямую к центральному веб-серверу через модуль HTTP глобального уровня, именуемый ManagedEngine, который загружает вспомогательную библиотеку DLL ASP.NET (webengine.dll) в конвейер обработки запросов IIS 7.0.
Модули в машинном коде используют интерфейс API IIS Web Server Core для регистрации конкретных событий на конвейере, таких как BeginRequest, AuthenticateRequest, AuthorizeRequest и ExecuteRequestHandler. ManagedEngine также предоставляет необходимую поддержку для интеграции модулей ASP.NET в конвейер запросов. С помощью этой новой архитектуры службы IIS 7.0 могут вызывать собственные модули и модули ASP.NET на любом этапе обработки запроса и вне зависимости от типа запрашиваемого содержимого.
В качестве примера давайте рассмотрим проверку подлинности пользователя ASP.NET. В IIS 6.0 для модуля HTTP на основе ASP.NET возможно регистрироваться на события OnAuthenticate (такие как FormsAuthentication.OnAuthenticate и WindowsAuthentication.OnAuthenticate) для установки учетных данных пользователя в текущем HttpContext. Это отлично работает в среде выполнения ASP.NET, но такой код ASP.NET нельзя использовать для защиты ресурсов, предоставляемых через веб-приложения на основе PHP.
Согласно настройке карты сценариев, службы IIS 6.0 перенаправляют запросы для типов содержимого ASP.NET к aspnet_isapi.dll, но не перенаправляют запросы для типов содержимого PHP к расширению ISAPI для ASP.NET. В конце концов, ASP.NET не обрабатывает код PHP, но это также значит, что код проверки подлинности ASP.NET не выполняется, если запрошена страница PHP. Таким образом, в случае IIS 6.0 необходимо продублировать логику проверки подлинности, поскольку приложениям на PHP приходится применять собственный механизм проверки подлинности.
Службы IIS 7.0 используют управляемую событиями модель обработки, поддерживающую смешивание и согласование отдельных модулей в конвейере запросов. Помимо прочих компонентов, в IIS 7.0 входят управляемые модули WindowsAuthentication и FormsAuthentication, которые создают события OnAuthenticate, когда конвейер запроса запускает событие AuthenticateRequest. Теперь модуль в машинном коде, такой как RequestFilteringModule или IpRestrictionModule, может обрабатывать событие BeginRequest, чтобы отвергать опасные запросы как можно раньше, после чего запускать специальный код проверки подлинности ASP.NET в момент события AuthenticateRequest и предоставить FastCgiModule возможность запустить обработчик сценариев PHP (php-cgi.exe) в момент события ExecuteRequestHandler для обработки страниц PHP.
Эта интегрированная архитектура избавляет веб-разработчиков от необходимости дублировать код для реализации распространенной бизнес-логики. Пользовательский вариант проверки подлинности ASP.NET можно использовать для защиты всех своих ресурсов IIS, включая приложения PHP. Кроме того, через модули ASP.NET можно выполнять другие задачи предобработки и послеобработки, такие как переписывание URL-адресов, пользовательское отслеживание и ведение журнала ошибок.

Интегрированный и классический режимы
Побочным эффектом этой новой архитектуры является то, что существующие приложения ASP.NET могут потребовать изменений в коде и настройке, которые разработчикам приложений следует выполнить, чтобы гарантировать отсутствие вызванных изменениями конфликтов модулей в конвейере запросов. Но если немедленно перенести существующее веб-приложение нельзя, то можно включить классический режим в пуле приложений, который рабочий процесс использует для выполнения веб-приложения. Службы IIS 7.0 не загружают ManagedEngine в рабочие процессы классического режима, из чего в данном случае следует, что конвейер запросов не может разрешать или вызывать модули ASP.NET. Вместо этого IIS 7.0 активирует ряд обработчиков ISAPI, основанных на IsapiModule (aspnet_isapi.dll), для обработки типов содержимого ASP.NET подобно IIS 6.0. Это можно увидеть, если проанализировать раздел обработчиков в system.webServer в файле applicationHost.config, который по умолчанию можно найти в папке %WinDir%\System32\InetSrv\Config.
Проведите поиск строки «aspx» в качестве примера, и будет найдена одна запись, указывающая PageHandlerFactory-Integrated (загруженную в рабочие процессы пула приложений интегрированного режима, согласно параметру preCondition="integratedMode") и другие записи, указывающие на PageHandlerFactory-ISAPI-2.0 и PageHandlerFactory-ISAPI-2.0-64 (загруженные в рабочие процессы пула приложений классического режима, согласно параметру preCondition="classicMode").
Поскольку режим конвейера устанавливается на уровне пула приложений, IIS 7.0 может запускать веб-приложения в интегрированном и классическом режимах одновременно. А рабочим процессам лишь нужно работать в разных пулах приложений, но они могут быть размещены на одном сервере.
Не забывайте, что интегрированный и классический режимы влияют лишь на то, как IIS 7.0 интегрирует ASP.NET в конвейер запросов. Эти режимы конвейера не влияют на приложения PHP напрямую. FastCgiModule и все прочие модули в машинном коде загружаются без предварительных условий, связанных с режимом конвейера, как в интегрированном, так и в классическом режиме. Для выполнения механизма сценариев PHP на IIS 7.0 желательно использовать интерфейс FastCGI Вместо использования FastCGI можно также создать сопоставление обработчика для механизма сценариев PHP с помощью CGI, либо можно использовать IsapiModule в сочетании PHP-ISAPI (php4isapi.dll).
Я, впрочем, думаю, что эти альтернативные конструкции в манере IIS 6.0 теперь устарели, поскольку FastCGI предлагает значительно улучшенные производительность и стабильность. CGI работает медленнее, поскольку службам IIS необходимо инициализировать новый процесс CGI для каждого запроса HTTP, тогда как FastCGI повторно использует процессы CGI для нескольких запросов. Для ISAPI требуется сборка PHP, поддерживающая многопоточное выполнение, а она требует большего расхода ресурсов, чем выполнение сборки PHP, не поддерживающей многопоточное выполнение.
Что, возможно, еще более важно, не все расширения PHP доступны в версии, поддерживающей многопоточное выполнение, а запуск не поддерживающих многопоточное выполнение расширений с помощью ISAPI – плохая мысль, поскольку это может привести к проблемам со стабильностью на сервере. FastCGI, с другой стороны, является средой с единственным параллелизмом, подобно CGI. Среда FastCGI, используемая для выполнения не поддерживающей многопоточное выполнение сборки PHP, стабильна и быстра, так что ее использование для запуска PHP 5 на IIS 7.0 является очевидным выбором. Она также доступна на IIS 6.0 для тех, кто еще не готов перейти на IIS 7.0.

Модули и функции
Архитектура IIS 7.0 имеет высокую степень модульности – или, как сформулировали это разработчики IIS, компонентный набор функций. Это хорошая новость для веб-администраторов, которые стремятся сделать занимаемый объем памяти и открытую для атак область IIS 7.0 настолько маленькими, насколько это возможно. Включая различные модули или, возможно, даже заменяя стандартные модули на пользовательские, можно полностью контролировать компоненты IIS 7.0 на своих веб-серверах.
Чтобы запустить ASP.NET в интегрированном или классическом режиме, а также запустить приложения PHP на том же сервере, нужно установить, как минимум, роль веб-сервера и основные модули для поддержки обработки запросов, настройки сервера ASP.NET, ISAPI и CGI (куда входит модуль FastCGI). Для этого можно использовать следующую командную строку:
start /w pkgmgr /iu:IIS-WebServerRole;
WAS-WindowsActivationService;WAS-ProcessModel;
WAS-ConfigurationAPI;IIS-ASPNET;
IIS-NetFxExtensibility;WAS-NetFxEnvironment;
IIS-ISAPIExtensions;IIS-ISAPIFilter;IIS-CGI
Я обычно предпочитаю устанавливать IIS 7.0 со всеми доступными возможностями на моем промежуточном сервере, чтобы гарантировать доступность всех компонентов и административных средств, необходимых для быстрой организации работы веб-приложений. Моя стратегия состоит в том, чтобы убедиться, что все работает, после чего я сужаю настройку, удаляя службы ролей и отключая модули. Когда веб-приложение начинает барахлить, я добавляю обратно только что удаленные службы ролей и модули.
Также имеется возможность использовать диспетчер пакетов (pkgmgr.exe) или средство командной строки IIS 7.0 (appcmd.exe), или прямое внесение изменений в раздел globalModules в файле applicationHost.config, но я нахожу очень удобными графические средства. Не забывайте, что некоторые модули, такие как RequestFilteringModule и StaticCompressionModule, весьма полезны, даже если они, строго говоря, и не требуются для запуска веб-приложения. В случае удаления модуля, который требуется пулу приложений, при попытке доступа к веб-приложению будет получена ошибка HTTP, как показано на рис. 5.
Рис. 5 Приложение ASP.NET не будет работать в классическом режиме, поскольку IsapiModule отсутствует(щелкните изображение, чтобы увеличить его)
Примечание: наилучшим вариантом является использование одного и того же набора модулей на всех своих серверах IIS 7.0. Чтобы проверить установленные компоненты, перейдите на HKEY_LOCAL_MACHINE\Software\Microsoft\InetStp\Components\ и проверьте разделы реестра. Значение 0000 0001 формата REG_DWORD для параметра реестра, такого как NetFxEnvironment или CGI, указывает, что соответствующий компонент установлен.

Перенос веб-приложений
Достаточно теории, пора мне закатать рукава и заняться переносом веб-приложений на IIS 7.0. Как упоминалось ранее, на моем промежуточном сервере работают службы IIS 7.0 со всеми доступными компонентами и не поддерживающая многопоточную обработку сборка PHP 5, зарегистрированная с помощью FastCGI. Прежде чем приступать, мне необходимо задать несколько базовых вопросов:
  • Нужна ли веб-приложению система управления базами данных, такая как SQL Server или MySQL?
  • Нужно или мне установить или настроить дополнительные компоненты, такие как подключения ODBC, объекты COM или сертификаты SSL?
  • Требует ли веб-приложение специальных учетных записей служб и повышенных прав локального или удаленного доступа к общим файловым ресурсам и прочим ресурсам?
  • Имеются ли в нем любые зависимости от функций конкретных платформ, недоступных на IIS 7.0, такие как зависимость от модуля Apache в плане переписывания URL-адресов (mod_rewrite)?
Ответы на подобные вопросы помогут заставить веб-приложения быстрее работать на IIS 7.0. Например, при попытке переноса приложения PHP, использующего mod_rewrite, с Apache 2.2 (скажем, ради удобства работы поисковиков или для предотвращения кражи пропускной способности через связанно-встроенные образы) возникнут проблемы, если не применить на IIS 7.0 пользовательское совместимое решение для переписывания URL-адресов. К счастью, osCommerce не требует функций mod_rewrite на IIS 7.0, но некоторые пакеты оптимизации работы поисковиков могут требовать его.
Теперь, когда я определил и установил необходимые дополнительные компоненты на промежуточном сервере, я готов к установке и запуску моих веб-приложений. Опять же, мне желательно задать себе несколько вопросов:
  • Какова простейшая настройка, которую я могу использовать для поддержки веб-приложения?
  • Какая настройка используется в производственной среде сейчас?
  • Могу ли я оптимизировать настройку веб-приложения на новой платформе?
  • Каков минимальный набор служб ролей и модулей, необходимых веб-приложению для работы в желаемой настройке?
Быстрейший способ убедиться, что веб-приложение работает – это заставить его работать в простейшей настройке. Если все выглядит отлично, пора применить настройку, подобную существующей производственной среде, и импортировать производственные данные в базы данных тестирования. Само собой, некоторые проблемы могут всплыть только в расширенных настройках.
Возможности для улучшения также могут быть замечены при зеркальном отражении производственной настройки в лаборатории тестирования. Помещение файла applicationHost.config в общую папку с путем в формате UNC является отличным способом централизовать настройку нескольких веб-серверов. Чтобы повысить отказоустойчивость через избыточность и синхронизацию содержимого, подумайте насчет применения репликации распределенной файловой системы (Distributed File System – DFS) – основанного на состоянии модуля репликации с несколькими хозяевами, доступного на Windows Server 2003 R2 и Windows Server 2008. Также можно свести к минимуму требуемое пространство хранилищ на веб-интерфейсах путем помещения файлов содержимого веб-приложений в общие папки с путем в формате UNC.
Другие потенциальные оптимизации могут затрагивать безопасность или динамическое кэширование. Здесь я не касался оптимизаций безопасности и производительности в моей лаборатории тестирования, поскольку они выходят за рамки данной статьи. Не производил я и настройки DFS, чтобы избежать установки новых серверов. Поэтапные указания в сопровождающем материале предоставляют упрощенный пример того, как разместить файл applicationHost.config и веб-содержимое в общих папках с путем в формате UNC. А на рис. 6 показано создание веб-фермы на основе UNC с помощью DFS.
Рис. 6 Развертывание веб-фермы с помощью файла applicationHost.config и веб-содержимого в общих папках с путем в формате UNC (щелкните изображение, чтобы увеличить его)

Заключение
IIS 7.0 – впечатляющая платформа веб-сервера. Ее базовая архитектура переработана и в то же время поддерживает почти стопроцентную обратную совместимость с IIS 6.0. Она должна быть способна использовать большинство существующих веб-приложений ASP.NET без изменений. Но, учитывая размах изменений архитектуры, надеяться на полное отсутствие проблем с совместимостью нельзя.
Независимо от того, планируется ли перенос на IIS 7.0 веб-приложений ASP.NET или PHP, лучшим является поэтапный подход, при котором основное внимание уделяется правильному планированию, подготовке, тестированию и документированию изменений в коде и настройке.
Службы IIS 7.0 стоят такой работы. Там имеется множество улучшений в таких областях, как безопасность, производительность, настраиваемость и гибкость. Рассказ о всех них занял бы целую книгу. Централизованная настройка и совместное использование содержимого на основе общих папок с путем формата UNC, делегированная настройка посредством файлов web.config в каталогах приложений, улучшенные средства управления, подробная диагностическая информация и отслеживание неудачных запросов, а также динамическое кэширование исходящих данных наверняка завоюют любовь веб-администраторов.
Возможность смешивать модули в машинном коде и управляемые модули в конвейере обработки процессов помогает разработчикам ASP.NET. А улучшения безопасности и стабильности, связанные с FastCGI в IIS 7.0 – отличная новость для разработчиков приложений на PHP.
И еще одна важная вещь, помогающая специалистам по ИТ успешно работать с IIS 7.0: портал сетевого сообщества Microsoft IIS (www.iis.net). Он содержит всю необходимую информацию, включая подробные статьи о новой архитектуре, исходный код для разработчиков C++ и ASP.NET, демонстрирующий, как создавать модули IIS 7.0, и поэтапные указания по установке и запуску приложений PHP. На этот веб-узел определенно стоит заглянуть. Он является хорошим местом для получения ответов на все вопросы, относящиеся к IIS.

Фергус Страхан (Fergus Strachan) - основатель и директор консультационной фирмы Maestra Ltd London, которая специализируется на разработке информационной инфраструктуры и поддержке управления проектов, обслуживая международные банки и образовательные учреждения в Великобритании. Он пишет статьи о серверных технологиях Майкрософт и является автором книги Integrating ISA Server 2006 with Microsoft Exchange 2007 («Интеграция ISA Server 2006 с Microsoft Exchange 2007»). Он также является соавтором книги Microsoft Exchange Server 2003 Resource Kit («Комплект Microsoft Exchange Server 2003 Resource Kit»).

© 2005 Корпорация Майкрософт и CMP Media LLC. Все права защищены; запрещено частичное или полное воспроизведение без специального разрешения.


Связь и совместная работа
Планирование перехода на единую систему обмена сообщениями
Джефф Гудвин (Jeff Goodwin)
Краткий обзор:
  • Краткая история голосовой почты
  • Что необходимо учесть при планировании перехода
  • Стратегии перехода
  • Задачи, возникающие в предприятиях с несколькими филиалами

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

Краткая история голосовой почты
Поскольку в действительности вы не можете планировать способ достижения конечного пункта, не зная, откуда ваше путешествие начинается, я хочу сделать шаг назад и дать краткий обзор систем голосовой почты — как того, откуда они появились, так и того, какова их архитектура. Существуют споры о том, кто первым изобрел систему голосовой почты. Однако, первая появившаяся в продаже система голосовой почты называлась VMX, что раскрывается как Voice Message Exchange (обмен голосовыми сообщениями).
Исходно VMX была разработана в качестве способа обеспечения голосовой связи между сотрудниками компании, точно так же, как в настоящее время используется электронная почта. В системе имелись команды для отправки сообщения, пересылки сообщения и ответа на сообщение. При наличии сообщения пользователь получал уведомление. Существовали разные методы уведомления, включая вызов (звонок адресату по заданному номеру телефона) и световую индикацию ожидающего сообщения (световой индикатор на телефоне адресата).
По мере приобретения VMX популярности организации приступили к объединению своих систем голосовой почты в общую сеть. Это привело к возникновению решения для корпоративной голосовой почты, позволявшей сотрудникам отправлять широковещательные сообщения в соответствии с корпоративными списками рассылок.
Конечно, для обеспечения способа взаимодействия с системой голосовой почты необходимо было создать пользовательский интерфейс тонального набора (TUI). Интерфейсы TUI с годами менялись и, к сожалению, для голосовой почты не существует стандартного интерфейса. Если на вашем сотовом телефоне есть голосовая почта, вероятно вы часто слышали что-нибудь вроде «нажмите 1 для получения голосовой почты.» Но с распространением систем голосовой почты, управляемых речью, в которых используются голосовые пользовательские интерфейсы (VUI), интерфейс TUI уже не имеет такого важного значения, как когда-то. Однако не следует недооценивать то, что пользователи могут испытывать привязанность к конкретному интерфейсу.
Используемые в настоящее время корпоративные системы голосовой почты основываются на двух разных архитектурах: распределенной и централизованной. На рис. 1 показаны офисы в Сиэтле, Нью-Йорке и Остине, имеющие распределенную архитектуру голосовой почты, в которой системы голосовой почты существуют бок о бок в каждом из этих филиалов. В отличие от них, в офисах в Лондоне, Париже и Глазго используется централизованная модель, в которой инфраструктура УАТС объединена в сеть, и все вызовы направляются обратно в центральное местоположение в Лондоне. У каждой модели есть свои преимущества и недостатки. Но следует отметить, что даже в случае распределенной модели можно системы голосовой почты объединять в сеть для доставки сообщений между филиалами.
Рис. 1 Две распространенные модели архитектуры голосовой почты(щелкните изображение для его увеличения)
Существуют три основные причины, по которым организация может предпочесть распределенную модель: необходимость в локальной доступности, наличие разнородных систем УАТС, которые невозможно объединить в сеть, и единообразные ограничения для абонентских групп.
Некоторым организациям требуется такая система голосовой почты, чтобы в случае сбоя в работе сети локальная УАТС и система голосовой почты продолжали нормально работать, обеспечивая филиалу полный набор функций системы. Системы интерактивного речевого ответа (IVR) продолжат работу, и звонящие извне смогут по-прежнему оставлять сообщения. В сущности, это никак не скажется на конечных пользователях, и работа будет продолжаться в нормальном режиме. Возможно, это покажется знакомым — именно по этой же причине многие организации предпочитают локализовать свои серверы, на которых работает Microsoft® Exchange Server. Вашей организации может потребоваться выполнить оценку рисков, чтобы определить, является ли необходимой локальная бесперебойность работы.
Если организация расширяется за счет приобретения других организаций, удаленные филиалы зачастую имеют платформы УАТС, которые невозможно объединить в сеть вместе с остальной частью инфраструктуры. В этом случае организации могут либо заменить УАТС, что может оказаться дорогим проектом, либо оставить в филиале все по-прежнему и включить в сеть платформу голосовой почты для обеспечения беспрепятственного обмена голосовыми сообщениями. Существуют также серверы сторонних производителей, которые помогут объединить в сеть разнородные системы голосовой почты.
Для объединения в сеть нескольких УАТС требуется единообразная абонентская группа (или UDP). UDP предусматривает, что телефонные добавочные номера и добавочные номера голосовой почты не должны перекрываться. На рис. 1 можно заметить, что Сиэтл, Нью-Йорк и Остин имеют перекрывающиеся диапазоны добавочных номеров. Это объясняется тем, что для филиалов, находящихся в Соединенных Штатах, нет UDP. UDP можно создать, расширив диапазон добавочных номеров до 7 или 10 цирф, но при этом возникают другие проблемы.
Вам может потребоваться изменить шаблоны набора на всех телефонах, изменить все добавочные номера пользователей в УАТС и изменить все приложения, интегрированные в систему. Это может вызвать недовольство сотрудников, которым придется помнить 7- или 10-значные номера, чтобы позвонить в соседнее помещение.
Хотя с годами эти базовые функции и архитектурные изменения совершенствовались, основные принципы голосовой почты остались неизменными. Обмен сообщениями, объединение в сеть, способы уведомления, пользовательский интерфейс и архитектура — все это важные факторы, о которых следует помнить при планировании перехода.

Планирование перехода
Единая система обмена сообщениями привносит изменения во все составляющие организации — от способа взаимодействия пользователей с голосовой почтой до варианта архитектурного проектирования способа, которым администраторы осуществляют управление. При переходе к единой системе обмена сообщениями необходимо учесть все эти отличия. Из этого следует, что требуется контрольный список с перечнем всего, что необходимо учесть при планировании перехода.
Сеть обмена сообщениями Любая организация, осуществляющая переход от устаревшей платформы голосовой почты к единой системе обмена сообщениями, должна пережить период сосуществования систем. Если ваша организация уже развернула сеть обмена сообщениями, представляющую собой систему для взаимодействия разных систем голосовой почты, просто добавьте единую систему обмена сообщениями в список существующих систем. Я настоятельно рекомендую сеть обмена сообщениями всем организациями, имеющим несколько площадок с отдельными системами голосовой почты или системами УАТС.
Инфраструктура При проектировании инфраструктуры для единой системы обмена сообщениями потребуется принять решение относительно требований к сети, интеграции телефонии, размещения сервера и т.п. Если вы еще не знакомы с основными стратегиями развертывания, прочитайте мою предыдущую статью «Развертывание единой системы обмена сообщениями с использованием Exchange Server 2007» (см. веб-страницу technet.microsoft.com/magazine/cc137737).
Автосекретари Во многих системах имеется несколько автосекретарей — например, разные автосекретари для дневного времени, для ночного, для разных отделов. Придется поработать с группой связи вашей организации, чтобы создать зеркальное отображение автосекретарей на устаревших системах голосовой почты.
Индикация ожидающих сообщений Вам, возможно, хотелось бы, чтобы ваше решение работало без индикаторов ожидающих сообщений, но ваши пользователя, вероятно, потребуют эту функцию. Поэтому не стоит недооценивать привязанность пользователей к этим уведомлениям в виде красных световых индикаторов. К счастью, существует несколько компаний, разработавших приложения для индикации сообщений для Exchange Server.
Поддержка факсов Многие устаревшие платформы голосовой почты поддерживают входящие факсимильные сообщения. Единая система обмена сообщениями Exchange также поддерживает функции работы со входящими факсимильными сообщениями, поэтому вам может потребоваться запланировать поддержку этой функции в новом развертывании.
Интерактивный речевой ответ В некоторых устаревших платформах голосовой почты поддерживаются приложения интерактивного речевого ответа (IVR), не имеющие аналогов в единой системе обмена сообщениями Exchange. Возможно, потребуется сохранить эти системы до момента, когда будет найдена подходящая альтернатива.
Администрирование Единая система обмена сообщениями Exchange основана на Active Directory® и роли сервера почтовых ящиков Exchange. Потребуется предусмотреть, каким образом развертывание единой системы обмена сообщениями скажется на администрировании, системных требованиях и т.п..
Пользовательский интерфейс При развертывании нового пользовательского интерфейса необходимо обеспечить обучение пользователей. В единой системе обмена сообщениями Exchange используется интерфейс, очень напоминающий тот, который используется большинством поставщиков сотовых телефонов, поэтому большая часть пользователей должна освоиться с ним на интуитивном уровне. В нем используется также распознавание речи, чтобы у пользователей не было необходимости пользоваться тональным набором. В Exchange Server он называется Outlook® Voice Access.
Обучение Единая система обмена сообщениями привносит изменение парадигмы в способ, которым пользователи устанавливают связь и используют голосовую почту. Помимо интерфейса пользователя, необходимо дать пользователям практические ревомендации и представить новые, более экономные способы, которые они могут использовать для связи. Например, пользователи могут не знать, как взаимодействовать с голосовой почтой в почтовом ящике электронной почты или как настроить некоторые дополнительные параметры единой системы обмена сообщениями.

Практические стратегии перехода
Несомненно, при переводе большой организации на единую систему обмена сообщениями возникают непростые задачи. Однако, работая в единой среде связи более 10 лет, я наблюдал, как даже организации с самой сложной структурой и очень специальными требованиями успешно осуществляли такой переход.
Независимо от того, работаете ли вы с организацией, имеющей одну или несколько площадок, будет очень полезно построить стратегию перехода исходя из следующих пяти основных этапов.
  1. Создайте план и разработайте проект решения.
  2. Установите и настройте роль сервера единой системы обмена сообщениями.
  3. Выполните перевод пробной группы.
  4. Пересмотрите свой проект на основе информации, полученной от пробной группы.
  5. Выполните перевод пользователей.
Конечно, организации с несколькими филиалами сталкиваются с определенными задачами, обычно не встречающимися в организациях с одной площадкой. Эти задачи обсуждаются отдельно на боковой панели «Задачи, возникающие в предприятиях с несколькими филиалами».
Планирование и проектирование решения является самостоятельным наиболее важным этапом процедуры перехода. Рекомендую создать для этого проекта группу единой системы обмена сообщениями. В эту группу должны входить представители из разных частей организации, имеющие опыт в области телекоммуникации, Active Directory, Exchange, сетей, безопасности, обучения и управления проектами. Получите также подробную схему архитектуры инфраструктур существующей УАТС вашей компании, голосовой почты и электронной почты.
После создания проекта можно устанавливать и настраивать роль сервера единой системы обмена сообщениями. Не бойтесь установить сервер единой системы обмена сообщениями параллельно с существующей устаревшей системой голосовой почты. Только обязательно выполняйте практические рекомендации, описанные в документах.
Теперь вы готовы испытать свой сервер единой системы обмена сообщениями. Определите и переведите на новую систему небольшую пробную группу. Подойдет группа от 25 до 50 пользователей. Тщательно выбирайте пользователей, чтобы создать пробную группу, состоящую из разных групп пользователей, – от сотрудинков, занимающихся связью и ИТ, до руководителей отделов и сотрудников отдела продаж. Работая с таким широким диапазоном специалистов, вы лучше поймете, достиг ли цели ваш проект, какие конкретные требования необходимо учесть, какое обучение пользователей может потребоваться и т.д.
После сбора впечатлений от пробной группы необходимо пересмотреть проект, чтобы исправить недочеты, вскрывшиеся в процессе тестирования. Конкретнее, вернитесь к пунктам, обсуждавшимся в разделе «Что необходимо учесть», и убедитесь в том, что все пункты выполнены в соответствии с особенностями вашей организации. Обратите внимание, что большинство сделанных здесь изменений обычно относятся к обучению.
Заключительным этапом является перевод пользователей. Существует множество точек зрения относительно способа перевода системы в полноценный рабочий режим. Две основные методики — это постепенный переход и мгновенное переключение.
При выборе постепенного перехода сообщества пользователей, происходящего в течение недель или месяцев, создаются «островки» голосовой почты среди пользователей, эксплуатирующих устаревшую и единую систему обмена сообщениями. Это препятствует перенаправлению сообщений между пользователями посредством голосовой почты. Если ваш проект не предусматривает создание сети обмена сообщениями, часть деловых связей будет нарушена. Если вы готовы к этому, рекомендую обеспечить включение решения для сети обмена сообщениями в исходный проект.
В случае мгновенного переключения все пользователи переводятся за один этап. Как правило, организации выполняют переход такого типа в течение выходных дней, чтобы осталось время для тестирования системы, внесения изменений в настройку и отката перехода в случае возникновения серьезного препятствия.
Вне зависимости от выбранного метода необходимо провести обучение сотрудников службы поддержки по общим вопросам, полученным от пробной группы пользователей. Следует также убедиться, что сотрудники службы поддержки хорошо справляются с выполнением основных задач, в том числе включения пользователя, проверки факта включения пользователя и изменение пароля.

Подробный разбор этапов перехода
Во время разбора примера перехода помните о том, что основная цель успешного перехода к единой системе обмена сообщениями заключается в перемещении почтового ящика голосовой почты из устаревшей платформы голосовой почты в единую систему обмена сообщениями с минимально возможным перерывом в обслуживании пользователей (как внутренних, так и внешних).
На рис. 2 подробно представлена архитектура организации. Изменение этой смешанной архитектуры Exchange не планируется. Основной центр данных офисов в США находится в Сиэтле. Все приложения ИТ для Остина обслуживаются из Сиэтла, а нью-йоркский офис обеспечивает работу локализованных служб Exchange. Голосовая почта для точек в США распространяется посредством разнородной инфраструктуры УАТС. Технически инфраструктуру УАТС невозможно включить в сеть для обеспечения централизованной голосовой почты. Европейские офисы, напротив, имеют единый центр данных, находящийся в Лондоне. Все приложения ИТ и связи в Евроае обслуживаются из этого единого центра данных.
Рис 2. Пример архитектуры до перехода (щелкните изображение для его увеличения)
В целом инфраструктура голосовой почты основана на платформе Octel (теперь она называется Avaya). Все системы голосовой почты были объединены в сеть с помощью OAN (Octel Analog Networking), коммерческого сетевого протокола, использующего аналоговые телефонные линии и междугородние вызовы для отправки сообщений включенной в сеть голосовой почты. Эта архитектура обеспечивает обмен голосовыми сообщениями между филиалами в рамках всей организации.
Задачи, возникающие в предприятиях с несколькими филиалами
При развертывании единой системы обмена сообщениями в предприятиях с несколькими филиалами может возникнуть любое число сложных задач. К счастью, можно воспользоваться опытом решения задач, уже возникавших в других организациях. В рамках этой статьи невозможно рассмотреть все задачи, но мы обсудим наиболее распространенные из тех, с которыми я сталкивался при работе с разными организациями.
«Используется централизованная архитектура Exchange Server и смешнная среда телефонии.»
Проект для распределенной среды создается легко. Устанавливается сервер единой системы обмена сообщениями и объединяется с локальной УАТС из каждого филиала. А если у вас имеется централизованная или даже смешанная среда? Вам необходимо задаться вопросом о том, требуется ли локальная бесперебойность работы от единой системы обмена сообщениями. При локальной бесперебойности работы единой системы обмена сообщениями, если данная точка теряет связь в центральным сервером Exchange, функции автосекретаря по-прежнему работают, и звонящие извне (не исключено, что это клиенты) могут оставлять сообщения. Ответ, вероятно, будет зависеть от того, насколько работа всего предприятия зависит от данной точки и насколько управляемым будет решение.
Если необходима локальная бесперебойность для всего филиала, хорошим вариантом станет удаленный сервер единой системы обмена сообщения, установленный в данном филиале. Если такого требования нет, в филиале можно установить шлюз SIP. Единая система обмена сообщениями Exchange обладает гибкостью, которая позволяет обойтись без объединения в сеть инфраструктуры УАТС и не требует единообразной абонентской группы.
«Выполняется обновление архитектуры сервера Exchange.»
Многие клиенты сомневаются относительно возможности перехода на единую систему обмена сообщениями во время обновления инфраструктуры Exchange. Мой совет состоит в том, что если решение о переходе на единую систему обмена сообщениями принято, двигайтесь дальше и осуществляйте переход одновременно с обновлением сервера Exchange. Просто следуйте планам по обновлению — никаких существенных сложностей к проекту не добавится.
«Имеется множество небольших филиалов с числом сотрудников менее 10, и в некоторых филиалах нет УАТС.»
В небольших филиалах, в которых имеется УАТС, все, что предстоит сделать, это просто установить шлюз SIP. Для тех филиалах, где нет УАТС, существуют методики телефонии, которые можно использовать для пересылки звонков на центральную УАТС с целью направления вызовов в единую систему обмена сообщениями. Коротко говоря, в небольших филиалах вашей организации можно развернуть службы единой системы обмена сообщениями с очень небольшими затратами.
Важно отметить, что в действительности такие небольшие филиалы предоставляют прекрасную базу для тестирования перехода. Одна из распространенных стратегий перехода заключается в запуске этого процесса на границе сети и последующем продвижении к центру. Сначала осуществляется перевод небольших филиалов, затем проводится обсуждение в группе единой системы обмена сообщениями с целью выявления удачных решений и возникших сложностей. Эти уроки могут быть учтены при переводе следующего филиала.
Группа единой системы обмена сообщениями приняла решение начинать переход с границы сети и продвигаться к центру. Во всех точках размещение сервера единой системы обмена сообщениями будет проходить в соответствии с практическими рекомендациями по соблюдению архитектуры сервера Exchange. Группа разрабатывает собственную плановую документацию для каждого филиала, помня о пунктах, обсуждавшихся в разделе «Что необходимо учесть». Эта документация используется во время установки и настройки серверов, во время обучения и при планировании стратегий перехода.
Для каждого филиала группа предусматривает пользователей, мгновенно переходящих на единую систему обмена сообщениями, и сохраняет устаревшую платформу для поддержки приложений IVR, которые остаются в употреблении до момента, когда будет найдено альтернативное решение. Группа решила подождать 30 дней после перехода, прежде чем выполнять переход в следующей точке. Период ожидания предназначен для того, чтобы прежде чем выполнять перевод большего числа пользователей и увеличивать число звонков в службу поддержки, была возможность убедиться в том, что все филиалы освоились с новой платформой.
В организации принято решение первым перевести филиал в Остине. Поскольку электронная почта в Остине обслуживается из Сиэтла, группа устанавливает роль сервера единой системы обмена сообщениями в Сиэтле и обеспечивает интеграцию АТС посредством установки шлюза SIP в Остине. Поскольку устаревшая платформа голосовой почты объединена в сеть, группе необходимо решить задачу включения в сеть единой системы обмена сообщений посредством установки сервера сети обмена сообщениями. Пользователи проходят обучение на новой системе, и переход осуществляется плавно, поэтому группа решает следующим перевести Нью-Йорк.
В нью-йоркском филиале имеются свой собственный сервер почтовых ящиков и транспортный сервер-концентратор. В соответствии с практическими рекомендациями сервер единой системы обмена сообщениями следует установить в Нью-Йорке. Группа устанавливает сервер в соответствии с документами по планированию перехода. Сервер добавляется к списку узлов на сервере сети обмена сообщениями с целью его включения в сеть голосовой почты. Пользователи проходят обучение и плавно переходят к единой системе обмена сообщениями.
В филиале в Сиэтле уже имеется сервер единой системы обмена сообщениями, развернутый на этапе перехода в Остине. Группа определяет, что сервер имеет достаточное число портов для поддержки филиала как в Сиэтле, так и в Остине. Пользователи в Сиэтле проходят обучение и переходят к единой системе обмена сообщениями.
Выполнить проект архитектуры в Европе гораздо проще. Инфраструктура УАТС объединена в сеть, и сервер Exchange централизован. Сервер единой системы обмена сообщениями разворачивается в Лондоне, и переводятся все филиалы, начиная с самых небольших. На рис. 3 показана окончательная архитектура.
Рис 3. Пример архитектуры после перехода (щелкните изображение для его увеличения)

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

Джеф Гудвин (Jeff Goodwin) — старший технолог в компании VIA Group, специализирующийся в области проектирования и развертывания сервера Exchange и единой системы обмена сообщениями. С ним можно связаться по электронной почте: jgoodwin@theviagroup.com.


Связь и совместная работа
Каким образом голосовая связь увеличивает возможности OCS 2007
Раджеш Раманатан (Rajesh Ramanthan)
Краткий обзор:
  • Вызовы в OCS 2007
  • Как обеспечивается безопасность вызовов
  • Многорежимные беседы в OCS
  • Интеграция с единой системой обмена сообщениями Exchange для голосовой почты

Содержание
Базовые голосовые звонки
Использование телефонных номеров
Безопасные звонки
Прохождение через преобразование сетевых адресов (NAT) и брандмауэры
Маршрутизация по телефонным номерам
Маршрутизация входящих звонков
Качественная отчетность и устранение неполадок
Сведение всего воедино
Многорежимное поведение и беседы
Голосовая почта
Заключение
В первой части серии статей о Microsoft Office Communication Server (OCS) 2007 было показано, как OCS строился на сильных сторонах версии Live Communication Server (LCS) 2005:
усовершенствованных возможностях мгновенного обмена сообщениями (IM) и возможностях отслеживания присутствия корпоративного уровня, а также улучшенных функциях телефона и передачи данных (см. выпуск журнала TechNet Magazine за февраль 2008 года на technet.microsoft.com/magazine/cc194409). В данной статье тема находит свое продолжение в виде углубленного изучения аспекта передачи голоса по IP (VoIP). Я объясню, как в системе OCS выполняются простые голосовые вызовы, и опишу технологию уровень за уровнем, так что каждый компонент будет добавляться вместе с соответствующими функциями.
Как было отмечено в предыдущей статье, OCS может быть установлен на предоставление пользователям услуг телефонии в нескольких различных вариантах:
Enterprise Voice Это законченное решение единой системы связи, использующее OCS вместе с сервером Microsoft® Mediation без необходимости в УАТС. Единая система обмена сообщениями Exchange (UM) предоставляет функции голосовой почты в этой системе. В оставшейся части статьи я буду именовать обладателей этой службы пользователями единой системы связи. Я также буду именовать клиентов в таком варианте оконечными точками этой системы.
Enterprise Voice с интеграцией УАТС Этот вариант позволяет воспользоваться преимуществами единой системы связи, в то же время оставляя существующие телефоны УАТС на их столах. Она позволяет устанавливать OCS и УАТС параллельно, так что входящие вызовы смогут одновременно приходить на оконечные точки Office Communicator и УАТС. УАТС по-прежнему управляет маршрутизацией вызовов и по-прежнему предоставляет услуги голосовой почты (автоответчика).
Удаленное управление вызовами Эта функция использует телефон УАТС как основной телефон и позволяет управлять телефоном через клиент Office Communicator.

Базовые голосовые вызовы
Здесь я уделю основное внимание тому, как они работают для пользователей Enterprise Voice. Простые голосовые вызовы устанавливаются в системе OCS с использованием механизма сообщений INVITE («Приглашение») протокола SIP, как описано в RFC 3261. Сервер OCS играет роль прокси, подобно почтмейстеру, передающему сообщения между клиентами (или оконечными точками). Новые сообщения INVITE протокола SIP исходят от клиентов при каждом создании сеанса в реальном времени, такого как вызов или сеанс обмена мгновенными сообщениями. Если на сообщение INVITE следует положительный ответ (то есть удаленная оконечная точка посылает ответ 200 ОК), то устанавливается вызов (см. рис. 1).
Рис. 1 Формат сообщения INVITE и 200 OK
INVITE sip:bob@example.com SIP/2.0
To: <sip:bob@example.com>
From: <sip:alice@example.com>;tag=5c5ffe5428;epid=d793aff63a
Call-ID: 3522acd5acd349b4855871e3100a5f4f
CSeq: 2 INVITE
Contact: sip:alice@xyz.example.com
Content-Type: application/sdp
Content-Length: 156

**Note: Alice Audio SDP payload not shown**

SIP/2.0 200 OK
To: <sip:bob@example.com>;tag=f5c728454a;epid=e73443245
From: <sip:alice@example.com>;tag=5c5ffe5428;epid=d793aff63a
Call-ID: 3522acd5acd349b4855871e3100a5f4f
CSeq: 2 INVITE
Contact: sip:bob@xyz.example.com
Content-Type: application/sdp
Content-Length: 160

**Note: Bob Audio SDP payload not shown**
На рис. 2 Алиса звонит Бобу, выбирая звонок с помощью Communicator Call из Office Communicator (OC) 2007, после чего OC 2007 оправляет сообщение INVITE универсальному коду ресурса (Uniform Resource Identifier – URI) SIP Боба (sip:bob@example.com). Сообщение INVITE содержит дескриптор аудиосеанса (именуемый SDP – от протокола описания сеанса, Session Description Protocol) оконечных точек передачи данных, где Алиса может получить аудиопередачу. OCS рассылает сообщение INVITE по зарегистрированным оконечным точкам SIP Боба (например, Communicator Phone Edition и рабочий стол Communicator). Сообщение INVITE содержит заголовок From («От»), содержащий sip:alice@example.com; он используется конечными клиентскими точками Боба при обратном поиске по имени (RNL) для обнаружения имени (Алиса), которое следует показать в уведомлении о входящем вызове.
Рис 2 Маршрутизация вызова не несколько оконечных точек (щелкните изображение, чтобы увеличить его)
Для каждой оконечной точки показан идентификатор URI глобально маршрутизируемого агента пользователя (Globally Routable User Agent URI – GRUU). GRUU дает уникальное определение каждой конечной точке SIP и получается от сервера OCS в процессе регистрации. Адрес GRUU помогает в маршрутизации сообщений SIP – скажем, после того, как на вызов отвечает конечная точка, последующая сигнализация SIP для операций, производимых в ходе вызова, может производиться между конечными точками, напрямую использующими адрес GRUU.
На рис. 3 показано продолжение процесса, в котором Боб отвечает с рабочего стола Communicator. OC Боба посылает сообщение 200 OK, говорящее, где он может принять голосовой вызов. Как только прокси OCS обнаруживает, что одна оконечная точка дала ответ, он отменяет вызов на все остальные оконечные точки Communicator Phone Edition. После того, как сообщение 200 OK достигнет оконечной точки Communicator Алисы, обе оконечные точки Communicator будут иметь достаточную информацию (порты IP, параметры шифрования и так далее) для начала передачи данных.
Рис 3: Ответ из одной оконечной точки (щелкните изображение, чтобы увеличить его)

Использование телефонных номеров
Пока что мы видели пользователя щелкающим значок Communicator Call для создания приглашения. Процесс происходит несколько по-другому, когда пользователь выбирает или вводит телефонный номер:
  • сперва клиент нормализует телефонный номер и представляет его в виде идентификатора URI TEL, который описывает ресурсы, определенные телефонными номерами, как указано в RFC 3966.
  • Поскольку OCS распознает лишь идентификаторы URI SIP, клиенты преобразуют идентификатор URI TEL в соответствующий идентификатор URI SIP путем добавления суффикса домена и тега user=phone.
  • Если номер соответствует внутреннему пользователю, OCS маршрутизирует приглашение напрямую. Если номер внешний, то приглашение маршрутизируется к ближайшему шлюзу из SIP в коммутируемую телефонную сеть общего пользования.
Некоторые вызовы на номер коммутируемой телефонной сети общего пользования (public switched telephone network – PSTN) требуют установки среды передачи перед ответом на вызов, чтобы можно было воспроизводить удаленные заявления или собирать дополнительные цифры для выполнения звонка. В таких случаях шлюз коммутируемой телефонной сети общего пользования оправляет индикатор 183 Session Progress («183 ход сеанса») с аудио SDP. Communicator использует эту информацию для установки дуплексной среды передачи с одной оконечной точкой назначения, прежде чем удаленный пользователь ответит на звонок.
После того, как начальная среда передачи установлена, Communicator включает блок клавиш цифрового двухтонального многочастотного набора (DTMF) (сигналов тонального набора), позволяя пользователю вводить любые дополнительные цифры, требуемые удаленной системой. Любые введенные цифры тонального набора отправляются через среду передачи как пакеты RFC 2833. Шлюз коммутируемой телефонной сети общего пользования берет на себя создание соответствующих тональных сигналов DTMF на стороне коммутируемой телефонной сети общего пользования.
Отметьте, что если бы Боб включил одновременный звонок на свой сотовый телефон, прокси OCS одновременно маршрутизировал бы вызов к шлюзу и дал бы этот звонок на другие оконечные точки Communicator Боба. В подобных случаях прокси OCS указывает в ответе 183 Session Progress, что дублирование активно, и это заставляет Communicator установить канал получения с помощью шлюза коммутируемой телефонной сети общего пользования.

Безопасные вызовы
Одним из ключевых компонентов голосовых вызовов, устанавливаемых OC, является то, что передаваемый звуковой сигнал по умолчанию шифруется с помощью протокола SRTP, как определено в RFC3711. SRTP предоставляет трафику RTP конфиденциальность, проверку подлинности сообщений и защиту от повторной передачи перехваченных сообщений. В ходе установки вызова клиенты согласовывают возможности безопасности между собой и обмениваются криптографическими ключами в ходе работы механизма INVITE.
По умолчанию, шифрование в OC имеет параметр «дополнительно», что позволяет двум оконечным точкам OC установить зашифрованный канал передачи. Этот параметр может быть скорректирован администратором в соответствии с нормативными требованиями организации. Например, его можно сделать более жестким, заставляя шифровать все вызовы, или отключить полностью.

Прохождение через преобразование сетевых адресов (NAT) и брандмауэры
Клиенты в системе OCS используют технологию интерактивной установки связи (Interactive Connectivity Establishment – ICE) для установки каналов передачи данных к пользователям, защищенным устройствами преобразования сетевых адресов (Network Address Translation – NAT) и брандмауэрами, не требуя никаких изменений в существующих компонентах NAT. Рабочая группа проектирования Интернета (Internet Engineering Task Force – IETF) в настоящий момент работает над технологией стандартизации ICE. Каждый клиент учитывает наличие пограничного аудио/видео сервера, который работает через механизм предоставления входящей пропускной способности и поддерживает канал с проверенной подлинностью к этому серверу в ходе входа в систему.
Перед совершением вызова клиент распределяет ресурсы по возможным точкам подключения (адресам и портам, также известным как кандидаты) пограничного аудио/видео сервера (для передачи канала) на NAT или на размещающем клиенте. При отправке сообщения INVITE протокола SIP вся эта информация о подключении переносится как часть сообщения INVITE. Ответ 200 OK несет аналогичную информацию о кандидатах отвечающего узла. После того, как у каждой из оконечных точек имеется список этих кандидатов, сложный механизм ранжирования и проверки выбирает оптимальный путь между двумя узлами сети, на котором передача данных гарантированно будет удачной.

Маршрутизация по телефонным номерам
Маршрутизация по телефонным номерам вносит некоторые сложности в базовый механизм вызова в силу следующих факторов:
  • Организации могут иметь различные абонентские группы, развертываемые внутренне, для краткого набора номера.
  • Номера могут храниться в нестандартных форматах (например, пользователи могли сохранить строки из семи цифр в Microsoft Office Outlook®).
  • Различным исходящим номерам могут соответствовать различные политики. Например, для определенных пользователей может быть заблокирован набор международных номеров.
Система OCS требует, чтобы телефонные номера были записаны в формате идентификаторов URI стандарта RFC 3966 TEL для их правильной маршрутизации. Если номера не в этом формате, они преобразуются перед выдачей клиентом сообщения INVITE. На чертеже на рис. 4 показано, как это происходит внутри системы OCS.
Рис 4. Маршрутизация телефонных номеров (щелкните изображение, чтобы увеличить его)
Доступные клиенту номера могут происходить из различных источников. Предварительно нормализованные номера берутся из службы адресной книги (ABS), в которой содержатся определенные администратором правила нормализации для преобразования номеров в формат E.164. После того, как клиент выдает сообщение INVITE протокола SIP нормализованному номеру, OCS применяет процесс преобразования, чтобы сопоставить номер с любым внутренним пользователем
  • Этап 1 показывает, что входящие в систему номера либо уникальны (нормализованы в соответствии с планом нумерации E.164), либо находятся в контексте телефона, определяющем местонахождение. Эти номера отсылаются серверу как часть сообщения INVITE протокола SIP. OCS маршрутизирует сообщение INVITE к процессу преобразования.
  • Процесс преобразования (этап 2) пытается сопоставить телефонный номер с оконечной точкой единой системы связи, используя RNL на стороне сервера. Преобразование может определить маршрут номера к маршрутизации исходящих или к пользователю единой системы связи либо выдать сбой вызова с кодом 4xx, если номер не может быть правильно преобразован.
  • Если номер преобразован во внешний номер или номер, не относящийся к единой системе связи, он может быть отправлен к компоненту исходящей маршрутизации, который перенаправляет сообщение INVITE к соответствующему шлюзу из SIP в коммутируемую телефонную сеть общего пользования для дальнейшей обработки после применения политик для номера, относящихся к вызывающему (этап 3A). Маршрутизация исходящих берет на себя балансировку нагрузки между шлюзами или переход на альтернативные шлюзы, если это необходимо. Процесс маршрутизации исходящих вызовов может закончиться сбоем или отвергнуть вызов, возвратив код ответа SIP 40, если для определенного номера доступ запрещен. Отметьте, что маршрутизация исходящих звонков применима только если вызывающий является пользователем UC. Когда это не так, OCS пытается использовать статические маршруты к шлюзам, установленные для данного идентификатора URI.
  • Если номер преобразован в номер пользователя единой системы связи, то сообщение INVITE маршрутизируется к идентификатору URI SIP для данного пользователя (этап 3B). Маршрутизация входящих является функцией OCS, применяющейся только к пользователям единой системы связи и ко всем вызовам, направленным к идентификатору URI SIP. Как можно будет увидеть, маршрутизация входящих применяет правила по максимальному времени звонков, перенаправлению вызовов и перенаправлению голосовой почты для пользователя единой системы связи.
Обратите внимание, что номера, создаваемые в процессе нормализации, могут быть различным в зависимости от местонахождения клиента. Администраторы могут настраивать профили местонахождения и назначать правила преобразования номеров для определенного местонахождения (например, как в нем работает набор номера из четырех цифр). Каждому пользователю единой системы связи выделяется профиль местонахождения, и все клиенты в системе загружают правила их конкретного профиля местонахождения, используя предоставление входящей пропускной способности. Далее я рассмотрю детали маршрутизации входящих.

Маршрутизация входящих вызовов
Правила маршрутизации входящих вызовов указывают, как именно следует маршрутизировать пользователя в присутствии или отсутствии зарегистрированных клиентов в системе. Компонент маршрутизации входящих вызовов также занимается применением основанных на присутствии правил к входящему вызову; например, он может отправлять входящие вызовы на голосовую почту, если пользователь установил состояние присутствия Do Not Disturb («Не беспокоить»). Маршрутизация входящих учитывает уровни контейнеров присутствия и автоматически отвергает вызовы от пользователей в заблокированных контейнерах. На рис. 5 показана сводка вариантов, поддерживаемых компонентом маршрутизации входящих OCS.
Рис. 5. Возможности по маршрутизации входящих
Возможность | Примечание
Продолжительность звонка | По умолчанию 20 секунд. Пользователь может изменить его вплоть до максимума в 60 секунд. По истечении этого срока вызовы перенаправляются в место хранения вызовов без ответа.
Маршрутизировать вызовы без ответа на голосовую почту | Используется по умолчанию, если у пользователя включена голосовая почта. Вызов маршрутизируется согласно правилам маршрутизации входящих.
Создавать уведомления о пропущенных вызовах, когда звонящий вешает трубку прежде, чем вызов достигает голосовой почты | Уведомляет единую систему обмена сообщениями Exchange о таких пропущенных вызовах.
Блокировка вызовов | Отвергает вызовы от заблокированных звонящих (заблокированы могут быть лишь вызовы с идентификаторами SIP).
Не беспокоить | Маршрутизирует вызовы на голосовую почту. Точки назначения одновременного вызова не обзваниваются, если пользователь находится в этом режиме.
Допустить список прерываний | Допускает вызовы от звонящих в контейнере Team («Группа»), даже если для пользователя установлено состояние «Не беспокоить».
Одновременный вызов | Настраивает входящие вызовы на телефон КТСОП, помимо клиентов Communicator и Communicator Phone Edition.
Вызвать немедленное перенаправление | Немедленное перенаправление входящего вызова на другого пользователя, телефонный номер КТСОП или голосовую почту.
Вызвать перенаправление в случае отсутствия ответа | Перенаправляет оставшийся без ответа звонок на другого пользователя, телефонный номер КТСОП или голосовую почту.
Рабочее время | Использует настроенное в календаре Outlook рабочее время для активации параметров перенаправления звонка для пользователя.
Правила маршрутизации входящих загружаются на сервер как схема XML в качестве части самопредоставляющейся информации пользователя. На рис. 6 показано, как действует маршрутизация входящих. Входящий вызов пользователю в системе OCS по умолчанию создает звонок у пользователя (показанного как "Me" («Я»)). Если по истечении продолжительности звонка ответа все еще нет, оставшийся без ответа вызов по умолчанию отсылается голосовой почте. Пользователь может изменить настройку по умолчанию, выбрав немедленное перенаправление на номер, на другого субъекта или напрямую на голосовую почту.
Рис 6. Маршрутизация вызовов (в рабочее время) (щелкните изображение, чтобы увеличить его)
Любые вызовы, которые немедленно перенаправляются другому субъекту или номеру, введут в действие правила маршрутизации входящих для этого субъекта или номера. Пользователь может также установить перенаправление оставшегося без ответа вызова на другого субъекта или другой номер.
Если пользователь выберет параметр «Apply only during my Outlook Working Hours» («Применять только в мое рабочее время Outlook»), то правила, показанные на рис. 6, будут применяться в рабочее время, а поведение по умолчанию (звонки на зарегистрированных конечных точках) будет применяться в остальное время. Обратите внимание, что это поведение требует от организации развертывания клиентов Microsoft Exchange Server 2007 и Outlook 2007, поскольку Communicator использует информацию о рабочем времени из веб-службы доступности Exchange 2007, а также пользуется поддержкой автоматического обнаружения в Outlook 2007 для получения местонахождении сервера.

Отчеты о качестве связи и устранение неполадок
Хотя клиенты в системе OCS 2007 используют RTAudio, аудиокодек нового поколения, который может вытерпеть неидеальную работу сети, скажем нарушение синхронизации, потерю пакетов и так далее, наблюдение остается крайне важным для обнаружения и исправления потенциальных больных мест администраторами. Клиенты в системе OCS 2007 сообщают о качестве каждого вызова и предоставляют подробную статистику о нем, включающую потерю пропускной способности сети, нарушение синхронизации, среднюю оценку пользователей (меру их восприятия), используемые устройства и прочее центральному серверу контроля качества взаимодействия (QoE). Это проделывается путем отправки полезных данных в запросе SERVICE SIP к серверу QoE, адрес которого программируется с использованием механизма предоставления входящей пропускной способности.
Отметьте, что каждая клиентская оконечная точка сообщает о качестве вызова серверу QoE независимо. Если вызов потерпит сбой из-за ошибки в сигналах, клиенты сообщат то же самое и системе OCS, которая предоставит хранилище всех ошибок, созданных клиентами.﻿

Резюме
Теперь, перебрав несколько аспектов создания вызова, в том числе ввод номеров, маршрутизацию входящих и исходящих и проверки подключения, давайте взглянем на процесс в целом. На Рис. 7 дана сводка происходящего с момента совершения вызова пользователем. Клиенты в системе OCS играют ключевую роль в создании вызова и управляют всем его процессом. OCS задействована в первоначальной маршрутизации вызова, а пограничные серверы помогают клиентам найти оптимальный путь передачи. Давайте взглянем на то, что происходит дальше – разговор.
Рис 7. Процесс вызова от начала до конца (щелкните изображение, чтобы увеличить его)

Многорежимное поведение и беседы
Концепция бесед является центральной в системе OCS. Беседа – это многорежимный сеанс между двумя или более пользователями, который может одновременно включать аудио, видео и мгновенные сообщения, а также такие компоненты, как передачу файлов во время сеанса, электронную почту в Outlook или заметки, сохраненные в Microsoft Office OneNote®.
Существуют несколько аспектов бесед, которые могут повлиять на проект клиентских систем OCS:
  • Все задействованные в беседе методы используют одно окно. Если к аудиобеседе добавлено мгновенное сообщение, оно связывается с тем же окном.
  • Беседы могут охватывать несколько устройств. Пользователи могут выбрать ведение аудиочасти беседы на Communicator Phone Edition с получением мгновенных сообщений на рабочем столе Communicator.
  • Все режимы расширяются до уровня конференции вместе: если расширение происходит, все методы беседы должны расширяться вместе независимо от того, на каком устройстве находится определенный метод. Например, если аудиорежим доступен на Communicator Phone Edition, а режим мгновенных сообщений для той же беседы на рабочем столе Communicator, то расширение до конференции гарантирует, что и аудиорежим, и мгновенные сообщения будут иметь одинаковый набор участников.
  • В журнал записываются беседы, а не отдельные сеансы. Журналы вызовов содержат полную информацию о беседе, включая подробности о заметках, сделанных по ходу нее, обменах мгновенными сообщениями, продолжительности аудиосеанса и т.д. Это дает удобное сводное представление о всей беседе, когда пользователь открывает журнал звонков в Outlook.
  • Беседы могут продолжаться из журналов бесед. Клиенты OCS связывают беседы вместе, используя идентификатор беседы (номер, уникальный для беседы и используемый для ее опознания на различных устройствах и приложениях). Существует замысловатый механизм вычисления разностности бесед, когда новые беседы запускаются из журнала старой беседы. Тот же идентификатор беседы сохраняется как идентификатор электронной почты в Outlook.
Идентификатор беседы перемещается как часть сообщения INVITE протокола SIP в виде специального свойства Ms-Conversation-Id. На Рис. 8 показана такая транзакция, где сперва добавляется голос, а затем мгновенное сообщение. Обратите внимание, что в конце многорежимной беседы журнал, сохраненный в Outlook, имеет тот же идентификатор беседы.
Рис 8. Многорежимные беседы и идентификатор беседы (щелкните изображение, чтобы увеличить его)

Системой голосовой почты для OCS 2007 является единая система обмена сообщениями Exchange (UM). OCS может маршрутизировать звонки лишь для пользователей, у которых в единую систему связи включена поддержка UM Exchange. OCS предоставляет несколько функций для интеграции с UM Exchange:
  • Параметр Call Voice Mail («Вызов голосовой почты») из интерфейса пользователя телефона Communicator (см. рис. 9) позволяет пользователю управлять почтовым ящиком системы обмена сообщениями, изменять приветствия и так далее, не вводя ПИН, поскольку его подлинность уже проверена.
  • Индикатор ожидающего сообщения в интерфейсе пользователя Communicator (см. рис. 10) позволяет пользователю открыть папку голосовой почты Outlook, а в Communicator Phone Edition позволяет пользователю воспроизводить голосовые сообщения напрямую с телефона.
  • Вызовы могут перенаправляться на голосовую почту из интерфейса пользователя Communicator.
  • Отвергнутые звонки автоматически маршрутизируются на голосовую почту.
  • Play on Phone («Воспроизвести на телефоне») из элемента голосовой почты в Outlook звонит прямо клиентам Office Communicator.
Рис. 9. Пункт меню Call Voice Mail («Вызов голосовой почты») в Communicator
Рис. 10. Индикатор ожидающего сообщения в Communicator
Механизм, с помощью которого OC получает уведомление о голосовой почте, отличается от Communicator Phone Edition. OC подписывается на новые уведомления о почте в папке поиска голосовой почты в Outlook и сообщает о новых сообщениях в этой папке. Communicator также использует пропущенные беседы и журналы вызовов.

Заключение
Я показал здесь работу голосовых вызовов в OCS 2007 – систему на основе SIP, пользующуюся несколькими RFC. Оконечные точки клиентов играют центральную роль в управлении вызовами в OCS. По умолчанию, все голосовые звонки надежно шифруются. OCS предоставляет гибкие компоненты, чтобы сделать возможным манипуляции с номерами и управление их потоком во всей системе.
Центральной концепцией OCS являются беседы, включающие голосовую связь, мгновенные сообщения и видео. OCS интегрируется с UM Exchange и позволяет уведомлять оконечные точки Communicator о голосовой почте, а также получать доступ к голосовой почте через Outlook или напрямую с сервера.

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


Связь и совместная работа
Создание многофункциональных подключений при помощи Groove и SharePoint
Алан Мэдисон
Краткий обзор:
  • Создание библиотеки документов SharePoint
  • Создание рабочей области Groove
  • Синхронизация Groove и SharePoint
  • Разрешение доступа к рабочей области

Содержание
Объединение Groove и SharePoint
Начало работы
Настройка средства контроля за утверждением документов
Создание рабочей области Groove
Синхронизация Groove и SharePoint
Разрешение доступа к рабочей области
Заключение
Специалистов по ИТ часто удивляет несомненное сходство между Microsoft Office Groove 2007 (Groove) и Microsoft Office SharePoint Server 2007 (SharePoint).Они даже не могут определить,
какое средство в каком случае использовать. На первый взгляд, эти два продукта действительно кажутся похожими, поскольку они оба предоставляют возможности для совместной работы. Однако, глубоко изучив их архитектуру, можно видеть, насколько сильно они различаются.
SharePoint® предоставляет устойчивую и масштабируемую платформу для управления содержимым и набор средств для совместной работы с поддержкой структурированных потоков работ. В отличие от него Groove™ является набором средств для совместной работы, которые позволяют быстро и с минимальной нагрузкой на специалистов по ИТ организовать рабочую область. Поддержка совместной работы с документами, наличие сгруппированных по темам дискуссий, ведение календаря и прочие функции Groove предоставляют идеальную платформу для динамичной, безопасной совместной работы в любой момент времени. Таким образом, большинство пользователей естественным образом применяют эти два продукта по-разному.
Кроме того, с выпуском Groove 2007 появилась встроенная поддержка интеграции со SharePoint при помощи средства «Файлы SharePoint». Это средство позволяет синхронизировать рабочие области с библиотеками документов SharePoint и, как будет показано, такая встроенная интеграция помогает максимально использовать оба продукта. Сочетание гибкости и динамичности Groove с развитыми и многосторонними средствами SharePoint предоставляет значительные преимущества для многих пользователей.
Объединение Groove и SharePoint
Современный мир ИТ требует все более тесного взаимодействия между организациями, их партнерами и поставщиками. Однако существующие средства совместной работы на основе таких продуктов, как SharePoint, в основном предназначены для внутренних рабочих групп и для распространения информации внутри организации. В результате предоставление доступа к данным для пользователей, внешних по отношению к организации, сталкивается с рядом значительных трудностей — как административных, так и связанных с обеспечением безопасности. Учитывая все эти трудности, обеспечение пользователей подключением по требованию к партнерам вне предприятия становится непростой задачей.
Решением именно этой задачи и является сочетание Groove и SharePoint. SharePoint обеспечивает взаимодействие внутри организации, поиск содержимого и платформу для потоков работ; Groove позволяет расширить эти возможности на взаимодействие между организациями. С помощью Groove несложно установить рабочие области, предназначенные для совместной работы, не ограниченной рамками компаний. Далее, поддержка 192-разрядных симметричных ключей стандарта шифрования AES обеспечивает безопасность совместной работы. К тому же средства обеспечения безопасности встроены в Groove и включены всегда, так что пользователям не нужно беспокоиться об их настройке.
Средства обеспечения безопасности в Groove устроены так, чтобы предоставлять высокий уровень защиты рабочих областей и их содержимого как при хранении данных на диске, так и при передаче их по сети. Средство «Файлы SharePoint» осуществляет двунаправленную синхронизацию этих данных с библиотекой документов SharePoint, тем самым упрощая доступ к этой информации изнутри предприятия. Давайте рассмотрим работу этого средства на конкретном примере.
Начало работы
В ходе каждодневной хозяйственной деятельности каждой организации приходится взаимодействовать со множеством других. В этом взаимодействии участвуют не только внешние организации, но и сотрудники отделов, которые нечасто работают вместе: например, финансового, юридического, отдела внешних связей. В результате таким организациям необходимо создавать специальные внутренние рабочие группы, которые работали бы вместе, а затем предоставлять продукт их совместной деятельности тем, кто в процессе разработки не участвовал, но кому нужен доступ к окончательному результату. При помощи SharePoint и Groove добиться этого очень легко.
Первым действием будет создание библиотеки документов SharePoint, синхронизирующейся с рабочей областью Groove. Для этого подключитесь к SharePoint и перейдите по ссылке «Просмотр всего содержимого». Когда эта страница загрузится, выберите в меню «Создать», затем, как показано на рис. 1, выберите пункт «Библиотека документов» в колонке «Библиотеки».
Рис 1: Создание библиотеки документов SharePoint (Щелкните изображение, чтобы увеличить его)
Затем нужно настроить ряд параметров на странице новой библиотеки документов – ввести имя и описание библиотеки, определить необходимость включения библиотеки в раздел быстрых переходов и необходимость включения контроля версий, а также выбрать формат по умолчанию для новых документов, создаваемых непосредственно в библиотеке. Журнал версий документа по умолчанию отключен, однако если на предприятии используется управление версиями документов, его можно включить. В реализации Groove и SharePoint можно воспользоваться некоторыми расширенными возможностями SharePoint, такими как
  • журнал версий
  • контроль за утверждением документов
  • процедуры извлечения документа
  • контроль за потоком работ
  • политики хранения документов
  • аудит
  • сводка по узлу RDF (RSS)
Эти дополнительные возможности SharePoint могут обеспечить значительные преимущества при работе с Groove. Скажем, в моем случае эти дополнительные возможности, в частности контроль за утверждением документов, оказались очень полезными. Предположим, например, что члены рабочей группы совместно работают в Groove, составляя проект некоторого документа. Когда окончательный вариант проекта готов к проверке, его можно передать в SharePoint и запустить там процесс утверждения.

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

Создание рабочей области Groove
После того, как в SharePoint создана библиотека документов, нужно создать рабочую область Groove. Прежде всего убедитесь, что у вас есть учетная запись в Groove и как минимум одно удостоверение. Удостоверения — это основа присутствия и связи в Groove. Каждой учетной записи Groove может соответствовать несколько удостоверений, а каждому удостоверению соответствует уникальный файл контакта, таким образом можно настроить свои контактные данные отдельно для каждого используемого удостоверения. Groove также позволяет экспортировать учетную запись и связанные с ней удостоверения, чтобы их можно было использовать на нескольких компьютерах.
После создания учетной записи и удостоверения откройте панель запуска Groove, дважды щелкнув значок Groove на панели задач. Выберите «Создать рабочую область», дайте ей соответствующее название и выберите «Стандартный тип» рабочей области. Стандартная рабочая область Groove обеспечивает отображение присутствия, передачу оповещений и назначение ролей участникам рабочей области. Groove создаст и откроет рабочую область, когда вы нажмете «ОК». На рис. 2 показана новая рабочая область вместе с некоторыми добавленными в нее файлами. Теперь рабочая область пригодна к использованию. При необходимости к ней можно добавить и настроить оповещения или любые другие нужные вам средства, тем самым завершив ее настройку.
Рис 2: Новая рабочая область Groove (щелкните изображение, чтобы увеличить его)
Оповещения можно настроить на уровне средства, рабочей области или отдельного файла. Существуют четыре уровня оповещений: нулевой, средний, высокий и автоматический. На среднем уровне выделяется новое содержимое, тогда как на высоком и автоматическом проигрывается звуковой файл. Можно настроить рассылку оповещения в случае, когда пользователь входит в определенную рабочую область. Для настройки оповещений выберите пункт «Настройка оповещений» в меню «Параметры». Оповещения на уровне отдельных файлов настраиваются в свойствах самого файла, щелкните правой кнопкой мыши файл в рабочей области и выберите пункт «Свойства».
Кроме средства «Файлы», служащего для совместной работы над документами, и средства «Обсуждение», применяющегося для обсуждения по темам, которые по умолчанию являются частью стандартной рабочей области, в Groove есть много других средств, в том числе «Календарь», «Формы», «Отслеживание вопросов», «Собрания», «Альбом» и, конечно же, средство «Файлы SharePoint». Каждое из них предоставляет важные дополнительные возможности для совместной работы. Чтобы добавить средство, нажмите кнопку «Добавить средство в рабочую область» в нижней правой части рабочей области, а затем выберите, какое средство нужно добавить, как показано на рис. 3. При необходимости средство легко удалить.
Рис 3: Добавление средства к рабочей области Groove(Щелкните изображение, чтобы увеличить его)

Синхронизация Groove и SharePoint
Добавив инструмент «Файлы SharePoint», необходимо указать URL-адрес узла SharePoint, на котором расположена библиотека документов, с которой нужно синхронизироваться. После выбора вкладки «Файлы SharePoint» в нижней части экрана рабочей области нажмите кнопку «Установка», как показано на рис. 4.
Рис 4: Настройка средства «Файлы SharePoint» (Щелкните изображение, чтобы увеличить его)
Введя URL-адрес, вы увидите все библиотеки, доступные на узле SharePoint, из которых вы выберете нужную, как показано на рис. 5. Groove подключится к библиотеке, и синхронизация начнется автоматически. В результате все документы, находящиеся в библиотеке SharePoint, будут загружены в рабочую область Groove и таким образом станут доступны. Пример показан на рис. 6.
Рис. 5 После указания URL-адреса библиотеки SharePoint становятся доступны в Groove ( щелкните изображение, чтобы увеличить его)
Рис 6: Синхронизация Groove и SharePoint (щелкните изображение, чтобы увеличить его)
В рабочей области Groove документы показаны как непрочитанные, потому что они только что были загружены. Заметьте, что к файлам, загруженным в ходе синхронизации из SharePoint, применимы операции взятия для изменения и возврата после изменения. Кроме того, если вы берете файл для изменения, то можете быть уверены, что, пока вы работаете с документом, другие пользователи не смогут внести в него никаких изменений.
Также важно помнить, что средство «Файлы SharePoint» осуществляет двухстороннюю синхронизацию, так что файлы, добавленные к SharePoint через Groove, будут загружены в библиотеку документов SharePoint. Хотя синхронизация по умолчанию происходит автоматически, ее можно запустить вручную нажатием кнопки «Синхронизировать ». Если вы это сделаете, то увидите итоговое количество изменений во всех файлах, требующих синхронизации, а также связанные с синхронизаций операции получения (из SharePoint) или отправки (в SharePoint), как показано на рис. 7.
Рис. 7 Итоговое количество изменений после синхронизации вручную.( щелкните изображение, чтобы увеличить его)
Важно помнить, что средство «Файлы», являющееся частью стандартной рабочей области Groove, отличается от средства «Файлы SharePoint». Средство «Файлы» не участвует в синхронизации с SharePoint, и при необходимости его можно удалить. Однако это средство можно использовать для указания хранилища временных файлов, к которым рабочая группа должна иметь доступ в ходе разработки проекта. Все участники рабочей группы получат синхронизированные копии этих файлов.

Разрешение доступа к рабочей области
Теперь, когда основная структура для совместной работы создана, можно заняться разрешением доступа пользователей к рабочей области. Однако сначала пользователям придется разослать приглашения. Используйте для этого электронную почту или обмен мгновенными сообщениями Groove. Groove также позволяет экспортировать приглашение в файл. Файл получает расширение GRV, с которым по умолчанию сопоставлен запуск программы. Этот файл можно доставить к пользователям способами, отличными от электронной почты: например, его можно выложить на веб-узел и позволить получателям загрузить приглашение.
В обмене мгновенными сообщениями Groove имеются проверки безопасности, которые гарантируют, что только адресат сможет прочитать приглашение. При рассылке приглашений по электронной почте или с использованием файла приглашения убедитесь, что установлен флажок «Требовать подтверждения принятия». Таким образом вы сможете еще раз проверить, что к рабочей области присоединится именно тот человек, которого пригласили. Вашей рабочей области это добавит дополнительный уровень безопасности. Заметьте, что можно отменить приглашения, на которые долго не приходит ответ.
Приглашая пользователей в рабочую область, каждому адресату нужно назначить роль. Таких ролей три: администратор, участник и гость. Каждой роли назначен определенный набор прав в рабочей области. Как правило, роль администратора должна присваиваться только тем пользователям, которым действительно необходимы полные права на рабочую область, включая право на удаление средств. Создателю рабочей области автоматически назначается роль администратора. Назначенные роли могут быть изменены в любой момент.
Поскольку в этой статье обсуждаются проекты, временные по своей природе, то после завершения работы над проектом рабочую область Groove надо будет удалить. Убедившись в том, что рабочая область синхронизирована с библиотекой документов SharePoint, нужно открыть рабочую область и выбрать пункт «Удалить рабочую область» из меню «Файл». Выберите вариант удаления «С данного компьютера» или «Для всех участников». (У каждого пользователя на машине находится своя копия рабочей области, которая будет храниться до тех пор, пока рабочая область не будет удалена у всех участников рабочей группы).
И в завершение работы над проектом представляется еще она отличная возможность воспользоваться взаимным дополнением Groove и SharePoint. Сразу после последней синхронизации наступает идеальный момент для использования тех преимуществ, которые предоставляет настройка политики управления данными в SharePoint. В частности, истечение срока действия данных предоставляет метод автоматического управления архивом.
Функция истечения срока действия позволяет указывать период времени, в течение которого нужно хранить данные. В конце периода хранения данных SharePoint или удаляет их автоматически, или запускает поток работ. Эта возможность предоставляет отличный способ включить данные Groove в жизненный цикл информации на вашем предприятии. Настроить политику хранения данных можно всегда. Если вы не сделали этого при создании и настройке библиотеки, еще не поздно сделать это сейчас.
Для настройки срока давности данных выберите меню «Параметры» в библиотеке документов, а затем параметры библиотеки документов. В разделе страницы «Разрешения и управление» находится команда меню «Параметры политики управления сведениями». Когда вы перейдете по ссылке «Параметры политики управления сведениями», вы сможете или создать собственную политику, или включить политику библиотеки документов, которая назначается на уровне сайта.
При создании собственной политики от вас потребуется ввести некоторые данные для настройки. В примере вам будет предложено включить срок давности данных, затем выбрать период их хранения и действие, которое будет выполняться по истечению этого периода.
Groove — средство организации совместной работы с большими возможностями, предоставляющее динамичную, интуитивно понятную и безопасную инфраструктуру для работы временных рабочих групп. Обладая большими функциональными возможностями, Groove предоставляет облегченную и гибко настраиваемую платформу взаимодействия как внутри организации, так и между организациями.
Если в вашей организации уже используется SharePoint как надежное и многостороннее средство создания инфраструктуры управления данными и набор средств взаимодействия, то, как мне кажется, привлекательным решением для вас станет сочетание его с Groove. Эта два продукта отлично дополняют друг друга и вместе приводят к большому подъему производительности совместно работающих групп.﻿

Алан Мэдисон (Alan Maddison) работает старшим консультантом в группе «Стратегические системы для бизнеса», подразделении компании Brocade.


Администрирование в Windows
Представляем отказоустойчивую кластеризацию Windows Server 2008
Чак Тимон (Chuck Timon)
Краткий обзор.
  • Оснастка управления отказоустойчивой кластеризацией
  • Новые функции и улучшения
  • Функции резервного копирования и восстановления
  • Переход с Windows Server 2003

Содержание
Новый интерфейс управления
Улучшенные процессы настройки
Встроенная процедура проверки
Новая модель кворума
Улучшенные возможности безопасности
Расширенные функции сети
Повышенная надежность при взаимодействии с хранилищем
Встроенные процессы аварийного восстановления
Новые функции резервного копирования и восстановления
Переход с кластеров серверов Windows Server 2003
С тех пор, как кластеризация впервые появилась в Windows NT 4.0 Enterprise Edition, пользователи жаловались, что ее сложно создавать и еще сложнее обслуживать. Администрирование кластера
требовало от администратора не только понимания самой кластеризации – администратору также было необходимо отлично знать технологии хранения и то, как служба кластера будет взаимодействовать с различными решениями хранения. Чтобы довести высокодоступное решение до рабочего состояния и затем его обслуживать, требовался исчерпывающий набор умений, который непросто было найти во многих организациях.
С течением лет кластеризация улучшилась, но всё же она во многом оставляла желать лучшего, когда корпорация Майкрософт начала работу над Windows Server® 2008. Учитывая все это, группа разработчиков взялась за переработку кластеризации, в первую очередь имея целью простоту. В Windows Server 2008 службы кластеризации Майкрософт (Microsoft® Cluster Services – MSCS) подверглись полному обновлению и теперь носят название отказоустойчивой кластеризации.
Это не значит, что простота является единственным, что предоставляет новая отказоустойчивая реализация кластеризации. За прошедшие годы корпорация Майкрософт усвоила много уроков по мере того, как организации предоставляли ценные отзывы о том, что они хотели бы видеть в прослушиваемом решении кластеризации. Новая функциональность безопасной кластеризации решает многие из основных проблем, о которых сообщали пользователи, а также добавляет некоторые интересные новые функции, делающие ее весьма привлекательной. Так что в этой статье я хотел бы представить некоторые из замечательных новых функций, которые можно обнаружить в отказоустойчивой кластеризации Windows Server 2008.

Новый интерфейс управления
После установки отказоустойчивой кластеризации доступ к интерфейсу управления отказоустойчивыми кластерами можно получить через боковое приложение «Администрирование» или путем запуска Cluadmin.msc. Оснастка управления отказоустойчивыми кластерами, подобно другим интерфейсам управления в Windows Server 2008, является консолью управления Майкрософт (MMC) версии 3.0. Для ветеранов кластеризации открытие оснастки управления отказоустойчивыми кластерами в первый раз может показаться подобным неожиданному переносу в чужую страну без карты под рукой.
Новый интерфейс разделен на три отдельные области, как показано на рис. 1. В левой области перечислены все отказоустойчивые кластеры Windows Server 2008 в организации. Центральная область предоставляет сведения о части состава кластера, выбранной в левой области, когда как в правой области показаны действия, которые можно выполнить.
Рис 1. Оснастка управления отказоустойчивыми кластерами (щелкните изображение, чтобы увеличить его)
Скажем, для примера, в левой области выбрано «Хранилище». В центральной области после этого появятся сведения о хранилищах, предоставленных в кластере, и о том, какие из них доступны в настоящий момент. Как можно увидеть на рис. 1, кластер содержит часть хранилища, поддерживающую диск-свидетель, хранилище, предоставленное для сервера файлов, и некоторый объем свободного места. В правой области перечислены связанные с хранилищем действия, такие как добавление к нему места. Обратите внимание, что оснастка управления отказоустойчивыми кластерами не может быть использована для администрирования предыдущих версий служб кластеризации Майкрософт.

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

Встроенная процедура проверки
В предыдущих версиях Windows Server поддерживаемыми решениями кластеров считались лишь комплекты оборудования, занесенные как решения кластеров в каталог Windows Server. Это касалось и кластеров с узлами в нескольких филиалах, которые перечислялись отдельно в категории географически распределенных. Чтобы попасть в каталог, производители оборудования должны были провести набор тестов лабораторий Windows Hardware Quality Lab (WHQL) и предоставить результаты в корпорацию Майкрософт. Это требовало затрат от производителя и базу данных каталога Windows Server было сложно поддерживать на уровне.
В Windows Server 2008 в состав отказоустойчивой кластеризации входит встроенный процесс проверки. Этот процесс состоит из ряда тестов, сгруппированных в четыре основных категории, как показано на рис. 3.
Рис 3. Категории проверочных тестов отказоустойчивых кластеров (щелкните изображение, чтобы увеличить его)
Можно заметить, что категория «Сеть» развернута, чтобы показать выполняемые тесты; каждая категория содержит ряд тестов. В категорию «Хранилище», являющуюся, вероятно, наиболее важной из четырех, входят тесты, обеспечивающие соответствие решений хранилищ новым требованиям отказоустойчивых кластеров Windows Server 2008.
Говоря конкретнее, поставщики оборудования теперь должны использовать драйверы, основанные на драйвере Microsoft Storport, а также поддерживать постоянное резервирование SCSI-3. Вдобавок, программные модули с несколькими путями, зависящие от устройств, при использовании должны быть основаны на стандарте ввода/вывода Microsoft Multi-Path Input\Output.
В результате появления процесса проверки изменилась модель поддержки. Все оборудование должно теперь иметь логотип Windows Server 2008, и все проверочные тесты должны быть успешными. Единственным исключением являются кластеры с узлами в нескольких филиалах, имеющие два отдельных и различных пространства хранилищ, по одному в каждом филиале, и реализация непрерывной репликации кластера в Exchange Server 2007, которая не использует общих хранилищ.

Новая модель кворума
В отказоустойчивой кластеризации Windows Server 2008 изменилась и модель кворума. В более старых системах при слове «кворум» администратор думал об общем диске, где находились настройка кластера и некоторые реплицированные файлы. Он был слабым звеном для всего кластера. В случае сбоя диска кворума служба кластера прекращала работу, и высокая доступность терялась.
Кластеры серверов Windows Server 2003 предлагали второй тип кворума, именуемый кворумом набора узлов большинства. Этот тип кворума обычно применялся на кластерах с несколькими узлами и не требовал общих хранилищ. Кворум набора узлов большинства состоял из общего файлового ресурса, находящегося на системном диске каждого узла кластера. Подключения к этому типу кворума проводились по протоколу SMB (Server Message Block). Опять же, для функционирования кластера требовалось участие большинства узлов.
Затем с появлением непрерывной репликации кластера (cluster continuous replication – CCR) в Exchange Server 2007 к кластерам серверов Windows Server 2003 была добавлена возможность файлового ресурса-свидетеля (File Share Witness – FSW). Это позволяло единственному узлу кластера CCR Exchange 2007 (или любому кластеру с несколькими узлами) продолжать предоставлять услуги, пока подключение к FSW позволяло достигнуть большинства.
В безопасной кластеризации Windows Server 2008 концепция кворума теперь действительно означает консенсус. Кворум (или консенсус) теперь достигается путем наличия достаточного числа голосов для ввода кластера в эксплуатацию. В зависимости от состава кластера, достаточное число голосов может быть достигнуто различными путями. В отказоустойчивой кластеризации Windows Server 2008 доступны четыре режима кворума, они показаны на рис. 4. Из четырех перечисленных режимов только первые два (большинства узлов и большинства узлов и дисков) могут быть автоматически выбраны в ходе процесса создания кластера. Следует использовать следующую логику:
  • Если в кластере настраивается нечетное число узлов, выберите режим большинства узлов.
  • Если в кластере настраивается четное число узлов, а общее хранилище подключено и доступно, выберите режим большинства узлов и дисков.
Рис 4. Режимы кворума в мастере настройки кворума кластера (щелкните изображение, чтобы увеличить его)
Чтобы выбрать диск-свидетель из доступного хранилища, выберите первый диск размером не менее 500 мегабайт, на котором есть раздел NTFS. Оставшиеся режимы кворума можно установить вручную, запустив мастер настройки кворума кластера. Режим большинства узлов и общих файловых ресурсов обычно используется в составах кластеров с узлами в нескольких филиалах или в кластере CCR Exchange 2007. Последний режим – отсутствие большинства и использование только диска – эквивалентен модели общего кворума в старых кластерах. Он представляет из себя слабое звено, и обычно его не следует использовать.
Существуют лишь два типа ресурсов-свидетелей (физический диск и общий файловый ресурс), которые можно настроить в кластере для помощи в достижении консенсуса.
Диск-свидетель – это часть хранилища, которую служба кластера может вывести в оперативный режим. Этот диск расположен в группе основных ресурсов кластера вместе с сетевым именем кластера и связанными ресурсами IP-адреса. Когда диск-свидетель настроен, на диск помещается папка кластера и полная копия настройки кластера (куст кластера или копия).
FSW – это общий сетевой ресурс, который, в идеале, расположен на сервере в сети, не являющейся частью кластера. К FSW производится подключение по протоколу SMB, и FSW поддерживает копию файла журнала свидетеля, содержащую информацию о версиях настройки кластера.
В кластере может быть настроен лишь один ресурс-свидетель. Этот ресурс предоставляет дополнительный голос, если таковой понадобится ресурсу для достижения кворума. Другими словами, если кластеру не хватает одного голоса (и, следовательно, одного узла) для достижения консенсуса, то для достижения кворума подключается ресурс-свидетель. Если для достижения кворума кластеру не хватает более чем одного голоса, ресурс-свидетель оставляется в покое, а кластер остается в неактивном состоянии, ожидая присоединения еще одного узла кластера.

Улучшенные возможности безопасности
В отказоустойчивых кластерах появилось несколько новых усовершенствовании безопасности. Вероятно, наиболее значительное из них связано с устранением требования наличия учетной записи службы кластеров (Cluster Service Account – CSA). В предыдущих версиях службы кластеров Майкрософт в ходе процесса настройки требовалась учетная запись пользователя домена. Эта учетная запись, которая использовалась для запуска службы кластеров, добавлялась к группе локальных администраторов на каждом узле кластера и давала учетные права локального пользователя, чтобы обеспечить верное функционирование службы кластера. В качестве учетной записи пользователя домена CSA подпадал под ряд политик уровня домена, которые могли быть применены к узлам кластера. Эти политики могли отрицательно повлиять на высокую доступность, вызывая сбой службы кластера.
Теперь служба кластера работает, используя учетную запись локальной системы с определенным набором прав на локальном узле кластера, которые позволяют ей правильно функционировать. Контекст безопасности для кластера перенесен на объект имени кластера (Cluster Name Object – CNO), являющийся объектом компьютера, создаваемым по умолчанию в контейнере «Компьютеры» Active Directory® в момент создания кластера. После того, как кластер успешно создан, и CNO существует в Active Directory, учетная запись пользователя, использовавшаяся для установки и настройки кластера, более не нужна.
Дополнительные объекты компьютера, создаваемые в контейнере «Компьютеры» Active Directory, связаны с отказоустойчивым кластером. Эти объекты, именуемые объектами виртуальных компьютеров (Virtual Computer Object – VCO), приравниваются к ресурсам сетевого имени кластера, создаваемыми как часть точек доступа клиента (Client Access Points – CAP) в кластере. CNO, ответственный за создание всех VCO в кластере, добавляется к системному списку управления доступом (System Access Control List – SACL) объекта в Active Directory (см. рис. 5).
Рис 5. Безопасность на объекте виртуального компьютера (VCO) в Active Directory (щелкните изображение, чтобы увеличить его)
CNO также берет на себя ответственность за синхронизацию паролей домена со всеми созданными им объектами VCO. Этот процесс выполняется в соответствии с настроенной для домена политикой ротации паролей. Вдобавок, поскольку объект CNO ответственен за создание всех компьютерных объектов в кластере, связанных с объектами VCO, объект CNO (учетная запись компьютера) должен иметь права уровня домена для создания объектов компьютера в контейнере, где создаются объекты VCO (по умолчанию, это контейнер «Компьютеры»).
Другое изменение состоит в том, что Kerberos теперь используется как метод проверки подлинности по умолчанию. Эта улучшенная функция безопасности становится возможной благодаря наличию учетных записей компьютеров в Active Directory. Но кластер имеет возможность использовать проверку подлинности протокола NT LAN Manager (NTLM), если приложению, не способному использовать для проверки подлинности Kerberos, понадобится доступ к ресурсам кластера.
Также более безопасна связь между узлами кластера, напрямую имеющими дело с процессом кластера. По умолчанию, все сообщения внутри кластера подписываются. Через интерфейс общего языка (CLI) cluster.exe это свойство кластера может быть изменено так, чтобы для предоставления дополнительного уровня безопасности шифровались все сообщения между узлами.

Расширенные функции сети
Новые возможности работы с сетью в отказоустойчивых кластерах делают возможной большую гибкость при разработке решений высокой доступности и аварийного восстановления. В то же время, эти усовершенствования работы с сетью предоставляют более надежную связь между узлами кластера.
Вероятно, наиболее запрашиваемой клиентской функцией была возможность обнаруживать узлы кластера на разделенных сетях. Теперь это возможно. Драйвер сети кластеров полностью переписан, так что теперь он предоставляет весьма надежную и отказоустойчивую связь между различными узлами в кластере при условии, что каждый узел подключен минимум к двум отдельным и различно маршрутизируемым сетям.
Драйвер сети кластеров собирает собственную таблицу внутренней маршрутизации в зависимости от информации о подключении, предоставленной в процессе запуска кластера. В ее состав входят сведения о локальном подключении, а также информация, предоставляемая в базе данных настройки кластера (кусте реестра кластера).
Частью процесса проверки кластера является процесс обнаружения связи по сети. Возможность обнаруживать узлы кластера в различных маршрутизируемых сетях сделала менее жесткими требования к работе сети для кластеров с узлами в нескольких филиалах. Это упрощает и удешевляет развертывание их организациями. Это также позволяет использовать хранилища iSCSI, более привлекательное решение хранения для отказоустойчивых кластеров.
Узлы кластеров также могут получить информацию о IP-адресе через протокол DHCP. Это может снизить нагрузку на сетевых администраторов, если они способны принять использование динамической адресации для серверов в своей среде.
Настройка сетевых интерфейсов узла кластера определяет, какие сети будут использовать статические или динамические IP-адреса. Даже если ресурс IP-адреса в кластере получен от сервера DHCP, он может быть изменен на статический IP-адрес в оснастке управления отказоустойчивыми кластерами.
В прошлом вся связь в кластере использовала широковещательную и порой многоадресную передачу по протоколу пользовательских датаграмм (User Datagram Protocol – UDP). Поддержка многоадресности прекращена, и связь в кластере теперь использует одноадресную передачу UDP. (Порт 3343 остается общим портом, используемым кластерами Майкрософт.) Многих сетевых администраторов очень обрадует исчезновение широковещательной передачи. Но реальная отдача для кластера связана с новым процессом обмена сообщениями, внутренними для самой службы кластера. (Это, однако, выходит за рамки данной статьи.) Связь внутри кластера теперь имеет характеристики более надежной связи TCP, хотя и теперь в качестве механизма передачи используется UDP.

Повышенная надежность при взаимодействии с хранилищем
Способ взаимодействия отказоустойчивых кластеров с хранилищем радикально отличается от прежнего. Драйвер диска кластера (clusdisk.sys) был полностью переписан и теперь является настоящим драйвером Plug and Play (PnP), а способ его взаимодействия с хранилищем изменен.
В Windows Server 2003 драйвер диска кластера находился на прямом пути к хранилищу. Но в Windows Server 2008 драйвер диска кластера сообщается с драйвером диспетчера раздела (partmgr.sys), чтобы взаимодействовать с хранилищем. Эти два подхода проиллюстрированы на рис. 6.
Рис. 6. Как изменен стек хранилища в Windows Server 2008 (щелкните изображение, чтобы увеличить его)
Основной обязанностью диспетчера раздела является защита дисковых ресурсов кластера. Все диски на общей шине хранилища автоматически помещаются в автономное состояние при первой установке соответствия с узлом кластера. Это позволяет одновременно установить соответствие хранилища со всеми узлами в кластере, даже до создания самого кластера. Больше не нужно загружать узлы по одному, готовить диски на одном, отключать этот узел, загружать другой, проверять настройку диска и т.д.
Однако всё ещё существуют тесты хранилища, выполняемые как часть процесса проверки кластера и требующие инициализации дисков. Они могут быть проделаны на одном из узлов в кластере перед выполнением процесса проверки. После того, как хранилище добавлено к кластеру, в интерфейсе управления дисками диски будут показаны как зарезервированные и не останутся в незащищенном состоянии.
Другое изменение имеет отношение к командам SCSI. В Windows Server 2003 команды SCSI-2 «Зарезервировать\Освободить» использовались для драйвера диска кластера, записывающего на секторы самого диска. В Windows Server 2008 требуются команды постоянного резервирования SCSI-3. Узлы кластера должны зарегистрироваться, прежде чем им будет позволено резервировать свое хранилище; они также периодически защищают свои резервирования, используя протокол защиты регистрирования.
Один из тестов хранилищ из процесса проверки проверяет эту функцию. Если решение хранилищ не поддерживает команды постоянного резервирования SCSI-3, оно не поддерживается отказоустойчивыми кластерами.
Многие организации используют программы с несколькими путями для избыточности при подключении к хранилищу. Это поддерживается и даже поощряется как лучший вариант. Однако, программные решения с несколькими путями от сторонних производителей или модули конкретных устройств должны быть переписаны с использованием стандарта Microsoft Multi-Path Input\Output, чтобы поддерживаться отказоустойчивыми кластерами. Это гарантирует, что все команды постоянного резервирования SCSI-3 одновременно отправляются по всем путям в хранилище независимо от того, активен ли путь или нет. Эта функциональность также проверяется в рамках процесса проверки.
В число дополнительных улучшений хранилищ входят улучшенный процесс проверки диска (chkdsk.exe), встроенные функции восстановления дисков, ранее бывшие частью программы восстановления Cluster Server Recovery Utility, и самовосстанавливающиеся диски. В отказоустойчивых кластерах и подпись диска, и идентификатор LUN используются при определении ресурса диска кластера. Если что-то из них изменилось, настройка кластера обновляется. Это вызывает снижение числа ошибок просто потому, что изменение атрибута на ресурсе физического диска ведет к большему уровню высокой доступности.

Встроенные процессы аварийного восстановления
Ранее упомянутое восстановление диска, очевидно, является одной из встроенных возможностей аварийного восстановления. Еще одной из них является возможность восстановления Active Directory. Если объект компьютера, представляющий CNO, удален, создавать объекты компьютера, связанные с клиентскими точками доступа кластера, станет невозможно. Однако первой проблемой, с которой придется столкнуться, вероятно будет невозможность для высокодоступных приложений и ресурсов получить доступ к ресурсам за пределами кластера из-за невозможности получить маркер безопасности
Восстановление после удаления объекта CNO идет в две стадии. Сперва необходимо, чтобы администратор домена восстановил удаленный объект компьютера из контейнера DeletedObjects в Active Directory. Затем, после того, как объект был восстановлен и заново включен, выполняется процесс восстановления объекта Active Directory в оснастке управления отказоустойчивыми кластерами.
В кластерах серверов Windows Server 2003 имелась возможность того, что файл настройки кластера, расположенный в подкаталоге %systemroot%\cluster, будет поврежден, и его понадобится заменить. В отказоустойчивых кластерах может помочь возможность самовосстановления. Если служба кластера запускается на узле, а база данных настройки повреждена, будет загружен минимальный шаблон настройки с использованием информации, содержащейся в разделе реестра HKLM\System\CCS\Services\ClusSvc\Parameters. Узел попытается присоединиться к уже сформированному кластеру, и, если попытка успешна, свежая копия куста реестра кластера будет направлена на узел. Если узел не сможет присоединиться к кластеру, служба кластера будет завершена.

Новые функции резервного копирования и восстановления
Отказоустойчивая кластеризация имеет собственный модуль записи службы теневого копирования томов. Это играет ключевую роль в резервном копировании и восстановлении базы данных кластера и данных, находящихся на ресурсах физического диска. Резервное копирование настройки кластера довольно незамысловато. Пока состояние системы является частью резервной копии, настройку кластера можно восстановить. Но обратите внимание, что резервное копирование кластера возможно только при наличии кворума у кластера. Это гарантирует наличие резервной копии самой последней настройки кластера.
Существует два различных типа восстановлений кластера: полномочное и неполномочное. При неполномочном восстановлении используется программа архивации данных Windows Server или приложение резервного копирования от стороннего производителя для выполнения восстановления из выбранной резервной копии. Полномочное восстановление узла кластера, с другой стороны, может быть выполнено лишь с помощью интерфейса командной строки программы архивации данных Windows Server (wbadmin.exe).
Полномочное восстановление, по сути, «отматывает назад» настройку кластера до момента создания резервной копии. Для выполнения полномочного восстановления служба кластера останавливается на всех узлах, кроме узла, на котором исполняется восстановление. После того, как восстановление завершено и служба кластера запущена на восстановленном узле, восстановленная настройка кластера становится новой, определяющей настройкой кластера. Затем, когда служба кластера запущена вновь на оставшихся узлах в кластере, восстановленная настройка направляется им в ходе процесса присоединения.
В определенных случаях это может существенно сэкономить время и деньги. Предположим, что у нас имеется кластер печати, размещающий несколько ресурсов диспетчера очереди печати, каждый из которых поддерживает 1 500 принтеров, и один из этих ресурсов случайно удален. Теперь большое число пользователей не может выполнять печать. Вместо того, чтобы вручную добавлять все эти принтеры обратно к настройке кластера, гораздо быстрее будет выполнить полномочное восстановление настройки кластера. Это, конечно, зависит от наличия основательной стратегии резервного копирования и восстановления.

Переход с кластеров серверов Windows Server 2003
В силу всех изменений архитектуры в отказоустойчивой кластеризации Windows Server 2008, обновления поверх существующей системы Windows Server 2003 и поэтапные обновления не поддерживаются. При переходе с кластеров Windows Server 2000 на Windows Server 2003 многие организации систематически исключали узлы в кластере по одному, выполняли чистую установку операционной системы и затем добавляли узел обратно в кластер. Этот подход нельзя использовать для перехода на Windows Server 2008, поскольку узлы кластера Windows Server 2003 и Windows Server 2008 не могут быть частью одного кластера.
К счастью, для облегчения перехода добавлен процесс перехода на основе мастера. Все же переход на отказоустойчивый кластер Windows Server 2008 требует некоторого планирования. Вот три базовых варианта перехода:
  • Использование тех же серверов и хранилища.
  • Использование тех же серверов, но с новым хранилищем.
  • Использование новых серверов и хранилища.
В любой из этих вариантов входит проверка того, что оборудование прошло проверку по программе использования логотипа Windows Server 2008 и что все тесты процесса проверки отказоустойчивого кластера завершились успешно. По выполнении этих действий может начаться процесс перехода.
Не все ресурсы в кластере серверов Windows Server 2003 могут быть перенесены. Могут быть перенесены сетевые имена, IP-адреса, физические диски, общие файловые ресурсы, распределенный общий файловый ресурс, DHCP и WINS. В ограниченной степени можно также перенести универсальные службы, универсальные приложения и универсальные ресурсы сценариев.
В то же время, такие приложения, как Microsoft Exchange и SQL Server®, имеют свои процедуры по переносу на отказоустойчивый кластер. Принтеры могут быть перенесены на Windows Server 2008 посредством использования оснастки управления печатью (которая устанавливается с ролью сервера печати) для экспорта и последующего импорта принтеров на свеженастроенный высокодоступный сервер печати. Типы ресурсов от сторонних производителей не могут быть перенесены.
В процессе перехода данные не переносятся. В этом процессе происходит перенос параметров настройки кластера с Windows Server 2003 на Windows Server 2008.
Все перенесенные ресурсы по завершении процесса переноса первоначально помещаются в автономное состояние. Это выполняется в силу возможной необходимости дополнительных действий. Следовательно, важно проверить отчет по итогам переноса, чтобы увидеть, какие дополнительные действия (помимо переноса данных при переходе на новое хранилище) могут потребоваться перед началом работы кластера. Например, при переносе сервера DHCP на всех узлах в кластере должна быть установлена роль сервера DHCP, а при переносе сервера WINS на всех узлах в кластере должен быть установлен компонент сервера WINS.

Чак Таймон (Chuck Timon) – инженер по улучшению поддержки в Майкрософт, поддерживающий технологии кластеров и установки. Он написал учебный курс по отказоустойчивым кластерам Windows Server 2008 и сейчас работает над обучением Hyper-V.


От редактора Печать мертва
Джошуа Хоффман (Joshua Hoffman)

Печать мертва. Во всяком случае, многие пытаются убедить нас в этом. Что делать собранию листов бумаги, соединенному клеем, в нашу эпоху неограниченной информации, доступной во всяческих формах, в любое время, откуда угодно, на множестве фантастических устройств? Не вышло ли его время? Следует ли журналам и газетам перейти на роль экземпляров Смитсоновского музея, чтобы мы в один прекрасный день смогли ностальгировать о том, что для нас значило носить с собой спрессованные куски древесины и чернил?
Малость мелодраматично? Да. Но я уверен, что вы понимаете – я совершенно не согласен с такой идеей (и не только ради сохранения места, в Майкрософт мне найдется достаточно работы). Я твердо убежден, что печатное слово предоставляет необычайно насыщенные и глубокие впечатления, несмотря на свою простоту (или, возможно, благодаря ей). Когда я сижу и читаю длинную статью, я почти всегда предпочел бы иметь бумажную версию в моих руках вместо компьютерного экрана. Для меня это просто более привлекательно. Не устарела ли такая точка зрения? Возможно, но согласно нашему последнему опросу читателей, 90% из вас чувствуют точно так же.
Ну, я, конечно, не предлагаю прятать голову в песок. Я фанат из фанатов, обожающий новые технологии. Но издание вроде нашего может (и должно) производить целостное впечатление, принимающее различные формы – сетевую, автономную и личную. Конечно, если мне нужно прочесть длинную, полную технических подробностей статью от Марка Руссиновича (Mark Russinovich), я бы хотел, чтобы она была напечатана. Но я бы также хотел воспользоваться лекцией Марка и пронаблюдать, как он демонстрирует методику, о которой рассказывает.
Этот взгляд стал руководящим принципом для журнала TechNet Magazine. И хотя мы продолжаем гордиться изданием, которое отсылаем в печать каждый месяц, всё когда либо напечатанное нами содержимое также доступно по адресу, заканчивающемуся на .com. И в ближайшем будущем читатели смогут увидеть еще больше содержимого, использующего уникальную платформу, доступную для нас в лице Интернета. Например, в прошлом выпуске мы начали нашу серию «Демонстрационный ролик» с Дона Джонса (Don Jones) и его рубрики по Windows PowerShell. Теперь Дона и его разбор темы выпуска рубрики за этот месяц можно увидеть на видео. На нашем веб-узле также можно найти рубрику «Экологически безопасная компьютеризация», целиком посвященную влиянию информационных технологий на окружающую среду и тому, что мы, как специалисты по ИТ, можем сделать, чтобы быть ответственными обитателями планеты.
Как всегда, ваши отзывы важны для нас, поскольку мы продолжаем превращать TechNet Magazine в богатый источник информации. Пишите по адресу tnmag@microsoft.com.
—Джошуа Хоффман (Joshua Hoffman)

Мы бы хотели поблагодарить следующих технических специалистов корпорации Майкрософт: Эда Банти (Ed Banti), Авронила Бхаттачарджи (Avronil Bhattacharjee), Нино Билича (Nino Bilic), Мэй-лан Томсен Буковец (Mai-lan Tomsen Bukovec), Эрика Чаррэна (Eric Charran), Элдена Христенсена (Elden Christensen), Трину Горман (Trina Gorman), Скотта Лэндри (Scott Landry), Майкла Мерголо (Michael Murgolo), Санджива Нэйра (Sanjeev Nair), Хью Пайла (Hugh Pyle), Амританша Рагхава (Amritansh Raghav), Джеза Садлера (Jez Sadler) и Джима Трухера (Jim Truher).


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

Службы доменов Active Directory
Мне определенно понравился выпуск журнала TechNet Magazine за март 2008 г. Думаю, я прочитал его уже 12 раз! В частности, мне особенно понравилась статья «Новые возможности доменных служб Active Directory в Windows Server 2008» Джила Киркпатрика. В этой статье Джил упоминает продукт под названием службы ACS Microsoft®. Доступен ли этот продукт и работает ли он как отдельное приложение?
— Эразмо М.

Службы ACS Microsoft входят в состав System Center Operations Manager (SCOM), программы управления, ранее известной как Microsoft Operations Manager (MOM). Она не доступна как отдельный продукт и поставляется только в составе SCOM.
— Джил Киркпатрик, руководитель технологического отдела компании NetPro и автор журнала TechNet Magazine

Подписи
Во втором параграфе статьи из рубрики Windows PowerShell в выпуске журнала TechNet Magazine за апрель 2008 г. («А вот тут, пожалуйста, подпись», technet.microsoft.com/magazine/cc434702) Дон Джонс говорит: «То, о чем пойдет здесь речь, обозначается термином "подпись", но само это слово на самом деле не совсем точно описывает суть происходящего. Когда вы подписываете сценарий, вы не утверждаете его, не подтверждаете его правильность, как в случае контрактов или чеков при оплате кредитной картой.»
Я не соглашусь с тем, что подписание контракта или чека при оплате кредитной картой не обязательно утверждает или подтверждает эти объекты. Выполненное действие является значимым только в контексте большего представления среды. Например, в детстве я играл с чеками оплаты кредитной картой на сервисной станции своего отца — никто никогда не пытался взимать долги, понесенные мной в результате этих операций.
В контексте «правильно настроенной» реализации сети Active Directory® именно подпись авторизует выполнение сценария. Наличие подписи означает, что подписавшееся лицо берет на себя ответственность за все подписанное; наличие подписи может в дальнейшем вызывать выполнение последующих действий — выставление счета компанией эмитентом кредитной карты или подтверждение сетью подлинности кода.
Продолжайте так же успешно работать, журнал TechNet Magazine очень полезен.
— Джереми П.

Спасибо за отзыв, Джереми. Приятно знать, что наши читатели так пристально следят за материалами журнала TechNet Magazine.

Службы SharePoint Services
Необходимы ли дополнительные клиентские лицензии (CAL) для пользователей, осуществляющих доступ к службам Windows® SharePoint® Services (WSS), не к Microsoft Office SharePoint Server, через интерфейс/URL-адрес веб-узла?
— Дуглас М.

По этому вопросу доступно несколько документов. Вот несколько полезных ссылок: msmvps.com/blogs/cgross/archive/2005/04/02/40723; microsoft.com/windowsserver2003/howtobuy/licensing/extconnector.mspx и windowsserver/sharepoint/bb684457.
— Пав Черни, ведущий рубрики «Внутри SharePoint» журнала TechNet Magazine

Идея для рубрики «Sharepoint изнутри»
Недавно я прочитал статью о SharePoint в выпуске журнала TechNet Magazine за май 2008 г. (technet.microsoft.com/magazine/cc462809). Вы спрашивали читателей о предложениях по этой теме. Большая статья об интеграции SharePoint с Project/Project Server была бы замечательной.
— Фил Х.

Project/Project Server – это отличная идея! Мы непременно обратимся к этой теме в одном из будущих выпусков. Спасибо за ответ,

Другие идеи для рубрики «Sharepoint изнутри»
В Интернете доступно множество материалов по настройке узлов с помощью стандартного пользовательского интерфейса SharePoint или SharePoint Designer, но совсем немного по определениям узлов (а в доступных статьях содержатся только основные сведения, и они мало пригодны для решения реальных проблем). Так как эту область начинает изучать много людей, подробные инструкции могут только способствовать внедрению SharePoint. В частности, моя компания сталкивалась со следующими проблемами.
  1. Установка пользовательских разрешений для списков в определении узла.
  2. Формы элементов специального списка в определении узла.
  3. Подключения веб-компонентов в определении узла.
  4. Как осуществляется постепенное предоставление определения узла.
— Адам С.

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


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

Автоматизируйте задачи администратора
Automise 2
automise.com/automise.aspx
Повторяющиеся, не требующие умственных усилий задачи скучны, утомительны и подвержены ошибкам. Автоматизация задач этого типа является ключевым элементом успешного администрирования и может дает возможность почувствовать удовлетворение от работы. Помимо унылых пакетных файлов и специальных сценариев VBScripts для автоматизации задач, существует ряд подобных макросам служебных программ для Windows® и несколько служебных программ, которые вообще заставляют пользователя учить один из специальных языков сценариев. Но существует и другое решение. Программа Automise 2 от компании VSoft Technologies позволяет создавать процедуры автоматизации через графический интерфейс перетаскивания и настройки стиля.
Интерфейс приложения во многом подобен стандартной интегрированной среде разработки для программистов и предлагает знакомые возможности. Пользователю предоставляются инструментарий, из которого можно перетаскивать элементы в область конструктора, элементы управления для отладки, делающие возможным пошаговое выполнение кода, представление различных проектов, протоколы выходных данных выполнения, журнал и окна свойств. Но в случае Automise «код» на самом деле является визуальным представлением потока работ автоматизированной задачи.
Инструментарий Automise состоит из действий, каждое из которых является этапом процесса автоматизации. Всего в приложение включены 380 действий, охватывающих весь спектр возможных операций от создания файлов .zip до перезапуска IIS.
При разработке своей задачи эти действия можно иерархически структурировать, чтобы охватить многие из регулярно выполняемых процедур администрирования. Кроме того, эти действия можно связывать посредством действий контроля потока, таких как блоки try/catch, выдача исключений, условные операторы, циклы, параметры, задержки и асинхронные группы действий.
В каждый из проектов автоматизации могут также входить другие проекты, что позволяет отделить основной процесс управления от его подзадач. Существуют также действия для управления строками и данными XML , установки переменных, ожидания процессов и команд и многого другого. Благодаря всем этим возможностям управления потоком доступна даже автоматизация сложных операций.
Automise позволяет создавать, запускать, изменять и удалять назначенные задания. Это значит, что Automise можно использовать и для управления существующими процессами. Здесь не хватит для перечисления всех действий, но среди них можно выделить следующие: действия по регистрации библиотек DLL в глобальном кэше сборок (GAC), восстановление индексов SQL Server®, запуск chkdsk, внесение изменений в реестр, резервное копирование журнала событий, изменение пользователей Active Directory®, создание точек восстановления и создание виртуального каталога. А на тот случай, если встроенным действиям не под силу выполнить требуемое, у Automise также есть модифицируемые сценарии, команды и создаваемые на месте действия исполнения SQL.
Так или иначе, это средство не помешает иметь под рукой. Если же необходимо автоматизировать лишь собственную рабочую станцию Windows, а не инфраструктуру сети, стоит обратить внимание на Automise Lite, удовлетворяющую большинство потребностей опытного пользователя, несмотря на ограниченный набор возможностей.
Цена: от 195 долларов США (за лицензию на одного пользователя).
Автоматизируйте свои задачи в визуальном режиме с помощью Automise 2 (щелкните изображение, чтобы увеличить его)

Наблюдайте за журналами в реальном времени
BareTailPro
baremetalsoft.com/baretailpro
Файлы журналов, файлы журналов, они везде! Но использование их – это немалая нагрузка. Если созданное приложение выдает журнал транзакций, это отлично. В дополнение к использованию средств объединения журналов, как можно действительно отследить в реальном времени то, что происходит? Одно из решений – проверенное средство BareTailPro от компании Bare Metal Software. Эта простая служебная программа, хоть она и не обновлялась с 2006 года, все еще остается улучшенным аналогом старой консольной команды 'tail -f' систем *nix для Windows.
С помощью ее незамысловатого графического интерфейса пользователя можно одновременно отслеживать несколько файлов журналов любого размера, прозрачно и в реальном времени отслеживая то, что записывается в них. Для переключения между файлами достаточно щелкнуть вкладку. И, что очень удобно, каждая вкладка отображает значок, сигнализирующий состояние каждого файла журнала, указывая, ведется ли запись в файл или его «хвост» остановился.
Хотя большинство приложений ведут журнал, делают это они обычно по-разному. К счастью, BareTailPro может читать файлы в кодировках Юникод, UTF-8, ANSI и ASCII и может разобраться, заканчиваются ли их строки парами CR/LF, единственными LF или нулями. Как перенос по словам, так и развертывание вкладок можно легко настроить для получения лучшего представления о конкретном типе файла журнала. Вдобавок можно улучшить читаемость файла журнала путем настойки размера шрифта, его типа, интервалов и высоты строк.
Другой отличной функцией этого приложения является настраиваемое выделение, которое можно применить к представлению журнала. Можно установить любое число правил кодирования цвета переднего плана и фона на основе строки текста. Например, можно выделять любую ошибку красным и предупреждение желтым, либо выбрать выделение всех строк, содержащих определенный IP-адрес или ссылку на узел. Для строк можно указывать выделение курсивом или полужирным шрифтом, а также выбирать игнорирование регистра строки текста.
Даже при наличии выделения текста агрессивный файл журнала может перегрузить восприятие пользователя, сделав сложным обнаружение искомых событий. BareTailPro предлагает еще одну функцию, которая может помочь в этом. Регулярные выражения и поиск по тексту позволяют быстро отсеять лишнее из представления журнала, изолируя проблемные экземпляры строк в поднабор, с которым можно справиться. Синтаксис регулярного выражения, используемый BareTailPro, состоит из поднабора стандартной системы символов, используемой Java, Perl и PHP. Для тех, кто не знаком с этим использованием, на веб-узле продукта предоставлена краткая справка.
Служебная программа показывает отфильтрованные результаты в табличном виде, добавляя несколько полезных столбцов, таких как метка времени, номер строки и результаты любых групп записи данных, которые были определены вместе первоначальным источником строки. В отфильтрованном представлении эти столбцы также можно упорядочить.
Я постоянно забываю синтаксис «волшебных» регулярных выражений, давших мне нужные результаты. Именно по этой причине я весьма ценю функцию сохранения шаблона этого средства. Она позволяет именовать, изменять и сохранять шаблоны для дальнейшего использования. После того, как важные строки оказались в отфильтрованном представлении, BareTailPro также позволяет экспортировать результаты в файл или в буфер обмена со специально подобранным форматом, позволяющим установить такие вещи, как длину, выравнивание префикс и суффикс для каждого из столбцов результатов.
Впечатляет, что эта крохотная служебная программа содержится в единственном и небольшом исполняемом файле, что делает ее легко передаваемой и не оказывающей серьезного влияния на среду. Обратите внимание, что если необходимо лишь следить за файлами журналов, а фильтрации на основе регулярных выражений, сохранения шаблонов поиска, а также экспорта результатов поиска и фильтрации не требуется, можно обойтись бесплатной версией, именуемой BareTail.
Цена: от 35 долларов США за индивидуальную лицензию.
Наблюдайте за своей сетью с помощью BareTailPro (щелкните изображение, чтобы увеличить его)

Инвентаризуйте свои системы
Total Network Inventory
softinventive.com
Наличие быстрого доступа к подробной информации о компьютерах, находящихся в среде, является ключевой частью успешного управления системами. Таблицы и реестры поставщиков с этой информацией легко теряются, быстро устаревают, и их сложно поддерживать полными.
Использование динамического средства, собирающего информацию о том, кто установил что и на каком оборудовании это работает, а затем предоставляющего ее по мере необходимости, может быть очень полезным. Средство такого рода также предоставляет отличный способ отслеживания того, что пользователи могли дополнительно установить на своих компьютерах. (Это само собой, если групповая политика не ограничивает права на установку и так или не предоставляет быстрые подсчеты числа лицензий, которые должны иметься, с учетом базы пользователей определенного программного пакета.) Одним из средств, соответствующих этим требованиям, является Total Network Inventory от компании Softinventive Lab.
После установки Total Network Inventory можно начать процесс инвентаризации, используя мастер проверки, который проводит пользователя через этапы обнаружения узлов в его сети. Можно начать проверку немедленно через указанный диапазон IP-адресов или просмотр компьютеров сетевого окружения, либо можно использовать проверку на основе сценария входа, которая позволяет собирать информацию при входе компьютера в домен.
Для выполнения своих проверок Total Network Inventory полагается на инструментарий управления Windows (WMI), либо IPC$\ADMIN$, либо RPC/DCOM, а также на обычный совместный доступ для локальных учетных записей. Так что запускать ее следует в контексте учетной записи администратора.
После того, как сканирование закончено, можно просматривать компьютеры или искать конкретные компьютеры для инвентаризации их ресурсов. Total Network Inventory разделяет собранную информацию на три группы: оборудование, программное обеспечение и прочее. В раздел оборудования входят сведения о процессоре, материнской плате и ее наборе микросхем, памяти, подсистеме видео, устройствах хранения (включая физические и логические), типах и настройках сетевого адаптера, периферии и любых других устройствах, установленных на системе.
Раздел программного обеспечения предоставляет информацию об ОС, в том числе ключи продуктов, серийные номера, системные каталоги и установленные пакеты обновления. Здесь же находятся сведения об исправлениях (с соответствующими номерами статей из базы сведений о разрешении проблем), а также любых установленных приложениях антивирусов и баз данных. Также выдается список установленных программ (вместе с представлением каталога Program Files, позволяющим увидеть программы, скрытые от стандартного перечисления «Установка и удаление программ») и перечисление автоматически запускемых приложений.
Наконец, в разделе «прочее» содержатся сведения о системной среде, такие как переменные пользователя и системы, общие ресурсы, работающие процессы, установленные службы и локальные учетные записи пользователей.
Total Network Inventory на практике дает необходимую информацию для выполнения аудита ресурсов, проверок лицензий, планирования обновлений и оценок производительности. Одной из лучших частей этого средства является компонент создателя отчетов. Этот компонент дает несколько хорошо организованных, подробных отчетов обо всем, от быстрой справки до документации аудита. Отчеты могут быть как сводными, так и от одного компьютера. Особенно полезным компонентом мне кажется представление вкладки Software and Licenses Accounting («Подсчет программного обеспечения и лицензий»). Оно отображает сводку результатов учета для каждого типа программного обеспечения, установленного в среде, помогая обеспечить соблюдение условий контрактов с поставщиками.
Цена: от 95 долларов США за лицензию на 25 узлов.
Мастер проверки проводит пользователей через обнаружение сетевых узлов (щелкните изображение, чтобы увеличить его)

Рецензия на книгу
Mastering Microsoft Exchange Server 2007
sybex.com
Нравится ли это или нет, электронная почта является стержневым компонентом организации, работающей без проблем. (Хотя я должен признать, что мне порой хочется, чтобы прохождение курса по эффективному письменному общению стало обязательным условием допуска пользователя к электронной почте.) И с течением времени желание интегрировать голосовую связь, календарь, планирование использования ресурсов, единообразный клиентский доступ и фильтрацию почты (на предмет спама, вирусов и так далее) стало более чем явным. Здесь то и появляется на сцене Microsoft® Exchange Server 2007.
Последняя версия Exchange без проблем интегрирует все эти компоненты в масштабируемое, надежное решение. Но при наличии всех этих компонентов и функций администратору, системному архитектору и работникам технической поддержки необходимо несколько хороших справочников, чтобы помочь им в планировании, развертывании, управлении и обслуживании подобного динамического решения по обмену электронными сообщениями.
В последнем выпуске рубрики «Инструментарий» я рассказал о Microsoft Exchange Server 2007 Administrator's Companion («Спутник администратора Microsoft Exchange Server 2007»). Другим хорошим источником сведений, который стоит учесть, является книга Mastering Microsoft Exchange Server 2007 («Освоение Microsoft Exchange Server 2007»), написанная Барри Гербером (Barry Gerber) и Джимом Макби (Jim McBee) (изд-во Sybex, 2007 г.). Это четко написанное руководство, проводящее читателя через весь цикл работы Exchange Server.
В первых трех главах книги, в разделе, озаглавленном "Understanding and Planning" («Ознакомление и планирование»), рассматриваются базовые компоненты и требования, которые необходимо выполнить для применения Exchange Server 2007. Те, кто знаком с предыдущими версиями Exchange, оценят раздел по функциям, которые больше не применяются или не являются важными. И все без исключения оценят обрисовку различных ролей серверов и компонентов, из которых состоит развертывание Exchange Server 2007. Развертывание такого сложного сервера определенно требует некоторого предварительного обдумывания, и читателю стоит обратить внимание на разделы по планированию будущего роста, требованиям к пространству на диске и интеграции с Active Directory.
В следующем разделе рассматривается собственно установка, куда входят как чистая установка, так и обновление с Exchange Server 2000 либо Exchange Server 2003 (обновиться напрямую с Exchange Server 5.5 нельзя). Здесь можно найти дополнительные сведения о различных ролях, которые может играть каждый сервер Exchange, – ролях пограничного транспортного, клиентского доступа, транспортного сервера-концентратора, почтового ящика, единой системы обмена сообщениями и средств управления.
Затем книга переходит к масштабируемости, показывая, как наблюдать за производительностью, добавлять дополнительное пространство для хранения в почтовых ящиках и так далее. Далее исследуется очень интересный, новый компонент – локальная непрерывная репликация, которая позволяет поддерживать своевременно обновляемую резервную копию хранилища почты. Если что-то случилось с основной базой данных, можно быстро переключиться на резервную копию без необходимости производить восстановление с какой-либо другой, менее доступной и менее свежей резервной копии.
В следующием разделе книги предоставлены подробные обзоры различных заданий и средств управления, предоставляемых развертыванием Exchange Server 2007. В их число входят такие средства, как командная консоль Exchange (основанная на Windows PowerShell™) и графический интерфейс консоли управления Exchange (который также полагается на механизм Windows PowerShell). В этом разделе можно узнать, как управлять почтовыми ящиками, списками адресов и учетными записями пользователей. Он также охватывает управление записями сообщений, а также классификацией сообщений, ведением журнала и правилами транспорта.
В четвертом разделе даны дополнительные подробные сведения о доступности и надежности. Теперь, когда компании стали зависимы от обмена электронными сообщениями, этот раздел более чем заслуживает внимания.
В нем можно познакомиться с основами балансировки нагрузки, избыточности серверов, хранилищ и сетей, а также кластеризации. Вслед за ними можно найти практические рекомендации по запланированному обслуживанию, ведению резервного копирования и ситуациях аварийного восстановления – по сути, вещах, которые необходимо знать, чтобы обеспечить эффективное функционирование системы обмена электронными сообщениями компании даже при возникновении проблем.
Следующие два раздела книги охватывают доступ клиентских программ, включая Microsoft Office Outlook® 2007, Outlook Web Access, IMAP и POP3. И наконец, заканчивается книга разделом, важность которого для администратора Exchange сложно переоценить – разделом по безопасности и аудиту, демонстрирующим базовые методики безопасности и меры предосторожности вместе с различными средствами аудита, находящимися в распоряжении пользователя. В целом, этот подробный справочник поможет читателю разобраться в Exchange и направить свое развертывание на верный путь.
Цена: 49,99 долларов США (прямая продажа).

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


Utility Spotlight Microsoft SharedView
Грег Стин (Greg Steen)

Я часто работаю с коллегами с другого конца мира, и постоянно возникают случаи, когда если бы все могли видеть одну настольную систему и работать с ней, тогда мы все смогли объяснять и сообщать наши мысли гораздо более эффективно.
Предположим, ваш отдел продаж находится в пути и возникает необходимость срочно провести собрание, чтобы поделиться информацией, проверить цены и снизить эффект дублирования. Представьте, насколько повысилась бы продуктивность собрания, если бы у всех его участников была возможность одновременного просмотра и редактирования одной таблицы Microsoft® Office Excel® или документа Word, вместо пересылки по электронной почте «текущего документа», который может быстро стать рассогласованным. Теперь стало доступным небольшое средство совместной работы, предоставляющее именно эти возможности — Microsoft SharedView 1.0.
Microsoft SharedView позволяет провести собрание с участием до 15 человек, обеспечивая возможность одновременного совместного использования настольного стола узла собрания, как если бы все видели одну настольную систему. Поначалу можно подумать, что если 15 человек могут одновременно управлять настольной системой, результатом будет только хаос, но в действительности управление настольной системой может передаваться между участниками.
Если возможностью управления обладаете вы, вы видите движения мыши других участников (каждый участник имеет персонализированный указатель), что позволяет им указывать на элементы документа или приложения. К сожалению, в SharedView отсутствуют интегрированные возможности аудио, но можно использовать клиент аудио Windows Live™ Messenger или любимый клиент, использующий протокол VoIP, для конференц-связи во время совместной работы с настольной системой.
Microsoft SharedView обеспечивает одновременное совместное использование настольной системы узла собрания (щелкните изображение, чтобы увеличить его)
Установка SharedView осуществляется очень просто, а сам клиент интуитивно понятен, позволяя быстро приступить к работе даже пользователям, не являющимся специалистами в области техники. После входа в систему с помощью учетной записи Windows Live можно начать сеанс SharedView с помощью всего нескольких щелчков мыши. Присоединение к сеансу осуществляется настолько же просто; необходимо просто ввести имя сеанса (обычно идентификатор Live ID узла), к которому необходимо подключиться, и пароль. Приглашения рассылаются по электронной почте или путем вставки созданного текста приглашения в программу обмена мгновенными сообщениями.
Другие возможности SharedView включают включение и отключение удаленного копирования и вставки (чтобы пользователи сеанса могли добавлять текст с локальных рабочих станций на основной компьютер); разрешение отслеживания изменений в программе Word напрямую, позволяя наблюдать за изменением общего документа; и список явно заблокированных адресов для исключения определенных идентификаторов Windows Live ID из участия. Приложение также включает замечательную функцию Handout, позволяющую сделать дополнительные файлы доступными для участников сеанса; максимальное ограничение для одного сеанса – 25 файлов или 200 МБ.
Кроме того, участникам можно посылать широковещательные сообщения, отображаемые в верхней части подключенного сеанса. При необходимости можно установить общий доступ ко всем компонентам, кроме того, в целях сохранения конфиденциальности в ходе собрания можно быстро и просто запускать и останавливать окна общего доступа на основном компьютере. В целом, если вам необходимо быстрое и простое средство совместной работы, Microsoft SharedView – именно то, что нужно.
Чтобы приступить к работе, необходимо загрузить средство Microsoft SharedView из раздела загрузок кода на веб-узле TechNet Magazine по адресу technetmagazine.com.

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


SharePoint изнутри Интеграция приложений Office
Пав Черны

Содержание
Интеграция приложения Office
Расширение пользовательского интерфейса SharePoint
Использование элемента управления OpenDocuments Office
Обмен данными с SharePoint
Реализация собственного решения OpenControl
Заключение
Службы Microsoft Windows SharePoint Services (WSS) 3.0 и Microsoft Office SharePoint Server (MOSS) 2007 эффективно интегрируются с настольными приложениями в выпуске 2007 системы Microsoft Office, способствуя успешной совместной работе над документами, таблицами, календарями, контактными данными и иным материалами. В сущности, интеграция настолько эффективна, что можно
сказать, что выпуск 2007 системы Office является единой платформой для офисных решений.
Это очень существенно для организаций, полагающихся на технологию Microsoft® Office для повышения производительности информационных работников. Однако для организаций с портфелем разнообразных приложений Office подобного уровня стандартной совместимости недостаточно. Выпуск 2007 системы Microsoft Office предоставляет необходимые возможности интеграции, хотя интерфейсы и компоненты работают не во всех случаях и недостаточно подробно документированы. Это затрудняет для сторонних разработчиков интеграцию технологии SharePoint® со своими приложениями, а их клиентам еще более сложно предоставить единое решение информационным работникам.
В данной статье будет показана интеграция и связь приложений Office со SharePoint, а также продемонстрирована интеграция приложений сторонних разработчиков со SharePoint на основе этих же принципов. Но сначала будут вкратце рассмотрены параметры настройки сервера, клиентские компоненты и протоколы связи, используемые для достижения эффективной интеграции.
После этого можно будет перейти к интеграции приложений, в которых отсутствует встроенная поддержка SharePoint. Для этого я выйду за рамки обычного уровня, который обычно заключается в реализации компонентов IFilter, и рассмотрю расширение возможностей поиска и добавление настраиваемых значков на серверах SharePoint. Расширение возможностей поиска и возврат результатов с верными значками не обеспечивают полной интеграции приложений; пользователям также может быть необходимо открывать эти документы непосредственно из пользовательского интерфейса.
Это и представляет сложность. Необходим клиентский компонент, доступный только при развертывании системы Office на рабочих станциях. Но даже если система Office развернута, в зависимости от настройки и топологии узла SharePoint этот компонент может работать ненадежно.
Для решения этой проблемы я создал собственное решение, позволяющее интегрировать любые приложения, такие как Блокнот, Adobe Reader или Autodesk AutoCAD, без необходимости развертывания Office. Это решение также демонстрирует причину ошибки интеграции приложений на основе стандартных компонентов Office в некоторых случаях. Это решение, а также поэтапные указания по развертыванию и настройке приведены в сопроводительном материале к этой статье, доступном в разделе кода для загрузки .com.

Интеграция приложений Office
С точки зрения пользователя меню SharePoint работают так же, как и меню «Пуск» Windows®. Создание нового документа в библиотеке документов осуществляется очень просто. выберите пункт «Создать», затем «Создать документ», после чего запустится Microsoft Office Word 2007. Правка существующих документов также осуществляется просто. Установите указатель на документ, откройте раскрывающееся меню поля правки элементов управления (Edit Control Box – ECB) и выберите «Изменить в Word». Иногда вспоминается, что Word 2007 запущен с веб-страницы через JavaScript, приложение запущено локально, а документ находится в базе данных SQL Server®, и что веб-сервер находится в пределах пути доступа к данным, как показано на рис. 1.
Рис. 1. Работа с документом Word в SharePoint (щелкните изображение, чтобы увеличить его)
Несмотря на подобные сложности, работа пользователя на рабочей станции Windows с установленным выпуском 2007 системы Microsoft Office не вызывает затруднений. Работа с документами в библиотеке SharePoint очень сходна с работой с локальными файлами и файлами в общей сетевой папке.
Однако на рабочей станции Windows без установленного выпуска 2007 системы Microsoft Office или Office 2003 пользовательский интерфейс другой. При выборе пункта «Новый документ» или «Изменить в Word» просто появляется диалоговое окно с сообщением о недоступности приложения, совместимого со службами Windows SharePoint.
И это не удивительно. Для предоставления единого интерфейса, с которым так удобно работать пользователям Office, необходима совместная работа нескольких элементов. Для отображения нужных команд в меню «Создать» и ECB службам SharePoint необходимы сведения о типах содержимого библиотеки документов. После выбора этих команд должен быть запущен код JavaScript для запуска соответствующего приложения и передачи пути к документу. Эта часть зависит от настройки рабочей станции, поскольку код JavaScript выполняется локально. Более того, для чтения и возможной записи файлов соответствующее приложение должно взаимодействовать со SharePoint. Для интеграции приложений со SharePoint необходима совместная работа этих элементов.
С другой стороны, взаимодействие SharePoint и сервера баз данных прозрачно для приложения, как и процессы индексирования на веб-сервере, выполняемые для упрощения поиска. По этой причине в данной статье я не будут рассматривать эти аспекты более подробно, но рекомендую ознакомиться с пакетом фильтров Microsoft, описанным в статье «Регистрация пакета фильтров Microsoft в службах Windows SharePoint Services 3.0» базы сведений о разрешении проблем Майкрософт, которая доступна по адресу support.microsoft.com/kb/946338. Теперь рассмотрим добавление команд, реализацию клиентских компонентов и упрощение связи приложения.

Расширение пользовательского интерфейса SharePoint
Доступно множество способов расширения пользовательского интерфейса и возможностей SharePoint. Можно изменить структуру узлов, настроить страницы ASP.NET, разработать веб-компоненты или изменить код JavaScript, включенный в WSS и MOSS, для запуска приложений напрямую.
Всегда можно открыть файл Ows.js в текстовом редакторе (файл находится в папке COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Template\Layouts\1033 интерфейсных серверов SharePoint) и изменить работу функций createNewDocumentWithProgIDCore, editDocumentWithProgIDNoUI и DispDocItem. Но существует лучший способ, не требующий изменения базы кода WSS неподдерживаемыми способами: использование сопоставлений типов документов и типов содержимого.
В моей статье «Стандартизация управления данными с помощью пользовательских типов содержимого» (см. выпуск журнала TechNet Magazine за февраль 2008 г., technet.microsoft.com/magazine/cc194408.aspx) я рассматривал создание типов содержимого конкретных узлов и глобальных типов содержимого для управления документами и другим содержимым списков и библиотек документов SharePoint. Кроме того, можно ознакомиться с документом Text Content Type.pdf, входящим в состав сопроводительного материала для этой статьи, в котором описано создание нового типа содержимого для файлов .text и сопоставление данного типа содержимого с библиотекой документов. В результате в меню «Создать» становится доступной команда «Текстовое содержимое», подобная команде «Документ» для документов Word (см. рис. 2).
Рис. 2. Пользовательский тип содержимого в интерфейсе пользователя SharePoint (щелкните изображение, чтобы увеличить его)
Меню ECB также может быть расширено. Вы могли рассчитывать на то, что меню ECB будет учитывать тип содержимого, но в текущей версии WSS это меню реализовано иначе. Вместо этого тип документов необходимо зарегистрировать в файле Docicon.xml, находящемся в папке %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Template\Xml всех интерфейсных серверов SharePoint.
Например, при добавлении к разделу <ByExtension> файла Docicon.xml следующего сопоставления типа документа в SharePoint появится команда «Изменить в блокноте» (подробные указания приведены в файле Text Content Type.pdf):
<Mapping Key="text" Value="ictxt.gif"
  EditText="Notepad"
  OpenControl="SharePoint.OpenDocuments"/>
Параметр Key определяет расширение имени файла, параметр Value – значок документа для отображения в пользовательском интерфейсе, параметр EditText – строку, добавляемую SharePoint к команде «Изменить в», а параметр OpenControl – код ProgID клиентского компонента COM. Это код ProgID, передаваемый функциями JavaScript SharePoint вызову ActiveXObject (см. Ows.js для получения дополнительных сведений) для создания экземпляра объекта COM, который может быть приложением или вспомогательным элементом управления, запускающим приложение на основе соответствующего типа файла.
Веб-узел «Продукты и технологии SharePoint»

  • Веб-узел «Продукты и технологии SharePoint»
  • Технический центр служб Windows SharePoint
  • Центр разработчиков для служб Windows SharePoint
  • Блог группы «Продукты и технологии Microsoft SharePoint»
Необходимо иметь в виду, что параметр OpenControl с именем SharePoint.OpenDocuments ссылается на элемент управления ActiveX®, который выходит в состав последних версий Office (%PROGRAMFILES%\Microsoft Office\Office12\Owssupp.dll). Если этот файл существует на ваших рабочих станциях, и указанный значок документа (параметр Value) находится в папке %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Template\Images серверов SharePoint, возможно, большая часть необходимой работы по интеграции уже выполнена.
В составе пакета SDK для служб Windows SharePoint 3.0 имеются определенные сведения о клиентских интерфейсах API, входящих в состав выпуска 2007 системы Microsoft Office, в том числе об элементе управления OpenDocuments. См. раздел «Справочник по клиентским интерфейсам API» по адресу msdn2.microsoft.com/ms440037.

Использование элемента управления OpenDocuments
Элемент управления OpenDocuments предназначен для решения наиболее важных задач интеграции приложений, но для него необходим выпуск 2007 системы Microsoft Office или Office 2003, и его возможности несколько ограничены. Команды меню «Создать» могут работать не всегда, и иногда отображаемые ими сведения могут вводить пользователей в заблуждение.
Как показано на рис. 3, элемент управления OpenDocuments информирует пользователя о том, что необходимое приложение установлено неправильно или невозможно открыть файл шаблона, хотя оба утверждения неверны. Функция «Изменить в» также имеет проблемы. Часто появляется второе сообщение об ошибке, показанное на рис. 3 на переднем плане. Это мое излюбленное сообщение, поскольку сбивает с толку даже специалистов по SharePoint, но оно будет рассмотрено подробнее чуть позже.
Рис. 3. Дезориентирующие сообщения об ошибке элемента управления OpenDocuments(щелкните изображение, чтобы увеличить его)
Тем не менее, элемент управления OpenDocuments полезен в средах, на всех рабочих станциях которых установлены последние версии Office. Помимо прочего, можно скрыть типы содержимого в меню «Создать» (откройте параметры библиотеки документов, выберите «Изменение порядка новых кнопок и типа содержимого по умолчанию» и снимите флажок «Видимый» для соответствующих типов содержимого), чтобы у пользователей не появлялось первое сообщение об ошибке. Также можно упростить топологию узла, чтобы избежать неполадок связи WebDAV (Web-Based Distributed Authoring and Versioning); это позволит избежать появления второго сообщения об ошибке.

Обмен данными со SharePoint
Пока что мне удалось расширить пользовательский интерфейс SharePoint и, возможно, запустить приложение с помощью элемента управления OpenDocuments, но для приложения по-прежнему необходим способ связи со SharePoint для доступа к данным. Как обычно, SharePoint поддерживает несколько способов достижения этого, например, серверные расширения Microsoft Office FrontPage®, удаленные вызовы процедур (RPC) WSS, WebDAV и веб-службы. В сущности, приложения Office, например, Word 2007, могут использовать любые способы связи или сразу все в зависимости от способа доступа к документу, например, через веб-папки, подключенные сетевые диски или пользовательский интерфейс SharePoint.
Все способы связи клиента и сервера SharePoint основаны на протоколе HTTP. Например, удаленные вызовы процедур (RPC) FrontPage и WSS будут использовать запросы HTTP POST и HTTP GET, направляемые расширениям ISAPI на серверах SharePoint в папке %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\ISAPI и всех ее подпапках.
Одним из наиболее важных расширений ISAPI является библиотека Owssvr.dll, реализующая, помимо прочего, функциональные возможности для работы со списками и библиотеками документов. На рис. 4 показано диалоговое окно SharePoint Save в Word 2007 (слева) и в обозревателе (справа), открытое непосредственно через запрос по URL-адресу http://sharepoint/HR/Administration/_vti_bin/owssvr.dll?dialogview=FileSave&location=Shared%20Documents&FileDialogFilterValue=*.docx. Сходства двух снимков экрана очевидны.
Рис. 4. Диалоговое окно «Сохранить» SharePoint в Word 2007 и Internet Explorer (щелкните изображение, чтобы увеличить его)
Другими важными расширениями ISAPI являются следующие библиотеки: Author.dll, реализующая удаленные вызовы процедур (RPC) FrontPage и WSS для клиентских операций правки, таких как загрузка, переименование и удаление документов; Admin.dll для управления узлами и выполнения ряда административных задач; и Shtml.dll для поддержки отправки форм HTML.
Как правило, поддержку удаленных вызовов процедур (RPC) FrontPage и WSS невозможно добавить к существующим приложениям, таким как «Блокнот» или Adobe Reader, без доступа к исходному коду. Но необходимые возможности связи можно предоставить с помощью функции веб-клиента Windows.
SharePoint также поддерживает WebDAV через библиотеку расширения Httpext.dll, которая находится в папке %WINDIR%\System32\Inetsrv\, но давайте останемся на стороне клиента. На компьютерах под управлением Windows Server® 2008 и Windows Vista® функция веб-клиента установлена по умолчанию. Служба WebClient доступна в средстве «Службы», находящемся в разделе «Администрирование» на панели управления. В операционных системах Windows XP и Windows Server 2003 необходимо установить веб-клиент. В любом случае убедитесь, что служба WebClient запущена и для нее установлен тип запуска «Авто».
На рис. 5 показана архитектура веб-клиента. Служба WebClient реализована в виде библиотеки DLL режима пользователя (Webclnt.dll), загружаемой диспетчером служб в размещающий процесс Svchost.exe. Webclnt.dll предоставляет интерфейс доступа к сети для операций, отличных от ввода-вывода (таких как проверка подлинности пользователя для доступа WebDAV; подключение узлов SharePoint в качестве сетевых дисков; перечисление узлов, списков и библиотек документов SharePoint как сетевых ресурсов; и отключение смонтированных дисков).
Figure 5 Архитектура перенаправителей клиентов WebDAV (щелкните изображение, чтобы увеличить его)
Для выполнения этой задачи Webclnt.dll связывается с драйвером файловой системы в режиме ядра, который в действительности предоставляет функции перенаправителя. Драйвер перенаправителя клиентов WebDAV (Mrxdav.sys) основан на подсистеме RDBSS (Redirected Drive Buffering Subsystem), которая интегрируется с диспетчером ввода-вывода и другими компонентами ядра для предоставления служб удаленной файловой системы. Mrxdav.sys реализует возможности связи WebDAV для поддержки доступа к узлам и библиотекам документов SharePoint на уровне файловой системы.
Возможность доступа к узлам и библиотекам документов SharePoint через сетевой перенаправитель устраняет необходимость поддержки удаленного вызова процедур (RPC) FrontPage и WSS RPC в пользовательском приложении. Сетевые диски можно сопоставить с библиотеками документов (например, net use x: http://wss/doclib/Shared%20Documents), а доступ к ресурсам SharePoint также может осуществляться через пути в формате UNC.
URL-адрес http://wss/doclib/Shared%20Documents соответствует \\wss\doclib\Shared%20Documents. Поэтому доступны несколько способов открытия документа в приложении. Например, можно открыть документ в программе «Блокнот», используя путь HTTP http://wss/doclib/Shared%20Documents/New%20Text%20Document.txt или путь UNC \\wss\doclib\Shared%20Documents\New%20Text%20Document.txt.
К сожалению, функция веб-клиента имеет ряд ограничений. Доступ к пользовательским свойствам и веб-приложениям, использующим пользовательские порты TCP, невозможен. Сбой веб-клиента, входящего в состав Windows Vista, также происходит в случае, если у пользователя отсутствует доступ к родительскому узлу в иерархии, как показано в файле WebDAV Access.pdf (см. сопровождающие материалы).
В путь http://sharepoint/HR/Administration/Shared%20Documents/ входит несуществующий корневой узел (это http://sharepoint), однако без доступа к корню веб-клиент не может определить возможности веб-сервера. Веб-сервер отвергает запрос OPTIONS веб-клиента с кодом состояния 401, что означает, что доступ несанкционирован, и поэтому веб-клиент продолжает запрашивать учетные данные пользователя, как показано на рис. 6, даже если пользователь имеет административный доступ к семейству веб-узлов sharepoint/HR и всем входящим в него узлам.
Рис. 6. Ошибка доступа WebDAV (щелкните изображение, чтобы увеличить его)
Если при использовании элемента управления OpenDocuments веб-клиент не может открыть документ, появляется сообщение об ошибке, показанное на рис. 3. Приложение доступно, а сопоставление типа документа правильное. Это документ, доступ к которому через перенаправитель WebDAV невозможен.

Реализация собственного решения OpenControl
Вообще, недостатки веб-клиента можно исправить двумя способами. Можно дождаться выпуска обновленной версии веб-клиента корпорацией Майкрософт или реализовать пользовательское решение OpenControl, успешное разрешающее текущую ситуацию. Реализация пользовательского решения OpenControl – нетривиальная задача, но оно устраняет необходимость установки Office на рабочих станциях, позволяет успешно совместно использовать команды «Создать» и «Изменить» и разрешать ситуации сбоя веб-клиента.
Если что-либо из перечисленного вам необходимо, взгляните на исходный код AppStart, входящий в материал, сопровождающий данную статью. В этом коде продемонстрировано предоставление интерфейсов COM OpenControl в сборке Microsoft .NET Framework, которые могут быть вызваны из кода JavaScript SharePoint. В исходном коде AppStart также показан один из возможных способов проверки доступности файла и его загрузки на локальный компьютер через HTTP, если прямой доступ через WebDAV невозможен. Наконец, исходный код AppStart реагирует на команду «Создать», загружая на локальный компьютер шаблон, соответствующий типу содержимого, чтобы пользователь мог начать работу с документом. В таблицах Text Content Type.pdf и Adobe Reader Support.pdf описано развертывание этого решения OpenControl.
На схеме, показанной на рис. 7, показана архитектура AppStart. Мой собственный компонент OpenControl (с именем Biblioso.dll) предоставляет два одинаковых интерфейса COM, вызываемые кодом JavaScript SharePoint для создания новых документов или открытия существующих документов для внесения изменений (Biblioso.AppStart.2 и Biblioso.AppStart.3).
Рис. 7. Архитектура AppStart (щелкните изображение, чтобы увеличить его)
Если документ открыт для изменения, Biblioso.dll проверяет существования файла и открывает соответствующее приложение вместе с путем к документу, если файл доступен напрямую через WebDAV. Если файл недоступен, Biblioso.dll запускает внепроцессный сервер COM, который в свою очередь загружает OpenDocsUtility.dll для загрузки файла через HTTP и открытия приложения вместе с путем к загруженному документу.
Внепроцессный сервер COM позволяет решению выйти из процесса Internet Explorer®, ограничивающего загрузку папкой временных файлов Интернета в защищенном режиме. Пользователи должны иметь возможность загрузки файлов без ограничений защищенного режима, которую предоставляет внепроцессный сервер COM, работающий в качестве приложения-посредника.
Разработка внепроцессных серверов COM в .NET не поддерживается, поэтому для выполнения этой задачи я переключился на C/C++. На языке C++ я создал только минимально необходимое диалоговое окно «Сохранить как». Для обеспечения максимальной простоты решения и минимальных усилий по разработке я поместил действительный код загрузки в сборку .NET (OpenDocsUtility.dll), который затем вызывается через другой интерфейс COM.
Для упрощения развертывания я добавил к решению проект Setup. Помимо прочего, процедура установки регистрирует все компоненты COM и записывает относящиеся к приложению параметры в HKEY_LOCAL_MACHINE\SOFTWARE\Biblioso\AppStart. Наиболее важные параметры – AllowedApps и AllowedFileTypes. Решение AppStart работает только с приложениями и типами файлов, явно указанными в этих параметрах.
Процедура установки также создает политику повышения прав для внепроцессного сервера COM, чтобы интерфейс Biblioso.dll в процессе Internet Explorer мог запустить AppBrokerEngine.exe без появления предупреждений безопасности. Тем, кто хочет поближе познакомиться с защищенным режимом Internet Explorer и работе с ним при разработке приложений, я рекомендую статью Марка Силби и Питера Брандретта «Знакомство с принципами защищенного режима обозревателя Internet Explorer и работа в нем», доступную по адресу msdn2.microsoft.com/bb250462.
При анализе компонентов AppStart следует помнить, что это решение разработано с целью демонстрации возможностей и еще не готово к использованию в рабочих средах. Не было достаточно времени для тщательной оптимизации кода и тестирования решения или для документирования функций помимо вставки комментариев в исходный код.
Это решение следует использовать на свой страх и риск. Если вы хотите изучить исходный код для создания собственного решения, начните с файла AppStart.cs проекта кода Biblioso. В этом файле реализуется интерфейс COM OpenControl и точки входа для вызовов JavaScript из Ows.js.
Заключение
WSS 3.0 и MOSS 2007 предоставляют богатые возможности интеграции приложений для улучшения работы пользователей с документами и другими элементами списков и библиотек документов SharePoint. Настольные приложения выпуска 2007 системы Microsoft Office весьма наглядно демонстрируют это, кроме того, можно добиться такого же уровня интеграции и удобства работы и для других приложений.
В основе архитектуры интеграции приложений лежат компоненты COM, используемые функциями JavaScript SharePoint вместе с путем к документу для запуска приложения. В выпуске 2007 системы Microsoft Office предоставлено нескольких уровней таких компонентов COM, оптимизированных для конкретных потребностей приложений Office; кроме того, элемент управления OpenDocuments Office можно повторно использовать для интеграции приложений сторонних производителей. Элемент управления OpenDocuments удовлетворяет большинство основных потребностей. В случае с более сложными требованиями к интеграции приложений возможна реализация пользовательского элемента управления.
Полная интеграции приложения со SharePoint влечет за собой не только установку компонентов IFilter и значков документов для расширения возможностей поиска и отображения, но также и создание собственных типов содержимого и сопоставлений типов документов на серверах SharePoint для включения соответствующих команд «Создать» и «Изменить» в пользовательский интерфейс SharePoint. Эти команды вызывают функции JavaScript, которые в свою очередь вызывают методы, предоставляемые компонентом OpenControl. Компонент OpenControl также должен быть доступен на рабочей станции.
Другая важная часть головоломки – веб-клиент, по умолчанию включенный и установленный в операционной системе Windows Vista. Веб-клиент реализует драйвер удаленной файловой системы и перенаправитель WebDAV для обеспечения доступа любых приложений к ресурсам списков и библиотек документов SharePoint, так же как и общим файловым ресурсам в сети. Хотя веб-клиент, входящий в состав Windows Vista, имеет недостатки, это важная часть истории интеграции приложения.
Поддержка WebDAV также ликвидирует разрыв между SharePoint и приложениями, работающими на рабочих станциях под управлением операционных систем, отличных от Windows. Как правило, в этих операционных системах недоступны технология COM и элементы управления ActiveX, что делает невозможным использование компонентов OpenControl для автоматического запуска приложений, но в состав большинства операционных систем входят перенаправители WebDAV, предоставляющие пользователям доступ к документам непосредственно в библиотеках документов без необходимости загрузки файлов на локальные рабочие станции.
WSS 3.0 и MOSS 2007 лежат в основе истории успеха выпуска 2007 системы Microsot Office, а пользователи приложений на основе Office производства сторонних разработчиков могут аналогичным образом использовать преимущества SharePoint. Возможности интеграции выходят далеко за пределы Office. Используя все преимущества SharePoint, можно создать единую платформу решений Office, предоставляющую подобное удобство работы с Office и программным обеспечением других производителей, и в результате повысить производительности информационных работников.

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

© 2005 Корпорация Майкрософт и CMP Media LLC. Все права защищены; запрещено частичное или полное воспроизведение без специального разрешения


Windows PowerShell коробка для промежуточных результатов
Дон Джонс (Don Jones)

Содержание
Будьте командлетом
Функция фильтрации
Думайте материально
Практическое применение
Оставьте время для игр
На одном из недавних занятий по Windows PowerShell, которые я веду, некоторым учащимся было очень трудно мысленно представить себе конвейер PowerShell. Должен признать, что точное наглядное представление конвейера невозможно, поэтому учащимся, лучше воспринимающим информацию зрительно, может быть очень трудно точно понять происходящее. Когда я добрался до
концепции функций фильтрации, работающих непосредственно в конвейере, все еще больше усложнилось, а на лицах некоторых учащихся было написано полное непонимание.
Чтобы помочь им разобраться, на следующее занятие я взял коробку, несколько наклеек с именами и шары для настольного тенниса. (Никто не утверждал, что среда Windows PowerShell® не может быть занятной.) Для демонстрации я решил использовать следующую командную строку:
Get-Process | Where { $_.VM –gt 1000 } | Sort VM
–descending | Export-CSV C:\Procs.csv

Будьте командлетом
С помощью наклеек с именами, наклеек «Привет, меня зовут …», которые вы всегда носили на встречах выпускников школы и других кошмарных мероприятиях, я присвоил всем учащимся имена командлетов. Я объяснил, что шары для настольного тенниса представляют объекты процесса Windows® (точнее, объекты процесса System.Diagnostics.Process), и спросил учащихся, по имени какого командлета можно сказать, что он, вероятнее всего, создает объекты процесса.
Изучив наклейки друг друга, учащиеся пришли к очевидному решению – Get-Process. Так была показана одна из главных причин, по которой мне нравятся имена командлетов в Windows PowerShell: обычно они очень понятны.
Итак, учащийся, изображающий командлет Get-Process, взял все шары и кинул их в картонную коробку. Коробка представляла конвейер PowerShell, а действия учащегося были очень сходны с операциями командлета. Командлет создает один или несколько объектов, после чего сбрасывает их в конвейер.
Затем очередь переходит к следующему командлету в конвейере. В этом примере учащийся, представляющий командлет Where-Object, поднял шары и поочередно изучил каждый из них, проверяя, превышает ли значение свойства VM 1 000. В PowerShell «VM» означает виртуальную память, и для данного занятия я на всех шарах маркером написал определенный объем виртуальной памяти.
Все шары (или процессы) со значением свойства VM 1000 или больше помещались обратно в коробку (иногда называемую конвейером), а шары с меньшим значением были выкинуты в мусорную корзину и больше никогда не использовались. (В действительности все было не так, я достал их, чтобы использовать на будущих занятиях.)
После этого учащийся, изображающий командлет Sort-Object, расставил все шары в коробке по порядку на основе свойства VM. Должен признать, что эту часть упражнения я продумал не так хорошо — расставить шары, чтобы они не раскатывались по всему помещению, было очень непросто! По-видимому, для следующего занятия мне придется найти кубики для настольного тенниса или иметь под рукой несколько картонных коробок для яиц.
Наконец, учащийся, представляющий Export-CSV, поднял шары и записал данные в файл CSV. В материальном мире это означает запись свойств процесса на перекидном плакате, который мы считали файлом CSV.

Функция фильтрации
Закончив с простым конвейером, мы решили рассмотреть более сложные функции фильтрации. Я предложил функцию фильтрации и командную строку, показанные на рис. 1.
Рис. 1. Пример функции фильтрации и командной строки
Function Do-Something {
 BEGIN { }
 PROCESS {
  $obj = New-Object PSObject
  $obj | Add-Member NoteProperty "TimeStamp" (Get-Date)
  $obj | Add-Member NoteProperty "ProcessName" ($_.Name)
  Write-Output $obj
 }
 END {}
}
Get-Process | Do-Something | Format-Table *
Прежде всего я хочу вкратце рассмотреть назначение функций фильтрации. Идея состоит в том, что функция содержит три блока сценариев, которые называются BEGIN, PROCESS и END.
При использовании функции в конвейере первым выполняется блок сценариев BEGIN. Этот сценарий может выполнять какие-либо задачи установки, например открытие подключения к базе данных.
Затем блок PROCESS выполняется единожды для каждого из переданного функции объекта. В блоке сценария PROCESS есть специальная переменная $_, автоматически заполняемая текущим объектом конвейера. Поэтому если передано 10 объектов, блок сценариев PROCESS выполняется 10 раз.
Наконец, после выполнения всех переданных объектов выполняется блок сценариев END, который выполняет все необходимые задачи очистки, такие как закрытие подключения к базе данных.
Если какой-либо объект в этих блоках сценариев написан с помощью Write-Output, он сохраняется в конвейере для следующего командлета. Все остальные объекты удаляются.
Поскольку мы начали с командлета Get-Process, последний учащийся собрал все шары (мы сделали небольшой перерыв, и шары каким-то образом оказались разбросаны по всему помещению) в коробку-конвейер. После этого пришла очередь учащегося, представляющего функцию фильтрации «Do-Something».
Сначала он выполнил блок сценариев BEGIN. Выполнение пустого блока не заняло много времени. Затем он собрал все объекты конвейера (шары для настольного тенниса) и начал их поочередно рассматривать. Это было довольно весело, поскольку шаров было около десяти, и он пытался удержать их все на коленях, наверное, вам стоило на это посмотреть.
Так или иначе, он брал по одному объекту процесса и выполнял его блок сценариев PROCESS. Этот блок сценариев стал причиной создания им нового пользовательского объекта. (Для этого я использовал специальные желтые шары для пинг-понга, которые, думаю, не трудно найти в местном магазине спортивных товаров.) На новых шарах учащийся написал текущую дату и время, а также имя объекта процесса, который он в тот момент рассматривал.
Затем этот новый пользовательский объект был записан в конвейер, то есть он положил шар в коробку, а исходный шар объекта процесса был выброшен. Он проделал это для всех шаров объектов процесса в коробке, всего около 12. По завершении процесса все белые шары были заменены желтыми шарами пользовательских объектов. Наконец, он выполнил блок сценариев END, который был пустой и не занял много времени.
Последним была очередь учащегося Format-Table. Он взял все содержимое коробки (на тот момент в ней были желтые «пользовательские» объекты) и приступил к созданию таблицы, используя оба свойства, написанные на каждом шаре. Результатом стала написанная на перекидном плакате таблица с двумя столбцами, TimeStamp и ProcessName, и примерно десятью строками.

Думайте материально
Это упражнение позволило всем учащимся понять конвейер и функции фильтрации. Шары для настольного тенниса великолепно заменили объекты, позволив абстрагироваться, когда речь шла только о PowerShell/
Все смогли пронаблюдать работу командлетов с объектами, размещение результатов в конвейере и их использование следующим командлетом для дальнейшей работы. Последовательность события в функции фильтрации была более очевидной, как и метод поочередной работы блока сценариев PROCESS с входными объектами.
Таким образом были показаны способы создания нового пользовательского объекта и его помещения в конвейер. Более того, это позволило показать преимущества создания пользовательских объектов по сравнению с простым текстом — новые пользовательские объекты могли быть использованы другими командлетами, такими как Format-Table, обеспечивая достаточную гибкость использования и представления данных.

Практическое применение
Учащиеся задали очевидный вопрос о том, как только что продемонстрированный конвейер и функции фильтрации могут использоваться на практике. Ответ очень простой: я создал несколько примеров для недавней конференции (примеры можно загрузить с веб-узла scriptinganswers.com/essentials/index.php/2008/03/25/techmentor-2008-san-francisco-auditing-examples).
Один пример предназначен для перечисления нескольких свойств класса Win32_UserAccount в инструментарии WMI с нескольких компьютеров. Если имена компьютеров перечислены в файле C:\Computers.txt, выполнить задачу позволит следующая простая команда:
Gwmi win32_useraccount –comp (gc c:\computers.txt)
Проблема состоит в том, что в классе Win32_UserAccount отсутствует свойство, определяющее, с какого компьютера пришел данный экземпляр, поэтому полученный список будет бесполезной кучей учетных записей множества компьютеров. Я разрешил проблему путем создания нового пользовательского объекта, включающего имя исходного компьютера, и выбора нужных свойств класса. Код этого пользовательского объекта показан на рис. 2.
Рис. 2. Использование пользовательского объекта для сбора имен компьютеров и выбора свойств
function Get-UserInventory {
  PROCESS {
    # $_ is a computer name
    $users = gwmi win32_useraccount -ComputerName $_
    foreach ($user in $users) {
      $obj = New-Object
      $obj | Add-Member NoteProperty Computer $_
      $obj | Add-Member NotePropertyPasswordExpires ($user.PasswordExpires)
      $obj | Add-Member NoteProperty Disabled ($user.Disabled)
      $obj | Add-Member NotePropertyFullName ($user.FullName)
      $obj | Add-Member NoteProperty Lockout ($user.Lockout)
      $obj | Add-Member NoteProperty Name ($user.Name)
      $obj | Add-Member NotePropertyPasswordRequired ($user.PasswordRequired)
      $obj | Add-Member NotePropertyPasswordChangeable ($user.PasswordChangeable)
    }
  }
}

Get-Content c:\computers.txt |
  Get-UserInventory |
  where { $_.PasswordRequired -eq $False } |
  selectComputer,Name |
  Export-Csv c:\BasUsersBad.csv
Последняя строка команды передает все имена компьютеров функции фильтрации, которая создает пользовательские объекты. Далее я отфильтровал всех пользователей, кроме тех, чье свойство PasswordRequired имеет значение False (идея заключаются в создании отчета аудита проблемных учетных записей). После этого я просто сохранил свойства Computer и Name, чтобы итоговый отчет был списком имен компьютеров и учетных записей, требующих особого внимания из-за паролей с неограниченным сроком действия. Функция фильтрации делает этот отчет для нескольких компьютеров возможным, поскольку добавляет имя исходного компьютера к результату, ограничивая свойства только необходимыми.
Хотя существуют и другие сходные пути выполнения этой задачи, данный подход, вероятно, является самым простым. Кроме того, он демонстрирует основные концепции и методы.

Оставьте время для игр
Даже если вы успешно работаете с конвейером, еще есть то, что необходимо изучить. Мышление в терминах физических объектов поможет лучше понять выполняемые действия.
Поэтому в следующий раз, когда вы столкнетесь с трудностями в концепции Windows PowerShell, попробуйте абстрагироваться от компьютера и воспроизвести задачу, используя в качестве иллюстрации повседневные предметы. Я скромно рекомендую держать для этого под рукой небольшой пакет с шарами для настольного тенниса (или кубиками, если вы сможете их найти).
Командлет месяца: Out-File
Сколько раз вы перенаправляли выходные данные командлета в файл с помощью символа >? Примерно вот так: Get-Process > Processes.txt. Знали ли вы, что в действительно вы используете скрытый командлет Out-File? Вот команда, выполняющая точно такую же функцию: Get-Process | Out-File Processes.txt.
Конечно, для этого требуется больше ввода с клавиатуры, зачем же утруждать себя вводом полного командлета Out-File? Одна из причин состоит в том, что командлет Out-File более ясен при чтении. Кто либо, обучающийся, скажем, шесть месяцев, может посмотреть на один из ваших сценариев и спросить, что означает символ > (это, в конце концов, устаревшее мышление).
Командлет Out-File, напротив, делает довольно очевидным то, что будет файл будет создан и записан. Более того, Out-File предоставляет параметр -append (почти то же самое, что >>), а также параметры -force и -noClobber, позволяющие контролировать перезапись существующих файлов. Наконец, ввод Out-File обеспечивает доступ к параметру -whatif. Этот удобный параметр позволяет просмотреть результаты работы командлета Out-File без действительного выполнения самой работы! Это отличный способ безопасной проверки сложной командной строки.
Видео
Посмотрите, как Дон Джонс работает с этими командлетами.

Дон Джонс – соавтор книги Windows PowerShell: TFM и преподаватель на курсах по Windows PowerShell (www.ScriptingTraining.com).


Эй, сценарист! Адреналиновая лихородка
Сценаристы корпорации Майкрософт

Несомненно, мы глубоко убеждены, что написание статей для TechNet Magazine является самой престижной (и благодарной) работой, которую только можно вообразить. (Конечно, она была еще привлекательнее, если бы нам за нее действительно платили, но это уже другая история.) Так насколько же эта работа престижна? Скажем так, прямо сейчас по всему миру дети, которых укладывают в кровать, говорят, глядя в глаза своим мамам: «Мамочка, когда я вырасту, я буду каждый месяц писать заметки о сценариях для журнала TechNet Magazine.»
Примечание. Безусловно, по всему свету встречаются люди, которые полагают, что уже эта статья написана детьми. Но это тоже другая история.
Хорошо известно, что сценаристы обожают то лестное чувство, которое испытывают пишущие для TechNet Magazine; мы даже научились обращаться с охотниками за автографами и папарацци. Но правда состоит в том, что мы выполняем эту работу не потому, что это для нас честь, и не для славы; мы занимаемся этим из чистой потребности в адреналиновой лихорадке, которую испытываем при написании сценариев для администрирования систем.
Конечно, не так часто встретишь упоминание о чисто адреналиновой лихорадке и написании сценариев для администрирования систем в одном предложении. (Конечно, если только чисто адреналиновой лихорадке не предшествует полная и абсолютная анадреналинемия.)
Человек с заурядной подготовкой считает написание сценариев для администрирования систем очень полезным, но, возможно, не очень увлекательным делом. В действительности он или она находят написание сценариев несколько однообразным. Есть еще одна причина: никто из этих людей не пытался писать сценарии для данных настройки загрузки в Windows Vista® или Windows Server® 2008.
Что, ваш пульс немного увеличился, не так ли? Как большинство читателей, вероятно, знает, в Windows Vista и Windows Server 2008 старый файл boot.ini был заменен на новое хранилище данных настройки загрузки, обеспечивающее повышенную гибкость (и возможности), когда доходит до управления процессом загрузки.
Это совершенно замечательно. Но что именно замечательно, так это то, что благодаря новому поставщику WMI (Windows® Management Instrumentation) хранилище данных настройки загрузки (BCD) стало легкодоступным и полностью управляемым с помощью сценариев.
Не стоит волноваться по поводу странного ощущения, которое только что волной прокатилось по вашему позвоночнику; именно так ощущается чисто адреналиновая лихорадка. Приступив к работе со сценариями BCD, вы начнете к этому привыкать.
Прежде чем идти дальше, следует отметить, что, возможно, нам не удастся даже приступить к обсуждению всего того, что можно сделать с помощью поставщика BCD, по крайней с этим не удастся справиться в одной этой статье. (Мы отправили сообщение электронной почты редакторам журнала с вопросом о возможности сделать специальный двойной выпуск, целиком посвященный написанию сценариев для данных настройки загрузки, но пока от них ничего не слышно.)
Если вам нужны более полные сведения, ознакомьтесь с документацией по поставщику WMI BCD на веб-странице по адресу go.microsoft.com/fwlink/?LinkId=116953. Тем временем мы покажем некоторый пример кода, предназначенный для мультизагрузочных компьютеров — компьютеров, на которых установлено несколько операционных систем.
Но — эти сценарии работают только в среде Windows Vista и Windows Server 2008. Это обусловлено тем, как мы упоминали ранее, что в настоящее время только эти две операционные системы поддерживают BCD.
Начнем с рассмотрения сценария, сообщающего нам, какая операционная система используется на компьютере в текущий момент. Разумеется, это не самый впечталяющий вариант использования поставщика BCD; в конце концов, уже существует возможность использовать класс WMI, Win32_OperatingSystem, для определения ОС, работающей на компьютере в текущий момент. Однако это достаточно простой сценарий (по крайней мере, в случае сценариев BCD), и он обеспечивает хороший способ продемонстрировать основные приемы, необходимые при работе с BCD. (Приемы, которые, мягко говоря, чуть-чуть … необычные.)
Кроме этого, мы не можем внедрять в наши статьи слишком много возбуждающих эпизодов: в журнале TechNet Magazine нам уже сказали, что мы будем нести ответственность за весь ущебр, нанесенный перевозбужденными и слишком страстными поклонниками рубрики «Эй, сценарист!» Имея в виду все те увечья, которые возникли по всему миру после нашей статьи о регулярных выражениях, мы никогда больше не можем себе позволить ничего, вызывающего возбуждение.
Примечание Помните все эти видеозаписи «Битлз», окруженных толпой поклонников, и все эти фотографии девушек, падающих в обморок и рыдающих при виде Джона, Пола, Джорджа и Ринго? Все это очень похоже на то, что с нами происходит каждый раз после публикации новой статьи.
Ладно, согласны, возможно, это некоторое преувеличение. Но нет никаких сомнений в том, что множество людей (мужчины так же, как женщины) рыдает после чтения одной из наших статей.
Во любом случае взгляните на сценарий на рис. 1, в котором поставщик BCD используется для определения ОС, работающей на компьютере в текущий момент. Прежде чем пытаться запустить этот сценарий, нужно знать, что вы должны выступать в качестве администратора, в противном случае сценарий закончится сбоем.
Рис. 1 Определение текущей операционной системы
Const BcdLibraryString_Description = &h12000004
Const Current = "{fa926493-6f1c-4193-a414-58f0b2456d1e}"

strComputer = "."

Set objStoreClass = GetObject("winmgmts:{(Backup,Restore)}\\" & _
 strComputer & "\root\wmi:BcdStore")

objStoreClass.OpenStore "", objStore
objStore.OpenObject Current, objDefault

objDefault.GetElement BcdLibraryString_Description, objElement
Wscript.Echo "Current operating system: " & objElement.String
И это не означает, что вы просто должны войти в систему с учетной записью, обладающей полномочиями администратора. Это означает, что вы должны открыть окно командной строки, выбрав в меню «Пуск» пункт «Командная строка», и выбрать «Запуск от имени администратора». Затем можно запускать этот сценарий из командной строки.
Итак, как работает данный сценарий? Знаете, мы боялись, что вы зададите этот вопрос. Но все в порядке; мы попытаемся все объяснить как можно лучше (что, если не еще что-нибудь, должно обеспечить минимальный уровень возбуждения, по крайней мере на некоторое время).
Мы начинаем с определения двух констант: BcdLibraryString_Description и Current. BcdLibraryString_Description относится к объекту, который требуется извлечь; в данном случае этот объект содержит Description (имя) текущей операционной системы.
Это, между прочим, одна из подкупающих особенностей работы с поставщиком BCD. Обычно вы не просто извлекаете значение свойства; вместо этого вы используете одно из этих значений констант (и метод GetElement) для извлечения другого объекта, затем получаете значение свойства, принадлежащего этому объекту. Безусловно, это немного глупо, но вы же знаете, что говорят: путь к цели — это половина удовольствия.
Примечание. Этот тот вид дела, когда вам интересно, куда бы все это могло завести, не так ли?
Что касается константы Current, что же, это просто идентификатор GUID, представляющий операционную систему, используемую в текущий момент. Значение
{fa926493-6f1c-4193-a414-58f0b-2456d1e}
считается «хорошо известным» идентификатором GUID (который, по крайней мере, доказывает, что у сотрудников Майкрософт действительно есть чувство юмора).
Несмотря на тот факт, что это хорошо известный идентификатор GUID, мы пошли дальше и все равно включили значение, просто на тот случай, если кому-нибудь из читателей трудно помнить, которое из двух значений является верным:
{fa926493-6f1c-4193-a414-58f0b2456d1e}
{fa926493-6f1c-4193-a414-58f0b2456d1f}
Примечание. Если вы удивлены, слово «GUID» можно произносить либо как «гвид», либо как «гуид ». Мы могли бы рассказать еще кое о чем, например: тот факт, что предшествующий идентификатор GUID должен быть идентификатором GUID версии 1, рассматривается как то, что третья группа цифр начинается с 4. Но мы пообещали попытаться свести возбуждение к минимуму. А мы держим свои обещания.
Как вы, возможно, догадались, потребуется многократно использовать констаныт, шестнадцатеричные значения и значения идентификаторов GUID всюду, где вы окажетесь, работая с поставщиком BCD. В статье этого месяца мы не сможем обсудить все эти элементы, но для получения подробных сведений можно ознакомиться со страницей BCD, упомянутой ранее, на веб-узле MSDN® (go.microsoft.com/fwlink/?LinkId=116953). То есть если вам не терпится.
После определения наших двух констант мы подключаемся к службе WMI на локальном компьютере. Можете ли вы использовать этот сценарий для извлечения данных настройки загрузки для удаленной машины? Конечно, можете.
Честно говоря, если вам это не под силу, то этот BCD мало чего стоит. Для извлечения из удаленной машины данных настройки загрузки (повторяем, удаленный компьютер должен работать под управлением либо Windows Vista, либо Windows Server 2008) вы просто присваиваете имя этой машины переменной strComputer:
strComputer = "atl-fs-001"
Также мы должны обратить ваше внимание на пару важных элементов в строке подключения WMI. Начнем с того, что, возможно, вы обратили внимание, что мы включили в нашу строку подключения оба полномочия — Backup и Restore; это именно то, что делает конструкция {(Backup,Restore)}. Важно ли это? Ну, если вы хотите, чтобы ваш сценарий работал, то это очень важно: поэтому, если эти два полномочия не включить явным образом, сценарий закончится аварийно.
Во-вторых, обратите внимание, что мы не подключаемся к пространству имен root\cimv2, которое наиболее часто используется в сценариях администрирования систем. Вместо этого мы подключаемся к пространству имен root\WMI и выполняем привязку непосредственно к классу BCDStore. Именно для этого предназначен следующий фрагмент кода.
"\root\wmi:BcdStore"
Нет, это пока еще не то, что интересно. Интересная часть еще впереди.
Хотя кое-где может быть пара исключений, в своем большинстве любой создаваемый сценарий BCD будет начинаться с одних и тех же трех действий: определения констант, подключения к службе WMI и открытия хранилища BCD. Мы уже выполнили этапы 1 и 2; следующая строка кода позаботится об этапе 3.
objStoreClass.OpenStore "", objStore
Как уже было сказано, здесь мы открываем хранилище BCD — объект операционной системы, в котором хранится вся информация о настройке загрузки. Для открытия хранилища мы просто вызываем метод OpenStore и передаем этому методу два параметра.
  • Пустая строка (""). Этим сценарию сообщается, что требуется открыть хранилище по умолчанию.
  • objStore. Это «выходной» параметр, предоставляемый нами сценарию. Мы передаем методу имя переменной, и, в качестве благодарности, метод возвращает объект (в данном случае объект, представляющий хранилище BCD), использующий имя переменной в качестве ссылки на объект.
Как только хранилище открыто, можно использовать метод OpenObject для извлечения еще одного объекта (хранящегося в выходном параметре objDefault).
objStore.OpenObject Current, objDefault
И что же собой представляет этот новый объект? Правильно: это версия операционной системы, используемой в текущий момент. Мы это знаем, поскольку передали методу OpenObject константу Current, хорошо известный идентификатор GUID, представляющий текущую операционную систему.
Хорошо, следовательно, мы теперь знаем, какая операционная система используется в текущий момент на компьютере, верно? Да, почти. Для получения этой информации нам все еще необходимо использовать метод GetElement для извлечения строки Description для этой операционной системы.
objDefault.GetElement _
  BcdLibraryString_Description, objElement
Теперь пообещайте, что вы не слишком перевозбудитесь и не станете наносить никаких увечий. Хорошо. В этом случае мы расскажем вам, что теперь можно получить значение свойства String и (наконец!) определить операционную систему, используемую в текущий момент на компьютере.
Wscript.Echo "Current operating system: " _
  & objElement.String
Пожалуйста, держите себя в руках. Помните о своем обещании: никаких увечий. Да, мы знаем, что это сложно. Просто сделайте максимум возможного. Постарайтесь поглубже вдохнуть; нам это всегда помогает, когда мы пишем сценарии BCD.
Как уже было сказано, чтобы определить, какая операционная система работает на компьютере в текущий момент, необходимо преодолеть много препятствий; существуют более простые способы выполнения этой задачи. Радует, однако, то, что теперь вы понимаете, как работает сценарий BCD, и это означает, что вы в состоянии сделать то, чего никогда не могли выполнить создатели сценариев. (Спокойно, спокойно.) Например, на мультизагрузочном компьютере одна операционная система всегда назначается системой «по умолчанию»; если компьютер перезагружается, и рядом нет никого, кто может указать другую, компьютер автоматически загружает операционную систему по умолчанию. До появления Windows Vista (и поставщика BCD) у создателя сценария не было никакого способа для определения операционной системы компьютера, загружаемой по умолчанию. Теперь, однако, это так же просто, как запустить сценарий, подобный сценарию из рис. 2.
Рис. 2 Определение операционной системы по умолчанию
Const BcdLibraryString_Description = &h12000004
Const BootMgrId = "{9dea862c-5cdd-4e70-acc1-f32b344d4795}"
Const DefaultType = &h23000003

strComputer = "."

Set objStoreClass = GetObject("winmgmts:{(Backup,Restore)}\\" & _
    strComputer & "\root\wmi:BcdStore")
objStoreClass.OpenStore "", objStore

objStore.OpenObject BootMgrId, objBootMgr

objBootMgr.GetElement DefaultType, objDefaultOSIdentifier
objStore.OpenObject objDefaultOSIdentifier.Id, objDefault

objDefault.GetElement BcdLibraryString_Description, objElement
WScript.Echo "Default operating system: " & objElement.String
Ваша правда, хочется немного побушевать, так ведь? Но совсем немного, хорошо? Мы не будем чересчур подробно обсуждать этот сценарий; в предположении, что вы не пропустили предыдущие 10 или 12 абзацев, вы в состоянии понять логику самостоятельно. Можно заметить, однако, что для получения операционной системы по умолчанию требуется выполнить промежуточное действие: необходимо использовать метод OpenObject для открытия экземпляра объекта диспетчера загрузки. После открытия диспетчера загрузки можно воспользоваться константой DefaultType для извлечения объекта, представляющего операционную систему по умолчанию.
Теперь, признаемся, это крайне вдохновляет: мы можем определить текущую операционную систему и операционную систему по умолчанию. Но знаете, что было бы действительно потрясающе? Возможность получить список всех операционных систем, установленных на компьютере. Вот это было бы действительно восхитительно! Пристегните ремни безопасности и взгляните на рис. 3.
Что мы здесь делаем? Ну, для начала определяем две новых константы: WindowsImages, которая позволяет извлечь экземпляры всех ОС, поддерживающих BCD (то есть Windows Vista и Windows Server 2008); и LegacyImages, которая позволяет извлечь экземпляры всех «устаревших» операционных систем на компьютере. После подключения к хранилищу BCD мы используем метод EnumerateObjects для извлечения всех экземпляров операционных систем, поддерживающих BCD, которые установлены на компьютере.
objStore.EnumerateObjects _
  WindowsImages, colObjects
Рис. 3 Поиск всех операционных систем на компьютере
Const BcdLibraryString_Description = &h12000004
Const WindowsImages = &h10200003
Const LegacyImages = &h10300006

strComputer = "."

Set objStoreClass = GetObject("winmgmts:{(Backup,Restore)}\\" & _
 strComputer & "\root\wmi:BcdStore")

objStoreClass.OpenStore "", objStore

objStore.EnumerateObjects WindowsImages, colObjects

For Each objObject in colObjects
 objObject.GetElement BcdLibraryString_Description, objElement
 Wscript.Echo objElement.String
Next
Wscript.Echo

objStore.EnumerateObjects LegacyImages, colObjects

For Each objObject in colObjects
 objObject.GetElement BcdLibraryString_Description, objElement
 Wscript.Echo objElement.String
Next
После того, как EnumerateObjects сделает свое дело, подготовим цикл For Each для перебора всех операционных систем в этой коллекции. В цикле для получения и последующего отображения Description операционной системы используем следующие две строки кода.
objObject.GetElement _
  BcdLibraryString_Description, objElement
Wscript.Echo objElement.String
Затем повторим обработку для каждой устаревшей операционной системы, установленной на машине.
objStore.EnumerateObjects _
  LegacyImages, colObjects

For Each objObject in colObjects
 objObject.GetElement _
  BcdLibraryString_Description, objElement
 Wscript.Echo objElement.String
Next
Примечание Мы понимаем ваше волнение, но, пожалуйста, запускайте сценарии BCD с чувством ответственности; скорее всего, существует ограничение на число адреналиновых лихорадок, которое может выдержать человеческий организм. Беременным женщинам, или тем, которые могут забеременеть, или, возможно, никогда не забеременеют, или тем, кто вообще не является женщиной, а, в сущности, является, мужчиной, не следует запускать сценарии BCD без предварительной консультации со своим врачом.
Ладно, хорошо, вам не обязательно сначала констультироваться с врачом. Но, правда же, было бы интересно услышать ответ врача на ваш вопрос о запуске сценариев BCD?
Теперь давайте испытаем что-нибудь действительно сногсшибательное; давайте посмотрим, можем ли мы изменить операционную систему по умолчанию. Например, предположим, что имеется компьютер с двойной загрузкой, на котором работает и Windows Vista, и Windows Server 2008. И предположим, что в качестве операционной системы по умолчанию требуется выбрать Windows Vista. Как бы это сделать? Что ж, взгляните на рис. 4. На нем показан один из способов выполнения этой задачи.
Рис. 4 Изменение операционной системы по умолчанию
Const BootMgrId = "{9dea862c-5cdd-4e70-accl-f32b344d4795}"
Const BcdLibraryString_Description = &h12000004
Const DefaultType = &h23000003
Const WindowsImages = &h10200003

strComputer = "."

Set objStoreClass = GetObject("winmgmts:{(Backup,Restore)}\\" & _
 strComputer & "\root\wmi:BcdStore")

objStoreClass.OpenStore "", objStore
objStore.EnumerateObjects WindowsImages, colObjects

For Each objObject in colObjects
 objObject.GetElement BcdLibraryString_Description, objElement
 If Instr(objElement.String, "Vista") Then
  objStore.OpenObject BootMgrId, objBootMgr
  objBootMgr.SetObjectElement DefaultType, objObject.ID
 End If
Next
С помощью этого сценария мы еще раз открываем хранилище BCD, затем используем метод EnumerateObjects для извлечения коллекции всех установленных на компьютере операционных систем, поддерживающих BCD. После этого подготовим цикл For Each для перебора всех элементов из коллекции, используя следующую (к этому времени уже знакомую) строку кода, чтобы получить Description для каждой операционной системы.
objObject.GetElement _
  BcdLibraryString_Description, objElement
Как только будет получена строка Description для данной операционной системы, мы воспользуемся функцией InStr, чтобы выяснить, входит ли слово Vista в это значение.
If Instr(objElement.String, "Vista") Then
Вы правы, это кажется несколько неуклюжим, правда? Отличным способом было бы использовать идентификатор GUID для Windows Vista и затем напрямую открыть эту операционную систему без перечисления и прохода по всем операционным системам на компьютере.
К сожалению, отличный способ потребовал бы от нас знания идентификатора GUID для Windows Vista. Зато в нашем способе нам не требуется знать ничего (это всегда дополнительный подарок для Сценаристов); все, что требуется сделать, это продолжать поиск до тех пор, пока не будет найдена операционная система, в названии которой есть слово Vista.
Примечание. Что, если на компьютере установлено несколько экземпляров Windows Vista? Ну, в этом случае придется, возможно, искать строку типа Vista Ultimate или Vista Enterprise.
Как только будет найдена Windows Vista, воспользуемся этеми двумя строками кода для открытия диспетчера загрузки Windows и установим в качестве операционной системы по умолчанию, скажем, Windows Vista.
objStore.OpenObject BootMgrId, objBootMgr
objBootMgr.SetObjectElement _
  DefaultType, objObject.ID
Это все, на что у нас есть время в этом месяце; в конце концов, даже Сценаристы не могут справляться с непрерывным возбуждением ежедневно и круглосуточно. Но не беспокойтесь — в следующем месяце мы вернемся с еще одним захватывающим выпуском «Эй, сценаристы!» Немного везения, и к этому времени вы придете в себя.
Головоломка-сценарий доктора Сценаряна.
Задача на этот месяц, требующая не только умения решать головоломки, но и навыков создания сценариев.

Июль 2008 г. Квадратики VBScript
Ладно, в таком виде они, возможно, прямоугольники, а не квадратики, но это не относится к делу. Для решения этой головоломки поместите каждый квадратик с правой стороны в некоторый пустой квадратик с левой стороны, чтобы получить имена функций VBScript. Каждый квадратик должен использоваться только один раз. Приведем пример.
Для правильного решения этого примера необходимо переместить квадратик OU (прямоугольник) в пустой квадратик в первом слове, а MS и OX — на пустые квадратики во втором слове. Это дает функции VBScript с именами UBound и MsgBox, как показано ниже.
Теперь попробуйте это:

ОТВЕТ:
Головоломка-сценарий доктора Скрипто.
Ответ: Квадратики VBScript, июль 2008 г.

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


Документы о рабочей среде Сетевая загрузка Windows
Уэс Миллер (Wes Miller)

Содержание
Как работает PXE
Служба RIS в подробностях
Служба развертывания Windows (WDS) — начало
Другие игроки
Заключение
В течение следующих нескольких месяцев я планирую описать службу развертывания Windows (WDS), которая доступна для Windows Server 2003 и встроена в Windows Server 2008. Служба развертывания Windows может стать очень важной частью вашей инфраструктуры развертывания, поэтому в нашем обсуждении я хочу добиться хорошего знакомства с основами ее работы. Эта
первая статья будет посвящена глубокому анализу протокола удаленной загрузки (PXE; произносится «пикси»), истории службы удаленной установки (RIS) и другим технологиям, которые связаны с удаленной загрузкой и используются корпорацией Майкрософт.
Когда в 2001 году меня перевели в группу разработки базовых возможностей ОС Windows, то одной из доставшихся мне в наследство технологий была RIS (и я был несколько напуган тем, насколько она была сложной и зависимой от оборудования и BIOS). Однако сложилось так, что вместе с Windows® PE RIS стала одной их тех технологий, которые мне, как руководителю программы, понравились больше всего.
Я помню, как впервые устанавливал Windows 3.0 — с набора трехдюймовых дискет. Со временем установка стала проще благодаря распространению загрузочных компакт-дисков (на которых выпускались некоторые версии Windows 98). Но одна вещь всегда оставалась неизменной: для установки требовался какой-то локальный носитель, так же, как и локальный жесткий диск.
С годами пользователи все чаще начали требовать возможности сетевой загрузки Windows — то есть загрузки только по сети на компьютер, не имеющий жесткого диска. Хотя некоторые ранние версии Windows и могли это делать, в Windows NT® такой возможности не было никогда. И хотя текущие версии Windows Server® 2003 и Windows Server 2008 могут загружаться через инициатор iSCSI, этот процесс отличается от настоящей сетевой загрузки тем, что он не полностью локален, а все время зависит от удаленного устройства, используемого как загрузочный диск.
Подготовка клиентских компьютеров
  • Оценка процесса подготовки клиента RIS
  • Планирование улучшения сетевой безопасности при помощи подготовленных клиентов
  • Подготовка клиентских компьютеров
  • Удаленная установка операционной системы
Начиная с Windows 2000 Microsoft приступил к разработке технологии, которая с течением времени стала называться службой удаленной установки RIS и которая должна была реализовать установку по сети. Цель службы RIS была достаточно проста: перенести образ операционной системы на локальный диск нужного компьютера с помощью протокола PXE.

Как работает PXE
На рис. 1 изображена последовательность загрузки с помощью PXE. PXE — это довольно простой протокол, разработанный Intel и другими поставщиками оборудования как часть инициативы Wired for Management («сеть для управления»). Протокол произошел от протокола DHCP, который в свою очередь был разработан на основе протокола BootP и обычно реализуется в сетевых платах. Проще говоря, происходит следующее:
Рис 1: Последовательность загрузки с помощью PXE(щелкните изображение, чтобы увеличить его)
Первый этап Загружается BIOS системы, которая определяет последовательность загрузки.
Второй этап Если в последовательности загрузки PXE находится впереди жестких дисков, флэш-накопителей и компакт-дисков или ни одно из этих устройств не установлено, то с сетевой платы загружается универсальный интерфейс сетевых драйверов (UNDI). В сетевую плату встроены очень маленький драйвер сетевого устройства и реализация протокола TFTP. (В некоторых версиях BIOS пользователь должен нажать клавишу F12, чтобы использовать протокол PXE. Это нестандартное поведение, и я очень рад, что его можно выключить).
Третий этап Система начинает широковещательную трансляцию по протоколу UDP, пытаясь найти сервер DHCP. Фактически это и есть первый этап последовательности загрузки с помощью протокола PXE, который называется «обнаружение» (Discover). Заметьте, что используется протокол UDP — а значит, если вы еще этого не сделали, то стоит потратить некоторое время на настройку маршрутизаторов и коммутаторов, чтобы разрешить обмен данными по протоколу PXE.
Четвертый этап Если сервер DHCP принял трансляцию, он отвечает выдачей IP-адреса. Этот этап называется «предложение» (Offer). Важно помнить, что протокол PXE — протокол без сведений о состоянии, и объем уникальных данных о состоянии системы, который доступен клиенту, довольно ограничен (MAC-адрес и, если он доступен, идентификатор GUID системы System Management BIOS, известный также как SMBIOS GUID).
Пятый этап Клиент, получив пакет данных с IP-адресом, требует дополнительной информации — адреса сервера PXE. Происходит следующая широковещательная передача, при которой, в частности, передаются данные, полученные в первом ответе от сервера DHCP. Клиент говорит серверу DHCP: «Мне нужна дополнительная информация — в частности, данные о местонахождении программы сетевой загрузки (NBP) ». Этот этап называется «запрос» (Request).
Шестой шаг В ответе сервера протокола PXE содержится адрес его самого и данные о расположении NBP — очень маленькой исполняемой программы загрузки, размер которой не должен превышать 32 килобайта. Этот шаг называется «подтверждение» (Acknowledge). Возможно, вы уже заметили аббревиатуру DORA (Discover, Offer, Request, Acknowledge), – хороший способ запомнить последовательность шагов.
Обратите внимание, что если у вас установлены сервер DHCP и служба WDS корпорации Microsoft (или похожий набор средств от другого поставщика), то этап запроса отсутствует, а пакет данных, отправляемый сервером DHCP на этапе предложения уже содержит сведения о расположении сервера PXE и программы NBP (таким образом, исключаются два этапа и экономится немного времени).
Седьмой этапКак было указано выше, у клиента есть небольшой стек протокола TFTP, с помощью которого и загружается программа NBP с сетевого ресурса, указанного сервером PXE. TFTP — это устаревший, очень небольшой протокол без сведений о состоянии. Он был выбран не за свою безопасность или производительность, и в результате многие администраторы маршрутизаторов запрещают его по умолчанию. Тем не менее, для работы PXE он должен быть включен.
Во многих реализациях протокола PXE (в том числе в службе RIS) добавлена возможность попросить пользователя в этот момент нажать для продолжения клавишу F12, но обычно администратор сервера PXE может отключить эту возможность. Когда в следующем месяце мы подробнее изучим службу WDS, я обращу ваше внимание на те усовершенствования, которые корпорация Майкрософт внесла в TFTPD (демон протокола) для увеличения его производительности в рамках службы WDS Windows Server 2008.
Восьмой этап NBP инициализирован. В случае использования службы RIS эта программа запускает загрузчик Windows, который начинает процесс развертывания. Протокол PXE (по крайней мере собственно протокол уровня загрузки) в процессе больше не участвует.
Важно помнить, что PXE (в составе службы RIS, WDS или другой инфраструктуры) плохо работает на медленных сетевых каналах (он может передавать значительные объемы данных) или на каналах с большими задержками, например спутниковых (в таких случаях обмен данными идет очень плохо и может вообще оборваться).
Вы могли обратить внимание в процессе загрузки PXE на то, что когда клиент отправляет запрос, нет ничего, что могло бы спросить: «Вы действительно моя мама?». Количество информации о состоянии, доступное серверу PXE, слушком мало, чтобы так или иначе об этом знать. Обычно возникает конфликт, который выигрывает сервер, первым отвечающий на запрос клиента. Пара приемов может помочь уменьшить эту проблему.
  • Выровняйте скорости ответа серверов PXE. Задержки сети и мощность сервера влияют на время ответа сервера. В корпорации Майкрософт серверы, которыми пользуется отдел ИТ, настолько хороши, что даже если сервер PXE находится прямо в офисе, серверы корпорации иногда выигрывают. В этом случае просто настройте свой местный сервер PXE работать с вашими подготовленными клиентами с нулевым временем ожидания.
  • Подготовьте клиенты. При работе с сервером PXE очень важно добиться того, чтобы ваш сервер PXE отвечал раньше серверов отдела ИТ предприятия. Путем предварительной подготовки клиентов вы даете возможность службе Active Directory® сообщить службам WDS или RIS: «да, действительно, я ваша мама». Использование идентификатора GUID SMBIOS в качестве уникального идентификатора системы в Active Directory крайне предпочтительно — однако если идентификатора GUID SMBIOS не реализован в системе (обычно потому, что используется относительно старое оборудование), вы можете (и вам придется) воспользоваться идентификатором GUID, основанном на MAC-адресе. Для получения дополнительных сведений см. статьи, приведенные на боковой панели «Подготовка клиентов».
  • Не позволяйте обмену данных по протоколу PXE проходить через коммутаторы или маршрутизаторы; поставьте с каждой стороны по серверу PXE. Такое решение, правда, дорого реализовать и дорого сопровождать (на каждом сервере должен поддерживаться свой собственный образ).
Подлинность серверов службы RIS (а теперь и WDS), как и серверов DHCP корпорации Майкрософт, должна быть проверена в том экземпляре Active Directory, к которому они принадлежат. Цель этой проверки состоит в том, чтобы уменьшить проблемы, которые могут быть вызваны незаконными серверами PXE (например, «широковещательными бурями PXE»), посредством информирования служб Active Directory обо всех таких серверах.
Правда, эта защита работает только против тех серверов, о которых известно службе Active Directory. Если вы установили свой домен или сервер PXE не от корпорации Microsoft, такая защита работать не будет.
Однажды в корпорации Microsoft один чрезмерно усердный сотрудник настроил полностью автоматизированное развертывание серверов PXE, не поддерживающих службу RIS. Его реализация работала так: все содержимое жесткого диска полностью стиралось, а на это место записывался новый образ. Если бы развертывание было ограничено изолированной лабораторией, не подключенной к сети, то все было бы нормально — но, к сожалению, это было не так, и закончилось все стиранием диска одного из директоров корпорации Майкрософт, у которого загрузка с помощью протокола PXE стояла впереди загрузки с жесткого диска.
Отдел ИТ корпорации Майкрософт всегда требует нажатия клавиши F12 для загрузки по PXE, что могло бы предотвратить происшествие, однако у этого сервера PXE не было настроено ни задержки, ни запроса на нажатие F12, ни какого-то другого типа оповещения. В результате у директора фактически пропал компьютер и все данные, не защищенные перемещаемым профилем пользователя.
Пусть эта история поможет не забывать о необходимости изоляции серверов PXE, если предполагается применение полностью автоматизированного развертывания, или как минимум о требовании нажатия клавиши F12.

Служба RIS в подробностях
Я начал работать со службой RIS после того, как начала продаваться система Windows 2000. Нехватка времени тяжело сказалась на службе RIS в составе Windows 2000 — тестирование, производительность и другие ограничения привели к тому, что в Windows Server 2000 служба RIS использовалась для профессионального развертывания только системы Windows 2000 Professional. Серверные же продукты, к сожалению, не могли разворачиваться через службу RIS. Windows 2000 была доступна только для компьютеров x86, что оказалось хорошей средой для тестирования службы RIS, поскольку в ней был только один продукт только для одной архитектуры. В службе RIS имелись (и были необходимыми условиями) полная интеграция со службой Active Directory, хорошо интегрированной с сервером DHCP корпорации Майкрософт, и собственный демон TFTPD.
Cлужба RIS использовала NBP для продолжения загрузки через TFTP и передачи на сторону клиента достаточного числа компонент ядра Windows, чтобы начать процесс установки. (В определенный момент времени, когда Windows переключается с TFTPD на подключение к серверу, основанное на протоколе SMB, работает буквально та же ветвь кода, которая осуществляет установку Windows 2000 или Windows XP с дискет). Когда инициализируется исходный режим Windows, установщик Windows запускает мастер выбора операционной системы службы RIS.
Экраны мастера выбора ОС — это до некоторой степени настраиваемые страницы, похожие на HTML 2.0. Их содержимое сильно ограничено: на них не может быть изображений и даже символов не из кодировки ANSI (что усложняет развертывание некоторых языковых стандартов Windows).
Конечный результат работы службы RIS — это файл txtsetup.sif, расположенный на сервере службы RIS. Когда мастер выбора OС завершает работу, происходит «теплая» перезагрузка клиента, однако расположение сервера RIS и файла txtsetup.sif запоминается и восстанавливается после перезагрузки. По сути, файл txtsetup.sif такой же, как и unattend.txt, за исключением нескольких дополнительных полей, помогающих службе RIS выполнить процесс установки.
Служба RIS может предоставить похожую на традиционную автоматическую установку (RISetup), а также содержит инфраструктуру клонирования, похожую на Sysprep (RIPrep), с которой она даже имеет общий программный код. Но и RIPrep может передать свой образ на сервер RIS.
Однако у службы RIS есть некоторые ставшие очевидными фундаментальные ограничения. Во-первых, это отсутствие поддержки развертывания серверов. Некоторые вредоносные программы, такие как Code Red и Sasser, в сочетании с осложнениями работы отделов ИТ, наступившими после трагедии 11 сентября 2001 года, привели к тому, что мы срочно разработали решение для существующих серверов RIS на базе Windows 2000, осуществляющее развертывание Windows Server. В нем использовалось кое-что из того, что планировалось включить в состав Windows Server 2003, но что так и не было официально выпущено.
Дополнительные сведения о технологиях, связанных с PXE
  • Описание взаимодействия по протоколу PXE между клиентом PXE и серверами DHCP и RIS
  • Планирование развертывания операционной системы, запускаемого с помощью PXE
  • Архитектура PXE
  • Службы удаленной установки
  • Удаленная установка операционной системы
  • Поэтапное руководство по удаленной установке OC
  • Поставщик PXE WDS
  • Что такое службы удаленной установки?
  • Автоматизированные службы развертывания Windows Server 2003.
Во вторых, служба RIS не могла полностью автоматизировать работу мастера выбора ОС, что было позже исправлено добавлением в Windows Server 2003 элемента <META ACTION="AUTOENTER">. Наконец, мастер не может нормально работать с символами, не входящими в кодировку ANSI — важный недостаток, на который указали несколько заказчиков за пределами США.
В результате установку с помощью службы RIS нельзя нормально выполнить, например, имея только французскую клавиатуру. Надежная работа с символами, не входящими в кодировку ANSI, на уровне BIOS на компьютерах из разных стран — крайне сложная задача, которую не так-то просто было решить.
При выпуске Windows Server 2003 была официально добавлена поддержка архитектуры Intel Itanium и всех серверных вариантов Windows 2000 и Windows Server 2003. Следующим шагом вперед было начало поддержки архитектуры x64 в Windows Server 2003.
Был также существенно переделан демон TFTPD, входящий в состав службы RIS, в результате чего возросла его производительность. Windows Server 2003 поддерживает одновременную загрузку до 75 клиентов; верхняя граница здесь обусловлена заполнением канала SMB сетевым трафиком клиентов.

Служба развертывания Windows (WDS) — начало
Когда мы начали работать над службой RIS для «Longhorn» (кодовое имя системы, которая впоследствии стала называться Windows Server 2008), стало очевидным, что нам нужно сделать шаг назад. Как я упоминал в предыдущей статье, мы уже сделали ставки на основанную на образах (WIM) установку из Windows PE. В результате основополагающим принципом, по которому работает служба WDS, стало развертывание, основанное на образах из загружаемого по протоколу PXE экземпляра Windows PE.
Мы также знали, что Windows Server 2003 будет распространенной платформой развертывания для Windows Vista® и что нам понадобится дополнительное решение для работы службы WDS на нижнем уровне. В результате служба WDS стала работоспособной к моменту выпуска Windows Server 2003 SP1 и была встроена в Windows Server 2003 SP2.
Поскольку эта служба может работать в режиме сервера RIS (режим прежних версий), как гибридный сервер (смешанный режим) и как сервер службы WDS (собственный режим), служба WDS позволяет гарантированно перейти к стилю развертывания, основанному на WDS. Я слышал, как заказчики спрашивают о том, можно ли установить RIS на Windows Server 2003 SP2. Да, можно — установите службу и запустите ее в режиме прежних версий. На рис. 2 показаны поддерживаемые операционные системы.
Рис. 2 Платформы, развертывание на которые поддерживается
Операционная система | Служба RIS (Windows 2000) | Служба RIS (Windows Server 2003)** | Служба WDS (Windows Server 2003)**** | Служба WDS (Windows Server 2008)
Windows 2000 Pro | X | X | X | X
Windows 2000 Server | * | X | X | X
Windows XP Pro |  | X (x86 и IA64)*** | X | X
Windows Server 2003 |  | X (x86 и IA64)*** | X | X
ОС Windows Vista |  |  | X | X
Windows Server 2008 |  |  | X | X
* support.microsoft.com/kb/308508 и support.microsoft.com/kb/313069 добавлена поддержка для Windows 2000 Server через службу RIS. ** для режимов WDS прежних версий и смешанного к устаревшим установкам применима та же матрица. *** В Windows Server 2003 SP1 добавлена поддержка систем x64. В системах IA64 поддерживается только установка на основе RISetup. **** Поддержка собственного режима.
Поставка службы WDS в составе Windows Server 2003 SP1 и SP2 была направлена на то, чтобы начать переход на WDS. Как я отмечал выше, ключевыми свойствами WDS, появившимися в Windows Server 2008, являются исправленный демон TFTPD, поддержка загрузки расширяемого интерфейса микропрограмм (EFI), и, конечно же, использование многоадресной рассылки при развертывании.

Другие игроки
Службы автоматического развертывания (ADS) были разработаны другой рабочей группой внутри корпорации Microsoft. Их главной целью была быстрая подготовка серверов. В ADS используются посекторное создание образов, свой собственный загрузочный агент (меньший, чем Windows PE, но полнофункциональный), собственный демон TFTPD и очень развитая система многоадресной рассылки. Встроенная в ADS функциональность до определенной степени доступна в System Center Configuration Manager (SCCM), хотя их возможности совпадают не полностью.﻿
В Windows XP Embedded встроена полная загрузка по протоколу PXE через свой собственный демон TFTPD на диск в ОЗУ, однако отсутствует возможность удаленного развертывания таким способом. Эта технология разработана для того, чтобы поддерживать загрузку большого количества систем с одного образа диска с помощью PXE.

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

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


На страже безопасности Пароли и кредитные карты, часть 1
Йеспер М. Йоханссон (Jesper M. Johansson)

Содержание
Невозможная для выполнения рекомендация относительно безопасности
Неправильная и невозможная для выполнения
Непонятная рекомендация
Подводные камни проверки подлинности на узле на основе изображений
Недавно ко мне обратился университет Миннесоты с просьбой дать интервью для своего журнала. По-видимому, они хотели посвятить один из своих выпусков успешным выпускникам и, не найдя подходящей кандидатуры, довольствовались мной. Интервьюер спросил, над чем я работаю, и меня на несколько минут увлекла попытка описать инфраструктуру
безопасности программного обеспечения После этого интервьюер воскликнул: «Это звучит невероятно сложно»! Для меня безопасность это пароли и кредитные карты.»
Я пару минут обдумывал такую реакцию и понял, что мнение журналиста действительно правильное. Безопасность – это на самом деле пароли и кредитные карты. По крайней мере, таковой она является для конечного пользователя. Для нас, специалистов в этой области, безопасность это криптографических алгоритмов, лучше ли Kerberos TLS или NTLMv2, преимущества WS*, должны ли хэши паролей иметь дополнительные salt-значения и все остальные эзотерические темы, о которых мы любим дискутировать. Конечно, у нас совершенно другая и более глубокая перспектива, чем у конечных пользователей, но в целом мы упустили из виду одну из фундаментальных вещей: для тех, для кого мы работаем, безопасность это пароли и кредитные карты.
Разумеется, вся эта эзотерика, о которой мы так любим спорить, и новые технологии, которые мы любим изобретать, предназначены для защиты данных конечных пользователей. Тем не менее, я считаю, что мы потеряли верное направление. Мы, представители субкультуры мира ИТ, существуем для удовлетворения определенной потребности доверившихся нам пользователей — необходимости обеспечения безопасности данных. Это, конечно, включает в себя обеспечение безопасности использования активов ИТ. Именно так все и обстоит.
В предыдущих статьях я подчеркивал, что никто не идет покупать компьютер из-за того, чтобы могло работать антивирусное программное обеспечение. Пользователи приобретают компьютеры для игр, работы с электронными банковскими системами, электронной почтой, учебы и иных основных функций. Аналогично, ни одна из компаний не финансирует группу ИТ-безопасности только для реализации NTLMv2. Группы ИТ-безопасности финансируются для защиты активов организаций, позволяя безопасно использовать ИТ-ресурсы и достигать коммерческих целей.
Мы не существуем, а служим.
И поэтому я должен спросить, действительно ли мы хорошо работаем сегодня. Или мы, субкультура безопасности, в действительности больше мешаем, чем помогаем? И способствуют ли этому законодатели и управленцы? Я не уверен, что все вводящиеся новые технологии действительно помогают конечным пользователям. Поэтому я бы хотел рассмотреть несколько областей, в которых мы, ИТ-поставщики мира, в действительности приносим больше вреда, чем пользы.
Порой кажется, что большая часть рекомендаций в области безопасности и множество технологий безопасности, которые мы навязываем пользователям, неверны, непонятны, невозможны для выполнения или (во многих случаях) что-либо из этого вместе. В этой серии из трех частей я собираюсь рассмотреть некоторые применяемые нами способы запутывания пользователей посредством советов и развертывания технологий, виновных в одной или нескольких этих трех буквах Н.

Невозможная для выполнения рекомендация относительно безопасности
Один из самых лучших способов запутывания пользователей – давать советы по безопасности, которые невозможно выполнить. Для получения премиальных баллов вы также можете сделать их неверными. На рис. 1 показан популярный, проверенный временем, кажущийся теоретически обоснованным и абсолютно бесполезный совет.
Рис. 1. Невозможная для выполнения рекомендация относительно безопасности (щелкните изображение, чтобы увеличить его)
Видите рекомендацию использовать разные пароли для всех имеющихся учетных записей? Тридцать лет назад это имело смысл. Людей, которые в итоге стали называться Интернетом, насчитывалось несколько сотен, и они были очень умны, чтобы, в частности, не использовать орфографически правильные пароли. К сожалению, этот совет по-прежнему существует и продолжает снова и снова высказываться, к тому же отсутствуют явные попытки согласовать его с тем, как сегодня используются компьютеры.
Сколько у вас учетных записей? Лично у меня 115, чуть больше или чуть меньше, я не слежу за их количеством. Совет, приведенный на рис. 1, не только рекомендует мне иметь 115 различных паролей, мне также следует менять все 115 паролей каждые 30 – 60 дней. Другими словами, я должен менять 2 – 4 пароля в день. (Посчитайте: это также означает, что в течение одного года у меня будет от 690 до 1380 паролей.)
Хотя технические специалисты некоторых узлов, дающие такую рекомендацию, возможно, могут придумать 4 хороших пароля в день и хранить 115 текущих паролей в кратковременной памяти, вы можете быть уверены, что 99,99 процентов обычных пользователей Интернета такого не могут.
Совет не использовать где-либо одинаковые пароли, по сути, является правильным и рассматривается, исключительно с теоретической точки зрения, как рекомендация менять все пароля каждые 30 – 60 дней. Но этот совет также не может быть выполнен. Сегодня пользователи имеют настолько много паролей, что просто не могут следовать этому совету без каких-либо вспомогательных средств, таких как бумага или программы. Перейдем к следующему примеру.

Неправильная и невозможная для выполнения
Совет, показанный на рис. 2, который приведен на веб-узле одного из самых крупных в мире банков, является одновременно неверным и невозможным для выполнения. В информации, приведенной под заголовком «Read our password advice» (Ознакомьтесь с рекомендациями по паролям) повторяется строка «везде разные пароли». Также рекомендуется «никогда не записывать их».
Рис. 2. Неправильная и невозможная для выполнения (щелкните изображение, чтобы увеличить его)
Теперь у меня 115 различных паролей, я должен создавать 4 новых пароля каждый день, и мне запрещено записывать их. Некоторое время я думал, что просто глуп, так как не могу запомнить все мои пароли. Затем я обнаружил, что этого не могут и все остальные. Человек просто не может запомнить 115 паролей. Мы можем запомнить и обработать семь фрагментов данных — так уж мы запрограммированы. Если следовать большинству советов, которые можно найти в Интернете, в действительности этого недостаточно даже для одного пароля (см. статью «The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information» Джорджа А Миллера, доступную по адресу musanim.com/miller1956).
К сожалению, когда дело касается рекомендаций по паролям, наша отрасль регулярно вводит пользователей в заблуждение. Если субкультура безопасности сообщает пользователям о недопустимости использования одинаковых паролей, мы также должны сообщить им, как это сделать — то есть, записать и сохранить эти пароли в безопасном месте. Запишите их на бумаге, используйте конфиденциальный документ или специальную программу, к примеру PasswordSafe (sourceforge.net/projects/passwordsafe). Примите это, мы все или записываем пароли или везде используем один и тот же пароль. Фактически, недавний опрос показал, что 88 процентов пользователей используют один пароль во всех системах с необходимость проверки подлинности (см. msnbc.msn.com/id/24162478).
Рекомендация не записывать пароль несомненно способствует этой тенденции. Необходимо обучить пользователей эффективному управлению паролями (и другими конфиденциальными данными), а не требовать, чтобы они вообще не занимались управлением. В результате значительно снизиться вероятность раскрытия их учетных данных.

Непонятная рекомендация
Первые два рисунка повторяют старый совет, который хорошо работал в 1960е, семидесятые и восьмидесятые годы, когда использование Интернета и веб-служб еще не было массовым. Но пока никто громко не выражал недовольство этой рекомендацией, поскольку это общепризнанная мудрость.
Эта рекомендация приводит пользователей в замешательство и вызывает у них чувство вины, так как пароли приходится где-то сохранять. Рекомендуя подобное вместо того, чтобы помогать пользователям делать то, что им приходится делать, профессионалы в области безопасности только вредят. В конце концов, выяснение способов обеспечения безопасности – это не обязанность пользователей. Этим должны заниматься специалисты в области безопасности. Необходимо выяснить допустимые способы управления пользователями своими учетными записями. Но поскольку в большинстве руководств повторяется один и тот же устаревший совет, для отслеживания паролей пользователи прибегают к наклейкам и таблицам.
Пароли, как механизм проверки подлинности, могут многое предложить. Однако главная проблема паролей заключается в том, что необходимость их запоминания вызывает у людей ужас. Вместо того, чтобы пытаться разрешить человеческую природу, мир ИТ продолжает изобретать всевозможные новые механизмы замены паролей, или, что хуже, дополнять их. Это только еще больше приводит пользователей в замешательство.
Представьте мое удивление, когда я в прошлый раз посетил узел некоторой финансовой службы и увидел экран входа в систему с единственным текстовым полем имени пользователя (см. рис. 3).
Рис. 3. Куда вводиться пароль?
Сначала я подумал, что попал на вредоносный веб-узел. Я быстро проверил узел, что было просто благодаря представленному на узле сертификату, и понял, что на самом деле я нахожусь в верном месте. Проблема в том, что при входе в систему узлов люди привыкли видеть два текстовых поля, имя пользователя и пароль. Причина этого – многолетняя работа с одним и тем же общим рабочим процессом. Поэтому когда вы неожиданно посещаете узел, на котором запрашивается только имя пользователя, работа сразу же прекращается. Все дело в том, что в этом случае поставщик реализовал технологию, использующую изображения для идентификации узлам пользователям с целью защиты от фишинговых атак. При вводе имени пользователя появляется экран с идентифицируемым изображением, как показано на рис. 4.
Рис. 4. Теперь на некоторых узлах используются изображения для проверки подлинности узла для пользователя(щелкните изображение, чтобы увеличить его)
Теория заключается в том, что вам известно изображение, соответствующее узлу. Если верное изображение не показано, можно сделать вывод о поддельности узла. Сама по себе эта концепция является голословной. Исходя из предположения, что пользователю известно изображение для определенного узла, эта стратегия имеет определенный смысл.
Конечно, проницательный читатель заметит на рис. 4 зеленую адресную строку. Это означает, что на узле используется SSL-сертификат и сертификат высокой надежности (EV); по этой причине адресная строка зеленого цвета. Это также означает, что вся идея использования изображения для идентификации узла не представляет никакой дополнительной выгоды. Вместо этого изображение делает немного больше, чем просто создает путаницу по крайней мере у части конечных пользователей. Узел уже выполнил идентификацию для пользователя — он предоставил сертификат с названием компании, адресом веб-узла и именем доверенного поставщика. А тот факт, что адресная строка зеленого цвета, говорите мне о том, что компания сделала даже больше, чем необходимо, заплатив трехкратную стоимость сертификата EV.
Кроме того, разумеется, изображения также могут подделываться. Если пользователь может отправить собственное изображение, у злоумышленников, скорее всего, существуют способы выяснения используемого изображения. Также велика вероятность того, что пользователь будет использовать одно изображение на всех узлах, так что злоумышленнику необходимо просто создать узел, содержимое которого будет ценным для пользователя (позволю вам предположить собственные примеры), и запросить у него изображение, которое будет использоваться для проверки узла. Если пользователь использует одно изображение для всех узлов, для этого нового узла станет доступным изображение, используемое пользователем, например для узла банковской системы.
Хотя некоторые узлы позволяют выбрать собственное изображение, на других узлах используются библиотеки стандартных фотографий. Например, на узле, показанном на рис. 4, доступно 318 фотографий для выбора. Предыдущая уловка не работает для узлов, не разрешающих пользователям отправлять собственные фотографии. Однако если пользователь не может выбрать собственное изображение, вероятность того, что он запомнит фотографию для определенного узла, будет низкой для редко посещаемых узлов. Честно говоря, у меня нет ни малейшего представления о том, какое изображение я использую на узле, показанном на рис. 4, однако могу заверить, что точно не изображение на данном снимке экрана.
Проблема этого подхода на основе изображений состоит в том, что злоумышленник может показать любую из 318 изображений или просто выбрать случайную фотографию на узле Flickr, и многие пользователи предположат, что это правильное изображение. Если бы большинство людей могло запомнить такие вещи, как изображения для определенных узлов, сегодня бы не было всех проблем фишинга и безопасности.
Поэтому зачем необходимо использование изображение для проверки подлинности узла для пользователя, если узел уже прошел проверку подлинности с помощью сертификата? Почему просто не использовать этот сертификат и ознакомить пользователей со способом его проверки? Сертификат уже подтвердил пользователю свою подлинность.
Процесс получения сертификата определенно более безопасен, чем процесс получения от пользователя изображения проверки подлинности узла. Если используется сертификат высокой надежности (EV) и обозреватель Internet Explorer® 7 или Firefox 3, соответствующие данные сертификата даже будут выделены в адресной строке обозревателя. К сожалению, выделение доступно только для очень дорогих сертификатов EV.

Подводные камни проверки подлинности на узле на основе изображений
Технология проверки подлинности с помощью изображения имеет ряд проблем. Прежде всего, сбор имен пользователей с узла становится очень простым. Фактически, при вводе неверного имени пользователя на узле, показанном на рис. 4, появится диалоговое окно, показанное на n рис. 5. После ввода верного имени пользователя, выбравшего секретное изображение, появится именно это изображение. Очевидно, что эти данные будут очень ценными для злоумышленника, пытающегося собрать сведения о пользователе.
Рис. 5. Узлы с проверкой подлинности с помощью изображений позволяют просто собирать имена пользователей
Показанный здесь тип реализации не имеет практически никакого значения для безопасности. Злоумышленник может просто продублировать процесс входа в систему на поддельном узле. Этот поддельный узел запрашивает имя пользователя и передает его подлинному узлу. Можно даже использовать AJAX на клиенте для обновления формы в режиме реального времени, чтобы обеспечить более убедительный внешний вид. Более того, если подлинный узел не предотвращает атаки межузловой подделки запроса (CSRF) на форме входа в систему, код AJAX может даже отправить запрос непосредственно действительному узлу, если он не предоставляет защиту от межузловых запросов XML-HTTP.
После возврата результатов злоумышленник может выполнить анализ данных, извлечь изображение и отобразить его конечному пользователю. Другими словами, любой злоумышленник, который может предоставить пользователю поддельный узел входа в систему, может также отобразить секретное изображение пользователя. В конечном счете, использование проверки подлинности узла на основе изображения не представляет ни какой дополнительной ценности. Изображение отображается до выполнения пользователем проверки подлинности узла и поэтому доступно для злоумышленника, знающего имя пользователя, или если имя пользователя можно получить.
Если предположить, что пользователю не известно о необходимости просмотра сертификата до отправки форм — и это безопасное предположение, учитывая, что использование проверки подлинности на основе изображений само по себе основано на этом же предположении — получение имени пользователя становится тривиальной задачей. Кроме того, поскольку многие схемы проверки подлинности узлов на основе изображений по-разному реагируют на действительные и неверные имена пользователей, сбор имени пользователя осуществляется очень просто. Злоумышленник может даже выполнить это внешними средствами еще до начала атаки.
В итоге пользователи верят, что они более безопасны, или просто еще больше запутываются. Мы затратили значительный объем акционерного капитала на реализацию проверки подлинности на основе изображений и ни как не затруднили для злоумышленников задачу убедить конечных пользователей предоставить учетные данные поддельным веб-узлам.
Это все, что смог рассмотреть в объеме данного выпуска рубрики «На страже безопасности». В следующем месяце появится вторая часть этой серии, в которой будут рассмотрены другие примеры ошибочных методик безопасности и неудовлетворительных реализаций проверки подлинности.

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


Полевые заметки Обеспечение точных результатов выборов
Джош Беналох (Josh Benaloh)

В этом году в США проходят выборы президента, и все внимание общественности приковано к технологиям для голосования. Пока мы боремся с вариантами, маятник раскачивается между подсчетов бюллетеней вручную – а это трудоемкий процесс, при котором могут возникнуть ошибки, механическими устройствами, которыми могут воспользоваться грамотные злоумышленники; перфокартами, где не полностью пробиты отверстия; оптическим сканированием бюллетеней, которые могут быть неверно распознаны плохо настроенными сканерами; сенсорными экранами, работа которых может быть нарушена нестабильным или вредоносным ПО; а также разнообразными гибридами, которые частенько создают куда больше проблем, чем решают.
В самом деле, это лишь простые примеры уязвимости подобных систем. Более того, технологии, широко используемые по всему миру, полностью зависят от честности и умения персонала, работающего на выборах, только тогда результаты выборов подсчитываются честно.
Но есть лучший способ, при котором честные выборы не зависят от персонала или оборудования. Выборы можно проводить таким образом, чтобы точность подсчета голосов проверялась чиновниками, отдельными избирателями и даже заинтересованными наблюдателями.
Для того, чтобы представить себе эту картину, вообразите, что лица, имеющие юридическое право голосовать на выборах, получают коды, позволяющие им отправлять голоса рядом со своими именами на общедоступном веб-узле. Избиратели могут обратиться к веб-узлу и убедиться в том, что ведется точный учет их голосов и что любой может выполнить независимую проверку право всех избирателей голосовать и подсчитать сопадения для заявленных групп.
Но подождите – в подобных открытых выборах отсутствует один компонент – конфиденциальность. Именно так, и этот пробел может заполнить шифрование, тем самым обеспечивая тайну голосования на выборах, результаты которых можно проверить. Вместо публикации предварительных голосов отправляемые голоса шифруются с помощью открытых ключей, ключи шифрования которых есть у администрации выборов и, соответственно, для расшифровки нужно их совместное участие. По завершении голосования администрация выборов начинает совместную работу по подсчету итогов выборов и криптограыической проверке соответствия итогов отправленным зашифрованным бюллетеням.
Индивидуальные избиратели могут проверить, соответствуют ли зашифрованные бюллетени их выбору, и любой может проверить правильность подсчета зафишрованных бюллетеней. Таким образом, можно проверить результаты выборов от начала до конца.
Неужели все настолько просто? Нет. Это точный обзор, однако существует множество деталей, с которыми нужно разобраться, чтобы все работало как следует. Например, все равно сохранится зависимость от традиционных методов, которые помогут гарантировать то, что устройства для выборов сохраняют необходимую конфиденциальность. И как избиратели должны выражать свое мнение в зашифрованных бюллетенях? Избиратели должны быть уверены в том, что эти загадочные зашифрованные бюллетени, отправляемые от их имени, действительно соответствуют их мнению и что их не нужно показывать третьей стороне (за исключением тех случаев, когда возникают подозрения в оказании давления на избирателей или подкупе). Все это необходимо сделать таким образом, чтобы избирателями не пришлось делать ничего более сложного, чем в традиционных системах для голосования.
Процессы выборов, которые можно проверить от начала до конца, изучались в литературе, посвященной шифрованию, более четверти века, и сейчас существуют надежные, практичные способы предоставления криптографической проверки точности подсчета голосов. Недавний всплеск внимания в сообществе, посвященном этим исследованиям, сконцентрирован на той части процесса, которая относится к избирателю, и с этом области также было сделано множество шагов вперед.
Коммерческий спрос на избирательные технологии велик, но не огромен. Обширные конгломераты на этом рынке с разнообразными интересами можно рассматривать с подозрением, так как определенные результаты выборов могут соответствовать этим интересам. Следовательно, лучше заполнить рынок более мелкими игроками, бизнес которых всецело зависит от выборов, проведенных честно. Для получения дополнительных сведений о полностью проверяемых методах проведения выборов обратитесь по адресу research.microsoft.com/crypto/voting.

Джош Беналох – старший сотрудний отдела шифрования в Microsoft Research. В течение восьми лет он входил в Совет директоров международной ассоциации криптографических исследований, и в число его обширных публикаций входит его докторская диссертация, которую он защитил в 1987 году, "Verifiable Secret-Ballot Elections" (проверяемые конфиденциальные выборы).


О Windows из первых рук История занимает место
Рэймонд Чен (Raymond Chen)

Помните Microsoft Bob? Он задумывался как удобный пользовательский интерфейс, надстраивающийся в Windows® 3.1, но вместо этого бесславно потерпел неудачу (заслужив сомнительную известность одного из самых худших технологических продуктов всех времен, как утверждалось журналом PC World). За годы, прошедшие после прекращения своего существования, Bob стал корпоративной шуткой со случайным упоминанием его имени при рисовании улыбок.
Между прочим, внутренним кодовым названием Microsoft® Bob было «Utopia», скажем честно, довольно амбициозное название, но, по крайней мере, с собственным стилем и свежестью. Когда мы узнали, что сотрудники отдела маркетинга решили дать продукту имя Bob, все дружно недоверчиво покачали головами.
Но наследие Bob больше, чем вы можете думать. Оказалось, что мертвый Bob гораздо полезнее живого.
Когда вы планируете распространение программного обеспечения на компакт-дисках, следует убедиться в том, что продукт действительно помещается на одном компакт-диске. К счастью, так случилось, что даже после принятия во внимание дискового пространства, необходимого для переводов, средств поддержки и других компонентов, необходимых на компакт-диске Windows XP, все равно остается около 30 мегабайт свободного пространства. Пользователи, беспокоящиеся о подобном, посчитали: так, мы уже заплатили за весь объем пространства на диске, поэтому мы можем его использовать, верно?
Внутренним кодовым названием Microsoft Bob было «Utopia», скажем честно, довольно амбициозное название, но, по крайней мере, с собственным стилем и свежестью. (щелкните изображение, чтобы увеличить его)
Результатом была довольно слабая попытка сдержать темп распространения нелегальных копий Windows. Кто-то решил заполнить это свободное пространство компакт-диска фиктивными данными, чтобы их присутствие проверялось программой установки Windows. Это, по логике, должно было вынудить пользователей, загружающих копию образа диска, также загружать и дополнительные тридцать или около того мегабайт. Вспомните, что это было время, когда слово «высокоскоростной» еще не стало повседневным термином, а большинство пользователей использовали удаленный доступ. Необходимость загрузки дополнительных тридцати мегабайт данных с помощью модема со скоростью 56 кбит/с была определенным препятствием, сдерживающим пользователей — при современных стандартах это конечно совсем не так.
Сотруднику, которому была поручена реализация этой проверки, был необходим источник фиктивных данных. Сейчас мы бы просто вызвали функцию CryptGenRandom, чтобы создать 30 мегабайт криптографических случайных байтов, но разве в этом есть что-то смешное? Вместо этого специалист обратился к архивам и нашел копию Microsoft Bob. Он объединил образы всех дискет в один большой файл. Содержимое образов дискет Microsoft Bob не является особенно случайным, поэтом он решил зашифровать данные. Когда пришло время ввода ключа шифрования, он небрежно ударил по клавиатуре, в результате чего появилась зашифрованная версия Microsoft Bob. Именно так появились дополнительные данные , заполняющие свободное пространство на компакт-диске Windows XP.
В итоге, операционная система Windows XP стала самым эффективным из когда-либо разработанных средств развертывания Microsoft Bob. Если вы зайдете в свой чулан, отыщите копию Windows XP, и сможете вызвать нужных духов, которые верно направят ваши пальцы на клавиатуре, результатом работы программы шифрования станет копия Microsoft Bob.

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

© 2005 Корпорация Майкрософт и CMP Media LLC. Все права защищены; запрещено частичное или полное воспроизведение без специального разрешения