Sellest hoolimata elan Eesti MVP perele kaasa oma tegemistes!

Artikli originaali leiad siit

Homme 3. aprillil toimub ka selleaastane Powered by MVP üritus, kus sellel aastal esinevad kõik hetkel aktiivsed Eesti MVP-d, kaasa arvatud ka mina. Minu teemaks on Mailbox role High Availability, kus vaatlen, mis on need tegurid, mis (ja kuidas) mõjutavad mailbox serveri valikut vea korral. Lubasin algul, et kõik demodega kaetud. Nüüd kui asja kokku panin, selgus, et ega ma väga live demosid teha ei saagi, lihtsalt mõned asjad käivad natuke aeglasemalt kui mu ettekanne võimaldaks, ning nii ongi enamus demosid animeeritud PowerPoint slaidid, mis teeb arusaamise minu meelest isegi paremaks. Igal juhul loodan, et tuleb huvitav ja kutsun kuulama. Registreeruda saate Eneta veebilehelt.

Artikli originaali leiad siit

Minu jaoks oli MVP Summit esimene, kuivõrd olen ju ka esimest aastat MVP. Küll aga olen ka 2 korda varem Seattles ja Redmondis käinud, mõlemad korrad veel Microsofti ridades olles. Korra käisin südatalvel ja teine kord südasuvel, nüüd siis ajal, mis hakkab kevadeks minema. Temperatuurid olid kõikuvad: –1 kraadist kuni 9 kraadini Celsiuse järgi, kuigi keskmiselt oli ikka 5-6 kraadi juures. Üldiselt tundus jahe, mis võis olla kõledast läänetuulest tingitud, aga kui esmaspäeval oli päikesepaisteline ilm (ja ainult +3 kraadi sooja), siis päike on juba päris terav. Mis mind hämmastas on see, et kirsid juba õitsevad hoolimata heitlikust ilmast, kuigi kõik puud olid veel täiesti lehetud.

Päevad oli pikad, sessioonid hakkasid kell 9 pihta ja kestsid tavaliselt kella 5-ni õhtul. Sisu kohta ei saa ka paraku midagi rääkida, sest kõik oli NDA all (milline piinamine, rääkida uutest ja huvitavatest asjadest, ning edasi rääkida ei tohi ). Päeva lõpus oli alati mingi üritus/pidu/koosviivimine mõnes toredas kohas, kus joogid ja söögipoolise eest oma rahakotti kergendama ei pidanud. Koosviibimiste tipuks oli neljapäevane üritus, mis toimus Seattle esindusstaadionil CenturyLink Field, ning on koduväljakuks kohalikule Ameerika jalgpalli ja jalgpalli meeskondadele. Loomulikult palju erinevat sööki ja jooki, meelelahutust alates ringikäivatest kenadest tantsutüdrukutest (kellega koos pildi tegemiseks tuli päris võidelda ja järjekorras seista), kuni live bändiga karaoke võimaluseni. Lisaks said kõik tehiskattega väljakul ringi käia ja palliga möllata.

