Memulihkan dan memulihkan pengawal domain setempat yang rosak

Apabila pengawal domain rosak atau dipulihkan secara salah, ketakutannya sangat besar: Log masuk gagal, GPO berhenti digunakan, dan replikasi rosak tanpa petunjuk.Berita baiknya ialah terdapat prosedur yang jelas untuk memulihkan DC fizikal atau maya, dengan syarat kaedah sandaran dan pemulihan yang diterima dipatuhi.

Dalam persekitaran Windows Server moden, memulihkan pengawal domain memerlukan pemahaman yang baik tentang konsep seperti status sistem, pemulihan berwibawa/tidak berwibawa, pengembalian SYSVOL, DFSR/FRS dan USNJika isu-isu ini ditangani dengan tergesa-gesa atau dengan alat pengimejan yang tidak serasi, hasilnya boleh menjadi hutan yang penuh dengan ketidakkonsistenan senyap yang sangat sukar untuk didiagnosis.

Mengapakah penting untuk melindungi dan memulihkan pengawal domain dengan betul

Active Directory ialah pusat pengesahan dan kebenaran dalam domain WindowsIa menyimpan pengguna, komputer, kumpulan, hubungan kepercayaan, dasar kumpulan, sijil dan elemen penting yang lain. Maklumat ini terletak terutamanya dalam pangkalan data. Ntds.dit, fail log dan folder yang berkaitan SYSVOL, antara komponen lain yang membentuk apa yang dipanggil "keadaan sistem".

Status sistem tersebut antara lain merangkumi Fail dan data log Active Directory, Windows Registry, volum sistem, SYSVOL, pangkalan data sijil (jika CA wujud), metabase IIS, fail but dan komponen sistem pengendalian yang dilindungiOleh itu, sebarang strategi kesinambungan perniagaan yang serius mesti merangkumi sandaran berkala bagi keadaan sistem setiap pusat data.

Apabila kerosakan sebenar pangkalan data Active Directory berlaku, kegagalan replikasi yang serius atau masalah dengan kebenaran pada SYSVOLPengawal domain mungkin berhenti memproses pertanyaan, gagal memulakan perkhidmatan Active Directory atau mencetuskan ralat bertingkat di seluruh forest. Dalam kes ini, Pemulihan yang cepat dan betul membezakan antara insiden serius dan bencana yang berpanjangan..

Sebelum cuba memulihkan, adalah penting untuk membezakan antara masalah pangkalan data yang tulen dan kegagalan yang lebih biasa. Selalunya, Puncanya terletak pada DNS, perubahan rangkaian, tembok api atau laluan yang diubah suai dengan alat seperti arahan netshOleh itu, adalah dinasihatkan untuk menolak faktor-faktor ini terlebih dahulu sebelum menyentuh pangkalan data AD.

Alat kawalan diagnostik dan replikasi asas

Sekiranya terdapat simptom kerosakan atau kegagalan replikasi, langkah pertama yang wajar adalah memeriksa keadaan persekitaran menggunakan alat asli. DCDiag, Repadmin, ReplMon (dalam versi lama) dan Pemapar Peristiwa Mereka adalah sekutu terbaik anda sebelum mempertimbangkan pemulihan yang agresif.

dengan DCDiag Pemeriksaan umum semua pengawal domain dilakukan, mengenal pasti masalah dengan replikasi, DNS, perkhidmatan AD DS, dll. Pentadbiran semula Ia membolehkan anda melihat status replikasi, rakan kongsi replikasi, tera air USN dan mengesan objek berterusan. Dalam versi Windows yang lebih lama, ReplMon Ia menawarkan pandangan grafik tentang ralat replikasi dalam domain.

Selain alat-alat ini, adalah penting untuk menyemak Pemapar Peristiwa untuk “Perkhidmatan Direktori” dan “Replikasi DFS”. Peristiwa seperti 467 dan 1018 menunjukkan kerosakan sebenar pangkalan data, manakala peristiwa 1113/1115/1114/1116 berkaitan dengan mendayakan atau melumpuhkan replikasi input/output.

Jika seorang DC yang disyaki perlu diasingkan sementara untuk mencegahnya daripada menyebarkan rasuah, kita boleh Lumpuhkan replikasi masuk dan keluar dengan Repadmin:

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

