Основные опции и стратегии миграции c Exchange 5.5
В последнее время компания Microsoft получала постоянные жалобы по поводу сложности пути миграции с Exchange 5.5 на Exchange Server 2000. Именно поэтому вопросу о переходе с Exchange 5.5 на теперь уже Exchange Server 2003 было уделено особое внимание; преследовалась цель структурировать указанный процесс и сократить степень риска при его проведении. В результате были разработаны новые мощные средства разворачивания - Exchange Deployment Tools, которые помогают администраторам осуществлять миграцию с Exchange 5.5. Кроме этих средств, понадобит­ся также знание архитектур как Exchange 5.5, так и Exchange Server 2003, и того, как они взаимодействуют между собой во время процесса миграции.
В данной главе предлагаются лучшие методики миграции с Exchange 5.5 на Exchange Server 2003. Кроме того, дается описание различий между Exchange 5.5 и Exchange Server 2003 и основных шагов, которые необходимо выполнить, чтобы осуществить перенос окружения. Особое внимание уделяется новым методам миграции, доступным благодаря средствам Exchange Deployment Tools, а также ряду "ручных" способов переноса данных.
Сравнение окружений Exchange 5.5 и Exchange Server 2003
Когда версия Exchange 5.5 только-только появилась, ее внедрение на предприятиях оставляло желать лучшего. Она представляла собой идеальный продукт для компаний малых и средних размеров, а также для совместной работы на уровне отделов. В данном разделе главы предлагается обзор типичных установок Exchange 5.5 и как все их недостатки решаются в Exchange Server 2003. Цель данного раздела заключается в том, чтобы дать общее представление разработчикам и администраторам о том, как можно максимально полно задействовать возможности Exchange Server 2003. Для большинства окружений обновление всех серверов Exchange 5.5 на Exchange Server 2003 - далеко не лучший вариант. Некоторые компоненты в окружении могут или должны консолидироваться или даже исключаться.
Описание проектных ограничений для Exchange 5.5
В целом, для окружений Exchange 5.5 применялась распределенная модель развертывания, при которой серверы Exchange размещались в каждом удаленном офисе, обычно включающем более 20-30 пользователей. Это было особенно характерно для организаций, которые внедряли ранние Exchange-окружения. Причиной тому служил ряд факторов, касающихся как самого продукта, так и сетевого окружения. 

Совмещение администрирования и маршрутизации
Версия Exchange 5.5 буквально связывала руки разработчикам, ограничивая Exchange-проекты пределами сайта. Сайт в Exchange 5.5 являлся границей, как для администрирования, так и для маршрутизации сообщений. Репликация каталога внутри сайта (Exchange 5.5.) происходит каждые 15 минут, все серверы сайта сообщаются между собой. Маршрутизация сообщений тоже происходит внутри сайта, с исходного сервера на целевой. Пока пропускная способность в организации ограничена не была, разработчикам приходилось устанавливать границы сайта, чтобы контролировать процессы маршрутизации сообщений и репликации каталога. Большинство организаций, выбравших проект с одним сайтом, сталкивались с проблемой постоянной бло­кировки по времени при передаче RPC-сообщений, и со временем все равно переходили на модель с множественными сайтами. Поскольку маршрутизация сообщений и администрирование объединены, распределенная модель администрирования создавалась автоматически, что только прибавляло трудностей. Возможности модульного администрирования в Windows NT 4.0 не облегчали положение. Любой, обладающий административными полномочиями в домене, мог добавить себя в глобальную группу, права которой назначались через программу Exchange Administrator. В действительности, это означало, что маршрутизация сообщений и централизованное администрирование становились невозможными, если кому-либо в удаленном офисе требовалось управлять сервером Exchange.