Outlook 11 и Exchange Server

Традиционно сервер Microsoft Exchange Server поддерживал только программный интерфейс Messaging API (MAPI) удаленного вызова процедур (RPC) поверх тех или иных протоколов, например NetBIOS over TCP (NetBT). Такая модель предполагает наличие надежного соединения клиента и сервера или, по крайней мере, соблюдение некоего согласованного стандарта работы в корпоративной локальной сети. Многие наши читатели не раз испытывали разочарование, наблюдая, как Microsoft Outlook выдает сообщения об ошибке при использовании медленных каналов связи или при возникновении больших задержек подключения (например, через RAS Dial-In). Протокол RPC, помимо всего прочего, характеризуется большим трафиком обмена данных, что также не способствует повышению его надежности и приводит к дополнительным сбоям и перерывам в работе.

Связка Outlook 11/Exchange Server 2003 (прежнее название — Titanium) и, в меньшей степени, Outlook 11/ Exchange 2000 Server позволяет заметно улучшить сетевую составляющую клиента и сервера. Оба программных продукта — Outlook 11 и Exchange 2003 — планируется выпустить в середине 2003 г., поэтому некоторые изложенные здесь данные к моменту выхода финальных версий этих продуктов еще могут измениться. Имеются сведения, что в новых программных продуктах остальные усовершенствования будут настолько значительны, что предмет нашего сегодняшнего обсуждения станет просто ничтожен. Поживем — увидим.

Усовершенствования сетевого компонента Outlook 11

Протокол RPC весьма чувствителен ко всякого рода сетевым задержкам, что становится проблемой при взаимодействии клиентов и серверов Exchange. С точки зрения клиента, проблемы RPC (вследствие недопустимо долгого ожидания) проявляются в тот момент, когда система выдает сообщение о том, что программа Outlook ждет ответа от почтового сервера Exchange. Во время одной сессии Outlook может связываться с несколькими серверами Exchange, по мере перемещения пользователя от своего почтового ящика к общим папкам. Тайм-ауты могут повлиять на любые из этих подключений, поэтому сам факт появления вышеупомянутого сообщения еще не означает, что проблема присутствует именно между данным клиентом и сервером Exchange, на котором хранится почтовый ящик клиента.

Из самой природы протокола RPC следует, что при подключении клиента Outlook к серверу Exchange можно воспользоваться каналом связи с низкой пропускной способностью и начать передавать по нему огромный объем данных, пусть даже и очень медленно. К примеру, многие используют канал на 9,6 Кбит/с при работе с сотовыми телефонами. При передаче данных по низкоскоростным каналам связи в RPC предусмотрены разделение крупных блоков передаваемой информации на множество пакетов и передача их в параллельном режиме. К сожалению, приложению может потребоваться весь блок информации целиком, и оно будет вынуждено ожидать завершения всей транзакции пересылки и только после этого сможет послать соответствующее уведомление — явление, которое можно наблюдать очень часто при взаимодействии Outlook и Exchange по низкоскоростным каналам связи. В версии клиента Outlook XP разработчики Microsoft усовершенствовали алгоритм работы клиента, и Outlook может продолжать заниматься другими задачами, не дожидаясь окончания транзакции, но в деле усовершенствования алгоритма работы клиента точка еще не поставлена.

Среди других исправлений, которые планируется реализовать в Outlook 11, — создание более «интеллектуального» клиента с точки зрения потребляемых ресурсов сети. Этот момент очень важен для Microsoft, и в первую очередь он связан с ростом числа соединений, осуществляемых при помощи мобильных устройств, на основе беспроводных каналов связи, а в последнее время и при помощи сетей сотовых телефонов. Такие устройства, как Tablet PC, выявляют непростую проблему в связи с работой приложений, для которых требуется постоянное взаимодействие с серверами и которые очень чувствительны к разрывам сетевых соединений. Новый клиент Outlook наверняка столкнется с подобной категорией устройств.

Изменения, затрагивающие сетевой компонент Outlook 11, представлены в данной статье в четырех аспектах: использование HTTP в качестве транспортного протокола RPC, кэшированное реплицирование, улучшение алгоритмов сжатия и поддержка технологии best-body, а также профили полосы пропускания.

