Memastikan replikasi yang benar di forest Active Directory adalah salah satu tugas utama administrator AD. Pada artikel ini, kami akan mencoba memahami prinsip-prinsip dasar replikasi dan metode pemecahan masalah database Active Directory. Perlu dicatat bahwa replikasi adalah salah satu prinsip dasar membangun jaringan perusahaan modern berdasarkan AD, misalnya, kita telah berbicara tentang mereplikasi kebijakan grup dalam domain AD dan mereplikasi zona DNS.
Untuk memantau replikasi Active Directory di lingkungan perusahaan, Microsoft merekomendasikan untuk menggunakan produk SCOM (atau produk pemantauan lainnya dengan fungsi yang sama). Selain itu, untuk memantau replikasi AD, Anda dapat menggunakan utilitas repadmin (repadmin / showrepl * / csv) bersamaan dengan skrip yang ditulis sendiri untuk menganalisis output dari utilitas ini. Masalah umum yang terkait dengan kesalahan replikasi Direktori Aktif adalah situasi di mana objek tidak muncul di satu atau lebih situs (misalnya, pengguna, grup, atau objek AD lainnya yang baru dibuat tidak tersedia di pengontrol domain di situs lain).
Titik awal yang baik untuk memecahkan masalah replikasi Active Directory adalah untuk menganalisis log Layanan Direktori pada pengontrol domain. Tindakan spesifik akan tergantung pada kesalahan apa yang terdeteksi dalam log, namun, untuk menyelesaikan masalah Anda harus memahami proses replikasi Direktori Aktif dengan jelas.
Salah satu elemen dasar mengelola lalu lintas replikasi antara pengontrol domain adalah situs Direktori Aktif. Situs saling berhubungan oleh tautan khusus yang disebut "tautan situs", yang menentukan biaya perutean data AD (hutan, domain, folder SYSVOL, dll.) Di antara situs yang berbeda. Perhitungan algoritma manajemen dan perutean untuk lalu lintas replikasi di hutan dilakukan oleh KCC.
KCC mendefinisikan mitra replikasi untuk semua pengontrol domain di hutan. Untuk replikasi lintas-situs, KCC secara otomatis memilih server jembatan khusus, di samping itu, administrator domain dapat secara manual menentukan pengontrol domain yang akan bertindak sebagai server jembatan untuk situs tertentu, server inilah yang mengontrol replikasi lintas-situs. Situs dan server Bridgehead diperlukan untuk mengelola lalu lintas replikasi Active Directory dengan mudah, dan untuk mengurangi jumlah lalu lintas yang dikirimkan melalui jaringan..
Topologi lintas-situs di hutan dapat dianalisis menggunakan perintah:
repadmin / showism
perintah ini menampilkan daftar situs di forest Active Directory. Untuk setiap situs, ditunjukkan 3 nilai: biaya replikasi antara dua situs, interval replikasi dalam hitungan menit, serta parameter komunikasi lintas situs yang dikonfigurasi tambahan. Output dari perintah ini mungkin terlihat seperti ini:
C: \> repadmin / showism ==== TRANSPORTASI CN = IP, CN = Transportasi Antar-Lokasi, CN = Situs, CN = Konfirmasi ransum, DC = winitpro, DC = id INFORMASI KONEKTIVITAS UNTUK 3 SITUS: ==== 0 , 1, 2 Situs (0) CN = LAB-Situs1, CN = Situs, CN = Konfigurasi, DC = winitpro, DC = id 0: 0: 0, 10: 15: 0, 10: 30: 0 Semua DSA di situs CN = ADP-ADSN, CN = Situs, CN = Konfigurasi, DC = lab, DC = net (dengan trans & hosting NC) adalah kandidat penghubung. Situs (1) CN = LAB-Site2, CN = Situs, CN = Konfigurasi, DC = winitpro, DC = id 10: 15: 0, 0: 0: 0, 20: 30: 0 Semua DSA di situs CN = ADP- Intranet, CN = Situs, CN = Konfigurasi, DC = la b, DC = net (dengan trans & hosting NC) adalah kandidat jembatan situs (2) CN = LAB-Site3, CN = Situs, CN = Konfigurasi, DC = winitpro, DC = id 10: 30: 0, 20: 30: 0, 0: 0: 0 1 server didefinisikan sebagai jembatan untuk transportasi CN = IP, CN = Transportasi Antar-Lokasi, CN = Situs, CN = Konfigurasi , DC = winitpro, DC = ru & situs CN = LAB-Site3, CN = Situs, CN = Konfigurasi, DC = winitpro, DC = ru: Server (0) CN = testlabdc2, CN = Server, CN = LAB-Site3, CN = Situs, CN = Konfigurasi, DC = winitpro, DC = en C: \>
Dapat dilihat pada log di atas bahwa ada 3 situs di domain winitpro.ru, yang masing-masing disebut Situs (0), Situs (1) dan Situs (2). Setiap situs memiliki 3 set informasi replikasi, satu untuk setiap situs di hutan. Sebagai contoh, koneksi antara Situs (2) (LAB-Site3) dan Situs (0) (LAB-Site1) dikonfigurasi, parameter koneksi ini adalah 10: 30: 0, yang berarti: 10 - biaya replikasi, dan interval replikasi adalah 30 menit. Juga perhatikan bahwa untuk situs (2) situs, server jembatan ditentukan - ini adalah pengontrol domain bernama testlabdc2.
Pengontrol domain, mitra replikasi - dapat diidentifikasi menggunakan Gui grafis atau menggunakan utilitas baris perintah. Buka konsol MMC "Active Directory Sites and Services", rentangkan node Sites, temukan situs yang menarik di dalamnya. Situs ini akan berisi pengontrol domain yang terkait dengan situs ini. Dengan memperluas pengontrol domain dan memilih Pengaturan NTDS, Anda akan melihat semua mitra replikasi pengontrol domain ini.
Dengan menggunakan perintah nslookup, Anda bisa mendapatkan daftar pengontrol domain yang terkait dengan situs kami di baris perintah (tentu saja, ini mengharuskan semua DC memiliki catatan SRV yang benar). Format perintahnya adalah:
nslookup -type = srv _ldap._tcp ... _sites.dc._
pada output kita mendapatkan sesuatu seperti berikut:
C: \> _ldap._tcp.LAB-Site1._sites.dc._msdcs.winitpro.ru Prioritas lokasi layanan SRV = 0 bobot = 100 port = 389 svr hostname = testlabdc1.winitpro.ru _ldap._tcp.LAB-Site1._sites .dc._msdcs.winitpro.ru Prioritas lokasi layanan SRV = 0 bobot = 100 port = 389 svr hostname = testlabdc2.winitpro.ru testlabdc1.winitpro.ru alamat internet = 172.21.23.13 alamat internet testlabdc2.winitpro.ru alamat internet = 172.21.23.16
Untuk menampilkan semua mitra replikasi untuk pengontrol domain tertentu, dengan tanggal dan waktu replikasi terakhir, gunakan perintah:
repadmin / showrepl
Perlu dicatat bahwa DNS adalah komponen penting dari Replikasi Direktori Aktif. Pengontrol domain mendaftarkan catatan SRV mereka dalam DNS. Setiap pengontrol domain di hutan mendaftar catatan CNAME formulir dsaGuid._msdcs.forestName, dimana dsaGuid -GUID terlihat di objek di item Pengaturan NTDS di konsol "Situs dan Layanan AD". Jika log Layanan Direktori berisi kesalahan yang terkait dengan DNS, untuk memeriksa CNAME yang valid dan catatan A untuk pengontrol domain.
dcdiag / test: konektivitas
Jika ada kesalahan, mulai ulang layanan Netlogon, yang akan mengakibatkan registrasi ulang entri dns yang hilang. Jika dcdiag masih menampilkan kesalahan, periksa konfigurasi layanan DNS dan pengaturan DNS yang benar di DC. Untuk pengantar yang lebih rinci tentang topik pengujian layanan dns, saya sarankan Anda merujuk ke artikel Mendiagnosis masalah dengan mencari pengontrol domain.
Tim repadmin memiliki parameter khusus / ringkasan ringkasan, yang memungkinkan Anda untuk dengan cepat memeriksa status replikasi pada pengontrol domain tertentu (namanya diindikasikan) atau pada semua pengontrol (opsi wildcard).
repadmin / replummary [targetDC | wildcard]
Jika tidak ada kesalahan replikasi, output dari perintah ini akan menunjukkan bahwa ada 0 kesalahan:
C: \> repadmin / replsummary testlabdc2 Ringkasan Replikasi Mulai Waktu: 2010-01-24 15:56:03 Awal pengumpulan data untuk ringkasan replikasi, ini mungkin memakan waktu cukup lama: ... Sumber DSA delta terbesar gagal / total %% kesalahan testlabdc1 06m: 27s 0/3 0 testlabdc3 06m: 27s 0/6 0 testlabdc4 06m: 27s 0/5 0 Tujuan DSA delta terbesar gagal / total% kesalahan kesalahan testlabdc3 06m: 27s 0/14 0 C: \>
Jika masih terjadi kesalahan, menggunakan utilitas Repadmin Anda bisa mendapatkan informasi yang lebih lengkap. Setiap pengontrol domain memiliki USN (Nomor Urut Pembaruan) uniknya sendiri, yang bertambah setiap kali pembaruan yang berhasil dari pembaruan objek Direktori Aktif. Ketika replikasi diinisialisasi, mitra ditransfer dengan USN, yang dibandingkan dengan USN yang diperoleh sebagai hasil dari replikasi yang berhasil terakhir dengan mitra ini, sehingga menentukan berapa banyak perubahan yang telah terjadi dalam database AD sejak replikasi terakhir.
Dengan kunci / showutdvec, Anda bisa mendapatkan daftar nilai USN saat ini yang disimpan di DC yang ditentukan.
repadmin / showutdvec
misalnya
C: \> repadmin / showutdvec testlabdc4 DC = winitpro, DC = id PANDUAN Caching ... LAB-Site1 \ testlabdc1 @ USN 16608532 @ Waktu 2010-01-24 16:27:11 LAB-Site1 \ testlabdc2 @ USN 307126 @ Waktu 2010- 01-24 16:27:27 LAB-Site2 \ testlabdc3 @ USN 297948217 @ Time 2010-01-24 16:19:34 LAB-Site3 \ testlabdc4 @ USN 245646728 @ Time 2010-01-24 16:19:36 C: \>
Dengan menjalankan perintah ini pada pengontrol domain yang memiliki masalah dengan replikasi, Anda dapat memahami betapa berbedanya database AD hanya dengan membandingkan nilai USN.
Menguji replikasi Active Directory menggunakan utilitas repadmin dapat dilakukan dengan beberapa cara:
- replmon / replikasi <targetDC> <sourceDC> <dirPartisi> (memungkinkan Anda memulai replikasi partisi tertentu ke pengontrol domain tertentu)
- replmon / replsingleobj <targetDC> <sourceDC> <objPath> (replikasi objek tertentu antara dua DC)
- replmon / syncall <targetDC> (sinkronisasi pengontrol domain yang ditentukan dengan semua mitra replikasi)
C: \> repadmin / replikasi testlabdc1 testlabdc3 DC = winitpro, DC = ru Sinkronisasi dari testlabdc3 ke testlabdc1 berhasil diselesaikan. C: \> repadmin / replacingleobj testlabdc1 testlabdc3 cn = stuart, ou = dsu sers, DC = winitpro, DC = ru Benda yang berhasil direplikasi cn = stuart, ou = dsuser, DC = winitpro, DC = ru ke testlabdc1 dari. C: \> repadmin / replacingleobj testlabdc1 testlabdc3 ou = dsusers, dc = la b, dc = net Berhasil mereplikasi objek ou = dsusers, DC = winitpro, DC = ru ke testlab dc1 dari. C: \> repadmin / replacingleobj testlabdc1 testlabdc3 DC = winitpro, DC = ru Berhasil mereplikasi objek DC = winitpro, DC = ru ke testlabdc1 dari. C: \> repadmin / syncall testlabdc3 CALLBACK PESAN: Replikasi berikut sedang berlangsung: Dari: 25fdc051-6ff6-4922-bc02-0b77a4652bfc._msdcs.winitpro.ru Kepada: 99305007-2290-489b-9551-20827ba06. .ru PANGGILAN PANGGILAN: Replikasi berikut selesai dengan sukses Dari: 25fdc051-6ff6-4922-bc02-0b77a4652bfc._msdcs.winitpro.ru Kepada: 99305007-2290-489b-9551-20827ba0664d._msdcs.winitpro.ru PANGGILAN PANGGILAN berikut: sedang dalam proses: Dari: b0870af5-ab82-4372-9e39-0a9772a5e47c._msdcs.winitpro.ru Ke: 99305007-2290-489b-9551-20827ba0664d._msdcs.winitpro.ru PANGGILAN KEMBALI PESAN: replikasi berikut selesai dengan sukses dari- ab82-4372-9e39-0a9772a5e47c._msdcs.winitpro.ru Kepada: 99305007-2290-489b-9551-20827ba0664d._msdcs.winitpro.ru PANGGILAN KEMBALI PESAN KEMBALI PESAN KEMBALI, PESAN KEMBALI PESAN KEMBALI: SyncAll Finished: SyncAll Finished. SyncAll dihentikan tanpa kesalahan. C: \>
