اختبار السكربتات والملفات في SOTI MobiControl: من يكتب المحتوى، ومن يشغله، وعلى أي جهاز؟

موظف الدعم يقدر يشغّل سكربت تشخيص معتمد على جهاز عميل. هذي قدرة يحتاجها في شغله. لكن هل يقدر يغير السكربت؟ وهل يقدر يرسل ملفًا ثانيًا لنفس الجهاز؟ ولو الإجراء مسموح على مجموعة فرع واحد، هل الاستهداف نفسه يبقى محدودًا عند استخدامه داخل Profile أو Package؟

هنا مراجعة MobiControl تصير أعمق من كلمة «تشغيل سكربت». أنت تفكك سلسلة لها مؤلف ومحتوى ومراجع وهدف وهوية تنفيذ. المقال يشرح كيف تختبرها في جهاز مختبر، بقراءة إعدادات وأثر تشخيصي بسيط، وكيف تفرق بين صلاحية تشغيلية مقصودة ومسار يصل فيه محتوى غير معتمد إلى أجهزة خارج حاجة صاحب الحساب.

ثلاث قدرات تتشابه في الواجهة وتختلف في الثقة

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

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

ابدأ بجرد العناصر المتاحة لحساب الاختبار ومراجعها. لا تجمع نصوص جميع السكربتات في الشركة؛ قد تحتوي بيانات حساسة أو منطقًا داخليًا. يكفي عنصر تجريبي يمثل المسار الذي تريد فحصه. اكتب بجانبه مالكه، من يراه، من يعدله، من يربطه، ومن يستهدف به. هذي الورقة توضح أين تبدأ التجربة وأين تحتاج تعاون المسؤول.

الإصدار يغير طريقة إدارة مكتبة السكربتات

ملاحظات إصدار MobiControl 2026.1.0 تعلن صفحة مركزية لإدارة السكربتات ومراجعها، وحقوقًا على مستوى السكربت الفردي تشمل None وRead Only وRead and Write. وتذكر ضوابط تمنع تحرير أو حذف سكربتات لها مراجع. هذه تفاصيل مهمة عند مطابقة تجربة قديمة من إصدار سابق مع نشر حديث.

إذا أنت تختبر 2025 أو نسخة أقدم، لا تتوقع نفس الصفحة أو نموذج الأذونات. وإذا تختبر 2026.1، لا تفترض أن Read and Write تعني أنك تستطيع تعديل عنصر مرتبط مهما كانت قيود سلامة المراجع. اقرأ رسالة المنصة وحالة العنصر والمرجع الذي يمنع التعديل. قد يكون المسار الذي توقعت إثباته مغلقًا بهذا القيد فعلًا.

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

قراءة السكربت قد تكشف بيانات حتى بدون تشغيله

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

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

ملاحظة كشف سر عبر القراءة منفصلة عن قدرة التنفيذ. الأولى قد تثبت من حساب محدود بمجرد الوصول إلى النص، والثانية تحتاج مسار تسليم وهوية وأثر. لا تقلل خطورة القراءة إذا المحتوى فيه بيانات اعتماد فعلية، ولا تضخمها إذا النص مجرد معلومات عامة. عالج نوع البيانات وحدود جمهورها بدل التعامل مع كل سطر تقني كأنه سر.

السكربتات تستخدم لغات وسياقات مختلفة

MobiControl يدعم مسارات أوامر وسكربتات تختلف بحسب منصة الجهاز ونمط الإدارة. لا تفترض أن حقلًا اسمه Script يقبل PowerShell على أي جهاز Windows، أو أن تعليمات Android هي أوامر Shell عامة. اقرأ نوع العنصر والمنصة والوكيل والمتطلبات قبل بناء اختبارك؛ فشل الصيغة لا يثبت منعًا أمنيًا.

في مسار PowerShell يدعمه نشر المختبر، يمكن أن يحتوي التشخيص المعتمد مثلًا:
[System.Security.Principal.WindowsIdentity]::GetCurrent().Name
$PSVersionTable.PSVersion.ToString()

هذان السطران يقرآن هوية العملية وإصدار PowerShell فقط. لا تضعهما في قالب منتج مختلف دون مطابقة مسار تشغيله. الغرض معرفة من نفذ التشخيص، مب افتراض أن المنصة دائمًا تشغّل كل شيء كـ SYSTEM.

راجع كذلك الدليل من الجهاز. ظهور اسم حساب في مخرجات مكتوبة داخل السكربت لا يكفي إذا كانت مجرد نص ثابت. استخدم قراءة الهوية الفعلية، وسجل الآلية والهدف والتوقيت. هوية العملية وحدود وصولها إلى الملفات والشبكة تؤثر في الأثر، لكنها لا تخبرك وحدها بأي عمليات سمحت بها واجهة الإدارة.

من يملك الملف المرجعي قد يملك ما يستهلكه الإجراء

بعض المسارات تستخدم ملفًا أو حزمة أو مصدرًا تتزامن منه الأجهزة. الفكرة الأمنية هنا سلسلة ملكية: حتى لو السكربت نفسه لا يتغير، قد يقرأ ملف إعداد قابلًا للتعديل من طرف مختلف. راجع مصدر كل اعتماد والمجلد أو المكتبة التي يأتي منها ومن يكتبها في البيئة المختبرة.

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

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

