none
Не идет миграция почтовых ящиков между базами Exchage 2016 RRS feed

  • Общие обсуждения

  • Установлен Exchange 2016 cu7.

    Нужно переместить пользователя из одной базы в другу.

    Базы находятся на одном сервере и на одном физическом диске, просто у них разные настройки ограничений.

    Создал New-MoveRequest -Identity USER -TargetDatabase NEWBASE -PrimaryOnly и оставил, а потом забыл. Прошел  МЕСЯЦ!!! На днях создавал новую миграцию и обнаружил, что это старое задание статус StalledDueToTarget_DiskLatency - вполнено 0%

    Запустил

    Get-MoveRequest | Get-MoveRequestStatistics -IncludeReport | fl *report*

    выдает

    Report : 10.03.2018 10:12:18 [exch] Запрос на перемещение создан 'firma.local/Пользователи/Администраторы/exchadmin'.

    И всё

    Удалил. Создал заново, подождал 2 дня - результат у всех заданий тот же

    статус StalledDueToTarget_DiskLatency выполнено 0%

    В чём может быть проблема?



    17 апреля 2018 г. 7:09

Все ответы

  • Добрый День.

    Вам ответили...

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


    Я не волшебник, я только учусь MCP CCNA. Если Вам помог чей-либо ответ, пожалуйста, не забывайте жать на кнопку "Пометить как ответ" или проголосовать "полезное сообщение". Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции работодателя. Вся информация предоставляется как есть без каких-либо гарантий. Блог IT Инженера, Twitter, YouTube, GitHub.

    17 апреля 2018 г. 16:43
    Модератор
  •  Диск и физически и логически один и тот же, просто две базы лежат рядом с разными настройками.

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

    Даже более того, попробовал между серверами в DAG мигрировать. Сервера вообще географически разнесены и базы разные - только статус поменялся на  "Queued", но миграция так и стоит на 0%


    18 апреля 2018 г. 10:12
  • StalledDueToTarget_DiskLatency 

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

    28 апреля 2018 г. 14:38
  • Да, это ВМ. Миграция на другой хост не помогла. Память - статическая, диски динамические (всегда были такими).
  • Воспользуйтесь perfmon для отслеживания IOPS на дисках внутри виртуалки и/или на гипервизоре, если диски на пределе то такое поведение возможно.

    также можно попробовать поднять приоритет

    new-moverequest .... -Priority Emergency

    И еще можно посмотреть в сторону MRS throttling

    https://social.technet.microsoft.com/Forums/en-US/efa793ff-cf7b-4177-8a98-03895a1a8c66/mailbox-migration-slow-when-to-a-dag-database?forum=Exch2016Adm

  • -Priority Emergency очень помог, спасибо Alexus817
  • Блин, всё равно, дошло до 78% и опять "StalledDueToTarget_DiskLatency"
  • В обычном случае миграция идет без проблем- у Вас явно с нагрузкой перебор, иначе ящики бы ехали без проблем. Не надейтесь на волшебные ключи, смотрите в сторону счетчиков и оборудования.

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

  • база в DAG ? циклическое ведение журналов транзакций на базе (которая destination ) включено или нет ?
  • Да, базы в DAG, циклическое ведение журналов включено на всех базах.


  • Проблема решилась, когда на всех серверах включил по 8 ядер в настройках виртуальных машин.
    5 июня 2018 г. 15:03
  • как бы странно это не звучало, но можно было попробовать отключить циклическое ведение жернада на период миграции ящиков, а потом включить обратно.
  • Проблема решилась, когда на всех серверах включил по 8 ядер в настройках виртуальных машин.
    Поделитесь, пожалуйста что за гипервизор используется. Не Proxmox, часом?
  • Нет, обычный Hyper-V
    9 июня 2018 г. 12:11