Сайт · Форум · Инструменты · WindowsFAQ.ru - Сайт о Windows, компьютерах, системном администрировании, локальных сетях

Поиск

Друзья

Клуб любителей ASPLinux
Kerio Winroute Firewall инструкции настройки
Главная arrow Статьи arrow Администрирование arrow Миграция почтовой системы с Exchange 2007 на Exchange 2010. Часть 2.
1С:Предприятие 8
  • 1С:Предприятие 8. Лицензирование клиентских рабочих мест

    Лицензионная политика «1С» обеспечивает пользователям независимую масштабируемость – по функционалу прикладных решений и по клиентским рабочим местам. Чтобы расширить функциональные возможности используемой системы, требуется приобрести новые приложения. Если увеличивается число рабочих мест – необходимо приобрести дополнительные клиентские лицензии. Также возможен апгрейд лицензий. Обычно поставка ПО осуществляется с программной защитой. По более высокой цене можно приобрести ПО с аппаратным ключом защиты (USB).

  • 1С:Предприятие 8. Лицензирование сервера

    Лицензионная политика «1С» обеспечивает пользователям независимую масштабируемость – по функционалу прикладных решений и по клиентским рабочим местам. Серверные лицензии — необходимы для запуска кластера сервера «1С:Предприятие». Могут быть 32-разрядными или 64-разрядными. Причем лицензия на 64-разрядный сервер позволяет использовать и 32-разрядные рабочие процессы.

  • MS SQL Server. Лицензирование сервера и клиентского доступа для 1С

    Серверные и клиентские лицензии "Microsoft SQL Server 2012 для 1С:Предприятие 8" поставляются отдельно от серверных и клиентских лицензий "1С:Предприятие 8". Для пользователей, у которых есть лицензии "1С:Предприятие 8", покупка совместных продуктов этой линейки является оптимальным вариантом, чтобы: - перейти с файл-серверной версии на клиент-серверную версию "1С:Предприятие 8" на базе Microsoft SQL; - обновить более раннюю версию (2000/2005/2008/2008R2) Microsoft SQL Server до версии Microsoft SQL 2012/2014

Перейти к разделу 1С
 
Миграция почтовой системы с Exchange 2007 на Exchange 2010. Часть 2. Версия для печати
Автор Станислав Булдаков   

Миграция почтовой системы с Exchange 2007 на Exchange 2010. Часть 1.

Установка вторых серверов в DAG и NLB

Ранее было описано, как устанавливать и настраивать первые серверы в DAG и NLB. Осталось добавить дополнительные серверы, чтобы решение стало действительно отказоустойчивым.

Добавляем второй узел в DAG

Процесс добавления практически ничем не отличается от установки первого узла.

У второго узла DAG будут также задействованы 2 сетевых интерфейса. Один для клиентского подключения, второй для внутренней репликации между узлами. Первый интерфейс будет иметь сетевые настройки характерные для клиентов локальной сети предприятия. На интерфейсе для репликации оставляем включённым только Internet Protocol Version 4. В его свойствах не забываем указать ip-адрес (отличный от ip-адреса интерфейса для репликации первого узла) и маску подсети, gateway и dns-серверы при этом не указываем, так же отключаем регистрацию клиента на dns-сервере (Register this connection’s addresses in DNS).

После этого можно приступать к установке необходимых компонентов системы через PowerShell:

Import-Module ServerManager

Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth, Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model, RSAT-Web-Server -Restart

После перезагрузки устанавливаем сервер Exchange 2010 с ролью Mailbox:

setup.com /r:M /Mdbname:"HQ Mailbox Database 01" /DbFilePath:e:\db01\db01.edb /LogFolderPath:d:\log01

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

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

Add-DatabaseAvailabilityGroupServer -Identity hq-dag -MailboxServer hq-mbx4

Во время работы этого командлета будут установлены необходимые бинарники кластерной службы Windows, проверен сервер hq-mbx4, если проверка пройдёт успешно, то он будет добавлен в группу доступности.

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

Добавляем второй сервер с ролями Client Access Sever и Hub Transport Server

Устанавливаем через PowerShell необходимые компоненты системы:

