Exchange 2010 SP1: не просто обновление

Познакомившись с пакетом обновления Microsoft Exchange Server 2010 SP1, я был, признаться, озадачен. Вообще такая реакция для меня нехарактерна, и, видимо, все дело здесь в меняющихся представлениях о том, что именно Microsoft включает и чего не включает в состав пакета обновления. Раньше пакеты обновлений состояли из набора исправлений ошибок для повышения надежности и устойчивости программного обеспечения. Иногда в них включали и новые средства, но чаще всего без удобного графического интерфейса пользователя, так что подобными инструментами приходилось управлять посредством изменения настроек реестра или других ухищрений системных администраторов. .

Не слишком ли много функций?

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

• тонко настраиваемая репликация групп доступности базы данных Database Availability Groups (DAG);
• локализация неисправностей внутри хранилища данных;
• вновь обретенная способность исправлять мелкие логические повреждения баз данных почтовых ящиков и общедоступных папок с помощью специальных команд (раньше эта проблема решалась с использованием утилиты Isinteg);
• возможность разделения почтовых ящиков пользователей и их персональных архивов по различным базам данных;
• новые составные команды, предназначенные для импорта и экспорта содержимого почтовых ящиков без необходимости установки программы Outlook на сервере Exchange;
• полностью обновленный интерфейс пользователя для веб-клиента Outlook (OWA);
• возможность управления политиками хранения и тегами силами администраторов с помощью графической консоли управления Exchange Exchange Management Console (EMC);
• многие другие средства, реализованные в панели управления Exchange Control Panel (ECP), включая средства реализации политик именования групп, управления ролями и назначения ролей, а также назначения ролей, необходимых для функционирования модели разрешений Role Based Access Control (RBAC) системы Exchange;
• возможность ограничения диапазонов RBAC базами данных;
• определение приоритетов сообщений и более эффективная балансировка нагрузки на серверы SMTP после перебоев в работе;
• иерархические адресные книги;
• способность программы установки разворачивать программные компоненты, необходимые для функционирования продукта, а также применять разделенные разрешения на обращение к AD.

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

В совокупности упомянутые средства представляют собой весомое дополнение к существующим возможностям Exchange 2010. И в самом деле, сегодня Exchange содержит такое богатство функций, что мне вспоминаются похожие критические замечания в адрес приложений пакета Office. Критики недоумевали, зачем Microsoft наделяет все новыми средствами продукты, которые и без того, что называется, ломятся от избытка функций, часть из которых представляет интерес лишь для немногих пользователей. Возможно, мы достигли того этапа, когда наличие двух версий — Exchange Standard и Exchange Enterprise — уже не обеспечивает достаточной дифференциации для всех рынков, где продаются системы Exchange, и в продаже появятся такие версии, как Exchange «проще некуда», Exchange «чуть посложнее», Exchange «сложная» и Exchange «во всем великолепии». А может быть, генеральный план Microsoft состоит в том, чтобы оснастить Exchange таким количеством функций, что все мы перейдем на использование служб из центров обработки данных Microsoft Business Productivity Online Standard Suite (BPOS)?

Клиент OWA: мощный, умный и прекрасный

В версии Exchange 2010, выпущенной в 2009 году, пользовательский интерфейс клиента OWA был весьма продуктивным, и для его освоения никому из пользователей не приходилось ломать голову. А значит, задача разработчиков состояла в том, чтобы усовершенствовать OWA, но не за счет его эффективности. Специалисты корпорации уделили клиенту много внимания и, как показано на экране 1, две версии разительно отличаются друг от друга. Ряд отличий можно наблюдать, что называется, невооруженным глазом.

Экран 1. Сопоставление пользовательского интерфейса OWA в Exchange 2010 RTM (вверху) и Exchange 2010 (внизу)

