Sissejuhatav.

AD metsi on kaks. Iga mets koosneb ühest domeenist: mets1.kohalik Ja mets2.kohalik. Ühes metsas (mets1) asuvad Kontod kasutajad. Teises metsas (forest2) on juurutatud Exchange 2010 hoolduspaketi SP3 organisatsioon, mis sisaldab metsa1 kasutajate postkaste. Kasutajakontode peegeldamist ei toimu.

Ülesanne.

Juurutage Exchange 2010 organisatsioon metsa1 ja migreerige kohandatud sisu postkastid metsast2 metsa1.

Infrastruktuuri kirjeldus.

Mets 1

mets1.kohalik

• mets1-dc1.mets1.kohalik- domeenikontroller


• mets1-kas1.mets1.kohalik


• mets1-mbx1.mets1.kohalik


• mets1-tmg1.mets1.kohalik

Kasutajatele nime panemise põhimõte on [nime eestäht][perekonnanimi]. Näiteks Ivan Ivanov - iivanov

Mets2

AD mets, mis koosneb ühest domeenist - mets2.kohalik

Metsas on juurutatud järgmised serverid:

• mets2-dc1.mets2.kohalik- domeenikontroller


• mets2-kas1.mets2.kohalik- Exchange 2010 SP3 server (CAS ja jaotur)


• mets2-mbx1.mets2.kohalik- Exchange Server 2010 hoolduspakett SP3 (postkast)


• mets2-tmg1.mets2.kohalik - tulemüür, puhverserver, vastupidine (tagurpidi, vastupidine jne) puhverserver

Kasutajate nimetamise põhimõte on [eesnimi].[perekonnanimi]. Näiteks Ivan Ivanov - ivan.ivanov

Exchange'i organisatsioon teenindab SMTP domeeni - forest.com. Kasutajad saavad juurdepääsu postkastidele Outlook Anywhere, OWA, ActiveSynci kaudu.

Postkastide üleandmine.

Võrgu infrastruktuuri ettevalmistamine.

Enne postkasti migratsiooniprotsessi alustamist peavad olema täidetud mõned eeltingimused.

• Pakkuge liikluse marsruutimist kahe metsa vahel (VPN Site-To-Site jne).


• Seadistage sisemiste nimede vastastikune viitamise tühistamine (tsoonide ülekandmine, tünnitsoonid, tingimuslik edastamine jne)


• Veendu, et Exchange'i server mõlemad organisatsioonid usaldavad üksteise sertifikaate.

Kliendi juurdepääsuserverite ettevalmistamine.

Postkasti sisu edastamise saate algatada kas lähtemetsast (minu näites mets2) või sihtmetsast (minu näites mets1). Kui teisaldamiskäsk käivitatakse sihtmetsast, siis peab lähtemetsas seadistus olema lubatud. Kui teisaldamiskäsk käivitatakse lähtemetsast, siis parameeter Postkasti replikatsiooniteenuse puhverserver (MRS-puhverserver) tuleb sihtmetsa lubada.

Alustan postkasti sisu migratsiooni sihtmetsast, seega pean serveris lubama MRS-i puhverserveri mets2-kas1.mets2.kohalik.

Set-Web Services VirtualDirectory - Identiteet "Forest2-Cas1\EWS (vaikeveebisait)" -MRSProxyEnabled $true

Get-WebServices VirtualDirectory | Set-Web Services VirtualDirectory -MRSProxyEnabled $true

Kasutajakontode loomine sihtmetsas.

Viin üle kasutaja Semjon Petrovi kirjad, kellel on järgmised valikud:

• Mõlemas metsas kuvatav nimi on Semjon Petrov


• Mets1 kasutajanimi on spetrov


• Mets2 kasutajanimi on semen.petrov


• Postiaadress - [e-postiga kaitstud]

Enne sisu migreerimise alustamist peate sihtmetsa (forest1) kasutajakontod ette valmistama. Seda tehakse kahes etapis.

Esimene samm sihtmetsa kasutajakontode ettevalmistamisel.

Esimene samm on muuta kõik sihtmetsa kasutajad, kelle postkastid migreeritakse, meilikasutajateks.

Teine samm on kasutajakontode varustamine sihtmetsas.

Teises etapis on see vajalik skripti abil Prepare-MoveRequest.ps1, kopeerige lähtemetsast mõned kasutajaatribuudid.

Prepare-MoveRequest.ps1 -Identity' [e-postiga kaitstud]’ -RemoteForestDomainController forest2-dc1.forest2.local -RemoteForestCredential (Get-Credential forest2\adm) -UseLocalObject

Edastan skriptile parameetri -Kasutage kohalikku objekti. Seda tuleb teha, sest Mul on sihtmetsas juba meilifunktsiooniga kasutaja.

Postkasti sisu migreerimine lähtemetsast sihtmetsa.

Sisu ülekandmine toimub cmdleti abil Uus-MoveRequest.

New-MoveRequest -Identity "semen.petrov" -Kaugjuhtimispult -KaugHostName forest2-cas1.forest2.local -RemoteCredential (Get-Credential forest2\adm) -TargetDeliveryDomain "forest1.local"

Mis juhtub kasutajaga sel ajal?

Pärast postkasti sisu migreerimist saab kasutaja järgmise teate:

Pärast taaskäivitamist Outlooki kasutaja luua ühendus Exchange'i serveriga, mis asub oma metsas.

Olen selgitanud Exchange 2007-s kasutatavat postkasti teisaldamise lähenemisviisi. Põhimõtteliselt see töötab Teisalda postkast Exchange'i halduskestas, kuigi postkastide teisaldamiseks saate loomulikult kasutada Exchange'i halduskonsooli. Exchange 2010-s saate postkaste teisaldada ka Exchange'i halduskonsooli ja Exchange'i halduskesta abil, kuigi protsessis on tehtud mõningaid muudatusi. Selles kolmeosalises artiklisarjas käsitlen postkaste Exchange 2010 teisaldamist ja keskendun rohkem uus funktsioon Teisaldamise taotlus.

Teisaldamise taotlused