Применение HTTP в качестве транспортного протокола RPC. Outlook 11 использует программный упаковщик для передачи обращений MAPI RPC на сервер Exchange 2003 по протоколу HTTP или HTTP Secure (HTTPS). Всякий раз, подключаясь к серверу Exchange 2003 через Outlook Web Access (OWA), вы можете подключиться к нему и при помощи клиента Outlook 11 — не нужно заново перераспределять RPC-порты или организовывать виртуальную частную сеть. Однако из-за того, что разработчики Microsoft изменили алгоритм работы RPC для достижения подобной функциональности, необходимо разворачивать Outlook 11 в системе Windows XP Service Pack 1 (SP1) или более поздних версиях операционной системы и подключаться к серверам Exchange 2003 для обеспечения безопасной аутентификации. Что касается конфигурации Front-End/Back-End, то серверы Front-End Exchange 2003 в демилитаризованной зоне (DMZ) могут выступать для серверов Back-End Exchange 2003 в роли proxy-серверов трафика «RPC в HTTP». Далее серверы Exchange 2003 должны работать в системе Windows 2003 Server, поскольку серверы глобального каталога Global Catalog (GC) используются клиентом Outlook. Рассматриваемая функциональность не может быть реализована в Exchange 2000 — прежде чем подключиться с помощью Outlook к Exchange по HTTP, нужно произвести обновление версии Exchange до уровня Exchange 2003.

Кэшированное реплицирование. Outlook 11 может извлечь данные из серверов Exchange 2003, Exchange 2000 и Exchange Server 5.5 и организовать на компьютере локальный кэш. В дальнейшем клиент использует кэш для доступа к сообщениям и вложениям. Ниже будет представлено описание работы локального кэша.

Улучшение алгоритмов сжатия и использование технологии Best-Body Support. В Outlook 11 была проведена оптимизация кода в части применения протокола RPC при взаимодействии клиента и сервера, в результате чего был сокращен объем данных, посылаемых по сети во время проведения синхронизации. Усилия Microsoft, направленные на снижение интенсивности обмена информацией между клиентом Outlook и сервером Exchange, не вызывают особого удивления, если как-нибудь провести мониторинг трафика через модемное соединение. Усовершенствование алгоритмов сжатия данных и разумное расходование сетевых ресурсов означают, что со временем пользователь будет все реже сталкиваться с сообщениями о том, что Outlook ожидает ответа от сервера Exchange.

Термин «Best-Body Support» означает, что Outlook может запросить у сервера Exchange «родной» контент сообщения, а не конвертированное в формат Rich Text Format (RTF) тело сообщения. Когда более старые версии клиента Outlook соединялись с Exchange, сервер не мог быть на 100% «уверен», что формат сообщения поддерживается данной версией клиента. Например, Outlook 97 «не понимал» сообщения в формате HTML. Если Exchange получал такое сообщение, сервер автоматически конвертировал HTML в RTF и посылал обе копии клиенту. Любой MAPI-клиент и любой Exchange-сервер поддерживали RTF, так что формат RTF фактически стал общим знаменателем любых операций пересылки сообщений. Отправление двух копий тела сообщения увеличивало трафик между сервером и клиентом, а размер хранилища Offline Folder Store (OST) оказывался гораздо больше, чем требовалось. А когда к серверу Exchange 2003 подключается Outlook 11, последний запрашивает наиболее подходящий формат тела сообщения, и сервер посылает только одну копию, без преобразований формата.

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

В полной мере прочувствовать последствия внедрения новой технологии Best-Body Support можно в том случае, если каждое рабочее место пользователя будет переведено на Outlook 11.

Профили полосы пропускания. Для учета различных условий выполнения реплицирования данных в Outlook 11 предусмотрены так называемые профили полосы пропускания (bandwidth profiles). Код, который выполняется клиентом во время репликации данных через высокоскоростное подключение по локальной сети, отличается от кода, обеспечивающего репликацию по низкоскоростным каналам.

В строке состояния Outlook отображается характер подключения, используемого в данный момент. Так, например, на Экране 1 показано, что действующее в настоящий момент подключение — Fast, т. е. обмен данными осуществляется через локальную сеть или аналогичное высокоскоростное подключение.

Экран 1. Строка состояния Outlook.

