Главная Exchange/UC, Новое Миграция с Exchange 2007 на Exchange 2010 в системах с кластерами
  • Миграция с Exchange 2007 на Exchange 2010 в системах с кластерами

    BOX_Microsoft-Exchange2010 Добрый день! Хочу рассказать о своем опыте внедрения Exchange Server 2010. Первоначально этот документ планировался как Step-By-Step Guide для коллег, однако позже он перерос в доклад на заседании MCP-клуба.

    Я работаю системным администратором в небольшой организации, начитывающей 200-250 рабочих мест. Отрасль – энергетика. Регион – Сибирь. Предприятие является головным для нескольких подконтрольных компаний с общей численностью в 4'000 рабочих станций, но при этом само является звеном федерального холдинга. Работа части сотрудников связана с регулярными командировками по разным часовым поясам. В связи со всем вышеперечисленным, почтовый сервис является бизнес-критическим приложением.

    Вот собственно и всё техническое задание.

    До начала миграции на Exchange 2010, почтовая система базировалась на Exchange Server 2007 SP2 и состояла из 6-ти серверов: два EDGE hub transport, будем называть их mx10 и mx20, два сервера с ролью Mailbox (Exch03 и Exch04) объединены в кластер Exch06 по технологии Cluster Continues Replication (CCR), и два сервера (Exch01 и Exch02) c установленными ролями Hub Transport и Client Access (объединен в NLB-кластер Exch00). Все серверы виртуальные, их жесткие диски хранятся на Системе Хранения Данных. Диски с базами данных подключены напрямую, Pass Through.

    Дополнительная информация:

    • Все серверы Exchange обновлены до SP2
    • Все серверы находятся в одном сайте.
    • Есть пользователи, использующие Outlook Web Access, опубликованный через ISA Server.
    • Уровень леса и домена – Windows 2008 R2.
    • Сервер сертификации собственный, без использования коммерческих сертификатов.
    • Роль сервера единой системы сообщений не используется.

    Цель перехода — получить аналогичную архитектуру под управлением Exchange 2010. В идеале, хотелось бы использовать четыре сервера, установив роли Hub Transport, Mailbox и Client Access на одном сервере. Однако настораживает ситуация с внешним балансировщиком, а метод DNS Round Robin здесь, на мой взгляд, явно не применим. Поэтому будет строиться аналогичная архитектура из шести серверов.

    Спросите почему Exchange 2010? Куда торопиться? Многие говорят про продукцию Microsoft: "Нужно дождаться выхода первого Service Pack, до него много глюков". Но, во-первых, я считаю, что в последнее время даже большинство beta-версий выходит с высокой степенью готовности, а во-вторых, мои mailbox'ы хранятся на SAN. В последнее время места на SAN катастрофически не хватает, и были приобретены два физических сервера для переноса роли почтовых ящиков.

    И вот, чтобы не делать работу дважды, освобождая место на SAN, заодно и перейдём на Exchange 2010.

    По ходу повествования буду вставлять ссылки на те статьи, которые мне помогли в работе. Отдельное спасибо Ивану Макарову и Лаврецкому Андрею за доклады "Новые возможности по хранению данных и обеспечению отказоустойчивости в Exchange 2010" и "Переход на Exchange 2010 с предыдущих версий " на TechDays.ru.

    Стратегия перехода

    Для начала поступим как ламеры, и посмотрим документацию на TechNet: Exchange 2007 — Planning Roadmap for Upgrade and Coexistence:

    Затем найдём этот же слайд на русском языке:


    Он взят с презентации "Переход на Exchange 2010 с предыдущих версий", показанной на Платформе 2010, и оба они показывают порядок миграции с 2007-ой версии на 2010-ую.

    Возьмём оттуда же ещё пару слайдов и воспользуемся рекомендациями по созданию сертификатов и DNS-имен:

    После того как "ознакомились с документацией", составляем укрупненный план перехода:

    1. Подготовка серверов.
    2. Установка ролей Client Access и Hub Transport.
    3. Настройка и проверка CAS.
    4. Объединение серверов Client Access в NLB-кластер.
    5. Проверка работы существующих пользователей.
    6. Установка ролей mailbox на физические сервера.
    7. Перенос собственного почтового ящика на Exchange 2010.
    8. Перенос ящиков тестовой группы пользователей на Exchange 2010.
    9. Замена одного сервера с ролью EGDE Hub Transport на Exchange 2010.
    10. Тестирование и ещё раз тестирование.
    11. Замена второго сервера с ролью EGDE Hub Transport на Exchange 2010.
    12. Перенос оставшихся почтовых ящиков на Exchange 2010.
    13. Деинсталляция ролей Exchange Server 2007 с серверов.

    Настройки существующих CAS-серверов остаются неизменными, и в случае, если что-то пошло бы не так, как планировалось, существующие пользователи ничего бы не заметили.

    Хочется сделать небольшую ремарку. Разумеется, чтение документации не ограничивалось просмотром "лекции о любви с показом слайдов". А во-вторых этот план подходил для МОЕГО сценария миграции. Для Вашего сценария миграции, скорее всего, будет другой план перехода.

    Подготовка серверов

    На двух новых серверах проверяем firmware на актуальность, устанавливаем Windows Server 2008 R2. Серверы с двумя Ксеонами, 24Gb RAM и 16-ю дисками 146GB 15K. Осознаю, что вычислительной мощи с избытком, а диски за ту же цену было бы лучше взять 300GB 3G SAS 10K SFF DP ENT HDD или даже 500GB 3G SATA 7.2K 2.5in MDL HDD, но так получилось…

    На установку Firmware, Win2008R2 и драйверов ушло примерно полтора часа. Ещё полчаса ушло на подготовку двух виртуальных серверов (40 GB HDD, 2 CPU, 4 Gb RAM) для Client Access и Hub Transport. Полчаса на установку обновлений. Итого два c половиной часа на подготовку физической среды. У нас не используется ни Library для VMM, ни System Center Configuration Manager, только Windows Deployment Services. Эта служба входит в состав Windows Server, и очень облегчает жизнь при установке Windows 7, Windows Server 2008 и Windows Server 2008 R2. Очень рекомендую.

    Напомню что Service Pack 2 уже был установлен
    на всех серверах Exchange.

    Настройка Split-DNS

    Согласно новой доктрине Microsoft, озвученной, например, в документе "Пошаговое руководство по использованию службы доменных имен в небольших сетях", рекомендуется отказаться от использования зоны local в пользу реальных имен и доменов третьего уровня. Приведу пример на стандартном домене: пусть в нашей компании зарегистрирован домен contoso.com, а внутри используется домен corp.contoso.com. Давайте посмотрим как за две минуты настроить Split-DNS.

    В оснастке "Active Directory — домены и доверие" на самом верхнем уровне вызываем свойства:


    И добавляем домен второго уровня contoso.com:

    Нажимаем "ОК", закрываем, и переходим в оснастку "DNS". В зонах прямого просмотра видим, что у нас всё как обычно:


    Теперь добавляем новую зону:







    Смотрим, что у нас получилось:

    Мы видим домен третьего уровня и автоматически созданный в нем контроллер домена:


    Создаем A-запись mail.contoso.com для кластераCAS:




    Хотелось бы поподробнее остановиться на зоне contoso.com. Если у вас есть внешний www-сервер, или какие-нибудь другие серверы, доступные из Интернета, то Вам необходимо создать в этой зоне А-записи для всех имен, зарегистрированных во внешнем DNS. В противном случае пользователи не смогут обратиться к этим ресурсам, так как DNS не сможет предоставить их IP-адреса.

    И да, забыл добавить, нужно создать ещё одну A-запись: autodiscover.contoso.com с тем же IPадресом.

    Рекомендации по использованию Split DNS так же встречал мной при развертывании Office Communication Server.

    Настройка ролей Client Access и Hub Transport

    Перед установкой необходимо проверить Exchange 2010 System Requirements, и воспользоваться Exchange 2010 Prerequisites для установки пререквизитов. Так же необходимо ознакомиться со статьёй Upgrading from Exchange 2007 Client Access.

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

    Хочу дорисовать свою ситуацию, чтобы был понятен сценарий миграции:

    Время сосуществования Exchange 2007 и Exchange 2010 будет минимальным, столько сколько нужно на настройку, тестирование и перенос почтовых ящиков. Поэтому пункт "Creating a set of legacy host names that will be associated with the version of Exchange you're upgrading from" не использовался. Доступ к OWA 2010 снаружи будет перенастроен в самом конце, после перемещения почтовых ящиков пользователей, его использующих.

    Установка.

    При первом запуске появилось окно:


    Настораживает пункт 3 – выбрать язык. Кстати, дистрибутив не бета, не триальный, а с сайта licensing.microsoft.com, по подписке Software Assurance. Выбрать ТОЛЬКО русский язык у меня не получилось. При выборе "Установить все языки из языкового пакета" появляется окно:

     

    Перерыв все папки, ничего не нашел – наверное не по глазам. После выбора второго из пунктов картинка меняется:


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


    Хочу напомнить что "Обычная установка" помимо установки ролей и средств управления настраивает организацию Exchange на работу с внешней почтой.

    То есть если вы установите на одном сервере выборочные роли, на сервере в DMZ установите EDGE, а затем выполните внутри "Обычную установку", то почта у Вас не пойдёт на EDGE, а пойдёт на "обычный" сервер, где и застрянет.

    А вот такой скриншот мне ни у кого не попадался, так как большинство людей для тестов ставили "обычную установку"

    Настраивать доступ в Интернет будем на EDGE Hub Transport, поэтому пропускаем.


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

    Дальше переходим на окно проверки готовности и получаем ошибку:

    От этой ошибке помогает командлет: Set-Service NetTcpPortSharing -StartupType Automatic

    При установке пререквезитов пользовался командлетами, подготовленными в библиотеке TechNet. Оказывается, для версии Windows Server 2008 R2 забыли добавить "Службы общего доступа к порту Net.Tcp", а вот для Windows 2008 этот пункт был. После добавления компонента повторяем попытку:

    Всё установлено, и про второй CAS наверное ничего рассказывать не имеет смысла – там всё аналогично.

    Запрос сертификатов.

    Существует несколько способов запроса сертификатов для Exchange-серверов. Это и через оснастку IIS,и через командлет PowerShell, и через web-службу центра сертификатов. Но, на мой взгляд, наиболее удобным способом является способ запроса сертификатов с помощью оснастки MMC.

    1. На центре сертификации запускаем оснастку "Центр сертификации" и говорим "Управление" на "Шаблонах сертификации".

    1. Правим свойства шаблона "Веб-сервер", где на вкладке "Безопасность" добавляем наши серверы и добавляем права "Заявка".

    1. На сервере CAS запускаем mmc и добавляем оснастку "Сертификаты", "Управление компьютером", "Локальным компьютером", и запрашиваем новый сертификат:

    1. В параметрах сертификата заполняем следующие значения:

    Где CN – это "Общее имя". Именно в нем мы должны создать Wildcard – указав "звёздочку" в имени домена. Обязательными являются поля "CN" и "Служба DNS", в которой должны быть перечислены ВСЕ имена узлов кластера. Есть одна маленькая, но важная хитрость – имя кластера должно быть первым, иначе работать не будет. Можно настроить IIS таким образом, чтобы при обращении из локальной сети к узлу кластера по короткому имени, OWA не будет запрашивать логин и пароль, а при обращении по полному имени – будет. Можно заполнить поле "Понятное имя" – оно служит для идентификации сертификата

    Ещё один важный момент – необходимо сделать сертификат экспортируемым, так он нам будет нужен на всех узла кластера:

    И завершаем подачу заявки:


    Экспортируем сертификат с первого CAS'а, импортируем его на второй и проверяем что он у нас прописался именно в "Локальном компьютере", а не в "текущем пользователе".

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

    • Get-Help Enable-ExchangeCertificate    -Examples
    • Get-ExchangeCertificate
    • Enable-ExchangeCertificate

    Первый выведет Вам пример командной строки, второй – текущие сертификаты, и для каких служб они используются. А затем с помощью Copy-Paste Вы легко сгенерируете третий командлет из первых двух.

    Настройка NLB-кластера

    На серверах с установленными ролями CAS и Hub Transport устанавливаем компонент "Балансировка сетевой нагрузки" и создаем кластер:


    Дальше вводим ip-адрес нового кластера:


    Вводим имя кластера:

    Если Вы используете маршрутизаторы Cisco, вам там нужно зафиксировать MAC-адрес кластера, иначе он не будет виден из других сегментов сети.

    Порты управления сделал все. Рекомендации по настройке NLB для серверов CAS приведены в докладе "Переход на Exchange 2010 с предыдущих версий", а полный список используемых портов опубликован на TechNet.

    Добавляем второй узел к кластеру:

    Создание массива серверов клиентского доступа

    Сначала нужно убедиться что массив у нас отсутствует:
    Get-ClientAccessArray

    Затем создаем массив:

    New-ClientAccessArray -Fqdn "mail.contoso.com" -Site "Default-First-Site-Name"

    Настройка CAS-сервера

    Сначала добавляем группу "Exchange Trusted Subsystem" в группу локальных администраторов на серверах Exchange 2007. В противном случае при переходе в настройки OWA и ECP на серверах CAS Exchange 2010 Вы будите получать ошибку:

    Не удалось создать запись каталога служб IIS. Сообщение об ошибке — "Отказано в доступе. ".HResult = — 2147024891 Выполнялась команда "Get-OwaVirtualDirectory"

    Следующим шагом отключаем Outlook Anywhere на серверах клиентского доступа Exchange 2007:

    Переходим в консоль управления Exchange 2010 и в "Клиентском доступе" на уровне "Конфигурации организации" ничего интересного не находим:

    Переходим в настройки серверов:

    На этом этапе хочу напомнить один слайд:

    На нем нас интересуют параметры веб-служб, а именно Internal и External URL'ы. Меняем наши параметры в соответствии с рекомендациями, приведенными в таблице, на обоих узлах кластера:

    Включаем Outlook Anywhere на всех узлах кластера:

    Запускаем командлеты на всех узлах кластера:

    Set-WebServicesVirtualDirectory -InternalUrl https://mail.contoso.com/EWS/Exchange.asmx

    Set-WebServicesVirtualDirectory -ExternalUrl https://mail.contoso.com/EWS/Exchange.asmx

    Set-ClientAccessServer –AutoDiscoverServiceInternalUrl https://mail.contoso.com/Autodiscover/Autodiscover.xml

    Продолжаем.

    Настройка роли Hub Transport.

    В нашей организации у некоторых сотрудников существует специализированное программное обеспечение, работающее по протоколам POP3/SMTP. Для таких пользователей, а так же для серверов SharePoint, нам нужно создать разрешающее правило доступа с ограниченного числа IP-адресов. Для этого на одном из серверов с ролью Hub Transport создаем "Соединитель получения":

    Так же необходимо указать почтовый сервер и в самом SharePoint, но уже перед удалением из организации Hub Transport'а Exchange 2007.

    Создание кластера MailBox (DAG)

    Как обычно – устанавливаем обновления и пререквезиты, выбираем роль сервера почтовых ящиков

    Настройка групп доступности базы данных (DAG)

    Очень рекомендую цикл статей "Настройка DAG в Exchange 2010 RTM" – там очень подробно описано, что нужно настраивать и, главное, для чего.

    Я пошел немного другим путем, и не стал подключать второй интерфейс. Причина в том, что два сервера у меня пока стоят рядом, а в разные ЦОДы будут разнесены позже, тогда и будет настроен heartbeat.

    Для создания файлового ресурса–свидетеля используем первый из серверов CAS 2010. Заходим на него и проверяем что в группу "Администраторы" включена группа "Exchange Trusted Subsystem". Если Вы создаёте ресурс-свидетель не на сервере с Exchange 2010, а, например, на файловом сервере, не забудьте добавить эту группу в группу локальных администраторов.

    Первым делом что я сделал – это переименовал имена созданных автоматически баз данных.


    Затем заходим в "Группы доступности" и создаем новую группу.

    Имя группы доступности базы данных будет использоваться в качестве имени кластера (читайте компьютера). Если вы используете унифицированную систему именования серверов, Вам необходимо указать имя DAG в соответствии с Вашими корпоративными стандартами. Так как мы создавали DAG с помощью графического интерфейса, то он получает ip-адрес с помощью DHCP. Меня это не устраивает, и поэтому задаем ip вручную:

    Set-DatabaseAvailabilityGroup -Identity exch05 -DatabaseAvailabilityGroupIPAddresses 192.168.111.33

    Добавляем узлы (члены группы доступности базы данных):

    Как видите, в новой версии кластер собирается гораздо проще, чем в Exchange 2007. Как мы можем убедиться, что всё прошло успешно?

    Сначала находим новый компьютер в AD:


    Затем смотрим его в DNS:


    Да, серверов Exchange в организации оказалось так много, что даже страшно становится. Но не забываем что у нас четыре кластера по два узла, которые создают ещё по несколько дополнительных, "виртуальных" имен.

    И напоследок смотрим в "Диспетчере отказоустойчивого кластера"


    На самом деле интереснее сначала добавить один узел, затем открыть оснастку "Диспетчер отказоустойчивого кластера", а затем добавить второй узел. При этом было видно, как второй узел появляется в остановленном состоянии, и затем переводится в оперативное.

    Создание отказоустойчивой базы

    Создаем новую базу почтовых ящиков:


    Раньше строго рекомендовалось разносить базы и журналы по разным дискам, но доверимся компании Microsoft, которая утверждает, что нагрузка на диски существенно снизилась:

    Дальше самое главное – добавляем копию базы данных почтового сервера:

    И получаем следующее:

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


    Это специальные временные ящики, участвующие в процессе модерирования или одобрения сообщений. Они создаются при установке первого сервера Exchange 2010 с ролью mailbox в первой базе.

    Для поиска данных почтовых ящиков необходимо запустить следующую команду:

    Get-Mailbox -Database "exch-10" -arbitration

    Get-Mailbox -Database "exch-10" -arbitration | New-MoveRequest -targetdatabase base01

    Перемещение почтовые ящиков

    Выбираем почтовый ящик и создаем "локальный запрос на перемещение":

    Удаленный запрос используется в сложных, многодоменных организациях

    "Создать локального запроса" – как-то не по-русски немного звучит…

    Мы получаем запросы на перемещение почтовых ящиков:

    В RTM-версии вручную за один раз можно было удалить только один запрос. Если необходимо было очистить множество запросов, выполнялся командлет:

    Get-MoveRequest –MoveStatus Completed | Remove-MoveRequest

    После установки у себя RollUp2 такая фича исчезла, и теперь из графического интерфейса можно удалить за один раз несколько запросов на перемещение.

    Это может Вам потребоваться, если Вы захотите удалить какую-нибудь базу данных, например созданную по умолчанию с "некрасивым" именем, или передумаете переносить ящик пользователя в base1, а захотите перенести его в base2.

    При перемещении почтового ящика из базы в базу в пределах Exchange 2010 Microsoft Outlook 2010 выдает сообщение "Администратор системы внес изменения. Необходимо закрыть Outlook и открыть заново". Во время переноса с Exchange 2007 на Exchange 2010 ящик остается доступным.

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

    Настройка автономной адресной книги.

    Однако, когда создал OAB и начал её сравнивать с существующей, то добавил ещё один сервер:

    Установка роли EDGE Hub Transport

    Подготовка системы

    У нас имеется два сервера с ролью EDGE HUB Transport. Для начала уберём подписку на второй сервер mail2, затем переустановим на нем Windows, обновив до версии Windows 2008 R2.

    Начинаем как обычно, с переустановки пререквезитов:

    PS c:>\ Import-Module ServerManager

    PS c:>\ Add-WindowsFeature NET-Framework,RSAT-ADDS,ADLDS –Restart

    Так как сервер не в домене, создаем A-запись в DNS.

    Сорок минут и сервер готов к установке Exchange.

    Алгоритм ввода в эксплуатацию EDGE 2010 описан здесь. Приступаем.

    Переподписка Exchange 2007 EDGE после ввода Exchange 2010 Hub

    После ввода в эксплуатацию первого Exchange2010 Hub Transport, необходимо переподписать все серверы c ролью пограничного транспортного сервера. Для этого мы на оставшемся EDGE 2007 создаем файл подписки:

    PS c:>\ New-EdgeSubscription -FileName "C:\EdgeSubscriptionInfo.xml"

    И в конфигурации организации запускаем мастер "Создать пограничную подписку":

    Установка роли EDGE Hub Transport

    Выбираем выборочную установку и затем "Роль пограничного транспортного сервера"

    Запускаем консоль управления Exchange и вводим серийный номер – установка завершена.

    Создание подписки Exchange 2010 Edge Server

    На mail2 выполняем командлет (запустив PowerShell с правами администратора):

    PS c:>\ New-EdgeSubscription -FileName "C:\EdgeSubscriptionInfo.xml"

    Снова в конфигурации организации запускаем мастер "Создать пограничную подписку".

    Клонирование конфигурации EDGE Transport

    Процедура клонирования описана на сайте Technet. На сервере – источнике выполняем командлет ExportEdgeConfig.ps1 c:\exp.xml

    На новом сервере переходим в папку "C:\Program Files\Microsoft\Exchange Server\V14\Scripts", выполняем проверку:

    .\importedgeconfig.ps1 -cloneConfigData c:\exp.xml -isImport $false -CloneConfigAnswer c:\ExpAnswer.xml

    И получаем предвиденную ошибку:

    Она получилась из-за того что мы импортируем параметры с другого компьютера. Открываем файл ответов exp.xml на изменение и исправляем старое имя сервера на новое. Проводим проверку ещё раз и получаем положительный результат:

    На "всякий пожарный" делаем экспорт "чистой, свежеустановленной" конфигурации: .\ExportEdgeConfig.ps1 c:\exp.xml

    Запускаем импорт конфигурации:

    ./importedgeconfig.ps1 -cloneConfigData c:\exp.xml -isImport $true -CloneConfigAnswer c:\expanswer.xml

    И получаем кучу предупреждений:

    Эту задачу нельзя выполнить на пограничном транспортном сервере, подписанном на сайт Active Directory. Необходимо выполнить эту операцию с помощью консоли управления на транспортном сервере-концентраторе или удалить пограничную подписку с помощью командлета Remove-EdgeSubscription.

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

    Подтверждение

    Вы действительно хотите выполнить это действие?

    Удаление записи фильтра вложений "ContentType:application/x-msdownload".

    [Y] Да — Y [A] Да для всех — A [N] Нет — N [L] Нет для всех — L [S] Приостановить — S [?] Справка

    (значением по умолчанию является "Y"):a

    И принимаем в ответ:

    Importing Edge configuration information Failed.

    Reason: Не удается привязать параметр "ExpirationTime". Не удается преобразовать значение "12/31/9999 23:59:59" в тип "S

    ystem.DateTime". Ошибка: "Строка не распознана как действительное значение DateTime."

    Открываем файл конфигурации и видим:

    Оказывается "Белый список IP-адресов" имеет предельное значение до 23:59:59 31.12.9999 года.

    Правим файл конфигурации: просто удаляем все строки с этим текстом, и запускаем импорт ещё раз.

    Открываем консоль управления, защиту от нежелательной почты и проверяем:

    Вроде все есть.

    Заходим в журнал событий Windows и находим ошибку:

    SmtpReceiveProtocolLogs: не удается создать каталог журналов C:\Program Files\Microsoft\Exchange Server\TransportRoles\Logs\ProtocolLog\SmtpReceive из-за ошибки: Отказано в доступе по пути "C:\Program Files\Microsoft\Exchange Server\TransportRoles\Logs\ProtocolLog\SmtpReceive"... До устранения проблемы журналы не будут создаваться.

    И ещё несколько аналогичных с другими журналами. В версии Exchange 2010 по сравнению с Exchange 2007 поменялось место хранения журналов. Открываем наш вышеустановленный Hub Transport 2010 и копируем пути оттуда в EDGE. А можно исправить файл конфигурации, заменив "C:\Program Files\Microsoft\Exchange Server\TransportRoles\Logs\" на "C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\" и импортировать настройки ещё раз.

    Перезагружаем службу "Транспорт Microsoft Exchange"

    Перенос транспортных правил с одного сервера на другой.

    Для переноса правил воспользуемся командлетами Export-TransportRuleCollection и Import-TransportRuleCollection.

    На сервере-источнике запускаем: Export-TransportRuleCollection c:\TrRu.XML

    Копируем файл на новый сервер и импортируем в два шага:

    [PS] C:\>[Byte[]]$Data = Get-Content -Path C:\distr\trru.xml -Encoding Byte -ReadCount 0

    [PS] C:\>Import-TransportRuleCollection -FileData $Data

    Удаление организации Exchange 2007

    Удаление организации Exchange 2007 происходит в три этапа:

    Во-первых, выключаем наш сервер mail1 (работающий на Exchange 2010) и проверяем что через mail2 (новый EDGE от Exchange 2010) почта в Интернет ходит. Затем удаляем подписку к серверу mail1 и затем удаляем сам сервер.

    Создаем заново сервер mail1, но уже в связке Windows Server2008 R2 и Exchange Server 2010. Оформляем прописку. Выполняем подписку.

    Во-вторых, удаляем сервера почтовых ящиков. Напомню, что кластер mailbox-серверов работал в режиме Cluster Continues Replication. Обращаемся к Библиотеке TechNet и читаем статьи "Удаление роли активного сервера почтовых ящиков из среды кластера с непрерывной репликацией" и "Удаление роли пассивого сервера почтовых ящиков из среды кластера с непрерывной репликацией". Деинсталлируем Exchange Server 2007 сначала с пассивного, затем с активного узлов.

    В-третьих, разбираем NLB-кластер, деинсталлируем роли Exchange 2007 Hub Transport и CAS с каждого узла с помощью оснастки "Программы и компоненты".

    Всё, в нашем домене не осталось ни одного сервера Exchange 2007.

    Установка ForeFront Protection 2010 for Exchange Server

    В отличии от Exchange 2007, где Microsoft Outlook подключался напрямую к роли MailBox, в Exchange 2010 все подключения осуществляются к роли Сервера клиентского доступа. Поэтому выполнять установку ForeFront Protection 2010 на серверы с ролью MailBox мы не будем, ограничимся только серверами с ролями CAS и EDGE.

    Запускаем дистрибутив:

    И видим предупреждение о перезапуске служб:

    В моем случае прокси-сервер не используется, пропускаем.

    Настройка антивирусной защиты является отдельной темой и является сугубо индивидуальной, поэтому подробно останавливаться на ней не будем, только несколько основных скриншотов для полноты картины:


    Заключение

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

    Во-первых, пользователи пожаловались на невозможность открыть вложение при просмотре почты через OWA – выдавалась ошибка. Проблема решается установкой RollUp'а. На момент написания статьи был выпущен второй пакет.

    Во-вторых, после установки ForeFront Protection 2010 for Exchange Server отключился список исключений для "Фильтрации содержимого". Правило продолжило работать, а почтовые ящики, которые должны были принимать всю почту вместе со спамом, стали попадать под правило и фильтровать спам. Баг…

    В третьих, на EDGE Hub Transport "Проводник журнала отслеживания" не работает. Выдается ошибка:

    Ошибка известная, описанная в Support'е. Там же и способ решения проблемы: "This hotfix is scheduled to be included in Exchange Server 2010 Service Pack 1 (SP1)." А пока Service Pack не вышел, пользуемся командлетом PowerShell Get-MessageTrackingLog.

    Всё, пожалуй, больше проблем не было.

    Вся миграция длилась примерно месяц. Начиная с просмотра докладов на TechDays с 26-го декабря, до удаления организации Exchange 2007 31-го января. Сервис Exchange 2010 был развернут за январские праздники, тогда же были перенесены и первые подопытные кролики тестовые почтовые ящики. В последнюю рабочую неделю января были перенесены остальные mailbox'ы.

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

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

    Кайгородов Евгений

