Sérült helyi tartományvezérlő visszaállítása és helyreállítása

Amikor egy tartományvezérlő megsérül vagy helytelenül állítják vissza, az óriási rémületet okoz: A bejelentkezések sikertelenek, a csoportházirend-objektumok alkalmazása leáll, és a replikáció szinte semmilyen nyom nélkül leáll.A jó hír az, hogy egyértelmű eljárások léteznek egy fizikai vagy virtuális tartományvezérlő helyreállítására, feltéve, hogy az elfogadott biztonsági mentési és visszaállítási módszereket betartják.

A modern Windows Server környezetekben egy tartományvezérlő visszaállításához olyan fogalmak alapos ismerete szükséges, mint például rendszerállapot, mérvadó/nem mérvadó visszaállítás, SYSVOL, DFSR/FRS és USN visszagörgetésekHa ezeket a problémákat elhamarkodottan vagy inkompatibilis képalkotó eszközökkel kezelik, az eredmény egy olyan erdő lehet, amely tele van csendes inkonzisztenciákkal, amelyeket nagyon nehéz diagnosztizálni.

Miért fontos a tartományvezérlő megfelelő védelme és helyreállítása?

Az Active Directory a hitelesítés és az engedélyezés lelke egy Windows-tartományban.Felhasználókat, számítógépeket, csoportokat, bizalmi kapcsolatokat, csoportházirendeket, tanúsítványokat és más kritikus elemeket tárol. Ezek az információk elsősorban az adatbázisban találhatók. Ntds.dit, a kapcsolódó naplófájlok és mappa SYSVOL, többek között az úgynevezett „rendszerállapotot” alkotó összetevők között.

A rendszer állapota többek között a következőket tartalmazza: Az Active Directory naplófájljai és adatai, a Windows rendszerleíró adatbázisa, a rendszerkötet, a SYSVOL, a tanúsítványadatbázis (ha létezik hitelesítésszolgáltató), az IIS metabázisa, a rendszerindító fájlok és a védett operációs rendszerösszetevőkEzért minden komoly üzletmenet-folytonossági stratégiának tartalmaznia kell az egyes adatközpontok rendszerállapotának rendszeres biztonsági mentését.

Amikor az Active Directory adatbázis tényleges sérülése, súlyos replikációs hiba vagy a rendszerrel kapcsolatos probléma merül fel engedélyek bekapcsolva SYSVOLA tartományvezérlő leállíthatja a lekérdezések feldolgozását, nem indíthatja el az Active Directory szolgáltatásokat, vagy kaszkádos hibákat okozhat az erdőben. Ezekben az esetekben A gyors és megfelelő helyreállítás jelenti a különbséget egy súlyos baleset és egy elhúzódó katasztrófa között..

A visszaállítás megkísérlése előtt kulcsfontosságú különbséget tenni a valódi adatbázis-problémák és a hétköznapibb hibák között. Nagyon gyakran Az ok a DNS-ben, a hálózati változásokban, a tűzfalakban vagy az olyan eszközökkel módosított útvonalakban rejlik, mint például netsh parancsEzért tanácsos ezeket a tényezőket kizárni, mielőtt az AD adatbázishoz érnénk.

Alapvető diagnosztikai és replikációvezérlő eszközök

Sérülés vagy replikációs hibák tünetei esetén az első ésszerű lépés a környezet állapotának ellenőrzése natív eszközök használatával. DCDiag, Repadmin, ReplMon (régebbi verziókban) és az Eseménynapló Ők a legjobb szövetségeseid, mielőtt agresszív restaurációkban gondolkodnál.

Con DCDiag A rendszer általános ellenőrzést végez az összes tartományvezérlőn, azonosítva a replikációval, a DNS-sel, az AD DS szolgáltatásokkal stb. kapcsolatos problémákat. Repadmin Lehetővé teszi a replikációs állapot, a replikációs partnerek, az USN vízjelek megtekintését és az állandó objektumok észlelését. A Windows régebbi verzióiban ReplMon Grafikus nézetet kínált a domainen belüli replikációs hibákról.

Ezen eszközök mellett elengedhetetlen az Eseménynapló „Címtárszolgáltatások” és „DFS-replikáció” funkciójának áttekintése is. Az olyan események, mint a 467 és a 1018, az adatbázis tényleges sérülésére utalnak., míg a 1113/1115/1114/1116 események a bemeneti/kimeneti replikáció engedélyezésére vagy letiltására vonatkoznak.

