شرح repadmin: ليش DC01 يشوف التغيير وDC02 ما يشوفه؟ اقرأ تكرار Active Directory قبل إعادة التعديل

أزلت عضوية في لاب Active Directory، ثم استعلمت مرة ثانية ووجدتها موجودة. هل الأمر فشل؟ مو لازم. قد تكون القراءة الأولى من DC01 والثانية من DC02، والتغيير لم يصل إلى الثانية بعد، أو عندك مشكلة تكرار تحتاج تشخيصًا. تكرار التعديل بدون معرفة مصدر القراءة ممكن يزيد الالتباس بدل حله.
repadmin يساعدك تراجع حالة تكرار الدليل وتحدد الوجهة والشريك والسياق الذي يحتاج متابعة. بنشرح خيارات العرض، والفرق بين ملخص عام ودليل على وصول تغيير محدد. الأمثلة في مختبر مصرح بوحدتي تحكم، ولا تتضمن إجبار تكرار أو تنظيف كائنات أو تغيير إعدادات وحدات التحكم.

نسختان من الدليل، والقراءة ليست بالضرورة من نفس المكان

Active Directory بيئة موزعة. تطبيق أو أداة قد يقرأ من وحدة تحكم مختلفة عن التي استقبلت تغييرًا. توضح Microsoft أن وصول التغييرات له تأخر لا يمكن تعميم توقيته بدقة لكل حالة. لهذا نحتاج أن تسمح منهجية القراءة باختلاف مؤقت، مع التمييز بينه وبين فشل مستمر يحتاج معالجة.
لا تحول هذه الفكرة إلى عذر لأي اختلاف. إذا بقيت بيانات مختلفة مدة غير متوقعة بحسب تصميم البيئة، أو ظهرت أخطاء تكرار، يصبح التشخيص مطلوبًا. الذي يهم هو المصدر والوقت والجدول والحالة، وليس رقم دقائق محفوظًا من فيديو. المختبر لا يحتاج اختراع حد عام يقول إن كل الدومينات تتطابق خلال مدة ثابتة.
خلنا نفترض أن مجموعة TrainingReaders تغيرت على DC01. أداة تستخدم DC02 افتراضيًا قد ترى الحالة السابقة. إذا لم تسجل Server، يصعب تفسير اختلاف الجلستين. لذلك في مقارنة تدريبية استخدم الوجهة الصريحة واحفظ وقت كل قراءة. اسم المجموعة وحده لا يخبرك أين قُرئت.
فهم هذه الطبقة مهم في إعادة فحص معالجة أمنية. قد تزيل جهة مخولة حقًا زائدًا، ثم يعلن المختبر أن المعالجة لم تنفذ بناء على قراءة من نسخة لم تتحدث. والعكس ممكن: يرى النتيجة على وحدة واحدة ثم يغلق الفحص بينما توجد مشكلة تكرار تمنع بقية البيئة من تبنيها. كلا الخطأين يأتي من تجاهل توزيع الدليل.

حدد السؤال قبل اختيار الملخص أو التفاصيل

عندك سؤال عام: هل توجد أخطاء تكرار ظاهرة في نطاق معين؟ وعندك سؤال محدد: هل وصل تعديل عضوية هذه المجموعة إلى DC02؟ repadmin يعطيك قراءات مفيدة للحالة، لكن الملخص العام لا يثبت تلقائيًا وصول كل خاصية من كل تغيير. تحتاج قراءة الكائن المقصود أيضًا.
ابدأ بتسمية الوحدتين والدومين والخاصية. مثالنا مجموعة تدريب، وتغير متفق عليه نفذه صاحب المختبر. لا تختَر تغييرًا حساسًا على حساب إنتاج كي تتعلم المقارنة. تستطيع استخدام تغير حميد معد مسبقًا في بيانات وهمية، أو قراءة اختلاف موثق دون تنفيذ أي تعديل بنفسك.
اكتب ما الذي سيعد دليلًا: قراءتان حاليتان لنفس الهوية والخاصية من مصدرين معروفين، وحالة تكرار مرتبطة بالمسار المطلوب، ووقت التغيير إذا توفر. لا تحتاج جرد كل الغابة إذا كان التمرين على دومين واحد. توسعة النطاق يجب أن تجيب سؤالًا إضافيًا، لا أن تأتي لأن الأداة تقبل نجمة.
في جهاز إدارة مجهز بأدوات AD، تأكد من الأداة ومساعدتها المحلية. المرجع الرسمي لبعض خيارات repadmin موجود ضمن وثائق Windows السابقة؛ هذا لا يغني عن مطابقة النسخة المثبتة. إذا لم تتوفر صلاحية تشخيص مناسبة، اطلب من فريق الدليل قراءة محددة، ولا تعتبر تعذر تشغيل الأمر برهانًا أن التكرار متوقف.