Neljapäeva õhtul ennem suurt pidu võtsin osa ka ringkäigust Microsofti uude Redmond Ridge Datacenter. Asub see Microsofti Redmondi campusest natuke eemal, sõites umbes 15 min sisemaale. Põhjusi, miks PG käsutuses olevad testserverid ja muud on viidud Microsofti Redmondi campusest välja, on mitmeid. Lisaks on uus datacenter väga “roheline”, kasutatakse 4 põlvakonna datacenter lahendust, kus jahutamine käib passiivselt. Sellises datacentris pole tõstetud põrandaid, millele alt jahedat õhku sisse puhutakse (ja mis seetõttu parasjagu lärmi tekitavad). Redmond Ridge Datacenter maja eemalt nähes, ei osanud üldse arvata, et seal midagi suurt võiks olla. Metsa vahel bürood meenutav 1-2 kordne maja ja kõik. Sissepääs loomulikult kõvasti turvatud, pildistamine keelatud, lisaks loeti eraldi sõnad peale, et kuhugi vastu ei puuduks ega toetaks. Valvuri juuresti edasi minnes oli kohe kontrollruum, kus täielik ülevaade, mis kuskil töötab ja kus on probleemid. Edasi tuligi nö datacenter ise, mis meenutas natuke filmidest nähtud sadama konteinerite hoiuplatsi. Iga konteinerit meenutav Pod (kookon) on eraldiseisev üksus, kus lisaks oma sees töötavale umbes 1U suurusele 1000-le serverile ka võrguühendused ja UPS, mis suudab kogu konterinerit kümmekond minutit elus hoida. Nagu ütlesin pole põrand tõstetud nii väljaspool kui seespool konteinerit. Selliseid konteinerite arvu on raske arvata, mingi sadakond kindlasti (ja igaühes siis umbes 1000 serverit). Serverid konteineris on ilma ventilaatorita, kogu ventilatsioon on passiivne õhu liikumine. Samas iga konteineri temperatuuri monitooritakse vägagi täpselt. Müra on suhteliselt tagasihoidlik sellist hulka serverit arvestades, saab täiesti vabalt rääkida ilma ülekarjumiseta.Küsisin voolutarbimise kohta, see on 23 MW/h! Kui palju majasid selle eest saaks ära kütta Kuigi tänu uuele tehnoloogiale pidavat see peaaegu poole väiksem olema kui samas suures vana tehnoloogia datacenteris, lisaks 90% väiksem jahutusvee kulu. Me käisime konkreetselt Bingi konteineris, kus fantaasi korral võid ette kujutada otsinguid tulemas ja vastuseid tagasi minemas. Iga konteinerit käitub kui üks server, milles olevaid servereid vajadusel koormuse kasvades juurde võetakse või vastupidi ka seisma pannakse. Ühe serveri katkiminek konteineris pole mingi probleem – see lihtsalt märgitakse vigaseks ja lülitatakse välja, ning asemele võetakse teine varus olev (loomulikult saadetakse vastav teade ka haldusele, kes siis kunagi, kui selliseid katkisi servereid rohkem tekkib, ka välja vahetab). Kogu datacenter maksumus – üle miljardi dollari. Kuna pilte teha ei saanud, siis mõned lingid asjast huvitatutele, kus mõned pildid ja ka videod:

• Microsoft Redmond Ridge Datacenter
• Microsoft GFS Datacenter Tour
• Microsoft Generation 4.0 Data Center Vision

Lõpuks veel üks uudis, mis Summiti ajal ära räägiti ja nüüd ka NDA alt väljas on: MEC is back!. Nimelt toimub sellel aastal peale 10 aastast vaheaega jälle MEC ehk siis Microsoft Exchange Conference. Toimub see 24-28. september, Orlando Florida. Tegu on suure Exchange inimeste kokkusaamisega, kus on kohal nii Exchange administraatorid, kui ka Exchange MVP ja Product Group inimesed. Toimuvad sessioonid, vestlusringid, kus Exchange PG inimesed annavad ülevaadet ja vastavad küsimustele. Ja kindlasti on ka peod. Exchange tehnoloogiaga seotud inimeste jaoks on see sisuliselt aasta tähtsaim sündmuse ja kui vähegi võimalik, üritage sinna minna, te ei kahetse. Hetkel pole veel teada hinnataset jm, aga jälgige ka ürituse veebilehte www.mecisback.com

Artikli originaali leiad siit

Natuke nüüd lähemalt mahainstalleerimisest. Kõigepealt võib veenduda, et me ikka õige masina peal olema. Selleks võib anda KMS masinal Command Promptis käsu (üldiselt pole cscripti vaja isegi ette panna):

cscript slmgr.vbs /dlv

ja Office 2010 KMS host korral ka:

cscript slmgr.vbs /dlv bfe7a195-4f8f-4f0b-a622-cf13c7d16864