Seetõttu tahan seda artiklit alustada, öeldes, et käsk Move-Mailbox ei ole enam Exchange 2010-s saadaval. Kogu lähenemine postkastide teisaldamisele Exchange 2010-s keskendub funktsioonile, mida nimetatakse teisaldamistaotlused. Kuna käsku Move-Mailbox enam ei kasutata, võib järeldada, et Exchange 2007 Move-Mailbox käsku ei saa kasutada postkastide teisaldamiseks Exchange 2007-st Exchange 2010-sse. peate kasutama Exchange 2010 toote teisaldamistaotluste funktsiooni.

Teisaldamistaotluse loob Exchange'i administraator, kasutades Exchange'i halduskonsooli või Exchange'i haldusshelli. Selles artiklis keskendun postkastide teisaldamisele samas metsas. Seda tüüpi liikumist nimetatakse kohalik kolimistaotlus. Postkaste metsade vahel teisaldades nimetatakse seda tüüpi kaugkolimise taotlused. Kaugteisaldamise taotlusi käsitletakse hilisemates artiklites siin saidil MSExchange.org.

Teenus täidab käsud, mis on osa teisaldamistaotlusest Microsoft Exchange'i postkasti replikatsiooniteenus, on Exchange 2010 uus teenus, mis töötab Client Access Serveri rollis. See teenus on näidatud joonisel 1.

Joonis 1: Microsoft Exchange'i postkasti replikatsiooniteenus

Teisaldamistaotlus asetab spetsiaalse süsteemiteate postkasti andmebaasi süsteemi postkasti. Microsoft Exchange'i postkasti replikatsiooniteenus kontrollib igas postkasti andmebaasis oleva süsteemi postkasti sisu teisaldamistaotluse leidmiseks ja seejärel töötleb neid päringuid asjakohaselt. Selle teenusega postkastide teisaldamisel on palju eeliseid. Siin on kolm peamist valdkonda, millega tavaliselt kokku puutun nende teisaldamistaotlustega fikseeritud migratsiooniprojektide rakendamisel.

• Postkaste saab nüüd võrgus teisaldada, isegi kui kasutajad on neisse sisse logitud. See funktsioon on saadaval ainult siis, kui postkastides töötab Exchange 2007 hoolduspakett SP2 või uuem hilisem versioon, või Exchange 2010. See on aga väga kasulik täiendus postkasti teisaldamise protsessile üldiselt, kuna aitab vältida postkastide teisaldamist väljaspool tööaega.
• Prügikastis olevad üksused teisaldatakse nüüd protsessi osana. Exchange'i eelmistes versioonides ei teisaldanud postkastide teisaldamine prügikasti objekte, seega pidi kasutaja kõik kustutatud objektid enne teisaldamist postkasti tagasi taastama. Lihtne oli unustada kasutajaid sellest teavitada ja mõnel juhul avastasid kasutajad, kelle postkaste prügikastist üksuste taastamise ajal teisaldati, et prügikast on tühi.
• Postkastide sisu ei töötle enam arvuti, kust teisaldamine toimub. Exchange 2007 puhul oli sageli nii, et käsk Move-Mailbox või sellega seotud skript töötati administraatorimasinas, mitte sihtserveris Exchange 2007. Selle stsenaariumi korral teisaldatakse postkasti sisu lähteandmebaasi administraatorimasinasse ja seejärel sihtandmebaasi. Seda stsenaariumi oleks saanud vältida käsu või käivitamisega käsu skript otse sihtandmebaasiserveris. Exchange 2010 puhul seda olukorda enam ei esine, kuna postkasti teisaldamise teostab Client Access Serveris töötav Microsoft Exchange'i postkasti replikatsiooniteenus.

Kui ma seda esimest korda lugesin Microsofti teenus Exchange'i postkasti replikatsioon igas Client Access Serveris vastutab postkasti teisaldamise eest. Ma mõtlesin, kuidas mitme kliendipääsuserveri omamine kolimist mõjutaks. Näiteks kas kaks Client Access Serverit proovivad sama postkasti korraga teisaldada? Õnneks teatas Microsoft, et seda rakendati üldine mehhanism kõigi samal Active Directory saidil asuvate Client Access Serverite vahel, et selliseid olukordi vältida.

Looge kohalik kolimistaotlus

Nüüd, kui oleme teisaldamistaotlusi veidi käsitlenud, on aeg näha, kuidas saate selle uue funktsiooni abil postkasti tegelikult teisaldada. Alustame sellest, kuidas luua Exchange'i halduskonsooli abil kohalik teisaldamistaotlus.

1. Kui Exchange'i halduskonsool on laaditud, laiendage Saaja konfiguratsioon konsoolipuus. Valige sõlmes Adressaadi konfiguratsioon objekt Postkast, mis kuvab tulemuste paanil kõigi postkastide loendi.
2. Siinkohal peate valima postkastid, mida soovite teisaldada. Saate valida korraga mitu postkasti, mida teisaldada.
3. Kui olete teisaldatavad postkastid valinud, valige suvand Uus kohalik kolimistaotlus" toiminguribal või paremklõpsake objektil Postkast ja valige kontekstimenüüst sama valik, nagu on näidatud joonisel 2.

Joonis 2: Uue kohaliku teisaldamise taotluse loomine

1. Te käivitate viisardi Uus kohalik teisaldusnõude viisard ja kuvage tutvustusleht Sissejuhatus, nagu on näidatud joonisel 3. Sellel lehel kuvatakse teie valitud postkastid ja ka oluline teave, mis sisaldab postkasti andmebaasi, mis sisaldab Sel hetkel need postkastid asuvad.

Joonis 3: Uue kohaliku teisaldamistaotluse viisardi tutvustusleht

1. Sissejuhatuslehel klõpsake nuppu Sirvi", mis avab postkasti andmebaasi valikuakna (Valige Postkasti andmebaas), nagu on näidatud joonisel 4. Selles aknas kuvatakse andmebaasid, mis on saadaval kõigis teie organisatsiooni serverites. Minu näites teisaldan postkasti lihtsalt andmebaasist Postkasti andmebaas 001 V Postkasti andmebaas 002 samas serveris nimega DAG1. Nii et ma lihtsalt valin selle andmebaasi ja klõpsan Okei.

Joonis 4: Postkasti andmebaasi valiku leht