Ha egy gyanús DC-t ideiglenesen el kell különíteni a korrupció terjedésének megakadályozása érdekében, akkor megtehetjük Bejövő és kimenő replikáció letiltása a Repadmin segítségével:

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

A replikáció normál állapotba való visszaállításához egyszerűen távolítsa el ezeket a beállításokat:

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

Támogatott rendszerállapot-mentések tartományvezérlőkön

Ahhoz, hogy garanciákkal vissza lehessen állítani egy DC-t, elengedhetetlen, hogy rendelkezzen a következőkkel: Active Directory-kompatibilis eszközökkel végzett rendszerállapot-mentésekEzek az eszközök a Microsoft biztonsági mentési és visszaállítási API-jait és a Volume Shadow Copy szolgáltatást (VSS) használják támogatott módon.

A leggyakoribb megoldások közé tartozik Windows Server Backup, harmadik féltől származó, VSS-sel integrált megoldások (például NAKIVO, Backup Exec és mások)vagy régebbi segédprogramok, mint például Ntbackup Windows 2000/2003 rendszerben. Minden esetben tiszteletben kell tartaniuk az AD API-kat az adatbázis és replikáinak konzisztenciájának biztosítása érdekében a visszaállítás után.

A Windows Server 2012 és a későbbi verziók egy fontos új kiegészítést tartalmaznak: Hyper-V generációs azonosító (GenID)Ez az azonosító lehetővé teszi a virtuális tartományvezérlő számára annak észlelését, hogy a lemezét egy korábbi időpontra visszagörgették. Amikor ez megtörténik, Az AD DS új InvocationID-t generál, és úgy kezeli a helyzetet, mintha egy sikeres biztonsági mentésből lett volna visszaállítva.értesíti a replikációs partnereit, így lehetővé téve a biztonságos átírást USN visszagörgetés nélkül.

Lényeges tiszteletben tartani a sírkő élettartamaEz azt jelzi, hogy egy rendszerállapot-mentés mennyi ideig használható anélkül, hogy fennállna a régen törölt objektumok újbóli bevezetésének kockázata. A modern verziókban ez jellemzően 180 nap, és a megfelelő biztonsági tartalék fenntartása érdekében ajánlott legalább 90 naponta biztonsági mentést végezni.

Nem engedélyezett módszerek, amelyek USN visszafordításokat okoznak

Az Active Directory csendes inkonzisztenciáinak egyik legveszélyesebb oka a USN visszagörgetésEz a helyzet akkor fordul elő, ha az AD adatbázis tartalmát nem támogatott technikával görgetik vissza anélkül, hogy az InvocationID visszaállna, vagy a replikációs partnerek értesítésre kerülnének.

Tipikus forgatókönyv egy DC indítása egy lemezkép vagy egy korábban készített virtuális gép pillanatképkompatibilis rendszer-visszaállítás használata nélkül. Vagy másolja át közvetlenül az Ntds.dit fájlt, használjon képalkotó programokat, például a Ghostot, indítson el egy hibás lemeztükörről, vagy alkalmazzon újra egy tárolási pillanatképet tömbszinten.

Ezekben az esetekben a tartományvezérlő továbbra is ugyanazt az InvocationID-t használja, mint korábban, de a A helyi USN számláló visszafelé működik.A többi tartományvezérlő megjegyzi a változások fogadását egy magas USN-ig, így amikor a visszaállított tartományvezérlő megpróbálja visszaküldeni a már felismert USN-eket, Partnereik úgy hiszik, hogy naprakészek, és nem fogadják el a konkrét változásokat..

