Red Line Software - мы помогаем вам управлять эффективностью работы вашего офиса.

Если вы пропустили предыдущие части этой серии статей, перейдите по ссылкам:

• Переход с GroupWise на Exchange 2007 – Функциональная совместимость и миграция (часть 1)
• Переход с GroupWise на Exchange 2007 – Функциональная совместимость и миграция (часть 2)
• Переход с GroupWise на Exchange 2007 – Функциональная совместимость и миграция (часть 3)
• Переход с GroupWise на Exchange 2007 – Функциональная совместимость и миграция (часть 4)
• Переход с GroupWise на Exchange 2007 – Функциональная совместимость и миграция (часть 5)
• Переход с GroupWise на Exchange 2007 – Функциональная совместимость и миграция (часть 6)
• Переход с GroupWise на Exchange 2007 – Функциональная совместимость и миграция (часть 7)

О соавторе Деклане Конрое

Вы можете связаться с Декланом так, или через его блог.

Мы будем продолжать говорить о том, что практически закончили! Однако написав эту «последнюю часть», оказалось, что у нас будет еще две части. Так что же мы будем рассматривать? В последних двух частях мы рассмотрим использование Quest GroupWise Migrator для Exchange. В наши намерения не входит воспроизведение документации Quest для пользователей, которая и без того огромна. Мы надеемся дать вам подробную картину того, что делает инструмент, почему, и как его использовать по максимуму. Эта статья охватывает основы инструментов Quest, а затем проводит по половине пути миграции. В последней статье будут рассмотрены окончательные шаги процесса перехода!

Миграция рабочей станции или сервера, XP или 2003

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

Мы использовали XP на рабочей станции миграции по двум причинам. Мы работаем с VM лабораторией, поэтому мы просто использовали XP виртуальный ПК, на котором тестировали Outlook и GroupWise. Во-вторых, здесь не требуется серверная ОС или серверное оборудование, что для большинства людей является преимуществом.

Если вы все же хотите использовать Windows Server 2003 Server, предварительные условия остаются теми же за исключением мест загрузки, поскольку некоторые компоненты, такие как DOT.NET, имеют специфичные для ОС версии.

• Загрузите и установите x86 DOT.NET Framework 2.0 Service Pack 1.
• Загрузите Windows PowerShell для Windows Server 2003.
• Если нужно, загрузите MMC 3.0 для Windows Server 2003 здесь. MMC 3.0 включена в SP2.
• Вы можете получить Windows Server 2003 SP2 AdminPak отсюда.
• Windows Server 2003 SP2 AdminPak может запросить SP2 CD во время установки. Если вы, как и я, устанавливали SP2 с Windows Update, то самым простым решением этой проблемы на мой взгляд является откат к SP1, и установка SP1 AdminPak отсюда.

Когда вы заново применяете SP2, AdminPak будет обновлен.

Прежде чем начать

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

Мы сделали некоторые предположения.

• Мы предположили, что исходная GroupWise и целевая Exchange системы настроены правильно для перехода. Мы полностью понимаем, что в реальности это может не всегда быть так, но просто существует слишком много возможных причин и проблем, в силу которых миграция может быть безуспешной, поэтому мы не сможем охватить их здесь.
• Мы также предположили, что вы следовали всем семи предыдущим частям этой серии статей и создали пользовательские объекты Active Directory, используя коннектор MS Exchange для Novell GroupWise.

Существует множество способов создания пользовательских объектов в AD, однако двумя самыми распространенными в процессе перехода с NDS на AD является использование ПО для перехода MSDSS или с NDS на AD от компании Quest. Преимущество использования коннектора MS Exchange заключается в том, что он создает пользовательские объекты в AD на основе GroupWise директории, а не на NDS.

Помните, GroupWise сохраняет свою директорию отдельно от NDS. Это очень похоже на ситуацию с Exchange 5.5 на NT 4.0. Если вы создадите свои пользовательские объекты AD на основе NDS, есть стадия в процессе миграции, во время которой GroupWise объекты и AD объекты (ранее NDS объекты) объединяются для создания единого набора целевых объектов.

Это объединение может вызывать проблемы. Представьте очень распространенный сценарий, в котором NDS и GW объекты созданы для Карен Смит, которая становится Карен Джонс после замужества. Очень часто GroupWise объект обновляется, поскольку адрес электронной почты является видимым. А NDS объект может обновляться или не обновляться, в результате эти объекты могут не объединиться.

