Миграция с Exchange 2003 на Exchange 2010 – ситуации. Часть 1.


Продолжение темы:

Миграция с Exchange 2003 на Exchange 2010 – от сомнений к реализации

Миграция с Exchange 2003 на Exchange 2010 – первые шаги

Миграция с Exchange 2003 на Exchange 2010 – ситуации. Часть 1.

 Миграция с Exchange 2003 на Exchange 2010 – ситуации. Часть 2.

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

При миграции с Exchange 2003 на Exchange 2010 используйте два варианта помощи: помощника, который доступен в установщике Exchange, и документацию в библиотеке Technet, в которой есть целый раздел по миграции, включая Check list. Оба варианта содержат последовательные  шаги миграции со ссылками на соответствующие разделы документации.

Документация достаточно высокого качества. Это означает, что в ней есть практически все, что вам нужно для успешной миграции.

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

Перемещение почтовой базы

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

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

Второе замечание: в Exchange 2003 для того чтобы переместить почтовую базу, было достаточно в оснастке управления указать для нее новое место – далее база копировалась туда вместе с логами. В Exchange 2010 перемещение, как показал опыт, требует дополнительных шагов.

Перемещение почтовой базы в Exchange 2010:

1.       Запретить индексацию http://technet.microsoft.com/en-us/library/aa996416.aspx

2.       Переместить базу http://technet.microsoft.com/en-us/library/dd351168.aspx

3.       Включить индексацию

4.       Перезапустить сервис индексации

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

Перемещение почтовых ящиков в новую почтовую базу.

Первое замечание. Установите обновление http://support.microsoft.com/kb/940012 на Exchange 2003.

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

Третье. Проблемы могут проявиться при переносе почтового ящика, после переноса и при дальнейшей работе с почтовым ящиком.

Проблемы при переносе. Вы делаете запрос Move-Request из оснастки управления или командной строки, и он завершается с ошибкой. Каждый такой запрос формирует лог, и в логе вы видите, что Exchange не может скопировать некоторые элементы почтового ящика. В моем случае я обнаружил, что ошибки вызывают невидимые служебные папки вроде ToDo, Free/Buzy и т.п. Так как я переносил ящики группами, то я оставил проблемные ящики и вернулся к ним после переноса основной массы почтовых ящиков. После чего я решил, что раз ошибки возникают не на папках пользователя, а на служебных папках, информация в которых все равно будет пересоздана в новом почтовом ящике, то такие ошибки можно игнорировать при перемещении почтового ящика. В запросе Move-Request увеличиваем счетчик игнорирования ошибок на единицу и выполняем попытку перемещения, смотрим логи ошибок перемещения: если нет ошибок для папок с письмами пользователя, задач и календарей, то увеличиваем счетчик еще на единицу. Практически 80%  моих почтовых ящиков перенеслось сразу, еще 18%  на счетчике равном трем, остальные на счетчике равном от пяти до семи.

Отдельный вопрос возник с почтовыми ящиками пользователей, которые когда-то входили в группу доменных администраторов. Как известно, права на учетные записи доменных администраторов контролирует и выставляет специальный процесс на домен-контроллерах. Учетные записи исключили из группы доменных администраторов, но дело в том, что на учетных записях бывших администраторов остается отключенным наследование прав, в том числе измененными оказываются права на почтовый ящик, что и служит причиной ошибки переноса почтового ящика. Не надейтесь, что выставление галки наследования прав в ADUC на такой учетной записи решит вопрос с переносом всех таких почтовых ящиков: один такой почтовый ящик у меня так и не захотел переноситься, поэтому был удален и создан заново уже в Exchange 2010. Конечно, если у вас будет много таких ящиков, то, возможно, будет оправдано потратить время на поиск причины ошибки и ее устранение.

После переноса почтового ящика проверьте его статус: он должен измениться с Legacy на Native. Если статус другой, то придется разбираться с таким почтовым ящиком. Например, почтовый ящик может отображаться как Linked. Такое бывало и при миграции на Exchange 2007, поэтому решение простое: исправление атрибута,   либо переподключение почтового ящика к учетке пользователя.