Import-Module ServerManager

Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth, Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model, RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression, NET-HTTP-Activation,RPC-Over-HTTP-Proxy,Telnet-Client,NLB -Restart

После перезапуска системы настроим сервис Net.Tcp Port Sharing на автоматический запуск:

Set-Service NetTcpPortSharing -StartupType Automatic

Затем приступаем к установке самого сервера Exchange 2010. Так как все необходимые настройки были уже сделаны при установке первого сервера с ролями CAS и Hub Transport, то можно обойтись установкой через командную строку, не указывая дополнительных параметров:

setup.com /r:C,HT

После очередной перезагрузки можно приступать к настройке нового сервера и добавлению его в NLB.

Для начала запускаем консоль Network Load Balancing Manager из административных утилит и подключаемся к уже существующему кластеру:

Миграция почтовой системы с Exchange 2007 на Exchange 2010

И добавляем новый узел:

Миграция почтовой системы с Exchange 2007 на Exchange 2010

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

Миграция почтовой системы с Exchange 2007 на Exchange 2010
Миграция почтовой системы с Exchange 2007 на Exchange 2010

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

Перенос функций клиентского доступа на Exchange 2010

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

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

Все необходимые сертификаты у нас выданы и установлены. Серверы клиентского доступа уже предварительно настроены. Outlook Anywhere на них включён. Не забываем так же, что у нас имеется балансировщик нагрузки, который балансирует клиентские подключения на серверы клиентского доступа.

  • Проверяем параметр ExternalURL на каждом сервере клиентского доступа Exchange 2010 для служб оффлайновой адресной книги, веб-сервисов, ActiveSync, OWA и Exchange Control Panel (ECP):

    Get-OABVirtualDirectory servername\OAB* | fl -ExternalURL
    Get-WebServicesVirtualDirectory servername\EWS* | fl -ExternalURL
    Get-ActiveSyncVirtualDirectory -Identity servername\Microsoft-Server-ActiveSync | fl -ExternalURL
    Get-OWAVirtualDirectory servername\OWA* | fl –ExternalURL
    Get-ECPVirtualDirectory servername\ECP* | fl -ExternalURL

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

    Set-OABVirtualDirectory servername\OAB* -ExternalURL https://hq-hub.domain.com/OAB
    Set-WebServicesVirtualDirectory servername\EWS* -ExternalURL https://hq-hub.domain.com/ews/exchange.asmx
    Set-ActiveSyncVirtualDirectory -Identity servername\Microsoft-Server-ActiveSync -ExternalURL https://hq-hub.domain.com/Microsoft-Server-ActiveSync
    Set-OWAVirtualDirectory servername\OWA* -ExternalURL https://hq-hub.domain.com/OWA
    Set-ECPVirtualDirectory servername\ECP* -ExternalURL https://hq-hub.domain.com/ECP

  • Если у нас имеются серверы Exchange 2007 в сайтах, которые не имеют выхода в интернет, то необходимо будет скопировать бинарные файлы OWA Exchange 2007 (самую старшую версию – на текущий момент это папка с названием 8.3.192.1, находится в %ProgramFiles%\Microsoft\Exchange Server\Client Access\Owa) в папку %ProgramFiles%\Microsoft\Exchange Server\V14\ClientAccess\Owa на серверы клиентского доступа Exchange 2010. По завершении запускаем IISReset на всех серверах клиентского доступа Exchange 2010.

  • Переносим оффлайновую адресную книгу на серверы Exchange 2010. Для начала переносим процесс создания адресной книги на один из серверов почтовых ящиков Exchange 2010 (к сожалению, DAG указать не получится):

    Move-OfflineAddressBook "Default Offline Address List" -Server servername

    Затем добавляем в её свойства новые точки распространения, расположенные на серверах клиентского доступа Exchange 2010. Делается это следующим набором команд:

    $OABVDir=Get-OABVirtualDirectory -Server servername
    $OAB=Get-OfflineAddressBook "Default Offline Address List"
    $OAB.VirtualDirectories += $OABVdir.DistinguishedName
    Set-OfflineAddressBook "Default Offline Address List" -VirtualDirectories $OAB.VirtualDirectories

    Процесс повторяется для обоих серверов клиентского доступа. Балансировщик указать не получится. Все это так же можно сделать через EMC: Organization Configuration > Mailbox > Offline Address Book.

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

  • Теперь мы готовы к самому процессу переключения функции клиентского доступа со старых серверов Exchange 2007 на новые серверы Exchange 2010. Проверяем что записано в параметре ExternalURL на каждом сервере клиентского доступа Exchange 2007 для служб оффлайновой адресной книги, веб-сервисов, ActiveSync, и OWA:

    Get-OABVirtualDirectory servername\OAB* | fl -ExternalURL
    Get-WebServicesVirtualDirectory servername\EWS* | fl -ExternalURL
    Get-ActiveSyncVirtualDirectory -Identity servername\Microsoft-Server-ActiveSync | fl –ExternalURL
    Get-OWAVirtualDirectory servername\OWA* | fl -ExternalURL

    Если там указано не имя самого сервера, настройки которого смотрим, то имеет смысл поменять:

    Set-OABVirtualDirectory servername\OAB* -ExternalURL https://servername.domain.com/OAB
    Set-WebServicesVirtualDirectory servername\EWS* -ExternalURL https://servername.domain.com/ews/exchange.asmx
    Set-ActiveSyncVirtualDirectory -Identity servername\Microsoft-Server-ActiveSync -ExternalURL https://servername.domain.com/Microsoft-Server-ActiveSync
    Set-OWAVirtualDirectory servername\OWA* -ExternalURL https://servername.domain.com/OWA

    Эта настройка связана с тем, что клиент, чей ящик находится на серверах почтовых ящиков Exchange 2007, при заходе на серверы клиентского доступа Exchange 2010 будет автоматически перебрасываться на адрес указанный в параметре ExternalURL службы, которая запрашивается в данный момент клиентом. Поэтому проще всего указать в этом параметре сами серверы клиентского доступа (или их dns-алиасы, доступные снаружи).

  • Во внешнем и внутреннем dns меняем записи autodiscover.domain.com (A, CNAME, SRV) так, чтобы они ссылались на наш балансировщик нагрузки. Ждём пока dns-кэш на клиентах обновится.