1. Nüüd tuleks sissejuhataval lehel andmebaasi väli täita sihtandmebaasi nimega. Klõpsake Edasi.
2. Järgmisena avaneb teisaldamisvalikute aken. (Liikumisvalikud), nagu on näidatud joonisel 5. Kui olete kasutanud, peaks see aken olema teile tuttav varasemad versioonid Vahetada. Siin saate määrata, kuidas käsitleda rikutud sõnumeid, kui neid leidub lähteandmebaasis. Siin on võimalus postkast täielikult vahele jätta või lubada teatud arv rikutud kirju. Puuduvad õigused või valed sätted, oleneb kõik sellest, kuidas teie organisatsioon andmete kadu kohtleb. Alloleval pildil olen valinud võimaluse jätta kogu postkast vahele; rikutud esemete leidmisel postkasti ei liigutata. Seejärel kontrollin andmebaasi selliste utiliitidega nagu ISINTEG, et näha, kas see suudab riknemist parandada.

Joonis 5: Teisaldamissuvandite leht

1. Kui olete teisaldamisvalikute lehel sobivad valikud valinud, klõpsake nuppu Edasi. See kuvab viimase lehe, kus saate enne nupu klõpsamist vaadata konfiguratsiooni kokkuvõtet Uus kohaliku teisaldamistaotluse loomiseks.
2. Seejärel luuakse kohalik teisaldamistaotlus ja edastatakse see Client Access Serverile; viisardi saab sulgeda.

Looge PowerShelliga teisaldamistaotlus

Kohaliku teisaldamistaotluse loomiseks Exchange'i halduskesta abil saate kasutada käsku Uus-MoveRequest ja sellega seotud parameetrid. lihtne käskühe postkasti ühest andmebaasist teise teisaldamiseks kohaliku teisaldamise taotluse loomine võib välja näha järgmine:

New-MoveRequest "Identity nimi "TargetDatabase "Mailbox Database 004"

Siin parameeter Identiteet kasutatakse teisaldatava postkasti ja parameetri määramiseks Sihtandmebaas Määrab andmebaasi, kuhu postkast teisaldatakse. Selle käsu käivitamine annab samasuguseid tulemusi nagu on näidatud joonisel 6.

Joonis 6: New-MoveRequest käsk

Joonisel 6 märkate, et osa veergudes olevast teabest on mõnevõrra ebaselge, millal standardvormingus kasutatakse Exchange Management Shellis. Selle olukorra parandamiseks saate käsu New-MoveRequest tulemused käivitada käsu kaudu formaat-tabel(allolevas näites lühendatud ft) ja kasutage valikuid "Automaatne suurus Ja "Mähkida, nagu on näidatud selles näites:

New-MoveRequest "Identity nimi "TargetDatabase "Mailbox Database 004" | ft "AutoSize -Wrap

See annab joonisel 7 kujutatutele sarnaseid tulemusi, muutes andmete lugemise palju lihtsamaks.

Joonis 7: vormindatud käsk New-MoveRequest

Siinkohal tahan mainida ka viga, millega võite kokku puutuda see etapp. Kui proovin nüüd sama postkasti teise andmebaasi teisaldada, kuvatakse järgmine tõrketeade:

Postkasti (nimi) on sellega seotud täidetud teisaldamistaotlus. Enne postkasti jaoks uue teisaldamistaotluse loomist käivitage täidetud teisaldamistaotluse kustutamiseks cmdlet Remove-MoveRequest.

See veateade on näidatud joonisel 8.

Joonis 8: New-MoveRequesti viga

Nagu veateade ütleb, on postkastis juba olemas täielik taotlus teisaldamine, mis tuleb enne muude teisaldustaotluste loomist kustutada. Seega tähendab see, et teisaldamistaotlus tuleb eemaldada kohe pärast selle täitmist.

Märge: teisaldamistaotlusi ei kustutata automaatselt isegi siis, kui postkasti teisaldamine õnnestub. See mõjutab ka postkastide andmebaaside kustutamist, mida käsitleme selles artikliseerias hiljem. Vaatame ka edasi.

New-MoveRequest käsul on palju valikuid, mida saate kasutada teisaldustaotluste juhtimiseks. Nagu võite oodata, kui olete Exchange 2007-ga tuttav, on Exchange Management Shellil see olemas rohkem viise päringu juhtelemendi teisaldamine kui Exchange'i halduskonsoolis. Täielik nimekiri kõik parameetrid on leitavad, kuid selles artiklis kirjeldan mõnda neist olulised parameetrid:

• BadItemLimit- nagu on näidatud joonisel 5, saate otsustada, kui palju kahjustatud postkasti üksusi programm postkasti teisaldamisel talub. Exchange'i halduskestas juhib seda sätet parameeter BadItemLimit.
• partii nimi- See kasulik parameeter See võimaldab mitme postkasti teisaldamisel määrata paketi nime. Seejärel saate seda paketinime kasutada konkreetsete postkastide otsimiseks, kui kasutate käsku GetMoveRequest, mida käsitlen selle sarja kolmandas osas.
• IgnoreRuleLimitErrors- Kui teil tekib postkasti teisaldamisel reeglipiirangu tõrkeid, saate kasutajareeglit postkasti osana mitte teisaldada. See valik võimaldab teil seda teha. Näiteks saate muuta teisaldamistaotluse parameetreid pärast selle lubamist, et tagada reeglite töötlemine. Sellest räägime ka tsükli kolmandas osas.
• MRSServer- Tavaliselt tegeleb teisaldamistaotlusega üks Active Directory saidi Client Access Servers. Konkreetse Client Access Serveri määramiseks kasutage MRSServeri parameetrit koos Client Access Serveri nime täieliku domeeninimega (FQDN).
• SuspendWhen ReadyToComplete – seda parameetrit kasutatakse teisaldamistaotluse peatamiseks enne postkasti püsivat sihtbaasi teisaldamist. Teisisõnu teisaldatakse kõik kehtivad postkasti andmed, kuid viimane liigutus toimub alles siis, kui administraator jätkab teisaldamist käsuga Resume-MoveRequest. Üks olukord, kus seda lähenemisviisi saab kasutada, on saada postkasti teisaldamiseks lõplik kinnitus. Seda võimalust arutatakse selle artiklite sarja kolmandas osas.

