Vioittuneen paikallisen toimialueen ohjauskoneen palauttaminen ja uudelleenasentaminen

Kun verkkotunnuksen ohjauskone vioittuu tai palautetaan virheellisesti, pelko on valtava: Kirjautumiset epäonnistuvat, ryhmäkäytäntöobjekteja ei enää sovelleta ja replikointi epäonnistuu lähes ilman vihjeitä.Hyvä uutinen on, että fyysisen tai virtuaalisen toimialueen ohjaajan palauttamiseen on olemassa selkeät menettelytavat, kunhan hyväksyttyjä varmuuskopiointi- ja palautusmenetelmiä noudatetaan.

Nykyaikaisissa Windows Server -ympäristöissä toimialueen ohjauskoneen palauttaminen edellyttää hyvää käsitteiden ymmärrystä, kuten järjestelmän tila, autoritatiivinen/ei-autoritatiivinen palautus, SYSVOL, DFSR/FRS ja USN-palautuksetJos näihin ongelmiin puututaan hätäisesti tai yhteensopimattomilla kuvantamistyökaluilla, tuloksena voi olla metsä täynnä hiljaisia ​​epäjohdonmukaisuuksia, joita on erittäin vaikea diagnosoida.

Miksi on tärkeää suojata ja palauttaa toimialueen ohjauskone asianmukaisesti

Active Directory on Windows-toimialueen todennuksen ja valtuutuksen ydinSe tallentaa käyttäjät, tietokoneet, ryhmät, luottamussuhteet, ryhmäkäytännöt, varmenteet ja muut kriittiset elementit. Nämä tiedot sijaitsevat pääasiassa tietokannassa. Ntds.dit, niihin liittyvät lokitiedostot ja kansio SYSVOL, muiden niin kutsutun "järjestelmän tilan" muodostavien komponenttien ohella.

Järjestelmän tila sisältää mm. Active Directoryn lokitiedostot ja -tiedot, Windowsin rekisteri, järjestelmäasema, SYSVOL, varmennetietokanta (jos varmenteiden myöntäjä on olemassa), IIS-metatietokanta, käynnistystiedostot ja suojatut käyttöjärjestelmän osatSiksi kaikkiin vakavasti otettaviin liiketoiminnan jatkuvuusstrategioihin on sisällytettävä säännölliset varmuuskopiot kunkin datakeskuksen järjestelmätilasta.

Kun Active Directory -tietokanta vioittuu, tapahtuu vakava replikointivirhe tai ongelma käyttöoikeudet päällä SYSVOLToimialueen ohjauskone saattaa lopettaa kyselyiden käsittelyn, epäonnistua Active Directory -palveluiden käynnistämisessä tai laukaista CSS-virheitä koko toimialueen metsässä. Näissä tapauksissa Nopea ja asianmukainen toipuminen ratkaisee, onko kyseessä vakava onnettomuus vai pitkittynyt katastrofi..

Ennen palautuksen yrittämistä on tärkeää erottaa aito tietokantaongelma tavallisemmista virheistä. Hyvin usein Syynä on DNS, verkon muutokset, palomuurit tai reittejä, joita on muokattu työkaluilla, kuten netsh komentoSiksi on suositeltavaa sulkea nämä tekijät ensin pois ennen AD-tietokantaan koskemista.

Perusdiagnostiikka- ja replikaationhallintatyökalut

Jos ilmenee korruption tai replikointivirheiden oireita, ensimmäinen järkevä askel on tarkistaa ympäristön tila natiivien työkalujen avulla. DCDiag, Repadmin, ReplMon (vanhemmissa versioissa) ja Tapahtumienvalvonta He ovat parhaita liittolaisiasi ennen kuin harkitset aggressiivisia restaurointeja.

kanssa DCDiag Kaikille verkkotunnusohjaimille suoritetaan yleinen tarkistus, jossa tunnistetaan replikointiin, DNS:ään, AD DS -palveluihin jne. liittyvät ongelmat. Repadmin Sen avulla voit tarkastella replikoinnin tilaa, replikointikumppaneita, USN-vesileimoja ja havaita pysyviä objekteja. Vanhemmissa Windows-versioissa ReplMon Se tarjosi graafisen näkymän replikaatiovirheistä verkkotunnuksessa.