replsummary: ملخص تبحث منه عن الحالة التي تستحق متابعة

توثيق repadmin /replsummary يقدمه لملخص الإخفاقات الواردة والصادرة. يمكن تقييد قائمة الوحدات بدل البحث الواسع. في مختبرك، صيغة مثل repadmin /replsummary DC01.lab.test تضيق الاستهداف حسب صيغة DSA_LIST المدعومة؛ راجع المساعدة المحلية للتأكد من نطاق النتائج الذي عُرض فعلًا.
المخرجات المعروفة تعرض جوانب مثل المصدر أو الوجهة والفشل من إجمالي المحاولات والفاصل المرتبط بالتكرار. لا تجعل نسبة فشل صفر دليلًا أن التطبيق سيقرأ كل تغيير فورًا. ولا تجعل قيمة زمنية أكبر من توقعك تشخيصًا نهائيًا لسبب العطل. الملخص يوجهك إلى التفاصيل التي تحتاجها.
انتبه إلى أخطاء الاستعلام عن الوحدة نفسها. إذا لم تستطع الأداة الاتصال بجهة، فهذا قيد في القراءة يحتاج تفسيرًا، وليس نتيجة تكرار سليمة لتلك الجهة. افصل الجهات التي قُرئت بنجاح عن الجهات غير المستجيبة. عبارة «فحصنا جميع الوحدات» غير دقيقة إذا كانت بعض القراءات فشلت.
في الملاحظات لا تنسخ الجدول وحده. اكتب النطاق والوقت وأي صف يستحق متابعة وما السؤال التالي. مثلًا: «ظهر إخفاق متعلق بوجهة محددة؛ سنقرأ شركاءها وسياق التكرار». بهذه الطريقة يصبح الملخص بداية تحليل، بدل رقم يوضع في التقرير ثم لا يعرف أحد ما الذي يفعله به.

showrepl: الوجهة تقرأ من أي شريك وأي سياق؟

repadmin /showrepl يعرض حالة التكرار الوارد وشركاءه على وحدة تحكم. مثال قراءة تعليمية: repadmin /showrepl DC02.lab.test. ابحث عن سياق الدليل، والشريك المصدر، ووقت المحاولة ونتيجتها. لا تخلط رأس الخادم الذي تستعلمه باسم المصدر الذي يحاول التكرار منه.
Naming Context أو NC مهم لأن الحالة قد تختلف بين أجزاء الدليل. إذا كنت تراجع عضوية مجموعة في دومين lab.test، اربط القراءة بسياق ذلك الدومين. نجاح جزء آخر لا يثبت وصول الخاصية التي تهمك. والملخص الذي يجمع عدة علاقات لا يبين وحده كل التفاصيل المؤثرة في حالتك.
آخر نجاح وآخر محاولة ليسا نفس المعلومة. إذا نجح التكرار في وقت ثم فشل لاحقًا، لا تستخدم النجاح القديم لتقول إن الحالة سليمة الآن. وإذا نجحت محاولة حديثة بعد إخفاق، احتفظ بالتسلسل عند تفسير المشكلة بدل حذف الفشل من القصة. الوقت يعطي النتيجة معناها.
لا تعتبر وجود شريك أو رابط دليل نجاح نقل البيانات. التكوين والحالة التشغيلية منفصلان. وفي المقابل، غياب شريك متوقع يحتاج مراجعة تصميم الموقع والطبولوجيا مع فريق الدليل، لا إنشاء رابط يدوي من داخل فحص القراءة. الهدف تحديد ما ينقصك من دليل وما يجب أن يراجعه صاحب النظام.

اقرأ نفس الكائن من الوحدتين، لا نفس الاسم فقط