По завершении перенастройки свойств виртуальных директорий необходимо переключить сервис автообнаружения на всех старых серверах клиентского доступа на новые (в нашем случае это будет балансировщик нагрузки). Выполняется это на серверах Exchange 2007 следующей командой для каждого старого сервера клиентского доступа:

Get-ClientAccessServer servername –AutoDiscoverServiceInternalUri https://hq-hub.domain.com/Autodiscover/Autodiscover.xml

Права доступа для региональных офисов

Модель назначения прав доступа в Exchange 2010 по сравнению с Exchange 2007 претерпела сильные изменения. Подробнее с ней можно ознакомиться здесь. Попробуем по аналогии с Exchange 2007 дать полный доступ региональным администраторам к своим почтовым серверам, а также дать им полный доступ к своим региональным почтовым объектам и общим папкам. Для начала создадим области действия наших региональных администраторов. Для почтовых объектов:

New-ManagementScope "Region1 Recipients Scope" -RecipientRoot region1.local -RecipientRestrictionFilter '(objectclass -like "*")'

И для серверов:

New-ManagementScope "Region1 Servers Scope" -ServerRestrictionFilter {ServerSite -eq "Region1-Site-Name"}

Далее копируем роли из существующей группы ролей «Server Management» в нашу новую группу ролей, область действия которой будет ограничена только региональными серверами. Затем добавим в неё регионального администратора (или группу администраторов):

$RoleGroup = Get-RoleGroup "Server Management"
New-RoleGroup "Region1 Server Management" -Roles $RoleGroup.Roles -CustomConfigWriteScope "Region1 Servers Scope" -ManagedBy "region1 admin" -Members "region1 admin"

По аналогии копируем роли из существующей группы ролей «Recipient Management» в нашу новую группу ролей, область действия которой будет ограничена только региональными почтовыми объектами. Затем добавим в неё регионального администратора (или группу администраторов):

