Ошибка при миграции почтового ящика - ErrorsMaster.ru - большая энциклопедия ошибок и их решений

Добрый день, мигрирую почтовую систему с exchange 2010 на 2016. Почтовый ящик переместился на 95%. В логе такое

12.06.2020 14:03:15 [mail2] Сведения об исходном архивном почтовом ящике:
Обычные элементы: 8516, 2.878 GB (3,090,372,257 bytes)
Обычные удаленные элементы: 0, 0 B (0 bytes)
Элементы FAI: 2, 0 B (0 bytes)
Удаленные элементы FAI: 0, 0 B (0 bytes)
12.06.2020 14:03:15 [mail2] Этап: FinalIncrementalSync. Процент выполнения: 95.
12.06.2020 14:03:15 [mail2] Процеc завершения в хранилище почтовых ящиков выполнен.
12.06.2020 14:03:15 [mail2] Процеc завершения в хранилище почтовых ящиков выполнен.
12.06.2020 14:03:15 [mail2] Данные SessionStatistics обновлены.
12.06.2020 14:03:15 [mail2] Проверка содержимого почтового ящика…
12.06.2020 14:03:15 [mail2] Проверка содержимого почтового ящика…
12.06.2020 14:03:21 [mail2] Проверка содержимого почтового ящика завершена: 173 папок, 18703 элементов, 4.726 GB (5,074,015,938 bytes).
12.06.2020 14:03:24 [mail2] Проверка содержимого почтового ящика завершена: 61 папок, 8518 элементов, 2.878 GB (3,090,372,257 bytes).
12.06.2020 14:03:24 [mail2] Ожидание репликации изменений в почтовом ящике.
12.06.2020 14:04:27 [mail2] Ожидание репликации изменений в почтовом ящике.
12.06.2020 14:04:32 [mail2] Почтовый ящик ‘USER’ загружен из контроллера домена ‘pdc.REW.Local’.
12.06.2020 14:04:32 [mail2] Сведения о целевом почтовом ящике:
Обычные элементы: 18324, 4.912 GB (5,274,458,361 bytes)
Обычные удаленные элементы: 206, 19.88 MB (20,841,083 bytes)
Элементы FAI: 190, 1.459 MB (1,529,954 bytes)
Удаленные элементы FAI: 0, 0 B (0 bytes)
12.06.2020 14:04:32 [mail2] Сведения о целевом архивном почтовом ящике:
Обычные элементы: 8522, 2.976 GB (3,195,047,373 bytes)
Обычные удаленные элементы: 0, 0 B (0 bytes)
Элементы FAI: 2, 6.813 KB (6,977 bytes)
Удаленные элементы FAI: 0, 0 B (0 bytes)
12.06.2020 14:04:32 [mail2] Произошла неустранимая ошибка UpdateMovedMailboxPermanentException.

Подскажите из за чего может происходить такое? Может ли это быть из-за квотирования ?

Источник

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

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

Get-MoveRequest | where {$_.status -ne "completed"} | Get-MoveRequestStatistics | ft -a displayname,status*,percent

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

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

Get-MoveRequest | where {$_.status -ne "completed"} | Get-MoveRequestStatistics | fl *failure*, message

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

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

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

Get-MailboxDatabaseCopyStatus -Identity db10

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

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

Test-ReplicationHealth -Server mbx2

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

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

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 должна:

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

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

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.

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

Вот как то так оно и работает 🙂

Источник

Администратор Exchange может перемещать ящики пользователей между почтовыми базами на одном сервере или между удалёнными mailbox серверами. В этой статье мы рассмотрим, как перемещать почтовые ящики в Exchange с помощью Exchange Admin Center и PowerShell (статья актуальна для всех поддерживаемых версий 2010/2013/2016/2019, с небольшими оговорками касательно графического интерфейса управления Exchange).

Содержание:

Перемещения почтовых ящиков с помощью Exchange Admin Center
Управление перемещением ящиков Exchange с помощью PowerShell
Пакетный перенос ящиков в Exchange

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

Обратите внимание, что перемещение и удаление ящика не уменьшит размер фалов почтовой базы на диске, а лишь освободит место внутри базы (white space). Освободившееся место в базе может использоваться для хранения почтовых элементов оставшихся пользователей. Для уменьшения размеры базы Exchange нужно выполнить ее офлайн дефрагментацию, или просто пересоздать (предварительно переместив пользователей в другие почтовые базы).

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