الاستهداف جزء من الاختبار حتى لو المحتوى سليم

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

ضع جهازين تجريبيين وحدد العملية التي يفترض أن تنجح على الأول وترفض على الثاني. استخدم نفس العنصر ونفس إصدار الوكيل وحالة الاتصال. إذا ظهر إجراء للمستخدم لكنه رُفض في الخادم على المجموعة الثانية، وثق أن حد الاستهداف مطبق في الحالة المختبرة. وإذا قُبل لكنه لم يصل، تابع دليل التسليم قبل نسبة الأثر إلى التنفيذ.

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

المخرجات والحالة: صلاحيتان قد لا تمشيان مع بعض

وثائق SOTI تفرق في بعض الإصدارات بين View Script Status وAccess Script Output. هذا فصل له معنى: معرفة أن الفحص انتهى لا تعني الحاجة إلى قراءة كل ما جمعه. قد تحتوي المخرجات أسماء ملفات أو مستخدمين أو معلومات تشغيلية، بحسب ما كتبه المؤلف، حتى لو لم يحتوِ النص على أسرار.

راجع من يشاهد النتيجة وأين تحفظ وكم تبقى وفق إعداد العميل. لا تخترع مدة احتفاظ افتراضية. ضع في المختبر قيمة عامة معروفة في المخرجات، ثم قارن حسابًا له حق الحالة وحسابًا له حق المخرجات. النتيجة تشرح هل التصميم يفصل الاثنين وكيف يظهر المنع في الواجهة والخادم.

إذا كان حساب ممنوع من قراءة النص قادرًا على رؤية مخرجات حساسة لإجراء قديم، فهذه ملاحظة جمهور بيانات مستقلة. وإذا منع النظام المخرجات لكنه عرض الحالة فقط، لا تسجل كشف محتوى. تفريقك بين القنوات يوفر توصية أدق: تقليل البيانات التي يجمعها السكربت، أو تضييق جمهور المخرجات، أو كلاهما إذا كان المحتوى الحالي أكبر من حاجة الدعم.

قبول المهمة وتنفيذها ومشاهدة نتيجتها ثلاث لحظات

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

سجّل معرف المهمة إذا توفر، الجهاز، الحساب، وقت الإرسال، وقت التسليم، ووقت النتيجة. اربطها بسجل إداري ودليل من الجهاز. لا تعتبر غياب المخرجات فشل تنفيذ قبل التحقق من صلاحية عرضها وطريقة التقاطها. وفي الاتجاه الثاني، ظهور مهمة في قائمة الجهاز لا يعني أنها أنهت كل التعليمات بنجاح.

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

تمرين من أربع حالات يعطيك خريطة موثوقة

الحالة الأولى حساب مرجعي يشغّل عنصر التشخيص على جهاز المختبر المسموح، وتثبت الهوية والمخرجات. الثانية حساب دعم يشغّل نفس العنصر على الجهاز نفسه، فتقيس فصل الاستخدام عن الإدارة. الثالثة الحساب نفسه يحاول عرض إعداد تحرير العنصر التجريبي دون حفظ أي تغيير، ثم تقارن التفويض المتوقع بالمعروض.

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

لا تغير عاملين معًا ثم تلوم الصلاحيات. لو الحساب المرجعي يستخدم جهاز Windows Classic وحساب الدعم Windows Modern فأنت لا تختبر نفس المسار. ولو العنصر الأول مرتبط بسياسة والثاني غير مرتبط، اختلاف التحرير قد يكون ضابط المراجع. كل مقارنة تحتاج ثوابت واضحة وعاملًا واحدًا محل السؤال، وإلا ستعيد التجربة أكثر من مرة بدون فهم.

كيف تقدر الأثر بدون كتابة سيناريو مبالغ فيه؟

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

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

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

راجع النسخة التي وافق عليها الفريق، مب الاسم فقط

عنصر باسم Diagnostics قد يمر بإصدارات أو نسخ مختلفة أثناء العمل. في الدليل سجل معرف العنصر ونسخته أو بصمة محتواه إذا كان ذلك متاحًا، ثم قارنه بما وصل للجهاز. اسم واحد في الواجهة لا يثبت أن كل الأجهزة استهلكت نفس النص، خصوصًا إذا في توزيع مؤجل أو حزمة عدلها فريق آخر.

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

مراجع تساعدك تطابق الوظيفة مع الإصدار

تغييرات إدارة السكربتات والأذونات الفردية في 2026.1.0:
https://pulse.soti.net/support/soti-mobicontrol/product-notes/release-notes/?version=2026-1-0

مسار إرسال السكربتات في توثيق 2025.1:
https://www.soti.net/mc/help/v2025.1/en/console/other/sending_scripts.html

للقراءة السابقة عن فصل الصلاحيات العامة ومجموعات الأجهزة وAccess Permissions:
https://courses.cyberpts.com/community/161/slahyat-soti-mobicontrol-lysh-allow-ma-ykfy-afhm-deny-waladwar-wmjmwaat-alajhzh-

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