Миграция с Microsoft Exchange Server 5.5 на Exchange 2003
ПРОЕКТ
Департаменту образования штата Кентукки необходимо было осуществить миграцию с работающего сервера Microsoft Exchange Server 5.5 на Exchange Server 2003. Данная система в течение учебного года обслуживала примерно 600 000 человек – преподавателей, сотрудников и учащихся.
УЧАСТНИКИ ПРОЕКТА
Проект осуществлялся управлением технических средств обучения (УТСО) департамента образования штата Кентукки при содействии консультантов компании KiZAN Technologies. Персонал УТСО обеспечивал общий надзор над существующей системой на основе Exchange 5.5. Повседневная эксплуатация серверов Exchange входила в обязанности персонала школьных округов.
ЗАДАЧИ
Департамент образования осуществляет техническое руководство всеми 178 школьными округами штата Кентукки. Эти школьные округи соединены друг с другом посредством глобальной сети, но каждый округ имеет свой собственный самостоятельно управляемый сервер Exchange 5.5, который необходимо было обновить отдельно. Такое обновление обеспечило бы поддержку клиентов кэшированного режима электронной почты Outlook® 2003, дополнительные возможности использования веб-клиента Outlook, поддержку стандартизированной схемы адресов электронной почты и дало бы много других преимуществ.
В дополнение к развертыванию нового почтового сервера и клиентской инфраструктуры многие школьные округи предполагали предоставить учащимся возможность пользоваться электронной почтой. Как федеральные нормы, так и нормы штата требовали, чтобы информация об учащихся была защищена и недоступна для просмотра за пределами соответствующего округа.
ПЛАН
Поскольку соединитель Active Directory® нельзя было использовать, была создана новая организация Exchange, и осуществлен перенос данных в нее. Стандартизация адресов электронной почты означала создание как новых дочерних доменов для идентификации каждого школьного округа, так и более 400 новых политик получателя. Для защиты адресов учащихся необходимо было создать для каждого школьного округа систему, включающую глобальные списки адресов и пользовательские списки адресов.
Реальный перенос включал установку нового оборудования, создание и настройку почтовых ящиков на основе принадлежности к округу и типа пользователя, а также установку таких атрибутов расширения на основе принадлежности к округу и типа пользователя, чтобы пользователь отображался в соответствующих списках адресов.
Было создано новое приложение на языке Visual Basic® для обнаружения и исправления неправильно настроенных атрибутов учетных записей и неверных данных об их принадлежности к группам, а также для предоставления новых почтовых ящиков с учетом ограничений на возможность их просмотра. Это приложение было развернуто во всех 178 округах и запускается на серверах школьных округов в соответствии с графиком.
Общие сведения
На первый взгляд все это не кажется трудной или технически сложной задачей. Однако необходимо было руководствоваться требованиями заказчика, а требования заказчика этого проекта были весьма неожиданными.
За много лет из-за децентрализованного управления и запутанных стандартов поддержка каждой системы требовала индивидуального подхода, и управлять всем этим, как правило, приходилось УТСО. Вдобавок УТСО приходилось одновременно обеспечивать соответствие системы на базе сервера Exchange 5.5 как требованиям школьных округов, так и департамента образования. Это означало, что в тех округах, где существовала электронная почта для учащихся, информация о них была защищена и недоступна для просмотра за пределами соответствующего округа, как требовали нормативы штата и федеральные нормативы (см. ed.gov/policy/gen/guid/fpco/ferpa/index.html (на английском языке)).
Для сервера Exchange 5.5 эти нормативы означали, что информация об учащихся округа не могла передаваться в другие школьные округи или другие государственные органы, которые имели доступ к данным глобального списка адресов. В частности, это приводило к необходимости осуществлять вручную процедуру импорта или экспорта для каждого из 178 узлов Exchange 5.5, а именно: скрыть информацию об учащихся, реплицировать список, открыть информацию об учащихся и, наконец, импортировать список адресов обратно. Таким образом, другие округи могли видеть только информацию о сотрудниках, а округ-владелец данных мог видеть все собственные данные и при этом – только данные о сотрудниках из других школьных округов.
С учетом сильных и слабых сторон существовавшей системы обновление инфраструктуры обмена сообщениями должно было удовлетворять некоторым особым требованиям. Во-первых, департамент образования штата Кентукки хотел ввести стандартизацию имен на основе общей легко читаемой схемы имен SMTP для всей организации. Эта схема должна была предоставить раздельные области SMTP-адресов для преподавательского состава и для учащихся.
Эта новая система должна была также обеспечить возможность централизованного предоставления услуг, чтобы снять с округов обязанности по управлению службой сообщений и ответственность за ее работу. Это означало, что управление восстановлением в случае аварии, потоком почты и ответами на обращения пользователей в службу поддержки должно было быть централизовано. По существу, новая система должна была обеспечить централизованный метод стандартизации конфигураций пользователей во всех округах, независимо от географического положения или принадлежности конкретного пользователя к какому-то округу.
Кроме того, новая система должна была обеспечить безопасный доступ к электронной почте через Интернет и с мобильных устройств в едином пространстве адресов, общем для всех округов.
С учетом всех этих требований, многие из которых еще не были реализованы в существовавшей системе Exchange 5.5, миграция на Exchange 2003 казалась грандиозной задачей.
Составные части решения
Для выполнения требований заказчика были определены несколько особенностей развертывания Exchange.
Было решено не использовать соединитель Active Directory из-за недостаточной стандартизации и значительных масштабов системы Exchange 5.5. Вместо этого была создана новая организация Exchange, и выполнена миграция в нее.
Для приведения в порядок и стандартизации адресов электронной почты персонала и учащихся всех округов потребовалось создать более 400 новых политик получателя. Для каждого округа требовалось создать уникальный идентификационный дочерний домен, включающий обозначение округа для учащихся. Например, для округа Шелби первичный дочерний домен будет shelby.kyschools.us. Учащимся всех округов назначен дочерний домен stu., то есть учащиеся округа Шелби получают адреса stu.shelby.kyschools.us.
Другим ограничением было то, что адреса учащихся должны были быть видны только внутри их собственного школьного округа, а адреса персонала должны были быть видны изо всех округов. Это потребовало построения сложной системы глобальных списков адресов и пользовательских списков адресов, как показано на рис. 1 и рис. 2. Одним из преимуществ миграции на Exchange 2003 было то, что списки адресов можно было защитить с помощью разрешений и, доступ к каждому конкретному адресу можно было контролировать путем включения в группу. Эта возможность позволила создать две группы безопасности на уровне округа (одну – для персонала, другую – для учащихся), а затем защитить глобальные и пользовательские списки адресов персонала и учащихся соответствующих округов таким образом, что определенные списки адресов были доступны только для пользователей, имеющих учетные записи конкретного округа. Удалив использовавшиеся по умолчанию глобальные и пользовательские списки адресов и убедившись, что группы Everyone (Все) и Authenticated Users (Пользователи, прошедшие проверку) не значатся в списке управления доступом ни одного из списков адресов, можно было установить список адресов, которые смогут увидеть конкретные пользователи конкретного округа.
Рис. 1 Пользовательские списки адресов на основе ролей
Однако благодаря разрешениям удалось решить только часть проблем, связанных с ограничениями на просмотр. Нужно было найти способ управлять тем, кто и в каком списке адресов должен был быть виден. Был создан базовый запрос LDAP, позволявший запросить информацию об отображении в списках адресов учащихся и сотрудников. Затем этот запрос был немного изменен применительно к каждому списку адресов и глобальному списку адресов. Например, запрос LDAP к глобальному списку адресов для персонала округа Шелби должен был отображать только соответствующий персонал и учащихся округа Шелби и весь персонал (но не учащихся) всех остальных округов штата. Глобальный список адресов учащихся Шелби должен был отображать только персонал и учащихся из округа Шелби и не должен был отображать ни персонал, ни учащихся из других округов штата. Такие запросы были созданы для всех округов в организации. На рис. 3 приведены примеры некоторых запросов LDAP, использованных при этой сложной миграции на новую систему.
Рис. 2 Глобальные списки адресов с разделением на персонал и учащихся
Различающим механизмом, лежащим в основе запросов LDAP, являлись значения свойств пользователей Exchange – extensionAttribute14 (пользовательский атрибут 14) и extensionAttribute15 (пользовательский атрибут 15). Для всего персонала и учащихся штата использовалось особое значение атрибута extensionAttribute14, обозначающее тип пользователя, и уникальное значение атрибута extensionAttribute15, обозначающее принадлежность к определенному округу. Благодаря использованию уникальных значений для каждого округа и одинаковых значений для каждого типа пользователей, в списках адресов могла отображаться лишь та информация, которая требовалась для каждого типа пользователей в каждом округе.
Рис. 3 Запросы LDAP для получения списка адресов
Запрос LDAP для получения глобального списка адресов персонала
Эти списки адресов оказались вполне приемлемыми для тех случаев, когда пользователи работали с электронной почтой, используя Outlook в режиме без кэширования или используя веб-клиент Outlook (каждый пользователь направлялся к нужному списку адресов в веб-клиенте Outlook с помощью атрибута msExchQueryBaseDN). Однако была еще одна проблема, связанная с пользователями, которые работали с Outlook в режиме кэширования. Поскольку Outlook не использует пользовательский глобальный список адресов в качестве автономной адресной книги, пришлось создать дополнительные списки адресов, представляющие собой копии глобальных списков. В каждом хранилище почтовых ящиков округа был настроен соответствующий список адресов автономной адресной книги для пользователей, работающих в режиме кэширования. Всего потребовалось создать более 1 500 списков адресов для предоставления полного набора услуг пользователям различных типов всех 178 округов.
Соблюдение установленных требований
Для обеспечения правильной работы этой структуры после ее внедрения самым важным было соблюдение вновь установленных стандартов. Для каждого пользователя организации, работающего в системе Exchange, необходимо было выполнить несколько приоритетных задач. Причина состояла в том, что необходимо было правильно задать местоположение каждого пользователя во всех округных серверах Exchange, и каждый пользователь должен был отображаться в соответствующих списках адресов.
Пользователь должен был быть членом соответствующей группы безопасности в домене округа, поскольку принадлежность к группе безопасности определяет права на открытие соответствующих списков адресов. Необходимо было правильно установить для пользователя значение атрибута msExchQuerybaseDN на основе принадлежности к округу и структурному подразделению. Тип пользователя определялся подразделением.
Следующим шагом было создание почтового ящика пользователя в соответствующем хранилище соответствующего сервера на основе принадлежности к округу и типа пользователя. Таким способом определялись уровни обслуживания, максимальные размеры почтовых ящиков и списки адресов автономной адресной книги, чтобы обеспечить правильное функционирование Outlook в режиме кэширования. Атрибуты расширения устанавливались на основе типа пользователя и его принадлежности к округу так, чтобы пользователь отображался только в нужных списках адресов и не был виден в других.
Наконец, необходимо было обеспечить средства автоматической корректировки атрибутов учетной записи или членства в группах в случае их неправильного задания или изменения. Перемещение пользователя из одного подразделения в другое в пределах домена округа означает изменение классификации пользователя и, соответственно, необходимость изменения местоположения почтового ящика, назначенного пользователю глобального списка адресов и условий отображения пользователя в списках адресов.
Необходима была система поддержки, которая выполняла бы все эти задачи и обеспечивала слаженную и точную работу службы каталогов Active Directory. Было создано консольное приложение на языке Visual Basic, запускаемое по графику на серверах Exchange 2003 в школьных округах. Это приложение, проверяющее соблюдение политики и стандартов, а также создающее и настраивающее новые объекты, было установлено во всех 178 округах.
Было ясно, что задачи, которые предстояло решить, слишком сложны, чтобы их можно было быстро и надежно выполнить с помощью набора сценариев. Приемлемым решением было признано создание приложения на языке Visual Basic. Данный вариант отличается эффективностью и наличием структурированной поддержки обработки ошибок и исключений, причем впоследствии программный код можно будет с минимальными доработками преобразовать в код расширения сервера Microsoft Identity Integration Server (MIIS-сервер).
Поскольку осуществлялся перенос данных в новую организацию, необходимо было найти некоторый способ сосуществования старой и новой версий. В новой среде необходимо было поддерживать более 178 устаревших доменов SMTP, так как в некоторых округах уже были домены электронной почты для учащихся, а в некоторых не было, однако была возможность проводить миграцию в округах по очереди и переключать их на новую систему сообщений и адресов, не затрагивая другие округи. Тем не менее, необходимо было исключить нарушения работы электронной почты при миграции округа с сервера Exchange 5.5 на Exchange 2003. Это означало необходимость реализации определенной синхронизации между Active Directory сервера Exchange 2003 и устаревшим каталогом сервера Exchange 5.5. На время миграции корпорация Майкрософт предоставила департаменту образования штата Кентукки право ограниченного использования сервера MIIS, поэтому был разработан код расширения, использовавшийся для синхронизации старой и новой организаций Exchange перед миграцией, а также во время и после нее.
Переход к новой организации Exchange, естественно, влияет на конфигурацию клиента MAPI. Департамент образования столкнулся с тем, что на уровне округов существовали буквально десятки тысяч профилей MAPI, которые необходимо было перенастроить в ходе миграции. К счастью, корпорация Майкрософт выпустила инструмент Exchange Profile Tool (ExProfRe.exe), который был использован для миграции профилей MAPI в округах. Была создана программа пакетной установки, которая запускала ExProfRe.exe с предустановленными параметрами для автоматического выполнения миграции профилей MAPI. Программа запускалась через групповую политику. Автоматическое преобразование профилей между организациями происходило с почти стопроцентным успехом.
Обновление оборудования
Поскольку новые серверы Exchange 2003 должны были занять место географически разбросанных серверов Exchange 5.5, применяемое оборудование должно было обеспечивать возможность работы такого же количества пользователей, что и система на основе Exchange 5.5, а также дополнительное количество учетных записей учащихся. Серверы должны были размещаться в округах, поскольку топология глобальной сети была разработана таким образом, что весь поток данных между округами (как внутренний, так и связанный с обращением к Интернету) проходил по частным каналам T1 (в некоторых округах по нескольким каналам T1).
Из-за ограничений, связанных с бюджетом, возможностями управления и размещением оборудования, невозможно было снабдить серверы Exchange устройствами хранения данных, подключаемыми к сети областей хранения (SAN), поэтому все эти устройства хранения данных должны были быть либо встроенными, либо непосредственно подключаемыми. Поскольку в большинстве округов не было центров обработки данных со специальными стойками и централизованной системой охлаждения, необходимо было, чтобы серверы были максимально автономными. К счастью, в большинстве округов было менее 5 000 пользователей, поэтому в них можно было ограничиться установкой одного сервера. В округах с большим количеством пользователей использовались более мощные серверы (или несколько серверов) и дополнительные устройства хранения данных, иногда вместе с серверами предварительной обработки данных для дальнейшего разделения потоков информации учащихся и персонала.
В большинстве округов удалось установить хорошо оснащенные двухпроцессорные серверы, оснащенные максимальным количеством жестких дисков Ultra320 SCSI со скоростью вращения 15 000 оборотов в минуту, несколькими контроллерами RAID и оперативной памятью 4 ГБ. В более крупных округах устанавливался один или несколько четырехпроцессорных серверов, а при необходимости — еще и менее мощные серверы переднего плана. Измерение и тестирование производительности перед установкой не выявило никаких проблем в работе, в том числе и при повышенной нагрузке. Тем не менее, решающим фактором, определяющим общую производительность серверов, были различные условия их эксплуатации.
Проверка концепции
Хотя реальная среда включала лес из 178 доменов Active Directory, модель для проверки концепции в тестовой лаборатории была уменьшена до 13 доменов округов и пустого корневого домена. Во все тестовые домены были экспортированы данные из реальных доменов. Были созданы виртуальные серверы Exchange 5.5, на которых были настроены копии выбранных баз данных округов, так что можно было протестировать процессы миграции и добавления планируемой среды к существующей. Вся тестовая среда для проверки концепции состояла из виртуальных компьютеров, так что она могла быть скомпонована, заморожена и вновь развернута, когда понадобится.
Были разработаны, запрограммированы, протестированы и окончательно оформлены различные комбинации сценариев (использующих язык VBScript), пакеты установщика сервера Systems Management Server (SMS) и консольные приложения. Наконец, имелись сценарии для выполнения первоначальной установки и конфигурирования сервера Exchange 2003, включая настройку политик получателя, глобальных и пользовательских списков адресов и разрешений. Конфигурирование административных групп, доменов округов (создание групп безопасности и делегирование разрешений) и подготовка к миграции после завершения установки также проводились с помощью сценариев.
Установка серверов Exchange 2003 представляла собой значительную проблему. Необходимо было провести установку серверов Exchange во всех 178 доменах, притом сделать это таким образом, чтобы не подвергать риску дальнейший процесс миграции. Сервер Exchange 2003 отличается от Exchange 2000 тем, что группа «Серверы домена Exchange», настраиваемая отдельно для каждого домена, не добавляется в список управления доступом организации до тех пор, пока в домене не будет установлен первый сервер Exchange 2003. (В Exchange 2000 эта группа добавляется при запуске процесса DomainPrep (Подготовка домена)). Чтобы убедиться, что все необходимые группы безопасности внесены в объект организации в Active Directory, нужно было провести установку одного домена, вручную провести репликацию Active Directory с этого домена на центральный сервер репликации Active Directory, а затем перенести эту реплику в следующий устанавливаемый округ. Установка в следующем округе могла начаться только после подтверждения, что список управления доступом объекта организации содержит группу «Серверы домена Exchange» из предыдущего округа. Если бы этот процесс завершился неправильно хотя бы в одном домене, установку в данном округе пришлось бы проводить повторно (по меньшей мере), или другие округи не смогли бы связаться друг с другом из-за того, что объект списка управления доступом содержал бы неправильный список остальных округов.
Процесс развертывания, конфигурирования, установки серверов и миграции тестировался много раз до тех пор, пока он не начал нормально выполняться в тестовой среде.
Миграция и болезни роста
После одобрения проектной группой процедуры проверки концепции и ее результатов можно было начинать миграцию. Первым провести миграцию решило само Управление технических средств обучения, чтобы непосредственно проверить процесс и его последствия. К моменту миграции все серверы уже были размещены и начальное состояние среды проверено. Все серверы предварительной обработки данных и почтовые серверы были на месте и готовы к обслуживанию пользователей.
План миграции был выполнен успешно, и после долгих 21 часа переноса данных с одного сервера на другой УТСО перешло на сервер Exchange 2003. К счастью, не возникло никаких значительных проблем при переносе профилей Outlook с сервера Exchange 5.5 на Exchange 2003. Был создан пакетный файл, который на основе несложных правил вызывал программу ExProfRe.exe в различных конфигурациях. Затем пакетный файл и программа ExProfRe.exe были помещены в папку общего доступа Netlogon контроллера домена в каждом округе, и в конце миграции с помощью политики групп был включен запуск этого пакетного файла для всех клиентов. Этот подход оказался удачным в случае с УТСО, что придало нам уверенности в успешном продолжении проекта.
К этому моменту план миграции был пересмотрен и вновь одобрен с учетом опыта развертывания в УТСО. Для продолжения миграции в качестве первой рабочей площадки были выбраны шесть округов. Перед миграцией каждого округа сервер MIIS должен был прочитать в системе Exchange 5.5 самые свежие данные о почтовых ящиках округа и обновить соответствующих пользователей в домене. Для реального переноса почтовых ящиков из одной организации в другую использовался мастер миграции Exchange (Mailmig.exe). После переноса почтовых ящиков с помощью мастера миграции все адреса прокси-сервера были заменены и обновлены с помощью данных, ранее экспортированных в Active Directory с MIIS-сервера. Во время миграции вся почта должна была накапливаться в очередях на SMTP-серверах переднего плана, а после завершения миграции, настройки серверов и проверки пользователей направляться в округи. Округ был готов к проведению широкомасштабного переноса клиентов с использованием ExProfRe.exe.
Проблемы со службой обновления получателей
Для обеспечения правильной работы клиентов Outlook нужно было, чтобы установка значений атрибутов была произведена именно программой наполнения данными. Для завершения работы по настройке учетных записей необходима была также служба обновления получателей, но она должна была запускаться только тогда, когда закончится наполнение данными. Для выполнения этого условия в графиках запуска экземпляров службы обновления получателей во всех 178 округах было установлено значение Never (Никогда), а в программу наполнения данными был включен код, который запускал службу обновления получателей после завершения работы программы наполнения данными.
В большинстве округов было менее 5 000 пользователей и совсем немного ежедневных обновлений, так что работа службы обновления получателей завершалась быстро, поскольку система наполнения данными в конце ежедневного сеанса просто запускала обновление вместо перестройки. Однако в нескольких округах было более 10 000 пользователей. Обновление в них заняло больше времени, а если бы службе обновления получателей потребовалось провести полную перестройку в этих больших округах, это могло занять неделю или больше. Поскольку служба обновления получателей во время работы вычисляет все типы объектов, проведение перестройки в таких больших округах было изнурительной работой.
Хотя мы не смогли предложить стратегию преодоления этой проблемы (мы пытались найти решение вместе с членами группы разработчиков продукта Exchange), программа наполнения данными была доработана для выполнения большинства тех задач, которые обычно выполняет служба обновления получателей. При первоначальном наполнении данными атрибуты пользователей showInAddressBook (Показывать в адресной книге) и proxyAddresses (Адреса прокси-сервера) устанавливались так, чтобы пользователи могли подключаться к системе сразу, не ожидая завершения работы службы обновления получателей. Была также создана задача, запускавшаяся вручную на одном из серверов предварительной обработки информации Exchange 2003. Она по графику выполняет импорт с помощью инструмента LDIFDE и очищает адрес шлюза gatewayProxy службы обновления получателей, так что, если в среде будет случайно применена какая-либо политика получателя, она не попадет в список выполняемых задач всех служб обновления получателей организации.
Проблемы с классификатором
Одним из интересных аспектов проблемы предотвращения пересылки данных об учащихся за пределы округа было внедрение средств ограничения пересылки учащимися электронных писем за пределы их собственного округа или в Интернет за пределы системы. Вместо разработки сложной системы соединителей и всего, что с этим связано, решено было использовать малоизвестную функцию Exchange 2003 и применить ограничения соединителей для существующего соединителя группы маршрутизации из округа к центральному пункту системы, где находятся серверы предварительной обработки информации. В каждом домене были созданы две группы безопасности – одна для персонала, а другая для учащихся. Эти две группы были добавлены к ограничениям соединителя.
Когда в реестре была включена проверка ограничений соединителя, начали появляться некоторые очень неприятные проблемы в работе. Сообщения часами оставались в классификаторе и локальных очередях доставки, даже если они были отправлены получателю на том же самом сервере. Эти проблемы еще больше усугублялись по мере миграции дополнительных округов на новый сервер. В качестве временного решения была выключена проверка ограничений соединителя, и работа системы доставки почты улучшилась. При дальнейшем рассмотрении выяснилось, что классификатор при получении сообщения проверял принадлежность не только к двум группам внутри собственного домена, но и принадлежность к этим двум группам во всех остальных 177 доменах. И это делалось для всех сообщений, приходящих на сервер и уходящих с сервера.
После этого мы обратились в службу поддержки корпорации Майкрософт. Корпорация Майкрософт провела анализ и в настоящее время работает над созданием исправления, позволяющего классификатору работать в режиме сжатой топологии. Подробной информации об этом исправлении на момент публикации пока нет. Но его цель – обеспечить настройку, позволяющую классификатору делать некоторые допущения о топологии маршрутизации и не проверять принадлежность к группе по всем соединителям.
Взгляд в будущее
Конечно, условия департамента образования штата Кентукки уникальны. В процессе развертывания почти каждая функция Exchange была использована или настроена, чтобы соответствовать требованиям департамента. Теперь, когда вся среда успешно развернута и перенесена, все готово для использования дополнительных возможностей. По мнению департамента образования, школьные округи заинтересованы в использовании платформы Windows Mobile®, и ожидается развитие поддержки мобильных устройств.
Значительные преимущества можно получить от консолидации серверов. Сейчас департамент образования штата Кентукки рассматривает возможность виртуализации некоторых аспектов среды Active Directory. И поскольку приближается выпуск сервера Exchange 2007, департамент начал готовить требования к обновлению системы обмена сообщений.
Департамент образования штата Кентукки рассматривает также дополнительные предложения о сотрудничестве в области применения серверов Live Communication Server, Live Meeting Server и т. д. В настоящее время идет развертывание системы Microsoft Operations Manager 2005 для управления серверами Exchange и Active Directory и слежения за ними.
Извлеченные уроки
Если я и извлекла какой-то урок, работая над этим проектом, то он состоит в том, что все, что мы делаем в качестве консультантов, определяется требованиями заказчика. Много раз нам приходилось сопоставлять возможность выполнения требований заказчика со сложностью решения. Решения, описанные в этой статье, казались нам самыми подходящими в нашей ситуации (включая те ее стороны, на обсуждение которых здесь не было времени) с учетом имевшихся ресурсов и требований заказчика. Возможно, ваши решения будут другими, но, надеюсь, эта статья дала вам материал для размышлений. К счастью для нас, Exchange 2003 и Active Directory обладают достаточной гибкостью для выполнения всех требований такой сложной миграции. Пройдя трудный путь развертывания системы в департаменте образования штата Кентукки, я могу сказать, что само решение довольно несложное и основывается, как мне кажется, на малоиспользуемых возможностях Active Directory и Exchange 2003.
Другой ценный урок – это необходимость уделять равное внимание устранению неисправностей и управлению рисками и проблемами. Иногда неполадки можно устранить на местном уровне, а иногда необходимо привлечь дополнительные ресурсы службы технической поддержки Майкрософт.
Итоги
Эта качественная всеобъемлющая система охватывает каждого ребенка в системе среднего школьного образования штата Кентукки, включая моих собственных детей и детей тех людей, с которыми я работала над этим проектом. Его реализация убедила департамент образования штата Кентукки в необходимости двигаться вперед быстрее, чем когда бы то ни было, с помощью новых технологий и на основе безопасных и стандартизированных методов. Я горжусь тем, что принимала участие в этом проекте.
