Сентябрь 2008 Сентябрь 2008
ISA-сервер: Руководство по обеспечению безопасности ISA Server 2006
Множество организаций полагается на сервер ISA Server 2006 для обеспечения защиты своих сред, но немногие из них предпринимают важный шаг защиты самого ISA Server. Данная статья представляет собой руководство по использованию мастера настройки безопасности и административных ролей для ограничения возможностей для атаки и защиты реализации ISA Server 2006. Алан Мэдисон (Alan Maddison)
ISA-сервер: Улучшение безопасности шлюза служб терминалов с помощью ISA Server 2006
С помощью новой функции шлюза служб терминалов Windows Server 2008 обеспечивает пользователям возможность доступа к их компьютерам из любого места без использования виртуальной частной сети. Узнайте о том, как можно опубликовать шлюз служб терминалов с помощью ISA Server 2006 и расширить возможности публикации ISA Server 2006 таким образом, чтобы они включали в себя состояние работоспособности клиента. Доктор Томас В. Шиндер и Юрий Диогенес (Dr. Thomas W. Shinder, Yuri Diogenes)
IIS 7.0: 10 лучших улучшений производительности в IIS 7.0
Последний выпуск IIS содержит модульную расширяемую платформу, где улучшена поддержка сценариев обычного развертывания и управления, в результате чего достигается значительное улучшение производительности. В статье рассмотрены 10 ключевых областей IIS 7.0, где содержатся эти улучшения. Майк Володарский (Mike Volodarsky)
Мобильность: Воспользуйтесь мобильными бизнес-приложениями
Многих мобильным специалистам в наши дни нужны бизнес-приложения, которые можно использовать в офисе (например, CRM, ERP) и которые доступны с мобильного устройства вне офиса. Узнайте о том, как Windows Mobile позволяют развертывать расширенную мобильную функциональность для важнейших бизнес-приложений. Мэтт Фонтейн (Matt Fontaine)
Security: Управление паролями общих учетных записей
Пароли для общих и привилегированных учетных записей – вопрос, знакомый каждому, но слишком многие организации не справляются с управлением этими общими паролями. Это серьезная угроза безопасности. Узнайте о рисках, связанных с общими и привилегированными учетными записями, а также о более эффективных подходах к вопросам управления более наджеными паролями. Крис Стонеф (Christopher Stoneff)
Columns
От редактора: Назад в школу: | Письма в редакцию: Мнения читателей: | Панели инструментов: Новые продукты для специалистов по информационным технологиям:
Exchange в вопросах и ответах: Выравнивание разделов диска, планирование SCR и прочее: В сентябрьском выпуске «Exchange– очередь за ответами» мы ответили на вопросы о расчете количества серверов глобального каталога, изменении членства сервера в сайте и многом другом.Хенрик Вальтер (Henrik Walther) | Обзор служебных программ: Средство проверки памяти Windows: Узнайте, как эта бесплатная программа помогает определить, вызваны ли неполадки в работе операционной системы Windows неисправной памятью.Лэнс Уитни (Lance Whitney) | Sharepoint изнутри: Интеграция каталогов SharePoint: Пав Черны обсуждает ограничения встроенного сервиса управления каталогом SharePoint и показывает как можно заменить этот компонент пользовательским решением, которое поможет синхронизовать информацию получателя SharePoint с другими решениями каталогов.Пав Черны (Pav Cherny)
Язык сценариев Windows PowerShell: Теория строк: Несмотря на свою объектно-ориентированную природу, Windows PowerShell также способен анализировать сложные строки. Дон Джонс демонстрирует, как можно сделать это в Windows PowerShell, используя командлет Select-String.Don Jones (Дон Джонс) | Эй, сценарист!: Оставайтесь на связи с тостером: Откройте для себя способы использования несвязанных наборов записей — виртуальных таблицы баз данных — для обхода ограничений VBScript, связанных с сортировкой данных и работой с большими наборами данных.Создатели сценариев корпорации Майкрософт | Документы о рабочей среде: Расширенные возможности WDS: В третьем выпуске серии статей о службах развертывания Windows Уэс Миллер рассматривает возможности улучшения производительности и масштабируемости, ведения журнала и автоматизации командной строки.Уэс Миллер (Wes Miller)
На страже безопасности: Пароли и кредитные карты, часть 3: В последней части серии из этих трех статей Джеспер Йоханссон обсуждает то, как поставщики программного обеспечения, наборы безопасности и маркетинговая деятельность препятствуют попыткам действительного обеспечения безопасности, и предупреждает, как подобные действия могут привести к обвалу экосистемы технологической безопасности.Йеспер М. Йоханссон (Jesper M. Johansson) | Полевые заметки: Инновации изнутри: Роми Махаян объясняет свою теорию «новаторства изнутри», которая выделяет творческие способности сотрудников и человеческий капитал в качестве ключевых факторов устойчивых сравнительных преимуществ.Роми Махаян (Romi Mahajan) | О Windows из первых рук: Windows 95 неофициально: Рэймонд Чен рассказывает о том, как небольшой код диагностики неожиданно привел к замедлению работы сборки Windows 95.Рэймонд Чен (Raymond Chen)


Руководство по обеспечению безопасности ISA Server 2006
Алан Мэдисон (Alan Maddison)
Краткий обзор.
  • Рекомендацию по обеспечению безопасности серверов
  • Установка мастера настройки безопасности
  • Описание мастера настройки безопасности
  • Назначение административных ролей

Cодержание
Обеспечение защиты серверов
Установка мастера настройки безопасности
Запуск мастера SCW
Административные роли
Хотя многие специалисты по ИТ полагаются на ISA Server 2006 для защиты своих технологических активов, немногие специалисты также защищают и сам ISA Server. Если вы
недавно установили ISA Server 2006, то можете помнить напоминание о немедленном выполнении после завершения установки. К сожалению, многие специалисты по ИТ нечасто уделяют (или имеют) время на выполнение этого важного этапа, и поэтому он оказывается в списке дел, которые не выполняются никогда.
В сегодняшних постоянно меняющихся условиях безопасности такое отсутствие защиты ISA Server более неприемлемо. К счастью, средства для обеспечения защиты ISA Server значительно улучшились. Больше вам не придется бороться с множеством трудностей в мастерах повышения безопасности, входивших в состав ISA Server до выпуска ISA Server 2004. Вместо этого можно полагаться на строго определенные этапы и средства, такие как мастер настройки безопасности (SCW), входящий в состав Windows Server® 2003.
В данной статье представлен краткий обзор общих рекомендаций по обеспечению защиты серверов. Затем будут подробно рассмотрены стратегии повышения безопасности самого сервера ISA Server, использующие мастер настройки безопасности с целью уменьшить число возможностей для атаки сервера ISA Server и административные роли для ограничения доступа к ISA Server.

Обеспечение защиты серверов
Существует множество элементов и практических рекомендаций, относящихся к обеспечению защиты серверов, находящихся в центре обработки данных или в серверном помещении рядом с вашим кабинетом. Вы как администратор несете ответственность за знание этих рекомендаций и выполнение всего возможного для соблюдения этих требований наиболее практичным для организации способом. С повышением внимания к безопасности в последние годы многие из нас довольно хорошо ознакомились с задачами, образующими основу эти требований, поэтому я не буду описывать очевидное, а лишь приведу краткий обзор.
Первое, что необходимо предпринять для защиты вашей среды, – это обеспечить физическую защиту серверов. На практике это означает необходимость ограничения физического доступа к серверам. В небольших средах это означает запирание двери серверной комнаты и определение ограниченного числа лиц, имеющих к ней доступ. В более крупных средах эти основные требования практически не изменяются, но способ их выполнения более сложен. Например, множество организаций используют электронное наблюдение. Это позволяет контролировать вход в помещение с серверами и даже ограничивать доступ к отдельным стойкам и отсекам в зависимости от должностных обязанностей.
При предотвращении возможности кражи или физической компрометации сервера ISA Server или сервера хранилища настроек ISA необходимо учитывать ряд уникальных факторов. Характер данных, которые могут быть получены с украденного сервера, потенциально подвергает риску все серверы ISA Server и трафик (включая зашифрованный) в вашей среде.
При возникновении подозрений на компрометацию сервера, его кражу и иные подобных угрозы необходимо немедленно убрать сервер (если он еще находится в месте эксплуатации) и выполнить стандартные процедуры фиксации улик. После выполнения этих необходимых действий следует приступить к изменению всей конфиденциальной информации — все установленные на сервере сертификаты должны быть отозваны, а все предварительные ключи и общие секреты должны быть изменены. Кроме того, при наличии реплики сервера хранилища настроек все данные, относящиеся к скомпрометированному серверу, должны быть удалены.
Следующим действием после обеспечения физической защиты серверов является внедрение структурированной методики установки исправлений для всего программного обеспечения, включая уровень виртуализации, операционную систему и приложения. Следует регулярно проверять и устанавливать доступные исправления и обновления. Но до установки в рабочих системах эти обновления должны проходить тестирование. Установка исправления не приведет ни к чему хорошему, если оно станет причиной проблемы, компрометирующей приложение или целостность данных.
При компрометации целостности данных следует полагаться на резервные копии. Это приводит к другому ключевому элементу защиты инфраструктуры. Если невозможно быстро и полностью восстановить данных в случае возникновения такой необходимости, простой может оказать значительное влияние на эксплуатацию, что в результате приведет к увеличению затрат, связанных со вторжением.
Два других элемента, которые необходимо принять во внимание, – это аудит и наблюдение. Наблюдение за приложениями и системами – исключительно важные части любого успешного плана безопасности. Если не уделять время изучению журналов, в частности, журналов, относящихся к безопасности, вряд ли можно вообще обнаружить попытки вторжения до фактического нанесения ущерба.
Не менее важным является аудит. Во многих организациях, особенно в больших, он часто формализован и даже может требоваться по закону. В любом случае, чтобы ваши действия были эффективными, необходимо регулярно проверять механизмы и методики, используемые для защиты активов организации, независимо от ее размера.
Наконец, поскольку ISA Server 2006 работает под управлением Windows Server® 2003, важно изучить руководство по безопасности Windows Server 2003 и выполнить необходимые рекомендации. Руководство по безопасности Windows Server 2003 доступно на веб-узле microsoft.com/technet/security/prodtech/windowsserver2003/w2003hg/sgch00.mspx.
В данный момент корпорация Майкрософт рекомендует применение шаблона Baseline Security Policy, но не следует реализовывать какие-либо фильтры IPsec.

Установка мастера настройки безопасности
Так как же сделать сервер ISA Server более безопасным? Основное средство обеспечения защиты ISA – мастер настройки безопасности (SCW). Это средство уменьшения возможностей для атаки. Мастер создает политики безопасности для служб, сетевой безопасности, реестра и политики аудита сервера, настраивая систему только для необходимых служб и функций. Необходимо заметить, что следует настраивать только те службы ISA Server, которые вы собираетесь использовать. Например, служба веб-прокси включена по умолчанию, но если ее использование не планируется, ее следует отключить. Таким образом, необходимо уделять особое внимание доступным вариантам настройки, представляемым мастером настройки безопасности.
Мастер SCW по умолчанию не входит в состав Windows Server 2003, поэтому первым действием является его самостоятельная установка с помощью апплета «Добавление и удаление компонентов Windows®» панели управления «Установка и удаление программ». (Обратите внимание, что мастер SCW в Windows Server 2008 установлен по умолчанию.) После появления окна «Компоненты Windows» установите флажок для мастера настройки безопасности.
По завершении установки приложение становится доступным в меню «Администрирование». До начала использования мастера необходимо обновить SCW, загрузив обновление для ISA Server 2006 (доступно по адресу go.microsoft.com/fwlink/?LinkId=122532). Это обновление служит для добавления ролей для ISA Server 2006 Standard Edition, ISA Server 2006 Enterprise Edition и сервера хранилища настроек ISA Server.
После загрузки обновления необходимо запустить пакет и извлечь из него файлы. После извлечения этих файлов скопируйте два файла XML (isa.xml и isaloc.xml) в папку kbs в SCW — в установке Windows Server по умолчанию это будет папка c:\windows\security\msscw\kbs.
При копировании файлов появится запрос на подтверждение перезаписи двух существующих файлов с такими же именами. Эти файлы для ISA Server 2004, поэтому до их перезаписи необходимо сделать их резервную копию. Заключительный этап – копирование файла isascwhlp.dll в папку bin, которая обычно расположена по адресу c:\windows\security\msscw\bin. После завершения добавления ролей ISA к мастеру SCW вы будете готовы к началу установки.
Как правило, корпорация Майкрософт рекомендует запускать мастер SCW только после завершения настройки ISA Server. При работе с Enterprise Edition это означает настройку всех массивов и всех членов массивов.

Запуск мастера SCW
Первым этапом является запуск мастера SCW из средств администрирования — необходимо помнить, что для успешного запуска мастера SCW необходимы права администратора.
На рис. 1 показан первый экран мастера. Если прочитать текст на экране, в частности, предупреждение «Этот мастер определяет входящие порты, прослушиваемые этим сервером», можно понять причину важности полной настройки сервера ISA Server и массивов до начала данного процесса.
Рис 1. Запуск мастера настройки безопасности (щелкните изображение, чтобы увеличить его)
Без полной настройки вашей среды будет велика вероятность необходимости пересмотреть настройку SCW после завершения настройки ISA Server. На следующем экране, показанном на рис. 2, запрашивается действие для выполнения. Необходимо выбрать пункт «Создать новую политику безопасности».
Рис 2. Создание новой политики безопасности (щелкните изображение, чтобы увеличить его)
После этого появится запрос на выбор сервера, который будет служить базовым для политики. Поскольку выполняется создание новой политики, по умолчанию выбрано использование компьютера, на котором запущен мастер SCW. Однако это поведение изменяется в зависимости от действия, выбранного для выполнения на предыдущем экране. В любом случае рекомендуется устанавливать мастер SCW на сервере, который будет использоваться в качестве базового. Если SCW не установлен на целевом сервере, будет отсутствовать информация, используемая для завершения создания политики. Поэтому, чтобы не усложнять жизнь, установите и запустите мастер SCW с сервера, который будет базовым.
При нажатии кнопки «Далее» мастер SCW начнет процесс анализа ISA Server. Этот анализ включает определение установленных на сервере ролей, ролей, которые, скорее всего, установлены на сервере, установленных служб и основных сетевых данных. После завершения процесса можно просмотреть базу данных, выбрав «Просмотр базы данных». В базе данных настройки содержится множество данных, в том числе все поддерживаемые роли серверов, функции клиента и порты.
После этого мастер SCW приступит к процессу настройки служб на основе ролей. После нажатия кнопки «Далее» появится следующий экран с запросом на выбор ролей сервера, как показано на рис. 3. Первоначальный выполняемый мастером SCW поиск является надежным, и вы увидите, что верные роли сервера уже определены. Однако очень важно еще раз проверить и удалить ненужные роли. Если сервер выполняет несколько ролей, убедитесь в том, что выбраны все соответствующие роли.
Рис. 3 Указание ролей сервера (Щелкните изображение, чтобы увеличить его)
При использовании ISA Server 2006 Enterprise Edition важно помнить, что необходимо учитывать сервер хранилища настроек. Если сервер хранилища настроек установлен на сервере, также выступающем в качестве сервера ISA Server (это, между прочим, противоречит рекомендациям, но, тем не менее, часто используется), необходимо убедиться в том, что выбрана роль сервера хранилища настроек. Не следует использовать проверку базовых показателей сервера, на котором размещены обе роли, но в действительности размещается только роль сервера ISA Server 2006.
Далее появится запрос на выбор клиентских функций сервера. Другими словами, необходимо указать требуемые сервером службы. Например, почти для всех серверов требуется клиент DNS, а если сервер является членом домена, для него будет требоваться функция члена домена.
После выполнения этих этапов появится экран «Параметры управления и другие параметры». На нем указываются параметры приложения, администрирования и операционной системы, используемые службами или полагающиеся на сетевое подключение. Все не выбранные к этому моменту службы будут отключены. Но после внесения изменений и нажатия кнопки «Далее» можно будет выбрать любые дополнительные службы, которые нужно разрешить.
После этого мастер приступит к настройке способа обработки неуказанных служб. Это позволяет определить действия при применении политики в случае обнаружения служб, не включенных в основную базу данных или установленных на базовом сервере. В соответствии с общей рекомендацией следует выбрать отключение неуказанных служб, поскольку это ограничит все непредвиденные направления атаки. К сожалению, это может иметь негативные последствия при сильной несхожести серверов; также необходимо помнить об этом параметре при добавлении каких-либо приложений или сетевых служб в будущем.
На следующем экране мастера, показанном на рис. 4, можно просмотреть службы, измененные мастером SCW. На этом экране подтверждения содержится сравнительное представление текущего состояния и измененного состояния после применения политики.
Рис. 4. Просмотр и подтверждение изменений служб (Щелкните изображение, чтобы увеличить его)
После подтверждения служб для изменения выполняется переход к разделу «Сетевая безопасность». Именно в нем мастер SCW обычно позволяет изменять параметры брандмауэра Windows и IPsec. Но, поскольку выполняется настройка сервера ISA Server 2006, остается лишь пропустить этот раздел, как показано на рис. 5.
Рис 5. Пропуск последних параметров сетевой безопасности (Щелкните изображение, чтобы увеличить его)
После этого мастер переходит к настройке параметров реестра, относящихся к безопасности и методам проверки подлинности сети. На первом экране в этом разделе указано подписывание SMB. Протокол SMB – это основной сетевой протокол Microsoft, а эти параметры обеспечивают возможность подписанной связи для снижения вероятности атак типа «злоумышленник в середине».
Параметры по умолчанию, как показано на рис. 6, обеспечивают высокую безопасность связи по SMB для ISA Server. Но необходимо учитывать влияние подписывания всей связи. При отсутствии свободной процессорной мощности следует снять второй флажок. Также не забудьте подумать обо всех серверах, для которых будет применена политика, — при наличии серверов с различными рабочими нагрузками для решения вопроса об установке этого флажка необходимо руководствоваться сервером с самым высоким потреблением ресурсов.
Рис. 6. Указание необходимости подписанной связи (Щелкните изображение, чтобы увеличить его)
Следующий набор экранов относится к уровню LMCompatibility, который должен использоваться сервером ISA Server. На первом из этих экранов представлено три варианта. Необходимо оставить выбранный по умолчанию вариант «Учетные записи в домене», если только не используются устаревшие операционные системы Windows (такие как Windows 95 или Windows 98) или если для управления доступом используются локальные учетные записи.
На втором экране, относящемся к уровню LMCompatibility, указываются сведения о контроллерах доменов. При отсутствии доменов Windows NT® 4.0 можно оставить выбранный вариант по умолчанию (Операционные системы Windows NT 4.0 с пакетом обновления 6a или более поздние версии ОС). В этом диалоговом окне также следует установить флажок синхронизации часов с часами выбранного сервера. После нажатия кнопки «Далее» можно будет установить ряд дополнительных параметров настройки для входящей связи LAN Manager (LM), как показано на рис. 7.
Рис. 7. Указание методов проверки подлинности для входящей связи (Щелкните изображение, чтобы увеличить его.)
На третьем экране, относящемся к уровню LMCompatibility, определяется необходимость LAN Manager (NTLM) версии 2 Windows NT и сохранение хеш-кодов LM. Необходимо убедиться в том, что эти флажки не установлены, при условии, что ваша среда поддерживает такую настройку, поскольку снятие этих флажков ведет к значительному повышению безопасности. После этого появится окно «Сводка параметров реестра». Просмотрите все записи и подтвердите правильность параметров политики.
Далее мастер переходит к последнему разделу — аудиту. Важно отметить, что изменения параметров настройки, выполненные в данном разделе, не могут быть отменены. Но, поскольку аудит не влияет на функциональность системы, не следует пропускать этот раздел.
Вариант по умолчанию «Выполнять аудит успешных действий» не предоставляет записи журнала событий для ошибок входа в систему. Однако сведения об ошибках входа в систему могут предоставить ценные данные о попытках вторжения. Поэтому, как правило, рекомендуется выбрать «Выполнять аудит как успешных, так и неуспешных действий».
После этого можно проверить настройку аудита и дважды нажать кнопку «Далее», чтобы сохранить политику безопасности. На этом экране, показанном на рис. 8, требуется только указать имя файла; однако также можно ввести краткое описание,. Это описание может быть полезным в больших средах, в которых обязанности по обеспечению безопасности разделяются между несколькими администраторами.
Рис 8. Указание имени и описания для политики безопасности (Щелкните изображение, чтобы увеличить его)
После сохранения файла можно применить политику немедленно или сделать это позднее. Если принято решение выбрать применение политики позже, процесс завершен. При обнаружении ошибок в настройке политики можно выполнить ее откат, за исключением параметров аудита.

Административные роли
Снижение количества возможных направлений для атаки сервера ISA Server – важный этап для уменьшения потенциальных нарушений из внешних источников. Однако также важно проверить назначение административных ролей в ISA Server для ограничения возможности компрометации из внутренних источников. Административные роли и неполный список типичных соответствующих задач показаны на рис. 9 и 10.
Рис. 9. Роли и соответствующие задачи в выпуске Standard Edition
Задача | Аудитор наблюдения | Аудитор | Полный администратор
Просмотр панели наблюдения, оповещений, подключений, сеансов и служб | Разрешено | Разрешено | Разрешено
Подтверждение оповещений | Разрешено | Разрешено | Разрешено
Просмотр информации журнала | – | Разрешено | Разрешено
Создание определений оповещений | – | – | Разрешено
Создание отчетов | – | Разрешено | Разрешено
Остановка и запуск сеансов и служб | – | Разрешено | Разрешено
Просмотр политики брандмауэра | – | Разрешено | Разрешено
Настройка политики брандмауэра | – | – | Разрешено
Настройка кэша | – | – | Разрешено
Настройка виртуальной частной сети (VPN) | – | – | Разрешено
Рис. 10. Роли и соответствующие задачи в выпуске Enterprise Edition
Действие | Аудитор наблюдения за массивом | Аудитор массива | Администратор массива
Просмотр панели наблюдения, оповещений, подключений и сеансов | Разрешено | Разрешено | Разрешено
Подтверждение и сброс оповещений | Разрешено | Разрешено | Разрешено
Просмотр информации журнала | – | Разрешено | Разрешено
Создание определений оповещений | – | - | Разрешено
Создание отчетов | – | Разрешено | Разрешено
Остановка и запуск сеансов и служб | – | Разрешено | Разрешено
Просмотр политики брандмауэра | – | Разрешено | Разрешено
Настройка политики брандмауэра | – | – | Разрешено
Настройка кэша | – | – | Разрешено
Настройка виртуальной частной сети (VPN) | – | – | Разрешено
Выполнение завершения/остановки балансировки сетевой нагрузки | – | Разрешено | Разрешено
Просмотр локальной настройки (в реестре члена массива) | – | Разрешено | Разрешено
Изменение локальной настройки (в реестре члена массива) | – | – | –
Как видите, административные задачи, связанные с ISA Server, значительно сегментированы. Это, в свою очередь, должно упростить назначение верных ролей пользователям в организации.
Кроме того, необходимо помнить, что наилучшим способом назначения ролей является использование концепции минимальных полномочий. Каждый определенный пользователь должен иметь только минимальный объем полномочий, необходимый для выполнения своей работы.
Также важно помнить, что члены локальной группы «Администраторы» в ISA Server 2006 Standard Edition имеют такие же права, как и полный администратор ISA Server. В Enterprise Edition члены локальной группы «Администраторы» на сервере с ролью сервера хранилища настроек имеют полный контроль над настройкой Enterprise. Это означает, что необходимо внимательно проверить членство в группе «Администратора домена», предполагая, что сервер ISA Server является членом домена, а также во всех остальных группах, являющихся членами локальной группы «Администраторы».

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


ISA-сервер
Улучшение безопасности шлюза сервера терминалов с помощью ISA Server 2006
Доктор Томас У. Шиндер (Thomas W. Shinder) и Юрий Диогенеc (Yuri Diogenes)
Коротко
  • Два случая использования шлюза СТ совместно с ISA Server
  • Настройка ISA Server 2006
  • Тестирование и наблюдение

Cодержание
За периметром
Первый случай
Настройка ISA Server 2006
Тестирование доступа клиентов и наблюдение за ним
Наблюдение из ISA Server
Второй случай
Как насчет клиента?
Заключение
Повторяя успех Outlook Anywhere в Exchange Server 2007, Windows Server 2008, в свою очередь, дает возможность получить доступ к вашему рабочему столу безопасным и контролируемым образом из любого места.
Новая служба шлюза сервера терминалов (шлюза СТ) в Windows Server® 2008 предлагает гибкость служб серверов терминалов Windows® в сочетании с возможностю подключения к серверу терминалов из любого места по подключению HTTP. Эта служба использует протокол удаленного рабочего стола (RDP) поверх HTTPS (SSL) для усиления защиты, предоставляя единый клиентский интерфейс для доступа к ресурсам служб терминалов.
Эта новая служба шлюза СТ предлагает существенные выгоды тем, кому нужен удаленный доступ к их компьютерам:
  • Нет необходимости устанавливать сеанс виртуальной частной сети (VPN) до подключения к внутренним ресурсам при помощи RDP.
  • Улучшена безопасность при помощи NAP и проверки работоспособности защиты Windows (Windows Security Health Checks) для контроля подключений по RDP.
  • Не нужно открывать порт 3389 TCP на вход для получения возможности более безопасной веб-публикации через брандмауэры.
Microsoft® Internet Security and Acceleration (ISA) Server 2006 можно использовать для усиления защиты службы шлюза СТ при разрешенном внешнем доступе к внутренним ресурсам. Можно настроить вариант моста SSL к SSL, где ISA Server 2006 получает запросы и передает их внутренней службе шлюза СТ также при помощи HTTPS. При передаче запроса брандмауэр ISA расшифровывает связь по SSL и производит инспекцию уровня приложений.
Если поток протокола HTTP проходит инспекцию, тогда связь шифруется снова и затем передается на прокси служб терминалов. Если поток протокола инспекцию не проходит, связь обрывается.

За периметром
Корпорация Майкрософт проделала значительную работу по повышению безопасности, и Windows Server 2008 — на данный момент самая безопасная и устойчивая версия системы Windows. Однако корпорация озабочена и тем, как пользователи будут реализовывать ее продукты и как пользователи будут следовать практическим рекомендациям для сохранения своей среды в безопасности. Практические рекомендации требуют подхода эшелонированной защиты, который предоставляет защиту в нескольких точках доступа или слоях. Слои, соответствующие нашей дискуссии: политики, процедуры и сведения о состоянии; периметр; внутренняя сеть и, наконец, узел (компьютер).
Когда разрешается доступ внешних пользователей ко внутреннему ресурсу через ISA Server, вам нужно определить границы слоя, в который входит каждый продукт. ISA Server 2006 и шлюз СТ предоставляют безопасность в слое периметра, но для внутренних ресурсов нужно иметь локальные политики, которые предоставляют доступ или отказывают в нем. Сетевая политика и службы доступа (NPAS) позволяют достигнуть этого, работая в слое политик, процедур и сведений о состоянии. Доступ ко внутренним ресурсам (диск, буфер обмена, принтеры, и т.д.) определяется политиками авторизации ресурсов служб терминалов, которые относятся к слою внутренней сети.
В этой статье сначала рассмотрим, как опубликовать шлюз служб терминалов через ISA Server 2006. Затем расширим случай публикации через ISA Server 2006 включением принудительной проверки работоспособности клиента при помощи NAP. При помощи NAP можно создавать политики проверки работоспособности клиента, которые помогут контролировать доступ в слое узла.

Первый случай
Цель — показать, как опубликовать шлюз СТ через ISA Server 2006. На рис. 1 показана общая картина компьютеров и потока данных при подключении. В этом случае реализуется роль сервера сетевой политики (Network Policy Server, NPS) на самом шлюзе СТ; однако он будет изменен во втором случае, где используется центральный сервер NPS. Изучите приведенную ниже последовательность этапов, чтобы ознакомиться с тем, как работает связь между компонентами решения публикации шлюза СТ.
Рис. 1. Публикация шлюза СТ через ISA Server 2006 (Щелкните изображение, чтобы увеличить его)
  1. Внешний пользователь RDP инициирует подключение. Первое, что должен сделать клиент, — разрешить внешнее имя шлюза СТ (в этом примере tsg.contoso.com). Внешняя служба DNS разрешает это имя, которое указывает на внешний IP-адрес сервера ISA.
  2. Между клиентом RDP и внешним интерфейсом сервера ISA устанавливается туннель SSL. Сервер ISA имеет правило веб-публикации на порту 443 TCP, которое использует сертификат, выданный для tsg.contoso.com.
  3. После выполнения этого правила и проверки того, что трафик разрешен, ISA Server пошлет запрос DNS внутреннему серверу DNS (расположенному на контроллере домена) для разрешения имени сервера, укзазанного в правиле веб-публикации.
  4. ISA Server затем откроет туннель SSL к шлюзу СТ и передаст ему запрос проверки подлинности.
  5. Сервер шлюза СТ подтверждает учетные данные пользователя и проверяет, авторизован ли этот пользователь для установления подключения.
  6. Установив, что пользователь авторизован для установления подключения, служба шлюза СТ принимает запросы на порт 443 TCP и перенаправляет пакеты RDP через порт 3389 TCP (по умолчанию) ко внутреннему серверу терминалов, где находятся приложения (такие как CRM).