Когда речь идет о пересылке данных с одного компьютера на другой, всегда существует вероятность искажения данных. Если Outlook сталкивается с объектом bad item в почтовом ящике или общих папках, то в процессе синхронизации возникает сбой. Более того, результатом получения искаженных данных может стать «зацикливание» клиента, когда Outlook активно, но безрезультатно посылает запросы RPC на сервер Exchange, что приводит только к бесполезному увеличению сетевого трафика. В Outlook 11 реализован алгоритм Bad-Item Check — проверка сообщений на возможное искажение, и, пока не станет ясно, что тело сообщения и набор свойств переданы полностью, синхронизация хранилища OST не будет начата.

Локальный кэш

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

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

Работа в автономном режиме вполне допустима, если ничего другого сделать не удается, а к серверу Exchange подключиться невозможно. Однако, работая в этом режиме, пользователь не может обратиться к актуальным данным глобального адресного списка, Global Address List (GAL), не может организовать встречи и не имеет доступа к папкам, на которых установлен атрибут синхронизации (перед тем как их использовать, необходимо снять данный атрибут, т. е. выполнить синхронизацию). Пользователи, готовясь к командировкам, заранее загружают адресную книгу для автономной работы, Offline Address Book (OAB), и синхронизуют почтовые каталоги, но чаще всего отсутствие связи с родным сайтом и несинхронизированные каталоги оказываются для большинства из них неприятным сюрпризом.

Можно использовать комбинацию клиента Outlook 11 и сервера Exchange (Exchange 2003, Exchange 2000, Exchange 5.5) для организации режима кэширования (Cached Mode) в процессе передачи данных от клиента к серверу и обратно, и всегда задействовать этот режим при подключении Outlook к серверу Exchange (режим работы по умолчанию). По существу, Cached Mode является комбинацией работы в оперативном и автономном режимах, когда клиент в фоновом режиме непрерывно получает данные с сервера, в то время как запросы пользователя обрабатываются в локальном кэше.

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

Экран 3. Загрузка сообщений целиком.

Я предпочитаю последнее, поскольку в этом случае всегда могу без ущерба для своего почтового ящика отключиться от сети.

Установив Cached Mode и завершив сеанс Outlook, я снова, как обычно, регистрируюсь на сервере Exchange (т. е. включаю уведомления о получении сообщения и т. п.), однако теперь Outlook должен использовать кэш. Первое, что обязан сделать Outlook, — это построить локальный кэш. Если, работая с предыдущими версиями Outlook, пользователи уже задействовали автономное хранилище OST, им, скорее всего, не потребуется полностью синхронизировать каждую папку в почтовом ящике. Следовательно, Outlook всего лишь дополнит содержимое этих папок, создав полную локальную копию почтового ящика. Если же OST ранее не использовался, Outlook построит локальный кэш «с нуля».

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

Размер OST-файла на жестком диске локальной станции пользователя всегда будет больше, чем размер его почтового ящика. Хранение данных в OST осуществляется не столь эффективно, как в базе данных Exchange, в результате размер файла OST примерно на 80% больше размера почтового ящика. Например, мой почтовый ящик, размером 686 Мбайт, разросся до 1,8 Гбайт в файле OST. Причины я поначалу никак не мог понять, если только не предположить, что произошло это из-за наличия в сообщениях большого разнообразия форматов — RTF, HTML, открытый текст и т. п. Через какое-то время я заметил, что Outlook 11 скопировал полный контент всех общих папок, которые были включены в список Favorites. Outlook скопировал некоторые почтовые папки, в которых насчитывалось более 10 тыс. элементов, что и привело к столь заметному росту файла OST. После того как эти папки были удалены из списка Favorites, размер OST сократился до 900 Мбайт — все еще многовато, конечно, но уже может быть оправдано преимуществами, которые я получаю при работе с локальным кэшем.

Естественно, возможность получить полную копию всех папок в автономном режиме работы дает пользователю прекрасную возможность удалить устаревшие материалы и сократить размер OST, но на практике мало кто действительно использует этот шанс. Технология Best-Body Support, которая может применяться только в связке Outlook 11/Exchange 2003, помогает дополнительно сократить размер OST за счет хранения только одной копии каждого сообщения.

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

