Хранилище Information Store можно с полным правом назвать сердцем системы Microsoft Exchange Server. Работать этот компонент должен безупречно, иначе вся система не будет функционировать нормально, а пользователи станут проявлять недовольство, так как не смогут обращаться к своим почтовым ящикам. В продуктах Exchange Server 2003 и Exchange 2000 Server была воплощена концепция групп хранения Storage Groups (SG) и реализованы такие компоненты, как потоковая база данных, streaming database. И хотя важнейшим усовершенствованием Store в системе Exchange 2007 стали средства для работы с 64-разрядной платформой Windows, надо отметить, что специалисты Microsoft внесли в этот компонент и другие фундаментальные изменения, о которых должны знать ИТ-специалисты, планирующие осуществить переход к системе Exchange 2007.
А где же SQL Server?
Многие ожидали, что наиболее значительным шагом вперед в Exchange 2007 станет переход к использованию нового ядра баз данных — Microsoft SQL Server. Но после того как разработчики Exchange проанализировали проблемы, возникающие в случае, когда предназначенному для обработки структурированных транзакций процессору поручается работа с данными, созданными системой Exchange и ее клиентами, они решили, что в Exchange 2007 идти по такому пути не стоит. И это неудивительно, если учесть, что по каналам Exchange проходят сообщения, разительно отличающиеся друг от друга, — это и небольшие послания объемом в 2 Кбайт, и многомегабайтные сообщения с несколькими вложениями, распространяемые через объемные списки рассылки. Кроме того, пользователи взаимодействуют с системой Exchange таким образом, что это взаимодействие может оказывать влияние на базу данных. Так, пользователь приложения Microsoft Outlook может щелкнуть на заголовке в папке «Входящие», чтобы рассортировать сообщения по критерию, указанному в заголовке соответствующего столбца. Такое действие создает новое пользовательское представление базы данных. Не будем забывать, что сервер обслуживает тысячи клиентов, причем каждый клиент может создавать множество различных представлений, и тогда мы поймем, почему переход на SQL Server сопряжен со столь серьезными инженерными проблемами.
Словом, в системе Exchange 2007 по-прежнему используется технология Extensible Storage Engine (ESE), применяемая с 1996 г. Разумеется, в каждой версии Exchange эта технология претерпевает те или иные изменения, и Exchange 2007 — не исключение. Важным нововведением в этой версии стал переход от 32-разрядной платформы к 64-разрядной.
64-разрядная платформа и Exchange
Если говорить об Exchange, надо подчеркнуть, что переход на 64-разрядную платформу — большой плюс, ибо он помогает решить ряд фундаментальных проблем хранилища Store, проявившихся в версиях Exchange 2003 и Exchange 2000. Обратимся к конкретному примеру. С выпуском корпорацией Microsoft все новых версий Windows функционирующие под управлением этой операционной системы серверы постепенно захватывают все большие объемы памяти режима ядра, ведь им приходится обеспечивать работу драйверов, таких как драйверы приложений для борьбы с вирусами и спамом, а также удовлетворять запросы на соединения, поступающие от клиентов. Еще пять лет назад пользователи, как правило, подключались к сети только с настольных клиентов, и администраторы могли с легкостью определять, какое количество клиентов тот или иной сервер должен обслуживать одновременно; этот показатель зависел от числа пользователей, чьи почтовые ящики хранятся на данном сервере. Теперь же благодаря широкому распространению мобильных устройств пользователи обращаются к своим почтовым ящикам различными способами. Поставляемый компанией Research in Motion (RIM) коммуникатор BlackBerry завоевал популярность во многих компаниях с почтовой организацией Exchange, но его применение сопряжено с затратами на дополнительную серверную инфраструктуру, поэтому компании часто накладывают ограничения на использование устройств BlackBerry. Здесь уместно напомнить, что корпорация Microsoft разработала серверное приложение ActiveSync (требующее меньших затрат, так как оно использует уже имеющуюся серверную инфраструктуру), к тому же важно иметь в виду растущую популярность устройств Windows Mobile и особенно возросшую функциональность ActiveSync в сочетании с Exchange 2007. Отсюда следует, что системе Exchange 2007 в будущем придется обеспечивать взаимодействие с еще большим числом мобильных устройств. Но ведь каждое одновременно поддерживаемое соединение с клиентом требует памяти, что и объясняет повышение спроса на этот ресурс.
Годами фрагментация виртуальной памяти была настоящим бичом систем Exchange, особенно кластеризованных. Приложения требуют у Windows памяти, и операционная система предоставляет эту память поблочно. Некоторым приложениям необходимо, чтобы блоки памяти располагались в смежных областях, и если в памяти нет достаточной по размеру непрерывной свободной области, приложение дает сбой. Так, для загрузки группы хранения и для монтажа ее баз данных системе Exchange необходимо наличие относительно больших объемов непрерывной виртуальной памяти. Когда сбой происходит в кластере, этот кластер пытается перевести группы хранения из отказавшего узла в другие узлы кластера, но если виртуальной памяти не хватает, кластер не может перемещать группы хранения, и пользователи теряют доступ к своим почтовым ящикам.
Резкое увеличение объема доступной памяти вследствие внедрения 64-разрядных версий Windows снижает остроту проблем, связанных с фрагментацией памяти в системах Exchange 2003 и Exchange 2000, а также дает возможность системам Exchange кэшировать гораздо больше данных, чем прежде. Способность кэшировать значительные объемы данных хороша тем, что система Exchange 2007 может обращаться к памяти, вместо того чтобы выполнять связанные с большими затратами операции дискового ввода/вывода. А это дает возможность развязать еще один важный узел, который ограничивает производительность системы Exchange на 32-разрядной платформе. Специалисты Microsoft предсказывают, что в конечном итоге переход на 64-разрядную платформу приводит к снижению количества инициированных пользователями операций ввода/вывода в пересчете на одну секунду с уровня примерно в 1,0 до уровня 0,4 (точный показатель определяется конкретной рабочей нагрузкой, характеристиками процессора и конфигурацией средств хранения). Сокращение количества операций ввода/вывода позволяет одновременно работать с большим числом пользователей, но, с другой стороны, в этом случае необходимо оснащать серверы Exchange 2007 большим количеством памяти, чем, скажем, серверы Exchange 2003. Используемые для хранения почтовых ящиков серверы Exchange 2007 с объемом памяти 8 Гбайт найдут широкое применение, поэтому при развертывании систем Exchange 2007 придется обращать внимание на тип и быстродействие модулей памяти DIMM, которые вы заказываете для серверов.
Разработчики Microsoft внесли во внутренний механизм Store и другие изменения, чтобы сделать работу хранилища более эффективной. На страницы баз данных ныне отведено 8 Кбайт вместо прежних 4 Кбайт, что позволяет системе Exchange размещать на каждой странице больше данных и, соответственно, сокращать число операций ввода/вывода. Хранилище Store системы Exchange 2007 с большей эффективностью выполняет совместные операции записи и групповые транзакции, поэтому вместо ряда последовательных операций записи совершаются единичные операции записи. Наконец, Store более эффективно использует память при кэшировании папок и сведений, к которым пользователи часто обращаются (например, календарей), что обеспечивает более высокую производительность пользователей.
Вследствие увеличения размеров страницы базы данных и других изменений внутренних механизмов исключается возможность монтирования базы данных Exchange 2003 на сервере Exchange 2007 и наоборот. Модернизация сопряжена с целым рядом сложностей, так что Microsoft не поддерживает модернизацию серверов, функционирующих под управлением 32-разрядной Windows и Exchange 2003 или Exchange 2000, до уровня 64-разрядной Windows и Exchange 2007 (даже при использовании одних и тех же аппаратных компонентов, допускающих 64-разрядную обработку). Поэтому вы не найдете особого режима для Eseutil или какой-либо другой утилиты, предназначенной для обновления баз данных. Чтобы переместить данные почтовых ящиков из Exchange 2003 или Exchange 2000 в систему Exchange 2007, нужно воспользоваться мастером Move Mailbox или командой Move-Mailbox. К счастью, сейчас операции по перемещению почтовых ящиков можно автоматизировать с помощью сценариев, которые выполняются в оболочке Exchange Management Shell. Дополнительные сведения о перемещении почтовых ящиков можно найти в статье «Exchange 2007: жизнь без ExMerge?», опубликованной в Windows IT Pro/RE № 3 за 2007 г.
Хотя производственные серверы Exchange 2007 могут работать только под управлением 64-разрядной Windows, Microsoft подготовила 32-разрядную версию Exchange 2007 для использования на тестовых серверах. Управляющие компоненты Exchange 2007, в том числе Exchange Management Shell, можно развертывать также на рабочих станциях, функционирующих под управлением 32-разрядной Windows XP SP1 (правда, в этом случае сначала придется установить Windows PowerShell и последнюю версию среды Microsoft .NET). В версии Exchange 2007 SP1, которая в настоящее время проходит бета-тестирование и, как предполагается, появится на рынке к концу 2007 г., будут реализованы средства для взаимодействия с рабочими станциями Windows Vista.
Максимальный объем баз данных
Во всех предшествующих версиях Exchange максимальный размер баз данных в издании Standard Edition был ограничен. До выхода в свет версии Exchange 2003 SP2 он составлял 16 Гбайт, с появлением SP2 увеличился до 75 Гбайт, и все-таки этот порог был слишком низким, если учесть темпы роста числа сообщений и среднего размера сообщения. Для сравнения: система Exchange 2003 Enterprise Edition позволяет формировать базы данных, размеры которых ограничиваются лишь имеющимся дисковым пространством. В некоторых организациях базы данных достигают 300 Гбайт, однако подавляющее большинство баз данных Exchange вмещает менее 50 Гбайт данных, и объясняется это прежде всего большими затратами времени на выполнение операций резервного копирования и восстановления. В системе Exchange 2007 нет ограничений на размеры баз данных, поэтому, даже если у вас установлена редакция Standard Edition, вы можете увеличивать свои базы данных до необходимых размеров. Однако в Standard Edition существуют определенные ограничения: баз данных для почтовых ящиков, равно как и групп хранения, должно быть не более пяти; между тем пользователи версии Enterprise Edition могут иметь до 50 баз данных и групп хранения.
В одной группе хранения можно размещать до пяти баз данных, но Microsoft рекомендует пользователям Exchange 2007 развертывать в каждой группе хранения не более одной. Эта рекомендация частично вытекает из необходимости обеспечить простоту управления, частично объясняется стремлением повысить производительность, частично — тем обстоятельством, что технология переноса журналов применима лишь к тем группам хранения, которые содержат по одной базе данных.
Журналы регистрации транзакций и репликация
Одно из самых интересных изменений, реализованных специалистами Microsoft в системе Exchange 2007, состоит в уменьшении размера журнала регистрации транзакций с 5 до 1 Мбайт. В журналах регистрации транзакций фиксируются детали всех изменений, внесенных в базы данных группы хранения; функционирующий с большой нагрузкой сервер может ежедневно генерировать десятки гигабайтов регистрационных данных. Размеры файла регистрации были изменены для обеспечения применения технологии переноса журналов — механизма, реализованного в Exchange 2007 для репликации содержимого баз данных на том же сервере (непрерывная локальная репликация, local continuous replication, LCR) или на другом сервере в кластере на ресурсе Majority Node Set (MNS) (непрерывная кластерная репликация, cluster continuous replication, СCR).
Microsoft заявила о своем намерении расширить эту возможность и реализовать репликацию базы данных на резервный сервер, расположенный в другом центре обработки данных (непрерывная репликация на резервных серверах, Standby Continuous Replication, SCR) в системе Exchange 2007 SP1. Внедрение механизма переноса журналов представляет собой важный шаг в конкурентной борьбе Microsoft; ведь Lotus Notes компании IBM, крупного конкурента корпорации на рынках уровня предприятия, уже несколько лет обеспечивает репликацию баз данных. Кроме того, на этом нововведении настаивали клиенты Microsoft, которые хотят иметь подобную функцию, но не желают платить независимым поставщикам за такие продукты, как Double-Take.
Механизм переноса журналов применим только к группам хранения, содержащим не более одной базы данных. Это важно иметь в виду проектировщикам систем, занятым разработкой структуры баз данных сервера. Однако на сервере Exchange 2007 Mailbox можно размещать до 50 групп хранения, причем все они могут реплицироваться, так что в целом система отличается высокой степенью гибкости. Непрерывную кластерную репликацию можно осуществлять только с использованием серверов Mailbox, но непрерывная локальная репликация может проводиться на многоролевых серверах, таких как серверы, которые поддерживают роли Mailbox, Client Access и Hub Transport.
В ходе непрерывной кластерной репликации или непрерывной локальной репликации прямое взаимодействие с базами данных общих папок не предусмотрено, но Microsoft обеспечивает репликацию через поддержку группы хранения, содержащей единственную базу данных общих папок, имеющуюся в организации. Если вы эксплуатируете более одной базы данных общих папок, можете использовать обычную репликацию общих папок для того, чтобы в организации имелось несколько копий данных, хранящихся в общих папках.
Когда администратор подключает к процессу репликации баз данных группу хранения, Exchange формирует пассивную копию базы данных. Делается это так: рабочая база данных копируется в каталог, где предполагается разместить копию (на локальном сервере или же на другом сервере). По завершении дублирования Exchange копирует и проверяет корректность журналов транзакций по мере их формирования хранилищем Store, а затем воспроизводит данные в журналах с целью обновления пассивной копии. В случае сбоя активную копию можно заменить пассивной копией базы данных и продолжать работу. Поставщики постепенно набираются опыта в работе с Exchange 2007, и вполне вероятно, что в средствах управления хранением данных от независимых поставщиков будут реализованы более широкие возможности для выполнения таких функций, как дублирование баз данных и перенос журналов.
Благодаря сокращению размеров журнала регистрации транзакций снижается риск потери данных в системе Exchange после отказа аппаратуры, приводящего к тому, что копии файлов оказываются неполными. Очевидно, что в случае, когда система Exchange оказалась не в состоянии скопировать журнал регистрации транзакций объемом 1 Мбайт, потери данных будут меньше, чем в ситуации, когда не состоялось копирование журнального файла размером 5 Мбайт. Кроме того, в Exchange 2007 есть новая функция lost log resilience (LLR), которая позволяет системе монтировать базы данных после отказа даже в тех случаях, когда некоторые данные в журналах регистрации отсутствуют (из-за сбоев в процессе копирования), а значит, не могут быть использованы для обновления базы данных. LLR выполняется на серверах CCR Mailbox; если Store отказывается монтировать базу данных из-за отсутствия необходимых данных, администраторам, эксплуатирующим все предыдущие версии Exchange, приходится исправлять положение вручную. Как правило, для восполнения базы данных администраторы должны запускать утилиту Eseutil. Известно, что в ходе выполняемых вручную операций часто совершаются ошибки, и всем нам не раз приходилось слышать истории о том, как администраторы запускали программу Eseutil с неверными командными переключателями или пытались применить не те, которые нужно, наборы журналов регистрации транзакций, и о том, какой урон наносился при этом базам данных.
Применение технологии переноса журналов транзакций отражается на быстродействии системы: в процессе копирования и воспроизведения регистрационных файлов в пассивной копии базы данных производительность серверов снижается. Чтение и запись данных в ходе операций ввода/вывода производятся в то время, когда Exchange копирует файлы регистрации транзакций из активной копии в «эталонный» каталог, где Exchange вычисляет контрольные суммы каждого регистрационного файла, с тем чтобы убедиться в его целостности перед воспроизведением содержимого файла в пассивной базе данных.
При этом также потребляются ресурсы памяти, так как для воспроизведения этих транзакций Exchange использует отдельный процессор ESE. В целом первые результаты говорят о том, что при выполнении указанных операций на сервере, обеспечивающем репликацию типа LCR, накладные расходы могут составлять 20%. При выполнении репликаций типа CCR снижается производительность пассивного узла, поскольку он изымает регистрационные файлы активного узла и воспроизводит их в свою копию базы данных.
Транспортная корзина, Transport dumpster, еще одна технология, реализованная в системе Exchange 2007, обеспечивает дальнейшее снижение риска потери данных за счет кэширования на серверах централизованной обработки Hub Transport копий сообщений, которые поступают в почтовые ящики реплицированных баз данных. В случае сбоя Exchange может осуществить повторную отсылку сообщений из кэша в пострадавшие почтовые ящики. Exchange пропускает сообщения, если они уже присутствуют в целевом почтовом ящике. Транспортная корзина не обеспечивает кэширования определенных транзакций, таких как черновые сообщения, но тем не менее благодаря таким средствам, как перенос журналов транзакций, LLR и транспортная корзина, версия Exchange 2007 демонстрирует большую устойчивость к аппаратным отказам, чем любой предшествующий выпуск сервера сообщений.
Не столь фундаментальное, но важное изменение, связанное с уменьшением размера регистрационных файлов, — это изменение именования файлов регистрации транзакций. В системе Exchange 2007 по-прежнему используется префикс SG, указывающий на группу хранения, к которой относится файл регистрации (так, все файлы регистрации, начинающиеся в «E0», относятся к первой группе хранения того или иного сервера), однако Microsoft увеличила шестнадцатеричное число, используемое для идентификации отдельного файла регистрации, с шести до девяти символов, и теперь встречаются такие, к примеру, имена, как E010000aa15.log. Представители Microsoft утверждают, что сейчас пользователи могут создавать свыше 4 млрд файлов регистрации транзакций в расчете на каждую группу хранения, перед тем как системе Exchange придется вновь использовать то или иное имя файла регистрации.
Переносимость
Базы данных Exchange 2007 являются переносимыми. Иначе говоря, вы можете взять базу данных с одного сервера и смонтировать ее на любом другом сервере Exchange 2007 в рамках одной и той же организации — раньше такое было невозможно. Переносимость помогает преодолевать последствия катастрофических сбоев, поскольку она дает возможность оперативно переносить базы данных с отказавшего сервера и монтировать их на другом сервере — если, конечно, у вас все еще сохраняется доступ к файлам базы данных. Способность обращаться к файлам баз данных с целью их последующего перемещения — это достаточное основание для того, чтобы разделяемые средства хранения по-прежнему оставались важным компонентом планирования процедур восстановления систем Exchange после сбоев. Ведь очевидно, что перемещать базы данных между серверами внутри сети хранения данных намного проще, чем если бы эти базы данных были размещены на непосредственно подключаемых дисках.
После размещения баз данных на новом сервере необходимо с помощью команды Move-Mailbox с ключом ConfigurationOnly обновить конфигурацию данных, хранящихся в Active Directory (AD), для почтовых ящиков, принадлежащих только что перемещенным базам, и перенаправить пользователей на сервер, где теперь размещаются эти базы данных. Переносимость — ценная функциональная возможность.
Удаленные элементы
В версии Exchange Server 5.5 разработчики Microsoft реализовали кэш удаленных объектов. Идея состояла в том, чтобы избавить администраторов от необходимости восстанавливать базы данных с целью восстановления элементов, удаленных по ошибке. Это средство применяется уже довольно долго, и технические специалисты давно его освоили. Единственная модификация, реализованная в системе Exchange 2007, состоит в том, что новый применяемый по умолчанию период сохранения удаленных объектов составляет 14 суток (а не 7 суток, как раньше). Период сохранения удаленных элементов определяет срок, по истечении которого хранилище Store навсегда удаляет эти элементы из баз данных. Иначе говоря, Exchange 2007 хранит удаленные элементы в два раза дольше, чем Exchange 2003. Упомянутое увеличение периода хранения влечет за собой увеличение размеров баз данных, возможно, до 10% (это зависит от пользователей, а также от потока трафика сообщений в организации).
Конец потоков
В системе Exchange 2000 в качестве дополнения к обычным файлам свойств баз данных Messaging API (MAPI) (файлам .edb) были введены файлы потоковых баз данных (файлы .stm). Последние позволяют системе Exchange сохранять все данные, поступившие в необработанном Internet-формате в базу данных, специально созданную для работы с этими форматами и не использующую свойства MAPI в файлах .edb. Речь, в частности, идет о посланиях электронной почты и о вложениях, закодированных с помощью многоцелевых расширений MIME. Разработчики ввели новые файлы, ибо полагали, что в будущем Internet-форматы получат гораздо более широкое распространение и что системы Exchange могут избежать снижения производительности, связанного с преобразованием данных MAPI, в ситуациях, когда IMAP- или POP-клиенты, такие как Outlook Express, получают сообщения. Но с момента появления Exchange 2000 производительность серверов резко возросла, и снижение быстродействия в процессе преобразования форматов уже не так важно, как раньше. Outlook по-прежнему уверенно занимает первое место в списке самых популярных клиентов Exchange, и MAPI по сей день остается наиболее активно используемым форматом. Поэтому специалисты Microsoft пришли к выводу, что файлы .stm больше не нужны, и исключили их из Exchange 2007.
Без диска M
Еще одним широко разрекламированным нововведением, реализованным в свое время в системе Exchange 2000, стали средства для отображения содержимого почтовых ящиков Exchange в виде накопителя DOS с помощью протокола Server Message Block (SMB) в файловой системе Exchange Installable File System (ExIFS). На первый взгляд это было превосходное решение: пользователи получали возможность перемещаться по своим почтовым ящикам, как если бы эти ящики были обычными папками DOS.
К сожалению, данная функция оказалась бесполезной в производственных сетях. Более того, она создавала массу проблем, когда администраторы полагали, что могут проверить на наличие вирусов сообщения и вложенные файлы по всему накопителю M, или когда пытались сделать резервные копии данных Exchange на уровне файлов по всему накопителю M. Разумеется, эти резервные копии были бесполезны, ибо они не содержали всех необходимых данных, требуемых системой Exchange (например, свойств MAPI), но эту проблему можно было обнаружить лишь после того, как сервер давал сбой и возникала необходимость в резервных копиях. Microsoft сделала первый шаг на пути к решению этой проблемы, по умолчанию скрывая накопитель M в системе Exchange 2003, и теперь завершила этот процесс, удалив ExIFS из выпуска Exchange 2007.
Общие папки
Иногда создается впечатление, что Microsoft не имеет четкого представления о том, что же, собственно, делать с общими папками. Сначала представители корпорации резко осуждали их использование в Exchange 2007, предполагая вообще исключить общие папки из следующей, существенно переработанной версии Exchange. Но, хотя общие папки нельзя назвать самым эффективным механизмом хранения данных и в них так и не был реализован тот потенциал, о котором говорили в Microsoft после появления этих папок в версии Exchange 4.0, не подлежит сомнению, что пользователи сетей, где установлены системы Exchange, ежедневно обращаются к миллионам общих папок. Сопротивление клиентов, а также осознание того факта, что удобный путь перехода с общих папок или с приложений, использующих общие папки, отсутствует, заставили Microsoft пересмотреть свое решение. Ныне позиция компании состоит в том, что она будет поддерживать общие папки по крайней мере до 2016 г.
Конечно, приятно сознавать, что еще целых девять лет мы можем размышлять о том, как поступить с общими папками, но все-таки обольщаться не стоит: никаких серьезных инициатив в этой области не предвидится. Необходимо приступать к разработке стратегии выхода. Microsoft указывает на SharePoint, и это, безусловно, один из возможных вариантов, хотя здесь придется выполнить большой объем работ вручную, ибо Microsoft не предлагает автоматизированных утилит миграции. Однако компания Quest Software уже поставляет программу Public Folder Migrator for SharePoint (http://www.quest.com/public-folder-migrator-for-sharepoint ), и можно надеяться, что со временем свои утилиты для этой операции разработают и другие компании.
В комплект поставки Exchange 2007 не входит графический интерфейс для управления общими папками, не предусмотрен графический пользовательский интерфейс для доступа к общим папкам и в продукте Outlook Web Access (OWA) 2007. Однако Microsoft исправит эти недоработки в системе Exchange 2007 SP1, а до появления пакета SP1 можно управлять общими папками с помощью диспетчера Exchange System Manager. Другая возможность — изучить команды PowerShell и управлять общими папками, не вспоминая о графическом интерфейсе.
Новое сердце системы Exchange
Администраторы наверняка высоко оценят изменения, внесенные в Exchange 2007. Переход на 64-разрядную Windows повышает стабильность работы и быстродействие, технология переноса журналов регистрации обеспечивает более широкие возможности для восстановления нормального функционирования. Кроме того, из системы исключены некоторые устаревшие компоненты. Хранилищами Store можно управлять с использованием команд оболочки Exchange Management Shell. Кое-какие проблемы остаются нерешенными, например, ни графический интерфейс пользователя, ни OWA не предусматривают средств для работы с общими папками, но специалисты Microsoft рассчитывают устранить эти недостатки в пакете SP1. У администраторов уйдет какое-то время на освоение эффективных методов развертывания и эксплуатации таких технологий, как перенос журналов транзакций, но это важный шаг вперед. В целом можно сказать, что с задачей «улучшения работы сердца» системы Exchange 2007 корпорация Microsoft справилась неплохо.
Тони Редмонд (exchguru@windowitpro.com) — редактор журнала Windows IT Pro, старший технический редактор Exchange & Outlook Administrator, вице-президент и главный технолог HP Services