Näiden työkalujen lisäksi on tärkeää tarkistaa Tapahtumienvalvonta "Hakemistopalvelut" ja "DFS-replikointi". Tapahtumat, kuten 467 ja 1018, viittaavat tietokannan todelliseen vioittumiseen., kun taas tapahtumat 1113/1115/1114/1116 liittyvät syötteen/tulosteen replikoinnin ottamiseen käyttöön tai poistamiseen käytöstä.

Jos epäilty DC on eristettävä väliaikaisesti korruption leviämisen estämiseksi, voimme Poista saapuvan ja lähtevän replikoinnin käytöstä Repadminin avulla:

repadmin /options DCNAME +DISABLE_INBOUND_REPL
repadmin /options DCNAME +DISABLE_OUTBOUND_REPL

Ja palauttaaksesi replikaation normaaliksi, poista vain nämä asetukset:

repadmin /options DCNAME -DISABLE_INBOUND_REPL
repadmin /options DCNAME -DISABLE_OUTBOUND_REPL

Tuetut järjestelmän tilan varmuuskopiot toimialueen ohjauskoneissa

Jotta DC voidaan palauttaa takuilla, on välttämätöntä, että Järjestelmän tilan varmuuskopiot, jotka tehdään Active Directory -yhteensopivilla työkaluillaNämä työkalut käyttävät Microsoftin varmuuskopiointi- ja palautus-API-rajapintoja ja Volume Shadow Copy Service (VSS) -palvelua tuetulla tavalla.

Yleisimpiä ratkaisuja ovat mm. Windows Server Backup, VSS:ään integroidut kolmannen osapuolen ratkaisut (kuten NAKIVO, Backup Exec ja muut)tai vanhempia apuohjelmia, kuten Ntbackup Windows 2000/2003:ssa. Kaikissa tapauksissa niiden on noudatettava AD-rajapintoja varmistaakseen tietokannan ja sen kopioiden yhdenmukaisuuden palautuksen jälkeen.

Windows Server 2012:ssa ja uudemmissa versioissa on tärkeä uusi lisäys: Hyper-V-sukupolven tunnus (GenID)Tämän tunnisteen avulla virtuaalinen toimialueen ohjain voi havaita, että sen levy on palautettu edelliseen ajankohtaan. Kun näin tapahtuu, AD DS luo uuden InvocationID:n ja käsittelee tilannetta ikään kuin se olisi palautettu onnistuneesta varmuuskopiosta.ilmoittaen replikointikumppaneilleen, mikä mahdollistaa turvallisen uudelleenkirjoittamisen ilman USN:n peruutusta.

On tärkeää kunnioittaa hautakiven käyttöikäTämä osoittaa, kuinka kauan järjestelmän tilan varmuuskopiota voidaan käyttää ilman, että kauan sitten poistettuja objekteja joudutaan ottamaan uudelleen käyttöön. Nykyaikaisissa versioissa se on tyypillisesti 180 päivää, ja varmuuskopioiden suorittamista suositellaan vähintään 90 päivän välein riittävän turvamarginaalin ylläpitämiseksi.

Luvattomat menetelmät, jotka aiheuttavat USN-palautuksia

Yksi vaarallisimmista Active Directoryn hiljaisten epäjohdonmukaisuuksien syistä on USN-palautusTämä tilanne ilmenee, kun AD-tietokannan sisältö peruutetaan käyttämällä ei-tuettua tekniikkaa ilman, että InvocationID palautetaan tai replikointikumppaneille ilmoitetaan.

Tyypillinen skenaario on käynnistää verkkoohjain levykuva tai aiemmin otettu virtuaalikoneen tilannekuvailman yhteensopivaa järjestelmän palautusta. Tai kopioi Ntds.dit-tiedosto suoraan, käytä levykuvantamisohjelmia, kuten Ghost, käynnistä rikkinäisestä levypeilistä tai ota tallennustilan tilannevedos uudelleen käyttöön taulukkotasolla.

