دليل احترافي شامل لنشر التطبيقات (App Deployment) في Intune

🎯 App Deployment in Microsoft Intune

يُعدّ نشر التطبيقات (App Deployment) داخل Microsoft Intune حجر الأساس لأي بيئة حديثة تعتمد على إدارة الأجهزة والسحابة. فنجاحك في "تغليف التطبيق ثم نشره ثم التأكد من تثبيته وتحديثه وإزالته عند الحاجة" لا يعتمد على النقرات داخل البوابة فقط، بل على فهم عميق لطبقات الإدارة مثل MDM و MAM، وأنواع التطبيقات (Win32/LOB/Microsoft Store/Microsoft 365 Apps)، ونماذج الاستهداف (User-based/Device-based)، وسياق التثبيت (User/System)، وأهم نقطة تشغيلية: قواعد الاكتشاف (Detection Rules) التي تمنح Intune القدرة على معرفة "هل التطبيق موجود فعلًا؟".

1️⃣ App Deployment — ما المقصود بنشر التطبيقات في Microsoft Intune؟

📖 نشر التطبيقات (App Deployment) هو إطار عمل تشغيلي يُغطي دورة حياة التطبيق بالكامل على الأجهزة المُدارة.
يبدأ بإعداد الحزمة (Packaging) ورفعها، ثم توزيعها واستهدافها (Assignment)، مرورًا بالتثبيت (Installation) والتحديث (Update) والمراقبة (Monitoring)، وأخيرًا الإزالة (Uninstall) عند الحاجة.

📋 مراحل دورة حياة التطبيق:

• تجهيز الحزمة — تحديد نوع التطبيق وتغليفه وتعريف أوامر التثبيت والإزالة.
• الاستهداف — توزيع التطبيق على مجموعات Entra ID وفق قواعد واضحة.
• التثبيت — تنفيذ الأمر في سياق User أو System.
• قواعد الاكتشاف — التحقق من أن التطبيق مثبت فعلًا عبر Detection Rules.
• المراقبة والتحديث — متابعة التقارير والسجلات وتحديث الإصدارات.
• الإزالة — إلغاء التثبيت عند انتهاء الحاجة وفق أمر موثوق.

لنفترض أن لديك تطبيق VPN مطلوبًا لكل الموظفين، تغلّفه كتطبيق Win32 وتضبط التثبيت في سياق System وتضع قاعدة اكتشاف تعتمد على Registry أو كود منتج MSI، ثم تُعلنه Required لمجموعة "All Corporate Devices". وفي الجهة المقابلة، أداة تصميم مطلوبة لفريق واحد فقط تُنشر كـ Available لمجموعة "Design Team" لتظهر في Company Portal.

🔑 نصيحة أساسية: إن فشل التثبيت على نسبة كبيرة، لا تبدأ بتغيير الأوامر فورًا؛ راجع أولًا قواعد الاكتشاف (Detection Rules) وسياق التثبيت، ثم افحص سجلات IME على الجهاز، لأن أغلب مشكلات "Installed but shows failed" سببها اكتشاف غير صحيح.

2️⃣ MDM vs MAM — الفرق بين إدارة الأجهزة وإدارة التطبيقات

📖 إدارة الأجهزة المحمولة (MDM) هو نموذج إدارة "الجهاز بالكامل"، بينما إدارة التطبيقات المحمولة (MAM) هو نموذج إدارة "التطبيق والبيانات فقط".
يعتمد MDM على تسجيل الجهاز (Enrollment) في Intune، بينما يعمل MAM دون الحاجة لتسجيل الجهاز، ويُستخدم بكثرة في سيناريوهات BYOD.

📋 مقارنة بين النموذجين:

• MDM: تطبيق سياسات الجهاز (Security/Configuration) والتحكم في الامتثال ونشر التطبيقات على مستوى النظام.
• MAM: حماية بيانات المؤسسة داخل التطبيقات المدعومة عبر App Protection Policies مثل منع النسخ/اللصق خارج التطبيقات المُدارة أو فرض PIN.
• الاختيار: الأجهزة المملوكة للمؤسسة أو التي تحتاج تحكمًا شاملًا → MDM، وحماية البيانات على جهاز شخصي → MAM.
• التنبيه: عندما يجتمع MDM و MAM على نفس الجهاز، يجب فهم أولوية السياسات وربطها بـ Conditional Access.

موظف يستخدم هاتفه الشخصي: بدل تسجيل الهاتف في MDM، تفرض عبر Conditional Access السماح بتسجيل الدخول إلى Microsoft 365 فقط من تطبيقات مدعومة مع سياسة حماية تطبيقات (MAM)، فتضمن عدم نسخ الملفات لتطبيقات شخصية وإمكانية المسح الانتقائي عند إنهاء الخدمة.

3️⃣ App Platforms — منصات التطبيقات في Intune

