Bojāta lokālā domēna kontrollera atjaunošana un atkopšana

Kad domēna kontrolleris tiek bojāts vai nepareizi atjaunots, tas rada ievērojamas bažas: pieteikšanās neizdodas, GPO vairs netiek lietoti, un replikācija pārstāj darboties bez brīdinājuma . Labā ziņa ir tā, ka pastāv skaidras procedūras fiziska vai virtuāla domēna kontrollera atkopšanai, ja vien tiek ievērotas atbalstītās dublēšanas un atjaunošanas metodes.

Mūsdienu Windows Server vidē domēna kontrollera atjaunošanai ir nepieciešama pamatīga tādu jēdzienu izpratne kā sistēmas stāvoklis, autoritatīva/neautoritatīva atjaunošana, SYSVOL, DFSR/FRS un USN atcelšana . Ja šīs problēmas tiek risinātas steigā vai izmantojot neatbalstītus attēlveidošanas rīkus, rezultāts var būt klusu neatbilstību mežs, ko ir ļoti grūti diagnosticēt.

Kāpēc ir svarīgi pareizi aizsargāt un atjaunot domēna kontrolleri

Active Directory ir autentifikācijas un autorizācijas kodols Windows domēnā : tajā tiek glabāti lietotāji, datori, grupas, uzticības attiecības, grupu politikas, sertifikāti un citi svarīgi elementi. Šī informācija galvenokārt atrodas Ntds.dit datubāzē , saistītajos žurnālfailos un mapē SYSVOL , kā arī citos komponentos, kas veido tā saukto "sistēmas stāvokli".

Sistēmas stāvoklis ietver, cita starpā, žurnālfailus un Active Directory datus, Windows reģistru, sistēmas sējumu, SYSVOL, sertifikātu datubāzi (ja tāda ir), IIS metabāzi, sāknēšanas failus un aizsargātas operētājsistēmas komponentes . Tāpēc jebkurai nopietnai biznesa nepārtrauktības stratēģijai ir jāietver regulāras katra domēna kontrollera sistēmas stāvokļa dublējumkopijas.

Kad rodas faktiska Active Directory datubāzes bojāšana, nopietna replikācijas kļūme vai SYSVOL atļauju problēma , domēna kontrolleris var pārtraukt vaicājumu apstrādi, neizdoties startēt Active Directory pakalpojumus vai izraisīt kaskādes kļūdas visā mežā. Šādos gadījumos ātra un veiksmīga atkopšana ir noteicošais faktors starp nopietnu incidentu un ilgstošu katastrofu.

Pirms atjaunošanas mēģinājuma ir svarīgi atšķirt īstu datubāzes problēmu no ikdienišķākām problēmām. Ļoti bieži cēlonis ir DNS, tīkla izmaiņas, ugunsmūri vai ceļi, kas modificēti ar tādiem rīkiem kā komanda netsh , tāpēc ieteicams vispirms izslēgt šos faktorus, pirms pieskaraties Active Directory datubāzei.

Pamata diagnostikas un replikācijas kontroles rīki

Ja rodas korupcijas vai replikācijas kļūmju simptomi, pirmais saprātīgais solis ir pārbaudīt vides statusu, izmantojot vietējos rīkus. DCDiag, Repadmin, ReplMon (vecākās versijās) un Event Viewer ir jūsu labākie sabiedrotie, pirms apsverat agresīvu atjaunošanu.

DCDiag veic vispārēju visu domēna kontrolleru pārbaudi, identificējot problēmas ar replikāciju, DNS, AD DS pakalpojumiem un citiem. Repadmin ļauj skatīt replikācijas statusu, replikācijas partnerus, USN ūdenszīmes un noteikt pastāvīgus objektus. Vecākās Windows versijās ReplMon piedāvāja grafisku skatījumu uz replikācijas kļūdām domēnā.

Papildus šiem rīkiem ir svarīgi pārskatīt notikumu skatītāju sadaļām “Direktoriju pakalpojumi” un “DFS replikācija”. Notikumi, piemēram, 467 un 1018, norāda uz faktisku datubāzes bojājumu , savukārt notikumi 1113, 1115, 1114 un 1116 attiecas uz ienākošās/izejošās replikācijas iespējošanu vai atspējošanu.

Ja aizdomīgs domēna kontrolleris ir īslaicīgi jāizolē, lai novērstu korupcijas izplatīšanos, mēs varam atspējot ienākošo un izejošo replikāciju, izmantojot Repadmin :

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

