Pagpapanumbalik at pagbawi ng isang sirang lokal na domain controller

Kapag ang isang domain controller ay nasira o hindi naibalik nang tama, napakalaki ng takot: Nabigo ang mga pag-login, humihinto ang pag-apply ng mga GPO, at nasisira ang replikasyon nang halos walang mga pahiwatig.Ang magandang balita ay may mga malinaw na pamamaraan para sa pagbawi ng isang pisikal o virtual na DC, sa kondisyon na ang mga tinatanggap na pamamaraan ng pag-backup at pagpapanumbalik ay iginagalang.

Sa mga modernong kapaligiran ng Windows Server, ang pagpapanumbalik ng isang domain controller ay nangangailangan ng mahusay na pag-unawa sa mga konsepto tulad ng katayuan ng sistema, awtoritatibong/hindi awtoritatibong pagpapanumbalik, mga rollback ng SYSVOL, DFSR/FRS at USNKung ang mga isyung ito ay madaliang haharapin o gamit ang mga hindi tugmang kagamitan sa pag-imaging, ang resulta ay maaaring maging isang kagubatan na puno ng mga tahimik na hindi pagkakapare-pareho na napakahirap i-diagnose.

Bakit mahalaga na maayos na protektahan at i-recover ang isang domain controller

Ang Active Directory ang puso ng pagpapatotoo at awtorisasyon sa isang Windows domainIniimbak nito ang mga gumagamit, computer, grupo, ugnayan ng tiwala, mga patakaran ng grupo, mga sertipiko, at iba pang mahahalagang elemento. Ang impormasyong ito ay pangunahing nasa database. Ntds.dit, ang mga kaugnay na log file at folder SYSVOL, bukod sa iba pang mga bahagi na bumubuo sa tinatawag na "estado ng sistema".

Kabilang sa katayuan ng sistema, bukod sa iba pang mga bagay, Mga log file at data ng Active Directory, ang Windows Registry, ang system volume, SYSVOL, ang certificate database (kung mayroong CA), ang IIS metabase, mga boot file, at mga protektadong bahagi ng operating systemSamakatuwid, ang anumang seryosong estratehiya sa pagpapatuloy ng negosyo ay dapat magsama ng mga regular na backup ng estado ng sistema ng bawat data center.

Kapag nangyari ang aktwal na katiwalian ng Active Directory database, isang malubhang pagkabigo sa replikasyon, o isang problema sa mga pahintulot sa SYSVOLMaaaring huminto ang domain controller sa pagproseso ng mga query, hindi masimulan ang mga serbisyo ng Active Directory, o mag-trigger ng mga cascading error sa buong forest. Sa mga kasong ito, Ang mabilis at wastong pagbangon ang siyang makakapagpaiba sa pagitan ng isang malubhang insidente at isang matagal na sakuna..

Bago subukan ang isang restore, mahalagang malaman ang pagkakaiba sa pagitan ng isang tunay na problema sa database at mas karaniwang mga pagkabigo. Kadalasan, Ang sanhi ay nasa DNS, mga pagbabago sa network, mga firewall, o mga rutang binago gamit ang mga tool tulad ng netsh utosSamakatuwid, ipinapayong alisin muna ang mga salik na ito bago hawakan ang database ng AD.

Mga pangunahing kagamitan sa pag-diagnose at pagkontrol ng replikasyon

Kung sakaling may mga sintomas ng katiwalian o pagkabigo ng replikasyon, ang unang makatwirang hakbang ay ang pagsuri sa estado ng kapaligiran gamit ang mga katutubong tool. DCDiag, Repadmin, ReplMon (sa mga mas lumang bersyon) at ang Event Viewer Sila ang iyong pinakamahusay na kakampi bago isaalang-alang ang mga agresibong restorasyon.

may DCDiag Isinasagawa ang pangkalahatang pagsusuri sa lahat ng domain controller, na tumutukoy sa mga problema sa replication, DNS, mga serbisyo ng AD DS, atbp. Readmin Pinapayagan ka nitong tingnan ang katayuan ng replikasyon, mga kasosyo sa replikasyon, mga watermark ng USN, at tukuyin ang mga persistent object. Sa mga mas lumang bersyon ng Windows, ReplMon Nag-alok ito ng grapikong pananaw ng mga error sa pagtitiklop sa loob ng domain.

