 TechNet Magazine December 2007

TechNet Magazine December 2007

Связь: 16 новых возможностей сервера Exchange Server 2007 с пакетом обновления 1

В отличие от обычного пакета обновления пакет обновления 1 для сервера Exchange Server 2007 — это не просто набор исправлений и обновлений для системы безопасности. Ниже приведен обзор некоторых наиболее важных новых функций и возможностей, предлагаемых в пакете обновления 1 (SP1).

Tony Smith Связь: Резервная непрерывная репликация в Exchange Server 2007 с пакетом обновления 1

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

Scott Schnoll Связь: Работа с Exchange Server в операционной системе Windows Server 2008

Готовы к использованию Exchange Server в операционной системе Windows Server 2008? Группа разработчиков Microsoft Exchange Server уже имеет опыт работы в этой среде, и Пол Боуден готов поделиться накопленными знаниями, а также дать советы о том, как лучше провести подготовку к эксплуатации.

Paul Bowden Связь: Развертывание единой системы обмена сообщениями на сервере Exchange Server 2007

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

Jeff Goodwin Безопасность: Руководство по основам расследований на компьютерах

Узнайте о недорогих и простых способах расследования на компьютерах.

Tom Cloward and Frank Simorjay Сети: Отчет корпорации Майкрософт по безопасности

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

Tim Rains Сети: Выявление скрытых неполадок в сети

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

Christopher Stoneff От редактора: Давайте начнем разговор

Joshua Hoffman Письма: Мнения читателей

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

Greg Steen Вопросы и ответы по SQL: Настройка памяти, профилирование производительности, выбор коэффициента заполнения и многое другое

Edited by Nancy Michell Обзор служебных программ: Средство для оценки системы безопасности Microsoft Security Assessment Tool

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

Lance Whitney Кабельщик: Сервер политики сети

Служба сервера политики сети (NPS) в операционной системе Windows Server 2008 замещает службу проверки подлинности в Интернете (IAS), которая использовалась в Windows Server 2003. В новую службу внесено множество усовершенствований, начиная с возможности принудительного применения требований к уровню работоспособности системы и заканчивая улучшенными возможностями управления.

Joseph Davies Windows PowerShell: Копнем глубже

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

Don Jones Эй, автор сценариев!: Возвращение WinRM

Сделал ли это дворецкий? Находилось ли это в кладовке рядом с подсвечником? Вы не найдете здесь ответы на эти вопросы. Но после длительного четырехнедельного перерыва авторы сценариев предлагают вторую и последнюю часть своей серии статей об удаленном управлении Windows.

The Microsoft Scripting Guys На страже безопасности: Политики паролей доменов Windows

До настоящего времени в Windows поддерживалась только одна политика паролей в домене. В Windows Server 2008 поддерживается несколько политик паролей, благодаря чему администраторы могут настроить различные политики для разных типов пользователей.

Derek Melber Материалы о рабочей среде: Развертывание Windows в виртуальном мире

Вы задумывались о виртуализации? Если нет, стоит задуматься. Узнайте, что необходимо для развертывания виртуальных систем, чего следует избегать и как виртуализация работает.

Wes Miller Заметки на полях: Перспективы взаимозаменяемости

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

Romi Mahajan Конфиденциальная информация Windows: Джойстику не нужно быть микроволновой печью

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

Raymond Chen


 Связь: 16 новых возможностей сервера Exchange Server 2007 с пакетом обновления 1
Связь Тони Смит (Tony Smith)

16 новых возможностей сервера Exchange Server 2007 с пакетом обновления 1
Краткий обзор:
  • Новые возможности управления
  • Улучшенные роли сервера
  • Усовершенствованная роль сервера единой системы обмена сообщениями

Большинство администраторов знают, как загружать и устанавливать пакеты обновления для серверов и настольных компьютеров. Подобные пакеты обновления, естественно, содержат исправления и обновления для системы безопасности, которые
позволяют поддерживать системы в актуальном состоянии. Однако в некоторых случаях пакет обновления предлагает нечто большее. Предстоящий выпуск пакета обновления для сервера Microsoft Exchange Server 2007 ® — это именно тот случай, когда пакет обновления включает множество новых замечательных возможностей.
Файл, который будет доступен для загрузки по адресу go.microsoft.com/fwlink/?LinkId=91472, можно будет использовать как для полной установки сервера Exchange Server 2007 (включая пакет обновления 1), так и для обновления уже установленного сервера Exchange Server 2007. Хотя сервер Exchange Server 2007 с пакетом обновления 1 (SP1) предназначен для установки в операционной системе Windows Server® 2003 (версии с пакетом обновления 1 (SP1), пакетом обновления 2 (SP2) и R2), он совместим с предстоящим выпуском операционной системы Windows Server 2008.
В пакете обновления 1 содержится гораздо больше новых возможностей и усовершенствований, чем можно охватить в данном кратком обзоре. Таким образом, мне пришлось составить список наиболее значимых изменений, с помощью которых можно существенно усовершенствовать среду Exchange. Подробные сведения обо всех изменениях см. в статье "Новые возможности сервера Exchange Server 2007 с пакетом обновления 1 (SP1)" по адресу technet.microsoft.com/bb676323.aspx.

Изменения в консоли управления Exchange
Пакет обновления 1 вносит в консоль управления Exchange, приведенную на рис. 1, ряд новых удобных функций. Во-первых, «Панель инструментов» — набор средств для диагностики, устранения неполадок и восстановления, устанавливаемый по умолчанию совместно с сервером Exchange Server 2007, — теперь включает консоль управления общими папками, редактор шаблонов сведений и средство просмотра журнала маршрутизации.
Figure 1 Exchange Management Console with Service Pack 1
Figure 1 Exchange Management Console with Service Pack 1
Консоль управления Exchange, консоль управления общими папками, редактор шаблонов сведений и средство просмотра очереди можно использовать для экспорта списков из области результатов и рабочей области. Списки можно экспортировать в следующих форматах: «Текст (разделитель — табуляция)», «Текст (разделитель — запятая)», «Текст в кодировке Юникод (разделитель — табуляция)» и «Текст в кодировке Юникод (разделитель — запятая)». В дополнение к возможности фильтрации данных в области результатов консоли управления Exchange теперь можно фильтровать данные в областях результатов консоли управления общими папками, редактора шаблонов сведений и средства просмотра очереди.
Однако наиболее примечательно то, что консоль управления Exchange теперь включает целый ряд новых интерфейсов управления (например вышеупомянутую консоль управления общими папками). Эти возможности будут описаны отдельно далее.

Поддержка протокола IPv6
Одновременно с поддержкой операционной системы Windows Server 2008 обеспечена поддержка протокола IPv6 (Internet Protocol версии 6). Естественно, такая поддержка обеспечивается только при установке сервера Exchange Server 2007 в операционной системе Windows Server 2008 с включенной поддержкой обоих стеков протокола IPv4 и IPv6. Если перед установкой сервера Exchange Server 2007 отключить поддержку протокола IPv4, протокол IPv6 поддерживаться не будет.
IP-адреса и диапазоны IP-адресов можно вводить как в формате IPv4, так и в формате IPv6. Все роли серверов, за исключением одной, могут отправлять и принимать данные от устройств, серверов и клиентов, использующих адреса в формате IPv6. Единственным исключением является роль сервера единой системы обмена сообщениями. Это связано с ограничениями некоторых обязательных компонентов телефонии и речевых служб роли сервера единой системы обмена сообщениями.

Графический интерфейс для управления протоколами POP3 и IMAP4
Консоль управления Exchange включает новый графический интерфейс для администрирования протоколов POP3 и IMAP4. С помощью данного графического интерфейса можно настроить все параметры протоколов POP3 и IMAP4 для сервера клиентского доступа, включая параметры портов, параметры проверки подлинности и параметры подключения. На рис. 2 показано диалоговое окно для настройки свойств протокола IMAP4; такое же диалоговое окно доступно для протокола POP3.
Figure 2 Exchange Management Console for POP3/IMAP4
Figure 2 Exchange Management Console for POP3/IMAP4

Более надежное управление почтовым ящиком
С помощью консоли управления Exchange теперь можно массово создавать почтовые ящики для существующих учетных записей пользователей. В то же время с помощью новых мастеров администраторы могут предоставлять или удалять права на полный доступ к почтовому ящику и настраивать для почтового ящика права отправки сообщения от имени другого пользователя.

Новые возможности управления данными почтового ящика
Администратор теперь может импортировать и экспортировать PST-файлы для управления данными почтового ящика. Эти операции также можно выполнять в командной консоли Exchange с помощью командлетов Import-Mailbox и Export-Mailbox, соответственно.
Управление записями сообщений теперь можно применять к управляемым папкам по умолчанию, размещенным на сервере Exchange со стандартной клиентской лицензией Exchange. (Обратите внимание на то, что для управления записями сообщений для настраиваемых управляемых папок по-прежнему требуется корпоративная клиентская лицензия Exchange). С помощью нового параметра RemoveManagedFolderAndPolicy командлета Set-Mailbox можно удалить для почтового ящика все политики управления записями сообщений, удалить свойства управления записями сообщений для любых управляемых папок, созданных в рамках политики управления записями сообщений, примененной к почтовому ящику, и преобразовать любые управляемые папки в стандартные папки.
С помощью новых счетчиков производительности для системного монитора можно получать различные сведения об оперативной дефрагментации, а именно: время последнего запуска оперативной дефрагментации, продолжительность дефрагментации и результаты ее выполнения. Эти сведения весьма полезны для оптимизации интервала между запусками оперативной дефрагментации.

Подтверждение удаленной очистки
С помощью возможностей сервера Exchange Server 2007 администратор или обычный пользователь может удаленно очистить всех данные на мобильном устройстве, что весьма удобно в случае утраты или кражи устройства. После установки пакета обновления 1 пользователю отправляется сообщение с запросом на подтверждение удаленной очистки устройства. Если запрос на удаленную очистку был отправлен пользователем (с помощью Outlook® Web Access), этому пользователю по электронной почте будет отправлено сообщение с запросом подтверждения. Если такой запрос был отправлен администратором (с помощью консоли управления Exchange), сообщение будет отправлено и администратору, и пользователю.

Более надежное управление клиентом Outlook Web Access
В почтовый клиент с веб-интерфейсом было внесено множество усовершенствований, облегчающих обмен сообщениями для сотрудников, работающих вне офиса. После установки пакета обновления 1 (SP1) пользователи Outlook Web Access могут создавать и изменять личные списки рассылки, а также правила на сервере. Кроме того, пользователи смогут использовать корзину и восстанавливать удаленные элементы.
В пользовательский интерфейс были добавлены команды перемещения и копирования, позволяющие пользователям перемещать и копировать папки с помощью контекстного меню для списка правил. Отдельные элементы в папках сообщений и общих папках теперь также можно перемещать и копировать с помощью контекстного меню списка элементов или с помощью значка на панели инструментов.
Полный доступ пользователей Outlook Web Access к общим папкам теперь осуществляется без использования виртуального каталога /public, вследствие чего отпадает необходимость в фоновом сервере Exchange 2003. Также в Outlook Web Access появилась возможность поиска в общих папках.
С помощью функции S/MIME пользователи теперь могут читать и создавать подписанные и зашифрованные сообщения электронной почты (см. рис. 3). В пакете обновления поддерживается даже API-интерфейс криптографии следующего поколения (CNG) и криптографические алгоритмы набора Suite-B. Одновременно с этим интерфейс Outlook Web Access можно настроить для эффективной интеграции с пользовательскими приложениями.
Figure 3 S/MIME message settings
Figure 3 S/MIME message settings

Отслеживание создания записей в Outlook Web Access Light
Outlook Web Access Light — облегченная версия Outlook Web Access, предназначенная для работы практически со всеми веб-обозревателями, — теперь отслеживает действия пользователя при создании им длинной записи любого типа (например сообщения или элемента календаря), чтобы сеанс не завершился (что привело бы к потере данных), пока пользователь вводит данные. Кроме того, сообщения автоматически сохраняются в папку «Черновики», если форма создания сообщения открыта, а сеанс завершается из-за бездействия пользователя.

Повышение производительности технологии Direct Push
В технологии Direct Push используется HTTPS-соединение между мобильным устройством и сервером Exchange Server 2007. В пакете обновления 1 для сервера Exchange Server 2007 размер заголовков запроса и отклика HTTPS сокращен, что позволяет уменьшить объем данных, отправляемых и принимаемых с мобильного устройства.

Управление общими папками
С помощью новой консоли управления общими папками, показанной на рис. 4, администраторы могут создавать, настраивать и обслуживать общие папки из консоли управления Exchange. Списки адресов, политики адресов электронной почты, динамические группы рассылки и списки рассылки — все это связано с общими папками. При предварительном просмотре списка адресов, политики адресов электронной почты, динамической группы рассылки и получателей группы рассылки теперь можно увидеть общие папки с включенной поддержкой почты, соответствующие критериям членства в группе.
Figure 4 Public Folder Management Console
Figure 4 Public Folder Management Console
С помощью консоли управления общими папками сервера Exchange Server 2007 с пакетом обновления 1 (SP1) можно настраивать права администратора для общих папок. Это также можно сделать, добавив пользователя в роль администратора общих папок с помощью командлета Add-ExchangeAdministrator или мастера добавления администратора Exchange, либо предоставив или удалив конкретные права для общих папок с помощью командлета Add-PublicFolderAdministratorPermission.

Улучшенная обработка и маршрутизация сообщений
Развернутые в лесу Active Directory® , транспортные серверы-концентраторы обрабатывают весь поток почты внутри организации, применяют правила транспорта и правила журнала, а также выполняют доставку сообщений в почтовые ящики получателей. Сообщения, отправляемые в Интернет, ретранслируются транспортным сервером-концентратором на пограничный транспортный сервер, расположенный в демилитаризованной зоне. Эти роли сервера в пакете обновления 1 усовершенствованы.
Благодаря функции мониторинга системных ресурсов сервера Exchange Server 2007 («Обратное давление») транспортные серверы-концентраторы и пограничные транспортные серверы могут адекватно реагировать на высокую загрузку ресурсов. В пакете обновления 1 требования к свободному месту на диске были существенно снижены (с 4 ГБ до 500 МБ).
В пакете обновления 1 увеличено количество параметров конфигурации транспорта в консоли управления Exchange. Адресное пространство X.400 теперь можно настроить в качестве уполномоченного домена (также поддерживаются длинные адреса X.400).
На транспортном сервере-концентраторе поддерживается очереди с приоритетами. Приоритет, назначенный сообщению пользователем Outlook, учитывается классификатором сообщений, гарантируя таким образом, что сообщения с высоким уровнем важности будут доставлены быстрее сообщений с низким уровнем важности.
В пакете обновления 1 для сервера Exchange Server 2007 настройка области действия соединителя отправки для отдельного сайта Active Directory упрощена благодаря новому параметру IsScopedConnector командлетов командной консоли Exchange и флажку «Соединитель отправки с областью действия». Если для соединителя отправки указана область действия, такой соединитель будет рассматриваться при определении маршрута только теми транспортными серверами-концентраторами, которые расположены на том же веб-узле Active Directory, что и исходные серверы данного соединителя.

Усовершенствования процесса синхронизации пограничных транспортных серверов
В сервере Exchange Server 2007 с пакетом обновления 1 (SP1) для немедленного запуска синхронизации данных между Active Directory и службой каталогов ADAM (Active Directory Application Mode) используется командлет Start-EdgeSynchronization. В сервере Exchange Server 2007 с пакетом обновления 1 (SP1) для этого командлета поддерживается параметр Server, позволяющий выполнить командлет с удаленного компьютера.
Для диагностического командлета Test-EdgeSynchronization, возвращающего состояние синхронизации пограничных транспортных серверов, был добавлен новый параметр, позволяющий проверить результаты синхронизации для отдельных пользователей.

Клонирование объектов TransportConfig
С помощью клонированных сценариев администраторам значительно проще выполнить согласованную настройку нескольких пограничных транспортных серверов, развернутых в организации. В пакете обновления 1 объект TransportConfig, управляющий параметрами сервера для роли пограничного транспортного сервера, теперь включен в клонируемые данные о конфигурации. Включение этого объекта значительно упрощает процедуры развертывания, резервного копирования и восстановления сервера.

Усовершенствования единой системы обмена сообщениями
Единая система обмена сообщениями была одним из самых значимых компонентов первоначального выпуска сервера Exchange Server 2007. В пакете обновления 1 в этот компонент добавлено множество новых функций, а имеющиеся функции — усовершенствованы. Для некоторых возможностей требуется развернуть сервер Office Communications Server 2007 в том же лесу Active Directory, но для большинства функций этого не требуется. В данной статье невозможно рассказать обо всех изменениях, внесенных в единую систему обмена сообщениями, поэтому я вкратце опишу наиболее значимые. Дополнительные сведения о единой системе обмена сообщениями см. в статье «Развертывание единой системы обмена сообщениями в сервере Exchange Server 2007» данного выпуска журнала TechNet Magazine .
Рассмотрим сначала новые возможности, требующие развертывания сервера Office Communications Server 2007. Появилась поддержка высококачественных голосовых сообщений и потоков медиа в обход брандмауэров. Также появилось уведомление о переадресации, когда пользователь оставляет голосовое сообщение, а удаленная сторона использует переадресацию звонков. Пользователи теперь могут использовать голосовой доступ к Outlook из Office Communicator 2007 без ввода ПИН. Появилась возможность интеграции сообщений электронной почты, уведомляющих о пропущенных звонках, и уведомлений голосовой почты с Office Communicator 2007 (см. рис. 5), и многое другое.
Figure 5 Voicemail notification in Office Communicator
Figure 5 Voicemail notification in Office Communicator
Одно из усовершенствований единой системы обмена сообщениями, не требующих развертывания сервера Office Communications Server, заключается в поддержке протокола SRTP (Secure Realtime Transport Protocol). В первоначальном выпуске сервера Exchange Server 2007 было два режима безопасности: небезопасный и безопасный. В безопасном режиме шифровался только трафик протокола SIP (Session Initiation Protocol), а трафик протокола RTP оставался незашифрованным. В пакете обновления 1 используются три режима: небезопасный, безопасный режим SIP и безопасный. В безопасном режиме SIP шифруется только трафик протокола SIP, а не протокола RTP. В безопасном режиме шифруется трафик обоих протоколов, SIP и RTP. С помощью консоли управления Exchange также можно настроить функцию MTLS (Mutual Transport Layer Security) для абонентских групп.
Среди других изменений, внесенных пакетом обновления 1, следует отметить новый мастер включения единой системы обмена сообщениями, с помощью которого можно добавить для пользователя адрес SIP или E.164; возможность настройки типа универсального кода ресурса (URI) для абонентской группы с помощью консоли управления Exchange и поддержку качества обслуживания (QoS) с использованием приоритезированных служб для маркировки трафика медиа.

Повышение уровня доступности
В пакет обновления 1 включено несколько новых функций, повышающих уровень доступности, а также усовершенствованы существующие функции обеспечения высокого уровня доступности. Новые и усовершенствованные функции расширяют возможности сценариев, предназначенных для обеспечения доступности данных и служб для ролей сервера Exchange Server 2007. С помощью новых сценариев можно отделить в организациях сценарии для обеспечения высокого уровня доступности от сценариев для обеспечения устойчивости узлов и разворачивать конфигурации, связанные с конкретными потребностями организации в каждой отдельной области.
Во-первых, благодаря поддержке операционной системы Windows Server 2008 можно использовать отказоустойчивые кластеры, расположенные в нескольких подсетях, а также новые модели кворума (диск-свидетель и файловый ресурс-свидетель). Также значительно улучшены возможности создания отчетов и наблюдения за кластером, включая дополнительные функции, предназначенные для упреждающего наблюдения за средами с непрерывной репликацией. Одновременно с этим усовершенствования в области производительности включают сокращение количества операций ввода-вывода на дисках с пассивными копиями групп хранения, повышение скорости копирования файлов журнала и скорости перемещения кластерных серверов почтовых ящиков между узлами.
Наконец, в пакет обновления добавлены новые мастера, упрощающие управление и настройку (см. рис. 6), а также новые элементы пользовательского интерфейса для управления кластерными серверами почтовых ящиков, включая вкладку «Кластерный сервер почтовых ящиков» и страницу настройки кластера с непрерывной репликацией.
Figure 6 Manage Clustered Mailbox Server Wizard
Figure 6 Manage Clustered Mailbox Server Wizard

Резервная непрерывная репликация
В резервной непрерывной репликации для расширенного развертывания и настройки используются те же технологии доставки и преобразования журналов, что и в локальной непрерывной репликации и кластерной непрерывной репликации. Резервная непрерывная репликация подобна локальной непрерывной репликации и кластерной непрерывной репликации, но обладает при этом собственными уникальными характеристиками. Подробные сведения о резервной непрерывной репликации см. в моей статье «Резервная непрерывная репликация в сервере Exchange Server 2007» в данном выпуске журнала TechNet Magazine.

Заключение
Пакет обновления 1 для сервера Exchange Server 2007, очевидно, представляет собой намного больше, чем просто набор исправлений и обновлений для системы безопасности. Он содержит множество новых функций и усовершенствований, которыми вскоре можно будет воспользоваться. Объем статьи не позволяет рассказать обо всех новых функциях и усовершенствованиях, но я надеюсь, что эта статья дает неплохое представление об этих возможностях. Подробные сведения обо всех изменениях, внесенных пакетом обновления 1, а также файлы для загрузки, веб-трансляции и форумы для обсуждения доступны на странице сервера Exchange Server веб-узла TechCenter по адресу technet.microsoft.com/exchange.

Тони Смит (Tony Smith) — ведущий технический писатель группы по обучению пользователей сервера Exchange Server, специализирующийся на единой системе обмена сообщениями. До перехода в корпорацию Майкрософт Тони работал сетевым инженером, поставщиком для корпорации Майкрософт и в качестве сертифицированного преподавателя Майкрософт. Он также разработал несколько проектов для программы обучения Microsoft Learning, включая книги и методические указания для лабораторных работ.
© 2007 Корпорация Майкрософт и компания CMP Media, LLC. Все права защищены; полное или частичное воспроизведение без разрешения запрещено.


 Связь: Резервная непрерывная репликация в Exchange Server 2007 с пакетом обновления 1
Связь Скотт Шнолль (Scott Schnoll)

Резервная непрерывная репликация в Exchange Server 2007 с пакетом обновления 1
Краткий обзор:
  • Настройка резервной непрерывной репликации
  • Важность дублирования
  • Снижение простоев с помощью резервной непрерывной репликации

В пакете обновления 1 для Exchange 2007 предусмотрено несколько новых функций. Одна из них — резервная непрерывная репликация (SCR) — обеспечивает повышенную устойчивость и дублирование данных в центрах данных. Из названия этой функции ясно, что она предназначена
для ситуаций, когда используются резервные серверы восстановления.
Если вы знакомы с основной коммерческой версией Exchange 2007 (RTM), то вы знаете, что в ней также поддерживается повышенная устойчивость и дублирование посредством доставки журналов, а также кластеры Windows® для переключения при сбое. В этой версии доставка журналов (ее официальное название — непрерывная репликация) доступна в двух видах: локальная непрерывная репликация (LCR), приведенная на рис. 1, и кластерная непрерывная репликация (CCR), приведенная на рис. 2.
Figure 1 Local continuous replication
Figure 1 Local continuous replication
Figure 2 CCR is log shipping to a second server in a Windows failover cluster
Figure 2 CCR is log shipping to a second server in a Windows failover cluster
Непрерывная репликация обеспечивает доступность данных и их дублирование, поскольку при ее использовании администраторы могут поддерживать копию каждой базы данных почтовых ящиков. Эта копия базы данных применяется для защиты от сбоев, утраты или повреждения данных в рабочей базе данных. Копию базы данных можно активировать и превратить в рабочую базу данных всего за несколько минут: не нужно тратить время на поиски ленточного накопителя с резервной копией с целью восстановления данных.
Резервная непрерывная репликация обеспечивает более широкие возможности по обеспечению доступности данных и служб. В новых условиях можно отделить топологии высокой доступности от топологий дублирования узлов, а также можно развертывать конфигурации, соответствующие потребностям организации во всех областях.
!В коммерческой версии Exchange 2007 (RTM) поддерживается дублирование в центре данных и устойчивость узлов, но поскольку репликация LCR и CCR поддерживает только одну копию каждой базы данных, приходится выбирать между дублированием и устойчивостью. В качестве примера рассмотрим функции доступности данных и служб в CCR. Развертывание активного и пассивного узлов в одном центре данных обеспечивает доступность службы и данных в этом центре данных, но не обеспечивает устойчивости (поскольку оба узла находятся физически в одном месте). Развертывание активного узла в одном центре данных, а пассивного узла — во втором центре данных обеспечивает устойчивость, но не обеспечивает доступность в центре данных, так как пассивный узел, обеспечивающий доступность, находится в другом центре данных).
В пакете обновления 1 поддерживается репликация SCR. Такая репликация позволяет создать дополнительные копии каждой базы данных, а значит, высокая доступность и устойчивость не исключают друг друга. Например, как показано на рис. 3, можно использовать SCR вместе CCR для локальной репликации групп хранения в основном центре данных (используя CCR для обеспечения доступности) и для удаленной репликации во втором или резервном центре данных (используя SCR для обеспечения устойчивости). Во втором центре данных находится резервный кластер, который можно активировать и быстро настроить в качестве дублирующего кластерного сервера почтовых ящиков при восстановлении узла.
Figure 3 CCR deployed in Redmond datacenter and SCR deployed in Quincy datacenter
Figure 3 CCR deployed in Redmond datacenter and SCR deployed in Quincy datacenter
На рис. 3 показана структура развертывания в организации с двумя центрами данных, каждый с собственным узлом Active Directory®: Redmond и Quincy. Узел Redmond находится в основном (рабочим) центре, а узел Quincy находится во втором (резервном) центре данных. На узле Redmond развертывается репликация CCR для обеспечения дублирования. Целевые объекты SCR и элементы инфраструктуры, необходимые для Exchange 2007, настраиваются на резервном кластере на узле Quincy для обеспечения устойчивости. К дополнительным элементам инфраструктуры относятся: сервер клиентского доступа, транспортный сервер-концентратор, сервер Active Directory, DNS-сервер и сервер доступа к Интернету. Эти элементы могут быть выделенными или совместными ресурсами. Выделенные ресурсы поддерживают только пользователей центра данных, в котором находятся эти ресурсы. Совместные ресурсы поддерживают пользователей и локального центра данных, и других центров данных. Решение о том, следует ли применять выделенные или совместные ресурсы, зависит от потребностей вашей организации. Дополнительные сведения о таких ресурсах см. в разделе справки Exchange Server 2007 «Site Resilience Configurations» по адресу technet.microsoft.com/bb201662.aspx. Обратите внимание на использование нового типа кворума — набора узлов большинства (MNS). В Exchange Server 2007 репликация CCR использует кворум MNS и файловый ресурс-свидетель (FSW) вместо традиционного узла голосования, как показано на рис. 3.
На рис. 4Изображена среда с CCR и SCR. Эта среда обеспечивает несколько уровней дублирования для почтовых ящиков и служб, размещенных на сервере EXCLUS1. Эти почтовые ящики защищены от критических сбоев любого масштаба.
Figure 4 Standalone mailbox servers using SCR to replicate storage groups to each other
Figure 4 Standalone mailbox servers using SCR to replicate storage groups to each other
Репликация SCR также может использоваться в небольших и средних организациях. Например, как показано на рис. 4, в организации можно развернуть два отдельных сервера почтовых ящиков (EXMBX1 и EXMBX2) и использовать SCR для репликации некоторых или всех групп хранения с одного сервера на другой.
В этом примере EXMBX1 и EXMBX2 — рабочие серверы с пятью активными группами хранения. Каждая группа хранения является исходным объектом SCR для целевого объекта SCR на другом сервере. В случае сбоя хранилища или любого другого события, при котором группа хранения, настроенная в качестве исходного объекта SCR, станет недоступной, можно быстро активировать копию целевого объекта SCR с помощью нескольких административных задач оболочки управления Exchange. При использовании Microsoft® Office Outlook® 2007 и функций переноса базы данных и автообнаружения Exchange 2007 время простоя при сбое активной группы хранения (или нескольких активных групп хранения) составит всего несколько минут.

Исходные и целевые объекты SCR
Как и в LCR и CCR, в репликации SCR также используются понятия активной и пассивной копий группы хранения, но в SCR они называются соответственно исходными и целевыми объектами. Тем не менее, исходные и конечные объекты SCR представляют собой копии группы хранения. (Для SCR невозможно включить группы хранения для восстановления.)
Начальная точка SCR (исходный объект SCR) — это любая группа хранения на отдельном сервере почтовых ящиков или на кластерном сервере почтовых ящиков в одной копии кластера или среды CCR. Следует отметить, что хотя исходным объектом SCR может служить кластерный сервер почтовых ящиков, репликация SCR сама по себе не является кластерным решением и для нее не требуется служба кластеров Windows. Конечной точкой (целевым объектом) SCR может быть либо отдельный сервер почтовых ящиков, либо узел в отказоустойчивом кластере с установленной ролью почтового ящика, без настроенного кластерного сервера почтовых ящиков.

Взаимоотношения между исходными и целевыми объектами
Каждой исходной группе хранения SCR может соответствовать неограниченное число целевых объектов SCR. Например, у исходной группе хранения может быть один целевой объект в том же самом центре данных и второй целевой объект в другом центре данных. Однако рекомендуется использовать не более четырех целевых объектов на каждый исходный объект. Если требуется использовать более четырех объектов, это приведет к повышенной нагрузке на ресурсы исходного сервера SCR (память, ЦП и место на диске). Это следует учесть при планировании архитектуры этого сервера. У каждого целевого компьютера SCR может быть несколько исходных серверов. И на исходных, и на целевых компьютерах должен быть установлен пакет обновления 1 для Exchange 2007. Операционная система также должна поддерживаться пакетом обновления 1 для Exchange 2007 (к примеру, это может быть Windows Server® 2008 или Windows Server 2003 с пакетом обновления 2). Впрочем, вне зависимости от используемой операционной системы в SCR не поддерживаются различные системы одновременно: операционная система на исходном сервере SCR должна быть такой же, как и на всех целевых серверах. Таким образом, если исходный сервер SCR работает под управлением Windows Server 2003, то и на всех целевых серверах SCR также должна быть ОС Windows Server 2003.
Репликация SCR доступа в выпуске Exchange 2007 Standard Edition. Если в качестве исходного сервера используется кластерный сервер почтовых ящиков в среде SCR или CCR, то требуется выпуск Exchange 2007 Enterprise Edition. Каждый целевой объект SCR поддерживает до 50 экземпляров (50 реплицированных групп хранения) при использовании выпуска Enterprise Edition и до 5 экземпляров при использовании выпуска Standard Edition.
Также следует соблюдать требования целевых объектов SCR. Прежде всего, и исходный и целевой компьютеры должны находиться в одном и том же домене Active Directory, хотя они могут быть на разных узлах Active Directory. Кроме того, пути базы данных и файлов журнала в исходной системе и во всех целевых системах должны совпадать для каждой группы хранения, реплицируемой с помощью SCR. И наконец, если узел или сервер настроен в качестве целевого объекта SCR, невозможно включить LCR для любой группы хранения на целевом компьютере SCR и невозможно добавить кластерные серверы почтовых ящиков в резервный отказоустойчивый кластер.