Dan untuk memulihkan replikasi kepada normal, cuma alih keluar pilihan tersebut:

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

Sandaran keadaan sistem yang disokong pada pengawal domain

Untuk dapat mendapatkan semula DC dengan jaminan, adalah penting untuk mempunyai Sandaran keadaan sistem dilakukan menggunakan alat yang serasi dengan Active DirectoryAlatan ini menggunakan API sandaran dan pemulihan Microsoft dan Perkhidmatan Salinan Bayangan Kelantangan (VSS) dengan cara yang disokong.

Antara penyelesaian yang paling biasa ialah Sandaran Pelayan Windows, penyelesaian pihak ketiga yang disepadukan dengan VSS (seperti NAKIVO, Backup Exec dan lain-lain)atau utiliti lama seperti Ntbackup dalam Windows 2000/2003. Dalam semua kes, mereka mesti mematuhi API AD untuk memastikan konsistensi pangkalan data dan replikanya selepas pemulihan.

Windows Server 2012 dan versi yang lebih baharu menampilkan tambahan baharu yang penting: ID Penjanaan Hyper-V (GenID)Pengecam ini membolehkan pengawal domain maya mengesan bahawa cakeranya telah digulung kembali ke titik masa sebelumnya. Apabila ini berlaku, AD DS menjana ID Penyerahan baharu dan melayan situasi seolah-olah ia telah dipulihkan daripada sandaran yang berjaya.memaklumkan rakan replikasinya, sekali gus membolehkan penulisan semula yang selamat tanpa mengalami pengembalian USN.

Adalah penting untuk menghormati seumur hidup batu nisanIni menunjukkan berapa lama sandaran keadaan sistem boleh digunakan tanpa mengambil risiko pengenalan semula objek yang telah dipadamkan sejak sekian lama. Ia biasanya 180 hari dalam versi moden, dan disyorkan untuk melakukan sandaran sekurang-kurangnya setiap 90 hari untuk mengekalkan margin keselamatan yang mencukupi.

Kaedah tanpa kebenaran yang menyebabkan pembalikan USN

Salah satu punca paling berbahaya bagi ketidakkonsistenan senyap dalam Active Directory ialah Pengurangan USNSituasi ini berlaku apabila kandungan pangkalan data AD diundurkan menggunakan teknik yang tidak disokong, tanpa InvocationID dipulihkan atau rakan kongsi replikasi dimaklumkan.

Senario biasa adalah untuk boot DC daripada gambar cakera atau petikan mesin maya yang diambil pada masa lalutanpa menggunakan pemulihan sistem yang serasi. Atau salin fail Ntds.dit secara langsung, gunakan program pengimejan seperti Ghost, but daripada cermin cakera yang rosak atau gunakan semula petikan storan pada peringkat tatasusunan.

Dalam kes ini, pengawal domain terus menggunakan InvocationID yang sama seperti sebelumnya, tetapi Kaunter USN tempatan terbalik ke belakangDC lain ingat menerima perubahan sehingga USN yang tinggi, jadi apabila DC yang dibalikkan cuba menghantar kembali USN yang telah dikenali, Rakan kongsi mereka percaya bahawa mereka sudah mengikuti perkembangan terkini dan berhenti menerima perubahan konkrit.