Bukod sa mga kagamitang ito, mahalagang suriin ang Event Viewer para sa “Directory Services” at “DFS Replication”. Ang mga pangyayaring tulad ng 467 at 1018 ay tumutukoy sa aktwal na katiwalian ng database, habang ang mga kaganapan 1113/1115/1114/1116 ay nauugnay sa pagpapagana o pag-disable ng input/output replication.

Kung ang isang pinaghihinalaang DC ay kailangang pansamantalang ihiwalay upang maiwasan ang pagkalat ng katiwalian, maaari nating I-disable ang papasok at palabas na replikasyon gamit ang Repadmin:

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

At para maibalik sa normal ang replikasyon, alisin lang ang mga opsyong iyon:

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

Mga sinusuportahang backup ng estado ng sistema sa mga domain controller

Para mabawi ang isang DC na may mga garantiya, mahalagang magkaroon ng Isinagawa ang mga backup ng estado ng sistema gamit ang mga tool na tugma sa Active DirectoryGinagamit ng mga tool na ito ang mga backup at restore API ng Microsoft at ang Volume Shadow Copy Service (VSS) sa isang sinusuportahang paraan.

Kabilang sa mga pinakakaraniwang solusyon ay Windows Server Backup, mga solusyon ng ikatlong partido na isinama sa VSS (tulad ng NAKIVO, Backup Exec, at iba pa)o mga lumang kagamitan tulad ng Ntbackup sa Windows 2000/2003. Sa lahat ng pagkakataon, dapat nilang igalang ang mga AD API upang matiyak ang pagkakapare-pareho ng database at mga replika nito pagkatapos ng pagpapanumbalik.

Ang Windows Server 2012 at mga mas bagong bersyon ay nagtatampok ng isang mahalagang bagong karagdagan: ID ng Henerasyon ng Hyper-V (GenID)Ang identifier na ito ay nagbibigay-daan sa isang virtual domain controller na matukoy na ang disk nito ay naibalik na sa dating punto ng panahon. Kapag nangyari ito, Bumubuo ang AD DS ng isang bagong InvocationID at tinatrato ang sitwasyon na parang naibalik ito mula sa isang matagumpay na backup.pagbibigay-alam sa mga kasosyo nito sa replikasyon, kaya pinapayagan ang ligtas na muling pagsusulat nang hindi nagkakaroon ng USN rollback.

Mahalagang igalang ang habang-buhay na lapidaIpinapahiwatig nito kung gaano katagal magagamit ang isang backup ng estado ng sistema nang hindi nanganganib na muling maibalik ang mga bagay na matagal nang nabura. Karaniwan itong 180 araw sa mga modernong bersyon, at inirerekomenda na magsagawa ng mga backup nang hindi bababa sa bawat 90 araw upang mapanatili ang sapat na margin ng kaligtasan.

Mga hindi awtorisadong pamamaraan na nagdudulot ng mga pagbaligtad ng USN

Isa sa mga pinaka-mapanganib na sanhi ng mga tahimik na hindi pagkakapare-pareho sa Active Directory ay ang Pagbabalik ng USNNangyayari ang sitwasyong ito kapag ang mga nilalaman ng AD database ay ibinalik gamit ang isang hindi sinusuportahang pamamaraan, nang hindi naibabalik ang InvocationID o naabisuhan ang mga kasosyo sa replikasyon.

Ang karaniwang senaryo ay ang pag-boot ng isang DC mula sa isang imahe ng disk o isang snapshot ng virtual machine na kinuha noonnang hindi gumagamit ng compatible na system restore. O kopyahin nang direkta ang Ntds.dit file, gumamit ng mga imaging program tulad ng Ghost, mag-boot mula sa sirang disk mirror, o muling maglagay ng storage snapshot sa array level.

