Ошибка при перемещении почтового ящика Exchange 2016

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

История такая: перемещаю ящик с помощью PowerShell, и, как обычно, мониторю процесс переноса такой вот командой:

Сначала ящик едет довольно бодро, но потом процесс останавливается на 95% и замирает в состоянии StalledDueToTarget_DataGuaranteeWait. Это состояние длится довольно долго, после чего процесс переноса завершается ошибкой.

Статус ошибки не указывает на причину, поэтому вывожу более подробную информацию:

Получаю вот такое сообщение, в котором говорится примерно следующее: «Не удалось реплицировать изменения почтового ящика. База данных не удовлетворяет ограничению SecondCopy потому что время фиксации изменений 04.09.2020 10:07:15 не гарантирует время репликации 31.12.9999 23: 59: 59».

Не очень внятное объяснение, особенно смущает дата из недалекого ? будущего. Но понятно, куда примерно копать. На серверах настроен DAG (Database Availability Group), база, в которую перемещается ящик, имеет копию, и видимо между базами есть проблемы с репликацией.

Проверяю состояние копий базы командой:

Как ни странно, все в полном порядке.

Тогда проверяю работу репликации на сервере, на котором располагается база:

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

На этом история завершилась. А в качестве заключения немного теории.

Data Guarantee API

Exchange Server включает в себя функционал Data Guarantee API, который используется службой репликации почтовых ящиков (Mailbox Replication Service, MRS) для проверки состояния системы копирования почтовых баз на основе определенных настроек. В частности, Data Guarantee API может использоваться для:

• Проверки Replication Health — подтверждение того, что доступно заданное число копий почтовой базы.
• Проверки Replication Flush — подтверждение того, что необходимые файлы журналов успешно применены к заданному числу копий почтовой базы.

После выполнения проверки API возвращает следующую информацию:

Статус

• Retry — возвращается как результат промежуточных ошибок, которые делают невозможным проверку состояния почтовой базы.
• Satisfied — возвращается, когда почтовая база соответствует заданным условиям или база не реплицируется.
• NotSatisfied — возвращается, когда почтовая база не соответствует заданным условиям. Кроме того возвращается информация о том, почему получен код NotSatisfied.

Время ожидания повторной проверки

• Если информация о копировании не получена, то время ожидания по умолчанию составляет 10 секунд.
• Если не найдено ни одной здоровой копии почтовой базы, то время ожидания по умолчанию составляет 2 минуты.
• Если здоровая копия почтовой базы найдена, но она отстает в репликации, то время ожидания по умолчанию составляет 1 минуту.

Максимально возможное время ожидания 10 минут.

DataMoveReplicationConstraint

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

• None — значение по умолчанию, присваивается при создании базы. При значении None условия в Data Guarantee API игнорируются. Это значение должно использоваться только для почтовых баз, которые существуют в единственном экземпляре и не реплицируются.
• SecondCopy — как минимум одна пассивная копия базы должна соответствовать условиям Data Guarantee API. Это значение по умолчанию, которое присваивается при создании копии базы.
• SecondDatacenter — как минимум одна копия базы в другом сайте Active Directory должна соответствовать условиям Data Guarantee API.
• AllDatacenters — как минимум одна копия базы в каждом сайте Active Directory должна соответствовать условиям Data Guarantee API.
• AllCopies — все копии почтовой базы должны соответствовать условиям Data Guarantee API.

Check Replication Health

Когда Data Guarantee API определяет «здоровье» инфраструктуры копий почтовых баз, вычисляются следующие параметры:

Если DataMoveReplicationConstraint имеет значение SecondCopy, то для данной базы по крайней мере одна пассивная копия должна:

• Быть в состоянии healthy.
• Иметь очередь воспроизведения (replay queue) с задержкой не более 10 минут.
• Иметь длину очереди копирования (copy queue) не более 10.
• Средняя длина очереди копирования (average copy queue length) не более 10. Средняя длина очереди копирования вычисляется на основе количества запросов приложения к состоянию базы данных.

Если DataMoveReplicationConstraint имеет значение SecondDatacenter, то для данной базы по крайней мере одна пассивная копия в другом сайте Active Directory должна:

• Быть в состоянии healthy.
• Иметь очередь воспроизведения (replay queue) с задержкой не более 10 минут.
• Иметь длину очереди копирования (copy queue) не более 10.
• Средняя длина очереди копирования (average copy queue length) не более 10.

