Ta članek se osredotoča na dokaj pogost problem, s katerim se bodo slej ko prej soočili vsi skrbniki Exchange. - škoda (logične napake) v nabiralniku uporabnik. Podobne logične napake se kažejo v takšnih težavah, kot so napake pri sinhronizaciji in zamrznitvi v Outlooku, napačna predstavitev elementov v mapi, njihovo napačno število, napake pri iskanju, napake v skupnih mapah itd..
Te napake se v glavnem pojavijo zaradi napak na stranki Outlooka v primeru, da odjemalec napačno posodobi zastavice MAPI pri obdelavi elementov poštnih map (to se zgodi zlasti pri "običajnih" nabiralnikih, ki jih hkrati uporablja več uporabnikov). V večini primerov uporabnik morda niti ne sumi, da obstajajo napake v njegovem nabiralniku ali mapah, ker Navzven vse deluje v redu. Toda z nekaterimi napakami lahko uporabnik naleti na težave z dostopom do nabiralnika ali posameznih map, pregledovanjem ali brisanjem črk ali map, shranjenih v nabiralniku itd..
V primeru, da se uporabnik sreča s takšnimi težavami, se je moral administrator strežnika Exchange zateči k enemu od treh načinov za obnovitev tako poškodovanega nabiralnika:
- Uvozi podatke iz Outlooka, zagnano v predpomnjenem načinu v datoteko PST, brisanje in ponovno ustvarjanje nabiralnika "problematičnega" uporabnika na strežniku ter na koncu uvoz podatkov iz datoteke PST v nov Exchange nabiralnik. Ta tehnika vključuje določeno količino ročnih manipulacij na uporabnikovem računalniku.
- Popolno onemogočanje (odstranjevanje) poštne trgovine in njene trgovine Preverjanje uporabnosti Isinteg.exe (Checker Integrity Checker), ki omogoča popravljanje škode v bazi podatkov Exchange na ravni aplikacije. Ta metoda zahteva precej dolg izpad poštne storitve za vse uporabnike, katerih nabiralniki se nahajajo v odklopljeni bazi podatkov.
Opomba. V nekaterih primerih lahko poskusite premakniti vse uporabniške nabiralnike v "zdravo" poštno bazo. V tem primeru bo mogoče preveriti celovitost pomnilnika, ne da bi odklopili večje število uporabnikov. Vendar ta tehnika iz različnih razlogov ni vedno uporabna..
- Obnovite zbirko podatkov iz e-poštne zbirke Exchange, uvoz podatkov iz določene škatle v datoteko PST in nadaljnji prenos podatkov v ponovno ustvarjeno polje. Ta tehnika ima pomanjkljivost - vsa črka, ki je padla v polje uporabnika po zadnji varnostni kopiji, bo izgubljena.
Administratorji strežnikov Exchange so morali do izdaje programa Exchange 2010 SP1 uporabljati zgoraj opisane metode, v katerih se je pojavila bolj priročna funkcionalnost za obnovo logične strukture poškodovanega nabiralnika - Powershell Novo-MailboxRepairRequest. Ta cmdlet omogoča iskanje in odpravljanje logičnih napak in poškodb v bazi podatkov Exchange na ravni aplikacije, iskanje in odpravljanje napak pa je mogoče izvesti tako za določen nabiralnik kot za vse nabiralnike v bazi (zaporedno). I.e. ni treba popolno prevesti poštne baze podatkov brez povezave, v vsakem trenutku pa bo na voljo samo en nabiralnik, tisti, za katerega se preverja in obnovi integriteta. Preden izvedete eno od zgoraj opisanih radikalnih metod za obnovitev celovitosti polja, je vsekakor vredno poskusiti ta ukaz.
Ta cmdlet se lahko uporablja za iskanje, obnovo in spremljanje poškodovanih nabiralnikov v vseh podprtih različicah sistema Exchange: 2010, 2013 in 2016..
Sintaksa ukaza je naslednja:
New-MailboxRepairRequest -Mailbox -CorruptType [-Archive] [-Confirm []] [-DetectOnly] [-DomainController] [-WhatIf []]Cmdlet omogoča iskanje in odpravljanje naslednjih vrst škode v nabiralnikih Exchange:
- Iskalnik - napake v iskalnih mapah
- Agregirani računi - preverjanje in popravljanje informacij o številu elementov v mapah in njihovi velikosti
- Folderview - Neveljavna vsebina, prikazana v pogledih mape
- Določena mapa - kršitve logične strukture map
S parametrom DetectOnly lahko preverite poštni nabiralnik ali poštno zbirko podatkov, ne da bi izvedli nobena dejanja, na primer:
New-MailboxRepairRequest -Mailbox winitpro -DetectOnly -CorruptType ProvisionedFolder, SearchFolder
Naslednji primer bo začel postopek analize in predelave uporabniškega polja winitpro za vse štiri vrste škode:
New-MailboxRepairRequest -Mailbox winitpro -CorrupType ProvisionedFolder, SearchFolder, AggregateCounts, Folderview
Tako lahko začnete iskanje napak in njihovo obnovitev za vse nabiralnike baze podatkov:
New-MailboxRepairRequest-Podatkovna baza „MailBaseMsk1“ -CorrupType ProvisionedFolder, SearchFolder, AggregateCounts, Folderview
Ukaz se izvede v ozadju in ne prikaže nobenih rezultatov na konzoli PowerShell. Njegov zagon in obnovitev lahko spremljate z ID-jem naloge RequestID in dnevnikom dogodkov Windows (vir dogodkov MSExchangeIS Mailbox Store: EventID dogodek 10059 - začetek skeniranja, EventID 10048 uspešen zaključek operacije).
Naslednji dogodki EventID so lahko tudi koristni (za lažje sledenje postopku obnovitve poštnih nabiralnikov Exchange jih je mogoče zbrati v ločenem pogledu dnevnika trgovine MSExchangeIS Mailbox Store)
- 10044 - Napaka pri izvrševanju zahteve za obnovitev nabiralnika
- 10045 - napaka pri zahtevi za obnovitev baze podatkov
- 10046 - Uspešno obnovljeno logično strukturo polja
- 10047 - Zagon zahteve za obnovitev ravni nabiralnika
- 10048 - zahteva za obnovitev uspešno zaključena
- 10049 - napaka pri izvajanju obnovitve, v isti bazi podatkov je bila najdena še ena teka zahteva
- 10050 - zahteva za obnovitev je preskočena za polje
- 10051 - zahteva za obnovitev je bila preklicana zaradi dejstva, da je baza podatkov odstranjena
- 10059 - Zagon obnovitve ravni podatkovnih baz
- 10062 - odkrita škoda
- 10064 - Začni obnoviti javno mapo
V primeru, da ima strežnik več poštnih baz podatkov, da bi ohranili uspešnost strežnika Exchange, ni priporočljivo zagnati New-MailboxRepairRequest hkrati za večje število baz podatkov (kljub dejstvu, da je za eno bazo podatkov znotraj ene podprte samo en postopek MailboxRepairRequest) strežnik lahko dela do 100 zahtev hkrati).
Kot praktičen primer uporabe cmdlet razmislite o majhnem primeru.
Uporabnik Exchangea ni mogel videti e-poštnih sporočil v eni od map Outlooka. Navedena mapa je bila obnovljena iz varnostne kopije polja. Vendar same mape, niti iz Outlooka, niti iz Outlook Web App, niti trdega in mehkega brisanja z uporabo MFCMAPI ni mogoče izbrisati. Napaka odjemalca v Outlooku govori le malo o:
Te mape ni mogoče izbrisati. Z desno miškino tipko kliknite mapo in nato kliknite Lastnosti, da preverite svoja dovoljenja za to mapo. Če želite spremeniti svoja dovoljenja, glejte lastnika mape ali skrbnika. Outlook sinhronizira lokalne spremembe, narejene v elementih v tej mapi. Te mape ne morete odstraniti, dokler sinhronizacija s strežnikom ni končana
Če želite preveriti in obnoviti celovitost polja, je bil ukaz izveden:
New-MailboxRepairRequest -Mailbox [email protected] -CorrupType ProvisionedFolder, SearchFolder, AggregateCounts, Folderview
Po uspešno zaključenem postopku obnovitve (dogodek 10048 v dnevniku) je poškodovana mapa v Outlook Web App takoj izginila, v Outlooku, za pravilen prikaz "posodobljenega" polja je bilo potrebno izbrisati lokalni predpomnilnik (ost datoteka).