Ссылки:

http://technet.microsoft.com/en-us/library/cc164371(EXCHG.80).aspx

http://www.fots.nl/index.php/archive/how-to-convert-linked-mailbox-to-user-mailbox/

http://blogs.technet.com/b/benw/archive/2007/04/05/exchange-2007-and-recipient-type-details.aspx

Почтовый ящик пользователя перенесен и  работает, но он также остался в старой базе. Возможно, при переносе была ошибка, что исходный почтовый ящик не может быть удален.  Выше было рекомендовано установить обновление http://support.microsoft.com/kb/940012 на Exchange 2003 до переноса почтовых ящиков. Если это не помогло, и старый почтовый ящик не удалился, то проверьте, что новый работает нормально. Тогда статус старого почтового ящика скорее всего – отсоединенный, можно не обращать на него внимания и похоронить позже вместе со старой почтовой базой, либо поступить как описано в статье KB940012.

Ссылки:

http://social.technet.microsoft.com/Forums/en/exchange2010/thread/43c11f0e-450e-4ff1-9163-2cb801e2e1e0

http://eightwone.com/2010/06/01/mapiexceptionnotfound-unable-to-delete-mailbox/

http://www.simple-talk.com/sysadmin/exchange/upgrade-exchange-2003-to-exchange-2010/

http://support.microsoft.com/kb/940012

Архивирование почтовой базы

После переноса почтовых ящиков из базы Exchange 2003 в базу Exchange 2010 возникает желание сразу сделать резервную копию новой базы. Если вы еще не успели «накрутить» новый сервер, то операция архивирования базы стандартными средствами пройдет без проблем.

Но стоило мне поднять DAG и попытаться сделать резервную копию базы, как я получил сообщение о том, что база не может быть использована для восстановления — consistency check error. Причина в том, что существует два способа резервного копирования и восстановления баз в Exchange 2010 – традиционное создание резервных копий и DAG. Exchange 2010 спроектирован так, что работает либо одно, либо другое. Поэтому рассмотрите оба варианта и решите, какой использовать. (Это ограничение штатных средств: продукты третьих фирм могут его преодолевать).

DAG дает огромную экономию средств при больших размерах почтовых баз. (Смотрите калькулятор ресурсов Exchange 2010) Но если у вас уже вложены средства в хранилища и систему резервного копирования, то миграция на DAG для вас это вопрос будущего. Хотя возможность миграции на DAG на простое хранилище (JBODSATA 7KRPM) может быть причиной рассмотрения вопроса о высвобождении ресурсов дорогого быстрого и надежного хранилища (RAID5 SCSI 15KRPM), например, под растущие базы данных SQL. В случае DAG рекомендуется делать не менее трех копий почтовой базы на разных (!) хранилищах. Если у вас только два сервера и две копии баз, то возможно вы захотите делать периодические архивные копии базы в DAG для длительного хранения, а копии в DAG использовать как оперативные копии.

Для создания архива базы в DAG нужно выполнить дополнительные шаги, чтобы избежать вышеупомянутой ошибки:

1.       Выключить Microsoft Exchange Replication service VSS http://technet.microsoft.com/en-us/library/dd876851.aspx

2.       Сделать резервную копию базы в DAG

3.       Включить Microsoft Exchange Replication service VSS обратно

Ссылки:

http://technet.microsoft.com/en-us/library/dd876874.aspx

http://blogs.technet.com/b/ehlro/archive/2010/02/13/backup-issues-and-limitations-with-exchange-2010-and-dag.aspx

http://technet.microsoft.com/en-us/library/dd876851.aspx

Обновление фильтров адресных книг

В Check list есть такой пункт и в документации описано, как обновить фильтры стандартных адресных списков с формата LDAP в новый формат OPATH. Но скорее всего у вас есть собственные адресные списки. В моем случае их было более десятка, и все имели сложный фильтр LDAP. Переводить вручную длинную формулу LDAPв формат OPATH трудно и долго. К счастью есть полезный скрипт, который автоматизирует этот процесс. Подробности смотрите в этой статье. Этот же скрипт поможет при миграции фильтров динамических групп рассылки.

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