$RoleGroup = Get-RoleGroup "Recipient Management"
New-RoleGroup "Region1 Recipient Management" -Roles $RoleGroup.Roles -CustomRecipientWriteScope "Region1 Recipients Scope" -ManagedBy "region1 admin" -Members "region1 admin"

То же самое для общих папок – область действия – региональные серверы:

$RoleGroup = Get-RoleGroup "Public Folder Management"
New-RoleGroup "Region1 Public Folder Management" -Roles $RoleGroup.Roles -CustomConfigWriteScope "Region1 Servers Scope" -ManagedBy "region1 admin" -Members "region1 admin"

Перенос данных с серверов почтовых ящиков

Перенос общих папок

Как и при миграции с Exchange 2003 на Exchange 2007, общие папки должны сначала отреплицироваться на новые серверы. Делается это внесением в свойства общей папки реплик на новые серверы почтовых ящиков, на которых будут находиться базы общих папок. Если папок много, то ручное внесение реплик становится трудоёмкой задачей. Для упрощения процесса существует скрипт AddReplicaToPFRecursive.ps1. Он добавляет реплики в свойства указанной общей папки и во все дочерние папки. Запускается следующим образом:

AddReplicaToPFRecursive.ps1 -Server 2007MBX -TopPublicFolder "\" -ServerToAdd 2010MBX

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

AddReplicaToPFRecursive.ps1 -Server 2007MBX -TopPublicFolder "\NON_IPM_SUBTREE" -ServerToAdd 2010MBX

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

Перенос почтовых ящиков пользователей

По завершении репликации общих папок можно приступать к переносу почтовых ящиков пользователей. Для этого лучше использовать Exchange Management Console (узел Recipient Configuration > Mailbox > New Local Move Request) или командлет New-MoveRequest в Exchange Management Shell. Процесс запускается с серверов Exchange 2010.

В процессе перемещения почтового ящика с ним можно полноценно работать. Как только процесс закончится, то выскочит предупреждение о том, что почтовым администратором внесены изменения, которые требуют перезапуска Outlook. После переноса всех почтовых ящиков необходимо будет удалить все запросы на перемещение (они автоматически не удаляются).

Удаление сервера почтовых ящиков Exchange 2007

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

  • Проверяем, что оставшиеся на старом сервере почтовые базы используют базу общих папок, расположенную на сервере Exchange 2010.

    Самый простой способ проверить это – запустить следующую команду на старом сервере:

    Get-MailboxDatabase -Server servername | fl Name,PublicFolderDatabase

    Если используется старая база общих папок – исправляем:

    Set-MailboxDatabase -Name "Old Mailbox Database" –PublicFolderDatabase "New Public Folder Database"

  • После этого можно приступать к процессу удаления реплик общих папок со старого сервера.

    Делается это скриптом MoveAllReplicas.ps1 на новом сервере:

    MoveAllReplicas.ps1 -Server oldserver -NewServer newserver

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

    Get-PublicFolderStatistics -Server oldserver

    Как только она перестанет показывать папки, находящиеся на старом сервере, можно приступать к следующему шагу. А что делать, если одна или несколько папок не будут удаляться со старого сервера? Самый просто способ – выгрузить данные, находящиеся в этих папках в pst-файл с помощью Outlook, запомнить клиентские права доступа к ним, папки удалить, проконтролировать, что они удалились на обоих серверах. После этого создаём эти папки обратно, задаём клиентские права доступа и загружаем данные из pst-файла назад в новые папки.

  • Удаляем старую базу общих папок.

    После удаления реплик данных из старой базы общих папок можно приступить к удалению старой базы. Делается это с нового сервера следующим образом:

    Get-PublicFolderDatabase -Identity "Old Public Folder Database" | Remove-PublicFolderDatabase

  • Удаляем старые почтовые базы.

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

    Get-MailboxDatabase -Server oldserver | Remove-MailboxDatabase

    После этого можно удалить edb-файлы баз и логи. Они в процессе удаления объектов баз с почтового сервера не удаляются. Придётся это делать вручную.

  • Удаляем старый сервер почтовых ящиков.

    Процесс запускается через Program and Features в панели управления сервера. Галки Mailbox Role и Management Tools надо будет убрать.

    Миграция почтовой системы с Exchange 2007 на Exchange 2010

