Эта ситуация наверняка знакома многим: после очередного выпуска Microsoft Exchange Server представители компании-производителя поднимают невероятный шум, извещая всех о том, что на свет появился продукт, не знающий себе равных, и что ваша система мгновенного обмена сообщениями — а значит, и вся ваша компания — без него не сможет уцелеть в бурном море бизнеса. При этом вы, разумеется, знаете, что это не так. Более того, внимательно приглядевшись к новой версии (пусть это будет, к примеру, Exchange Server 2010), вы, вероятно, обнаружите, что есть вопросы, которые остаются без ответа, что в условиях конкретной сети у нового продукта не во всем концы сходятся с концами и что есть вещи, удерживающие вас от того, чтобы посоветовать своим специалистам немедленно отправить на свалку ныне эксплуатируемые системы, которые, кстати, превосходно справляются со своими обязанностями.

.

Какой путь модернизации с версий Exchange 2003 или Exchange 2007 вы рекомендуете? И почему не предусмотрена возможность обновления на месте? Судя по откликам читателей, это обстоятельство вызывает у них разочарование.

Да, я понимаю. Одна из главных причин, в силу которых мы не предусмотрели обновление на месте в этой версии, состоит в том, что мы значительно изменили схему баз данных почтовых ящиков. Мы особо об этом не распространяемся, но дело в том, что многие усовершенствования в отношении ввода-вывода были реализованы как раз благодаря изменению схемы баз данных. А это, в сущности, означает, что для перевода почтовых ящиков на новую версию их надо перемещать из одной базы данных в другую. Вот вам одна из причин, побудивших нас отказаться от обновления на месте.

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

Да, я видел объявление об этом в блоге разработчиков Exchange.

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

Выдерживают ли средства архивации, реализованные в Exchange 2010, сравнение с изделиями от независимых поставщиков? С какой целью вы включали в состав продукта такие средства?

Первоначально мы решили включить их в состав продукта для того, чтобы наши пользователи Exchange вновь получили возможность управлять с помощью средств Exchange всеми данными файлов PST (которые доставляют немало хлопот). То есть, если смотреть на проблему глазами пользователей, у них появляется некое единое место, где они могут получить свои данные. А с точки зрения администраторов, появляется единый набор инструментальных средств, с помощью которых можно управлять данными. Мы знаем, что порядка 80% наших клиентов, эксплуатирующих Exchange, вообще не пользуются программами архивирования: как правило, они ограничиваются работой с файлами PST. И в самом деле, персональный архив — это возможность поместить такие данные в Exchange и работать с ними в управляемой среде.

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

Какие отзывы об этой функции получили вы от первых пользователей и от участников программы Technology Adoption Program (TAP)?

Представители ряда организаций, первыми приступивших к работе с продуктом, познакомились с этой функцией и высказались в таком духе: «Это именно то, что нам нужно». Все понятно — они хотят, чтобы данные вернулись в Exchange и чтобы пользователи могли обращаться к ним максимально просто. Наверное, только время покажет, многие ли будут использовать эту функцию, но ведь мы впервые реализуем ее в своем продукте. И уже поступило много откликов о том, насколько проста она в использовании и в управлении.

У вас уже есть какие-то идеи относительно того, каким образом вы будете использовать или совершенствовать эту функцию в будущих версиях Exchange?

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

Одно наиболее интересных нововведений Exchange 2010 — это группа доступности базы данных (DAG). Администраторы Exchange, работая с предыдущими версиями системы, стали знатоками в области кластеров Exchange. Что им следует знать, чтобы быстро освоить группы DAG?

Это нововведение, в сущности, отражает эволюцию концепции непрерывной репликации, реализованной нами в Exchange 2007. Вспомните CCR и SCR (непрерывная репликация кластера и резервная непрерывная репликация). Те, кто знаком с таким способом сохранения актуальности копии базы данных с помощью доставки журналов, могут использовать многие из этих принципов — они все еще применимы. Но есть одно важное отличие: теперь все происходит на уровне базы данных. Другое направление нашей работы: мы сочетаем в одном решении репликацию onsite и offsite. Система масштабируется и может включать в себя до 16 серверов, а это значит, что можно конфигурировать до 16 копий каждой базы данных. И, поскольку переход на другой ресурс осуществляется на уровне базы данных, время переключения сокращается до 30 секунд или даже менее того.