3. Если DataMoveReplicationConstraint имеет значение AllDatacenters, то для данной почтовой базы активная копия должна быть смонтирована, а пассивная копия в каждом сайте Active Directory должна:

• Быть в состоянии healthy.
• Иметь очередь воспроизведения (replay queue) с задержкой не более 10 минут.
• Иметь длину очереди копирования (copy queue) не более 10.
• Средняя длина очереди копирования (average copy queue length) не более 10.

4. Если DataMoveReplicationConstraint имеет значение AllCopies, то для данной почтовой базы активная копия должна быть смонтирована, а все пассивные копии почтовой базы должны:

• Быть в состоянии healthy.
• Иметь очередь воспроизведения (replay queue) с задержкой не более 10 минут.
• Иметь длину очереди копирования (copy queue) не более 10.
• Средняя длина очереди копирования (average copy queue length) не более 10.

Check Replication Flush

Data Guarantee API может также использоваться для проверки того, что заданное число копий почтовой базы применяет требуемые транзакционные журналы. Это проверяется сравнением временной метки последнего примененного журнала с временной меткой подтверждения от вызывающего сервиса (в большинстве случаев это временная метка последнего файла журнала, который содержит требуемую информацию) плюс 5 секунд (это связано с отклонениями системного времени). Если метка времени применения больше, чем время подтверждения, то проверка возвращает статус Satisfied, если меньше — возвращает статус NotSatisfied.

Mailbox Replication Service

При перемещении ящиков служба репликации MRS вызывает Data Guarantee API несколько раз за время выполнения запроса на перемещение. Перемещение выполняется в следующем порядке:

• Запрос на перемещение обновляет Active Directory и помещает сообщение в системный почтовый ящик, расположенный в почтовой базе целевого сайта Active Directory. Затем MRS запрашивает Data Guarantee API, чтобы определить здоровье целевой инфраструктуры копий почтовых баз. Пока возвращаемый статус равен Satisfied, выполнение запроса на перемещение будет продолжаться.
• MRS начинает перемещение информации, клонируя структуру почтового ящика в целевую почтовую базу, параллельно запрашивая Data Guarantee API для определения состояния целевой инфраструктуры копий почтовых баз. Пока возвращаемый статус равен Satisfied, выполнение запроса на перемещение будет продолжаться.
• MRS выполняет начальную синхронизацию, создавая мгновенный снимок почтового ящика-источника и реплицируя его папки и содержимое. Во время этого процесса MRS запрашивает Data Guarantee API каждые 10 секунд, чтобы определить состояние целевой инфраструктуры копий почтовых баз. Пока возвращаемый статус равен Satisfied, выполнение запроса на перемещение будет продолжаться.
• MRS выполняет дополнительную синхронизацию, реплицируя изменения, появившиеся по отношению к первоначальному мгновенному снимку. Во время этого процесса MRS запрашивает Data Guarantee API каждые 10 секунд, чтобы определить состояние целевой инфраструктуры копий почтовых баз. Пока возвращаемый статус равен Satisfied, выполнение запроса на перемещение будет продолжаться.
• MRS блокирует почтовый ящик-источник.
• MRS выполняет дополнительную синхронизацию, чтобы провести изменения, сделанные с момента последнего события синхронизации, кроме того, копирует другие данные почтового ящика. Начиная Exchange 2010 SP1 MRS будет заставлять целевую базу применить активный транзакционный журнал, если он еще не применился, тем самым гарантируя, что непрерывная репликация может реплицировать информацию этого журнала, который содержит данные синхронизации перемещаемого почтового ящика. MRS определяет, выполнилось ли это успешно с помощью вызова Check Replication Flush в Data Guarantee API.
• MRS запрашивает Data Guarantee API, чтобы определить состояние инфраструктуры копий почтовых баз. Пока возвращаемый статус равен Satisfied, выполнение запроса на перемещение будет продолжаться.
• MRS обновляет учетную запись пользователя в Active Directory, отмечая, что перемещение завершено.
• MRS блокирует целевой почтовый ящик.
• MRS изменяет состояние почтового ящика в почтовой базе-источнике на soft-deleted. Эта функция была добавлена в Exchange 2010 SP1 для гарантии того, что в случае потери целевой почтовой базы вы сможете восстановить почтовый ящик из предыдущей почтовой базы.