Ennek eredményeként bizonyos módosítások (pl. felhasználó létrehozása, jelszómódosítás, eszközregisztráció, csoporttagság módosítása, új DNS-rekordokEzek a hibák soha nem kerülnek replikációra a visszaállított tartományvezérlőről a hálózat többi részére, de a monitorozó eszközök nem feltétlenül mutatnak egyértelmű hibákat. Ez egy rendkívül veszélyes csendes hiba.

Az ilyen helyzetek észlelése érdekében a Windows Server 2003 SP1 és újabb illesztőprogramok naplózzák a Címtárszolgáltatások eseménye 2095 Amikor a rendszer észleli, hogy egy távoli tartományvezérlő már nyugtázott USN-eket küld az InvocationID módosítása nélkül, a rendszer Karanténba helyezi az érintett tartományvezérlőt, szünetelteti a hálózati bejelentkezést, és megakadályozza a további módosítások bekövetkezését. amit nem lehetett helyesen reprodukálni.

További igazságügyi bizonyítékként lehet a Nyilvántartásban megtekinthető a kulcs HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Paraméterek és az érték DSA nem írhatóHa ez az érték be van állítva (pl. 0x4), az azt jelzi, hogy a DC-t az USN megfordulásészlelés nem írási állapotba helyezte. A hiba manuális módosítása a hiba „javítása” érdekében teljesen nem támogatott. és az adatbázist véglegesen inkonzisztens állapotba hozza.

Általános stratégiák tartományvezérlő sérülése vagy visszaállítása esetén

A sérült vagy helytelenül visszaállított tartományvezérlő kezelésekor követendő eljárás számos tényezőtől függ: A tartományvezérlők száma a tartományban/erdőben, a rendszerállapot érvényes másolatainak elérhetősége, más szerepkörök (FSMO, CA, globális katalógus) jelenléte és a probléma időbeli hatóköre.

Ha vannak más egészséges tartományvezérlők a tartományban, és Nincsenek egyedi, kritikus adatok a sérült tartományvezérlőn.A leggyorsabb és legtisztább megoldás általában a tartományvezérlő eltávolítása és újraépítése. Ha azonban ez az egyetlen tartományvezérlő, vagy ha bizalmas szerepköröket és adatokat tárol, akkor körültekintőbb visszaállításra (mérdeklő vagy nem mérvadó) lesz szükség.

Általánosságban elmondható, hogy a lehetőségek a következők:

• Erőszakkal lefokozzuk a korrupt DC-t és eltávolítjuk a domainről., majd metaadatok tisztítása és szükség esetén új előléptetés.
• Visszaállítás érvényes rendszerállapot-mentésből, akár mérvadó, akár nem mérvadó módban.
• DC újraépítése egy másikból IFM (Telepítés adathordozóról) használatával, amikor nincs újabb példány, de vannak más helyes DC-k.
• Virtuális tartományvezérlő VHD pillanatképének használata, a további lépések alkalmazásával jelölje meg az adatbázist biztonsági mentésből visszaállítottként (Biztonsági mentésből visszaállított adatbázis = 1), és gondoskodjon egy új InvocationID létrehozásáról.

Ha egyértelműen felmerül az USN visszagörgetésének gyanúja (például egy virtuális gép pillanatképből történő visszaállítása után a legjobb gyakorlatok betartása nélkül), és megjelenik a 2095-ös esemény, a legésszerűbb megoldás általában a következő: Kapcsolja ki a forgalomból az egyenáramú tápegységet, és ne próbálja meg a helyszínen „megjavítani”., kivéve, ha lehetséges a támogatott rendszerállapotnak a visszaállítás előtti biztonsági másolatára visszaállítani.

Kényszerített lefokozás és metaadatok tisztítása

Ha egy tartományvezérlő annyira sérült, hogy nem lehet normál módon lefokozni, vagy helytelenül lett visszaállítva, és meg szeretné akadályozni a problémák terjedését, akkor a következőhöz folyamodhat: kényszerített lefokozás.

A régebbi verziókban ezt a műveletet a következővel végezték el: dcpromo /forceremoval, mit Távolítsa el az AD DS szerepkört anélkül, hogy megpróbálná replikálni a módosításokat az erdő többi részébe.A modern környezetekben a varázsló megváltozott, de a koncepció ugyanaz: a problémás tartományvezérlő eltávolítása az AD topológiából anélkül, hogy az részt venne a további replikációban.

Kényszerített visszalépés után kötelező parancsot végrehajtani egy egészséges tartományvezérlőről. metaadatok tisztítása az eszköz használatával NtdsutilEz a folyamat eltávolítja az AD adatbázisból a törölt tartományvezérlőre mutató összes hivatkozást (NTDS-beállítások objektumok, DNS-hivatkozások stb.), így nincsenek "szellem" maradványok, amelyek megzavarnák a replikációt.

Ha a leromlott teljesítményű vezérlő FSMO szerepkörökkel rendelkezett (PDC emulátor, RID Master, Schema Master stb.), akkor szükséges lesz a átruházza vagy elveszi ezeket a szerepeket egy másik tartományvezérlőre a lefokozás előtt vagy után, a helyzettől függően. Később az operációs rendszer újratelepíthető az adott szerveren, és visszaléptethető egy tiszta tartományvezérlővé.

Nem mérvadó vs. mérvadó visszaállítás az Active Directoryban

Amikor elérhető a rendszerállapot érvényes másolata, az AD helyreállítás kétféleképpen történhet: nem tekintélyes és tekintélyesA különbség megértése kulcsfontosságú ahhoz, hogy ne maradjunk le a legutóbbi módosításokról, és ne replikáljuk az elavult adatokat.

Az egyik nem hiteles helyreállításA DC visszatér egy korábbi pontra, de ha egyszer elindul, A többi tartományvezérlőt referenciának tekintjük.Más szóval, az indítás után a visszaállított tartományvezérlő bejövő replikációt kér, és frissíti az adatbázisát a többi tartományvezérlő hiányzó módosításaival. Ez a beállítás ideális, ha Vannak más egészséges irányítók is, és azt szeretnénk, ha a helyreállított utolérné őket..

Az egyik tekintélyelvű restaurációAzonban kifejezetten kimondják, hogy A visszaállított adatoknak kell érvényesülniük. a többi tartományvezérlőhöz képest. Ez azt jelenti, hogy a visszaállítás után a helyreállított objektumok magasabb verziószámmal rendelkeznek, hogy kényszerítve legyenek replikálva az adott tartományvezérlőből a tartomány többi részébe. Ez a megfelelő választás, ha Véletlenül töröltünk objektumokat vagy szervezeti egységeket, vagy vissza szeretnénk állítani a SYSVOL és a csoportházirend-objektum tartalmát egy korábbi állapotba, és replikálni szeretnénk azokat..

Fontos részlet, hogy a hiteles visszaállításnak nem feltétlenül kell a teljes adatbázisra vonatkoznia. A segédprogrammal Ntdsutil Egyedi objektumok, részfák (pl. egy szervezeti egység) vagy a teljes tartomány is megjelölhető mérvadóként. Ez jelentős rugalmasságot kínál például a következők esetében: csak egy felhasználót, egy csoportot, egy szervezeti egységet vagy a dc=mycompany,dc=local részfát kér le.

Általános eljárás a rendszer állapotának visszaállítására egy tartományvezérlőben

A DC (akár fizikai, akár virtuális) rendszerállapotának kompatibilis eszközökkel történő visszaállításának alapvető sémája mindig hasonló: Indítsa el a rendszert a Címtárszolgáltatások visszaállítási módjában (DSRM), állítsa vissza a rendszert a biztonsági mentési eszközzel, majd indítsa újra a rendszert.

Összefoglalva, egy virtuális tartományvezérlő tipikus lépései a következők lennének:

1. Indítsa el a virtuális gépet a Windows Boot Managerben (általában az F5/F8 billentyű lenyomásával történik indítás közben). Ha a virtuális gépet egy hipervizor felügyeli, akkor szükség lehet a gép szüneteltetésére a billentyűleütés rögzítéséhez.
2. A speciális rendszerindítási beállításokban válassza a Címtárszolgáltatások visszaállítási módja (Címtárszolgáltatások visszaállítási módja). Ez a mód az Active Directory adatbázis funkcionális csatlakoztatása nélkül indítja el a kiszolgálót.
3. Jelentkezzen be a DSRM rendszergazdai fiókjával a tartományvezérlő eredeti promóciója során lett meghatározva (nem szabványos tartományi rendszergazdai fiókkal).
4. Futtassa a biztonsági mentés eszközt használt (Windows Server Backup, NAKIVO vagy más kompatibilis) programot, és válassza a rendszerállapot visszaállítását a kívánt biztonsági mentési pontra.
5. Fejezze be a visszaállítási varázslót, és Indítsa újra a DC-t normál módbanNem mérvadó visszaállítás esetén a szerver replikációt kezdeményez, hogy utolérje a többi tartományvezérlőt.

Amikor harmadik féltől származó biztonsági mentési termékekről beszélünk, mint például NAKIVO biztonsági mentés és replikációAz „alkalmazás-érzékeny” módja képes felismerni, hogy a helyreállítandó gép egy tartományvezérlő, és automatikusan módosítja a folyamatot az AD konzisztenciájának megőrzése érdekébenA legtöbb esetben, ha több vezérlő van, elegendő a teljes helyreállítás nem mérvadó módban.

Hiteles visszaállítás az Ntdsutil segítségével

Ha azt szeretné, hogy a visszaállított tartományvezérlőn végrehajtott módosítások elsőbbséget élvezzenek a többivel szemben, akkor a nem mérvadó visszaállítás után egy további lépést kell hozzáadnia: Az Ntdsutil használatával jelölje meg az objektumokat mérvadóként.

Az egyszerűsített folyamat a következő lenne:

1. Állítsa vissza a rendszer állapotát a szokásos módon, és hagyja a szervert bekapcsolva DSRM mód (Még ne indítsa újra normál módban).
2. Nyissa meg a parancssor emelt jogosultságokkal és futni ntdsutil.
3. Aktiválja az AD-példányt a következővel: aktiválja a példány ntds-jét.
4. Belépés az autoriter restauráció kontextusába mérvadó visszaállítás.
5. Használj parancsokat, mint pl restore object <DN_objeto> o restore subtree <DN_subarbol>, ahol a DN a mérvadó módon visszaállítandó objektum vagy részfa megkülönböztető neve.
6. Erősítse meg a tranzakciót, és miután az befejeződött, Indítsa újra a DC-t normál módban hogy a megjelölt objektumok prioritással replikálódjanak a tartomány többi részéhez képest.

Az ilyen típusú felújítás nagy körültekintést igényel. Ha a teljes domain hitelesítő módon vissza van állítva, és a biztonsági mentés régiFennáll a biztonsági mentés után végrehajtott jogos módosítások (például felhasználók létrehozása, jelszómódosítások vagy csoportok módosítása) elvesztésének kockázata. Ezért bevett gyakorlat, hogy a mérvadó visszaállításokat csak a feltétlenül szükséges objektumokra vagy fákra korlátozzák.

SYSVOL visszaállítás és helyreállítás (FRS vs. DFSR)

A SYSVOL a tartományvezérlő kulcsfontosságú összetevője: Indítási szkripteket, csoportházirendeket, biztonsági sablonokat és más alapvető megosztott erőforrásokat tárol.Az engedélyek hibája, a fájlok sérülése vagy a replikációs problémák használhatatlanná tehetik a csoportházirend-objektumokat, vagy kiszámíthatatlan viselkedést okozhatnak az ügyfeleknél.

A Windows Server verziójától és a migrálás állapotától függően a SYSVOL replikációját a következő végezheti el: FRS (fájlreplikációs szolgáltatás) miért DFSR (elosztott fájlrendszer-replikáció)A SYSVOL hiteles visszaállításának eljárása attól függ, hogy melyiket használják a kettő közül.

Ennek megállapításához ellenőrizheti a kulcsot a beállításjegyzékben. HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DFSR\Parameters\SysVols\Sysvols migrálása\LocalStateHa ez az alkulcs létezik és az értéke 3 (TÖRÖLT), akkor a DFSR használatban van. Ha nem létezik, vagy az értéke eltér, akkor egy olyan környezettel van dolgunk, amely továbbra is FRS-t használ.

FRS-t használó környezetekben a SYSVOL hiteles helyreállítása általában az érték módosítását jelenti. Burflags en HKLM\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process egy adott értékre (pl. 212 decimális / 0xD4 hex) annak jelzésére, hogy ez a DC a mérvadó forrás.

Ha a SYSVOL-t DFSR replikálja, a folyamat némileg bonyolultabb: a következő használatát foglalja magában: ADSIE Szerkesztés a SYSVOL előfizetési objektumok (attribútumok) módosításához msDFSR-Engedélyezve y msDFSR-beállítások) a mérvadó tartományvezérlőn és a többieken kényszerítse az AD replikációt, hajtsa végre dfsrdiag pollad és erősítse meg az eseménynaplóban a megjelenését 4114, 4602, 4614 és 4604 események amelyek igazolják, hogy a SYSVOL inicializálása és replikálása helyesen történt.