С этой точки зрения, все пакеты, которые клиент RDP отправляет службе шлюза СТ через ISA Server, пересылаются внутреннему серверу терминалов и наоборот.
Важно отметить, что RDP по HTTPS за кулисами ничем не лучше, чем RDP/RPC/HTTPS. Клиент RDP инкапсулирует связь по RDP в заголовок RPC, который, в свою очередь, инкапсулирован в заголовок HTTP, безопасность которого обеспечивается SSL (или безопасностью транспортного уровня, TLS). Должны присутствовать все компоненты, которые нужны для решения RPC по HTTPS. Поэтому, когда вы устанавливаете службу роли шлюза СТ, автоматически устанавливается прокси RPC по HTTP. Чтобы лучше понять, как этот протокол работает, рекомендуем прочесть статью «Тестирование RPC по HTTP через ISA Server 2006, часть 1: протоколы, проверка подлинности и обработка», которую можно найти в блоге группы ISA Server (доступно по адресу blogs.technet.com/isablog).
Для этой реализации требуется Windows Server 2008 с установленным шлюзом служб терминалов, и это средство зависит от прокси RPC поверх HTTP. Для функционирования компонента прокси RDP по RPC по HTTP должны быть установлены службы IIS 7.0, и они должны работать . Кроме того, требуются службы сетевых политик и доступа, но, если нужно, можно настроить шлюз СТ для использования сервера NPS (ранее известного как службы IAS) для централизации хранения, контроля и проверки политик авторизации подключения служб терминалов (TS CAP). Наконец, нужно получить сертификат SSL для сервера шлюза СТ, если его ещё нет. Важно подчеркнуть, что ISA Server 2006 должен доверять центру сертификации, который выпустил этот сертификат. Поэтому обеспечьте иморт этого сертификата в хранилище доверенных корневых сертификатов.
Доменные службы Active Directory ® требуются только в том случае, если настраивается авторизационная политика шлюза СТ, для которой необходимо, чтобы пользователи были членами группы безпасности Active Directory для подключения к серверу шлюза СТ. Для этого примера установки будет использована служба Active Directory на компьютере с Windows Server 2003 с пакетом обновления 2 (SP2).
Когда установка службы шлюза служб терминалов закончится, появится окно на рис. 2, в котором показаны установленные компоненты. Для подключения к шлюзу СТ клиенты должны работать под управлением одной из следующих систем: Windows Vista®; Windows XP с пакетом обновления 2 (SP2) и RDP 6.0 или выше; Windows Server 2008; Windows Server 2003 с пакетом обновления 1 (SP1) или выше RDP 6.0 или выше. Дальнейшие сведения по настройке шлюза СТ можно найти в поэтапном руководстве по установке сервера шлюза СТ Windows Server 2008, доступном по адресу go.microsoft.com/fwlink/?LinkId=122251. Теперь перейдем к настройке ISA Server 2006.
Рис 2. Обзор установки шлюза СТ(Щелкните изображение, чтобы увеличить его)

Настройка ISA Server 2006
Первым шагом станет создание веб-прослушивателя, который будет обслуживать запросы от внешнего клиента RDP. Веб-прослушиватель имеет следующие ниже параметры.
  • Проверка подлинности: базовая
  • Утверждение проверки подлинности: Windows (Active Directory)
  • Подключения: включено подключение по SSL (HTTPS) через порт 443
  • Сертификаты: сертификат, выпущенный для tsg.contoso.com
  • Сети: внешняя
Затем нужно создать правило веб-публикации. С точки зрения ISA Server 2006, клиент RDP будет использовать тот же протокол, что и Outlook® Anywhere, так что выбираем мастер Exchange Server 2007. Просто выполните следующие действия.
  1. Щелкните правой кнопкой пункт Firewall Policy («Политика брандмауэра»), выберите New («Новая»), а затем – правило публикации доступа веб-клиента сервера Exchange.
  2. На странице Welcome to the New Web Publishing Rule Wizard («Мастер создания правила веб-публикации») введите имя правила и нажмите кнопку «Далее».
  3. На странице Select Rule Action («Выберите действие правила») выберите пункт Allow («Разрешить») и нажмите кнопку «Далее».
  4. На странице Authentication Delegation («Делегирование проверки подлинности») выберите вариант No delegation, but client may authenticate directly («Нет делегирования, но подлинность клиента можно проверить непосредственно») и нажмите кнопку «Далее».
  5. На странице User Set («Установленные пользователи») проверьте, что выбран вариант по умолчанию (Все пользователи), нажмите кнопку «Далее», затем «Готово» и примените изменения.
  6. На странице New Exchange publishing rule («Создание нового правила публикации Exchange») выберите версию Exchange, в нашем случае — Exchange Server 2007. Выберите Outlook Anywhere (RPC/HTTP(s)) и нажмите кнопку «Далее». (Примечание: не выбирайте Publish additional folders («Публиковать дополнительные папки») в параметрах клиента Exchange Server для Outlook 2007.)
  7. На странице Publishing Type («Тип публикации») выберите вариант Publish a single Web Site or load balancer («Опубликовать одиночный веб-узел или балансировщик нагрузки») и нажмите кнопку «Далее».
  8. На странице Server Connection Security («Безопасность подключения к серверу») выберите Use SSL («Использовать SSL») для подключения к опубликованному веб-серверу или ферме серверов, затем нажмите кнопку «Далее».
  9. На странице Internal Publishing Details (сведения о внутренней публикации) в поле Internal site name («Имя внутреннего узла») наберите имя сервера шлюза СТ. Установите флажок Use a computer name or IP address to connect to the published server («Использовать имя компьютера или IP-адрес для подключения к опубликованному серверу), и затем в поле Computer name or IP address («Имя или IP-адрес компьютера») введите имя сервера. Если вы не знаете имя сервера шлюза СТ, нажмите кнопку «Пролистать», чтобы найти его местоположение. Заметим, что имя, которое использовано на этой странице, должно совпадать с общим или субъектным именем на сертификате веб-узла, привязанного к этому веб-узлу шлюза СТ.
  10. На странице Public Name Details («Сведения об общедоступном имени») выберите This domain name (type below) («Имя этого домена (ввод ниже)») в раскрывающемся списке Accept requests for («Принимать запросы к») и затем в поле «Общедоступное имя» введите общедоступное имя, совпадающее с именем в сертификате, который был выпущен для этого URL-адреса, здесь — tsg.contoso.com. Затем нажмите кнопку «Далее»
  11. На странице Select Web Listener («Выбрать веб-прослушиватель) щелкните раскрывающийся список и выберите веб-прослушиватель, который был ранее создан, затем нажмите кнопку «Далее».