Näissä tapauksissa toimialueen ohjauskone käyttää edelleen samaa InvocationID:tä kuin aiemmin, mutta sen Paikallinen USN-laskuri toimii taaksepäinMuut toimialueen ohjaimet muistavat vastaanottaneensa muutoksia korkeaan USN-numeroon asti, joten kun palautettu toimialueen ohjain yrittää lähettää takaisin jo tunnistetut USN-numerot, Heidän kumppaninsa uskovat olevansa ajan tasalla eivätkä hyväksy konkreettisia muutoksia.

Seurauksena on, että tietyt muutokset (esim. käyttäjän luominen, salasanan vaihdot, laitteen rekisteröinti, ryhmän jäsenyyden muutokset, uudet DNS-tietueetNäitä virheitä ei koskaan replikoida palautetusta toimialueen ohjauskoneesta muualle verkkoon, mutta valvontatyökalut eivät välttämättä näytä selkeitä virheitä. Tämä on erittäin vaarallinen hiljainen vika.

Näiden tilanteiden havaitsemiseksi Windows Server 2003 SP1 ja uudemmat ohjaimet kirjaavat Hakemistopalvelutapahtuma 2095 Kun järjestelmä havaitsee etätoimialueen ohjaimen lähettävän jo kuitattuja USN-tunnuksia ilman muutosta InvocationID:ssä, Se asettaa kyseessä olevan toimialueen ohjaajan karanteeniin, keskeyttää verkkokirjautumisen ja estää lisämuutosten tapahtumisen. jota ei voitu toistaa oikein.

Lisätodisteena rikosteknisenä todisteena se voi tutustuttavaksi rekisterissä avain HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parametrit ja arvo DSA ei ole kirjoitettavissaJos tämä arvo on asetettu (esim. 0x4), se osoittaa, että USN:n peruutustunnistus asetti DC:n ei-kirjoitustilaan. Tämän arvon manuaalinen muokkaaminen sen "korjaamiseksi" on täysin kiellettyä. ja jättää tietokannan pysyvästi epäjohdonmukaiseen tilaan.

Yleiset strategiat toimialueen ohjauskoneen vioittumisen tai palautuksen sattuessa

Vioittuneen tai virheellisesti palautetun toimialueen ohjaajan käsittelymenettely riippuu useista tekijöistä: Verkkotunnuksen/metsän ohjauskoneiden lukumäärä, järjestelmän tilan kelvollisten kopioiden saatavuus, muiden roolien (FSMO, CA, globaali luettelo) olemassaolo ja ongelman ajallinen laajuus.

Jos toimialueella on muita terveitä toimialueen ohjauskoneita ja Vaurioituneella toimialueen ohjauskoneella ei ole yksilöllisiä kriittisiä tietoja.Nopein ja selkein vaihtoehto on yleensä poistaa kyseinen toimialueen ohjain ja rakentaa se uudelleen. Jos se on kuitenkin ainoa toimialueen ohjain tai jos se isännöi arkaluonteisia rooleja ja tietoja, tarvitaan huolellisempi palautus (autoritatiivinen tai ei-autoritatiivinen).

Yleisesti ottaen vaihtoehdot ovat:

• Alenna korruptoitunutta verkkotunnusohjainta väkisin ja poista se verkkotunnuksesta, jota seuraa metatietojen puhdistus ja tarvittaessa uusi ylennys.
• Palautus kelvollisesta järjestelmän tilan varmuuskopiostajoko auktoritatiivisessa tai ei-autoritatiivisessa tilassa.
• Rakenna toimialueen ohjauskone uudelleen toisesta tiedostosta IFM:n (Install From Media) avulla, kun ei ole olemassa tuoretta kopiota, mutta on olemassa muita oikeita domeenikoodeja.
• Virtuaalisen toimialueen ohjaimen VHD-tilannevedoksen käyttäminen, lisäämällä lisävaiheet tietokannan merkitsemiseksi varmuuskopiosta palautetuksi (Varmuuskopiosta palautettu tietokanta = 1) ja varmistamalla, että uusi InvocationID luodaan.

Jos USN-palautusta selvästi epäillään (esimerkiksi virtuaalikoneen palauttamisen jälkeen tilannevedoksesta noudattamatta parhaita käytäntöjä) ja tapahtuma 2095 ilmestyy, järkevin toimintatapa on yleensä Poista kyseinen tasavirtalähde käytöstä äläkä yritä "korjata" sitä paikan päällä., ellei ole mahdollista palauttaa varmuuskopiota tuetusta järjestelmän tilasta, joka oli ennen palautusta.

Pakotettu alentaminen ja metatietojen siivous

Kun toimialueen ohjauskone on niin vaurioitunut, ettei sitä voida alentaa normaalisti tai se on palautettu virheellisesti ja haluat estää sitä leviämästä ongelmista, voit turvautua a:han pakotettu alentaminen.

Vanhemmissa versioissa tämä toiminto suoritettiin ns. dcpromo /forceremoval, mitä Poista AD DS -rooli yrittämättä replikoida muutoksia muuhun metsään.Nykyaikaisissa ympäristöissä ohjattu toiminto on muuttunut, mutta konsepti on sama: poistaa ongelmallinen toimialueen ohjain AD-topologiasta ilman, että se osallistuu jatkoreplikointiin.

Pakotetun alennuksen jälkeen komento on suoritettava toimivasta toimialueen ohjaimesta. metatietojen puhdistus työkalun avulla NtdsutilTämä prosessi poistaa kaikki viittaukset poistettuun toimialueen ohjaimeen (NTDS-asetusobjektit, DNS-viittaukset jne.) AD-tietokannasta, jotta ei ole jäljellä "haamu"jäänteitä, jotka hämmentäisivät replikaatiota.

Jos heikentyneellä ohjaimella oli FSMO-rooleja (PDC-emulaattori, RID-pääkäyttäjä, kaavapääkäyttäjä jne.), on tarpeen siirtää tai ottaa nuo roolit haltuunsa toiseen toimialueen ohjaimeen ennen alentamista tai sen jälkeen tilanteesta riippuen. Myöhemmin käyttöjärjestelmä voidaan asentaa uudelleen kyseiselle palvelimelle ja se voidaan ylentää takaisin puhtaaksi toimialueen ohjaimeksi.

Ei-autoritatiivinen vs. autoritatiivinen palautus Active Directoryssa

Kun järjestelmän tilasta on saatavilla kelvollinen kopio, AD-palautus voidaan tehdä kahdella tavalla: ei-auktoriteettinen ja arvovaltainenEron ymmärtäminen on avainasemassa, jotta viimeaikaiset muutokset eivät jää huomaamatta tai vanhentunutta dataa ei kopioida.

Eräässä ei-auktoriteettinen restaurointiDC palautetaan edelliseen pisteeseen, mutta kun se alkaa, Muita toimialueen ohjaimia pidetään viitteinäToisin sanoen käynnistyksen jälkeen palautettu toimialueen ohjain pyytää saapuvaa replikointia ja päivittää tietokantaansa muiden toimialueen ohjainten puuttuvilla muutoksilla. Tämä vaihtoehto on ihanteellinen, kun On muitakin terveitä ohjaajia, ja haluamme palautetun saavuttavan heidät..

Eräässä autoritaarinen restauraatioSiinä kuitenkin nimenomaisesti sanotaan, että Palautettujen tietojen pitäisi olla voimassa. muiden toimialueen ohjainten versionumeroiden yläpuolelle. Tämä tarkoittaa, että palautuksen jälkeen palautetuilla objekteilla on suurempi versionumero, joka pakottaa ne replikoitumaan kyseisestä toimialueen ohjaimesta muualle toimialueelle. Se on sopiva valinta, kun Olemme vahingossa poistaneet objekteja tai organisaatioyksiköitä tai haluamme palauttaa SYSVOL- ja GPO-objektien sisällön edelliseen tilaan ja replikoida ne..

Tärkeä yksityiskohta on, että auktoritatiivisen palautuksen ei välttämättä tarvitse koskea koko tietokantaa. Apuohjelman avulla Ntdsutil Yksittäisiä objekteja, alipuita (esim. OU) tai koko verkkotunnus voidaan merkitä määräysvaltaisiksi. Tämä tarjoaa huomattavaa joustavuutta esimerkiksi seuraaville: nouda vain käyttäjä, ryhmä, OU tai alipuu dc=mycompany,dc=local.

Yleinen menettely järjestelmän tilan palauttamiseksi toimialueen ohjauskonsolissa

Yhteensopivilla työkaluilla toimivan DC:n (olipa se sitten fyysinen tai virtuaalinen) järjestelmätilan palauttamisen perusperiaate on aina samanlainen: Käynnistä hakemistopalveluiden palautustilassa (DSRM), palauta järjestelmä varmuuskopiointityökalulla ja käynnistä se uudelleen..

Yhteenvetona voidaan todeta, että virtuaalisen verkkotunnuksen ohjaimen tyypilliset vaiheet olisivat seuraavat:

1. Käynnistä virtuaalikone Windowsin käynnistyksenhallinnassa (yleensä painamalla F5/F8 käynnistyksen aikana). Jos virtuaalikoneen toimintaa hallinnoi hypervisor, koneen pysäyttäminen näppäinpainalluksen tallentamiseksi voi olla tarpeen.
2. Valitse käynnistyksen lisäasetuksista Hakemistopalveluiden palautustila (Hakemistopalveluiden palautustila). Tämä tila käynnistää palvelimen liittämättä Active Directory -tietokantaa toiminnallisella tavalla.
3. Kirjaudu sisään DSRM-järjestelmänvalvojan tilillä määritelty toimialueen ohjaimen alkuperäisen kampanjan aikana (ei tavallisella toimialueen järjestelmänvalvojan tilillä).
4. Suorita varmuuskopiointityökalu käytetty (Windows Server Backup, NAKIVO tai muu yhteensopiva) ja valitse järjestelmän tilan palauttaminen haluttuun varmuuskopiointipisteeseen.
5. Suorita palautusavustaja loppuun ja Käynnistä DC uudelleen normaalitilassaEi-autenttisessa palautuksessa palvelin aloittaa replikoinnin saavuttaakseen muut toimialueen ohjaimet.

Kun puhumme kolmannen osapuolen varmuuskopiointituotteista, kuten NAKIVO Varmuuskopiointi ja replikointiSen "sovellustietoinen" tila pystyy tunnistamaan, että palautettava kone on toimialueen ohjain ja säätää prosessia automaattisesti AD-yhtenäisyyden säilyttämiseksiUseimmissa tilanteissa, joissa on useita ohjaimia, täydellinen palautus ei-autoritatiivisessa tilassa riittää.

Auktoritatiivinen palautus Ntdsutil-työkalulla

Jos haluat palautetun toimialueen ohjauskoneen muutosten olevan etusijalla muihin nähden, sinun on lisättävä ylimääräinen vaihe ei-auktoritatiivisen palautuksen jälkeen: Käytä Ntdsutil-komentoa objektien merkitsemiseen määräysvaltaisiksi.

Yksinkertaistettu työnkulku olisi:

1. Palauta järjestelmän tila normaalilla tavalla ja jätä palvelin edelleen päälle DSRM-tila (Älä vielä käynnistä uudelleen normaalitilassa).
2. Avaa a komentokehote laajennetuilla oikeuksilla ja juokse ntdsutil.
3. Aktivoi AD-instanssi komennolla aktivoi instanssi ntds.
4. Auktoritatiivisen restauroinnin kontekstiin siirtyminen auktoriteettipalautus.
5. Käytä komentoja, kuten restore object <DN_objeto> o restore subtree <DN_subarbol>, jossa DN on auktoritatiivisesti palautettavan objektin tai alipuun erottuva nimi.
6. Vahvista tapahtuma ja kun se on valmis, Käynnistä DC uudelleen normaalitilassa niin, että merkityt objektit replikoidaan prioriteetilla muuhun verkkotunnukseen nähden.

Tämän tyyppinen restaurointi vaatii suurta varovaisuutta. Jos koko verkkotunnus on palautettu auktoriteettiperiaatteella ja varmuuskopio on vanhaVarmuuskopioinnin jälkeen tehdyt lailliset muutokset (esimerkiksi käyttäjien luominen, salasanan vaihdot tai ryhmän muutokset) voivat kadota. Siksi on yleistä käytäntöä rajoittaa auktoritatiiviset palautukset vain ehdottoman välttämättömiin objekteihin tai puihin.

SYSVOL-palautus ja -palautus (FRS vs. DFSR)

SYSVOL on toimialueen ohjauskoneen keskeinen osa: Se tallentaa käynnistysskriptejä, ryhmäkäytäntöjä, suojausmalleja ja muita tärkeitä jaettuja resursseja.Käyttöoikeusongelmien, tiedostojen vioittumisen tai replikointiongelmien vuoksi ryhmäkäytäntöobjektit voivat muuttua käyttökelvottomiksi tai aiheuttaa virheellistä toimintaa asiakasohjelmissa.

Windows Server -versiosta ja siirron tilasta riippuen SYSVOL-tiedoston voi replikoida FRS (tiedostojen replikointipalvelu) miksi DFSR (hajautetun tiedostojärjestelmän replikointi)SYSVOL-varauskannan auktoritatiivisen palautuksen menettely vaihtelee sen mukaan, kumpaa näistä kahdesta käytetään.

Voit selvittää tämän tarkistamalla avaimen rekisteristä. HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DFSR\Parameters\SysVols\Sysvols-tiedostojen siirtäminen\LocalStateJos tämä aliavain on olemassa ja sen arvo on 3 (POISTETTU), DFSR:ää käytetään. Jos sitä ei ole tai sen arvo on eri, kyseessä on ympäristö, joka käyttää edelleen FRS:ää.

FRS-ympäristöissä SYSVOL-arvon määräävä palautus edellyttää yleensä arvon säätämistä Burflagsit en HKLM\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process tiettyyn arvoon (esim. 212 desimaali / 0xD4 heksadesimaali) osoittamaan, että tämä DC on auktoriteettilähde.

Jos SYSVOL replikoidaan DFSR:llä, prosessi on jonkin verran monimutkaisempi: siinä käytetään ADSIEdit muokata SYSVOL-tilausobjekteja (attribuutteja msDFSR-käytössä y msDFSR-asetukset) pakota AD-replikaatio autoritaarisessa DC:ssä ja muissa, suorita dfsrdiag pollad ja vahvista tapahtumalokissa merkinnän esiintyminen tapahtumat 4114, 4602, 4614 ja 4604 jotka varmistavat, että SYSVOL on alustettu ja replikoitu oikein.

Virtuaalisten toimialueen ohjainten palauttaminen VHD:ltä

Virtualisoiduissa ympäristöissä on hyvin yleistä, että Verkkotunnusohjainten VHD/VHDX-tiedostotJos sinulla ei ole järjestelmän tilan varmuuskopiota, mutta sinulla on toimiva "vanha" virtuaalilevy, voit liittää uuden toimialueen ohjaimen kyseiseltä levyltä, mutta sinun on tehtävä se erittäin varovasti, jotta vältät USN:n peruutuksen.

Suositus on Älä käynnistä kyseistä virtuaalikonetta suoraan normaalitilassaSen sijaan sinun pitäisi käynnistää se edelliseltä VHD:ltä DSRMAvaa rekisterieditori ja siirry kohtaan HKLM\SYSTEM\CurrentControlSet\Services\NTDS\ParametersSiellä on suositeltavaa tarkistaa arvo Aiempien DSA-palautusten määrä (jos sellainen on olemassa) ja ennen kaikkea luo uusi DWORD-arvo (32-bittinen) nimeltä Tietokanta palautettu varmuuskopiosta arvolla 1.

Valitsemalla tämän arvon Active Directorylle ilmoitetaan, että tietokanta on palautettu varmuuskopiosta, mikä pakottaa uuden InvocationID:n luominen normaalitilassa käynnistettäessäTällä tavoin muut toimialueen ohjaimet tulkitsevat sen uutena instanssina ja säätävät replikointivesileimojaan oikein, estäen USN:n peruutuksen.

Kun olet käynnistänyt verkkoohjaimen uudelleen normaalitilassa, on suositeltavaa tarkistaa Tapahtumienvalvonta, erityisesti tapahtumien loki. Hakemistopalvelut, etsimässä tapahtuma 1109Tämä tapahtuma vahvistaa, että palvelimen InvocationID-attribuutti on muuttunut, ja näyttää vanhat ja uudet arvot sekä varmuuskopioinnin aikaan voimassa olleen korkeimman USN-tunnuksen. Lisäksi arvo Aiempien DSA-palautusten määrä Sitä olisi pitänyt korottaa yhdellä.

Jos näitä tapahtumia ei tule näkyviin tai niiden määrä ei kasva, sinun tulee tarkistaa käyttöjärjestelmän versiot ja Service Pack -päivitykset, koska Tietyt palautustoiminnot riippuvat tietyistä korjaustiedostoistaJoka tapauksessa on aina suositeltavaa työskennellä alkuperäisen VHD:n kopion parissa ja säilyttää ehjä versio siltä varalta, että prosessi on toistettava.

Käytännön skenaarioita ja lisäsuosituksia

Käytännössä korruptioon tai virheellisiin restaurointeihin liittyviä ongelmia esiintyy usein arkipäivän tilanteissa: SYSVOL-käyttöoikeuksien manuaaliset muutokset, yritykset päivittää ADMX/ADML-malleja, ryhmäkäytäntöjen muutokset, joita ei replikoidajne. On suhteellisen helppo aiheuttaa epäjohdonmukaisuuksia, jos jaettuja kansioita muokataan manuaalisesti, kuten SYSVOL\Policies replikaatiota kunnioittamatta.

Jos ensisijaisen toimialueen ohjaimen replikointi (sekä AD-tiedot että SYSVOL) on rikki ja valvontaviestejä on tyyppiä "Tietokanta palautettiin ei-tuetulla menetelmällä. Mahdollinen syy: USN-palautus", viisasta on tehdä seuraavaa:

• Tarkista dcdiag y repadmin virheiden laajuus ja onko olemassa ”pysyviä objekteja”.
• Tarkista tapahtuma 2095 ja sen arvo DSA ei ole kirjoitettavissa rekisterissä.
• Arvioi, onko mahdollista poista tuo DC ja rakenna se uudelleen (Jos muita terveitä DC:itä on kolme tai useampia, tämä on yleensä paras vaihtoehto).
• Jos se on ainoa DC tai kriitikko, nosta järjestelmän tilan palautus yhteensopivasta varmuuskopiosta, mieluiten tuoreesta ja tombstone-jakson sisällä olevasta.

Useita ohjaimia sisältävissä verkkotunnuksissa on erittäin suositeltavaa, että verkkotunnukset ovat mahdollisimman "puhtaita": ilman lisärooleja tai paikallisia käyttäjätietojaTällä tavoin, jos yksi vikaantuu tai vioittuu, uusi voidaan muotoilla ja siirtää toisen toimialueen ohjaimen perusteella tai IFM:n kautta, mikä vähentää huomattavasti palautuksen monimutkaisuutta.

Lisäksi on hyvä muistaa rajoitukset, kuten Järjestelmän tilakopiot ovat voimassa vain hautakivikauden aikana (60, 90, 180 päivää kokoonpanosta riippuen) poistettujen objektien elvyttämisen välttämiseksi ja että NTLM-koneavaimet vaihtuvat 7 päivän välein. Hyvin vanhoissa palautuksissa voi olla tarpeen nollaa joukkueen tilit ongelmia "Active Directory -käyttäjät ja tietokoneet" -kansiosta tai jopa niiden poistamista ja liittämistä takaisin toimialueeseen.

Järjestelmän tilan säännöllistä varmuuskopiointia varten on käytössä menettelytavat, Dokumentoi selkeästi FSMO-roolit, globaalin luettelon ja replikointitopologianJa palautusvaiheiden testaaminen laboratorioympäristössä on ajallista investointia, joka säästää paljon päänvaivaa, kun toimialueen ohjauskone vioittuu tai joku ottaa tilannevedoksen ajattelematta.