Virtuális tartományvezérlők helyreállítása VHD-ről

Virtualizált környezetekben nagyon gyakori, hogy Tartományvezérlők VHD/VHDX fájljaiHa nincs rendszerállapot-mentésed, de van egy működő „régi” virtuális merevlemezed, akkor csatlakoztathatsz egy új tartományvezérlőt erről a lemezről, bár ezt nagyon óvatosan kell tenned, hogy elkerüld az USN visszagörgetését.

Az ajánlás az Ne indítsa el a virtuális gépet közvetlenül normál módbanEhelyett az előző VHD-ről kell indítania a következőben: DSRMNyissa meg a Beállításszerkesztőt, és navigáljon a következőhöz: HKLM\SYSTEM\CurrentControlSet\Services\NTDS\ParametersOtt érdemes ellenőrizni az értéket Korábbi DSA-visszaállítások száma (ha létezik), és mindenekelőtt hozzon létre egy új DWORD (32 bites) értéket, amelynek neve Adatbázis visszaállítva a biztonsági mentésből 1-ös értékkel.

Ennek az értéknek a kiválasztásával az Active Directory azt a jelzést kapja, hogy az adatbázis biztonsági mentésből lett visszaállítva, ami kikényszeríti a új InvocationID generálása normál módban történő indításkorIly módon a többi tartományvezérlő új példányként értelmezi, és helyesen módosítja a replikációs vízjeleket, megakadályozva az USN visszagörgetését.