في التمرين، اقرأ المجموعة من DC01 ومن DC02 باستخدام Server صريح. يمكن قراءة الهوية والخاصية مثل Get-ADGroup -Identity TrainingReaders -Server dc01.lab.test -Properties member | Select-Object Name,SID,DistinguishedName,member ثم القراءة المقابلة من dc02.lab.test. كلاهما استعلام، ولا يغير العضوية.
طابق SID أو معرفًا ثابتًا مناسبًا مع DN والاسم. إذا قرأت كائنين مختلفين لهما أسماء متقاربة، لا تصبح مقارنة التكرار صحيحة لمجرد أن السطرين يشبهان بعضهما. كذلك ترتيب الأعضاء في العرض ليس برهان اختلاف عضوية؛ قارن مجموعة القيم الفعلية، لا ترتيب النص وحده.
إذا كان التغيير متعلقًا بأكثر من كائن، قد تحتاج قراءة أكثر من خاصية أو علاقة. توثيق Microsoft يشرح حالات يظهر فيها بعض التحديثات قبل اكتمال البقية. لا تستنتج أن معاملة تشغيل كاملة انتهت لأن كائنًا واحدًا صار يعكس الحالة الجديدة. حدد ما الذي يتكون منه معيار المعالجة.
بعد إعادة القراءة سجل وقتًا جديدًا ولا تستبدل القديم بصمت. إذا تطابقت القيم لاحقًا، هذا يساعدك تفهم وصول التغيير، لكنه لا يثبت أن كل مسارات التكرار كانت سليمة طوال الفترة. اربط النتيجة بسؤال المشروع: الكائن المحدد أصبح متوافقًا في المصدرين المقروءين عند الوقت الجديد.

الأخطاء تقودك لطبقات، وليس لأمر إصلاح واحد

إرشاد Microsoft يذكر الاتصال وحل الأسماء والطبولوجيا والمصادقة ومكونات الدليل ضمن أسباب ممكنة لمشكلات التكرار. لذلك لا تختصر كل خطأ إلى DNS، ولا تعتبر كل رفض وصول حاجة لمنح صلاحيات أوسع. اقرأ رمز الخطأ ورسالة الحالة وسياق الشريك ثم اختر المرجع الذي يخصه.
لو كان الاتصال غير متاح، راجع المسار الشبكي المعتمد مع صاحب البيئة. فتح منفذ واحد ليس ضمانًا لكل التواصل المطلوب؛ بعض خدمات الدليل تعتمد على تدفقات متعددة. لا تطلب إلغاء الجدار الناري كحل تشخيصي عام. حدد الاتصال المتأثر ثم يراجع الفريق الإعداد المناسب وفق تصميمه.
إذا كانت الرسالة عن مصادقة، افصلها عن نقص وجود الكائن. وقد تحتاج مراجعة وقت أو هوية أو علاقة بين الجهات. لا تنفذ إعادة ضبط حسابات أو تغيير إعدادات KDC استنادًا إلى ملخص واحد. إجراءات كهذه تؤثر في نظام أكبر من حالة القراءة التي بدأت منها.
في اللاب قد تكون وحدة مطفأة عمدًا أو معزولة ضمن تمرين. اكتب الانقطاع المقصود حتى لا تصفه بعطل غير متوقع. لكن المقصود لا يعني أن أثره غير مهم؛ إذا تعتمد عليها قراءة أو اختبار، يجب أن تعرف حدود ذلك. فهم سبب الحالة يساعدك تختار التوقيت والنطاق اللذين يعطيان مقارنة مفيدة.

سيناريو مراجعة: إزالة عضو ثم اختلاف مصدرين

في مختبر تدريبي أزال المسؤول حسابًا وهميًا من TrainingReaders على DC01 في وقت معلوم. بعد دقائق قرأ الطالب DC02 ورآه موجودًا. بدل تنفيذ الإزالة مرة أخرى، حفظ القراءتين وراجع نفس هوية المجموعة وبيانات المصدر. هذا يمنع أن يطمس دليل الاختلاف بتعديل جديد.
قراءة showrepl على الوجهة تعطي حالة مسار مناسب. إذا أظهرت فشلًا، يبحث فريق الدليل في سببه وفق المرجع. إذا لم تظهر فشلًا في القراءة المتاحة، لا يقفز الطالب إلى ضمان وصول التغيير؛ يعيد قراءة الخاصية بعد نافذة يحددها تصميم المختبر، ويحتفظ بالوقت والنتيجة.
لاحقًا تختفي العضوية من المصدرين. هنا يكتب الطالب أن القيم المقروءة تطابقت، ويذكر تسلسل المشاهدات، وما إذا حُسم سبب التأخر. إذا كان الفريق عالج اتصالًا، يوثق الإجراء الذي نفذه صاحب النظام. لا ينسب النجاح إلى انتظار فقط إذا حدث تغيير بين القراءتين.
ثم يراجع الوظيفة التي كانت تعتمد على العضوية ضمن تجربة بيانات وهمية متفق عليها. عضوية الدليل ليست كل حالة الوصول؛ قد توجد جلسة أو اعتماديات أخرى تحتاج قراءة منفصلة. لا يعيد التعديل إذا بقي التطبيق يعرض بيانات قديمة، بل ينتقل للطبقة التي تخص التطبيق وفق الدليل.

