Тази статия се фокусира върху доста често срещан проблем, с който рано или късно ще се сблъскат всички администратори на Exchange. - повреда (логически грешки) в пощенската кутия потребител. Подобни логически грешки се проявяват в такива проблеми като грешки в синхронизацията и замразяването в Outlook, неправилно представяне на елементи в папка, техният грешен номер, неуспехи в търсенето, грешки в споделените папки и т.н..
Тези грешки се появяват главно поради грешки в клиентската страна на Outlook, в случай че клиентът неправилно актуализира MAPI флаговете при обработка на елементи от папката на пощенските кутии (особено това се случва с „споделени“ пощенски кутии, които се използват от няколко потребители едновременно). В повечето случаи потребителят може дори да не подозира, че има грешки в пощенската му кутия или папки, защото Външно всичко работи добре. Но с някои грешки, потребителят може да изпита проблеми с достъпа до пощенската кутия или отделните папки, преглеждането или изтриването на букви или папки, съхранявани в пощенската кутия и т.н..
В случай, че потребителят срещне такива проблеми, администраторът на сървъра на Exchange трябваше да прибегне до един от трите начина за възстановяване на такава повредена пощенска кутия:
- Импортиране на данни от Outlook, стартиран в кеширан режим на PST файл, изтриване и възстановяване на пощенската кутия на „проблемния“ потребител на сървъра и накрая импортиране на данни от PST файла в нова пощенска кутия на Exchange. Тази техника включва известно количество ръчна манипулация на компютъра на потребителя.
- Пълно деактивиране (демонтиране) на магазина за поща и неговия Проверка на полезността на Isinteg.exe (Information Store Integrity Checker), която ви позволява да поправите щети в базата данни на Exchange на ниво приложение. Този метод изисква доста дълъг престой на пощенската услуга за всички потребители, чиито пощенски кутии са разположени в прекъсната база данни.
забележка. В някои случаи можете да опитате да преместите всички потребителски пощенски кутии в „здрава“ пощенска база данни. В този случай ще бъде възможно да се провери целостта на съхранението, без да се изключва голям брой потребители. Тази техника обаче по различни причини не винаги е приложима..
- Възстановяване на базата данни на Exchange от архивиране, импортиране на данни от конкретна кутия в PST файл и по-нататъшно прехвърляне на данни в пресъздадено поле. Тази техника има недостатък - всички букви, попаднали в полето на потребителя след последното архивиране, ще бъдат загубени.
Администраторите на Exchange сървърите трябваше да използват описаните по-горе методи до пускането на Exchange 2010 SP1, в която се появи по-удобна функционалност за възстановяване на логическата структура на повредената пощенска кутия - Powershell нов-MailboxRepairRequest. Този командлет ви позволява да намерите и коригирате логически грешки и повреди в базата данни на Exchange на ниво приложение и търсенето и коригирането на грешки може да се извърши както за конкретна пощенска кутия, така и за всички пощенски кутии в базата данни (последователно). Т.е. не е необходимо да се превежда напълно пощенската база данни офлайн и във всеки даден момент само една пощенска кутия ще бъде недостъпна, тази, за която се проверява и възстановява целостта. Преди да изпълните един от описаните по-горе радикални методи за възстановяване на целостта на кутията, определено си струва да опитате тази команда.
Този командлет може да се използва за намиране, възстановяване и наблюдение на повредени пощенски кутии във всички поддържани версии на Exchange: 2010, 2013 и 2016..
Синтаксисът на командите е както следва:
New-MailboxRepairRequest -Mailbox -CorruptType [-Archive] [-Confirm []] [-DetectOnly] [-DomainController] [-WhatIf []]Командлета ви позволява да намерите и поправите следните видове щети в пощенските кутии на Exchange:
- SearchFolder - грешки в папките за търсене
- AggregateCounts - проверка и коригиране на информация за броя на елементите в папките и техния размер
- FolderView - Невалидно съдържание, показвано от изгледи на папки
- ProvisionedFolder - нарушения на логическата структура на папките
Използвайки параметъра DetectOnly, можете да проверите пощенска кутия или пощенска база данни, без да извършвате никакви действия, например:
New-MailboxRepairRequest -Mailbox winitpro -DetectOnly -CorruptType ProvisionedFolder, SearchFolder
Следващият пример ще започне процеса на анализ и възстановяване на потребителското поле на winitpro за всички 4 вида щети:
New-MailboxRepairRequest -Mailbox winitpro -CorrupType ProvisionedFolder, SearchFolder, AggregateCounts, Folderview
Така че можете да започнете търсенето на грешки и тяхното възстановяване за всички пощенски кутии на базата данни:
New-MailboxRepairRequest-База данни „MailBaseMsk1“ -CorrupType 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 - Стартиране на възстановяване на ниво обмен на база данни
- 10062 - открити щети
- 10064 - Стартиране на възстановяване на обществена папка
В случай, че сървърът има няколко пощенски бази данни, за да се поддържа производителността на Exchange сървъра, не се препоръчва едновременно да стартирате New-MailboxRepairRequest за голям брой бази данни (въпреки факта, че само една процедура на MailboxRepairRequest се поддържа за една база данни, в рамките на една сървърът може да работи до 100 заявки едновременно).
Като практичен пример за използване на командлета, помислете за малък случай.
Потребител на Exchange не е в състояние да преглежда имейли в една от папките на Outlook. Посочената папка беше възстановена от архива на кутията. Самата папка обаче, нито от Outlook, нито от Outlook Web App, нито дори твърдо и меко изтриване с помощта на MFCMAPI, не могат да бъдат изтрити. Грешка на клиента на Outlook, казва малко за:
Тази папка не може да бъде изтрита Щракнете с десния бутон върху папката и след това щракнете върху Свойства, за да проверите вашите разрешения за тази папка. Вижте собственика на папката или вашия администратор, за да промените разрешенията си. Outlook синхронизира местните промени, направени в елементите в тази папка. Не можете да премахнете тази папка, докато синхронизирането със сървъра не приключи
За да проверите и възстановите целостта на полето, командата се изпълни:
New-MailboxRepairRequest -Mailbox [email protected] -CorrupType ProvisionedFolder, SearchFolder, AggregateCounts, Folderview
След успешното завършване на операцията по възстановяване (събитие 10048 в дневника) повредената папка в Outlook Web App изчезна веднага, в Outlook, за правилното показване на полето "актуализиран", беше необходимо да изтриете локалния кеш (ost файл).