📖 منصات التطبيقات (App Platforms) تعني أن Intune لا ينشر التطبيقات بصيغة موحدة، بل يتعامل مع كل نظام تشغيل بآليات مختلفة.
لكل منصة أنواع تطبيقات، وآليات تثبيت، ومتطلبات توقيع وصلاحيات، وقواعد اكتشاف مختلفة.

📋 الصيغ حسب المنصة:

• Windows: Win32 (.intunewin) أو تطبيقات Microsoft Store.
• macOS: حزم PKG أو DMG.
• iOS/iPadOS: تطبيقات VPP أو من المتجر.
• Android: عبر Managed Google Play.

لديك تطبيق "Company VPN": على Windows تنشره Win32 مع الإعدادات، وعلى iOS تنشره من App Store مع Managed App Configuration، وعلى Android عبر Managed Google Play، ثم تضع سياسة Conditional Access تشترط امتثال الجهاز قبل الوصول.

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

4️⃣ Win32 App — لماذا يُعد الخيار الأكثر مرونة على Windows؟

📖 تطبيق Win32 هو نموذج نشر تطبيقات سطح المكتب على Windows (مثل EXE أو MSI) بعد تغليفها بصيغة .intunewin.
ما يجعله الأكثر مرونة هو إتاحته إمكانيات تشغيلية متقدمة لا توفرها الأنواع الأخرى.

📋 الإمكانيات المتقدمة لـ Win32:

• قواعد اكتشاف متعددة (Detection Rules).
• تبعية التطبيقات (Dependencies) لضمان ترتيب التثبيت.
• الاستبدال (Supersedence) لإحلال إصدار محل إصدار آخر.
• متطلبات دقيقة (Requirements) مثل الإصدار والمعمارية.
• التحكم في سلوك التثبيت وإعادة التشغيل وتجربة المستخدم.

لديك إصدار قديم من "7-Zip" منتشر على الأجهزة: تنشر الإصدار الجديد كـ Win32 مع خيار Supersedence ليحل محل القديم ويُزيله، وتضع قاعدة اكتشاف تعتمد على نسخة الملف. وتطبيق داخلي يحتاج .NET Desktop Runtime، فتنشر الـ Runtime كتطبيق مستقل ثم تجعل التطبيق يعتمد عليه كـ Dependency.

5️⃣ Win32 Content Prep Tool — أداة تجهيز محتوى Win32

📖 أداة تجهيز محتوى Win32 (Win32 Content Prep Tool) هي أداة من Microsoft لتحويل ملفات مصدر التطبيق إلى حزمة .intunewin مشفّرة.
بدلًا من رفع ملفات خام، تغلّف الأداة المحتوى بطريقة يفهمها Intune ويستطيع IME تنزيله وفكّه وتنفيذه بأمان.

📋 خطوات التغليف:

• جمع ملفات المصدر (مثل setup.exe والملفات المصاحبة) في مجلد واحد.
• اختيار ملف الإعداد الأساسي من المجلد.
• تحديد مجلد الإخراج لإنتاج الحزمة .intunewin.
• تنظيم المصادر واتباع تسمية واضحة للإصدارات وتوثيق خيارات التثبيت الصامت.

تطبيق داخلي يحتوي EXE + ملفات DLL + ملفات تكوين: تضعها كلها في مجلد واحد، تختار ملف الـ EXE كملف إعداد أساسي، فتنتج الحزمة، وبعد الرفع تستخدم أمر تثبيت صامت مع إنشاء ملف سجل (Log) داخل %ProgramData% لتسهيل الاستكشاف.

6️⃣ LOB App vs Win32 App — الفرق بين التطبيق المباشر والمرن

📖 تطبيق خط العمل (LOB App) في Intune يُقصد به نشر تطبيقات MSI مباشرة وبخيارات أبسط، مقارنة بـ Win32 App الذي يوفر إمكانيات مؤسسية متقدمة.
تاريخيًا كان LOB مناسبًا للسيناريوهات السريعة، لكنه محدود في التبعيات والاستبداد والتحكم في التثبيت والتحقق.

📋 متى تختار كل نوع؟

• LOB: لملف MSI بسيط دون تبعيات أو استبدال، عند الحاجة لنشر سريع.
• Win32: للترقية المنظمة والاستبدال (Supersedence) وإدارة التبعيات وقواعد الكشف المتقدمة.
• المعيار الاحترافي: اعتماد Win32 كمسار أساسي لمعظم تطبيقات Windows لتوحيد المنهجية.
• التوافق: عند الانتقال من SCCM إلى Intune أو بناء Co-management، تُعاد بناء التطبيقات كـ Win32 لتقارب المفاهيم.

ملف MSI لطابعة افتراضية صغيرة بدون تبعيات يمكن نشره LOB بسرعة، أما تطبيق محاسبي يحتاج Runtime وإزالة إصدار قديم وتأكيد نسخة محددة فيتطلب Win32 مع Dependencies و Supersedence وقواعد كشف دقيقة، وإلا ستتكرر حالات "تثبيت فوق تثبيت".

