Polling untuk Perubahan Menggunakan USNChanged

Kontrol DirSync kuat dan efisien, tetapi memiliki dua batasan signifikan:

• Hanya untuk aplikasi yang sangat istimewa: Untuk menggunakan kontrol DirSync, aplikasi harus berjalan di bawah akun yang memiliki hak istimewa SE_SYNC_AGENT_NAME pada pengendali domain. Beberapa akun sangat istimewa, sehingga aplikasi yang menggunakan kontrol DirSync tidak dapat dijalankan oleh pengguna biasa.
• Tidak ada cakupan subtree: Kontrol DirSync mengembalikan semua perubahan yang terjadi dalam konteks penamaan. Aplikasi yang hanya tertarik pada perubahan yang terjadi dalam subtree kecil dari konteks penamaan harus melewati banyak perubahan yang tidak relevan, yang tidak efisien baik untuk aplikasi maupun untuk pengendali domain.

Perubahan dari Direktori Aktif juga dapat diperoleh dengan mengkueri atribut uSNChanged , yang menghindari batasan kontrol DirSync. Alternatif ini tidak lebih baik daripada kontrol DirSync dalam segala hal karena melibatkan transmisi semua atribut ketika ada perubahan atribut dan membutuhkan lebih banyak pekerjaan dari pengembang aplikasi untuk menangani skenario kegagalan tertentu dengan benar. Saat ini, cara terbaik untuk menulis aplikasi pelacakan perubahan tertentu.

Ketika pengendali domain memodifikasi objek, ia mengatur atribut uSNChanged objek tersebut ke nilai yang lebih besar dari nilai sebelumnya dari atribut uSNChanged untuk objek tersebut, dan lebih besar dari nilai saat ini dari atribut uSNChanged untuk semua objek lain yang disimpan pada pengontrol domain tersebut. Sebagai konsekuensinya, aplikasi dapat menemukan objek yang terakhir diubah pada pengendali domain dengan menemukan objek dengan nilai uSNChanged terbesar. Objek kedua yang terakhir diubah pada pengendali domain akan memiliki nilai uSNChanged terbesar kedua, dan sebagainya.

Atribut uSNChanged tidak direplikasi, oleh karena itu membaca atribut uSNChanged objek di dua pengontrol domain yang berbeda biasanya akan memberikan nilai yang berbeda.

Misalnya, atribut uSNChanged dapat digunakan untuk melacak perubahan dalam subtree S. Pertama, lakukan "sinkronisasi penuh" subtree S. Misalkan nilai uSNChanged terbesar untuk objek apa pun di S adalah U. Kueri berkala untuk semua objek dalam subtree S yang nilai uSNChanged-nya lebih besar dari U. Kueri akan mengembalikan semua objek yang telah berubah sejak sinkronisasi penuh. Atur Anda ke uSNChanged terbesar di antara objek yang diubah ini, dan Anda siap untuk melakukan polling lagi.

Seluk beluk penerapan aplikasi sinkronisasi uSNChanged meliputi:

• Gunakan atribut highestCommittedUSN dari rootDSE untuk mengikat filter uSNChanged Anda. Artinya, sebelum memulai sinkronisasi penuh, baca highestCommittedUSN pengontrol domain afiliasi Anda. Kemudian, lakukan kueri sinkronisasi penuh (menggunakan hasil halaman) untuk menginisialisasi database. Ketika ini selesai, simpan nilai highestCommittedUSN yang dibaca sebelum kueri sinkronisasi penuh; untuk digunakan sebagai batas bawah atribut uSNChanged untuk sinkronisasi berikutnya. Kemudian, untuk melakukan sinkronisasi inkremental, dibaca ulang atribut rootDSE HighestCommittedUSN . Kemudian kueri untuk objek yang relevan, menggunakan hasil halaman, yang uSNChanged-nya lebih besar dari batas bawah nilai atribut uSNChanged yang disimpan dari sinkronisasi sebelumnya. Perbarui database menggunakan informasi ini. Setelah selesai, perbarui batas bawah atribut uSNChanged dari nilai highestCommittedUSN yang dibaca sebelum kueri sinkronisasi bertahap. Selalu simpan batas bawah nilai atribut uSNChanged dalam penyimpanan yang sama dengan yang disinkronkan aplikasi dengan konten pengendali domain.

  Mengikuti prosedur ini, daripada yang didasarkan pada nilai uSNChanged pada objek yang diambil, menghindari pembuatan ulang objek yang diperbarui server yang berada di luar set yang berlaku untuk aplikasi.