Sihtandmebaasi haldamine

Huvitav on see, et käsu New-MoveRequest parameeter TargetDatabase on tegelikult valikuline. Selle artikli alguses olevates näidetes on näha, et seda valikut kasutati postkasti teisaldamise tagamiseks andmebaasi nimega Postkasti andmebaas 004. Kui välistate parameetri TargetDatabase, valib teisaldamistaotluse protsess andmebaasi automaatselt.

Kui teil on üks või mitu postkasti andmebaasi, mida soovite sellest valikuprotsessist välja jätta, saate parameetri väärtust muuta IsExcludedFromProvisioning andmebaas, mille soovite välistada. See säte on näidatud joonisel 9, kus see on vaikimisi loetletud. vale, mis näitab, et andmebaas on postkastide täitmiseks saadaval. Kui ma sooviksin muuta selle postkasti andmebaasi 004 sätte tõeseks, käivitaksin järgmise käsu:

Set-MailboxDatabase "Mailbox Database 004" "IsExcludedFromProvisioning $True

Joonis 9: Postkasti andmebaaside väljajätmine teisaldamistaotlusest

Teisalda taotluste haldamine

Nüüd, kui kohalik kolimistaotlus on loodud, peate selle edenemist jälgima. Exchange'i halduskonsoolis klõpsake objektil Teisaldamise taotlus asub sõlmes Saaja konfiguratsioon konsoolipuus. See avab akna, mis on sarnane joonisel 10 näidatud aknaga. Sellelt jooniselt olen selguse huvides eemaldanud toiminguriba.

Joonis 10: Teisaldamise taotluste haldamine

Siin näete, et kuvatakse teisaldamistaotluste loend. Praegu on pooleli ainult üks teisaldamise taotlus ja taotluse oleku väli Teisaldamistaotluse olek näitab käigu olekut Liikumine. Vaikimisi kuvatakse konsoolis ainult väljad Kuvanimi, Alias, Teisaldamistaotluse olek ja Teisalda taotluse tüüp. Teile saadava teabe laiendamiseks on kaks võimalust.

1. Valige Exchange'i halduskonsoolis menüü Vaade, siis valik Lisa/eemalda veerud" akent välja tuua Lisa/eemalda veerge, nagu on näidatud joonisel 11. Siin näete, et väljad Nimi (Nimi), Nimi kaughost Saadaval on ka (kaughosti nimi), lähteandmebaas ja sihtandmebaas. Ekraanil olevate erinevate nuppude abil saate määrata, milliseid täiendavaid välju kuvada, samuti nende kuvamise järjekorda.

Joonis 11: Lisateabe veergude lisamine

1. Teine võimalus Exchange'i halduskonsoolis teabe lisamiseks on teisaldustaotluse atribuutide vaatamine. Selleks paremklõpsake lihtsalt teisaldamistaotlusel ja valige Omadused V kontekstimenüü. See avab teisaldustaotluse atribuutide akna, mis sarnaneb joonisel 12 näidatud aknaga.

Joonis 12: Teisaldamistaotluse atribuudid

Üks huvitavamaid joonistel 10 ja 12 näidatud välju on olekuväli. Teisaldamistaotluse olek. Joonis 12 näitab, et olek on tähistatud kui Lõpetamine, kuid loomulikult võib see väli võtta ka selliseid väärtusi nagu Progress, Lõpetatud, ebaõnnestunud jne. See võimaldab teil näha, kus liigutustaotlus üldises protsessis on.

Teisalda taotluste haldamine

Saate kasutada Exchange'i halduskestat, et vaadata käsu abil teisaldamistaotluse edenemist GetMoveRequest. Vaikeolekus tagastab käsk Get-MoveRequest kõigi saadaolevate teisaldustaotluste tulemused. Näiteks vaadake joonist 13, millel on näidis käsu Get-MoveRequest tagastatud teabest. See näitab ainult ühte teisaldamistaotlust ja näitab ka seda, et minu postkast teisaldati sihtandmebaasi nimega TEST. Samuti näete, et teisaldamistaotlus on lõpetatud.

Joonis 13: Get-MoveRequesti tulemused

Nagu käsu New-MoveRequest puhul, on ka selle käsu jaoks saadaval palju Get-MoveRequest valikuid. Täieliku valikute loendi leiate. Mõned kõige olulisemad parameetrid on järgmised:

MoveStatus: selle valikuga saate kasutada käsu Get-MoveRequest tulemusi ainult kindla olekuga teisaldustaotluste hankimiseks. Näiteks kui teil on vaja vaadata kõiki olekuga teisaldamistaotlusi Progress, peate kasutama järgmist käsku:

Get-MoveRequest "MoveStatus Progress

Sellise käsu tulemuste näide on näidatud joonisel 14. Kehtivad olekuparameetrid on Mitte ühtegi, Järjekorras, Progress, Automaatselt peatatud, LõpetamineKäimas, Lõpetatud, Lõpetatud hoiatusega, Peatatud Ja ebaõnnestunud.

lähteandmebaas: see suvand näitab kõiki postkaste, mida konkreetsest lähteandmebaasist teisaldatakse, seega on see kasulik lähte postkasti serveri koormuse määramisel.

SuspendWhenReadyToComplete: seda sätet kasutatakse teisaldamistaotluste peatamiseks enne, kui kast on püsivalt sihtandmebaasi teisaldatud. Sellest valikust räägime veidi hiljem.

sihtandmebaas: see parameeter on sarnane SourceDatabase'iga, välja arvatud see, et see näitab sihtandmebaasi.

Peatage teisaldamistaotlus

Nagu me selle seeria teises osas ja eelmises osas lühidalt käsitlesime, hõlmavad käsud New-MoveRequest ja Get-MoveRequest SuspendWhenReadyToComplete parameeter, mida kasutatakse teisaldamistaotluse peatamiseks enne sihtandmebaasi lõpliku asukoha värskendamist. Selle lähenemisviisi korral teisaldatakse postkasti andmed, kuid viimane lülitus toimub alles pärast peatatud teisaldamistaotluse taaskäivitamist. Samuti saate käsuga peatada olemasoleva teisaldamistaotluse Suspend-MoveRequest.