Lai atjaunotu replikāciju normālā stāvoklī, vienkārši noņemiet šīs opcijas:

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

Atbalstītās sistēmas stāvokļa dublējumkopijas domēna kontrolleros

Lai droši atjaunotu domēna kontrolleri, ir svarīgi izveidot sistēmas stāvokļa dublējumkopijas, izmantojot ar Active Directory saderīgus rīkus . Šie rīki atbalstītā veidā izmanto Microsoft dublēšanas un atjaunošanas API un sējuma ēnkopijas pakalpojumu (VSS).

Starp visizplatītākajiem risinājumiem ir Windows Server Backup, trešo pušu risinājumi, kas integrēti ar VSS (piemēram, NAKIVO, Backup Exec un citi) , vai vecākas utilītas, piemēram, Ntbackup operētājsistēmā Windows 2000/2003. Visos gadījumos tiem ir jāievēro AD API, lai nodrošinātu datubāzes un tās kopiju konsekvenci pēc atjaunošanas.

Windows Server 2012 un jaunākās versijās ir ieviesta svarīga jauna funkcija: Hyper-V paaudzes ID (GenID) . Šis identifikators ļauj virtuālajam domēna kontrollerim noteikt, kad tā disks ir atjaunots uz iepriekšējo laika punktu. Kad tas notiek, Active Directory domēna pakalpojumi (AD DS) ģenerē jaunu izsaukuma ID un apstrādā situāciju tā, it kā tā būtu atjaunota no veiksmīgas dublējuma , paziņojot par to saviem replikācijas partneriem un iespējojot drošu pārrakstīšanu, neizraisot USN atcelšanu.

Ir ļoti svarīgi ievērot kapakmens kalpošanas laiku , kas nosaka, cik ilgi var izmantot sistēmas stāvokļa dublējumu, neriskējot atjaunot sen izdzēstus objektus. Mūsdienu versijās tas parasti ir 180 dienas, un ieteicams veikt dublējumus vismaz ik pēc 90 dienām, lai saglabātu pietiekamu drošības rezervi.

Neautorizētas metodes, kas izraisa USN maiņu

Viens no bīstamākajiem kluso neatbilstību cēloņiem Active Directory ir USN atcelšana . Tas notiek, ja AD datubāzes saturs tiek atsaukts, izmantojot neatbalstītu metodi, neatiestatot izsaukšanas ID vai nepaziņojot replikācijas partneriem.

Tipisks scenārijs ietver domēna kontrollera palaišanu no iepriekš uzņemta diska attēla vai virtuālās mašīnas momentuzņēmuma , neizmantojot saderīgu sistēmas atjaunošanu. Citas iespējas ietver Ntds.dit faila tiešu kopēšanu, attēlveidošanas programmatūras, piemēram, Ghost, izmantošanu, palaišanu no bojāta diska spoguļa vai krātuves momentuzņēmuma atkārtotu lietošanu masīva līmenī.

Šādos gadījumos domēna kontrolleris turpina izmantot to pašu InvocationID kā iepriekš, bet tā lokālais USN skaitītājs atgriežas pie iepriekšējā . Citi DC atceras izmaiņu saņemšanu līdz augstam USN skaitam, tāpēc, kad atjaunotais DC mēģina vēlreiz nosūtīt atpazītus USN, tā partneri uzskata, ka tie ir atjaunināti, un pārtrauc pieņemt konkrētas izmaiņas.

Rezultātā noteiktas izmaiņas (piemēram, lietotāju izveide, paroļu maiņa, ierīču pievienošana, grupu dalības izmaiņas, jauni DNS ieraksti ) nekad netiek replicētas no atjaunotā domēna kontrollera uz pārējo tīklu, taču uzraudzības rīki var neuzrādīt nekādas skaidras kļūdas. Šī ir ārkārtīgi bīstama klusa ievainojamība.

Lai noteiktu šīs situācijas, Windows Server 2003 SP1 un jaunāku versiju draiveri reģistrē direktoriju pakalpojumu notikumu 2095 , kad tiek konstatēts attālais domēna kontrolleris (DC), kas sūta iepriekš apstiprinātus USN bez mainīta InvocationID. Šādā gadījumā sistēma ievieto karantīnā skarto DC, aptur tīkla pieteikšanos un neļauj veikt turpmākas izmaiņas , kuras nevar veiksmīgi replicēt.

