شرح Get-ADComputer: الجهاز ظاهر في الدومين، لكن هل هو شغّال فعلًا؟

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

ثلاث معلومات قد تختلف بدون أن تكون إحداها كذبة

خذ جهازًا تدريبيًا اسمه LAB-WS01. توجد له هوية داخل الدليل، وسجل اسم في خدمة الأسماء، ونظام تشغيل قد يكون يعمل أو متوقفًا. هذه أشياء مترابطة لكنها ليست قراءة واحدة موحدة.
أمر Get-ADComputer يسألك الدليل عن كائن الجهاز وخصائصه. استعلام DNS يسأل عن السجل الذي يحل الاسم إلى عنوان. واختبار اتصال إلى منفذ محدد يسأل هل نجح هذا الاتصال من جهاز الفحص في تلك اللحظة. لا تستبدل جواب واحدة بجواب الثانية.
خلنا نفترض أن الجهاز الافتراضي مطفأ لكن حسابه ما زال موجودًا. من الطبيعي أن ينجح استعلام الدليل. ويمكن أن يبقى سجل الاسم موجودًا أيضًا، بينما يفشل الاتصال بخدمة على الجهاز. النتيجة الصحيحة ليست «الأداة متناقضة»، بل «المصادر تصف طبقات مختلفة».
وفي حالة ثانية، قد يكون الجهاز شغالًا لكن مسار الشبكة أو سياسة الاتصال تمنع الفحص من موقعك. عدم الرد هنا لا يكفي للحكم بأنه مطفأ. تحتاج تعرف ما الذي اختبرته ومن أين، وهل الوصول المتوقع مسموح أصلًا.
هذه الفروق مهمة عندما تكتب تقرير تغطية اختبار. قائمة الكائنات المكتشفة في الدليل لا تساوي قائمة الأجهزة التي اختُبرت خدماتها. احتفظ بالقائمتين ومعنى كل واحدة بدل دمجهما تحت عنوان واحد مثل «الأجهزة المفحوصة».

اقرأ جهازًا معروفًا قبل جرد الوحدة كاملة

في جهاز إداري مجهز بوحدة ActiveDirectory، ومن حساب مصرح، ابدأ بمثال محدد:
Get-ADComputer -Identity LAB-WS01 -Server dc01.lab.test -Properties DNSHostName,OperatingSystem,OperatingSystemVersion | Select-Object Name,Enabled,DNSHostName,OperatingSystem,OperatingSystemVersion,DistinguishedName
الأسماء هنا افتراضية للاب. نطلب خصائص مفيدة للسؤال بدل جميع الخصائص. الاسم المميز يساعدنا نحدد مكان الكائن، واسم المضيف يساعدنا نعرف ما سنراجعه لاحقًا في خدمة الأسماء.
قيمة Enabled تتعلق بحساب الجهاز في الدليل، ولا تعني أن النظام قيد التشغيل أو أن كل خدماته متاحة. كذلك اسم نظام التشغيل وإصداره في خصائص الكائن ليسا اختبارًا حيًا لكل تحديث مثبت على الجهاز. استخدمهما كمعلومة من هذا المصدر، ثم تحقق من تفاصيل الحالة الفعلية بالمصدر المناسب إذا احتاجت المهمة.
إذا لم يظهر الجهاز، راجع الهوية والخادم والنطاق قبل توسيع الاستعلام. وإذا ظهر باسم قريب، لا تعتبره المقصود دون التحقق من المعرف أو الموقع مع مسؤول اللاب. أسماء الأجهزة قد تتشابه، وقد يعاد استخدامها بعد إعادة بناء أو نقل أصل.
دوّن ما تتوقعه مسبقًا: اسم الجهاز، والوحدة التنظيمية التي يفترض أن يكون فيها، ونوع النظام المعروف في اللاب. المقارنة بحالة مرجعية واحدة تساعدك تكتشف خطأ اختيار المصدر قبل أن تصدر جدولًا كبيرًا وتبدأ تفسير كل صف فيه.

ابنِ جردًا صغيرًا له حدود واضحة