Vaatame parameetri SuspendWhenReadyToComplete kasutamist käsu New-MoveRequest jaoks. Käivitatava käsu näide oleks järgmine:

New-MoveRequest "Identity nimi" SuspendWhenReadyToComplete

Kui olete selle seeria eelmisi osi lugenud, märkate, et ülaltoodud käsk ei sisalda parameetrit Sihtandmebaas et määrata konkreetne andmebaas, kuhu kast teisaldatakse. Ilma selle parameetrita valib süsteem andmebaasi.

Nagu me ütlesime, lükkub postkasti teisaldamise protsess kuni viimase teisaldamiseni edasi. Seda saab konfigureerida käsu käivitamisega GetMoveRequest. Vaadake joonist 15, mis näitab, et postkasti teisaldati parameetri SuspendWhenReadyToComplete abil. Veidi hiljem on selle kolimistaotluse olek Progress ja postkasti sisu teisaldatakse. Pärast järgmist värskendust näitab käsk Get-MoveRequest, et päringu olek on nüüd muutunud Automaatselt peatatud, mis on parameetri SuspendWhenReadyToComplete kasutamisel kuvatav olek. Sarnaselt näitab seda olekut Exchange'i halduskonsool, nagu on näha joonisel 16.

Joonis 15: Peatatud teisaldamistaotlus " Exchange Management Shell

Joonis 16: Peatatud teisaldamistaotlus " Exchange'i halduskonsool

Kui administraator otsustab, et teisaldamise saab lõpule viia, saab teisaldamistaotlust jätkata käsu andmisega Resume-MoveRequest järgmise süntaksiga:

Resume-MoveRequest "Identity neil

Selle käsu täitmisel peaks käsu Get-MoveRequest uuesti käivitamine näitama olekut Lõpetatud.

Partii nimed

Selle seeria eelmises osas vaatasime käsu New-MoveRequest parameetreid ja nägime, et üks neist parameetritest on nn. Partii nimi. Seda parameetrit saab kasutada mitme postkasti teisaldamisel paketi nime määramiseks, mida saab seejärel kasutada koos käsuga Get-MoveRequest konkreetsete postkasti teisalduspakettide leidmiseks.

Ühe postkasti andmebaasi sisu teisaldamisel on paketinimed üsna kasulikud. Asjade lihtsuse huvides loon samade postkastide jaoks kaks päringut ja annan mõlemale erineva paketinime. Seejärel kasutame käsku Get-MoveRequest, et näidata, kuidas neid pakettide nimesid otsida. Esiteks loome kaks lihtne taotlus liigub Exchange Management Shelli kasutades erinevate paketinimedega:

New-MoveRequest "Identity nimi "TargetDatabase "Mailbox Database 003" "BatchName Batch001

New-MoveRequest "Identiteedi röövimine "TargetDatabase "Postkasti andmebaas 004" "BatchName Batch002

Pärast nende teisaldamistaotluste loomist saate kasutada käsku Get-MoveRequest koos parameetriga BatchName, et leida kõik postkasti teisaldamise taotlused, mis on seotud konkreetse partii nimega. Näiteks kõigi paketinimega seotud postkasti teisaldamistaotluste vaatamiseks Partii001, peate kasutama järgmist käsku:

Get-MoveRequest "BatchName Batch001

Selle käsu tulemused on näidatud joonisel 17, mis näitab, et kahest postkastist saadeti tagasi ainult üks, kuna teist postkasti teisaldati erineva paketinimega.

Joonis 17: Filtreerimine paketi nime järgi

Mitme postkasti teisaldamine

Selle sarja teises osas vaatlesime kasutaja postkasti teisaldamist käsu abil Uus-MoveRequest. Ühe postkasti teisaldamine on lihtne ülesanne, kuna postkasti pseudonüüm tuleb lihtsalt parameetris määrata Identiteet meeskonnad Uus-MoveRequest. Aga mitme postkasti teisaldamine? Seda saab teha mitmel viisil, millest mõnda kirjeldatakse allpool.

Esiteks on üsna lihtne kõiki postkaste ühest andmebaasist teise teisaldada lihtsalt käsu andmisega Get-MailboxDatabase meeskonnale Uus-MoveRequest. Näide oleks järgmine käsk:

Get-Mailbox "Database "Mailbox Database 001" | New-MoveRequest "TargetDatabase"

"Postkasti andmebaas 002"

Kui teil on vaja teisaldada vaid mõnda postkasti, saate kasutada PowerShelli massiivi funktsiooni. Oletame, et tahame teisaldada postkaste, mis kuuluvad kasutajatele Neilile, Robile ja Markile. Selles näites on kasutajanimed ka postkasti varjunimed. Selle ülesande täitmiseks saate kasutada järgmist skripti:

$MailboxesToMove = "neil","rob","mark"

ForEach ($SingleMailbox in $MailboxesToMove) (New-MoveRequest "Identity $SingleMailbox `

"TargetDatabase "Mailbox Database 002" "BatchName Batch001)

Selle stsenaariumi korral näeme, et me kõigepealt määratlesime $MailboxesToMove massiivina, mis sisaldab kolme teisaldatava postkasti varjunime nimesid. Iga postkasti pseudonüüm edastatakse seejärel käsule Uus-MoveRequest töödelda olenemata lähtepostkasti andmebaasi asukohast.

Võite kasutada ka käsku Hankige sisu, saadaval PowerShellis. Kõigepealt peate looma lihtsa tekstifail A, mis sisaldab loendit postkasti varjunimedest, mida kavatsete teisaldada. Joonis 18 näitab sellise faili näidet, see on fail nimega postkastid.txt.

Joonis 18: Näidisfail Mailboxes.txt

Seejärel võib failis mailboxes.txt loetletud postkastide teisaldamise näidisskript välja näha järgmine:

$Mailboxes = Hangi sisu ./mailboxes.txt

For ($Start = 0; $Start -lt $Mailboxes.length; $Start++) (New-MoveRequest "Identity`

$Mailboxes[$Start] -TargetDatabase "Mailbox Database 002")

