تتخيّل بعض المؤسسات أن نجاح Microsoft Intune يبدأ وينتهي عند شراء الترخيص وتفعيل السياسات؛ لكن الواقع التشغيلي يثبت أن القيمة الحقيقية تظهر عندما تُدار الأجهزة كـ Lifecycle كامل: بدءًا من دخول الجهاز إلى الإدارة عبر Enrollment، ثم الضبط والحماية والامتثال، ثم تشغيل التطبيقات والتحديثات، ثم المراقبة والمعالجة الاستباقية، وأخيرًا إنهاء الخدمة عبر Retirement أو Wipe أو Delete وفق السيناريو الصحيح.
عندما تكون “مرحلة اليوم صفر” مضبوطة، تقل تذاكر Service Desk، وتتحسن نتائج Compliance، ويصبح Conditional Access أكثر اتساقًا وموثوقية. في هذا المقال سنشرح الفكرة بأسلوب مبسّط وعملي، مع أمثلة تشغيلية قابلة للتطبيق.
🧭 Device Enrollment — الأساس الذي تُبنى عليه دورة حياة الجهاز
🧩 السؤال 1: ما المقصود بدورة حياة الجهاز (Device Lifecycle) في Microsoft Intune؟
🧠 الإجابة:
Device Lifecycle في Microsoft Intune هو طريقة تفكير وتشغيل لإدارة الجهاز من لحظة دخوله إلى المؤسسة حتى خروجه منها. الفكرة ليست “إضافة جهاز للوحة التحكم” فقط؛ بل بناء رحلة كاملة تشمل: تسجيل الجهاز Enrollment، ثم ضبط الإعدادات Configuration، ثم تطبيق سياسات الأمان، ثم قياس الامتثال Compliance، ثم تشغيل التطبيقات والتحديثات، ثم المتابعة المستمرة، وأخيرًا إنهاء الخدمة بطريقة صحيحة عند تغيير الجهاز أو مغادرة الموظف.
تكمن أهمية دورة الحياة في أنها تجعل الإدارة قابلة للتنبؤ. عندما يكون المسار واضحًا، يصبح لديك إجابات ثابتة لأسئلة تتكرر يوميًا: لماذا هذا الجهاز لا يطبق سياسة؟ لماذا ظهر “Not compliant”؟ لماذا انقطع الوصول إلى Microsoft 365؟ غالبًا السبب يعود لمرحلة مبكرة في الدورة، خصوصًا Enrollment أو تصميم الاستهداف.
من زاوية الأمان، دورة الحياة تمنع “الأجهزة اليتيمة” أو القديمة من البقاء في البيئة دون رقابة. ومن زاوية التشغيل، تمنع الفوضى في التقارير وتقلل الأخطاء في إجراءات مثل Remote actions.
🧪 مثال عملي:
سيناريو أجهزة الشركة (Windows): تجهيز الجهاز عبر Windows Autopilot، ثم ربطه بـ Entra ID، ثم تطبيق سياسات أساسية مثل BitLocker وSecurity baseline، ثم قياس Compliance وربطه بـ Conditional Access. النتيجة أن الوصول لخدمات العمل يصبح مبنيًا على حالة الجهاز بشكل تلقائي.
سيناريو جهاز شخصي (BYOD): تسجيل عبر Company Portal للوصول إلى البريد فقط، مع قيود تحمي بيانات العمل داخل التطبيق قدر الإمكان. النتيجة حماية بيانات المؤسسة بدون التدخل الزائد في جهاز المستخدم.
🧩 السؤال 2: لماذا تُعد مرحلة Enrollment “Day 0” أهم مرحلة في Intune؟
🧠 الإجابة:
مرحلة Enrollment هي نقطة البداية التي تُعرّف الجهاز داخل المؤسسة. في هذه المرحلة يتحدد: هل الجهاز تابع للمؤسسة Corporate أم جهاز شخصي Personal؟ هل انضمامه من نوع Entra ID Joined أم مجرد Registered؟ وهل الإدارة ستكون كاملة عبر MDM أم محدودة؟
لماذا هذا مهم؟ لأن كثيرًا من مشاكل “Intune لا يعمل” ليست مشكلة في Intune نفسه، بل لأن الجهاز دخل من المسار غير المناسب. عندها تظهر نتائج مزعجة مثل تعارض سياسات، تأخر تطبيق الإعدادات، أو “Not compliant” دون أن يفهم المستخدم السبب.
أفضل أسلوب عملي هو تصميم مسارات واضحة وثابتة: مسار واحد للأجهزة المؤسسية، ومسار آخر للأجهزة الشخصية، ثم اختبار ذلك على مجموعة Pilot قبل التعميم. بهذه الطريقة تقلّ الأعطال ويصبح الدعم الفني أسهل.
🧪 مثال عملي:
لاحظ فريق IT أن بعض أجهزة Windows ظهرت كـ Registered بدل Joined، ففشلت ملفات إعدادات مهمة. السبب كان تسجيلًا يدويًا عبر Company Portal بدل المسار المؤسسي. تم حل المشكلة بحصر الأجهزة المؤسسية على المسار المعتمد، ثم إعادة تسجيل الأجهزة التي دخلت بالطريقة الخطأ.
🧩 السؤال 3: ما الفرق بين Windows Autopilot وManual Join وBYOD من منظور Intune؟
🧠 الإجابة:
الفرق الحقيقي هو “نوع العلاقة” بين الجهاز والمؤسسة، وليس مجرد خطوات تسجيل مختلفة:
Windows Autopilot مخصص عادة لأجهزة الشركة. يجهّز الجهاز من البداية بتجربة منظمة، ويجعل الإعدادات والتطبيقات والسياسات أكثر اتساقًا، ويقلل العمل اليدوي.
Manual Entra ID Join يعني انضمامًا يدويًا. قد ينجح لكنه غالبًا يفتح باب اختلافات بين الأجهزة لأن خطوات الإعداد قد تختلف بين مستخدم وآخر.
BYOD موجه للأجهزة الشخصية. الهدف هنا هو حماية بيانات المؤسسة وتمكين الوصول، مع تقليل السيطرة على الجهاز احترامًا للخصوصية وتخفيف الاحتكاك مع المستخدم.
اختيار المسار الصحيح يجعل بقية التشغيل منضبطًا، ويقلل تعارض السياسات ويجعل الامتثال مرتبطًا بواقع الجهاز لا بتخمينات.
🧪 مثال عملي:
جهاز شركة جديد: يتم شحنه للموظف ويجهز عبر Autopilot بدون زيارة IT، ثم تصبح التطبيقات الأساسية جاهزة خلال وقت قصير.
هاتف شخصي للموظف: يتم تسجيله كـ BYOD للوصول إلى البريد، مع حماية بيانات العمل داخل التطبيق. النتيجة وصول آمن بدون سياسات ثقيلة على جهاز شخصي.
🧩 السؤال 4: كيف أحدد إن كان الجهاز Corporate أم Personal داخل Intune، ولماذا يهم ذلك؟
🧠 الإجابة:
تصنيف الجهاز كـ Corporate أو Personal هو قرار حوكمة قبل أن يكون إعدادًا تقنيًا. لأنه يحدد حدود ما يمكن لفريق IT فعله عن بُعد، ويحدد توقعات المستخدم حول الخصوصية، ويؤثر على نوع السياسات التي ينبغي تطبيقها.
لماذا يهم؟ لأن تطبيق سياسات قوية على جهاز شخصي قد يسبب رفضًا وشكاوى، بينما التعامل مع جهاز شركة كأنه شخصي قد يقلل السيطرة الأمنية ويضعف الامتثال. لذلك الأفضل أن يأتي التصنيف صحيحًا من مسار Enrollment، وليس كتصحيح بعد حدوث المشكلة.
تشغيليًا، اجعل الاستهداف مبنيًا على Ownership قدر الإمكان، ووثّق بوضوح ما الذي يحدث عند إجراءات مثل Retire أو Wipe حتى لا تقع أخطاء تسبب خسارة بيانات شخصية أو إرباك للمستخدم.
🧪 مثال عملي:
تم تسجيل iPhone شخصي بالخطأ كـ Corporate، فتم تطبيق قيود صارمة وارتفعت الشكاوى. بعد إعادة تسجيله كـ BYOD بسياسات وصول وحماية بيانات داخل التطبيقات، تحسنت تجربة المستخدم وبقيت حماية بيانات العمل.
🧩 السؤال 5: ما المتطلبات الأساسية قبل تفعيل Enrollment على مستوى المؤسسة؟
🧠 الإجابة:
قبل فتح Enrollment للجميع، تحتاج المؤسسة إلى أساس واضح حتى لا يتحول التسجيل إلى فوضى. أهم المتطلبات العملية هي: تحديد من يحق له التسجيل، وتحديد أنواع الأجهزة المسموح بها، وضبط تصور الملكية Corporate/Personal، وتجهيز الحد الأدنى من السياسات المطلوبة لليوم الأول بدون تعقيد.
المشكلة الشائعة أن بعض المؤسسات تضع شروط وصول صارمة مبكرًا فتمنع التسجيل من أساسه، مثل اشتراط “Compliant device” قبل أن يحصل الجهاز على فرصة ليصبح compliant فعليًا. لذلك يجب أن يكون التصميم تدريجيًا.
خطوات مناسبة: ابدأ بمجموعة Pilot، جهّز تطبيق Company Portal حيث يلزم، راجع إعدادات Enrollment restrictions، ثم راجع سياسات Conditional Access لتتأكد أنها لا تعطل التسجيل.
🧪 مثال عملي:
تم فرض شرط “Require device to be marked compliant” على الجميع قبل تطبيق سياسات الامتثال. النتيجة أن المستخدم لم يستطع التسجيل لأنه لم يصبح compliant بعد. الحل كان بتدرج تطبيق الشرط واستثناء مرحلة التسجيل أو مجموعات Pilot حتى يثبت الامتثال أولًا.
🧩 السؤال 6: ما أكثر أخطاء Enrollment شيوعًا التي تسبب limited control وتضارب سياسات؟
🧠 الإجابة:
الأخطاء الشائعة غالبًا تكون في التصميم، مثل خلط مسارات الأجهزة المؤسسية مع مسارات BYOD، أو السماح بأكثر من طريقة تسجيل لنفس الفئة دون ضبط. كذلك من الأخطاء استهداف السياسات على “All users” بلا تقسيم منطقي، فيلتقط الجهاز سياسات لا تخصه.
عندما تتكرر هذه الأخطاء، تظهر أعراض واضحة: فشل في تطبيق ملفات إعدادات، رسائل تعارض، وتأخر في تطبيق الإعدادات، ثم تظهر حالات “Not compliant” يصعب تفسيرها لأن الجهاز دخل بيئة سياسات غير منضبطة.
الحل العملي هو توحيد المسارات، ثم بناء استهدافات واضحة غير متقاطعة قدر الإمكان، ثم اعتماد قاعدة: عند فساد المسار بشدة، إعادة التسجيل في المسار الصحيح أفضل من ترقيع عشوائي يستهلك وقت الدعم الفني.
🧪 مثال عملي:
تم تسجيل جهاز Windows يدويًا، ثم أضيف لاحقًا إلى Autopilot، فحدث تداخل وفشل في تثبيت بعض التطبيقات. تم حل المشكلة بإعادة تعيين الجهاز وإعادة تسجيله عبر المسار المعتمد فقط، ثم تنظيف الاستهدافات التي كانت تكرر نفس الهدف.
🧩 السؤال 7: كيف أضع Best Practices لتسجيل أجهزة Windows دون تعطيل تجربة المستخدم؟
🧠 الإجابة:
أفضل قاعدة لتجربة مستخدم جيدة هي: اجعل “يوم البداية” بسيطًا ومستقرًا، ثم وسّع لاحقًا. الكثير من الأعطال تأتي من محاولة تثبيت عدد كبير من التطبيقات والسياسات الثقيلة أثناء مرحلة التجهيز الأولى، خصوصًا على شبكات ضعيفة أو أجهزة متوسطة.
نهج عملي مناسب: استخدم Autopilot للأجهزة المؤسسية، ثم ضع حزمة Day 0 تحتوي الضروري فقط (مثل سياسات أمان أساسية وتطبيقات لا غنى عنها). بعد ذلك ضع حزمة Day 1 لبقية التطبيقات والسياسات حسب القسم أو الدور.
هذا التقسيم يقلل زمن الإعداد ويزيد نسبة النجاح ويخفف ضغط Service Desk.
🧪 مثال عملي:
كانت المؤسسة تفرض 25 تطبيقًا “Required” أثناء التجهيز الأول. بعد تقسيمها إلى 6 تطبيقات Day 0 و19 تطبيقًا Day 1، انخفض زمن التجهيز وتحسنت نسبة نجاح التثبيت، وتراجعت تذاكر “التجهيز عالق” بشكل واضح.
🧩 السؤال 8: كيف أتعامل مع Enrollment للأجهزة الشخصية BYOD دون تعريض بيانات المؤسسة للخطر؟
🧠 الإجابة:
في BYOD الهدف هو حماية بيانات المؤسسة وليس التحكم الكامل في الجهاز. لذلك ركّز على ثلاثة محاور: تقييد الوصول عبر Conditional Access، حماية البيانات داخل التطبيقات حيثما أمكن، ووضع حد أدنى من متطلبات الأمان مثل قفل الشاشة وإصدار نظام مدعوم.
المهم أيضًا هو “مسار الخروج”. عند نهاية علاقة العمل يجب أن تتمكن من إزالة بيانات المؤسسة بدون المساس ببيانات المستخدم قدر الإمكان، باستخدام إجراءات مناسبة مثل Retire أو ما يعادل “Selective wipe” حسب نوع السيناريو.
بهذا الأسلوب تحصل على توازن بين الحماية والخصوصية، وهو ما يزيد التزام المستخدم ويقلل الاحتكاك.
🧪 مثال عملي:
تم السماح بالوصول للبريد فقط من تطبيقات Microsoft المعتمدة، مع سياسات تمنع نسخ بيانات العمل إلى تطبيقات غير مُدارة. عند الاستقالة تم تنفيذ Retire لإزالة بيانات العمل. النتيجة حماية بيانات المؤسسة مع احترام خصوصية المستخدم.
🧩 السؤال 9: ما العلاقة بين Enrollment وبين “Not compliant” في المراحل اللاحقة؟
🧠 الإجابة:
حالة “Not compliant” غالبًا تكون نتيجة لسبب سابق، وليس مفاجأة بلا أصل. الامتثال يعتمد على وصول سياسة الامتثال للجهاز، وقدرة الجهاز على تطبيق المتطلبات، ثم إرسال الحالة للخدمة. إذا كان Enrollment غير صحيح أو المسار غير مناسب للجهاز، قد لا تصل السياسات كما ينبغي أو يتأخر التقييم، فيظهر “Not compliant” بشكل محير.
لذلك عند التشخيص لا تبدأ من النهاية. ابدأ بالسؤال: هل الجهاز مسجل بالطريقة الصحيحة؟ هل نوع الانضمام مناسب؟ هل استلم الجهاز سياسات التهيئة الأساسية التي تحقق متطلبات الامتثال؟
هذا النهج يمنع الحلقة المزعجة التي تقطع الوصول عن المستخدم قبل أن يحصل على فرصة واقعية ليصبح compliant.
🧪 مثال عملي:
جهاز جديد ظهر Not compliant بسبب عدم تفعيل BitLocker، بينما الوصول للبريد ممنوع حتى يصبح compliant. تم تعديل سياسات Day 0 لتفعيل التشفير مبكرًا مع فترة سماح قصيرة، ثم تفعيل الحظر تدريجيًا. النتيجة أمان بدون تعطيل يوم العمل الأول.
🧩 السؤال 10: كيف أبني Enrollment Strategy قابلة للتوسع وتقلل تذاكر Service Desk؟
🧠 الإجابة:
الاستراتيجية الناجحة تقوم على ثلاثة مبادئ بسيطة: توحيد المسارات، فصل الفئات، والتدرج في التطبيق. توحيد المسارات يعني أن لكل فئة طريقة واحدة معتمدة، وليس عدة طرق “كلها صحيحة”. فصل الفئات يعني التفريق بين Corporate وBYOD وبين الفئات الحساسة والعادية. التدرج يعني Day 0 خفيف وحاسم، ثم توسع لاحق.
تشغيليًا، ابدأ بـ Pilot، واكتب تعليمات قصيرة للمستخدم توضح ما الذي سيحدث أثناء التسجيل، ثم راقب تقارير فشل التسجيل والأجهزة المكررة، واجعل المعالجة “عملية ثابتة” بدل حلول فردية.
وأمنيًا، اربط الاستراتيجية بـ Conditional Access لكن دون أن تعطل التسجيل. ضع مسارًا واضحًا لنهاية دورة الحياة: متى Retire؟ متى Wipe؟ ومتى Delete؟
🧪 مثال عملي:
عند حصر المسارات إلى: Windows Corporate عبر Autopilot، والهواتف المؤسسية عبر Enrollment رسمي، وBYOD بسياسات وصول محدودة، ثم توحيد Baseline لليوم الأول وتنظيف الاستهدافات المتداخلة، انخفضت تذاكر “Intune issues” لأن أسباب الأعطال أصبحت واضحة ومتكررة ويمكن علاجها بنمط ثابت.
خاتمة موجزة:
مرحلة Enrollment هي حجر الأساس في Microsoft Intune؛ فهي تحدد نوع الجهاز وحدود السيطرة ومسار الامتثال والوصول لاحقًا. كلما كانت الاستراتيجية أوضح وأكثر انضباطًا وتدرجًا، أصبحت بقية دورة الحياة أكثر سلاسة، وانخفضت تذاكر الدعم، وارتفعت جودة الأمان والامتثال.
🧭 Configuration & Compliance — الضبط والامتثال كقلب التشغيل اليومي
🧩 السؤال 11: ما الفرق بين Configuration Profiles وEndpoint Security Policies وSecurity Baselines داخل Intune؟
🧠 الإجابة:
قد تبدو هذه المسميات متقاربة، لكنها تؤدي أدوارًا مختلفة، وفهم الفرق بينها يقلل تعارض السياسات ويجعل التشغيل أبسط. Configuration Profiles هي الطريقة العامة لضبط إعدادات الجهاز، مثل إعدادات Wi-Fi، قيود الاستخدام، وإعدادات Windows عبر Settings catalog وغيرها.
أما Endpoint Security Policies فهي سياسات موجهة للأمان وتوجد ضمن مساحة Endpoint security، وتغطي مجالات مثل Antivirus وFirewall وEncryption وغيرها. غالبًا تكون أكثر وضوحًا من ناحية الأمان لأنها مصممة أساسًا لهذا الغرض.
بينما Security Baselines هي خطوط أساس جاهزة من Microsoft تحتوي مجموعة توصيات أمنية واسعة. يمكن استخدامها كنقطة بداية ثم تخصيصها حسب احتياج المؤسسة.
النهج العملي الأسهل هو تحديد “من يضبط ماذا”. اجعل Baseline نقطة مرجعية، واجعل Endpoint security مسؤولًا عن إعدادات الأمان التشغيلية، واجعل Configuration profiles مسؤولًا عن بقية الإعدادات العامة، مع تجنب ضبط نفس الإعداد من أكثر من مكان.
🧪 مثال عملي:
تصميم واضح: نشر Security Baseline لWindows كقاعدة عامة، ثم ضبط BitLocker وFirewall من Endpoint security، ثم ضبط Wi-Fi وOneDrive من Configuration profiles. النتيجة وضوح وتقليل فرص التعارض.
تصميم غير واضح: تفعيل Firewall بقيم مختلفة في Endpoint security وفي Configuration profile. النتيجة تعارض وفشل في التطبيق وتذاكر دعم متكررة.
🧩 السؤال 12: لماذا تظهر مشكلة “Policies apply in the wrong order” في Intune، وكيف أفهم منطق التطبيق؟
🧠 الإجابة:
كثيرون يتوقعون أن Intune يطبق السياسات بترتيب صارم مثل “سلسلة أوامر”، لكن الواقع أنه نظام توزيع وتقييم. توقيت وصول السياسة للجهاز يعتمد على الاستهداف، واتصال الجهاز، ودورات المزامنة، وأحيانًا على متطلبات مثل إعادة التشغيل أو توفر مكون معين.
لذلك قد تصل سياسة مبكرًا وأخرى لاحقًا، وقد ترى إعدادًا ينجح ثم يتغير إذا وصل إعداد آخر لنفس النقطة من مصدر مختلف. هنا ينشأ شعور “الترتيب خاطئ”، بينما المشكلة غالبًا هي وجود تداخل أو تعارض أو اعتماد على شروط مسبقة.
أفضل معالجة ليست محاولة التحكم في الترتيب، بل تحسين التصميم: اجعل لكل إعداد مالكًا واحدًا، وقلل التداخل في الاستهداف، واختبر على Pilot، ثم استخدم تقارير الحالة لمعرفة أين حدث التأخر أو الفشل.
🧪 مثال عملي:
تم نشر ثلاث سياسات تحتوي إعدادات متداخلة لنفس القيود. بعض الأجهزة كانت “تطبق” ثم “تتراجع”. بعد دمج الإعدادات المتقاربة في سياسة واحدة لكل مجال وإزالة التكرار وتقسيم الاستهداف إلى مجموعات غير متقاطعة، استقر التطبيق واختفت الأعراض.
🧩 السؤال 13: كيف أتجنب تعارض السياسات (Policy Conflicts) عندما أستخدم أكثر من نوع سياسة؟
🧠 الإجابة:
التعارض يحدث عندما يستقبل الجهاز نفس الإعداد بقيم مختلفة من أكثر من سياسة. هذا شائع لأن نفس الإعداد قد يتوفر في أكثر من قناة مثل Settings catalog وAdministrative Templates وEndpoint security، وأحيانًا Custom OMA-URI.
لتجنب ذلك عمليًا، استخدم قواعد تشغيلية واضحة:
أولًا: حدّد “مصدرًا واحدًا” لكل مجال، خصوصًا المجالات الحساسة مثل Firewall وBitLocker وDefender.
ثانيًا: قلل الاستهداف المتقاطع، واجعل المجموعات واضحة.
ثالثًا: استخدم Naming conventions تساعدك على معرفة وظيفة السياسة من اسمها.
رابعًا: راجع التعارضات دوريًا وتعامل معها بإزالة الازدواجية بدل قبول “حل مؤقت”.
عند الحاجة لإعداد غير متاح، استخدم Custom OMA-URI بحذر وبعد اختبار، واحتفظ بتوثيق واضح وخطة تراجع.
🧪 مثال عملي:
تم ضبط سياسة كلمات المرور في Administrative Templates وفي Settings catalog مع اختلافات بسيطة، فظهرت حالات تعارض. تم اعتماد Settings catalog كمصدر وحيد لهذا المجال وإزالة التكرار من القناة الأخرى، ثم إعادة مزامنة الأجهزة. النتيجة اختفاء التعارض وتحسن الاتساق.
🧩 السؤال 14: ما أفضل طريقة لتصميم Configuration Profiles: ملف واحد كبير أم عدة ملفات صغيرة؟
🧠 الإجابة:
الاختيار الصحيح يعتمد على “المجال” و“معدل التغيير”. ملف واحد كبير قد يبدو أسهل في البداية، لكنه يجعل التشخيص والتراجع أصعب، ويزيد احتمال أن يتأثر أكثر من مجال عند أي تعديل. أما الملفات الصغيرة فهي مرنة وتسهّل العزل عند حدوث مشكلة، لكنها تحتاج انضباطًا في التسمية والتوثيق حتى لا تتحول لكثرة غير مفهومة.
النهج العملي الأكثر نجاحًا هو التقسيم حسب المجالات: شبكة، تحديثات، متصفح، قيود عامة، OneDrive، وهكذا. ثم إضافة ملفات أصغر للأقسام التي تحتاج اختلافات فعلية، مثل Finance أو Dev.
تشغيليًا، هذا يجعل التتبع أسرع ويقلل أثر التغيير. وأمنيًا، يساعد على ضمان أن الإعدادات الحساسة تبقى في مصدر واضح ويمكن تدقيقه بسهولة.
🧪 مثال عملي:
تصميم مقترح: CFG-WIN-Baseline للإعدادات العامة، CFG-WIN-Updates للتحديثات، CFG-WIN-Browser لإعدادات Edge، CFG-WIN-Network لمتطلبات الشبكة. ثم سياسات إضافية صغيرة للأقسام مثل CFG-WIN-Finance-Restrictions. عند ظهور مشكلة في المتصفح تعرف مباشرة أين تبحث دون التأثير على بقية المجالات.
🧩 السؤال 15: ما الفرق بين Settings catalog وAdministrative Templates وCustom OMA-URI؟ ومتى أستخدم كل واحد؟
🧠 الإجابة:
هذه ثلاث طرق لضبط إعدادات Windows عبر Intune، ولكل واحدة مكانها:
Settings catalog هو الخيار الحديث والأوسع، يجمع عددًا كبيرًا من الإعدادات في مكان واحد، وغالبًا يعطي رؤية أفضل لحالة الإعدادات.
Administrative Templates يشبه منطق قوالب الإدارة في GPO، ومفيد عندما يكون الإعداد موجودًا هناك بشكل واضح أو عندما تحتاج نمطًا قريبًا من سياسات ADMX.
Custom OMA-URI خيار متقدم يُستخدم عندما لا يتوفر الإعداد في القنوات الأخرى. يحتاج دقة عالية في المسار والقيمة، لأن الخطأ قد يؤدي لفشل صامت أو سلوك غير متوقع.
القاعدة العملية لتقليل التعارض: استخدم Settings catalog أولًا، ثم Administrative Templates عند الحاجة، واجعل OMA-URI حلًا أخيرًا لما لا يتوفر فقط، مع اختبار وتوثيق قويين.
🧪 مثال عملي:
إذا كان إعداد مطلوب موجودًا في Settings catalog، استخدمه هناك ولا تكرر ضبطه بـ OMA-URI. وإذا احتجت إعدادًا غير متاح، استخدم OMA-URI مع توثيق الاسم والمسار والقيمة والمجموعة المستهدفة وخطة التراجع، ثم راقب التطبيق على Pilot قبل التعميم.
🧩 السؤال 16: لماذا تظهر الأجهزة “Not compliant” بدون سبب واضح؟ وكيف أضع منهج تشخيص ثابت؟
🧠 الإجابة:
“Not compliant” ليست عطلًا واحدًا، بل نتيجة تقييم لمتطلبات Compliance. قد يكون السبب أن متطلبًا لم يتحقق (مثل التشفير أو إصدار النظام)، أو أن سياسة الامتثال لم تصل للجهاز، أو أن المزامنة متأخرة، أو أن هناك تعارضًا في السياسات، أو أن Conditional Access قطع الوصول قبل اكتمال التهيئة.
لذلك تحتاج منهج تشخيص ثابت بدل التجربة العشوائية:
أولًا: تحقق من Enrollment ونوع الانضمام وملكية الجهاز.
ثانيًا: افتح تفاصيل سبب عدم الامتثال داخل تقرير Compliance policy وحدد المتطلب الذي فشل.
ثالثًا: تحقق هل الجهاز استلم السياسات اللازمة لتحقيق المتطلب (مثل BitLocker policy).
رابعًا: راجع Conditional Access وسجلات تسجيل الدخول لترى هل هناك حظر يمنع الجهاز من إكمال خطواته.
خامسًا: طبّق إصلاحًا تدريجيًا على Pilot قبل أي إغلاق واسع.
تشغيليًا، اجعل رسالة الامتثال مفهومة للمستخدم قدر الإمكان، وقدّم له خطوات بسيطة مثل “مزامنة الجهاز” أو “إعادة تشغيل” أو “الاتصال بالشبكة”.
🧪 مثال عملي:
بعد تطبيق شرط وصول جديد، أصبحت مئات الأجهزة Not compliant. بالتحليل ظهر أن الأجهزة لم تكمل متطلبات التشفير بسبب تأخر التهيئة. تم إرجاع الشرط لمجموعة Pilot، وتفعيل التشفير مبكرًا، ثم إعادة تطبيق الشرط تدريجيًا بعد تحسن نسبة الامتثال. النتيجة تقليل الانقطاع وزيادة الاستقرار.
🧩 السؤال 17: كيف يرتبط Compliance بـ Conditional Access؟ ولماذا قد يخسر المستخدم Microsoft 365 أو VPN بسبب جهاز واحد؟
🧠 الإجابة:
Conditional Access يمكنه أن يربط الوصول إلى خدمات مثل Microsoft 365 أو VPN بحالة الجهاز. إذا كانت السياسة تشترط أن يكون الجهاز “Marked as compliant”، فإن أي جهاز يظهر “Not compliant” سيُحجب عنه الوصول فورًا وفق القاعدة.
لماذا يخسر المستخدم الوصول؟ لأن CA يعتمد على “إشارة الامتثال” القادمة من Intune. إذا كانت الإشارة غير صحيحة بسبب تصميم سياسات غير منضبط أو بسبب تأخر التقييم، فإن النتيجة ستكون حجبًا حتى لو كان الهدف لديك هو الحماية لا التعطيل.
لذلك التنفيذ الآمن يعتمد على التدرج: ابدأ بـ Pilot، راقب سجلات الدخول، عالج أسباب عدم الامتثال، ثم وسّع التطبيق تدريجيًا عندما تصبح نسبة الأجهزة compliant مستقرة. بهذه الطريقة تجمع بين الأمان واستمرارية العمل.
🧪 مثال عملي:
تم تفعيل شرط “Require compliant device” على Microsoft 365 لكل الموظفين دفعة واحدة، فحدث انقطاع واسع لأن نسبة الأجهزة compliant كانت منخفضة. تم التراجع لمجموعة Pilot، ثم رفع الامتثال عبر سياسات تشفير وإصلاحات، وبعد استقرار الامتثال تم تعميم CA تدريجيًا دون انقطاعات كبيرة.
🧩 السؤال 18: كيف أتعامل مع تعارض إعدادات الأمان بين Endpoint security وConfiguration profiles؟
🧠 الإجابة:
التعامل الصحيح مع التعارض هو إعادة تحديد “مصدر الحقيقة” للأمان. تعارض الأمان يحدث عادة لأن إعدادًا حساسًا مثل Firewall أو Antivirus تم ضبطه من أكثر من مكان: Baseline، Endpoint security، أو Configuration profiles. عند اختلاف القيم، تصبح النتيجة غير موثوقة.
خطوات علاج عملية:
أولًا: اختر مكانًا واحدًا لإعدادات الأمان التشغيلية، وغالبًا يكون Endpoint security لأنه منظم لهذا الهدف.
ثانيًا: راجع Baseline وعدّل الإعدادات المتداخلة معه حتى لا يكرر ما تفعله يدويًا.
ثالثًا: احذف التكرار من القنوات الأخرى، ثم اختبر على Pilot قبل التعميم.
رابعًا: راقب التقارير بعد التعديل لتتأكد أن التعارض اختفى وأن الإعداد يطبق بثبات.
بهذا الأسلوب يصبح الأمان واضحًا وقابلًا للتدقيق بدل أن يكون خليطًا يصعب تفسيره.
🧪 مثال عملي:
تم نشر Security Baseline ثم تم إنشاء سياسة Firewall منفصلة بقيم مختلفة، فظهرت نتائج غير ثابتة. تم تعديل Baseline لإزالة التداخل، وجعل Firewall يدار من Endpoint security فقط. النتيجة مصدر واحد واضح وتقارير أكثر استقرارًا.
🧩 السؤال 19: كيف أستخدم تقارير Settings catalog وDevice status لتفسير فشل السياسات بسرعة؟
🧠 الإجابة:
التقارير هي أسرع طريق لفهم ما حدث بدل التخمين. عند فتح سياسة من Settings catalog يمكنك رؤية حالة التطبيق على الأجهزة، وأحيانًا رؤية تفاصيل على مستوى الإعداد نفسه. هذا يساعدك على معرفة هل المشكلة في الاستهداف، أم في دعم النظام، أم في التعارض، أم في تأخر المزامنة.
لتجعل التشخيص سريعًا، اتبع أسئلة ثابتة في كل حالة فشل:
هل الجهاز مستهدف فعلًا؟ هل يوجد Filter يستثنيه؟
هل الإصدار أو نوع الجهاز يدعم الإعداد؟
هل هناك سياسة أخرى تضبط نفس الإعداد بقيمة مختلفة؟
هل يحتاج الجهاز مزامنة أو إعادة تشغيل؟
تشغيليًا، اربط هذه المعلومات بتذاكر الدعم. اجعل كل تذكرة تحتوي اسم السياسة، معرف الجهاز، ونتيجة التطبيق، وما الذي تم تجربته. هذا يحول الدعم من “محاولة وخطأ” إلى عملية قابلة للتكرار.
🧪 مثال عملي:
سياسة Settings catalog كانت تظهر “Failed” على مجموعة صغيرة. بعد مراجعة التقارير تبيّن أن الإعداد غير مدعوم على إصدار Windows معين. تم تعديل الاستهداف ليشمل الأجهزة المدعومة فقط، وإضافة حد أدنى للإصدار ضمن قواعد الامتثال. النتيجة انخفاض الفشل وتحسن وضوح التقارير.
🧩 السؤال 20: ما أفضل نهج للترحيل من GPO إلى Intune دون خلق تضارب بين GPO وMDM؟
🧠 الإجابة:
الترحيل من GPO إلى Intune ليس نقلًا حرفيًا، بل إعادة تنظيم للسياسات في نموذج إدارة سحابي. أفضل نهج هو الترحيل المرحلي: ابدأ بالسياسات الأكثر أهمية وتأثيرًا، ثم انتقل تدريجيًا لبقية السياسات بعد أن ترى نتائج ثابتة في Pilot.
سبب التضارب هو أن نفس الجهاز قد يتلقى نفس الإعداد من GPO ومن Intune في الوقت نفسه، خصوصًا في بيئات Hybrid. هذا يؤدي إلى نتائج غير متوقعة ويصعّب التشخيص. لذلك الهدف خلال مرحلة التداخل المؤقتة هو تقليل الازدواجية قدر الإمكان، وتحديد “من يملك الإعداد” لكل مجموعة.
خطوات تشغيلية واضحة:
جرد GPOs وحدد الضروري منها وما يمكن الاستغناء عنه.
حدد مكافئ كل سياسة في Intune (Settings catalog أو Administrative Templates أو Endpoint security).
نفّذ Pilot على مجموعة لا تتلقى GPO المتداخل قدر الإمكان.
تجنب ترك نفس الإعداد مفعلًا في الجهتين على نفس المجموعة لفترة طويلة.
وثّق الملكية والمسؤولية خلال فترة الانتقال.
وعند السياسات الحساسة مثل Defender وFirewall وEncryption، تحقق من التطبيق فعليًا قبل إطفاء GPO نهائيًا.
🧪 مثال عملي:
تم ترحيل إعدادات المتصفح إلى Intune بينما بقيت إعدادات GPO فعّالة على مجموعة Pilot نفسها، فظهرت إعدادات متضاربة. تم تعديل Pilot ليكون في مجموعة لا تتلقى GPO المتداخل، ثم قياس التطبيق عبر تقارير Intune. بعد ثبات النتائج تم توسيع الترحيل تدريجيًا.
خاتمة موجزة:
مرحلة Configuration & Compliance هي القلب الحقيقي للتشغيل اليومي في Intune. عندما تحدد مصادر الحقيقة للإعدادات، وتمنع التعارض، وتبني الامتثال تدريجيًا قبل تفعيل Conditional Access بشكل صارم، تصبح البيئة أكثر أمانًا وأقل ضجيجًا، وتتحول تذاكر Service Desk من أزمة يومية إلى حالات محدودة يمكن التعامل معها بسرعة وبمنهج ثابت.