То есть с концепциями пользователи будут более или менее знакомы — если разбираются в системе Exchange 2007, но с точки зрения развертывания мы все заметно упростили. Сейчас мы пользуемся моделью инкрементного развертывания, которая существенно отличается от того, что было в предыдущих версиях Exchange. Если прежде нужно было сначала создать кластер и провести всю подготовительную работу, то теперь администратору требуется только создать базу данных почтовых ящиков Exchange. Затем он может создать группу DAG, добавить к ней службу и формировать копии базы данных, когда в них возникнет необходимость. И все эти административные действия выполняются с помощью инструментальных средств управления Exchange.

Мы приложили большие усилия, чтобы максимально облегчить работу администраторов. Клиенты, с которыми мы обсуждали тему групп DAG, рассказывают, что относятся к таким группам с энтузиазмом, потому что, как они говорят, «все это мне по силам, в этом нет ничего сложного, при необходимости я вполне смогу реализовать такую штуку в своей сети». Отмечу, что это не такое решение, которое нужно заблаговременно планировать в полном объеме. Вдобавок, и это в первую очередь относится к небольшим компаниям, а также к компаниям, размещенным в небольших зданиях, сегодня можно размещать все роли Exchange на серверах с высоким уровнем доступности, и вы можете разместить эту систему Exchange высокой степени доступности всего на двух серверах. И еще одно: если раньше высокой степенью доступности отличалась редакция Exchange Enterprise, то теперь такая степень доступности заложена и в редакцию Standard. Мы думаем, что это будет большим подспорьем средних и малых компаний.

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

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

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

Несомненно, с появлением в Exchange 2010 таких возможностей, как группы DAG и персональные архивы, изменятся требования к организациям Exchange в плане хранения данных. Как могут администраторы Exchange рассчитывать объемы массовой памяти, необходимые для развертывания системы Exchange 2010?

О, мы приготовили для них калькулятор! У нас и раньше был компонент Exchange Storage Calculator. Но сейчас мы выпустили его обновленную версию, которую назвали Exchange 2010 Mailbox Server Role Requirements Calculator. И название было изменено потому, что это изделие выполняет не только задачи расчета объема необходимой памяти. К примеру, вы предоставляете программе сведения о том, каков масштаб вашей организации, какие объемы информации должны храниться в почтовых ящиках, и другие сведения подобного рода, а калькулятор выдает такие результаты: конфигурация вашей базы данных почтовых ящиков, сведения о том, как будут генерироваться журналы транзакций, каковы требования к памяти и к процессорам серверов почтовых ящиков, какова рекомендуемая архитектура хранилища. Причем, если мы говорим о конфигурации высокой степени доступности, система сообщит вам, сколько имеется активных баз данных в расчете на сервер. К примеру, если у вас произошел один отказ, тогда на один сервер будет приходиться столько-то активных баз данных, а если два отказа — этот показатель увеличивается до соответствующего числа активных баз данных на сервер. Так что это будет превосходный инструмент, особенно для более крупных сетей. Он сможет рассчитывать требования как к ресурсам хранения данных, так и к серверам почтовых ящиков.

И этот инструмент можно бесплатно загрузить в Интернете?

Совершенно верно.

Скажите, по каким критериям производится выбор одной из систем хранения данных в Exchange, таких как сеть устройств хранения данных или система с прямым подключением? Дает ли калькулятор свои рекомендации по этому вопросу?

В программе калькулятора вы указываете, какой тип дисков хотели бы использовать. Программа действительно дает рекомендации, особенно относительно того, какие массивы дисков следует использовать — RAID или JBOD. Дело в том, что в случае применения JBOD мы выдвигаем ряд дополнительных требований, например необходимо иметь по несколько копий баз данных. Если у вас имеются копии баз данных с задержкой воспроизведения (lagged copies), мы рекомендуем задействовать JBOD, при условии что на одном узле присутствуют две копии с задержкой воспроизведения. Калькулятор поможет вам в принятии такого рода решений. Он пригодится и при проведении сравнительного анализа, чтобы определить, сколько дисков вам потребуется.