Väljundiks tuleb üldiselt hunnik juttu, kus kohe alguses on “Description” väli, kus kirjas vastavalt “Windows Operating System – Windows Server(R), VOLUME_KMS_R2_B channel” või “Microsoft Office 2010 KMS, VOLUME_KMS channel” (või midagi sarnast).

Järgmisena installeerimegi maha KMS teenuse käsuga:

cscript slmgr.vbs /upk

ja Office 2010 KMS jaoks:

cscript slmgr.vbs /upk bfe7a195-4f8f-4f0b-a622-cf13c7d16864

Nüüd on meil aktiveerimata masin, millele tuleks võti anda ja aktiveerida. Üks võimalus on teha seda Control Panel ja System alt, kus sisestame uue võtme, mille peale üritatakse kohe seda ka aktiveerida. Teine võimalus, et teeme seda Command Promptis juba tuttava käsuga. Kui KMS teenus tuleb teise masina peale, siis oleks mõttekas olemasolev masin ka aktiveerida KMS kliendi võtmega (vaata vaikimisi KMS klienti võtmeid varasematest artiklitest Product activation, KMS vs MAK ja Office 2010 aktiveerimine). Kui endine KMS host masin oli Windows Server 2008 R2 Standard, siis võti on YC6KT-GKW9T-YTKYR-T4X34-R7VHC ja käsk ise:

cscript slmgr.vbs /ipk YC6KT-GKW9T-YTKYR-T4X34-R7VHC

ja aktiveeerimiseks:

cscript slmgr.vbs /ato

Nüüd peaks endine KMS host masin olema tavaline KMS kliendi masin ja käsk cscript slmgr.vbs /dlv annab “Description” väljale “Windows Operating System – Windows Server(R), VOLUME_KMSCLIENT channel” väärtuse.

Lisaks tuleb kustutada või uuendada DNS serveris KMS serveri kirjet. See on SRV kirje ja asub _tcp all nimega _VLMCS. Kui KMS saab teise serveri peal asuma, siis tuleks kirjes asendada vana KMS serveri nime uue serveri nimega.

Nüüd on KMS server eemaldatud ja uuel serveril vaja see peale panna. Kuidas seda teha on kirjeldatud varasemates artiklites Product activation, KMS vs MAK ja Office 2010 aktiveerimine.

Artikli originaali leiad siit

Artikli originaali leiad siit

Taastamise algus on samamoodi: taastada failid, teha läbi soft recovery ja veenduda, et baas on “puhtas” seisus, luua recovery baas taastatud baasile, ning võtta baas külge. Vaatame erinevaid taastamise stsenaariume.

Lahtiühendatud postkast (disconnected mailbox) on postkast, mis pole omistatud ühelegi Active Directory kasutaja külge. Exchange Server 2010 SP1 võimaldab kahte tüüpi lahtiühendatud postkasti:

• Disabled mailbox – postkast on lahti ühendatud Disable-Mailbox või Remove-Mailbox käsuga (või sellele vastava EMC valikuga). Exchange hoiab selliselt kustutatud postkasti alles kuni säilitusaja lõpuni (vaikimisi 30 päeva).
• Soft-deleted mailbox – kui postkast tõstetakse üle teise baasi, siis Exchange 2010 SP1 ei kustuta tõstetud postkasti vanas asukohas, vaid märgib selle staatuseks soft-deleted, ning hoitakse samuti säilitusaja lõpuni.

Disabled mailbox-ga saab teha 3 tegevust:

1. Ühendada see olemasoleva AD kasutajaga
2. Taastada see AD kasutajale
3. Kustutada see lõplikult baasist

Soft-deleted mailbox-ga saab teha 2 tegevust:

1. Taastada see AD kasutajale
2. Kustutada see lõplikult baasist

1. Ühenda olemasoleva kasutajaga

Eesmärk ühendada postkast olemasoleva AD kasutajaga, kellel pole veel postkasti. Kasutaja võib olla sama mis varem, või on see mõni teine kasutada. Kasutaja saab peale seda omistamist postkasti omanikuks ja täisõigused selle sisule. Külgeühendamine toimub Connect-Mailbox käsuga. Näiteks Mike Ray postkasti temale endale külge tagasi panek:

Connect-Mailbox -Database “Mailbox Database 0989701769″ -Identity ‘Mike Ray’

Antud näites on AD kasutaja määramata ja Exchange üritab ise leida/kokku sobitada postkasti nime ja AD-st kasutaja. Kui paneme postkasti teisele kasutajale, siis tuleks täpsem olla. Näiteks ühendame Mike Ray postkasti Terry Adams kasutaja külge (tal pole postkasti küljes):

Connect-Mailbox -Database “Mailbox Database 0989701769″ -Identity ‘Mike Ray’ -User ‘Terry Adams’

EMC abil saab samuti kasutajaid külge ühendada. Selleks tuleb võtta Recipients Configuration alt Disconnected Mailbox. Lahtiühendatud postkastid on siin näha (ainult disabled mailbox staatusega!) ja neid saab külge ühendada:

Märkus: Mõnikord võib olla vaja käivitada Clean-MailboxDatabase käsk, et värskendada lahtiühendatud postkasti info AD ja Exchange baasi vahel.

2. Taasta sisu olemasolevale kasutajale

Eesmärk taastada lahtiühendatud postkasti sisu olemasoleva kasutaja postkasti. Seda saab teha ainult Powershellis New-MailboxRestoreRequest käsuga. Näiteks taastame Mike Ray disabled mailbox-i sisu Holly postkasti:

New-MailboxRestoreRequest -SourceDatabase “Mailbox Database 0989701769″ -SourceStoreMailbox ‘Mike Ray’ -TargetMailbox Holly -AllowLegacyDNMismatch

Juhul kui sihtpostkast pole sama kui disabled mailbox, siis tuleb kasutada -AllowLegacyDNMismatch võtit. Kui on vaja, et taastamine toimuks kindlasse kataloogi, siis tuleb kasutada -TargetRootFolder võtit. Võimalik on filtreerida ainult kataloogide tasemel, see tähendab taastada ainult teatud katalooge või mingeid katalooge mitte taastada. Analoogiliselt saab sama käsuga taastada ka soft-deleted postkasti sisu olemasolevale kasutajale.

Kuivõrd antud käsk algatab taastamise protsessi, siis selle oleku saab käsuga Get-MailboxRestoreRequest. Kui staatus on Completed, siis saab seda eemaldada Remove-MailboxRestoreRequest käsuga.

Lisaks New-MailboxRestoreRequest käsule saab Recovery mailbox baasis olevate postkastide taastamiseks kasutada ka Restore-Mailbox käsku. Restore-Mailbox käsul on võimalik kasutada erinevaid filtreid (näiteks kuupäevad, subjektid jne). Juhul kui taastamise sihtpostkast ei ole sama kui lahtiühendatud postkastil, siis saab taastada ainult sihtpostkastis määratud kataloogi.

3. Kustutada lõplikult baasist

Eesmärk kustutada lahtiühendatud postkastid koheselt baasist. See võib osutuda eriti oluliseks soft-deleted postkastide korral, mis jäävad järele peale postkasti teise baasi tõstmisel, ning hoiavad baasi ruumi kinni. Kustutamist on võimalik teha kahte moodi (mõlemad Powershellis), EMC kaudu seda teha ei saa:

• Kasutada Remove-Mailbox käsku koos StoreMailboxIdentity võtmega, väärtuseks näiteks eemaldatava postkasti GUID. See on kohmakas ja ebamugav, mõtekam on kasutada teist meetodit (kui võimalik). Järgmine näide kustutab püsivalt Mike Ray lahtiühendatud postkasti:

$Temp = Get-Mailbox | ? {$_.DisplayName -eq ‘Mike Ray’}

Remove-Mailbox -Database “Mailbox Database 0989701769″ -StoreMailboxIdentity $Temp.MailboxGuid

• Kasutada Remove-StoreMailbox käsku (alates SP1-st). Eelmine näide antud käsuga näeks välja nii:

Remove-StoreMailbox -Database “Mailbox Database 0989701769″ -Identity ‘Mike Ray’ -MailboxState Disabled

Juhul kui vaja kõik baasis allesolevad äratõstetud postkastid (ehk soft-deleted mailboxes), siis järgmine näide teeb seda:

Get-MailboxStatistics -Database “Mailbox Database 0989701769″ | ? {$_.DisconnectReason -eq “SoftDeleted”} | foreach {Remove-StoreMailbox -Database $_.database -Identity $_.mailboxguid -MailboxState SoftDeleted}

Kuigi arhiivi taastamine on põhimõtteliselt sama kui lahtiühendatud postkastil, erineb arhiivi taastamine natuke eelnevast. Online arhiivist taastamist võib ette tulla, kui sealt on midagi kustutatud säilituspoliitika abil (retention policy) või on kasutaja midagi ise sealt ära kustutanud. Analoogiliselt lahtiühendatud  postkastiga, on 3 võimalust:

1. Taasühenda arhiiv kasutajaga
2. Taasta arhiivi sisu
3. Eemalda baasist lahtiühendatud arhiiv

1. Taasühenda arhiiv kasutajaga

Arhiivi saab külge võtta ainult samale kasutajale, kellele see ennem kuulus. Põhjus on selles, et LegacyDN attribuut on nii primaarsel kui ka arhiivi postkastil üks ja seesama, mistõttu ei saa seda “valele” kasutajale külge panna. Külge ühendamine ise käib analoogiliselt lahtiühendatud postkastidega, tuleb vaid lisada parameeter Archive. Näiteks ühendame Nuno Bunto lahtiühendatud arhiivi talle külge tagasi:

Connect-Mailbox -Database Archive -Identity ‘Online Archive – Nuno Bento’ -Archive

2. Taasta arhiivi sisu

Primaarsel postkastil ja arhiivi postkastil on erinevad identifikaatorid (Guid). Taastamiseks oleks vaja ette anda või teada arhiivi postkasti Guid-i. Näiteks pärime recovery database sisu koos Guid-ga:

Get-MailboxStatistics -Database RecoverArchive | fl Display*, *guid*

Jätkame näidet, Holly arhiivi taastamine, parameetrid võtame Holly primaarse postkasti attribuutidest, taastatav sisu ühildatakse olemasolevaga:

Get-Mailbox Holly | % {New-MailboxRestoreRequest -SourceDatabase RecoverArchive -SourceStoreMailbox $_.ArchiveGuid -TargetMailbox $_.Identity -TargetIsArchive}

Kasutame juba tuttavat New-MailboxRestoreRequest käsku (% ees on alias ForEach käsule), lisandiks TargetIsArchive arhiivi määratlemiseks. Lõpetatud taastamiskäsu kustutamine:

Get-MailboxRestoreRequest | ? {$_.Status -eq “Completed”} | Remove-MailboxRestoreRequest -Confirm:$false

Võib ka kasutada Restore-Mailbox käsku. Sellisel juhul saame taastada ainult mingisse kataloogi, küll aga saame kasutada filtreid. Järgnev näide taastab Holly arhiivi postkasti Taastatud kataloogi:

Restore-Mailbox Holly -RecoveryDatabase RecoverArchive -RecoveryMailbox ‘c719b767-551f-4bac-8630-9f61c4cafcaa’ -TargetFolder Taastatud

3. Eemalda baasist lahtiühendatud arhiiv

Täpselt analoogiline lahtiühendatud postkastidega.

Artikli originaali leiad siit

Artikli originaali leiad siit

Registreerimine ja täpsem info käib läbi Eneta, eraldi registreerimine arendajate ja IT-proffide (infra) loengutele. IT-proffide poolelt kutsun tagasihoidlikult ka oma Exchange 2010 teemalisele loengule algusega 17:30, peale mida saabki kohe pühenduda Kinectiga mängimisele ja muule kasulikule tegevusele. Kuivõrd kohtade arv on piiratud, tuleks registreerida võimalikult kiiresti, et kindlustada endale osavõtu. Teisisõnu kasutades tsitaati ühest vanemast eesti filmist: kiirustage, seltsimehed unetud!