Sa mga kasong ito, patuloy na ginagamit ng domain controller ang parehong InvocationID gaya ng dati, ngunit ang Pabaliktad ang lokal na counter ng USNNatatandaan ng ibang mga DC na nakatanggap ng mga pagbabago hanggang sa isang mataas na USN, kaya kapag sinubukan ng ibinalik na DC na ipadala pabalik ang mga nakilala nang USN, Naniniwala ang kanilang mga kasosyo na napapanahon sila at hindi na tumatanggap ng mga konkretong pagbabago.

Ang resulta ay ang ilang mga pagbabago (halimbawa, paggawa ng user, pagpapalit ng password, pagpaparehistro ng device, mga pagpapalit ng membership sa grupo, mga bagong DNS recordAng mga error na ito ay hindi kailanman nauulit mula sa naibalik na DC patungo sa iba pang bahagi ng network, ngunit ang mga tool sa pagsubaybay ay maaaring hindi magpakita ng malinaw na mga error. Ito ay isang lubhang mapanganib na tahimik na pagkabigo.

Para matukoy ang mga sitwasyong ito, nilo-log ng Windows Server 2003 SP1 at mga mas bagong driver ang Kaganapan sa Mga Serbisyo ng Direktoryo 2095 Kapag natukoy ang isang remote DC na nagpapadala ng mga kinikilala nang USN nang walang pagbabago sa InvocationID, ang sistema Ikinukuwarentenas nito ang apektadong DC, ihihinto ang Netlogon, at pinipigilan ang mga karagdagang pagbabago na mangyari. na hindi maaaring kopyahin nang tama.

Bilang karagdagang ebidensyang forensik, maaari itong na konsultahin sa Registry ang susi HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters at ang halaga Hindi Maisusulat ang DsaKung nakatakda ang halagang ito (hal., 0x4), ipinapahiwatig nito na ang DC ay inilagay sa isang no-write state sa pamamagitan ng USN reversal detection. Ang manu-manong pagbabago sa halagang ito upang "ayusin" ito ay ganap na hindi sinusuportahan. at iniiwan ang database sa isang permanenteng hindi pare-parehong estado.

Mga pangkalahatang estratehiya kung sakaling magkaroon ng sira o pagbabaliktad ng isang domain controller

Ang pamamaraang dapat sundin kapag nakikitungo sa isang sira o hindi wastong naibalik na DC ay nakasalalay sa ilang mga salik: Bilang ng mga domain controller sa domain/forest, pagkakaroon ng mga wastong kopya ng estado ng sistema, pagkakaroon ng iba pang mga tungkulin (FSMO, CA, global catalog), at temporal na saklaw ng problema.

Kung may iba pang malulusog na DC sa domain at Walang natatanging kritikal na datos sa nasirang domain controllerAng pinakamabilis at pinakamalinis na opsyon ay karaniwang alisin ang domain controller na iyon at muling buuin ito. Gayunpaman, kung ito lamang ang domain controller, o kung nagho-host ito ng mga sensitibong tungkulin at data, kinakailangan ang mas maingat na pagpapanumbalik (awtorisado o hindi awtorisado).

Sa pangkalahatan, ang mga pagpipilian ay:

• Sapilitang i-demote ang tiwaling DC at alisin ito sa domain, na susundan ng paglilinis ng metadata at, kung naaangkop, bagong promosyon.
• Ibalik mula sa isang wastong backup ng estado ng system, nasa makapangyarihan man o hindi makapangyarihan na paraan.
• Muling buuin ang DC mula sa isa pa gamit ang IFM (Install From Media), kapag walang bagong kopya ngunit may iba pang tamang DC.
• Paggamit ng VHD snapshot ng isang virtual DC, ilalapat ang mga karagdagang hakbang upang markahan ang database bilang naibalik mula sa backup (Naibalik ang database mula sa backup = 1) at tiyaking may nabubuong bagong InvocationID.

Kung ang isang USN rollback ay malinaw na pinaghihinalaan (halimbawa, pagkatapos ibalik ang isang VM mula sa isang snapshot nang hindi sinusunod ang mga pinakamahusay na kasanayan) at lumitaw ang kaganapan 2095, ang pinaka-makatwirang aksyon ay karaniwang Alisin ang DC na iyan sa serbisyo at huwag subukang "ayusin" ito on-site., maliban na lang kung posibleng bumalik sa isang backup ng sinusuportahang estado ng sistema na kinuha bago ang rollback.

Sapilitang demosyon at paglilinis ng metadata

Kapag ang isang domain controller ay labis na nasira na hindi na ito maaaring i-demote nang normal, o hindi wastong naibalik at gusto mong pigilan ito sa pagkalat ng mga problema, maaari kang gumamit ng sapilitang pagbaba ng posisyon.

Sa mga mas lumang bersyon, ang operasyong ito ay isinagawa gamit ang dcpromo /forceremoval, Ano Alisin ang papel na AD DS nang hindi sinusubukang kopyahin ang mga pagbabago sa iba pang bahagi ng kagubatan.Sa mga modernong kapaligiran, nagbago na ang wizard, ngunit pareho pa rin ang konsepto: alisin ang problematikong DC mula sa topolohiya ng AD nang hindi ito nakikilahok sa karagdagang replikasyon.

Pagkatapos ng sapilitang pag-downgrade, kinakailangang isagawa ang isang utos mula sa isang malusog na DC. paglilinis ng metadata gamit ang tool NtdsutilTinatanggal ng prosesong ito ang lahat ng mga sanggunian sa mga tinanggal na DC (mga bagay ng NTDS Settings, mga sanggunian ng DNS, atbp.) mula sa AD database, nang sa gayon ay walang natitirang mga labi ng "multo" upang malito ang replikasyon.

Kung ang na-degrade na controller ay may mga tungkulin sa FSMO (PDC Emulator, RID Master, Schema Master, atbp.), kakailanganin itong ilipat o agawin ang mga tungkuling iyon sa ibang DC bago o pagkatapos ng demotion, depende sa sitwasyon. Kalaunan, maaaring muling i-install ang operating system sa server na iyon at maaari itong i-promote pabalik sa isang malinis na DC.

Hindi awtoritatibo vs. awtoritatibong pagpapanumbalik sa Active Directory

Kapag may magagamit na wastong kopya ng estado ng sistema, maaaring gawin ang pagbawi ng AD sa dalawang paraan: hindi awtoritatibo at awtoritatiboAng pag-unawa sa pagkakaiba ay mahalaga upang hindi makaligtaan ang mga kamakailang pagbabago o maulit ang mga lumang data.

Sa isang hindi awtorisadong pagpapanumbalikAng DC ay ibinabalik sa nakaraang punto, ngunit kapag nagsimula na ito, Ang iba pang mga domain controller ay itinuturing na sanggunianSa madaling salita, pagkatapos magsimula, ang naibalik na DC ay humihiling ng papasok na replikasyon at ina-update ang database nito kasama ang anumang nawawalang pagbabago mula sa iba pang mga DC. Ang opsyong ito ay mainam kapag May iba pang malulusog na controller, at gusto naming mahabol sila ng naibalik na controller..

Sa isang awtoritaryan na pagpapanumbalikGayunpaman, tahasang nakasaad na Ang naibalik na datos ang dapat na mangibabaw. kaysa sa kung ano ang mayroon ang iba pang mga DC. Nangangahulugan ito na, pagkatapos ng pag-restore, ang mga na-recover na object ay magkakaroon ng mas mataas na numero ng bersyon upang mapilitan silang kopyahin mula sa DC na iyon patungo sa iba pang bahagi ng domain. Ito ang naaangkop na pagpipilian kapag Hindi sinasadyang nabura natin ang mga bagay o OU, o gusto nating ibalik ang mga nilalaman ng SYSVOL at GPO sa dating estado at ipa-replicate ito..

Isang mahalagang detalye ay ang awtoritatibong pagpapanumbalik ay hindi kinakailangang para sa buong database. Gamit ang utility Ntdsutil Ang mga indibidwal na bagay, mga subtree (hal., isang OU), o ang buong domain ay maaaring markahan bilang awtoritatibo. Nag-aalok ito ng malaking kakayahang umangkop para sa, halimbawa, kunin lamang ang isang user, isang grupo, isang OU o ang subtree na dc=mycompany,dc=local.

Pangkalahatang pamamaraan para sa pagpapanumbalik ng katayuan ng sistema sa isang DC

Ang pangunahing pamamaraan para sa pagpapanumbalik ng estado ng sistema ng isang DC (pisikal man o virtual) gamit ang mga katugmang tool ay palaging magkatulad: Mag-boot sa Directory Services Restore Mode (DSRM), i-restore gamit ang backup tool, at i-restart.

Sa madaling salita, ang mga karaniwang hakbang para sa isang virtual domain controller ay:

1. Simulan ang virtual machine sa Windows Boot Manager (karaniwan ay sa pamamagitan ng pagpindot sa F5/F8 habang nagsisimula). Kung ang VM ay pinamamahalaan ng isang hypervisor, maaaring kailanganing i-pause ang makina upang makuha ang keystroke.
2. Sa mga advanced na opsyon sa boot, piliin ang Mode ng pagpapanumbalik ng mga serbisyo sa direktoryo (Mode ng Pagpapanumbalik ng mga Serbisyo sa Direktoryo). Sinisimulan ng mode na ito ang server nang hindi ini-mount ang database ng Active Directory sa isang gumaganang paraan.
3. Mag-log in gamit ang DSRM administrator account tinukoy noong orihinal na promosyon ng DC (hindi gamit ang isang karaniwang domain administrator account).
4. Patakbuhin ang tool sa pag-backup ginamit (Windows Server Backup, NAKIVO o iba pang katugma) at piliing ibalik ang estado ng system sa nais na backup point.
5. Kumpletuhin ang restoration wizard at I-restart ang DC sa normal na modeSa isang hindi awtoritatibong pagpapanumbalik, sisimulan ng server ang replikasyon upang makahabol sa iba pang mga DC.

Kapag pinag-uusapan natin ang mga produktong backup ng third-party, tulad ng NAKIVO Backup at ReplikasyonNakikilala ng "app-aware" mode nito na ang makinang nire-recover ay isang DC at awtomatikong isaayos ang proseso upang mapanatili ang pagkakapare-pareho ng ADSa karamihan ng mga sitwasyon na may maraming controller, sapat na ang isang buong pagbawi sa non-authoritative mode.

Awtorisadong pagpapanumbalik gamit ang Ntdsutil

Kung gusto mong mauna ang mga pagbabago sa naibalik na domain controller kaysa sa iba, kailangan mong magdagdag ng isa pang hakbang pagkatapos ng hindi awtoritatibong pagpapanumbalik: gamitin ang Ntdsutil upang markahan ang mga bagay bilang awtoritatibo.

Ang pinasimpleng daloy ay magiging:

1. Ibalik ang estado ng sistema sa karaniwang paraan at iwanan ang server na naka-on pa rin Mode ng DSRM (Huwag munang i-restart sa normal mode).
2. Buksan ang a command prompt na may mataas na pribilehiyo at tumakbo ntdsutil.
3. I-activate ang AD instance gamit ang i-activate ang instance ntds.
4. Pagpasok sa konteksto ng awtoritatibong pagpapanumbalik nang may awtoritatibong pagpapanumbalik.
5. Gumamit ng mga utos tulad ng restore object <DN_objeto> o restore subtree <DN_subarbol>, kung saan ang DN ay ang natatanging pangalan ng bagay o subtree na awtoritatibong ibabalik.
6. Kumpirmahin ang transaksyon at, kapag nakumpleto na, I-restart ang DC sa normal na mode upang ang mga minarkahang bagay ay maulit nang may prayoridad kaysa sa iba pang bahagi ng domain.

Ang ganitong uri ng pagpapanumbalik ay nangangailangan ng matinding pag-iingat. Kung ang buong domain ay awtoritatibong naibalik at ang backup ay luma naMay panganib na mawala ang mga lehitimong pagbabagong ginawa pagkatapos ng backup (halimbawa, paggawa ng user, pagpapalit ng password, o mga pagbabago sa grupo). Samakatuwid, karaniwang gawain na limitahan ang mga awtoritatibong pagpapanumbalik sa mga mahigpit na kinakailangang bagay o puno lamang.

Pagpapanumbalik at pagbawi ng SYSVOL (FRS vs DFSR)

Ang SYSVOL ay isang mahalagang bahagi ng domain controller: Nag-iimbak ito ng mga startup script, mga patakaran ng grupo, mga template ng seguridad, at iba pang mahahalagang pinagsasaluhang mapagkukunan.Ang pagkabigo sa iyong mga pahintulot, katiwalian ng file, o mga problema sa pagtitiklop ay maaaring maging sanhi ng hindi magamit na mga GPO o magdulot ng hindi pangkaraniwang pag-uugali sa mga kliyente.

Depende sa bersyon ng Windows Server at sa katayuan ng paglipat, maaaring kopyahin ang SYSVOL ng FRS (Serbisyo ng Pagkopya ng File) o para sa DFSR (Distributed File System Replication)Ang pamamaraan para sa isang awtoritatibong pagpapanumbalik ng SYSVOL ay nag-iiba depende sa kung alin sa dalawa ang ginagamit.

Upang matukoy ito, maaari mong suriin ang susi sa Registry. HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DFSR\Parameters\SysVols\Migrating Sysvols\LocalStateKung umiiral ang subkey na ito at ang halaga nito ay 3 (DELETED), ginagamit ang DFSR. Kung hindi ito umiiral o iba ang halaga nito, nakikitungo tayo sa isang kapaligiran na gumagamit pa rin ng FRS.

Sa mga kapaligirang may FRS, ang awtoritatibong pagbawi ng SYSVOL ay karaniwang kinabibilangan ng pagsasaayos ng halaga Mga Burflag en HKLM\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process sa isang partikular na halaga (hal., 212 decimal / 0xD4 hex) upang ipahiwatig na ang DC na ito ang mapagkakatiwalaang pinagmulan.

Kung ang SYSVOL ay kinokopya ng DFSR, ang proseso ay medyo mas detalyado: kinabibilangan ito ng paggamit ng ADSIEdit para baguhin ang mga bagay ng subscription sa SYSVOL (mga katangian Pinagana ang msDFSR y msDFSR-Mga Pagpipilian) sa awtoritatibong DC at sa iba pa, pilitin ang pagkopya ng AD, isagawa dfsrdiag pollad at kumpirmahin sa event log ang paglitaw ng mga pangyayari 4114, 4602, 4614 at 4604 na nagpapatunay na ang SYSVOL ay na-initialize at na-replicate nang tama.

Pagbawi ng mga virtual domain controller mula sa VHD

Sa mga virtualized na kapaligiran, karaniwan nang magkaroon ng Mga VHD/VHDX na file ng mga domain controllerKung wala kang backup ng estado ng sistema ngunit mayroon kang gumaganang "lumang" VHD, maaari kang mag-mount ng bagong DC mula sa disk na iyon, bagaman dapat mo itong gawin nang may pag-iingat upang maiwasan ang pagdudulot ng USN rollback.

Ang rekomendasyon ay Huwag simulan ang VM na iyon nang direkta sa normal na modeSa halip, dapat kang mag-boot mula sa nakaraang VHD sa DSRMBuksan ang Registry Editor at mag-navigate sa HKLM\SYSTEM\CurrentControlSet\Services\NTDS\ParametersDoon, ipinapayong suriin ang halaga Bilang ng mga nakaraang pagpapanumbalik ng DSA (kung mayroon man) at, higit sa lahat, lumikha ng isang bagong halaga ng DWORD (32-bit) na tinatawag na Naibalik na ang database mula sa backup may halaga 1.

Sa pamamagitan ng pagpili sa halagang ito, sasabihin sa Active Directory na ang database ay naibalik na mula sa isang backup, na siyang pumipilit sa pagbuo ng isang bagong InvocationID kapag nag-boot sa normal na modeSa ganitong paraan, binibigyang-kahulugan ito ng ibang mga DC bilang isang bagong instance at wastong inaayos ang kanilang mga watermark ng replikasyon, na pumipigil sa pag-rollback ng USN.

Pagkatapos i-restart ang DC sa normal na mode, ipinapayong suriin ang Event Viewer, partikular ang log ng Mga serbisyo sa direktoryo, hinahanap ang kaganapan 1109Kinukumpirma ng kaganapang ito na nagbago ang katangiang InvocationID ng server at ipinapakita ang mga luma at bagong halaga, pati na rin ang pinakamataas na USN sa oras ng pag-backup. Bukod pa rito, ang halaga ng Bilang ng mga nakaraang pagpapanumbalik ng DSA Dapat sana dinagdagan pa ito ng isa.

Kung hindi lumalabas ang mga kaganapang ito, o hindi tumaas ang bilang, dapat mong suriin ang mga bersyon ng operating system at mga Service Pack, dahil Ang ilang partikular na gawi sa pagpapanumbalik ay nakadepende sa mga partikular na patchSa anumang kaso, palaging ipinapayong magtrabaho sa isang kopya ng orihinal na VHD, na pinapanatili ang isang buo na bersyon kung sakaling kailangang ulitin ang proseso.

Mga praktikal na senaryo at karagdagang mga rekomendasyon

Sa pagsasagawa, ang mga problema ng katiwalian o hindi wastong pagpapanumbalik ay kadalasang lumilitaw sa pang-araw-araw na mga sitwasyon: Manu-manong pagbabago ng mga pahintulot sa SYSVOL, mga pagtatangkang i-update ang mga template ng ADMX/ADML, mga pagbabago sa GPO na hindi nagagalawatbp. Medyo madaling magdulot ng mga hindi pagkakapare-pareho kung manu-manong binabago ang mga nakabahaging folder, tulad ng SYSVOL\Policies nang hindi nirerespeto ang replikasyon.

Sa kaganapan ng isang pangunahing DC na may sirang replikasyon (parehong AD data at SYSVOL) at mga mensahe sa pagsubaybay na uri ng "Naibalik ang database gamit ang isang hindi sinusuportahang pamamaraan. Posibleng sanhi: USN rollback", ang matalinong gawin ay:

• Suriin gamit ang dcdiag y repadmin ang lawak ng mga pagkakamali at kung mayroong "mga nagpapatuloy na bagay".
• Suriin ang kaganapan 2095 at ang halaga Hindi Maisusulat ang Dsa sa Rehistro.
• Suriin kung posible tanggalin ang DC na iyon at muling itayo (Kung mayroong tatlo o higit pang iba pang malulusog na DC, ito ay karaniwang ang pinakamahusay na opsyon).
• Kung ito lang ang DC o kritiko, magtaas ng pagpapanumbalik ng estado ng sistema mula sa isang tugmang backup, mas mainam kung bago pa lamang at nasa loob ng panahon ng lapida.

Sa mga domain na may maraming controller, lubos na inirerekomenda na ang mga DC ay maging "puro" hangga't maaari: walang karagdagang mga tungkulin o lokal na data ng userSa ganitong paraan, kung ang isa ay mabigo o masira, ang isang bago ay maaaring i-format at i-promote batay sa isa pang DC o sa pamamagitan ng IFM, na lubos na nakakabawas sa pagiging kumplikado ng pagbawi.

Bukod pa rito, mahalagang tandaan ang mga limitasyon tulad ng Ang mga kopya ng estado ng sistema ay may bisa lamang sa panahon ng lapida (60, 90, 180 araw depende sa configuration) upang maiwasan ang muling pagbuhay ng mga nabura na bagay, at ang mga NTLM machine key ay nagbabago bawat 7 araw. Sa mga lumang restore, maaaring kailanganin na i-reset ang mga account ng koponan mga problema mula sa "Mga Gumagamit at Computer ng Active Directory" o kahit na pag-aalis ng mga ito at muling pagsasama sa kanila sa domain.

Ang pagkakaroon ng mga pamamaraan para sa regular na pag-backup ng estado ng sistema, Malinaw na idokumento ang mga tungkulin ng FSMO, pandaigdigang katalogo, at topolohiya ng replikasyonAt ang pagsubok sa mga hakbang sa pagpapanumbalik sa isang kapaligirang laboratoryo ay mga pamumuhunan sa oras na nakakatipid ng maraming sakit ng ulo kapag dumating ang araw na ang isang domain controller ay masira o may mag-apply ng snapshot nang hindi nag-iisip.