На этом процесс удаления сервера почтовых ящиков Exchange 2007 завершается.

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

Удаление транспортного сервера и сервера клиентского доступа

После завершения переноса данных с серверов почтовых ящиков на новые серверы и удаления старых можно приступать к переключению на новые транспортные серверы. Можно это делать сразу после установки первого транспортного сервера. Порядок не принципиален. Основная работа по переключению будет идти с DNS-сервером и коннекторами.

Для начала можно перенести транспортные правила со старых серверов на новые. Делается это через Exchange Management Shell на любом сервере Exchange 2010 следующим образом:

$file = Export-TransportRuleCollection -ExportLegacyRules
Set-Content -Path d:\rules.xml -Value $file.FileData -Encoding Byte
[Byte[]]$Data = Get-Content -Path d:\rules.xml -Encoding Byte -ReadCount 0
Import-TransportRuleCollection -FileData $Data

Для того чтобы новые транспортные серверы могли отправлять почту необходимо для них создать во внешней DNS-зоне A-записи и MX-записи, ссылающиеся на эти A-записи. Чтобы при этом почта проходила спам-фильтры на принимающих серверах (при их наличии) необходимо так же проконтролировать, что провайдер в обратной зоне для внешнего ip-адреса транспортных серверов укажет в PRT-записях их dns-имена. Так же, имеет смысл создать корректную SPF-запись, либо, если она уже существует, добавить в неё новые транспортные серверы.

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

В случае если создаётся новый send-коннектор, старый можно отключать. Сразу удалять его не стоит – может пригодиться, если по каким-то причинам придётся его заново использовать. Если новые транспортные серверы были добавлены в существующий send-коннектор, то из него нужно удалить старые транспортные серверы. Но этот вариант, с моей точки зрения, менее красив, так как откатиться к старому send-коннектору в случае каких-либо проблем будет сложнее.

Если у нас имеется специальный коннектор для приёма анонимных сообщений от внутренних smtp-серверов, то его необходимо перенести на один из новых транспортных серверов, а внутренние smtp-серверы перенастроить на использование в качестве смарт-хоста нового транспортного сервера. Если список ip-адресов внутренних smtp-серверов будет велик, то вручную его переносить на новый коннектор будет затруднительно. Используем для этого EMS:

$connector = Get-ReceiveConnector "EX2007HT\Relay"
Set-ReceiveConnector "EX2010HT\Relay" -RemoteIPRanges $connector.RemoteIPRanges

Так как send-коннектор для старых транспортных серверов мы отключили, то можно удалять из внешней DNS-зоны MX-записи, ссылающиеся на старые серверы. Так же можно удалить существующие для них PTR-записи. Затем отключаем Receive-коннекторы на старых серверах. После этого старые транспортные серверы перестанут отправлять и получать почту из внешнего мира.

Осталось удалить A-записи для старых транспортных серверов и почистить от них существующую SPF-запись. Затем, через Programs and Features запускаем программу удаления Exchange 2007 и удаляем роли Hub Transport, Client Access Server и Exchange Management Tools.

Миграция почтовой системы с Exchange 2007 на Exchange 2010

После удаления последнего сервера с ролью Hub Transport/Client Access Server миграция будет считаться завершённой.

SavageNoName
создано: 28-11-2011 12:21
Миграция почтовой системы с Exchange 2007 на Exchange 2010
Никнейм:


BB-коды, смайлы
Тема на форуме
Опции
 
 
< Контроль за использованием интернета при помощи GFI WebMonitor   Миграция почтовой системы с Exchange 2007 на Exchange 2010. Часть 1. >


На форуме

Лента RSS

Mobatime - Автору - Рекламодателю - Веб-мастеру - Контакт - История - Наверх
© Владислав Семёнов aka SavageNoName 2003-2019
При любом использовании материалов ссылка на WindowsFAQ.ru обязательна
Сайту 15 лет, 4 месяца и 0 дней. Форуму 18 лет, 8 месяцев и 13 дней.