التكرار ليس SYSVOL ولا جلسة المستخدم

قد تسمع كلمة Replication في سياق بيانات AD وفي سياق SYSVOL، لكن لا تجعل أداة واحدة دليلًا شاملًا لكل الملفات والسياسات. إذا كان السؤال عن ملف سياسة أو حالة توزيع محتواها، يحتاج الفريق مراجعة المكوّن المناسب. قراءة كائن GPO في الدليل لا تساوي إثبات وصول كل محتوى السياسة للجهاز.
كذلك نجاح وصول عضوية إلى وحدة تحكم لا يضمن أن جلسة مستخدم قائمة تبنت كل آثارها فورًا. لا تستنتج من هذا أن التكرار فشل مرة ثانية. افصل بيانات الدليل الحالية عن سياق الجلسة وعن التطبيق الذي يستهلكها. هذه ثلاث طبقات قد تعطي ملاحظات مختلفة دون تعارض تقني.
في إعادة اختبار أمني، اكتب شروط التجربة: الحساب والمورد ونوع الجلسة ووقت بدئها ومصدر قراءة الدليل. إذا كان اختبارًا جديدًا متفقًا عليه، سجله كذلك. لا تنهِ جلسات أشخاص حقيقيين أو تمسح تذاكرهم أثناء الدوام بحجة توحيد التجربة؛ يحدد صاحب البيئة إجراء تحقق مناسبًا.
هذا الفصل يرفع قيمة التقرير. يقدر فريق الدليل يراجع التكرار، وفريق التشغيل يراجع الجلسة والتطبيق، وكل واحد يعرف الدليل الذي يخصه. أما تقرير يقول «الصلاحية ما زالت شغالة إذن AD لا يكرر» فقد يجمع عدة ظواهر تحت سبب واحد لم يثبت.

خلاصة الفحص التي يستطيع فريق الدليل العمل بها

سلّم قائمة قصيرة فيها المصدر والوجهة وسياق الدليل والكائن والخاصية والوقت وحالة القراءة، ثم حالة التكرار ذات الصلة ورمز الخطأ إن وجد. أرفق المقتطف اللازم وتفسيره. لا تحتاج ملفًا من آلاف الأسطر ليعرف الفريق أن هناك مسارًا يحتاج مراجعة.
اكتب الفرضيات التي لم تُحسم، مثل انقطاع مقصود أو اختلاف حالة مختبر أو نافذة قراءة غير كافية. لا تجعلها أسبابًا نهائية. وإذا تعذر الوصول إلى وحدة، اذكرها خارج التغطية الحالية بدل إسقاطها من الجدول وجعل بقية النتائج تبدو شاملة.
معيار إعادة الفحص هو زوال المشكلة المثبتة، وتطابق القيم المطلوبة في الجهات المتفق عليها، ونجاح الوظيفة ذات الصلة ضمن حدود الاختبار. نجاح أمر ملخص وحده لا يجيب كل هذا، لكنه يدعم الصورة. والقراءة المتطابقة لكائن واحد لا تمنحك ضمانًا لكل الدومين.
المراجع: ملخص repadmin https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc835092(v=ws.11) وshowrepl https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc742066(v=ws.11) وسلوك التكرار https://learn.microsoft.com/en-us/windows/win32/ad/replication-behavior-in-active-directory-domain-services وإرشاد التشخيص https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/troubleshoot-adreplication-guidance . استخدم خيارات العرض لفهم الحالة، واترك إجراءات المعالجة لخطة تشغيل معتمدة تناسب السبب المثبت. وفي تمرينك احتفظ أيضًا بالقراءات غير الحاسمة؛ مثل استعلام لم يصل أو مخرج لا يغطي السياق المطلوب. تسميتها بوضوح تعلمك تعرف متى تحتاج معلومة جديدة، وتمنع تحويل الفجوة إلى نتيجة سلبية. ليس مطلوبًا أن تجيب عن كل مشكلة في جلسة واحدة، لكن المطلوب أن تترك سؤال المتابعة قابلًا للفهم والتنفيذ.