Local move – локальный запрос на перенос ящика внутри одного леса (из одной базы в другую на том же самом почтовом сервере, или на другой сервер в этой же организации Exchange);
Cross-forest enterprise move – перенос почтовых ящиков между разными лесами Active Directory;
Remote mailbox moves in hybrid deployments – перенос почтовых ящиков в гибридных конфигурациях (между on-premises Exchange и Office 365).

Перемещения почтовых ящиков с помощью Exchange Admin Center

С помощью Exchange Admin Center вы можете переместить один или несколько ящиков пользователей.

Откройте EAC и перейдите на вкладку Recipients -> Migrations;
Нажмите кнопку + и выберите пункт Move to a different database;
Выберите учетные записи, ящики которых нужно переместить;
Можно указать список пользователей для переноса в CSV файле и загрузить его в EAC.
Затем нужно указать целевую почтовую базу, в которую нужно переместить ящики;
Далее вы можете указать, нужно ли запустить перемещение сразу, или позднее, а также указать ящик, на который нужно доставить отчет об успешном перемещении ящика.

Я сам практически не пользуюсь возможностями перемещения ящиков через EAC, т.к. с помощью PowerShell можно выполнить эти действия гораздо удобнее и быстрее.

Управление перемещением ящиков Exchange с помощью PowerShell

Чтобы узнать, в какой почтовой базе находится ящик пользователя, запустите Exchange Management Shell и выполните команду:

Get-Mailbox aaivanov| Format-List Database

В этом примере ящик пользователя находится в базе DB01.

Для создания локального запроса на перенос ящика используется командлет New-MoveRequest. Например:

New-MoveRequest -Identity aaivanov -TargetDatabase "MBX01" –BadItemLimit 10

Кроме имени пользователя важные параметры это:

TargetDatabase – имя целевой почтовой базы, в которую нужно переместить ящик;
BadItemLimit – количество поврежденных элементов в ящике, которое можно пропустить (игнорировать) при переносе ящике.
Если указать BadItemLimit 0, значит при наличии хотя бы одного поврежденного элемента, ящик не будет перемещен и останется в исходной базе. Если вы указали значение BadItemLimit > 50, нужно дополнительно указывать ключ AcceptLargeDataLoss.

Командлет вернет размер ящика и архива (TotalMailboxSize , TotalArchiveSize) и сообщение о том, что запрос на перенос добавлен в очередь (Queued)

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

Get-Mailbox -Database DB01 -ResultSize Unlimited | New-MoveRequest -TargetDatabase DB02

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

Get-Mailbox -Database DB01 -Arbitration | New-MoveRequest -TargetDatabase DB02

В конфигурационном файле MSExchangeMailboxReplication.exe.config (C:Program FilesMicrosoftExchange ServerV15Bin) можно изменить настройки миграции ящиков. Например, вы можете указать сколько одновременных операций перемещения поддерживается для одной базы или сервера. Это параметры MaxActiveMovesPerSourceMDB, MaxActiveMovesPerTargetMDB, MaxActiveMovesPerSourceServer, MaxActiveMovesPerTargetServer.

В зависимости от размер ящика и местоположения целевого сервера, его перенос может занять длительное время. Для отслеживания статуса миграции почтового ящика в % используется командлет Get-MoveRequestStatistics.

Get-MoveRequestStatistics -Identity aaivanov

В данном примере статус переноса — InProgress, процент завершения (PercentComplete) – 26%.

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

Get-MoveRequest | Get-MoveRequestStatistics

После того, как перенос завершен, значение PercentComplete достигнет 100, а статус переноса изменится на Completed.

Можно вывести статистику только по незавершённым операциям переноса:

Get-MoveRequest | where {$_.status -ne "completed"} | Get-MoveRequestStatistics | ft -a displayname,status*,percent

Вывести все ящики в процессе перемещения или ожидания в очереди:

Get-MoveRequest -movestatus inprogress Get-MoveRequest -movestatus queued

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

Get-MoveRequest aaivanov | Get-MoveRequestStatistics | fl *failure*, message

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