Kā papildu tiesu medicīnas pierādījumu varat pārbaudīt reģistra atslēgu HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters un vērtību Dsa Not Writable . Ja šī vērtība ir iestatīta (piemēram, 0x4), tas norāda, ka domēna kontrolleris tika pārvests uz nerakstīšanas stāvokli, nosakot USN atcelšanu. Šīs vērtības manuāla modificēšana, lai to "labotu", ir pilnībā neatbalstīta un atstāj datubāzi pastāvīgi nekonsekventā stāvoklī.

Vispārīgas stratēģijas domēna kontrollera bojājuma vai atgriešanas gadījumā

Veids, kā rīkoties ar bojātu vai nepareizi atjaunotu domēna kontrolleri, ir atkarīgs no vairākiem faktoriem: domēna kontrolleru skaita domēnā/mežā, derīgu sistēmas stāvokļa kopiju pieejamības, citu lomu (FSMO, CA, globālā kataloga) klātbūtnes un problēmas laika tvēruma.

Ja domēnā ir citi veselīgi domēna kontrolleri un bojātajā domēna kontrollerī neatrodas unikāli kritiski dati , ātrākais un tīrākais risinājums parasti ir noņemt un atjaunot šo domēna kontrolleri. Tomēr, ja tas ir vienīgais domēna kontrolleris vai ja tajā atrodas sensitīvas lomas un dati, būs nepieciešama rūpīgāka atjaunošana (autoritatīva vai neautoritatīva).

Vispārīgi runājot, iespējas ir šādas:

• Piespiedu kārtā pazemināt korumpēto domēna pārvaldi un noņemt to no domēna., kam seko metadatu tīrīšana un, ja piemērojams, jauna paaugstināšana.
• Atjaunot no derīgas sistēmas stāvokļa dublējuma, gan autoritatīvā, gan neautoritatīvā režīmā.
• Pārveidojiet DC no cita, izmantojot IFM (instalēšana no multivides), ja nav nesenas kopijas, bet ir citi pareizi domēna kodi (DC).
• Izmantojot virtuālā domēna kontrollera VHD momentuzņēmumu, veicot papildu darbības, lai atzīmētu datubāzi kā atjaunotu no dublējuma (Datubāze atjaunota no dublējuma = 1) un nodrošinātu, ka tiek ģenerēts jauns InvocationID.

Ja ir nepārprotamas aizdomas par USN atcelšanu (piemēram, pēc VM atjaunošanas no momentuzņēmuma, neievērojot labāko praksi) un parādās notikums 2095, vissaprātīgāk parasti ir noņemt šo domēna kontrolleri no pakalpojuma un nemēģināt to "salabot" vietā , ja vien nevarat atgriezties pie atbalstīta sistēmas stāvokļa dublējuma, kas tika izveidots pirms atcelšanas.

Piespiedu pazemināšana un metadatu tīrīšana

Ja domēna kontrolleris ir tik bojāts, ka to nevar normāli pazemināt, vai arī tas ir nepareizi atjaunots, un vēlaties novērst problēmu izplatīšanos, varat izmantot piespiedu demonizāciju.

Vecākās versijās šī darbība tika veikta ar `dcpromo /forceremoval` , kas noņem AD DS lomu, nemēģinot replicēt izmaiņas pārējā mežā . Mūsdienu vidē vednis ir mainījies, taču koncepcija ir tāda pati: noņemt problemātisko domēna kontrolleri no AD topoloģijas, nepiedaloties tam turpmākā replikācijā.

Pēc piespiedu pazemināšanas ir obligāti jāveic metadatu tīrīšana no veselīga domēna kontrollera, izmantojot rīku Ntdsutil . Šis process noņem visas atsauces uz dzēsto domēna kontrolleri no Active Directory datubāzes (NTDS iestatījumu objekti, DNS atsauces utt.), nodrošinot, ka nav palikuši "spoku" atlikumi, kas traucētu replikāciju.

Ja pazeminātajam domēna kontrollerim bija FSMO lomas (PDC emulators, RID meistars, shēmas meistars utt.), šīs lomas pirms vai pēc pazemināšanas ir jāpārnes vai jākonfiscē citam domēna kontrollerim atkarībā no situācijas. Pēc tam operētājsistēmu var atkārtoti instalēt šajā serverī, un to var paaugstināt atpakaļ par tīru domēna kontrolleri.

Neautoritatīva un autoritatīva atjaunošana pakalpojumā Active Directory