У нас были подобные проблемы, где объекты GroupWise имели разное написание, или где имена, написанные через дефис или другие общие имена обрабатывались по-разному между NDS и GW.

Объекты, которые не были объединены, регистрируются логами в утилите AD Object Merge, и вам зачастую приходится проделывать большие объемы чистки данных.

Поскольку мы создали наши объекты AD непосредственно из директории GroupWise, этот шаг становится гораздо проще.

Пакет Quest Software Suite

Существует пакет продуктов и инструментов в ПО Quest:

• Directory Exporter
• Active Directory Object Merge Tool (инструмент управления объектами AD)
• Administrator Driven Batch Migrator
• Self-Service Desktop Migrator
• Quest Log File Viewer

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

Все начинается с Directory Exporter. Эта утилита должна быть запущена в первую очередь.

Когда вы запускаете Directory Exporter, он запрашивает почтовый ящик GroupWise и пароль, TCP/IP адрес или имя хоста Post Office, использующего GWIA, и наконец Путь домена, как показано на рисунке 1:

Заметка: У вас должен быть GWIA в домене GroupWise Domain, иначе Quest не будет работать корректно

Рисунок 1: Ввод информации GroupWise в Directory Exporter

Затем Directory Exporter подключается к GroupWise и извлекает адресную книгу, как показано на рисунке 2.

Рисунок 2: Directory Exporter подключается к GroupWise, чтобы считать информацию из адресной книги

Стадии миграции отображены на рисунке 3.

Сначала directory exporter входит на GroupWise и извлекает специфичный post office вид директории GroupWise. Каждому объекту в GroupWise может быть задан один из четырех уровней видимости: Нет Домен Система Почта (Post Office) Directory Exporter извлечет список всех объектов GroupWise с видимостью системы. Смысл заключается в том, что существуют определенные почтовые ящики или объекты, которые имеют видимость Post Office, и они не могут быть извлечены, если только вы не используете почтовый ящик в той же почте (post office). Самый безопасный способ убедиться в том, что вы захватили все объекты GroupWise, это использовать почтовый ящик на каждой Post Office в системе, объединить все получившиеся экспортированные файлы в один файл, и удалить все дубликаты. Несмотря на то, что этот шаг довольно нудный, он очень важен. Это, по большому счету, игра цифр. Нам нужно понять, с каким количеством объектов мы начали, сколько было перемещено, и почему (если таковые есть) некоторые из них не были перемещены. Нам нужно иметь возможность объяснить цифры. Quest Directory Exporter создает четыре файла, которые используются в качестве вводимых файлов другими утилитами пакета. Эти файлы перечислены в таблице 1.

Эти четыре файла являются основным набором файлов. Я бы посоветовал скопировать их в безопасное место. Вам придется много работать с этими файлами, и резервная копия обязательно понадобится, поверьте мне.

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

Три или четыре файла практически идентичны.

• UsersToMigrate.csv
• UsersToMerge.csv
• AddressTranslation.csv

UsersToMigrate.csv имеет дополнительный заголовок в столбце L, SearchKey, но за этим исключением файлы абсолютно одинаковы.

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

Хитрость работы с этими файлами заключается в постоянной работе с копией файла UsersToMigrate.csv, и последующем ее сохранении в виде двух файлов UsersToMerge.csv и AddressTranslation.csv.

Если вы используете отдельный набор файлов миграции, называйте их говорящими названиями типа Фаза-1-Переход, Фаза-1-Объединение и Фаза-1-Трансляция.csv

Объединение объектов AD

Как только мы осуществили необходимый экспорт директории, нам нужно выполнить объединение объектов AD. Это позволяет убедиться в том, что все пользовательские объекты AD корректно сопоставлены с соответствующими GroupWise почтовыми ящиками, и необходимо в основном потому, что (как мы говорили ранее), самым частым источником AD объектов является NDS, а не GroupWise.

Посмотрите на файл UsersToMerge.csv.

В нем есть два интересных поля, ObjType и NDSUsername.

ObjType перечисляет различные значения, где 0 соответствует пользователю или внешнему объекту, 2 - это группы распространения и 3 - это ресурс GroupWise. Это три самых основных типа объектов в экспорте директорий.

Обратите внимание, что для каждого типа объекта 2 или 3 отсутствует значение NDSUsername.

Содержимое атрибута NDSUsername сопоставляется с именем User logon name (pre-Windows 2000): поле вкладки пользовательской Учетной записи в Active Directory, как показано на Рисунке 4.

