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

Ці помилки в основному виникають через збої на стороні клієнта Outlook, в тому випадку, якщо клієнт при обробці елементів поштових папок некоректно оновлює прапори MAPI (особливо часто це відбувається з «загальними» ящиками, з якими одночасно працюють кілька користувачів). У більшості випадків користувач може навіть не підозрювати про наявність у його шухляді або папках помилок, тому що зовні все працює нормально. Але при деяких помилках користувач може мати проблеми з доступом до ящика або окремих папок, перегляду або видалення листів або папок, що зберігаються в ящику і т.п.

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

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

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

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

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

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

Синтаксис команди такий:

New-MailboxRepairRequest -Mailbox -CorruptionType [-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, мало про що говорить:

Не вдається видалити цю папку. Клацніть правою кнопкою миші папку та клацніть Властивості, щоб перевірити свої дозволи для цієї папки. Зверніться до власника папки або адміністратора, щоб змінити ваші дозволи. Outlook синхронізує локальні зміни, внесені до елементів у цій папці. Ви не можете видалити цю папку, поки не завершиться синхронізація із сервером

outlook помилка видалення папки

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

New-MailboxRepairRequest -Mailbox accounts@winitpro.ru -CorruptionType ProvisionedFolder,SearchFolder,AggregateCounts,Folderview

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

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

Leave a Reply

Your email address will not be published. Required fields are marked *