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

Статья посвящена достаточно распространенной проблеме, с которой рано или поздно сталкиваются все администраторы Exchange – повреждение (логические ошибки) в почтовом ящике пользователя. Подобные логические ошибки проявляются в таких проблемах, как ошибки синхронизации и зависания в Outlook , неправильное представление элементов в папке, их неверное количество, сбои в поиске, ошибки в общих папках и т.д.

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

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

  • Импорту данных из Outlook, запущенного в режиме кэширования, в PST файл, удалению и пересозданию почтового ящика «проблемного» пользователя на сервере, и, наконец, импорту данных из PST-файла в новый ящик Exchange. Данная методика предполагает определенное количество ручных манипуляция на компьютере пользователя.
  • Полное отключение (размонтирование) почтового хранилища и его проверка утилитой Isinteg.exe (Information Store Integrity Checker), позволяющей исправить повреждения в базе Exchange на уровне приложения. Данный метод требует довольно длительного простоя почтового сервиса для всех пользователей, чьи ящики располагаются в отключенной базе.

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

  • Восстановление почтовой базы Exchange из резервной копии, импорт данных конкретного ящика в PST файл и дальнейший перенос данных в пересозданный ящик. Такая методика имеет недостаток – будут потеряны все письма, которые попали в ящик пользователя после выполнения последнего бэкапа.

Описанными выше методиками приходилось пользоваться администраторам Exchange-серверов вплоть до выхода Exchange 2010 SP1, в котором появился более удобный функционал для восстановления логической структуры поврежденного ящика – комадлет Powershell New-MailboxRepairRequest. Данный командлет позволяет на прикладном уровне найти и исправить логические ошибки и повреждения в базе Exchange, причем поиск и исправление ошибок может производиться как для конкретного ящика, так и для всех ящиков в базе (последовательно). Т.е. не требуется целиком переводить почтовую базу в режим offline, а в каждый конкретный момент времени будет недоступен только один ящик, тот, для которого в данный момент проводится проверка и восстановление целостности. Перед выполнением одного из описанных выше радикальных способов восстановления целостности ящика, определенно стоит попробовать воспользоваться этой командой.

Данный командлет можно использовать для поиска, восстановления и мониторинга поврежденных ящиков во всех поддерживаемых версиях Exchange: 2010 ,2013 и 2016.

Синтаксис команды таков:

New-MailboxRepairRequest -Mailbox <MailboxIdParameter> -CorruptionType <MailboxStoreCorruptionType[]> [-Archive <SwitchParameter>] [-Confirm [<SwitchParameter>]] [-DetectOnly <SwitchParameter>] [-DomainController <Fqdn>] [-WhatIf [<SwitchParameter>]]

Командлет позволяет найти и исправить следующие типы повреждений в ящиках Exchange:

  • SearchFolder – ошибки в папках поиска
  • AggregateCounts – проверка и исправление информации о количестве элементов в папках и их размере
  • FolderView – неверное содержимое, отображаемое представлениями папок
  • ProvisionedFolder – нарушения логической структуры папок

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

New-MailboxRepairRequest -Mailbox winitpro -DetectOnly -CorruptionType ProvisionedFolder, SearchFolder

Следующий пример запустит процесс анализа и восстановления ящика пользователя winitpro на все 4 типа повреждений:

New-MailboxRepairRequest -Mailbox winitpro -CorruptionType ProvisionedFolder, SearchFolder, AggregateCounts, Folderview

Так можно запустить поиск ошибок и их восстановление для всех ящиков базы:

New-MailboxRepairRequest -Database “MailBaseMsk1” -CorruptionType ProvisionedFolder, SearchFolder, AggregateCounts, Folderview

Команда выполняется в фоновом режиме и в консоль PowerShell результатов выполнения не выводит. Отследить ее запуск и восстановление можно по идентификатору задачи RequestID и журналу событий Windows (источник событий MSExchangeIS Mailbox Store: событие EventID 10059 — запуск сканирования, EventID 10048 успешное завершение операции).

Также могут быть полезными следующие EventID (для удобства отслеживания процедуры восстановления ящиков Exchange, их можно собрать в отдельное представление журнала MSExchangeIS Mailbox Store)

  • 10044 – ошибка выполнения запроса восстановления ящика
  • 10045 — ошибка выполнения запроса восстановления базы
  • 10046 – Восстановление логической структуры ящика завершено успешно
  • 10047 – запуск запроса восстановления уровня ящика
  • 10048 – запрос восстановления успешно завершен
  • 10049 – ошибка выполнения восстановления, обнаружен другой выполняющийся запрос в этой же базе
  • 10050 –запрос восстановления пропущен для ящика
  • 10051 – запрос восстановления отменен из-за того, что база отмонтирована
  • 10059 – запуск восстановления на уровне базы Exchange
  • 10062 – обнаружено повреждние
  • 10064 – запуск восстановления общей папки

exchange - событие окончание восстановления поврежденного ящика

Совет. В Exchange 2013 появился специальный командлет Get-MailboxRepairRequest, позволяющий узнать статус выполнения операции восстановления ящика.

Примечание. Одной из особенностей командлета New-MailboxRepairRequest – после его запуска, процедуру исправления ящика нельзя прервать без остановки службы Exchange Information Store и отмонтирования почтовой базы.

В том случае, если на сервере имеется несколько почтовых баз, с целью сохранения производительности сервера Exchange, не рекомендуется одновременно запускать New-MailboxRepairRequest сразу для большого количества баз (не смотря на то что, для одной базы поддерживается только один процесс MailboxRepairRequest, в рамках одного сервера одновременно может работать до 100 запросов).

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

Пользователь Exchange столкнулся с невозможностью просмотра писем в одной из папок Outlook. Указанная папка была восстановлена из резервной копии ящика. Однако саму папку ни из Outlook, ни из Outlook Web App, ни даже hard и soft удалением с помощью MFCMAPI, удалить не получилось. Ошибка клиента Outlook, мало о чем говорит:

Cannot delete this folder. Right-click the folder, and then click Properties to check your permissions for this folder. See the folder owner or your administrator to change your permissions. Outlook is synchronizing local changes made to items in this folder. You cannot remove this folder until the synchronization with the server is complete

outlook ошибка удаления папки

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

New-MailboxRepairRequest -Mailbox [email protected] -CorruptionType ProvisionedFolder,SearchFolder,AggregateCounts,Folderview

New-MailboxRepairRequest командлет Powershell

После успешного завершения операции восстановления (событие 10048 в журнале), поврежденная папка в Outlook Web App пропала немедленно, в Outlook же, для корректного отображения «обновленного» ящика пришлось удалить локальный кэш (ost файл).

Статья посвящена достаточно распространенной проблеме, с которой рано или поздно сталкиваются все администраторы Exchange – повреждение (логические ошибки) в почтовом ящике пользователя. Подобные логические ошибки проявляются в таких проблемах, как ошибки синхронизации и зависания в Outlook , неправильное представление элементов в папке, их неверное количество, сбои в поиске, ошибки в общих папках и т.д.

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

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

  • Импорту данных из Outlook, запущенного в режиме кэширования, в PST файл, удалению и пересозданию почтового ящика «проблемного» пользователя на сервере, и, наконец, импорту данных из PST-файла в новый ящик Exchange. Данная методика предполагает определенное количество ручных манипуляция на компьютере пользователя.
  • Полное отключение (размонтирование) почтового хранилища и его проверка утилитой Isinteg.exe (Information Store Integrity Checker), позволяющей исправить повреждения в базе Exchange на уровне приложения. Данный метод требует довольно длительного простоя почтового сервиса для всех пользователей, чьи ящики располагаются в отключенной базе.

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

  • Восстановление почтовой базы Exchange из резервной копии, импорт данных конкретного ящика в PST файл и дальнейший перенос данных в пересозданный ящик. Такая методика имеет недостаток – будут потеряны все письма, которые попали в ящик пользователя после выполнения последнего бэкапа.

Описанными выше методиками приходилось пользоваться администраторам Exchange-серверов вплоть до выхода Exchange 2010 SP1, в котором появился более удобный функционал для восстановления логической структуры поврежденного ящика – комадлет Powershell New-MailboxRepairRequest. Данный командлет позволяет на прикладном уровне найти и исправить логические ошибки и повреждения в базе Exchange, причем поиск и исправление ошибок может производиться как для конкретного ящика, так и для всех ящиков в базе (последовательно). Т.е. не требуется целиком переводить почтовую базу в режим offline, а в каждый конкретный момент времени будет недоступен только один ящик, тот, для которого в данный момент проводится проверка и восстановление целостности. Перед выполнением одного из описанных выше радикальных способов восстановления целостности ящика, определенно стоит попробовать воспользоваться этой командой.

Данный командлет можно использовать для поиска, восстановления и мониторинга поврежденных ящиков во всех поддерживаемых версиях Exchange: 2010 ,2013 и 2016.

Синтаксис команды таков:

New-MailboxRepairRequest -Mailbox <MailboxIdParameter> -CorruptionType <MailboxStoreCorruptionType[]> [-Archive <SwitchParameter>] [-Confirm [<SwitchParameter>]] [-DetectOnly <SwitchParameter>] [-DomainController <Fqdn>] [-WhatIf [<SwitchParameter>]]

Командлет позволяет найти и исправить следующие типы повреждений в ящиках Exchange:

  • SearchFolder – ошибки в папках поиска
  • AggregateCounts – проверка и исправление информации о количестве элементов в папках и их размере
  • FolderView – неверное содержимое, отображаемое представлениями папок
  • ProvisionedFolder – нарушения логической структуры папок

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

New-MailboxRepairRequest -Mailbox winitpro -DetectOnly -CorruptionType ProvisionedFolder, SearchFolder

Следующий пример запустит процесс анализа и восстановления ящика пользователя winitpro на все 4 типа повреждений:

New-MailboxRepairRequest -Mailbox winitpro -CorruptionType ProvisionedFolder, SearchFolder, AggregateCounts, Folderview

Так можно запустить поиск ошибок и их восстановление для всех ящиков базы:

New-MailboxRepairRequest -Database “MailBaseMsk1” -CorruptionType ProvisionedFolder, SearchFolder, AggregateCounts, Folderview

Команда выполняется в фоновом режиме и в консоль PowerShell результатов выполнения не выводит. Отследить ее запуск и восстановление можно по идентификатору задачи RequestID и журналу событий Windows (источник событий MSExchangeIS Mailbox Store: событие EventID 10059 — запуск сканирования, EventID 10048 успешное завершение операции).

Также могут быть полезными следующие EventID (для удобства отслеживания процедуры восстановления ящиков Exchange, их можно собрать в отдельное представление журнала MSExchangeIS Mailbox Store)

  • 10044 – ошибка выполнения запроса восстановления ящика
  • 10045 — ошибка выполнения запроса восстановления базы
  • 10046 – Восстановление логической структуры ящика завершено успешно
  • 10047 – запуск запроса восстановления уровня ящика
  • 10048 – запрос восстановления успешно завершен
  • 10049 – ошибка выполнения восстановления, обнаружен другой выполняющийся запрос в этой же базе
  • 10050 –запрос восстановления пропущен для ящика
  • 10051 – запрос восстановления отменен из-за того, что база отмонтирована
  • 10059 – запуск восстановления на уровне базы Exchange
  • 10062 – обнаружено повреждние
  • 10064 – запуск восстановления общей папки

exchange - событие окончание восстановления поврежденного ящика

Совет. В Exchange 2013 появился специальный командлет Get-MailboxRepairRequest, позволяющий узнать статус выполнения операции восстановления ящика.

Примечание. Одной из особенностей командлета New-MailboxRepairRequest – после его запуска, процедуру исправления ящика нельзя прервать без остановки службы Exchange Information Store и отмонтирования почтовой базы.

В том случае, если на сервере имеется несколько почтовых баз, с целью сохранения производительности сервера Exchange, не рекомендуется одновременно запускать New-MailboxRepairRequest сразу для большого количества баз (не смотря на то что, для одной базы поддерживается только один процесс MailboxRepairRequest, в рамках одного сервера одновременно может работать до 100 запросов).

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

Пользователь Exchange столкнулся с невозможностью просмотра писем в одной из папок Outlook. Указанная папка была восстановлена из резервной копии ящика. Однако саму папку ни из Outlook, ни из Outlook Web App, ни даже hard и soft удалением с помощью MFCMAPI, удалить не получилось. Ошибка клиента Outlook, мало о чем говорит:

Cannot delete this folder. Right-click the folder, and then click Properties to check your permissions for this folder. See the folder owner or your administrator to change your permissions. Outlook is synchronizing local changes made to items in this folder. You cannot remove this folder until the synchronization with the server is complete

outlook ошибка удаления папки

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

New-MailboxRepairRequest -Mailbox [email protected] -CorruptionType ProvisionedFolder,SearchFolder,AggregateCounts,Folderview

New-MailboxRepairRequest командлет Powershell

После успешного завершения операции восстановления (событие 10048 в журнале), поврежденная папка в Outlook Web App пропала немедленно, в Outlook же, для корректного отображения «обновленного» ящика пришлось удалить локальный кэш (ost файл).

00В прошлой статье мы обсудили вопрос мягкого восстановления базы данных при помощи команды Esutil /R. В подавляющем большинстве случаев эта команда отрабатывает успешно и базу удается смонтировать на сервер. Но бывают и такие ситуации, когда база сильно повреждена и мягко восстановить её не получается, в таких случаях необходимо попытаться вытащить из базы как можно больше информации.

Исправление

Для исправления базы данных придется использовать команду ESEUTIL /P. Стоит несколько раз подумать, прежде чем пользоваться функцией Repair, т.к. данная операция в ЛЮБОМ случае приведет к потере данных, и сколько именно данных будет потеряно спрогнозировать не реально, можно только с уверенностью сказать, что информация, находящаяся в лог-файлах будет на 100% потеряна.

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

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

eseutil /P MDB2.edb

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

clip_image003

Рис.1: Предупреждение перед операцией Repair.

Если все же вы твердо решили продолжать, то нужно нажать ОК и утилита ESEUTIL сделает все сама.

clip_image005

Рис.2: Исправление базы при помощи команды ESEUTIL /P.

После операции Repair может быть заметно снижена производительность базы данных, в связи с этим рекомендуется делать автономную дефрагментацию базы при помощи команды ESEUTIL /D, в результате выполнения команды будет создана абсолютно новая база данных, но тут нужно помнить, что для дефрагментации базы у вас должно быть свободного места больше на 110%, чем занимает исходная база.

Проверка логической целостности

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

isinteg -s имя_сервера -fix -test alltests

тем самым инициировав процесс проверки базы данных.

clip_image006