7️⃣ Microsoft Store App (WinGet) — متى يكون أفضل خيار؟

📖 تطبيق المتجر (Microsoft Store App (WinGet)) هو نمط نشر يعتمد على Microsoft Store الجديد / Windows Package Manager لتسهيل توزيع التطبيقات.
في كثير من الحالات تحصل على تحديثات أسهل تلقائيًا وبعبء تغليف أقل مقارنةً بـ Win32 التقليدي.

📋 مزايا واعتبارات المسار:

• تقليل العبء التشغيلي للتطبيقات الشائعة المتاحة عبر المتجر/WinGet.
• تقليل حجم المحتوى المُدار داخل Intune وتبسيط التحديثات.
• خيارات تخصيص أقل من Win32، وقد لا يتوفر كل تطبيق عبر هذا المسار.
• تحقق من مصدر التطبيق وناشره، واعتمد سياسات تقييد المتجر عند الحاجة للحوكمة الصارمة.

تريد نشر "PowerToys" أو أداة شائعة متاحة عبر المتجر: بدل حزمة Win32 وإعادة رفع كل إصدار، تنشرها عبر Microsoft Store كـ Available للمستخدمين في Company Portal. أما تطبيق يحتاج إعدادات مخصصة أثناء التثبيت أو ملفات إضافية فـ Win32 أفضل لأنك تتحكم في كل شيء.

8️⃣ App Assignment — لماذا تُعد "قرار هوية" بقدر ما هي "قرار تقني"؟

📖 تعيين التطبيق (App Assignment) هو عملية استهداف التطبيق لمستخدمين أو أجهزة عبر مجموعات Entra ID.
هو في الحقيقة قرار حوكمة وهوية: من الذي يجب أن يحصل على هذا التطبيق؟ ولماذا؟ وهل يرتبط بدور وظيفي أم بنوع جهاز أم بحالة امتثال؟

📋 عناصر التعيين:

• نوع التعيين: Required / Available / Uninstall.
• مجموعات Entra ID واضحة مع تسميات قياسية ومراجعات دورية.
• الاستثناءات (Exclusions) تُدار بحذر شديد.
• مرشحات الأجهزة (Filters) لتقييد الاستهداف حسب خصائص الجهاز ونظام التشغيل.

تطبيق HR مطلوب لكل الموظفين: تنشئ مجموعة Entra ID ديناميكية تعتمد على سمة Department وتُعلنه Required لها، فيُدار التطبيق تلقائيًا عند انتقال الموظفين. وتطبيق "Admin Tools" خاص بفريق IT، فتقيّده عبر Filter على أجهزة الشركة فقط لمنع تثبيته على BYOD.

9️⃣ Required vs Available vs Uninstall — أنواع تعيين التطبيقات

📖 Required يعني أن Intune سيحاول تثبيت التطبيق تلقائيًا، وAvailable يعني عرضه في Company Portal ليقوم المستخدم بتثبيته يدويًا، وUninstall يعني إزالته من الأهداف.
اختيار النوع يحدد تجربة المستخدم والعبء التشغيلي لكل تطبيق.

📋 متى تستخدم كل نوع؟

• Required: للتطبيقات الحرجة (VPN، عوامل الأمان، Microsoft 365 Apps) مع إدارة سلوك إعادة التشغيل.
• Available: للتطبيقات الاختيارية عبر Company Portal لتقليل الانقطاعات.
• Uninstall: لضبط النظافة (Hygiene) وسحب البرامج غير المعتمدة بعناية شديدة.
• إزالة تعيين Required لا تعني إزالة التطبيق من الجهاز؛ الإزالة تتطلب تعيين Uninstall أو منطق Supersedence.

نشر حزمة Microsoft Defender for Endpoint كـ Required على أجهزة الشركة لضمان حماية موحدة، وأدوات PDF اختيارية كـ Available لفريق محدد، وعند اكتشاف إصدار قديم غير آمن من "Java" تنشر مهمة Uninstall لهذا الإصدار ثم تنشر الحديث كـ Required أو Supersedence.

🔟 Installation Context (User vs System) — كيف يؤثر على التثبيت والاكتشاف؟

📖 سياق التثبيت (Installation Context) يحدد تحت أي هوية أمنية يتم تنفيذ التثبيت: سياق User بصلاحيات المستخدم الحالي، أو سياق System بحساب SYSTEM بصلاحيات مرتفعة.
يؤثر هذا القرار على مسارات الملفات، ومفاتيح Registry، وأوامر الإزالة، وطريقة تصميم قواعد الاكتشاف.

📋 أثر السياق على التثبيت:

• User context: تثبيت داخل AppData وكتابة مفاتيح في HKCU.
• System context: تثبيت في Program Files وكتابة في HKLM وتشغيل الخدمات.
• يجب أن تتوافق قواعد الاكتشاف مع السياق: HKCU مع User و HKLM مع System.
• قلّل الاعتماد على SYSTEM إن لم تكن هناك حاجة حقيقية.

نشر عامل أمان يحتاج خدمة Windows وكتابة مفاتيح في HKLM: تختار System context وقاعدة اكتشاف تتحقق من وجود الخدمة أو مفتاح HKLM. أما إضافة تُثبت داخل %LocalAppData% فتختار User context وقاعدة اكتشاف تعتمد على ملف داخل مسار المستخدم أو مفتاح HKCU.

مثلما يملك مدير المبنى مفتاحًا يفتح كل الغرف (سياق System) بينما يملك الموظف مفتاح غرفته فقط (سياق User)، فإن اختيار "المفتاح" الصحيح يحدد أي الأبواب تُفتح، وأين تُترك الآثار التي يبحث عنها نظام الكشف لاحقًا.

✅ خلاصة أساسيات نشر التطبيقات:

• نشر التطبيقات (App Deployment) دورة حياة كاملة من التغليف إلى الإزالة وليست "إرسال تطبيق" فقط.
• MDM يدير الجهاز بالكامل بينما MAM يحمي التطبيق والبيانات في سيناريوهات BYOD.
• Win32 هو المعيار المرن مع Detection Rules و Dependencies و Supersedence.
• التعيين (Required/Available/Uninstall) وسياق التثبيت قرارات حوكمة تؤثر على كل ما بعدها.

📖 جدول المصطلحات

المصطلح (English)	الترجمة	المفهوم
App Deployment	نشر التطبيقات	إطار تشغيلي يغطي دورة حياة التطبيق على الأجهزة المُدارة.
MDM	إدارة الأجهزة المحمولة	نموذج إدارة الجهاز بالكامل عبر تسجيله في Intune.
MAM	إدارة التطبيقات المحمولة	نموذج يحمي التطبيق والبيانات دون تسجيل الجهاز.
Win32 App	تطبيق Win32	نموذج نشر مرن لتطبيقات Windows بعد تغليفها بصيغة .intunewin.
Win32 Content Prep Tool	أداة تجهيز محتوى Win32	أداة تحول ملفات المصدر إلى حزمة .intunewin مشفرة.
LOB App	تطبيق خط العمل	نشر MSI مباشر بخيارات أبسط ومحدودة.
App Assignment	تعيين التطبيق	استهداف التطبيق لمستخدمين أو أجهزة عبر مجموعات Entra ID.
Installation Context	سياق التثبيت	يحدد الحساب (User أو System) الذي ينفذ التثبيت.

1️⃣ Detection Rules — ما هي ولماذا تُعد عنصرًا حاسمًا؟

📖 قواعد الاكتشاف (Detection Rules) هي القواعد التي يستخدمها Microsoft Intune للتحقق مما إذا كان التطبيق مثبتًا بالفعل بعد تنفيذ أمر التثبيت.
Intune لا "يفترض" النجاح؛ بل يعتمد كليًا على نتيجة الاكتشاف ليقرر هل يعلن التطبيق Installed أم Failed.

📋 لماذا هي عنصر حاسم؟

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

تم نشر عامل أمان بنجاح، لكن قاعدة الاكتشاف تبحث عن ملف في مسار مختلف عن المسار الحقيقي. النتيجة: يظهر التطبيق Failed رغم عمله فعلًا، ويستمر IME بمحاولات إعادة التثبيت مما يستهلك الموارد ويخلق تشويشًا في التقارير.

🔑 نصيحة أساسية: قاعدة الاكتشاف (Detection Rule) هي عقد تشغيلية بين فريق التغليف والنظام: إذا تحقق الشرط اعتُبر التطبيق جاهزًا، لذلك صمّمها بعناية قبل التعميم واختبرها على جهاز تجريبي.

2️⃣ File-based Detection — الاكتشاف عبر الملفات

📖 قاعدة الاكتشاف عبر الملفات (File-based Detection Rule) تعتمد على التحقق من وجود ملف في مسار محدد مع إمكانية فحص الإصدار أو تاريخ التعديل.
تُستخدم غالبًا مع تطبيقات EXE أو التطبيقات الداخلية التي لا تسجّل نفسها في Windows Registry.

📋 أفضل الممارسات:

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

تطبيق داخلي EXE يُثبت داخل C:\Program Files\CompanyApp: تضبط قاعدة الاكتشاف للتحقق من وجود CompanyApp.exe مع شرط أن يكون الإصدار أكبر أو يساوي رقمًا محددًا لضمان نجاح التحديث.

3️⃣ Registry-based Detection — الاكتشاف عبر السجل

📖 قاعدة الاكتشاف عبر السجل (Registry-based Detection Rule) تعتمد على التحقق من وجود مفتاح أو قيمة داخل Windows Registry في HKLM أو HKCU.
يُعد هذا النوع من أكثر طرق الاكتشاف استقرارًا عندما يكون التطبيق مصممًا وفق المعايير المؤسسية الصحيحة.