Коль скоро пользователь начинает работать с локальным кэшем, всякий раз при изменении контента почтового ящика на сервере Exchange спрашивает разрешения инициировать синхронизацию. Когда пользователь получает сообщение, Outlook загружает его заголовок и первые 254 байт тела, и, таким образом, пользователь знает, кто является отправителем сообщения (и видит эту информацию в Inbox). Затем Outlook загружает начальные данные, может выполнить установленные клиентом правила и отобразить собственно текст сообщения в окне предварительного просмотра Preview Pane (в новой версии Outlook это окно называется Reading Pane). Одновременно Outlook загружает тело сообщения и всю имеющуюся информацию о вложениях и сохраняет эти данные в локальном кэше. Если пользователь решает прочесть сообщение и просмотреть вложения, Outlook извлекает полученные данные с сервера, отображает их, после чего сохраняет все в локальном кэше.

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

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

Для установки контрольных точек, с помощью которых определяются данные, реплицированные во время сессий синхронизации с сервером Exchange, применяется усовершенствованный алгоритм Incremental Change Synchronization (ICS).

В Outlook 11 и более ранних версиях почтового клиента разработчики Microsoft использовали огромные массивы контрольных точек, устанавливаемые с помощью ICS. С точки зрения производительности это было оправданно, но, если соединение между клиентом и сервером оказывалось разорванным, такой подход приводил к тому, что Outlook перезапускал процедуру синхронизации с контрольной точки, которая к тому времени уже была неактуальна. Специалисты Microsoft переработали алгоритм ICS (сейчас он носит название Advanced ICS), и теперь в тех же самых ситуациях повторно копируется меньший объем данных. При этом рост производительности Outlook был достигнут при меньшем числе контрольных точек.

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

Кэширование и производительность сервера

Как утверждают в Microsoft, режим кэширования повышает производительность клиента (поскольку Outlook работает с локальными данными) и приводит к снижению сетевого трафика и загрузки сервера, так как обеспечивает более экономное расходование ресурсов, если смотреть со стороны сервера. Производительность сервера возрастает, так как сетевые клиенты загружены более равномерно, соответственно, можно обслуживать большее число клиентов. Однако проводить консолидацию серверов целесообразно только в том случае, если Outlook 11 и Exchange 2003 развернуты повсеместно, и можно не просто установить режим кэширования, но и получить от этого все преимущества автоматической компрессии данных — такая функциональность достижима лишь при условии комбинации Outlook 11 и Exchange 2003 в масштабах всей сети (об автоматической компрессии данных я расскажу чуть позже).

В ряде случаев режим кэширования нежелателен. Рассмотрим следующие примеры.

• Предположим, некий пользователь постоянно переходит с одного компьютера на другой. В этом случае кэширование устанавливать не стоит, так как Outlook вынужден был бы непрерывно перестраивать локальный кэш на каждом компьютере, за который садится пользователь, что привело бы к увеличению сетевого трафика и загрузке сервера. Кроме того, и сам пользователь был бы недоволен тем, что его почтовый ящик постоянно находится в состоянии обновления. Такому пользователю можно посоветовать работать в оперативном режиме и каждый раз подключаться к серверному почтовому ящику.
• Если сотрудник использует рабочую станцию очень редко, ему нет смысла задействовать локальное кэширование - всякий раз во время подключения к серверу Exchange происходила бы неоправданно массовая загрузка данных.
• Пользователю, у которого почтовый ящик достигает огромных размеров, тоже не следует применять режим кэширования. Мне известны случаи, когда размер почтового ящика составлял более 2 Гбайт - в отдельных случаях речь шла о 5 Гбайт. Создание полной реплики такого огромного почтового ящика на ноутбуке теряет всякий смысл, особенно если учесть еще большие размеры файла OST. При желании можно прямо сейчас создать OST-файл в формате Unicode и теоретически неограниченно увеличить его размер. Насколько это оправданно - другой вопрос, так как при размере файла OST свыше 1 Гбайт наблюдается снижение скорости его обработки. Если размер файла хранилища еще больше, его владельцу лучше работать со своим хранилищем в автономном режиме: на группы отправления и приема почты могут быть наложены фильтры, и тем самым ограничен поток данных, который необходимо синхронизировать между Outlook и Exchange.
• Для пользователей Windows 2003 и Windows 2000 Terminal Services или тонкого клиента Citrix MetaFrame режим кэширования данных недоступен.