بعد نجاح قراءة الجهاز المعروف، اجلب الحسابات من وحدة التدريب فقط:
$labComputers = Get-ADComputer -Filter * -SearchBase 'OU=Workstations,OU=Training,DC=lab,DC=test' -SearchScope Subtree -Server dc01.lab.test -Properties DNSHostName,OperatingSystem,OperatingSystemVersion
ثم اعرض ما تحتاجه:
$labComputers | Select-Object Name,Enabled,DNSHostName,OperatingSystem,OperatingSystemVersion,DistinguishedName
غيّر الاسم المميز حسب اللاب الفعلي الذي تملكه أو المصرح لك به. لا تفترض أن مجلد Computers الافتراضي وحدة تنظيمية باسم OU=Computers؛ نوع المكون جزء من الاسم الصحيح ويجب أخذه من البيئة، لا تخمينه.
استخدام نطاق Subtree في هذا المثال يعني أننا نريد ما يقع تحت نقطة البحث بما يشمل المستويات الفرعية. إذا كانت المهمة تخص مستوى واحدًا فقط، ناقش النطاق المطلوب واضبطه وفق التوثيق بدل حذف النتائج يدويًا بعد جلبها ثم نسيان سبب استبعادها.
راجع جهازًا من المستوى الرئيسي وجهازًا من وحدة فرعية إن كان اللاب يحتويهما. إذا ظهرا كما توقعت، أصبح عندك اختبار بسيط للتغطية. أما العدد الإجمالي وحده فلا يكشف أنك بحثت في المكان الصحيح؛ خمسون صفًا من الوحدة الخطأ تظل نتيجة غير مناسبة للمهمة.
احتفظ بالناتج مع وقت الجلب ومصدره. إذا نقل المسؤول جهازًا إلى وحدة ثانية بعد ذلك، سيصبح تفسير الاختلاف في الجولة التالية أسهل. قائمة الدليل لقطة زمنية لبيانات المصدر، وليست وعدًا بأن البنية ستبقى ثابتة بعد انتهاء الأمر.

إذا خانة نظام التشغيل فاضية، لا تخترع تصنيفًا

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

انتقل إلى حل الاسم بسؤال واحد

إذا كان نطاق العمل يسمح بالتحقق الشبكي، اختر جهازًا تدريبيًا واحدًا وراجع اسمه:
Resolve-DnsName -Name lab-ws01.lab.test -Type A
المثال يطلب سجل عنوان من النوع A. إذا رجع عنوان، فهذا يصف جواب خدمة الأسماء في ظروف الاستعلام، ولا يثبت أن الجهاز يعمل أو أن العنوان ما زال يعود للأصل الذي تقصده.
قارن الاسم مع DNSHostName الذي قرأته من الدليل ومع سجل الأصول المعتمد في اللاب. إذا اختلفا، لا تستبدل أحدهما عشوائيًا كي ينجح الاتصال. قد يكون هناك تغيير اسم أو سجل قديم أو تفسير آخر يحتاج مسؤول البيئة.
إذا فشل حل الاسم، افصل ذلك عن فشل خدمة على الجهاز. أنت لم تصل بعد إلى اختبار منفذ التطبيق. راجع خدمة الأسماء التي يستخدمها جهازك، وتهجئة الاسم، والنطاق الذي تسأل عنه، وحدود الشبكة. لا تبدأ بفحص عناوين كثيرة بحثًا عن جهاز يشبه الاسم.
وفي الشبكات التي تستخدم أكثر من نوع سجل أو إعدادات خاصة، لا تعتبر غياب سجل A وحده دليلًا شاملًا على غياب كل إمكانية وصول. المثال محدود بنوع السجل الذي طلبناه. إذا كانت المهمة تحتاج نوعًا آخر، حدده وراجع توثيقه بدل تعميم النتيجة.
الشيء الذي يستحق تسجيله هنا هو الاسم المطلوب والجواب والخادم أو السياق المستخدم ووقت الاستعلام. بهذا تقدر لاحقًا تفصل مشكلة تعريف الأصل عن مشكلة الوصول للخدمة.

اختبر خدمة محددة، وليس فكرة أن الجهاز حي

نفترض أن اللاب مصمم ليقدم خدمة تدريبية على منفذ TCP معلوم، وأن فحص الاتصال بها مصرح. استخدم منفذ الخدمة المتفق عليه، مثل خدمة HTTPS تدريبية:
Test-NetConnection -ComputerName lab-ws01.lab.test -Port 443 -InformationLevel Detailed
اقرأ نتيجة اتصال TCP والعنوان الذي اختُبر. نجاح الاتصال يعني أن هذا النوع من الاتصال إلى ذلك العنوان والمنفذ نجح من موقعك وقت التجربة. لا يثبت أن تطبيق الويب يعمل بشكل صحيح أو أن الشهادة سليمة أو أنك تملك صلاحية الدخول إليه.
إذا فشل الاتصال، فالتفسير ما زال مفتوحًا لعدة أسباب: خدمة غير مستمعة، أو سياسة شبكة، أو مسار غير متاح، أو جهاز متوقف، أو عنوان غير مناسب. النتيجة وحدها لا تختار السبب. ارجع لتصميم اللاب والمصدر الإداري وحدد أي طبقة تحتاج مراجعة.
لا تجعل فشل Ping وحده بوابة تمنعك من فهم النتيجة الأخرى أو سببًا لإعلان أن كل خدمة متوقفة. أنواع الاتصال تختلف، والاختبار الذي اخترته يجب أن يرتبط بالخدمة والسؤال. وفي المقابل، رد Ping لا يثبت أن الخدمة المطلوبة تعمل.
الأفضل في التدريب أن تبدأ بخدمة يعرف المسؤول حالتها، ثم يغير عاملًا واحدًا ضمن خطة التجربة، مثل إيقاف الخدمة التدريبية مع بقاء الجهاز يعمل. بعدها راقب كيف تغيرت نتيجة الاتصال دون أن يختفي كائن الجهاز من الدليل. هذا يوضح الفرق عمليًا أكثر من حفظ تعريفات متفرقة.