Рисунок 4: Поле входа Pre-Windows 2000

Экспорт директории может также содержать объекты, синхронизированные через коннектор с Exchange, и хотя у них есть ObjType со значением 0, у них также отсутствует значение NDSUsername.

Моя экспортируемая директория содержит 21 объект.

• 11 пользователей
• 6 групп распределения
• 2 ресурсных почтовых ящика
• 1 внешний объект
• 1 Exchange пользователь.

Когда я запускаю инструмент Active Directory Object Merge Tool, после указания исходного файла, содержащего список объектов для объединения, у меня есть три варианта того, как найти пользователей в Active Directory, как показано на рисунке 5.

• Найти объект по Pre-Win2K имени пользователя
• Найти пользователей из базы данных Quest NDS Migrator
• Найти объект по атрибуту.

Рисунок 5: Выбор способа поиска пользователей в Active Directory

Если я просто выполню объединение объектов AD, используя умолчания pre-Win2K имени пользователя, любые объекты с отсутствующим значением для атрибута NDSUsername не будут объединены.

Как только я понимаю, что все ObjType 2 и 3 и один из моих ObjType 0 (пользователь exchange) дали сбой, цифры добавились, и я получил 11 успешных объектов и 10 ошибок из общего количества 21 объекта, как показано на рисунке 6.

Рисунок 6: Панель результатов Merge Tool

Если я проверю содержимое Отчета объединения, я увижу, что все пользователи с атрибутом NDSUsername были объединены, а все остальные нет.

• Мой пользователь exchange не был объединен, но это не проблема.
• Мои группы распределения не были объединены, и опять же, это вполне понятно.
• Мои ресурсные почтовые ящики не были объединены, равно как и внешний объект, а это уже проблема.

Цифры здесь ДОЛЖНЫ добавиться. Если нет, вам необходимо остановиться и выяснить, почему. На ранних этапах проекта цифры могут казаться трудностью, но неизбежно придет тот день ближе к концу, когда нужно будет вести подсчет, и если вы не до конца поняли эти цифры, остановитесь, и продумайте, чтобы понять все до конца.

Здесь у меня есть два основных выбора. Я могу возиться с цифрами по мере их добавления и понять их, или передать данные в .csv файл, чтобы получить четкие результаты.

Например, если я удалю группы распределения и пользователя exchange из своего UsersToMerge.csv файла, у меня останется 14 объектов.

• 11 пользователей,
• 2 ресурсных почтовых ящика
• 1 внешний объект

Далее самым простым решением будет заполнение полей NDSUsername для этих объектов с помощью значений, взятых из AD объектов, с которыми я пытаюсь их объединить, что, как правило, является полем Userid, рисунок 7.

Рисунок 7: Заполнение NDSUsername поля

Однако следует отметить, что мои User login names имена не содержат пробелов, где они содержат их в почтовых ящиках GroupWise, например Board Room в GroupWise стала BoardRoom в Active Directory, поэтому мне нужно удалить пробелы, и тогда на этот раз у меня получится абсолютно успешное объединение объектов AD, как показано на рисунке 8.

Рисунок 8: Чистое объединение объектов AD

Резюме

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

Если вы пропустили предыдущие части этой серии статей, перейдите по ссылкам:

• Переход с GroupWise на Exchange 2007 – Функциональная совместимость и миграция (часть 1)
• Переход с GroupWise на Exchange 2007 – Функциональная совместимость и миграция (часть 2)
• Переход с GroupWise на Exchange 2007 – Функциональная совместимость и миграция (часть 3)
• Переход с GroupWise на Exchange 2007 – Функциональная совместимость и миграция (часть 4)
• Переход с GroupWise на Exchange 2007 – Функциональная совместимость и миграция (часть 5)
• Переход с GroupWise на Exchange 2007 – Функциональная совместимость и миграция (часть 6)
• Переход с GroupWise на Exchange 2007 – Функциональная совместимость и миграция (часть 7)

Автор: Натан Уинтерс(Nathan Winters)

Натан Уинтерс – консультант по унифицированным коммуникациям для Dimension Data. В первой половине 2006 Натан основал Microsoft Messaging and Mobility User Group UK. В апреле 2007 Натан был награжден MVP (Exchange Server) за свою работу с MMMUG и за пожертвование в Mark Minasi Forum. Вы можете написать Натану на Nathan@clarinathan.co.uk или блог.