Artikli originaali leiad siit

Ennem varukoopia tegemist oli Peter Houston postkastis kiri subjektiga “Before backup”, mille me nüüd “kogemata” ära kustutame ja mida oleks vaja nüüd taastada:

Esimese sammuna valime Windows Server Backup programmist taastamise (Recover…), mille peale avaneb aken:

Valida tuleb, kus kohas asub varukoopia, kas lokaalsel masinal või kuskil võrgukettal. Kuivõrd meie praegune varukoopia sai tehtud samale masinale, siis esimene valik on õige.

Nüüd tuleb valida, mis kuupäeva (ja vajadusel ka kellaaja) seisuga taastada vaja on, viimast seisu pakutakse vaikimisi.

Valime, kas taastada teatud faile ja katalooge, või terveid voluume. Meil on ainult ühte baasi vaja taastada, siis valik on “Files and folders”.

Selles aknas tuleb valida, mis failid või kataloogid taastame. Kui samas varukoopia nimekirjas on eraldi kataloogidena nii baasid kui transaktsioonid, siis taastada tuleb üks kataloog korraga, GUI kaudu ei saa taastada neid mõlemaid. Sellisel juhul tuleb taastada näiteks kõigepealt baasid, siis sama protseduur uuesti transaktsioonidega. Meil on nii baasid kui transaktsioonid samas kataloogis, seega selekteerime vasakult puust kataloogi 1.

See on nüüd oluline koht, kus eksida ei tasuks. Esimese valiku (Original location) tehes, taastatakse kogu vastav baas, kus hetkel töö jookseb ja tehakse läbi kõik taastamisega vajalikud protseduurid. Seda valikut läheb vaja siis, kui terve baas on puudu või vigane. Teine valik (Another location), on vajalik, et teha single item restore asju (ehk teine asukoht ja kasutame seda recover database baasina). Kuivõrd meie stsenaariumis ongi vaja taastada ainult ühte kirja, siis teine valik ja taastame failid E ketta RecoverDB1 kataloogi.

Viimane aken enne failide taastamise algust, tundub kõik õige olevat ja võibki vajutada Recover nuppu Meeldetuletuseks veelkord, et juhul kui baas ja transaktsioonid olid erinevates kataloogides, siis tuleb sama asi veelkord läbi teha ka transaktsioonidega. Kui kõik sai taastatud, siis peaks E:RecoverDB1 kataloogis olema selline pilt:

Järgnevalt pange käima Exchange Management Shell ja minge samasse kataloogi, kuhu me failid taastasime, antud juhul siis E:RecoverDB1 kataloogi. Kõigepealt peame laskma käima nö soft recovery, et olemasolevad transaktsioonid baasile läbi mängiksid. Seda saab teha siis käsuga:

eseutil /r e01 /d E:RecoverDB11.edb /l E:RecoverDB1

Võti /r on soft recovery tegemiseks, E01 on baasi prefiks. Seda leiab kõige lihtsamalt, kui võtate 3 esimest sümbolit transaktsioonifailist või kui võtate checkpoint faili (.chk lõpuga) nime ilma laiendita, antud juhul on see siis E01. Võti /d ja katalooginimi koos baasiga, on baasi nimi ja asukoht, võit /l ja katalooginimi on transaktsioonide asukoht.

Üldiselt peaks eseutil /r jooksma läbi ilma vigadeta kuni lõpuni. Kui aga ei juhtu, siis tuleb täiendavalt vaeva näha, et viia baas korrektsesse seisu, vastasel korral  pole seda võimalik külge võtta. Kogemuse põhjal tundub, et selline probleem tekkib, kui baas ja transaktisoonid on erinevatel ketastel, nagu ka käesolevas näites on. Ka siin on asi pooleli jäänud umbes 95% juures.