Рис.3: Проверка логической целостности базы при помощи ISINTEG.

Описание программы ISINTEG.

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

Exchange 2010

Плюсом к этому, с приходом Exchange 2010 ISINTEG перестала понимать все функции новой базы данных. Но это и нормально, ведь данное средство не изменялось с 2000-го года!

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

clip_image007

Рис.4: Фоновое обслуживание базы данных.

Exchange 2010 SP1

С входом Exchange 2010 SP1, появилась замена средства ISINTEG в виде новых командлетов:

· New-MailboxRepairRequest – тестирование и исправление почтовых ящиков;

· New-PublicFolderDatabaseRepairRequest – тестирование и исправление общих папок.

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

Синтаксис использования командлетов следующий:

new-MailboxRepairRequest [-Mailbox <MailboxID> | -Database <DatabaseID>] -CorruptionType <CorruptionType> [-DetectOnly] [-DomainController <FQDN>]

Здесь

· Mailbox или Database – это соответственно почтовый ящик или база данных;

· CorruptionType – вид проверки, которую вы желаете запустить:

o SearchFolder;

o AggregateCounts;

o ProvisionedFolder;

o FolderView.

· DetectOnly – используется, если вы хотите лишь обнаружить ошибки, но не исправлять их;

· DomainController – определяет контроллер домена для обновления данных.

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

New-MailboxRepairRequest -Mailbox <MailboxID> -CorruptionType SearchFolder,AggregateCounts,ProvisionedFolder,FolderView

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

New-MailboxRepairRequest –Database MDB2 –CorruptionType AggregateCounts

clip_image009

Рис.5: Проверка всей базы.

В результате команда будет выполняться в фоновом режиме, а вам будет доступен её RequestID. Также в журнале событий Windows вы найдете событие под номером EventID = 10059, которое будет означать запуск сканирования

clip_image011

Рис.6: Запуск сканирования базы данных в журнале событий Windows.

И событие с EventID = 10048, которое будет означать успешное завершение операции.

clip_image013

Рис.7: Завершение операции сканирования базы данных в журнале событий Windows.

Заключение

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

Почтовый ящик в Exchange может быть поврежден или поврежден. Это может произойти по разным причинам, таким как перемещение почтового ящика в другую базу данных. Это также может произойти из-за повреждения из-за сбоя системы, неправильного завершения работы сервера или вирусной атаки. У пользователя с поврежденным почтовым ящиком могут возникнуть проблемы. Некоторые из проблем связаны с неправильным количеством элементов в папках. Также возможно, что результаты не отображают правильное содержимое в поиске. Давайте узнаем и узнаем, как восстановить поврежденный почтовый ящик.

Содержание

  1. Как восстановить поврежденный почтовый ящик
  2. Как проверить почтовый ящик в Exchange на наличие ошибок без восстановления. 
  3. Как починить один почтовый ящик Exchange ?
  4. Как починить все почтовые ящики в базе данных Exchange ?
  5. При восстановлении почтового ящика Exchange — Queued 0%

Как восстановить поврежденный почтовый ящик

Запустите командлет New-MailboxRepairRequest , чтобы обнаружить и восстановить поврежденный почтовый ящик. Командлет New-MailboxRepairRequest доступен только для следующих серверов Exchange:

  • Exchange Server 2010
  • Exchange Server 2013
  • Exchange Server 2016
  • Exchange Server 2019

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

Командлет может восстанавливать четыре типа повреждений почтового ящика:

  • Ошибки в папках поиска ( SearchFolder ).
  • Ошибки в количестве папок, которые не отражают правильные значения ( AggregateCounts ).
  • Ошибки в папках, которые не возвращают правильное содержимое ( FolderView ).
  • Ошибки в структуре папок в почтовом ящике ( ProvisionedFolder ).

Чтобы избежать каких-либо проблем с производительностью, существуют ограничения на количество одновременных запросов на восстановление, отправляемых на сервер. Только один запрос может быть активен для восстановления на уровне базы данных, или до 100 запросов могут быть активны для восстановления.

Обнаружение повреждений только для определенного почтового ящика без восстановления

Запустите Exchange Management Shell от имени администратора и выполните следующую команду.

[PS] C:>New-MailboxRepairRequest –Mailbox "admin@alukashin.ru" –CorruptionType SearchFolder, AggregateCounts, ProvisionedFolder, FolderView -DetectOnly

Identity                                                                  Task                                                           Detect Only Job State Progress
--------                                                                  ----                                                           ----------- --------- --------
68sdd69-cafc-4144-87b3-497e1fe1720df568b725-65a3-4e3a-b865-aa24cc009426 {SearchFolder, AggregateCounts, ProvisionedFolder, FolderView} True        Queued    0

Получим статус о восстановлении.

[PS] C:>Get-MailboxRepairRequest -Mailbox "admin@alukashin.ru"

Identity                                                                                                       Task                Detect Only Job State Progress
--------                                                                                                       ----                ----------- --------- --------
68db0169-cafc-4144-87b3-797e1fe1720df568b725-65a3-4e3a-b865-aa24cc009426d3a55901-762e-439f-89b0-81cd74732fdf {SearchFolder}      True        Queued    0
68db0169-cafc-4144-87b3-797e1fe1720df568b725-65a3-4e3a-b865-aa24cc009426e9eefd18-301a-45f5-a127-89c54cd2d3cf {AggregateCounts}   True        Queued    0
68db0169-cafc-4144-87b3-797e1fe1720df568b725-65a3-4e3a-b865-aa24cc0094266f10428d-2a9f-4726-8acb-f051e6ab7bfa {ProvisionedFolder} True        Queued    0
68db0169-cafc-4144-87b3-797e1fe1720df568b725-65a3-4e3a-b865-aa24cc0094269f22a529-030b-405d-b121-984be4d5569f {FolderView}        True        Queued    0

Он покажет восстановление почтового ящика  Detect Only как  True и Job State как Queued .

Вам нужно немного подождать, прежде чем работа завершится. Выполните предыдущую команду Get-MailboxRepairRequest . Вы можете продолжать выполнять команду, пока не увидите состояние задания как успешное .

[PS] C:>Get-MailboxRepairRequest -Mailbox "admin@alukashin.ru" можно также использовать 

Get-MailboxRepairRequest -Identity68db0169-cafc-4144-87b3-797e1fe1720df568b725-65a3-4e3a-b865-aa24cc009426d3a55901-762e-439f-89b0-81cd74732fdf
Identity                                                                                                       Task                Detect Only Job State Progress
--------                                                                                                       ----                ----------- --------- --------
68db0169-cafc-4144-87b3-797e1fe1720df568b725-65a3-4e3a-b865-aa24cc009426d3a55901-762e-439f-89b0-81cd74732fdf {SearchFolder}      True        Succeeded 100
68db0169-cafc-4144-87b3-797e1fe1720df568b725-65a3-4e3a-b865-aa24cc009426e9eefd18-301a-45f5-a127-89c54cd2d3cf {AggregateCounts}   True        Succeeded 100
68db0169-cafc-4144-87b3-797e1fe1720df568b725-65a3-4e3a-b865-aa24cc0094266f10428d-2a9f-4726-8acb-f051e6ab7bfa {ProvisionedFolder} True        Succeeded 100
68db0169-cafc-4144-87b3-797e1fe1720df568b725-65a3-4e3a-b865-aa24cc0094269f22a529-030b-405d-b121-984be4d5569f {FolderView}        True        Succeeded 100
[PS] C:Windowssystem32>get-MailboxRepairRequest -Mailbox "admin@alukashin.ru" |fl


RunspaceId          : 898704ed-2b19-4ebb-86b5-2ecffec62e8d
Identity            : 16382aaf-b22b-4ebf-8192-8e2cfd7e92bf93499ad1-90d4-4d1d-bb04-37387516dc32
Mailbox             : 51f91dcf-f5ce-4ffd-aa62-812d6b2b8939
Source              : OnDemand
Priority            : Normal
DetectOnly          : True
JobState            : Succeeded
Progress            : 100
Tasks               : {SearchFolder, AggregateCounts, ProvisionedFolder, FolderView}
CreationTime        : 12/6/2022 2:10:40 PM
FinishTime          : 12/6/2022 2:14:52 PM
LastExecutionTime   : 12/6/2022 2:14:52 PM
CorruptionsDetected : 0
ErrorCode           :
CorruptionsFixed    : 0
TimeInServer        : 00:00:06.7680000
Corruptions         : {}
IsValid             : True
ObjectState         : New

CorruptionsDetected : 0
CorruptionsFixed : 0

Как починить один почтовый ящик Exchange ?

[PS] C:>New-MailboxRepairRequest -Mailbox "admin@alukashin.ru" -CorruptionType SearchFolder, AggregateCounts, ProvisionedFolder, FolderView

Identity                                                                  Task                                                           Detect Only Job State Progress
--------                                                                  ----                                                           ----------- --------- --------
68db0169-cafc-4144-87b3-797e1fe1720df1347601-ac44-455f-81f3-0b50d56aa92c {SearchFolder, AggregateCounts, ProvisionedFolder, FolderView} False       Queued    0
Также можно использовать только один из четырех типов повреждения почтового ящика для определенного почтового ящика.
[PS] C:>New-MailboxRepairRequest -Mailbox "admin@alukashin.ru" -CorruptionType SearchFolder

Identity                                                                                                       Task           Detect Only Job State Progress
--------                                                                                                       ----           ----------- --------- --------
68db0169-cafc-4144-87b3-797e1fe1720d404e2799-b7e8-4e6d-b3db-54333d2ee1188cbc3d82-b9bb-4821-bc91-0d50d392f35a {SearchFolder} False       Queued    0

Вы можете использовать имя пользователя, если вы не знаете адрес электронной почты. Замените электронную почту admin@alukashin.ru на имя пользователя Alexey Lukashin.

Как починить все почтовые ящики в базе данных Exchange ?

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

[PS] C:>New-MailboxRepairRequest –Database "DB1" –CorruptionType SearchFolder, AggregateCounts, ProvisionedFolder, FolderView -DetectOnly

Получить статус восстановления почтового ящика в базе данных.

[PS] C:>Get-MailboxRepairRequest -Database "DB1"

Обнаружение и устранение повреждений почтовых ящиков в базе данных.

[PS] C:>New-MailboxRepairRequest –Database "DB1" –CorruptionType SearchFolder, AggregateCounts, ProvisionedFolder, FolderView

Также возможно использовать только один из четырех типов повреждения почтовых ящиков для всех почтовых ящиков в базе данных.

[PS] C:>New-MailboxRepairRequest –Database "DB1" –CorruptionType ProvisionedFolder

При восстановлении почтового ящика Exchange — Queued 0%

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

[PS] C:Windowssystem32>Get-MailboxRepairRequest -Database db25eu

Identity                                                                                                       Task                Detect Only Job State Progr
                                                                                                                                                         ess