Selle stsenaariumi korral käsk Hankige sisu kasutatakse sisu saamiseks postkastid.txt faili ja sisu määramiseks $Postkastid. Seejärel liigub see sisu läbi $Postkastid ja iga tsükli jaoks kasutatakse käsku Uus-MoveRequest.

Kuigi neid on erinevaid viise Exchange 2010 postkastide teisaldamisel, kasutades mitut Exchange Management Shelli käsku, peaksite sellest teadma Microsofti ettevõte annab MoveMailbox PowerShelli skript, mille leiate kaustast \Programmifailid\Microsoft\Exchange Server\V14\Scripts pärast Exchange 2010 installimist. See skript täidab kohaliku teisaldamise taotluse ühes Exchange'i organisatsioonis ja on lisakasu, mis tähendab, et see kustutab teisaldustaotluse kohe pärast selle täitmist. Enne paari näite stsenaariumi vaatamist vaadakem sellega kasutatavaid valikuid. See skript kasutab mitmeid parameetreid, mida oleme selles artikliseerias juba käsitlenud, kuigi mitmel parameetril on erinevad nimed.

Esiteks on olemas Automaatne peatamine parameeter, mille funktsioon on sama, mis parameetril SuspendWhenReadyToComplete kasutatakse koos käskudega Uus-MoveRequest Ja GetMoveRequest. Samuti BadItemLimit parameetrit saab kasutada koos skriptiga MoveMailbox. On ka valikuid Postkasti andmebaas Ja Sihtandmebaas, mis juhivad vastavalt lähte- ja sihtandmebaasi. Üks peamisi valikuid, mida selle skriptiga kasutate, on Andmebaasikaart parameeter. See on tõesti kasulik säte, mis võimaldab teil määrata, kuhu postkastid teisaldada. Vaatame seda võimalust veidi hiljem üksikasjalikumalt.

Praegu tutvume lihtsa postkasti teisaldamise protsessiga, kasutades skripti MoveMailbox. Postkasti teisaldamiseks andmebaasi nimega Postkasti andmebaas 002, käivitan lihtsalt skripti järgmiste parameetritega:

./MoveMailbox.ps1 "Identity nimi "TargetDatabase "Mailbox Database 002"

Selle käsu käivitamine annab tulemusi, mis on sarnased joonisel 19 näidatud tulemustega. Nagu ma ütlesin, on selle skripti üks suurepäraseid omadusi see, et see puhastab teisaldamise taotluse automaatselt.

Joonis 19. Ühe postkasti teisaldamine käsuskripti MoveMailbox.ps1 abil

MoveMailbox.ps1 andmebaasikaardid

Parameeter Andmebaasikaart MoveMailboxi käsuskript on väga kasulik, kui käsitlete selles mitut postkasti ja teisaldate need mitmesse sihtandmebaasi. Saate määrata mitu allika/sihtmärgi paari käsurida mis parandab oluliselt selle tõhusust. Selle valiku süntaks oleks järgmine:

DatabaseMap @("Source Database"="Sihtandmebaas";"Source Database"="Sihtandmebaas")

Selles süntaksis on nähtavad kaks allika/sihtmärgi vastendust ja need on eraldatud semikooloniga. Milleks seda kasutada, näiteks kui soovite andmebaasi postkaste teisaldada Postkasti andmebaas 001 baasile Postkasti andmebaas 003, ja baasi postkastid Postkasti andmebaas 002 baasile Postkasti andmebaas 004, peate käivitama käsu järgmise DatabaseMap parameetri süntaksiga:

DatabaseMap @("Mailbox Database 001"="Postkasti andmebaas 003";"Postkasti andmebaas 002"="Postkasti andmebaas 004")

Oletame, et soovite teisaldada kõik postkastid, mis kuuluvad osakonna liikmetele Konsultandid, V uus alus postkaste samamoodi, nagu äsja arutasime. Selleks võite kasutada järgmist PowerShelli käsku, eeldusel, et Active Directory atribuut "osakond" on õigesti täidetud:

Hangi kasutaja | Kus ($_.osakond "eq "konsultandid") | Get-Mailbox | ./MoveMailbox.ps1 "DatabaseMap @("Mailbox Database 001"="Postkasti andmebaas 003";"Postkasti andmebaas 002"="Postkasti andmebaas 004")

See kood hangib esmalt nende kasutajate konto üksikasjad, kelle Active Directory atribuudil "osakond" on väärtus Konsultandid. Selle käsu tulemused esitatakse käsule töötlemiseks Hangi postkast et saada üksikasju nende kasutajate postkastide kohta. Neid postkasti üksikasju käsitletakse seejärel skriptis MoveMailbox ja postkaste liigutatakse vastavalt. Nagu on näidatud joonisel 20, kutsub käsk MoveMailboxi skripti ja skript ootab nüüd teisaldamisprotsessi lõpuleviimist. Pärast selle protsessi lõppu kuvatakse ekraanil olekuteave, nagu on näidatud joonisel 21. Selle käsu käivitamise tulemusena minu lihtsas testkeskkonnas teisaldati üks postkast andmebaasist Postkasti andmebaas 001 baasile Postkasti andmebaas 003 ja kast aluselt Postkasti andmebaas 002 koliti baasi Postkasti andmebaas 004.

Joonis 20: Mitme postkasti teisaldamine on pooleli

Joonis 21: Mitme postkasti teisaldamine on lõpetatud

Postkasti replikatsiooniteenuse seisund

Selles artiklis oleme juba öelnud, et teenus Microsoft Exchange'i postkasti replikatsioon on üldise kolimistaotluse protsessi jaoks väga oluline, järeldub, et seda teenust tuleb vastavalt jälgida. Eelmises artikliseerias saidil msexchange.org rääkisin erinevatest Exchange 2007 "test" Exchange Management Shelli käskudest, mida saate kasutada Exchange 2007 teatud funktsioonide testimiseks. Exchange 2010 sisaldab Test-MRSHealth käsk, kus MRS on postkasti replikatsiooniteenuse lühend. Konkreetse Client Access Serveri seisukorra kontrollimiseks kasutage lihtsalt parameetrit "Identiteedi, mis sisaldab sobivat Client Access Serveri nime, näiteks:

Test-MRSHealth "Identity DAG1

Ülaltoodud näites kannab Client Access Server nime DAG1. Selle käsu täitmise tulemus on sarnane joonisel 22 kujutatule.

Joonis 22: Käsu Test-MRSHealth käitamise tulemused

Joonisel 22 on näha, et käsk Test-MRSHealth kontrollib, kas postkasti replikatsiooniteenus töötab, seejärel pingib RPC teenusele ja lõpuks kontrollib, kui kaua on möödunud postkasti andmebaasi järjekorra skannimisest.

Postkasti andmebaasi kustutamine

Tavaliste administraatorikohustuste osana peate mõnikord olemasoleva Exchange 2010 serveri kasutusest kõrvaldama või lihtsalt eemaldama vana alus postkasti andmed. Võib-olla mäletate eelmistest osadest, et teisaldamistaotlusi ei kustutata automaatselt isegi siis, kui teisaldamine on lõpule viidud. Erandiks on skripti MoveMailbox.ps1 kasutamine, kuid kui teisaldamistaotlused loodi käsitsi Exchange'i halduskesta või Exchange'i halduskonsooli abil, tuleb need enne postkasti andmebaasi kustutamist kustutada. See kehtib isegi olukordades, kus antud alus postkastid ei sisalda ühtegi postkasti, kuid teisaldamise taotlus on siiski olemas.

Kui üritate olemasoleva teisaldamistaotlusega postkasti andmebaasi loobuda, kuvatakse tõrketeade, mis algab sõnadega "See postkasti andmebaas on seotud ühe või mitme teisaldamistaotlusega." See tõrge kuvatakse. Vt joonis 23. Sel põhjusel peate kasutama Käsud Get-MoveRequest ja Remove-MoveRequest olemasolevate teisaldustaotluste otsimiseks ja eemaldamiseks.

Joonis 23. Andmebaasi langetamise ajal olemasolev teisaldamistaotlus

Järeldus

Sellega lõpetatakse neljaosaline seeria Exchange 2010 kohalike teisaldamistaotluste kohta. Pange tähele, et me ei ole käsitlenud kõiki käske ja nendega seotud valikuid, kuid leiate nende kohta teavet vastavast dokumentatsioonist. Loodan, et see artikliseeria on andnud teile hea aluse kogu postkasti teisaldamise taotluse protsessi toimimiseks Exchange 2010-s.

Neil on Ühendkuningriigi Microsofti kuldpartneri Silverslandsi (www.silversands.co.uk) peakonsultant ning vastutab paljude suurklientide rakenduste arendamise, juurutamise ja toetamise eest üle Euroopa. Ta on töötanud IT-valdkonnas alates 1987. aastast ja on spetsialiseerunud sõnumivahetusele alates 1995. aastast. Ta alustas tööd Exchange 4.0-ga. Tal on ka Exchange'i MVP tiitel ja ta pühendab osa oma isiklikust ajast erinevate Exchange'i kasutajate abistamisele, mis on pühendatud Exchange'ile. Need ajaveebid leiate aadressilt www.msexchangeblog.com. Neiliga saab ühendust võtta aadressil

Ettevalmistus. Tööjaamade operatsioonisüsteemide loend, Outlooki kliendid, viirusetõrjed. Varustage Exchange 2013 serveri jaoks ressursse ja installige operatsioonisüsteem. Läbivaatus DNS-kirjed ja välise ruuteri edastamise muutmise valmisoleku määramine.

Paigaldamine Exchange 2013 server Exchange 2010 kõrval.

Seadistamine ja testimine ühine töö kaks serverit korraga.

Vahetamine meilivoog Exchange 2013-s.

Ülekanne Exchange 2013 postkastid.

aretus Exchange 2010 serveri käitamisest.

Sissejuhatus: kõik Exchange 2010 rollid on installitud samasse serverisse. Samuti peate kompaktselt üle minema Exchange 2013-le.

Ettevalmistus

Ettevalmistusfaasis peate kontrollima, kas teie ettevõtte võrk on Exchange 2013 versiooniuuenduse jaoks valmis.

Kõige parem on, kui operatsioonisüsteem tööjaamades Windows 7 või hiljem. Kuigi olen näinud tavaline töö Exchange 2013 operatsioonisüsteemiga Outlook 2007 Windows XP hoolduspaketi SP3 all. XP on aga tugiteenustest eemaldatud ja sellega ei saa arvestada. Kui teil on vaja tagada klientide töö Windows XP all, siis on parem hoiduda Exchange 2013 installimisest. Või leidke testkeskkonnas usaldusväärne viis, kuidas need sellises konfiguratsioonis tööle panna, ja alles siis pöörduge tagasi selle ettevõtmise juurde. IN viimase abinõuna vanade või muude operatsioonisüsteemide kasutajad saavad alati OWA kaudu brauseri kaudu e-postiga ühenduse luua.

Outlook 2003 kliente ei toetata. Hilisemate jaoks on soovitatav installida värskendused (need tulevad WSUS-i, peate lihtsalt kinnitama):
- Outlook 2007 jaoks - KB2687404
- Outlook 2010 jaoks - KB2687623
- Outlook 2013 jaoks - KB2863911 (praktika on näidanud, et see pole hoolduspaketi SP1 jaoks vajalik)

Kui teil pole Outlooki, pole teil tõenäoliselt ka Exchange'i vaja.

Paar sõna viirusetõrje kohta. Kaspersky 8 koos veebikontrolliga blokeerides Outlooki töö. Peate veebijuhtimise keelama või erandid seadistama või kõik uuendama Kaspersky versioonile 10.

Paar sõna DNS-i kohta. DNS-i seadistamine Sest meiliserver juba . Ühe jaoks saate kohe lisada väljaspool CNAME kirje samale aadressile, kuhu viitab peamine MX-kirje. Midagi sellist: "CNAME-posti automaatne avastamine". Et saaks ühendada Outlooki klient väljaspool peaks kuulama port 443. Kuigi nagu varemgi, saate IMAP-i või POP3 kaudu seadistada mis tahes teisi kliente.

Väikese organisatsiooni jaoks (200...300 postkasti jaoks) on loogiline Exchange 2013 all välja tuua. virtuaalne keskkond server 4…6 tuumaga, 12 GB RAM, HDD: 100…120 GB ( süsteemi ketas) + Ketas meiliandmebaasi jaoks. Meie puhul võttis Exchange 2010 EDB andmebaasifail enda alla umbes 120 GB. Ligikaudu samaks jäi see peale üleviimist aastasse 2013. Kohast ei kahju olnud, tegime C + D = 120 + 500 (kasvuks). OS võeti vene keeles - Windows Server 2012R2. Installige kindlasti kõik värskendused.

TÄHTIS! Teil peab olema kehtiv CA. Kui seda mingil põhjusel ikka pole, siis on aeg see tõsta. Pealegi pole see keeruline. Exchange 2013 EI tööta ilma sertifikaatideta. Ja on veel üks nüanss: tavalisel sertifitseerimisasutusel (CA) Windowsil on natukenegi toetada võimalust määrata ühele sertifikaadile mitu nime. Kõrval vähemalt Windows 2008 R2 puhul oli see vajalik. Võib-olla on Windows sellest ajast peale targutanud.

Paigaldamine

Kõigepealt teeme varukoopia AD. Kuigi sellest hilisema taastumise võimalus on väga kaheldav. Regulaarsed vahendid DC-s: Start - Administrative Tools - Windows Server Backup.

Kõigi sellega seotud manipulatsioonide läbiviimise mugavuse huvides Exchange'i installimine 2013, installime sellele ühest serverist (on uus server Exchange 2013) haldustööriistad. Windows Powershellis:

Impordimooduli serverihalduri installimine - Windowsi funktsioon RSAT-ADDS installimine - Windowsi funktsioon AS-HTTP-aktiveerimine, töölauakogemus, NET-Framework-45-funktsioonid, RPC-üle HTTP-puhverserver, RSAT-klasterdamine, RSAT-klasterdamine-CmdInterface, veebis -Mgmt-konsool, WAS-protsessimudel, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http - Vead, veebi-Http-logimine, veebi-Http-ümbersuunamine, veebi-Http-jälgimine, veebi-ISAPI-Ext, veebi-ISAPI-filter, veebi-Lgcy-Mgmt-konsool, veebimetabaasi, veebi-Mgmt-konsool , Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation

(Jah, see on väga pikk nöör. Kuid selleks on kõik lihtne ja kiire.)

Installige serverisse:

Exchange 2013 häälestusprogramm küsib teilt vajaduse korral ülejäänu.

Kasutatud levitamiskomplekt ei olnud ISO, mis on postitatud MVLS-is (www.microsoft.com/Licensing/servicecenter), vaid see, mis on avatud juurdepääs— KB2936880

Exchange 2013 postkastide teisaldamist ühest andmebaasist teise saab teha üsna lihtsalt läbi EAC (Exchange Admin Center), kuid selles artiklis kaalun võimalust liikuda powershell, sest isegi SP1 versiooni veebiliides on üsna toores ja kasti ühest andmebaasist teise vedamisel esineb ülesannetes aeg-ajalt vigu.

Otsi rohkem informatsiooni Exchange 2013 konfigureerimise ja haldamise kohta minu ajaveebis saate põhiteema artiklis -.

Exchange 2013 postkastide teisaldamine

Kastide andmebaaside vahel teisaldamise taotluste loomiseks kasutage cmdleti Uus-MoveRequest. Näide täismeeskond näeb välja selline:

C:\Windows\system32> New-MoveRequest -Identity " [e-postiga kaitstud]» -TargetDatabase "Sihtandmebaasi nimi" -BatchName "Sisestage oma päringu nimi" -BadItemLimit "200"

Teisaldamise taotlus tehtud, suurepärane. Aga mis siis, kui kastis on kumbki suur suurus või tohutul hulgal elemente ja soovite lihtsalt jälgida toimingu edenemist, mis ilmus kohe alguses veerus Täielik protsent? Siit tuleb kõige huvitavam, sest ülesande edenemise jälgimiseks vajame veel ühte cmdlet-i, siin see on: Get-MoveRequestStatistics.

Kasutusnäide artikli alguses oleva käsu andmete põhjal:

C:\Windows\system32> Get-MoveRequestStatistics -Identity [e-postiga kaitstud]

Ja siin on käsu väljund:

Paremal on veerg, kus on näidatud ülesande täitmise protsent.

Parameetri kohta on vaja eraldi rääkida BadItemLimit cmdlet Uus-MoveRequest: vastutab vahele jäetud rikutud elementide arvu eest. Vaikimisi, kui pole määratud, on see 0 ja Microsoft soovitab tungivalt seda mitte puudutada. Kui aga kastis on rikutud üksusi, siis päring nurjub ja kast jääb samasse andmebaasi. Minu praktikas ei olnud kahesaja postkasti ühest andmebaasist teise ülekandmisel (Exchange 2010-st 2013-le migreerumisel) rohkem kui 2-4 postkasti, millel oli vähemalt üks kahjustatud element, hoolimata sellest, et 2010. aasta server oli töötanud. mitu aastat. Seetõttu võime järeldada, et Exchange'i nõuetekohase haldamise korral on kahjustatud elementide esinemise juhtumeid üsna vähe.

Samuti tahan märkida, et kui väärtus BadItemLimit teil on rohkem kui 50, siis peate võtit sundima Aktsepteeri LargeDataLoss, vähemalt nii on Technetis kirjas, aga tegelikkuses panin alati elementide arvuks 200 ja keegi pole kunagi küsinud, kas olen nõus "suure andmekaoga" ega keelanud käsu täitmist (vt. esimene ekraanipilt, parameeter Aktsepteeri LargeDataLoss pole seal loetletud).

Tuleb märkida, et Exchange 2013 kontseptsioon seisneb selles, et halduskeskused sisaldavad ainult põhifunktsioone, minimaalset komplekti. Peentele parameetritele ja sageli isegi mõnele funktsioonile juurdepääsu saamiseks (näiteks võrguühenduseta aadressiraamatu toimingutele, aga sellest lähemalt mõni kord), peate kasutama ainult Powershelli.