A DC normál módban történő újraindítása után ajánlott ellenőrizni az Eseménynaplót, különösen a naplót. Címtárszolgáltatások, keresem a rendezvény 1109Ez az esemény megerősíti, hogy a szerver InvocationID attribútuma megváltozott, és megjeleníti a régi és az új értékeket, valamint a biztonsági mentés időpontjában érvényes legmagasabb USN-t. Ezenkívül a következő érték is megjelenik: Korábbi DSA-visszaállítások száma Egyel kellett volna növelni.

Ha ezek az események nem jelennek meg, vagy a számláló nem növekszik, ellenőrizze az operációs rendszer verzióit és a szervizcsomagokat, mivel Bizonyos helyreállítási viselkedések adott javításoktól függenekMindenesetre mindig ajánlott az eredeti VHD egy másolatán dolgozni, és egy ép verziót megőrizni arra az esetre, ha a folyamatot meg kell ismételni.

Gyakorlati forgatókönyvek és további ajánlások

A gyakorlatban a korrupció vagy a nem megfelelő restaurálás problémái gyakran jelennek meg a mindennapi helyzetekben: A SYSVOL jogosultságainak manuális módosítása, az ADMX/ADML sablonok frissítési kísérletei, a csoportházirend-módosítások replikálása elmarad.stb. Viszonylag könnyű következetlenségeket okozni, ha a megosztott mappákat manuálisan módosítják, például SYSVOL\Policies a replikáció tiszteletben tartása nélkül.