С выходом версии Exchange 2010 облегчается процесс применения различных политик сохранения. Что именно в этом продукте поможет ИТ-специалистам сэкономить время и нервы? Ведь людям, которые привыкли пользоваться методом управляемых папок, применявшимся в Exchange 2007, предстоит столкнуться с большими изменениями. К тому же вы дополнительно реализовали функцию, позволяющую конечным пользователям добавлять собственные политики хранения, а это может осложнить весь процесс управления.

Я могу рассказать вам, как мы сделали эти политики хранения чуть более удобными для пользователя. Одна из самых серьезных проблем, с которыми сталкиваются пользователи, когда им приходится работать с управляемыми политиками, связана с тем, что им неизвестно, когда истекает срок хранения того или иного сообщения. А это необходимо знать, чтобы поместить его в нужную папку. Так вот, одно из усовершенствований, реализованных в версии 2010, состоит в том, что теперь вы можете посмотреть на электронное сообщение, и оно известит вас не только о том, какая политика была применена, но и о том, когда истекает срок хранения данного сообщения.

Очень удобная функция.

Да. Вы получаете наглядную информацию о том, что произойдет. Я думаю, что эта функция сама по себе развеет некоторые опасения пользователей. Наверное, многие пользователи не будут сами применять пользовательские политики. Они посмотрят, что сделал администратор, и скажут: «Смотри-ка, здорово. Во всяком случае, я знаю, что будет дальше».

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

А могут администраторы лишить пользователей возможности формулировать политики?

Да, могут. Если администраторы не публикуют политики, которые могут применять пользователи, тогда пользователи не могут создавать свои политики.

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

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

Так, картина проясняется. Выходит, пользователь не может взять и сформулировать собственную политику?

Нет, пользователи могут только применять политики, полученные от администратора. В результате они получают определенную степень контроля, но карт-бланш — право поступать, как им заблагорассудится, — пользователям не предоставляется.

Похоже, что управление доступом на основе ролей (RBAC) — это действительно эффективная модель предоставления разрешений, но некоторых наших читателей охватывает беспокойство: не будет ли она слишком сложной в использовании? Что им следует знать, чтобы быстро освоиться с этой моделью? Какие преимущества дает RBAC администраторам?

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

С ролевой группой обычно ассоциируется целый ряд ролей. Речь идет о таких ролях, как discovery management, UM management, server management или Help Desk. В части панели управления Exchange мы обеспечили действительно простой в применении интерфейс, который администраторы могут применять для связи пользователя или группы с одной из ролевых групп, и, как только эти объекты прикрепляются к данным группам, они тут же получают соответствующие разрешения. Так вот, большинство наших клиентов могут ограничиваться описанными действиями.

Но если вы хотите получить более высокую степень детализации, у нас имеются также ролевые группы, состоящие примерно из 65 встроенных ролей. Этим группам уже назначены задания, и вы, к примеру, можете сказать: «Хочу делегировать конкретные роли». И здесь опять-таки вам не придется создавать сложные роли — они уже подготовлены. А когда их целых 65, уже можно говорить о некотором уровне детализации, причем если вы хотите делегировать свои полномочия пользователю на ступеньку ниже, то и у этого пользователя возможностей будет достаточно. Ну а если вы будете работать с по-настоящему сложной схемой делегирования — что ж, делайте, что сочтете нужным, в самом деле, и осуществляйте делегирование.

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

Дает ли данная система какие-либо дополнительные преимущества конечным пользователям?

Безусловно. Одно из наших нововведений — реализация идеи самообслуживания пользователя. Когда в веб-клиенте Outlook вы нажимаете кнопку Options, то попадаете на панель управления Exchange. А она выросла не только из функций OWA, но и из портала самообслуживания. И если вам предоставили разрешения, это значит, что вы можете делать такие, например, вещи: присоединиться к группе рассылки или отследить сообщение. Или же, если вы отвечаете за обеспечение соответствия требованиям или за управление поиском и выборкой, то можете воспользоваться тем же самым интерфейсом для выполнения поиска по нескольким почтовым ящикам.

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