• В продукт вновь были включены выбираемые пользователем темы. Мне лично больше всего нравится показанная на экране 1 тема Herding Cats. Окончательная версия будет содержать по меньшей мере 25 других тем, так что у вас будет из чего выбрать. Кроме того, Microsoft теперь официально поддерживает заказчиков, которые хотят снабдить клиенты OWA своими корпоративными брендами, значками и цветными композициями.
• В клиентах OWA используются более крупные гарнитуры шрифтов, что повышает различимость информации и ее доступность. Выбранный элемент более заметен и теперь снабжен отметкой «галочка», указывающей на его состояние.
• Усовершенствован механизм навигации. Сотрудники Microsoft, выполнявшие разработку пользовательского интерфейса, полагают, что сумели лучше, чем прежде, организовать экранную площадь и разместить на ней больше данных. Разумеется, самый важный вопрос — хорошо ли работает пользовательский интерфейс. Могу сообщить, что SP1-версия OWA выглядит лучше и функционирует быстрее, чем предыдущие версии — по крайней мере, по моему мнению. Улучшения достигнуты за счет введения цепочек ссылок, которые показывают пользователю, где он находится в данный момент и как сюда попал, а также за счет применения переработанных значков для обозначения важных функций, таких как Reply. Последнее изменение было реализовано потому, что, как показали результаты тестирования, пользователи совершали ошибки, именно отвечая на сообщения. Некоторые, не относящиеся к числу необходимых элементы, такие как значок Exchange в верхней части почтового ящика, удалены, чтобы упорядочить интерфейс.
• Всплывающие уведомления, извещающие пользователя о предстоящих встречах, другие напоминания или извещения о новых сообщениях стали более заметными.

Как показано на экране 2, в SP1-версию клиента OWA включены и некоторые типичные функции, такие как возможность изменения пароля, позволяющая пользователю корректировать настройку, продолжая работать в OWA и не переходя для этого на панель ECP. Это изменение непринципиальное, простое, но эффективное.

Экран 2. Новые настройки, которые можно изменять в OWA

Детальная репликация

В версии Exchange 2010 появились группы доступности базы данных (DAG). DAG — это конструкция, основанная на репликации транзакционных данных с серверов почтовых ящиков, на которых находятся активные копии баз данных (то есть копии, к которым в данный момент подключены клиенты), и с других серверов почтовых ящиков в группе DAG, содержащей пассивные копии баз данных. Служба репликации Microsoft Exchange обеспечивает репликацию данных между этими серверами, а также воспроизведение данных в пассивные копии, чтобы они всегда были синхронизированы с активными базами данных и могли использоваться в случае необходимости перехода на другой ресурс.

Exchange 2010 реплицирует транзакционные данные на основе журналов транзакций емкостью в 1 Мбайт. Когда журналы закрываются на активном сервере, они реплицируются, проверяются и воспроизводятся на пассивных серверах. Репликация с тонкой настройкой, или блочная репликация, — это новая функция, обеспечивающая минимизацию задержки между транзакцией, выполняемой в активной базе данных, и процессом ее копирования и воспроизводства в копии базы данных. Идея состоит в том, что при ускорении репликации снижается риск потери данных в случае сбоя в период между генерированием журнала транзакций и его копированием. В этом отношении журнал транзакций можно рассматривать как потенциальную единственную точку отказа, которой разработчикам Exchange нужно было заняться для обеспечения по-настоящему высокой степени готовности.

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