Juhul kui niimoodi juhtub, siis tuleb kasutada kangemat lähenemist, sama eseutil käsk, aga võtmega /p:

eseutil /p E:RecoverDB11.edb

Antud juhul üritatakse taastada baasi tabelite struktuur, nii et see oleks kasutuskõlbulik. Põhimõtteliselt võib siin tekkida ka infokadu, aga seda eelkõige siis, kui baas on juba ennem katkine olnud. Taastamise korral on enamasti põhjuseks see, et mingi transaktsiooni logi jupp on veel puudu ja selle käsuga sisuliselt ignoreeritakse viimaseid transaktsiooni logisid.

Käsk lõppes õnnelikult, nüüd tuleks kontrollida, kas baas on korrektses puhtas seisus (terviklikus seisus). Seda võiks teha ka siis, kui recovery /r võti viga ei andnud. Selleks kasutame jällegi eseutil käsku võtme /mh, mis kuvab baasi päise:

eseutil /mh E:RecoverDB11.edb

Meid huvitab baasi päisest hetkel ainult üks rida, tõmbasin sellele ka punase joone alla. Me otsime Status välja ja selle väärtust, mis peaks olema Clean Shutdown. Kui staatus on Clean Shutdown, siis on baas korrektses seisus ja võime edasi minna. Nüüd tuleks tekitada taastatud baasi failidele Exchange taastamisbaas. Seda saab teha ainult Powershellist ja käsk näeb välja selline:

New-MailboxDatabase -Name RecoverDB1 -Server ex01 –Recovery -EdbFilePath E:RecoverDB11.edb -LogFolderPath E:RecoverDB1

Kindlasti ei tohiks ära unustada võtit -Recovery, vaid nii tehakse see taastamisbaasiks. Võti –Name väärtus ei pea olema kataloogi nimega sarnane, vaid vabalt valitav, nii et oleks arusaadav.

Nüüd on meil ka Exchnge mõistes baas olemas ja võime selle külge mountida kas graafilisest EMC või EMS-st Powershell käsuga mount-Database RecoverDB1

Taastamine ise tuleb samuti teha Exchange Management Shellist kasutades Powershell käsku Restore-Mailbox. Sellel käsul on mitmeid võimalusi, taastada ühe inimese postkast teise inimese postkasti, taastada terve postkast ja liita kokku taastatud ja olemasolev postkast (merge), taastada kogu postkast eraldi kataloogi (ettevaatust postkasti quota seadetega, neid võib olla vaja suurendada!), taastada võtmesõnade järgi, taastada kirjade algus- ja/või lõppkuupäeva järgi jne. Igal juhul tasub uurida siin Restore-Mailbox süntaksit, et taastamine oleks võimalikult kiire ja efektiivne. Meie konkreetsel juhul taastan lihtsalt, tehes olemasolevale ja taastatava sisule merge käsuga:

Restore-Mailbox Holly -RecoveryDatabase RecoverDB1

Kui see käsk lõpetab, siis ongi meie kadunud kiri jälle tagasi:

Peale õnnestunud taastamist, tuleks ära koristada ka suure tööga saadud vaheproduktid. Kõike seda saab teha ka graafiliseses keskkonnas. EMS-i kasutades kõigepealt Remove-MailboxDatabase RecoverDB1, ning seejärel kustutada ära E kettal olev RecoverDB kataloog.

Eraldi artiklisse panen veel selle, kuidas tuleks teha, kui vaja taastada arhiivist või vaja taastada postkasti, millel kasutaja AD-st kustutatud. Sellisel juhul on algus samamoodi, nagu eelnevalt kirjas, ainult lõpp natuke teistmoodi. Artikli nimeks:

• Exchange 2010 arhiivide taastamine

Artikli originaali leiad siit

Microsofti Outlook tiim tegeleb asjaga ja parandus peaks sellele tulema juba veebruaris paketiga February 2011 Cumulative Update for Office 2007. Annan ka blogis teada, kui see on olemas, seni kannatust.

Artikli originaali leiad siit