--------                                                                                                       ----                ----------- --------- -----
8e722900-d1a2-498f-8aca-e4a15a73aeda5f162bf5-8c41-4735-865f-d76a6163f20b24ec5220-814e-4cd1-876a-2d01288debca {FolderView}        True        Queued    0
8e722900-d1a2-498f-8aca-e4a15a73aeda5f162bf5-8c41-4735-865f-d76a6163f20b76491636-f52c-4217-88d7-e6bba0a86399 {ProvisionedFolder} True        Queued    0
8e722900-d1a2-498f-8aca-e4a15a73aeda5f162bf5-8c41-4735-865f-d76a6163f20bba024b9e-826a-40bf-af30-ef22cf05ac5e {AggregateCounts}   True        Queued    0
8e722900-d1a2-498f-8aca-e4a15a73aeda5f162bf5-8c41-4735-865f-d76a6163f20b59d2e885-f5b4-4cfa-bbbc-64ffa53e1fee {SearchFolder}      True        Queued    0
8e722900-d1a2-498f-8aca-e4a15a73aeda5f162bf5-8c41-4735-865f-d76a6163f20b1ba9c1ba-1481-4790-babf-aedd578a1a6b {FolderView}        True        Queued    0
8e722900-d1a2-498f-8aca-e4a15a73aeda5f162bf5-8c41-4735-865f-d76a6163f20b2ca2cfde-1b7a-481c-bb59-150bcc20fcc1 {ProvisionedFolder} True        Queued    0
8e722900-d1a2-498f-8aca-e4a15a73aeda5f162bf5-8c41-4735-865f-d76a6163f20bc1ecade3-880a-4c95-9c9d-a54338605e7d {AggregateCounts}   True        Queued    0
8e722900-d1a2-498f-8aca-e4a15a73aeda5f162bf5-8c41-4735-865f-d76a6163f20b74ed0e58-b8c8-44f5-b677-d1a849b175c9 {SearchFolder}      True        Queued    0
8e722900-d1a2-498f-8aca-e4a15a73aeda5f162bf5-8c41-4735-865f-d76a6163f20b136a811d-6d58-46e7-9fd3-f68d0cd6b5f1 {FolderView}        True        Queued    0
8e722900-d1a2-498f-8aca-e4a15a73aeda5f162bf5-8c41-4735-865f-d76a6163f20b7e00a802-d3cd-4676-821c-8a838369e6f9 {ProvisionedFolder} True        Queued    0
8e722900-d1a2-498f-8aca-e4a15a73aeda5f162bf5-8c41-4735-865f-d76a6163f20b3006cbb8-9aca-4a04-a25b-5ac075256688 {AggregateCounts}   True        Queued    0
8e722900-d1a2-498f-8aca-e4a15a73aeda5f162bf5-8c41-4735-865f-d76a6163f20b556b246a-26a5-4282-ac52-3a9accda5f4e {SearchFolder}      True        Queued    0
8e722900-d1a2-498f-8aca-e4a15a73aeda5f162bf5-8c41-4735-865f-d76a6163f20bf2c4489b-1f55-49a8-8120-ef9b19de9efb {FolderView}        True        Queued    0
8e722900-d1a2-498f-8aca-e4a15a73aeda5f162bf5-8c41-4735-865f-d76a6163f20b72432b19-f737-4e44-a89c-2de284c13230 {ProvisionedFolder} True        Queued    0
8e722900-d1a2-498f-8aca-e4a15a73aeda5f162bf5-8c41-4735-865f-d76a6163f20b161b19d1-f326-4fa2-b318-cd0669cb854c {AggregateCounts}   True        Queued    0
8e722900-d1a2-498f-8aca-e4a15a73aeda5f162bf5-8c41-4735-865f-d76a6163f20b44129eab-e93f-47ba-828a-7ed0af4a1ac6 {SearchFolder}      True        Queued    0
  1. Проверить все службы ( get-service *exch*
  2. Проверить почтовый ящик в карантине

qura

Проверить почтовый ящик карантина Exchange через реестр по пути который на скриншоте
  1. Есть ли порушенный DAG , в котором как пример есть пассивная копия которая находится на сервере который уже не обслуживается. Удалить копию можно командой.
Remove-MailboxDatabaseCopy -Identity DB1MBX1 -Confirm:$False
Профилактика для сохранения работоспособности почтовой системы

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

  1. Проверка событий резервного копирования.
  2. Проверка системных журналов событий.
  3. Проверка дисковой системы.
  4. Проверка обновлений антивирусных баз.
  5. Проверка очередей.
  6. Проверка квитанций о недоставке (NDR).
  7. Проверка оборудования.

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

1. Проверка событий резервного копирования

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

Чтобы убедиться в пригодности резервной копии, проверять надо процедуры резервирования для каждой установленной системы Exchange. Обычно резервное копирование на файловом уровне выполняется, когда сохраняемые файлы не используются. В случае с системой Exchange файлы баз данных свободны только тогда, когда система остановлена. К счастью, Exchange предоставляет API, который позволяет программам резервного копирования работать в тандеме с модулем Extensible Storage Engine (ESE) и выполнять копирование, когда базы данных используются.

Во время резервного копирования ESE читает базы данных и передает информацию программе резервирования, которая, в свою очередь, сохраняет эту информацию на резервном носителе данных. Поскольку два компонента (т. е. ESE и программа резервирования) работают с данными во время резервирования, важно убедиться, что каждый компонент сохраняет данные без ошибок. Табл. 1 можно использовать для интерпретации системного журнала Application. Она включает события, связанные с работой ESE и NTBackup — штатной программы резервного копирования Windows 2000. ID событий от программы резервирования зависят от используемого программного обеспечения, а ID от ESE будут оставаться неизменными.

Интерпретировать события в системном журнале очень просто. Например, посмотрим на окно с журналом Application, показанное на экране 1. События с ID 8000 и 8001 показывают время начала и завершения резервного копирования со стороны NTBackup. События с ID 210 и 213 показывают время начала и завершения полного резервного копирования со стороны ESE. Другие виды резервирования, такие как инкрементальное и дифференциальное, будут отличаться соответствующими ID.


Экран 1. Журнал приложений Exchange 2000

События NTBackup с ID 8008 и 8009 показывают начало и завершение процесса верификации. Во время процесса верификации NTBackup читает данные и соответствующие контрольные суммы с носителя резервной копии для подтверждения пригодности сохраненных данных. Если возникает аппаратная ошибка или сбой носителя, то NTBackup сообщает об ошибке. Поскольку процесс верификации завершается после сообщения ESE об успешном завершении резервного копирования, для уверенности в нормальном сохранении данных Exchange необходимо убедиться в отсутствии сообщений об ошибках от программного обеспечения, выполняющего резервное копирование. Поэтому только после сообщений об успешном завершении резервного копирования от всех источников можно считать, что получена работоспособная копия данных.

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

Проверяя сообщения о событиях резервного копирования, можно судить о состоянии баз данных. При выполнении полного резервного копирования ESE читает базы данных порциями, которые называются страницами. Каждая страница содержит контрольную сумму, взглянув на которую администратор может убедиться, что данные в странице не повреждены. API резервного копирования высчитывает новую контрольную сумму и сравнивает с хранящейся версией для выявления нарушений. Если ESE находит сбой, в журнал заносится сообщение об ошибке и резервное копирование прерывается. О таких сообщениях об ошибках рассказывается в статье Microsoft «XADM: Understanding and Analyzing -1018, -1019, and -1022 Exchange Database Errors» (http://support.microsoft.com/default.aspx?scid=kb;en-us;q314917). Важно как можно раньше обнаружить наличие данного типа ошибок. Если не заметить эту проблему и продолжить эксплуатировать Exchange, возникнет реальный риск не восстановить в случае сбоя базы и все транзакции, поскольку в резервной копии не будет полноценного набора необходимых данных.

2. Проверка системных журналов событий

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

По умолчанию Exchange записывает большое количество данных в системные журналы. Определив базовое состояние, можно сэкономить время, поскольку уже будет известно, на какие именно сообщения следует обратить внимание. Одни информационные сообщения, такие как были описаны выше (о выполнении резервного копирования), критичны для регулярного контроля, другие — нет. Например, событие с ID 1221 сообщает об освобождении свободного пространства в хранилище. Когда пользователи удаляют свои сообщения из почтовых ящиков, Exchange не уменьшает размер хранилища почтовых ящиков, а вместо этого устанавливает флаг, означающий, что данные удалены. Такой тип информации поможет сэкономить дисковое пространство. В табл. 2 приведен список событий, на которые обычно можно не обращать внимания при ежедневном осмотре.

При определении базового состояния следует сосредоточиться на сообщениях об ошибках и предупреждениях. При изучении таких событий необходимо понять, что есть причина, а что следствие. Например, в журнале обнаружено событие с ID 2090, показанное на экране 2. Если разбираться с этим сообщением, то надо отыскать в свойствах сервера Exchange закладку Directory Access (она появилась в Exchange 2000 Service Pack 2) для определения ситуации с контроллером домена (DC) или сервером глобального каталога (GC), к которому необходим доступ, но в данный момент он недоступен. Из всех перечисленных DC и GC оставить надо только те, которые необходимо, так как сбой может быть следствием того, что Exchange и текущий сервер GC находятся на разных территориях и между ними — медленный канал связи.


Экран 2. Событие, вызванное недосягаемостью контроллера домена

Если в сети много серверов Exchange, просмотр системных журналов становится нелегкой задачей. Для ее решения можно задействовать автоматизированные средства мониторинга, такие как Microsoft Operations Manager (MOM), Aelita Software EventAdmin, NetIQ AppManager Suite (AppManager) или Hewlett-Packard HP OpenView. Эти продукты предоставляют механизмы, позволяющие фильтровать события, которые нет необходимости отслеживать. Кроме того, эти продукты предоставляют дополнительные возможности по уведомлениям в случае возникновения важных событий.

3. Проверка дисковой системы

Серверы Exchange могут останавливаться из-за недостаточного количества свободного места на диске, что является серьезной проблемой для многих администраторов. Обычно на серверах Exchange имеются отдельные диски для операционной системы, для журналов транзакций и для хранилища. На некоторых серверах также могут быть отдельные диски для других компонентов, таких как журналы отслеживания сообщений, очереди коннекторов SMTP, карантины для перехваченных антивирусным программным обеспечением файлов. Важно проверять свободное дисковое пространство на каждом диске каждый день, чтобы быть уверенным в том, что система не остановится из-за нехватки свободного места. Достаточное количество свободного пространства на дисках зависит от таких факторов, как объем передаваемой информации через почтовую систему в день и требования стандартных процедур Exchange по работе с журналами, файлами карантина и другими файлами. Для выполнения соответствующих проверок свободного дискового пространства необходимо следующее.

  • Убедиться, что Exchange чистит журналы транзакций. Перед выполнением полного резервного копирования всех баз данных в рамках группы хранения (SG) можно увидеть журналы транзакций со времени последнего выполнения такого резервного копирования. Exchange чистит журналы транзакций только при успешном завершении резервирования всех баз данных в SG. Если вы увидите старые журналы, это означает, что Exchange не очищал их, и это косвенно говорит о том, что базы данных не были успешно скопированы.
  • Проверить размер антивирусных карантинов и отчетов. Некоторые поставщики антивирусных программ заявляют, что производительность их продуктов может падать при большом увеличении файлов в зоне карантина. Это, вероятно, происходит потому, что программное обеспечение записывает файлы на диск последовательно и со временем их может скопиться очень много. Но эта проблема не является реально опасной в промышленной среде. В большинстве случаев отчеты и файлы карантина хранятся от 15 до 30 дней, в зависимости от организации и принятых в ней порядков. Такой период времени позволяет восстановить файл в случае ошибочного попадания в карантин.
  • Проверить размер каталога журналов SMTP и очистить в случае необходимости. Несмотря на то что Exchange позволяет управлять файлами журналов, они все равно последовательно заполняются и старые журналы автоматически не удаляются. Нельзя позволять журналам накапливаться бесконтрольно, это может привести к сбою. Если каталог с журналами находится на системном диске по умолчанию, то Windows может дать сбой при заполнении всего дискового пространства. Если каталог с журналами находится на диске с каталогами виртуального сервера SMTP, то этот сервер SMTP может остановить обработку писем, пока не освободится дисковое пространство. Журналы имеет смысл хранить от 21 до 30 дней. В случае возникновения проблем этого срока вполне достаточно, чтобы разобраться в причинах.
  • Удалить устаревшие архивные сообщения. Если используются возможности архивирования протокола SMTP, следует убедиться в том, что архивные сообщения удалены или перемещены в другой каталог, прежде чем заканчивается срок хранения сообщений для данного каталога, установленный исходя из здравого смысла. Компании архивируют сообщения по разным причинам — от выявления неполадок до контроля содержимого переписки. Но если не слишком активно заниматься управлением архивом сообщений и удалением лишнего, все доступное дисковое пространство будет быстро заполняться.

4. Проверка обновлений антивирусных баз

Когда в систему попадет очередной вирус, неизвестно. Лучшей защитой от вирусов является регулярное обновление баз установленного антивирусного программного обеспечения. Проверять наличие обновлений антивирусных баз необходимо не реже чем один раз в день. Обычно антивирусное программное обеспечение, обработав и установив новые базы, делает соответствующую запись в системный журнал Windows. Если антивирусная программа не вносит записи в журнал событий, то, возможно, она записывает информацию в собственный журнал. Например, Sybari Software Antigen записывает информацию об обновлениях в файл programlog.txt, а Trend Micro ScanMail for Microsoft Exchange записывает свои события в update.log. Проверяя журнал Windows или собственный журнал антивирусной программы, необходимо убедиться, что обновления баз были успешно получены и корректно установлены.

Можно считать это неинтеллектуальной задачей, но в некоторых случаях могут возникать серьезные проблемы. Например, одна компания отключила соединение с Internet, когда появился вирус Nimda. Поскольку антивирусное программное обеспечение не могло получить доступ к сайту разработчика для загрузки обновлений, администратор Exchange использовал коммутируемое соединение для загрузки обновлений и записи их на компакт-диск. Когда администратор скопировал обновления с компакт-диска на сервер, он оставил у файлов атрибут read-only. Позднее, когда компания восстановила соединение с Internet, процесс автоматического обновления завершился со сбоем, поскольку новые файлы антивирусных баз не могли перезаписать старые файлы.

5. Проверка очередей

Сервер Exchange, обрабатывая очень большой объем почтовых сообщений, может на некоторое время задерживать их в своих очередях. Наличие сообщений в очередях в течение длительного срока обычно указывает на ненормальную работу системы, о чем может сообщаться в системном журнале. Пиковый рост очередей может возникать при отправке сообщений по большим спискам рассылки (DL), при отправке очень больших сообщений нескольким получателям или когда сервер получателя подключен по медленному сетевому каналу. Такие ситуации не являются аварийными. Аварийной можно считать ситуацию, когда в очередях накапливаются тысячи сообщений для одних серверов получателей или когда появляется множество очередей для разных серверов и доменов. Наличие тысяч сообщений в очереди для одного получателя говорит о зацикливании при отправке почты или об атаке типа «отказ в обслуживании» (Denial of Service, DoS). Наличие множества очередей с сообщениями для разных серверов и доменов говорит о том, что на сервере произошел сбой, системная служба остановлена или сбои в сети не позволяют серверу установить соединение.

Для того чтобы оценить критичность ситуации, необходимо определить базовое состояние, по которому решать — нормальное положение или нет. Для табличного отображения очередей можно задействовать утилиту MailQ из Microsoft Exchange Server Resource Kit. Если по очередям будет видно наличие проблемы, исследовать ее причины можно с помощью Exchange System Manager (ESM).

6. Проверка квитанций о недоставке (NDR)

NDR приходят всегда. Основные причины появления NDR — неверное написание имени получателя или отказ сервера получателя принять сообщение. Серверы посылают NDR отправителю сообщения, но систему можно настроить так, чтобы копии отчетов шли в назначенный администратором почтовый ящик. Эта возможность настраивается в ESM в диалоговом окне свойств для каждого виртуального сервера SMTP. На закладке Messages следует ввести соответствующий адрес в формате SMTP в поле Send copy of non-delivery reports to. После внесения такого изменения в настройках надо остановить и снова запустить виртуальный сервер.

Пробовать определять и корректировать информацию для каждого NDR — это задача не на каждый день. Вместо этого достаточно будет сравнивать количество NDR с выбранным базовым состоянием. Для определения такого базового состояния надо выбрать среднее значение отправленных или принятых NDR в течение недели. Их количество может варьироваться. Например, в понедельник может приходить 25 NDR каждые 10 минут, а в пятницу — 25 NDR в час.

Резкий скачок в количестве NDR обычно говорит о проблеме, такой как атака DoS или зацикливание в отправке почты. Зацикливание в отправке почты может возникнуть, когда у пользователя настроено правило для пересылки на личный почтовый ящик у провайдера Internet. Пользователи могут настраивать такую конфигурацию, несмотря на то что корпоративная почтовая система может не иметь выхода в Internet. Теоретически такие настройки не являются серьезной ошибкой. Однако можно ошибиться в имени личного почтового ящика у провайдера, этот почтовый ящик может переполниться или возникнет другой сбой, и сервер провайдера услуг Internet будет отсылать NDR, а пользовательское правило будет успешно их пересылать обратно на тот же адрес, который в данный момент недоступен. В результате возникает цикл NDR.

7. Проверка оборудования

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

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

Базовое состояние

Какой тип событий сервер Exchange обычно записывает в системный журнал? Как много сообщений обычно находится в очереди? Сколько NDR отправляется и принимается каждый день? Важно знать ответы на такие вопросы. Если не принимать во внимание типичное состояние системы, сложно вовремя заметить критическую для сервера ситуацию. Помочь в данном случае могут ежедневные проверки и определение на их основе базовых состояний, а также профилактический контроль состояния системы Exchange.

Джозеф Ньбауэр — Старший технический консультант HP, специалист по Windows и Microsoft Exchange Server. joseph.neubauer@hp.com

One of the most common problems for Exchange users is mailbox corruption, which can be caused by many reasons, including:

  • system and server failure
  • Exchange dirty shut-down
  • Malfunction of the system applications
  • virus or malware attacks
  • Users’ mistaken operations

Whatever the cause is, you can find answers here. On this page, we will focus on how to repair corrupted mailbox in Exchange 2016 in two ways: one is using Microsoft New-MailboxRepairRequest cmdlet (in Part 1) to manually fix the issue, the other is using EaseUS Exchange Recovery (in Part 2)  to recover mailbox automatically and effectively.

Part 1: Use New-MailboxRepairRequest cmdlet (Commands Needed)

New-MailboxRepairRequest can be used to easily repair corrupted mailbox in Exchange 2016. It enables users to detect and repair a specific mailbox corruption or the whole database damage in Exchange.

After a quick scanning of the following steps, you can see that this solution contains many commands. You need to troubleshoot manually. If you are new to Exchange and know little about it, you’d better directly use the much simpler Exchange Server recovery software in Part 2 to fix the problem in an automated way.

Before starting the process to repair corrupted mailbox Exchange 2016. You can run the commands below to first detect and report the corruption in the Exchange mailbox.

New-MailboxRepairRequest -Mailbox Alias -CorruptionType ProvisionedFolder,SearchFolder -DetectOnly

Run the following New-MailboxRepairRequest commands to repair corrupted mailbox in Exchange 2016.

1. Command to check and fix corruption in a single mailbox in Exchange 2016

New-MailboxRepairRequest -Mailbox [email protected] -CorruptionType FolderView

2. Command to check and repair all Corruption types for Alias mailbox and archive

New-MailboxRepairRequest -Mailbox alias -CorruptionType ProvisionedFolder,SearchFolder,AggregateCounts,Folderview -Archive

3. Command to check and repair all types of corruptions in mailboxes that have CustomAttribute4

Get-Mailbox -Filter {CustomAttribute4 -like “Repair Required”} | New-MailboxRepairRequest -CorruptionType SearchFolder,ProvisionedFolder, AggregateCounts,FolderView

4. Commands to create a variable that identifies Alias’ mailbox. Then, uses this the variable to specify the values for the StoreMailbox and Database parameters to create a request to detect and fix all types of corruptions.

$Mailbox = Get-MailboxStatistics annb; New-MailboxRepairRequest -Database $Mailbox.Database -StoreMailbox $Mailbox.MailboxGuid -CorruptionType ProvisionedFolder,SearchFolder,AggregateCounts,Folderview

After applying all commands, the corrupted mailbox in Exchange 2016 will be repaired. If not, continue to use an easier alternative to these complex commands to repair Exchange mailbox.

Part 2: Repair Corrupted Mailbox in Exchange 2016 Automatically

Is the above manual solution can’t help you, don’t worry, here comes the automated way to repair corrupted mailbox in Exchange 2016 with EaseUS Exchange Recovery, which allows you to quickly recover and repair corrupted Exchange Server mailboxes (EDB) files and contents.  

The outstanding features of this tool to repair corrupted Exchange Server/EDB/mailboxes.

  • Repair database when Eseutils Powershell Commands failed
  • Restore data after Dirty Shutdown or unexpected Exchange Server crash
  • Repair corrupted Exchange mailboxes of private and public folders
  • Export repaired mailboxes to MSG or live Exchange Server
  • Recover Dismounted/Offline EDB Mailbox
  • Supports MS Exchange Server 2019/2016/2013/2010

Step by step guide to repairing corrupted mailbox in Exchange 2016 with Exchange Server recovery software. 

Step 1. Download, install and launch the software. On the home screen, under «Select EDB file», click the three dots to browse and open the corrupted EBD file.

repair corrupted mailbox in Exchange

Step 2. Click «Analyze» to start analyzing the EDB file. When the process completes, all the mailboxes and contents will be listed in a tree-view on the left panel of the screen.

repair corrupted mailbox in Exchange

Step 3. You can select any mailbox to preview on the right side of the screen. Once you’ve found what you need to recover, check the items and click «Recover» to export to a live Exchange Server.

repair corrupted mailbox in Exchange

Step 4. Or you can choose «Export MSG» to export the recovered mailboxes to MSG.

repair corrupted mailbox in Exchange

One of the most common problems for Exchange users is mailbox corruption, which can be caused by many reasons, including:

  • system and server failure
  • Exchange dirty shut-down
  • Malfunction of the system applications
  • virus or malware attacks
  • Users’ mistaken operations

Whatever the cause is, you can find answers here. On this page, we will focus on how to repair corrupted mailbox in Exchange 2016 in two ways: one is using Microsoft New-MailboxRepairRequest cmdlet (in Part 1) to manually fix the issue, the other is using EaseUS Exchange Recovery (in Part 2)  to recover mailbox automatically and effectively.

Part 1: Use New-MailboxRepairRequest cmdlet (Commands Needed)

New-MailboxRepairRequest can be used to easily repair corrupted mailbox in Exchange 2016. It enables users to detect and repair a specific mailbox corruption or the whole database damage in Exchange.

After a quick scanning of the following steps, you can see that this solution contains many commands. You need to troubleshoot manually. If you are new to Exchange and know little about it, you’d better directly use the much simpler Exchange Server recovery software in Part 2 to fix the problem in an automated way.

Before starting the process to repair corrupted mailbox Exchange 2016. You can run the commands below to first detect and report the corruption in the Exchange mailbox.

New-MailboxRepairRequest -Mailbox Alias -CorruptionType ProvisionedFolder,SearchFolder -DetectOnly

Run the following New-MailboxRepairRequest commands to repair corrupted mailbox in Exchange 2016.

1. Command to check and fix corruption in a single mailbox in Exchange 2016

New-MailboxRepairRequest -Mailbox [email protected] -CorruptionType FolderView

2. Command to check and repair all Corruption types for Alias mailbox and archive

New-MailboxRepairRequest -Mailbox alias -CorruptionType ProvisionedFolder,SearchFolder,AggregateCounts,Folderview -Archive

3. Command to check and repair all types of corruptions in mailboxes that have CustomAttribute4

Get-Mailbox -Filter {CustomAttribute4 -like “Repair Required”} | New-MailboxRepairRequest -CorruptionType SearchFolder,ProvisionedFolder, AggregateCounts,FolderView

4. Commands to create a variable that identifies Alias’ mailbox. Then, uses this the variable to specify the values for the StoreMailbox and Database parameters to create a request to detect and fix all types of corruptions.

$Mailbox = Get-MailboxStatistics annb; New-MailboxRepairRequest -Database $Mailbox.Database -StoreMailbox $Mailbox.MailboxGuid -CorruptionType ProvisionedFolder,SearchFolder,AggregateCounts,Folderview

After applying all commands, the corrupted mailbox in Exchange 2016 will be repaired. If not, continue to use an easier alternative to these complex commands to repair Exchange mailbox.

Part 2: Repair Corrupted Mailbox in Exchange 2016 Automatically

Is the above manual solution can’t help you, don’t worry, here comes the automated way to repair corrupted mailbox in Exchange 2016 with EaseUS Exchange Recovery, which allows you to quickly recover and repair corrupted Exchange Server mailboxes (EDB) files and contents.  

The outstanding features of this tool to repair corrupted Exchange Server/EDB/mailboxes.

  • Repair database when Eseutils Powershell Commands failed
  • Restore data after Dirty Shutdown or unexpected Exchange Server crash
  • Repair corrupted Exchange mailboxes of private and public folders
  • Export repaired mailboxes to MSG or live Exchange Server
  • Recover Dismounted/Offline EDB Mailbox
  • Supports MS Exchange Server 2019/2016/2013/2010

Step by step guide to repairing corrupted mailbox in Exchange 2016 with Exchange Server recovery software. 

Step 1. Download, install and launch the software. On the home screen, under «Select EDB file», click the three dots to browse and open the corrupted EBD file.

repair corrupted mailbox in Exchange

Step 2. Click «Analyze» to start analyzing the EDB file. When the process completes, all the mailboxes and contents will be listed in a tree-view on the left panel of the screen.

repair corrupted mailbox in Exchange

Step 3. You can select any mailbox to preview on the right side of the screen. Once you’ve found what you need to recover, check the items and click «Recover» to export to a live Exchange Server.

repair corrupted mailbox in Exchange

Step 4. Or you can choose «Export MSG» to export the recovered mailboxes to MSG.

repair corrupted mailbox in Exchange

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

Когда учетная запись почтового ящика Microsoft Exchange настроена с помощью почтового клиента Outlook, создается OST-файл. Этот OST-файл хранит синхронизированную копию информации вашего почтового ящика на вашем локальном компьютере.

Иногда, когда ваше соединение с почтовым сервером прерывается, сервер не может синхронизировать все электронные письма в OST-файле. Таким образом, это создаст много проблем с синхронизацией.

Давайте обсудим проблемы, вызванные ошибкой синхронизации.

При возникновении ошибки синхронизации в Microsoft Outlook могут возникнуть следующие проблемы:

1: Это будет препятствовать важным функциям рассылки, таким как отправка и получение сообщений, удаление писем и т. Д.

2: Между сообщениями, которые вы получаете в Microsoft Outlook, и в Microsoft Outlook Web App есть различия или несоответствия.

3: Некоторые элементы, такие как сообщения электронной почты, встречи, контакты, задачи, записи журнала и заметки, отсутствуют в вашем OST-файле или в вашем почтовом ящике.

4: Эта проблема синхронизации может привести к внезапному сбою приложения Microsoft Outlook.

5: Это также может привести к зависанию или замедлению работы Outlook.

Ручные способы решения проблем синхронизации с почтовыми ящиками Exchange

Что ж, вот несколько быстрых обходных путей для решения проблемы синхронизации между почтовым ящиком сервера Microsoft Exchange и файлом OST:

1. Проверьте синхронизацию автономных папок.

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

1: Откройте Outlook и щелкните правой кнопкой мыши папку, которую необходимо проверить.

2: Перейдите в Свойства и щелкните вкладку синхронизации.

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

3: В разделе «Статистика» проверьте поле «Последняя синхронизация», в котором отображается дата.

4: Проверьте количество элементов на сервере и в автономной папке.

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

Если синхронизация не работает должным образом, это означает, что у вас проблемы с настройками профиля Outlook.

2: Запустите средство проверки целостности OST

Для Outlook 2003 или Outlook 2007 существует инструмент проверки целостности OST, известный как файл Scanost.exe, чтобы проверить, есть ли в вашем .OST-файле проблемы с синхронизацией. Инструмент может быстро устранить все проблемы с синхронизацией, восстановив потерянную информацию после сканирования OST-файла в вашей системе.

Но если в вашей системе установлен Outlook 2010 или другая последняя версия MS Outlook, вы можете не найти инструмент проверки целостности OST. Однако, если в конкретной папке есть проблемы с синхронизацией, вам просто нужно снова синхронизировать эту папку в приложении Microsoft Outlook, которое вы запускаете.

1: Для этого щелкните папку правой кнопкой мыши и перейдите в Свойства.

2: После этого нажмите «Очистить автономные элементы» и нажмите «ОК».

3: Щелкните вкладку «Отправка и получение» на ленте Outlook 2010 и щелкните ее.

4: Затем выберите опцию Обновить папку.

3. Восстановить OST-файл Outlook

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

1: Закройте приложение Outlook.

2: Откройте Почту из Панели управления.

3: Теперь нажмите «Учетные записи электронной почты» в диалоговом окне «Настройка почты».

4: Нажмите «Файлы данных», выберите файл OST, а затем нажмите «Открыть расположение файла» (перейдите в папку, в которой находится конкретный файл OST).

5: Щелкните правой кнопкой мыши файл OST и выберите параметр «Удалить», чтобы удалить OST-файл Outlook.

Примечание — Перед удалением файла закройте окно «Настройки учетной записи и настройки почты», иначе появится сообщение об ошибке.

6: Снова перезапустите приложение Outlook. Он автоматически создаст новый файл OST для учетной записи MS Outlook.

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

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

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

Заключительные слова

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

  • #1

Друзья привет! Собираем тут полезные командлеты для exchange server, то что необходимо каждый день, в одном месте.
Формат такой — код powershell и то что он делает. Возможно пояснить походу для масс.
Не стесняемся добавлять.
Погнали.
Дать права на экспорт почтового ящика в PST

Код:

New-ManagementRoleAssignment -Role "Mailbox Import Export" -User "<username>"

Команда выгружает содержимое почтового ящика пользователя username@mailbox.com в файл PST

Код:

New-MailboxExportRequest -Mailbox username@mailbox.com -FilePath "susemailarchiveuser.pst"

Выгрузить архив пользователя
New-MailboxExportRequest -Mailbox Kweku -FilePath "SERVER01PSTFileShareKweku_Archive.pst" -IsArchive

Экспорт некоторых папок почтового ящика в PST (в примере Входящие и отправленные)

Код:

New-MailboxExportRequest -IncludeFolders "#Inbox#/*","#SentItems#" -Mailbox USERNAME -FilePath server1backupusername.pst

Выгрузка с использованием контентного фильтра

Код:

New-MailboxExportRequest -Mailbox user1 -ContentFilter {(Received -lt '17/02/19') -and (Subject -like 'happy*')} -FilePath serversharetemp.pst

Поиск и удаление писем с темой 123 в почтовом ящике username@mailbox.com

Код:

Get-mailbox username@mailbox.com | search-mailbox –searchquery “Subject:’123’” –DeleteContent

Импорт ящика из pst

Код:

New-MailboxImportRequest -Mailbox username serversharetemp.pst

Последнее редактирование модератором: 17.02.2021

Surf_rider

  • #2

Очистка почтового ящика exchange

Код:

Search-Mailbox username@domain.com -Deletecontent

Узнать размер почтовых ящиков в базе Exchange
Get-Mailbox -Database DATABASE| Get-MailboxStatistics | ft displayname,totaldeleteditemsize,totalitemsize

Последнее редактирование: 07.09.2020

  • #3

Для вывода информации почтовых ящиках на сервере.

Код:

Get-Mailbox -Server имя сервера

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

Код:

Get-Mailbox -Server имя сервера | Get-MailboxStatistics | sort TotalItemSize -descending | ft DisplayName, TotalItemSize, ItemCount

При перемещении почтового ящика посмотреть информацию

Код:

Get-MoveRequest -Identity имя почтового ящика

Информация о размере почтовых баз на конкретном сервере.

Код:

Get-MailboxDatabase -Server имя сервера -Status | select ServerName,Name,DatabaseSize
или в другом виде
Get-MailboxDatabase -Status -Server имя сервера | fl name, DatabaseSize

Информация о сотрудниках, которые входят в определенную группу

Код:

Get-DistributionGroupMember имя группы

Информация о содержании общих папок

Код:

Get-PublicFolderStatistics -Server имя сервера

Отправка писем с сервера

Код:

[PS] C:Windowssystem32>Send-MailMessage -From имя ящика с которого отправляем -To имя ящика куда отправляем -Subject "Test #01" -Body "Justa test message" -SMTPServer имя сервера отправки

Информация по спискам рассылок

Информация по общим календарям

Код:

Get-Publicfolder -Identity имя -recurse

Переиндексация базы. Иногда требуется, когда возникает ошибка при поиске писем
[PS] C:Program FilesMicrosoftExchange ServerV14scripts>.ResetSearchIndex.ps1 -Force имя базы
MSExchangeSearch service stopped
Deleting catalog forимя базы
No index for database:имя базы
MSExchangeSearch service Started

Принудительный запрос сертификата

Код:

Get-ExchangeCertificate | FL

Последнее редактирование модератором: 25.02.2019

  • #4

Принудительное обновление OAB

Код:

Get-OfflineAddressbook | Update-OfflineAddressbook
Get-ClientAccessServer | Update-FileDistributionService

Включение Архива для всех ящиков из базы
Задание ограничения на архив и политики архивирования

Код:

Get-MailboxDatabase MDB | Get-Mailbox | Enable-Mailbox -Archive -ArchiveDatabase AMDB
Get-MailboxDatabase MDB | Get-Mailbox | Set-Mailbox -ArchiveWarningQuota 3584MB -ArchiveQuota 4GB
Get-MailboxDatabase MDB | Get-Mailbox | Set-mailbox -RetentionPolicy "Default Archive and Retention Policy"

Политика хранения применяется Managed Folder Assistant’ом. В Exchange 2010 RTM он запускался по расписанию (с часа ночи до 9 утра по умолчанию). В Exchange 2010 SP1 этот ассистент включен постоянно, так что политики архивирования к почтовому ящику должны примениться сразу же. Для ручного запуска используется командлет:

Код:

Get-MailboxDatabase | Get-Mailbox | Start-ManagedFolderAssistant

Найти какому почтовому ящику принадлежит определенный электронный адрес

Код:

Get-mailbox -resultsize unlimited | where-object{$_.Emailaddresses -like "*st@*"} | format-list name,emailaddresses,database,servername

Поиск и удаление писем по теме,вложению

Код:

Get-Mailbox -ResultSize unlimited | Search-Mailbox -SearchQuery вложение:"котики.jpg" -DeleteContent

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

Код:

Get-MailboxDatabase MDB | Get-Mailbox -ResultSize 15

Просмотр статистики по отдельной БД

Код:

Get-MailboxDatabase MDB |Get-MailboxStatistics | Sort totalitemsize -desc | ft displayname, totalitemsize, itemcount

Экспорт статистики в CSV файл

Код:

Get-MailboxDatabase MDB | Get-MailboxStatistics | Sort totalitemsize -desc | ft displayname, totalitemsize, itemcount | Export-CSV C:MDB.csv -encoding unicode

Ящики которые не использовались за последние 120 дней

Код:

Get-MailboxDatabase | Get-MailboxStatistics | where {$_.Lastlogontime -lt (get-date).AddDays(-120)} | Sort Lastlogontime -desc | ft DisplayName,ItemCount,Lastlogontime

Экспорт статистики в HTML

Код:

Get-MailboxDatabase | Get-MailboxStatistics | where {$_.Lastlogontime -lt (get-date).AddDays(-120)} | Sort Lastlogontime -desc | ConvertTo-Html DisplayName,ItemCount,Lastlogontime > c:tempMB.html

[PS] C:>Get-MailboxDatabase | Get-MailboxStatistics | where {$_.Lastlogontime -lt (get-date).AddDays(-60)} | where {$_.DisconnectReason -ne "Disabled"} | where {$_.Lastlogontime -ne $null} | Sort Lastlogontime | ft DisplayName,ItemCount,Lastlogontime

Предоставить доступ группе «Organization Management» к содержимому всех существующих почтовых ящиков

Код:

Get-Mailbox | Add-MailboxPermission -User "Organization Management" -AccessRights FullAccess -AutoMapping:$False

[PS] C:>Get-Mailbox | Get-MailboxPermission | ?{($_.AccessRights -like "*fullaccess*") -and ($_.User
-notlike "*nt authorityself*") -and ($_.IsInherited -like "false")}

——Подумал и добавил——

Эскпорт почтового ящика в PST

Код:

New-MailboxExportRequest -Mailbox "zalozny" -Filepath "PCtempzalozny.pst" -ContentFilter {(Received -gt "01/04/2014")}
New-MailboxExportRequest -Mailbox "zalozny" -Filepath "PCtempzalozny.pst"

Просмотреть статус экспорта

Код:

Get-MailboxExportRequest | ft

очистка выполненых запросов

Код:

Get-MailboxExportRequest -Status Completed | Remove-MailboxExportRequest

проверить пустое пространство в почтовых базах

Код:

Get-MailboxDatabase -Status | FL Name,AvailableNewMailboxSpace

Найдено в просторах интернетов

Surf_rider

  • #5

Интересный скрипт для отчетности Exchange
https://gallery.technet.microsoft.com/exchange/Generate-Exchange-2388e7c9

Предлагаемый скрипт позволяет автоматически создавать отчет для серверов и DAG (database availability groups) в Exchange 2003, 2007, 2010 и 2013, а именно:
• Общее количество серверов на версию и SP Exchange
• Общее количество почтовых ящиков на версию и SP Exchange
• Общее количество Exchange ролей в Вашей ИТ-инфраструктуре
• Разбивка по сайтам для следующих параметров:
o Почтовые ящики на сайте
o Exchange серверы, версия, пакет обновления и его версия, уровень службы, установленные роли, версия ОС и service
• Разбивка по каждой Database Availability Group, включая:
o Наименование каждой DAG, число членов и их список
o Информация о базе данных:
— Имя
— Количество почтовых ящиков на базу данных и их средний размер
— Количество архивных почтовых ящиков на базу данных и их средний размер – показывается только если БД включена в архивные почтовые ящики
— Размер БД и свободное место
— % свободного места в БД и логическом диске
— Время и дата последнего бекапа (новое) – показывается, если хотя бы одна база данных DAG имеет полный бекап
— Состояние циклического ведения журнала (Circular Logging) (новое) — показывается, если хотя бы для одной базы данных DAG включено циклическое ведение журнала
— Сервер, на котором находится активная копия
— Список серверов, на которых находятся активные копии и количество копий
• Разбивка по не-DAG базам данных, включая БД Exchange 2007 и 2003 с информацией о базе данных и имени группы хранения Storage Group (где это применимо).

Образец развернутого отчета

Пример запуска

Код:

.Get-ExchangeEnvironmentReport  -HTMLReport c:report.html

Serg

Serg

Случайный прохожий
  • #6

Узнать размер почтовых баз Exchange

Код:

Get-MailboxDatabase -Status | select-object Name,Server,DatabaseSize,Mounted

Удалить «Плохое письмо» из всех ящиков в БД Exchange

Код:

get-mailbox -OrganizationalUnit Needed_OU -ResultSize unlimited | Search-Mailbox -SearchQuery Subject:'Very bad message' -TargetMailbox mailbox@mailbox.com -TargetFolder Inbox –DeleteContent

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

Запретить юзерам возможность соединения по RPC over HTTPS

Код:

Set-CASMailbox -Identity mailbox@mailbox.com -MAPIBlockOutlookRpcHttp $true

Запретить работать с почтовым ящиком юзеру, настроенному не в режиме кэширования

Код:

Set-CASMailbox -Identity mailbox@mailbox.com -MAPIBlockOutlookNonCachedMode $true

Запретить использовать пользователям версии Outlook старее, чем 2003.

Код:

Get-CASMailbox -Resultsize Unlimited | Set-CASMailbox -MAPIBlockOutlookVersions '-5.9.9;7.0.0-10.9.9'

Получить сводную информацию по почтовым ящикам с заданного аккаунта и экспортировать ее в Excel

Код:

Get-Mailbox -OrganizationalUnit groza -Resultsize unlimited | Get-MailboxStatistics | Sort-Object TotalItemSize -Descending | Select-Object DisplayName,@{Name="TotalItemSize(KB)";Expression={$_.TotalItemSize.Value.ToKB()}},ItemCount,lastlogontime,lastlogofftime,lastloggedonuseraccount | Export-Csv c:xfergroza.csv | foreach {$_.length=($_.length)/1024/1024/1024; $_}

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

Код:

 Test-MAPIConnectivity -Database DB1

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

Код:

Test-MAPIConnectivity –Identity username@contoso.ru

— -Подумал и добавил — —

Test-ActiveSyncConnectivity — тестирует ActiveSync протокол;
Test-CalendarConnectivity – тестирование доступности календаря;
Test-EcpConnectivity – валидация виртуальной директории ECP на выбранном CAS сервере
Test-ImapConnectivity – проверка статуса сервиса IMAP и возможности клиентского подключения по данному протоколу
Test-OutlookWebServices – проверка корректности информации, выдаваемой пользователю сервисом AutoDiscover
Test-OwaConnectivity – валидация виртуальной директории OWA на указанном CAS сервере
Test-WebServicesConnectivity – проверка Exchange Web Services, которые используются, например, Outlook for Mac, Mac Mail и еще некоторыми клиентами.

  • #7

Поиск писем в журналах exchange с форматированным выводом FL, запись в файл txt

Код:

Get-MessageTrackingLog -Sender [email]sender@domain1.ru[/email] -Recepients [email]recep@domain2.ru[/email] | select timestamp,messageid,messagesubject | FL > c:result.txt

Surf_rider

  • #8

Список всех имеющихся отключенных ящиков во всех базах организации:

Код:

Get-MailboxDatabase | Get-MailboxStatistics | Where { $_.DisconnectReason -eq "Disabled" } | ft DisplayName,Database,DisconnectDate,MailboxGUID

Поиск в конкретной почтовой БД

Код:

Get-MailboxStatistics –database DBNAME | Where { $_.DisconnectReason -eq "Disabled" } | ft DisplayName,Database,DisconnectDate,MailboxGUID

Удаление почтового ящика по GUID

Код:

Remove-StoreMailbox -Database Msk-DB1  -Identity "6398897d-d12a-4975-8ef0-ebca5b1c635b" -MailboxState Disabled

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

Код:

Get-MailboxDatabase | Get-MailboxStatistics | where {$_.DisconnectReason -eq "Disabled"} | foreach {Remove-StoreMailbox -Database $_.database -Identity $_.mailboxguid -MailboxState SoftDeleted}

  • #9

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

Код:

 Get-PublicFolderItemStatistics -identity "30 Day" | Sort-Object CreationTime | Format-List

или

Код:

 Get-PublicFolderItemStatistics -identity "30 Day" | Sort-Object CreationTime | Format-List Subject,CreationTime,Start,End

  • #10

Скрипт создания события в общем календаре Outlook (надо проверить)

Код:

```powershell
<#
Скрипт создания события в общем календаре Outlook

03.11.2016 Сатин Павел
#>

#Следующая фигня перезапускает скрипт в однопоточном режиме. Только для дого, что-бы форме работал AutoComplete
if ([System.Threading.Thread]::CurrentThread.ApartmentState -eq [System.Threading.ApartmentState]::MTA)
{
    powershell.exe -Sta -File $MyInvocation.MyCommand.Path
    return
}



#Определяем путь от куда запущен скрипт
$Global:CurrPath = $MyInvocation.MyCommand.Definition | split-path -parent
#Загружаем переменные из конфигурационного файла
Get-Content "$Global:CurrPathSBS-ATMEvents.conf" | ForEach-Object { $ExecutionContext.InvokeCommand.InvokeScript($_) }

#Заполняем список УС
$Global:FileListUS = "$Global:CurrPath$Global:FileListUS"
$Global:ListUS = Get-Content $Global:FileListUS


function NewOutlookEvent {

[void] [System.Reflection.Assembly]::LoadWithPartialName("System.Windows.Forms")
[void] [System.Reflection.Assembly]::LoadWithPartialName("System.Drawing")

$objForm = New-Object System.Windows.Forms.Form
$objForm.Text = "Новое событие УС"
$objForm.Size = New-Object System.Drawing.Size(300,240)
$objForm.StartPosition = "CenterScreen"


$OKButton = New-Object System.Windows.Forms.Button
$OKButton.Location = New-Object System.Drawing.Size(75,160)
$OKButton.Size = New-Object System.Drawing.Size(75,23)
$OKButton.Text = "OK"
$OKButton.DialogResult = [System.Windows.Forms.DialogResult]::OK
$OKButton.Add_Click({$objForm.Close()})
$objForm.Controls.Add($OKButton)

$CancelButton = New-Object System.Windows.Forms.Button
$CancelButton.Location = New-Object System.Drawing.Size(150,160)
$CancelButton.Size = New-Object System.Drawing.Size(75,23)
$CancelButton.Text = "Cancel"
$CancelButton.DialogResult = [System.Windows.Forms.DialogResult]::Cancel
$CancelButton.Add_Click({$objForm.Close()})
$objForm.Controls.Add($CancelButton)

$objLabelStart = New-Object System.Windows.Forms.Label
$objLabelStart.Location = New-Object System.Drawing.Size(10,20)
$objLabelStart.Size = New-Object System.Drawing.Size(280,20)
$objLabelStart.Text = "Дата события:"
$objForm.Controls.Add($objLabelStart)


$datePicker = New-Object Windows.Forms.DateTimePicker
$datePicker.ShowUpDown = $false
#$datePicker.MinDate = $now
#$datePicker.MaxDate = $now.AddMonths(3); #arbitrary
#$datePicker.MaxSelectionCount = 1
$datePicker.Location = New-Object System.Drawing.Size(10,40)
$datePicker.Size = New-Object System.Drawing.Size(260,20)
#$datePicker.Width = 350
$datePicker.Format = "Custom"
$datePicker.CustomFormat = "dd.MM.yyyy HH:mm"
$datePicker.Enabled = $true
$objForm.Controls.Add($datePicker)


$objLabelUS = New-Object System.Windows.Forms.Label
$objLabelUS.Location = New-Object System.Drawing.Size(10,60)
$objLabelUS.Size = New-Object System.Drawing.Size(280,20)
$objLabelUS.Text = "Номер УС:"
$objForm.Controls.Add($objLabelUS)

$objComboBoxUS = New-Object System.Windows.Forms.ComboBox
$objComboBoxUS.Location = New-Object System.Drawing.Size(10,80)
$objComboBoxUS.Size = New-Object System.Drawing.Size(260,20)
#$objComboBoxUS.Height = 80

#Заполняем значения
$Global:ListUS | ForEach-Object {[void] $objComboBoxUS.Items.Add($_)}


$objComboBoxUS.Sorted = $true
$objComboBoxUS.AutoCompleteMode = [System.Windows.Forms.AutoCompleteMode]::SuggestAppend
$objComboBoxUS.AutoCompleteSource = [System.Windows.Forms.AutoCompleteSource]::ListItems
$objForm.Controls.Add($objComboBoxUS)

$objLabelDecr = New-Object System.Windows.Forms.Label
$objLabelDecr.Location = New-Object System.Drawing.Size(10,100)
$objLabelDecr.Size = New-Object System.Drawing.Size(280,20)
$objLabelDecr.Text = "Описание события:"
$objForm.Controls.Add($objLabelDecr)

$objEditBoxDescr = New-Object System.Windows.Forms.TextBox
$objEditBoxDescr.Location = New-Object System.Drawing.Size(10,120)
$objEditBoxDescr.Size = New-Object System.Drawing.Size(260,20)
$objForm.Controls.Add($objEditBoxDescr)


$objForm.Topmost = $True

$objForm.Add_Shown({$objForm.Activate()})
$resultForm = $objForm.ShowDialog()


if ($resultForm -eq [System.Windows.Forms.DialogResult]::OK) {


    $EventSubjectUS = $objComboBoxUS.Text
    $EventSubjectDescr = $objEditBoxDescr.Text

    Add-type -assembly "Microsoft.Office.Interop.Outlook" | out-null

    $outlook = new-object -comobject outlook.application
    $namespace = $outlook.GetNameSpace("MAPI")
    $folder = $namespace.GetFolderFromID($olFolders)

    $olAppointmentItem = 1

    $appt = $folder.Items.Add($olAppointmentItem)
    $appt.Start = $datePicker.Value
    #$appt.Duration = 60
    $appt.Subject = "$EventSubjectUS; $EventSubjectDescr"
    #$appt.Body = "Meet with Scripting Guys to discuss upcoming plans."
    $appt.Location = $aptLocation
    #$appt.ReminderMinutesBeforeStart = 15
    $appt.ReminderSet = $False

    $result = $appt.Save()

}

} #End NewOutlookEvent



NewOutlookEvent

```

  • #11

Скрипт выборки событий из общего календаря Outlook

Код:

```powershell
<#
Скрипт выборки событий из общего календаря Outlook

03.11.2016 Сатин Павел
#>

#Определяем путь от куда запущен скрипт
$Global:CurrPath = $MyInvocation.MyCommand.Definition | split-path -parent
#Загружаем переменные из конфигурационного файла
Get-Content "$Global:CurrPathSBS-ATMEvents.conf" | ForEach-Object { $ExecutionContext.InvokeCommand.InvokeScript($_) }

#$Global:ReportStart =  [datetime]"11/01/2016"
#$Global:ReportEnd = [datetime]"11/07/2016"


Function FormDateQuery {

[void] [System.Reflection.Assembly]::LoadWithPartialName("System.Windows.Forms")
[void] [System.Reflection.Assembly]::LoadWithPartialName("System.Drawing")

$objForm = New-Object System.Windows.Forms.Form
$objForm.Text = "Формирование отчета"
$objForm.Size = New-Object System.Drawing.Size(300,240)
$objForm.StartPosition = "CenterScreen"


$OKButton = New-Object System.Windows.Forms.Button
$OKButton.Location = New-Object System.Drawing.Size(75,160)
$OKButton.Size = New-Object System.Drawing.Size(75,23)
$OKButton.Text = "OK"
$OKButton.DialogResult = [System.Windows.Forms.DialogResult]::OK
$OKButton.Add_Click({$objForm.Close()})
$objForm.Controls.Add($OKButton)

$CancelButton = New-Object System.Windows.Forms.Button
$CancelButton.Location = New-Object System.Drawing.Size(150,160)
$CancelButton.Size = New-Object System.Drawing.Size(75,23)
$CancelButton.Text = "Cancel"
$CancelButton.DialogResult = [System.Windows.Forms.DialogResult]::Cancel
$CancelButton.Add_Click({$objForm.Close()})
$objForm.Controls.Add($CancelButton)

$objLabelStart = New-Object System.Windows.Forms.Label
$objLabelStart.Location = New-Object System.Drawing.Size(10,20)
$objLabelStart.Size = New-Object System.Drawing.Size(280,20)
$objLabelStart.Text = "Дата события:"
$objForm.Controls.Add($objLabelStart)


$datePicker = New-Object Windows.Forms.DateTimePicker
$datePicker.ShowUpDown = $false
#$datePicker.MinDate = $now
#$datePicker.MaxDate = $now.AddMonths(3); #arbitrary
#$datePicker.MaxSelectionCount = 1
$datePicker.Location = New-Object System.Drawing.Size(10,40)
$datePicker.Size = New-Object System.Drawing.Size(260,20)
#$datePicker.Width = 350
$datePicker.Format = "Custom"
$datePicker.CustomFormat = "dd.MM.yyyy HH:mm"
$datePicker.Enabled = $true
$objForm.Controls.Add($datePicker)

$objLabelEnd = New-Object System.Windows.Forms.Label
$objLabelEnd.Location = New-Object System.Drawing.Size(10,60)
$objLabelEnd.Size = New-Object System.Drawing.Size(280,20)
$objLabelEnd.Text = "Дата события:"
$objForm.Controls.Add($objLabelEnd)


$datePickerEnd = New-Object Windows.Forms.DateTimePicker
$datePickerEnd.ShowUpDown = $false
#$datePickerEnd.MinDate = $now
#$datePickerEnd.MaxDate = $now.AddMonths(3); #arbitrary
#$datePickerEnd.MaxSelectionCount = 1
$datePickerEnd.Location = New-Object System.Drawing.Size(10,80)
$datePickerEnd.Size = New-Object System.Drawing.Size(260,20)
#$datePickerEnd.Width = 350
$datePickerEnd.Format = "Custom"
$datePickerEnd.CustomFormat = "dd.MM.yyyy HH:mm"
$datePickerEnd.Enabled = $true
$objForm.Controls.Add($datePickerEnd)

$objForm.Topmost = $True


$objForm.Add_Shown({$objForm.Activate()})
$resultForm = $objForm.ShowDialog()

    if ($resultForm -eq [System.Windows.Forms.DialogResult]::OK) {
        $Global:ReportStart =  $datePicker.Value
        $Global:ReportEnd = $datePickerEnd.Value
    }

} #End FormDateQuery


Function QueryATMEvents {

Add-type -assembly "Microsoft.Office.Interop.Outlook" | out-null
#$olFolders = "Microsoft.Office.Interop.Outlook.OlDefaultFolders" -as [type]
$outlook = new-object -comobject outlook.application
$namespace = $outlook.GetNameSpace("MAPI")

$folder = $namespace.getFolderFromID($Global:olFolders)

$result = $folder.items | Select-Object -Property Start, End, Subject, Location |
    where-object { $_.start -gt $Global:ReportStart -AND $_.start -lt $Global:ReportEnd } | Sort-object Start

if ($result -ne $null) {

$result | Add-Member -MemberType NoteProperty -Name NumberUS -Value ""
$result | Add-Member -MemberType NoteProperty -Name Description -Value ""

foreach ($reselement in $result) {
    $DescStart = $reselement.Subject.IndexOf(";")
    $DescLen = ($reselement.Subject.Length - $DescStart)
    $NumUS = $reselement.Subject.Substring(0, $DescStart)
    $Descr = ($reselement.Subject.Substring($DescStart + 1, $DescLen - 1)).TrimStart(" ")
    #$reselement.Start = ($reselement.Start).Date
    $reselement.NumberUS = $NumUS
    $reselement.Description = $Descr
}

$result | Select-Object -Property Start, End, Location, NumberUS, Description

} else {

    Write-Host "За указанный период событий не найдено!"

}

} #End QueryATMEvents


########################### Main #######################################

if ($args[0] -ne $Null) {
    $Global:ReportStart =  [datetime]$args[0]

    if ($args[1] -ne $Null) {
        $Global:ReportEnd =  [datetime]$args[1]
    } else {
        $Global:ReportEnd =  Get-Date
    }

} else {
    FormDateQuery
}

$ATMEvents = QueryATMEvents
#Выводим без даты окончания события, так как пока в ней нет необходимости
$ATMEvents | Select-Object -Property Start, Location, NumberUS, Description

```

https://webnote.satin-pl.com/2016/12/15/posh_outlook_events/

  • #12

Посмотреть права на календарь:

Код:

Get-MailboxFolderPermission -identity "username@domen.local:Календарь"

Дать права на редактирование календаря другому пользователю.

Код:

Add-MailboxFolderPermission -identity "username@domen.local:Календарь" -user USER22@domen.local -AccessRights Editor

  • #13

Удалить успешно завершенные запросы на перемещение при экспорте PST

Код:

Get-MailboxExportRequest -Status Completed | Remove-MailboxExportRequest

или

Код:

Get-MailboxImportRequest | where {$_.status -eq "Completed"} | Remove-MailboxImportRequest

  • #14

Просмотр и настройка всех виртуальных директорий Exchange Server 2016

Код:

Get-MapiVirtualDirectory | Set-MapiVirtualDirectory -InternalUrl https://mail.domain.ru/mapi -ExternalUrl https://mail.domain.ru/mapi - IISAuthenticationMethods Negotiate

Код:

Get-OutlookAnywhere | Set-OutlookAnywhere -InternalHostname mail.domain.ru -ExternalHostname mail.domain.ru -ExternalClientsRequireSSSL $true -InternalClientsRequireSSL $true -InternalClientAuthenticationMethod negotiate -ExternalClientAuthenticationMethod negotiate

Код:

Get-ActiveSyncVirtualDirectory | Set-ActiveSyncVirtualDirectory -InternalUrl "https://mail.domain.ru/Microsoft-Server-ActiveSync" -ExternalUrl "https://mail.domain.ru/Microsoft-Server-ActiveSync"

Код:

Get-OabVirtualDirectory | Set-OabVirtualDirectory -InternalUrl "https://mail.domain.ru/OAB" -ExternalUrl "https://mail.domain.ru/OAB"

Код:

Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory -InternalUrl "https://mail.domain.ru/EWS/Exchange.asmx" -ExternalUrl "https://mail.domain.ru/EWS/Exchange.asmx"

Код:

Get-OwaVirtualDirectory | SetOwaVirtualDirectory -InternalUrl "https://mail.domain.ru/owa" -ExternalUrl "https://mail.domain.ru/owa"

Код:

Get-ECPVirtualDirectory | Set-ECPVirtualDirectory -InternalUrl "https://mail.domain.ru/ecp" -ExternalUrl "https://mail.domain.ru/ecp"

Настройка службы Autodiscover
Просмотр и изменение AutodiscoverServiceInternalUri

Код:

Get-ClientAccessService | fl name,*URI*
Get-ClientAccessService | Set-ClientAccessService -AutodiscoverServiceInternalUri "https://mail.domain.ru/Autodiscover/Autodiscover.xml"

Последнее редактирование: 07.03.2019

  • #15

Перемещение базы данных Exchange

Код:

Move-DatabasePath -Identity "DB-01" -EdbFilePath "F:DataDB-01DB-01.edb" -LogFolderPath "F:DataDB-01"

  • #16

Полнотекстовый индекс Exchange

Посмотреть

Код:

Get-MailboxDatabaseCopyStatus*

Починить полнотекстовый индекс Exchange
1. Останавливаем службы в services.msc

Код:

Microsoft Exchange Search Host Controller
Microsoft Exchange Search

2. Удаляем папку с полнотектовым индексом из каталога с БД (это папка вида 45234sdfiouvsberg34tfdv)
3. Запускаем службы и ждем (зависит от размера базы — час-два-сутки)

  • #17

Просмотр очереди писем Exchange в shell

Подробная информация о письмах в очереди от определенного отправителя:
Get-Message -Filter { FromAddress -like "user@domain.ru" } | Format-List

Cписок отправителей для определенной очереди:
Get-Queue mx12345 | Get-Message -ResultSize Unlimited | Select FromAddress

Список получателей:
Get-Queue mx12345 | Get-Message -ResultSize Unlimited -IncludeRecipientInfo | Select Recipients

Последнее редактирование модератором: 01.12.2021

  • #18

Массовое создание почтовых ящиков в Exchange (при условии наличия учетки в AD)

Код:

Get-User -OrganizationalUnit Users | Enable-Mailbox

  • #19

Просмотр и установка квот на базу данных Exchange

Код:

Get-MailboxDatabase "DB-TEST 1" | fl *quota*

Код:

Set-MailBoxDatabase "DB-TEST 1" -IssuewarningQuota 4GB -ProhibitSendQuota 5GB -ProhibitSendReceiveQuota 6GB

Установка корзины 2 уровня для базы. Срок восстановления — 30 дней

Код:

Set-MailboxDatabase "DB-TEST 1" -DeletedItemRetention 30.00:00:00

Последнее редактирование: 18.03.2019

  • #20

Работа с eseutil
Все работы с утилитой eseutil выполняются только с размонтированной БД

Проверка контрольных сумм базы данных Exchange (CRC)

Проверка целостности БД

Вывод отчета по БД (включая состояние бд clean shutdown , dirty shutdown и тд)

Перевод из dirty shutdown в clean shutdown

Код:

eseutil /R "тут префикс транзакционных логов из каталога где бд" , например E01

после этого база переводится в состояние clean shutdown

Проверка целостности транзакционных логов Exchange

Почтовый ящик в Exchange может быть поврежден или поврежден. Это может произойти по разным причинам, таким как перемещение почтового ящика в другую базу данных. Это также может произойти из-за повреждения из-за сбоя системы, неправильного завершения работы сервера или вирусной атаки. У пользователя с поврежденным почтовым ящиком могут возникнуть проблемы. Некоторые из проблем связаны с неправильным количеством элементов в папках. Также возможно, что результаты не отображают правильное содержимое в поиске. Давайте узнаем и узнаем, как восстановить поврежденный почтовый ящик.

Содержание

  1. Как восстановить поврежденный почтовый ящик
  2. Как проверить почтовый ящик в Exchange на наличие ошибок без восстановления. 
  3. Как починить один почтовый ящик Exchange ?
  4. Как починить все почтовые ящики в базе данных Exchange ?
  5. При восстановлении почтового ящика Exchange — Queued 0%

Как восстановить поврежденный почтовый ящик

Запустите командлет New-MailboxRepairRequest , чтобы обнаружить и восстановить поврежденный почтовый ящик. Командлет New-MailboxRepairRequest доступен только для следующих серверов Exchange:

  • Exchange Server 2010
  • Exchange Server 2013
  • Exchange Server 2016
  • Exchange Server 2019

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

Командлет может восстанавливать четыре типа повреждений почтового ящика:

  • Ошибки в папках поиска ( SearchFolder ).
  • Ошибки в количестве папок, которые не отражают правильные значения ( AggregateCounts ).
  • Ошибки в папках, которые не возвращают правильное содержимое ( FolderView ).
  • Ошибки в структуре папок в почтовом ящике ( ProvisionedFolder ).

Чтобы избежать каких-либо проблем с производительностью, существуют ограничения на количество одновременных запросов на восстановление, отправляемых на сервер. Только один запрос может быть активен для восстановления на уровне базы данных, или до 100 запросов могут быть активны для восстановления.

Как проверить почтовый ящик в Exchange на наличие ошибок без восстановления. 

Обнаружение повреждений только для определенного почтового ящика без восстановления

Запустите Exchange Management Shell от имени администратора и выполните следующую команду.

[PS] C:>New-MailboxRepairRequest –Mailbox "admin@alukashin.ru" –CorruptionType SearchFolder, AggregateCounts, ProvisionedFolder, FolderView -DetectOnly

Identity                                                                  Task                                                           Detect Only Job State Progress
--------                                                                  ----                                                           ----------- --------- --------
68sdd69-cafc-4144-87b3-497e1fe1720df568b725-65a3-4e3a-b865-aa24cc009426 {SearchFolder, AggregateCounts, ProvisionedFolder, FolderView} True        Queued    0

Получим статус о восстановлении.

[PS] C:>Get-MailboxRepairRequest -Mailbox "admin@alukashin.ru"

Identity                                                                                                       Task                Detect Only Job State Progress
--------                                                                                                       ----                ----------- --------- --------
68db0169-cafc-4144-87b3-797e1fe1720df568b725-65a3-4e3a-b865-aa24cc009426d3a55901-762e-439f-89b0-81cd74732fdf {SearchFolder}      True        Queued    0
68db0169-cafc-4144-87b3-797e1fe1720df568b725-65a3-4e3a-b865-aa24cc009426e9eefd18-301a-45f5-a127-89c54cd2d3cf {AggregateCounts}   True        Queued    0
68db0169-cafc-4144-87b3-797e1fe1720df568b725-65a3-4e3a-b865-aa24cc0094266f10428d-2a9f-4726-8acb-f051e6ab7bfa {ProvisionedFolder} True        Queued    0
68db0169-cafc-4144-87b3-797e1fe1720df568b725-65a3-4e3a-b865-aa24cc0094269f22a529-030b-405d-b121-984be4d5569f {FolderView}        True        Queued    0

Он покажет восстановление почтового ящика  Detect Only как  True и Job State как Queued .

Вам нужно немного подождать, прежде чем работа завершится. Выполните предыдущую команду Get-MailboxRepairRequest . Вы можете продолжать выполнять команду, пока не увидите состояние задания как успешное .

[PS] C:>Get-MailboxRepairRequest -Mailbox "admin@alukashin.ru" можно также использовать 

Get-MailboxRepairRequest -Identity68db0169-cafc-4144-87b3-797e1fe1720df568b725-65a3-4e3a-b865-aa24cc009426d3a55901-762e-439f-89b0-81cd74732fdf
Identity                                                                                                       Task                Detect Only Job State Progress
--------                                                                                                       ----                ----------- --------- --------
68db0169-cafc-4144-87b3-797e1fe1720df568b725-65a3-4e3a-b865-aa24cc009426d3a55901-762e-439f-89b0-81cd74732fdf {SearchFolder}      True        Succeeded 100
68db0169-cafc-4144-87b3-797e1fe1720df568b725-65a3-4e3a-b865-aa24cc009426e9eefd18-301a-45f5-a127-89c54cd2d3cf {AggregateCounts}   True        Succeeded 100
68db0169-cafc-4144-87b3-797e1fe1720df568b725-65a3-4e3a-b865-aa24cc0094266f10428d-2a9f-4726-8acb-f051e6ab7bfa {ProvisionedFolder} True        Succeeded 100
68db0169-cafc-4144-87b3-797e1fe1720df568b725-65a3-4e3a-b865-aa24cc0094269f22a529-030b-405d-b121-984be4d5569f {FolderView}        True        Succeeded 100
[PS] C:Windowssystem32>get-MailboxRepairRequest -Mailbox "admin@alukashin.ru" |fl


RunspaceId          : 898704ed-2b19-4ebb-86b5-2ecffec62e8d
Identity            : 16382aaf-b22b-4ebf-8192-8e2cfd7e92bf93499ad1-90d4-4d1d-bb04-37387516dc32
Mailbox             : 51f91dcf-f5ce-4ffd-aa62-812d6b2b8939
Source              : OnDemand
Priority            : Normal
DetectOnly          : True
JobState            : Succeeded
Progress            : 100
Tasks               : {SearchFolder, AggregateCounts, ProvisionedFolder, FolderView}
CreationTime        : 12/6/2022 2:10:40 PM
FinishTime          : 12/6/2022 2:14:52 PM
LastExecutionTime   : 12/6/2022 2:14:52 PM
CorruptionsDetected : 0
ErrorCode           :
CorruptionsFixed    : 0
TimeInServer        : 00:00:06.7680000
Corruptions         : {}
IsValid             : True
ObjectState         : New

CorruptionsDetected : 0
CorruptionsFixed : 0

Как починить один почтовый ящик Exchange ?

[PS] C:>New-MailboxRepairRequest -Mailbox "admin@alukashin.ru" -CorruptionType SearchFolder, AggregateCounts, ProvisionedFolder, FolderView

Identity                                                                  Task                                                           Detect Only Job State Progress
--------                                                                  ----                                                           ----------- --------- --------
68db0169-cafc-4144-87b3-797e1fe1720df1347601-ac44-455f-81f3-0b50d56aa92c {SearchFolder, AggregateCounts, ProvisionedFolder, FolderView} False       Queued    0
Также можно использовать только один из четырех типов повреждения почтового ящика для определенного почтового ящика.
[PS] C:>New-MailboxRepairRequest -Mailbox "admin@alukashin.ru" -CorruptionType SearchFolder

Identity                                                                                                       Task           Detect Only Job State Progress
--------                                                                                                       ----           ----------- --------- --------
68db0169-cafc-4144-87b3-797e1fe1720d404e2799-b7e8-4e6d-b3db-54333d2ee1188cbc3d82-b9bb-4821-bc91-0d50d392f35a {SearchFolder} False       Queued    0

Вы можете использовать имя пользователя, если вы не знаете адрес электронной почты. Замените электронную почту admin@alukashin.ru на имя пользователя Alexey Lukashin.

Как починить все почтовые ящики в базе данных Exchange ?

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

[PS] C:>New-MailboxRepairRequest –Database "DB1" –CorruptionType SearchFolder, AggregateCounts, ProvisionedFolder, FolderView -DetectOnly

Получить статус восстановления почтового ящика в базе данных.

[PS] C:>Get-MailboxRepairRequest -Database "DB1"

Обнаружение и устранение повреждений почтовых ящиков в базе данных.

[PS] C:>New-MailboxRepairRequest –Database "DB1" –CorruptionType SearchFolder, AggregateCounts, ProvisionedFolder, FolderView

Также возможно использовать только один из четырех типов повреждения почтовых ящиков для всех почтовых ящиков в базе данных.

[PS] C:>New-MailboxRepairRequest –Database "DB1" –CorruptionType ProvisionedFolder

При восстановлении почтового ящика Exchange — Queued 0%

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

[PS] C:Windowssystem32>Get-MailboxRepairRequest -Database db25eu

Identity                                                                                                       Task                Detect Only Job State Progr
                                                                                                                                                         ess
--------                                                                                                       ----                ----------- --------- -----
8e722900-d1a2-498f-8aca-e4a15a73aeda5f162bf5-8c41-4735-865f-d76a6163f20b24ec5220-814e-4cd1-876a-2d01288debca {FolderView}        True        Queued    0
8e722900-d1a2-498f-8aca-e4a15a73aeda5f162bf5-8c41-4735-865f-d76a6163f20b76491636-f52c-4217-88d7-e6bba0a86399 {ProvisionedFolder} True        Queued    0
8e722900-d1a2-498f-8aca-e4a15a73aeda5f162bf5-8c41-4735-865f-d76a6163f20bba024b9e-826a-40bf-af30-ef22cf05ac5e {AggregateCounts}   True        Queued    0
8e722900-d1a2-498f-8aca-e4a15a73aeda5f162bf5-8c41-4735-865f-d76a6163f20b59d2e885-f5b4-4cfa-bbbc-64ffa53e1fee {SearchFolder}      True        Queued    0
8e722900-d1a2-498f-8aca-e4a15a73aeda5f162bf5-8c41-4735-865f-d76a6163f20b1ba9c1ba-1481-4790-babf-aedd578a1a6b {FolderView}        True        Queued    0
8e722900-d1a2-498f-8aca-e4a15a73aeda5f162bf5-8c41-4735-865f-d76a6163f20b2ca2cfde-1b7a-481c-bb59-150bcc20fcc1 {ProvisionedFolder} True        Queued    0
8e722900-d1a2-498f-8aca-e4a15a73aeda5f162bf5-8c41-4735-865f-d76a6163f20bc1ecade3-880a-4c95-9c9d-a54338605e7d {AggregateCounts}   True        Queued    0
8e722900-d1a2-498f-8aca-e4a15a73aeda5f162bf5-8c41-4735-865f-d76a6163f20b74ed0e58-b8c8-44f5-b677-d1a849b175c9 {SearchFolder}      True        Queued    0
8e722900-d1a2-498f-8aca-e4a15a73aeda5f162bf5-8c41-4735-865f-d76a6163f20b136a811d-6d58-46e7-9fd3-f68d0cd6b5f1 {FolderView}        True        Queued    0
8e722900-d1a2-498f-8aca-e4a15a73aeda5f162bf5-8c41-4735-865f-d76a6163f20b7e00a802-d3cd-4676-821c-8a838369e6f9 {ProvisionedFolder} True        Queued    0
8e722900-d1a2-498f-8aca-e4a15a73aeda5f162bf5-8c41-4735-865f-d76a6163f20b3006cbb8-9aca-4a04-a25b-5ac075256688 {AggregateCounts}   True        Queued    0
8e722900-d1a2-498f-8aca-e4a15a73aeda5f162bf5-8c41-4735-865f-d76a6163f20b556b246a-26a5-4282-ac52-3a9accda5f4e {SearchFolder}      True        Queued    0
8e722900-d1a2-498f-8aca-e4a15a73aeda5f162bf5-8c41-4735-865f-d76a6163f20bf2c4489b-1f55-49a8-8120-ef9b19de9efb {FolderView}        True        Queued    0
8e722900-d1a2-498f-8aca-e4a15a73aeda5f162bf5-8c41-4735-865f-d76a6163f20b72432b19-f737-4e44-a89c-2de284c13230 {ProvisionedFolder} True        Queued    0
8e722900-d1a2-498f-8aca-e4a15a73aeda5f162bf5-8c41-4735-865f-d76a6163f20b161b19d1-f326-4fa2-b318-cd0669cb854c {AggregateCounts}   True        Queued    0
8e722900-d1a2-498f-8aca-e4a15a73aeda5f162bf5-8c41-4735-865f-d76a6163f20b44129eab-e93f-47ba-828a-7ed0af4a1ac6 {SearchFolder}      True        Queued    0
  1. Проверить все службы ( get-service *exch*
  2. Проверить почтовый ящик в карантине

qura

Проверить почтовый ящик карантина Exchange через реестр по пути который на скриншоте
  1. Есть ли порушенный DAG , в котором как пример есть пассивная копия которая находится на сервере который уже не обслуживается. Удалить копию можно командой.
Remove-MailboxDatabaseCopy -Identity DB1MBX1 -Confirm:$False

00В прошлой статье мы обсудили вопрос мягкого восстановления базы данных при помощи команды Esutil /R. В подавляющем большинстве случаев эта команда отрабатывает успешно и базу удается смонтировать на сервер. Но бывают и такие ситуации, когда база сильно повреждена и мягко восстановить её не получается, в таких случаях необходимо попытаться вытащить из базы как можно больше информации.

Исправление

Для исправления базы данных придется использовать команду ESEUTIL /P. Стоит несколько раз подумать, прежде чем пользоваться функцией Repair, т.к. данная операция в ЛЮБОМ случае приведет к потере данных, и сколько именно данных будет потеряно спрогнозировать не реально, можно только с уверенностью сказать, что информация, находящаяся в лог-файлах будет на 100% потеряна.

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

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

eseutil /P MDB2.edb

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

clip_image003

Рис.1: Предупреждение перед операцией Repair.

Если все же вы твердо решили продолжать, то нужно нажать ОК и утилита ESEUTIL сделает все сама.

clip_image005

Рис.2: Исправление базы при помощи команды ESEUTIL /P.

После операции Repair может быть заметно снижена производительность базы данных, в связи с этим рекомендуется делать автономную дефрагментацию базы при помощи команды ESEUTIL /D, в результате выполнения команды будет создана абсолютно новая база данных, но тут нужно помнить, что для дефрагментации базы у вас должно быть свободного места больше на 110%, чем занимает исходная база.

Проверка логической целостности

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

isinteg -s имя_сервера -fix -test alltests

тем самым инициировав процесс проверки базы данных.

clip_image006

Рис.3: Проверка логической целостности базы при помощи ISINTEG.

Описание программы ISINTEG.

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

Exchange 2010

Плюсом к этому, с приходом Exchange 2010 ISINTEG перестала понимать все функции новой базы данных. Но это и нормально, ведь данное средство не изменялось с 2000-го года!

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

clip_image007

Рис.4: Фоновое обслуживание базы данных.

Exchange 2010 SP1

С входом Exchange 2010 SP1, появилась замена средства ISINTEG в виде новых командлетов:

· New-MailboxRepairRequest – тестирование и исправление почтовых ящиков;

· New-PublicFolderDatabaseRepairRequest – тестирование и исправление общих папок.

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

Синтаксис использования командлетов следующий:

new-MailboxRepairRequest [-Mailbox <MailboxID> | -Database <DatabaseID>] -CorruptionType <CorruptionType> [-DetectOnly] [-DomainController <FQDN>]

Здесь

· Mailbox или Database – это соответственно почтовый ящик или база данных;

· CorruptionType – вид проверки, которую вы желаете запустить:

o SearchFolder;

o AggregateCounts;

o ProvisionedFolder;

o FolderView.

· DetectOnly – используется, если вы хотите лишь обнаружить ошибки, но не исправлять их;

· DomainController – определяет контроллер домена для обновления данных.

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

New-MailboxRepairRequest -Mailbox <MailboxID> -CorruptionType SearchFolder,AggregateCounts,ProvisionedFolder,FolderView

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

New-MailboxRepairRequest –Database MDB2 –CorruptionType AggregateCounts

clip_image009

Рис.5: Проверка всей базы.

В результате команда будет выполняться в фоновом режиме, а вам будет доступен её RequestID. Также в журнале событий Windows вы найдете событие под номером EventID = 10059, которое будет означать запуск сканирования

clip_image011

Рис.6: Запуск сканирования базы данных в журнале событий Windows.

И событие с EventID = 10048, которое будет означать успешное завершение операции.

clip_image013

Рис.7: Завершение операции сканирования базы данных в журнале событий Windows.

Заключение

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

Профилактика для сохранения работоспособности почтовой системы

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

  1. Проверка событий резервного копирования.
  2. Проверка системных журналов событий.
  3. Проверка дисковой системы.
  4. Проверка обновлений антивирусных баз.
  5. Проверка очередей.
  6. Проверка квитанций о недоставке (NDR).
  7. Проверка оборудования.

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

1. Проверка событий резервного копирования

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

Чтобы убедиться в пригодности резервной копии, проверять надо процедуры резервирования для каждой установленной системы Exchange. Обычно резервное копирование на файловом уровне выполняется, когда сохраняемые файлы не используются. В случае с системой Exchange файлы баз данных свободны только тогда, когда система остановлена. К счастью, Exchange предоставляет API, который позволяет программам резервного копирования работать в тандеме с модулем Extensible Storage Engine (ESE) и выполнять копирование, когда базы данных используются.

Во время резервного копирования ESE читает базы данных и передает информацию программе резервирования, которая, в свою очередь, сохраняет эту информацию на резервном носителе данных. Поскольку два компонента (т. е. ESE и программа резервирования) работают с данными во время резервирования, важно убедиться, что каждый компонент сохраняет данные без ошибок. Табл. 1 можно использовать для интерпретации системного журнала Application. Она включает события, связанные с работой ESE и NTBackup — штатной программы резервного копирования Windows 2000. ID событий от программы резервирования зависят от используемого программного обеспечения, а ID от ESE будут оставаться неизменными.

Интерпретировать события в системном журнале очень просто. Например, посмотрим на окно с журналом Application, показанное на экране 1. События с ID 8000 и 8001 показывают время начала и завершения резервного копирования со стороны NTBackup. События с ID 210 и 213 показывают время начала и завершения полного резервного копирования со стороны ESE. Другие виды резервирования, такие как инкрементальное и дифференциальное, будут отличаться соответствующими ID.


Экран 1. Журнал приложений Exchange 2000

События NTBackup с ID 8008 и 8009 показывают начало и завершение процесса верификации. Во время процесса верификации NTBackup читает данные и соответствующие контрольные суммы с носителя резервной копии для подтверждения пригодности сохраненных данных. Если возникает аппаратная ошибка или сбой носителя, то NTBackup сообщает об ошибке. Поскольку процесс верификации завершается после сообщения ESE об успешном завершении резервного копирования, для уверенности в нормальном сохранении данных Exchange необходимо убедиться в отсутствии сообщений об ошибках от программного обеспечения, выполняющего резервное копирование. Поэтому только после сообщений об успешном завершении резервного копирования от всех источников можно считать, что получена работоспособная копия данных.

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

Проверяя сообщения о событиях резервного копирования, можно судить о состоянии баз данных. При выполнении полного резервного копирования ESE читает базы данных порциями, которые называются страницами. Каждая страница содержит контрольную сумму, взглянув на которую администратор может убедиться, что данные в странице не повреждены. API резервного копирования высчитывает новую контрольную сумму и сравнивает с хранящейся версией для выявления нарушений. Если ESE находит сбой, в журнал заносится сообщение об ошибке и резервное копирование прерывается. О таких сообщениях об ошибках рассказывается в статье Microsoft «XADM: Understanding and Analyzing -1018, -1019, and -1022 Exchange Database Errors» (http://support.microsoft.com/default.aspx?scid=kb;en-us;q314917). Важно как можно раньше обнаружить наличие данного типа ошибок. Если не заметить эту проблему и продолжить эксплуатировать Exchange, возникнет реальный риск не восстановить в случае сбоя базы и все транзакции, поскольку в резервной копии не будет полноценного набора необходимых данных.

2. Проверка системных журналов событий

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

По умолчанию Exchange записывает большое количество данных в системные журналы. Определив базовое состояние, можно сэкономить время, поскольку уже будет известно, на какие именно сообщения следует обратить внимание. Одни информационные сообщения, такие как были описаны выше (о выполнении резервного копирования), критичны для регулярного контроля, другие — нет. Например, событие с ID 1221 сообщает об освобождении свободного пространства в хранилище. Когда пользователи удаляют свои сообщения из почтовых ящиков, Exchange не уменьшает размер хранилища почтовых ящиков, а вместо этого устанавливает флаг, означающий, что данные удалены. Такой тип информации поможет сэкономить дисковое пространство. В табл. 2 приведен список событий, на которые обычно можно не обращать внимания при ежедневном осмотре.

При определении базового состояния следует сосредоточиться на сообщениях об ошибках и предупреждениях. При изучении таких событий необходимо понять, что есть причина, а что следствие. Например, в журнале обнаружено событие с ID 2090, показанное на экране 2. Если разбираться с этим сообщением, то надо отыскать в свойствах сервера Exchange закладку Directory Access (она появилась в Exchange 2000 Service Pack 2) для определения ситуации с контроллером домена (DC) или сервером глобального каталога (GC), к которому необходим доступ, но в данный момент он недоступен. Из всех перечисленных DC и GC оставить надо только те, которые необходимо, так как сбой может быть следствием того, что Exchange и текущий сервер GC находятся на разных территориях и между ними — медленный канал связи.


Экран 2. Событие, вызванное недосягаемостью контроллера домена

Если в сети много серверов Exchange, просмотр системных журналов становится нелегкой задачей. Для ее решения можно задействовать автоматизированные средства мониторинга, такие как Microsoft Operations Manager (MOM), Aelita Software EventAdmin, NetIQ AppManager Suite (AppManager) или Hewlett-Packard HP OpenView. Эти продукты предоставляют механизмы, позволяющие фильтровать события, которые нет необходимости отслеживать. Кроме того, эти продукты предоставляют дополнительные возможности по уведомлениям в случае возникновения важных событий.

3. Проверка дисковой системы

Серверы Exchange могут останавливаться из-за недостаточного количества свободного места на диске, что является серьезной проблемой для многих администраторов. Обычно на серверах Exchange имеются отдельные диски для операционной системы, для журналов транзакций и для хранилища. На некоторых серверах также могут быть отдельные диски для других компонентов, таких как журналы отслеживания сообщений, очереди коннекторов SMTP, карантины для перехваченных антивирусным программным обеспечением файлов. Важно проверять свободное дисковое пространство на каждом диске каждый день, чтобы быть уверенным в том, что система не остановится из-за нехватки свободного места. Достаточное количество свободного пространства на дисках зависит от таких факторов, как объем передаваемой информации через почтовую систему в день и требования стандартных процедур Exchange по работе с журналами, файлами карантина и другими файлами. Для выполнения соответствующих проверок свободного дискового пространства необходимо следующее.

  • Убедиться, что Exchange чистит журналы транзакций. Перед выполнением полного резервного копирования всех баз данных в рамках группы хранения (SG) можно увидеть журналы транзакций со времени последнего выполнения такого резервного копирования. Exchange чистит журналы транзакций только при успешном завершении резервирования всех баз данных в SG. Если вы увидите старые журналы, это означает, что Exchange не очищал их, и это косвенно говорит о том, что базы данных не были успешно скопированы.
  • Проверить размер антивирусных карантинов и отчетов. Некоторые поставщики антивирусных программ заявляют, что производительность их продуктов может падать при большом увеличении файлов в зоне карантина. Это, вероятно, происходит потому, что программное обеспечение записывает файлы на диск последовательно и со временем их может скопиться очень много. Но эта проблема не является реально опасной в промышленной среде. В большинстве случаев отчеты и файлы карантина хранятся от 15 до 30 дней, в зависимости от организации и принятых в ней порядков. Такой период времени позволяет восстановить файл в случае ошибочного попадания в карантин.
  • Проверить размер каталога журналов SMTP и очистить в случае необходимости. Несмотря на то что Exchange позволяет управлять файлами журналов, они все равно последовательно заполняются и старые журналы автоматически не удаляются. Нельзя позволять журналам накапливаться бесконтрольно, это может привести к сбою. Если каталог с журналами находится на системном диске по умолчанию, то Windows может дать сбой при заполнении всего дискового пространства. Если каталог с журналами находится на диске с каталогами виртуального сервера SMTP, то этот сервер SMTP может остановить обработку писем, пока не освободится дисковое пространство. Журналы имеет смысл хранить от 21 до 30 дней. В случае возникновения проблем этого срока вполне достаточно, чтобы разобраться в причинах.
  • Удалить устаревшие архивные сообщения. Если используются возможности архивирования протокола SMTP, следует убедиться в том, что архивные сообщения удалены или перемещены в другой каталог, прежде чем заканчивается срок хранения сообщений для данного каталога, установленный исходя из здравого смысла. Компании архивируют сообщения по разным причинам — от выявления неполадок до контроля содержимого переписки. Но если не слишком активно заниматься управлением архивом сообщений и удалением лишнего, все доступное дисковое пространство будет быстро заполняться.

4. Проверка обновлений антивирусных баз

Когда в систему попадет очередной вирус, неизвестно. Лучшей защитой от вирусов является регулярное обновление баз установленного антивирусного программного обеспечения. Проверять наличие обновлений антивирусных баз необходимо не реже чем один раз в день. Обычно антивирусное программное обеспечение, обработав и установив новые базы, делает соответствующую запись в системный журнал Windows. Если антивирусная программа не вносит записи в журнал событий, то, возможно, она записывает информацию в собственный журнал. Например, Sybari Software Antigen записывает информацию об обновлениях в файл programlog.txt, а Trend Micro ScanMail for Microsoft Exchange записывает свои события в update.log. Проверяя журнал Windows или собственный журнал антивирусной программы, необходимо убедиться, что обновления баз были успешно получены и корректно установлены.

Можно считать это неинтеллектуальной задачей, но в некоторых случаях могут возникать серьезные проблемы. Например, одна компания отключила соединение с Internet, когда появился вирус Nimda. Поскольку антивирусное программное обеспечение не могло получить доступ к сайту разработчика для загрузки обновлений, администратор Exchange использовал коммутируемое соединение для загрузки обновлений и записи их на компакт-диск. Когда администратор скопировал обновления с компакт-диска на сервер, он оставил у файлов атрибут read-only. Позднее, когда компания восстановила соединение с Internet, процесс автоматического обновления завершился со сбоем, поскольку новые файлы антивирусных баз не могли перезаписать старые файлы.

5. Проверка очередей

Сервер Exchange, обрабатывая очень большой объем почтовых сообщений, может на некоторое время задерживать их в своих очередях. Наличие сообщений в очередях в течение длительного срока обычно указывает на ненормальную работу системы, о чем может сообщаться в системном журнале. Пиковый рост очередей может возникать при отправке сообщений по большим спискам рассылки (DL), при отправке очень больших сообщений нескольким получателям или когда сервер получателя подключен по медленному сетевому каналу. Такие ситуации не являются аварийными. Аварийной можно считать ситуацию, когда в очередях накапливаются тысячи сообщений для одних серверов получателей или когда появляется множество очередей для разных серверов и доменов. Наличие тысяч сообщений в очереди для одного получателя говорит о зацикливании при отправке почты или об атаке типа «отказ в обслуживании» (Denial of Service, DoS). Наличие множества очередей с сообщениями для разных серверов и доменов говорит о том, что на сервере произошел сбой, системная служба остановлена или сбои в сети не позволяют серверу установить соединение.

Для того чтобы оценить критичность ситуации, необходимо определить базовое состояние, по которому решать — нормальное положение или нет. Для табличного отображения очередей можно задействовать утилиту MailQ из Microsoft Exchange Server Resource Kit. Если по очередям будет видно наличие проблемы, исследовать ее причины можно с помощью Exchange System Manager (ESM).

6. Проверка квитанций о недоставке (NDR)

NDR приходят всегда. Основные причины появления NDR — неверное написание имени получателя или отказ сервера получателя принять сообщение. Серверы посылают NDR отправителю сообщения, но систему можно настроить так, чтобы копии отчетов шли в назначенный администратором почтовый ящик. Эта возможность настраивается в ESM в диалоговом окне свойств для каждого виртуального сервера SMTP. На закладке Messages следует ввести соответствующий адрес в формате SMTP в поле Send copy of non-delivery reports to. После внесения такого изменения в настройках надо остановить и снова запустить виртуальный сервер.

Пробовать определять и корректировать информацию для каждого NDR — это задача не на каждый день. Вместо этого достаточно будет сравнивать количество NDR с выбранным базовым состоянием. Для определения такого базового состояния надо выбрать среднее значение отправленных или принятых NDR в течение недели. Их количество может варьироваться. Например, в понедельник может приходить 25 NDR каждые 10 минут, а в пятницу — 25 NDR в час.

Резкий скачок в количестве NDR обычно говорит о проблеме, такой как атака DoS или зацикливание в отправке почты. Зацикливание в отправке почты может возникнуть, когда у пользователя настроено правило для пересылки на личный почтовый ящик у провайдера Internet. Пользователи могут настраивать такую конфигурацию, несмотря на то что корпоративная почтовая система может не иметь выхода в Internet. Теоретически такие настройки не являются серьезной ошибкой. Однако можно ошибиться в имени личного почтового ящика у провайдера, этот почтовый ящик может переполниться или возникнет другой сбой, и сервер провайдера услуг Internet будет отсылать NDR, а пользовательское правило будет успешно их пересылать обратно на тот же адрес, который в данный момент недоступен. В результате возникает цикл NDR.

7. Проверка оборудования

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

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

Базовое состояние

Какой тип событий сервер Exchange обычно записывает в системный журнал? Как много сообщений обычно находится в очереди? Сколько NDR отправляется и принимается каждый день? Важно знать ответы на такие вопросы. Если не принимать во внимание типичное состояние системы, сложно вовремя заметить критическую для сервера ситуацию. Помочь в данном случае могут ежедневные проверки и определение на их основе базовых состояний, а также профилактический контроль состояния системы Exchange.

Джозеф Ньбауэр — Старший технический консультант HP, специалист по Windows и Microsoft Exchange Server. joseph.neubauer@hp.com

Понравилась статья? Поделить с друзьями:
  • Exchange ошибка обновления счетчика производительности
  • Exchange ошибка 500 winrm
  • Exchange ошибка 401
  • Exchange ошибка 1003
  • Exchange ошибка 0x80070005 0x0004dc 0x000524