Стаття присвячена досить поширеною проблеми, з якою рано чи пізно стикаються всі адміністратори 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 -CorruptionType [-Archive] [-Confirm []] [-DetectOnly] [-DomainController] [-WhatIf []]Командлет дозволяє знайти і виправити такі типи пошкоджень в ящиках 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, не рекомендується одночасно запускати New-MailboxRepairRequest відразу для великої кількості баз (не дивлячись на те що, для однієї бази підтримується тільки один процес MailboxRepairRequest, в рамках одного сервера одночасно може працювати до 100 запитів).
В якості практичного прикладу використання командлет розглянемо невеликий кейс.
Користувач Exchange зіткнувся з неможливістю перегляду листів в одній з папок Outlook. Зазначена папка була відновлена з резервної копії ящика. Однак саму папку ні з Outlook, ні з Outlook Web App, ні навіть hard і soft видаленням за допомогою MFCMAPI, видалити не вийшло. Помилка клієнта Outlook, мало про що говорить:
Can not 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 can not remove this folder until the synchronization with the server is complete
Для перевірки і відновлення цілісності ящика була запущена команда:
New-MailboxRepairRequest -Mailbox [email protected] -CorruptionType ProvisionedFolder, SearchFolder, AggregateCounts, Folderview
Після успішного завершення операції відновлення (подія 10048 в журналі), пошкоджена папка в Outlook Web App пропала негайно, в Outlook ж, для коректного відображення "оновленого" ящика довелося видалити локальний кеш (ost файл).
