اختبار الدعم البعيد في SOTI وXSight: مشاهدة الشاشة مب نفس التحكم، وهل الجلسة مرتبطة بالشخص والجهاز الصحيح؟

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

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

حدد سؤال الجلسة قبل فتح شاشة جهاز

موظف الدعم يحتاج يشوف رسالة خطأ على جهاز المستودع. هل يحتاج تحريك المؤشر؟ هل يحتاج قراءة ملفات؟ هل يحتاج Terminal؟ كل قدرة إضافية تختلف عن الحاجة الأولى. لذلك لا تبدأ بكلمة Remote Control كأنها حزمة واحدة؛ حولها إلى أعمال محددة يتفق عليها صاحب العملية.

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

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

المسار قد يمر بمنتجين، فراجع الطرفين

توضح وثائق SOTI 2025.1 أن المسار المستند إلى الويب يمكن أن يفتح XSight من MobiControl، بينما هناك مسار Plugin قديم موصوف كميزة Legacy. لا تعتبر فتح تبويب ثاني مجرد تفصيل في الواجهة؛ قد تكون هناك خدمة وهوية وإعدادات وأذونات أخرى تدخل في قرار الجلسة.

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

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

Remote View وRemote Control وFile Access قدرات مختلفة

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

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

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

الموافقة والإشعار مب نفس الوظيفة

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

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

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

هوية الجهاز الفعلية تحميك من دليل على هدف غلط

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

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

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

الشاشة السوداء ما تعني أن التفويض منع الجلسة

ممكن تنشأ جلسة ثم تظهر شاشة سوداء بسبب قيود مشاركة الشاشة أو متطلبات النظام أو التطبيق أو الاتصال. وممكن يظهر الجهاز Offline أو يتطلب Plugin معينًا. لا تنسب كل فشل إلى RBAC. اقرأ مرحلة الفشل: هل رُفض طلب الجلسة؟ هل أنشئت قناة؟ هل استقبل الجهاز طلب المشاركة؟ وهل ظهرت صورة؟

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

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

المشاركة عبر المتصفح تحتاج ربطًا صحيحًا عند البداية والنهاية

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

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

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

من بدأ الجلسة؟ السجل اللي يجيب عن السؤال

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

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

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

اختبار الملفات أو Terminal له تصريح وأثر منفصل

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

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

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

الأجهزة المشتركة: المستخدم الحالي جزء من سياق الجلسة

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

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

حالات إعادة اختبار تغلق الملاحظة وتحافظ على الدعم

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

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

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

مراجع SOTI وما يربط هذا المقال بباقي السلسلة

دعم الأجهزة والقيود حسب المنصة في توثيق 2025.1:
https://soti.net/mc/help/v2025.1/en/console/troubleshooting/remotecontrol/using.html

الانتقال إلى XSight:
https://soti.net/mc/help/v2025.1/en/console/troubleshooting/remotecontrol/remote_controlling_SA.html

سجل أنشطة المستخدمين:
https://soti.net/mc/help/v2025.0/en/console/reference/dialogs/users/userlogs.html

ومقال فصل الأدوار ومجموعات الأجهزة داخل المجتمع:
https://courses.cyberpts.com/community/161/slahyat-soti-mobicontrol-lysh-allow-ma-ykfy-afhm-deny-waladwar-wmjmwaat-alajhzh-

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