Сравнение SCR, CCR и LCR
В репликации SCR (см. рис. 5) используется та же технология доставки журналов, как и в LCR и CCR, для предоставления новых возможностей развертывания и конфигураций. Как и в LCR и CCR, группы хранения с поддержкой SCR могут содержать только одну базу данных. Кроме того, SCR нельзя использовать для базы данных общих папок, если в организации Exchange существует несколько баз данных общих папок.
Figure 5 SCR is log shipping to another server or a passive node in a failover cluster
Figure 5 SCR is log shipping to another server or a passive node in a failover cluster
Одно из основных отличий заключается в том, что SCR поддерживает несколько целевых объектов в группе хранения, тогда как в LCR и CCR поддерживается только один целевой объект (пассивная копия). Еще одно важное отличие состоит в том, что нельзя создать резервную копию копии SCR, в отличие от CCR и LCR. При использовании SCR заголовки баз данных целевых объектов SCR обновляются, а файлы журналов обрезаются при резервном копировании исходной группы хранения SCR (или, при использовании CCR и LCR, при резервном копировании активных или пассивных копий исходной группы хранения SCR).
Как в LCR и CCR, доставка журнала в SCR является непрерывной и использует модель получения. Как только новый файл журнала закрывается и получает следующий порядковый номер, служба репликации Microsoft Exchange, работающая на целевом компьютере SCR, получает закрытые файлы журнала транзакций с исходного компьютера SCR, проверяет их и затем перемещает в соответствующую папку файлов журнала на целевом компьютере SCR.

Запаздывание воспроизведения
После копирования файлов журналов на целевой компьютер репликация SCR делает то, что не выполняется при репликации LCR и CCR. Вместо немедленного воспроизведения файлов журналов в копию базы данных в SCR начинается встроенная задержка воспроизведения 50 файлов на 24 часа. В SCR можно указать дополнительное время задержки, помимо этого времени по умолчанию. Это может пригодиться в разных ситуациях. Например, в случае логического повреждения активной базы данных задержка на 24 часа может исключить логическое повреждение целевой базы данных.
Длительность задержки воспроизведения управляется администратором с помощью параметра ReplayLagTime, который определяет, сколько времени служба репликации Exchange должна ждать перед воспроизведением файлов журнала, скопированных на целевой компьютер. Используется формат Дни.Часы:Минуты:Секунды, значение по умолчанию — 24 часа. Наибольшее допустимое значение — 7 дней. Наименьшее допустимое значение — 0 секунд. Если установить это значение, то воспроизведение файлов журналов произойдет сразу по истечении задержки по умолчанию для 50 файлов.
В дополнение к параметру ReplayLagTime в Exchange предусмотрена встроенная задержка на 50 файлов журнала, которая не зависит от значения параметра. Чтобы определить, когда следует воспроизводить файл журнала, в Exchange используется большее из двух значений: либо значение параметра ReplayLagTime, либо x файлов журнала, где x=50. Это дополнительная мера предосторожности, предусмотренная для того, чтобы не нужно было заново распространять группу хранения в случаях, когда в исходной системе SCR с непрерывной репликацией (например кластерный сервер почтовых ящиков в среде CCR) возникает сбой и необходимо восстановить работу одной или нескольких групп хранения с помощью командлета Restore-StorageGroupCopy. (Распространение — это использование интерфейсов API потокового копирования расширенного обработчика хранилищ (ESE) для создания рабочей копии исходной базы данных SCR на целевом компьютере SCR.) Задержка воспроизведения снижает необходимость повторного распространения копий SCR, поскольку по природе работы SCR в случае ошибок в исходной системе две копии будут выполнены с незначительным интервалом между ними.

Запаздывание усечения
В коммерческой версии Exchange 2007 (RTM) в среде с непрерывной репликацией применяется следующее правило: файл журнала невозможно удалить, если он не был скопирован и воспроизведен в копии базы данных. При использовании SCR это правило изменяется. Репликация SCR (обеспечивающая возможность нескольких копий базы данных) допускает усечение файлов журнала на исходном компьютере, как только они проанализированы всеми целевыми компьютерами. При усечении журнала исходный сервер не ждет воспроизведения всех журналов на всех целевых объектах, поскольку в копиях целевых объектов может быть настроена разная длительность задержки воспроизведения.
Можно указать дополнительную задержку усечения журнала с помощью нового параметра TruncationLagTime, который указывает, сколько времени служба репликации Exchange должна ждать (используется формат Дни.Часы:Минуты:Секунды) перед усечением файлов журнала, скопированных на целевой компьютер и воспроизведенных в копии базы данных. Отсчет времени начинается сразу после успешного воспроизведения файлов журнала в копии базы данных. Наибольшее допустимое значение — 7 дней, наименьшее — 0 секунд. Если установить последнее значение, задержка усечения файлов журнала отключается.
В среде SCR каждые три минуты запускается фоновый поток, определяющий, требуется ли усечение каких-либо файлов журнала. Если порядковый номер файла журнала меньше контрольной точки для группы хранения, а файл журнала старше времени, равного сумме значений параметров ReplayLagTime и TruncationLagTime, то файл журнала в целевой системе SCR будет усечен.
В среде с репликацией LCR или CCR, дополненной репликацией SCR, файл журнала в целевой системе SCR будет усечен при выполнении следующих четырех условий: 1) существует резервная копия файла журнала; 2) порядковый номер файла журнала меньше контрольной точки для группы хранения; 3) пассивная копия группы хранения находится в состоянии, допускающем усечение файла журнала; 4) все целевые объекты SCR исследовали файл журнала.

Включение и управление резервной непрерывной репликацией
Резервная непрерывная репликация (SCR) включается с помощью командлета Enable-StorageGroupCopy в командной консоли Exchange, в которую в пакете обновления 1 добавлены некоторые новые параметры. Как описано выше, с помощью параметров ReplayLagTime и TruncationLagTime можно управлять поведением объектов репликации SCR. Еще один параметр, SeedingPostponed, можно использовать, чтобы пропустить первоначальное распространение целевого объекта репликации. Это может пригодиться в разных ситуациях. Предположим, база данных в группе хранения, где поддерживается репликация SCR, имеет размер 100 ГБ. Нецелесообразно разрешать передачу 100 ГБ данных по сети компании во время пиковой загрузки. С помощью параметра SeedingPostponed можно включить SCR немедленно, а распространить данные позднее. В последствии можно будет вручную выполнить распространение с помощью командлета Update-StorageGroupCopy.
Перечисленные выше параметры необязательны, но для SCR обязателен один параметр командлета: StandbyMachine. В нем указывается имя компьютера, который будет содержать целевой объект репликации. Значение этого параметра указывается как часть значения атрибута msExchStandbyCopyMachines группы хранения, для которой поддерживается репликация SCR. Атрибут msExchStandbyCopyMachines — это строка в формате Юникод с несколькими значениями, добавляемая в схему Active Directory при введении Exchange 2007 SP1 в организацию Exchange. Это одна из причин, по которой при установке пакета обновления 1 требуется обновление схемы Active Directory.
Параметр StandbyMachine является важнейшим для SCR. Некоторые командлеты в пакете обновления 1 были изменены с целью использовать этот параметр для поддержки и управления целевыми объектами SCR. Изменения командлетов описаны на рис. 6.
Figure 6 Cmdlets that use the StandbyMachine parameter (Close Figure 6)

Командлет | Описание
Disable-StorageGroupCopy | Отключает назначение репликации SCR для группы хранения.
Get-StorageGroupCopyStatus | Определяет текущее состояние назначения репликации SCR.
New-StorageGroup | Создает новую группу хранения с поддержкой SCR, при этом не требуется отдельно включать SCR с помощью командлета Enable-StorageGroupCopy.
Restore-StorageGroupCopy | Отключает SCR и делает базу данных назначения SCR пригодной для присоединения с помощью операции Mount-Database в процедуре восстановления.
Resume-StorageGroupCopy | Восстанавливает непрерывную репликацию для группы хранения, в которой она была приостановлена.
Suspend-StorageGroupCopy | Приостанавливает непрерывную репликацию для группы хранения, в которой она была включена.
Update-StorageGroupCopy | Используется для заполнения целевой группы хранения SCR.

Активация целевых объектов репликации SCR
Резервная непрерывная репликация обеспечивает наличие одной или нескольких своевременных копий данных, которые можно использовать при утрате или повреждении исходных данных. Процесс создания копии целевого объекта SCR и ее повторная подготовка в виде рабочей базы данных называется активацией. Активация выполняется в рамках процесса восстановления, который может происходить в двух вариантах (/m:RecoverServer — восстановление одного сервера, /RecoverCMS — восстановление кластерного сервера почтовых ящиков).

Как можно использовать SCR
Посмотрим, как вымышленная компания может использовать SCR и перенос баз данных для восстановления после сбоя базы данных почтовых ящиков. После обнаружения повреждения рабочей базы данных администратор включает целевой объект SCR.
В организации развернуты серверы Exchange 2007 с пакетом обновления 1 и применяется SCR для копирования группы хранения на удаленном сервере почтовых ящиков. Оба сервера почтовых ящиков (исходный сервер и целевой сервер) находятся на одном и том же узле Active Directory и настроены для использования встроенных в Active Directory DNS-серверов. Интервал репликации Active Directory равен 15 минутам.

Включение резервной непрерывной репликации и промежуточного восстановления
Репликация SCR настроена таким образом, что файлы журналов транзакций реплицируются для одной группы хранения SG1, содержащей одну базу данных MBX1. Пути к файлам группы хранения и к файлу базы данных — C:\SG1 и C:\SG1\MBX1.EDB. В этом случае EXMBX1 является источником, а EXMBX2 — целевым объектом SCR. Эта система была настроена следующим образом:
Enable-StorageGroupCopy EXMBX1\SG1 -StandbyMachine EXMBX2
После включения SCR было проверено состояние SCR для SG1 с помощью командлета Get-StorageGroupCopyStatus:
Get-StorageGroupCopyStatus EXMBX1\SG1 -StandbyMachine EXMBX2
Чтобы сэкономить время при активации целевого объекта SCR, на сервере EXMBX2 была заранее настроена группа хранения SG1PORT и база данных MBX1PORT, которые будут использоваться для переноса. SG1PORT и MBX1PORT отделены от целевой группы хранения и файлов базы данных. Поэтому для SG1PORT и MBX1PORT указывается временный путь, не конфликтующий с путями целевых объектов SCR. SG1PORT и MBX1PORT будут использоваться только для переноса базы данных; сами по себе файлы базы данных и группы хранения SG1PORT не нужны. Поэтому администратор отсоединяет базу данных MBX1PORT и удаляет все ее файлы в группе хранения. Объекты группы хранения и базы данных остаются в Active Directory, поскольку они будут использованы для переноса базы данных в процессе восстановления.

Активация и восстановление
Журнал событий приложения указывает, что исходная база данных SCR физически повреждена. Поскольку SCR-репликация была включена для SG1, принимается решение активировать целевую базу данных SCR для SG1 вручную и восстановить доступность данных. Активация целевой копии SCR начинается с отсоединения MBX1 в SG1 с помощью следующего командлета:
Dismount-Database EXMBX1\SG1\MBX1
После этого целевая база данных SCR подготавливается к подключению, а почтовые ящики переносятся с MBX1 на MBX1PORT.
Для отключения SCR и подготовки целевой базы данных SCR к подключению используется командлет Restore-StorageGroupCopy. При этом база данных группы хранения помечается как присоединяемая и предоставляется отчет о потере данных, который будет вызван присоединением базы данных в группе хранения. Также проверяется наличие в расположении группы хранения пассивной копии всех файлов журналов, созданных активной копией группы хранения. Если каких-либо файлов не хватает, будет предпринята попытка их скопировать. Следующий командлет используется для подготовки целевой базы данных SCR к присоединению:
Restore-StorageGroupCopy EXMBX1\SG1 -StandbyMachine EXMBX2
В этом примере файлы журнала из исходной группы хранения SCR доступны для копирования. Если эти файлы недоступны (например, если компьютер выключен), к задаче Restore-StorageGroupCopy нужно добавить параметр Force. Если этого не сделать, задача Restore-StorageGroupCopy будет пытаться подключиться к исходной группе хранения для копирования недостающих файлов журнала, а если исходная группа хранения будет недоступна, задача Restore-StorageGroupCopy не будет выполнена и база данных не будет подготовлена к присоединению. Параметр Force означает, что исходные файлы недоступны; задача Restore-StorageGroupCopy не пытается подключиться и подготавливает базу данных к присоединению.
После завершения работы команды Restore-StorageGroupCopy администратор должен убедиться, что база данных находится в состоянии чистого отключения. Если база данных находится в состоянии «неправильного отключения» (см. technet.microsoft.com/aa996757.aspx), ее нужно перевести в состояние чистого отключения. Если префикс файла журнала группы хранения (например E00 или E01) одинаков для источника SCR (EXMBX1\SG1) и для группы хранения назначения SCR (SG1PORT), которая будет использоваться для переноса базы данных (EXMBX2\SG1PORT), то запускать программу Eseutil в режиме восстановления не требуется. Последняя операция присоединения базы данных приведет ее в состояние чистого отключения после анализа всех реплицированных файлов журнала. Если база данных не находится в состоянии чистого отключения, нужно запустить программу Eseutil в режиме восстановления (Eseutil /r).
После того, как база данных будет приведена в состояние чистого отключения, нужно запустить две команды, которые указывают в Active Directory новое расположение файлов группы хранения и файла базы данных. Эти команды изменяют пути к SG1PORT и MBX1 с исходных на промежуточную группу хранения и базу данных (SG1PORT и MBX1PORT):
Move-StorageGroupPath EXMBX2\SG1PORT -SystemFolderPath C:\SG1 -LogFolderPath C:\SG1 –ConfigurationOnly

Move-DatabasePath EXMBX2\SG1PORT\MBX1PORT -EdbFilePath C:\SG1\MBX1PORT.EDB –ConfigurationOnly
В указанные выше команды нужно включить параметр –ConfigurationOnly, чтобы в Active Directory были обновлены только параметры конфигурации для этих объектов. Файлы и данные не перемещаются: этого не требуется, поскольку данные уже реплицированы в папку C:\SG1 на сервере EXMBX2.
Теперь нужно настроить базу данных (MBX1PORT), чтобы разрешить ее замену при восстановлении. Для этого нужно установить флажок «База данных может быть перезаписана при восстановлении» в свойствах объекта базы данных в консоли управления Exchange или выполнить следующую команду в оболочке управления Exchange:
Set-MailboxDatabase EXMBX2\SG1PORT\MBX1PORT -AllowFileRestore:$true
После того как база данных настроена для перезаписи, следует присоединить базу данных с помощью следующей команды:
Mount-Database EXMBX2\SG1PORT\MBX1PORT
После присоединения базы данных почтовые ящики, связанные исходной базой данных (SG1\MBX1) нужно связать с MBX1PORT на EXMBX2. Для этого следует запустить командлет Get-Mailbox и направить его выходные данные командлету Move-Mailbox. При этом важно, чтобы системный помощник Exchange и системные почтовые ящики не были включены в выходные данные командлета Get-Mailbox, направляемые командлету Move-Mailbox. Эти объекты не нужно перенаправлять. Следующая команда служит для перенаправления всех почтовых ящиков пользователей и исключения системных почтовых ящиков:
Get-Mailbox -Database EXMBX1\SG1\MBX1 |where {$_.ObjectClass -NotMatch '(SystemAttendantMailbox| ExOleDbSystemMailbox)'}| Move-Mailbox -ConfigurationOnly -TargetDatabase EXMBX2\SG1PORT\MBX1PORT
На этом этапе клиенты могут получить доступ к MBX1PORT. Однако доступ пользователей к своим почтовым ящикам после их перемещения с EXMBX1\SG1\MBX1 на EXMBX2\SG1PORT\MBX1PORT зависит от скорости репликации Active Directory, то есть от количества серверов каталогов и от того, сколько времени им требуется для распространения изменений. Кроме того, доступ зависит и от используемых клиентских программ. Клиенты Outlook 2007 и отличные от Outlook получат доступ к почтовым ящикам пользователей после того, как в серверах каталогов, используемых сервером клиентского доступа пользователей, будут указаны новые пути. Для клиентов Outlook 2003 и более ранних версий потребуется обновить профиль системы сообщений на настольных ПК пользователей, указав новое имя сервера.

Заключительные действия
Итак, теперь клиенты имеют доступ к своим почтовым ящикам. Нужно восстановить возможность дублирования, заново включив резервную непрерывную репликацию. Для этого нужно удалить с EXMBX1 все оставшиеся группы хранения и файлы баз данных. После этого можно переместить пути для EXMBX1\SG1\MBX1 во временное расположение, а EXMBX1 может стать объектом репликации для EXMBX2.

Скотт Шнолль (Scott Schnoll) — главный технический писатель в группе Exchange Server в корпорации Майкрософт. Он пишет материалы, посвященные Exchange Server 2007. До перехода на работу в корпорацию Майкрософт Скотт написал книгу «Exchange Server 2003 Distilled» (изд-во Addison-Wesley Professional, 2004 г.) и был ведущим автором книги «Exchange 2000 Server: The Complete Reference» (изд-во McGraw-Hill/OsborneMedia, 2001 г.).


 Связь: Работа с Exchange Server в операционной системе Windows Server 2008
Связь Пол Боуден (Paul Bowden)

Работа с Exchange Server в операционной системе Windows Server 2008
Краткий обзор:
  • Настройка Exchange Server в операционной системе Windows Server 2008
  • Советы и рекомендации по настройке
  • Знакомство со средой Exchange Server

В мои обязанности, как члена группы разработчиков Microsoft Exchange Server, входит составление графика работ, определение темпов их проведения и расстановка приоритетов для группы. В корпорации Майкрософт эта должность называется «ответственный за выпуск». Это приблизительно соответствует техническому руководителю проекта в других компаниях. Как и любому руководителю, работающему
в этой должности, чтобы обеспечить своевременный выпуск качественного продукта, мне необходимы мои знания, квалификация и трудолюбие, а также уважение и поддержка со стороны группы. А завоевать доверие таких ярких и талантливых специалистов совсем непросто, его действительно нужно заслужить.
Одним из способов зарекомендовать себя является размещение личного почтового ящика на экспериментальном сервере — промышленно-эксплуатируемом почтовом сервере, где установлена предварительная версия Exchange Server. Это очень динамичная среда, в которой переходы на новые промежуточные версии (сборки) Exchange Server происходят каждые 2-3 недели. Подобный эксперимент позволяет проверить программное обеспечение в условиях реальной эксплуатации при взаимодействии с реальными пользователями. Мы даже устанавливаем свои почтовые ящики на самых свежих тестовых сборках программы. Я тоже принимал участие в этих испытаниях и готов рассказать об этом.

Подготовка к работе с «Longhorn»
В конце 2006 года, когда только начались поставки Exchange Server 2007, на горизонте появилась новая операционная система — Windows Server®с кодовым названием «Longhorn». Как только мы начали планировать выпуск первого пакета обновления для новой платформы Exchange, стало очевидно, что пути Exchange и Windows® тесно переплетены, и что операционная система «Longhorn» (теперь известная как Windows Server 2008) — это всерьез и надолго. Именно в этот момент мы решили проектировать Exchange Server 2007 с пакетом обновления 1 как для Windows Server 2003, так и для Windows Server 2008. Для поддержки такого корпоративного приложения сразу на нескольких версиях Windows требовались значительные усилия по координации и планированию работ. Например, Exchange тесно взаимодействует с IIS, а операционная система Windows Server 2008 содержит новую версию IIS 7.0.
Я помню, как мы первый раз устанавливали Windows Server 2008 в нашей лаборатории в конце декабря 2006 года. Больше всего это событие запомнилось следующими двумя моментами: во-первых, установка была очень быстрой; а во-вторых, средства управления, несмотря на то, что они сильно отличались от аналогичных инструментов в Windows Server 2003, были интуитивно понятны и удобны в работе.
В нашей главной лаборатории на установку операционной системы Windows Server 2008 потребовалось примерно в три раза меньше времени, чем необходимо на установку Windows Server 2003. Одна из причин этого в том, что теперь дополнительные компоненты не требуют обязательного запуска операционной системы и их не нужно настраивать при установке продукта. Это помогает значительно снизить уязвимость компьютера для атак злоумышленников и максимально упрощает работы по установке. Никто не любит бесполезной суеты. Обычно обратной стороной такой установки были бесконечные требования вставить установочный диск при добавлении каждого нового компонента. Но в Windows Server 2008 все файлы копируются в папку SxS (сокращение от английского слова "рядом" — side-by-side). Затем с помощью диспетчера сервера выполняется настройка требуемых компонентов, и операционная система сама определяет, какие файлы нужно скопировать.
Здесь следует особо отметить возможность, названную Server Core (ядро сервера). Это такой режим установки Windows Server 2008, при котором устанавливается набор компонентов, минимально необходимый для работы операционной системы. В этом режиме взаимодействие с консолью сервера происходит с помощью командной строки, поскольку даже проводник Windows не устанавливается. Этот режим хорошо подходит для серверов инфраструктуры, например контроллеров доменов и серверов DNS. Но не все приложения смогут выполняться при таком варианте установки. Exchange Server широко использует управляемые коды, и это препятствует использованию режимов установки Server Core.

Настройка Exchange Server
Мне понравилось, насколько просто можно выполнить полную установку Windows Server 2008 и Exchange Server 2007 с пакетом обновления 1, взяв только один диск с дистрибутивом, но не выполняя никаких предварительных загрузок или проверок готовности. Лучшим способом настроить устанавливаемую операционную систему Windows Server 2008 для работы с Exchange Server является использование средства ServerManagerCmd. Я создал файл ответов XML, показанный на рис. 1, с помощью которого выполняется установка только тех компонентов операционной системы, которые необходимы для установки и эксплуатации Exchange Server на платформе Windows Server 2008. Как только новая операционная система будет установлена, я запускаю следующую команду для ее настройки:
Figure 1 ServerManagerCmd answer file for Exchange (Close Figure 1)
<!—Файл ответов ServerManagerCmd совместим с Windows Server 2008        --> <!—Синтаксис команды: ServerManagerCmd –ip Exchange.xml

<ServerManagerConfiguration Action="Install" xmlns="http://schemas.microsoft.com/sdm/Windows/ServerManager/Configuration/2007/1">

    <!-- BASE: Установка компонента PowerShell 1.0 --> <Feature Id ="PowerShell"/>

    <!-- PREPARESCHEMA: Установка LDIFDE и других инструментов для работы с каталогами, таких как LDP и ADSIEdit --> <Feature Id="RSAT-ADDS"/>

    <!-- CAS/MBX: Установка роли веб-сервера с дополнительными дочерними компонентами --> <Role Id="Web-Server"/> <RoleService Id="Web-Metabase"/> <RoleService Id="Web-Lgcy-Mgmt-Console"/> <RoleService Id="Web-Basic-Auth"/> <RoleService Id="Web-Windows-Auth"/>

    <!-- CAS: Установка трех типов аутентификации для OWA, сжатия GZip compression и поддержки мобильного Outlook--> <RoleService Id="Web-ISAPI-Ext"/> <RoleService Id="Web-Digest-Auth"/> <RoleService Id="Web-Dyn-Compression"/> <Feature Id="RPC-over-HTTP-proxy"/>

    <!-- EDGE: Установка службы каталогов Active Directory Lightweight (ранее известной как ADAM) --> <Role Id="ADLDS"/>

    <!-- UM: Установка компонентов проигрывателя Windows Media  --> <Feature Id="Desktop-Experience"/>

</ServerManagerConfiguration>

ServerManagerCmd –ip Exchange.xml
Когда ее выполнение закончится, и система будет перезапущена, у вас будет все необходимое для установки ролей Exchange Server, таких как почтовый ящик (Mailbox), клиентский доступ (Client Access), транспортный сервер-концентратор (Hub Transport), пограничный транспортный сервер (Edge Transport) и единая система обмена сообщениями (Unified Messaging).
Другим полезным приемом использования ServerManagerCmd является переключатель запросов. С его помощью выполняется нумерация всего списка ролей и служб, а затем показывается, какие из них действительно настроены (отмечено зеленым текстом на рис. 2).
Figure 2 Enumerating Exchange roles and services
Figure 2 Enumerating Exchange roles and services
Вернемся к основной теме. Первые месяцы 2007 года мы в своей лаборатории пытались выяснить, какие изменения необходимы для получения оптимальной производительности Windows Server 2008. Один из наиболее важных выводов состоит в том, что сколько бы не проводились установки и нагрузочные испытания программ в лабораторных условиях, подлинное их качество можно оценить только в условиях реального развертывания с участием реальных пользователей. Вот почему мы проводим подобные эксперименты со своими продуктами — тестируем их в реальной повседневной работе. Выпуск 3-ей бета-версии Windows Server 2008 в апреле 2007 оказался поворотным этапом — настал момент перехода на эту платформу и ее производственного развертывания.
Я сидел в лаборатории и смотрел, как работают участники группы, когда они развертывали первый набор служб Exchange Server на Windows Server 2008. Установка Exchange Server прошла без проблем и все службы были успешно запущены. Все, что пришлось сделать после этого, это перенести почтовый ящик и проверить, как он работает. Я вызвался сам произвести проверку. Размер моего почтового ящика около 2 ГБ, но всего через 26 минут все уже было готово к работе и я мог отправлять и получать электронную почту с помощью Exchange Server на Windows Server 2008. Великолепно!

Извлеченные уроки
С момента той первой установки Windows Server 2008 мы продолжали совершенствовать технологию развертывания, готовясь к «премьере». Нам пришлось принять несколько ключевых решений относительно того, как проводить развертывание.
Установка Можно использовать Exchange Server 2007 с пакетом обновления 1 либо в качестве обновления оригинальной установки Exchange Server 2007, который я бы назвал Exchange 2007 RTM (выпуск для промышленной эксплуатации), или взять новый компьютер и выполнить установку непосредственно с носителя с Exchange Server 2007 с пакетом обновления 1. Это очень важная возможность, поскольку нельзя установить Exchange Server 2007 RTM на компьютер под управлением Windows Server 2008.
Обновления Хотя можно выполнить обновление установленной операционной системы в широком диапазоне, начиная с версии Windows Server 2003 с пакетом обновления 2 и до Windows Server 2008, имеется несколько компонентов, которые нужно установить предварительно. Одним из таких компонентов является Windows PowerShell™. Это один из краеугольных камней системы управления Exchange Server; даже программа установки Exchange создана на основе Windows PowerShell. По этой причине мы не можем поддерживать обновления операционной системы, если Exchange Server уже установлен. В большинстве случаев это означает, что вначале Windows Server 2008 будет устанавливаться на новые компьютеры, а затем будет выполняться установка Exchange Server 2007 с пакетом обновления 1.
IPv6 Exchange Server спроектирован таким образом, чтобы использовать преимущества нескольких новых возможностей Windows Server 2008. Например, протокол IPv6 устанавливается по умолчанию и два сервера Exchange, работающих на одной операционной системе, будут автоматически использовать протокол IPv6 для взаимодействия друг с другом. Различные интерфейсы консоли управления Exchange также будут поддерживать работу с адресами в диапазоне IPv6. Но необходимо помнить, что для Exchange Server по-прежнему необходим адрес IPv4 для связи со всеми сетевыми интерфейсами.
Контроллеры доменов только для чтения Радикальные изменения, которые произошли с процедурой развертывания Active Directory®, связаны с появлением контроллеров доменов только для чтения (или глобального сервера каталогов). Это позволяет организациям развертывать серверы Active Directory, которые получают односторонние репликации, но сами не имеют возможности передавать свои изменения обратно. Это может быть полезно для филиалов или удаленных офисов, в которых не всегда возможно гарантировать безопасность на физическом уровне. К сожалению, Exchange Server 2007 с пакетом обновления 1 не умеет использовать контроллеры доменов только для чтения и требует доступ к стандартным записываемым разделам Active Directory.

Ваша среда Exchange Server
Ресурсы Exchange Server и Windows Server
  • Windows Server 2008 TechCenter
  • Технический центр Microsoft Exchange Server TechCenter
  • Центр испытаний TechNet Evaluation Center
  • Виртуальные лаборатории Windows Server 2008

Когда приходит пора определить уровень операционной системы для предстоящего развертывания, есть возможность выбора одной из множества различных конфигураций, показанных на рис. 3.
Figure 3 Exchange environment matrix (Close Figure 3)

Версия Exchange | Операционная система на сервере | Контроллер доменов
Exchange Server 2007 с пакетом обновления 1 | Windows Server 2008 | Windows Server 2008
Exchange Server 2007 с пакетом обновления 1 | Windows Server 2008 | Windows Server 2003
Exchange Server 2007 с пакетом обновления 1 | Windows Server 2003 с пакетом обновления 2 | Windows Server 2008
Exchange Server 2007 с пакетом обновления 1 | Windows Server 2003 с пакетом обновления 2 | Windows Server 2003
Другой важной возможностью является развертывание на разных версиях. Действительно, можно использовать множество различных версий Exchange и Windows, взаимодействующих между собой. Например, можно выполнить развертывание Exchange Server 2007 с пакетом обновления 1 на Windows Server 2008 для серверов доступа клиента и обеспечить им доступ к почтовым серверам Exchange Server 2007 RTM на Windows Server 2003.
Работая с более старыми версиями Exchange Server и Windows Server 2008 Active Directory, нужно помнить о ряде нюансов. Если используется Exchange Server 2003 с пакетом обновления 2 или более поздняя версия, можно развернуть и использовать в вашей среде контроллеры доменов Windows Server 2008. Однако если развернут Exchange Server 2000, потребуется либо воздержаться от развертывания контроллеров доменов Windows Server 2008 на узле Active Directory, где находятся эти серверы Exchange, либо жестко запрограммировать настройки Directory Services Access (DSAccess), чтобы Exchange 2000 не пытался использовать контроллеры доменов Windows Server 2008.

Выводы
Мы хорошо потрудились, чтобы добиться стабильной работы Exchange 2007 с пакетом обновления 1 на обеих платформах: как Windows Server 2003, так и Windows Server 2008. Для Exchange Server мы постарались обеспечить максимальную гибкость и согласованные сценарии развертывания. Думаю, для вас станет приятным сюрпризом то, насколько просто и быстро можно развернуть Exchange на платформе Windows Server 2008. Нельзя не отметить несколько изменений в производительности и масштабируемости, например значительно возросшую масштабируемость сервера клиентского доступа.
Операционная система Windows Server 2008 — великолепная платформа для будущего развития коммуникационных технологий. Она вас не разочарует.

Пол Боуден (Paul Bowden) — главный менеджер программы в группе разработчиков Exchange Server. Ему часто приходится тратить свое свободное время на подтверждение по запросу своих учетных сведений в PayPal.


 Связь: Развертывание единой системы обмена сообщениями на сервере Exchange Server 2007
Связь Джефф Гудвин (Jeff Goodwin)

Развертывание единой системы обмена сообщениями на сервере Exchange Server 2007
Краткий обзор:
  • Основы телефонии
  • Вопросы проектирования единой системы обмена сообщениями
  • Перенос пользователей