Вспомним, как потребители в свое время принимали Exchange 2007. На первых порах отмечалось энергичное сопротивление использованию PowerShell, в штыки была встречена идея об управлении Exchange из окна командной строки или с помощью сценариев. А знаете ли вы о том, что специалисты говорят сейчас? Привыкли ли они к работе с оболочкой PowerShell в среде Exchange? Как сказывается на общей картине дистанционное использование PowerShell в Exchange 2010?

Сегодня мы видим, что использование PowerShell как в системе Exchange, так и в других продуктах получает все более широкое распространение, поэтому можно сказать, что специалисты несомненно все больше свыкаются с идеей управления сервером с помощью PowerShell. Но мы попытались заложить в пользовательский интерфейс возможность решения как можно большего числа задач. Поэтому идет ли речь о Exchange Management Console или об Exchange Control Panel, работа в основном может быть выполнена с помощью одного из инструментов управления, реализованных через графический интерфейс.

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

Надо сказать, что с точки зрения удаленной работы PowerShell два обстоятельства делают его очень эффективным. Теперь пользователь может, к примеру, управлять дополнительными лесами Exchange с помощью консоли управления Exchange. А это стало возможным благодаря тому, что подключение осуществляется через удаленное использование PowerShell. Так что вы можете устанавливать удаленное соединение и управлять, скажем, несколькими лесами с помощью консоли управления Exchange. Теперь о другой задаче, которую мы теперь можем выполнять. PowerShell создает основу для инструментальных средств с графическим интерфейсом, которые мы используем с помощью RBAC, а затем вам выделяются только те функции инструментов, к которым вы фактически имеете доступ. И, поскольку удаленное использование PowerShell предусматривает концепцию неограниченных сред исполнения, он предоставляет доступ только к тем объектам, к которым вы допущены через механизм RBAC.

Итак, PowerShell предоставил администраторам более простой в применении инструмент, применяемый при делегировании полномочий. Еще один аргумент в пользу дистанционной работы PowerShell — пользователям, не имеющим 64-разрядной операционной системы, предоставляется возможность устанавливать эти средства управления. В сущности, администраторы могут дистанционно выполнять PowerShell под управлением 32-разрядной операционной системы и при этом подключаться к серверу Exchange и запускать на нем сценарии. Таким образом, это дает нам довольно мощную платформу, с которой можно работать.

Похоже, что благодаря усовершенствованиям, реализованным в системе Exchange 2010, веб-клиент Outlook (OWA) становится сильным конкурентом клиента Outlook для настольных систем. Как вы полагаете, это обстоятельство повлияет на ход модернизации до версии Outlook 2010?

По-моему, это не помешает компаниям модернизировать свои системы. Но они получат более широкие возможности выбора. По нашим данным, имеется целый ряд организаций, где пользователи вообще не получают доступа к электронной почте, потому что не у всех есть компьютеры или сотрудники работают посменно и один компьютер приходится на несколько человек. Теперь такие организации имеют более широкий выбор — они могут предоставлять своим сотрудникам программу на базе браузера для подключения (к системам обработки электронной почты). То есть теперь важно добиться того, чтобы организации могли выбирать инструментальное средство и чтобы они, осуществляя этот выбор, в любом случае сохраняли широкий набор возможностей. Именно по этой причине многие функции OWA дублируются в Outlook 2010. Мы хотим, чтобы все наши программные клиенты по возможности располагали сопоставимыми наборами функций.

Какие функции, реализованные ныне в OWA 2010 и в Outlook 2010, недоступны в Outlook 2007?

Ну, озвучить полный список я, пожалуй, не смогу — назову только наиболее важные. Это представление «Разговор» и представление «Новый разговор», в сущности перенесенное из Exchange. Подсказки MailTips имеются только в этих двух продуктах. Персональные архивы доступны лишь в OWA или Outlook 2010. Совместное использование календаря, при котором вы можете делиться конфиденциальной информацией с другими организациями. Вот, пожалуй, и все важные функции.

Но если система обновлена до версии Exchange 2010, всеми этими функциями можно пользоваться и в OWA, даже если клиент Outlook не обновлен?

Да, разумеется.

Б. К. Уинстед (bwinstead@windowsitpro.com) — помощник редактора в Windows IT Pro и SQL Server Magazine