📋 اعتبارات هذا النوع:

• أغلب التطبيقات المؤسسية تكتب الإصدار أو حالة التثبيت في السجل عند التثبيت.
• نجاحه مرتبط مباشرة بسياق التثبيت: System غالبًا HKLM و User يعني HKCU.
• الخطأ الشائع: البحث في HKLM بينما التطبيق مثبت لكل مستخدم فيؤدي لفشل الاكتشاف.
• يمنح مؤشرًا أقرب لحالة النظام الحقيقية مقارنة بالتحقق من ملف فقط.

عامل مؤسسي يكتب قيمة Installed=1 داخل HKLM\Software\Company\Agent: تضبط قاعدة الاكتشاف للتحقق من وجود المفتاح والقيمة، ما يضمن أن الخدمة ثُبّتت بشكل صحيح.

4️⃣ MSI-based Detection — الاكتشاف عبر حزمة MSI

📖 قاعدة الاكتشاف عبر MSI تعتمد على كود المنتج (Product Code) الخاص بحزمة MSI.
يُعد هذا النوع الأسهل والأكثر موثوقية عند التعامل مع تطبيقات MSI أصلية غير معاد تغليفها.

📋 مميزاته التشغيلية:

• متكامل مع آلية Supersedence في Intune لفهم العلاقة بين الإصدارات.
• يمكن للنظام تنفيذ الاستبدال أو الإزالة تلقائيًا.
• غير مناسب لتطبيقات EXE أو MSI مغلّفة داخل Wrapper مخصص.
• يعتمد على هوية فريدة (GUID) يصعب التلاعب بها مقارنة بالملفات.

تطبيق MSI له Product Code ثابت: تدخل الكود مباشرة في قاعدة الاكتشاف، فيتعرف Intune فورًا على حالة التطبيق عند التثبيت أو التحديث دون فحص ملفات أو سجل يدويًا.

5️⃣ Script-based Detection — الاكتشاف عبر السكربت

📖 قاعدة الاكتشاف عبر السكربت (Script-based Detection Rule) تستخدم PowerShell للتحقق من أي منطق مخصص مثل عدة ملفات أو حالة خدمة أو تحقق مركب.
هذا النوع هو الأكثر مرونة لكنه أيضًا الأكثر حساسية للأخطاء.

📋 قواعد الاستخدام الصحيح:

• يجب أن يكون السكربت بسيطًا وسريع التنفيذ.
• يعيد رمز خروج واضحًا: 0 = Installed، 1 = Not Installed.
• راجع السكربت أمنيًا لتجنب تنفيذ أوامر غير ضرورية بصلاحيات مرتفعة.
• يُستخدم فقط عندما تفشل جميع طرق الاكتشاف الأخرى.

تطبيق داخلي يحتاج التحقق من وجود خدمة تعمل + ملف إعداد + إصدار معين: تنشئ سكربت PowerShell يجمع هذه الشروط ويعيد رمز الخروج 0 فقط إذا تحققت جميعها.

مثل الفحص الطبي: النظر إلى الوجه (File-based) ثم قياس الحرارة (Registry) ثم البطاقة الرسمية (MSI) وأخيرًا الفحص الشامل المركب (Script) — كل أداة أدق في حالتها المناسبة.

✅ خلاصة قواعد الاكتشاف:

• قواعد الاكتشاف (Detection Rules) هي نقطة الفصل بين البيئة المستقرة والتقارير غير الدقيقة.
• File-based للـ EXE والداخلي، وRegistry للـ HKLM/HKCU، وMSI للأصلية، وScript للمركب.
• التطابق مع سياق التثبيت (Installation Context) شرط أساسي لنجاح الاكتشاف.
• السكربت يجب أن يكون بسيطًا وسريعًا بأكواد خروج واضحة (0 = مثبت، 1 = غير مثبت).

📖 جدول المصطلحات

المصطلح (English)	الترجمة	المفهوم
Detection Rule	قاعدة الاكتشاف	القاعدة التي يتحقق بها Intune من تثبيت التطبيق فعلًا.
File-based Detection	اكتشاف عبر الملفات	التحقق من وجود ملف وإصداره في مسار محدد.
Registry-based Detection	اكتشاف عبر السجل	التحقق من وجود مفتاح أو قيمة في HKLM أو HKCU.
MSI-based Detection	اكتشاف عبر MSI	يعتمد على كود المنتج (Product Code) لحزمة MSI.
Script-based Detection	اكتشاف عبر السكربت	PowerShell ينفذ منطقًا مخصصًا للتحقق من شروط مركبة.
Product Code	كود المنتج	معرف GUID فريد لحزمة MSI.
Exit Code	رمز الخروج	القيمة التي يحدد بها السكربت حالة الاكتشاف (0 مثبت، 1 غير مثبت).
Supersedence	الاستبدال	استبدال إصدار قديم بإصدار جديد ضمن نفس التطبيق.