• Karena uSNChanged adalah atribut non-replikasi, aplikasi harus mengikat pengontrol domain yang sama setiap kali dijalankan. Jika tidak dapat mengikat pengontrol domain tersebut, pengontrol domain tersebut harus menunggu hingga dapat melakukannya, atau berafiliasi dengan beberapa pengontrol domain baru dan melakukan sinkronisasi penuh dengan pengendali domain tersebut. Ketika aplikasi berafiliasi dengan pengendali domain, aplikasi mencatat nama DNS pengendali domain tersebut dalam penyimpanan yang stabil, yang merupakan penyimpanan yang sama, itu menjaga konsisten dengan konten pengendali domain. Kemudian menggunakan nama DNS tersimpan untuk mengikat pengontrol domain yang sama untuk sinkronisasi berikutnya.

• Aplikasi harus mendeteksi kapan pengendali domain yang saat ini berafiliasi dengannya telah dipulihkan dari cadangan, karena ini dapat menyebabkan inkonsistensi. Ketika aplikasi berafiliasi dengan pengendali domain, aplikasi menyimpan "id pemanggilan" pengontrol domain tersebut dalam penyimpanan yang stabil, yaitu penyimpanan yang sama dengan konten pengontrol domain. "ID pemanggilan" dari pengendali domain adalah GUID yang disimpan dalam atribut invocationID objek layanan pengendali domain. Untuk mendapatkan nama khusus objek layanan pengendali domain, baca atribut dsServiceName dari rootDSE.

  Ketahuilah bahwa ketika penyimpanan stabil aplikasi dipulihkan dari cadangan tidak ada masalah konsistensi karena nama pengendali domain, id pemanggilan, dan batas bawah nilai atribut uSNChanged disimpan dengan data yang disinkronkan dengan konten pengendali domain.

• Gunakan penomoran saat mengkueri server, baik sinkronisasi penuh maupun bertambah bertahap, untuk menghindari kemungkinan pengambilan tataan hasil besar secara bersamaan. Untuk informasi selengkapnya, lihat Menentukan Opsi Pencarian Lainnya.

• Lakukan kueri berbasis indeks untuk menghindari memaksa server menyimpan hasil perantara besar saat menggunakan hasil halaman. Untuk informasi selengkapnya, lihat Atribut Terindeks.

• Secara umum, jangan gunakan pengurutan sisi server dari hasil pencarian, yang dapat memaksa server untuk menyimpan dan mengurutkan hasil perantara besar. Ini berlaku untuk sinkronisasi penuh dan bertahap. Untuk informasi selengkapnya, lihat Menentukan Opsi Pencarian Lainnya.

• Tangani tidak ada kondisi induk dengan anggun. Aplikasi mungkin mengenali objek sebelum mengenali induknya. Tergantung pada aplikasi, ini mungkin atau mungkin tidak menjadi masalah. Aplikasi selalu dapat membaca status induk saat ini dari direktori.

• Untuk menangani objek yang dipindahkan atau dihapus, simpan atribut objectGUID dari setiap objek yang dilacak. Atribut objectGUID objek tetap tidak berubah terlepas dari di mana objek dipindahkan ke seluruh forest.

• Untuk menangani objek yang dipindahkan, lakukan sinkronisasi penuh berkala atau tingkatkan cakupan pencarian dan filter perubahan yang tidak diinginkan di akhir klien.

• Untuk menangani objek yang dihapus, lakukan sinkronisasi penuh berkala atau lakukan pencarian terpisah untuk objek yang dihapus saat Anda melakukan sinkronisasi bertahap. Saat Anda mengkueri objek yang dihapus, ambil objectGUID objek yang dihapus untuk menentukan objek yang akan dihapus dari database Anda. Untuk informasi selengkapnya, lihat Mengambil Objek yang Dihapus.

• Ketahuilah bahwa hasil pencarian hanya menyertakan objek dan atribut yang dapat dibaca oleh pemanggil (berdasarkan deskriptor keamanan dan DACL pada berbagai objek). Untuk informasi selengkapnya, lihat Efek Keamanan pada Kueri.

Untuk informasi selengkapnya, dan contoh kode yang menunjukkan dasar-dasar aplikasi sinkronisasi USNChanged, lihat Contoh Kode untuk Mengambil Perubahan Menggunakan USNChanged.