Anda sedang offline saat ini, menunggu internet Anda untuk menyambung kembali

Memulihkan pengontrol domain dapat menyebabkan inkonsistensi antara pengontrol domain

PENTING: Artikel ini diterjemahkan oleh perangkat lunak penerjemahan mesin Microsoft, dan mungkin telah diedit oleh Masyarakat Microsoft melalui teknologi CTF dan bukan oleh seorang penerjemah profesional. Microsoft menawarkan baik artikel yang diterjemahkan oleh manusia maupun artikel hasil editan terjemahan oleh mesin/komunitas, sehingga Anda dapat mengakses semua artikel di Sentra Pengetahuan yang kami miliki dalam berbagai bahasa. Namun artikel hasil editan mesin atau bahkan komunitas tidak selalu sempurna. Artikel ini dapat mengandung kesalahan dalam hal kosa kata, sintaksis atau tatabahasa, sangat mirip dengan penutur asing yang membuat kekeliruan ketika berbicara dalam bahasa Anda. Microsoft tidak bertanggung jawab atas ketidakakuratan, kesalahan atau kerugian apa pun akibat dari kekeliruan dalam penerjemahan isi atau penggunaannya oleh pelanggan kami. Microsoft juga akan senantiasa memperbarui perangkat lunak penerjemahan mesin dan alat untuk menyempurnakan Editan Hasil Penerjemahan Mesin.

Klik disini untuk melihat versi Inggris dari artikel ini: 316829
Gejala
Memulihkan pengontrol domain dapat menyebabkan peristiwa ID: 1587, menunjukkan inkonsistensi antara pengontrol domain. Jika hal ini terjadi, beberapa objek hidup mungkin ada di pengendali domain yang dipulihkan. Selain itu, objek baru pada pengendali domain dipulihkan tidak direplikasi.
Penyebab
Masalah ini terjadi karena pengontrol domain menetapkan ID permintaan baru, tetapi menggunakan tanda highwater asli.
Pemecahan masalah
Untuk mengatasi masalah ini, Dapatkan Service Pack terbaru untuk Windows 2000. Untuk informasi tambahan, klik nomor artikel berikut ini untuk melihat artikel di Pangkalan Pengetahuan Microsoft:
260910 Cara mendapatkan Service Pack Windows 2000
Untuk mengatasi masalah ini, Dapatkan hotfix yang dijelaskan di artikel Pangkalan Pengetahuan Microsoft berikut ini:
299687 MS01-036: Fungsi terkena menggunakan LDAP melalui SSL dapat mengaktifkan sandi berubah
Teknik pemecahan masalah
Untuk mengatasi masalah ini, demote dan kemudian mempromosikan pengendali domain yang dipulihkan. Sebelum Anda demote server yang terpengaruh, memaksa replikasi penuh dari server yang terpengaruh ke pengendali domain lainnya. (Sinkronisasi penuh dapat sumber intensif untuk domain yang lebih besar.) Menjalankan sinkronisasi penuh di partisi domain dan konfigurasi partisi. Baris berikut ini menunjukkan sintaks perintah Repadmin yang Anda gunakan untuk melakukan sinkronisasi:
repadmin /sync <Naming context=""> <Dest dc=""> <Source dc="" guid="">[/ Force] [/full]</Source> </Dest> </Naming>
Baris berikut ini adalah contoh penggunaan perintah ini:
repadmin /sync DC = domain, DC = akar good_DC dc1 122a5239-36b3-488a-b24c-971ed0ca8a46/Force/penuh
Dalam contoh perintah,
  • "DC = domain, DC = akar" konteks penamaan domain.
  • "good_DC" adalah tujuan DC. Ini adalah mitra baik yang akan menerima pembaruan.
  • DSA pengenal unik global adalah replikasi pengenal unik global untuk DC dipulihkan. Anda bisa mendapatkan ini dengan menjalankan Repadmin /showreps di server dipulihkan. pengenal unik global tercantum di bagian atas di bawah "DC objek Guid".
Jika sinkronisasi berhasil, Anda menerima pesan berikut ini:
Sinkronisasi dari 122a5239-36b3-488a-b24c-971ed0ca8a46 untuk Good_DC berhasil diselesaikan.


Ulangi proses untuk konfigurasi konteks penamaan dengan menggunakan perintah yang sama dengan berikut ini:
repadmin /sync cn = configuration, DC = domain, DC = akar good_DC dc1 122a5239-36b3-488a-b24c-971ed0ca8a46/Force/penuh
Masalah ini tidak cenderung diselesaikan setelah Anda melakukan hal ini. Setelah Anda melakukan ini, instal hotfix atau demote dan kemudian mempromosikan pengontrol domain untuk memecahkan masalah.
Status
Microsoft telah mengkonfirmasi bahwa ini merupakan masalah di dalam produk Microsoft sebagaimana tercantum di bagian awal artikel ini. Masalah ini pertama kali dikoreksi di Windows 2000 Service Pack 3.
Informasi lebih lanjut
Ketika Anda memulihkan pengontrol domain, USN berkomitmen tertinggi adalah dibatalkan ke titik saat pembuatan cadangan telah dibuat. pengendali domain permintaan ID dihentikan dan yang baru akan ditetapkan. Ketika mitra mencoba untuk mereplikasi pertama kali setelah pemulihan, ikuti pesan tercatat:

