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

Kad domēna kontrolleris tiek bojāts vai nepareizi atjaunots, bažas ir milzīgas: Pieteikšanās neizdodas, GPO vairs netiek lietoti, un replikācija pārstāj darboties gandrīz bez jebkādām norādēm.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 pieņemtās dublēšanas un atjaunošanas metodes.

Mūsdienu Windows Server vidēs domēna kontrollera atjaunošanai ir nepieciešama laba tādu jēdzienu izpratne kā sistēmas statuss, autoritatīva/neautoritatīva atjaunošana, SYSVOL, DFSR/FRS un USN atcelšanaJa šīs problēmas tiek risinātas steigā vai izmantojot nesaderīgus attēlveidošanas rīkus, rezultāts var būt mežs, kas pilns ar klusām neatbilstībām, kuras 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 sirds 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 datubāzē. Ntds.dit, saistītie žurnālfaili un mape SYSVOL, starp citām sastāvdaļām, kas veido tā saukto “sistēmas stāvokli”.

Sistēmas statuss ietver, cita starpā, Active Directory žurnālfaili un dati, Windows reģistrs, sistēmas sējums, SYSVOL, sertifikātu datubāze (ja pastāv CA), IIS metabāze, sāknēšanas faili un aizsargātās operētājsistēmas komponentesTāpēc jebkurai nopietnai uzņēmējdarbības nepārtrauktības stratēģijai ir jāietver regulāras katra datu centra sistēmas stāvokļa dublējumkopijas.

Kad rodas Active Directory datubāzes faktiska bojāšana, nopietna replikācijas kļūme vai problēma ar atļaujas ieslēgtas SYSVOLDomē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 pareiza atveseļošanās ir noteicošā starpgadījuma un ilgstošas ​​katastrofas rašanās ziņā..

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

Pamata diagnostikas un replikācijas kontroles rīki

Korupcijas vai replikācijas kļūmju simptomu gadījumā pirmais saprātīgais solis ir pārbaudīt vides stāvokli, izmantojot vietējos rīkus. DCDiag, Repadmin, ReplMon (vecākās versijās) un notikumu skatītājs Viņi ir jūsu labākie sabiedrotie, pirms apsverat agresīvas restaurācijas.

ar DCDiag Tiek veikta vispārēja visu domēna kontrolleru pārbaude, identificējot problēmas ar replikāciju, DNS, AD DS pakalpojumiem utt. Repadmin Tas ļ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 Tas 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 “Directory Services” un “DFS Replication”. Notikumi, piemēram, 467 un 1018, norāda uz faktisku datubāzes bojājumu., savukārt notikumi 1113/1115/1114/1116 attiecas uz ievades/izvades replikācijas iespējošanu vai atspējošanu.

Ja aizdomīgs DC ir īslaicīgi jāizolē, lai novērstu korupcijas izplatīšanos, mēs varam Ienākošās un izejošās replikācijas atspējošana, 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 varētu atgūt DC ar garantijām, ir svarīgi, lai būtu Sistēmas stāvokļa dublējumkopijas, kas veiktas, izmantojot 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āki komunālie pakalpojumi, 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 iekļauts svarīgs jauns papildinājums: Hyper-V paaudzes ID (GenID)Šis identifikators ļauj virtuālajam domēna kontrollerim noteikt, ka tā disks ir atritināts uz iepriekšējo laika punktu. Kad tas notiek, AD DS ģenerē jaunu InvocationID un apstrādā situāciju tā, it kā tā būtu atjaunota no veiksmīgas dublējuma.paziņojot saviem replikācijas partneriem, tādējādi nodrošinot drošu pārrakstīšanu, neradot USN atcelšanu.

Ir svarīgi ievērot kapa pieminekļa kalpošanas laiksTas norāda, cik ilgi var izmantot sistēmas stāvokļa dublējumu, neriskējot atkārtoti ieviest 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Šī situācija rodas, ja AD datubāzes saturs tiek atsaukts, izmantojot neatbalstītu metodi, neatjaunojot InvocationID vai neinformējot replikācijas partnerus.

Tipisks scenārijs ir DC palaišana no diska attēls vai iepriekš uzņemts virtuālās mašīnas momentuzņēmumsneizmantojot saderīgu sistēmas atjaunošanu. Vai arī tieši kopējiet failu Ntds.dit, izmantojiet attēlveidošanas programmas, piemēram, Ghost, palaidiet no bojāta diska spoguļa vai atkārtoti lietojiet krātuves momentuzņēmumu masīva līmenī.

Šādos gadījumos domēna kontrolleris turpina izmantot to pašu InvocationID kā iepriekš, bet tā Vietējais USN skaitītājs darbojas apgrieztā secībā.Pārējie DC atceras saņemtās izmaiņas līdz augstam USN, tāpēc, kad atsauktais DC mēģina nosūtīt atpakaļ jau atpazītos USN, Viņu partneri uzskata, ka viņi ir lietas kursā, un pārstāj pieņemt konkrētas izmaiņas..