Hasilnya ialah pengubahsuaian tertentu (contohnya, penciptaan pengguna, perubahan kata laluan, pendaftaran peranti, perubahan keahlian kumpulan, rekod DNS baharuRalat ini tidak pernah direplikasi dari DC yang dipulihkan ke seluruh rangkaian, tetapi alat pemantauan mungkin tidak menunjukkan ralat yang jelas. Ini adalah kegagalan senyap yang sangat berbahaya.

Untuk mengesan situasi ini, pemacu Windows Server 2003 SP1 dan yang lebih baharu akan merekodkan Acara Perkhidmatan Direktori 2095 Apabila DC jauh dikesan menghantar USN yang telah diakui tanpa perubahan dalam InvocationID, sistem Ia mengkuarantin DC yang terjejas, menjeda Netlogon dan menghalang perubahan selanjutnya daripada berlaku. yang tidak dapat direplikasi dengan betul.

Sebagai bukti forensik tambahan, ia boleh untuk dirujuk di Pejabat Pendaftaran kunci HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters dan nilai Dsa Tidak Boleh DitulisJika nilai ini ditetapkan (cth., 0x4), ia menunjukkan bahawa DC telah dimasukkan ke dalam keadaan tanpa tulis melalui pengesanan pembalikan USN. Mengubah suai nilai ini secara manual untuk "memperbaikinya" adalah tidak disokong sepenuhnya. dan meninggalkan pangkalan data dalam keadaan tidak konsisten secara kekal.

Strategi umum sekiranya berlaku kerosakan atau pembalikan pengawal domain

Prosedur yang perlu diikuti apabila berurusan dengan DC yang rosak atau dipulihkan dengan salah bergantung kepada beberapa faktor: Bilangan pengawal domain dalam domain/forest, ketersediaan salinan sah keadaan sistem, kehadiran peranan lain (FSMO, CA, katalog global), dan skop temporal masalah.

Jika terdapat DC sihat lain dalam domain dan Tiada data kritikal unik pada pengawal domain yang rosakPilihan terpantas dan paling bersih biasanya adalah dengan mengalih keluar pengawal domain tersebut dan membinanya semula. Walau bagaimanapun, jika ia satu-satunya pengawal domain, atau jika ia mengehos peranan dan data sensitif, pemulihan yang lebih teliti (berwibawa atau tidak berwibawa) adalah perlu.

Secara umum, pilihannya adalah:

• Turunkan DC yang korup secara paksa dan keluarkannya dari domain, diikuti dengan pembersihan metadata dan, jika berkenaan, promosi baharu.
• Pulihkan daripada sandaran keadaan sistem yang sah, sama ada dalam mod berwibawa atau tidak berwibawa.
• Bina semula DC daripada yang lain menggunakan IFM (Pasang Daripada Media), apabila tiada salinan terkini tetapi terdapat DC lain yang betul.
• Menggunakan petikan VHD DC maya, menggunakan langkah tambahan untuk menandakan pangkalan data sebagai dipulihkan daripada sandaran (Pangkalan data dipulihkan daripada sandaran = 1) dan memastikan bahawa ID Penyerahan baharu dijana.

Jika pengembalian USN disyaki dengan jelas (contohnya, selepas memulihkan VM daripada snapshot tanpa mengikuti amalan terbaik) dan peristiwa 2095 muncul, tindakan yang paling bijak biasanya adalah untuk Tanggalkan DC tersebut daripada perkhidmatan dan jangan cuba "membaikinya" di lokasi., melainkan jika boleh kembali kepada sandaran keadaan sistem yang disokong yang diambil sebelum pengembalian.

Penurunan pangkat secara paksa dan pembersihan metadata

Apabila pengawal domain rosak teruk sehingga tidak dapat diturunkan pangkat secara normal, atau telah dipulihkan secara salah dan anda ingin menghalangnya daripada menyebarkan masalah, anda boleh menggunakan cara penurunan pangkat secara paksa.

Dalam versi lama, operasi ini dilakukan dengan dcpromo /forceremoval, apa Alih keluar peranan AD DS tanpa cuba meniru perubahan pada seluruh hutan.Dalam persekitaran moden, wizard telah berubah, tetapi konsepnya adalah sama: untuk mengalih keluar DC yang bermasalah daripada topologi AD tanpa ia terlibat dalam replikasi selanjutnya.

Selepas penurunan taraf secara paksa, adalah wajib untuk melaksanakan arahan daripada DC yang sihat. pembersihan metadata menggunakan alat tersebut NtdsutilProses ini mengalih keluar semua rujukan kepada DC yang dipadam (objek Tetapan NTDS, rujukan DNS, dsb.) daripada pangkalan data AD, supaya tiada sisa "hantu" yang tinggal untuk mengelirukan replikasi.

Jika pengawal yang terdegradasi mempunyai peranan FSMO (Emulator PDC, RID Master, Schema Master, dll.), adalah perlu untuk memindahkan atau merampas peranan tersebut ke DC lain sebelum atau selepas penurunan pangkat, bergantung pada situasi. Kemudian, sistem pengendalian boleh dipasang semula pada pelayan tersebut dan ia boleh dinaik taraf kembali kepada DC yang bersih.

Pemulihan tidak berwibawa vs. berwibawa dalam Active Directory

Apabila salinan keadaan sistem yang sah tersedia, pemulihan AD boleh dilakukan dalam dua cara: tidak berwibawa dan berwibawaMemahami perbezaan adalah kunci untuk tidak terlepas perubahan terkini atau mereplikasi data ketinggalan zaman.

Dalam a pemulihan tidak berwibawaDC dikembalikan ke titik sebelumnya, tetapi sebaik sahaja ia bermula, Pengawal domain lain dianggap sebagai rujukanDalam erti kata lain, selepas permulaan, DC yang dipulihkan meminta replikasi masuk dan mengemas kini pangkalan datanya dengan sebarang perubahan yang hilang daripada DC lain. Pilihan ini sesuai apabila Terdapat pengawal lain yang sihat, dan kami mahu pengawal yang telah dipulihkan dapat mengejar mereka..

Dalam a pemulihan autoritarianWalau bagaimanapun, dinyatakan secara eksplisit bahawa Data yang dipulihkan adalah apa yang sepatutnya diutamakan. melebihi apa yang dimiliki oleh DC lain. Ini bermakna, selepas pemulihan, objek yang dipulihkan akan mempunyai nombor versi yang lebih tinggi untuk memaksanya direplikasi dari DC tersebut ke seluruh domain. Ia adalah pilihan yang sesuai apabila Kami telah memadam objek atau OU secara tidak sengaja, atau kami mahu mengembalikan kandungan SYSVOL dan GPO kepada keadaan sebelumnya dan mereplikasinya..

Satu perincian penting ialah pemulihan berwibawa tidak semestinya untuk keseluruhan pangkalan data. Dengan utiliti Ntdsutil Objek individu, subpokok (cth., OU), atau keseluruhan domain boleh ditanda sebagai autoritatif. Ini menawarkan fleksibiliti yang besar untuk, contohnya, dapatkan hanya pengguna, kumpulan, OU atau subpokok dc=mycompany,dc=local.

Prosedur umum untuk memulihkan status sistem dalam DC

Skim asas untuk memulihkan keadaan sistem DC (sama ada fizikal atau maya) dengan alat yang serasi sentiasa serupa: But ke Mod Pemulihan Perkhidmatan Direktori (DSRM), pulihkan menggunakan alat sandaran dan mulakan semula.

Secara ringkasnya, langkah-langkah biasa untuk pengawal domain maya ialah:

1. Mulakan mesin maya dalam Pengurus But Windows (biasanya dengan menekan F5/F8 semasa permulaan). Jika VM diuruskan oleh hypervisor, mungkin perlu menjeda mesin untuk menangkap ketukan kekunci.
2. Dalam pilihan but lanjutan, pilih Mod pemulihan perkhidmatan direktori (Mod Pemulihan Perkhidmatan Direktori). Mod ini memulakan pelayan tanpa memasang pangkalan data Active Directory secara berfungsi.
3. Log masuk dengan akaun pentadbir DSRM ditakrifkan semasa promosi asal DC (bukan dengan akaun pentadbir domain standard).
4. Jalankan alat sandaran digunakan (Windows Server Backup, NAKIVO atau yang serasi) dan pilih untuk memulihkan keadaan sistem ke titik sandaran yang diingini.
5. Lengkapkan wizard pemulihan dan Mulakan semula DC dalam mod biasaDalam pemulihan yang tidak berwibawa, pelayan akan memulakan replikasi untuk mengejar DC yang lain.

Apabila kita bercakap tentang produk sandaran pihak ketiga, seperti Sandaran & Replikasi NAKIVOMod "sedar aplikasi"nya dapat mengenali bahawa mesin yang dipulihkan adalah DC dan melaraskan proses secara automatik untuk mengekalkan konsistensi ADDalam kebanyakan senario dengan berbilang pengawal, pemulihan penuh dalam mod tidak berwibawa adalah mencukupi.

Pemulihan berwibawa dengan Ntdsutil

Jika anda mahu perubahan pada pengawal domain yang dipulihkan diutamakan berbanding yang lain, anda perlu menambah langkah tambahan selepas pemulihan bukan autoritatif: gunakan Ntdsutil untuk menandakan objek sebagai berwibawa.

Aliran yang dipermudahkan ialah:

1. Pulihkan keadaan sistem dengan cara standard dan biarkan pelayan masih dalam keadaan Mod DSRM (Jangan mulakan semula dalam mod biasa lagi).
2. Buka arahan gesaan dengan keistimewaan yang tinggi dan lari ntdsutil.
3. Aktifkan tika AD dengan aktifkan ntds contoh.
4. Memasuki konteks pemulihan berwibawa dengan pemulihan berwibawa.
5. Gunakan arahan seperti restore object <DN_objeto> o restore subtree <DN_subarbol>, yang mana DN ialah nama tersendiri bagi objek atau subpokok yang akan dipulihkan secara sah.
6. Sahkan transaksi dan, setelah selesai, Mulakan semula DC dalam mod biasa supaya objek yang ditanda direplikasi dengan keutamaan berbanding seluruh domain.

Jenis pemulihan ini memerlukan perhatian yang teliti. Jika keseluruhan domain dipulihkan secara sah dan sandaran sudah lamaTerdapat risiko kehilangan perubahan sah yang dibuat selepas sandaran (contohnya, penciptaan pengguna, perubahan kata laluan atau pengubahsuaian kumpulan). Oleh itu, adalah amalan biasa untuk mengehadkan pemulihan berwibawa hanya kepada objek atau pokok yang sangat diperlukan.

Pemulihan dan pemulihan SYSVOL (FRS vs DFSR)

SYSVOL ialah komponen utama pengawal domain: Ia menyimpan skrip permulaan, dasar kumpulan, templat keselamatan dan sumber kongsi penting yang lain.Kegagalan dalam kebenaran anda, kerosakan fail atau masalah replikasi boleh menyebabkan GPO tidak dapat digunakan atau menyebabkan tingkah laku tidak menentu pada klien.

Bergantung pada versi Windows Server dan status migrasi, SYSVOL mungkin direplikasi oleh FRS (Perkhidmatan Replikasi Fail) atau oleh DFSR (Replikasi Sistem Fail Teragih)Prosedur untuk pemulihan SYSVOL yang berwibawa berbeza-beza bergantung pada yang mana satu antara kedua-duanya sedang digunakan.

Untuk menentukan perkara ini, anda boleh menyemak kunci dalam Pendaftaran. HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DFSR\Parameters\SysVols\Migrating Sysvols\LocalStateJika subkunci ini wujud dan nilainya ialah 3 (DELETED), DFSR sedang digunakan. Jika ia tidak wujud atau nilainya berbeza, kita berurusan dengan persekitaran yang masih menggunakan FRS.

Dalam persekitaran dengan FRS, pemulihan SYSVOL yang berwibawa biasanya melibatkan pelarasan nilai Bendera Burflags en HKLM\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process kepada nilai tertentu (cth., 212 perpuluhan / 0xD4 heksadesimal) untuk menunjukkan bahawa DC ini ialah sumber yang berwibawa.

Jika SYSVOL direplikasi oleh DFSR, prosesnya agak lebih terperinci: ia melibatkan penggunaan Suntingan ADSI untuk mengubah suai objek langganan SYSVOL (atribut Didayakan msDFSR y Pilihan-msDFSR) pada DC yang berwibawa dan pada yang lain, paksa replikasi AD, laksanakan dfsrdiag pollad dan sahkan dalam log peristiwa kemunculan peristiwa 4114, 4602, 4614 dan 4604 yang mengesahkan bahawa SYSVOL telah diinisialisasi dan direplikasi dengan betul.

Memulihkan pengawal domain maya daripada VHD

Dalam persekitaran maya, adalah sangat biasa untuk mempunyai Fail VHD/VHDX pengawal domainJika anda tidak mempunyai sandaran keadaan sistem tetapi mempunyai VHD "lama" yang berfungsi, anda boleh memasang DC baharu daripada cakera tersebut, walaupun anda mesti melakukannya dengan berhati-hati untuk mengelakkan daripada menyebabkan pengembalian USN.

Syornya adalah Jangan mulakan VM itu secara langsung dalam mod biasaSebaliknya, anda harus boot dari VHD sebelumnya dalam DSRMBuka Editor Pendaftaran dan navigasi ke HKLM\SYSTEM\CurrentControlSet\Services\NTDS\ParametersDi sana, adalah dinasihatkan untuk menyemak nilainya Bilangan pemulihan DSA sebelumnya (jika ia wujud) dan, yang paling penting, cipta nilai DWORD (32-bit) baharu yang dipanggil Pangkalan data dipulihkan daripada sandaran dengan nilai 1.

Dengan memilih nilai ini, Active Directory diberitahu bahawa pangkalan data telah dipulihkan daripada sandaran, yang memaksa menjana ID Penyerahan baharu semasa boot dalam mod biasaDengan cara ini, DC lain mentafsirkannya sebagai contoh baharu dan melaraskan tera air replikasi mereka dengan betul, menghalang pengembalian USN.

Selepas memulakan semula DC dalam mod biasa, adalah dinasihatkan untuk menyemak Pemapar Peristiwa, khususnya log Perkhidmatan direktori, mencari Peristiwa 1109Peristiwa ini mengesahkan bahawa atribut InvocationID pelayan telah berubah dan memaparkan nilai lama dan baharu, serta USN tertinggi semasa sandaran. Selain itu, nilai Bilangan pemulihan DSA sebelumnya Sepatutnya ia ditambah satu.

Jika peristiwa ini tidak muncul, atau kiraan tidak meningkat, anda harus menyemak versi sistem pengendalian dan Pek Perkhidmatan, kerana Tingkah laku pemulihan tertentu bergantung pada tampalan tertentuWalau apa pun, adalah dinasihatkan untuk sentiasa mengusahakan salinan VHD asal, menyimpan versi yang utuh sekiranya proses itu perlu diulang.

Senario praktikal dan cadangan tambahan

Dalam praktiknya, masalah rasuah atau pemulihan yang tidak betul sering muncul dalam senario harian: Pengubahsuaian manual kebenaran dalam SYSVOL, percubaan untuk mengemas kini templat ADMX/ADML, perubahan GPO yang tidak direplikasidsb. Agak mudah untuk menyebabkan ketidakkonsistenan jika folder kongsi diubah suai secara manual, seperti SYSVOL\Policies tanpa menghormati replikasi.

Sekiranya berlaku DC utama dengan replikasi yang rosak (kedua-dua data AD dan SYSVOL) dan mesej pemantauan jenis "Pangkalan data telah dipulihkan menggunakan prosedur yang tidak disokong. Kemungkinan punca: pengembalian USN", perkara yang bijak untuk dilakukan ialah:

• Periksa dengan dcdiag y repadmin tahap ralat dan sama ada terdapat "objek berterusan".
• Semak peristiwa 2095 dan nilainya Dsa Tidak Boleh Ditulis dalam Pejabat Pendaftaran.
• Nilaikan jika ia mungkin keluarkan DC itu dan bina semula (Jika terdapat tiga atau lebih DC sihat yang lain, ini biasanya merupakan pilihan terbaik).
• Jika ia satu-satunya DC atau pengkritik, bangkitkan pemulihan keadaan sistem daripada sandaran yang serasi, idealnya yang terkini dan dalam tempoh batu nisan.

Dalam domain dengan berbilang pengawal, sangat disyorkan agar DC menjadi "tulen" yang mungkin: tanpa peranan tambahan atau data pengguna setempatDengan cara ini, jika seseorang gagal atau rosak, yang baharu boleh diformat dan dipromosikan berdasarkan DC lain atau melalui IFM, sekali gus mengurangkan kerumitan pemulihan dengan ketara.

Tambahan pula, perlu diingat batasan seperti itu Salinan keadaan sistem hanya sah semasa tempoh batu nisan (60, 90, 180 hari bergantung pada konfigurasi) untuk mengelakkan daripada menghidupkan semula objek yang dipadam, dan kekunci mesin NTLM berubah setiap 7 hari. Dalam pemulihan yang sangat lama, mungkin perlu tetapkan semula akaun pasukan masalah daripada “Pengguna dan Komputer Direktori Aktif” atau malah mengalih keluarnya dan menyambungkannya semula ke domain.

Mempunyai prosedur untuk membuat sandaran keadaan sistem secara berkala, Dokumentasikan peranan FSMO, katalog global dan topologi replikasi dengan jelasDan menguji langkah pemulihan dalam persekitaran makmal merupakan pelaburan masa yang menjimatkan banyak masalah apabila pengawal domain rosak atau seseorang menggunakan snapshot tanpa berfikir panjang.