Ja ir pieejama derīga sistēmas stāvokļa kopija, Active Directory atkopšanu var veikt divos veidos: neautoritatīvā un autoritatīvā veidā . Izpratne par šo atšķirību ir būtiska, lai izvairītos no jaunāko izmaiņu zaudēšanas vai novecojušu datu replicēšanas.

Neautoritatīvā atjaunošanā domēna kontrolleris tiek atgriezts iepriekšējā stāvoklī, bet pēc tā palaišanas pārējie domēna kontrolleri tiek uzskatīti par atsauci . Tas nozīmē, ka pēc palaišanas atjaunotais domēna kontrolleris pieprasa ienākošo replikāciju un atjaunina savu datubāzi ar visām trūkstošajām izmaiņām no citiem domēna kontrolleriem. Šī opcija ir ideāli piemērota, ja ir citi veseli domēna kontrolleri un mēs vēlamies, lai atjaunotais tos panāktu.

Savukārt autoritatīvā atjaunošanā ir skaidri norādīts, ka atjaunotajiem datiem ir jābūt prioritāriem salīdzinājumā ar citu domēna kontrolleru (DC) datiem. Tas nozīmē, ka pēc atjaunošanas atjaunotajiem objektiem būs augstāks versijas numurs, lai piespiestu replikāciju no šī DC uz pārējo domēnu. Šī ir piemērota izvēle, ja nejauši esam izdzēsuši objektus vai organizatoriskās vienības (OU) vai ja vēlamies atjaunot SYSVOL un GPO saturu iepriekšējā stāvoklī un tos replicēt.

Svarīga detaļa ir tā, ka autoritatīvām atjaunošanas darbībām nav jābūt attiecināmām uz visu datubāzi. Utilīta Ntdsutil ļauj atzīmēt atsevišķus objektus, apakškokus (piemēram, OU) vai visu domēnu kā autoritatīvus. Tas piedāvā ievērojamu elastību, ļaujot, piemēram, atjaunot tikai lietotāju, grupu, OU vai apakškoku dc=mycompany,dc=local.

Vispārīga procedūra sistēmas statusa atjaunošanai DC

DC (fiziska vai virtuāla) sistēmas stāvokļa atjaunošanas pamatshēma ar saderīgiem rīkiem vienmēr ir līdzīga: startēšana direktoriju pakalpojumu atjaunošanas režīmā (DSRM), atjaunošana ar dublēšanas rīku un restartēšana.

Rezumējot, tipiskās virtuālā domēna kontrollera darbības būtu šādas:

1. Startējiet virtuālo mašīnu Windows sāknēšanas pārvaldniekā (parasti to dara, startēšanas laikā nospiežot taustiņu F5/F8). ​​Ja virtuālo mašīnu pārvalda hipervizors, taustiņsitienu fiksēšanai var būt nepieciešams apturēt datora darbību.
2. Papildu sāknēšanas opcijās atlasiet Direktoriju pakalpojumu atjaunošanas režīms (Direktoriju pakalpojumu atjaunošanas režīms). Šajā režīmā serveris tiek startēts, funkcionāli nepievienojot Active Directory datubāzi.
3. Piesakieties ar DSRM administratora kontu definēts sākotnējās domēna kontrollera reklāmas laikā (nevis ar standarta domēna administratora kontu).
4. Palaidiet dublēšanas rīku izmantoto (Windows Server Backup, NAKIVO vai citu saderīgu) un izvēlieties atjaunot sistēmas stāvokli vēlamajā dublēšanas punktā.
5. Pabeidziet atjaunošanas vedni un Restartējiet DC normālā režīmāNeautoritatīvā atjaunošanā serveris sāks replikāciju, lai panāktu pārējos domēna kontrollerus.

Runājot par trešo pušu dublēšanas produktiem, piemēram, NAKIVO Backup & Replication , to "lietotnes atpazīšanas" režīms var atpazīt, ka atkopjamā mašīna ir domēna kontrolieris, un automātiski pielāgot procesu, lai saglabātu Active Directory konsekvenci . Vairumā gadījumu ar vairākiem kontrolieriem pietiek ar pilnīgu atkopšanu neautoritatīvā režīmā.

Autoritatīva atjaunošana ar Ntdsutil

Ja vēlaties, lai atjaunotā domēna kontrollera izmaiņas būtu prioritāras pār pārējām, pēc neautoritatīvās atjaunošanas ir jāpievieno papildu darbība: izmantojiet Ntdsutil, lai atzīmētu objektus kā autoritatīvus.