Get-MoveRequest -resultsize unlimited | Where-Object {$_.status -like “failed”} | Get-MoveRequestStatistics -IncludeReport | select DisplayName, Message, FailureType, FailureSide, FailureTimeStamp, *bad*, *large*, Report, Identity | fl

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

Remove-MoveRequest -Identity aaivanov

Чтобы удалить успешно завершенные запросы на перемещение (без этого вы не сможете перенести этот ящик в следующий раз), выполните:

Get-MoveRequest -MoveStatus Completed | Remove-MoveRequest

Пакетный перенос ящиков в Exchange

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

Get-Mailbox -Database DB01 | New-MoveRequest -TargetDatabase DB02 -BatchName DB01toDB02Move20200915

Теперь, чтобы получить статус миграции всех ящиков в этом пакете нужно указать его имя:

Get-MoveRequest -BatchName DB01toDB02Move20200915| Get-MoveRequestStatistics

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

Можно временно приостановить перенос почтовых ящиков:

Get-MoveRequest | ? {$_.Batchname –like “*DB01toDB02Move20200915”}|Set-MoveRequest –SuspendWhenReadytoCompleate

Или продолжить миграцию:

Get-MoveRequest | ? {$_.Batchname –like “*DB01toDB02Move20200915”|Resume-MoveRequest

В Exchange 2013, 2016, 2019 и Exchange Online можно перемещать несколько ящиков с помощью пакетного режима (командлет New-MigrationBatch). Список ящиков для миграции нужно указать в CSV файле, а затем выполнить команду:

New-MigrationBatch -Local -AutoStart -AutoComplete -Name DB01Move20200915 -CSVData ([System.IO.File]::ReadAllBytes("C:PSDB01Move20200915.csv")) -TargetDatabases DB02 -BadItemLimit 10

Для переноса только основного ящика укажите параметр
PrimaryOnly
, чтобы перенести архивный почтовый ящик –
ArchiveOnly
.

Источник

Обновлено 15.08.2019

Добрый день! Уважаемые читатели и гости одного из популярных IT блогов в России Pyatilistnik.org. В прошлой статье мы с вами разобрали, как устраняется ошибка при подключении по RDP «Произошла ошибка при проверке подлинности. Указанная функция не поддерживается». Сегодня же я хочу поговорить на такую жизненную тему, как переезд с Exchange 2010 на Exchange 2013. На мой взгляд, это актуальная тема с которой сейчас сталкиваются многие системные администраторы. Мы поговорим, о подводных камнях и дополнительных настройках, с которыми вам придется столкнуться.

Антивирус

Функция “Веб контроль” в антивирусе Касперского версии 8 блокирует работу клиентов Outlook с сервером Exchange 2013, хотя никак не мешала работе того же клиента с Exchange 2010. Нужно либо настроить исключения антивируса, либо совсем отключить “Веб контроль”, либо обновить на всех клиентских машинах Касперского до версии 10.

Накладки при миграции

В интерфейсе ECP Exchange 2013 на странице “получатели — миграция” можно создать множество заданий, которые могут выполняться одновременно, либо быть отложенными для последующего ручного запуска. Но один и тот же почтовый ящик не может упоминаться во всех этих заданиях дважды. Если по какой-то причине миграция одного из пакетов не завершилась, то невозможно создать новый пакет миграции с участием того же почтового ящика, который фигурирует в уже созданных заданиях. Прежде необходимо удалить ранее созданный пакет целиком либо удалить запрос на перемещение конкретного почтового ящика.

В этом примере удаляется запрос на перемещение почтового ящика test5.

Remove-MoveRequest -Identity ‘test5@mydomain.ru’

POP3, IMAP4

Не удалось заставить Exchange 2013 предоставлять доступ клиентам по защищенному подключению (SSL). Заработало только по 110 и 143 портам. При этом “Способ входа” необходимо задавать “Обычная проверка подлинности (обычный текст)”

Какие проблемы и дополнительные настройки при переезде с Exchange 2010 на Exchange 2013-01

Но оказалось, что задавать способ входа через GUI бесполезно. Нужно именно в командной строке Exchange Management Shell выполнить команды:

Set-PopSettings –server <Имя сервера> –LoginType 1Set-ImapSettings –server <Имя сервера> –LoginType 1

Удаление старого адреса из конфигурации транспорта

После деинсталяции Exchange 2010 в конфигурации транспортного сервера на Exchange 2013 остается IP-адрес старого сервера. Если посмотреть конфигурацию транспорта командой:

Get-TransportConfig

то в поле “InternalSMTPServers” содержатся адреса двух серверов: текущего и удаленного.

Чем удалять лишний адрес, проще ввести в это поле новое значение из одного адреса:

Set-TransportConfig -InternalSMTPServers «10.10.10.10»

Механизм автообнаружения Exchange 2013 в локальной сети

Клиент Outlook в локальной сети прежде всего ищет информацию о ближайшем сервере Exchange в AD. Посмотреть основные параметры, которые используются клиентами можно из командной строки Exchange 2013:

Get-ClientAccessServer | fl Name,AutoDiscoverServiceInternalUri,AutoDiscoverSiteScope,WhenCreated

Через GUI можно увидеть эти параметры с помощью административных инструментов Windows, например, на контроллере домена в “Active Directory Sites and Services”.

Какие проблемы и дополнительные настройки при переезде с Exchange 2010 на Exchange 2013-02

Причем, по умолчанию узел “Services” не отображается в консоли. Его нужно сначала отобразить: “View — Show Services Node”

Какие проблемы и дополнительные настройки при переезде с Exchange 2010 на Exchange 2013-03

Outlook выбирает все серверы Exchange, считывает 3 параметра: сайт, адрес AutoDiscover, дату создания. Серверы в “чужих” сайтах отбрасываются, а остальные сортируются по дате создания, так что преимущество имеют более молодые.

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

Ограничение на рассылку

Вот тут Микрософт реально подложил свинью. На предприятии используется программа, которая рассылает своим пользователям в том же домене (и даже в локальной сети) уведомления о важных событиях. Её клиент подключался к Exchange 2010 через POP3, и все работало нормально до переезда на Exchange 2013. После переезда пользователи начали жаловаться, что уведомления не приходят или приходят, но не всегда. Как оказалось, по умолчанию в Exchange 2013 разрешено отправлять не более 5 писем в минуту.

Посмотреть текущие ограничения можно в “Exchange Management Shell”:

get-receiveconnector | ft name,messageratelimit

Какие проблемы и дополнительные настройки при переезде с Exchange 2010 на Exchange 2013-04

Как видно из скриншота, групповое изменение параметра не поддерживается, нужно указывать коннектор конкретно.

Set-Receiveconnector -Identity “Client Proxy EX” -MessageRateLimit 50Set-Receiveconnector -Identity “Client Frontend EX” -MessageRateLimit 50

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

Restart-Service MSExchangeTransport

База данных по умолчанию

После установки получилось 3 базы данных почтовых ящиков:
— “Mailbox Database 1682978795” — создана при установке автоматически и оставлена для служебных нужд,
— “Simple” — для большинства пользователей,
— “VIP” — для пользователей с большими ящиками.

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

Выполняем в “Exchange Management Shell” по одной команде на каждую базу данных, которую нужно исключить из автоматического распределения:

Set-MailboxDatabase “Mailbox Database 1682978795” -IsExcludedFromProvisioning $TrueSet-MailboxDatabase “vip” -IsExcludedFromProvisioning $True

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

Источник

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

Столкнулись с проблемой на Exchange 2013 при переходе с Exchange 2010

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

get-mailbox -arbitration | fl name,persis*

WARNING: The object /Users/Migration.8f3e7716-2011-43e4-96b1-aba62d229136 has been corrupted, and it’s in an
inconsistent state. The following validation errors happened:
WARNING: Database is mandatory on UserMailbox.

Get-Mailbox -Arbitration -Identity «Migration.8f3e7716-2011-43e4-96b1-aba62d229136» | New-MoveRequest -TargetDatabase «Mailbox Database 0716799622»

Решили так:

Set-Mailbox -Arbitration «Migration.8f3e7716-2011-43e4-96b1-aba62d229136» -targetdatabase «Mailbox Database 0716799622»

Комментарии пользователей

Анонимам нельзя оставоять комментарии, зарегистрируйтесь!

Источник