Если во время шагов с 1 по 4 Data Guarantee API вернет NotSatisfied или Retry, MRS поместит запрос на перемещение в очередь и будет повторять запрос каждые 30 секунд. MRS помещает запрос на перемещение в очередь не более чем на 15 минут, после чего аварийного его завершает. Если в пределах этих 15 минут возвращается ответ Satisifed, MRS будет автоматически возобновлять запрос на перемещение.

Во время шага 6 MRS будет ждать максимум 30 минут, пока Data Guarantee API не вернет Satisfied (повторяя запрос каждые 10 секунд). Если Satisfied не получен, то MRS будет аварийно завершать перемещение почтового ящика.

Когда запрос на перемещение завершается аварийно, он не будет возобновляться сервисом MRS автоматически. До выполнения Resume-MoveRequest администратору следует выполнить Get-MoveRequestStatistics для того, чтобы определить причину аварийного завершения перемещения. После этого администратор может выполнить Resume-MoveRequest.

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

Исправлена ​​ошибка, из-за которой помощник по планированию не мог получить данные.

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

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

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

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

2. Используйте онлайн-режим

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

3. Изменить разрешения календаря

Когда пользователь установил для своего разрешения на доступ к календарю значение «Нет / Автор», другие люди не смогут видеть его информацию «Свободен / Занят». В случае, если только информация о занятости одного пользователя не может быть получена, это может быть результатом неправильной настройки его календарного разрешения. В этом случае разрешение разрешения для его календаря Outlook на Свободное / Занятое время или Свободное / Занятое время, тема, местоположение может решить проблему. Этот шаг будет предпринят в системе пользователя, чей график занятости не может быть получен.

Разрешения календаря не установлены

4. Очистите список автозаполнения

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

5. Отключите антивирус / брандмауэр

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

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

После этого не забудьте включить Антивирус и Брандмауэр. Если вам удалось успешно получить информацию о занятости, сделайте исключение в Антивирусе / Брандмауэре, чтобы Outlook мог обмениваться данными с сервером.

6. Очистить кэшированные учетные данные

Windows использует Credential Manager в качестве «цифрового хранилища» для хранения учетных данных, таких как имена пользователей, пароли и адреса. Затем эти данные используются самой Windows или приложениями и программами, такими как Microsoft Office и т. Д. Учетные данные делятся на две основные категории; Учетные данные Windows и веб-учетные данные. Если эти учетные данные были повреждены, то пользователь может столкнуться с обсуждаемой ошибкой. В этом случае удаление записей, связанных с Outlook, из учетных данных может решить проблему. Этот шаг должен быть сделан в системах обоих пользователей.

7. Используйте Outlook в безопасном режиме

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

Теперь проверьте, показывает ли помощник по планированию информацию о занятости. Если это так, отключите надстройки Outlook по очереди, выполнив следующие действия.

8. Восстановить файл OST

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

9. Изменить конфигурацию сервера

Это разные настройки сервера, которые позволяют пользователям использовать разные функции, такие как просмотр данных о занятости. Если какой-либо из этих параметров не установлен, пользователи могут страдать от данной проблемы. Существует множество настроек для настройки, но в основном это могут быть Autodiscover, EWS и mailboxfolderpermission.

Outlook использует автообнаружение для получения информации о доступности / занятости, и если автообнаружение настроено правильно, данные о занятости будут отображаться серыми косыми чертами. Убедитесь, что помощник вне офиса работает правильно. Если нет, то, скорее всего, служба автообнаружения в Exchange не настроена должным образом, поскольку эти два признака (не работающий Office и сбой помощника по планированию для получения данных о занятости) часто встречаются, когда автообнаружение неправильно настроено.

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

10. Ремонт профиля пользователя

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

11. Создайте новый профиль пользователя

Сбой в получении информации о занятости может возникнуть из-за поврежденной / неправильной конфигурации профиля пользователя. В этом случае удаление текущего профиля и создание нового может решить проблему. Обратите внимание, что, выполнив это, вы полностью удалите свой профиль Outlook, и вам придется создать новый и перенастроить ваше соединение.

Надеюсь, теперь вы можете использовать помощник по планированию без каких-либо проблем. Если нет, используйте Outlook Web App (OWA).