Vienkāršotā plūsma būtu šāda:

1. Atjaunojiet sistēmas stāvokli standarta veidā un atstājiet serveri ieslēgtu. DSRM režīms (Vēl nerestartējiet normālā režīmā).
2. Atvērt komandrinda ar paaugstinātām privilēģijām un palaist ntdsutil.
3. Aktivizējiet AD instanci ar aktivizēt instances ntds.
4. Ieejot autoritatīvās restaurācijas kontekstā ar autoritatīva atjaunošana.
5. Izmantojiet tādas komandas kā restore object <DN_objeto> o restore subtree <DN_subarbol>, kur DN ir objekta vai apakškoka atšķiramais nosaukums, kas jāatjauno autoritatīvi.
6. Apstipriniet darījumu un, kad tas ir pabeigts, Restartējiet DC normālā režīmā lai iezīmētie objekti tiktu replicēti ar prioritāti pārējā domēnā.

Šāda veida atjaunošanai nepieciešama liela piesardzība. Ja viss domēns tiek atjaunots autoritatīvi un dublējums ir vecs , pastāv risks zaudēt likumīgas izmaiņas, kas veiktas pēc dublējuma (piemēram, lietotāja izveide, paroles maiņa vai grupas modifikācijas). Tāpēc ir ierasta prakse ierobežot autoritatīvo atjaunošanu tikai ar absolūti nepieciešamajiem objektiem vai kokiem.

SYSVOL atjaunošana un atkopšana (FRS salīdzinājumā ar DFSR)

SYSVOL ir domēna kontrollera galvenā sastāvdaļa: tajā tiek glabāti startēšanas skripti, grupu politikas, drošības veidnes un citi svarīgi koplietojamie resursi . Atļauju kļūme, failu bojājums vai replikācijas problēmas var padarīt GPO nelietojamus vai izraisīt neregulāru darbību klientos.

Atkarībā no Windows Server versijas un migrācijas statusa SYSVOL var replicēt vai nu FRS (failu replicēšanas pakalpojums) , vai DFSR (izplatītās failu sistēmas replicēšana) . Autoritatīvas SYSVOL atjaunošanas procedūra atšķiras atkarībā no tā, kurš no abiem tiek izmantots.

Lai to noteiktu, varat pārbaudīt reģistra atslēgu HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DFSR\Parameters\SysVols\Migrating Sysvols\LocalState . Ja šī apakšatslēga pastāv un tās vērtība ir 3 (DZĒSTA), tiek izmantota DFSR. Ja tā nepastāv vai tās vērtība atšķiras, vide joprojām izmanto FRS.

Vidēs ar FRS SYSVOL autoritatīva atkopšana parasti ietver vērtības pielāgošanu. Burflags en HKLM\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process uz noteiktu vērtību (piemēram, 212 decimālskaitlis / 0xD4 heksadecimālskaitlis), lai norādītu, ka šis DC ir autoritatīvs avots.

Ja SYSVOL replicē DFSR, process ir nedaudz sarežģītāks: tas ietver ADSIEdit izmantošanu , lai modificētu SYSVOL abonēšanas objektus ( atribūtus msDFSR-Enabled un msDFSR-Options ) autoritatīvajā domēna kontrollerī un citos, piespiežot AD replikāciju, palaižot komandu dfsrdiag pollad un notikumu žurnālā apstiprinot notikumu 4114, 4602, 4614 un 4604 parādīšanos , kas apliecina, ka SYSVOL ir veiksmīgi inicializēts un replicēts.

Virtuālo domēna kontrolleru atkopšana no VHD

Virtualizētās vidēs ļoti bieži ir domēna kontrolleru VHD/VHDX faili . Ja jums nav sistēmas stāvokļa dublējuma, bet ir funkcionējošs "vecais" VHD, varat pievienot jaunu domēna kontrolleri no šī diska, taču tas jādara ļoti uzmanīgi, lai izvairītos no USN atcelšanas.

Ieteikums ir Neieslēdziet šo virtuālo mašīnu tieši normālā režīmā.Tā vietā jums vajadzētu startēt no iepriekšējā VHD DSRMAtveriet reģistra redaktoru un dodieties uz HKLM\SYSTEM\CurrentControlSet\Services\NTDS\ParametersTur ieteicams pārbaudīt vērtību Iepriekšējo DSA atjaunojumu skaits (ja tāda pastāv) un, galvenais, izveidojiet jaunu DWORD (32 bitu) vērtību ar nosaukumu Datubāze atjaunota no dublējuma ar vērtību 1.

