Ez a cikk egy meglehetősen általános problémára összpontosít, amelykel minden Exchange rendszergazda előbb vagy utóbb szembesül. - sérülés (logikai hibák) a postafiókban felhasználó. Hasonló logikai hibák olyan problémákban jelentkeznek, mint a szinkronizálás és a befagyasztási hibák az Outlookban, a mappák téves bemutatása, helytelen számuk, keresési hibák, megosztott mappák hibái stb..
Ezek a hibák elsősorban az Outlook ügyféloldalán fellépő hibák miatt fordulnak elő, abban az esetben, ha az ügyfél helytelenül frissíti a MAPI zászlókat, amikor a levélmappa elemeket dolgozza fel (ez különösen érvényes a "megosztott" postafiókok esetében, amelyeket több felhasználó egyszerre használ). A legtöbb esetben a felhasználó nem is gyanítja, hogy hibái vannak a postafiókjában vagy mappáiban, mert Külsőleg minden jól működik. Néhány hibával azonban a felhasználónak problémákat okozhat a postaláda vagy az egyes mappák elérése, a postafiókban tárolt levelek vagy mappák megtekintése vagy törlése stb..
Abban az esetben, ha a felhasználó ilyen problémákkal szembesül, az Exchange szerver rendszergazdájának a sérült postafiók helyreállításának három módszer egyikét kellett választania:
- Adatok importálása az Outlookból, gyorsítótárazott módban PST fájlba indítva, törölve és újra létrehozva a kiszolgálón található „probléma” felhasználó postafiókját, és végül adatokat importál a PST fájlból egy új Exchange postafiókba. Ez a technika bizonyos mértékű kézi manipulációt foglal magában a felhasználó számítógépén.
- A levéltár és annak teljes letiltása (leválasztása) Az Isinteg.exe segédprogramjának ellenőrzése (Információs áruház integritásának ellenőrzője), amely lehetővé teszi az Exchange adatbázisban található sérülések alkalmazás szintjén történő kijavítását. Ez a módszer a levelezési szolgáltatás meglehetősen hosszú leállását igényli minden felhasználó számára, akinek a postafiókjai leválasztott adatbázisban találhatók.
megjegyzés. Bizonyos esetekben megpróbálhatja az összes felhasználói postafiókot "egészséges" e-mail adatbázisba helyezni. Ebben az esetben ellenőrizni lehet a tárolóeszközök integritását anélkül, hogy nagyszámú felhasználót bontanák meg. Ez a módszer azonban különféle okokból nem mindig alkalmazható..
- Az Exchange levelezési adatbázis visszaállítása a biztonsági mentésből, egy adott mező adatainak importálása egy PST fájlba, és az adatok továbbítása egy újra létrehozott mezőbe. Ennek a technikanak hátránya van - minden olyan levél elveszik, amely a felhasználói fiókba esett az utolsó biztonsági mentés után.
Az Exchange kiszolgálók rendszergazdáinak a fent leírt módszereket kellett használniuk az Exchange 2010 SP1 kiadásáig, amelyben a sérült postafiók logikai struktúrájának helyreállításához kényelmesebb funkcionalitás jelent meg - Powershell új-MailboxRepairRequest. Ez a parancsmag lehetővé teszi a logikai hibák és károk megtalálását és kijavítását az Exchange adatbázisban alkalmazás szintjén, és a hibakeresés és -javítás elvégezhető mind az adott postafiókra, mind az adatbázis összes postafiókjára (egymás után). Ie nem szükséges teljes mértékben lefordítania a levelezési adatbázist offline állapotban, és egy adott pillanatban csak egy postaláda nem lesz elérhető, amelyik integritását ellenőrzik és visszaállítják. Mielőtt végrehajtaná a fentebb leírt radikális módszerek egyikét a doboz integritásának helyreállítása érdekében, feltétlenül érdemes kipróbálni ezt a parancsot.
Ez a parancsmag használható az sérült postaládák keresésére, helyreállítására és figyelésére az Exchange összes támogatott verziójában: 2010, 2013 és 2016..
A parancs szintaxisa a következő:
New-MailboxRepairRequest -Mailbox -CorruptionType [-Archive] [-Confirm []] [-DetectOnly] [-DomainController] [-WhatIf []]A parancsmag lehetővé teszi az alábbi típusú sérülések megtalálását és kijavítását az Exchange postafiókokban:
- SearchFolder - hibák a keresési mappákban
- AggregateCounts - a mappákban lévő elemek számával és méretével kapcsolatos információk ellenőrzése és javítása
- FolderView - Érvénytelen tartalom jelenik meg a mappanézetekben
- ProvisionedFolder - a mappák logikai szerkezetének megsértése
A DetectOnly paraméter segítségével ellenőrizheti a postafiókot vagy a levelezési adatbázist bármilyen művelet végrehajtása nélkül, például:
New-MailboxRepairRequest -Postafiók winitpro -DetectOnly -CorruptionType ProvisionedFolder, SearchFolder
A következő példa elindítja a winitpro felhasználói fiók elemzésének és helyreállításának folyamatát mind a négy típusú kár esetén:
New-MailboxRepairRequest -Mailbox winitpro -CorruptionType ProvisionedFolder, SearchFolder, AggregateCounts, Folderview
Így elindíthatja a hibák keresését és azok helyreállítását az adatbázis összes postaládája számára:
Új-MailboxRepairRequest -Adatbázis “MailBaseMsk1” -CorruptionType ProvisionedFolder, SearchFolder, AggregateCounts, Folderview
A parancs a háttérben fut, és nem ad eredményt a PowerShell konzolról. Az indítást és a helyreállítást nyomon követheti a RequestID feladat-azonosítóval és a Windows eseménynaplójával (MSExchangeIS postafiók-áruház eseményforrása: EventID esemény 10059 - szkennelés indítása, EventID 10048 a művelet sikeres befejezése).
A következő EventID-ok szintén hasznosak lehetnek (az Exchange postafiókok helyreállítási eljárásának nyomon követése érdekében összegyűjthetők az MSExchangeIS postafiók tárolónaplójának külön nézetében)
- 10044 - A postafiók visszaállítási kérésének végrehajtási hibája
- 10045 - hiba az adatbázis-visszaállítási kérés végrehajtása során
- 10046 - A doboz logikai szerkezetének helyreállítása sikeresen befejeződött
- 10047 - Postafiók-szintű helyreállítási kérelem indítása
- 10048 - a helyreállítási kérelem sikeresen befejeződött
- 10049 - hiba a helyreállítás végrehajtása közben, egy másik futási kérelem található ugyanabban az adatbázisban
- 10050 - helyreállítási kérelem kihagyva a mezőbe
- 10051 - a visszaállítási kérést törölték az adatbázis leszerelésének hiánya miatt
- 10059 - Az Exchange adatbázis-szintű helyreállítás indítása
- 10062 - kár észlelve
- 10064 - Indítsa el a Nyilvános mappa visszaállítását
Abban az esetben, ha a szervernek több levelezési adatbázisa van, az Exchange szerver teljesítményének fenntartása érdekében nem ajánlott a New-MailboxRepairRequest egyszerre futtatása nagyszámú adatbázis számára (annak ellenére, hogy egy adatbázishoz csak egy MailboxRepairRequest folyamat támogatott, egyben a szerver akár 100 kérést is képes kezelni egyszerre).
A parancsmag használatának gyakorlati példájaként vegye figyelembe egy kis esetet.
Az Exchange felhasználó nem tudta megtekinteni az e-maileket az egyik Outlook mappában. A megadott mappa vissza lett állítva a doboz biztonsági másolatából. Magát a mappát sem az Outlook, sem az Outlook Web App alkalmazásból, sem pedig az MFCMAPI használatával történő kemény és puha törlést sem lehet törölni. Az Outlook kliens hibája, alig szól:
Nem lehet törölni ezt a mappát. Kattintson a jobb gombbal a mappára, majd kattintson a Tulajdonságok elemre, hogy ellenőrizze a mappához tartozó engedélyeket. Az engedélyek megváltoztatásához keresse meg a mappa tulajdonosát vagy a rendszergazdát. Az Outlook szinkronizálja a mappában szereplő elemek helyi módosítását. Ezt a mappát csak akkor lehet eltávolítani, ha a szinkronizálás befejeződött
A doboz integritásának ellenőrzésére és visszaállítására a következő parancs futott:
New-MailboxRepairRequest -Mailbox [email protected] -CorruptionType ProvisionedFolder, SearchFolder, AggregateCounts, Folderview
A helyreállítási művelet sikeres befejezése után (a naplóban szereplő 10048 esemény) az Outlook Web App sérült mappája azonnal eltűnt, az Outlookban a "frissített" mező helyes megjelenítéséhez törölni kellett a helyi gyorsítótárat (ost fájl)..