Jenis peristiwa: Informasi
Sumber peristiwa: Replikasi NTDS
Kategori peristiwa: (5)
ID Kejadian: 1587
Tanggal: 3/16/2001
Waktu: 10:52:35: 00
Pengguna: $ CONTOSO\CO-NA-DC-01
Komputer: CO-DC-02
Keterangan:
Direktori Layanan agen (DSA) sesuai dengan objectGuid d0a6a575-9702-4f4e-bf68-bb2a9f875188 telah meminta perubahan mulai bookmark sebelumnya DSA lokal pemulihan terbaru dari cadangan di USN 94727614. Bookmark yang disetel sebagai berikut: sebelumnya permintaan ID: bc546028-fae7-4978-abe0-d294694da32b
Pemutakhiran objek sebelumnya USN: 95853579
Pemutakhiran properti sebelumnya USN: 95853579
ID permintaan baru: ae6286cb-740b-4bb3-ace7-9577efa9dc9f
Objek baru Update USN: 94727614
Properti baru Update USN: 94727614


Peristiwa ini khas untuk pengendali domain yang dipulihkan. Dengan sendirinya, ini menunjukkan masalah. Ini adalah masalah jika objek yang dibuat pada pengendali domain dipulihkan "diam-diam" tidak mereplikasi keluar.

Dalam skenario masalah, USN tertinggi telah dibatalkan. Namun, selama bookmark (atau "up-to-dateness" direset vector), pengendali domain sumber persediaan tertinggi USN nilai yang hadir sebelum pemulihan. Objek yang memiliki nilai USNchanged antara nilai atribut atas dan bawah highestCommittedUSN tidak pernah dianggap sebagai untuk replikasi.

Misalnya: menganggap bahwa pengontrol domain 1 memiliki USN tertinggi 100. Mitra replikasi, pengendali domain 2, memiliki "up-to-dateness" vektor 100 untuk pengendali domain 1.

Anda memulihkan pengendali domain 1 dari cadangan yang USN tertinggi adalah 50. Setelah replikasi berikutnya dengan pengontrol domain 2, pengendali domain 1 me-reset penunjuk ke 100 (harus 50). pengendali domain 1 berasal dari perubahan 51, 52, dan 53. Saat pengendali domain 2 melakukan negosiasi replikasi, itu tidak pernah mempertimbangkan perubahan karena yakin bahwa memiliki perubahan hingga 100. pengendali domain 1 terus membuat perubahan dan akhirnya mencapai 101. Ubah 101 direplikasi, tetapi perubahan 51 hingga 100 tidak.

Dalam beberapa kasus, Anda dapat mendeteksi status ini. Gunakan Ldp atau ADSI Edit membaca atribut highestCommittedUSN saat ini pada objek rootDSE pada pengendali domain yang dipulihkan. Kemudian, membandingkan output dari repadmin /showreps / verbose pada salah satu mitra. Dalam Keluaran Repadmin, Cari nilai "USN ### /OU" untuk pengendali domain dipulihkan untuk setiap konteks penamaan. Jika nilai di Repadmin lebih tinggi daripada atribut highestCommittedUSN , pengendali domain dipulihkan mengalami masalah.

Perhatikan bahwa jika pengendali domain yang dipulihkan telah berasal dari pemutakhiran cukup atribut highestCommittedUSN yang telah tercapai atau melebihi "up-to-dateness" vektor yang direkam pada pengontrol domain lainnya (seperti dalam contoh dalam artikel ini), beberapa perubahan tidak harus dianggap untuk replikasi. Namun, perubahan baru direplikasi keluar. Perubahan unreplicated yang disebut sebagai "objek hidup."
Referensi
Untuk informasi tambahan tentang objek hidup, klik nomor artikel berikut ini untuk melihat artikel di Pangkalan Pengetahuan Microsoft:

317097 Objek hidup mencegah replikasi direktori aktif dari terjadi

3125191 ID Kejadian 1587 yang dihasilkan pada pengendali domain ketika terdapat lebih dari dua pengendali domain di situs yang sama sebagai Lync server
kbDirServices

Peringatan: Artikel ini telah diterjemahkan secara otomatis

Properti

ID Artikel: 316829 - Tinjauan Terakhir: 01/25/2016 22:03:00 - Revisi: 3.0

  • kbbug kbdirservices kbfix kbwin2000presp3fix kbwin2000sp3fix kbmt KB316829 KbMtid
Tanggapan
/html>