1️⃣ User-based vs Device-based — ما الفرق بين نموذجي التعيين؟

📖 التعيين حسب المستخدم (User-based Assignment) يتبع التطبيق هوية المستخدم عبر أجهزته المسجلة، بينما التعيين حسب الجهاز (Device-based Assignment) يثبّت التطبيق لأن الجهاز عضو في مجموعة مستهدفة.
في User-based يُنشر التطبيق تلقائيًا عند تسجيل دخول المستخدم إلى أي جهاز، وفي Device-based يُثبت بغض النظر عن المستخدم.

📋 متى تستخدم كل نموذج؟

• User-based: للتطبيقات المرتبطة بدور المستخدم مثل تطبيقات العمل اليومية.
• Device-based: للتطبيقات المرتبطة بالجهاز مثل العوامل الأمنية والسائقين و VPN وأدوات الإدارة.
• الاختيار الخاطئ قد ينشر تطبيقات حساسة على أجهزة غير مناسبة أو يفقد تطبيقات مطلوبة عند تبديل المستخدمين.

تطبيق Microsoft 365 Apps يُعين User-based لمجموعة الموظفين فيُثبت على أي جهاز يسجلون الدخول إليه، بينما عامل أمني يُعين Device-based لمجموعة أجهزة الشركة لضمان وجوده دائمًا بغض النظر عن المستخدم.

2️⃣ When User-based Fails — متى يكون التعيين حسب المستخدم خاطئًا؟

📖 يصبح التعيين حسب المستخدم (User-based Assignment) خاطئًا عندما يكون التطبيق مرتبطًا بالجهاز أو يحتاج صلاحيات مرتفعة على مستوى النظام.
في هذه الحالات قد يسبب فشل التثبيت أو تثبيتًا متكررًا عند تسجيل الدخول والخروج.

📋 حالات تستوجب Device-based:

• التطبيقات التي تعمل كخدمات Windows.
• التطبيقات المستخدمة قبل تسجيل الدخول (Pre-logon).
• التطبيقات التي تشكل جزءًا من البنية الأمنية للجهاز.
• أي تطبيق قد يخلق فجوة حماية إذا لم يسجل المستخدم المستهدف الدخول بعد.

تعيين عميل VPN كـ User-based قد يجعل الاتصال غير متوفر أثناء شاشة تسجيل الدخول؛ عند تحويله إلى Device-based مع سياق System يصبح الاتصال متاحًا فور تشغيل الجهاز.

3️⃣ Installation Context — لماذا يُعد قرارًا معماريًا؟

📖 سياق التثبيت (Installation Context) يحدد الحساب الذي يُنفذ من خلاله التثبيت: User أو System.
هو قرار معماري لأنه يؤثر على مسارات الملفات ومفاتيح Registry وصلاحيات التنفيذ وسلوك الإزالة وقواعد الاكتشاف.

📋 أثر القرار المعماري:

• User context: ضمن صلاحيات المستخدم الحالي، غالبًا داخل AppData أو HKCU.
• System context: بحساب SYSTEM، يسمح بالكتابة في Program Files و HKLM وتشغيل الخدمات.
• عدم التوافق بين السياق وقاعدة الاكتشاف من أكثر أسباب فشل التطبيقات شيوعًا.
• استخدام System دون حاجة حقيقية يزيد من سطح الهجوم.

تطبيق يُثبت في سياق User ويكتب مفاتيح في HKCU: إذا أُعدّت قاعدة الاكتشاف للبحث في HKLM، سيعتبر Intune التطبيق غير مثبت ويعيد التثبيت باستمرار.

4️⃣ Uninstall & Supersedence — كيف يؤثر السياق على الإزالة والاستبدال؟

📖 سياق التثبيت (Installation Context) يؤثر مباشرة على نجاح أو فشل أوامر الإزالة (Uninstall) والاستبدال (Supersedence).
إذا ثُبّت التطبيق في سياق User لكن أمر الإزالة يعمل في سياق System، قد لا يجد Intune المسارات أو المفاتيح الصحيحة.

📋 قواعد الاتساق:

• يجب أن يتوافق سياق الإزالة مع سياق التثبيت الأصلي.
• في Supersedence يعتمد Intune على قواعد الاكتشاف لتحديد ما إذا أزيل الإصدار القديم قبل تثبيت الجديد.
• الفشل في الإزالة يترك بقايا تطبيقات قديمة أو تعارضات تشغيلية.
• استخدم Script-based Uninstall عند الحاجة للتعامل مع ملفات جميع المستخدمين.

تطبيق مُثبت لكل مستخدم داخل AppData: عند محاولة إزالته عبر سياق System تفشل العملية، والحل هو استخدام سياق User أو سكربت إزالة يتعامل مع ملفات جميع المستخدمين.