На странице Authentication Delegation («Делегирование проверки подлинности») выберите вариант No delegation, but client may authenticate directly («Нет делегирования, но подлинность клиента можно проверить непосредственно») и нажмите кнопку «Далее».
На странице User Set («Установленные пользователи») проверьте, что выбран вариант по умолчанию (Все пользователи), нажмите кнопку «Далее», затем «Готово» и примените изменения.
Если дважды щелкнуть это правило и перейти на вкладку Path («Путь»), то единственным имеющимся путем там будет /rpc/*. Это — следствие того факта, что мы использовали мастер Outlook Anywhere для Exchange Server 2007.

Тестирование доступа клиентов и наблюдение за ним
Как было указано раньше, для подключения к шлюзу СТ нужен клиент RDP версии 6.0 или выше. Для настройки клиентского приложения RDP загрузите его и наберите имя сервера терминалов, к которому нужно подключиться, в поле Computer («Компьютер»). Нажмите кнопку Options («Параметры»), выберите вкладку Advanced («Дополнительно»), затем Settings («Параметры»), затем наберите внешнее имя сервера шлюза СТ, как показано на (рис. 3). В нашем примере это имя на сертификате, привязанном к веб-прослушивателю, который используется правилом веб-публикации для приема входящих запросов. Заметим, что в этом примере используется проверка подлинности Windows NT® LAN Manager. Закончив ввод, нажмите кнопку «OK» и потом «Подключиться». Появится запрос проверки подлинности. Введите учетные данные пользователя с доступом к серверу терминалов и нажмите кнопку «ОК».
Рис 3. Настройка клиента RDP(Щелкните изображение, чтобы увеличить его)
Заметим, что при использовании клиента RDP версии 6.0 (для Windows XP и Windows Server 2003) появится экран на рис. 3. Запрос на проверку подлинности будет выдан дважды: первый раз для компьютера шлюза СТ, второй раз — для сервера терминалов, доступ к которому нужно получить. Это — важный момент: хотя можно было бы подумать, что это вызвано настройкой ISA Server, на самом деле ISA Server не поддерживает поддержку проверки подлинности совсем, так как веб-роль публикации применима ко «Всем пользователям», из-за чего становятся возможными анонимные подключения через брандмауэр ISA.
Клиент RDP, поставляемый в составе Windows Server 2008, имеет параметр «Использовать мои учетные данные шлюза СТ для удаленного компьютера», как показано на рис. 4. Если выбран этот вариант, не нужно вводить учетные данные дважды, что повышает удобство работы пользователей. Этот вариант единого входа также доступен в Windows Vista после установки пакета обновления 1 (SP1).
Рис 4. Клиент RDP из состава Windows Server 2008 (Щелкните изображение, чтобы увеличить его)
Можно наблюдать за подключениями через диспетчер шлюза СТ, используя режим Monitoring («Наблюдение»). Служба шлюза СТ также предоставляет информацию, когда неавторизованный пользователь пытается подключиться к серверу. На рис. 5 в окне просмотра событий показана попытка подключения пользователя, который не имеет полномочий для подключения через шлюз СТ.
Рис. 5. Событие в службе шлюза СТ, занесенное в журнал (Щелкните изображение, чтобы увеличить его)
Для этого события записан внутренний IP-адрес сервера ISA Server 2006, потому что в правиле веб-публикации включен режим «Запросы, пришедшие с компьютера ISA Server». Если нужно зарегистрировать исходный IP-адрес клиента, нужно изменить правило веб-публикации ISA Server 2006 и выбрать режим «Запросы приходят от исходного клиента» на вкладке «Кому».

Наблюдение из ISA Server
При помощи новых компонентов обновления обеспечения поддержки ISA Server 2006 можно пристально следить за каждым подключением ко внутренней сети и знакомиться с тем, что при этом происходит. На рис. 6 показано одно выделенное подключение, и на линии Request: («Запрос:») команда RPC_IN_DATA указывает URL-адрес для RPC через прокси HTTP.
Рис. 6 Журналирование в ISA Server 2006 при помощи обновления обеспечения поддержки (Щелкните изображение, чтобы увеличить его)
Ниже в журнале можно увидеть другую команду RPC по HTTP, RPC_OUT_DATA. Важно знать, какие методы HTTP используются для RDP/HTTP, а именно RPC_IN_DATA и RPC_OUT_DATA, потому что если фильтрация HTTP настроена для блокировки этих методов, трафик на ISA Server будет заблокирован. Если нужно заблокировать среду, можно настроить веб-правило публикации RDP/HTTP для разрешения только этих двух методов. Дополнительные сведения о методах HTTP, обычно используемых для публикации, приведены в статье «Фильтрация HTTP в ISA Server 2004» по адресу technet.microsoft.com/library/cc302627.

Второй случай
В этом случае шлюз СТ будет использовать политику центра NPS, расположенного на другом сервере. Применим политику NAP для клиентов, удаленно подключающихся через шлюз СТ. Эти же компоненты, которые использовались в случае 1, используются тут снова, только добавлен сервер NPS. Однако благодаря введению NAP на клиентской стороне будет использовано больше компонентов, как видно на рис. 7.
Рис. 7 Основные компоненты топологии случая 2 (Щелкните изображение, чтобы увеличить его)
Здесь приведено объяснение каждого компонента. В клиенте Windows Vista агент работоспособности системы (SHA) состоит из компонентов на стороне клиента, ответственных за наблюдение и отчетность о состоянии работоспособности клиента. В составе Windows Vista поставляется агент SHA Windows, однако другие производители также работают по созданию собственных агентов SHA.
Агент NAP на клиенте отвечает за установление подключения к серверу NAP Enforcement Server, когда клиент пытается получить доступ в сеть. Агент NAP отправляет заключение о работоспособности (SoH) этому серверу.
В шлюзе СТ есть политика авторизации ресурсов служб терминальнов (TS RAP) — компонент, который позволяет определить, какие компьютеры будут доступны для получения входящих запросов RDP. TS RAP также определяет, каким пользователям разрешено устанавливать подключения по RDP к указанным серверам.
Центр NPS отвечает за управление условиями, ограничениями и параметрами, регулирующими доступ к внутренним компьютерам. Средства проверки системной работоспособности (SHV) в центре NPS отвечают за оценку того, является ли SoH, поданный клиентом, соответствующим набору политик, установленных администратором.
Давайте сейчас изменим шлюз СТ для указания на сервер центра NPS. Открываем консоль управления шлюза СТ (TS Gateway Manager Console), щелкаем правой кнопкой мыши имя сервера и выбираем пункт «Свойства». В окне свойств сервера переходим на вкладку TS CAP Store и выбираем сервер центра NPS. Затем вводим имя сервера или IP-адрес сервера NPS и нажимаем на кнопку «Добавить». Появится всплывающее окно общего секрета. Введите этот секрет и нажмите кнопку ОК, затем еще раз нажмите кнопку «ОК», чтобы закрыть окно. Нужно помнить этот секрет, так как он будет использоваться на сервере NPS.
Ниже представлены действия, которые нужно выполнить (предположим, что NPS уже установлен на другом сервере):
  1. Откройте консоль сервера сетевой политики, и на левой окне панели выберите NPS (Локально).
  2. На правой панели выберите «Настроить NAP». Появится страница Select Network Connection Method for Use with NAP («Выбор метода сетевого подключения для использщования при помощи NAP»).
  3. В поле Network Connection Method («Метод сетевого подключения») выберите TS Gateway («Шлюз СТ»)из раскрывающегося списка и нажмите кнопку «Далее».
  4. На странице Specify NAP Enforcement Servers Running TS Gateway («Укажите серверs применения NAP, на которых запущен шлюз СТ») нажмите кнопку «Добавить».
  5. В новом окне TS Gateway («Шлюз СТ») введите имя и IP-адрес сервера шлюза СТ. И затем внизу окна введите общий секрет, который был использован при настройке сервера шлюза СТ. Затем выберите «ОК».
  6. На странице настройки перенаправления устройств клиента и методов проверки подлинности можно указать, какие устройства будут перенаправляться, и допустимый метод провери подлинности (пароль или смарт-карта). Для этого примера оставьте параметры по умолчанию и нажмите кнопку «Далее».
  7. На странице Configure User Groups and Machine Groups («Настройка групп пользователей и машин») добавьте группу пользователей, которой разрешено устанавливать подключение. В этом примере, нажмите на кнопку Add Users («Добавить пользователей») под заголовком User Groups (Required) («Группы пользователей: (Обязательно)) и выберите «Администраторы домена». Щелкните кнопку «ОК», а затем «Далее».
  8. На странице определения политики работоспособности NAP вы заметите, что SHV по умолчанию уже выбран. Обратите также внимание на то, что в нижней части страницы закрыт доступ для несоответствующих компьютеров. Оставьте выбранные параметры по умолчанию и нажмите «Далее».
  9. На странице Completing NAP Enforcement Policy and RADIUS Client Configuration («Политика применения NAP и настройка клиента RADIUS») еще раз просмотрите параметры, которые вы ранее выбрали. Можно также перейти по гиперссылке «Сведения о настройке», в результате чего откроется страница HTML с перечнем выбранных параметров. Закончив работу, нажмите кнопку «Готово».
Этот мастер позаботится о настройке параметров для множества важных политик (политики запроса подключений, сетевые политики и политики работоспособности), существенно уменьшит работу, необходимую в этом случае для настройки NAP.

А что там с клиентом?
Сейчас все серверы установлены и настроены, а что нужно делать в отношении клиента?
Для получения преимуществ от политики применения NAP клиентской системой должна быть либо Windows Server 2008, либо Windows Vista. Для Windows XP нужно установить пакет обновления 3 (SP3), в составе которого есть клиент NAP.
Кроме требований к операционной системе, есть некоторые важные службы и параметры, которые нужно включить на стороне клиента. В их число входят следующие.
  • Добавление имени сервера шлюза СТ в список доверенных серверов у клиента.
  • Запуск службы агента NAP и установка типа запуска службы на «Автоматически».
  • Включение клиента применения карантина шлюза СТ.
Чтобы упростить развертывание этого решения, корпорация Майкрософт создала команду настройки клиента NAP служб терминалов (Tsgqecclientconfig.cmd), которая может быть загружена по адресу go.microsoft.com/fwlink/?LinkId=122267. После запуска этой команды клиент будет настроен как клиент применения NAP для щлюза СТ. Обратите внимание на то, что команда должна выполняться под учетной записью с повышенными правами.
На всем протяжении этой статьи основной задачей было не только показать и объяснить новые свойства щлюза СТ, которые доступны на Windows Server 2008, и показать, как их безопасно публиковать через ISA Server 2006, но и предоставить общую перспективу достижений защиты, которые сочетание этих двух продуктов может предоставить вашей организации.
В современном мире быть на связи везде — ключевое требование почти для любого успешного бизнеса. Однако также необходимо, чтобы эта связь не поставлялась ценой удобства работы пользователей. И, что даже более важно, необходимо, чтобы все это было сделано с обеспечением безопасности.

Доктор Томас У. Шиндер является MCSE и ISA Server MVP. Он работает как преподаватель по технологиям, автор и консультант с 1996 года. Доктор Шиндер — автор шести книг по брандмауэрам ISA. Он также является идейным вдохновителем и основным злоумышленником в ISAserver.org, самом большом сообществе администраторов и поклонников брандмауэров ISA в Интернете.

Юрий Диогенес, MCSE+S, MCTS, MCITP, Security+, Network+ и CCNP, является инженером сопровождения безопасности в отделе Microsoft ISA Server/IAG. Он пишет статьи для Microsoft TechNet Library и блога отдела ISA Server. Юрий работает с технологиями Майкрософт с 1993 г. До прихода в корпорацию Майкрософт он работал преподавателем по технологиям Майкрософт, аналитиком поддержки и консультантом.


IIS 7.0
Десять лучших способов улучшения производительности IIS 7.0
Майк Володарский (Mike Volodarsky)
Кратко
  • Уменьшить место, занимаемое приложением
  • Уменьшить занимаемую полосу пропускания
  • Использовать расширенные возможности кэширования

Cодержание
Экономичные веб-серверы
Использование экономичной операционной системы
Применение топологий, адаптированных для нужд приложения
Улучшенная поддержка приложения
Увеличенная плотность приложений
Сокращение занимаемой полосы пропускания за счет сжатия данных
Регулировка полосы пропускания для мультимедийных файлов
Кэширование выводимых данных
Преобразование кода ISAPI в модули IIS 7.0
Расширяемость сервера
Заключение
Всякий раз, когда я встречаюсь с представителями компаний, планирующих переход на IIS 7.0, мне задают один и тот же вопрос: увеличится ли производительность серверов и приложений в результате этого перехода? В общем,
производительность должна возрасти; но не удивляйтесь, если сразу после переноса приложений на IIS 7.0 этого не произойдет.
Чтобы понять причину этого явления, необходимо сначала разобраться с сутью последнего выпуска IIS. Версия IIS 6.0 содержала существенные технологические изменения, направленные на достижение трех целей: повышение уровня безопасности, увеличение надежности и улучшение производительности. Выпуск версии IIS 7.0 преследовал совершенно иную цель: на основе высокопроизводительного кода базовых компонентов веб-сервера, написанного для версии 6.0, создать модульную и расширяемую платформу, которая поддерживала бы основные сценарии развертывания веб-приложений и управления ими.
Многие архитектурные изменения и новые функции этой версии могут отрицательно воздействовать на производительность веб-сервера. Например, одним из основных изменений стало разделение компактных и оптимизированных ветвей кода веб-сервера на изолированные модули, которые не подвергаются никакой специальной обработке со стороны веб-сервера. Однако в результате огромной работы по улучшению производительности, выполненной группой разработки IIS, его производительность осталась примерно такой же, как и у его предшественника, а в некоторых случаях даже повысилась. Как разработчик основных компонентов веб-сервера и интегрированного конвейера я могу сказать, что такой результат был достигнут в результате искусного проектирования и кропотливой работы над созданием продукта.
Тем не менее, у IIS 7.0 есть намного большие возможности по значительному приросту скорости работы и снижению затрат, связанных с производительностью фермы серверов, чем любая другая предыдущая версия IIS.
Скорее всего, просто переход на IIS 7.0 не выявит всех преимуществ нового веб-сервера, хотя в некоторых случаях и этого будет достаточно. Например, на узле Microsoft.com было отмечено 10-процентное улучшение эффективности использования ЦП (полный анализ доступен в блоге группы разработки Microsoft.com наgo.microsoft.com/fwlink/?LinkId=122497). Кроме того, в некоторых определенных областях может наблюдаться существенный рост производительности, в частности в работе протокола SSL и проверки подлинности Windows® (оба процесса теперь выполняются на уровне ядра), а также улучшение вертикальной масштабируемости на многопроцессорных и многоядерных машинах.
Однако основная мощность IIS 7.0 состоит не в пошаговом улучшении производительности существующих функций. Напротив, главные усовершенствования заключаются в новых возможностях, которые нужно активно использовать. Эти возможности основываются на гибкости и расширяемости новой платформы, а также на новых функциях повышения производительности. В этой статье я расскажу вам о 10 наиболее важных способах улучшения производительности, которые станут вам доступны после перехода на IIS 7.0.

Экономичные веб-серверы
Возможность развертывать экономичные серверы IIS 7.0 обеспечивается их модульной архитектурой. Практически все функции веб-сервера реализованы в виде модульных компонент, которые можно добавлять и удалять независимо друг от друга. Таким образом можно убрать все ненужные для приложения операции, что приведет к существенному уменьшению области, открытой для атак и ресурса, используемого операциями, а также к улучшению производительности.
Полный набор функций веб-сервера IIS 7.0 состоит из 44 модулей, включая собственные модули IIS и ASP.NET, предоставляющие службы для интегрированного конвейера. В модулях реализованы такие функции, как проверка подлинности (модули проверки подлинности Windows и дайджест-проверки подлинности), поддержка инфраструктуры приложения (модуль FastCGI), службы приложений (модуль состояния сеанса), обеспечение безопасности (модуль фильтрации запросов) и производительности (модуль кэширования выходных данных). Однако минимальному веб-серверу, обслуживающему статические страницы, для работы требуется всего 2 модуля!
Количество дополнительные данных от неиспользуемых модулей может быть довольно значительным — например, от модуля записи запросов в журнал или от модуля трассировки неудачно завершившихся запросов. Если удалить эти модули из окружения, где они не нужны, можно получить прирост общей пропускной способности и уменьшение времени реакции сервера, что в свою очередь улучшит такие характеристики нагрузки на сервер, как время до получения первого байта (TTFB) и время до получения последнего байта (TTLB).
На рис. 1 показаны результаты простых тестов пропускной способности для HTML-файла (статическая нагрузка) и страницы «Здравствуй, мир», написанной на ASP.NET (нагрузка ASP.NET). Использовались три конфигурации веб-сервера: с полным набором функций, с предлагаемым по умолчанию набором функций для каждого типа нагрузки и с минимальным набором необходимых для каждого типа нагрузки функций. Можно заметить, что, хотя большинство необязательных функций отключены даже в полной конфигурации сервера, пропускную способность можно существенно увеличить как в случае статической нагрузки, так и при работе ASP.NET, если полностью удалить ненужные функции.
Рис. 1. Пропускная способность сервера при статической нагрузке и работе с ASP.NET в трех разных конфигурациях со 100 параллельно подключенными клиентами (Щелкните изображение, чтобы увеличить его)
Кроме того, может снизиться объем занимаемой памяти и повыситься плотность веб-узлов, особенно в случае сред совместного размещения или при использования большого количества рабочих процессов. Это происходит за счет уменьшения количества библиотек DLL, загружаемых каждым процессом, а также количества запросов на выделение памяти, происходящих при инициализации модуля и обработке запроса. На рис. 2 изображено использование памяти (в байтах исключительного использования рабочими процессами IIS) в тестах пропускной способности, о которых говорилось выше. И, хотя приведенные в этом примере изменения не так заметны, они, тем не менее, соответствуют всем ожиданиям. Дело в том, что поддержка приложений ASP.NET требует больше служебных данных, чем можно высвободить удалением модулей.
Рис. 2 Использование памяти (в байтах исключительного использования рабочими процессами IIS) сервером при статической нагрузке и работе с ASP.NET в трех разных конфигурациях со 100 параллельно подключенными клиентами (Щелкните изображение, чтобы увеличить его)
При помощи наборов необходимых условий IIS 7.0 также предоставляет дополнительные возможности по управлению тем, какие модули будут включены на уровне приложения, а также по использованию модулей в зависимости от рабочей нагрузки на них. Хотя для этого и потребуется профессиональная настройка веб-сервера, многоузловые серверы или приложения с несколькими видами рабочей нагрузки могут получить значительные дополнительные преимущества.
В качестве предупреждения: определение требующегося набора функций — непростая задача. Необходимо принять во внимание не только минимальные возможности, требующиеся для работы приложений, но и любые дополнительные функции, которые могут неявно использоваться приложением. Например, приложение может зависеть от собственных методов проверки подлинности пользователя, а может полагаться на средства авторизации, предоставляемые различными возможностями IIS. В последнем случае удаление этих функций может снизить уровень безопасности приложения. Подобным образом приложение может опираться на некоторые технически необходимые или повышающие производительность функции. В этом случае удаление модуля с этими функциями может повлечь за собой неверную работу приложения или снижение его производительности.

Использование экономичной операционной системы
В Windows Server® 2008 реализовано выделение компонентов на уровне операционной системы, посредством чего можно дополнительно сократить контактную зону веб-сервера. Минимальным режимом установки Windows Server 2008 является режим «Server Core», который содержит минимальный набор основных подсистем операционной системы. Для экономичных веб-серверов на базе IIS 7.0 лучшим вариантом установки является именно Server Core.
Однако, рассматривая возможности Server Core, необходимо учитывать, какие его ограничения могут отразиться на работе вашего приложения. В Server Core отсуствует поддержка платформы Microsoft® .NET Framework, то есть нет ASP.NET, расширений.NET для IIS и диспетчера служб IIS. Кроме того, решение задач местного управления потребует использования средств командной строки, поскольку консоль управления (MMC) также отсутствует. Между приложениями, работающими под управлением Server Core и полной версией Windows Server, не будет особых отличий в объеме занимаемой памяти и пропускной способности приложений, если уже были использованы преимущества компонентной структуры IIS. Работа, выполняемая IIS и вашими приложениями, одинакова на обеих платформах. Однако есть характеристика, где разница будет заметна: место, занимаемое сервером, как на жестком диске, так и в оперативной памяти.
В качестве примера на рис. 3 показана разница в занимаемом объеме после одинаковой статической рабочей нагрузки на серверы, работающие под управлением Windows Server 2008 в полной конфигурации и Server Core. Хотя IIS занимает в обоих случаях почти одинаковое место, общий объем места, занимаемого операционной системой Server Core меньше, что позволяет поддерживать ту же рабочую нагрузку, используя существенно меньший объем памяти. Из-за меньшего размер установки может появиться возможность использовать менее мощное аппаратное обеспечение для работы приложения. При этом основная мощность процессора будет тратиться на обработку запросов приложения, а не операционной системы, что делает Server Core отличным вариантом для виртуализированных сред.
Рис. 3. Память, занимаемая Windows Server 2008 в полной конфигурации и Server Core после выполнения теста на статическую нагрузку (Щелкните изображение, чтобы увеличить его).

Применение топологий, адаптированных для нужд приложения
Оптимизируя нагрузку на приложение, в ней можно выделить отдельные части. Например, вместо 30 одинаковых веб-серверов можно обойтись 10 веб-серверами, 3 серверами приложений и 3 прокси-серверами, последние из которых будут выполняли бы кэширование и сжатие данных.
Такая специализация работает по нескольким причинам. Во-первых, производительность многих приложений сильно зависит от разных ресурсов, используемых совместно, таких как память. Части одного и того же приложения могут конкурировать за доступ к таким ресурсам. Такая конкуренция может приводить к образованию узких места и, а это, в свою очередь, будет мешать всем серверам воспользоваться ресурсом. Выделение разных частей приложения позволяет предоставить им доступ к ресурсам, за которые в другом была бы возможна конкуренция, таким образом повышая эффективность их использования.
Во-вторых, специализация может привести к тому, что приложение будет лучше размещено в кэше, что увеличит его производительность. Это относится к кэшам низкого уровня, таким как аппаратный буфер TLB виртуальной памяти, кэш файловой системы, а также другие средства кэширования, реализуемые как операционной системой, так и приложением. Другим источником хорошего местоположения является ЦП. Уменьшение числа одновременно выполняемых операций путем уделения основного внимания только определенной части приложения позволяет уменьшить количество переключений контекста максимально увеличить объем работы, выполняемой ЦП.
В-третьих, специализация обеспечивает возможность оптимизации рабочих нагрузок, повышая эффективность работы всех частей приложения. Множество из этих оптимизаций невозможны при поддержке всего приложения на одном сервере из-за противоречия потребностей различных частей приложения.
Это возможно только в конфигурации потоков IIS и ASP.NET, которая существенно влияет параллелизм и косвенно сказывается на использовании памяти, задержке и пропускной способности множества приложений. Рабочая нагрузка статического файла IIS крайне асинхронна и требует максимального уровня одновременных запросов, но использует очень небольшое количество доступных потоков. С другой стороны, многие функции ASP.NET синхронны, отличаются длительной блокировкой и требуют большого количества потоков, тогда как для других функций требуется более низкий предел параллелизма для снижения воздействия на память. Путем выделения статической нагрузки и поврежденных частей конвейера обработки процессов в отдельный процесс или сервер можно оптимизировать параллелизм каждой отдельной нагрузки.
Наконец, специализация может повысить уровень общей масштабируемости, позволяя приложению выполнять масштабирование отдельных нагрузок или частей приложения независимо друг от друга. Это позволяет топологии приложения увеличивать производительность и избыточность там, где это необходимо, вместо необходимости применения одного шаблона ко всему приложению. В этой модели специализированными ресурсами могут быть физические серверы, виртуальные серверы или даже пулы приложений на одном компьютере.
Оценку возможных преимуществ специализации в топологии приложения необходимо начать с поиска обработки или ограничений приложения, требующих существенных затрат ресурсов. Эти области должны быть первыми кандидатами на специализацию, поскольку при изоляции они могут обеспечить значительные возможности для оптимизации, а также потому, что для них потребуется наибольшее горизонтальное масштабирование. Затем необходимо оценить, позволит ли изоляция более эффективно использовать ресурсы остальным частям приложения. Наконец, потребуется оценить перегрузку механизма подключения, необходимую для объединения изолированных компонентов приложения.

Улучшенная поддержка приложения
Службы IIS 7.0 включают в себя расширенную поддержку платформ приложений с помощью FastCGI, открытого протокола, поддерживаемого множеством платформ приложений с открытым исходным кодом, которые в противном случае могут не поддерживать надежную и высокопроизводительную собственную интеграцию с IIS. В отличие от протокола CGI, который в течение длительного времени поддерживался IIS, FastCGI обеспечивает значительно улучшенную производительность на платформе Windows. В основном это обусловлено архитектурой многократно используемых процессов FastCGI, уменьшающей значительные затраты на создание процессов для отдельных запросов, что позволяет клиентам использовать преимущества постоянных открытых соединений.
При поддержке платформ приложений в IIS с помощью CGI или другого механизма можно улучшить производительность (а в некоторых случаях и стабильность) путем перехода на протокол FastCGI.
Первой платформой приложений, использующей преимущества этой поддержки, является PHP. Группа разработчиков IIS фактически напрямую работала с компанией Zend Technologies для обеспечения успешной работы реализации FastCGI IIS с PHP и улучшения производительности платформы PHP в Windows. (Более подробные сведения об этом проекте см. в моем блоге по адресу go.microsoft.com/fwlink/?LinkId=122509.) При наличии различных технологий веб-серверов, включающих в себя приложения ASP или ASP.NET, работающие в IIS, и PHP и другие платформы приложений, совместимые с FastCGI, использующие иные технологии, можно консолидировать эти приложения на платформе IIS 7.0.
Перенос PHP и других платформ приложений на IIS 7.0 и FastCGI позволит использовать преимущества различных функций IIS 7.0, в том числе интегрированный контейнер ASP.NET. Это предоставляет очень удобный способ улучшения платформ приложений при помощи служб ASP.NET без их преобразования в ASP.NET. Это также позволяет совместно работать приложениям, использующим различные платформы. Пример использования этого для улучшения существующих приложений при помощи функций и повышения производительности без изменения кода см. в моей статье «Улучшите приложения при помощи интегрированного конвейера ASP.NET» в журнале MSDN® Magazine (доступна по адресу msdn.microsoft.com/magazine/cc135973.aspx).

Увеличенная плотность приложений
IIS 7.0 включает множество улучшений, предназначенных для увеличения плотности приложений, которые могут быть размещены на одном сервере. Эти улучшения являются некоторыми из множества функций IIS 7.0, направленных на улучшение качества совместного размещения, которые включают улучшенную подготовку узлов и лучшую изоляцию приложений.
С точки зрения производительности улучшения главным образом касаются двух аспектов увеличения плотности приложений — увеличение количества приложений, которые могут быть подготовлены на сервере IIS 7.0, и количества приложений, которые могут быть активны в любое заданное время.
Обратите внимание на то, что службы IIS 7.0 теперь позволяют подготавливать на каждом сервере больше приложений, чем раньше — в нескольких внутренних тестах достигалась цифра в 100 000 узлов на одном сервере. Это обеспечивает возможность создания и настройки большого числа узлов и приложений.
В качестве предупреждения: для достижения высокоскоростной подготовки необходимо перейти на новые API настройки, поскольку старые API настройки не позволяют этого. Кроме того, не все API настройки IIS предоставляют одинаковые характеристики производительности, поэтому для обеспечения максимальной производительности необходим тщательный выбор API. При возникновении сомнений используйте параметры конфигурации, которые напрямую используют новые объекты настройки IIS, включая пространство имен Microsoft.Web.Administration, служебную программу командной строки AppCmd.exe и объекты настройки IIS COM, которые можно вызвать из сценария, кода .NET или C++.
Разница между количеством узлов, которые могут быть подготовлены и которые могут быть активны – очень важное отличие архитектуры IIS, постоянно использующей приложения и рабочие процессы для выполнения обработки запроса. В этой модели активные приложения потребляют больше ресурсов на сервере, но обеспечивают постоянную лучшую производительность благодаря кэшированию и отсутствию затрат на инициализацию.
Поскольку для каждого активного приложения необходим определенный объем памяти и рабочий процесс (при использовании рекомендуемой модели изоляции приложений), количество активных приложений сильно зависит от объема памяти приложения. Поэтому хотя для рабочего процесса одного приложения, выполняющего только обслуживание статического содержимого, требуется всего 3 МБ (подобные приложения часто могут использовать рабочий процесс совместно с другими приложениями, работающими со статическим содержим), для некоторых динамических приложений может требоваться 100 МБ ОЗУ или больше даже при низкой загрузке. Это обуславливает незначительную загрузку памяти самим рабочим процессом IIS по сравнению с местом, которое занимает приложение, при определении максимальной возможной плотности.
В типичном сценарии совместного размещения часто можно увидеть так называемое распределение 80/20, когда 80 процентов запросов выполняются к 20 процентам узлов. Результат – небольшой процент активных узлов в любой определенный момент времени. Для обеспечения большего количества активных узлов службы IIS 7.0 предоставляют активное управление временем существования. Это помогает высвободить память неактивных приложений, чтобы можно было разместить большее количество активных приложений.
В IS 7.0 появился новый алгоритм под названием «динамический простой», заблаговременно регулирующий тайм-ауты простоя рабочих процессов на основе доступной на сервере памяти. При нехватке памяти простаивающие приложения удаляются более быстро, что обеспечивает размещение большего количества приложений. Однако при наличии доступной памяти тайм-ауты могут оставаться большими для обеспечения лучшей производительности и поддержания состояния приложения. Помимо большего количества приложений, которые могут быть активными, динамический простой позволяет избежать условий нехватки памяти, вызывающих существенное снижение производительности сервера из-за пробуксовки.
Для обеспечения возможности размещения множества активных приложений также следует использовать преимущества 64-разрядной операционной системы, заключающиеся в возможности использования более 4 ГБ ОЗУ. На основе этого можно настроить рабочие процессы IIS для работы в 32-разрядном режиме (SysWoW64), в котором они используют меньше памяти, одновременно позволяя операционной системе работать с большим объемом памяти, чем возможно в 32-разрядной среде.

Сокращение занимаемой полосы пропускания за счет сжатия данных
Неудивительно, что затраты на полосу пропускания – одни из самых больших затрат при работе центра обработки данных, имеющего выход в Интернет. Кроме того, полоса пропускания, необходимая для предоставления запрошенного содержимого, является ключевым фактором воспринимаемой скорости работы вашего приложения.
Одним из наиболее эффективных способов уменьшения полосы пропускания, необходимой для доставки ответов приложения, является использование сжатия HTTP. Оно позволяет значительно уменьшить размер ответа, часто даже в 10 раз, для просто сжимаемого содержимого, такого как HTML. Лучше всего то, что сжатие HTTP поддерживают практически все обозреватели для настольных систем, а затраты на распаковку на оборудовании настольных систем минимальны по сравнению с неявной экономией отправки меньшего количества данных. А поскольку сжатие основано на согласовании кодировки содержимого, определенном в протоколе HTTP 1.1, включение этой функции безопасно для клиентов, не поддерживающих сжатие — эти клиенты просто получают несжатую версию содержимого.
Службы IIS 7.0 предоставляет две функции сжатия, представленные в их предшественнике: статическое сжатие и динамическое сжатие. Статическое сжатие выполняет предварительное сжатие статического содержимого и сохраняет его на диск, таким образом, позволяя будущим запросам работать напрямую со сжатым содержимым без затрат на сжатие. Динамическое сжатие выполняет сжатие ответов в реальном времени, и позволяет сжимать созданные приложениями ответы. Все платформы приложений на IIS 7.0 могут использовать преимущества динамического сжатия, включая ASP, ASP.NET и PHP.
Несмотря на распространенный миф, обычно динамическое сжатие не вызывает чрезмерную загрузку ЦП. Фактически, часто динамическое сжатие использует меньше 5 процентов ресурсов ЦП загруженного сервера. Динамическое сжатие может использоваться довольно свободно, обеспечивая максимальную экономию полосы пропускания для выполняющихся приложений.
Можно дополнительно оптимизировать загрузку сжатия, настроив уровень сжатия для достижения необходимого соотношения сжатия и загрузки ЦП. Но на этом все не заканчивается — также можно настроить приложение для поддержки кэширования сжатого содержимого, что устраняет загрузку сжатия на попадания в кэше благодаря работе с уже сжатым содержимым. Имейте в виду, что в кэши вывода ASP.NET и IIS включена дополнительная возможность кэширования сжатого содержимого для поддерживающих это клиентов, а также обработка запросов клиентов, для которых необходимо несжатое содержимое.

Регулировка полосы пропускания для мультимедийных файлов
С увеличением числа узлов, предоставляющих медиа-содержимое, затраты на полосу пропускания для многих организаций значительно возросли. Что еще хуже, теряется большая часть полосы пропускания мультимедиа из-за того, что отправленное клиенту медиа-содержимое никогда в действительности не используется. Почему это происходит?
Вспомните, когда вы последний раз смотрели интерактивное видео или видели видеорекламу при просмотре веб-узлов. Вы досмотрели видео до конца? Чаще всего пользователи, посещающие узлы с видео, просматривают только часть видео до того, как перейти к следующему или уйти с веб-страницы. Однако веб-сервер, использующий прогрессивную загрузку для предоставления видео, обычно отправляет гораздо больше данных, чем необходимо для этих нескольких секунд воспроизведения. Большая часть данных никогда не используется.
Если среднее время просмотра ваших видео составляет всего 5 секунд, но за это время предоставляются (буферизируются) видеоданные длительностью 30 секунд, скорее всего, вы теряете более 80 процентов полосы пропускания!
Год назад для разрешения этой проблемы для клиента, переходящего на бета-выпуск IIS 7.0, я написал модуль регулировки полосы пропускания, автоматически определяющий скорость видео и обеспечивающий предоставление сервером видео клиенту приблизительно с этой же скоростью. Группа мультимедиа IIS использовала этот модуль, называющийся модулем регулировки скорости (см. рис. 4) и доступный в центре загрузок iis.net (iis.net/downloads/?tabid=34&g=6&i=1640). Более подробно об этом можно узнать в блоге Скотта Гатри (Scott Guthrie) (доступен по адресу go.microsoft.com/fwlink/?LinkId=122514).
Рис. 4. Регулировки скорости уменьшает использование полосы пропускания (Щелкните изображение для его увеличения)
Модуль регулировки скорости автоматически определяет скорость кодирования наиболее популярных типов видео. Можно контролировать объем данных, предварительно отправляемых клиенту, для устранения начальных задержек на буферизацию (быстрый запуск) и процент скорости кодирования для предоставления содержимого. Также можно настраивать множество других параметров, таких как максимальная полоса пропускания и одновременные подключения, и управлять модулем программно.

Кэширование выводимых данных
Вообще говоря, кэширование – это лучший способ увеличения производительности приложений, выполняющих повторяющиеся операции. В отличие от улучшений производительности отдельных приложений, для чего часто требуется множество усилий и работа с затратами на обработку приложения, кэширование устраняет загрузку повторяющихся запросов для одного содержимого.
До IIS 7.0, как IIS, так и ASP.NET предоставляли возможности кэширования в форме кэша ядра IIS и кэша вывода ASP.NET. Кэш ядра IIS обеспечивал максимальную производительность, но ограничивался преимущественно статическим содержимым. Кэш вывода ASP.NET был гораздо более полным решением для кэширования динамического содержимого, за исключением более низкой производительности и менее эффективного управления памятью. Новый кэш вывода в IIS 7.0 ликвидирует разрыв между кэшем ядра IIS и кэшем вывода ASP.NET.
Кэш вывода IIS 7.0 обеспечивает возможность кэширования динамического содержимого из любого приложения, включая ASP, ASP.NET, PHP и любых других платформ приложений, совместимых с IIS 7.0. Предоставляя базовую поддержку изменчивости и срока действия содержимого, эта новая функция позволяет реализовывать кэширование для содержимого, которое не может кэшироваться кэшем ядра IIS. Кэш ядра по-прежнему может использоваться для содержимого, не соответствующего ограничениям.
Кроме того, кэш ядра IIS 7.0 также предоставляет высокопроизводительную альтернативу кэшу вывода ASP.NET для содержимого ASP.NET, не требующего дополнительных функций кэширования (таких как зависимости кэша и недействительность данных в кэше), которые доступны только в кэше вывода ASP.NET.
Что касается кэширования выводимых данных, обычно проблемы связаны с определением верных политик срока действия содержимого, недействительности данных и изменчивости, обеспечивающих эффективное кэширование ответов и одновременное поддержание необходимой правильности и свежести кэша. В большинстве случаев это можно выполнить путем простой настройки верных правил кэширования, хотя иногда требуются более сложные политики, зависящие от информации времени выполнения. Для решения этой проблемы кэш вывода IIS 7.0 предоставляет программные API, которые могут использоваться для обеспечения необходимого поведения кэширования. Это разблокирует потенциал эффективности кэширования для содержимого, кэширование которого в противном случае было бы невыгодным. Кроме того, интегрированный конвейер ASP.NET позволяет использовать кэш вывода ASP.NET для содержимого, не относящегося к ASP.NET.
Развертывание кэширования вывода для динамического содержимого может быть сложным и может требовать многоуровневой стратегии для использования преимуществ эффективности и гибкости различных функций кэширования на платформе IIS 7.0. Развертывание часто включает описание множества параметров, влияющих на ответ, и определение стратегий срока действия и недействительности для поддержания свежести кэша, а также последующее определение кэша, поддерживающего необходимую семантику.
Но выполнение этой сложной работы почти всегда оправдано. Реализация кэша вывода IIS 7.0 позволяет в несколько раз улучшить общую пропускную способность приложения и соответственно уменьшить нагрузку на базу данных и компоненты уровня предприятия.

Преобразование кода ISAPI в модули IIS 7.0
В IIS 7.0 появился новый серверный интерфейс API, на котором основаны все модули IIS 7.0. Он заменяет устаревшие интерфейсы API ISAPI Filter и ISAPI Extension, использовавшиеся в предыдущих версиях IIS. Для новых модулей, которым не требуется поддержка предыдущих версий, новые API более просты в использовании, позволяют улучшить надежность серверного кода и гораздо более эффективны.
Однако IIS 7.0 предоставляет возможность поддержки существующих фильтров и расширений ISAPI путем использования слоя совместимости, реализуемого посредством дополнительных модулей IIS 7.0. Это позволяет существующим компонентам ISAPI работать в IIS 7.0 без необходимости переписывания.
Хотя использование существующих вложений в ISAPI снижает планку для перехода на IIS 7.0, следует серьезно рассмотреть перенос устаревшего кода ISAPI на новые API IIS 7.0. Это устраняет затраты на слой совместимости ISAPI и позволяет использовать преимущества производительности, недоступные для компонентов ISAPI. В зависимости от работы, выполняемой компонентом ISAPI, эти преимущества производительности могут быть довольно значительными. Например, API модуля IIS 7.0 предоставляет встроенную поддержку кэширования метаданных конфигурации и других произвольных данных, связанных с узлами, приложениями, URL-адресами, что можно значительно увеличить скорость выполнения внутренних операций компонента.
Помимо этого, API модуля IIS позволяет модулям асинхронно выполнять длительные операции, такие как получение данных объекта запроса и отправка ответа. Асинхронное выполнение этих задач позволяет серверу масштабироваться до большого количества одновременно клиентов (десятки тысяч) вместо прежнего максимального количества в несколько десятков или самое большое нескольких сотен одновременных клиентов из-за ограничений количества потоков запросов. Асинхронная обработка также может устранить эффект обработки на других запросах и действиях в приложении, снизить загрузку памяти и обеспечить гораздо лучшее использование ЦП.
Помимо определенных шаблонов, влияющих на производительность, собственный интерфейс API предоставляет разработчикам большую гибкость работы с задачами обработки запросов. Это позволит улучшить архитектуру серверного компонента и, в свою очередь, повысить эффективность. Например, определенные задачи фильтрации, для которых ранее требовались расширения ISAPI с подстановочными символами и выполнение дочернего запроса, теперь могут быть выполнены в модуле во время исходного запроса, а также могут разрешить кэширование ядра IIS для ответа.
Для этого могут быть необходимы определенные эксперименты и прототипы для определения оптимальной архитектуры, наилучшим образом использующую улучшения перехода. Из-за фундаментальных архитектурных различий ISAPI и API модуля IIS 7.0 прямой маршрут переноса не всегда является верным. Хорошая новость заключается в том, что API модуля IIS 7.0 также более прост в использовании, чем ISAPI, что упрощает переход.

Расширяемость сервера
IIS 7.0 предоставляет сквозную расширяемость. Для этого требуются значительные заблаговременные знания работы сервера, но это также позволяет добиться значительного повышения производительности отдельных приложений. Понимание архитектуры сервера и обработки запроса позволяет использовать преимущества этой расширяемости для создания специальных эффективных решений, отвечающих вашим требованиям к приложениям, рабочей нагрузке и оборудованию.
Это может быть выполнено путем замены каких-либо встроенных функций IIS 7.0 пользовательскими реализациями. Хотя IIS 7.0 претерпели значительную оптимизацию и тестирование производительности, они, конечно же, не оптимизированы для всех возможных применений. Поэтому можно повысить производительность определенных модулей путем создания оптимизаций для конкретной рабочей нагрузки. Например, можно решить повторно реализовать модуль вывода каталогов для кэширования списков содержимого каталогов в памяти вместо использования интерфейсов API операционной системы для перечисления файлов.
Также расширяемость может использоваться для создания новых функций повышения производительности. Встроенные примеры таких функций включают кэш вывода, модули сжатия и несколько других внутренних кэшей.
Для того, чтобы определить, что пользовательская функция повышения производительности действительно необходима, нужно понимать характеристики производительности приложения и его рабочей нагрузки, а также знать ограничение, которое требуется устранить. IIS 7.0 предоставляет достаточную диагностическую поддержку для выполнения анализа, который помогает сделать требования и возможную архитектуру необходимых функций более ясными.

Заключение
Хотя выпуск IIS 7.0 в основном является функциональным, он предлагает заслуживающие внимания улучшения производительности, обусловленные его модульной архитектурой, настраиваемостью и новыми функциями производительности. Эти улучшения могут помочь добиться значительных экономических выгод через консолидацию серверов и уменьшения используемой полосы пропускания, а также повысить удобство работы пользователей.
Для верного использования множества этих улучшений часто необходимо выполнение тщательного анализа текущей платформы приложений и хорошие знания архитектуры IIS 7.0. Дополнительные сведения об архитектуре IIS 7.0 и упомянутых в этой статье функциях доступны на веб-узле iis.net. На веб-узле mvolo.com я буду вести блог о методах упреждающего использования IIS 7.0 для повышения производительности приложений и снижения эксплуатационных издержек.
Майк Володарский ранее являлся руководителем программы в группе IIS корпорации Майкрософт. Последние пять лет он руководил проектированием и разработкой основных функций ASP.NET 2.0 и IIS 7.0. Теперь он занимается созданием усовершенствованных технологий веб-серверов для высокопроизводительных веб-ферм, использующих IIS 7.0 и Windows Server 2008. Майк является ведущим автором книги IIS 7.0 Resource Kit и часто пишет для журнала MSDN Magazine и в своем блоге по IIS 7.0, mvolo.com.


Мобильность
Сделайте бизнес-приложения мобильными
Мэтт Фонтейн (Matt Fontaine)
Кратко
  • Бизнес нуждается в мобильных бизнес-приложениях
  • Надежная платформа для развития и развертывания мобильных бизнес-приложений
  • Безопасность беспроводных сетей, управление ими и их подготовка

Cодержание
Обеспечение удаленной работы и управление удаленными работниками
Управление безопасностью и устройствами
Возможности взаимодействия
Производительность отделов ИТ и пользователей
Разработка и распространение приложений
Последняя строка
Кроме традиционных функций передачи звуков, сообщений и улучшения производительности, сегодня в деловой практике желательно, чтобы мобильные работники имели доступ к тем же бизнес-системам (LOB), который они используют
в офисе посредством мобильных бизнес-приложений (mLOB). В число систем, мобильность которых следует обеспечить, обычно входят системы для управления отношениями с клиентами (CRM), планирования ресурсов предприятия (ERP), информационного обеспечения принятия решений (BI), финансовые и бухгалтерские приложения. Очевидно, наличие функциональности мобильных бизнес-приложений дает возможность мобильным пользователям получать доступ к ним и использовать их, оперировать данными в мобильном режиме в реальном времени, таким образом сокращая время продажи, улучшая качество обслуживания покупателей и увеличивая производительность бизнеса. В число некоторых типичные деловые ситуаций, например, могут входить следующие ниже.
  • Отделы продаж могут использовать Microsoft Dynamics™ CRM Mobile для просмотра и обновления данных пользователя из любого места. Другое мобильное бизнес-приложение может дать им доступ к информации в реальном времени о ценах и состоянии склада. Затем продавцы могли бы использовать специализированные устройства для комплектования документации для заказов на выезде – от заполнения заказов до получения подписей. Фактически, есть даже приложения для кассы для устройств Windows Mobile®, которые могут считывать штрих-коды и принимать кредитные карты, а затем взаимодействовать с серверными бизнес-системами данных для обработки информации.
  • Работа выездных работников может быть спланирована прии помощи решений ERP, которые определяют маршрут персонала при помощи сведений о назначенных встречах и нахождении работников, а расположение работников можно автоматически отследить при помощи устройств Windows Mobile с поддержкой GPS. Выездные работники берут только первое дневное задание и по его завершении автоматически направляются на следующее (см. рис. 1).
  • В производственных предприятиях устройства Windows Mobile с возможностью считывания меток радиочастотной идентификации (RFID) могут быть использованы для управления учетом на складе, оснащенном RFID, мгновенно и без физического контакта размещая информацию в базе данных. Более того, существуют устройства Windows Mobile, которые усилены или спроектированы для работы в экстремальных условиях для опасной рабочей среды для доставки данных в нужное место, при этом удовлетворяя важным требованиям безопасности труда.
  • Мобильные директора, переходящие от переговоров с клиентами к совещанию дирекции, для уплотнения графика рабочего дня (возможно вдали от основного офиса), где бы ни случилось им находиться, могут получать финансовые отчеты, сведения о затратах или информацию о покупателе.
Эти и другие деловые сценарии приводят передовые компании к использованию mLOB приложений. В данной статье будет показано, как Windows Mobile и Mobile Device Manager работают вместе, таким образом давая отделам ИТ возможность для развертывания насыщенной мобильной функциональности, которая все больше нужна современному бизнесу.
Рис. 1 Мобильное бизнес-приложение, показывающее выполненную выездную ремонтную работу

Организация удаленной работы и управление удаленными работниками
Windows Mobile показала себя многосторонней платформой для организации удаленной работы в разных отраслях промышленности, потому что она хорошо работает с существующими, основанными на Windows® информационными активами; ее мобильный обмен сообщениями и универсальная связь (UC) обеспечиваются Exchange Server и Office Communications Server. Как пользователи, так и специалисты по ИТ одинаково работают со знакомым интерфейсом Windows, что приводит к снижению объема необходимого обучения для ознакомления и использования. Политики и программное обеспечение могут быть автоматичски переданы на телефоны. Политиками безопасности, программным обеспечением и оборудованием можно управлять очень избирательно при помощи широкого набора возможностей инвентаризации и отчетности.
Движущая сила этих новинок — идея о том, что мобильным устройствам лучше быть естественным расширением систем ИТ, чем существовать в своем замкнутом мире промежуточного оборудования. Для компаний, желающих существенно выйти за пределы уровня обмена сообщениями, связи и базовой функциональности на устройствах Windows Mobile, важнейшей задачей является создание из мобильных устройств полноправных членов сети.
А что если и вы работаете в одной тех организаций, которые хотят выйти за пределы обыденности? Давайте взглянем на то, как это становится возможным благодаря свойствам Windows Mobile и Mobile Device Manager, поскольку они предоставляют обширную платформу для мобильных бизнес-приложений.

Управление безопасностью и устройствами
Именно возможности, которые делают привлекательными мобильные бизнес-приложения (предоставление доступа к важнейшей бизнес-информации о покупателях, финансах, складских запасах и т.д. независимо от времени и места), также делают задачи безопасности более серьезными. Пользователи вводят информацию и получают доступ к ней небольших устройств через общедоступную сеть в различных местах.
Множество компаний уже включили мобильный доступ к бизнес-приложениям, а также к другим совместно используемым ресурсам и средствам в интрасетях посредством переносных компьютеров, подключенных через виртуальную частную сеть (VPN). Mobile Device Manager расширяет эту функциональность для устройств Windows Mobile при помощи мобильной сети VPN (Mobile VPN) (см. рис. 2). В сервере шлюза Mobile Device Manager есть зашифрованый по IPsec туннель между клиентом Windows Mobile и сетью, предоставляющий безопасный доступ к информации за корпоративным брандмауэром через общедоступные подключения, такие как Интернет или беспроводные пакетные сети передачи данных. Windows Mobile поддерживает различные типы шифрования в этой настройке.
Рис 2. Улучшение управления устройством, безопасности и предоставление мобильной сети VPN при помощи Mobile Device Manager (Щелкните изображение, чтобы увеличить его)

Возможности взаимодействия
Для данных на устройствах и картах памяти могут быть установлены и введены в действие политики шифрования. Работники, использующие мобильные бизнес-приложения, должны загружать конфиденциальную информацию в свои переносные устройства, которые очень легко теряются по сравнению с другими сетевыми устройствами. К счастью, очистка удаленного устройства может быть осуществлена для любого устройства, полключенного к мобильной сети VPN с установленным подключением (см. рис. 3). Если продавец в аптеке, например, загрузит файлы пользователя из системы CRM компании в мобильное устройство и затем нечаянно оставит его в такси, последствия могут быть очень серьезными.
Рис. 3 Если мобильное устройство потеряно или украдено, информация на нем может быть стерта удаленно. (Щелкните изображение, чтобы увеличить его)
Mobile Device Manager спроектирован для того, чтобы разрешать такие проблемы. Фактически, Mobile Device Manager позволяет управлять почти любым аспектом функциональности устройства Windows Mobile и пользовательской политикой от выключения отдельных свойств оборудования до определения, какие приложения могут быть установлены для ограничения доступа к определенным сетевым ресурсам. Всё это может быть сделано из одного решения, и всё из этого может быть сделано по беспроводной связи. Когда пользователи имеют возможность работы с мобильными бизнес-приложениями, эти возможности становятся даже более важными Например, может потребоваться запретить пользователям использовать сеть Bluetooth, которая может позволить выгрузку данных в неконтролируемые приборы. Может потребоваться, чтобы только определенные пользователи имели возможность установить мобильный клиент бухгалтерского программного обеспечения так, чтобы установка его для выгрузки и установки автоматически были разрешены только тем пользоватеям, кто в этом нуждается.
Дополнительные материалы
  • Microsoft System Center Mobile Device Manager 2008
  • Представляем Microsoft System Center Mobile Device Manager 2008
  • Microsoft System Center Mobile Device Manager 2008: Технический официальный документ
  • Microsoft System Center Mobile Device Manager 2008: Введение для деловой аудитории
  • Line of Business Solution Accelerator 2008 для Windows Mobile
Более того, Mobile Device Manager не требует передачи корпоративных данных через центр сетевых операций (NOC) стороннего производителя, который может представлять другую возможную точку доступа или уязвимости безопасности. По существу дела, Mobile Device Manager дает полный контроль над развертываниями мобильных устройств почти в любых масштабах — контроль, облегчающий развертывание, управление и защиту функциональности мобильных бизнес-приложений.
Сетевая интеграция дает и другое преимущество: весь этот хорошо структурированный контроль дополняется средствами Active Directory и групповыми политиками без необходимости управления мобильными устройствами отдельно от других клиентов сети. Это сохраняет деньги и время. Однако, что более важно, это позволяет использовать согласованные защиту и политики доступа. Групповая политика — очень эффективный способ контролировать мобильный доступ к бизнес-данным. Те, кому нужен доступ, могут легко его получить; те, кому он не нужен, могут быть ограничены «в массе» или индивидуально.
Другой большой вклад в управление развертываниями мобильных бизнес-приложений (и в общем случае всеми мобильными устройствами) — возможность взаимодействия с существующей инфраструктурой. В отличие от Windows Mobile, некоторые операционные системы мобильных устройств не связаны с другими формами ИТ, а требуют собственные языки, серверы и средства. Эти факторы становятся все более важными, когда предоставляется доступ к сложным приложениям и важным данным на мобильных устройствах.
Windows Mobile и Mobile Device Manager предоставляют такую возможность взаимодействия. Как и ОС Windows, Windows Mobile хорошо работает с другими основанными на Windows информационными продуктами, такими как Microsoft® Exchange Server, Microsoft Forefront™, SQL Server® и Microsoft Office Communications Server. Эта возможность взаимодействия между линиями продуктов облегчает проектирование и создание передовой мобильной бизнес-функциональности.
Например, Windows Communication Foundation (WCF), технология Microsoft .NET Framework для обеспечения взаимодействия между приложениями, может подключить Exchange Server для использования в качестве средства передачи сообщений для реализаций мобильных бизнес-приложений, используя архитектуру, ориентированную на службы (SOA). Редко подключающиеся рабоитники могут продолжить использование новой платформы синхронизации. Это облегчает синхронизацию данных между устройствами Windows Mobile, на которых используется SQL Server Compact 3.5, и корпоративными данными в SQL Server 2008. Эти случаи могли бы быть более сложными для реализации без мобильной инфраструктуры, которая работает с огромным множеством сетевых ресурсов без дополнительной настройки.

Производительность отделов ИТ и пользователей
Увеличение производительности — важная цель развертываний мобильных бизнес-приложений. Но если эти возможности трудны для использования работниками и для управления сотрудниками отделов ИТ, то затраты на это могут превысить или, как минимум, снизить окупаемость вложений (ROI). Целью развертывания Windows Mobile является сделать интерфейс пользователя настолько похожим на Windows на настольных ПК, насколько возможно; полученный знакомый интерфейс может повысить ценность этого решения для всех участников.
Со стороны отделов ИТ Windows Mobile (если использовать Mobile Device Manager) спроектирована для охвата устройств Windows Mobile в основным руслом сети. Это происходит благодаря задействованию знакомой технологии, в частности, Active Directory и Windows Server®. Mobile Device Manager — часть семейства решений System Center по управлению ИТ, используемых большим количеством специалистов по ИТ в мире. Вместо необходимости обучению совершенно новому множеству средств и методов работы, сотрудники отделов ИТ, знакомые с основанной на Windows средой, могут использовать оснастки для уже известной им консоли управления Microsoft.
Это справедливо и для пользователей. Интерфейс пользователя Windows Mobile, аналогичный настольному ПК, поможет им быстро войти курс дела. Они могут использовать набор Office Mobile, в который входит Office Mobile Outlook®, для работы без обучения новым приложениям. Им не нужно беспокоиться об управлении устройствами, так как это делается централизованно. Мобильные бизнес-приложения могут быть спроектированы для работы способами, знакомыми пользователям настольных версий этих же программ; новые средства могут быть сделаны так, чтобы выглядеть и вести себя как типичное программное обеспечение для Windows. Эта похожесть вида может привести к снижению числа звонков в службу поддержки и снижению серьезности происшествий, что также является благом для сотрудников ИТ.
Другие аспекты платформ Windows Mobile и Mobile Device Manager также увеличивают производительность. Мобильная сеть VPN предоставляет беспроблемную и постоянную связь, даже проходя через несколько сетей, дополнительно к функциональности быстрого восстановления подключения, позволяя пользователям подключаться, когда им нужно, и сокращая число других общих причин звонков в службу поддержки. Различные габаритные размеры устройств, поддерживаемых Windows Mobile, позволяют компаниям стандартизовать небольшое количество устройств, при этом сохраняя сотрудникам возможность выбора устройств, удовлетворяющих их запросам. Разнообразие устройств также учитывает такие случаи улучшенной производительности мобильных бизнес-приложений, как управление инвентаризацией склада на основе штрих-кодов или выбор маршрута с помощью устройств, оснащенных GPS.

Разработка и распространение приложений
Признаки, определяющие мобильные бизнес-приложения (насыщенность данными, многофункциональность и специализированная функциональность), лучше проявляются на мобильной платформе, спроектированной для улучшения производительности конкретных приложений. Windows Mobile предоставляет для мобильных работников интерфейс пользователя, подобный настольному компьютеру, облегчая разработку мобильных бизнес-приложений, распространение их и управление ими.
Начнем с того, что Windows Mobile поддерживает версию.NET, называемую «Платформа .NET Compact». Так как платформа .NET — набор программных средств, используемый миллионами производителей в мире, множество работников отделов ИТ уже имеют собственные навыки разработки, необходимые для персонализации и создания мобильных бизнес-приложений для Windows Mobile. Если таких навыков пока нет, они доступны на рынке.
Windows Mobile также поддерживает большое количество коммерчески доступных мобильных бизнес-приложений. Корпорация Майкрософт предлагает мобильные бизнес-решения как часть своей линейки продуктов Microsoft Dynamics, включающей Microsoft Dynamics CRM Mobile и Microsoft Dynamics AX Mobile Sales. Кроме того, средства разработки Microsoft Dynamics предоставляют разработчикам технологии расширения их программного обеспечения на мобильную среду. Корпорация Майкрософт дала обязательство сделать мобильными другие решения Microsoft Dynamics, а поддержка Microsoft Dynamics NAV уже скоро появится. И большинство основных бизнес-решений, таких как SAP, Siebel, PeopleSoft и SalesForce.com, предоставляют версии своих пакетов приложений, совместимые с Windows Mobile.
Будучи раз купленными или разработанными, мобильные бизнес-приложения могут распространяться и управляться по беспроводным сетям при помощи Mobile Device Manager и Windows Server Update Services 3.0. Групповая политика может быть использована для определения того, какие устройства получат приложения и к каким функциям у них будет доступ. Заметим, что обновления приложений могут быть осуществлены тем же простым способом.

Последнняя строка
Растущее число компаний предоставляет мобильные бизнес-приложения для сотрудников и администрации, добавляя новые ограничения для тех, кто занят развертыванием и поддержанием информационных систем. Windows Mobile и Mobile Device Manager дают перспективный взгляд на мобильные устройства, пригодные для работы в сети, предоставляя легко управляемую платформу для развития и развертывания мобильных бизнес-приложений. Эта платформа позволяет достичь наибольшей безопасности и производительности пользователя при сведении к минимуму головной боли отделов ИТ и издержек на инфраструктуру. И, поскольку Mobile Device Manager позволяет масштабировать развертывания мобильных бизнес-приложений большему количеству пользователей, приходящая на одного пользователя стоимость развития и развертывания мобильных бизнес-приложений снижается, в то время как окупаемость — увеличивается. Таким образом, легкость управления Windows Mobile при помощи Mobile Device Manager дает время на творчески поразмыслить о том, как мобильные бизнес-приложения могут быть использовны наиболее эффективно, вместо того, чтобы в первую очередь думать о том, как заставить их работать.

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


Безопасность
Общие сведения об управлении паролями общих учетных записей
Крис Стонеф (Chris Stoneff)
Кратко
  • Угрозы паролей общих и привилегированных учетных записей
  • Сохранение паролей
  • Управление общими паролями и обеспечение их безопасности
  • Соответствие нормативным требованиям

Cодержание
Знакомство с задачей
Чем длиннее, тем лучше
Насилие домена
Извинения, извинения, извинения
Требования нормативных инстанций
Автоматизированный подход
Подумайте об этом
Одним из действий, которое все чаще приходится выполнять администраторам, является регулярное изменение пароля для общих и привилегированных учетных записей, таких как встроенная
учетная запись администратора или учетная запись пользователя root, учетная запись аварийного доступа, возможно, даже учетная запись процесса. Встроенную учетную запись администратора или пользователя root можно определить как учетную запись, существующую во всех версиях Windows®, Linux и UNIX, которая всегда имеет один идентификатор безопасности или пользователя. Учетные записи аварийного доступа создаются для упрощения осуществления аварийного доступа к защищенной системе. Эти учетные записи аварийного доступа или администратора иногда используются другими непривилегированными пользователями для получения доступа к ключевым системам в случае возникновения проблем. Наконец, учетные записи процессов – это учетные записи, используемые для выполнения служб, задач, приложений COM+ и внедренных элементов, таких как сценарии и другие двоичные файлы, для которых необходим вход в систему.
Сейчас вы, вероятно, выполняете развертывание систем с помощью сценариев установки или образов. Кроме того, возможно, на всех ваших рабочих станциях или серверах есть учетная запись администратора с одним и тем же именем и восьмизначный пароль, который, скорей всего, не менялся после первоначального развертывания систем. Поэтому вместо термина «пароли» я использую термин «пароль» в единственном числе.
Администратор может быть вынужден сменить эти пароли в соответствие с используемыми рекомендациями или техническими требованиями, например, установленными законом Сарбейнса-Оксли (SOX), стандартом Payment Card Industry (PCI) или актом HIPAA (акт по обеспечению переносимости и возможности учета в системах для страхования в области здравоохранения). Иногда действия администратора обусловлены увольнением из компании бывшего администратора или технического специалиста, знающего пароли, опасностью разглашения брешей в системе безопасности или утратой возможности работы с кредитными картами. Несмотря на эти факторы, все сводится к тому, что администратору приходится изменять эти пароли по простой причине обеспечения безопасности компании и данных, которые должна защищать компания.

Знакомство с задачей
При работе с этими учетными данными и паролями для них необходимо знать несколько факторов.
  1. Чем старее становятся пароли, тем менее они безопасны.
  2. Как правило, более длинные пароли труднее взламывать.
  3. Способ проверки подлинности компьютеров не меняется только потому, что они принадлежат к домену. В каждом домене заключена основа рабочей группы.
Утверждение «чем старее становятся пароли, тем менее они безопасны» вводит в заблуждение. Оно означает только то, что для взлома компьютера необходимо только время. На вопрос: «Сколько времени занимает взлом пароля?» я обычно отвечаю, что определенный ответ отсутствует, и даю советы, помогающие получить ответ для определенной системы:
  • Как много людей знают пароль?
  • Работают ли все эти люди по-прежнему в компании?
  • Если кто-либо из людей, знающих пароль для учетной записи, больше не работает в компании, покинул ли он компанию в дружественной обстановке?
  • Запретили ли вы возможность загрузки с дискеты, устройства чтения компакт-дисков или дисков DVD или из сети?
  • Являются ли пользователи компьютеров также и локальными администраторами?
  • Используется ли во всех ваших системах одинаковый пароль для привилегированных учетных записей?
Начиная сверху списка, можно с уверенностью сказать, что чем большему количеству людей известен секрет, тем выше вероятность разглашения этого секрета. Я работал в компаниях, администраторы которых считали более удобным установить один общий пароль и сообщить его специалистам по ИТ и их помощникам, вместо того чтобы, как требуется, вводить за них пароли. Конечно, с течением времени на компьютерах стали появляться различные неутвержденные параметры, а эти учетные данные стали доступными обычным пользователям сети.
Если все люди, которым известен пароль, по-прежнему работают в компании и являются надежными и исполнительными сотрудниками, эта опасность доступа немного уменьшается. Но никогда не известно, когда придется иметь дело со злоумышленным пользователем. Если какие-либо из этих пользователей покидают компанию и остаются с ней в плохих отношениях, они становятся свободными враждебными элементами, которым известно, как получить доступ к сети с помощью неотслеживаемой учетной записи.
При отсутствии запрета на загрузку с устройств, отличных от жесткого диска, вы также позволяете пользователям выполнять загрузку с несанкционированных образов, таких как Windows PE или различные системы Linux, которые могут выполнять чтение напрямую из файловой системы компьютера и получать доступ к защищенному хранилищу компьютера. (Следует отменить, что причиной множества брешей системы безопасности являются внутренние элементы. Даже если все сотрудники и их помощники по-прежнему работают в компании, защиту паролей и систем обеспечить невозможно.)
Я знаю много людей, продолжавших входить в сеть бывшего работодателя только потому, что у них была такая возможность. Довольно смешно, что они просто замечали неверный подход – оставлять системные пароли неизменными, – но ущерб, который они могут нанести при наличии злоумышленных намерений, может быть пугающим.
При разрешении возможности загрузки с устройства чтения дисков DVD или через сеть наблюдение за действиями пользователей может стать невозможным, то есть загрузочный диск Linux или сетевой образ часто позволяет получить доступ непосредственно к файловой системе. Если в ваших системах используются одинаковые имена пользователей и пароли для привилегированных учетных записей, настройка систем делает возможной серьезную компрометацию. Однако это будет рассматриваться немного позднее.
Верные срок действия и длина пароля определяются в зависимости от способов взлома пароля. Если для определения паролей используется подбор, все сводится только ко времени. Чем реже меняется пароль, тем больше времени дано злоумышленнику для получения пароля.
Более длинные пароли имеют экспоненциально большее количество вариантов сочетаний символов, и поэтому для их взлома требуется больше времени. Поэтому важно учитывать, составляет ли длина паролей менее 7 символов, от 8 до 14 символов или более 15 символов. И, если длина паролей менее 15 символов и используется операционная система Windows, отключено ли хеширование LAN Manager (LM) в качестве части процесса настройки системы или в результате применения групповой политики?
Как длина пароля влияет на что-либо? В случае Windows ответ простой. Помимо журнала процессов хеширования корпорация Майкрософт реализует два типа хеш-кодов для паролей, хеш-коды LM и хеш-коды MD4. По умолчанию Майкрософт использует хеш-коды LM, а значения сохраняются для всех паролей длиной до 14 символов, если хранение этих хеш-кодов не отключено намеренно. Эти пароли разделены на два семизначных значения — первое значение для первых 7 символов, а второе значение для вторых 7 символов, как показано на рис. 1.
Рис. 1. Пример таблицы хеш-кодов
Имя учетной записи | Идентификатор RID | Хеш-код LM | Хеш-код NT | Пароль | Примечания
Администратор | 500 | aad3b435b51404ee: aad3b435b51404ee | 31d6cfe0d16ae931: b73c59d7e0c089c0 | Пустой пароль | Хеш-код LM идентичен хеш-коду LM 20-символьного пароля.
Администратор | 500 | 0182bd0bd4444bf8: aad3b435b51404ee | 328727b81ca05805: a68ef26acb252039 | 7-символьный пароль = 1234567 | Первая часть, представляющая первые 7 символов, идентична 8-символьному паролю.
Администратор | 500 | 0182bd0bd4444bf8: 36077a718ccdf409 | 0182bd0bd4444bf8: 36077a718ccdf409 | 8-символьный пароль = 12345678 | Первая часть, представляющая первые 7 символов, идентична 8-символьному паролю, но вторая часть отличается.
Администратор | 500 | aad3b435b51404ee: aad3b435b51404ee | b79d07c2ecb3d565: 033ece663f5a0b2e | 20-символьный пароль = 9876543210 9876543210 | Хеш-код LM идентичен пустому паролю, поскольку хеш-код LM не может быть создан для паролей, длина которых превышает 14 символов.
Сергей | 1221 | e52cac67419a9a: 224a3b108f3fa6cb6d | 8846f7eaee8fb117: ad06bdd830b7586c | Identical | Вам понятно, почему хеш-коды LM и NT в этих трех примерах идентичны? Это означает, что все пароли для всех этих учетных записей идентичны. Корпорация Майкрософт никогда не меняла алгоритм хеширования.
Понедельник | 1385 | e52cac67419a9a: 224a3b108f3fa6cb6d | 8846f7eaee8fb117: ad06bdd830b7586c | Identical
SvcAcctX | 1314 | e52cac67419a9a: 224a3b108f3fa6cb6d | 8846f7eaee8fb117: ad06bdd830b7586c | Identical
Таким образом, если длина вашего пароля всего 7 символов, он будет находиться в одном хеш-коде LM. Многие годы корпорация Майкрософт рекомендовала использовать пароли длиной минимум 8 символов. Причина состояла в том, что в этих случаях восьмой символ делает обязательным разделение пароля на два значения хеш-кода LM.
Однако важно отметить, что хеш-коды LM хорошо всем знакомы и очень просты для обхода. Их единственная цель в текущих решениях состоит в обеспечении обратной совместимости с системами нижнего уровня, такими как Windows NT® 4.0.
Сейчас вы должны использовать пароли (в действительности кодовые фразы) длиной не менее 15 символов или даже больше, поскольку для них по определению не создается хеш-кодов LM. Если обязательное использование 15-символьных паролей невозможно в вашей среде, необходимо отключить хранение хеш-кодов LM как в процессе создания образа (с помощью локальной политики), так и в групповой политике Active Directory®.
Эта политика доступна в разделе «Конфигурация компьютера\Конфигурация Windows\Параметры безопасности\Локальные политики\Параметры безопасности». Просто установите для политики «Сетевая безопасность: не хранить хэш-значения LAN Manager при следующей смене пароля» значение «Включено».
Важно помнить, что, хотя хорошая политика определяет использование строчных и прописных букв, а также цифр и специальных символов, лучшая политика также определяет длину в 15 или более символов.

Чем длиннее, тем лучше
Одним из используемых сейчас способов взлома компьютеров являются атаки Rainbow Table, использующие хеш-коды LM как уязвимости. Но более длинные пароли могут снизить эффективность атак Rainbow Table.
Я поражен, как много администраторов, занимающихся обеспечением безопасности, по-видимому, мало знакомы (или совсем незнакомы) с атаками Rainbow Table. Существуют различные способы создания атак Rainbow Table для различных алгоритмов. А они являются всего лишь предварительно вычисленным списком всех хеш-кодов LM из 0-14 символов.
Ограничением атак Rainbow Table является то, что злоумышленник должен в первую очередь получить хеш-коды LM. Это приводит к предыдущим вопросам о способах загрузки системы (с устройства чтения компакт-дисков или дисков DVD) и о том, являются ли пользователи локальными администраторами. В конечном счете, эти хеш-коды LM могут быть извлечены за несколько секунд с помощью бесплатных средств, например pwdump. Атаки Rainbow Table часто используются для поиска хеш-кодов, необходимых для определения пароля.
Чтобы удовлетворить мое любопытство, я установил пароль для встроенной учетной записи администратора системы. Пароль был длиной 14 символов и содержал различные строчные и прописные буквы, а также специальные символы и цифры. Затем я воспользовался бесплатно загруженной из Интернета программой для Rainbow Table и смог получить хеш-коды паролей для всех учетных записей в моей системе, а пароль администратора был определен менее, чем за две минуты.
Должен признать, здорово наблюдать за тем, как получается первый хеш-код LM, потом второй хеш-код, после чего они объединяются для получения пароля.. Повторю, что если бы я отключил мои хеш-коды LM с помощью обсуждавшейся ранее политики, это направление атаки было бы серьезно ограничено, если не полностью заблокировано.

Насилие домена
Нахождение в домене не устраняет проблему. Проверка подлинности компьютеров в домене по-прежнему происходит таким же образом. И, как я уже сказал, в каждом домене заключена основа рабочей группы. Это простое утверждение не всегда очевидно. Я много обсуждал эту тему с другими специалистами и обнаружил, что часто напоминаю администраторам о том, что необходимо для доступа к компьютеру – имя пользователя и пароль. После этого я должен перейти к рассмотрению работы Windows в рабочей группе.
Для получения доступа к системе необходимо предоставить удаленной системе имя пользователя и пароль. При использовании интегрированной проверки подлинности система Windows сделает попытку выполнить это для вас. Это означает, что при доступе к другой системе Windows операционная система будет использовать имя пользователя и пароль текущего сеанса. Поэтому при попытке доступа к другой системе Windows запрос на ввод имени пользователя и пароля не появляется, если удаленная система имеет идентичные учетные данные.
Это также называется сквозной проверкой подлинности. Этот процесс выполняется в рабочих группах и между доменами. В худшем случае система выдаст запрос на ввод имени пользователя и пароля, что означает, что необходимо просто еще раз ввести сведения о входе в систему.
Теперь даже при присоединении рабочей станции или сервера к домену и после того, как служба Active Directory станет центральным хранилищем учетных записей, все локальные диспетчеры учетных записей безопасности (SAM) или локальные хранилища учетных записей не исчезают волшебным образом. Единственное, что происходит с этими локальными диспетчерами учетных записей безопасности, – это то, что они более не считаются защищенными и управляемыми, в чем и кроется проблема. Как вы в последний раз изменяли встроенную учетную запись администратора или пользователя root на ваших системах? А еще лучше загрузить какую-либо программу для работы с отчетами, которая может показывать срок действия паролей для всех учетных записей, а также то, пройдут ли результаты аудит.
Если вы все еще не очень понимаете, что я имею в виду, войдите на какую-либо из ваших рабочих станций, входящих в домен, с учетной записью домена с правами администратора. Откройте окно «Управление компьютером» системы и создайте локального пользователя ToldYouSo. Установите пароль для учетной записи и добавьте ее в локальную группу администраторов системы. Повторите этот процесс на другой системе домена.
Теперь войдите в какую-либо из этих двух систем с локальной учетной записью ToldYouSo и попытайтесь получить доступ ко второму компьютеру, перейдя по адресу \\systemName\c$. Вы получите доступ к административному общему ресурсу даже без запроса системы на ввод пароля! Надеюсь, это вас не удивляет. Но если это сюрприз для вас, запомните это и позвольте мне повторить: только то обстоятельство, что система принадлежит домену, не меняет факт, что все эти системы по-прежнему работают так, как будто принадлежит рабочей группе.
Суть в том, что при использовании для общих и привилегированных учетных записей редко меняемых, если вообще меняемых, паролей общие и привилегированные учетные записи находятся в опасности. Для компрометации всей вашей сети необходимо только время.

Извинения, извинения, извинения
Когда я разговариваю с администраторами или даже руководителями подразделений ИТ, то часто слышу одинаковые причины не менять пароли этих учетных записей:
  • У нас тысячи систем и недостаточно времени или человеческих ресурсов для изменения этих учетных записей.
  • Отсутствуют необходимые средства.
  • Учетные записи администраторов полностью отключены.
  • Утечки данных пока нет, и поэтому мы не думаем, что это проблема.
  • Аудиторы не замечают этого.
Хотя я и могу понять первые две причины, они не являются уважительными. Я с содроганием думаю, что моя личная информация может храниться в компаниях, которые по каким-либо причинам не разрешают эту проблему.
Хотя конфиденциальные данные хранятся не во всех системах в вашей сети, пользователи этих систем потенциально могут получить доступ к подобным данным, таким как номер страховки, медицинские заключения или финансовые данные. Являясь администратором системы, пользователь может установить программы регистрации нажатия клавиш и записи изображения, остановить применение групповой политики, ввести «прослойки» в различные подсистемы для записи и передачи данных и т.д. И при выполнении пользователем этих действий на уровне отдельного компьютера ваша возможность нахождения злоумышленника значительно усложняется, поскольку он называется «Администратор».
Знали ли вы, что отключение встроенной учетной записи администратора в Windows не ведет к потере возможности входа в систему с этой учетной записью? Попробуйте следующее: перезапустите систему в безопасном режиме и войдите в нее со встроенной учетной записью администратора. Вероятно, можно успешно использовать пароль, выданный учетной записи исходным образом. Дополнительные сведения об этом поведении см. в статье «Как получить доступ к компьютеру после отключения учетной записи администратора» базы знаний Microsoft® (support.microsoft.com/kb/814777).

Требования нормативных органов
Удовлетворение требований SOX, PCI, HIPAA и других нормативных актов может поставить вас в тупик. Требования могут быть довольно трудными для понимания, поскольку они обширны и четко не определены. Как правило, все эти требования можно свести к следующему.
Прежде всего, необходимо определить лиц, имеющих постоянный доступ ко всем привилегированным учетным записям и информации, и предоставить метод проверки. Это удачное поведение во всех случаях: привилегированная учетная запись – это учетная запись с правами на выполнение любых действий в системе. Это встроенная учетная запись администратора. Это учетная запись аварийного входа. Эти учетные записи, вероятно, известны всем сотрудникам службы поддержки и администраторам.
При реализации решения для управления этими паролями общих учетных записей создается журнал аудита для встроенной учетной записи администратора, в которой он в этот момент отсутствует. Вы получаете изменяемый пароль. А поскольку решение автоматизированное, вам не придется тратить целые недели на изменение этих паролей. В конечном счете, поскольку решение предоставляет возможности аудита, это упрощает для компании успешное прохождение проверки.

Автоматизированный подход
Наиболее эффективный способ работы с подобными учетными записями состоит в их регулярном изменении, чтобы для двух учетных записей никогда не использовался один пароль. При использовании общих паролей компрометация одной системы означает и компрометацию другой. Другими словами, не должно использоваться общие локальные учетные записи или учетные записи домена.
При использовании автоматизированных решений с возможностями управления и рандомизации этих паролей не следует выполнять только минимальные требуемые аудиторами действия. Например, зачем использовать для паролей всего 8 символов, когда можно использовать 15, 20 или 127, не затрачивая дополнительных усилий (см. рис. 2)?
Рис. 2. Автоматическое создание очень длинных паролей (Щелкните изображение, чтобы увеличить его)
Кроме того, стоит рандомизировать привилегированные учетные записи каждый день, как показано на рис. 3. Нет причин делать это только каждые 90 дней, когда эту процедуру можно выполнять один или два раза в месяц или даже ежедневно. В конце концов, если процедура автоматизирована, она не требует от вас никакой дополнительной работы. Кроме того, регулярное выполнение этой процедуры принуждает пользователей к восстановлению паролей через интерфейс получения аудита служебной программы, предоставляя другой журнал аудита, если его еще не было. (Если в настоящий момент вы храните записанные пароли в конверте, находящемся в безопасном месте в чьем-нибудь офисе, у вас отсутствует журнал аудита для этих паролей, который существовал бы при использовании решения управления паролями.)
Рис. 3. Ежедневная рандомизация привилегированных учетных записей (Щелкните изображение, чтобы увеличить его)
Наконец, необходимо гарантировать, что по истечении определенного периода времени после восстановления паролей выполняется их повторная рандомизация. Я имею в виду не созданные вами запланированные задания рандомизации, а создание одноразовых паролей со сроком действия всего в несколько часов, а не месяцев. Опять же, этот метод принуждает пользователей к восстановлению паролей через интерфейс получения аудита служебной программы, предоставляя журнал аудита.

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

Крис Стонев — менеджер по продуктам в компании Lieberman Software (liebsoft.com), разработчик программ в области безопасности и управления системами. В работе он руководствуется желанием понять не только как именно что-то работает определенным образом, но и почему.


В последние несколько недель мне сопутствовала удача, и я посетил повторный курс о том, что значить был специалистом по ИТ. Время, когда лето заканчивается, а мысли обращены к предстоящему учебному году, определенно очень подходит для такого курса. Но, тем не менее, должен признать, что я был немного шокирован.
Дело в том, что команда журнала корпорации Майкрософт (группа, ответственная за публикацию журналов MSDN Magazine и TechNet Magazine) занимается проверкой и улучшением нашего … успешной … работы. Мы наконец-то решили, что, поскольку на дворе все-таки 2008 год, нам необходимо избавиться от оставшихся бумажных макетов и пометок цветными карандашами и полностью перейти на цифровые технологии. (Знаю, знаю — мы невероятные новаторы!) Если серьезно, настала пора проанализировать некоторые из средств повышения производительности, навязываемые крупными разработчиками программного обеспечения.
Пока мы привыкали к новому цифровому рабочему процессу, быстро стало очевидным, что нас сдерживает средство, отслеживающее состояние статей. Оно уже было «цифровым», но было основано на довольно старой технологии (которая, мы надеемся, окончательно покинет наш мир) и дополнялось небольшими цветными окнами, напечатанными сверху каждого слоя. Высокие технологии, да? Итак, я приступил к созданию экспериментальной замены и выяснил, что SharePoint будет идеальным вариантом.
Немного забегу вперед и скажу, что стал уважать наших читателей, являющихся администраторами SharePoint. Мы не споткнулись об SharePoint— это, скорее, признание гибкости и богатых возможностей платформы, — но создание решения настраиваемого рабочего процесса в SharePoint – действительно трудная задача! (К счастью, нам помогла новая рубрика «SharePoint изнутри».) Тем не менее, возможность заняться этим после нескольких лет отсутствия активной практики было для меня боевым призывом — пришло время снова заняться учебой.
Существует ряд превосходных ресурсов, чтобы помочь вам снова углубиться в основы или изучить что-то новое: от нового цикла видеороликов «Практические советы» на веб-узле TechNet (technet.microsoft.com/cc138021), до демо-роликов, которые мы снимаем в журнале (.com/video), сообщества TechNet Edge (edge.technet.com) и многого другого. Но мне кажется, что пора раскрыть «основы» в самом журнале TechNet Magazine. Я не хвастаюсь, просто полагаю, что мы отлично справляемся с задачей предоставления подробных технических материалов, которые вам предстоит изучить и (надеюсь) полюбить. Тем не менее, не думаю, что мы пострадаем от того, что периодически будем пересматривать основы. Поэтому я желаю вам хорошо провести остаток лета, ведь довольно скоро мы все возвращаемся в школу. —Джошуа Хоффман (Joshua Hoffman)

Мы бы хотели поблагодарить следующих технических специалистов корпорации Майкрософт: Натант Бигмэн (Nathan Bigman), Нино Билич (Nino Bilic), Мэй-лан Томсен Буковец (Mai-lan Tomsen Bukovec), Эрик Чаррэн (Eric Charran), Трина Горман (Trina Gorman), Гершон Левиц (Gershon Levitz), Томас Марквардт (Thomas Marquardt), Мэнди Максвелл (Mandy Maxwell), Майкл Мерголо (Michael Murgolo), Санджив Нэйр (Sanjeev Nair), Мишель Рутцер (Michelle Rutzer), Джез Садлер (Jez Sadler), Джим Трухер (Jim Truher) и Шимон Яннай (Shimon Yannay).


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

Средство планирования мощности для SharePoint
В моей организации работает меньше 600 сотрудников, и значительное их число не использует активно свои ПК или интрасеть. Однако все вопят, требуя средства связи и совместной работы в масштабе компании. Я думаю, что службы Windows® SharePoint® Services (WSS) 3.0 будут идеальны для рабочей среды, но начальник выделил средства только на один сервер, предназначенный для этих целей.
Я пытался использовать средство планирования мощности для SharePoint, но оно не позволяет моделировать односерверную модель. Есть ли вариант моделирования для одиночного сервера?
—Аллен M.
Я не думаю, что здесь есть вариант для одиночного сервера. Но выбрать масштаб, не приняв во внимание все возможные действия пользователей, очень трудно. Предполагаю использовать четырехъядерный ЦП и начать с ОЗУ в 8 ГБ. Обычно сервер среднего уровня работает хорошо.
Джоел Олесон (Joel Oleson) собрал большое количество ссылок на решения задач масштабирования, которые доступны в его блоге blogs.msdn.com/joelo/archive/2007/07/09/capacity-planning-key-links-and-info.aspx. Они могут служить в качестве дополнительных справочных вседений для принятии лучшего решения, служащего интересам компании.
—Пав Черны, автор заметок.
Sharepoint изнутри

Microsoft Bob
Я знаю, что целью публикации статьи «История занимает место» (июль 2008г., technet.microsoft.com/magazine/cc565089) в рубрике «О Windows из первых рук» было показать, что на диске Windows XP была скрыта программа Microsoft® Bob, но это — еще один сильный удар по программе, которую любили мои дети и использовали для обучения основам компьютерной обработки текста. Программа Bob появилась у нас вместе с нашим первым домашним компьютером NEC с предустановленной ОС Window 95. И по мере того как мои дети росли, каждый из них часами играл и пользовался программой Bob.
Программа Bob была поднята в этой статье на смех как продукт негодной технологии, но на самом деле это был великий программный продукт, который просто был представлен на неподходящий рынок. . . взрослые. Он был приспособлен для детей и, будучи представленым таким образом, был бы оценен в другом свете и, возможно, даже имел другую судьбу. Кто знает, если бы он был представлен как детская программа с самого начала, он мог бы радовать еще и моих внуков.
— Джим С.

Печать мертва
Мне было очень интересно прочесть редакторскую статью «Печать мертва» в июльском выпуске 2008г. (в technet.microsoft.com/magazine/cc595615). Я считаю, что профессиональные книги в области информационных технологий в печатном виде скоро умрут и будут распространяться в электронном виде. Но, согласно опубликованным вами данным, 90% опрошенных ваших читателей предпочитают бумажный носитель. Был ли этот опрос репрезентативным? Или вы учли только тех людей, к которым смогли обратиться за ответом на опрос через печатную продукцию? В эту группу не входит молодое поколение, которое больше не подписывается на газеты или журналы, как вы, но получает всю информацию через Интернет и никогда не слышало о вашем опросе.
Читатель печатного текста не имеет возможности просмотреть видео или веб-трансляцию из всплывающего текста. Он не имеет возможности щелкнуть напечатанную ссылку на ресурс в Интернете, чтобы открыть домашнюю страницу, группу новостей или блог. Он не имеет возможности щелкнуть мышью для загрузки надстройки или средства, только что упомянутого в печатном тексте.
Подвожу итог: печатное издание — плохой компромисс. Читатель скоро поймет, что чтение напечатанного издания даст только часть преимуществ DVD, и сможет скопировать все содержание DVD в свой ноутбук и затем получить доступ к его содержимому в любой момент времени и в любом месте.
— Ульрих С. (Ulrich S.)
Спасибо за ваши замечание и отзыв. В качестве ответа на ваш вопрос о 90% наших читателей, которые сказали, что предпочитают бумажный носитель, этот обзор был проведен как среди наших подписчиков на печатную продукцию, так и среди веб-читателей (приблизительно в одинаковой пропорции) в рамках нашего ежегодного редакторского исследования и был представлен в электронной форме, а не в печатном виде. Этот вопрос был задан тем, кто сказал, что читает как печатные издания, так и веб-страницы, и 90% из опрошенных сообщили, что предпочитают напечатанный экземпляр.
Хотя я совершенно согласен с вами в вопросах преимуществ публикации в Интернете (хороший носитель, повсеместная доступность, возможность перехода по ссылкам и т.д.), я в то же время думаю, что чтение статьи, напечатанной на бумаге, дает более приятное ощущение. Мне удобнее работать с содержимым, и я чувствую более тесную связь с ним, и многие разделяют это ощущение. Было сказано, что наличие своих преимуществ у каждого носителя — причина того, что мы продолжаем публиковать Журнал TechNet, используя оба способа. Еще раз спасибо.
—Joshua Hoffman, главный редактор


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

Наблюдение за серверами
Настройка инфраструктуры служб отчетов SQL Server 2005
sybex.com
Чем сложнее становится инфраструктура, тем меньше мы, администраторы, осведомлены о том, что хранится в журнальных файлах баз данных. А для того, чтобы эта информация вновь обрела смысл, потребуется механизм аналитической службы и средства для представления результатов в удобной форме. Одним из таких удобных средств как раз и является служба отчетов Microsoft® SQL Server® 2005 Reporting Services. Это средство позволит вам собрать воедино все данные и представить их в удобной для пользователя форме. Он также позволяет как автоматически, так и по требованию представить информацию в удаленные места назначения. Тем самым вы обеспечите своих бизнес-пользователей всей необходимой информацией во времени, близком к реальному, для принятия более взвешенных решений.
Успешно работающая инфраструктура службы отчетов не только удовлетворяет нужды вашей организации сегодня, но и растет вместе с ней. Для успешного планирования и внедрения инфраструктуры, а также управления ею потребуется сноровка и немного терпения. Если вы решили развернуть службу отчетов SQL Server, книга «Управление инфраструктурой SQL Server 2005 Reporting Services» Джозефа Л. Джордана, (Издательство Sybex, 2007 год) поможет вам успешно понять все этапы этого процесса и справиться с ними.
Эта книга напоминает о часто забываемых аспектах внедрения службы отчетов до того, как пускаться в подробные технические детали дела. Эти аспекты помогут ответить на вопросы, зачем вы внедряете систему, каковы бизнес-требования к ней, и расскажет, как управлять ожиданиями ваших конечных пользователей. В книге также есть глава, посвященная стратегии управления изменениями в системе отчетности. В ней подробно описаны различные подходы к управлению изменениями, а также представлены руководства по составлению и шаблоны форм запросов. Я не сторонник бюрократии, но структурирование этой информации гарантирует лучшую стабильность системы.
После обсуждения рабочей части службы отчетов в книге подробно описаны развертывание инфраструктуры, включая установку, автоматизацию и настройу. В книге также представлен ряд советов по интеграции со службами Microsoft Windows® SharePoint® Services (WSS). Книга будет хорошим пособием по началу разработки списка требований, которые помогут избежать задержек на всех этапах внедрения.
Одна из замечательных новых компонентов в службе отчетов SQL Server 2005 – это возможность составления специализированных отчетов. Этот компонент позволит пользователям создавать отчеты «на лету». В книге объясняется, как включить этот компонент и настроить новое средство построения отчетов Report Builder. Также рассмотрен вопрос создания подписок на отчеты, которые позволяют по расписанию создавать и доставлять отчеты с помощью электронной почты, папок общего доступа или интегрированной службы доставки SharePoint.
Любая система требует обслуживания в течении времени, и в следующей глава рассказывается о таких необходимых вещах, как резервное копирование, управление содержимым отчетов и устранение неисправностей на основе журналов событий. Кроме того, в книге освещены вопросы безопасности, такие как варианты проверки подлинности и авторизации при развертывании.
Для программистов интересными будут главы, посвященные расширению возможностей службы отчетов, а также доступу к отчетам и работе с ними из приложений, написанных для среды Microsoft .NET Framework. Кроме того, в книге есть глава, посвященная одному из фундаментальных аспектов службы отчетов, языку определения отчетов (ЯОО). В ней рассматриваются ключевые элементы, структура файла ЯОО, а также основы создания и развертывания этих файлов.
Книга заканчивается разделом, посвященным приемам и советам по настройке производительности развернутой службы отчетов. Вы найдете сведения об измерении производительности, внесении изменений в настройку и использовании консоли производительности. Также имеется приложение по интеграции службы отчетов и SharePoint. Вы должны взглянуть на эту книгу, если планируете развертывание служб отчетов SQL Server 2005 в своей среде. Она поможет вам использовать непрямолинейные пути.

Цена: 49,99 долларов США (прямая продажа).

Аудит среды
Alloy Discovery (версия Professional).
alloy-software.com
Возможность оперативно получать информацию о конкретной системе в вашей среде является залогом успешного выполнения вашей работы, устранения неисправностей, а также гарантией того, что система во время обновляется и соответствует всем требованиям к программному обеспечению и политикам безопасности. А дружественное представление этой информации, которое позволяет мгновенно оценить состояние инфраструктуры, может быть большим преимуществом (не говоря о том, что это позволит вам гораздо лучше выглядеть в глазах начальства). Если и этого мало, вы сможете увидеть, какое программное обеспечение в вашей сети использует каждый из сотрудников, и проверить соответствующие лицензии. Одним из таких средств инвентаризации и проведения аудита, на которое будет интересно взглянуть, является Alloy Discovery профессиональной версии от Alloy Software.
Это простое в установке приложение позволит вам быстро начать аудит нужной группы машин в вашей локальной сети. Компьютеры будут представлены в интерфейсе на основе групп, очень похожих на папки Internet Explorer®, и после настройки аудита одной или нескольких групп аудит группы будет выполняться простым щелчком. Система собирает обширную информацию, включая используемое оборудование и программное обеспечение, доступ к совместным папкам и принтерам, и даже события. Кроме того, будут доступны коды ресурсов, серийные номера, статистика бесперебойной работы, переменные среды, настройка сети и локальные учетные записи пользователей. На самом деле все, что нужно знать о вашей среде, может быть получено не отходя от рабочего стола, хотя я бы посоветовал отходить от него время от времени для вашего же здоровья.
Также, кроме аудита по требованию, можно настроить его работу по расписанию. Для машин, находящихся вне вашей локальной сети, а также тех, для которых вы не имеете достаточно прав для выполнения аудита, Alloy Discovery предусматривает способ аудита с использованием агентов. С помощью этого способа отчеты могут быть сформированы, а затем запущены по расписанию или по требованию и отправлены по электронной почте в главный репозиторий Alloy Discovery. Кроме того, можно записать агент аудита на флэш-накопитель и вручную запустить аудит на нужных машинах. После этого можно синхронизировать информацию вручную или автоматически в зависимости от метода, выбранного для главного хранилища.
Alloy Discovery также позволяет включать фильтрацию результатов аудита для анализа всех активов. Например, можно увидеть, на какие машины необходимо установить дополнительную память для поддержки приложения, а также оценить, сколько в вашей сети машин работает под управлением Windows® XP Professional, а сколько – под Windows Vista® Business edition.
После сбора данных наверняка нужно будет сделать отчет. Приложение может публиковать отчеты в виде страниц HTML, на которых можно получить подробную информацию. Кроме того, можно настроить расписание для постоянного создания таких отчетов –отличный вариант для центра эксплуатации сети. В дополнение, можно экспортировать всю информацию в виде XML, CSV или файлов Microsoft Excel®, например, в качестве подтверждения для аудиторов.

Цена: 795 долларов США (прямая продажа) за базовую версию плюс 3 доллара США за каждый узел. ﻿
Следите за своей средой с помощью Alloy Discovery(Щелкните изображение, чтобы увеличить его)

Управление паролями
Password Corral
cygnusproductions.com
Пароли – неотъемлемая часть нашего взаимосвязанного мира. (По крайней мере, пока мы не создадим полностью биометрическую среду или утопическую среду с полным доверием, хотя оба варианта малоосуществимы в ближайшем будущем.) Если вы похожи на меня, у вас, вероятно, установлены различные типы паролей для различных систем, и вы храните множество паролей на разных носителях.
Кроме этих систем повседневного использования, существует множество паролей для учетных записей администратора, служебных учетных записей и другой важной учетной информации. И, естественно, что всем этим паролям соответствуют разные имена пользователей. Этот список можно продолжать до бесконечности. Поэтому встает вопрос о безопасном, но простом методе хранения всех этих паролей.
Один из способ – это хранение всей информации в едином зашифрованном репозитории, и Password Corral позволяет просто сделать это. Это простое приложение, которое в то же время использует стойкие алгоритмы, такие как Diamond2 и Blowfish, для шифрования ваших паролей, существует с 2001 года. Оно прошло множество тестов и проверок временем и до сих пор активно разрабатывается и поддерживается.
После установки программы вы получите новый файл паролей, создав нового пользователя и выбрав место для хранения файла паролей (на локальной машине или на сетевом диске). Не стоит и говорить о том, что при использовании единого файла Password Corral для хранении всей важной информации, ваш пароль для Password Corral должен быть чрезвычайно стойким и регулярно меняться. Это будет единственный пароль, который вам действительно придется помнить, так что будьте внимательны с ним.
После проверки подлинности Password Corral представит интерфейс, похожий на Internet Explorer, с иерархической структурой папок слева и панелью с подробной информацией справа. Можно организовать ваши пароли в древовидную структуру папок. Для каждого пароля есть возможность указать описание, имя пользователя, пароль, URL-адрес, адрес электронной почты для справок и комментарии. Кроме того, можно сообщить приложению, какова политика для каждого пароля, в том числе количество дней действия пароля и количество дней до его смены.
Существует режим фильтрации просроченных паролей, так что можно увидеть, какие пароли потребуется сменить при следующем входе. Другая приятная особенность – возможность автоматического создания паролей, которая избавит от необходимости выдумывать стойкие пароли для каждой учетной записи. Этот генератор полностью настраивается, позволяя указать необходимую длину, сложность и набор используемых для пароля символов.
Также есть возможность поиска сохраненных паролей по любым полям, что позволит быстро найти редко используемые, глубоко зарытые в структуру папок пароли. Есть возможность установки тайм-аута для приложения, так что если вы забудете закрыть Password Corral, приложение автоматически заблокируется для сохранения конфиденциальной информации. Приложение позаботится об очистке буфера обмена при выходе на случай, если вы забыли отчистить его после использования пароля.
Если вы нуждаетесь в постоянном доступе к паролям, можно включить значок приложения на панели задач, с помощью которого можно запустить Password Corral двойным щелчком. Если же вы хранили где-то пароли раньше, Password Corral может импортировать их, избавляя вас от дополнительной работы по их набору в базу данных программы. И, если захотите, можете даже экспортировать или распечатать ваши пароли, главное – не забудьте съесть распечатку! Так или иначе, этот чрезвычайно полезная программа.

Цена: распространяется бесплатно.
Управление паролями с помощью Password Corral(Щелкните изображение, чтобы увеличить его)

Аудит использования файлов
File System Auditor
scriptlogic.com
Регулярный аудит в совместно используемых файловых системах может позволить избежать головной боли. Однако, что еще более важно, это обязательное соответствие стандартам, касающимся политик сохранения информации. Для того чтобы знать, кто, что и когда сделал, можно воспользоваться File System Auditor от компании ScriptLogic. Это приложение для централизованного управления системой с возможностью аудита использования файлов системы практически в реальном времени, а также сохранения этой информации в базе данных SQL Server для создания отчетов.
File System Auditor поддерживает Microsoft SQL Server Desktop Engine (MSDE), SQL Server 2000 и все версии SQL Server 2005 (включая бесплатную версию SQL Server 2005 Express). На каждой машине, где необходимо производить аудит, нужно установить агент, который будет производить наблюдение за использованием файлов и отправлять отчеты в SQL Server. После установки будет запущен мастер создания базы данных, который позволит создать хранилище на основе базы данных для хранения информации, полученной в процессе аудита.
Как системный администратор вы, вероятно, задумаетесь о нагрузке и уровне подробности отчетов для тяжело нагруженных систем, но приложение использует систему экономного аудита, совмещая несколько различных действий в одном элементе аудита. Говоря о необходимой пропускной способности, File System Auditor передает всего 100 байт информации при первом обращении к файлу и около 10-20 байт для последующих обращений.
Вы спросите, почему бы не использовать стандартные возможности Windows для аудита, однако выделенное приложение для наблюдения с централизованным управлением и объединением событий – гораздо более гибкое и удобное средство. К тому же, использование в качестве хранилища базы данных SQL облегчает обращение с других систем.
После настройки базы данных установите агент на целевых серверах с помощью Agent Configuration Console. Можно ввести имя сервера или осуществить поиск по Active Directory®. File System Auditor также поддерживает кластерные файловые серверы, так что можно ввести название кластера. После этого вы устанавливаете агентскую службу (одним щелчком, если у вас есть удаленный доступ) и выбираете, какую учетную запись Windows или SQL Server должен использовать агент для подключения к хранилищу File System Auditor.
Для каждого сервера по отдельности можно указать три вида исключений: Path Filters (фильтры пути), Process Exclusion Filters (фильтры исключения процессов) и User Exclusion Filters (фильтры исключения пользователей). Path Filters позволяют выбрать пути и события, которые следует включить в наблюдение или исключить из него, такие как изменения прав доступа, создание и удаление файлов, для всех файлов или только для определенных типов. Process Exclusions и User Exclusions позволяют сделать тоже самое для указанных пользователей и процессов; правда, они не позволяют настроить фильтрацию по типам файлов.
После настройки и начала сбора сведений вы запускаете консоль настройки отчетов, чтобы начать их использовать. Для настройки отчета можно указать несколько фильтров, в том числе фильтры по пользователям, событиям файлов и папок, путям, серверам, процессам и временным рамкам. Кроме того, можно настроить отправку отчетов по электронной почте по расписанию с помощью сервера SMTP. И, наконец, для просмотра происходящего в системе в реальном времени можно запустить Real Time Viewer и наблюдать, как новые события добавляются в конец журнального файла (подобно команде tail в UNIX).

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

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


Обзор служебных программ Средство проверки памяти Windows
Лэнс Уитни (Lance Whitney)

Загрузка кода возможна по следующей ссылке: Utility2008_09.exe (640 КБ)

Cодержание
Получение средства проверки памяти Windows
Проверка памяти
Один из поддерживаемых вами компьютеров плохо работает: зависает, происходят сбои и отказы системы. Происходит сбой определенного оборудования? Неполадки вызваны недавно установленным приложением? Или, может быть, причина в неисправной памяти? Одним из способов точного определения этого является бесплатное средство проверки памяти Microsoft® Windows®. Это средство выполняет различные тесты памяти компьютера для определения наличия дефектов в каком-либо модуле.

Получение средства проверки памяти Windows
Для использования средства проверки памяти Windows необходимо загрузить и выполнить один файл программы, mtinst.exe, доступный по адресу oca.microsoft.com/en/windiag.asp. Обратите внимание на то, что установка средства проверки памяти Windows не требуется. Средство предоставляет две возможности, как показано на снимке экрана:
Рис. 1. Варианты средства проверки памяти Windows для создания загрузочного носителя (щелкните изображение, чтобы увеличить его)
  • «Create Startup Disk» (Создать загрузочный диск) – создание загрузочной дискеты в программе
  • «Save CD Image to Disk» (Сохранить образ компакт-диска на диск) – сохранение образа ISO программы на жесткий диск. Затем этот образ можно записать на компакт-диск и сделать его загрузочным с помощью программ для записи компакт-дисков. После создания загрузочного носителя необходимо перезагрузить компьютер и выполнить диагностику с дискеты или компакт-диска.
Тестирование памяти
После загрузки программы немедленно начинается проверка ОЗУ. Средство проверки памяти Windows запускается в режиме «Standard» (Стандартный), включающем 6 различных последовательных тестов памяти, каждый из которых использует уникальный алгоритм для поиска различных типов ошибок. В окне средства отображаются выполняемые тесты, ход их выполнения и диапазон проверяемых адресов памяти. После выполнения этих 6 тестов средство еще раз выполняет их, пока не будет закрыто. Как правило, однократного выполнения тестов достаточно для определения исправности памяти.
Для более тщательной проверки можно переключиться в режим «Extended» (Расширенный), в котором выполняется 11 отдельных тестов памяти. Также существует режим «Basic» (Базовый), в котором выполняется всего 2 теста, но для тщательности проверки следует использовать режимы «Standard» и «Extended». При выполнении расширенного набора тестов рекомендуется оставить средство проверки памяти Windows выполняться на ночь.
После выполнения каждого теста отображается сообщение «Succeeded» (Успешно) или «Failed» (Ошибка). В сообщении «Failed» указываются сведения об ошибке, обычно обозначается сбой одного из модулей ОЗУ. В зависимости от среды компьютера диагностика может сузить проблему памяти до конкретного модуля.
В этом случае в меню появится пункт для просмотра ошибок по модулю памяти. Это помогает определить конкретные сбойные модули, которые должны быть заменены.
На экране «Advanced options» (Дополнительные параметры) можно переключиться между режимами «Basic», «Standard» и «Extended». На этом экране также можно отключить кэш процесса на время проверки, благодаря чему средство обращается к данным непосредственно в ОЗУ, что обеспечивает более тщательное тестирование. Команда «System Information» (Сведения о системе) перечисляет объем и тип блоков ОЗУ, установленных в каждом гнезде.
Средство проверки памяти Windows поддерживает платформы на базе x86, в том числе процессоры Intel Pentium и Celeron, а также процессоры AMD K6, Athlon и Duron. Однако средство может работать с ОЗУ объемом только до 4 ГБ и не выполняет проверку памяти за пределами этого диапазона.
Версию этого средства можно найти в системе Windows Vista® в меню «Администрирование» и на установочном носителе Windows Vista в меню «Repair» (Восстановление). Тем не менее, версия этого средства, включенная в состав Windows Vista, обеспечивает меньшую визуальную обратную связь и меньшее количество параметров. Поэтому вам непременно захочется иметь под рукой отдельную версию в следующий раз при возникновении неполадок с одним из ваших компьютеров.
Лэнс Уитни— консультант по информационным технологиям, преподаватель и разработчик технической документации. Он провел бессчетные часы за настройкой рабочих станций и серверов Windows. Журналист по профессии, 15 лет назад он занялся изучением информационных технологий.


SharePoint изнутри Интеграция с каталогом SharePoint
Пав Черны (Pav Cherny)

Загрузка кода возможна по следующей ссылке: SharePoint2008_09.exe (2,775 KB)

Cодержание
Служба управления каталогом SharePoint
Пользовательская служба управления каталогом
SharePoint и ILM
Заключение
В состав служб Microsoft Windows SharePoint Services (WSS) 3.0 и пакета Microsoft Office SharePoint Server (MOSS) 2007 входят средства синхронизации с каталогом в форме службы управления каталогом (Directory Management Service), который может предоставлять контакты с поддержкой почты и групповые объекты для ресурсов SharePoint в Active Directory. Предоставление этих типов
объектов получателей для ресурсов SharePoint® дает возможность пользователям выбирать библиотеки SharePoint, списки и группы прямо из адресной книги Microsoft® Outlook® при отправке документов и иной информации.
Объекты получателя SharePoint также предоставляют способ управления передачей сообщений и преобразования форматов в организации, использующей Exchange Server. Среди прочего можно предотвратить возможность отправки сообщений в библиотеки SharePoint пользователями, не прошедшими проверку подлинности, такими как спамеры, установкой ограничений доставки сообщений в Active Directory®.
Свойства управления каталогами SharePoint, однако, ограничены, и на момент написания статьи предполагается, что в качестве нижележащей системы обмена сообщениями используется Exchange Server 2003. Сейчас, если используется Exchange Server 2007 или другая система обмена сообщениями, потребуется расширить или заменить встроенные средства управления каталогом на собственное решение для достижения нужного уровня возможностей взаимодействия.
В этой статье я кратко опишу возможности средств управления каталогом в SharePoint, а затем представлю подход для обхода существующих ограничений. Моей предпосылкой является то, что встроенная служба управления каталогом соответствует только самым основным требованиям пользователей. Среды с множеством систем обмена сообщениями и платформ управления каталогом нуждаются в большей гибкости и функциональности. Заменив встроенные компоненты собственными решениями, можно синхронизировать информацию получателей SharePoint с любым решением для работы с каталогом, которое предоставляет интерфейс API или возможности импорта.
Чтобы доказать эту точку зрения, я покажу, как синхронизировать информацию получателей SharePoint таким образом, который совместим с Exchange Server 2007. Аналогично можно использовать собственное решение для синхронизации информации получателей с IBM Lotus Notes или другой системой.
Таким же образом приобретается возможность централизации процессов предоставления каталога, основанная на службе метакаталога, такой как Identity Information Server, который входит в состав Microsoft Identity Lifecycle Manager (ILM) 2007 Feature Pack 1 (FP1). Я покажу, как интегрировать SharePoint с ILM 2007 для координации предоставления объектов каталога для библиотек документов SharePoint. Средства, исходный код и поэтапные указания для построения этого решения можно найти в сопутствующем материале к этой статье, доступном в разделе загрузки кода на веб-узле technetmagazine.com.

Служба управления каталогом SharePoint
В отличие от Exchange Server, в котором используется Active Directory почти для всей информации о настройке и получателях, SharePoint основывается на базах данных настройки и содержимого. SharePoint должен, следовательно, распространять информацию получателей о библиотеках, списках и группах с поддержкой электронной почты из своей базы данных в такой каталог. В конце концов, клиенты, обменивающиеся сообщениями, предполагают найти получателя информации в адресной книге, которая обычно создается из объектов каталога.
По умолчанию в состав пакета SharePoint с этой целью входит служба управления каталогом, которая является частью веб-службы интеграции электронной почты (SharepointEmailWS.asmx). Ее можно настроить в центральной администрации SharePoint 3.0 на странице Operations («Эксплуатация») в пункте параметров входящей электронной почты. На рис. 1 показано, как работает встроенная служба управления каталогом.
Рис. 1 Архитектура службы управления каталогом SharePoint (Щелкните изображение, чтобы увеличить его)
Когда вы включаете веб-ферму для управления каталогом и затем назначаете библиотеке, списку или группе адрес электронной почты для получения сообщений, как при использовании EmailSettings.aspx, вы неявно вызываете веб-службу интеграции электронной почты для предоставления соответствующих объектов получателей в Active Directory. Во-первых, SharePoint сохраняет информацию об адресах электронной почты в базе данных содержимого. Затем SharePoint отправляет запросы на подготовку от вашего имени веб-службе интеграции электронной почты, используя идентификацию учетной записи пула веб-приложений. Если запрос подготовки завершается сбоем, процесс заканчивается записью информации об адресе электронной почты в базу данных содержимого, но без размещения соответствующих объектов получателей в Active Directory.
Дополнительные материалы
  • Веб-узел «Продукты и технологии SharePoint»
  • Технический центр служб Windows SharePoint
  • Центр разработчиков для служб Windows SharePoint
  • Блог группы «Продукты и технологии Microsoft SharePoint»
Запросы подготовки могут закончиться сбоем по множеству причин. Самой частой причиной является отсутствие полномочий для доступа к метабазе IIS. Вследствие того, что SharepointEmailWS.asmx предназначен быть веб-службой для учетных записей групп приложений, эта веб-служба проверяет метабазу IIS, чтобы увидеть, является ли пул приложений вызывающей учетной записью, и если ответ отрицательный, отклоняет доступ вне зависимости от вашего узла SharePoint site и уровня полномочий Active Directory.
SharepointEmailWS.asmx производит эту проверку доступа в идентификации вызывающего, так что вызывающей учетной записи пула приложений требуется доступ к метабазе для проверки собственных полномочий доступа. Поэтому приходится давать учетным записям пула приложений соответствующие полномочия.
Конечно, повышенные полномочия на веб-сервере — источник проблем с безопасностью. Есть лучшие способы управления доступом к веб-службе ASP.NET. Более того, SharePoint предполагает найти службу управления каталогом на центральном административном узле, хотя этот сайт не доступен в веб-ферме постоянно, поскольку заблокирован для уменьшения возможностей для атак. Следовательно, если потребуется использовать встроенную службу управления каталогом в производственной среде SharePoint, нужно применить настройку ослабленной безопасности.
Невозможность реализовать собственную логику также предполагает, что не удастся настоить процесс подготовки, например для реализации пользовательских одобрений. SharePoint поддерживает процессы одобрений для групп, но эта возможность основана на узле центральной администрации. Только администраторы фермы SharePoint могут одобрить ожидающие запросы, хотя администраторы SharePoint не обязаны отвечать за одобрение процессов подготовки Active Directory.
Кроме того – и это, может быть, даже более важно, – нет процессов одобрения для поддерживающих электронную почту библиотек документов и списков. Если вы включите управление каталогом, то непременно дадите всем администраторам узлов вашей веб-фермы право создания контактов и групп в Active Directory с поддержкой электронной почты. Также невозможно структурировать управление получателями, основанное на организационных подразделениях (OU), поскольку все объекты получателей каждой веб-фермы размещены в том же организационном подразделении.
Нельзя переместить объекты получателей в другое организационное подразделение, потому что служба управления каталогом предполагает найти объекты в организационном подразделении SharePoint OU, и учетной записи группы центральной администрации SharePoint должны быть даны административные полномочия в Active Directory. Кроме того, нет способа реализовать двунаправленную синхронизацию между SharePoint и Active Directory. При изменении атрибутов объектов в Active Directory эти изменения не распространяются обратно в среду SharePoint.

Пользовательская служба управления каталогом
Поскольку мы установили, что встроенная служба управления каталогом оставляет мало возможностей для построения дополнительной гибкости, давайте рассмотрим несколько альтернатив. Хорошей новостью является то, что SharePoint позволяет реализовать собвственную службу управления каталогом. Нужно только зарегистрировать эту веб-службу как удаленную службу управления каталогом в центральной администрации SharePoint 3.0 на странице Operations в пункте параметров входящей электронной почты.
Для ознакомления с подробными поэтапными указаниями по развертыванию и регистрации пользовательской веб-службы вопользуйтесь электронной таблицей «Directory Integration Based on a Custom Directory Management Service.xps» в сопутствующем материале. Кроме того, данная пользовательская веб-служба позволяет увидеть, как помещать совместимые с Exchange Server 2007 объекты получателя в Active Directory без командлетов или средств управления сервером Exchange. Соответствующий исходный код находится в папке EmailIntegrationService. На рис. 2 показана архитектура решения.
Рис. 2 Архитектура пользовательской службы управления каталогом (Щелкните изображение, чтобы увеличить его)
Интерфейс пользовательской веб-службы должен соответствовать интерфейсу службы управления каталогом, как описано в пакете SDK для SharePoint. Если выполнить поиск строки «SharepointEmailWS» на веб-узле MSDN® (msdn.microsoft.com), можно найти все требуемые детали. Можно также ознакомиться с файлом Service.cs в папке EmailIntegrationService\App_Code в сопутствующем материале. Этот файл реализует требуемый интерфейс веб-службы, тогда как актуальный код для подготовки объектов Active Directory находится в SPRecipient.cs. Например, функция UpdateRecipientAttributes в SPRecipient.cs создает требуемые атрибуты Exchange Server 2007. SPRecipient.cs — кодовый файл, который нужно заменить, если нужно разработать свою службу управления каталогом.
Пользовательская служба управления каталогом — хорошее средство для преодоления требования повышенных полномочий и интеграции SharePoint с другими системами каталога или обмена сообщениями. Не надо проверять метабазу IIS для ограничения доступа веб-службы к учетным записям группы приложений. Вместо этого можно добавить раздел <authorization> в файл web.config веб-службы (пример есть в сопутствующем материале).
Однако остается несколько сложностей, так как нельзя проверить, вызывает ли SharePoint вызывает вашу службу управления каталогами, а если это происходит, то когда именно. Среди прочего, SharePoint не вызывает службу управления каталогом, когда удаляется библиотека документов или список с поддержкой электронной почты и, таким образом, в Active Directory остается неверный объект получателя. Независимо от того, используете вы встроенную службу управления каталогом или пользовательское решение, нельзя гарантировать, что информация о получателях в Active Directory соответствует ресурсам SharePoint.

SharePoint и ILM
Для получения надежной интеграции каталога следует рассмотреть развертывание профессионального пакета управления каталогом, такого как ILM. Эта система основана на модели синхронизации с каталогом по принципу получения информации. Управляющие агенты получают информацию из связанных с ними ресурсов, импортируют ее в общий метакаталог и экспортируют информацию из метакаталога в связанные с ними системы. Системы-источники обычно не выкладывают свою информацию в метакаталог. Получая информацию, можно гарантировать соответствие на каждом цикле синхронизации.
Другое преимущество состоит в том, что в состав ILM по умолчанию входит несколько агентов управления для поддержки Active Directory, Lotus Notes и множества других систем. Нужно только реализовать пользовательский управляющий агент для SharePoint с целью синхронизации информации SharePoint с другой поддерживаемой в среде платформой каталога.
Данная логика должна быть реализована для получения необходимой информации из SharePoint, ее сохранения в файле импорта и передачи импортированной информации в метакаталог. Но не нужно реализовывать эту логику для экспорта информации из метакаталога в Active Directory или другую платформу каталога. На рис. 3 показано, как реализовать синхронизацию от SharePoint к Active Directory при помощи ILM. Также возможно достигнуть синхронизации в другом направлении для подготовки ресурсов SharePoint для объектов каталога, хотя этот вопрос можно рассматривать как необязательный или дополнительный.
Рис 3. Интеграция каталога на основе ILM (Щелкните изображение, чтобы увеличить его)
Хорошей начальной точкой для разработки управляющего агента SharePoint является статья Алекса Черняховского (Alex Tcherniakhovski) «Подключение ILM 2007 к спискам служб SharePoint» по адресу blogs.msdn.com/alextch/archive/2007/09/02/wsslistsandilm.aspx. Алекс показывает, как построить основанное на ILM решение для управления каталогом, которое базируется на построенных на InfoPath® запросах подготовки, отправляемых к библиотеке документов. Управляющий агент Алекса извлекает все одобренные запросы из библиотеки документов и создает соответствующий метакаталог объектов, который затем может быть экспортирован в подключенные к нему каталоги.
По умолчанию, однако, SharePoint не создает основанные на InfoPath запросы на подготовку, когда включается поддержка почты для списка или группы. Можно достигнуть этого, используя пользовательскую службу управления каталогом, но тогда обнаружатся вопросы согласованности, упомянутые выше, потому что SharePoint не вызывает службу управления каталогом ни при каких обстоятельствах. Поэтому я рекомендую, чтобы пользовательский агент управления извлекал требуемую информацию получателей SharePoint напрямую из списков и групп набора узлов. Если нужен процесс одобрения, можно затем создать основанные на InfoPath запросы подготовки для новых ресурсов в управляющем агенте, а потом последовательно обработать все одобренные запросы.
Есть несколько вариантов для извлечения информации SharePoint. Можно прочесть эту информацию напрямую из базы данных содержимого, используя объектную модель SharePoint, или воспользоваться преимуществами веб-служб SharePoint.
Прямой доступ к базе данных содержимого не рекомендуется вследствие того, что стуктуры базы данных могут изменяться в будущих версиях, что испортит решение управления каталогом.
Прямое использование объектной модели SharePoint в управляющем агенте также непросто выполнить, потому что эта объектная модель требует локального запуска кода, кроме того, установка ILM на веб-сервере в каждой ферме SharePoint в среде может усложнить инфраструктуру управления каталогом.
Можно было бы подумать о использовании веб-служб SharePoint, но при этом возникнет другая сложность, поскольку требуемую информацию, например информацию адресов электронной почты групп SharePoint или входящий отображаемый почтовый адрес сервера, нелегко получить через веб-службы SharePoint.
Кажется, что лучше всего реализовать пользовательскую веб-службу SharePoint, которая использует объектную модель SharePoint для извлечения желаемой информации и возвращает эту информацию инициатору запроса в форме документа XML. Сейчас можно централизовать развертывание ILM и интегрировать любое количество наборов ферм и узлов через индивидуальные экземпляры веб-служб SharePoint, как показано на рис. 3.
Остался один аспект, требующий упоминания: основанная на ILM интеграция каталога не устранит необходимость в пользовательской службе управления каталогом. Эта пользовательская служба не требует какой-либо работы, потому что ILM предоставляет объекты каталога, кроме того, нужно предоставить пользовательскую службу, чтобы можно было включить управление каталогом в центральной администрации SharePoint 3.0. Иначе, например, нельзя будет назначить адреса электронной почты группам в первую очередь. На рис. 4 показана архитектура полученного решения.
Рис 4. Интеграция каталога со SharePoint на основе веб-службы (Щелкните изображение, чтобы увеличить его)
Можно превратить пользовательскую службу управления каталогом, приведенную в сопровождающем материале, в службу-заглушку, установив параметр OpMode в файле web.config (<add key="OpMode" value="dummy"/>). В этой настройке пользовательская служба всегда возвращает SUCCESS («Успешно») в ответ на запросы подготовки без осуществления какой-либо работы.
Кроме того, в пользовательской службе используется метод ResolveUsers, поэтому управляющий агент SharePoint может попросить разрешить основанные на NetBIOS имена учетных записей пользователей в различенные имена, что представляет собой обязательный шаг при подготовке групп. (SharePoint возвращает информацию о членстве в группе как список основанных на NetBIOS имен учетных записей пользователей, но для Active Directory требует различенные имена.) Вот и все. Подробные сведения о том, как развернуть полученное решение, находятся в файле «Configuring Directory Integration based on ILM 2007.xps» в сопровождающем материале.
В состав WSS 3.0 и MOSS 2007 входит служба управления каталогом для интеграции SharePoint с Exchange Server 2003 для основанной на обмене сообщенияями кроссплатформенной совместной работы.
Однако есть несколько ограничений. Пользователи должны заменить встроенную службу управления каталогом на пользовательское решение. Следует также использовать профессиональное решение для управления каталогом, такое как ILM, для интеграции SharePoint в инфраструктуру управления каталогом. Оно предоставляет высочайший уровень гибкости и может обеспечить соответствие информации через основанную на получении модель синхронизации.

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


Windows PowerShell теория строк
Don Jones (Дон Джонс)

Cодержание
Случай из реального мира
Сложные совпадения
Это мир строк
Выступая на конференциях, таких как Tech•Ed или TechMentor, я приобретаю привычку обращаться к аудитории — объявлять общие правила, которые помогут пользователям запомнить ключевые позиции таких вещах, как Windows PowerShell. Мое последнее воззвание гласит: «Если вы выполняете синтаксический анализ строки в Windows PowerShell, вы делаете что-то не то».
Это проистекает из моей философии относительно того, что Windows PowerShell является объектно-ориентированным интерпретатором команд. Если вы выполняете процедуру наподобие выгрузки списков служб в текстовый файл и последующего анализа этого текстового файла, чтобы увидеть, какие службы запущены, то очень затрудняете себе работу. Это — допустимый подход для основанных на тексте ОС, таких как UNIX, но Windows PowerShell (также как и система Windows® сама по себе) позволяет использовать объекты более экономно.
Видео
Просмотрите, как Дон Джонс демонстрирует процесс использования Windows PowerShell для анализа сложных строк.

Даже вашим собственным сценариям следует производить объекты, а не форматированный текст, чтобы для работы с выводом из сценариев можно было использовать различные команды Power Shell для форматирования, фильтрации, экспорта и т.п. (В моей статье о Windows PowerShell за июль 2008 г.можно получить дополнительные сведения о концепции пользовательских объектов как выходе сценария.)
На недавнем семинаре TechMentor в г. Орландо, штат Флорида, один из моих студентов напомнил мне, что почти все правила, особенно общие, имеют исключения. «Что насчет нахождения всякой чепухи в файле журнала IIS? Разве вам не очень нужно анализировать текст в этом случае?».
Хорошо, ошибка, да. Но, к счастью, когда придется анализировать строки текста, Windows PowerShell не подведет в силу своего умения работать с объектами. И сейчас, как вы уже заметили, файлы журналов IIS, брандмауэра и другие основанные на тексте журналы являются прекрасными примерами.

Пример из жизни
Однажды я должен был проанализировать набор журналов брандмауэра компании, в которой работал. Служащий был пойман при просмотре некоторых неуместных веб-узлов, и в качестве части последующих разбирательств отдел кадров нуждался в полном списке веб-узлов, которые он посетил. Несмотря на то, что вытащить файл журнала за один день несколько сложно, люди в отделе кадров хотели просмотреть историю за нескольких последних недель — задача, которую мне совершенно не хотелось выполнять вручную.
Сервер протокола DHCP указал, что компьютер служащего использовал один и тот же IP-адрес (скажем, 192.168.17.54) в течение нескольких месяцев. Что, конечно, не удивительно, потому что это был настольный компьютер, который редко выключался. И, поскольку в журнале брандмауэра хранились записи об IP-адресах источника, я знал, что Windows PowerShell поможет.
Секрет состоит в команде выборки строки Select-String, о которой часто забывают. Кроме того, также требовалось предметное знание регулярных выражений (о которых я рассказывал в статье о Windows PowerShell за ноябрь 2007 г.).
Команда Select-String («Выбрать строку») принимает полный путь, по которому находятся текстовые файлы, регулярное выражение или просто строку, которую нужно найти. Затем она выдаст каждую строку из каждого файла журнала, которая удовлетворяет регулярному выражению или простой строке. Для начала мне просто нужно было получить каждую строку, содержащую IP-адрес настольного компьютера этого служащего. Каждая строка файла журнала содержала дату и отметку времени — все, что было нужно сотрудникам отдела кадров.
Вот команда, с помощью которой это делается:
select-string -path c:\logs\*.txt -pattern "192.168.17.54"
-allmatches –simplematch
Параметр –simpleMatch указывает, что шаблон, предоставленный мною, — простая строка, а не регулярное выражение. На рис. 1 показана часть результата, который также можно направить в файл. Важно отметить, что результат содержит как имя файла, так и номер строки, в которой было найдено совпадение, что может быть очень полезно, если захочется вернуться в это место и получить дополнительную информацию.
Командлет месяца: Start-Sleep
Это командлет, который может дать вам то, что нужно в середине долгого рабочего дня, — легкий отдых. Start-Sleep предлагает короткую остановку для сценариев Windows PowerShell.
Короткая остановка нечасто требуется в сценариях. Например, скажем, вам нужно запустить службу, подождать несколько секунд, пока она запустится, и затем выполнить другие задания, которые зависят от этой службы. Именно для таких случаев Start-Sleep и нужен. При выдаче команды Start-Sleep 10, например, произойдет остановка PowerShell на 10 секунд. Если нужно более точное управление, можно запустить Start-Sleep с параметром -milli, например Start-Sleep -milli 100 для остановки на 100 милисекунд. Start-Sleep полностью останавливает PowerShell, включая сценарии, конвейеры и все остальное, на указанный период времени. Если сейчас кто-то захочет написать Start-Nap командлет, я вздохну.
Рис. 1. Выходные данные команды Select-String (щелкните изображение, чтобы увеличить его)

Сложные совпадения
После того как я представил отделу кадров именно то, о чем они просили, они поняли, что в итоге им требовалось совсем другое. Мой отчет включал в себя посещения множества IP-адресов, таких как 207.68.172.246 (Веб-узел MSN®). Следующее, что меня попросили сделать, – урезать отчет до включения в него только посещений указанных IP-адресов, которые они идентифицировали как принадлежащие одному из отслеживаемых веб-узлов. В этой статье я не хочу открывать истинные IP-адреса, которые были получены в этом расследовании. Вместо них здесь я буду использовать 207.68.172.246 (хотя веб-узел MSN обычно не рассматривается как нежелательный).
Этот запрос мог быть чуть посложнее. В файле журнала, с которым я работал, IP-адреса источника и получателя находились рядом и были разделены запятой. Так что я просто изменил мою строку поиска на «192.168.17.54,207.68.172.246» и повторил поиск.
Однако в более сложном файле журнала между двумя IP-адресами могли быть записаны переменные данные, так что простое совпадение строк не сработало бы. В этой ситуации нужно было бы прибегнуть к регулярному выражению, это также хорошо подходит для более простых форматов журналов, что я и продемонстрирую.
В регулярном выражении символ точки является символом подстановки для любого одиночного символа, и я могу использовать подвыражение (.)* для поиска любого количества символов между двумя указанными IP-адресами. Тем не менее, необходимо использование обратной косой черты для экранирования символов точек, которые появляются в самих IP-адресах.
Полученная команда:
select-string -path c:\logs\*.txt -pattern
"192\.168\.17\.54(.)*207\.68\.172\.246" –allmatches
Я удалил параметр –simpleMatch, так как в этот раз использую регулярное выражение. В полученном результате отражены только посещения веб-узлов, указанных как недопустимые, с компьютера указанного служащего. Кроме того, в результат входили дата и время, которые требовались для расследования. На рис. 2 показана часть результата, который можно получить при запуске подобной команды.
Рис. 2 В результате суженного поиска отображаются посещения только указанного узла. (Щелкните изображение, чтобы увеличить его)
Но я могу поступить лучше и передать результ в командлет Format-Table, чтобы использовать его возможности показа вычисленных столбцов. Я могу вставить в эту таблицу имена файлов журналов и номер строки, где совпадение было обнаружено, и даже могу показать саму найденную строку. Тем не менее, можно попросить PowerShell заменить регулярное выражение пустой строкой так, что будет показан только остаток строки — дата и время в моем примере. Это более сложный прием, но он является дальнейшей иллюстрацией того, как Windows PowerShell может работать со строковыми данными и производить глубоко переработанный результат с помощью всего лишь одной командной строки:
select-string -path c:\logs\*.txt -pattern
"192\.168\.17\.54(.)*207\.68\.172\.246" -allmatches |
ft  filename,linenumber,@{"Label"="Time";
"Expression"={$_.line.replace
($_.matches[0],"")}} –auto
Окончательный результат должен выглядеть, как на рис. 3.
Рис. 3. Форматированный результат команды Select-String (щелкните изображение для его увеличения)

Это мир строк.
Я рад провозгласить объектно-ориентированную сущность Windows PowerShell одной из его самых сильных его сторон. Но, тем не менее, есть случаи, когда объекты — не выход.
Windows PowerShell может жить в объектно-ориентированном мире. К счастью, команда разработчиков Windows PowerShell поняла, что мир часто содержит внешние днные в форматированных строках, так что в PowerShell есть команда Select-String. Вооружившись командой Select-String и знаниями о регулярных выражениях, можно использовать Windows PowerShell для написания командных строк, которые будут анализировать самые сложные строки.

Дон Джонс – соавтор книги Windows PowerShell: TFM и автор множества других книг по ИТ. С ним можно связаться через его блог www.concentratedtech.com.


Эй, сценарист!!
Сценаристы корпорации Майкрософт

Загрузка кода возможна по следующей ссылке: HeyScriptingGuy2008_09.exe (150 KB)

Если и существует нечто , что обобщает суть нашего современного мира, то оно заключено в следующих двух словах: «Оставайтесь на связи». Благодаря сотовым телефонам вам не нужно больше быть дома для того, чтобы люди могли вам позвонить; они теперь могут найти вас всюду, где вы находитесь, в любое время дня и ночи. (Хм. Как … приятно.) Благодаря беспроводной компьютерной связи не нужно быть в офисе, чтобы выполнять свою работу; сейчас можно работать дома, на пляже, – везде, где можно себе представить.
История из жизни: родители редактора сценариев недавно отправились в туристический поход, но им пришлось поволноваться — как великим первооткрывателям Льюису и Кларку, — когда они столкнулись с проблемами подключения к беспроводной сети кампуса. Слава создателю, что спутниковое телевидение все еще работало!
И это еще только цветочки. Устройства GPS позволяют точно знать, где вы находитесь, в пределах нескольких десятков сантиметров; в зависимости от устройства, они также могут сообщить эту информацию другим людям. (Старая фраза «Вы можете убежать, но не спрятаться» никогда еще не была так точна, как сегодня.) Если было бы желание, сценарист, который пишет эту статью, смог бы получать телефонный звонок от чекового счета каждый раз, когда оплачивается чек; также он мог бы получать ежемесячный отчет по электронной почте от своего автомобиля о его состоянии. А если бы и этого было мало, тостеру получил бы предложение прогуляться с собакой и полить цветы каждый раз, когда сценарист едет в оттпуск.
Хорошо, может быть, это еще не произошло .. пока. Но при желании сценарист смог бы купить тостер с возможностью подключения к Интернету. Затем он смог бы позвонть своему тостеру по пути домой и, когда он войдет в дверь, получить только что приготовленный горячий тост. Честно говоря, мы не знаем, почему ему бы этого захотелось. Но если б захотелось..
Конечно, если целью каждого будет оставаться на связи, неудивительно, что сценаристы, которые никогда не были рабами ультрасовременности, начнут выступать за большее уединение. Означает ли это, что сценаристы рекомендуют выкинуть сотовый телефон или переносной компьютер? Нет, даже если сценаристы будут умнее. Однако вот то, за что они выступают: чтобы вы добавили к своему арсеналу сценариев несвязанные наборы записей. Но если вы все же захотите выкинуть сотовый телефон или переносной компьютер, хорошо, мы не будем вам мешать.
Замечание. Согласно опросу, проведенному службой Harris Interactive, 43 процента американцев используют переносной компьютер в отпуске для получения и отправки рабочей корреспонденции. И более 50 процентов американцев используют свои сотовые телефоны в отпуске для проверки электронной почты и/или голосовых сообщений. И сюда не включены 40 процентов американцев, у которых нет отпуска на протяжении года.
Это происходит без разговоров о том, что огромное количество людей были бы счастливы добавить несвязанные наборы записей в арсенал сценариев, исключая одно соображение: они не знают, что собой представляют несвязанные набры записей. Хорошо, в том случае, если вы не знакомы с этой концепцией, несвязанный набор записей (более или менее) представляет собой таблицу базы данных, которая не привязана к реальной базе данных; вместо этого она создается сценарием, существует только в памяти и исчезает, когда сценарий завершается. Другими словами, несвязанные наборы записей — это созданная структура, которая существует только в течение нескольких минут и исчезает, унося с собой информацию. Ха, это, похоже действительно полезно, сценаристы. Спасибо за помощь!
Ладно, допустим: слова «несвязанные наборы записей» звучат не слишком увлекательно. Да, это так, они не слишком увлекательны. Но они могут быть чрезвычайно полезны. Как прекрасно знают все составители сценариев Visual Basic (VBScript) со стажем, VBScript совершенно точно не имеет лучших в мире способностей по сортировке данных. (Хорошо, пока вы не рассматриваете отсутствие способности сортировки данных как лучшую способность сортировки данных в мире.) Способность VBScript иметь дело с большими объемами данных точно так же, в лучшем случае, ограничена. За пределами объекта словаря (Dictionary) (который ограничивает программиста работой с элементами, которые имеют максимум два свойства) или массива (который сильно ограничен до списков данных, имеющих одно свойство), ну… это все о нем.
Несвязанные наборы записей позволяют решить оба этих вопроса (и еще много). Нужно отсортировать информацию, в частности, данные со множеством свойств? Нет проблем; как уже сказано, несвязанный набор записей является виртуальным эквивалентом таблицы базы данных, и нет ничего легче в этом мире, чем сортировать таблицу базы данных (Хорошо, если захотите прицепиться к этому моменту, мы допустим, что невыполнение сортировки таблицы базы данных легче, чем сортировка таблицы базы данных.) Или, возможно, у вас есть огромное множество элементов, элементов со множеством свойств, которые нужно отслеживать? Нет проблем; мы уже упоминали, что несвязанный набор записей является виртуальным эквивалентом таблицы базы данных? Вам нужно фильтровать информацию каким-либо образом или, может быть, искать в данных какое-то значение? Ох, если бы только были бы способы использовать виртуальный эквивалент таблицы базы данных…
Стоит заметить: может быть, это всё делается для того, чтобы только показать вам, о чем мы говорим (предполагая, что хотя бы известен предмет разговора) Для начинающих, скажем, у нас есть статистика по бейсболу, показанная на рис. 1: это статистика, взятая с веб-узла MLB.com и сохраненная в файле значений, разделенных табуляцией, с названием C:\Scripts\Test.txt.
Рис. 1 Статистика, сохраненная в файле со значениями, разделенными табуляцией.
Игрок | Хоумраны | RBI | Средний
Д. Педройа (D Pedroia) | 4 | 28 | .276
К. Кузманофф (K Kouzmanoff) | 8 | 25 | .269
Дж. Франкуе (J Francouer) | 7 | 35 | .254
С. Гузман (C Guzman) | 5 | 20 | .299
Ф. Санчес (F Sanchez) | 2 | 25 | .238
И. Сузуки (I Suzuki) | 3 | 15 | .287
Дж. Гамильтон (J Hamilton) | 17 | 67 | .329
И. Кинслер (I Kinsler) | 7 | 35 | .309
М. Рамирес (M Ramirez) | 12 | 39 | .295
А. Гонзалес (A Gonzalez) | 17 | 55 | .299
Всё это хорошо и здорово, но представьте, что нам бы на самом деле хотелось показать список игроков, отсортированных по числу хоумранов, которые они выбили. Может тут помочь несвязанный набор записей? Попробуем выяснить; взглянем на рис. 2. Ага, здесь уйма кода, не так ли? Но не беспокойтесь, так как вы скоро увидите, что все это страшно только на первый взгляд.
Рис.2. Несвязанный набор записей
Const ForReading = 1
Const adVarChar = 200
Const MaxCharacters = 255
Const adDouble = 5

Set DataList = CreateObject("ADOR.Recordset")
DataList.Fields.Append "Player", _
  adVarChar, MaxCharacters
DataList.Fields.Append "HomeRuns", adDouble
DataList.Open

Set objFSO = _
  CreateObject("Scripting.FileSystemObject")
Set objFile = objFSO.OpenTextFile _
  ("C:\Scripts\Test.txt", ForReading)

objFile.SkipLine

Do Until objFile.AtEndOfStream
    strStats = objFile.ReadLine
    arrStats = Split(strStats, vbTab)

    DataList.AddNew
    DataList("Player") = arrStats(0)
    DataList("HomeRuns") = arrStats(1)
    DataList.Update
Loop

objFile.Close

DataList.MoveFirst

Do Until DataList.EOF
    Wscript.Echo _
        DataList.Fields.Item("Player") & _
        vbTab & _
        DataList.Fields.Item("HomeRuns")
    DataList.MoveNext
Loop
Для начала определяем четыре новых константы:
  • ForReading. Эта константа будет использоваться, когда мы откроем и прочитаем текстовый файл.
  • adVarChar. Это — стандартная константа ADO для создания поля, которое использует тип данных Variant.
  • MaxCharacters. Это — стандартная константа ADO, используемая для показа максимального количества символов, которое поле Variant может содержать (в данном случае 255).
  • adDouble. Последняя константа ADO для создания поля, которое использует тип данных с двойной точностью (с плавающей точкой).
После определения констант мы находим блок кода:
Set DataList = CreateObject _
    ("ADOR.Recordset")
DataList.Fields.Append "Player", _
    adVarChar, MaxCharacters
DataList.Fields.Append "HomeRuns", _
    adDouble
DataList.Open
Это — часть сценария, где мы на самом деле устанавливаем и настраиваем несвязанный набор записей. Для выполнения этой задачи первое, что нужно сделать, — это создать экземпляр объекта ADOR.Recordset object; надо сказать, при этом и создается таблица виртуальной базы данных (то есть наш несвязанный набор записей).
Затем используем эту строку кода (и метод Append («Добавить»)) для добавления нового поля в набор записей:
DataList.Fields.Append "Player", adVarChar, MaxCharacters
Как видите, здесь совсем нет ничего волшебного: мы просто вызываем метод «Добавить» (Append), за которым следуют три параметра:
  • Имя поля (Players).
  • Тип данных для этого поля (adVarChar).
  • Максимальное количество символов, которые могут быть размещены в нем (MaxCharacters).
После добавления поля Players можно добавить следующее поле: Homeruns (Хоумраны), которое имеет численный (adDouble) тип данных. Покончив с этим, вызываем метод Open («Открыть») для объявления нашего набора записей открытым и готовым для дела.
Затем создаем экземпляр объекта Scripting.FileSystemObject и открываем файл C:\Scripts\Test.txt. Этой части сценария реально нечего делать с несвязанным набором записей, она тут только потому, что нужно получить данные из текстовоо файла. Первая строка текстового файла содержит информацию о заголовке:
Player     Home Runs     RBI        Average
Несвязанному набору записей эта информация не нужна, так что после открытия файла вызываем метод SkipLine («Пропустить строку») для пропуска первой строки:
objFile.SkipLine
Сейчас, когда мы перешли к первой строке, содержащей актуальную информацию, устанавливаем цикл Do Until, предназначенный для построчного чтения остатка файла. При каждом чтении строки из файла сохраняем ее в переменную strLine, затем используем функцию Split («Отделить») для перевода этой строки в массив значений (отделяя новую строку каждый раз, когда обнаруживается табуляция):
arrStats = Split(strStats, vbTab)
Заметим, что все это — что-то вроде общего обзора, но предполагаем, что к этому времени большинство из вас уже достаточно хорошо умеет извлекать информацию из текстовых файлов. Короче, в первый проход через цикл массив arrStats будет содержать элементы с рис. 3.
Рис. 3. Содержимое массива
Номер элемента | Имя элемента
0 | Д. Педройа (D Pedroia)
1 | 4
2 | 28
3 | .276
А теперь можно и повеселиться:
DataList.AddNew
DataList("Player") = arrStats(0)
DataList("HomeRuns") = arrStats(1)
DataList.Update
Здесь мы добавляем информацию об игроке 1 (Д. Педройа) в несвязанный набор записей. Чтобы добавить запись в набор записей, начнем с вызова метода AddNew («Добавить новый»); он создает новую пустую запись, с которой мы будем работать. Используем следующие две строки кода для назначения значений двум полям набора записей (Player (Игрок) и HomeRuns (хоумраны)), затем мы вызываем метод Update («обновить») для официальной записи этой записи в набор. И затем переходим на начало цикла еще раз, где мы повторяем весь процесс с новой строкой — следующим игроком — в текстовом файле. Понимаете? Тут может быть много кода, но все это очень просто и прямолинейно.
И что же произойдет после того, как все игроки будут добавлены в набор записей? Хорошо, после того, как закрываем текстовый файл, исполняем блок кода:
DataList.MoveFirst

Do Until DataList.EOF
  Wscript.Echo _
    DataList.Fields.Item("Player") & _
    vbTab & _
    DataList.Fields.Item("HomeRuns")
  DataList.MoveNext
Loop
В строке 1 используется метод MoveFirst («Переместить в начало») для позиционирования курсора в начало набора записей; если мы это не сделаем, возникает риск увидеть только часть данных набора записей. Затем настраивается цикл Do Until, выполняющийся до конца потока данных (то есть пока свойство набора записей EOF — конец файла — не станет истинным).
Все, что мы делаем внутри цикла, это выдача на консоль значений полей игрока (Player) и хоумранов (HomeRuns) (заметим, что иногда используется нечеткий синтаксис для индикации конкретного поля): DataList.Fields.Item("Player"). Затем просто вызываем метод MoveNext («Переместиться на следующий») для перемещения на следующую запись в наборе.
Не нужно говорить, что все это на самом деле просто. Когда все сказано и сделано, следует вернуться к следующему моменту:
D Pedroia       4
K Kouzmanoff    8
J Francouer     7
C Guzman        5
F Sanchez       2
I Suzuki        3
J Hamilton      17
I Kinsler       7
M Ramirez       12
A Gonzalez      17
Как можно видеть, всё – ну, если задуматься, на самом деле не так уж всё и хорошо, верно? Допустим, мы вернули имена игроков и общее количество хоумранов, но сортировка по хоумранам не выполнена. Елки-палки, почему несвязанный набор записей не сделал этого за нас?
Этому есть хорошее объяснение: мы не сказали набору записей, по какому полю нужно сортировать. Это довольно легко исправить: просто изменим сценарий для добавления сведений о сортировке сразу перед вызовом метода MoveFirst («переместиться в начало»). Иными словами, сделайте эту часть сценария так:
DataList.Sort = "HomeRuns"
DataList.MoveFirst
Очевидно, тут нет трюка; просто присваиваем поле HomeRuns (Хоумраны) свойству Sort (Сортировать). Теперь посмотрим на результат, который получится после запуска этого сценария:
F Sanchez       2
I Suzuki        3
D Pedroia       4
C Guzman        5
J Francouer     7
I Kinsler       7
K Kouzmanoff    8
M Ramirez       12
J Hamilton      17
A Gonzalez      17
Намного лучше. Все это хорошо, за исключением одного «но»: обычно общее количество хоумранов показывается в нисходящем порядке, где игрок с максимальным их количеством показывается первым. Есть какой либо способ сортировать несвязанный набор записей в нисходящем порядке?
Конечно есть, все, что нужно сделать, – это вспомнить о полезном параметре DESC, например, так:
DataList.Sort = "HomeRuns DESC"
А что параметр DESC делает для нас? Получилось:
A Gonzalez      17
J Hamilton      17
M Ramirez       12
K Kouzmanoff    8
I Kinsler       7
J Francouer     7
C Guzman        5
D Pedroia       4
I Suzuki        3
F Sanchez       2
Между прочим, совершенно справедливо сортировать по нескольким свойствам; всё, что нужно сделать, – это присвоить каждому из этих свойств порядок сортировки. Например, предположим, что вам нравится сортировать сначала по хоумранам, а затем по RBI. Не проблема; эта команда все сделает:
DataList.Sort = "HomeRuns DESC, RBI DESC"
Попробуйте и посмотрите сами. Это не так радует, как просмотр электронной почты в отпуске, но близко к тому.
Замечание. Помните о том, что нельзя сортировать по полям, которые не были добавлены в набор записей. Что это значит? Это значит, что перед добавлением свойства, как, например, RBI, в оператор Sort, нужно добавить в сценарий в соответствующие места следующие строки:
DataList.Fields.Append "RBI", adDouble

DataList("RBI") = arrStats(2)
И, если вы посмотрите на результат, то поймете, что нужно исправить и оператор Wscript.Echo:
Wscript.Echo _
  DataList.Fields.Item("Player") & _
  vbTab & _
  DataList.Fields.Item("HomeRuns") & _
  vbTab & DataList.Fields.Item("RBI")
Посмотрим, что еще можно сделать при помощи несвязанных наборов записей. О, есть еще кое-что. Предположим, что мы извлекли всю информацию для всех игроков и затем сортируем данные по среднему числу ударов. (Среди прочего, это означает, что нужно изменить изначальный сценарий для создания полей RBI и BattingAverage (среднее число ударов).) Результат выглядит следующим образом:
J Hamilton      17      67      0.329
I Kinsler       7       35      0.309
A Gonzalez      17      55      0.304
C Guzman        5       20      0.299
M Ramirez       12      39      0.295
I Suzuki        3       15      0.287
D Pedroia       4       28      0.276
K Kouzmanoff    8       25      0.269
J Francouer     7       35      0.254
F Sanchez       2       25      0.238
Хорошо, но если нужен только список игроков, выбивающих 0,300 и выше? Как можно ограничить отображаемые данные только игроками, которые соответствуют указанным критериям? Ну, один способ — назначить фильтр набору записей:
DataList.Filter = "BattingAverage >= .300"
Фильтр набора записей служит тем же общим целям, что и запрос к базе данных: он предоставляет механизм по ограничению возвращаемых данных до подмножества всех записей в наборе. В этом случае просто просим фильтр отобрать все записи, за исключением тех, где поле BattingAverage имеет значение, большее или равное 0,300. И что вы думаете? Фильтр делает в точности то, что его просят:
J Hamilton      17      67      0.329
I Kinsler       7       35      0.309
A Gonzalez      17      55      0.304
Если бы наши дети так отвечали, а?
Кстати, можно использовать несколько критериев в одном фильтре. Например, приведенная ниже команда ограничивает возвращаемые данные записями, где поле BattingAverage больше или равно 0,300 и поле HomeRuns больше 10:
DataList.Filter = _
  "BattingAverage >= .300 AND HomeRuns > 10"
И наоборот, приведенный ниже фильтр ограничивает данные записями, где поле BattingAverage больше или равно 0,300 или поле HomeRuns field больше 10:
DataList.Filter = "BattingAverage >= .300 OR HomeRuns > 10"
Испробуйте оба варианта, и вы увидите, в чём отличие. А собака зарыта здесь: просто для интереса, вот еще один фильтр на пробу:
DataList.Filter = "Player LIKE 'I*'"
Как видно, можно использовать в фильтре подстановочные символы. Чтобы это сделать, используйте оператор LIKE (вместо знака равенства) и затем звездочку так же, как бы вы это сделали в MS-DOS® в команде типа dir C:\Scripts\*.txt. В предыдущем примере будет получен список игроков, чье имя начинается с буквы I; просто потому, что используемый синтаксис говорит: «Показать список всех записей, где значение поля Player (Игрок) начинается с I и затем идет, ну, скажем, что угодно». Попробуйте .. хорошо; вы сейчас уже знаете эту процедуру.
Кстати, вас еще не утомили средние числа ударов типа 0.309. (Обычно среднее число ударов записывается без ведущего нуля ,309, например.) Но это хорошо; вы можете просто использовать функцию FormatNumber для форматирования среднего числа ударов в любой традиционный вид, который вы хотите:
FormatNumber (DataList.Fields.Item("BattingAverage"), 3, 0)
Просто включите эту функцию в оператор Wscript.Echo, когда отображаете число (или, наоборот, можно присвоить результат переменной и передать ее оператору Echo):
Wscript.Echo _
  DataList.Fields.Item("Player") & _
  vbTab & _
  DataList.Fields.Item("HomeRuns") & _
  vbTab & DataList.Fields.Item("RBI") & _
  vbTab & _
  FormatNumber _
  (DataList.Fields.Item("BattingAverage"), _
   3, 0)
Интересная штука, а?
К несчастью, это выглядит, как если бы у вас целый месяц не было времени. Обобщая, просто хочется сказать, что … извините, телефонный звонок.
По-любому, хочется отметить, что … о, звонит уже мобильный телефон. И только что получено сообщение от тостера. Важно: горячий тост уже готов, и что мы хотим: масло или джем? Должен идти, увидимся через месяц!
Головоломка-сценарий доктора Сценарио.
Задача на этот месяц, требующая не только умения решать головоломки, но и навыков создания сценариев.

Сентябрь 2008 г.: Сценарный поиск
Вот простой (или может быть не очень) поиск слова. Найти все функции VBScript и операторы в списке. Но вот уловка: оставшиеся буквы сложатся в скрытое слово, которое окажется просто — вы угадали — командлетом Windows PowerShell™.
Список слов: Abs, Array, Atn, CCur, CLng, CInt, DateValue, Day, Dim, Else, Exp, Fix, InStr, IsEmpty, IsObject, Join, Len, Log, Loop, LTrim, Mid, Month, MsgBox, Now, Oct, Replace, Set, Sin, Space, Split, Sqr, StrComp, String, Timer, TimeValue, WeekdayName.

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

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


Материалы о рабочей среде Расширенная функциональность в WDS
Уэс Миллер (Wes Miller)

Cодержание
Управление из командной строки
Хранилище образов
Многоадресность
Ведение журнала WDS
Другие вопросы
Заключение
В последних двух выпусках этой рубрики я рассматривал службы развертывания Windows (WDS). Я начал с рассмотрения истории средств развертывания Майкрософт, основанных на среде предзагрузочного выполнения (PXE) и последующего обзора WDS. В этом месяце я подробно рассмотрю некоторые сложные вопросы.
WDSUtil (многофункциональная служебная программа командной строки для WDS), хранилище образов WDS, ведение журналов WDS и работа с многоадресной рассылкой в WDS для Windows Server® 2008.
Когда службы удаленной установки (RIS) входили в состав Windows® 2000 and Windows Server 2003, они никогда не обладали настолько богатыми возможностями, как многие бы хотели. Особенно выделялись три области.
  • Производительность (более масштабируемое развертывание)
  • Ведение журнала/аудит
  • Автоматизация командной строки
Как вы увидите в данной статье, в первоначальном выпуске WDS, а именно WDS в Windows Server 2008, во все эти области были внесены существенные изменения.

Управление из командной строки
В статье прошлого месяца я упоминал о том, что в службах WDS предоставлена значительно улучшенная консоль управления. Но что еще более важно для большинства предприятий, в состав WDS входит новая служебная программа командной строки для управления, WDSUtil.exe (см. рис. 1). WDSUtil устанавливается вместе с дополнительным компонентом WDS в Windows Server 2003 (пакет обновления 1 (SP1) + WDS или пакет обновления 2 (SP2)) и с ролью WDS в Windows Server 2008.
Рис. 1. Установка для параметра обнаружения архитектуры значения «yes» (да) при помощи WDSUtil (Щелкните изображение, чтобы увеличить его)
WDSUtil – это невероятно многофункциональная, но сложная служебная программа. Фактически всё, что можно сделать с помощью консоли управления Microsoft® (MMC), и многое другое может быть сделано с помощью WDSUtil. Чтобы привести хороший пример этого, который также является одним из лучших способов диагностирования наличия проблем, попробуйте выполнить следующее:
wdsutil /get-server /show:config
Результаты практически полностью отражают результаты работы оснастки MMC для WDS — хотя результаты WDSUtil могут быть выведены в более простом для чтения формате, который потом может быть экспортирован в текстовый файл.
Недостаточно информации? Попробуйте выполнить следующую команду, возвращающую еще больше:
wdsutil /get-server /show:all /detailed
Можно остановить и перезапустить сервер WDS, выполнив следующее:
wdsutil /stop-server
wdsutil /start-server
Справочник по командам для WDSUtil доступен на веб-узле go.microsoft.com/fwlink/?LinkId=112194. Также можно загрузить версию этого справочника в формате CHM (вместе со всей документацией по WDS 2008) с веб-узла go.microsoft.com/fwlink/?LinkId=89381.
При использовании RIS отсутствовал простой способ — если вы не специалист по интерфейсам служб Active Directory® (ADSI) — выяснить через командную строку, связан ли определенный MAC-адрес или идентификатор GUID с объектом учетной записи компьютера (MAO) в Active Directory. С помощью WDSUtil можно выполнить запрос на основе MAC-адреса или идентификатора GUID.
Идентификаторы GUID могут казаться запутанными, поскольку их можно вводить как в виде двоичных строк, так и в виде строк GUID; единственным отличием является порядок байтов и отсутствие дефисов. MAC-адреса могут вводиться как с дефисами, так и без них с помощью одной из следующих строк кода:
wdsutil /get-device /id:01-23-45-67-89-AB
wdsutil /get-device /id:0123456789AB
Можно получить сведения об устройстве в виде двоичной строки с помощью следующей команды:
wdsutil /get device /id:ACEFA3E81F20694E953EB2DAA1E8B1B6
Или можно получить сведения об устройстве в виде строки GUID с помощью следующей команды:
wdsutil /get device /id:E8A3EFAC-201F-4E69-953-B2DAA1E8B1B6
Многие ваши компьютеры, скорее всего, могут работать под управлением 64-разрядных версий Windows, но некоторые из них, к сожалению, не могут верно сообщать свою архитектуру. Можно разрешить WDS выполнять определение поддержки компьютерами 64-разрядных систем, запустив небольшую программу сетевой загрузки, входящую в состав WDS. Как показано на рис. 1, это можно выполнить следующим образом:
wdsutil /set-server /architecturediscovery:yes
Команда /set-server WDSUtil фактически выполняет настройку большого числа параметров сервера. Для просмотра возможностей выполните следующую команду:
wdsutil /set-server /?
В случае обновления сервера WDS под управлением Windows Server 2003 до Windows Server 2008 можно преобразовать любые образы RIPrep в образы в формате образов Windows (WIM), выполнив следующее:
WDSUtil /convert-RIPrepImage
Хотя WDSUtil может преобразовывать образы RIPrep, все оставшиеся образы RISetup (традиционный установки RIS/устаревшие установки WDS с использованием сценариев) не могут быть преобразованы.
Богатые возможности WDSUtil основаны на возможности автоматизации часто повторяющихся задач. Команды, приведенные на рис. 2, дают представление о возможностях WDSUtil. Выполняется ли развертывание новых серверов WDS, добавление или изменение образов на нескольких серверах, администрирование многоадресной архитектуры или указание программы загрузки по сети для использования для определенного клиента загрузки, WDSUtil предоставляет полезные возможности, ранее отсутствующие в RIS.
Рис. 2. Команды WDSUtil
Команда | Описание
/add | Добавление устройств, образов или групп образов.
/approve-AutoAddDevices | Утверждение ожидающих устройств Auto-Add и установка параметров настройки для них.
/convert-RiprepImage | Преобразование устаревшего образа RIPrep в образ WIM.
/copy-Image | Дублирование образа в хранилище образов.
/delete-AutoAddDevices | Удаление всех или определенных ожидающих устройств Auto-Add.
/disable | Отключение сервера WDS или транспортного сервера.
/disconnect-Client | Отключение клиента от многоадресной передачи или пространства имен.
/enable | Включение сервера WDS или транспортного сервера.
/export-Image | Как и /export в ImageX, данная команда экспортирует существующий образ из хранилища образов в образ WIM.
/get | Получение свойств и атрибутов для устройства, образа, группы образов, сервера WDS или транспортного сервера.
/initialize-Server | Настройка сервера WDS для использования после первой установки.
/new | Сохранение или обнаружение образов, многоадресных передач и пространств имен.
/progress | Отображение хода выполнения определенной команды.
/reject-AutoAddDevices | Отклонение всех или определенных ожидающих устройств Auto-Add.
/remove | Удаление образов, групп образов, многоадресных передач и пространств имен.
/replace-Image | Замена (перезапись) образа новым образом.
/set | Получение свойств и атрибутов для устройства, образа, группы образов, сервера WDS или транспортного сервера.
/start | Запуск сервера WDS или транспортного сервера.
/stop | Остановка сервера WDS или транспортного сервера.
/uninitialize-Server | Отмена изменений сервера, внесенных при инициализации сервера (возврат к ненастроенному состоянию).
/update-ServerFiles | Обновление файлов в общем ресурсе сервера REMINST последними версиями из каталога сервера System32\RemInst.
/verbose | Отображение подробного вывода при выполнении определенной команды.

Хранилище образов
В статье за прошлый месяц я упоминал о том, что хранилище единственных копий (SIS), используемое RIS для более эффективного хранения файлов на диске, не используется WDS. Теперь все образы в стандартном режиме (WIM) независимо от ОС хранятся в хранилище образов WDS. Как я указывал в предыдущих статьях, эта функция единственных копий сохраняла пространство в файлах WIM, если в образах томов имелись соответствующие файлы. Хранилище образов WDS работает подобных образом. Фактически, оно использует функции WIM для хранения образов.
Для работы с хранилищем образов необходима по крайней мере одна группа образов; при инициализации WDS появится запрос на создание группы. Также при добавлении образа установки можно создать новую группу образов, в которую будет добавлен этот образ (см. рис. 3).
Рис. 3. Создание новой группы образов (Щелкните изображение, чтобы увеличить его)
Так что же такое хранилище образов? Откройте каталог RemoteInstall в каталоге Images, и вы найдете каталоги для всех созданных групп образов. Как показано на рис. 4, существует один файл WIM для каждого образа установки, импортированного в группу образов, и один общий файл RWM (Resource WIM).
Рис. 4. Содержимое группы образов (Щелкните изображение, чтобы увеличить его)
Внимательно взгляните на файлы, показанные на рис. 4. Эта группа образов состоит из следующих файлов:
  • install.wim (Windows Server 2008, Standard Edition)
  • install-(2).wim (Windows Server 2008, Enterprise Edition)
  • install-(3).wim (Windows Server 2008, Datacenter Edition)
  • install-(4).wim (Windows Server 2008, Standard Edition (Server Core)
  • install-(5).wim (Windows Server 2008, Enterprise Edition (Server Core)
  • install-(6).wim (Windows Server 2008, Datacenter Edition (Server Core)
Теперь сравните размер файлов с размером файлов MMC (показанных на рис. 5). Размер каждого файла WIM на рис. 4 – это только небольшая часть размера файла Res.rwm. Почему? Для экономии места показанные файлы WIM – это просто прототипы действительных файлов. Они содержат метаданные для восстановления файла WIM, но не содержат файловых ресурсов. Все файловые ресурсы в группе образов хранятся в файле RWM для этой группы образов.
Рис. 5. Образы, показанные в диспетчере серверов (Щелкните изображение, чтобы увеличить его)
Для изменения образа установки в хранилище образов можно либо экспортировать образ, внести изменения, а затем заменить образ (или импортировать новый), либо для работы с ним можно отключить соответствующий образ установки в MMC и внести изменения путем монтирования и изменения файла WIM.
Проблемой RIS всегда была репликация образов. При копировании файлов после SIS через сеть теряется SIS, поскольку это атрибут NTFS. Это означает, что имелись образы RISetup и RIPrep объемом 40 ГБ, которые реплицировались на другой сервер, и даже если средство поиска повторений SIS уменьшило их размер до 5 ГБ, выполнялась репликация 40 ГБ по сети. Для хранилища образов WDS это не так. Из-за архитектуры хранилища образов его фактически можно сохранить на сервере DFS и использовать репликацию DFS (DFS-R) для его репликации между узлами.
Особенности этого процесса различаются в зависимости от версии WDS. Для Windows Server 2003 см. главу 7 о работе с образами документации, которую можно загрузить с веб-узла go.microsoft.com/fwlink/?LinkId=81031. Для Windows Server 2008 см. Документ «Сохранение и репликация образов с помощью DFS» по адресу go.microsoft.com/fwlink/?LinkId=121960. Поскольку все ресурсы сохраняются в файле RWM даже при копировании группы образов между серверами, передаваемые данные – это только часть данных, которая была бы передана при передаче всех файлов WIM (или старой архитектуры SIS RIS).
Итак, когда создается новая группа образов и когда используется старая? Правила в основном совпадают с правилами для файла WIM. Хотя можно поместить образ Windows XP Professional с пакетом обновления 3 (SP3) в группу образов, преимущественно состоящую из образов Windows Server 2008, это не имеет особого смысла, поскольку экономится немного места. В случае файлов WIM потребуется группа образов по крайней мере для каждого следующего случая.
  • Каждый отдельный выпуск Windows — как SKU (Windows XP Professional), так и редакции пакетов обновления (пакет обновления 3 (SP3)).
  • Windows Server 2003 и более ранние версии: все локализованные выпуски (не многоязыковые интерфейсы). До Windows Vista® локализованные сборки включали абсолютно разные двоичные файлы, и поэтому их невозможно было успешно сохранить в файле WIM с точки зрения одного экземпляра.
  • Все пакеты обновления всех выпусков. Несмотря на то, что можно сохранить образы Windows Server 2008 и Windows Vista с пакетом обновления 1 (SP1) вместе, необходимо обдумать, целесообразно ли это в вашей организации.
Хранилище образов, даже больше чем SIS, успешно экономит пространство — как на диске, так и в сети, и обычно для поддержания его функциональности не требуется много усилий.

Одной из самых слабых сторон RIS было отсутствие масштабируемости. Многоадресное развертывание исправляет это. Под многоадресностью часто подразумевается «более быстрое» развертывание, но в действительности оно не более быстрое, а более «многочисленное». Через RIS можно выполнять развертывание нескольких систем. Фактически, RIS может выполнять одновременное развертывание около 75 систем.
Тем не менее, задолго до достижения такого количества это сильно скажется на производительности, и каждая установка будет выполняться значительно дольше. Что еще хуже, с увеличением количества установок увеличивается и вероятность возникновения сбоев. Одновременно с этим несколько установок перегружают сеть трафиком SMB (так, что во время развертывания для сотрудников могут быть недоступны важные сетевые ресурсы, например, Microsoft Exchange Server).
Многоадресность состоит в увеличении количества развертываний. Выполняется ли развертывание четырех серверов или конференц-центра со 100 системами, многоадресность позволяет выполнить развертывание относительно быстро, не загружая сеть. Хотя многоадресность можно использовать для развертывания одной системы, это возможно, только если преимущества масштабируемости используются несколькими системами, прослушивающими передачу.
Для использования многоадресности необходимы маршрутизаторы, поддерживающие многоадресность. Обычно это означает, что должно быть включено слежение протокола IGMP. Также необходима система Windows PE 2.1 (Windows Server 2008 RTM иди Windows Vista с пакетом обновления 1 (SP1)), поскольку в версии 2.0, поставляемой вместе с первоначальной окончательной версией Windows Vista, отсутствует возможность получения многоадресной передачи.
Кроме того, при наличии нескольких серверов WDS (или других многоадресных серверов) в одной сети должен быть указан пользовательский диапазон IP-адресов. Это можно просто изменить в оснастке MMC для WDS, щелкнув сервер правой кнопкой мыши, выбрав «Properties» (Свойства), а затем вкладку «Network Settings» (Параметры сети).
При выполнении многоадресной передачи многоадресный сервер может установить скорость получения самого медленного клиента или самый высокий уровень скорости и отключать клиентов с меньшей скоростью. Для обеспечения надежности WDS будет работать со скоростью самого медленного клиента-получателя.
Если скорость передачи ниже ожидаемой, выполните команду wdsutil /Get-MulticastTransmission/Show-clients. Будет определен основной клиент, регулирующий передачу. После этого можно отключить этот клиент, который вернется к использованию SMB вместо многоадресности. Пример сценария автоматического отключения медленных клиентов приведен на веб-узле go.microsoft.com/fwlink/?LinkId=121961.
Для создания многоадресной передачи можно правой кнопкой мыши щелкнуть «Образ установки» и выбрать «Создание многоадресной передачи» или правой кнопкой мыши щелкнуть «Многоадресные передачи» в консоли WDS и выбрать «Создание многоадресной передачи». После создания многоадресной передачи можно создать авторассылку или рассылку по расписанию. Авторассылка полезна при наличии нескольких регулярно подключающихся клиентов, для всех из которых необходим один образ; новые клиенты будут автоматически добавлены к текущей передаче, инициированной для первого клиента, запросившего образ установки. Рассылка по расписанию позволяет установить размер группы, по достижении которого начнется передача.
Также можно установить запуск передачи в определенное время. Клиенты, использующие многоадресную передачу, можно просмотреть, щелкнув имя образа. На правой панели отображаются сведения о подключенных к передаче клиентах.
Как правило, конечные пользователи будут использовать многоадресность из клиента установки WDS. Однако существует служебная программа командной строки, WDSMCast, поставляемая вместе с пакетом автоматической установки Windows (WAIK) для Windows Server 2008, которая позволяет запрашивать файл WIM через многоадресную передачу из WDS. Файл WIM должен быть полностью передан и применен к клиенту — поэтому необходимо убедиться в наличии достаточно свободного пространства на диске для сохранения и применения образа. В следующем месяце будет рассмотрена интеграция WDSMCast с собственным пользовательским процессом развертывания.

Ведение журнала WDS
WDS обладает значительными возможностями ведения журнала и трассировки, хотя многие возможности по умолчанию отключены для экономии места. Существует два типа регистрации событий — запись клиентов в журнал событий Windows и запись других аспектов WDS в журналы трассировки.
Однако в Windows Server 2008 по умолчанию WDS выполняет регистрацию в совсем небольшом объеме. Эти журналы доступны в меню «Администрирование» | «Просмотр событий». Журналы WDS доступны в средстве просмотра событий в меню «Журналы приложений и служб» | «Microsoft» | «Windows» | «Deployment-Services-Diagnostics» (Развертывание-службы-диагностика). Удобно то, что это те же журналы, которые доступны при просмотре роли WDS в MMC (см. рис. 6).
Рис. 6. Просмотр событий WDS в диспетчере серверов (Щелкните изображение, чтобы увеличить его)
Ведение журнала клиентом WDS (показано в журнала событий на рис. 6) может быть запущено путем запуска WDSUtil со следующими аргументами:
wdsutil /wdsclientlogging /enabled:yes /logginglevel:info
Кроме того, ведение журнала трассировки может быть запущено на нескольких различных подкомпонентах WDS. Для настройки трассировки установите соответствующее значение реестра типа DWORD в разделе(-ах) ресстра, показанных на рис. 7. Все журналы трассировки хранятся в каталоге \Windows\tracing. Затем необходимо перезагрузить соответствующий компонент для начала ведения журнала.
Рис. 7. Настройка ведения журнала трассировки
Компонент WDS | Раздел реестра | Значение реестра | Имя журнала
Сервер | HKLM\SOFTWARE\Microsoft\Tracing\WDSServer\EnableFileTracing | 1 | wdsserver.log
Многоадресность | HKLM\System\CurrentControlSet\Services\WDSServer\Providers\WDSMC\TraceDisabled | 0 | wdsserver.log
Компоненты управления | HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Tracing\WDSMGMT\EnableFileTracing | 1 | wdsmgmt.log
MMC | HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Tracing\WDSMMC\EnableFileTracing | 1 | wdsmmc.log
В WDS также есть счетчики производительности (описание доступно на веб-узле go.microsoft.com/fwlink/?LinkId=121962), за которыми можно наблюдать в случае возникновения проблем с производительностью системы (или для заблаговременного выполнения анализа производительности системы). Как отмечалось ранее, при возникновении неполадок можно получить более подробные сведения с помощью ключей /detailed, /verbose и /progress программы WDSUtil.
При возникновении проблем подключения клиентов WDS или их взаимодействия с сервером WDS можно использовать сетевой монитор Microsoft (Netmon), прекрасное средство для устранения неисправностей. Сетевой монитор доступен для загрузки на веб-узле go.microsoft.com/fwlink/?LinkId=121491.

Другие вопросы
Стоит упомянуть еще о нескольких пунктах. Первая из них память — помните, что служба WDS основана на Windows PE 2.x. Это означает, что клиентам WDS необходимо не менее 384 МБ ОЗУ — но для обеспечения оптимальной производительности рекомендуется наличие 512 МБ ОЗУ. Также необходимо помнить, что загрузка Windows PE 2.x в системах, не поддерживающих протокол ACPI, невозможна — и причиной этого не всегда является старое оборудование. Существуют относительно новые системы, не поддерживающие ACPI.
Имейте в виду, что эти системы также не поддерживают Windows Vista и Windows Server 2008. Для систем без поддержки ACPI необходима доступность Windows Server 2003 или более ранних версий WDS или RIS Server с соответствующим образом настроенными клиентами или установка Windows не через механизм PXE.
Наконец, помните, что при необходимости загрузки Windows PE 1.x с сервера также потребуется Windows Server 2003 или более ранние версии WDS или сервера RIS, поскольку службы WDS в Windows Server 2008 не могут загрузить образ Windows PE 1.x (RAMDisk или PXE).

Заключение
К данному моменту были рассмотрены история WDS, основные концепции и ряд сложных вопросов. В следующем месяце я рассмотрю некоторые пользовательские случаи использования WDS — в частности, возможность взаимодействия с WDS и настройка служб для выполнения необходимых задач, часто осуществляемая без использования WDS/существующей установки.

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


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

Cодержание
Перегрузка технологий обновления
Несовместимые сообщения безопасности
Всё о флажках
Призыв к оружию
В последних выпусках журнала TechNet Magazine, я говорил о том, как специалисты компьютерной безопасности и отрасль ИТ в широком смысле слова вводят в заблуждение потребителей и реально затрудняют работы по эффективной защите. В первых двух статьях этой серии я останавливался на таких вопросах, как решения, которые предоставляют вводящую в заблуждение информацию потребителям, перегружают
процесс входа в систему и вырабатывают у пользователя плохие навыки. Затем я показал множество различных примеров того, как отрасль в своем рвении показаться заинтересованной безопасностью пользователя реально делает ситуацию намного хуже, чем нужно. В данном третьем (и последнем) выпуске я покажу, как некоторые из наиболее важных доступных для пользователей технологий не оправдывают ожиданий, которые должны быть связаны у пользователей с этими решениями. Вот почему я призываю к оружию.

Перегрузка технологий обновления
Одним из основных принципов (фактически необсуждаемым требованием) для соблюдения электронной безопасности является необходимость поддерживать все обновления программного обеспечения. Почти каждый основной производитель программного обеспечения сейчас имеет несколько форм полуавтоматического механизма для поддержания как минимум некоторых своих продуктов на современном уровне. Однако на самом деле это не так просто.
Во первых, чем больше программного обеспечения у вас есть, тем большее его количество надо обновлять. И чем больше у вас поставщиков программного обеспечения, тем с большим количеством механизмов обновления вам приходится иметь дело. Это фактор путаницы.
Например, если вы только оставить параметры по умолчанию без изменения, обозреватель Internet Explorer®обновит сам себя. Но Internet Explorer на самом деле является лишь контейнером для других технологий. Потенциальное воздействие этого было продемонстрировано на конференции CanSecWest 2008г., когда Shane Macaulay (Шейн Маколей) использовал сочетание уязвимостей в Java и Adobe Flash, чтобы взломать «Макинтош». (Подробности на момент написания этой статьи были несколько скудны, так как эта уязвимость все еще не была раскрыта.) Моя точка зрения заключается в том, что никакая из этих технологий не является встроенным компонентом, и они обе доступны на большинстве компьютеров, так как широко используются в Интернете. Обе они представляют собой некоторую проблему по сохранению в актуальном виде — у каждой есть свой механизм обновления, хотя ни один из них не срабатывает очень часто.
Кроме того, большинство конечных пользователей просто не представляют, что эти технологии присутствуют и нуждаются в обновлении. Во многих случаях эти технологии были предоставлены в образе изготовителя на компьютере, который для потребителя неотличим от операционной системы. По мнению конечного пользователя, когда Windows® Update сообщает, что обновлений нет, то их нет.
Вторая проблема заключается в том, что механизмы обновления усложнены более, чем необходимо. Любой механизм обновления, который не имеет полностью автоматического режима, наверное, не получит большого распространения, так как пользователи в большинстве своем не в курсе, что им нужно запускать средство обновления. Далее, в большинстве случаев пользователь должен быть администратором, чтобы эти обновления запустить. И в самом худшем случае пользователь должен быть администратором, только чтобы получить уведомление о доступности обновления.
И, наконец, поставщики всё шире используют технологии программного обновления для развертывания совершенно постороннего программного обеспечения, которое пользователь не устанавливал — панелей инструментов и т.д. Технологии обновления программного обеспечения эволюционировали от узкой специализации для развертывания обновлений для програмного обеспечения до использования в качестве способа распространения дополнительного программного обеспечения.
Два бросающихся в глаза случая этого: служба обновлений корпорации Майкрософт (Microsoft® Windows Update) (показана на рис. 1) и обновления программного обеспечения корпорации Apple (Apple Software Update) (показано на рис. 2). Как корпорация Apple, так и Майкрософт выбрали использование своих механизмов не только для обновления программных продуктов, но и для развертывания нового программного обеспечения, которое пользователь изначально не устанавливал.
Рис. 1 Использование обновлений Windows для развертывания Silverlight (Щелкните изображение, чтобы увеличить его)
Рис. 2 Использование обновлений программного обеспечения корпорации Apple для развертывания Safari (Щелкните изображение, чтобы увеличить его)
В случае Apple вам будет предложены как iTunes, так и Safari, даже если вы установили только QuickTime. Интересно то, что они все также выбираются по умолчанию.
В случае обновлений Windows новейшее программное обеспечение, развертываемое при помощи службы обновлений, – это Silverlight™. Корпорация Майкрософт использовала эту технологию и в прошлом для распространения новых программных продуктов. К ее чести, корпорация Майкрософт по крайней мере не устанавливает по умолчанию флажок для установки нового программного обеспечения.
Этот подход по распространению нового программного обеспечения через механизмы обновления вызывает две проблемы для пользователей. Во-первых, у многих пользователей количество программного обеспечения на компьютере растет со временем. Как вы знаете, все программное обеспечение любого типа имеет ошибки, и некоторые из них могут привести к потенциальным уязвимостям, а некоторые из этих уязвимостей в конечном счете будут использованы в какого-либо рода атаках. В результате некоторое количество пользователей будут атаковано через программное обеспечение, в котором они не нуждаются или которое они даже не используют, но которое было развернуто на из компьютере механизмом обновлений.
Другим эффектом является то, что пользователи могут получить неверное представление о значении механизмов обновлений программного обеспечения. Если пользователи нашли, что механизмы обновления программного обеспечения используются для развертывания нового программного обеспечения в противоположность свежим обновлениям, они могут рассматривать механизмы обновлений как препятствие и прекратят их использование. Только представьте, что может чувствовать пользователь после того, как он был атакован через уязвимое место, пришедшее вместе с программой, которую он никогда не использует, но получил через механизм обновления программного обеспечения.
Мало что так опасно для здоровья и безопасности технологической экосистемы, как пользователи, теряющие веру в технологии, которые должны поддерживать безопасность. Единожды потеряв доверие пользователей, эти технологии будут отвергаться и в конечном счете выпадут из использования. Если технологии, настолько важные для защиты, насколько технологии обновлений, выйдут из доверия, вся технологическая экосистема будет в опасности. Именно ради защиты этой экосистемы корпорация Майкрософт распространяет обновления безопасности даже на компьютеры, на которых заведомо используется пиратское программное обеспечение.
Надо сказать, что я искренне уважаю ясный и специально сконструированный под задачу интерфейс обновлений обозревателя Mozilla Firefox, показанный нарис. 3. Я, конечно, надеюсь, что Mozilla продолжит уходить от соблазна распространения дополнительного программного обеспечения с помощью своего средства обновлений.
Рис. 3 Интерфейс обновления программного обеспечения для обозревателя Firefox — один из самых чистых в отрасли. (Щелкните изображение, чтобы увеличить его)

Противоречивые сообщения о безопасности
Было бы хорошо, если бы в отрасли были действительно приняты общие принципы формирования сообщений потребителям. Поскольку конкуренция в промышленности важна, потребители вынуждены понять, что для них следует значить безопасность. К несчастью, они не могут сделать этого, если в отрасли будет продолжаться рассылка конфликтующих сообщений. Откровенно говоря, я бы довольствовался компаниями, сообщения которых не противоречат друг другу.
Поскольку в отрасли, возможно, никогда не будут выработаны такие принципы формирования сообщений, есть как минимум необходимость быть последовательными и честными в сообщениях. Поскольку крайне важно, чтобы потребители продолжали доверять технологиям безопасности, в отрасли в целом это должно выполняться лучше.
Точно так же нужно узнать, что сегодня является по-настоящему полезным. Например, я не верю, что антивирусное программное обеспечение сейчас даже приблизительно так эффективно или является настолько важным, как заверяет отрасль. Рассмотрим компьютер, который использует мой семилетний сын, и компьютер на кухне. На обоих установлено антивирусное программное обеспечение, и за три года с момента его установки ни на одном из этих компьютеров не было никакой тревоги по какому-либо поводу. Я не хочу сказать, что нам следует отказаться от антивирусного программного обеспечения, — сейчас это ключевой компонент технологической экосистемы. Понятно, что если бы мы внезапно удалили всё антивирусное программное обеспечение, злоумышленники быстро воспользовались этим, и количество заражений увеличилось.
Ситуация сейчас такова, что в отрасли следует поднять вопросы о том, какие возможности в продуктах безопасности пользователям реально требуются, насколько эффективны эти возможности, и как компании могут донести эти потребности и пользу до потребителей. Как установлено, пользователи сейчас получают чрезвычайно много конфликтующих, преувеличенных и зачастую неверных сообщений о безопасности.

Всё о флажках
Например, отрасль программного обеспечения безопасности вся построена на наборах. Сегодня программное обеспечение безопасности распространяется практически только наборами по внешнему виду не связанных компонентов. И практически нет информации, какие из этих компонентов действительно нужны пользователям.
Это, по видимому, приводит к гонке по отметке большего количества позиций в контрольных списках. Поскольку контрольные списки предоставляют хороший способ сравнить продукты, они могут также привести к появлению компонентов, которые не необходимы или даже не желательны, или вовсе не имеют смысла. На рис. 4 – 7 показаны четыре различных списка отметок в контрольных списках от четырех различных поставщиков программного обеспечения безопасности. Будет ли надежным предположение, что продукт с 17 отметками лучше, чем продукт, у которого только 10 отметок?
Эти рисунки кажутся мне довольно забавными. На рис. 4 продукт получил отметку в контрольном списке за то, что он является новой версией. А продукт на рис. 5 получил отметку в контрольном списке вследствие того, что, по заявлению компании, «останавливает атаки с гнусных веб-узлов». Продукт на рис. 6 получил дополнительные очки вследствие того, что он «защищает детей в сети». Очевидно, никому не нужен продукт, который не сможет защитить детей. Победитель, однако, получил награду за изобретательность за наличие таких компонентов в наборе средств обеспечения безопасности, как очистка реестра и дефрагментация диска. Первый едва ли нужен вообще, а последний уже встроен в ОС. Фактически ОС Windows уже содержит решения для 15 из 17 контрольных отметок, показанных на рис. 7.
Рис. 4 Этот головной продукт получил только 10 контрольных отметок (Щелкните изображение, чтобы увеличить его)
Рис. 5 Этот продукт с 11 контрольными отметками должен быть лучше (Щелкните изображение, чтобы увеличить его)
Рис. 6 Держитесь, эти продукты имеют 12 контрольных отметок (Щелкните изображение, чтобы увеличить его)
Рис. 7 Но этот продукт с 17 контрольными отметками должен быть наилучшим решением, правда? (Щелкните изображение, чтобы увеличить его)
Кака видно, существуют некоторые тревожные тенденции. Эти продукты не только дублируют функциональность, которая уже включена в операционную систему (этот факт пока игнорируется в рекламной литературе), о них также делаются откровенно ложные заявления. Например, никакое программное обеспечение безопасности в мире не может действительно остановить атаки откуда-либо — оно только может помочь предотвратить их. Также никакой продукт не может реально скрыть ваше присутствие от атакующих.
Проблема в том, что бизнес программной безопасности в большой мере построен на защите пользователей от уязвимостей, привнесенных продуктами других производителей. Но эти производители постоянно совершенствуются в защите своих потребителей, и в результате отрасль программного обеспечения безопасности обнаруживает, что модель ее бизнеса находится под угрозой. Хотя отрасль программного обеспечения безопасности не может предложить очень многого при появлении новых рисков, все же поставщикам нужно помогать пользователям управлять риском, а не просто защищать от угроз, которые на самом деле больше угрозами не являются.

Призыв к оружию
Есть лишь одно положение, которое я бы рекомендовал читателям уяснить из этой серии из трех частей: мы как отрасль должны быть честными с пользователями и покупателями. Нужно рассказывать о рисках и о том, как пользователи могут исключить эти риски. И, в конечном счете, нужно начать оснащение людей для защиты от самих себя.
Наибольшее беспокойство во всех этих «решениях» доставляет то, что есть серьезная вероятность, что они будут очень сильно ухудшать безопасность в долгосрочной перспективе. Если пользователи и даже лица, ответственные за ИТ, на самом деле верят, что эти продукты положат конец реальным рискам безопасности, особенно всем рискам, которые они обманчиво обещают устранять, то можно потерять возможность научить людей, как реально защитить самих себя.
В качестве примера рассмотрим проверку подлинности пользователя по паролю. Если пользователи верят, что нестойкие надстройки для основанной на использовании пароля системе проверки подлинности, о которых я говорил в первой части этой серии, на самом деле их защитят, они могут еще больше расслабиться и использовать менее стойкие пароли. В худших случаях, которые я выделил в этой серии, эта технология на самом деле вынуждает пользователя использовать менее стойкую защиту, чем та, которая была бы использована в том случае, когда новая технология не была реализована. Это означает, что к тому времени, когда злоумышленики найдут, как поразить эти системы, что часто несложно, мы будем находиться даже в худшем состоянии, чем сейчас. Это может привести к серьезной проблеме доверия, в результате чего люди будут отказываться от решений, имеющих реальный смысл.
Сейчас нужно действовать для защиты технологической экосистемы, которая поддерживает наш бизнес. Новинки, конечно, должны приветствоваться, но также нужно быть очень осторожными, чтобы не позволить новинкам ради новинок заменить реальный анализ рисков. Иначе у нас будет только театр безопасности, и в конечном итоге этот театр рухнет вокруг нас.
Это остается верным для других примеров,о которых я уже говорил. Возьмите, например, что-нибудь приятное глазу, но ничего не значащее в плане безопасности,. Оно не принесет ничего хорошего пользователям, оно убаюкает их фальшивым чувством безопасности и позволит поставщикам услуг в Интернете пойти на оптимизации, которые реально нанесут косвенный урон пользователям. Между тем себестоимость предоставления адекватной информации пользователям составит всего несколько тысяч долларов или, возможно, десятков тысяч в самых крайних случаях. Является ли в действительности чрезмерной просьба к производителям потратить эту небольшую сумму на работу по защите их пользователей и бизнеса?
Это имеет множество последствий. Во-первых, должно быть изжито представление о том, что пользователи не способны принимать решения и их не следует к этому допускать. Пользователи способны научиться принимать решения. В конце концов, пользователи приняли множество решений, таких как решение о покупке компьютера или об использовании вашего узла, или о покупке одного из ваших продуктов или услуг. Подобно тому, как люди нуждаются в обучении безопасному вождению автомобиля, они должны также выучиться использовать компьютер безопасно. Сегодня атаки нацелены персонально на пользователя, и для принятия решений нельзя надеяться на технологии. Скорее, технологии безопасности должны являться системами поддержки принятия решений, предоставляя правдивую информацию в нужное время для того, чтобы пользователь смог принять разумное решение.
Некоторые из худших пользовательских интерфейсов в мире пришли из решений безопасности, так как эти приложения были спроектированы для того, чтобы либо скрыть от пользователя любое принятие решений, либо свалить на него (в неудобоваримом виде) все доступные данные. Никакой из этих подходов не работает. Первый ставит пользователя перед риском, так как от технологии не может зависеть правильный выбор. И если технология воспринимается как затрудняющая цели бизнеса пользователя, то через короткое время этой технологией перестанут пользоваться. Последний подход, между тем, не проходит из-за того, что люди не хотят ломать себе голову по поводу IP-адресов, идентификаторов процессов и других данных, которые для них ничего не значат. Они только хотят знать, что компьютер делает с их паролями и кредитными картами. Это, в конце концов, то, в чем на самом деле заключается безопасность.

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


Заметки разъездного инженера Инновации
Роми Махаян (Romi Mahajan),

В своей книге The Future of Management известный гуру менеджмента и специалист по стратегиям бизнеса Гари Хэмел (Gary Hamel) не согласен с тем, что долгосрочные сравнительные преимущества обуславливаются созданием культуры новаторства, которая сама является продуктом развития технологий управления. Поскольку сама отрасль бесчисленное число раз обновлялась и перестраивалась по множеству направлений, большинство компаний по-прежнему завязли в иерархической культуре управления. Это препятствует возникновению подлинно новаторской культуры просто потому, что она не позволяет эффективно использовать творческий подход и человеческий капитал.
Подобные иерархии являются проклятием для новаторства; в то же время творческие способности сотрудников, избавленные от оков, – основная движущая сила долгосрочных сравнительных преимуществ, обусловленных новаторством. Если творческие способности ограничены, до 80 процентов сотрудников не участвуют в том, чем они занимаются. Хэмел считает, что это не только ошибка бизнеса, но также и моральная ошибка.
На самом простом уровне в отрасли должен прозвучать громкий призыв к избавлению от избыточной иерархии. По существу аргумент является в корне антибюрократическим. Возможности по принятию решений существовать только у несведущих менеджеров и дирекции с толстыми кошельками.
Хэмел полагает, что источником новаторства является управление, а не ИТ. В конце концов, ИТ могут быть превращены в товар, и, следовательно, как они смогут реализовывать сравнительные преимущества? Если ИТ не являются источником новинок и увеличение производительности, бесперебойная работа, надежность, быстрый ввод новых приложений и единый вход (и т.д.) не могут реализовать сравнительные преимущества, о чем, в самом деле, мы все так беспокоимся?
Хотите ли вы заглянуть в душу своих отделов ИТ и компаний и убедиться, просто на всякий случай, в том, что Хэмел прав? Как можно убедиться в том, что ИТ не считается ценным товаром?
Я занимался реализацией лучших концепций Хэмела и использовал их, чтобы помочь отделам ИТ сохранить положение центров новаторства. В процессе этой работы я разработал теорию под названием «Новаторство изнутри». Оптимальное использование творческих способностей сотрудников и человеческого капитала является ключом к получению устойчивого сравнительного преимущества. Крупные организации должны сделать новаторство неотъемлемой частью своей деятельности. Организации должны поддерживать сообщество, а не бюрократию. И, что самое важное, часто управление препятствует новаторству — подлинное новаторство возможно только в случае развития управления.
Взглянем на организации ИТ. Сотрудники отдела ИТ, как правило, разумны и преданны своему делу, а также стремятся к достижению результатов. От них часто требуется выполнение больших объемов работы при меньших ресурсах, и они часто тратят более значительную часть времени на выполнение основной работы, что оставляет совсем немного времени на новаторство.
В моей концепции «Новаторство изнутри» теория Хэмела применяется в отношении ИТ. Ниже приведены основные принципы.
  • Учитывая присущий специалистам по ИТ творческий потенциал, в наших интересах создать модель управления ИТ, использующую эти творческие возможности.
  • Источником новаторства является постоянный и неблагодарный процесс анализа ошибок пробных версий, присущий ИТ.
  • Технические решения появляются при открытом и полном сотрудничестве с сообществом. ИТ может руководить этим процессом, начиная с самого себя!
  • Единственным источником сравнительных преимуществ в ИТ являются люди.
  • Управление ИТ должно перейти от внимания к проекту и бюджету к новой, замечательной ориентации на управление новаторством.
  • ИТ должны быть связаны не со снижением затрат, а с получением отличных результатов.
Вы готовы поверить в эту теорию? Можем ли мы применить эту концепцию «Новаторство изнутри» и показать, что отделы ИТ – подходящее место для проведения этого грандиозного эксперимента? Готовы ли менеджеры уступить свои полномочия собственным сообществам? Готово ли руководство сдать свои полномочия в пользу нашего коллективного гения?

Роми Махаян – старший специалист по маркетингу компании Ascentium Corporation. До перехода в компанию Ascentium он более семи лет проработал в корпорации Майкрософт, где его последней должностью был пост директора по техническому аудиту и платформенному маркетингу. Роми имеет множество публикаций в областях технологии, политики, экономики и социологии.


О Windows из первых рук Windows 95 неофициально
Рэймонд Чен (Ramond Chen)

Несмотря на то, что для сборки 32-разрядных программ для Windows® 95 можно использовать обычный 32-разрядный компилятор, а для 16-разрядных программ – обычный 16-разрядный компилятор, для сборки самой операционной системы Windows 95 был необходим специальный компилятор, понимающий оба мира 32 и 16 разрядов и способный соединить их. Для сборки системы Windows 95 также был необходим специальный компоновщик, способный собирать эти два типа кода, а также компоновщик для файлов VxD (формат драйвера для Windows 95).
В обеспечении этих специальных компиляторов и компоновщиков команда разработчиков Windows 95 полагалась на подразделение языков и средств. Я уверен, что подразделение языков посчитало этот запрос странным: «Вы хотите, чтобы мы написали компилятор, выполняющий X, Y и Z, и который предназначается для компилирования всего двух библиотек DLL?». Именно так. Но это были, в конце концов, две очень важные библиотеки DLL.
Несмотря на очевидную абсурдность запроса, подразделение языков и средство оказало поддержку, и узкоспециализированные компилятор и компоновщик стали частью процесса сборки Windows 95. Конечно, компилятор был создан не сразу. Команда разработчиков Windows получила предварительную версию, после чего периодически получала обновления с внедренными оптимизациями и исправленными ошибками.
Однажды работа над сборкой Windows 95 неожиданно замедлилась. Компоновка файла, обычно длившаяся несколько секунд, неожиданно заняла несколько минут. Файл по-прежнему был создан успешно, но процесс создания длился очень долго. И это происходило не только на компьютере одного разработчика — проблема коснулась всей команды. Возникла ли в коде какая-то патология, связанная с компоновщиком? Или, может быть, мы столкнулись с ошибкой компоновщика?
После определенной отладки мы выявили источник проблемы. В последней версии компоновщика содержался определенный код диагностики, который сотрудники подразделения языков забыли удалить перед передачей кода группе разработчиков Windows. Этот код диагностики регистрировал результаты работе в файле, хранящемся на компьютере, который был расположен в офисе группы компиляции. А этот компьютер оказался выключенным. (Вспоминается Лесли Лампорт (Leslie Lamport), который отлично описал распределенную систему как систему, работа в которой невозможна из-за того, что компьютер, о котором вы никогда не слышали, выключен.)
Эта версия компоновщика успешно проработала несколько недель. Каждый раз, когда кто-либо пытался скомпоновать VxD при сборке Windows 95, выполнялось обновление файла, который находился на компьютере разработчика. Пока компьютер был включен и подключен к сети, никто ничего и не замечал. Но однажды компьютер выключили, и работа сильно замедлилась.
После выявления проблемы сотрудникам отдела компиляции потребовалось не слишком много времени, чтобы предоставить группе разработчиков Windows исправление, удалявшее код диагностики из компоновщика.
Существует несколько концовок этой истории, в зависимости от того, кто ее рассказывает. Мой вариант: «А потом разработчик этого компилятора перешел в команду разработки Windows и перестал быть моим начальником.» Я часто рассказываю эту историю в форме доброй шутки.
Однако если эту историю рассказывает мой начальник, ее концовка совсем другая: «И оказалось, что я даже не писал этот код диагностики. Это был один из моих коллег, решивший, что вместо заполнения своего компьютера диагностической информацией он лучше будет заполнять мой!»

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