Комментарии

  1. Спасибо, предстоит миграция в скором времени. Перестал переживать по этому поводу ))

  2. Отличная статься! Мне кажеться она победит 😉

  3. Ну призов несколько) Кстати в номинации «новые возможности для пользователей» еще никто ничего не прислал.

  4. статья хороша,но блин не могу избавится от стойкого ощущения,что уже её где-то читал возможно по-английски

  5. Нет, Стас 🙂

    Всё реально — всё сделано своими руками 🙂

    Скриншоты же все на русском 🙂

    Просто в статье куча ссылок и слайдов на ранее опубликованные материалы.

    По сути это обобщение данных из разных источников.

  6. Пока публиковалась статья, вышел Exchange 2010 Update Rollup 3

    blogs.technet.com/exchang...te-rollup-3.aspx

    Пару дней назад установил на один EDGE — полёт нормальный.

  7. Пока читал возникли сомнения в правильности подходов к инфраструктуре. Как я понимаю все было на виртуальных машинах и СХД, замечательно, нет единой точки отказа удобно управлять.

    Зачем было CCR, если все данные все равно на СХД?

    Это неоправданное дублирование, защиту данных в этом случае надо делать средствами СХД.

    «В последнее время места на SAN катастрофически не хватает, и были приобретены два физических сервера для переноса роли почтовых ящиков.»

    Странное решение, надо было просто избавиться от CCR копии данных и если этого недостаточно, добавить дисков в СХД, причем дисков SATA большой емкости.

    Купив 2 сервера вы:

    1. Неоправданно усложнили IT инфраструктуру

    2. Внесли в ИТ инфраструктуру элемент отличающийся от других, который надо администрировать отдельно (а не как все виртуальные машины)

    3. Сервера будут недозагружены, а электричество кушать будут исправно и кондиционеры которые их охлаждают тоже

    4. Когда закончится место на дисках этих серверов, что делать будете?

    Серверы с двумя Ксеонами, 24Gb RAM и 16-ю дисками 146GB 15K?

    Хм... я бы сказал, что это конфигурация подходит скорее для MSSQL. Судя по рекомендациям Microsoft, нужны большие SATA диски. Ибо над IOPS они поработали.

    В общем, ИМХО деньги не туда потратили и создали себе массу проблем в будущем.

    Меняйте подход.

  8. 2 Сергей

    Не совсем согласен с Вашими замечаниями.

    0-1. <>

    У CCR, в отличии от SCC, ДВЕ базы почтовых ящиков. И в случае логического повреждения файлов, простой на обслуживание поврежденной базы пройдёт для пользователей незаметно. Это во-первых.

    Во-вторых, если всё правильно помню, возникли сложности с реализацией в Hyper-V у Windows 2008 SP1 — она не поддерживала доступ с двух виртуальных машин к одному хранилищу. R2 на момент внедрения Exchange 2007 ещё не вышел.

    Технология CCR является рекомендуемым компанией Microsoft способом обеспечения отказоустойчивости. Например, поищите в Интернете цикл статей «how Microsoft IT» о внедрении у себя Exchange Server 2007.

    К тому же стоимость ещё одной полки для СХД была сопоставима или выше стоимости двух серверов, и на её покупку разрешение не дали. Да, серверы планировались в более простой конфигурации. Но есть такое понятие как «бюджет» — если деньги остаются, их надо потратить. И не всегда мы можем купить то что хочется. Например могут выделить денег на ДВА сервера, и не важно что за эту сумму можно купить три — денег выделено на ДВА. Это так, для примера. На самом деле мне сказали оборудование покупать мощнее, так как деньги в бюджете остаются. Какой же сисадмин от этого откажется? 🙂

    <>

    Но с этим комментарием я согласен, так и написано в статье в части «подготовка серверов» — «так получилось».

    2. <>

    Не согласен в корне. Если мы говорим об администрировании организации Exchange — она управляется с моего рабочего компьютера с помощью «Exchange Management Console». Если мы говорим об управлении экземплярами операционной системы, то её мониторинг планируется с помощью Operations Manager 2007 R2. Да и не вся инфраструктура у нас на Blade-системе, есть с десяток обычных серверов. А если бы мы использовали роль объединенных коммуникаций? Она же не поддерживается в виртуальной среде. Поэтому считаю что нет никакой разницы на чем базируется один из серверов Exchange.

    3. <>

    На счёт электроэнергии и охлаждения – современные серверы и Windows 2008 R2 умеют отключать неиспользуемые компоненты, проверял в диспетчере задач. Ну и вытащить можно один процессор. 🙂

    4. <>

    Когда закончится место на диске — вариантов два: а) заменить диски. б) DAS – рекомендуемо.

  9. Блин, фразы в двойных знаках сравнения вырезались...

    0-1. Зачем было CCR, если все данные все равно на СХД?" & "Неоправданно усложнили IT инфраструктуру

    Серверы с двумя Ксеонами, 24Gb RAM и 16-ю дисками 146GB 15K?

    2. Внесли в ИТ инфраструктуру элемент отличающийся от других, который надо администрировать отдельно

    3. Сервера будут недозагружены, а электричество кушать будут исправно и кондиционеры которые их охлаждают тоже

    4. Когда закончится место на дисках этих серверов, что делать будете?

    Вот это должно было быть вставлено, без этих фраз непонятно о чём речь.

  10. Не плохая статья, будет полезна тем, кому предстоит миграция.

    По некоторым моментам согласен с Сергеем, но раз уж вы сами говорите, «так получилось», даже спорить не буду... главное, чтобы работало.

    По самой статье — считаю, что её можно было бы сократить примерно в 2 раза, убрав большое количество ненужных скриншотов, демонстрирующих простые действия, типа инсталляции серверов Exchange (ну очень длинный манускипт получился, «листать не перелистать», да и печатать не удобно) и собственно описание самой инсталляции итереса не вызывает, а вот про настройку и миграцию можно было бы немого подробнее...

    ЗЫ. Если статья опубликована в рамках конкурса в номинации «новые возможности для администраторов», то не понимаю о каких новых возможностях идет речь? (если про DAG, то очень мало). Скорее её нужно на конкурс Внедрение/Миграция (похожий сейчс по Hyper-V проходит).

  11. В статье приведены ВСЕ настройки. Это же была миграция, а не новая установка, поэтому часть настроек переехала через AD. Скриншоты делались со всех окон, где надо было проставлять галочки 🙂 Step-by-Step Guide для коллег по отделу.

    А в рамках конкурса есть подтема «Внедрение»... 🙂

  12. Уважаемый, Kevgeny, я писал пост не для того чтобы спорить с вами и не для того чтобы вы оправдывались. Долго решал, отвечать или нет. Но попробую все же вас убедить.

    Перечитайте еще раз мои замечания и свои комментарии.

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

    т.е. если процессор не будет работать, то его не надо покупать,

    если не нужны IOPS, не надо брать SAS 15k диски,

    если есть СХД для консолидации данных, не надо снова их разбрасывать по серверам,

    если не хватает места, то не надо держать лишнюю копию данных, просто вспомнить о наличии снепшотов как со стороны СХД так и со стороны виртуализации и бекапов.

    И считать надо не начальную цену покупки, а во что это обойдется за весь срок службы (например для сервера это срок гарантии, обычно 3-5 лет).

  13. Сергей, хотелось бы Вас переубедить — DAS для Exchange является решением с наименьшем TCO.

    www.maximumexchange.ru/20...r-exchange-2007/

  14. Статья интересная и подробно описана что да как. Вопрос возникает

    в следующем — чем обусловлена причина миграции с 2007 на 2010 exchange. Если простым решением что вот вышло новое и срочно это надо поставить или есть действительно ряд задач которые не посильны exchange 2007.

    Если сверх сложных задач нет то может и exchange 2003 sp2 на HP DL380 справиться без особых проблем...

  15. 2 Макс

    Ответ в самом начале:

    «В последнее время места на SAN катастрофически не хватает, и были приобретены два физических сервера для переноса роли почтовых ящиков.

    И вот, чтобы не делать работу дважды, освобождая место на SAN, заодно и перейдём на Exchange 2010.»

    Но есть и несколько моментов которые делают жизнь приятнее 🙂

    В первую очередь меня не как администратора, а как пользователя почтовой системы.

  16. Ну если покупать новые сервера только для хранения маил-боксов, а не к примеру винты большей ёмкости, то причина очень везкая :)))

  17. Kevgeny, вы привели ссылку на www.maximumexchange.ru/20...r-exchange-2007/ видимо воспользовавшись поисковиком 🙂

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

    В вашем случае те выкладки совершенно неприменимы.

    Улыбнули фразы из статьи:

    «Ключевым моментом новой стратегии, обернувшимся сэкономленными $5.000.000, стало исключение ленточных накопителей в архивации данных Exchange, и применении новых систем отказоустойчивости Exchange Server 2007, в виде длительной кластерной репликации CCR (cluster continuous replication)»

    «Microsoft IT использует Data Protection Manager 2007, полностью поддерживающий CCR и архивацию пассивных кластерных узлов каждые 15 минут.»

    нестыковка.

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

    Или как вариант построить второй резервный ЦОД, что иногда вполне оправдано.

  18. 2 Сергей.

    Статью я читал ещё до развертывания у себя Exchange 2007 🙂

    Каждая компания предъявляет свои требования к Бэкапу. Например Микрософт посчитал допустимым отказаться от ленточных накопителей, а мы — нет. У нас DPM используется и для быстрых, и для медленных резервных копий. Причем я писал и про разнос серверов в разные ЦОД.

    Кстати, бэкап же никто не отменял, иначе логи забьют всё свободное дисковое пространство. 🙂

    И всё-таки ещё раз:

    Первоначально сервер планировался с одним процессором, с памятью в 8GB, м восьмью дисками 300GB SAS 10K SFF, а в этом году планировалось докупить ещё по восемь дисков 500GB SATA 7.2K 2.5in

    Забавно что именно этот момент вызвал наибольшую дискуссию. 🙂

    В любом случае, мы же не можем перейти in place, нужно искать другое оборудование. А причины переходить или не переходить каждый определяет для себя сам.

  19. «Это неоправданное дублирование, защиту данных в этом случае надо делать средствами СХД»

    Неверно для Exchange. В СХД копия данных один черт будет одна, от физической ошибки спасет, от логической нет. CCR — две копии и в этом бонус.

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

    1. NLB не спасает от остановки SMTP/IIS сервисов, и обеспечивает отказоустойчивость на уровне серверов, а не сервисов. Это решение по балансировке, но не по отказоустойчивости. Пример — остановите SMTP сервис на NLB ноде и где ваша отказоустойчивость?

    2. Придирка: "Есть пользователи, использующие Outlook Web Access, опубликованный через ISA Server. « А есть и не использующие?

    3.»Многие говорят про продукцию Microsoft: «Нужно дождаться выхода первого Service Pack, до него много глюков». "

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

    4. «В последнее время места на SAN катастрофически не хватает, и были приобретены два физических сервера для переноса роли почтовых ящиков.»

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

    5. Вольные фразы в статьях не приветствуется. В блогах можно, в статьях нет.

    «Для начала поступим как ламеры» А в чем ламерство?

    "Разумеется, чтение документации не ограничивалось просмотром «лекции о любви с показом слайдов». "

    «„Создать локального запроса“ – как-то не по-русски немного звучит…»

    «После установки у себя RollUp2 такая фича исчезла»

    по умолчанию с «некрасивым» именем

    «укрупненный план перехода»

    6.

    "Настройки существующих CAS-серверов остаются неизменными, и в случае, если что-то пошло бы не так, как планировалось, существующие ользователи ничего бы не заметили. "

    «Развёртывание роли клиентского доступа, на мой взгляд, является самым сложным этапом. Во-первых, это затрагивает существующую организацию, а во-вторых, здесь больше всего настроек и параметров.»

    Да ладно Вам 🙂 По хорошему Exchange 2010 настраивается полностью и тестируется, просто переключения DNS записей делаются в последний момент, а все тесты проводить с использованием hosts на тестируемых рабочих станциях.

    «Доступ к OWA 2010 снаружи будет перенастроен в самом конце, после перемещения почтовых ящиков пользователей, его использующих. „ в корне неправильно. Система 2010 перед миграцией должна быть оттестирована и работать на 100%

    7.“Выбрать ТОЛЬКО русский язык у меня не получилось.» русский язык качается из Инета нормально.

    8."Хочу напомнить что «Обычная установка» помимо установки ролей и средств управления настраивает организацию Exchange на работу с внешней почтой."

    Что то изменилось? Раньше на receive connector нужно было разрешать прием анонимных пользователей. Сейчас галка ставится по умолчанию?

    9. «А вот такой скриншот мне ни у кого не попадался, так как большинство людей для тестов ставили „обычную установку“» Просто выкинуть. Явно лишнее.

    10. Запрос сертификатов все же лучше делать через встроенный мастер Exchange. Зачем Микрософт его делал тогда? 🙂

    11. «Я пошел немного другим путем, и не стал подключать второй интерфейс. Причина в том, что два сервера у меня пока стоят рядом, а в разные ЦОДы будут разнесены позже, тогда и будет настроен heartbeat.»

    Неправильно. Надо было сделать, а при переносе просто IP поменять. Так будет меньше возможных проблем при переносе. Перенос сведется к смене IP

    12. «в Exchange 2010 все подключения осуществляются к роли Сервера клиентского доступа. Поэтому выполнять установку ForeFront Protection 2010 на серверы с ролью MailBox мы не будем, ограничимся только серверами с ролями CAS и EDGE»

    Для CAS роли ForeFront не нужен. Я понимаю, что у Вас там HUB роль стоит, а читатели могут и не понять. Плюс это не защищает от помещения файлов с вирусами в свой почтовый ящик в черновики и возможность открытия их на другом компьютере.

    теперь Сергею:

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

    т.е. если процессор не будет работать, то его не надо покупать,

    если не нужны IOPS, не надо брать SAS 15k диски,

    если есть СХД для консолидации данных, не надо снова их разбрасывать по серверам,

    "

    продолжаем логику ...

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

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

    Ох уж эти игры в современных, грамотных и продуманных ИТ директоров... 🙂

    На практике все по другому.

  20. 2 Pavel Nagaev

    Со скриншотами согласен, и надо было делать две статьи – одну «затертую» для itband, вторую, подробную, для коллег. И по поводу вольных фраз – учту на будущее.

    По пунктам.

    2. "Есть пользователи, использующие Outlook Web Access, опубликованный через ISA Server. " А есть и не использующие? – Имелось ввиду что в некоторых компаниях пользователи работают через OWA в локальной сети, например в удаленных офисах. У нас таких пользователей нет.

    3. Если все будут ждать выхода первых Сервис Паков и баз знаний, то внедряться будет всё очень медленно. 🙂 Было время и для внедрения и для отката назад в случае каких-либо проблем. Была предупреждающая покупка серверов, в ожидании выхода новых продуктов (Exch2010 и TMG).

    6. Перед миграцией система была оттестирована на 98%. OWA изнутри работала. Перенастроить внутренний адрес в правиле публикации на ISA несложно, и вероятность что что-то пойдёт не по плану стремится к нулю.

    7. Версия сразу русская, просто насторожила фраза «выбор языка» – предпочитаю оставлять только два, английский и русский, остальные отключать.

    8. Согласен полностью, всё ждал что кто-нибудь заметить. Был у меня просто случай – после «обычной» установки ещё одного сервера в организацию Exchange, почта перестала ходить, застревала на сервере. Потом уже сообразил, что нужно было переподписать EDGE после ввода Hub Trunsport'а. Детская ошибка.

    12. А можно поподробнее? Что-то не соображу… Правильнее разбить на два подвопроса:

    а) Если Hub и CAS разнесены по разным серверам? Антивирусом проверяется только роль HUB'а? А CAS не проверяется?

    б) При открытии любого письма из почтового ящика, в том числе и из Черновиков, разве пользователь откроет его не через CAS?

  21. 2. чтобы таких вопросов не возникало, нужно сразу писать понятно, чтобы не придраться было.

    3. «то внедряться будет всё очень медленно.» Поработаете в большой компании, где есть отдел безопасности и ваше мнение изменится 🙂

    Плюс есть здравая логика о которой я писал выше.

    12. А у CAS что на вирусы проверять? Forefront работает с двумя ролями — HUB и MAILBOX. Каким образом он получает доступ в мейлбоксы я не знаю. Outlook к Public folderам то напрямую цепляется, значит может обращаться к E2010 напрямую по MAPI, тогда и FF может, если по MAPI работает.

    В общем тут не скажу, не знаю.

  22. В требованиях к ForeFront Protection 2010 есть вот что.

    Client Access Server (CAS). Required only for use with the on-demand scan with Exchange Server 2010.

  23. Павлу:

    «не нужно делать в офисе дополнительных розеток, т.к. они же не используются, зачем тратить деньги.»

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

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

    Павел, не экономия, а здравый смысл. Kevgeny перенес Exchnage из виртуальной среды на физические сервера, только лишь потому что нехватало места в SAN, очень странная причина, учитывая что SAN как раз легко масштабируется.

    «Неверно для Exchange. В СХД копия данных один черт будет одна, от физической ошибки спасет, от логической нет. CCR — две копии и в этом бонус.»

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

    Коллеги, ведь SAN, виртуализацию, кучу функционала СХД (snapshot, репликацию и т.п.) придумали именно для того, чтобы небыло проблем с расширением пространства или увеличением вычислительной мощности. Не спорю что в отдельных случаях (как например у microsoft) выгода от выноса Exchange в фактически отдельную инфраструктуру существенно выше чем стоимость ее обслуживания, но здесь то описан другой случай.

  24. Есть ещё одна выгода, о которой я упоминал, но вскользь.

    Два сервера можно разнести по ЦОД'ам в разных зданиях, что и планировалось сделать.

  25. Практически все делал по этой статье, должен заметить небольшие неточности, например «Сначала добавляем группу „Exchange Trusted Subsystem“ в группу локальных администраторов на серверах Exchange 2007» тут видимо имелось ввиду Exchange 2010, а также в разделе «Настройка CAS сервера» в строке «Set-ClientAccessServer –AutoDiscoverServiceInternalUrl» ошибка, в место Url пишем Uri, но это все мелочи, в основном отличная статья помогла пересеть на 2010 без каких либо осложнений, Автору спасибо.

  26. Спасибо большое за статью, с мелкими погрешностями, но в целом практчический step-by-step миграция!

  27. Александр, статья и забумывалась как step-by-step guide.

    Несмотря на то, что на подходе уже следующая версия, многие всё ещё используют Exchange 2007.

    Поэтому было бы замечательно, если бы мои погрешности были поправлены.

    Пиши, люди оценят ))

  28. Предстоит делать такое с 2003 на 2010...Можете направить на такой же ман где-нибудь?

  29. Это опыт МОЕЙ миграции. других у меня не было 🙂

    В тексте есть ссылки на доклады и на сайт TechNet.

    Там рядом есть про миграцию с Exch2003 на Exch2010.

  30. […] Хорошая статья про кластера (на русском) – itband.ru/2010/04/exchang...7-exchange-2010/ […]

  31. […] Хорошая статья про кластера (на русском) – itband.ru/2010/04/exchang...7-exchange-2010/ […]

Опубликовать

Я не робот.