1. Все репликации начинаются в файловом режиме, и завершенные журналы транзакций копируются с активных серверов на пассивные. Когда сервер подключается к сети, он вступает в контакт с серверами, на которых размещаются активные копии его баз данных, и направляет запрос на репликацию всех поколений журналов, с которыми он «не знаком».
2. Серверы, содержащие активные базы данных, отвечают копиями всех незавершенных журналов.
3. Сервер воспроизводит журналы и актуализирует свои копии баз данных.
4. Когда копия базы данных является актуальной (то есть когда необходимым для нее журналом транзакций является текущий журнал), Exchange может переходить в блочный режим.
5. Когда при работе в блочном режиме транзакции записываются в буфер журнала расширенного обработчика хранилищ ESE (то есть в кэш объемом 1 Мбайт, используемый для аккумулирования транзакций, которые будут фиксироваться в журнале транзакций), модуль копирования журналов копирует эти данные параллельно на все серверы, включающие копию базы данных. На этих серверах упомянутые данные копируются в аналогичный буфер журнала.
6. Когда буфер журнала на принимающих серверах заполняется, содержимое полного буфера переписывается в виде журнала транзакций. Новый журнал проверяется на предмет наличия в нем повреждений, и в случае успешного прохождения испытаний включается в поток журналов, которые будут записываться в пассивные базы данных.
7. Репликация продолжается в блочном режиме до тех пор, пока на сервере не формируется очередь воспроизведения, состоящая из четырех журналов. В этот момент Exchange автоматически возвращается в файловый режим, и репликация продолжается в этом режиме до момента исчезновения очереди, то есть до того времени, когда требуемым журналом опять становится текущий журнал транзакций. После этого Exchange вновь возвращается в блочный режим.

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

Отдельная транзакция может уместиться на одной 32-килобайтной странице базы данных. Понятно, что новые данные попадают на серверы, где размещаются копии баз данных, быстрее, если программе копирования журналов приходится ждать передачи (а затем и копировать) не завершенный журнал транзакций на 1 Мбайт, а всего лишь страницу объемом в 32 Кбайт. Этот выигрыш не столь заметен при передаче транзакций, сгенерированных объемными сообщениями, ибо в таких случаях требуется репликация нескольких журналов транзакций. Однако достаточно компактные транзакции умещаются на одной странице, и благодаря этому блоковая репликация считается весьма привлекательной, ибо она позволяет резко сокращать совокупную задержку репликации.

Новые команды импорта и экспорта

Сразу же после выхода версии Exchange 2010 в сообществе пользователей Exchange начались разговоры о необходимости выполнения на сервере почтовых ящиков Exchange 2010 64-разрядной версии приложения Outlook 2010 — для обеспечения возможности использования составных команд Import-Mailbox или Export-Mailbox с целью экспорта данных PST. Способность этих команд, применяемых также в среде Exchange 2007 для работы с данными PST, обеспечивается клиентским MAPI-провайдером Outlook. Эта проблема в значительной степени объясняется несогласованностью действий групп инженеров Microsoft, разрабатывавших системы Exchange и Outlook. 64-разрядная версия Outlook появилась лишь по прошествии шести месяцев после выхода в свет версии Exchange 2010.

К счастью, с появлением пакета Exchange 2010 SP1 команды Import-Mailbox и Export-Mailbox отошли в прошлое. Их место занял новый механизм, созданный в соответствии с моделью, которая применяется при перемещении почтовых ящиков. В отличие от старых команд, в основе которых лежала библиотека MAPI Outlook, эти новые команды базируются на библиотеке нового модуля записи PST, написанной группой разработчиков Exchange, поэтому импорт из PST, а также экспорт в PST можно осуществлять без предварительной установки на одном из серверов Exchange кода Outlook.

В версии Exchange 2010 SP1 и в последующих версиях управление запросами на импорт и экспорт будет осуществляться с помощью новых команд New-MailboxImportRequest и New-MailboxExportRequest, поэтому, если вы намереваетесь запускать сценарии с использованием старых команд на сервере Exchange 2010 SP1, вам придется вносить в такие сценарии соответствующие изменения. Прежние команды можно, разумеется, и впредь использовать на серверах Exchange 2010 RTM и Exchange 2007.

