- Rëndësia e kopjeve rezervë të gjendjes së sistemit dhe metodat e mbështetura për mbrojtjen e kontrolluesve të domenit.
- Dallimet midis restaurimit autoritar dhe jo-autoritar në Active Directory dhe kur duhet të përdoret secili prej tyre.
- Procedura të hollësishme për rikuperimin e DC-ve fizike dhe virtuale, duke përfshirë problemet SYSVOL dhe rikthimet e USN.
- Strategjitë e zbutjes: degradimi i detyruar, pastrimi i meta të dhënave dhe rindërtimi i kontrolluesit të domenit.
Kur një kontrollues domeni korruptohet ose rikthehet gabimisht, frika është e madhe: Hyrjet dështojnë, GPO-të ndalojnë së aplikuari dhe replikimi ndërpritet pothuajse pa asnjë të dhënë.Lajmi i mirë është se ekzistojnë procedura të qarta për rikuperimin e një DC fizik ose virtual, me kusht që të respektohen metodat e pranuara të kopjimit të rezervimit dhe rivendosjes.
Në mjediset moderne të Windows Server, rivendosja e një kontrolluesi domeni kërkon një kuptim të mirë të koncepteve të tilla si statusi i sistemit, rivendosja autoritare/jo-autoritare, rikthimet SYSVOL, DFSR/FRS dhe USNNëse këto probleme trajtohen me nxitim ose me mjete imazherie të papajtueshme, rezultati mund të jetë një pyll plot me mospërputhje të heshtura që janë shumë të vështira për t'u diagnostikuar.
Pse është thelbësore të mbrohet dhe rikuperohet siç duhet një kontrollues domeni
Active Directory është zemra e autentifikimit dhe autorizimit në një domen të Windows.Ai ruan përdoruesit, kompjuterët, grupet, marrëdhëniet e besimit, politikat e grupit, certifikatat dhe elementë të tjerë kritikë. Ky informacion ndodhet kryesisht në bazën e të dhënave. Ntds.dit, skedarët e regjistrit dhe dosja e shoqëruara SYSVOL, ndër komponentët e tjerë që përbëjnë të ashtuquajturën "gjendje të sistemit".
Statusi i sistemit përfshin, ndër të tjera, Skedarët dhe të dhënat e regjistrit të Active Directory, Regjistri i Windows, vëllimi i sistemit, SYSVOL, baza e të dhënave të certifikatave (nëse ekziston një CA), metabaza e IIS, skedarët e nisjes dhe komponentët e sistemit operativ të mbrojturPrandaj, çdo strategji serioze e vazhdimësisë së biznesit duhet të përfshijë kopje rezervë të rregullta të gjendjes së sistemit të secilës qendër të të dhënave.
Kur ndodh korruptim real i bazës së të dhënave Active Directory, një dështim serioz i replikimit ose një problem me lejet në SYSVOLKontrolluesi i domenit mund të ndalojë përpunimin e pyetjeve, të mos fillojë shërbimet e Active Directory ose të shkaktojë gabime të përsëritura në të gjithë pyllin. Në këto raste, Një rikuperim i shpejtë dhe i duhur bën diferencën midis një incidenti serioz dhe një katastrofe të zgjatur..
Përpara se të provoni një rivendosje, është thelbësore të bëni dallimin midis një problemi të vërtetë të bazës së të dhënave dhe dështimeve më të zakonshme. Shumë shpesh, Shkaku qëndron te DNS, ndryshimet e rrjetit, firewall-et ose rrugët e modifikuara me mjete të tilla si komanda netshPrandaj, këshillohet që të përjashtohen këta faktorë së pari përpara se të prekni bazën e të dhënave AD.
Mjetet themelore të diagnostikimit dhe kontrollit të replikimit
Në rast të simptomave të korruptimit ose dështimeve të replikimit, hapi i parë i arsyeshëm është të kontrolloni gjendjen e mjedisit duke përdorur mjete native. DCDiag, Repadmin, ReplMon (në versionet më të vjetra) dhe Shikuesi i Ngjarjeve Ata janë aleatët tuaj më të mirë përpara se të merrni në konsideratë restaurimet agresive.
me DCDiag Kryhet një kontroll i përgjithshëm i të gjithë kontrolluesve të domenit, duke identifikuar problemet me replikimin, DNS, shërbimet AD DS, etj. Repadmin Ju lejon të shikoni statusin e replikimit, partnerët e replikimit, filigranët e USN dhe të zbuloni objekte të vazhdueshme. Në versionet më të vjetra të Windows, ReplMon Ofroi një pamje grafike të gabimeve të replikimit brenda domenit.
Përveç këtyre mjeteve, është thelbësore të rishikoni Shikuesin e Ngjarjeve për "Shërbimet e Drejtorisë" dhe "Replikimin e DFS". Ngjarjet si 467 dhe 1018 tregojnë për korruptim të vërtetë të bazës së të dhënave., ndërsa ngjarjet 1113/1115/1114/1116 lidhen me aktivizimin ose çaktivizimin e replikimit të hyrjes/daljes.
Nëse një DC e dyshuar duhet të izolohet përkohësisht për të parandaluar përhapjen e korrupsionit, ne mundemi Çaktivizoni replikimin hyrës dhe dalës me Repadmin:
repadmin /options DCNAME +DISABLE_INBOUND_REPL
repadmin /options DCNAME +DISABLE_OUTBOUND_REPL
Dhe për të rikthyer replikimin në normalitet, thjesht hiqni këto opsione:
repadmin /options DCNAME -DISABLE_INBOUND_REPL
repadmin /options DCNAME -DISABLE_OUTBOUND_REPL
Kopjet rezervë të gjendjes së sistemit të mbështetura në kontrolluesit e domenit
Për të qenë në gjendje të rikuperoni një DC me garanci, është thelbësore të keni Kopjet rezervë të gjendjes së sistemit të kryera duke përdorur mjete të pajtueshme me Active DirectoryKëto mjete përdorin API-të e Microsoft-it për backup dhe restore dhe Shërbimin e Kopjimit në Hije të Volume (VSS) në një mënyrë të mbështetur.
Ndër zgjidhjet më të zakonshme janë Rezervimi i Windows Server, zgjidhje të palëve të treta të integruara me VSS (si NAKIVO, Backup Exec dhe të tjera)ose shërbime të vjetra si p.sh. Ntbackup në Windows 2000/2003. Në të gjitha rastet, ata duhet të respektojnë API-të e AD për të siguruar qëndrueshmërinë e bazës së të dhënave dhe replikave të saj pas restaurimit.
Windows Server 2012 dhe versionet e mëvonshme kanë një shtesë të re të rëndësishme: ID e Gjenerimit Hyper-V (GenID)Ky identifikues i lejon një kontrolluesi virtual të domenit të zbulojë që disku i tij është rikthyer në një pikë të mëparshme kohore. Kur kjo ndodh, AD DS gjeneron një InvocationID të ri dhe e trajton situatën sikur të ishte rikthyer nga një kopje rezervë e suksesshme.duke njoftuar partnerët e saj të replikimit, duke lejuar kështu rishkrimin e sigurt pa shkaktuar një rikthim të USN.
Është thelbësore të respektohet jetëgjatësia e gurit të varritKjo tregon se për sa kohë mund të përdoret një kopje rezervë e gjendjes së sistemit pa rrezikuar rikthimin e objekteve të fshira shumë kohë më parë. Zakonisht është 180 ditë në versionet moderne dhe rekomandohet të kryhen kopje rezervë të paktën çdo 90 ditë për të ruajtur një kufi të mjaftueshëm sigurie.
Metoda të paautorizuara që shkaktojnë përmbysje të USN-së
Një nga shkaqet më të rrezikshme të mospërputhjeve të heshtura në Active Directory është Rikthimi i USN-sëKjo situatë ndodh kur përmbajtja e bazës së të dhënave AD rikthehet duke përdorur një teknikë të pambështetur, pa u rikthyer InvocationID ose pa u njoftuar partnerët e replikimit.
Skenari tipik është të nisësh një DC nga një imazhi i diskut ose një pamje e makinës virtuale e bërë në të kaluarënpa përdorur një rivendosje të sistemit të pajtueshme. Ose kopjoni skedarin Ntds.dit direkt, përdorni programe imazherie si Ghost, niseni nga një pasqyrë disku e prishur ose riaplikoni një pamje të çastit të ruajtjes në nivelin e vargut.
Në këto raste, kontrolluesi i domenit vazhdon të përdorë të njëjtin InvocationID si më parë, por i tij Numëruesi lokal i USN shkon prapaDC-të e tjera mbajnë mend se kanë marrë ndryshime deri në një USN të lartë, kështu që kur DC-ja e rikthyer përpiqet të dërgojë mbrapsht USN-të e njohura tashmë, Partnerët e tyre besojnë se janë të azhurnuar dhe nuk pranojnë më ndryshime konkrete..
Rezultati është se disa modifikime (për shembull, krijimi i përdoruesit, ndryshimet e fjalëkalimit, regjistrimi i pajisjes, ndryshimet e anëtarësimit në grup, regjistrimet e reja të DNS-sëKëto gabime nuk replikohen kurrë nga DC-ja e rivendosur në pjesën tjetër të rrjetit, por mjetet e monitorimit mund të mos tregojnë gabime të qarta. Ky është një dështim i heshtur jashtëzakonisht i rrezikshëm.
Për të zbuluar këto situata, drajverët e Windows Server 2003 SP1 dhe më vonë regjistrojnë Ngjarja 2095 e Shërbimeve të Drejtorisë Kur zbulohet një DC i largët që dërgon USN të pranuara tashmë pa një ndryshim në InvocationID, sistemi Ai e vendos në karantinë DC-në e prekur, e ndalon Netflix-in dhe parandalon ndryshime të mëtejshme. që nuk mund të përsëritej saktë.
Si provë shtesë mjeko-ligjore, mund të për t'u konsultuar në Regjistër çelësi HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters dhe vlera Dsa nuk mund të shkruhetNëse kjo vlerë është vendosur (p.sh., 0x4), kjo tregon se DC është vënë në një gjendje pa shkrim nga zbulimi i përmbysjes së USN. Modifikimi manual i kësaj vlere për ta "rregulluar" atë nuk mbështetet plotësisht. dhe e lë bazën e të dhënave në një gjendje të përhershme jokonsistente.
Strategji të përgjithshme në rast të korruptimit ose rikthimit të një kontrolluesi domeni
Procedura që duhet ndjekur kur merret me një DC të korruptuar ose të restauruar gabimisht varet nga disa faktorë: Numri i kontrolluesve të domenit në domen/pyll, disponueshmëria e kopjeve të vlefshme të gjendjes së sistemit, prania e roleve të tjera (FSMO, CA, katalogu global) dhe shtrirja kohore e problemit.
Nëse ka DC të tjera të shëndetshme në domen dhe Nuk ka të dhëna unike kritike mbi kontrolluesin e domenit të dëmtuarOpsioni më i shpejtë dhe më i pastër është zakonisht heqja e atij kontrolluesi domeni dhe rindërtimi i tij. Megjithatë, nëse është i vetmi kontrollues domeni, ose nëse përmban role dhe të dhëna të ndjeshme, do të jetë i nevojshëm një restaurim më i kujdesshëm (autoritar ose joautoritar).
Në terma të përgjithshëm, opsionet janë:
- Ulni me forcë pozicionin e DC-së së korruptuar dhe hiqeni atë nga domeni, e ndjekur nga pastrimi i meta të dhënave dhe, nëse është e aplikueshme, promovimi i ri.
- Rivendos nga një kopje rezervë e vlefshme e gjendjes së sistemit, qoftë në modalitetin autoritar apo jo-autoritar.
- Rindërtoni DC-në nga një tjetër duke përdorur IFM (Install From Media), kur nuk ka një kopje të kohëve të fundit, por ka DC të tjera të sakta.
- Duke përdorur një pamje të shkurtër VHD të një DC virtuale, duke zbatuar hapat shtesë për të shënuar bazën e të dhënave si të restauruar nga kopja rezervë (Baza e të dhënave e restauruar nga kopja rezervë = 1) dhe për t'u siguruar që të gjenerohet një InvocationID e re.
Nëse dyshohet qartë një rikthim i USN (për shembull, pas rivendosjes së një VM nga një pamje e çastit pa ndjekur praktikat më të mira) dhe shfaqet ngjarja 2095, veprimi më i arsyeshëm është zakonisht të Hiqeni atë DC nga shërbimi dhe mos u përpiqni ta "rregulloni" atë në vend., përveç nëse është e mundur të rikthehesh në një kopje rezervë të gjendjes së mbështetur të sistemit të marrë para rikthimit.
Ulje e detyruar në detyrë dhe pastrim i meta-datave
Kur një kontrollues domeni është aq i dëmtuar sa nuk mund të ulet në nivelin normal, ose është rikthyer gabimisht dhe ju doni ta parandaloni përhapjen e problemeve, mund të përdorni një ulje e detyruar në detyrë.
Në versionet më të vjetra, ky operacion kryhej me dcpromo /forceremoval, çfarë Hiqni rolin AD DS pa u përpjekur të kopjoni ndryshimet në pjesën tjetër të pyllit.Në mjediset moderne, magjistari ka ndryshuar, por koncepti është i njëjtë: të hiqet DC problematik nga topologjia AD pa marrë pjesë në replikim të mëtejshëm.
Pas një uljeje të detyruar, është e detyrueshme të ekzekutohet një komandë nga një DC i shëndetshëm. pastrimi i meta-datave duke përdorur mjetin NtdsutilKy proces heq të gjitha referencat për DC-në e fshirë (objektet e Cilësimeve NTDS, referencat DNS, etj.) nga baza e të dhënave AD, në mënyrë që Nuk mbeten mbetje "fantazma" që të ngatërrojnë replikimin.
Nëse kontrolluesi i degraduar kishte role FSMO (Emulator PDC, Master RID, Master Schema, etj.), do të jetë e nevojshme të transferon ose merr ato role në një DC tjetër para ose pas uljes në nivel, varësisht nga situata. Më vonë, sistemi operativ mund të riinstalohet në atë server dhe mund të promovohet përsëri në një DC të pastër.
Restaurimi jo-autoritar kundrejt atij autoritar në Active Directory
Kur një kopje e vlefshme e gjendjes së sistemit është e disponueshme, rikuperimi i AD mund të bëhet në dy mënyra: jo-autoritar dhe autoritarTë kuptuarit e ndryshimit është çelësi për të mos humbur ndryshimet e fundit ose për të mos replikuar të dhëna të vjetruara.
Në një restaurim jo-autoritarDC kthehet në një pikë të mëparshme, por sapo të fillojë, Kontrolluesit e tjerë të domenit konsiderohen si referencë.Me fjalë të tjera, pas nisjes, DC-ja e rivendosur kërkon replikim hyrës dhe përditëson bazën e të dhënave të saj me çdo ndryshim që mungon nga DC-të e tjera. Ky opsion është ideal kur Ka kontrollues të tjerë të shëndetshëm, dhe ne duam që ai i rivendosur t'i arrijë ata..
Në një restaurimi autoritarMegjithatë, thuhet shprehimisht se Të dhënat e rikuperuara janë ato që duhet të mbizotërojnë. mbi atë që kanë DC-të e tjera. Kjo do të thotë që, pas rivendosjes, objektet e rikuperuara do të kenë një numër versioni më të lartë për t'i detyruar ato të replikohen nga ai DC në pjesën tjetër të domenit. Është zgjedhja e duhur kur Ne kemi fshirë aksidentalisht objekte ose njësi organizative, ose duam të rikthejmë përmbajtjen e SYSVOL dhe GPO në një gjendje të mëparshme dhe ta replikojmë atë..
Një detaj i rëndësishëm është se restaurimi autoritar nuk është domosdoshmërisht i nevojshëm për të gjithë bazën e të dhënave. Me programin Ntdsutil Objektet individuale, nën-pemët (p.sh., një njësi organizative) ose i gjithë domeni mund të shënohen si autoritare. Kjo ofron fleksibilitet të konsiderueshëm, për shembull, merr vetëm një përdorues, një grup, një njësi organizative ose nënpemën dc=mycompany,dc=local.
Procedura e përgjithshme për rivendosjen e statusit të sistemit në një DC
Skema bazë për rivendosjen e gjendjes së sistemit të një DC (qoftë fizik apo virtual) me mjete të pajtueshme është gjithmonë e ngjashme: Niseni në Modalitetin e Rivendosjes së Shërbimeve të Drejtorisë (DSRM), rivendoseni duke përdorur mjetin e kopjimit rezervë dhe rinisni përsëri.
Në përmbledhje, hapat tipikë për një kontrollues domeni virtual do të ishin:
- Nisni makinën virtuale në Windows Boot Manager (zakonisht duke shtypur F5/F8 gjatë nisjes). Nëse makina virtuale menaxhohet nga një hipervizor, mund të jetë e nevojshme të ndaloni makinën për të kapur shtypjen e tastit.
- Në opsionet e avancuara të nisjes, zgjidhni Modaliteti i rikthimit të shërbimeve të drejtorisë (Modaliteti i Rivendosjes së Shërbimeve të Drejtorisë). Ky modalitet e nis serverin pa montuar bazën e të dhënave Active Directory në një mënyrë funksionale.
- Hyni me llogarinë e administratorit DSRM të përcaktuara gjatë promovimit origjinal të DC-së (jo me një llogari standarde administratori domeni).
- Ekzekutoni mjetin e kopjimit rezervë të përdorura (Windows Server Backup, NAKIVO ose ndonjë tjetër e pajtueshme) dhe zgjidhni të rivendosni gjendjen e sistemit në pikën e dëshiruar të rezervimit.
- Përfundoni asistentin e rikuperimit dhe Rinisni DC-në në modalitetin normalNë një rivendosje jo-autoritare, serveri do të fillojë replikimin për të kapur ritmin me DC-të e tjera.
Kur flasim për produktet e kopjes rezervë të palëve të treta, si p.sh. NAKIVO Rezervimi dhe përsëritjaModaliteti i tij "i vetëdijshëm për aplikacionin" është në gjendje të njohë që makina që po rikuperohet është një DC dhe rregulloni automatikisht procesin për të ruajtur qëndrueshmërinë e AD-sëNë shumicën e skenarëve me kontrollues të shumtë, një rikuperim i plotë në modalitetin jo-autoritar është i mjaftueshëm.
Restaurim autoritar me Ntdsutil
Nëse dëshironi që ndryshimet në kontrolluesin e domenit të rivendosur të kenë përparësi mbi pjesën tjetër, duhet të shtoni një hap shtesë pas rivendosjes jo-autoritare: Përdorni Ntdsutil për të shënuar objektet si autoritative.
Rrjedha e thjeshtuar do të ishte:
- Rivendos gjendjen e sistemit në mënyrën standarde dhe lëre serverin ende në Modaliteti DSRM (Mos e rinisni ende në modalitetin normal).
- Hapni një komandë e shpejtë me privilegje të larta dhe vrapo
ntdsutil. - Aktivizoni instancën AD me aktivizo instancën ntds.
- Hyrja në kontekstin e restaurimit autoritar me rivendosje autoritare.
- Përdorni komanda si
restore object <DN_objeto>orestore subtree <DN_subarbol>, ku DN është emri i dalluar i objektit ose nënpemës që do të restaurohet në mënyrë autoritare. - Konfirmoni transaksionin dhe, pasi të keni përfunduar, Rinisni DC-në në modalitetin normal në mënyrë që objektet e shënuara të replikohen me përparësi ndaj pjesës tjetër të domenit.
Ky lloj restaurimi kërkon shumë kujdes. Nëse i gjithë domeni është restauruar në mënyrë autoritare dhe kopja rezervë është e vjetërEkziston rreziku i humbjes së ndryshimeve legjitime të bëra pas kopjimit rezervë (për shembull, krijimi i përdoruesit, ndryshimet e fjalëkalimit ose modifikimet e grupit). Prandaj, është praktikë e zakonshme të kufizohen rikthimet autoritare vetëm në objektet ose pemët rreptësisht të nevojshme.
Restaurimi dhe rikuperimi i SYSVOL (FRS kundrejt DFSR)
SYSVOL është një komponent kyç i kontrolluesit të domenit: Ai ruan skriptet e fillimit, politikat e grupit, shabllonet e sigurisë dhe burime të tjera thelbësore të përbashkëta.Një dështim në lejet tuaja, korruptimi i skedarëve ose problemet e replikimit mund t'i bëjnë GPO-të të papërdorshme ose të shkaktojnë sjellje të çrregullt te klientët.
Në varësi të versionit të Windows Server dhe statusit të migrimit, SYSVOL mund të replikohet nga FRS (Shërbimi i Replikimit të Skedarëve) ose nga DFSR (Replikimi i Sistemit të Skedarëve të Shpërndarë)Procedura për një restaurim autoritar të SYSVOL ndryshon në varësi të asaj se cila nga të dyja është në përdorim.
Për ta përcaktuar këtë, mund të kontrolloni çelësin në Regjistër. HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DFSR\Parameters\SysVols\Migrating Sysvols\LocalStateNëse ky nënçelës ekziston dhe vlera e tij është 3 (FSHIRË), po përdoret DFSR. Nëse nuk ekziston ose vlera e tij është e ndryshme, kemi të bëjmë me një mjedis që ende përdor FRS.
Në mjedise me FRS, rikuperimi autoritar i SYSVOL zakonisht përfshin rregullimin e vlerës. Flamuj Burg en HKLM\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process në një vlerë specifike (p.sh., 212 dhjetore / 0xD4 heksadeksadore) për të treguar se ky DC është burimi autoritar.
Nëse SYSVOL replikohet nga DFSR, procesi është disi më i përpunuar: përfshin përdorimin e ADSIERedakt për të modifikuar objektet e abonimit SYSVOL (atributet msDFSR-Aktivizuar y Opsionet-msDFSR) në DC autoritative dhe në të tjerët, detyron replikimin e AD, ekzekuton dfsrdiag pollad dhe konfirmoni në regjistrin e ngjarjeve shfaqjen e ngjarjet 4114, 4602, 4614 dhe 4604 që vërtetojnë se SYSVOL është inicializuar dhe replikuar saktë.
Rikuperimi i kontrolluesve të domenit virtual nga VHD
Në mjediset e virtualizuara është shumë e zakonshme të kesh Skedarët VHD/VHDX të kontrolluesve të domenitNëse nuk keni një kopje rezervë të gjendjes së sistemit, por keni një VHD "të vjetër" që funksionon, mund të montoni një DC të ri nga ai disk, megjithëse duhet ta bëni këtë me shumë kujdes për të shmangur shkaktimin e një rikthimi të USN.
Rekomandimi është Mos e nis atë VM direkt në modalitetin normalNë vend të kësaj, duhet të nisësh nga VHD-ja e mëparshme në DSRMHapni Redaktorin e Regjistrit dhe shkoni te HKLM\SYSTEM\CurrentControlSet\Services\NTDS\ParametersAtje, këshillohet të kontrolloni vlerën Numri i restaurimeve të mëparshme DSA (nëse ekziston) dhe, mbi të gjitha, krijoni një vlerë të re DWORD (32-bit) të quajtur Baza e të dhënave u rikthye nga kopja rezervë me vlere 1.
Duke zgjedhur këtë vlerë, Active Directory informohet se baza e të dhënave është rikthyer nga një kopje rezervë, gjë që detyron gjenerimi i një InvocationID të ri gjatë nisjes në modalitetin normalNë këtë mënyrë, DC-të e tjera e interpretojnë atë si një instancë të re dhe rregullojnë saktë filigranët e tyre të replikimit, duke parandaluar rikthimin e USN-së në gjendjen e mëparshme.
Pas rinisjes së DC në modalitetin normal, këshillohet të kontrolloni Shikuesin e Ngjarjeve, konkretisht regjistrin e Shërbimet e drejtorisë, duke kërkuar për ngjarja 1109Ky ngjarje konfirmon që atributi InvocationID i serverit ka ndryshuar dhe shfaq vlerat e vjetra dhe të reja, si dhe numrin më të lartë të shërbimit të të dhënave (USN) në kohën e ruajtjes së të dhënave. Përveç kësaj, vlera e Numri i restaurimeve të mëparshme DSA Duhej të ishte rritur me një.
Nëse këto ngjarje nuk shfaqen, ose numri nuk rritet, duhet të kontrolloni versionet e sistemit operativ dhe Paketat e Shërbimit, meqenëse Sjellje të caktuara të restaurimit varen nga patch-e specifikeSidoqoftë, është gjithmonë e këshillueshme të punoni në një kopje të VHD-së origjinale, duke ruajtur një version të paprekur në rast se procesi duhet të përsëritet.
Skenarë praktikë dhe rekomandime shtesë
Në praktikë, problemet e korruptimit ose restaurimeve të papërshtatshme shpesh shfaqen në skenarë të përditshëm: Modifikime manuale të lejeve në SYSVOL, përpjekje për të azhurnuar shabllonet ADMX/ADML, ndryshime GPO që nuk replikohenetj. Është relativisht e lehtë të shkaktohen mospërputhje nëse dosjet e përbashkëta modifikohen manualisht, si p.sh. SYSVOL\Policies pa respektuar replikimin.
Në rast të një DC primar me replikim të ndërprerë (si të dhënat AD ashtu edhe SYSVOL) dhe mesazhe monitorimi të tipit "Baza e të dhënave u rivendos duke përdorur një procedurë të pambështetur. Shkak i mundshëm: Rikthimi në të kaluarën i USN", gjëja e mençur për të bërë është:
- Kontrollo me dcdiag y repadmin shkalla e gabimeve dhe nëse ka "objekte të vazhdueshme".
- Kontrolloni ngjarjen 2095 dhe vlerën Dsa nuk mund të shkruhet në Regjistër.
- Vlerësoni nëse është e mundur hiqe atë DC dhe rindërtoje atë (Nëse ka tre ose më shumë DC të tjera të shëndetshme, ky është zakonisht opsioni më i mirë).
- Nëse është i vetmi DC ose kritik, ngrini një restaurimi i gjendjes së sistemit nga një kopje rezervë e pajtueshme, idealisht e kohëve të fundit dhe brenda periudhës së gurit të varrit.
Në domenet me kontrollues të shumtë, rekomandohet fuqimisht që DC-të të jenë sa më "të pastra" të jetë e mundur: pa role shtesë ose të dhëna lokale të përdoruesitNë këtë mënyrë, nëse një dështon ose korruptohet, një i ri mund të formatohet dhe promovohet bazuar në një DC tjetër ose përmes IFM, duke zvogëluar shumë kompleksitetin e rikuperimit.
Për më tepër, ia vlen të kujtojmë kufizime të tilla si kjo Kopjet e gjendjes së sistemit janë të vlefshme vetëm gjatë periudhës së gurit të varrit (60, 90, 180 ditë në varësi të konfigurimit) për të shmangur ringjalljen e objekteve të fshira, dhe që çelësat e makinës NTLM të ndryshojnë çdo 7 ditë. Në rikthimet shumë të vjetra, mund të jetë e nevojshme të rivendos llogaritë e ekipit probleme nga "Përdoruesit dhe Kompjuterët e Active Directory" ose edhe heqja e tyre dhe ribashkimi i tyre në domen.
Duke pasur procedura të vendosura për të bërë kopje rezervë të rregullt të gjendjes së sistemit, Dokumentoni qartë rolet FSMO, katalogun global dhe topologjinë e replikimitDhe testimi i hapave të restaurimit në një mjedis laboratorik janë investime kohore që kursejnë shumë dhimbje koke kur vjen dita që një kontrollues domeni korruptohet ose dikush aplikon një pamje të çastit pa menduar.
Shkrimtar i apasionuar pas botës së bajteve dhe teknologjisë në përgjithësi. Më pëlqen të ndaj njohuritë e mia përmes shkrimit, dhe kjo është ajo që do të bëj në këtë blog, duke ju treguar të gjitha gjërat më interesante në lidhje me pajisjet, softuerin, harduerin, tendencat teknologjike dhe më shumë. Qëllimi im është t'ju ndihmoj të lundroni në botën dixhitale në një mënyrë të thjeshtë dhe argëtuese.