5️⃣ Best Practices — أفضل الممارسات لربط نموذج التعيين بالسياق

📖 أفضل الممارسات تبدأ بربط المنطق الوظيفي للتطبيق بنموذج التعيين والسياق: التطبيقات المرتبطة بالمستخدم ← User-based + User context، والمرتبطة بالجهاز ← Device-based + System context.
عند الالتزام بهذه القاعدة تصبح البيئة أكثر استقرارًا وتقل حالات الفشل الصامت.

📋 الممارسات الموصى بها:

• توثيق قرار التعيين والسياق لكل تطبيق ضمن كتالوج التطبيقات المؤسسي.
• اختبار السيناريوهات الأساسية: تثبيت، اكتشاف، إعادة تشغيل، تحديث، إزالة.
• تقليل عدد التطبيقات التي تعمل في سياق System إلا لوجود مبرر تقني واضح.
• استخدام Filters لمنع التثبيت على أجهزة غير مناسبة مثل BYOD.

إضافة Teams Add-in تُعين User-based مع سياق User، بينما عامل Defender يُعين Device-based مع سياق System — هذا الفصل الواضح يمنع التعارض ويبسط الإدارة طويلة المدى.

مثل توزيع مفاتيح المنزل: مفتاح الغرفة (سياق User) لكل ساكن، ومفتاح مدير المبنى (سياق System) فقط للحارس — تسليم المفتاح الخطأ يجعل الأبواب تبقى مغلقة وقت الحاجة.

✅ خلاصة نماذج التعيين وسياق التثبيت:

• User-based يتبع هوية المستخدم بينما Device-based يتبع الجهاز نفسه.
• التطبيقات المرتبطة بالجهاز والخدمات تُدار Device-based + سياق System.
• تطابق السياق مع قواعد الاكتشاف وأوامر الإزالة شرط نجاح النشر.
• وثّق القرار لكل تطبيق واختبر السيناريوهات كاملة قبل التعميم.

📖 جدول المصطلحات

المصطلح (English)	الترجمة	المفهوم
User-based Assignment	تعيين حسب المستخدم	التطبيق يتبع هوية المستخدم عبر أجهزته المسجلة.
Device-based Assignment	تعيين حسب الجهاز	التطبيق يثبت لأن الجهاز عضو في مجموعة مستهدفة.
Installation Context	سياق التثبيت	الحساب (User أو System) الذي ينفذ التثبيت.
Uninstall	الإزالة	أمر يزيل التطبيق من الأهداف المحددة عند التقييم.
Supersedence	الاستبدال	إحلال إصدار جديد محل إصدار قديم مع خيار إزالته.
Device Filter	مرشح الجهاز	قاعدة تقيّد الاستهداف حسب خصائص الجهاز أو نظام التشغيل.
Company Portal	بوابة الشركة	تطبيق يثبت منه المستخدمون التطبيقات المتاحة.

1️⃣ How Intune Evaluates Install Status — كيف يقيّم حالة التثبيت؟

📖 يقيّم Microsoft Intune حالة التطبيق بناءً على سلسلة مترابطة من الخطوات، وليس على نتيجة أمر التثبيت فقط.
بعد تنفيذ أمر التثبيت عبر IME، يعتمد النظام كليًا على قاعدة الاكتشاف (Detection Rule) لتحديد الحالة النهائية.

📋 نقاط جوهرية في التقييم:

• الحالة تعكس "هل تحقق شرط الاكتشاف" وليس "هل نجح الأمر".
• أي خطأ في قاعدة الاكتشاف أو عدم توافقها مع السياق ينتج حالة خاطئة.
• التقارير لا تُظهر "هل نجح الأمر" بل "هل تحقق شرط الاكتشاف".
• الحالات الوهمية تؤثر على قرارات التحديث أو الإزالة.

تطبيق ثُبّت بنجاح لكن قاعدة الاكتشاف تبحث عن إصدار أقدم: النتيجة أن التطبيق يظهر Failed في التقارير، ويستمر Intune بمحاولة إعادة التثبيت في كل دورة تقييم.

2️⃣ Device vs User Install Status — الفرق في التقارير

📖 يوفر Intune منظورين لمتابعة التطبيقات: حالة تثبيت الجهاز (Device install status) وحالة تثبيت المستخدم (User install status).
الأول يركز على الجهاز بغض النظر عن المستخدم، والثاني يركز على تجربة المستخدم وتفاعله مع التطبيق.

📋 متى تستخدم كل منظور؟

• Device install status: مع التعيين حسب الجهاز (Device-based) وتطبيقات سياق System.
• User install status: مع التعيين حسب المستخدم (User-based) والنشر عبر Company Portal.
• الاعتماد على التقرير الخطأ يؤدي إلى استنتاجات غير دقيقة.
• الحالة Not applicable لا تعني فشلًا دائمًا.