حالة مراجعة كاملة: أربع نتائج وأربع خطوات تالية

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

كيف تحفظ النتيجة بحيث تفيد الفريق؟

صدّر خصائص الدليل إلى ملف واضح الاسم داخل مجلد العمل:
$labComputers | Select-Object Name,Enabled,DNSHostName,OperatingSystem,OperatingSystemVersion,DistinguishedName | Export-Csv -Path 'training-computer-objects.csv' -NoTypeInformation -Encoding UTF8
راجع وجود نسخة سابقة قبل التصدير، ولا تخلط هذه القائمة بنتائج الاتصال تحت عنوان واحد يوحي بأن جميع الأجهزة فُحصت شبكيًا. يمكن أن تحتفظ بسجل آخر لكل اختبار اتصال يتضمن الاسم والعنوان والمنفذ ووقت التنفيذ وموقع الفحص والنتيجة.
عند الربط بين السجلين، استخدم هوية الأصل والسياق بعناية. العنوان وحده قد لا يكون معرفًا دائمًا، والاسم قد يتغير أو يعاد استخدامه. إذا كانت هناك فجوة في المطابقة، علّمها للمراجعة بدل اختيار أول صف يبدو قريبًا.
اكتب ملخصًا يفرق بين ما عرفته وما تحتاجه. مثلًا: «راجعنا كائنات الأجهزة ضمن وحدة التدريب، واختبرنا الاتصال بخدمة محددة على ثلاثة أجهزة معروفة. تعذر حل اسم جهاز واحد من بيئة الفحص، ويحتاج مطابقة مع سجل الأصول». هذا أوضح من «فحصنا الشبكة وكل شيء تمام إلا جهاز».
ولا تضع معلومات الأجهزة الداخلية في خدمات مشاركة عامة لأجل تنسيق الجدول. الناتج قد يصف بنية الجهة وأنظمتها، حتى لو لم يتضمن أسرار مصادقة. استخدم المسار المصرح للمراجعة، وانشر أمثلة اصطناعية عند تحويل التجربة إلى شرح عام.

جرّب الفرق بنفسك وارجع للمراجع عند الحاجة

في لاب تملكه، اختر جهازًا افتراضيًا واحدًا وخدمة تدريبية معلومة. راجع كائن الجهاز وحل الاسم والاتصال بالخدمة وهو يعمل. ثم اطلب إيقاف الخدمة فقط وأعد الاختبار. وبعد حفظ عملك، أوقف الجهاز بطريقة سليمة وأعد مراجعة المصادر نفسها. لا تحتاج حذف حسابه أو تعديل بيانات الدليل لهذه المقارنة.
سجل ما بقي ظاهرًا وما تغير في كل مرحلة. هل اختفى الكائن بمجرد توقف النظام؟ هل نجاح حل الاسم أخبرك بحالة الخدمة؟ هل فشل اتصال واحد أعطاك سببًا قاطعًا؟ الهدف أن تصير قادرًا على تفسير النتيجة من مصدرها، لا وصف كل شيء بكلمة «الجهاز موجود».
مرجع Microsoft لقراءة كائنات الأجهزة وخصائصها:
https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adcomputer
مرجع حل أسماء DNS:
https://learn.microsoft.com/en-us/powershell/module/dnsclient/resolve-dnsname
مرجع اختبار الاتصال المحدد:
https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection
ولفهم حدود التواريخ عند مراجعة الحسابات القديمة، اقرأ شرح lastLogon وlastLogonTimestamp في المجتمع:
https://courses.cyberpts.com/community/66/akhr-tsjyl-dkhwl-fy-active-directory-alfrq-byn-lastlogon-wlastlogontimestamp-qbl
إذا أخذت من التجربة عادة واحدة، فلتكن كتابة مصدر كل نتيجة بجانبها. حساب في الدليل، وسجل اسم، واتصال ناجح: كل واحد مفيد، لكن فائدتهم الحقيقية تظهر لما تجمعهم بدون أن تخلط معانيهم.