Abban az esetben, ha egy elsődleges tartományvezérlő replikációja hibás (mind az AD-adatok, mind a SYSVOL), és a következő típusú monitorozási üzenetek jelennek meg: „Az adatbázist nem támogatott eljárással állították vissza. Lehetséges ok: USN visszagörgetés", a bölcs dolog a következő:

• Ellenőrizze a dcdiag y repadmin a hibák mértéke és hogy vannak-e „állandó objektumok”.
• Ellenőrizze a 2095-ös eseményt és az értéket DSA nem írható a Nyilvántartásban.
• Értékelje, hogy lehetséges-e Vedd ki a DC-t és építsd újra (Ha három vagy több másik egészséges DC is van, akkor ez általában a legjobb megoldás).
• Ha ez az egyetlen DC vagy kritikus, emelj egy rendszerállapot-visszaállítás egy kompatibilis biztonsági mentésből, ideális esetben a legújabb és a sírkő időszakán belül.

Több vezérlővel rendelkező tartományokban erősen ajánlott, hogy a tartományvezérlők a lehető legtisztábbak legyenek: további szerepkörök vagy helyi felhasználói adatok nélkülÍgy, ha az egyik meghibásodik vagy megsérül, egy új formázható és előléptethető egy másik tartományvezérlő alapján vagy IFM-en keresztül, ami jelentősen csökkenti a helyreállítás bonyolultságát.

Továbbá érdemes megjegyezni az olyan korlátozásokat is, mint például A rendszerállapot-másolatok csak a sírkő időszakában érvényesek (60, 90, 180 nap a konfigurációtól függően) a törölt objektumok újraélesztésének elkerülése érdekében, és hogy az NTLM gépi kulcsok 7 naponta változnak. Nagyon régi visszaállítások esetén szükséges lehet a csapatfiókok visszaállítása problémák az „Active Directory felhasználók és számítógépek” mappa használatával, vagy akár eltávolításukkal és a tartományhoz való újbóli csatlakoztatásukkal.

Eljárások megléte a rendszerállapot rendszeres biztonsági mentésére, Az FSMO szerepkörök, a globális katalógus és a replikációs topológia egyértelmű dokumentálásaA visszaállítási lépések laboratóriumi környezetben történő tesztelése időbefektetés, amely sok fejfájástól kímél meg, amikor eljön a nap, amikor egy tartományvezérlő megsérül, vagy valaki gondolkodás nélkül pillanatképet alkalmaz.