Iestatot šo vērtību, Active Directory tiek informēts, ka datubāze ir atjaunota no dublējuma, kas piespiež ģenerēt jaunu InvocationID normālas startēšanas laikā . Tas ļauj citiem domēna kontrolleriem to interpretēt kā jaunu instanci un pareizi pielāgot replikācijas ūdenszīmes, novēršot USN atcelšanu.

Pēc domēna kontrollera restartēšanas parastajā režīmā pārbaudiet notikumu skatītāju, īpaši direktoriju pakalpojumu žurnālu , lai atrastu notikumu 1109. Šis notikums apstiprina, ka servera InvocationID atribūts ir mainījies, un tiek parādītas gan vecās, gan jaunās vērtības, kā arī augstākais USN dublēšanas laikā. Turklāt DSA iepriekšējo atjaunošanas reižu skaita vērtībai vajadzētu būt palielinājusies par vienu.

Ja šie notikumi neparādās vai skaits nepalielinās, jums jāpārbauda operētājsistēmas versijas un servisa pakotnes, jo noteikta atjaunošanas darbība ir atkarīga no konkrētiem ielāpiem . Jebkurā gadījumā vienmēr ieteicams strādāt ar oriģinālā VHD kopiju, saglabājot neskartu versiju gadījumam, ja process ir jāatkārto.

Praktiski scenāriji un papildu ieteikumi

Praksē korupcijas vai nepareizas restaurācijas problēmas bieži parādās ikdienas situācijās: Manuālas atļauju izmaiņas SYSVOL, mēģinājumi atjaunināt ADMX/ADML veidnes, GPO izmaiņas, kas netiek replicētasutt. Ir samērā viegli radīt neatbilstības, ja koplietotās mapes tiek manuāli modificētas, piemēram, SYSVOL\Policies neievērojot replikāciju.

Primārā domēna kontrollera gadījumā ar bojātu replikāciju (gan AD, gan SYSVOL dati) un uzraudzības ziņojumiem, piemēram, " Datubāze tika atjaunota, izmantojot neatbalstītu procedūru. Iespējamais iemesls: USN atcelšana ", saprātīga rīcība ir šāda:

• Pārbaudiet ar dcdiag y repadmin kļūdu apmēru un to, vai pastāv “pastāvīgi objekti”.
• Pārbaudiet notikumu 2095 un tā vērtību DSA nav rakstāms reģistrā.
• Izvērtējiet, vai tas ir iespējams Noņemiet šo DC un izveidojiet to no jauna (Ja ir trīs vai vairāk citu veselīgu DC, šī parasti ir labākā izvēle).
• Ja tas ir vienīgais DC vai kritiķis, paceliet lūgumu. sistēmas stāvokļa atjaunošana no saderīgas dublējuma, ideālā gadījumā nesenas un kapakmens periodā.

Domēnos ar vairākiem domēna kontrolleriem ir ļoti ieteicams, lai domēna kontrolleri būtu pēc iespējas "tīri": bez papildu lomām vai lokāliem lietotāju datiem . Tādā veidā, ja viens no tiem neizdodas vai tiek bojāts, to var formatēt un paaugstināt uz jaunu, pamatojoties uz citu domēna kontrolleri vai izmantojot informācijas pārvaldības sistēmu (IMF), ievērojami samazinot atkopšanas sarežģītību.

Turklāt ir svarīgi atcerēties ierobežojumus, piemēram, to, ka sistēmas stāvokļa dublējumkopijas ir derīgas tikai kapakmens periodā (60, 90 vai 180 dienas atkarībā no konfigurācijas), lai novērstu izdzēsto objektu atjaunošanu, un to, ka NTLM datora atslēgas mainās ik pēc 7 dienām. Ļoti vecām atjaunošanas reizēm var būt nepieciešams atiestatīt problemātiskos datoru kontus no "Active Directory lietotāji un datori" vai pat noņemt un atkārtoti pievienot tos domēnam.

Procedūru ieviešana regulārai sistēmas stāvokļa dublēšanai, skaidra FSMO lomu, globālā kataloga un replikācijas topoloģijas dokumentēšana , kā arī laiku pa laikam atjaunošanas darbību testēšana laboratorijas vidē ir laika ieguldījums, kas ietaupa daudzas galvassāpes, kad pienāk diena, kad domēna kontrolleris tiek bojāts vai kāds bez domāšanas lieto momentuzņēmumu.