Итак, принято решение о развертывании в организации единой системы обмена сообщениями сервера Exchange Server 2007. Роль сервера единой системы обмена сообщениями установлена, интегрирована с существующей УАТС, и теперь у вас и десяти сотрудников вашей организации голосовая почта, электронная почта и факсимильные сообщения хранятся на сервере Exchange Server. Можете
считать свою задачу выполненной. Но как предоставить те же самые возможности тысячам абонентов, распределенным по многочисленным узлам, не нарушив при этом нормальную работу организации?
Надеюсь, моя статья поможет справиться с этой задачей. Эта статья написана с целью помочь пользователям понять процедуру развертывания единой системы обмена сообщениями в организации, а также прояснить основные понятия телефонии, связанные с подобным развертыванием. Если вам необходима помощь по установке, настройке или функциям единой системы обмена сообщениями Exchange Server 2007, см. врезку «Ресурсы единой системы обмена сообщениями» в конце данной статьи. Кроме того, корпорация Майкрософт присвоила ряду компаний статус специалистов по единой системе обмена сообщениями. Такие компании помогают клиентам при проектировании и развертывании единой системы обмена сообщениями Exchange Server 2007, а также проводят консультации. Если вам необходима помощь по установке, настройке или развертыванию, обратитесь к указанным на врезке экспертам.

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

Основы телефонии
Процесс планирования станет намного проще при понимании основной архитектуры, процесса передачи звонков и терминологии, связанной с единой системой обмена сообщениями. На рис. 1 приведен пример единой системы обмена сообщениями, интегрированной в существующую корпоративную систему телефонии. Теперь давайте более подробно рассмотрим некоторые основные концепции и технологии, с которыми придется иметь дело в процессе развертывания.
Figure 1 A PBX-to-Unified Messaging solution
Figure 1 A PBX-to-Unified Messaging solution
УАТС (учрежденческая автоматическая телефонная станция) — это частная телефонная сеть, используемая в организации. В подобной системе у каждого пользователя имеется, как правило, телефонный аппарат, подключенный к УАТС, с которого можно звонить внутренним пользователям путем набора добавочного номера (состоящего, как правило, из четырех или пяти цифр) и на внешние телефонные номера.
Если в организации имеется несколько УАТС, их зачастую требуется соединить друг с другом с помощью сетевых технологий, выбор которых зависит от производителя УАТС. Это позволяет всем пользователям объединенных в сеть УАТС звонить друг другу просто путем набора добавочного номера.
Единая система обмена сообщениями объединяет две разнородные системы: систему обмена сообщениями Exchange и физическую телефонную систему. Связь между сервером единой системы обмена сообщениями и архитектурой телефонии осуществляется по протоколу SIP. Некоторые УАТС могут взаимодействовать с сервером единой системы обмена сообщениями напрямую по протоколу SIP; другим требуется шлюз SIP. На рис. 1УАТС подключена к шлюзу SIP по линии T1. Когда звонок передается в единую систему обмена сообщениями, УАТС отправляет данные (номер телефона вызывающей стороны, номер телефона вызываемой стороны и код причины) в шлюз SIP. На основе этих данных сервер единой системы обмена сообщениями определяет, кому предназначен звонок.
Некоторые УАТС можно объединить друг с другом по IP-сети. Телефонная сеть позволяет переадресовывать вызовы по IP-сети в централизованное решение голосовой почты. Например, если взглянуть на рис. 2, можно заметить, что Цюрих соединен по сети с Лондоном.
Figure 2 A more complex Unified Messaging deployment
Figure 2 A more complex Unified Messaging deployment

Процесс передачи звонка
Ресурсы единой системы обмена сообщениями
  • Каталог специалистов по единой системе обмена сообщениями
  • Страница единой системы обмена сообщениями Exchange веб-узла TechCenter
  • Поддерживаемые шлюзы SIP
  • Помощник по телефонии
  • Примечания по конфигурации УАТС

Предположим, что внешняя вызывающая сторона звонит абоненту единой системы обмена сообщениями. В этом случае абонент единой системы обмена сообщениями находится вне офиса, поэтому звонок остается без ответа. Путь прохождения сообщения показан на рис. 1.
УАТС передает вызов в шлюз SIP, который, в свою очередь, устанавливает связь по протоколу SIP через TCP с сервером единой системы обмена сообщениями. Сервер получает от шлюза SIP данные интеграции, в которых указано, кому предназначен вызов. После этого сервер единой системы обмена сообщениями воспроизводит приветствие абонента и позволяет звонящему записать сообщение. Это сообщение затем доставляется в почтовый ящик Exchange абонента единой системы обмена сообщениями.
Подобный процесс передачи звонков является крайне упрощенной схемой реального процесса. Важно понимать, что после того, как сообщение записано, сервер единой системы обмена сообщениями передает сообщение на транспортный сервер-концентратор по протоколу SMTP для дальнейшей доставки на сервер почтовых ящиков.
Абоненты единой системы обмена сообщениями получают доступ к своим почтовым ящикам Exchange по телефону (с помощью голосового доступа к Outlook® ) или с компьютера (с помощью Outlook 2007 или веб-клиента Outlook). Но абоненты также могут прослушивать сообщения по телефону с помощью Outlook 2007 или веб-клиента Outlook, используя функцию воспроизведения на телефоне, которая позволяет абоненту единой системы обмена сообщениями вместо использования компьютера воспроизвести выбранное сообщение, набрав указанный номер. При использовании данного способа сервер единой системы обмена сообщениями взаимодействует одновременно с сервером клиентского доступа и сервером почтовых ящиков. Это важно знать, поскольку если сервер единой системы обмена сообщениями находится в удаленном офисе, в котором отсутствует локальный сервер клиентского доступа, то серверу единой системы обмена сообщениями придется взаимодействовать с сервером клиентского доступа по глобальной сети, что может привести к снижению производительности.

Проектирование системы
Имеются две основные архитектуры Exchange: централизованная и децентрализованная. Как правило, архитектура единой системы обмена сообщениями следует за архитектурой Exchange, то есть вслед за развертыванием сервера почтовых ящиков необходимо развернуть сервер единой системы обмена сообщениями. Разумеется, из любого правила есть исключения.
При проектировании архитектуры единой системы обмена сообщениями необходимо учитывать пять основных аспектов.
  • Размещение сервера
  • Количество серверов единой системы обмена сообщениями
  • Шлюз SIP
  • Хранилище почтовых ящиков
  • Конфигурация узла единой системы обмена сообщениями
И не забудьте учесть, что работа организации не должна прерываться. Как правило, план аварийного восстановления для сервера Exchange можно использовать и для разработки соответствующего плана восстановления единой системы обмена сообщениями.
Примеры сценариев развертывания помогут вам лучше понять роли сервера единой системы обмена сообщениями. На рис. 2 приведен пример развертывания сервера Exchange Server 2007 с единой системой обмена сообщениями в крупной организации.
В данном более сложном случае основные центры обработки данных расположены в Сиэтле и Лондоне. Серверы единой системы обмена сообщениями в этих городах обслуживают своих пользователей, поскольку серверы почтовых ящиков и транспортные серверы-концентраторы являются локальными. В обоих узлах установлены УАТС, работающие по протоколу IP, которые обслуживают вызовы к локальному серверу единой системы обмена сообщениями для ответа на звонки.
Узлы среднего размера расположены в Нью-Йорке и Глазго. Серверы единой системы обмена сообщениями в этих городах обслуживают своих пользователей, поскольку серверы почтовых ящиков и транспортные серверы-концентраторы являются локальными. Как и в основных центрах обработки данных, в обоих узлах установлены УАТС, работающие по протоколу IP, которые обслуживают вызовы к локальному серверу единой системы обмена сообщениями для ответа на звонки.
На узлах меньшего размера нет локальных серверов почтовых ящиков и транспортных серверов-концентраторов, однако здесь используются возможности единой системы обмена сообщениями, предоставляемые основными центрами обработки данных. В городе Остин установлена УАТС производства компании NEC, подключенная к локальному шлюзу SIP по аналоговой линии. Звонки локальным пользователям передаются в шлюз SIP, который подключается к серверу единой системы обмена сообщениями в Сиэтле, чтобы отвечать на звонки в единой системе обмена сообщениями.
В Цюрихе установлена УАТС Avaya Communication Manager, которая соединена по IP-сети с такой же УАТС в Лондоне. Звонки локальным пользователям передаются через УАТС Avaya Communication Manager, которая подключается к серверу единой системы обмена сообщениями в Лондоне, чтобы отвечать на звонки в единой системе обмена сообщениями.
В данном примере серверы почтовых ящиков Exchange и серверы единой системы обмена сообщениями физически расположены в Сиэтле в одном месте. При использовании архитектуры с одним узлом все серверы (серверы почтовых ящиков, единой системы обмена сообщениями, клиентского доступа и т.д.) и оборудование УАТС расположены на одном узле. При наличии нескольких узлов сложность проектирования возрастает. Подобная сложность может показаться непреодолимой, но, при четком понимании базовых принципов единой системы обмена сообщениями, задача становится выполнимой.
Как показано на рис. 2, если на узле имеется сервер почтовых ящиков, рекомендуется также развернуть там сервер единой системы обмена сообщениями. Узлы в Сиэтле, Лондоне, Нью-Йорке и Глазго соответствуют этой рекомендации. Хотя в узлах в Остине и Цюрихе отсутствуют локальные серверы почтовых ящиков, службы единой системы обмена сообщениями в этих городах доступны по IP-сети. В Остине установлена локальная аналоговая УАТС. В этом случае для подключения по IP-сети к серверу единой системы обмена сообщениями в Сиэтле необходим шлюз SIP. В Цюрихе установлена локальная УАТС, работающая по протоколу IP, которая соединена по сети с УАТС в Лондоне. Таким образом, звонок пользователю в Цюрихе передается по телефонной сети обратно в Лондон, на УАТС и сервер единой системы обмена сообщениями.
Поскольку звонки абонентам в Цюрихе передаются по сети и обрабатываются централизованной системой обмена сообщениями в Лондоне, то в случае сбоя в работе сети звонки всем абонентам в Цюрихе будут оставаться без ответа, пока сеть не будет восстановлена. Если необходимо обеспечить локальную бесперебойную работу на случай сбоя в работе сети, в Цюрихе следует развернуть сервер единой системы обмена сообщениями. В случае сбоя в работе сети сервер единой системы обмена сообщениями продолжит отвечать на звонки и доставит их абонентам после восстановления работоспособности сети.
Размещение сервера, по-видимому, является наиболее важным фактором, который следует принимать во внимание при проектировании архитектуры для конкретной среды. С помощью диаграммы, приведенной на рис. 3, можно определить, каким образом следует разместить сервер.
Figure 3 Determining server placement
Figure 3 Determining server placement

Оценка потребности в серверах
Следующее, что необходимо определить, — это количество серверов единой системы обмена сообщениями, необходимое для обслуживания сообщества пользователей. Ответ на этот вопрос зависит от нескольких факторов, связанных с узлом.
Масштабируемость сервера единой системы обмена сообщениями определяется количеством одновременных звонков (или портов, в терминах телефонии), которое поддерживается сервером. Каждый звонок требует от сервера единой системы обмена сообщениями выделения ресурсов сети, ЦП, оперативной памяти и места на жестком диске. Если выделить дополнительные ресурсы, сервер единой системы обмена сообщениями сможет обрабатывать больше звонков одновременно. Поскольку ресурсы всегда ограничены, сервер единой системы обмена сообщениями сможет одновременно обрабатывать ровно столько звонков, насколько хватит ресурсов.
Определить количество портов, необходимое для обслуживания заданного количества абонентов, можно с помощью методов анализа трафика Эрланга, в которые я не буду здесь углубляться. Более простой способ определить необходимое количество портов — просто спросить администратора телефонной станции, сколько портов используется в существующей системе голосовой почты. Практический опыт показывает, что требования к количеству портов в традиционной системе голосовой почты и единой системе обмена сообщениями должны быть аналогичны.
Обычно я рекомендую использовать на одном сервере не более 60 портов. Это не имеет никакого отношения к ограничениям оборудования или программного обеспечения. Эта рекомендация основана на том факте, что один сервер с 60 портами позволяет обслуживать примерно 5000 пользователей. При сбое одного единственного сервера полностью пострадает очень большая база абонентов.
При внедрении серверов единой системы обмена сообщениями следует внести в архитектуру избыточность по формуле N+1. На рис. 4 приведен пример архитектуры серверов и шлюзов SIP с полным дублированием. В данной архитектуре в случае сбоя первого сервера единой системы обмена сообщениями звонки с первого шлюза SIP будут автоматически перенаправляться на второй сервер единой системы обмена сообщениями. Также можно запрограммировать УАТС на равномерное распределение нагрузки между всеми шлюзами SIP. Например, первый звонок в систему будет передан в шлюз SIP 1, а следующий — в шлюз SIP 2. Распределение звонков между шлюзами позволяет равномерно распределить нагрузку между серверами единой системы обмена сообщениями.
Figure 4 Distributing calls between servers for redundancy
Figure 4 Distributing calls between servers for redundancy
В настоящее время серверами единой системы обмена сообщениями Exchange Server 2007 поддерживаются шлюзы SIP двух поставщиков: AudioCodes и Dialogic. Если в архитектуре необходимо использовать шлюзы SIP, убедитесь в том, что приобретенные шлюзы поддерживают необходимое количество сеансов (портов). Например, если в архитектуре требуются 32 порта, необходимо установить шлюз, поддерживающий, по крайней мере, такое же количество сеансов.
Если вы не уверены в том, будет ли ваша УАТС работать с единой системой обмена сообщениями и какой шлюз следует выбрать, обратитесь к врезке «Ресурсы единой системы обмена сообщениями». На врезке имеются ссылки на руководства компании Майкрософт, а также каталог специалистов по единой системе обмена сообщениями, которые помогут оценить потребности вашей организации. Мой личный опыт показывает, что крайне мало УАТС не могут работать со шлюзами SIP и единой системой обмена сообщениями Exchange, а некоторые УАТС могут взаимодействовать с сервером единой системы обмена сообщениями напрямую по протоколу SIP через TCP.
Единая система обмена сообщениями Exchange поддерживает для хранения сообщений голосовой почты три аудиокодека: G.711 PCM Linear, GSM 06.10 и Windows Media® Audio (WMA). Каждый WAV-файл, сжатый аудиокодеком PCM Linear, требует примерно 16 КБ на каждую секунду звука. Аудиокодек WMA используется в единой системе обмена сообщениями по умолчанию и сжимает звук до 1,1 килобит (кбит) на каждую секунду звука плюс 7 КБ на заголовок. Аудиокодек GSM 06.10 сжимает звук до 1,6 кбит на каждую секунду звука, но использует заголовок меньшего размера, чем кодек WMA.
Аудиокодеки WMA и GSM 06.10 обеспечивают приемлемое качество звука для голосовых сообщений. Практический опыт использования кодеков WMA и GSM показывает, что размер хранилища почтовых ящиков возрастает на 10-20% в зависимости от интенсивности использования организацией голосовой почты.
При выборе аудиокодека, который будет использоваться в конкретной среде, следует учитывать мобильные устройства и операционные системы, которые могут использовать абоненты. Основной вопрос заключается в том, смогут ли пользователи прослушивать сообщения голосовой почты на устройствах с операционной системой Windows Mobile®. Также следует принять во внимание и другие операционные системы: возможно, в организации развернуто большое количество компьютеров с операционной системой Linux, в которой не удастся воспроизвести WMA-файлы. В любом случае, необходимо понимать, что подобные факторы повышают требования к службе поддержки, возможно, даже потребуется дополнительное обучение сотрудников.

Настройка и тестирование
Независимо от того, какая архитектура единой системы обмена сообщениями используется — централизованная или распределенная, перед развертыванием в организации единой системы обмена сообщениями необходимо учитывать множество требований к голосовой почте. Подробный список вопросов, которые необходимо обсудить группе проектировщиков, см. на врезке «Контрольный список для единой системы обмена сообщениями». Сведения по всем вопросам необходимо собрать для каждого узла, где планируется внедрить единую систему обмена сообщениями. Помните, что над этими вопросами должны совместно работать отделы ИТ и связи.
После создания проекта системы и завершения настройки необходимо протестировать систему. В архитектуре с несколькими узлами рекомендуется протестировать по крайней мере два отдельных узла, чтобы убедиться в работоспособности системы и проверить правильность ее функционирования.
При разработке плана тестирования функциональных возможностей следует отталкиваться от требований к конфигурации. План тестирования функциональных возможностей должен учитывать методы доступа абонентов (по телефону, через Outlook 2007 или веб-клиент Outlook), методы администрирования и сбои оборудования и сети.
После завершения тестирования и подтверждения того, что все функции существующей системы голосовой почты поддерживаются единой системой обмена сообщениями либо альтернативным решением, созданным для тех функций или конфигураций, которые невозможно продублировать, для проверки системы необходимо выбрать пилотную группу пользователей. Пилотная группа позволит отработать действия по перемещению (или, на жаргоне телефонистов, переключению) абонентов из старой системы голосовой почты в единую систему обмена сообщениями. Как правило, при переключении выполняются следующие действия.
  1. Отключение абонента от существующей системы голосовой почты.
  2. Включение для абонента поддержки единой системы обмена сообщениями в Active Directory с помощью консоли управления Exchange.
  3. Изменение зоны обслуживания телефона на телефонный номер доступа к единой системе обмена сообщениями.
Важно отключить абонента от существующей системы голосовой почты, чтобы сообщения не отправлялись в старый почтовый ящик.
На этапе пилотной проверки необходимо собрать у абонентов все вопросы, касающиеся функционирования системы. Задокументировав эти сведения, можно в дальнейшем устранить ряд типичных проблем на этапе обучения.
Обучение пользователей критически важно для успешного перехода на новую систему. Абоненты привыкли получать доступ к голосовой почте по телефону, используя особый интерфейс пользователя. Например, в некоторых системах голосовой почты для прослушивания сообщений необходимо нажать на телефоне кнопку 5. В единой системе обмена сообщениями Exchange пользователь должен нажать на телефоне кнопку 1 или произнести фразу «голосовая почта» (либо воспользоваться Outlook 2007 или веб-клиентом Outlook для воспроизведения голосовых сообщений). Обучение абонентов единой системы обмена сообщениями должно включать обучение навигации с помощью телефона, голосового доступа к Outlook и навигации Outlook или веб-клиента Outlook.
В единой системе обмена сообщениями Exchange 2007 использование голосовых команд осуществляется с помощью голосового доступа к Outlook. Некоторые пользователи приходят в восторг от новых возможностей системы, и это значительно упрощает переход от одного интерфейса к другому.
В единой системе обмена сообщениями Exchange при подключении новых пользователей можно отправлять им по электронной почте настраиваемое текстовое сообщение. Подобные сообщения могут содержать ссылки на типичные вопросы и ответы, документацию абонента, номера телефонов службы поддержки и т.д. Они также могут содержать сведения о доступе к системе голосовой почты и уникальный пароль абонента. Это одна из наиболее мощных возможностей, которой можно воспользоваться при подключении к системе конечных пользователей.

Перенос пользователей
Контрольный список для единой системы обмена сообщениями
В следующих разделах приведены определения некоторых базовых элементов единой системы обмена сообщениями и вопросы, на которые необходимо ответить при подготовке к развертыванию и настройке единой системы обмена сообщениями Exchange Server 2007. Используйте данный раздел в качестве контрольного списка при разработке плана развертывания.
Абонентские группы. Абонентская группа единой системы обмена сообщениями логически соответствует УАТС и связанным с ней добавочным номерам. Ниже приведены некоторые аспекты абонентской группы, которые необходимо учитывать заранее.
  • Сколько цифр будет в добавочном номере?
  • Какой телефонный номер будет использоваться для доступа к единой системе обмена сообщениями?
  • Какой номер необходимо набрать для выхода на внешнюю линию?
  • Какой аудиокодек будет использоваться для записи сообщений?
  • Каков добавочный номер оператора компании?
Сервисные группы и номера доступа. Сервисная группа — это набор добавочных телефонных номеров, настроенных на прием звонков в определенном порядке. Телефонный номер доступа является основным добавочным номером, используемым для доступа к сервисной группе. Количество добавочных номеров в сервисной группе должно совпадать с количеством портов голосовой почты.
Политики почтовых ящиков. Политики почтовых ящиков голосовой почты практически не отличаются от политик почтовых ящиков Exchange. Ниже приведены некоторые политики, которые необходимо обсудить в процессе проектирования.
  • Сколько дней будут храниться сообщения голосовой почты перед удалением?
  • Как часто следует менять пароль для голосовой почты?
  • Какова политика резервного копирования голосовой почты?
  • Какова минимально возможная длина пароля?
  • Каково максимальное количество неудачных попыток входа в систему, после которого почтовый ящик будет заблокирован?
Автосекретарь. Автосекретарь отвечает на входящие звонки, не предназначенные определенному абоненту. Автосекретарь может сообщать звонящим определенные сведения и перенаправлять их в другие отделы организации. В единой системе обмена сообщениями Exchange для навигации с помощью автосекретаря используется DTMF и голосовой ввод. В отношении автосекретарей необходимо учитывать факторы, указанные ниже.
  • Будет ли автосекретарь использовать различные приглашения в дневное время, ночное время и в праздники? (Приглашения необходимо задокументировать и записать).
  • Кому можно будет позвонить из меню автосекретаря?
  • Будет ли использоваться голосовая навигация?
  • Будет ли использоваться несколько языков?
Общий (ночной) почтовый ящик. В некоторых организациях используется общий (ночной) почтовый ящик для голосовой почты, позволяющий звонящим оставлять общие сообщения. Если в компании имеется такой ящик, для него необходимо создать почтовый ящик Exchange и включить для него поддержку единой системы обмена сообщениями.
Индикация ожидающих сообщений (MWI). Функция индикации ожидающих сообщений соответствует индикатору на телефоне и напоминает о наличии в почтовом ящике непрочитанных голосовых сообщений. Требуется ли в процессе развертывания реализовать в телефонах функцию индикации ожидающих сообщений?
Поддержка нескольких добавочных номеров. Во многих организациях имеются сотрудники с несколькими телефонами. При включении таких абонентов в единую систему обмена сообщениями необходимо связать с ними все их добавочные номера. Перед началом работы составьте список сотрудников с несколькими добавочными номерами.
Поддержка интерактивного речевого ответа (IVR). В некоторых традиционных системах голосовой почты поддерживаются приложения интерактивного речевого ответа, не имеющие аналогов в единой системе обмена сообщениями. Выясните, имеются ли в старой системе подобные приложения. Такие приложения можно оставить в существующей системе или либо заменить их на альтернативные приложения интерактивного речевого ответа.
Сеть голосовой почты. С помощью сети голосовой почты можно отправлять сообщения из одной системы в другую, с ней не связанную систему. Например, генеральному директору крупной организации потребовалось отправить голосовое сообщение всем сотрудникам организации или необходимо объявить о пожарных учениях. С помощью сети голосовой почты генеральный директор может записать голосовое сообщение один раз и отправить его каждому сотруднику компании, вне зависимости от используемой конкретным сотрудником системы голосовой почты. В настоящее время единую систему обмена сообщениями Exchange невозможно объединить в сеть с другими традиционными системами голосовой почты.
Поддержка факсов. В некоторых традиционных платформах голосовой почты поддерживаются входящие факсимильные сообщения, что позволяет использовать один телефонный номер как для голосовых, так и для факсимильных сообщений. В единой системе обмена сообщениями сервера Exchange Server 2007 поддерживаются входящие факсимильные сообщения, поэтому ее можно использовать в качестве замены этой возможности. Эта функция односторонняя; система не позволяет отправлять факсимильные сообщения. Если это необходимо, для поддержки этой функции потребуется установить программный продукт стороннего производителя.

Существует несколько точек зрения на то, каким образом следует переводить систему из тестовой в производственную среду. Две основные методологии — это постепенный переход и мгновенное переключение. Вне зависимости от выбранной методологии необходимо обучить сотрудников службы поддержки общим вопросам, полученным от пилотной группы пользователей. Кроме того, убедитесь в том, что сотрудники службы поддержки знают, как включить пользователя в систему, как проверить, что пользователь включен, и как изменить пароль.
Перенос пользователей из старой системы голосовой почты в единую систему обмена сообщениями достаточно прост, но имеется одна серьезная проблема, которую следует иметь в виду: сеть голосовой почты. Подобно тому, как система электронной почты позволяет отправлять, пересылать и отвечать на сообщения других пользователей и систем, система голосовой почты также позволяет отправлять, пересылать и отвечать на голосовые сообщения других пользователей и систем.
Рассмотрим ситуацию, в которой Алла и Борис используют старую систему голосовой почты. Борис перешел на использование единой системы обмена сообщениями и хочет отправить сообщение Алле в старую систему голосовой почты. Поскольку пользователи находятся в различных системах, они не могут больше отправлять, пересылать и отвечать друг другу на сообщения голосовой почты; к сожалению, голосовая почта стала изолированной.
Способ решения данной проблемы в традиционных системах голосовой почты заключается в использовании преобразователя сетевого протокола, с помощью которого можно объединить в сеть разнородные системы. Однако в настоящее время не существует преобразователя сетевых протоколов, с помощью которого можно было бы объединить единую систему обмена сообщениями Exchange Server 2007 с другими системами. Хотя для организации это может быть не важно, эту проблему следует иметь в виду при переносе пользователей в малых группах.
Я предпочитаю выполнять мгновенное переключение всех пользователей на каждом узле. Мгновенное переключение четко отделяет одну систему от другой. Перенос часто выполняется на выходных; пользователи отправляются домой в пятницу, а вернувшись на работу в понедельник, видят новую систему голосовой почты. Некоторые администраторы утверждают, что мгновенное переключение следует применять только для мелких организаций или удаленных узлов. Позволю себе не согласиться. Мне приходилось выполнять мгновенное переключение 7000 пользователей, работающих в одном месте; при этом менее 1% сотрудников обратилось в службу поддержки. Если все остальные этапы проекта были запланированы и проведены надлежащим образом, переход из тестовой среды в производственную должен пройти безболезненно.
Однако при переводе в производственную среду нескольких узлов следует начинать с самых маленьких удаленных узлов, переводя их по одному за раз, а в конце перевести самый крупный узел. Учитесь на ошибках, возникающих при переводе более мелких узлов, чтобы внести соответствующие изменения в проект.
Как правило, перед подключением системы обучение пользователей должно быть завершено и для них должна быть включена поддержка единой системы обмена сообщениями. Ниже приведено пошаговое руководство по подготовке к мгновенному переключению системы голосовой почты.
Первое, что необходимо сделать, — это проверить, что единая система обмена сообщениями полностью установлена, настроена и протестирована.
Обучение следует проводить в небольших группах. Объясните пользователям, что их почтовые ящики будут включены перед работой в системе и что они могут войти в свой почтовый ящик и инициализировать его, изменив пароль и записав приветствие. После завершения обучения необходимо сразу же включить этих пользователей, чтобы они могли инициализировать свои почтовые ящики перед переключением.
Наконец, когда все пользователи будут обучены, выберите выходные, чтобы отключить всех пользователей от старой системы голосовой почты и настроить их телефонные номера для единой системы обмена сообщениями Exchange. В понедельник утром система будет работать для всех пользователей в организации.

Заключение
Независимо от количества узлов в организации (одного или нескольких), сведения, приведенные в данной статье, должны оказаться полезными. Организации с несколькими узлами сложнее в проектировании, но основные требования одинаковы и для 50, и для 5000 пользователей.
Я еще раз настаиваю на том, что отделы ИТ и связи должны работать вместе в процессе развертывания единой системы обмена сообщениями. Мой опыт показывает, что в большинстве случаев сбой проекта развертывания единой системы обмена сообщениями происходит из-за разногласий между отделом ИТ и отделом связи, а несогласованные действия — верный признак грядущей неудачи. Объединение технологий не настолько сложный процесс, но он может потребовать привлечения стороннего специалиста, одинаково хорошо разбирающегося в информационных технологиях и телекоммуникациях, который организовал бы совместную работу обоих отделов или составил план успешного развертывания проекта.

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


 Безопасность: Руководство по основам расследований на компьютерах
Безопасность Том Клауард (Tom Cloward) and Фрэнк Сайморджей (Frank Simorjay)

Руководство по основам расследований на компьютерах
Краткий обзор:
  • Решение «The Fundamental Computer Investigation Guide for Windows» (руководство по компьютерным расследованиям для Windows)
  • Решение Malware Removal Starter Kit (набор для удаления вредоносных программ)
  • Создание набора для расследований на основе Windows PE
  • Сохранение информации для анализа