Rezultātā tiek veiktas noteiktas izmaiņas (piemēram, lietotāja izveide, paroles maiņa, ierīces reģistrācija, grupas dalības maiņa, jauni DNS ierakstiŠīs kļūdas 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 skaidras kļūdas. Šī ir ārkārtīgi bīstama klusa kļūme.

Lai noteiktu šīs situācijas, Windows Server 2003 SP1 un jaunāki draiveri reģistrē Direktoriju pakalpojumu notikums 2095 Kad tiek konstatēts, ka attālais domēna kontrolleris sūta jau apstiprinātus USN bez izmaiņām InvocationID, sistēma Tas karantīnā ievieto skarto domēna kontrolleri, aptur tīkla pieteikšanos un novērš turpmāku izmaiņu rašanos. ko nevarēja pareizi atkārtot.

Kā papildu tiesu medicīnas pierādījums tas var iepazīties ar reģistru atslēga HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parametri un vērtība DSA nav rakstāmsJa šī vērtība ir iestatīta (piemēram, 0x4), tas norāda, ka USN apvērses noteikšanas funkcija DC pārslēdza uz nerakstīšanas stāvokli. Šī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ā

Procedūra, kas jāveic, strādājot ar bojātu vai nepareizi atjaunotu domēna kontrolleri, ir atkarīga no vairākiem faktoriem: Domēna kontrolleru skaits domēnā/mežā, derīgu sistēmas stāvokļa kopiju pieejamība, citu lomu (FSMO, CA, globālais katalogs) klātbūtne un problēmas laika tvērums.

Ja domēnā ir citi veselīgi domēna kontrolleri un Bojātajā domēna kontrollerī nav unikālu kritisku datu.Ātrākais un tīrākais risinājums parasti ir noņemt šo domēna kontrolleri un atjaunot to. Tomēr, ja tas ir vienīgais domēna kontrolleris vai ja tajā tiek mitinātas 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, saprātīgākā rīcība parasti ir šāda: Izņemiet šo līdzstrāvas barotāju no ekspluatācijas un nemēģiniet to "salabot" uz vietas., ja vien nav iespējams atgriezties pie atbalstītā sistēmas stāvokļa dublējuma, kas tika veikts pirms atcelšanas.

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

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

Vecākajās versijās šī darbība tika veikta ar dcpromo /forceremoval, kas Noņemiet 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 turpmākajā replikācijā.

Pēc piespiedu pazemināšanas ir obligāti jāizpilda komanda no veselīga DC. metadatu tīrīšana izmantojot rīku NtdsutilŠis process no AD datubāzes noņem visas atsauces uz dzēsto DC (NTDS iestatījumu objektus, DNS atsauces utt.), lai nav palikušas "spoku" paliekas, kas varētu mulsināt replikāciju.

Ja degradētajam kontrollerim bija FSMO lomas (PDC emulators, RID meistars, shēmas meistars utt.), būs nepieciešams nodod vai atņem šīs lomas uz citu DC pirms vai pēc pazemināšanas atkarībā no situācijas. Vēlāk operētājsistēmu var atkārtoti instalēt šajā serverī, un to var paaugstināt atpakaļ uz tīru DC.

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

Ja ir pieejama derīga sistēmas stāvokļa kopija, AD atkopšanu var veikt divos veidos: neautoritatīvs un autoritatīvsIzpratne par atšķirību ir būtiska, lai nepalaistu garām jaunākās izmaiņas vai neatkārtotu novecojušus datus.

Vienā neautoritatīva atjaunošanaDC tiek atgriezts iepriekšējā punktā, bet, tiklīdz tas sākas, Pārējie domēna kontrolleri tiek uzskatīti par atsaucesCitiem vārdiem sakot, pēc startēš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 arī citi veseli kontrolieri, un mēs vēlamies, lai atjaunotais viņus panāktu..

Vienā autoritāra atjaunošanaTomēr ir nepārprotami norādīts, ka Atjaunotie dati ir tie, kam vajadzētu dominēt. virs tā, kas ir citiem domēna kontrolleriem. Tas nozīmē, ka pēc atjaunošanas atgūtajiem objektiem būs augstāks versijas numurs, lai piespiestu tos replicēt no šī domēna kontrollera uz pārējo domēnu. Tā ir piemērota izvēle, ja Esam nejauši izdzēsuši objektus vai OU vai arī vēlamies atjaunot SYSVOL un GPO saturu iepriekšējā stāvoklī un to replicēt..

Svarīga detaļa ir tā, ka autoritatīvai atjaunošanai nav obligāti jābūt visai datubāzei. Ar utilītu Ntdsutil Atsevišķus objektus, apakškokus (piemēram, OU) vai visu domēnu var atzīmēt kā autoritatīvus. Tas piedāvā ievērojamu elastību, piemēram, izgūt 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: Ieslēdziet direktoriju pakalpojumu atjaunošanas režīmu (DSRM), atjaunojiet, izmantojot dublēšanas rīku, un restartējiet.

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.

Kad mēs runājam par trešo pušu dublēšanas produktiem, piemēram, NAKIVO dublēšana un replikācijaTās "lietotnes apzinošais" režīms spēj atpazīt, ka atkopjamā mašīna ir DC un automātiski pielāgot procesu, lai saglabātu AD konsekvenciVairumā 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 ir autoritatīvi atjaunots un dublējums ir vecsPastāv risks zaudēt likumīgas izmaiņas, kas veiktas pēc dublējuma izveides (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 tikt replicēts ar FRS (failu replikācijas pakalpojums) vai DFSR (izplatītās failu sistēmas replikācija)SYSVOL autoritatīvas atjaunošanas procedūra atšķiras atkarībā no tā, kurš no abiem tiek lietots.

Lai to noteiktu, varat pārbaudīt atslēgu reģistrā. HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DFSR\Parameters\SysVols\Sysvols migrēšana\LocalStateJa šī apakšatslēga pastāv un tās vērtība ir 3 (DZĒSTA), tiek izmantota DFSR atslēga. Ja tā nepastāv vai tās vērtība atšķiras, mēs strādājam ar vidi, kas joprojām izmanto FRS atslēgu.

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 tiek replicēts ar DFSR, process ir nedaudz sarežģītāks: tas ietver ADSIEdiegot lai modificētu SYSVOL abonēšanas objektus (atribūtus msDFSR — iespējots y msDFSR opcijas) autoritatīvajā DC un citos, piespiedu AD replikāciju, izpildi dfsrdiag pollad un notikumu žurnālā apstipriniet tā parādīšanos notikumi 4114, 4602, 4614 un 4604 kas apliecina, ka SYSVOL ir pareizi inicializēts un replicēts.

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

Virtualizētās vidēs tas ir ļoti bieži sastopams Domēna kontrolleru VHD/VHDX failiJa jums nav sistēmas stāvokļa dublējuma, bet ir darbojoš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.

Atlasot šo vērtību, Active Directory tiek informēts, ka datubāze ir atjaunota no dublējuma, kas piespiež ģenerējot jaunu InvocationID, startējot normālā režīmāTādā veidā citi domēna kontrolleri to interpretē kā jaunu instanci un pareizi pielāgo savas replikācijas ūdenszīmes, novēršot USN atcelšanu.

Pēc DC restartēšanas normālā režīmā ieteicams pārbaudīt notikumu skatītāju, īpaši notikumu žurnālu. Katalogu pakalpojumi, meklējot pasākums 1109Šis notikums apstiprina, ka servera InvocationID atribūts ir mainījies, un parāda vecās un jaunās vērtības, kā arī augstāko USN dublēšanas laikā. Turklāt vērtība Iepriekšējo DSA atjaunojumu skaits Tam vajadzēja būt palielinātam 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āpiemJebkurā 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 dati, gan SYSVOL) un uzraudzības ziņojumiem, kuru tips ir “Datu bāze tika atjaunota, izmantojot neatbalstītu procedūru. Iespējamais iemesls: USN atcelšana", prātīgākais, kas jādara, ir:

• 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 kontrolieriem ir ļoti ieteicams, lai DC būtu pēc iespējas "tīrāki": bez papildu lomām vai lokāliem lietotāju datiemTādā veidā, ja viens neizdodas vai tiek bojāts, jaunu var formatēt un reklamēt, pamatojoties uz citu DC vai izmantojot IFM, ievērojami samazinot atkopšanas sarežģītību.

Turklāt ir vērts atcerēties par ierobežojumiem, piemēram, Sistēmas stāvokļa kopijas ir derīgas tikai kapakmens periodā (60, 90, 180 dienas atkarībā no konfigurācijas), lai izvairītos no dzēstu objektu atdzīvināšanas, un ka NTLM datora atslēgas mainās ik pēc 7 dienām. Ļoti vecās atjaunošanas reizēs var būt nepieciešams atiestatīt komandas kontus problēmas no “Active Directory lietotājiem un datoriem” vai pat to noņemšana un atkārtota pievienošana domēnam.

Ir ieviestas procedūras sistēmas stāvokļa regulārai dublēšanai, Skaidri dokumentējiet FSMO lomas, globālo katalogu un replikācijas topoloģijuUn atjaunošanas darbību testēšana laboratorijas vidē ir laika ieguldījums, kas ietaupa daudz galvassāpju, kad pienāk diena, kad domēna kontrolleris tiek bojāts vai kāds bez domāšanas lieto momentuzņēmumu.