Как и запросы на перемещение почтовых ящиков, запросы на осуществление операций по импорту и экспорту сначала помещаются в очередь, а затем выбираются для обработки с помощью экземпляра службы репликации почтовых ящиков Mailbox Replication Service (MRS), который выполняется на сервере клиентского доступа в узле, где были созданы эти запросы. Запросы обрабатываются асинхронно в фоновом режиме. Служба MRS может импортировать данные в почтовые ящики любой базы данных или экспортировать данные из любого почтового ящика внутри своего узла. Для облегчения осуществления операций по импорту/экспорту почтовых ящиков все PST, в которых MRS осуществляет операции чтения или записи, должны быть размещены на общем файловом ресурсе, открытом для серверов клиентского доступа. Такие файловые ресурсы защищаются от просмотра лицами, не имеющими на то полномочий. Доступ предоставляется только доверенной подсистеме Exchange; для осуществления экспорта требуется доступ для чтения и записи, для выполнения операций импорта — только для чтения. При осуществлении всех экспортных операций генерируются PST в формате Unicode, хотя в ходе импорта Exchange может считывать данные PST как в старом формате ANSI, так и в формате Unicode.

Рассмотрим пример использования команды New-Mailbox ImportRequest. Допустим, нам нужно импортировать PST с именем Redmond.pst в почтовый ящик Redmond. PST расположен в общей папке \\ExServer44\Imports. Используйте следующую команду:

New-MailboxImportRequest
   -Mailbox Redmond -FilePath
   '\\Exserver44\Imports\Redmond.pst'
   -ConflictResolutionOption
   KeepLatestItem
   -BadItemLimit 5

Параметр -ConflictResolutionOption указывает на то, что мы намерены сохранять новейшие версии любых дублирующих объектов, попадающихся в процессе импорта (дубликаты выявляются с помощью идентификатора сообщений), и что лимит на число неправильных элементов имеет значение пять; это означает, что Exchange может обнаружить до пяти поврежденных или по иным причинам не поддающихся прочтению элементов и при этом довести операцию импорта до завершения. Повреждение элементов может объясняться многими причинами, например ошибками при указании свойств или при написании кода. Наконец, элемент может быть попросту очень старым. В ходе тестирования системы Exchange 2010 SP1 мне пришлось столкнуться с рядом интересных проблем при импорте старых объектов, созданных на сервере Exchange 4.0 еще в 1996 году.

Следующий пример показывает, что при экспорте данных используется сходный синтаксис:

New-MailboxExportRequest
   -Mailbox 'Jim Smith'
   -BadItemLimit 5-FilePath
   ‘\\ExServer44\Exports\JSmith.pst’

Данные из общих папок нельзя импортировать и экспортировать с помощью команд импорта/экспорта; такие данные необходимо предварительно пропустить через почтовый ящик. Объекты можно копировать из общей папки в PST с помощью программы Outlook, а затем импортировать их из PST в другой почтовый ящик.

Отказ от требования устанавливать Outlook на серверах почтовых ящиков Exchange представляет собой большой шаг вперед. Но что еще более важно, реализованный в версии SP1 новый механизм запросов на импорт и экспорт почтовых ящиков намного превосходит по богатству функциональных возможностей предшествующие составные команды. Единственное недостающее звено в данном механизме — отсутствие мастера, который позволял бы выполнять эти задачи из консоли EMC; специалисты Microsoft не успели завершить эту работу к моменту выпуска SP1, так что вам придется выполнять все задачи по импорту/экспорту почтовых ящиков с помощью служб EMS.

Помните, что перед тем как вы сможете импортировать и экспортировать данные почтовых ящиков, вам нужно наделить свою учетную запись ролью Mailbox Import Export. По умолчанию эта роль не назначается ни одной учетной записи, в том числе и записям, обладающим ролью Organization Management. Поэтому для назначения данной роли пользователям или группам, которые будут выполнять эти операции, требуются особые действия со стороны администраторов. Логика в данном случае такова: доступ к почтовым ящикам нужно рассматривать в контексте обеспечения безопасности данных и предоставлять его лишь тем пользователям, которым действительно требуются разрешения для импорта данных в почтовый ящик другого сотрудника или для экспорта данных из чужого почтового ящика. Сказанное справедливо и для исходной версии Exchange 2010, поскольку нужно, чтобы роль Mailbox Import Export могла использовать команды Import-Mailbox и Export-Mailbox или запускать мастер консоли EMC с целью импорта либо экспорта данных почтовых ящиков.

