عند إنشاء PowerShell Platform Script داخل Microsoft Intune لمعالجة مشكلة تشغيلية على جهاز ما، يكون التوقع المنطقي أن يتم تنفيذ السكربت فورًا بعد تعيينه. لكن الواقع التقني مختلف تمامًا. تأخير تنفيذ سكربتات PowerShell في Intune ليس عشوائيًا، ولا يرتبط بخلل في الخدمة، بل يعتمد على آليات داخلية محددة في Intune Management Extension (IME) تتحكم في متى وكيف يتم تقييم السياسات وتنفيذها. في هذا المقال سنشرح بدقة ما الذي يسبب التأخير، ولماذا لا يؤدي الضغط على زر Sync إلى تشغيل السكربت فورًا.
🧭 لماذا لا يتم تنفيذ سكربت PowerShell فور نشره؟
🧩 السؤال 1: ماذا يحدث عند نشر PowerShell Script في Intune؟
🧠 الإجابة:
عند رفع سكربت PowerShell إلى Intune وتعيينه لمجموعة أجهزة أو مستخدمين، يتم تخزين السياسة في خدمة Intune السحابية. لكن الجهاز المستهدف لا يتلقى "إشارة فورية" بالتنفيذ. بدلًا من ذلك، يعتمد التنفيذ على آلية تقييم داخلية في IME. المفهوم الأساسي هنا أن IME يعمل وفق نموذج Event-Driven وليس Push-Driven؛ أي أن الخدمة لا تبقى في اتصال حي دائم (Live Connection) بانتظار تغييرات جديدة، بل تعتمد على مؤقتات داخلية (Timers) وأحداث نظام (Events) مثل تسجيل الدخول أو إعادة تشغيل الخدمة.
من الناحية التشغيلية، بعد التعيين:
1) يتم تسجيل السياسة في الخدمة السحابية.
2) ينتظر الجهاز “محفزًا” (Trigger) يطلق دورة تقييم جديدة داخل IME.
3) عند تحقق الشرط، يقوم IME ببناء PolicyRequest وإرساله إلى خدمة Intune.
4) يستلم IME سياسات السكربتات على شكل كائنات مثل EmsPolicy ثم يصفّيها ويقرر تنفيذها وفق منطق الجدولة.
أمنيًا، هذا التصميم يقلل الحمل المستمر على الخدمة والشبكة ويمنع التنفيذ غير المنضبط الذي قد يسبب اضطرابات على الأجهزة.
🧪 مثال عملي:
قمت بتعيين سكربت لمعالجة إعداد Registry على جميع الأجهزة. الجهاز كان يعمل لكنه على شاشة تسجيل الدخول. لن يتم تنفيذ السكربت حتى يحدث:
- تسجيل دخول مستخدم (لسكربت User Context)
- أو انتهاء مؤقت 8 ساعات (8-Hour Timer)
- أو إعادة تشغيل خدمة IME (IME Service Restart)
🧩 السؤال 2: ما هو دور Intune Management Extension (IME) في التنفيذ؟
🧠 الإجابة:
Intune Management Extension (IME) هو المكوّن المحلي (Local Agent) المسؤول عن تشغيل PowerShell Scripts وWin32 Apps داخل Intune. وهو يعمل كخدمة Windows (Windows Service) ضمن سياق النظام System Context، أي بصلاحيات أعلى من صلاحيات المستخدم.
عند تشغيل الجهاز، يبدأ IME العمل في الخلفية وينتظر محفزات داخلية، أهمها:
- انتهاء مؤقت التقييم (Timer Expiration)
- تغيّر جلسة المستخدم (Session Change)
- إعادة تشغيل الخدمة (Service Restart)
داخل منطق IME توجد دالة باسم OnSessionChange(SessionChangeDescription changeDescription) تستجيب لأحداث مثل SessionLogon وSessionLogoff. وعند حدوث SessionLogon تحديدًا، قد يطلق IME مسار تقييم سكربتات PowerShell فورًا بدل انتظار المؤقت.
هذا يعني أن IME لا يتفاعل مع كل تغيير سحابي لحظيًا، بل ينتظر Trigger واضح يفرض إعادة التقييم.
🧪 مثال عملي:
جهاز بقي 6 ساعات دون تنفيذ السكربت. بمجرد تسجيل دخول المستخدم، قام IME بطباعة سطر مشابه في السجلات:
- [PowerShell] Request PS Scripts for user logon
وخلال دقيقة تم تنفيذ السكربت بنجاح.
🧩 السؤال 3: ما سبب ارتباط التنفيذ بعملية تسجيل الدخول (Logon)؟
🧠 الإجابة:
سكربتات User Context تتطلب وجود “هوية مستخدم” صالحة للتنفيذ، أي User Token (رمز أمني يمثل المستخدم). عندما يكون الجهاز على شاشة تسجيل الدخول، لا توجد جلسة مستخدم نشطة (No Active User Session)، ولا يوجد User Bearer Token يمكن للسكربت الارتباط به. لذلك:
- سكربتات Device Context يمكنها العمل في الخلفية لأنها تعمل بصلاحيات النظام.
- سكربتات User Context تتطلب SessionLogon حقيقيًا حتى يتوفر Token.
عند تسجيل الدخول، يرسل Service Control Manager إشعارًا إلى IME بحدوث SessionLogon، فيبدأ IME دورة تقييم جديدة فورًا وقد يطلب السياسات ويُنفّذ السكربت.
🧪 مثال عملي:
تم تعيين سكربت لتعديل إعدادات Outlook لكل مستخدم. الجهاز بقي 8 ساعات دون تنفيذ لأن المستخدم لم يسجل الدخول. عند تسجيل الدخول، تم التنفيذ خلال أقل من دقيقة لأن User Token أصبح متاحًا.
🧩 السؤال 4: من أين يأتي مؤقت الـ 8 ساعات؟
🧠 الإجابة:
داخل PowerShell Script Plugin في IME يوجد مؤقت (Timer) مضبوط على:
28,800,000 milliseconds = ثماني ساعات.
هذه القيمة تمثل دورة التقييم الافتراضية (Cadence) لسكربتات PowerShell عندما تكون السياسات موجودة. المهم فهم أن هذا ليس Polling مستمرًا؛ أي أن IME لا “يفحص كل دقيقة”، بل “ينتظر” حتى تنتهي الدورة ثم يبدأ التقييم.
إذا تم تعيين سكربت جديد بين دورتين، فلن يعيد IME التقييم فورًا إلا إذا حدث Trigger آخر مثل SessionLogon أو Service Restart.
🧪 مثال عملي:
إذا تم تعيين سكربت بعد ساعة واحدة من آخر دورة تقييم، فقد ينتظر الجهاز 7 ساعات إضافية قبل التنفيذ ما لم يحدث Trigger آخر.
🧩 السؤال 5: لماذا لا يؤدي الضغط على زر Sync إلى تنفيذ السكربت؟
🧠 الإجابة:
زر Sync في Intune أو على الجهاز يتواصل أساسًا مع طبقة MDM Stack عبر عميل OMA-DM Client. بينما سكربتات PowerShell من نوع Platform Scripts تعمل داخل Intune Management Extension وهو مكوّن منفصل (Separate Component) ومسار منفصل (Separate Traffic Lane).
بمعنى آخر:
- Sync يعالج سياسات MDM التقليدية.
- عبء عمل PowerShell داخل IME له دورة ومحفزات مختلفة.
لذلك الضغط على Sync لا يستدعي PowerShell Workload مباشرة ولا “يوقظ” الـ ScriptPlugin.
🧪 مثال عملي:
قمت بالضغط على Sync عشر مرات متتالية. لم يتم التنفيذ. عند تسجيل الخروج ثم الدخول (Logoff/Logon)، تم التنفيذ فورًا لأن SessionLogon هو الذي حفّز IME.
🧩 السؤال 6: ما الذي يحدث داخل PowerShell Workload أثناء التقييم؟
🧠 الإجابة:
عند بدء التقييم، يمر IME بسلسلة من الخطوات المنظمة:
1) بناء PolicyRequest وإرساله لخدمة Intune.
2) استلام السياسات ككائنات EmsPolicy.
3) تمرير السياسات عبر FilterPolicies() لتصفية ما ينطبق على السياق الحالي (User/Device).
4) تشغيل ProcessPolicies() لاتخاذ قرار التنفيذ.
5) قيام Schedule Manager (مدير الجدولة) بفحص تاريخ التنفيذ وإعادة المحاولة.
في مرحلة الجدولة يتم التحقق من:
- هل السكربت Run Once (يُنفذ مرة واحدة)؟
- هل تم تنفيذه سابقًا؟
- هل تجاوز عدد المحاولات (Retry Count)؟
- هل حان وقت التنفيذ الآن؟
بعد التنفيذ، يتم إرسال النتائج لاحقًا إلى الخدمة لتحديث حالة الجهاز في بوابة Intune.
🧪 مثال عملي:
سكربت Run Once لن يُعاد تنفيذه عند كل Logon، بل مرة واحدة فقط ما لم يتم تغييره أو إعادة تعيينه بطريقة تُعيد إدخاله ضمن شروط الجدولة.
🧩 السؤال 7: هل يمكن أن يؤدي إعادة تشغيل خدمة IME إلى التنفيذ؟
🧠 الإجابة:
نعم. إعادة تشغيل خدمة Intune Management Extension تُعد Trigger صريحًا، لأن بدء الخدمة من جديد يعيد تهيئة Workloads ويؤدي غالبًا إلى بدء دورة تقييم جديدة.
لكن تشغيليًا يجب استخدام ذلك بحذر، لأنه قد يتداخل مع عمليات أخرى مثل نشر Win32 App deployments أو عمليات تقييم مطلوبة للأجهزة.
🧪 مثال عملي:
تنفيذ أمر مثل Restart-Service IntuneManagementExtension (ضمن سياسة دعم معتمدة) قد يؤدي إلى بدء تقييم فوري للسكربتات بدل انتظار المؤقت.
🧩 السؤال 8: هل إشعارات WNS توقظ IME لتنفيذ السكربتات؟
🧠 الإجابة:
لا. Windows Notification Service (WNS) تُستخدم لتفعيل أعباء معينة (Workloads) في سيناريوهات محددة، لكنها لا تُعتبر محفزًا مباشرًا لبدء دورة تقييم PowerShell Workload داخل IME.
IME يعتمد على:
- Timer (انتهاء المؤقت)
- Session Change (تغير جلسة المستخدم)
- Service Restart (إعادة تشغيل الخدمة)
وليس على Push Notification لتشغيل سكربتات PowerShell بشكل فوري.
🧪 مثال عملي:
حتى لو استقبل الجهاز إشعارًا لتحديث تطبيق، فهذا لا يعني أن PowerShell plugin سيُعاد تقييمه في اللحظة نفسها.
🧩 السؤال 9: لماذا تبدو البوابة وكأنها فورية بينما الجهاز ليس كذلك؟
🧠 الإجابة:
بوابة Intune غالبًا تعرض Assignment State (حالة التعيين) بسرعة، لكنها لا تعني Execution State (حالة التنفيذ الفعلي) في اللحظة نفسها.
من منظور السحابة:
- السياسة مُعيّنة ✔
لكن من منظور الجهاز:
- لم يبدأ IME دورة التقييم بعد ✖
هذا الفرق بين Cloud State وDevice Evaluation Cycle هو السبب الرئيسي في الالتباس، خصوصًا عند نشر سكربتات عاجلة تتوقع تنفيذًا فوريًا.
🧪 مثال عملي:
قد ترى “Assigned” في البوابة منذ ساعات، بينما الجهاز لم ينفذ لأنه ينتظر Trigger مناسب أو انتهاء المؤقت.
🧩 السؤال 10: ما الخلاصة العملية عند نشر سكربت جديد؟
🧠 الإجابة:
عند نشر سكربت جديد، يجب توقع التنفيذ عند تحقق أحد المحفزات التالية:
- تسجيل دخول المستخدم (SessionLogon)
- إعادة تشغيل الجهاز (قد تتضمن إعادة تشغيل IME)
- إعادة تشغيل خدمة IME (Service Restart)
- انتظار انتهاء دورة 8 ساعات (8-Hour Timer)
IME يعمل وفق نموذج Event-Driven وليس Push-Driven. لذلك فهم المحفزات والدورة الزمنية يجعل السلوك متوقعًا، ويساعدك على التخطيط للنشر وتقليل الارتباك التشغيلي، خصوصًا في سيناريوهات الدعم عن بُعد.
🧪 مثال عملي:
إذا أردت تنفيذًا شبه فوري:
- اطلب من المستخدم تسجيل الخروج ثم الدخول (Logoff/Logon)
أو
- أعد تشغيل خدمة IME في سيناريو دعم مُتحكم به وفق سياسات المؤسسة.
الخاتمة:
تأخير تنفيذ PowerShell Script في Intune ليس خطأً في النظام، بل نتيجة طبيعية لتصميم Intune Management Extension (IME) القائم على الأحداث (Events) والمؤقتات (Timers). زر Sync لا يشغّل PowerShell Workload لأن مسار MDM منفصل. وتسجيل الدخول (SessionLogon) يعد من أقوى المحفزات التي تُجبر IME على إعادة التقييم. فهم هذه الآلية يمنحك قدرة أفضل على التخطيط للنشر، إدارة التوقعات، وتفسير السلوك بدقة تقنية عالية.