Злоумышленники могут использовать компьютеры для незаконной деятельности самыми разными способами — взламывать системы, выкрадывать коммерческие тайны, похищать личные сведения и т.д. Постоянно появляются сведения о новых уязвимостях
и методах их использования в злонамеренных целях. Гораздо реже можно узнать о том, как использовать компьютеры для расследования таких злонамеренных действий.
Для некоторых видов расследований требуются высококвалифицированные специалисты, применяющие сложные методики и дорогостоящее оборудование. Однако существуют и более доступные методы, применяемые для простых расследований и анализа. В этой статье мы рассмотрим методики анализа работы компьютеров, доступные для обычных администраторов.
В статье описываются два решения, которые можно загрузить бесплатно: «The Fundamental Computer Investigation Guide for Windows» (go.microsoft.com/fwlink/?LinkId=80344и Malware Removal Starter Kit (go.microsoft.com/fwlink/?LinkId=93103). В этой статье мы узнаем, как с помощью этих двух решений создать среду предустановки Windows® PE, в которой можно эффективно исследовать состояние компьютера и сохранить результаты исследования для отчетов и анализа. Обратите внимание, что описываемую методику нельзя применять для жестких дисков с шифрованием или входящих в RAID-массив. Кроме того, если жесткий диск поврежден, понадобится сначала выполнить необходимые действия по его восстановлению.
В нашем решении описывается удобный способ сбора доказательств на компьютере под управлением Windows, но это все же весьма простой способ. Существует ряд усовершенствованных коммерческих решений, с помощью которых можно выполнить описываемые действия гораздо более эффективно.
Также имейте в виду, что описываемая нами методика не является гарантированно надежной и не сертифицирована Международным обществом исследователей компьютеров (ISFCE). Перед началом расследования следует решить, могут ли доказательства, найденные на жестком диске, быть использованы в судебном разбирательстве. Если такая вероятность существует, к проведению расследования должен был привлечен сертифицированный специалист по исследованию компьютеров. В зависимости от вида возможного судебного разбирательства следует принять решение о том, следует ли передать расследование непосредственно в соответствующие правоохранительные структуры. Дополнительные сведения об этом см. в руководстве «The Fundamental Computer Investigation Guide for Windows».

О решениях Solution Accelerator
В руководстве «Fundamental Computer Investigation Guide for Windows» рассматриваются процессы и средства, используемые для анализа компьютеров. В руководстве выделены четыре этапа расследования на компьютере: оценка ситуации, получение данных, анализ данных, отчет. Это удобная модель, с помощью которой ИТ-специалисты могут проводить расследования, фиксируя важные факты.
В руководстве также указано, в каких случаях следует привлекать правоохранительные структуры. При принятии таких решений следует обращаться к юридическим консультантам. Также в этом руководстве содержатся сведения о преступлениях в компьютерной области, о том, как обращаться в правоохранительные структуры, а также о программах Windows Sysinternals и прочих программах Windows, которые могут пригодиться при проведении расследований.
Второе решение типа Solution Accelerator, на которое мы ссылаемся в этой статье — это Malware Removal Starter Kit. В этом решении содержатся советы о том, как создать загрузочный диск Windows PE для удаления вредоносных программ с компьютера. Также это руководство включает список угроз и некоторые способы их устранения, с помощью которых можно снизить ущерб в организациях. Кроме того, подчеркивается важность заблаговременной разработки плана действий на случай возможного проникновения вредоносных программ в систему. Подход, применяемый в решении Malware Removal Starter Kit, также включает четыре этапа работы: нужно определить вид вредоносных программ, ограничить их распространение, удалить их, если возможно, убедиться в том, что они удалены, и перейти к дальнейшим действиям.

Компакт-диск Windows PE
Для выполнения расследования понадобятся две вещи: компакт-диск Windows PE и внешний накопитель, например флэш-накопитель USB.
Возможно, когда вы смотрели детективы по телевизору, то обратили внимание, что сотрудники правоохранительных органов должны зафиксировать состояние места преступления без изменений. По этой же причине нужно сохранить данные на исследуемом жестком диске. В отличие от диска с набором Malware Removal Starter Kit, создаваемый нами загрузочный диск Windows PE будет запускать программы только так, чтобы они никаким образом не изменяли данные на жестком диске.
При использовании диска Windows PE загружается ограниченная среда Windows. При создании этого загрузочного диска можно добавить на него программы (такие как Malware Removal Starter Kit), заранее настроенные для определенных целей. Обратите внимание, что на компьютере должно быть не менее 512 МБ ОЗУ — это требование Windows PE.
Процесс создания загрузочного компакт-диска Windows PE, подробно описанный в Malware Removal Starter Kit, довольно прост. Перед созданием этого загрузочного диска нужно установить набор автоматической установки Windows (AIK), пакет Sysinternals Suite (доступный по адресу microsoft.com/technet/sysinternals/utilities/sysinternalssuite.mspx), поместить программы Sysinternals в список программ, как описано в задаче 2 решения Malware Removal Starter Kit, и установить прочие средства для проверки на наличие вредоносных программ. Подробные инструкции по созданию диска см. в документе Malware Removal Starter Kit.

Внешний USB-накопитель
Поскольку нельзя менять данные на исследуемом диске, понадобится внешний флэш-накопитель или жесткий диск для сохранения файлов. (Рекомендуется применять флэш-накопитель USB, поскольку Windows PE автоматически подключает USB-устройства.) Также можно использовать внешний жесткий диск для сохранения образа исходного жесткого диска. При этом важно заранее спланировать, сколько места на диске потребуется для расследования.
Нужно убедиться в том, что для расследования используются только нужные программы, поэтому с внешнего жесткого диска, который будет использоваться для расследования, нужно полностью удалить все данные. Для этого можно применить программы, полностью стирающие и перезаписывающие весь диск. Затем внешний диск можно отформатировать и установить нужную метку для использования в расследовании. Эти меры предосторожности необходимы для того, чтобы на внешнем диске не осталось лишних файлов, которые могли бы повлиять на данные, собранные во время расследования.
Также следует использовать форму цепи обеспечения сохранности, чтобы официально зафиксировать в документах, кто работал с компьютером в ходе расследования. В руководстве «The Fundamental Computer Investigation Guide for Windows» содержится пример такой формы. После подготовки набора (с загрузочным диском Windows PE, внешним накопителем и формой) можно начать расследование.

Выполнение расследования
Итак, приступаем к расследованию. Прежде всего, нужно загрузить компьютер с диска Windows PE. Убедитесь, что в установленном на компьютере порядке загрузки первым загрузочным устройством является дисковод для компакт-дисков. При получении запроса нажмите любую клавишу для загрузки с компакт-диска. Это позволит запускать программы, записанные на диске.
Мы будем использовать набор на тестовом компьютере, чтобы продемонстрировать, как собирать данные. Тестовый компьютер будет называться Testbox1. Дисковод для компакт-дисков на компьютере Testbox1 обозначен буквой X:\, а папка программ набора Malware Removal Starter Kit по умолчанию —X:\tools. Чтобы перейти в эту папку, введите простую команду: cd \tools.
Существует несколько программ, с помощью которых можно узнать, какие диски установлены на компьютере. Программа Bginfo.exe, находящаяся в папке программ Sysinternals, может предоставить такие данные и поместить их в фоновое окно рабочего стола для справки. Программа Drive Manager также может определить все диски на компьютере, включая логические диски и внешнее USB-устройство. На рис. 1 показаны сведения о дисках компьютера Testbox1. Загрузочный диск — X:\, нужный нам исходный жесткий диск — C:\, а внешний USB-накопитель —F:\.
Figure 1 Viewing disk information with Drive Manager
Figure 1 Viewing disk information with Drive Manager

Проверка наличия вредоносных программ
Перед началом расследования нужно убедиться в наличии вредоносных программ, которые могли бы повлиять на собираемые данные. Отчет, создаваемый средством удаления вредоносного ПО, при необходимости можно использовать как доказательство. Если компьютер не проверен на наличие вредоносных программ, это может подвергнуть риску расследование и заставить усомниться в квалификации проверяющего, в его аккуратности и тщательность работы. Рекомендуем использовать предоставленные средства обнаружения вредоносного ПО в режиме чтения или в режиме отчетов.
В наборе Malware Removal Starter Kit перечислено несколько рекомендуемых средств, включая средство удаления вредоносных программ Майкрософт и McAfee AVERT Stinger. При запуске средства удаления вредоносных программ Майкрософт обязательно используйте в командной строке параметр /N, чтобы средство не пыталось удалить вредоносные программы, а только составило отчет о них:
x:\tools\windows-KB890830-v1.29.exe /N
Файл отчета будет находиться в папке %windir%\debug\mrt.log.
Сходным образом, при запуске McAfee AVERT Stinger выберите режим «Report only», как показано на рис. 2, чтобы компьютер был проверен без каких-либо изменений на жестком диске. После проверки обязательно сохраните отчет.
Figure 2 Use Report only mode in McAfee AVERT Stinger
Figure 2 Use Report only mode in McAfee AVERT Stinger

Сохранение важных файлов
Если перед началом исследования не была создана копия всего диска, нужно скопировать хотя бы самые важные файлы пользователей. Данные о конфигурации могут быть использованы для изучения в дальнейшем. Для начала нужно скопировать файлы и параметры реестра, содержащие все важные сведения о том, как работал компьютер, и какие программы были установлены.
Чтобы сохранить реестр компьютера Testbox1, сначала создадим папку на съемном диске F:\, а затем запишем дату и время начала исследования с помощью следующих команд:
f: Mkdir f:\evidence_files Date /t >> f:\evidence_files\Evidence_start.txt Time /t >> f:\evidence_files\Evidence_start.txt
Теперь сохраним реестр с помощью команды xcopy. Эта команда копирует всю папку конфигурации и ее содержимое. Нужные нам файлы реестра находятся в папке %windows%\system32\config. Запустим следующую команду:
xcopy c:\windows\system32\config\*.* f:\registrybkup /s /e /k /v
При этом будут скопированы все данные конфигурации из папки config. В папке config компьютера Textbox1 содержится около 95 МБ данных.
Теперь займемся данными пользователей. Эти данные могут находиться где угодно на диске. В нашем примере скопируем данные только из папки C:\HR. Чтобы полностью скопировать все данные из этой папки и вложенных папок, снова используем команду xcopy:
Mkdir f:\evidence_files\HR_Evidence Mkdir f:\evidence_files\documents_and_settings Mkdir f:\evidence_files\users xcopy c:\HR\*.* f:\evidence_files\HR_Evidence /s /e /k /v
Теперь скопируем личные папки. Нужно скопировать все данные, включая и вложенные папки. Для этого используем следующие команды:
Xcopy c:\documents and settings\*.* f:\evidence_files\documents_and_settings /s /e /k /v

Xcopy c:\users\*.* f:\evidence_files\users /s /e /k /v
В нашем примере собрано около 500 МБ данных, которые теперь можно при необходимости анализировать. Объем собранных данных может быть огромным, особенно если среди этих данных будут звуковые файлы, видео и фотографии. Тем не менее, нужно постараться сохранить как можно больше исходных данных, поскольку в ходе расследования может потребоваться не только собрать данные, но и гарантировать, что данные не были изменены в процессе сбора. Лучше всего создать образ всего диска, но это может быть затруднено из-за ограничений по размеру. Именно поэтому лучше заранее продумать, сколько места может понадобиться для расследования.

Сбор дополнительных сведений
При сборе доказательств могут пригодиться и системные файлы, однако их сбор не так прост: эти файлы могут находиться в разных местах. Тем не менее, некоторые типы файлов стоит найти, потому что они могут содержать полезные данные. Например, файлы подкачки содержат данные о том, какие файлы были прочитаны в память. Кроме того, файлы подкачки могут содержать подробные данные об использовании системы. Данные веб-обозревателей и файлы «cookie» содержат сведения о посещенных веб-узлах.
Найти эти данные не всегда просто, особенно если пользователь изменил конфигурацию и сохранял эти данные не в папках по умолчанию, а в других папках. Для поиска важных файлов можно использовать некоторые программы Sysinternals. На рис. 3 перечислено пять полезных приложений и описано, как они могут помочь в исследовании.
Figure 3 Tools to locate files and data of interest (Close Figure 3)

Приложение | Описание
AccessChk | Показывает сведения об обращениях указанного пользователя или группы к файлам, разделам реестра и службам Windows.
AccessEnum | Показывает права доступа пользователей папкам, файлам и разделам реестра на компьютере. Этот инструмент можно использовать для поиска ошибок при назначении разрешений.
Du | Показывает, сколько места на диске занимает каждая папка.
PsInfo | Отображает сведения о компьютере.
Strings | Поиск строк в формате ANSI и Юникод в двоичных образах.

Том Клауард (Tom Cloward), обладатель сертификатов CCE и CISSP — руководитель программы в корпорации Майкрософт. Его работа — разработка решений в области соответствия нормам и безопасности для ИТ-специалистов. Том проработал свыше 15 лет в области программного обеспечения и информационных технологией. Он увлекается ИТ-безопасностью, анализом данных и обеспечением соответствия систем законодательным нормам.
Фрэнк Сайморджей (Frank Simorjay), обладатель сертификатов CISSP и CET — технический руководитель программы и эксперт по безопасности в группе Solution Accelerator—Security and Compliance корпорации Майкрософт. Он проектирует решения по безопасности для клиентов Майкрософт. Последняя его работа — решение Malware Removal Starter Kit — доступна в сети Microsoft TechNet.


 Сети: Отчет корпорации Майкрософт по безопасности
Сети Тим Рейнс (Tim Rains)

Отчет корпорации Майкрософт по безопасности
Краткий обзор:
  • Тенденции в разглашении уязвимостей программ и вредоносное ПО
  • Влияние угроз на различные версии Windows
  • Наиболее и наименее опасные области в мире

Корпорация Майкрософт собирает данные с миллионов компьютеров, подключенных к Интернету, и с крупнейших в мире сетевых служб, что позволяет получить очень точное представление об угрозах безопасности, с которыми в настоящее время сталкиваются пользователи Интернета.
по защите от вредоносных программ (MMPC), отдел Microsoft Security Response Center (MSRC), группа Trustworthy Computing (TwC) и многочисленные группы продуктов. Отчет по безопасности содержит подробное рассмотрение последних тенденций в разглашении уязвимостей, а также в развитии вредоносных и нежелательных программ, таких как шпионские и рекламные программы. В отчете также указываются различия в положении разных версий ОС Windows с точки зрения безопасности, и в каких регионах мира более всего распространены вредоносные программы. Последняя версия отчета, посвященная тенденциям за первую половину 2007 года, включает новый раздел, в котором рассказывается о средствах взлома, создаваемых для уязвимостей в программах. Если вы отвечаете за безопасность компьютеров или эта тема вас интересует, то чтение отчета по безопасности будет вам полезно, поскольку вы узнаете обо всех угрозах, связанных с Интернетом.
Последний отчет по безопасности свидетельствует о том, что исследователи находят все больше уязвимостей в программах всех поставщиков. Только за первую половину 2007 года стало известно о более чем 3400 уязвимостей. Впрочем, общий процент уязвимостей, получивших огласку, снижается.
Что это значит? Возможно, исследователи безопасности сосредотачиваются в основном на приложениях, поскольку безопасность операционных систем постоянно повышается. Более того, поскольку новых приложений создается намного больше, чем новых операционных систем, тенденции обнаружения большого числа уязвимостей может быть вызвана именно этим.
В 2006 году для 29,3% широко известных уязвимостей в продуктах Майкрософт были написаны средства взлома, а по данным на 1 августа 2007 года средства взлома были созданы только для 20,9% широко известных уязвимостей. Число уязвимостей постоянно повышается, но процент уязвимостей, для которых есть код взлома, остается неизменным и даже слегка снижается. Труднее всего найди код взлома для уязвимостей в новых продуктах. Мы провели сравнение продуктов, и оказалось, что для новых версий продуктов риск ниже, чем для версий, которые дольше находятся на рынке. В среднем подверженность взлому снижается в течение срока жизни продуктов, то есть для большинства продуктов более поздние версии лучше защищены. Это наиболее заметно для Windows и Microsoft Office System. В последних версиях обоих семейств (Windows Server® 2003, Windows Vista®, Office 2003 и 2007 Office) отмечено снижение числа уязвимостей.
В отчете по безопасности раскрываются тенденции развития и изменения вредоносных программ. Эти тенденции указывают на тактику, применяемую в атаках пользователей. Рассмотрение данных, полученных из различных источников, включая Microsoft Exchange Hosted Services (EHS), Windows Live® OneCare и программу проверки Windows Live OneCare, средство удаления вредоносных программ Windows Tool (MSRT) и Windows Defender, позволяет оценить положение с разных точек зрения.
В распространении вредоносных программ все большую роль играет прикладная социология. Такие атаки вынуждают пользователей выполнять какие-либо действия, снижающие эффективность защитных механизмов. По данным EHS, в первой половине 2006 года крупнейшей угрозой, передаваемой по электронной почте, были классические почтовые черви — их объем составил 95% среди всех вредоносных программ, обнаруженных в электронной почте. Начиная со второй половины 2006 года эта доля снизилась до 49% и осталась постоянной в первой половине 2007 года (см. рис. 1). Фишинговые атаки и электронные сообщения с вредоносными рамками IFrame составили 27% обнаруженных атак в электронной почте во второй половине 2006 года, а в первой половине 2007 года их доля возросла до 37%. Средства загрузки троянских коней в электронных письмах составили 20% всех обнаруженных угроз в электронной почте во второй половине 2006 года, но в первой половине 2007 года их доля снизилась до 7%.
Figure 1 Composition of infected e-mail in the first half of 2007
Figure 1 Composition of infected e-mail in the first half of 2007
Данные, собранные в службах Windows Live OneCare и в системе проверки безопасности Windows Live OneCare (safety.live.com), показывают, что в первой половине 2007 года увеличилось число вирусов, троянских коней и вредоносных программ для несанкционированного управления удаленными компьютерами, кражи паролей и кражи данных.
Средство удаления вредоносных программ (MSRT) предназначено для удаления наиболее распространенных вредоносных программ с компьютеров пользователей. Это средство распространяется как важное обновление посредством Центра обновления Windows, Центра обновления Майкрософт и системы автоматического обновления. За последние два года при помощи MSRT было удалено 50,3 млн. вирусов с 20,5 млн. компьютеров во всем мире. В общей сложности средство удаления вредоносных программ было запущено более 7,4 млрд. раз, включая 1,9 млрд. раз в первой половине 2007 года.
MSRT — удобный источник данных и для корпорации Майкрософт, и для пользователей. По данным MSRT степень заражения в ОС Windows Vista и Windows XP с пакетом обновления 2 значительно ниже, чем среди прежних версий Windows, как показано на рис. 2. Посредством средства MSRT с ПК под управлением Windows Vista было на 60% меньше вредоносных программ, чем с ПК под управлением Windows XP с пакетом обновления 2, и на 91,5% меньше, чем с ПК под управлением Windows XP без пакетов обновления. Интересно отметить, что число вирусов на каждом компьютере практически не меняется со временем: на каждом зараженном компьютере обнаруживается в среднем 2,2 вируса.
Figure 2 OS versions cleaned by the MSRT in the first half of 2007
Figure 2 OS versions cleaned by the MSRT in the first half of 2007
Как правило, в развивающихся странах обнаруживается больше вредоносных программ, чем в развитых странах. Например, в Европе страны с наибольшим числом заражений — Албания и Турция, а меньше всего заражений в Италии и Финляндии. В Азиатско-Тихоокеанском региона больше всего заражений в Монголии и Таиланде, а меньше всего — в Новой Зеландии и Японии. В США пропорциональное число зараженных систем ниже, чем в большинстве других стран Северной и Южной Америки, и примерно соответствует среднемировому значению. В среднем, за первую половину 2007 года средством удаления вредоносных программ было обнаружено и устранено вредоносное ПО на одном из 216 компьютеров.
Защитник Windows Defender работает под управлением ОС Windows Vista, Windows XP и Windows Server 2003. За первую половину 2007 года было обнаружено около 50,7 млн. копий нежелательных программ, при этом на ПК с Windows Vista таких программ было обнаружено примерно в 2,8 раза меньше, чем на ПК с Windows XP с пакетом обновления 2. Число обнаруженных копий нежелательных программ в ОС Windows Server 2003 также примерно вдвое выше, чем в Windows Vista.
Вы скажете: «статистика, конечно, интересная, но как она может пригодиться для защиты информационной среды?» В последнем отчете о безопасности перед всеми основными разделами приводится их краткая сводка и набор «Стратегия, защита и противодействие». С помощью этих списков можно быстро узнать, чему посвящен каждый отчет.
Кроме того, можно использовать данные, советы и руководства в отчетах для укрепления системы безопасности с учетом постоянно изменяющихся угроз. Полный отчет, содержащий стратегию, данные о защите и противодействии, основанные на важнейших обнаруженных угрозах, можно загрузить по адресу microsoft.com/sir.

Тим Рейнс (Tim Rains) — менеджер по продуктам в центре Майкрософт по защите от вредоносных программ (MMPC). К сфере его ответственности относится выпуск отчета корпорации Майкрософт по безопасности. Авторы отчета по безопасности — Джефф Джонс (директор отдела Microsoft Trustworthy Computing Group), Джефф Уильямс (директор MMPC), Майк Риви (менеджер группы в отделе Microsoft Security Response Center) и Зив Мадор (старший руководитель программ и координатор ответов в MMPC).


 Сети: Выявление скрытых неполадок в сети
Сети Кристофер Стонеф (Christopher Stoneff)

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

Возможно, вы сталкивались с этим неоднократно: один компьютер неизвестно почему не может связаться с другими. Система управления находится в одном сегменте сети с маршрутизаций, подключенного к другим сегментам сети с помощью маршрутизатора, например сервера Microsoft Internet
Security and Acceleration (ISA) Server или другого устройства. При управлении десятью, двадцатью и даже сотней системам никаких неполадок не возникает. Но при попытке управлять 500 системами ваш компьютер не может связаться по сети с другими компьютерами за исключением тех, к которым уже открыты подключения. Невозможно обмениваться данными с другими системами, невозможно выйти в Интернет, но ни у кого во всей сети, в том числе и в вашем сегменте, нет таких неполадок. Где прежде всего стоит искать причину?

Диагностика неполадки
В такой ситуации прежде всего следует предположить сбой программы, управляющей системами. Многие средства управления могут подключаться к другим компьютерам и управлять ими, но иногда такие средства сами могут вызвать неполадки, которые вы пытаетесь устранить. Причина заключается в том, что средства управления могут создавать тысячи подключений к устройствам в целях управления. В Windows® эти подключения по умолчанию остаются открытыми в течение двух минут даже в случае простоя, если только какая-либо программа, приложение или служба не продлит срок действия этих подключений. Это означает, что даже если система управления не обращалась к другим компьютерам в течение двух минут, может быть по-прежнему более 1000 открытых подключений. (Чтобы увидеть открытые подключения, можно выполнить в командной строке команду NETSTAT. С помощью этой команды можно увидеть все открытые, ожидающие и закрывающиеся подключения к системе и их состояние. Описания сообщений о состоянии приведены в документе RFC 793 по адресу tools.ietf.org/html/rfc793.)
Чтобы определить, что именно система управления вызывает сбой, можно создать пакетный файл, устанавливающий подключение к удаленным системам. Если такая же неполадка возникнет при запуске пакетного файла, то система управления не имеет отношения к неполадке. Вот пример содержимого такого пакетного файла:
Net use \\system01\ipc$ Net use \\system02\ipc$ Net use ...
Если программа управления использует свой собственный сетевой стек и стек проверки подлинности, причина неполадки может заключаться в этой программе, однако в решениях без агентов, таких как большинство систем управления, для выполнения действий в сети используются системные стеки сети и проверки подлинности. Применение пакетного файла, запускающего столько же сетевых подключений без сбоев, будет означать, что проблема вызвана не тем, как программа использует стеки операционной системы (сетевой и проверки подлинности), поскольку пакетный файл использует их правильно.

Если журналы и сообщения об ошибках не помогают
Возможно, вы обратили внимание, что когда начались неполадки в сети, на компьютере появились сообщения об ошибках: ошибка 53 — сетевой путь не найден, ошибка 64 — имя в сети удалено, ошибка 1203 — поставщик сети не принял указанный сетевой путь. Все эти сообщения могут правильно указывать на наличие соответствующих ошибок, но ведь на других компьютерах нет никаких проблем с разрешением имен и подключением к тем же самым системам. Чтобы проверить правильность параметров компьютера и убедиться, что неполадка вызвана не ими, просто выполните команду ipconfig.
Теперь, поскольку проблема существует только в вашей системе управления, стоит заглянуть в журналы событий. Поиск журналов приложений бесполезен, но в системном журнале окажется событие предупреждения с кодом 4226 из источника TCP/IP, означающее, что достигнуто предельное число подключений (см. рис. 1).
Figure 1 TCP connection limit has been reached
Figure 1 TCP connection limit has been reached
данных об ограничениях подключений в базе знаний Майкрософт приведет к следующему результату: оказывается, есть ограничения, накладываемые на невыполненные подключения, но выполненные подключения ограничений не имеют. Для управления этими свойствами можно изменить значения реестра в разделе HKLM\System\CurrentControlSet\Services\TCPIP. Параметр TcpNumConnections используется для установки максимального числа одновременно открытых TCP-подключений (по умолчанию это число равно 10). Параметр TCPTimedWaitDelay устанавливает время, в течение которого подключение остается в состоянии TIME_WAIT при закрытии. Это время по умолчанию равно 120 секундам, то есть подключение обычно используется в течение 4 минут. Наибольше число подключений также зависит от параметра MaxFreeTcbs. Если все контрольные блоки TCP использованы, протокол TCP должен высвободить подключения, находящиеся в состоянии TIME_WAIT, чтобы создать больше подключений, даже если время, указанное параметром TCPTimedWaitDelay, еще не истекло. Диапазон допустимых значений параметра TCPTimedWaitDelay составляет от 30 до 300 секунд (0x1E – 0x12C).
В зависимости от среды изменение этих параметров реестра может привести к некоторому повышению производительности работы системы. Для устранения ограничений можно также изменить файл TCPIP.sys, но это повлияет только на работу P2P-приложений.

Запись сетевых данных
Если больше ничего не помогает, можно попробовать записать сетевые данные с компьютеров. При запуске сетевого монитора (Netmon) записанные данные в точности соответствовали результатам, которые были очевидны при запуске средств управления и тестовых сценариев: сначала все работает, а потом перестает работать без каких-либо указаний на ошибки.
На рис. 2 показан результат запуска Netmon — успешная связь между первыми и системами. Обратите внимание, что я получаю подтверждения запросов удаленного вызова процедур. Это именно то, что нужно увидеть – успешный двусторонний обмен данными.
Figure 2 Successful communication in Netmon
Figure 2 Successful communication in Netmon
Теперь посмотрим на данные системы управления и удаленных компьютеров, на которых возникает ошибка 53/1203. Как и предполагалось, смотреть не на что: компьютеры не обмениваются данными. В записи сетевых данных на рис. 3система управления преобразовала IP-адрес и пытается подключиться к системе по порту 445 (порт SMB Майкрософт), но не получает ответа.
Figure 3 Attempts to connect to the system over port 445 yield no response
Figure 3 Attempts to connect to the system over port 445 yield no response
Если количество потоков превышает число подключений, которые может установить ваш компьютер в настоящее время, могут возникать различные ошибки. В некоторых случаях в исходной системе возникает ошибка 53, которая означает, что получено преобразование имени, но IP-адрес не был найден. Это означает, что DNS-сервер предоставил адрес, к которому невозможно подключиться. В некоторых случаях возникает ошибка 1203, которая означает, что на запрошенное имя или IP-адрес не ответил ни один компьютер. В этом случае ошибка 1203 означает, что служба DNS недоступна. Чтобы убедиться в этом, можно запустить команду nslookup.
На этом этапе вы, наверное, уже потеряете надежду, но еще есть возможности все исправить. Обычно мало кто обращает внимание на инфраструктуру подключений из-за того, как именно возникает неполадка: ваш компьютер — единственный из всех, которому не удается подключиться к остальной сети, и даже журналы событий свидетельствуют, что на компьютере достигнуто предельное число подключений, поэтому вряд ли причиной неполадки является архитектура сети.
Несмотря на то, что тысячи подключений, создаваемых системой управления, создаются не одновременно, из-за времени ожидания передачи данных и подключений может возникнуть очень большое число одновременно открытых подключений. Поэтому нужно обратить внимание на системы, посредством которых ваш компьютер подключен к остальной сети.
А дело вот в чем. Как я уже говорил выше, весь трафик в вашей сети проходит через коммутаторы, маршрутизаторы и, вероятно, через межсетевые экраны. В любом из этих элементов, обычно в маршрутизаторах или межсетевых экранах, могут применяться системы обнаружения вторжения. В управляемых коммутаторах и маршрутизаторах также может быть включена фильтрация трафика. Тем, кто управляет этими устройствами, нужно проверить их журналы — возможно, в них будут ошибки или предупреждения. Неполадки связи вполне могут быть вызваны именно этими системами.
Вы подключаетесь из внутренней системы к другим внутренним системам, поэтому оповещения не создаются: создание оповещений может быть не настроено на устройствах, или потому что неполадка не рассматривается как вторжение или атака типа «отказ в обслуживании». Итак, снова начнем с журналов. В качестве примера будем использовать ISA Server. В этом случае журналы будут находиться в консоли управления ISA Server в разделе Массивы\<Имя_массива>\Наблюдение\Ведение журнала.
Если вам мешает политика, можно (при использовании ISA Server) поискать следующие коды результатов (исходный IP-адрес — ваш компьютер управления):
  • 0xc0040037 FWX_E_TCP_RATE_QUOTA_EXCEEDED_DROPPED
  • 0xc004000d FWX_E_POLICY_RULES_DENIED
  • 0xc0040017 FWX_E_TXP_SYN_PACKET_DROPPED
Если вы их обнаружили, то причина неполадок в сети найдена.

Применение решения
Итак, теперь проблема установлена, решение может быть простым, но политика отдела может затруднить применение этого решения. Перед внесением каких-либо изменений убедитесь, что у вас есть на это разрешение, поскольку создание исключений в конфигурации безопасности межсетевых экранов, маршрутизаторов и систем обнаружения вторжений может быть запрещено.
На примере ISA Server посмотрим, как увеличить наибольшее число подключений для данного узла или для всех компьютеров сети (см. рис. 4). Откройте консоль управления ISA Server и перейдите в раздел Массивы\<Имя_массива>\Конфигурация\Общие\Настройте параметры предотвращения Flood-атаки.
Figure 4 Increase the maximum number of connections for one host or all machines using ISA Server
Figure 4 Increase the maximum number of connections for one host or all machines using ISA Server
Два нужных нам параметра — наибольшее число одновременных TCP-подключений на IP-адрес и наибольшее число запросов TCP-подключений на IP-адрес в минуту. Предельное число одновременных TCP-подключений на IP-адрес обычно устанавливается таким, чтобы его было достаточно при отсутствии активного управления, то есть одному компьютеру не нужно быстро подключаться к тысячам других компьютеров. В ISA Server наибольшее число одновременных TCP-подключений равно 160. Число запросов TCP-подключений на IP-адрес в минуту устанавливается таким образом, чтобы ограничить нагрузку, вызванную сканированием сети, и его видимость. Это число равно 600 запросам в минуту на каждый IP-адрес.
Как мы уже обсудили выше, в Windows подключение по умолчанию остается активным в течение двух минут, если не предпринимаются никакие действия, чтобы продлить срок действия подключения, даже если оно не используется. Это означает, что подключение к какому-либо компьютеру останется активным даже после того, как все действия по управлению этим компьютером уже выполнены и обмениваться с ним данными больше не нужно. Это открытое подключение остается одним из множества открытых подключений. Если повторить этот процесс более 160 раз, не удаляя подключения, то окажется, что все дальнейшие попытки подключений будут отклонены маршрутизатором. Даже если программа управления активно завершает сеанс, операционная система Windows может оставить подключение в состоянии time_wait, дожидаясь от второго компьютера ответа с согласием на отключение.
Таким образом, прежде всего нужно изменить тот параметр, который вероятнее всего вызывает неполадку: наибольшее число одновременных TCP-подключений на IP-адрес. Значение этого параметра нужно установить таким, чтобы система управления смогла устанавливать все необходимые подключения, не сталкиваясь с запретом доступа. Нажмите кнопку «Изменить» рядом с этим параметром и измените значения.
В следующем окне (см. рис. 5) появится поле «Предел», в котором указано предельное значение по умолчанию, применяемое ко всем клиентским системам. «Настраиваемый предел» применяется ко всем компьютерам, сетям и другим объектам, определенным на вкладке «Исключения IP-адресов» окна предотвращения Flood-атак. Чтобы разрешить всем компьютерам создавать больше подключений, измените значение параметра «Предел». Чтобы настроить исключение только для данного компьютера, измените предельное значение и добавьте данный компьютер на вкладку «Исключения IP-адресов». Рекомендуется разрешить исключения только для вашего компьютера.
Figure 5 Default connection limit and custom connection limit
Figure 5 Default connection limit and custom connection limit
Если нужно изменить это значение только для определенных компьютеров, измените значение в поле «Настраиваемый предел» и нажмите кнопку «ОК». Затем добавьте ваш компьютер на вкладку «Исключения IP-адресов» окна предотвращения Flood-атак. Чтобы добавить только ваш компьютер в список исключений, нажмите на вкладке «Исключения IP-адресов» кнопку «Добавить», чтобы открыть окно «Наборы компьютеров». Щелкните «Создать», чтобы создать новый набор, содержащий ваш компьютер (если такого еще не существует). Выберите этот набор и нажмите кнопку «Добавить», чтобы добавить набор «Внутренние сети», затем нажмите кнопку «Закрыть». Снова выберите набор «Внутренние сети» и нажмите кнопку «Изменить». При этом откроется окно свойств набора «Внутренние сети» (см. рис. 6). Нажмите в этом окне кнопку «Добавить», чтобы открыть вложенное меню, в котором можно добавить компьютер, диапазон адресов или подсеть. Выберите компьютер. Введите имя, чтобы определить эту запись, IP-адрес и понятное описание, чтобы кто-нибудь другой при просмотре этой записи не удалил вашу систему (см. рис. 7). Нажмите кнопку «ОК», чтобы добавить ваш компьютер, затем нажмите ее снова, чтобы добавить исключение. Теперь нужно применить внесенные изменения.
Figure 6 Internal networks properties settings
Figure 6 Internal networks properties settings
Figure 7 Enter computer name, IP address, and description to ensure your system is not removed
Figure 7 Enter computer name, IP address, and description to ensure your system is not removed
Попробуйте снова запустить систему управления. Вы увидите, что производительность стала гораздо выше, а подключения работают без неполадок (во всяком случае, без неполадок, вызванных сетевым трафиком). Таким образом, в итоге выяснилось, что неполадка была вызвана не числом подключений, вызванных программой, а неправильным их планированием.

Извлеченные уроки
Одна из самых больших неприятностей в сфере ИТ — возникновение и устранение проблем, причину которых трудно обнаружить. Эти неполадки не вызваны действиями пользователей или серверной группы, служба поддержки окажется не в курсе, но вы можете отвечать за их устранение. Существуют средства, которые помогут выявить неполадки, обнаружить их и устранить, но иногда их недостаточно. Иногда они работают неправильно. Иногда вам нужно быть умнее таких средств.
Если вдруг возникнет ситуация, когда у вашего компьютера начнутся неполадки с сетевыми подключениями без каких-либо очевидных причин, попробуйте сделать то, о чем я рассказал выше. Вполне вероятно, что, выполнив описанные действия, внимательно изучив работу системы управления и правильно настроив разрешенные подключения, вы успешно решите проблему.

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


 От редактора: Давайте начнем разговор
От редактора
Давайте начнем разговор
Джошуа Хоффман (Joshua Hoffman)

Почти все важные события, которые когда-либо случались в этой жизни, начинались с разговора.
«Честно говоря, я не думаю, что земля плоская. Как вы думаете, может быть, нам это проверить?»
«Почему бы нам не послать космонавта на луну?»
«Давайте обсудим мою идею о новых компьютерах».
«Давайте встретимся и выпьем по чашке кофе».
(Последнее мероприятие нельзя назвать очень важным... Просто я люблю кофе. Впрочем, если мы встретимся за чашкой кофе, нам может придти в голову какая-нибудь важная идея!)
В любом случае, в этом месяце я хотел бы обсудить два уровня, на которых, как мне кажется, утверждение, что все самое важное обычно начинается с разговора, является особенно верным. Первый уровень относится к реальным разговорам, которые постоянно случаются между нами, — в блогах, коридорах зданий и даже в этом выпуске журнала TechNet Magazine (см «Заметки на полях» Роми Махаяна (Romi Mahajan) на стр. 91). На этом уровне все разговоры касаются информационных технологий и происходят они потому, что мы все-таки люди, а не постоянно работающие специалисты по ИТ. Нельзя сбрасывать со счетов один непреложный факт: все, что бы мы ни делали в нашей обыденной жизни, — занимались благотворительностью, пели караоке, играли с приставкой Xbox (да мало ли что еще) — оказывает влияние на нашу работу и те решения, которые принимаются в нашей профессиональной деятельности. Именно поэтому на предстоящей конференции Windows Connections в Лас-Вегасе я, Роми и еще несколько специально приглашенных гостей организуем групповое обсуждение «The Fungible Future» («Многозначное будущее»), на котором будем заниматься только разговорами. Надеюсь, вы присоединитесь к нам лично или примете участие в обсуждении на веб-узле WeWantToKnow.net. Мы также приглашаем вас присоединиться к разговору, который ведется в нашем блоге по адресу blogs.technet.com/tnmag, потому что нам, действительно, важно ваше мнение!
Я хотел бы обсудить сегодня и второй аспект нашей проблемы. Он касается технологий, которые мы используем для того, чтобы наши разговоры состоялись. В выпуске журнала TechNet Magazineза этот месяц мы рассматриваем основные усовершенствования сервера Exchange Server, которые делают проще процесс общения — и в коридорах зданий, и через многокилометровые пространства. Мы расскажем о новых усовершенствованных функциях, которые предлагаются в пакете обновления 1 (SP1) сервера Exchange Server 2007, объясним, почему резервная непрерывная репликация значительно улучшает планы аварийного восстановления, покажем, как можно расширить функциональные возможности платформы Exchange в операционной системе Windows Server 2008 и каким образом единая система обмена сообщениями помогает сделать ваше общение более надежным и разнообразным. А в качестве специального приза в печатной версии TechNet Magazine содержится последняя серия очень популярных плакатов, созданных нашими пишущими редакторами Астрид и Мартином МакКлин (Astrid McClean, Martin McClean). Возможно, вы уже знакомы с их знаменитым составным плакатом Active Directory Component, удостоенным многочисленных наград, или плакатом Windows Server 2008, который мы публиковали в своем журнале. В этом месяце они взялись за Exchange. Давайте начнем разговор! Джошуа Хоффман (Joshua Hoffman)

Мы бы хотели поблагодарить следующих технических специалистов корпорации Майкрософт: Эд Банти (Ed Banti), Ана Кэмерон (Anah Cameron), Чун Йонг Чуа (Chun Yong Chua), Клиф Дидкок (Cliff Didcock), Джереми Келли (Jeremy Kelly), Майкл Мерголо (Michael Murgolo), Йон Ортон (Jon Orton), Джеф Ресслер (Jeff Ressler), Кевин Салливан (Kevin Sullivan), Джим Труер (Jim Truher), Скот Видкан (Scot Vidican) и Майкл Вилсон (Michael Wilson).

Джошуа Хоффман (Joshua Hoffman)


 Письма: Мнения читателей
Письма
Мнения читателей

Программа PageDefrag
Я попытался запустить программу SysInternals PageDefrag, о которой говорилось в выпуске за сентябрь 2007 года. Но ее не удалось запустить под Windows Vista® x64. При этом выводится сообщение об ошибке: «Make sure that you are an administrator. Error loading PageDefrag driver.» («Убедитесь, что вы являетесь администратором. Ошибка при загрузке драйвера PageDefrag»).
— Алекс Д.

В настоящее время программа PageDefrag не поддерживает с Windows Vista. Она работает только с Windows NT® 4.0, Windows® 2000, Windows XP и Windows Server® 2003. Приносим извинения, что недостаточно ясно рассказали об этом в сентябрьской статье.

Планировщик резервного копирования
Я с большим интересом прочел статью «Руководство по технологиям резервного копирования Windows Vista» в сентябрьском номере, но у меня есть несколько вопросов. На рис. 2 в статье показана дата и время следующего копирования. Как это возможно, если в программе резервного копирования нет собственного планировщика?
Если изменения блоков на диске являются основой для определения того, что именно будет скопировано, что произойдет в случае дефрагментации диска? Приведет ли это к тому, что будет скопирован больший объем данных (поскольку блоки были перемещены и изменены)? Кроме того, если при восстановлении блоки возвращаются туда, где они изначально были, как на это влияет дефрагментация дисков?
— Брюс Дж.

Мы переслали эти вопросы автору (статью написала Кристина Фок), и вот что она ответила.
На рис. 2 показана дата и время следующего копирования файлов и папок, и только время самой последней архивации Complete PC. Можно запланировать архивацию на уровне файлов и папок, но, как вы заметили, средство архивации Complete PC Backup не содержит собственного планировщика.
Вы правы в том, что если между двумя архивациями Complete PC дефрагментировать диск, то второй образ Complete PC может быть больше. Вы также правильно поняли, как будет происходить восстановление после дефрагментации. Архивация Complete PC работает на уровне тома, ниже уровня файловой системы. При восстановлении каждый блок данных помещается в точности туда, откуда он был скопирован при архивации вне зависимости от того, был ли дефрагментирован диск после архивации. Поэтому имеет смысл еще раз дефрагментировать диск после восстановления.

Программа BGInfo
Меня заинтересовала колонка «Обзор служебных программ» в выпуске за август 2007 года. Программа SysInternals BGInfo, собирающая важные сведения о процессоре и сети, мне особенно понравилась. Было интересно прочесть про людей, которые сами разрабатывают новые продукты, программы и приложения. Разрабатывал ли г-н Когсвелл (Cogswell) другие программные продукты для Майкрософт?
— Дэрил Б.

Приятно слышать, что программа BGInfo оказалась полезной для вас. Брайс Когсвелл (Bryce Cogswell) разработал несколько полезных программ вместе с Марком Русиновичом (Mark Russinovich), который также работал в Sysinternals. К счастью, корпорация Майкрософт приобрела компанию Sysinternals в 2006 году, и теперь и Когсвелл, и Русинович работают в Майкрософт. Все созданные ими программы вы найдете на веб-узле Sysinternals по адресу microsoft.com/technet/sysinternals.

Удаленный вызов процедур и брандмауэры
Статья «Устранение ошибок удаленного вызова процедур» в номере за июль 2007 года была весьма полезной, но в ней упущен важный момент: брандмауэр Windows также может вызывать ошибки удаленного вызова процедур. Если брандмауэр Windows настроен так, что разрешены запросы PING, но запрещены незапрошенные входящие сообщений, то удаленное управление компьютером будет невозможно. Если запустить программу RPCPING.exe из пакета Windows Resource Kit, возвращается ошибка 1722 (сервер удаленного вызова процедур недоступен).
В этом случае брандмауэр делает именно то, что должен: запрещает доступ извне к данной системе. К сожалению, это вдобавок помешает администраторам управлять компьютерами в корпоративной сети.
— Аарон М.

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

Лицензии на использование Windows XP
В колонке «Заметки на полях» выпуска за октябрь 2007 года была упомянута возможность приобретения лицензий на Windows XP всего по 5 долларов. Наша организация — некоммерческое издательство. Хотелось бы узнать, как можно приобрести такие лицензии. Это как-то можно сделать по телефону или по почте? У меня есть электронная почта, но нет доступа в Интернет.
— Эрнст Б.

Вы можете обратиться к административному партнеру MAR, компании TechSoup, по адресу communitymar@techsoup.org или по телефону 800-659-3579 x350. Также можно воспользоваться обычной почтой — пишите по адресу: Community MAR Administrator, TechSoup Stock, 435 Brannan Street #100, San Francisco, CA 94107.


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

Наблюдение за сетями
Сетевой монитор ActiveXperts
activexperts.com
Системному администратору лучше узнавать о проблеме заранее, до того как пользователи начнут вскакивать из-за своих рабочих мест, подобно напуганным птицам. Наблюдение за службами является ключевым средством управления инфраструктурой с целью профилактического устранения проблем. Сетевой монитор компании ActiveXperts — надежное решение, позволяющее выполнять несколько видов проверок локальной и глобальной сети, а также серверов под управлением операционных систем Windows®, Novell и UNIX, выявляя проблемы до того, как о них сообщат пользователи.
Сетевой монитор ActiveXperts — это Windows-приложение, запущенное в виде службы на компьютере, предназначенном для наблюдения за сетью. Этот компьютер может работать под управлением операционных систем Windows 2000, Windows Server® 2003, Windows XP и Windows Vista®. После установки программы запускается мастер быстрой настройки, который позволяет настроить уведомления по электронной почте и через SMS-сервер, а также периодичность сканирования и пороговое значение сбоя. Также можно добавить набор типичных проверок и использовать их в качестве примеров в конкретной конфигурации. Это позволяет избавиться от блочного выполнения и показывает основы настройки различных возможностей приложения под потребности конкретной среды.
Приложение состоит из трех независимых компонентов: это ядро сетевого монитора (служба Windows, постоянно выполняющая задачи наблюдения); диспетчер сетевого монитора (приложение Windows, позволяющее отслеживать текущие действия монитора, просматривать результаты выполнения задач и вносить изменения в конфигурацию) и веб-интерфейс, предоставляющий доступ только для чтения к задачам и результатам выполнения задач.
Помимо выполнения задач наблюдения ядро сетевого монитора обрабатывает уведомления, действия, выполняемые в зависимости от результата, и ведет журнал приложения. Ядро сетевого монитора является многопоточным, что позволяет масштабировать его для потребностей конкретной среды. Для запуска задач наблюдения этой службе не требуется наличие агента конечной точки, но это означает, что для наблюдения за удаленными серверами и рабочими станциями Windows необходимо иметь права администратора. К счастью, можно указать несколько наборов учетных данных, поэтому для запуска программы наблюдения за компьютерами в различных доменах и контекстах безопасности не потребуется создавать единую учетную запись, обладающую всеми возможными правами.
По-видимому, большую часть времени пользователь будет затрачивать для диспетчера сетевого монитора, который предоставляет полный контроль над всеми возможностями, параметрами конфигурации и функциями. С помощью данного средства можно свести все задачи наблюдения в древовидную структуру, позволяющую быстрее находить отдельные элементы в крупных средах, а также фильтровать текущие данные в окне приложения для быстрого просмотра задач наблюдения.
Добавить новую задачу наблюдения очень просто. В сетевом мониторе имеется около 40 стандартных задач проверки, включая следующие: проверка IP и сетевых протоколов (например ICMP, LDAP, SMTP и HTTP), проверка Windows (ЦП, процессов, памяти и сервера терминалов), проверка возможности подключения ODBC, TnsPing компании Oracle, проверка баз данных OLEDB на основе запросов, проверка членства Novell и проверка RSH для операционных систем семейства UNIX. Кроме того, можно отслеживать параметры окружающей среды (например температуру, влажность и т.д.) сети с помощью монитора SensaTronics.
В данном приложении поддерживается создание сценариев для VBScript и удаленной оболочки, что позволяет создавать собственные задачи наблюдения. Совместно с приложением поставляется набор шаблонов на языке VBScript для наблюдения за различными службами, например антивирусными программами, Microsoft® ISA Server и службами запросов XML, поэтому задачи наблюдения не придется создавать с нуля.
Для каждой задачи можно указать периодичность запуска и пороговое значение сбоя, а также создать расписание задач, указав день и время их запуска, в тех случаях, когда это необходимо, в частности, для проверки результатов работы других процессов, например задачи архивирования журналов или сброса пула приложений служб IIS. Также можно указать исполняемый файл, сценарий или пакетное задание, которые будут запускаться в случае сбоя или восстановления проверки, а также перезагружать компьютер или перезапускать указанную службу. Наконец, веб-интерфейс предоставляет XSLT-преобразование для форматирования XML-данных результата. Для создания собственного представления данных для сетевого операционного центра или мобильного устройства можно создать собственные таблицы стилей; кроме того, поскольку данные хранятся в формате XML, их можно легко использовать в другом приложении или системе сбора данных.

Цена: от 395 долларов США за лицензию на пять серверов при прямых поставках.
ActiveXperts Network Monitor includes sample checks to get you started
ActiveXperts Network Monitor includes sample checks to get you started

Обзор книги
Windows Vista Resource Kit (Набор ресурсов для Windows Vista)
microsoft.com/mspress/books/9536.aspx
Поскольку все больше и больше организаций внедряют в свою инфраструктуру клиентские компьютеры с операционной системой Windows Vista, специалистам по информационным технологиям необходимо постоянно быть в курсе новых программ для данной операционной системы. В недавно опубликованной книге Windows Vista Resource Kit (Набор ресурсов для Windows Vista) (издательство Microsoft Press®, 2007 г.) речь идет о средствах, необходимых для успешного развертывания в организации клиентских компьютеров с операционной системой Windows Vista, — начиная с автоматической установки, активации томов, управления и обслуживания рабочего стола и заканчивая использованием сетей на базе протокола IPv6 и удаленного помощника. 1568 страниц книги дополнены DVD-диском с более чем 100 сценариями для администрирования и развертывания, средствами отладки, комплектом Solution Accelerator для Business Desktop Deployment (BDD) и другими полезными программами.
Книга начинается с обзора новых возможностей операционной системы Windows Vista, а особое внимание в ней уделено усовершенствованиям системы безопасности, в частности контролю учетных записей, технологиям шифрования диска BitLocker и предотвращения выполнения данных. Также рассматриваются концепции усиления защиты службы и защиты от исправлений ядра. Далее рассказывается о развертывании Windows и рассматривается большое количество средств, позволяющих автоматизировать этот процесс. Например, в книге рассматриваются вопросы настройки среды предустановки и восстановления Windows PE 2.0, подробно описывается программа BDD 2007, которая упрощает планирование и развертывание в организации системы Windows Vista. Кроме того, здесь приводятся рекомендации по созданию и настройке образов дисков, а также подробно обсуждаются вопросы переноса данных пользователей с помощью средства переноса данных Windows и средства миграции пользовательской среды.
Далее подробно рассказывается об управлении рабочим столом с помощью групповых политик и о новых файлах административных шаблонов в формате XML (файлах ADMX). Также рассматриваются вопросы управления дисками и файловыми системами и новые технологии системы Windows Vista ReadyBoost и BitLocker. В книге объясняются механизмы работы предыдущих версий, теневого копирования и дисковых квот, затем автор переходит к вопросам развертывания и управления конференц-залом Windows в рабочих группах, доменах и беспроводных средах прямого подключения.
Раздел «Управление рабочим столом» посвящен задачам, отчетам об ошибках Windows, наблюдению за производительностью и событиям Windows. В данном разделе также рассказывается о возможности использования удаленного помощника службой технической поддержки. Далее в книге рассматриваются обновления программного обеспечения, фоновая интеллектуальная служба передачи (BITS), центр обновления Windows, а также средства аудита.
Раздел «Сеть» посвящен брандмауэру Windows, в нем также описываются усовершенствования сетевого стека. Кроме того, в этом разделе рассказывается об использовании удаленного рабочего стола и VPN-подключений для настройки удаленных пользователей и сетей.
В конце книги предоставляется обширная информация об устранении различных неполадок, начиная с проблем с загрузкой и сетью и заканчивая ошибками драйверов и проблемами с оборудованием. Иногда в книге встречаются чисто маркетинговые материалы, но это ни в коем случае не полторы тысячи страниц «воды». Эта книга дает глубокое, всестороннее представление о системе Windows Vista, ее средствах и управлении операционной системой.

Цена: 59,99 долларов США при прямых поставках.

Анализ HTTP-трафика
Средство Charles Web Debugging Proxy
xk72.com/charles
При широком использовании протокола HTTP для взаимодействия между приложениями, рабочими станциями, серверами и Интернетом хорошее средство анализа HTTP-трафика исключительно полезно для системного администратора. С помощью подобного средства можно выявлять проблемы с прокси-серверами, системой безопасности, подключениями, конфигурацией, а также проблемы взаимодействия приложений. Мне очень нравится Java-приложение Карла фон Рэндоу (Karl von Randow) Charles Web Debugging Proxy (прокси-сервер для веб-отладки).
Как и другие отладочные прокси-серверы, эта программа устанавливается как посредник между конечными приложениями, перехватывая и анализируя трафик. Благодаря подобной конфигурации приложение также позволяет просматривать зашифрованный HTTPS-трафик в виде обычного незашифрованного текста. Графический интерфейс приложения дает удобное представление записанного сеанса, предоставляя все необходимые сведения, начиная с основных запросов страниц, изображений, сценариев и таблиц стилей и заканчивая мельчайшими подробностями о размере, задержках и времени выполнения. Также доступны данные об отправленных и принятых в каждом запросе файлах cookie и их содержимом; можно даже заблокировать все файлы cookie.
С помощью программы Charles Web Debugging Proxy можно устранить проблемы с кэшированием запросов, проверив даты последнего изменения откликов HTTP «304 Не изменено» либо отключив кэширование путем удаления связанных с кэшированием заголовков из соответствующих запросов и откликов, проходящих через приложение. Фактически, используя параметры перезаписи приложения, можно создать набор правил для перезаписи определенных заголовков или тела HTTP при прохождении запросов и откликов через приложение. С помощью приложения можно даже использовать подмену DNS для переопределения IP-адреса узла, что позволяет тестировать запросы к элементам, которые могут быть не зарегистрированы в системе DNS. Это удобно для тестирования, например, нового веб-сервера и позволяет убедиться в том, что этот сервер правильно реагирует на заголовок узла, перед тем как его выпустить.
Данное средство также можно использовать для отладки запросов и откликов AJAX и просмотра необработанных XML-данных в отклике. С помощью графического интерфейса можно просматривать исходные данные запроса и отклика в текстовом виде, чтобы отслеживать подозрительные заголовки.
В этом средстве данные можно представить двумя способами, каждый из которых позволяет лучше понять процесс передачи данных: таблица «Summary» (Сводка) и таблица «Chart» (Диаграмма). С помощью таблицы «Summary» можно быстро просканировать данные запроса и отклика и получить размер заголовка, размер тела запроса и отклика, время отклика, код отклика, тип MIME и ресурс. В таблице «Chart», с другой стороны, приведена в графическом виде временная шкала жизненного цикла, на которой последовательно показано время создания данных запроса или отклика и время выполнения транзакции.
Данные о сеансе можно сохранить для дальнейшего воспроизведения и анализа. Это полезно при перехвате сложного потока запросов и откликов, который приводит к случайным ошибкам связи; после записи такой поток можно воспроизвести. Можно даже импортировать файлы трассировки HTTP в новый сеанс, а также экспортировать текущий сеанс в CSV-файл или формат трассировки HTTP.
Для моделирования запросов в низкоскоростных каналах — например, для того чтобы выяснить, почему запрос не работает при модемном подключении на скорости 56 килобит, но работает в корпоративной сети, — в приложении имеется функция регулировки полосы пропускания, с помощью которой можно выбрать один из предустановленных вариантов полосы пропускания или создать свой собственный вариант на основе четырех опорных точек: полоса пропускания, процент загрузки, задержка приема-передачи и MTU. Отладочный прокси-сервер также можно настроить в качестве обратного прокси или ретранслятора портов, что позволяет выполнить привязку локального порта к удаленной конечной точке (и порту) и перенаправлять весь трафик, отправляемый на этот порт, на удаленный адрес.

Цена: от 50 долларов США при прямых поставках за лицензию для одного пользователя.
Charles Web Debugging Proxy analyzes HTTP traffic
Charles Web Debugging Proxy analyzes HTTP traffic

Очистка ненужных файлов
Программа Wise Disk Cleaner 2
wisecleaner.com
Жесткий диск в чем-то похож на дом — со временем там скапливаются совершенно ненужные вещи. Иногда следует потратить немного времени на генеральную уборку. В операционную систему Windows встроено несколько стандартных средств очистки жесткого диска, например средство «Очистка диска» и функция поиска. Но в некоторых случаях лучше воспользоваться быстрой и простой программой — особенно если она бесплатна. Одна из таких программ — Wise Disk Cleaner 2, которая ищет на жестких дисках ненужные файлы, занимающие лишнее место, которые можно безопасно удалить.
В этой программе мне нравится то, что она представляет все найденные файлы непосредственно перед пользователем, позволяя выявить любые потенциальные проблемы. Другая удобная функция — возможность добавления дополнительных шаблонов файлов для поиска и удаления. Программа Wise Disk Cleaner также позволяет по желанию пользователя очистить временные файлы Интернета и оставить файлы cookie, если необходимо сохранить настройки веб-узлов. Также можно удалить файлы удаления обновлений Windows, а также очистить источник обновлений Windows, список последних файлов и временные папки Windows и пользователя. Можно даже настроить автоматический запуск приложения, указав ему удалять файлы окончательно или помещать их в корзину. Приложение записывает свои действия в журнал, что позволяет в дальнейшем их просмотреть — неплохо для бесплатной программы.

Цена: бесплатно.
Wise Disk Cleaner 2 finds files that you can safely delete
Wise Disk Cleaner 2 finds files that you can safely delete

Управление сетевыми устройствами
Программа iReasoning Networks MIB Browser Personal Edition
ireasoning.com/mibbrowser.shtml
Если в инфраструктуре используются сетевые устройства, приложения или компьютеры с поддержкой протокола SNMP (Simple Network Management Protocol), то с помощью программы iReasoning Networks MIB Browser можно загрузить набор MIB-файлов и построить иерархическую структуру, во многом подобную структуре папок проводника Windows. В этой структуре можно просмотреть сведения о выбранном объекте, включая идентификатор объекта, синтаксис, доступ на чтение или запись и описание.
С помощью пользовательского интерфейса можно легко создать SNMP-запрос на получение данных от сетевого устройства. Просто введите IP-адрес устройства, выберите объект MIB и нажмите кнопку «Go» (Запуск). Если необходимо, также можно указать порт, версию SNMP-запроса, а также считывать и записывать строки сообщества. Вносить изменения в агент тоже очень просто (если устройство поддерживает такую возможность). Достаточно выбрать идентификатор объекта, тип данных и значение и нажать кнопку «OK». Кроме того, в приложение встроены служебные программы Trap Sender и Trap Receiver, с помощью которых можно создавать ловушки и отслеживать их активность (к ловушкам можно применять фильтры, что позволяет лучше изучить исследуемое устройство).
Программа iReasoning Networks MIB Browser Personal Edition бесплатна, но в ней не поддерживается третья версия протокола SNMP и можно одновременно загружать не более пяти MIB-файлов. Рассмотрите возможность приобретения версии Professional Edition данной программы (от 269 долларов США за лицензию при прямых поставках), которая обладает дополнительными функциями, поддерживает протокол SNMP версии 3, обнаружение сети и сравнение устройств.

Цена: бесплатно.
iReasoning Networks MIB Browser
iReasoning Networks MIB Browser

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


 Вопросы и ответы по SQL: Настройка памяти, профилирование производительности, выбор коэффициента заполнения и многое другое
Вопросы и ответы по SQL
Настройка памяти, профилирование производительности, выбор коэффициента заполнения и многое другое
Под редакцией Нэнси Мичел (Nancy Michell)

Настройка памяти
Совет. Упрощенное профилирование
Знаете ли вы, что теперь можно использовать системный монитор совместно с профайлером SQL Server 2005?
Возможно, вам приходилось замечать в системном мониторе пиковую загрузку ЦП, избыточное потребление памяти или общее падение производительности на компьютере с SQL Server, и вы не понимали причин подобных аномалий производительности. В версиях SQL Server до SQL Server 2005 необходимо было с помощью профайлера выполнить трассировку, затем изучить системные процессы в программе Enterprise Manager, и, наконец, записать данные в журналы системного монитора, для чего, естественно, требовалось запустить системный монитор. И даже после всей проделанной с помощью указанных выше средств работы необходимо было вручную сопоставить события, записанные разными программами, чтобы выяснить причины падения производительности. А это, в свою очередь, требовало кропотливой работы по просмотру всех строк в каждом журнале. Вряд ли этом можно назвать увлекательным занятием, но без него было невозможно выяснить суть проблем с производительностью.
В SQL Server 2005 по-прежнему необходимо проводить трассировку и изучать журналы системного монитора, но теперь их можно подключить к профайлеру. Теперь при просмотре инструкций T-SQL профайлер будет автоматически в графическом виде показывать, что произошло. Если щелкнуть в поле профайлера в окне системного монитора, будет выведена инструкция, соответствующая указанной отметке времени. Это позволяет сэкономить много времени при устранении неполадок в среде SQL Server.
Рассмотрим, как подключить журналы системного монитора к профайлеру.
  1. Запустите системный монитор и начните сбор данных с сервера баз данных.
  2. Создайте в группе «Журналы и оповещения производительности» новый журнал счетчиков и введите имя журнала.
  3. Добавьте новые счетчики, например «% загруженности процессора». На вкладке «Расписание» можно настроить ведение журнала для запуска вручную или по расписанию.
  4. Нажмите кнопку «ОК» и, если был выбран запуск вручную, убедитесь в том, что ведение журнала включено.
  5. Настройте трассировку в профайлере SQL Server. Это можно сделать с помощью команды «Создать трассировку» меню «Файл». Включите в трассировку время начала и время окончания, присвойте ей имя и настройте трассировку таким образом, чтобы результаты сохранялись в файл. Наконец, смоделируйте на сервере какие-либо транзакции, после чего остановите сбор данных в системном мониторе и профайлере.
  6. Выберите в меню «Файл» профайлера команду «Импорт данных производительности». Затем выберите папку, в которую был сохранен файл журнала системного монитора, с помощью пунктов «Открыть» и «Трассировка» меню «Файл». Наконец, выберите папку, в которую был сохранен файл трассировки профайлера.
Выполнив эти действия, вы убедитесь в том, насколько проще стало оценивать влияние отдельных инструкций SQL на время обработки.

В. Я пытаюсь определить наилучшую конфигурацию памяти для серверов SQL Server™. Администратор, работавший до меня, настроил файл Boot.ini для каждого компьютера с 12 ГБ ОЗУ в кластере SQL Server 2000 с двумя узлами следующим образом: Yes /PAE NO /3GB (для SQL Server не включены расширения AWE). Так как доступно 12 ГБ ОЗУ, следует ли мне удалить из файла Boot.ini параметр /3GB, включить расширения AWE и предоставить серверу SQL Server примерно 10 ГБ ОЗУ из 12? На компьютерах запущен только SQL Server, поэтому не нужно выделять память для других приложений.
О. Да, расширения AWE следует включить и установить верхнюю границу ОЗУ для SQL Server на уровне 10 ГБ — это нормально при наличии выделенного под SQL Server компьютера с 12 ГБ ОЗУ. (Имейте в виду, что предварительное выделение памяти возможно только для SQL Server 2000. В версиях начиная с SQL Server 2005 расширения AWE перестали быть статическими и могут изменяться динамически). Вопрос о том, следует ли использовать оба параметра /3GB и /PAE или только параметр /PAE, всегда был предметом ожесточенных споров. Хотя в действительности необходимо использовать только параметр /PAE и включить расширения AWE, я рекомендую использовать оба параметра; однако необходимо учитывать ряд факторов.
Вопрос об использовании параметра /3GB сводится к тому, необходим ли он в конкретной ситуации. Выходите ли вы за пределы областей памяти MemToLeave, которые должны быть расположены в первых двух или трех гигабайтах виртуального адресного пространства? Хватает ли операционной системе памяти после включения данного параметра? (Дополнительные сведения см. в статье по адресу support.microsoft.com/kb/316739 (на английском языке)). При использовании кластера можно включить параметр /3GB на одном узле и отключить на другом. Таким образом, в случае возникновения проблем при тестировании параметра /3GB можно достаточно быстро переключиться на другой узел. Следует иметь в виду, что при наличии более 16 ГБ ОЗУ параметр /3GB не поддерживается.
При использовании параметра /3GB виртуальное адресное пространство увеличивается на 50%, что позволяет повысить производительность приложений, интенсивно использующих виртуальное адресное пространство, а не только кэш данных. К счастью, в 64-разрядных серверах, построенных как на основе архитектуры IA64, так и x64, этот фактор устранен. Что касается нехватки памяти для ОС, этот вопрос не имеет отношения к компьютерам, специально отведенным для работы SQL Server. 2 ГБ ОЗУ для ОС более чем достаточно; если сервер предназначен только для работы SQL Server и на нем запущен минимальный набор стандартных служб ОС, на компьютере будет свободно примерно 1,3 ГБ памяти, поэтому можно позволить серверу SQL Server использовать дополнительный гигабайт ОЗУ. Начните с 10 ГБ, отслеживайте с помощью системного монитора объем доступной памяти в течение длительного промежутка времени, после чего внесите соответствующие изменения. Помните, что недостаточное выделение памяти для SQL Server 2000 приведет к использованию файла подкачки, поскольку расширения AWE нельзя изменять динамически, как это делается в SQL Server 2005. Вопрос о необходимости использования параметра /3GB решается в результате тестирования в конкретной среде.

Имена экземпляров для репликации
В. Можно ли теперь использовать IP-адрес сервера в процессе репликации SQL Server 2005, чтобы указать экземпляр для репликации? В SQL Server 2000, как показано в статье «Репликация между компьютерами с SQL Server, расположенными в доменах, не являющихся доверенными, или через Интернет» (support.microsoft.com/kb/321822, на английском языке), такие действия привели бы к ошибкам, но мне неизвестно, исправлено ли это в новой версии.
О. При указании экземпляров сервера, участвующих в репликации, необходимо указать зарегистрированное имя экземпляра SQL Server. Например, имя экземпляра SQL Server необходимо использовать при указании параметров Publisher и Subscriber хранимых процедур репликации, а также при указании параметров подключения агента репликации в командной строке. Если сетевое имя для экземпляра SQL Server отличается от зарегистрированного имени экземпляра, агенты не смогут подключаться для выполнения репликации.
Если сетевое имя экземпляра отличается от имени экземпляра SQL, добавьте имя экземпляра SQL Server в качестве допустимого сетевого имени. Один из способов задать альтернативное сетевое имя — добавить его в локальный файл hosts. Файл hosts по умолчанию находится в папке WINDOWS\system32\drivers\etc или WINNT\system32\drivers\etc. Например, если имя компьютера — comp1, IP-адрес компьютера — 10.193.17.129, а имя экземпляра — inst1/instname, добавьте в файл hosts следующую запись:
10.193.17.129 inst1

Службы интеграции SQL Server
В. Я устанавливаю кластер в режиме «активный/активный» для SQL Server 2005 (64-разрядная версия Enterprise Edition с двумя серверами), а всего имеется четыре экземпляра сервера SQL Server 2005. Службы интеграции SQL Server (SSIS) потребуются для всех экземпляров. Возможна ли кластеризация служб интеграции SQL Server и каково влияние кластеризации на планы обслуживания?
О. Кластеризация служб интеграции SQL Server возможна, однако это не является необходимым и может привести к различным проблемам, включая ограничение поддержки делегирования (см. статью по адресу msdn2.microsoft.com/aa337083) и отсутствие возможности одновременного запуска на одном узле нескольких экземпляров службы.
Ранее для работы мастера планов обслуживания было необходимо установить службы интеграции SQL Server (хотя их запуск был необязательным). Однако это не относится к SQL Server 2005 с пакетом обновления 1 (SP1). Если службы интеграции SQL Server не запущены, планы обслуживания могут выполняться агентом SQL Server.
Вместо кластеризации служб интеграции SQL Server можно по-прежнему запускать их в виде автономной службы и изменить файл MsDtsSrvr.ini.xml таким образом, чтобы он указывал на все без исключения запущенные экземпляры. Это позволит управлять пакетами с любого узла, обеспечить высокий уровень доступности, необходимый большинству клиентов, и избежать проблем, связанных с кластеризацией службы.
Дополнительные сведения о сбоях при создании плана обслуживания см. в статье базы знаний Майкрософт по адресу support.microsoft.com/kb/909036 (на английском языке).

Странное время выполнения
В. В процессе тестирования под нагрузкой компьютера, отведенного для SQL Server 2005 с пакетом обновления 1 (SP1), в профайлере SQL Server было записано множество отрицательных значений для времени выполнения хранимой процедуры, а в некоторых случаях время выполнения хранимой процедуры не соответствовало разнице между временем окончания и временем начала выполнения процедуры.
О. На результат, регистрируемый профайлером SQL Server для времени выполнения хранимых процедур и иных временных показателей производительности, влияет множество факторов. Помните, что SQL Server 2005 рассчитывает время выполнения в миллисекундах, поэтому при использовании технологий, изменяющих единицу измерения, время выполнения, зафиксированное в отчете, и реальное время выполнения не будут совпадать.
Например, при использовании других схем управления питанием, внутренних версий процессора или технологии «Cool 'n Quiet» компании AMD тактовая частота ЦП изменяется и перестает соответствовать значению, используемому профайлером SQL Server при расчете времени выполнения.
В статье базы знаний Майкрософт по адресу support.microsoft.com/kb/931279 (на английском языке) приведены симптомы, возможные причины и способы устранения проблемы.
Совет. Проверьте коэффициент заполнения
Предположим, что у вас есть стакан, полностью заполненный водой, и вы пытаетесь долить в стакан еще воды. Что произойдет? Вода выплеснется.
То же самое может произойти и с SQL Server. Каждый раз при добавлении новой строки на страницу с полностью заполненным индексом SQL Server перемещает приблизительно половину строк на новую страницу, чтобы освободить место для новой строки. Этот процесс называется разбиением страницы. При разбиении страниц высвобождается пространство для новых записей, но этот процесс занимает много времени и потребляет много ресурсов. Разбиения страниц могут привести к фрагментации, что отрицательно скажется на производительности операций ввода-вывода. Так как же избежать разбиений?
Чтобы предотвратить появление подобных ситуаций, необходимо заблаговременно определить значение коэффициента заполнения. При создании или перестроении индекса значение коэффициента заполнения определяет процент заполнения данными каждой страницы конечного уровня; остальное место резервируется для последующего роста базы данных. Например, коэффициент заполнения, равный 60, означает, что 40% каждой страницы конечного уровня останутся пустыми. Пустое пространство будет использоваться для расширения индекса по мере добавления данных в соответствующую таблицу.
Коэффициент заполнения по умолчанию всегда равен 0, что нормально для большинства ситуаций. По существу, коэффициент заполнения 0, означает, что страницы конечного уровня заполнены почти полностью, но при этом имеется место по крайней мере для одной дополнительной строки индекса. (Обратите внимание на то, что значения коэффициента заполнения 0 и 100 эквивалентны).
Значение коэффициента заполнения для отдельных индексов можно задать с помощью инструкций CREATE INDEX и ALTER INDEX, либо настроить это значение непосредственно на уровне сервера таким образом, чтобы оно устанавливалось по умолчанию для всех вновь создаваемых индексов.
В приведенном ниже примере коэффициенту заполнения присваивается на уровне сервера значение 70%, означающее, что для будущего расширения индексов будет зарезервировано 30% свободного места. Конечно, этот параметр необходимо тщательно протестировать перед его внедрением в производственной среде.
USE Master; GO SP_Configure 'show advanced options',1; GO SP_Configure 'Fill Factor', 70; GO — чтобы изменения вступили в силу, необходимо перезапустить SQL Server.
Что делать, если необходимо настроить коэффициент заполнения на уровне отдельных индексов? Предположим, что создается таблица, для которой необходимо создать уникальный индекс для столбца Col_A с коэффициентом заполнения 70. Команда будет выглядеть следующим образом:
USE Item_DB; GO CREATE TABLE ITEM (Col_A Varchar(100),Col_b Varchar(200)); GO; — создание таблицы Item

CREATE UNIQUE INDEX AK_Index ON Item (Col_A) WITH (FillFactor = 70); GO — создание уникального индекса для столбца Col_A таблицы Item с коэффициентом заполнения 70
Как определить значение коэффициента заполнения для каждого индекса? Чтобы получить значения коэффициентов заполнения для всех индексов в базе данных, необходимо выполнить запрос к таблице sys.Indexes, например, таким образом:
USE Item_DB; GO SELECT Fill_Factor FROM Sys.Indexes WHERE Object_id=object_id('item') AND name IS NOT NULL; GO


 Обзор служебных программ: Средство для оценки системы безопасности Microsoft Security Assessment Tool
Обзор служебных программ
Средство для оценки системы безопасности Microsoft Security Assessment Tool
Лэнс Уитни (Lance Whitney)
Загрузить исходный код для этой статьи: Microsoft Security Assessment Tool 3.0 (только на английском языке) (10547.2KB)

Отслеживание проблем безопасности сети — достаточно сложный процесс, требующий много времени. Одним из средств, позволяющих выявить и устранить угрозы безопасности, является средство оценки системы безопасности Microsoft® Security Assessment Tool (MSAT) — бесплатная служебная программа с электронной анкетой, которая позволяет описать сетевую среду. Предназначенное для организаций среднего размера (от 50 до 500 компьютеров), средство MSAT содержит 172 вопроса в нескольких категориях. После обработки ответов программа выдает результаты анализа конкретной ситуации и рекомендации по ее улучшению.
Первая группа вопросов касается бизнес-модели и используется для создания профиля угроз для бизнеса (Business Risk Profile, BRP), с помощью которого оценивается угроза для системы безопасности по сравнению с другими организациями в отрасли. Заполнение анкеты обычно занимает около двух часов, но в любой момент можно остановиться и впоследствии продолжить отвечать на вопросы с того же места. Ниже перечислены категории и приведены примеры вопросов.
Общие сведения Сколько в организации клиентских компьютеров и серверов?
Безопасность инфраструктуры Есть ли в организации сотрудники, работающие удаленно? Имеют ли доступ к сети организации внешние подрядчики?
Безопасность приложений Занимается ли компания разработкой приложений? Хранятся ли в организации конфиденциальные данные, обрабатываемые приложениями, разработанными самой компанией?
Безопасность операций Подключена ли корпоративная сеть к внешним сетям? Получает ли организация данные от внешних организаций?
Безопасность сотрудников Пользуется ли компания услугами сторонних организаций по обслуживанию компьютеров? Разрешено ли сотрудникам загружать конфиденциальные данные компании на свои рабочие станции?
Среда Сколько сотрудников в организации? Высока ли текучесть кадров в отделе информационных технологий?
После обработки анкеты программа MSAT выдает оценку по индексу глубокой защиты Defense-in-Depth Index (DiDI), который предназначен для оценки используемых процессов безопасности. Ниже приведены типичные вопросы для указанных выше категорий. Установлены ли брандмауэры на каждом компьютере организации? Используются ли в приложениях Microsoft Office пользовательские макросы? Обладают ли пользователи правами администратора на своих рабочих станциях? Существует ли в организации политика развертывания на ПК исправлений и обновлений?
После обработки ответов программа MSAT создает три отчета. Сводный отчет содержит гистограмму результатов. Высокая оценка в профиле BRP указывает на большую степень риска, в то время как высокая оценка по индексу DiDI указывает на более высокий уровень безопасности. Из показаний MSAT видно, что желательно получить низкую оценку в профиле угроз для бизнеса и высокую оценку по индексу глубокой защиты, однако более важно изучить отдельные области. Таким образом, для каждой области, полный отчет показывает, соответствует ли организация рекомендациям, нуждается ли она в улучшении или подвержена серьезному риску (см. рис. 1).
Figure 1 The complete report
Figure 1 The complete report
Наконец, сравнительный отчет предлагает анонимно загрузить результаты анализа на безопасный веб-узел MSAT, на котором можно будет сравнить результаты для своей организации с результатами для других организаций.
Данное средство можно загрузить в Центре безопасности Microsoft TechNet по адресу securityguidance.com или с веб-узла журнала TechNet Magazine по адресу technetmagazine.com/code07.aspx.

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


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

Служба сервера политики сети (NPS) в операционной системе Windows Server 2008 замещает службу проверки подлинности в Интернете (IAS) в Windows Server 2003. С помощью службы сервера политики сети компьютер с операционной системой Windows Server 2008 может работать в качестве сервера RADIUS (Remote Authentication Dial-In User Service) и RADIUS-прокси. Протокол RADIUS является одним из стандартов рабочей группы проектирования Интернета
(IETF), описанным в документах RFC 2865 и 2866, и обеспечивает централизованную проверку подлинности, авторизацию и аудит для сетевых устройств, таких как беспроводные точки доступа. Серверы RADIUS выполняют проверку подлинности, авторизацию и аудит сетевых устройств. RADIUS-прокси пересылают сообщения RADIUS между клиентами RADIUS (сетевыми устройствами) и серверами RADIUS.
Служба сервера политики сети упрощает развертывание доступа к сети с проверкой подлинности, обеспечивает возможности расширения для компонентов сторонних производителей и поддерживает самые современные сетевые технологии и платформы. Новая оснастка службы NPS показана на рис. 1.
Figure 1 The new NPS snap-in
Figure 1 The new NPS snap-in

Возможности сервера политики сети
В данной статье речь пойдет о функциях сервера политики сети, отсутствовавших в предыдущих версиях Windows®. Начнем с того, каким образом защита доступа к сети (NAP) позволяет принудительно применить требования к работоспособности системы для сети, затем коснемся вопросов управления, настройки, поддержки протокола IPv6 и иных вопросов. Также будут описаны возможности новой оснастки службы NPS.
Защита доступа к сети Защита доступа к сети, появившаяся в операционной системе Windows Server® 2008, представляет собой набор технологий, которые позволяют принудительно привести систему в соответствие с требованиями к работоспособности компьютера и таким образом лучше защитить интрасеть. В политиках работоспособности можно потребовать, например, чтобы на всех клиентских компьютерах, подключенных к сети, был установлен и включен брандмауэр, а также установлены все последние обновления для операционной системы. С помощью защиты доступа к сети можно создавать пользовательские политики, которые будут проверять работоспособность компьютера перед тем, как предоставить ему доступ к сети, автоматически обновлять компьютеры в соответствии с текущими требованиями и ограничивать доступ к сети компьютеров, не соответствующих требованиям, пока эти требования не будут выполнены. Дополнительные сведения см. по адресу microsoft.com/nap.
При развертывании защиты доступа к сети сервер политики работает в качестве сервера политик работоспособности NAP и проверяет работоспособность клиентов от имени точек NAP — например центров регистрации работоспособности (HRA), точек доступа 802.1X, VPN-серверов и DHCP-серверов. Сервер политики сети также определяет, какой доступ к интрасети следует предоставить клиентам: полный или ограниченный. Сервер политики сети оценивает работоспособность на основе политик сети, политик работоспособности и параметров защиты доступа к сети.
Поддержка политик EAPHost и EAP Сервер политики сети поддерживает EAPHost, новую архитектуру для методов проверки подлинности протокола EAP (Extensible Authentication Protocol). Данная архитектура позволяет поставщикам методов протокола EAP с легкостью разрабатывать и устанавливать новые методы EAP для проверки подлинности на основе протоколов 802.1X и PPP (point-to-point protocol) как на клиентских компьютерах, так и на серверах политики сети.
Архитектура EAPHost будет поддерживать установку и использование всех методов EAP, указанных в реестре EAP по адресу www.iana.org/assignments/eap-numbers, а также другие распространенные методы проверки подлинности, такие как LEAP (Lightweight EAP) компании Cisco Systems. EAPHost поддерживает одновременное совместное использование нескольких реализаций одного и того же метода EAP. Например, можно установить и выбрать версии Protected EAP (PEAP) корпорации Майкрософт и компании Cisco Systems.
Для поставщиков методов EAP архитектурой EAPHost поддерживаются методы EAP, разработанные ранее для операционных систем Windows XP и Windows Server 2003, а также упрощенный способ разработки новых методов EAP для операционных систем Windows Vista® и Windows Server 2008. После установки можно настроить необходимые методы EAP для заданного в политике сети сценария доступа к сети. Политика сети для сервера политики сети аналогична политике удаленного доступа для службы проверки подлинности в Интернете.
Дополнительные сведения об архитектуре EAPHost см. в статье по адресу technetmagazine.com/issues/2007/05/CableGuy.
Хранение конфигурации в формате XML Служба проверки подлинности в Интернете хранила сведения о конфигурации в базе данных Jet. Сервер политики сети хранит сведения о конфигурации в формате XML, что упрощает экспорт конфигурации одного сервера политики сети на другой. Экспорт и импорт файлов конфигурации — это один из способов синхронизации параметров нескольких серверов политики сети в отказоустойчивой конфигурации. Экспортировать конфигурацию сервера политики сети можно с помощью команды netsh nps export, а импортировать конфигурацию — с помощью команды netsh nps import.
Соответствие общим критериям Сервер политики сети теперь поддерживает развертывание в средах, которые должны соответствовать общим инженерным критериям (CEC) корпорации Майкрософт® . Дополнительные сведения см. в статье по адресу microsoft.com/windowsserversystem/cer/allcriteria.mspx.
Надежные DLL-библиотеки, расширяющие возможности сервера политики сети Возможности службы NPS можно расширить с помощью DLL-библиотек с дополнительными функциями и методами проверки подлинности. В отличие от службы проверки подлинности в Интернете компоненты сторонних производителей изолированы в «песочнице» службы NPS, поэтому в случае возникновения проблем с данными компонентами это никак не отразится на работоспособности службы NPS.
Поддержка протокола IPv6 Сервер политики сети поддерживает протокол IPv6 и развертывание в исходных или туннелированных средах IPv6. Для клиентов и удаленных серверов RADIUS можно настроить адреса IPv6, а служба NPS может взаимодействовать по протоколу IPv6 для выполнения проверки подлинности и авторизации учетных записей доменных служб Active Directory® .
Сравнение службы проверки подлинности в Интернете со службой NPS
Тот, кто знаком с оснасткой службы проверки подлинности в Интернете для операционной системы Windows Server 2003, оценит перечисленные ниже изменения в оснастке службы NPS.
  • Политики удаленного доступа теперь называются политиками сети и перемещены в узел «Политики».
  • Узел «Клиенты RADIUS» перемещен в узел «Клиенты и серверы RADIUS».
  • Узла «Обработка запроса на подключение» больше не существует. Узел «Политики запросов на подключение» перемещен в узел «Политики», а узел «Группы удаленных серверов RADIUS» перемещен в узел «Клиенты и серверы RADIUS».
  • Условия и параметры профиля политики доступа разнесены по вкладкам «Обзор», «Условия», «Ограничения» и «Параметры» окна свойств политики сети.
  • Условия и параметры профиля политики запроса на подключение разнесены по вкладкам «Обзор», «Условия» и «Параметры» окна свойств политики запросов на подключение.
  • Папка Remote Access Logging (ведение журнала удаленного доступа) переименована в узел «Аудит» и более не содержит узлов «Локальный файл» и «SQL Server»TM .

Автоматическое создание надежных общих секретов RADIUS Общие секреты RADIUS используются для проверки того, что сообщения RADIUS были отправлены клиентом, сервером или RADIUS-прокси, настроенным на использование этого же общего секрета. Общие секреты также используются для шифрования некоторых секретных атрибутов RADIUS, таких как пароли и ключи шифрования. Надежные общие секреты RADIUS представляют собой длинную (более 22 знаков) случайную последовательность букв, цифр и знаков препинания.
С помощью оснастки службы NPS можно автоматически создавать надежный общий секрет RADIUS при добавлении или изменении клиента RADIUS. Созданный таким образом надежный общий секрет можно затем скопировать в текстовый редактор, например Блокнот, что позволяет настроить сетевое устройство или точку NAP на использование того же самого общего секрета.
Интеграция с диспетчером сервера Службу NPS можно установить с помощью задач начальной настройки и средств диспетчера сервера. В обоих случаях служба NPS устанавливается совместно с ролью «Политика сети и службы доступа». Чтобы начать установку, выберите в средстве «Задачи начальной настройки» в разделе «Настроить этот сервер» параметр «Добавить роли». В диспетчере сервера откройте раздел «Сводка по ролям» и нажмите кнопку «Добавить роли».
После установки службы NPS в дереве консоли диспетчера сервера можно раскрыть узел «Политика сети и службы доступа» узла «Роли» и проверить состояние службы NPS, а также получить список ошибок, произошедших за последние 24 часа. С помощью узла консоли «Политика сети и службы доступа» можно настроить службу NPS и соответствующую оснастку.
Улучшенная поддержка команды Netsh В операционной системе Windows Server 2003 был ограниченный набор команд для настройки службы проверки подлинности в Интернете в контексте netsh aaaa. В операционной системе Windows Server 2008 появился новый контекст netsh nps с расширенным набором команд для настройки сервера политики сети в командной строке или с помощью сценария. Теперь с помощью команд netsh nps можно настраивать клиенты и удаленные серверы RADIUS, политики сети, ведение журнала, а для защиты доступа к сети — политики работоспособности, средства проверки работоспособности системы и группы серверов обновлений. Использование сценариев, состоящих из команд контекста netsh nps, является другим способом синхронизации параметров нескольких серверов политики сети в отказоустойчивой конфигурации.
Исходные теги для изоляции политик сети Политики сети можно настроить на использование конкретного сервера для доступа к сети или точки NAP, например DHCP-сервера или центра регистрации работоспособности, который станет исходным тегом классификации политики сети. Серверы доступа и точки NAP с операционной системой Windows Server 2008 включают этот исходный тег в сообщения RADIUS. При получении сообщения RADIUS с запросом доступа служба NPS пытается найти соответствующую политику сети с таким же исходным тегом, что и у входящего сообщения. Если соответствующую политику найти не удается, служба NPS пытается найти соответствующую политику сети среди тех политик, для которых не указан исходный тег.
Использование исходного тега в политике сети и входящих сообщениях RADIUS позволяет изолировать различные типы политик сети друг от друга. Например, политики сети для DHCP-серверов не используются для VPN-подключений.
Интеграция с функцией контроля доступа к сети компании Cisco С помощью службы NPS можно интегрироваться со средами, в которых используется оборудование Cisco с функцией контроля доступа к сети (NAC). Возможности интеграции включают поддержку протокола HCAP (Host Credential Authorization Protocol) и условий HCAP, условия срока действия политики, и параметр расширенного состояния защиты доступа к сети в политиках сети.
Новые условия политик сети В политиках сети службы NPS появились новые условия, предназначенные для указания групп компьютеров, групп пользователей, разрешенных типов EAP и адресов IPv6 клиентов и серверов доступа. Для поддержки протокола HCAP в службу NPS введены новые условия для групп местоположений и групп пользователей. Для поддержки защиты доступа к сети в службе NPS используются новые условия политики для типа идентификатора, политики работоспособности, компьютеров, пригодных для защиты доступа к сети, операционной системы и срока действия политики.
Оснастка службы NPS Новая оснастка службы NPS была значительно усовершенствована, что существенно облегчило процессы создания и управления клиентами и удаленными серверами RADIUS, политиками сети для обычного доступа к сети, политиками работоспособности и параметрами защиты доступа к сети в соответствующих сценариях, а также параметрами ведения журнала.
С помощью узла «Клиенты и серверы RADIUS» можно настраивать клиенты RADIUS (серверы доступа к сети, точки NAP и иные RADIUS-прокси, когда служба NPS работает в качестве сервера RADIUS) и группы удаленных серверов RADIUS (другие серверы RADIUS, когда служба NPS работает в качестве RADIUS-прокси).
С помощью узла «Политики» можно настраивать политики запросов на подключение (если служба NPS будет работать в качестве сервера или RADIUS-прокси), политики сети (параметры авторизации и подключения, а также ограничения, если служба NPS работает в качестве сервера RADIUS) и политики работоспособности (соответствие клиентов NAP требованиям к работоспособности). При выборе в области сведений политики запросов на подключение или политики сети оснастка службы NPS выведет условия и параметры политики. На рис. 2 показано, как это может выглядеть.
Figure 2 The NPS snap-in enhanced display
Figure 2 The NPS snap-in enhanced display
Требования к работоспособности для защиты доступа к сети настраиваются в узле «Средства проверки работоспособности системы» узла «Защита доступа к сети». В узле «Группы серверов обновления» настраивается набор серверов, доступ к которым будет разрешен ограниченным клиентам NAP через VPN и DHCP. Наконец, в узле «Аудит» настраивается способ хранения службой NPS сведений об аудите.
Оснастка службы NPS включает расширенный набор мастеров, предназначенных для автоматизации первоначальной настройки клиентов RADIUS и политик, необходимых для методов принудительной защиты доступа к сети, подключений удаленного доступа и VPN-подключений, а также беспроводных и кабельных подключений с проверкой подлинности по протоколу 802.1X. Для методов принудительной защиты доступа к сети мастер защиты доступа к сети автоматически настраивает все политики запросов на подключение, политики сети и политики работоспособности.
Эти новые мастера находятся в узле «Служба NPS» соответствующей оснастки. Чтобы настроить политики и параметры методов принудительной защиты доступа к сети, выберите в раскрывающемся списке «Стандартная конфигурация» пункт «Защита доступа к сети» и нажмите кнопку «Настройка NAP». Чтобы настроить политики и параметры VPN-подключения и удаленного доступа, выберите в раскрывающемся списке «Стандартная конфигурация» пункт «RADIUS-сервер для подключений удаленного доступа или VPN» и нажмите кнопку «Настройка VPN или удаленного доступа». Чтобы настроить политики и параметры беспроводного или кабельного подключения с проверкой подлинности по протоколу 802.1X, выберите в раскрывающемся списке «Стандартная конфигурация» пункт «RADIUS-сервер для беспроводных или кабельных подключений 802.1X и нажмите кнопку «Настройка 802.1X».
С помощью каждого из этих мастеров можно настроить наиболее распространенные параметры конфигурации для выбранного сценария. Особенно полезны мастера для методов принудительной защиты доступа к сети. С помощью мастера NAP для принудительного VPN-подключения создаются следующие политики: политика запросов на подключение, три политики сети (для клиентов NAP, удовлетворяющих требованиям, клиентов NAP, не удовлетворяющих требованиям, и клиентов, несовместимых с NAP) и две политики работоспособности (для клиентов NAP, удовлетворяющих требованиям и клиентов NAP, не удовлетворяющих требованиям).
Новые мастера защиты доступа к сети и мастера для создания клиентов RADIUS, групп удаленных серверов RADIUS, политик запросов на подключение и политик сети упрощают настройку службы NPS для различных сценариев доступа к сети.

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


 Windows PowerShell: Копнем глубже
Windows PowerShell
Копнем глубже
Дон Джонс (Don Jones)

Оболочка Windows PowerShell содержит множество полезных функций, о которых многие администраторы попросту забывают. Если как следует разобраться, можно найти очень удобные возможности. Даже я сам зачастую нахожу новые возможности в командлетах, которые, как мне казалось, я знал вдоль и поперек.
Метод обучения Windows PowerShellTM, где я преподаю, я рекомендую сделать администраторам календарь, на каждой страничке которого описывался бы командлет дня — наподобие обычного отрывного календаря. Если есть такой календарь, то можно утром каждого дня (естественно, только не в выходные) потратить несколько минут, чтобы ознакомиться со всеми возможностями командлета. В Windows PowerShell содержится около 130 командлетов, то есть можно узнать обо всех функциях и возможностях Windows PowerShell примерно за полгода, если каждый день изучать по одному. После этого можно будет перейти к командлетам Exchange Server 2007.
В этой статье я приведу несколько примеров того, что можно найти и чего можно добиться, если потратить всего несколько минут на изучение возможностей командлетов.

Красивые отчеты в HTML
Один из редко используемых командлетов — ConvertTo-HTML. Этот «умник» принимает набор входных объектов — службы, процессы, объекты Windows® Management Instrumentation (WMI) и т.д., — и превращает их в таблицу HTML. Затем можно передать эту таблицу HTML в командлет Out-File, и в результате получается HTML-страница, пригодная для размещения на веб-сервере в интрасети. Например, на каждое утро можно запланировать запуск следующей команды:
Gwmi Win32_Service | Where { $_.StartMode –eq "Auto" –and $_.State –ne "Running" } | ConvertTo-HTML | Out-File C:\ServiceAlert.html
Эта команда будет создавать отчет HTML, подобный изображенному на рис. 1. В отчете будут указаны службы, которые должны запускаться автоматически, но не запущены.
Figure 1 An HTML report of services that aren't running
Figure 1 An HTML report of services that aren't running
При этом может возникнуть естественное желание сделать отчет покрасивее. К счастью, командлет ConvertTo-HTML выдает «чистый» код HTML, то есть не внедряет в создаваемый код теги форматирования. По правилам языка HTML не следует использовать форматирование в коде (его там должно быть как можно меньше). Форматирование следует разместить во внешней таблице стилей (CSS) и связать таблицу стилей с HTML. Такую ссылку можно сделать с помощью ConvertTo-HTML.
Ссылка на таблицу CSS указывается в разделе <HEAD> HTML-файла. Синтаксис команды ConvertTo-HTML, описанный в справке, содержит параметры, на которые вы могли не обращать внимания раньше:
ConvertTo-Html [[-property] <Object[]>] [-inputObject <psobject>] [-body <string[]>] [-head <string[]>] [-title <string>] [<CommonParameters>]
Параметр -head предназначен для того, чтобы указать дополнительный HTML-код, который нужно вставить в раздел <HEAD> сценария. Теперь изменим мою команду, чтобы указать ссылку на существующий CSS-файл, содержащий форматирование для таблицы HTML:
Gwmi Win32_Service | Where { $_.StartMode –eq "Auto" –and $_.State –ne "Running" } | ConvertTo-HTML -title "Services" -head "<link rel='stylesheet' href='styles.css' type='text/ css' />" | Out-File C:\ServiceAlert.html
Здесь я применил параметр -head для вставки ссылки на CSS-файл, находящейся в той же папке, что и выходной HTML-файл. Параметр -title использовался, чтобы указать название страницы. Результат показан на рис. 2. Текст использованного мной файла Style.CSS такой:
Figure 2 An HTML report that is formatted with a CSS file
Figure 2 An HTML report that is formatted with a CSS file
body { background-color:#EEEEEE; } body,table,td,th { font-family:Tahoma; color:Black; Font-Size:10pt } th { font-weight:bold; background-color:#CCCCCC; } td { background-color:white; }

Удобная фильтрация
Командлет месяца
В этом месяце я расскажу о паре командлетов: Start-Transcript и Stop-Transcript. Оба командлета используются для управления ведением журнала Windows PowerShell (весь текст, появляющийся в окне консоли, записывается в указанный текстовый файл). Командлеты работают довольно просто. Запустите Start-Transcript, указав имя файла. Затем запустите Stop-Transcript, чтобы завершить ведение журнала и закрыть файл. Это очень удобно при переходе от произвольного использования оболочки к формальным сценариям: после того, как вам удастся создать нужные командные строки в оболочке, их можно будет просто скопировать из созданного файла журнала. А можно, конечно же, отредактировать файл журнала, отставив в нем только команды сценария. Мой коллега Джеффри Хикс (Jeffery Hicks) написал сценарий, анализирующий журналы и преобразующий их в PS1-файлы для Windows PowerShell. Этот сценарий находится по адресу blog.sapien.com/current/2006/11/28/powershell-transcripts.html.

Теперь поговорим о командлете Get-WMIObject. В справке Windows PowerShell описываются все функции этого командлета, многие из которых редко используются:
Get-WmiObject [-class] <string> [[-property] <string[]>] [-namespace <string>] [-computerName <string[]>] [-filter <string>] [-credential <PSCredential>] [<CommonParameters>]
Можно отметить одну общую ошибку всех новичков, применяющих Windows PowerShell — запуск следующей команды WMI:
Gwmi Win32_NTLogEvent –comp Server2
Эта команда получает записи журнала событий с сервера Server2. Все записи. Выполнение этой задачи сервером Server2 займет довольно много времени, да и оболочке Windows PowerShell потребуется время, чтобы сделать что-нибудь полезное с таким большим объемом данных.
Разумнее сделать так, чтобы сервер Server2 находил и отправлял только важные события. Для этого можно использовать запрос на языке WQL (языке запросов WMI). Некоторым синтаксис такого запроса покажется сложным, но в Windows PowerShell с помощью параметра -filter можно указать только ту часть запроса WQL, которая отвечает за фильтрацию.
Gwmi Win32_NTLogEvent –comp Server2 –filter "EventIdentifier=1024"
Эта команда получает все события из всех журналов с кодом события 1024. Обратите внимание, что в условии фильтра в качестве оператора сравнения используется «=», а не оператор Windows PowerShell -eq. Дело в том, что фильтр передается для обработки в службу WMI удаленного компьютера, поэтому условие нужно указывать с помощью синтаксиса WMI, а не синтаксиса Windows PowerShell.
Параметр -filter есть и в других командлетах, таких как Get-ChildItem, используемого в псевдонимах Dir и Ls. Параметр -filter обычно передает условие фильтра непосредственно на нижележащий уровень, то есть фильтрация выполняется в источнике. Это намного быстрее, чем передача всех объектов с последующим запуском командлета Where-Object, чтобы отфильтровать ненужные объекты.

Забытые командлеты
Изучение по одному командлету каждый день поможет лучше понять командлеты, которые вы уже считали хорошо знакомыми. Еще один важный довод в пользу ежедневного календаря с командлетами: это надежный способ узнать о командлетах, о которых вы при отсутствии такого календаря вообще бы не узнали. Один из моих любимых командлетов, которым многие не пользуются — Resolve-Path. Этот командлет возвращает набор имен файлов и папок, соответствующих указанному пути. Он схож с командлетом Get-ChildItem (то есть с хорошо известными псевдонимами Dir и Ls), но возвращает не целые файлы и папки, а текстовые строки, которые можно передать в другие командлеты для фильтрации и обработки. Использовать этот командлет очень просто:
Resolve-Path C:\P*
Эта команда возвратит пути, такие как C:\Program Files, C:\Processes.txt и т. д. На рис. 3 показаны два примера использования этого командлета.
Figure 3 Using the handy, though overlooked, Resolve-Path cmdlet
Figure 3 Using the handy, though overlooked, Resolve-Path cmdlet

Начните с начала
В самом начале работы с календарем «командлет дня» запустите Gcm — псевдоним командлета Get-Command. Вы получите список всех командлетов Windows PowerShell, включая добавленные через надстройки, например Exchange Server 2007 Management Shell, PowerShell Community Extensions и т. д. Выберите первый в списке, к примеру, Add-Content, и прочтите справку:
Help Add-Content –full
Вам понадобится полный текст справки, а не более сжатая справка по умолчанию. Можно получить полное описание всех параметров, посмотреть примеры использования командлетов и узнать другие подробности. Попробуйте поэкспериментировать с командлетом. (Для этого лучше использовать виртуальную систему, чтобы не повредить рабочую среду). Рекомендую тратить на это 10 минут каждый день, причем в одно и то же время, чтобы это стало привычкой. После этого вы за кратчайшее время овладеете всеми функциями и возможностями Windows PowerShell.

Дон Джонс (Don Jones) — ведущий специалист по написанию сценариев компании SAPIEN Technologies, соавтор книги «Windows PowerShell: TFM» (изд-во SAPIEN Press, 2007 г.). С ним можно связаться по адресу www.ScriptingAnswers.com.


 Эй, автор сценариев!: Возвращение WinRM
Эй, автор сценариев!
Возвращение WinRM
Программисты корпорации Майкрософт

Когда авторы сценариев задумали свою серию статей (состоящую из двух частей) об удаленном управлении Windows® (WinRM), на передний план немедленно вышла одна важная проблема: безопасность. Безусловно, нам, авторам сценариев, хорошо известно о проблемах, возникших в связи с выпуском последней книги серии о Гарри Поттере: заказанные заранее экземпляры неожиданно были отправлены и доставлены раньше официального выхода книги в свет. (Это, действительно, вызвало большие проблемы? Ну, конечно, нет; просто издательские компании попросили клиентов не читать книгу до ее официального выхода.)
И это еще только цветочки. Текст книги и окончание всей серии стали достоянием широкой публики гораздо раньше того, как книги появились в книжных магазинах. (Если вы до сих пор не читали последнюю книгу, это произошло по следующей причине: видимо, Гарри Поттер и впрямь оказался волшебником или чем-то вроде этого!) Аналогичным образом, отсканированные копии всех страниц мгновенно были выложены в Интернете, в некоторых случаях даже раньше, чем автор, Дж. К. Роулинг, написала эти страницы. Иными словами, этот был пример полного фиаско в сфере безопасности, и авторы сценариев были полны решимости не допустить повторения подобных вещей с их трудами. Посудите сами, если некоторые лица затратили столько трудов ради финала серии о Гарри Поттере, можно себе представить, какие силы будут брошены на то, чтобы наложить руки на окончание серии о WinRM (состоящей из двух частей).
К счастью, авторы сценариев смогли собраться и сохранить свои секреты в секрете (простите за тавтологию). Это произошло в первую очередь потому, что наши авторы завершили вторую часть своей серии уже после того, как прошли все сроки для предоставления статьи в редакцию. Но простите, ведь тот автор, который отвечает за написание колонки, был в отпуске весь август. И, в отличие от на удивление большого количества сотрудников Майкрософт, он никогда даже и не смотрит на компьютер во время отпуска, не говоря уж о том, чтобы его использовать.
Хотя, сказать по правде, он редко смотрит и почти никогда не использует компьютер, даже когда он не в отпуске. Но это совсем другая история.
Как бы там ни было, но мы знаем, что многие читатели полностью потеряли сон в последние четыре недели. Все это время они вертелись в постели, кряхтели и все думали, чем же закончится сага об удаленном управлении. Можем их обрадовать: мучительные дни бессонного ожидания наконец закончились. Сегодня, впервые в истории, мы представляем душераздирающее заключение серии статей об удаленном управлении (состоящей из двух частей). В сущности, вся информация приведена на рис. 1.
Figure 1 The denouement (Close Figure 1)
strComputer = "atl-fs-01.fabrikam.com"

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

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

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

Do Until objResponse.AtEndOfStream strXML = objResponse.ReadItem

    Set objXMLDoc = CreateObject("Microsoft.XMLDom") objXMLDoc.async=False objXMLDoc.loadXML(strXML)

    Set objElement = objXMLDoc.documentElement Wscript.Echo "Name: " & objElement.ChildNodes(0).ChildNodes(0).NodeValue Wscript.Echo "Display Name: " &  objElement.ChildNodes(1).ChildNodes(0).NodeValue Wscript.Echo Loop
Да, мы понимаем. Такого поворота событий никто не мог ожидать. objElement.ChildNodes(0).ChildNodes(0).NodeValue! Кто это когда-либо видел? Безусловно, это часть нашей системы безопасности: ведь даже авторы сценариев понятия не имели, чем закончится наша серия. Но теперь все тайное стало явным.
Прежде чем мы пойдем дальше, необходимо сделать краткий обзор всей темы в целом. Вдруг кто-то из вас, по какой-то невероятной причине, не сумел прочесть первую часть статьи (которую можно найти по адресу technetmagazine.com/issues/2007/11/HeyScriptingGuy). Тогда, в первой части, мы рассмотрели общие понятия удаленного управления — новой технологии, реализованной в операционных системах Windows Server® 2003 R2, Windows Vista® и Windows Server 2008. Эта технология значительно упрощает процесс управления компьютерами через Интернет даже при наличии брандмауэра. Безусловно, и раньше существовала возможность удаленного управления компьютерами с помощью инструментария управления Windows (WMI); однако в основе WMI лежит технология удаленного управления Distributed COM (DCOM). Мы ничего не имеем против этой технологии за исключением одного факта: многие брандмауэры по умолчанию блокируют трафик DCOM. Конечно, можно открыть соответствующие порты и разрешить трафик DCOM, однако многие сетевые администраторы никогда бы не согласились с этим по одной очень существенной причине: открывая доступ трафику DCOM, мы одновременно распахиваем дверь перед многочисленными злоумышленными программами всех сортов и мастей.
Итак, WinRM «является реализованным Майкрософт протоколом WS-Management — стандартным протоколом на основе SOAP, который позволяет взаимодействовать оборудованию и операционным системам различных производителей». Звучит довольно сложно, но, в сущности, здесь говорится о том, что теперь можно осуществлять удаленное управления, используя стандартные Интернет-протоколы, например HTTP или HTTPS.
Как мы указывали в статье прошлого месяца, с помощью WinRM стало гораздо проще устанавливать соединение и извлекать с удаленных компьютеров данные WMI. Но означает ли это, что WinRM — совершенно идеальная технология? Увы, не совсем. Как мы уже поясняли, когда WinRM отправляет данные вызывающему сценарию, эти данные возвращаются в формате XML. Вряд ли стоит говорить, что синтаксический анализ и использование XML-файлов вызывает большие трудности, особенно у тех системных администраторов, которые не имеют большого опыта в этой области. По этой причине в комплект поставки WinRM входит XSLT-файл, который преобразует возвращаемые данные в более удобный формат.
Это было бы просто прекрасно, если бы не тот факт, что ваши выходные данные всегда будут выглядеть приблизительно так:
Win32_Service AcceptPause = false AcceptStop = true Caption = User Profile Service CheckPoint = 0 CreationClassName = Win32_Service
Это не так уж и плохо, однако нельзя забывать, что выходные данные всегда будут выводиться в окне командной строки. По умолчанию вы не сможете сохранить данные в текстовом файле, записать их в базу данных или таблицу Microsoft® Excel® или выполнить с ними какие-либо другие операции. Эти данные можно только отобразить на экране. В этом нет ничего хорошего.
Более того, если вы захотите возвратить лишь выбранное число свойств класса WMI (что обычно делается для снижения сетевого трафика), ваши проблемы только усугубятся. При работе лишь с отдельными свойствами класса, а не со всеми его свойствами, выходные данные будут выглядеть примерно следующим образом:
XmlFragment DisplayName = Windows Event Log Name = EventLog

XmlFragment DisplayName = COM+ Event System Name = EventSystem
Интересно, но не слишком привлекательно с эстетической точки зрения (особенно это касается заголовка XmlFragment, который появляется во всех строках отчета).
Но что можно с этим сделать? Написать собственный код для синтаксического анализа и форматирования данных XML? Вряд ли системному администратору, даже и владеющему навыками написания сценариев, захочется сделать что-то подобное. Или все-таки захочется?

Если вы хотите, чтобы какая-то вещь была сделана правильно, сделайте ее сами
Получается, что использование необработанных данных XML, возвращаемых WinRM, далеко не такая страшная задача, как это может показаться на первый взгляд. В этом месяце мы покажем один простой метод синтаксического анализа и форматирования данных XML. Подход, который здесь будет использоваться, является далеко не единственным способом работы с XML, но он дает превосходные результаты. В этой статье мы, в первую очередь, хотим показать, что вам не стоит полностью полагаться на преобразования XSLT. Если вы поняли основную идею, значит, ваши возможности работы с данными WinRM становятся практически безграничными.
Здесь есть небольшая загвоздка: чтобы уместить эту статью в отведенное для нее пространство, нам пришлось опустить большую часть сценария, приведенного на рис. 1. Однако это не должно вызвать больших проблем, поскольку первые две трети сценария были подробно описаны в статье прошлого месяца. Теперь мы сосредоточимся на последней трети сценария. Именно в этой части выполняется фактическая работа с возвращенными данными.
Как видите, этот эпизод хроник удаленного управления начинается после того, как мы создали экземпляр объекта WSMan.Automation, запросили удаленный компьютер (в данном случае atl-fs-01.fabrikam.com) и получили сведения о всех службах, выполняющихся на этом компьютере. Теперь мы оказались на той строке сценария, в которой мы создали цикл Do Until для считывания и обработки возвращенных данных XML. Выполнение этого цикла будет продолжаться до тех пор, пока не останется данных для считывания и обработки. (Или, если сделать вид, что мы понимаем то, о чем говорим, до тех пор, пока свойство XML-файла AtEndOfStream не получит значение True.)
Вот та строка кода, о которой идет речь, и именно с этой строки начинается история этого месяца:
Do Until objResponse.AtEndOfStream
Первое, что мы делаем внутри цикла, — это используем метод ReadItem для считывание первого раздела возвращенных данных XML. (Поскольку мы работаем с WinRM и получаем сведения о службах, в первом разделе будут содержаться данные о первой службе в коллекции.) После сортировки этих данных (естественно, в формате XML) в переменной с именем strXML создается экземпляр объекта Microsoft.XMLDom. В действительности, при этом создается пустой документ XML, с которым можно работать:
Set objXMLDoc = _ CreateObject("Microsoft.XMLDom")
Создав пустой документ, мы устанавливаем для свойства Async значение False и вызываем метод loadXML.
Затем выполняется... Что вы сказали? Почему для свойства Async установлено значение False? И зачем вызывается метод loadXML? Хорошие вопросы; жаль, что мы не подумали о них сами!
Для начинающих поясним, что свойство Async управляет возможностью асинхронной загрузки данных XML. Если это свойство имеет значение True, загрузка начнется и управление будет передано сценарию немедленно, даже если загрузка еще не завершена. Конечно, это звучит довольно привлекательно. Но, к сожалению, выполнение сценария затем будет продолжено, как будто все необходимые данные уже получены. Если же загружены не все сведения, вы рискуете нажить себе неприятности. Вот почему для свойства Async устанавливается значение False.
Примечание. Можно написать код для периодической проверки состояния загрузки и, таким образом, избежать преждевременного выполнения сценария. Это, безусловно, сработает, но гораздо проще установить для свойства Async значение False. В этом случае выполнение сценария блокируется до завершения загрузки; другими словами, как только началась загрузка, сценарий терпеливо ждет ее окончания и лишь затем выполняет следующие действия.
Что касается метода loadXML, о его предназначении легко понять из названия: он загружает документ (или фрагмент документа) XML правильного формата в пустой документ. Все, что нам нужно сделать, — это вызвать метод loadXML, указав переменную strXML в качестве единственного параметра:
objXMLDoc.loadXML(strXML)
Что мы имеем в чистом остатке? Мы преобразовали данные WinRM в виртуальный документ XML. И теперь можно использовать стандартные методы XML для синтаксического анализа этого виртуального документа.
Для этого необходимо использоваться показанную ниже строку кода, чтобы создать объектную ссылку на корневой элемент в XML-файле:
Set objElement = objXMLDoc.documentElement
А теперь можно и повеселиться. (Если, конечно, вы находите веселой процедуру синтаксического анализа XML-файла. Для нас, авторов сценариев, это одно из самых веселых занятий на свете.)
Как вы, возможно, помните, наш запрос на языке запросов WMI (WQL) (или, используя терминологию WinRM, наш фильтр) выглядит следующим образом:
strFilter = "Select Name, DisplayName " & _ "From Win32_Service Where State = 'Running'"
Как можно видеть, мы запросили два свойства класса Win32_Service: Name и DisplayName. (Мы также включили предложение Where, которое ограничивает возвращаемые данные только выполняющимися службами. Однако в этом нет ничего, что может вызвать проблемы.) Насколько важен тот факт, что мы запросили два свойства? И существен ли порядок этого запроса? Возможно. И каким же образом мы должны догадаться об этом?
Неплохое замечание. Возможно, как авторы этой статьи, мы и вправду знаем ответы на эти вопросы. Все правильно. Совершенно случайно мы знаем, что ответ на оба вопроса является положительным. Важен ли тот факт, что мы запросили два свойства в запросе WQL? Да, важно. В конце концов, нам будут возращены только эти два свойства. (В противоположность запросу Select * From, который возвратит значения для всех свойств класса.)
А порядок запроса этих двух свойств важен? Уверены, что да. Значения свойств возвращаются в том порядке, в каком они указываются в запросе. Это важно потому, что каждое значение свойства возвращается в качестве дочернего узла (или раздела) корневого элемента. Какое свойство станет первым дочерним узлом? Ответ на этот вопрос достаточно прост. В нашем случае первым дочерним узлом станет свойство Name, поскольку это свойство указано первым в запросе WQL. Какое свойство станет вторым дочерним узлом? Правильно — свойство DisplayName, поскольку оно является вторым элементом в запросе WQL.
Секундочку. Вы это вычислили сами или кто-то заранее предоставил материал для этой статьи? Хм...
В любом случае, довольно просто получить значение свойства Name. Все, что нужно сделать, — это указать ссылку NodeValue первого элемента (элемента 0) в первой коллекции ChildNodes (элемент 0) примерно следующим образом:
Wscript.Echo "Name: " & _ objElement.ChildNodes(0).ChildNodes(0).NodeValue
А каким образом указать ссылку на значение свойства DisplayName? В этом случае мы указываем ссылку NodeValue первого элемента во второй коллекции ChildNodes (элемент 1):
Wscript.Echo "Display Name: " & _ objElement.ChildNodes(1).ChildNodes(0).NodeValue
А если в запросе WQL имеется и третье свойство (скажем, Status)? В таком случае мы просто указываем ссылку NodeValue первого элемента в третьей коллекции ChildNodes (элемент 2):
Wscript.Echo "Status: " & _ objElement.ChildNodes(2).ChildNodes(0).NodeValue
И так далее, пока не получите последнее свойство.
И каким образом теперь будут выглядеть выходные данные нашего сценария? Примерно вот так:
Display Name: Windows Event Log Name: EventLog

Display Name: COM+ Event System Name: EventSystem
Конечно, эти строки по внешнему виду не сильно отличаются от выходных данных WinRM по умолчанию (хотя нам удалось избавиться от глупых заголовков XmlFragment). Главное отличие заключается в следующем: работая с отдельными значениями свойств, мы более не связаны форматированием по умолчанию (обратите внимание, что мы используем метку Display Name, а не DisplayName). И теперь можно не только выводить данные в окне командной строки.
Хотите записать данные в таблицу Excel? Это довольно легко сделать. Для начала вставьте следующий блок кода (который создает и настраивает новую таблицу Excel) сразу после строки сценария WinRM, в которой вызывается метод Enumerate:
Set objExcel = _ CreateObject("Excel.Application") objExcel.Visible = True Set objWorkbook = objExcel.Workbooks.Add() Set objWorksheet = objWorkbook.Worksheets(1)

i = 2 objWorksheet.Cells(1,1) = "Name" objWorksheet.Cells(1,2) = "Display Name"
Теперь замените исходный цикл Do Until циклом, показанным на рис. 2. Попробуйте и посмотрите, что получится.
Figure 2 New Do Until loop (Close Figure 2)
Do Until objResponse.AtEndOfStream strXML = objResponse.ReadItem

  Set objXMLDoc = CreateObject("Microsoft.XMLDom") objXMLDoc.async=False objXMLDoc.loadXML(strXML)

  Set objElement = objXMLDoc.documentElement objExcel.Cells(i, 1) = objElement.ChildNodes(0).ChildNodes(0).NodeValue objExcel.Cells(i, 2) = objElement.ChildNodes(1).ChildNodes(0).NodeValue i = i + 1 Loop

WinRM, часть 3?
Между статьями этого и прошлого месяца у вас было достаточно времени для начала работы с WinRM. Во всяком случае, мы на это надеемся. WinRM — увлекательная новая технология, которая позволит сделать удаленное управление компьютерами гораздо проще (без ущерба для надежности и безопасности). Безусловно, у читателя возникнет резонный вопрос: означает ли это, что нам следует ждать третьей части саги об удаленном управлении?
К сожалению, мы не можем сказать ничего определенного. Дело здесь не в желании защитить конфиденциальную информацию. Просто так уж устроен процесс планирования и принятия решений авторов сценариев: мы не имеем ни малейшего представления, удастся ли нам написать еще что-нибудь о WinRM. Как говорится, следите за информацией!
Головоломка-сценарий доктора Скрипто
С доктором Скрипто случилась неприятность. Он забыл убрать один из своих сценариев (как следовало бы сделать хорошему специалисту по написанию сценариев) и случайно споткнулся о него. В результате, фрагменты сценария разлетелись во все стороны. Ему удалось найти все переменные, ключевые слова, символы и другие служебные объекты и аккуратно сложить их в алфавитном порядке. Но теперь нужно сложить все это вместе, чтобы получить исходный сценарий. Эта задача отнимет у него довольно много времени, но он надеется закончить ко времени выхода очередного выпуска журнала TechNet Magazine в следующем месяце. Тем временем, вы тоже можете попробовать превратить этот беспорядочный набор фрагментов в полноценный сценарий. Удачи!
Подсказка: пожалуй, мы вам немного поможем. Окончательный сценарий удаляет на локальном компьютере все файлы старше указанной даты.

Головоломка-сценарий доктора Скрипто
Ответ: неловкий доктор Скрипто, декабрь 2007 г.
Да, доктору Скрипто удалось снова сложить свой сценарий. Ниже приведен восстановленный рабочий сценарий, который удаляет на локальном компьютере все файлы старше указанной даты.
strDate = "20060102000000.000000+000"

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set colFiles = objWMIService.ExecQuery("Select * From CIM_DataFile Where CreationDate < '" & strDate & "'")
For Each objFile in colFiles
    Wscript.Echo objFile.Name
Next

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


 На страже безопасности: Политики паролей доменов Windows
На страже безопасности
Политики паролей доменов Windows
Дерик Мелбер (Derek Melber)

Если вы занимаетесь администрированием домена Windows, то слишком хорошо знаете все ограничения, связанные с политиками паролей для учетных записей пользователей домена. Однако в Windows Server 2008 некоторые из этих ограничений будут упразднены. Давайте посмотрим, как в новой операционной системе решена одна проблема: невозможность использования нескольких политик паролей.
Если сейчас запустить любую версию домена Windows® (Windows NT®, Windows 2000 Active Directory®или Windows Server® 2003 Active Directory), в каждом домене может быть только одна политика паролей. На самом деле, ограничена не только политика паролей, но и более широкий набор параметров, относящихся к политикам учетных записей. На рис. 1 показаны эти политики и параметры.
Figure 1 Account policies (Close Figure 1)

Политика паролей
Вести журнал паролей
Максимальный срок действия пароля
Минимальный срок действия пароля
Минимальная длина пароля
Пароль должен отвечать требованиям сложности
Хранить пароли, используя обратимое шифрование
Политика блокировки учетной записи
Продолжительность блокировки учетной записи
Порог блокировки учетной записи
Время до сброса счетчика блокировки
Политика Kerberos
Принудительные ограничения входа пользователей
Максимальный срок жизни билета службы
Максимальный срок жизни билета пользователя
Максимальный срок жизни для возобновления билета пользователя
Максимальная погрешность синхронизации часов компьютера
Эти параметры политики по умолчанию применяются ко всем учетным записям домена и пользователей, связанных с доменом. Вызвано это тем, как групповая политика наследует параметр в структуре Active Directory. Чтобы лучше понять, как эти политики влияют на учетные записи домена и локальных пользователей, нужно разобраться, где эти политики устанавливаются и как наследование групповой политики влияет на все учетные записи. (Обратите внимание, что параметры политики Kerberos применяются только к учетным записям пользователей домена, поскольку Kerberos используется для проверки подлинности только учетными записями домена. Локальные учетные записи используют для проверки подлинности NTLMv2, NTLM или LM.)

Установка политик учетных записей
В Active Directory групповая политика устанавливает политики учетных записей для всего домена. Это происходит при первоначальной установке домена Active Directory и осуществляется посредством установки объекта групповой политики по умолчанию, связанного с узлом домена в Active Directory. Этот объект групповой политики, называемой политикой домена по умолчанию, содержит конфигурацию по умолчанию для всех трех разделов политик учетных записей. На рис. 2 показан полный список первоначальных параметров для объектов политики паролей в домене Windows Server 2003.
Figure 2 Default password policies for Windows Server 2003 domain
Figure 2 Default password policies for Windows Server 2003 domain
Параметры в этом объекте групповой политики управляют политиками учетных записей для всех учетных записей пользователей домена и для всех компьютеров домена. Обратите внимание, что на всех компьютерах домена (как настольных ПК, так и серверах) есть локальный диспетчер учетных записей безопасности (SAM). Этот диспетчер управляется параметрами в объекте групповой политики. Кроме того, локальный диспетчер SAM содержит локальные учетные записи пользователей для каждого компьютера.
Параметры политики домена по умолчанию влияют на все компьютеры домена посредством наследования объектов групповой политики в структуре Active Directory. Поскольку данный объект групповой политики связан с узлом домена, от него будут зависеть все учетные записи компьютеров домена.

Что нельзя сделать с текущими политиками паролей
Существует ряд неверных предположений об управлении паролями в текущей реализации Active Directory (в Windows Server 2003), невзирая на годы тщательного тестирования и полное отсутствие подтверждения этих предположений. Совершенно ясно, что политика работает в точности так, как это предусмотрено.
Например, многие администраторы считают, что для пользователей одного домена может быть несколько политик паролей. Они предполагают, что можно создать объект групповой политики и связать его с подразделением. Идея состоит в том, чтобы переместить учетные записи в подразделение, чтобы на них влиял объект групповой политики. Внутри объекта групповой политики изменяются политики учетных записей и создается более безопасная политика паролей, например путем указания максимальной длины паролей равной 14 знакам. Однако по ряду причин такая конфигурация не даст желаемого результата. Во-первых, параметры политики паролей основаны на компьютерах, а не на пользователях. По этой причине они не будут влиять на учетные записи пользователей. Во-вторых, единственный способ изменения параметров политики учетных записей для учетной записи пользователя домена обеспечивается объектом групповой политики, связанным с доменом. Объекты групповой политики, связанные с подразделениями, которые настроены для изменения политик учетных записей, изменят локальный диспетчер учетных записей безопасности компьютеров, находящихся в подразделении или во вложенных подразделениях связанного подразделения.
Второе неверное предположение заключается в том, что параметры политик учетных записей, установленных в корневом домене (начальном домене леса Active Directory) будут унаследованы дочерними доменами леса. Это неверно. Заставить параметры работать таким образом — невозможно. Объекты групповой политики, связанные с доменом и подразделениями внутри одного домена, не повлияют на объекты в другом домене, даже если домен со связанными объектами групповой политики является корневым. Единственный способ распространения параметров объектов групповой политики в различных доменах — связать объекты групповой политики с сайтами Active Directory.

Как обрабатываются пароли
Как мы только что видели, в текущих версиях Windows пароли учетных записей пользователей обрабатываются простым и понятным образом. Для всех учетных записей домена используется единый набор правил паролей, так же как и для управления политиками учетных записей посредством объекта групповой политики, связанного с узлом домена в Active Directory. Однако в Windows Server 2008 все это изменено.
В Windows Server 2008 и инфраструктуре поставляющейся с ним службы каталогов Active Directory используется другой подход. Вместо размещения политик учетных записей в объекте групповой политики (это позволяло использовать только одну политику для всех учетных записей пользователей домена) параметры перемещены на более глубокий уровень Active Directory. Политики учетных записей больше не основаны на учетных записях компьютеров. Теперь объектами управления паролями могут быть отдельные пользователи и группы пользователей. Это принципиальное новшество для администраторов Windows, поскольку до этого управление учетными записями в течение долгого времени осуществлялось посредством политик учетных записей.

Политики учетных записей в Windows Server 2008
В Windows Server 2008 не нужно устанавливать политики учетных записей с политикой домена по умолчанию. Более того, вообще не надо будет использовать объекты групповой политики для создания политик учетных записей пользователей домена. В Windows Server 2008 изменения будут производиться в базе данных Active Directory. В частности, для изменения объекта Active Directory и связанных с ним атрибутов будет применяться программа, такая как ADSIEdit.
Причина этого изменения заключается в том, что групповая политика не поддерживает несколько политик паролей в одном домене. Реализация поддержки нескольких политик паролей в одном домене в Windows Server 2008 весьма изящна, но не слишком проста. Впрочем, со временем интерфейс для настройки параметров станет проще. В настоящее время для внесения изменений в систему требуется изменять базу данных Active Directory, а это непросто и требует высокой квалификации.
Впрочем, нет необходимости использовать ADSIEdit для изменения параметров политик учетных записей, если вы предпочитаете делать это иначе. Можно использовать любые другие средства редактирования LDAP, способные изменять базу данных Active Directory, и даже сценарии. При реализации политик паролей в Windows Server 2008 подход будет коренным образом отличаться от того, что вы делали раньше. Прежде всего, придется обдумать, какие параметры паролей нужно назначить определенным пользователям и группам.
Следует учесть не только длину паролей, но и дополнительные ограничения, включая минимальный и максимальный срок действия, число последовательных уникальных паролей и т.д. Кроме того, следует подумать о том, как настроить параметры блокирования пользователей и параметры Kerberos. Между нынешними параметрами политики учетных записей и параметрами в базе данных Active Directory в Windows Server 2008 существует однозначное соответствие, однако следует учитывать, что имена всех параметров изменились, поскольку они теперь стали объектами и атрибутами Active Directory.
Для применения новых параметров паролей следует создать в контейнере параметров паролей объект параметров паролей (PSO) под названием msDS-PasswordSettings с путем LDAP "cn=Password Settings,cn=System,dc=domainname,dc=com." Обратите внимание, что функциональный уровень домена, в котором вы работаете, следует установить равным Windows Server 2008. В новом объекте нужно заполнить данные для нескольких атрибутов, как показано на рис. 3.
Figure 3 Password attributes in Active Directory (Close Figure 3)

Атрибут Active Directory | Описание
msDS-PasswordSettingsPrecedence | Устанавливает приоритет в случая, когда пользователь состоит в нескольких группах с различными политиками паролей.
msDS-PasswordReversibleEncryptionEnabled | Указывает, включено ли обратимое шифрование.
msDS-PasswordHistoryLength | Указывает, сколько последовательных паролей должны быть уникальными перед повторным использованием старого пароля.
msDS-PasswordComplexityEnabled | Указывает количество и тип знаков, обязательных в пароле.
msDS-MinimumPasswordLength | Указывает минимальную длину.
msDS-MinimumPasswordAge | Указывает, сколько времени пользователь должен использовать пароль перед тем, как сменить его.
msDS-MaximumPasswordAge | Указывает, сколько времени пользователь может использовать пароль перед тем, его придется сменить.
msDS-LockoutThreshold | Указывает разрешенное число ошибочных попыток ввода пароля, после которого учетная запись будет заблокирована.
msDS-LockoutObservationWindow | Указывает время, после которого счетчик неверно введенных паролей будет обнулен.
msDS-LockoutDuration | Указывает, на какое время будет заблокирована учетная запись после превышения разрешенного числа ошибочных попыток ввода пароля.
Как можно увидеть, все параметры групповой политики, относящиеся к параметрам политики учетных записей, продублированы в виде атрибутов. Следует учесть, что нужно установить и приоритет. Это необходимо для применения нескольких политик паролей в одном домене, поскольку неизбежно возникнут конфликты между политиками, и потребуется механизм для их устранения.

Указание на параметры политики учетных записей
Для каждого создаваемого объекта следует заполнить все атрибуты, чтобы политика учетных записей применялась к каждому пользователю. Есть один новый атрибут msDS-PSOAppliesTo, определяющий, к каким объектом будет применен набор параметров политики. Это самый важный атрибут, с помощью которого можно установить разные параметры для разных пользователей. Этот атрибут применяется к списку, в котором могут находиться как пользователи, так и группы, однако рекомендуется использовать группы вместо отдельных пользователей, как и во всех прочих случаях при работе со списками управления доступом. Группы стабильней, наглядней и намного проще в управлении.

Подведем итоги
Многие годы всем нам хотелось использовать различные политики паролей внутри одного домена Active Directory, и теперь это наконец возможно. Больше не нужно применять для всех пользователей целого домена один и тот же уровень безопасности в том, что касается паролей. Теперь, к примеру, можно настроить параметры так, чтобы у обычных пользователей были пароли длиной 8 знаков, а у ИТ-специалистов (у которых могут быть права администраторов) — пароли длиной 14 знаков.
Потребуется некоторое время, чтобы привыкнуть к тому, что для установки или изменения параметров политики учетных записей нужно изменять базу данных Active Directory. Однако, к счастью, вы уже знакомы с синтаксисом новых параметров. Обязательно ознакомьтесь с новыми параметрами сразу же, как только начнете работать с Windows Server 2008, поскольку эти параметры будут в числе самых первых, которые вам понадобится настроить.

Дерик Мелбер (Derek Melber)обладатель сертификатов MCSE, CISM, MVP — независимый консультант и преподаватель. Он преподает технологии Майкрософт и специализируется на Active Directory, групповой политике, безопасности и управлении настольными ПК. Дерик выпустил несколько книг в области ИТ, включая «Руководство по групповой политике Microsoft Windows» (изд-во Microsoft Press, 2005 г.). С ним можно связаться по адресу derekm@braincore.net.


 Материалы о рабочей среде: Развертывание Windows в виртуальном мире
Материалы о рабочей среде
Развертывание Windows в виртуальном мире
Уэс Миллер (Wes Miller)

Виртуальные среды используются повсеместно. Если вы еще не пользуетесь преимуществами этого решения, вы многое теряете. Виртуализация снижает зависимость от оборудования благодаря созданию слоя абстрагирования оборудования (HAL) и позволяет запускать такие гостевые операционные системы, как Windows Server или клиентские операционные системы Windows.
Виртуализация отличается от эмуляции тем, что не эмулирует гостевой процессор. Виртуализация лишь представляет ресурсы основной системы таким образом, чтобы гостевая система имела доступ к ним. В результате основные системы прозрачны для гостевых систем. Можно перенести виртуальную машину с системы, созданной одним производителем, на систему, созданную другим производителем, — аппаратное обеспечение основной системы обычно не имеет значения. Однако здесь необходимо сделать ряд предостережений. Например, при переносе виртуальной машины, созданной на базе процессора одного производителя, например AMD, на аппаратные средства другого производителя, например Intel, могут возникнуть определенные сложности (в зависимости от используемой технологии виртуализации). Это объясняется тем, что технология виртуализации основана на передаче данных между основной и гостевой системами, в этой технологии не эмулируется конкретный процессор для гостевой системы (как, например, в программе Microsoft® Virtual PC, запущенной на устаревшем компьютере Macintosh с архитектурой PowerPC).
Однако в технологии виртуализации эмулируются ключевые компоненты оборудования для гостевой системы. Чаще всего это относится к сетевому оборудованию, видеоадаптерам (как правило, эмулируются устройства с весьма ограниченными возможностями, значительно отстающими от возможностей современных графических процессоров) и запоминающим устройствам. Это работает путем предоставления одного или нескольких типов программно эмулированных устройств гостевой системе. По прочтении этой части статьи вы должны были обратить внимание на то, что именно эти устройства необходимы среде предустановки Windows® PE. Для правильной работы Windows технология виртуализации должна поддерживать все указанные типы устройств. Кроме того, любая технология виртуализации должна эмулировать систему BIOS. Хотя технология виртуализации также может эмулировать интерфейс EFI (Extensible Firmware Interface), малое количество операционных систем, поддерживающих в настоящее время этот интерфейс, ограничивает его использование. Эмуляция всех указанных выше функций позволяет загружаться виртуальным гостевым системам. Система BIOS и все необходимые устройства эмулируются программным путем и предоставляются гостевым системам. Это означает, что для этих виртуальных устройств требуются те же драйверы (не обязательно драйверы, поставляемые с Windows), что и для реальных устройств. Это важно иметь в виду.
Хотя некоторые технологии виртуализации позволяют использовать устройства USB (или USB 2.0), я не буду углубляться в конкретные особенности этих технологий. Не считая USB-устройств, которым также требуются драйверы (принтеры, беспроводные сетевые USB-платы и т.д.), и поддержки технологии DirectX® (отсутствующей в большинстве технологий виртуализации), заставить устройства работать не так сложно. Помните, что поддержка USB-устройств и иных неэмулируемых устройств зависит от используемой технологии виртуализации. Убедитесь в том, что вам известны все ограничения (я бы сказал, острые углы) используемого программного продукта для виртуализации перед тем, как использовать с этим продуктом новые устройства.
Программы виртуализации для операционной системы Windows в настоящее время предлагают два производителя: корпорация Майкрософт и компания VMware (vmware.com). Также готовятся к выпуску программные продукты других производителей, например Parallels (parallels.com).
Теперь вы получили общее представление о виртуализации. Далее я расскажу, как установить эту технологию, как избежать наиболее распространенных «подводных камней» и как развернуть эту технологию на большом количестве компьютеров в организации.

Виртуальное развертывание
Развертывание виртуальных систем, по-видимому, не должно отличаться от развертывания реальных систем. Но, как вы убедитесь, имеется ряд веских причин, чтобы сделать это по-другому.
Во времена Windows NT®развертывание систем выполнялось с помощью программы установки. Можно было использовать сценарий, но все равно требовалось пройти весь процесс установки от начала и до конца. После завершения установки скопировать образ на несколько компьютеров (что было бы весьма удобно) было нельзя, поскольку такая возможность попросту не поддерживалась.
Со временем корпорация Майкрософт пришла к выводу, что поддержка копирования дисков или «клонирования» систем Windows NT имеет смысл. Таким образом, в настоящее время любой способ развертывания реальных систем подходит также для развертывания виртуальных систем. Доступны следующие способы: Winnt32 (или программа setup.exe для Windows Vista® и Windows Server® 2008); среда предустановки Windows PE (версии 1.x или 2.x, в зависимости от развертываемого клиента, как показано в моих предыдущих статьях); служба удаленной установки (RIS) или службы развертывания Windows (WDS); средство Sysprep (программа подготовки системы, появившаяся в Windows NT 4.0) или любая программа дублирования дисков (например ImageX).
Конечно, это необходимо проделать только при первом развертывании конкретной ОС. После этого развернутую ОС можно просто скопировать. Однако при использовании упомянутых выше средств дублирования дисков возникает одна проблема.

Использование средства Sysprep
Первоначальное решение корпорации Майкрософт не поддерживать дублирование дисков было связано, в основном, с идентификатором безопасности Windows NT (SID). К счастью, эту проблему можно решить с помощью средства Sysprep. Но давайте сначала рассмотрим саму проблему. Как показано в статье support.microsoft.com/kb/314828, идентификатор безопасности SID состоит из номера версии структуры SID (как правило, идентификатора GUID), который служит для идентификации компьютера с операционной системой Windows. Этот идентификатор используется в дальнейшем в качестве корневого компонента идентификаторов всех учетных записей. Локальные учетные записи имеют собственный уникальный идентификатор — относительный идентификатор (RID). Идентификатор RID состоит из идентификатора учетной записи ID, прикрепленного в конце идентификатора SID. Таким образом, сочетание двух идентификаторов становится идентификатором для локальных учетных записей.
Давайте теперь рассмотрим, почему это может привести к проблеме при использовании идентификатора SID администратора S-1-5-21-191058668-193157475-1542849698-500. Здесь S-1-5 — это дескриптор, указывающий на то, что используются идентификатор SID (буква S всегда присутствует в текстовом представлении идентификатора SID), а цифры 1 и 5 представляют соответственно номер версии SID в Windows NT и код службы, создавшей этот идентификатор (в данном случае система безопасности Windows). Оставшаяся часть идентификатора представляет собой фактическое значение SID, включая число 500, которое показывает, что данный идентификатор принадлежит учетной записи администратора Windows. Идентификатор SID учетной записи «Администратор», которая создается по умолчанию (и которую нельзя удалить), во всех версиях Windows заканчивается на 500. Локальные учетные записи пользователей, добавляемые в Windows после установки, заканчиваются числами, большими 1000.
Программа PSGetSID из пакета Windows Sysinternals (о которой рассказывалось в моей статье, посвященной пакету PSTools, по адресу technetmagazine.com/issues/2007/03/DesktopFiles), позволяет получить идентификатор SID для указанного пользователя либо идентификатор SID системы. На рис. 1 приведены выходные данные программы PSGetSID — идентификатор SID моей виртуальной системы и идентификатор SID моей учетной записи, 1003.
Figure 1 Output of PSGetSID for a virtual system's SID and the SID of user account 1003
Figure 1 Output of PSGetSID for a virtual system's SID and the SID of user account 1003
Поскольку относительные идентификаторы локальных учетных записей создаются на основе данного идентификатора SID, проблема, возникающая при переносе системы путем дублирования диска или при копировании образа виртуальной машины, достаточно очевидна. Не изменив идентификатор SID (основная, но не единственная задача программы Sysprep), вы получите копию ключевого компонента, обеспечивающего уникальность системы Windows. Если система А и система Б имеют одинаковый идентификатор SID учетной записи «Администратор», пользователи каждой системы будут считаться одним и тем же пользователем. Тот же эффект будет иметь место для всех локальных учетных записей системы Б при проверке подлинности в системе А и наоборот. Хуже того, эти системы будут иметь одинаковый идентификатор SID в Active Directory®. Таким образом, если предоставить системе А доступ к ресурсу домена, но запретить это системе Б, произойдет конфликт. Если запретить доступ системе Б, доступ будет запрещен и системе А.
Таким образом, критически важно заново создать в системах идентификаторы SID с помощью программы Sysprep — особенно в случае использования виртуальных систем, поскольку образы систем легко распространяются. Не следует использовать для изменения идентификатора SID программы сторонних производителей — только Sysprep. Программа Sysprep предназначена для подготовки систем (даже виртуальных) к дублированию; эта программа разработана, протестирована и поддерживается корпорацией Майкрософт. На рис. 2 показано окно программы Sysprep перед изменением в системе идентификатора SID. Перед подготовкой системы к дублированию убедитесь, что флажок «Don't regenerate security identifiers» («Не восстанавливать идентификатор безопасности») снят.
Figure 2 "Don't regenerate security identifiers" should be unchecked when preparing for duplication
Figure 2 "Don't regenerate security identifiers" should be unchecked when preparing for duplication
Помимо замены идентификатора SID на новый идентификатор ID программа Sysprep также изменяет частные хранилища данных, использующие идентификатор SID и имя компьютера, либо настраивает их алгоритмы шифрования на использование нового идентификатора SID. Примерами таких хранилищ данных являются хранилище данных «Назначенные задания» и значения в метабазе служб IIS (если службы IIS установлены).
Программа Sysprep также принудительно удаляет из системы все сетевые платы и все данные о конфигурации сети для сетевых плат. Поскольку конфигурация сети для сетевой платы хранится в реестре и связана с сетевой платой по ее аппаратному идентификатору (который при клонировании реальных систем, скорее всего, изменится), программа Sysprep очищает эти ненужные данные.
Программа Sysprep также очищает все сведения о членстве системы в Active Directory. В результате работы программы система принудительно удаляется из домена. Это гарантирует, что системы, только что получившие новые идентификаторы SID, смогут присоединиться к домену. Некоторые служебные программы для изменения идентификатора SID позволяют изменить идентификатор SID компьютера, не удаляя компьютер из домена, но этот метод является ненадежным и небезопасным. Если программу Sysprep абсолютно точно необходимо запустить на компьютере, который входит в домен, тогда либо удалите компьютер из домена перед запуском Sysprep, либо запустите программу Sysprep и позвольте ей выполнить эту задачу самостоятельно.
Кроме того, при виртуализации любого контроллера домена необходимо дублировать системы, являющиеся автономными серверами, уровень которых не был повышен до уровня контроллера домена и которые не были присоединены к домену. Контроллер доменов можно безопасно дублировать, если он не работает под управлением операционной системы Windows Server 2003 Small Business Server Edition. Чтобы безопасно создать новый контроллер домена, необходимо создать образ диска сервера, подготовленного к присоединению к домену и повышению до уровня контроллера домена. Программа Sysprep (за исключением отличного от всех других систем Small Business Server с одним лесом и одним сервером), не позволяет безопасно изменить идентификаторы SID на контроллере домена.
Наконец, помимо изменения идентификатора SID и удаления компьютера из домена программа Sysprep также изменяет имя компьютера.
Возможно, это прозвучит жестоко, но перед созданием образа (и даже перед простым копированием) виртуальных систем обязательно следует выполнить все вышеперечисленные задачи. Это критично — особенно при использовании этих систем в сети с другими физическими или виртуальными системами, доменами или с собственными копиями.
Если при дублировании виртуальных систем не использовать программу Sysprep, это почти наверняка приведет к ряду очевидных проблем (проблемы с Active Directory и иные конфликты в сети) и ряду непредвиденных проблем. Например, виртуальные образы будут весьма неустойчивы к взлому, поскольку взлом одного образа автоматически означает взлом всех остальных.

Драйверы и слои абстрагирования оборудования (HAL)
Как было упомянуто выше, для виртуальных устройств на виртуальном образе может не быть «коробочных» драйверов для Windows. Перед развертыванием (и перед созданием образов дисков с помощью программы Sysprep) необходимо убедиться в наличии подходящих драйверов для устройств, поскольку катастрофическая ошибка драйвера 0x0000007B может произойти просто при переносе виртуального образа с одного драйвера хранилища на другой, как это возможно при работе с физическим оборудованием. То же самое касается сетевых плат. Хотя в большинстве программных продуктов для виртуализации используются практически универсальные устройства, для этих устройств все равно могут потребоваться дополнительные драйверы.
Также нельзя игнорировать слой абстрагирования оборудования (HAL). В идеале хотелось бы создавать виртуальные машины, поддерживающие многопроцессорные конфигурации с интерфейсом ACPI (см. статью intel.com/technology/iapc/acpi), если это поддерживается технологией виртуализации. Преобразование одного слоя абстрагирования оборудования (HAL) в другой в общем случае не поддерживается (дополнительные сведения см. в статье support.microsoft.com/kb/309283 ). Однако создатели некоторых технологий виртуализации — и, что более важно, технологий перехода — утверждают, что их программные продукты позволяют безопасно перенести систему Windows, установленную на компьютере без поддержки ACPI на компьютер с поддержкой ACPI и наоборот. Это не соответствует действительности, и вдобавок установленная таким образом система Windows не будет поддерживаться корпорацией Майкрософт в случае возникновения проблем. Те же ограничения, обсуждавшиеся на упомянутой выше веб-странице, действуют и для виртуализированных систем. На рис. 3 приведен пример слоя абстрагирования оборудования (HAL) в диспетчере устройств на одном из моих виртуальных компьютеров — в данном случае используется однопроцессорный слой абстрагирования оборудования с поддержкой ACPI. Пусть вас не смущает использование одного процессора, в данном случае слой абстрагирования оборудования можно заменить на многопроцессорный.
Figure 3 HAL in Device Manager on a virtual machine
Figure 3 HAL in Device Manager on a virtual machine

Различные изменения
Измените, что можно изменить, и примите как есть то, что нельзя изменить
При переносе физической системы на виртуальную и наоборот следует помнить о том, что можно и что нельзя изменить. Ниже перечислены аспекты Windows, которые можно изменить.
  • Слой абстрагирования оборудования (HAL) (можно изменять только однопроцессорный HAL на многопроцессорный и наоборот, если оба слоя используют одинаковую конфигурацию питания).
  • Контроллеры запоминающих устройств (это непросто — но большинство решений для перехода с физической системы на виртуальную пытаются сделать это собственными средствами). Обратите внимание на то, что большинство поставщиков предлагает решения на основе технологий IDE и SCSI. Необходимо сделать обдуманный выбор между этими двумя технологиями, поскольку переход с одной технологии на другую весьма сложен. Как правило, выбор технологии SCSI позволяет создать более надежное устройство (это случай с эмуляцией устройств SCSI большинства поставщиков).
  • Сетевая плата (в случае перехода с одной виртуальной системы на другую в рамках технологии одного поставщика, как правило, будет использоваться одно и то же устройство).
Ниже перечислены аспекты Windows, которые изменить нельзя.
  • Слой абстрагирования оборудования (HAL) (за исключением упомянутого выше случая, когда используется одинаковая конфигурация питания). Не следует думать, что система Windows, установленная с помощью решения для переноса системы, которое позволяет изменить HAL, будет работать стабильно и надежно (и, что более важно, такая система лишается поддержки корпорации Майкрософт).

Помимо изменения идентификатора SID и имени компьютера также необходимо изменить некоторые значения, специфичные для используемой технологии виртуализации. В частности, необходимо изменить MAC-адрес (уникальный идентификатор для сетевых устройств). Кроме того, многие приложения виртуализации также используют собственные уникальные идентификаторы. Большинство таких приложений хранят свои идентификаторы в файлах конфигурации, поэтому необходимо выяснить, как следует обращаться с этими записями (и поддерживать их допустимые значения). Имейте в виду, что многие программные продукты для виртуализации поддерживают протокол удаленной загрузки (PXE) на основе собственного уникального идентификатора SMBIOS — подчеркивая необходимость изменения этого идентификатора (также можно позволить программному обеспечению сделать это самостоятельно, если возможно) при присоединении к домену; в противном случае, управление клиентскими системами на основе службы развертывания Windows (WDS) или служб удаленного развертывания (RIS) может оказаться невозможным (в случае конфликта идентификаторов GUID). Большинство решений для виртуализации, с которыми мне приходилось работать, могут привести к серьезным проблемам с сетью в случае одинаковых MAC-адресов; поэтому во всех случаях, за исключением простого перемещения виртуальной машины, крайне важно изменить MAC-адрес, если программное обеспечение не делает этого самостоятельно.
Другие компоненты, о которых необходимо помнить при подготовке виртуальной системы к развертыванию, — это связанные диски и моментальные снимки. В зависимости от используемого решения виртуализации эти компоненты могут называться разностными дисками или иметь другое название. Однако если при использовании для подготовки системы программы Sysprep в виртуальной системе имеются моментальные снимки (или иные средства возврата в предыдущее состояние), их необходимо уничтожить, чтобы сделать образ безвредным, надежным и безопасным при дублировании. В случае наличия моментального снимка или аналогичного средства «отмены изменений», возврат в предыдущее состояние с помощью этого снимка может привести конфликту нескольких систем, созданных на основе одной исходной виртуальной машины (и даже к конфликту с исходной системой, если она тоже используется). По этим причинам все моментальные снимки и аналогичные средства должны быть обработаны программой Sysprep.

Оптимизация
Большинство технологий виртуализации включают дополнительные средства для повышения производительности и упрощения взаимодействия с гостевой системой из основной системы. Эти средства, как правило, оптимизируют работу мыши, клавиатуры и других компонентов и зачастую включают возможности копирования и вставки из буфера обмена (и иные средства взаимодействия основной и гостевой систем). Перед развертыванием установите в виртуальных системах последние версии этих средств.
Также необходимо обеспечить оптимальный для гостевой системы объем ОЗУ с учетом основной системы, в которой будет производиться развертывание. Худшее, что можно сделать, — это развернуть образ Windows XP, настроенный на использование 1 ГБ ОЗУ в системах с небольшим объемом ОЗУ.
Также необходимо помнить об ограничениях, накладываемых большинством современных технологий виртуализации — поскольку пользователям важно знать, каким образом будет осуществляться взаимодействие с периферийными устройствами, подключенными к виртуальным системам, а также какие приложения будут работать в гостевой ОС (большинство технологий не поддерживают, например, DirectX 9 и 10 либо обеспечивают ограниченную поддержку устаревших версий). Пользователи могут не знать о подобных проблемах и их проявлении (некоторые приложения неправильно обрабатывают подобные ситуации).

Вопросы, связанные с основной системой
Помните, что в общем случае не следует особо беспокоиться о конфигурации ПК, на котором установлено программное обеспечение для виртуализации, независимо от того, установлена на компьютере полнофункциональная операционная система или гипервизор (программа управления операционными системами) первого типа, запущенный непосредственно на оборудовании. Большинство технологий виртуализации спроектировано таким образом, что гостевой ОС не требуются никакие сведения (или требуется совсем немного сведений) об основной системе. Изучите конфигурацию используемых компьютеров, поскольку при переносе гостевой системы с одного компьютера на другой могут возникнуть проблемы. Также изучите ограничения, накладываемые конкретным программным продуктом для виртуализации на использование определенных платформ. Хотя гостевые системы можно переносить с одной платформы на другую, при переносе некоторые функции гипервизора второго типа (приложения для виртуализации) могут оказаться недоступными и наоборот.

Другие механизмы развертывания
Ссылки по программе Sysprep
В приведенных ниже документах содержится множество полезных сведений о программе Sysprep:
  • Установка операционных систем на основе образов с помощью программы Sysprep
  • Использование программы Sysprep для автоматизации процесса развертывания Windows XP
  • Дублирование диска с помощью средства подготовки системы (Sysprep.exe)
  • Использование средства подготовки системы на разнородных компьютерах

Использование программы Sysprep или дублирование диска (либо запуск программы Sysprep и копирование виртуальной машины) — самые очевидные способы развертывания виртуальных систем, но существует ряд других способов. Фактически, при использовании образов или программы установки для виртуализации гораздо проще воспользоваться Windows PE, чем физическими компьютерами, поскольку работа осуществляется с ISO-образами, а не физическим компакт-диском. Помните, что некоторые технологии виртуализации могут работать с DVD-дисками, поэтому узнайте у поставщика, поддерживает ли его продукт такую возможность. Также можно воспользоваться программой установки winnt32 (setup.exe для Windows Vista и Windows Server 2008), но это не дает никаких особых преимуществ. При использовании других технологий развертывания производства Майкрософт, например служб автоматического развертывания, технология виртуализации должна поддерживать протокол для развертывания по сети, как и при использовании служб RIS и WDS.

Перенос
Наконец, помимо фактического переноса ПК целиком, не следует забывать о средстве миграции пользовательской среды (USMT). Средство миграции пользовательской среды упрощает перенос параметров пользователя с физического клиента на новую виртуальную систему. Таким образом, если пользователям необходимо перенести свои данные и параметры на новую виртуальную машину, можно, например, взять файлы и параметры из операционной системы Windows XP, сохранить их в формат UNC и перенести на новую виртуальную машину.

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


 Заметки на полях: Перспективы взаимозаменяемости
Заметки на полях
Перспективы взаимозаменяемости
Роми Махаян (Romi Mahajan)

Карл Маркс писал в одном из своих трактатов, что «твердые тела испаряются», подразумевая меняющиеся отношения между социальными группами, возникшие с появлением индустриализации и капитализма в XIX веке в Европе. Это действительно очень глубокая идея о том, что различные разделения и категории не остаются в незыблемом, закостеневшем состоянии, а постоянно переигрываются во множестве форм и контекстов, особенно в мире технологий, где единственным постоянным фактором являются непрерывные изменения.
В этой быстро меняющейся отрасли нет лучшего примера высоких темпов изменений (и возникающих в связи с этим проблем), чем развитие потребительских технологий. Действительно, информационные технологии переориентировались на пользователей, и основные индикаторы изменений теперь напрямую связаны укладом жизни современных людей, оказывая большое влияние как на их профессиональную деятельность, так и на частную жизнь. Это явление проявляется в различных формах. Вот несколько примеров.
  1. Основные действия в мире Web 2.0 — это чтение и публикация данных в Интернете; причем публикации в Интернете являются максимумом того, что дозволено автору в качестве потребителя.
  2. Потребительские приложения и технологии создают для компании своеобразный гало-эффект.
  3. Основные магистрали Интернет планируются и тестируются вследствие потребительского перерождения информационных технологий.
  4. ИТ-подразделения, такие как службы поддержки, должны осуществлять планирование, взаимодействие с клиентами и обучение с учетом очень размытых границ между домашним и профессиональным применением технологий.
  5. Решения принимаются людьми, а эти люди — в такой же степени потребители, в какой они являются профессиональными работниками.
  6. Любимой технологией любого отдельно взятого человека, как правило, является потребительская технология, а не та, что ориентирована на профессиональную деятельность.
Эти выводы очень разумны, а категории пересекаются между собой. И это лишь несколько примеров. Один мой друг, работающий в высокотехнологичной компании, рассказал мне, что почти 8 процентов звонков в их службу поддержки связаны с обновлениями iTunes. Информационный бюллетень Cisco «The Exabyte Era (Эра экзабайта)» начинается с двух постулатов: что Интернет не задохнется под тяжестью трафика, создаваемого потоковым видео, и что YouTube это только начало. По данным отчета NDP Group корпорация Apple завоевала почти 10 процентов рынка сбыта мобильных компьютеров в течение марта 2007, и все это благодаря гало-эффекту iPod. Корпорация Майкрософт осуществляет широкие инвестиции в различные развлекательные области, такие как игры, музыка, цифровая фотография и размещение видео. И, наконец, современные компании проводят совещания в виртуальном мире Second Life.
Кроме того, крупнейшие технологические марки ушли в отрыв и прочно удерживают лидирующие позиции на рынке. Люди «гуглят» информацию, обсуждают айподы, «майспейсят» себя, играют в «Xbox®». Между людьми и используемыми ими технологиями устанавливается эмоциональная связь, воздействие которой соединяет для них работу с домом, дом с работой и вызывает у людей особое отношение к компаниям, создавшим эти устройства, приложения, веб-сайты и сообщества. Сформировавшись, такие отношения — хорошие, плохие или нейтральные — сосуществуют вместе с нами в личной жизни и в профессиональной деятельности.
Поэтому все, что относится к понятию личности, всегда не просто. И если компании стремятся одновременно решить ряд проблем связанных с масштабированием их почтовых систем, установлением более тесных взаимосвязей и проявлением заботы о клиентах, необходим фундаментальный культурный сдвиг. В прежнюю эпоху, до появления глубокой специализации по ролям, общие послания являлись основой маркетинга. В противоположность этому, в последние годы «прицельные» сообщения стали повальным увлечением, позволяя с лазерной точностью вычленять из общей массы потребителей отдельные категории, например по должностям, по сегментам аудитории, размерам компаний и специфическим технологиям. Но что действительно было упущено, так это осознание того факта, что, действительно, твердые тела — испаряются, а поэтому единственный способ добиться успеха на современном рынке — это найти подход к пользователю, учитывая его личностные и потребительские взаимосвязи.
Взаимозаменяемость означает возможность легкой замены, а значит не должно быть существенных различий между разными категориями. Говоря другими словами, нельзя больше возводить стены между тем, что предлагается потребителям для домашнего и профессионального использования. Потребительское перерождение информационных технологий уже стремительно происходит, и будущее — за взаимозаменяемостью.

Роми Махаян (Romi Mahajan) является директором по маркетингу в группе технического аудита и платформенного маркетинга в корпорации Майкрософт. Роми принадлежит множество публикаций в различных сферах, в том числе о политике, защите окружающей среды, технологиях и по социологии.


 Конфиденциальная информация Windows: Джойстику не нужно быть микроволновой печью
Конфиденциальная информация Windows
Джойстику не нужно быть микроволновой печью
Рэймонд Чен (Raymond Chen)

Недавно я посетил блог моего коллеги по прозвищу Audio Fool, и вспомнил об ошибке, которую я совершил много лет назад и которая до сих пор меня беспокоит. Во времена разработки интерфейса джойстика с силовой обратной связью DirectInput® корпорация Майкрософт пригласила производителей джойстиков в свою штаб-квартиру в Редмонде (штат Вашингтон), чтобы обсудить детали предложенного интерфейса и получить обратную связь от производителей (простите за невольный каламбур).
Во время этих встреч было выявлено множество проблем, но одна проблема, которая не дает мне покоя до сих пор, — это отсутствие соглашения относительно того, каким образом следует выражать периодические силы — через период или частоту. Один из присутствовавших на встречах производителей был против использования периода, поскольку его компания уже создала драйвер, в котором периодические силы были выражены в терминах частоты, и не хотела ничего менять. С учетом того, что целью встречи было прояснение деталей принципиально нового интерфейса, как мог производитель покинуть встречу и не внести изменения в драйвер?
Но этот производитель так много жаловался, что мы в конце концов сдались и согласились на использование частоты вместо периода для указания интенсивности периодических сил. В конце концов, это не имело особого значения. Сила с частотой десять колебаний в секунду эквивалентна силе с периодом в одну десятую долю секунды. Период и частота являются взаимно обратными величинами.
Однако это не совсем так. Период выражается в миллисекундах, что дает динамический диапазон от одной миллисекунды до 50 дней. Период в 50 дней слишком долог для человеческого восприятия, а период в одну миллисекунду слишком краток и воспринимается не как периодическое явление, а как музыкальный тон.
С другой стороны, частота выражается в герцах, что дает динамический диапазон от одного герца до 4 миллиардов колебаний в секунду. Не странно ли это, играть музыку на джойстике? А теперь представьте себе силы, действующие в микроволновом диапазоне!
Проблема заключается в том, что практически бесполезная выразительная сила в верхней части диапазона получается за счет урезания полезной нижней части диапазона. Оказывается, в пилотажных тренажерах интенсивно используются периодические силы со сравнительно долгими периодами. Мне неизвестные законы физики, лежащие в основе этого факта, но мне известно, что один из эффектов, с которыми приходится сталкиваться пилотам, — это периодическая сила, действующая на штурвал примерно раз в несколько минут. Самолет естественным образом движется по крайне медленно изменяющейся вертикальной синусоиде, а пилотам приходится противодействовать этой силе, чтобы поддерживать горизонтальный полет. Если бы интенсивность силы была выражена через период, в программе пилотажного тренажера пришлось бы использовать период в 120000 миллисекунд. Однако частота составила бы всего 0,0083 герца, что намного меньше самого малого значения частоты, которое можно использовать в интерфейсе драйвера — а именно 1 Гц. Следовательно, самая медленная сила, которую можно смоделировать в пилотажном тренажере, — это сила, повторяющаяся каждую секунду, что довольно быстро по сравнению с физическим эффектом, который необходимо имитировать пилотажному тренажеру.
Поскольку эта проблема продолжала беспокоить меня на протяжении всех последних лет, я решил заглянуть в документацию по силовой обратной связи. К моему удивлению, оказалось, что в структуре DIPERIODIC для выражения периодических эффектов используется период, а не частота. (Кроме того, в качестве единицы измерения используется микросекунда, что позволяет и играть музыку, и летать на самолете). Либо ошибка была исправлена, либо я старею и память сыграла со мной злую шутку. В любом случае, я могу не беспокоиться больше об этой ошибке — даже если ее никогда и не было.

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