Политики и теги хранения

Средства управления записями сообщений Messaging Records Management (MRM) были реализованы специалистами Microsoft в версии Exchange 2007. Они были разработаны с тем, чтобы помочь пользователям управлять операциями сохранения электронной почты, но уже скоро стало ясно, что это нововведение было встречено пользователями без всякого энтузиазма. Для работы со средствами MRM пользователи, желающие сохранить те или иные объекты, должны переместить их в специальные управляемые папки. Между тем, как известно любому администратору, пользователи не относятся к категории людей, охотно выполняющих пожелания других, особенно когда они видят, что выполнение просьбы означает для них необходимость приложить дополнительные усилия и не сулит при этом особых выгод.

Стало очевидно, что сообщество сможет принять систему MRM лишь в том случае, если она будет в большей степени автоматизирована и если в ее функционировании для администраторов будет зарезервирована более важная роль. Разработчики Exchange 2010 отвергли идею управляемых папок и развернули новую систему тегов и политик хранения. Теги хранения присоединяются к объектам с тем, чтобы задать объекту период хранения (скажем, 30 дней) и указать действие, которое помощник для управляемых папок Managed Folder Assistant должен выполнить по истечении срока хранения. Этот помощник (возможно, теперь его было бы правильнее называть «помощником по вопросам хранения») представляет собой процесс, выполняемый в фоновом режиме. Версия SP1 и здесь отходит от установившегося порядка, поскольку помощник выполняется постоянно, а не в ограниченный период обслуживания. Идея состоит в том, чтобы рабочая нагрузка обрабатывалась по мере поступления заданий и чтобы администраторам не приходилось дожидаться начала периода обслуживания, когда станет возможной активация политик хранения.

Тег может относиться к одной папке, например к папке «Входящие» или ко всем папкам. Поддерживается целый диапазон возможных действий — от удаления объекта без возможности восстановления до перемещения в папку «Удаленные объекты» или в архив. Политики хранения объединяют теги в удобные наборы, которые можно назначать почтовым ящикам.

По идее это неплохая система, но в среде Exchange 2010 она реализована с некоторыми упущениями. Дело в том, что система функционирует при участии администраторов, которые должны с помощью EMS создавать теги и политики хранения, а также управлять ими. Конечно, это не такая уж сложная задача, если вы найдете возможность исследовать все особенности составных команд и их параметров, но кто сможет выделить время на изучение различных тонкостей поведения, скажем, команды New-RetentionPolicyTag?

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

Экран 3. Отображение тегов политики хранения в окне EMC

После того как политика хранения применена к почтовому ящику, помощник для управляемых папок применяет содержащиеся в политике теги хранения к объектам, размещенным в этом ящике, в ходе следующей операции по его обработке. И теперь уже пользователи могут увидеть эффект тегов хранения с четкими указаниями в окнах клиентов OWA и Outlook 2010. На экране 4 представлено отображенное в OWA электронное послание с примененной к нему политикой хранения. Здесь видно, что период хранения для тега на объекте составляет 14 дней, по истечении которых данный объект будет вновь обработан средствами помощника для управляемых папок, и затем будет выполнено действие, указанное в теге.

Экран 4. Воздействие тега хранения на электронное послание OWA

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