تطبيق مُعين Device-based يظهر Installed في حالة تثبيت الجهاز، لكن حالة تثبيت المستخدم تظهر Not applicable لمستخدم لم يسجل الدخول بعد — هذا سلوك طبيعي وليس فشلًا.

3️⃣ IME — دور Microsoft Intune Management Extension في الاستكشاف

📖 إدارة Intune للتطبيقات (Microsoft Intune Management Extension - IME) هي المحرك المسؤول عن تنفيذ تطبيقات Win32 والسكربتات وتقييم قواعد الاكتشاف على أجهزة Windows.
بدون IME لا يمكن لـ Intune تنفيذ منطق النشر المتقدم.

📋 لماذا يبدأ الاستكشاف من IME؟

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

تطبيق يظهر Failed: بمراجعة سجل IME يتضح أن أمر التثبيت نجح لكن قاعدة الاكتشاف أعادت "Not found"؛ تُصحح مسار الملف في القاعدة فتتحول الحالة إلى Installed في التقييم التالي.

🔑 نصيحة أساسية: لا تبدأ بتغيير أوامر التثبيت عند رؤية Failed؛ راجع سجلات IME أولًا لأنها تكشف سبب فشل الاكتشاف الفعلي وتوفر عليك ساعات من التجربة والخطأ.

4️⃣ Common Failure Causes — أكثر أسباب الفشل شيوعًا

📖 أغلب حالات الفشل لا تعود إلى Intune نفسه، بل إلى تصميم الحزمة أو منطق النشر.
فهم الأسباب المتكررة يمنع تكرار المشاكل نفسها عبر التطبيقات.

📋 الأسباب الأكثر شيوعًا:

• عدم توافق سياق التثبيت (Installation Context) مع قاعدة الاكتشاف.
• أوامر تثبيت غير صامتة تنتظر تفاعل المستخدم في نشر Required.
• مسارات خاطئة في أوامر التثبيت أو قواعد الاكتشاف.
• استهداف خاطئ للمجموعات أو اعتماد حلول سريعة غير آمنة مثل تشغيل كل شيء في سياق System.

تطبيق EXE يحتاج وسيط /silent لكنه نُسي: ينتظر التثبيت تفاعل المستخدم ويفشل بعد Timeout — الحل بسيط لكنه غير واضح دون مراجعة منطقية للأوامر.

5️⃣ Troubleshooting Methodology — المنهجية الصحيحة للاستكشاف

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

📋 خطوات المنهجية:

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

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

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

✅ خلاصة المراقبة والاستكشاف:

• الحالة في Intune تعكس نتيجة قاعدة الاكتشاف وليس نجاح الأمر.
• حالة تثبيت الجهاز (Device install status) للمعدات، وحالة المستخدم (User install status) للتجربة.
• IME وسجلاته مفتاح حل معظم مشكلات التطبيقات.
• اتبع المنهجية من التعيين إلى السجلات واختبر على جهاز تجريبي قبل التعميم.

📖 جدول المصطلحات

المصطلح (English)	الترجمة	المفهوم
IME	إدارة Intune للتطبيقات	المحرك الذي ينفذ Win32 والسكربتات ويقيّم قواعد الاكتشاف.
Install Status	حالة التثبيت	الحالة النهائية التي يعلنها Intune للتطبيق.
Device install status	حالة تثبيت الجهاز	حالة التطبيق على الجهاز بغض النظر عن المستخدم.
User install status	حالة تثبيت المستخدم	حالة التطبيق من منظور تجربة المستخدم وتفاعله.
Detection Rule	قاعدة الاكتشاف	الشرط الذي يحدد نجاح التثبيت من فشله.
Autopilot	أوبايلوت	أداة التهيئة التلقائية للأجهزة أثناء الإعداد.
Company Portal	بوابة الشركة	مركز تثبيت التطبيقات المتاحة للمستخدمين.

🚀 الخاتمة

في هذا المقال انتقلنا من فهم دورة حياة نشر التطبيقات (App Deployment) في Microsoft Intune، إلى تصميم قواعد الاكتشاف (Detection Rules)، ثم نماذج التعيين (Assignment Models) وسياق التثبيت (Installation Context)، وأخيرًا المنهجية العملية للمراقبة والاستكشاف (Monitoring & Troubleshooting). الفكرة المحورية أن النشر الاحترافي لا يقوم على النقرات داخل البوابة، بل على قرارات منسجمة بين نوع التطبيق وسياق التثبيت وقاعدة الاكتشاف والتعيين الدقيق. عندما تتطابق هذه الطبقات يتحول Intune إلى منصة إدارة تطبيقات مستقرة، بتقارير أدق وفشل أقل واستكشاف أسرع. ابدأ بتطبيق هذه المبادئ على تطبيق واحد وثّق النتائج ثم عمّمها على كتالوج تطبيقاتك بالكامل.

تعديل المقال