Для проведения мониторинга коммуникационного трафика в Outlook 11 предусмотрена возможность отслеживания трафика RPC. Outlook периодически посылает накопленные данные замеров производительности на сервер Exchange 2003. В результате на сервере аккумулируются сведения о работе всех подключенных клиентов Outlook. Администратор системы может использовать Performance Monitor для просмотра счетчиков производительности работы клиентов для объекта MSExchangeIS (Information Store). Регистрация параметров производительности приводит к некоторому ее снижению, но, если используются более-менее современные рабочие станции, это не будет очень заметно, разве что в момент пересылки данных на сервер.

Компрессия данных и рабочие буферы

Для работы клиентов MAPI характерно требование, чтобы сервер передавал клиенту данные небольшими порциями. В целях оптимизации потока данных между клиентом и сервером размер рабочего буфера варьируется в зависимости от версии клиента и типа сети. Например, как следует из Таблицы 1, Outlook 2002 использует более крупные, по 32 Кбайт, буферы для высокоскоростных сетей (типа локальной сети) и буферы объемом 8 или даже 4 Кбайт для медленных каналов связи. При этом ни клиент, ни сервер не сжимают передаваемые данные.

Помимо реализации локального кэширования в Outlook 11 размер буфера более тщательно подбирается под конкретные условия работы, а данные на сервер пересылаются в сжатом виде. Exchange 2003 использует аналогичную технологию сжатия данных, поэтому для связки Outlook 11 и Exchange 2003 речь идет о полнодуплексном обмене сжатыми данными. Однако это справедливо только при подключении Outlook 11 к серверу Exchange 2003. Сервер Exchange 2003 «узнает» о возможности передавать клиенту сжатые данные только после получения специального клиентского запроса MAPI. В предыдущих версиях Outlook этот вызов не используется, поэтому Exchange 2003 посылает данные в прежнем, неупакованном, формате.

При осуществлении компрессии/декомпрессии неизбежны определенные накладные расходы на сервере. Однако в Microsoft полагают, что, поскольку в этом случае число сетевых пакетов уменьшается, небольшое увеличение нагрузки на сервер оправдано. Все сообщение целиком, включая вложения, передается в упакованном виде. Точно так же, как коэффициент сжатия в хорошо всем известных утилитах Zip меняется от формата к формату, в Exchange тоже все зависит от типа сообщения и вложений. Например, для HTML и «плоского» текста характерны коэффициенты сжатия от 60 до 80%. Документы Microsoft Word и Microsoft Excel сжимаются очень хорошо, презентации Microsoft PowerPoint — похуже. Как бы то ни было, при передаче по сети сжатых данных, например RTF-сообщений, трафик снижается очень сильно.

В Таблице 2 показано, как Outlook 11 меняет размер буфера в различных ситуациях. Сценарий «автономный режим» означает, что пользователь автономно готовит почтовое отправление и после этого подключается к серверу для синхронизации своего почтового ящика. Если сравнить эти данные с тем, какие установки в той же ситуации выполняет Outlook 2002, можно заметить, что в Outlook 11 особое внимание уделяется утилизации сети. Еще раз хотелось бы подчеркнуть, что влияние на сервер оптимизации размера буфера в очень большой степени зависит от характера работы и формата данных. Например, если серверы обновлены до уровня Exchange 2003, но почтовые клиенты остались прежними, с точки зрения загрузки сети никаких изменений пользователь не заметит.

Перевод каждого клиента на Outlook 11 приведет к некоторому повышению производительности, но не столь существенному, как можно было бы ожидать, если пользователи задействуют HTML в качестве редактора сообщений и посылают друг другу объемные презентации PowerPoint. Лучше всего, если пользователи обновят устаревшие версии Outlook и будут применять разумную комбинацию форматов HTML, плоский текст, RTF при составлении сообщений с вложениями.

Специалисты Microsoft проделали огромную работу, чтобы Outlook 11 стал самым лучшим почтовым клиентом для Exchange. В Таблице 3 показано, какие новые функции Outlook проявляются при работе с Exchange 2000 или Exchange 5.5, но максимальные результаты могут быть достигнуты только в связке Outlook 11 и Exchange 2003.

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

Тони Редмонд — редактор Windows 2000 Magazine, вице-президент в Compaq Global Servises. С ним можно связаться по адоесу: exchguru@win2000mag.com.