Убедить пользователей самостоятельно очищать свои папки, такие как Sync Issues или RSS Feeds (не говоря уже о папке «Входящие»), — это задача, решить которую не удастся никогда. Но стоит применить соответствующую политику хранения, и почтовые ящики пользователей будут очищаться автоматически. Несомненно, у многих такой поворот событий вызовет своего рода «культурный шок» — ведь буквально на их глазах из почтовых ящиков будут исчезать те или иные объекты, — но, может быть, это поможет всем нам научиться вовремя расставаться с лишними сообщениями в своих почтовых папках.

Управление доступом на основе ролей (RBAC)

Исследуя средства RBAC, реализованные в системе Exchange 2010 RTM, многие администраторы внутренне содрогаются. И в самом деле, не так-то просто перейти от ранее применявшейся в Windows модели, основанной на списках управления доступом, к системе, базирующейся на ролях, назначении ролей, ролевых группах и политиках. И дело не в том, что модель RBAC неэффективна — как раз наоборот. Важно другое: практически всю работу средствами RBAC приходится выполнять с помощью EMS, в то время как не каждый администратор хорошо знаком с командами этой оболочки. В данной ситуации, напоминающей переход от локальной среды PowerShell (в которой сеансы проводятся на том же компьютере, где выполняются команды) к удаленной среде PowerShell (в которой все сеансы канализируются через сервер Microsoft IIS — даже в тех случаях, когда команды выполняются на локальном компьютере), переход к модели RBAC сопряжен с более серьезными трудностями, чем можно было бы ожидать.

Пакет SP1 не в состоянии компенсировать пробелы в знаниях администраторов, но он может предложить графический интерфейс, способный защитить администраторов от хитросплетений механизма RBAC, и именно такой интерфейс был реализован в модернизированном разделе Roles в ECP. То обстоятельство, что Microsoft в качестве платформы управления для RBAC выбрала не консоль EMC, а панель ECP, у некоторых может вызвать удивление. Разумеется, в качестве контраргумента можно выдвинуть тезис о том, что EMC — заповедная зона действий администраторов Exchange, но рассуждать так — значит игнорировать выгоды, связанные с предоставлением функциональных возможностей через веб-приложение, которое может запускаться с любого компьютера, поддерживающего браузеры Internet Explorer (IE), Chrome или Firefox. И действительно, в дополнение к средствам управления RBAC панель ECP включает в себя такие функциональные возможности, как доставка отчетов отсутствующие в EMC, что указывает на дифференциацию в выборе инструментов, существующую, по крайней мере, в умах разработчиков Microsoft, если не в умах реальных администраторов.

Многие из самых типичных сценариев взаимодействия администратора со средствами RBAC сегодня можно реализовать посредством ECP. Как явствует из экрана 5, ECP дает администраторам возможность с легкостью совершенствовать роли, назначенные группам ролей, доставленные с помощью Exchange, и создавать собственные группы ролей, а также назначать их пользователям. Пока что некоторые операции в рамках RBAC — такие, как замена назначения роли специализированной ролью в применяемой по умолчанию политике назначения ролей, — пользователям приходится выполнять с помощью EMS, но с появлением пакета SP1 работа с системой RBAC существенно упрощается.

Экран 5. Работа с ролями RBAC средствами ECP

Приятно сообщить и о том, что в ECP впервые представлен набор новых функций для SP1. Теперь мы можем с помощью ECP приостанавливать сохранение содержимого почтовых ящиков или сохранять находящиеся в них данные для возможного применения последних в дальнейшем в ходе судебных разбирательств; мы можем управлять политиками для поддерживающих ActiveSync устройств. Кроме того, в одном из разделов представлены заранее подготовленные отчеты для данных, собранных с помощью функции аудита почтовых ящиков. Наконец, надо сказать, что ECP — это интерфейс, с помощью которого создаются политики именования групп для организации, а это еще одна функция, не представленная в EMC.

Больше, чем пакет обновлений

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

Тони Редмонд (exchguru@windowsitpro.com) — редактор журнала Windows IT Pro, старший технический редактор Exchange & Outlook Administrator, вице-президент и главный технолог HP Services