من نهج المجموعة إلى Intune ── دليل ترحيل إدارة الأجهزة للمنشآت الصغيرة والمتوسّطة

«نافذة دعم الخادم انتهت، فنخطِّط لاستبدال. لكنّنا فقدنا الثقة في أن نشتري خادم AD آخر وندير النطاق ونهج المجموعة لدورة أخرى (خمس سنوات).» «نهج المجموعة الذي قرّرناه في المكتب لا يُطبَّق أبداً على الحواسيب المحمولة المستخدمة للعمل عن بُعد. إن طُبِّق فقط عندما يتّصلون بـ VPN، هل نستطيع حقّاً أن نقول إنّنا نديرهم؟» ── على مدى السنوات القليلة الماضية، استشارات من هذا النوع من عملاء المنشآت الصغيرة والمتوسّطة ازدادت باطّراد.

الخلفيّة تغيّر في كيفيّة العمل. Active Directory (AD) المحلّيّ ونهج المجموعة (GPO) آليّة تفترض «الحاسوب على شبكة الشركة المحلّيّة ويستطيع دائماً بلوغ متحكّم نطاق». الآن وقد صارت الحواسيب المحمولة للعمل والعمل عن بُعد هي العرف، تلك الفرضيّة هي التي انكسرت. فوق ذلك، أُهمل WSUS ── الافتراضيّ الطويل لإدارة التحديثات ── في سبتمبر 2024،¹ وانتقل مركز ثقل إدارة أجهزة مايكروسوفت إلى Entra ID زائد Intune (MDM).

flowchart TB
    accTitle: الفرضيّة المنكسرة وانتقال مركز الثقل
    accDescr: AD وGPO يفترضان أنّ الحاسوب على شبكة الشركة ويستطيع دائماً بلوغ متحكّم نطاق، لكنّ الحواسيب المحمولة والعمل عن بُعد كعرف كسرا تلك الفرضيّة، ومع إهمال WSUS انتقل مركز ثقل الإدارة إلى Entra ID وIntune
    adgpo["AD وGPO محلّيّان"] -.-> premise["فرضيّة: المتحكّم يُبلَغ دائماً"]
    work["حواسيب محمولة وعمل عن بُعد كعرف"] --> broken["الفرضيّة هي التي انكسرت"]
    premise --> broken
    wsus["WSUS مُهمَل"] --> shift["مركز الثقل ينتقل إلى Entra ID+Intune"]
    broken --> shift

الشكل 1: فرضيّة AD+GPO أنّ «الحاسوب على شبكة الشركة» انكسرت مع تغيّر طرق العمل، وانتقل مركز ثقل الإدارة إلى Entra ID+Intune.

مع ذلك، الترحيل ليس كلّاً أو لا شيء. الحواسيب المُدارة بـ Entra join زائد Intune والحواسيب المنضمّة لنطاق AD زائد GPO يمكن أن تتعايش في الشركة نفسها،² وترحيل مرحليّ ممكن: أبقِ AD لخادم الملفّات، وحوِّل الحواسيب الجديدة إلى إدارة Intune. موجَّه إلى موظّفي تقنيّة المعلومات وأصحاب الأعمال في المنشآت الصغيرة والمتوسّطة، ينظِّم هذا المقال ── مستنداً إلى مصادر أوّليّة مثل Microsoft Learn حتّى أغسطس 2026 ── فروق كيفيّة عمل GPO وMDM، والإعدادات المسبقة، والترخيص، وكيفيّة جرد GPO الحاليّة، وسيناريو ترحيل مرحليّ، والمطبات.

1. الخلاصة أوّلاً

• GPO يُطبَّق عندما يكون الحاسوب متّصلاً بشبكة النطاق؛ Intune (MDM) يزامِن عبر الإنترنت. مشكلة «الإعدادات لا تصل أبداً إلى حاسوب منزليّ» لا تنشأ بنيويّاً مع MDM. مزامنة الحالة المستقرّة نحو كلّ 8 ساعات، وتجري أيضاً مزامنة مدفوعة بإشعار عند تغيّر السياسة.³
• الترحيل ليس كلّاً أو لا شيء؛ ترحيل مرحليّ يفترض التعايش هو الجواب الواقعيّ. مايكروسوفت نفسها توصي بانضمام Entra للحواسيب الجديدة، وترك الحواسيب المنضمّة للنطاق القائمة hybrid join واستبدالها في دورة تجديد العتاد.²
• يمكنك الاشتراك في Intune وحده، لكن للمنشآت الصغيرة والمتوسّطة المسار الواقعيّ استخدام Intune Plan 1 المشمول في Microsoft 365 Business Premium (حتّى أغسطس 2026). تركيب الخطط يستمرّ بالتغيّر، فأكِّد دائماً المصادر الأوّليّة قبل التوقيع.⁴⁵
• لجرد GPO الحاليّة، استخدم Group Policy analytics المضمَّن في Intune. استورد تصديراً XML لـ GPO فيُصنَّف كلّ إعداد حسب إمكان الترحيل؛ الإعدادات ذات مقابل يمكن تحويلها إلى سياسة كتالوج إعدادات.⁶
• المهام الرئيسة لعصر GPO لها تقريباً كلّها مقابل في Intune. القوالب الإداريّة تقابل كتالوج الإعدادات،⁷ وWSUS يقابل Windows Update for Business، ومفاتيح استعادة BitLocker تقابل التخزين في Entra ID،⁸ وكلمات مرور المدير المحلّيّ تقابل Windows LAPS،⁹ ونشر التطبيقات يقابل تطبيقات Win32 ‏(.intunewin)¹⁰ وتطبيقات Microsoft Store (قائمة على winget).¹¹
• الأشياء الكلاسيكيّة التي لا تنتقل كما هي سكربتات تسجيل الدخول، وتعيين المحرّكات، ونشر الطابعات. تستبدلها بنشر سكربت PowerShell،¹² وRemediations (سابقاً Proactive remediations)،¹³ أو تحويل العمل إلى تطبيق، أو «إيقاف تلك الممارسة».
• لا تنشر الإعداد نفسه من GPO وMDM كليهما. افتراضيّاً GPO يفوز عند التعارض. ضبط MDMWinsOverGP إلى 1 يجعل MDM يفوز، لكنّه ينطبق فقط على إعدادات Policy CSP.¹⁴
• الآلات المنضمّة للنطاق والآلات المنضمّة لـ Entra يمكن أن تتعايش، وآلة منضمّة لـ Entra تستطيع الوصول إلى خادم ملفّات محلّيّ. إخراج AD فوراً ليس شرط ترحيل.²

بجملة واحدة: سؤال «هل نستبدل خادم AD لدورة أخرى» ينبغي إعادة صياغته «للسنوات الخمس القادمة، بماذا سندير حواسيب تجلس خارج المكتب» والقرار على ذلك الأساس.

flowchart LR
    accTitle: إعادة صياغة السؤال الذي ينبغي تقريره
    accDescr: سؤال ما إذا كنت تستبدل خادم AD لدورة أخرى ينبغي إعادة صياغته سؤالاً بماذا ستدير الحواسيب خارج الموقع للسنوات الخمس القادمة
    q1["استبدال خادم AD لدورة أخرى؟"] -->|"أعد الصياغة"| q2["للسنوات الخمس القادمة، ماذا يدير الحواسيب خارج الموقع؟"]

الشكل 2: أعد صياغة سؤال استبدال الخادم «للسنوات الخمس القادمة، بماذا سندير حواسيب تجلس خارج المكتب» وقرّر على ذلك الأساس.

2. كيف يختلف GPO وMDM ── مقارنة آليّات التطبيق

أوّلاً، قارن الاثنين في الميدان نفسه. آليّة GPO نفسها (ترتيب تطبيق LSDOU، كيفيّة التأكيد بـ gpupdate/gpresult) مشمولة بعمق في «دليل عمليّ لنهج المجموعة (GPO)»، لذا نضيّق هنا إلى الفروق التي تهمّ قرار الترحيل.

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

flowchart TB
    accTitle: الاختيار بين إبقاء GPO حيّاً والترحيل إلى MDM
    accDescr: عدم بلوغ GPO حاسوباً منزليّاً لأنّ فرضيّة التصميم لم تعد تطابق كيفيّة العمل اليوم، ومسار فرض VPN دائم الاتّصال لإبقاء GPO حيّاً اختيار لتحمّل صيانة قطعة بنية تحتيّة منفصلة، منصّة VPN
    gap["فرضيّة التصميم لم تعد تطابق كيفيّة العمل"] --> sel{"كيف تستجيب؟"}
    sel -->|"أبقِه حيّاً بـ VPN دائم الاتّصال"| vpn["واصل GPO"]
    sel -->|"رحِّل إلى MDM"| mdm["أدِر عبر الإنترنت"]
    vpn --> cost["تتحمّل صيانة بنية تحتيّة أخرى"]

الشكل 3: مسار إبقاء GPO حيّاً بـ VPN دائم الاتّصال أيضاً اختيار لتحمّل صيانة قطعة بنية تحتيّة منفصلة: منصّة VPN.

من جهة أخرى، فاصل مزامنة MDM (نحو 8 ساعات) أخشن من تحديث GPO الدوريّ (نحو 90 دقيقة)، وإحساس «انشره فيُطبَّق فوراً» لا ينتقل. عندما تعيِّن سياسة أو تغيّرها يُرسَل إشعار إلى الجهاز ويزامِن بسرعة نسبيّة،³ لكنّ ضوابط تتطلّب فوريّة (حظر طارئ وما شابه) تحتاج إلى تصميم حول فاصل المزامنة.

flowchart TB
    accTitle: كيف يطبِّق GPO وMDM السياسة
    accDescr: GPO يُطبَّق فقط عندما يستطيع الحاسوب الاتّصال بمتحكّم نطاق داخليّ، لذا حاسوب منزليّ يعتمد على VPN؛ Intune يزامِن عبر الإنترنت نحو كلّ 8 ساعات ويزامِن أيضاً عند إشعار تغيّر سياسة، لذا يبلغ حاسوباً أينما كان
    officepc["حاسوب داخليّ"] --> dc["متحكّم نطاق"]
    officepc -.-> when["البدء وتسجيل الدخول"]
    when -.-> when2["زائد تحديث دوريّ"]
    homepc["حاسوب منزليّ"] --> vpn{"بلوغ المتحكّم عبر VPN؟"}
    vpn -->|"نعم"| dc
    vpn -->|"لا"| miss["السياسة لا تصل أبداً"]
    anypc["حاسوب أينما كان"] --> intune["خدمة Intune"]
    anypc -.-> every["مزامنة نحو كلّ 8 ساعات"]
    intune -.-> notify["تغيير مدفوع بإشعار"]
    dc ~~~ homepc
    miss ~~~ anypc

الشكل 4: GPO يُطبَّق فقط عندما يستطيع الحاسوب بلوغ متحكّم نطاق؛ Intune يزامِن عبر الإنترنت بغضّ النظر عن الموقع.

3. فرز المتطلّبات المسبقة ── الأشكال الثلاثة: انضمام نطاق، وhybrid join، وEntra join

ثمّة ثلاثة أشكال لـ «كيف ينضمّ حاسوب Windows إلى الشركة»، واختيارك يحدّد أيّ أدوات إدارة تستطيع استخدامها.²

hybrid join شكل لـ «إعطاء حاسوب منضمّ للنطاق قائم هويّة سحابيّة»، ويتيح لك بدء استخدام Intune والوصول المشروط مع الإبقاء على الأصول القائمة. غير أنّ مايكروسوفت توصي بألا تجعل hybrid join الهدف النهائيّ، وبانضمام Entra للحواسيب الجديدة والبديلة.²

ثمّة قيد واحد ينبغي استيعابه هنا. لا طريقة مدعومة من مايكروسوفت لتحويل حاسوب منضمّ للنطاق قائم (بما فيه hybrid join) إلى Entra join؛ يلزم إعادة ضبط Windows (مسح). لذلك توصي مايكروسوفت أيضاً بالانتقال إلى Entra join عند تجديد العتاد أو إعادة تثبيت نظام التشغيل.²

flowchart TB
    accTitle: أشكال الانضمام الثلاثة ومسارات الترحيل
    accDescr: حاسوب انضمام نطاق AD فقط يمكن تسجيله في Entra ID أيضاً ويصير hybrid join، لكن لا طريقة لتحويله مباشرة إلى Entra join ويلزم مسح، لذا يُوصى بانضمام Entra للحواسيب الجديدة والبديلة
    adonly["انضمام نطاق AD فقط（GPO）"] -->|"سجِّل أيضاً في Entra ID"| hybrid["hybrid join（GPO وIntune）"]
    hybrid -.->|"بلا مسار تحويل مباشر"| wipe["مسح（إعادة ضبط）مطلوب"]
    wipe --> entra["Entra join（Intune）"]
    newpc["حواسيب جديدة وبديلة"] -->|"موصى به"| entra

الشكل 5: لا طريقة مدعومة لتحويل آلة منضمّة للنطاق قائمة إلى Entra join؛ النمط المستقرّ التحويل من الحواسيب الجديدة والبديلة.

ممّا سبق، يمكن وضع هدف واقعيّ لمنشأة صغيرة أو متوسّطة هكذا.

1. أدِر الحواسيب الجديدة والبديلة بـ Entra join زائد Intune
2. اترك الحواسيب المنضمّة للنطاق القائمة ودعها تُستبدل طبيعيّاً في دورة تجديد العتاد
3. أبقِ AD في الوقت الحاليّ لأدوار متبقّية كمصادقة خادم الملفّات، وأفرغ محتويات GPO على مراحل

flowchart TB
    accTitle: إعداد تعايش أثناء ترحيل مرحليّ
    accDescr: الآلات المنضمّة لـ Entra والمنضمّة للنطاق يمكن أن تتعايش في بيئة الشركة نفسها؛ الأولى تُدار بـ Intune والثانية بـ GPO، بينما يُبقى AD لأدوار متبقّية وتُفرَّغ محتويات GPO فقط على مراحل
    env["بيئة الشركة نفسها"] --> ejoin["آلات منضمّة لـ Entra"]
    env --> djoin["آلات منضمّة للنطاق"]
    ejoin --> intune["تُدار بـ Intune"]
    djoin --> gpo["تُدار بـ GPO"]
    gpo -.-> shrink["أفرغ المحتويات على مراحل"]
    env -.-> ad["أبقِ AD للأدوار المتبقّية"]

الشكل 6: الآلات المنضمّة لـ Entra والمنضمّة للنطاق يمكن أن تتعايش في بيئة الشركة نفسها، ويُبقى AD في الوقت الحاليّ لأدوار متبقّية.

الآلات المنضمّة لـ Entra والمنضمّة للنطاق يمكن أن تتعايش في البيئة نفسها، وآلة منضمّة لـ Entra تستطيع الوصول إلى أصول داخليّة كخادم ملفّات محلّيّ.² غير أنّ لتسجيل الدخول الواحد ذاك متطلَّبين مسبقين. (1) المستخدم هويّة هجينة مزامَنة من AD محلّيّ بـ Entra Connect (أو Cloud Sync) (مستخدم يوجد في السحابة فقط لا يستطيع الحصول على بيانات اعتماد Kerberos/NTLM لـ AD)، و(2) للحاسوب قابليّة بلوغ شبكيّة إلى متحكّم نطاق (من خارج الموقع، يلزم VPN أو ما شابه).¹⁵ في خطّة الترحيل، أكِّد أوّلاً أنّه لا مستخدمين أو سيناريوهات استخدام تفشل في هاتين النقطتين.

flowchart TB
    accTitle: متطلّبات SSO المسبقة من آلة منضمّة لـ Entra إلى أصول محلّيّة
    accDescr: للوصول إلى خادم ملفّات محلّيّ من آلة منضمّة لـ Entra، يجب استيفاء متطلَّبين: هويّة هجينة مزامَنة بـ Entra Connect أو ما شابه، وقابليّة بلوغ متحكّم نطاق
    pc["آلة منضمّة لـ Entra"] --> cond1{"هويّة هجينة؟"}
    cond1 -->|"نعم"| cond2{"هل تستطيع بلوغ متحكّم؟"}
    cond1 -->|"لا"| ng1["لا تستطيع الحصول على بيانات اعتماد AD"]
    cond2 -->|"نعم"| ok["SSO إلى خادم الملفّات"]
    cond2 -->|"لا"| ng2["من خارج الموقع، يلزم VPN أو ما شابه"]

الشكل 7: لـ SSO من آلة منضمّة لـ Entra إلى أصول محلّيّة متطلَّبان: هويّة هجينة وقابليّة بلوغ متحكّم نطاق.

4. الترخيص والتكلفة ── أيّ الخطط تشمل Intune (حتّى أغسطس 2026)

ترخيص Intune الأساس Microsoft Intune Plan 1، يُقدَّم اشتراكاً مستقلّاً ومضمَّناً في خطط Microsoft 365 متنوّعة.⁴

ما يهمّ المنشآت الصغيرة والمتوسّطة أنّ Microsoft 365 Business Premium، لحتّى 300 مستخدم، يشمل Intune Plan 1.⁵ يشمل Business Premium أيضاً Microsoft Entra ID P1 وMicrosoft Defender for Business، لذا إعداد سياسة الامتثال زائد الوصول المشروط المذكور لاحقاً يمكن إكماله داخل هذه الخطّة. أمّا Business Standard/Basic فلا يشملان Intune. عندما تنتقل من عقد بريد وOffice فقط إلى إدارة أجهزة، تكلفة الترقية إلى Business Premium هي التكلفة الفعليّة لإدخال Intune.

flowchart TB
    accTitle: كيف تتعلّق خطط المنشآت الصغيرة والمتوسّطة بـ Intune
    accDescr: Business Premium لحتّى 300 مستخدم يشمل Intune Plan 1 وEntra ID P1 وDefender for Business ويُكمل حتّى الوصول المشروط، لكنّ Business Standard/Basic لا يشملان Intune
    bp["Business Premium"] -.-> cap["حتّى 300 مستخدم"]
    bp --> intune["Intune Plan 1"]
    bp --> p1["Entra ID P1"]
    bp --> dfb["Defender for Business"]
    p1 --> ca["يُكمل حتّى الوصول المشروط"]
    dfb ~~~ std["Business Standard/Basic"]
    std --> noint["لا يشمل Intune"]

الشكل 8: يشمل Business Premium ‏Intune Plan 1 وEntra ID P1؛ Business Standard/Basic لا يشملان Intune.

ثمّة محذوران.

• تركيب الخطط يتغيّر كثيراً. حتّى في 2026، تغييرات تعيد توزيع ميزات Intune Suite إلى خطط Microsoft 365 أعلى (E3/E5 وما شابه) كانت جارية، ومراجعات ما هو مضمَّن مستمرّة.⁴ عالج هذا القسم حتّى أغسطس 2026، وقبل التوقيع أكِّد دائماً أحدث المعلومات على صفحات ترخيص مايكروسوفت وأسعارها.
• بعض الميزات التي تستطيع فتحها من واجهة Intune تتطلّب ترخيصاً منفصلاً. المثال النموذجيّ Remediations، المذكور لاحقاً: يتطلّب ترخيصاً من فئة Windows Enterprise E3/E5 (مضمَّن في Microsoft 365 E3/E5 وما شابه) وهو غير متاح ضمن نطاق Business Premium.¹³

مقارنة التكلفة ليست «تكلفة اشتراك Intune» مقابل «صفر». في جانب GPO أنت تدفع أصلاً استبدال عتاد خادم AD، وتراخيص Windows Server وCAL، وتكلفة البناء، وخمس سنوات صيانة، ونسخاً احتياطيّاً، واستجابة حوادث. المقارنة الصحيحة وضع عرض استبدال الخادم بجانب خمس سنوات من Business Premium، ثمّ إدخال فرق القدرة «هل تبلغ الإدارة حواسيب خارج الموقع».

flowchart TB
    accTitle: الطريقة الصحيحة للتفكير في مقارنة التكلفة
    accDescr: جانب GPO أيضاً يتحمّل تكاليف كاستبدال خادم AD وتراخيص وخمس سنوات صيانة، لذا ضع عرض استبدال الخادم بجانب خمس سنوات من Business Premium ثمّ قرّر مع إدخال فرق القدرة ما إذا كانت الإدارة تبلغ حواسيب خارج الموقع
    gpocost["تكلفة مواصلة GPO"] --> hw["استبدال خادم، تراخيص، CAL"]
    gpocost --> ops["بناء، صيانة، نسخ احتياطيّ"]
    bpcost["تكلفة الترحيل إلى Intune"] --> sub["خمس سنوات Business Premium"]
    hw --> diff["ضع فرق السنوات الخمس جنباً إلى جنب"]
    ops --> diff
    sub --> diff
    diff --> ability["أدخل ما إذا كانت الإدارة تبلغ حواسيب خارج الموقع"]

الشكل 9: ضع عرض استبدال الخادم بجانب خمس سنوات من Business Premium، وقرّر مع إدخال فرق قدرة إدارة حواسيب خارج الموقع.

5. كيف تفعل في Intune ما كنت تفعله بـ GPO

لكلّ من المهام الرئيسة لعمليّات GPO، يُعرض مقابل Intune في جدول توافق.

بضع ملاحظات.

• كتالوج الإعدادات شاشة تقابل «طبعة السحابة لمحرِّر GPO»، ومايكروسوفت نفسها تضعه «وجهة الترحيل الطبيعيّة عندما تريد الضبط بالدقّة نفسها كـ GPO محلّيّ». يشمل سياسات مدعومة بـ ADMX (طبعة MDM لإعدادات معرَّفة في ADMX)، وثمّة أيضاً ميزة (معاينة) لاستيراد ADMX طرف ثالث.⁷
• سياسة الامتثال زائد الوصول المشروط فكرة لم تكن لـ GPO. تعرِّف شروط امتثال مثل «BitLocker مفعَّل، نظام التشغيل حاليّ، Defender يعمل» ويمكنك حظر وصول Microsoft 365 من أجهزة لا تستوفيها. الوصول المشروط ميزة Entra ID P1 ومشمولة في Business Premium.¹⁶
• Remediations أُعيدت تسميته من Proactive remediations. آليّة تشغِّل دوريّاً زوج سكربت كشف زائد سكربت إصلاح، ويمكنها استبدال نوع عمليّات GPO التي «تصلح شيئاً عند كلّ تسجيل دخول»، لكن كما ذُكر تتطلّب ترخيصاً من فئة Windows Enterprise E3/E5.¹³ ضمن نطاق Business Premium، البديل الواقعيّ الجمع بين سكربتات المنصّة (تُشغَّل عندما يتغيّر السكربت أو التعيين، وتُعاد المحاولة عند الفشل)¹² وقواعد كشف تطبيقات Win32.
• الخيارات التفصيليّة لإدارة التحديثات (القرار بين WUfB وAutopatch ومواصلة WSUS) مشمولة في «إدارة تحديثات Windows بعد إهمال WSUS»، وتصميم BitLocker وLAPS في «دليل BitLocker العمليّ» و«دليل عمليّ لـ Windows LAPS» على التوالي.

flowchart TB
    accTitle: تدفّق سياسة امتثال ووصول مشروط
    accDescr: سياسة امتثال تحكم فقط حالة امتثال جهاز مقابل شروط الامتثال؛ فقط عندما تتطلّب سياسة وصول مشروط جهازاً ممتنلاً تُسمَح الأجهزة الممتنلة وتُحظَر غير الممتنلة
    policy["عرِّف شروط الامتثال"] -.-> cond["BitLocker مفعَّل، نظام التشغيل حاليّ، وما شابه"]
    policy --> state["احكم حالة امتثال الجهاز"]
    state --> ca["الوصول المشروط يتطلّب امتثالاً"]
    ca -->|"ممتثل"| allow["وصول Microsoft 365 مسموح"]
    ca -->|"غير ممتثل"| block["الوصول محظور"]

الشكل 10: حكم حالة الامتثال عمل سياسة امتثال؛ الحظر عمل وصول مشروط. فقط بالجمع يأخذ الحظر أثره.

6. جرد GPO الحاليّة ── الفرز بـ Group Policy analytics

أوّل عمل حقيقيّ لخطّة ترحيل جرد GPO الحاليّة. لدى Intune ميزة مخصَّصة، Group Policy analytics، تستطيع تصنيف، لكلّ إعداد، «هل يستطيع MDM استبدال هذا» دون أن تقرأ GPO يدوياً.⁶

الخطوات كالتالي.⁶

1. افتح وحدة إدارة نهج المجموعة (GPMC.msc) على متحكّم نطاق أو ما شابه، انقر يميناً GPO المستهدفة ← Save Report وصِدِّرها ملفّ XML (4 ميغابايت أو أقلّ لكلّ ملفّ)
2. في مركز إدارة Intune، اذهب إلى Devices ← Group Policy analytics واستورد XML (الاختيار المتعدّد مسموح)
3. بعد تحليل تلقائيّ، تعرض كلّ GPO نسبة دعم MDM (حصّة الإعدادات ذات مكافئ في Intune)
4. في تقرير Group policy migration readiness، أكِّد التصنيف لكلّ إعداد: Ready for migration / Not supported / Deprecated
5. إعدادات Ready for migration يمكن تحويلها كما هي إلى سياسة كتالوج إعدادات ونشرها

flowchart TB
    accTitle: تدفّق الجرد بـ Group Policy analytics
    accDescr: صدِّر GPO كـ XML من GPMC واستوردها إلى Intune؛ تُعرض نسبة دعم MDM وجاهزيّة الترحيل لكلّ إعداد، وإعدادات Ready for migration يمكن تحويلها إلى سياسة كتالوج إعدادات
    export["صدِّر GPO كـ XML من GPMC"] --> import["استورد إلى Intune"]
    import --> rate["تُعرض نسبة دعم MDM"]
    rate --> report["تقرير جاهزيّة الترحيل"]
    report --> ready["Ready for migration"]
    report --> notsup["Not supported"]
    report --> dep["Deprecated"]
    ready --> convert["حوِّل إلى سياسة كتالوج إعدادات"]

الشكل 11: من تصدير XML عبر الاستيراد، والتصنيف لكلّ إعداد، والتحويل إلى كتالوج الإعدادات ── ذلك تدفّق Group Policy analytics.

ثمّة محذور مهمّ في البيئات اليابانيّة. تحليل إعدادات غير ADMX في Group Policy analytics بالإنجليزيّة فقط؛ استيراد GPO فيه إعدادات بلغة غير الإنجليزيّة يمكن أن يجعل نسبة دعم MDM غير دقيقة.⁶ عالج نسبة الدعم قيمة مرجعيّة تقريبيّة، واجعل الحكم النهائيّ من القائمة لكلّ إعداد.

flowchart TB
    accTitle: محذور عند تحليل GPO يابانيّة
    accDescr: تحليل إعدادات غير ADMX في Group Policy analytics بالإنجليزيّة فقط، لذا GPO فيها إعدادات يابانيّة يمكن أن تجعل نسبة دعم MDM غير دقيقة؛ عالج النسبة مرجعاً تقريبيّاً واجعل الحكم النهائيّ من القائمة لكلّ إعداد
    jgpo["GPO فيها إعدادات يابانيّة"] --> limit["تحليل غير ADMX بالإنجليزيّة فقط"]
    limit --> rate["نسبة الدعم يمكن أن تكون غير دقيقة"]
    rate --> use1["عالج النسبة مرجعاً تقريبيّاً"]
    rate --> use2["اجعل الحكم النهائيّ من القائمة لكلّ إعداد"]

الشكل 12: في GPO يابانيّة يمكن أن تكون نسبة دعم MDM غير دقيقة، لذا اجعل الحكم النهائيّ من القائمة لكلّ إعداد.

عمليّاً، قسِّم نتائج التصنيف إلى ثلاث أكوام.

1. إعدادات تُهمَل ── إعدادات عصر Internet Explorer، وإعدادات لأنظمة مُخرَجة، وإعدادات لا أحد يستطيع شرح سببها. أكبر عائد للجرد، في الواقع، القدرة على رمي هذه الكومة. GPO أُديرت عشر سنوات فيها قدر معتبر من الإرث متراكم.
2. إعدادات تُنقَل إلى Intune ── تلك من بين Ready for migration التي ستظلّ تحتاجها. حوِّلها إلى كتالوج الإعدادات وتحقّق بمجموعة تجريبيّة.
3. إعدادات تصمِّم لها بديلاً ── تلك من بين Not supported التي ستظلّ تحتاجها. أمثلة نموذجيّة واتّجاهات الاستبدال كالتالي.

flowchart TB
    accTitle: الأكوام الثلاث لنتائج الجرد
    accDescr: تُعالَج نتائج الجرد ثلاث أكوام: إعدادات تُهمَل، وإعدادات تُنقَل إلى Intune وتُتحقَّق، وإعدادات بلا مقابل وتصميم بديل لها
    result["نتائج التصنيف"] --> discard["إعدادات تُهمَل"]
    result --> more{"انقل أم استبدل؟"}
    more --> move["انقل إلى Intune"]
    more --> alt["صمِّم بديلاً"]
    discard -.-> legacy["تخلَّص من الإرث"]
    move --> pilot["كتالوج الإعدادات"]
    pilot -.-> pilotN["ثمّ تحقّق"]
    alt --> design["سكربت أو اجعله تطبيقاً"]

الشكل 13: قسِّم نتائج الجرد إلى الأكوام الثلاث «أهمل»، و«انقل إلى Intune»، و«صمِّم بديلاً».

7. سيناريو ترحيل مرحليّ ── خمس مراحل ومعايير خروج

قسِّم الكلّ إلى خمس مراحل وضَع معيار خروج على كلّ منها. تقرير مسبقاً «متى نستطيع القول إنّ هذا تمّ» الحيلة التي تمنع ترحيل تقنيّة معلومات شخص واحد من التوقّف.

flowchart TB
    accTitle: سيناريو ترحيل بخمس مراحل
    accDescr: تقدّم على مراحل من التجريب عبر سياسة الأساس، ونشر التطبيقات، واستبدال الحواسيب القائمة في دورة تجديد العتاد، وتقليص دور AD، وأخيراً اجعل الإعدادات المنشورة عبر GPO صفراً
    s1["（1）تجريب"] --> s2["（2）سياسة أساس"]
    s2 --> s3["（3）نشر تطبيقات"]
    s3 --> s4["（4）استبدال طبيعيّ لحواسيب قائمة"]
    s4 --> s5["（5）تقليص دور AD"]
    s5 -.-> goal["الإعدادات المنشورة عبر GPO صفر"]

الشكل 14: تقدّم الترحيل في خمس مراحل من التجريب عبر تقليص دور AD، وقرّر معيار خروج كلّ مرحلة مسبقاً.

النقاط الرئيسة لكلّ مرحلة.

• (1) التجريب يبدأ بحاسوب كنت ستشتريه على أيّ حال ── حاسوب الموظّف الجديد التالي، واستبدال عطل/إصلاح، وما شابه. البدء من آلة جديدة له مزيّة أنّك تستطيع البدء بصفر استثمار إضافيّ، وإن فشل تستطيع المسح والبدء من جديد. متى نما العدد، انظر في استخدام Windows Autopilot لأتمتة من OOBE (الإعداد الأوّليّ) عبر انضمام Entra زائد تسجيل Intune.²
• في (2) سياسة الأساس، لا تهدف إلى إعادة إنتاج كلّ إعداد GPO. أوّلاً ضيِّق إلى الخمسة: تحديث، وتشفير، وDefender، وقفل شاشة، وLAPS، وأظهر حالة الامتثال بسياسة امتثال. تفعيل «أجهزة ممتنلة فقط» في الوصول المشروط يأتي بعد أن أكَّدت أنّه لا إيجابيّات كاذبة في التجريب.¹⁶
• (3) نشر التطبيقات مستمرّ مع أتمتة التجهيز. إن كان لديك أصلاً إجراء قائم على winget («أتمتة تجهيز الحواسيب بـ winget + PowerShell»)، يمكن إعادة استخدام ذلك الأصل تقريباً كما هو كغلاف تطبيق متجر (جديد) أو تطبيق Win32.¹¹
• (4) الحواسيب القائمة، كما قال الفصل 3، لا مسار تحويل إلى Entra join، لذا المبدأ الاستبدال الطبيعيّ. المنظّمات التي ما زال لديها خطّة استبدال Windows 10 («خيارات عمليّة بعد انتهاء دعم Windows 10») يمكنها تجنّب فعل العمل مرّتين بتقديم ذلك الاستبدال في الوقت نفسه مع (4).
• في (5) تقليص دور AD، إفراغ GPO لا يعني بالضرورة أنّ AD غير ضروريّ فوراً. إن بقيت مصادقة خادم ملفّات، وعمليات بحث LDAP من تطبيقات قديمة، وما شابه، يواصل AD بشكل مقلَّص «خادم مصادقة». جرد تلك وضبط مواعيد عمل هذه المرحلة.

flowchart TB
    accTitle: ماذا تفعل بـ AD بعد أن تفرغ GPO
    accDescr: حتّى بعد أن تفرغ GPO، إن بقيت مصادقة خادم ملفّات أو عمليات بحث LDAP من تطبيقات قديمة، يواصل AD بشكل مقلَّص خادم مصادقة، وجرد الأدوار المتبقّية وضبط مواعيد عمل المرحلة النهائيّة
    gpoempty["GPO فارغة"] --> remain{"ما الأدوار المتبقّية؟"}
    remain -->|"مصادقة خادم ملفّات"| keep["واصل بشكل مقلَّص خادم مصادقة"]
    remain -->|"عمليات بحث LDAP قديمة"| keep
    remain -->|"بلا أدوار متبقّية"| retire["انظر في إخراج AD نفسه"]
    keep --> task["نفِّذ الجرد وضبط المواعيد"]

الشكل 15: حتّى بعد أن تفرغ GPO، إن وُجدت أدوار متبقّية، يواصل AD بشكل مقلَّص خادم مصادقة.

8. المطبات

8.1. تطبيق مزدوج لـ GPO وMDM ── افتراضيّاً GPO يفوز

أثناء فترة الترحيل، سينشر GPO وIntune كلاهما إعدادات إلى الحاسوب نفسه (آلة hybrid join). هنا، عندما يتعارض الإعداد نفسه، نهج المجموعة يفوز افتراضيّاً. ضبط MDMWinsOverGP لـ Policy CSP إلى 1 يجعل إعداد جانب MDM يفوز ويحظر إعداد GPO المقابل، لكنّ تلك الآليّة تنطبق فقط على إعدادات تحت Policy CSP ولا تنطبق على إعدادات معرَّفة في CSP أخرى مثل Defender CSP. مايكروسوفت نفسها تنصّ على أنّك إن ضبطت إعداداً ليس تحت MDMWinsOverGP من GPO وMDM كليهما، تدخل حالة تعارض ولا ضمان أيّهما يفوز.¹⁴

flowchart TB
    accTitle: الأسبقيّة عندما يتعارض GPO وMDM
    accDescr: إن نشرت الإعداد نفسه من GPO وMDM كليهما، GPO يفوز افتراضيّاً؛ ضبط MDMWinsOverGP إلى 1 يجعل MDM يفوز فقط لإعدادات تحت Policy CSP، ولإعدادات في CSP أخرى لا ضمان أيّهما يفوز
    both["انشر الإعداد نفسه من GPO وMDM كليهما"] --> flag{"MDMWinsOverGP=1؟"}
    flag -->|"لا"| gpowin["GPO يفوز（افتراضيّ）"]
    flag -->|"نعم"| csp{"إعداد تحت Policy CSP؟"}
    csp -->|"نعم"| mdmwin["MDM يفوز"]
    csp -->|"لا"| unknown["لا ضمان أيّهما يفوز"]
    both -.-> avoid["المبدأ ألا تنشر من كليهما"]

الشكل 16: افتراضيّاً GPO يفوز، وMDMWinsOverGP ينطبق فقط تحت Policy CSP. المبدأ تجنّب النشر المزدوج.

المبدأ العمليّ بسيط. لا تعتمد على ضبط الأسبقيّة؛ لا تنشر الإعداد نفسه من كليهما. لإعداد نقلته إلى Intune، أعد إعداد جانب GPO المقابل إلى «Not configured»، أو ألغِ ربط GPO تماماً. قائمة المُرحَّل في الفصل 6 أيضاً دفتر هذا.

8.2. الاعتماد على أصول محلّيّة ── محرّكات شبكة وطابعات

كثير من مواضع توقّف ترحيل ليست ميزات Intune بل الاتّصال بأصول محلّيّة. الوصول نفسه من آلة منضمّة لـ Entra إلى خادم ملفّات محلّيّ ممكن،² لكن إن اعتمد تعيين المحرّكات ونشر الطابعات على سكربت تسجيل دخول GPO، تختفي وسيلة النشر تلك أوّلاً. قرّر أثناء التجريب ما إذا كنت تطوي ترحيل مشاركة إلى OneDrive/SharePoint أو استبدالاً بـ Universal Print في المرحلة (3)، أو تجسّر في الوقت الحاليّ بنشر سكربت.¹²

flowchart TB
    accTitle: استبدال نشر يعتمد على أصول محلّيّة
    accDescr: إن اعتمد تعيين المحرّكات ونشر الطابعات على سكربت تسجيل دخول GPO، تختفي وسيلة النشر تلك أوّلاً في الترحيل، لذا قرّر أثناء التجريب ما إذا كنت تستجيب بترحيل مشاركة إلى OneDrive أو SharePoint، أو استبدال بـ Universal Print، أو نشر سكربت في الوقت الحاليّ
    dep["اعتماد على سكربت تسجيل دخول"] --> lost["وسيلة النشر تختفي في الترحيل"]
    lost --> share["رحِّل إلى OneDrive/SharePoint"]
    lost --> print["استبدل بـ Universal Print أو ما شابه"]
    lost --> script["جسِّر بنشر سكربت"]
    share --> decide["قرّر النهج أثناء التجريب"]
    print --> decide
    script --> decide

الشكل 17: نشر يعتمد على سكربت تسجيل دخول يفقد وسيلته أوّلاً في الترحيل، لذا قرّر الاستبدال أثناء التجريب.

8.3. إعادة تصميم التجهيز ── Autopilot ليس «مطلوباً»

ستُنصَح أحياناً بإدخال Windows Autopilot كمجموعة مع ترحيل Intune، لكن على مقياس شراء بضعة إلى عشرة أجهزة في السنة، تسجيل الدخول بحساب عمل عند OOBE وانضمام Entra يدوياً لا ضرر حقيقيّ فيه. يبدأ Autopilot يؤتي عندما ينمو عدد الشراء ويكون للإعداد بلا مراقبة من فتح الصندوق قيمة، أو عندما تستطيع استخدام تسجيل أجهزة في جانب الموزِّع. إضافته بعد أن يكون (2) و(3) في مكانهما جيّدة؛ ليست متطلَّباً مسبقاً للترحيل.

flowchart TB
    accTitle: قرار إدخال Autopilot
    accDescr: على مقياس شراء بضعة إلى عشرة أجهزة في السنة، انضمام Entra يدوياً عند OOBE لا ضرر حقيقيّ فيه؛ أضف Autopilot لاحقاً، عندما ينمو عدد الشراء ويكون للإعداد بلا مراقبة قيمة
    scale{"ما مقياس الشراء السنويّ؟"} -->|"بضعة إلى عشرة"| manual["انضمام Entra يدويّ عند OOBE"]
    scale -->|"متى نما العدد"| ap["بلا مراقبة بـ Autopilot"]
    ap -.-> later["أضفه بعد أن يكون（2）و（3）في مكانهما"]

الشكل 18: بينما مقياس الشراء صغير، انضمام Entra يدويّ يكفي؛ يمكن إضافة Autopilot لاحقاً.

8.4. سوء الفهم أنّ «لا خير ما لم يكن كلّ شيء في Intune»

الأخير ليس مشكلة تقنيّة بل مشكلة فرضيّة. تعايش آلات منضمّة لـ Entra وآلات منضمّة للنطاق إعداد مدعوم رسميّاً،² و«AD ما زال هناك = الترحيل فشل» ليس صحيحاً. شركات تدير سنوات بإعدادات قليلة ما زالت في GPO ليست نادرة، وحتّى حينها ثمّة قيمة كبيرة في حالة «كلّ حاسوب جديد مُدار سحابيّاً، والضبط يعمل خارج الموقع أيضاً». فضِّل تقدّمات صغيرة قابلة للعكس على جمال ترحيل كامل.

flowchart TB
    accTitle: قيمة التشغيل بالتوازي دون الإصرار على ترحيل كامل
    accDescr: بقاء AD ليس ترحيلاً فاشلاً؛ حتّى إن شغّلت بالتوازي سنوات بإعدادات ما زالت في GPO، ثمّة قيمة كبيرة في الحالة حيث كلّ حاسوب جديد مُدار سحابيّاً والضبط يعمل خارج الموقع
    miscon["بقاء AD يعني أنّ الترحيل فشل؟"] -->|"لا"| run["شغِّل بالتوازي سنوات وGPO ما زالت هناك"]
    run --> value["الحواسيب الجديدة تحت الضبط حتّى خارج الموقع"]
    value -.-> forward["فضِّل تقدّمات صغيرة"]

الشكل 19: حتّى التشغيل بالتوازي وAD ما زال هناك، الحالة حيث كلّ حاسوب جديد مُدار سحابيّاً لها قيمة كبيرة.

9. جواب واقعيّ لتقنيّة معلومات شخص واحد

أخيراً، ملخّص تصميم تشغيليّ في شركة المسؤول فيها واحد (أو له الدور عملاً جانبيّاً).

• ضيِّق عناصر الإدارة من البداية. إن حاولت جلب كلّ إعداد عصر GPO، ستُنهك نفسك بالجرد وحده. ابدأ من الخمسة في الفصل 7 (2) (تحديث، تشفير، Defender، قفل شاشة، LAPS) واجعله «تصميم طرح» يضيف إعداداً فقط عندما تنشأ الحاجة. يقدِّم كتالوج الإعدادات آلاف الإعدادات،⁷ لكنّك لست ملزَماً باستخدامها.
• قرّر صورة حاسوب قياسيّة واحدة. صُن معياراً واحداً فقط: «حاسوب في هذه الشركة هذه المجموعة من السياسات وهذه المجموعة من التطبيقات». استثناءات الأقسام يمكن التعبير عنها بمجموعات ومرشّحات، لكن كلّما نمت الاستثناءات قلّ ما يستطيع شخص واحد متابعته.
• اطلب من شريك خارجيّ التصميم وصنع القوالب؛ أبقِ العمليّات اليوميّة داخليّاً. تعهيد ترحيل Intune الذي يفشل بسهولة الحالة حيث ترمي البناء فوق الجدار وتنتهي في حالة «لا أحد يفهم ماذا تعني شاشات الإدارة». اطلب من الخارج التصميم الأوّليّ، وقالَبة السياسات، ولوحة صوت لقرارات الترحيل، واجعل الهدف حالة تستطيع فيها إضافة حاسوب وضبط سياسة بنفسك يوماً بيوم. بعبارة أخرى، ينبغي أن تختار شريكاً يسلِّم إلى ذلك الحدّ.
• غيِّر شيئاً واحداً في كلّ مرّة. اجعل تغييرات السياسة واحدة تلو الأخرى، وانتقل فقط بعد أن أكَّدت النتيجة في تقارير Intune (حالة تطبيق السياسة وإخفاقات التعيين). مزامنة MDM على دورة نحو 8 ساعات،³ ومعظم «لم يُطبَّق» مسألة وقت، لا عطل.

flowchart TB
    accTitle: دورة تشغيل تغيير سياسة
    accDescr: اجعل تغييرات السياسة واحدة تلو الأخرى، وانتقل إلى التغيير التالي فقط بعد تأكيد حالة التطبيق في تقارير Intune. معظم حالات عدم التطبيق تُحلّ بانتظار دورة المزامنة نحو 8 ساعات
    change["اجعل تغييراً واحداً فقط في السياسة"] --> report["أكِّد حالة التطبيق في التقارير"]
    report --> next["إن لم تكن مشكلة، إلى التغيير التالي"]
    next --> change
    report -.-> wait["معظم عدم التطبيق انتظار مزامنة"]

الشكل 20: اجعل تغييرات السياسة واحدة تلو الأخرى، وانتقل فقط بعد تأكيد النتيجة في التقارير.

10. الخلاصة

• GPO آليّة تفترض قابليّة بلوغ متحكّم نطاق، ولا تبلغ بنيويّاً حواسيب خارج الموقع. Intune (MDM) يزامِن عبر الإنترنت، لذا يحلّ هذه المشكلة من الجذر.
• الترحيل ليس كلّاً أو لا شيء. الآلات المنضمّة لـ Entra والمنضمّة للنطاق يمكن أن تتعايش، وترحيل مرحليّ يحوِّل الحواسيب الجديدة إلى Entra join زائد Intune الجواب الواقعيّ للمنشآت الصغيرة والمتوسّطة. لا مسار تحويل للآلات القائمة، لذا الاستبدال في دورة تجديد العتاد النمط المستقرّ.
• للمنشآت الصغيرة والمتوسّطة، بدء Intune بـ Microsoft 365 Business Premium (Intune Plan 1 زائد Entra ID P1) واقعيّ. غير أنّ تركيب الخطط يستمرّ بالتغيّر، وبعض الميزات مثل Remediations تتطلّب ترخيصاً أعلى، لذا لا تأخذ مقال أغسطس 2026 هذا إنجيلاً؛ أكِّد المصادر الأوّليّة.
• جرد GPO الحاليّة يمكن أتمتته بـ Group Policy analytics. حوِّل إعدادات Ready for migration إلى كتالوج الإعدادات، واستبدل سكربتات تسجيل الدخول ونشر الطابعات بلا مقابل بنشر سكربت، أو تحويل العمل إلى تطبيق، أو إيقاف الممارسة. لاحظ أنّه في GPO يابانيّة يمكن أن تكون نسبة الدعم غير دقيقة.
• تقدّم الترحيل في المراحل الخمس «تجريب ← سياسة أساس ← نشر تطبيقات ← استبدال طبيعيّ لحواسيب قائمة ← تقليص دور AD»، وقرّر معيار خروج كلّ مرحلة أوّلاً.
• تعارضاً تطبيق مزدوج يفوز به GPO افتراضيّاً. MDMWinsOverGP آليّة Policy CSP فقط، لذا المبدأ «لا تنشر الإعداد نفسه من كليهما».
• عندما يهبط عرض استبدال خادم أفضل وقت للنظر في هذا الترحيل. قبل «دورة أخرى من AD»، فكِّر أين ستُستخدم حواسيب السنوات الخمس القادمة.

مقالات ذات صلة

• دليل عمليّ لنهج المجموعة (GPO) ── كيف يعمل، وتأكيد التطبيق، والاختيار بين GPO وIntune
• إدارة تحديثات Windows بعد إهمال WSUS ── كيف تختار بين WUfB وAutopatch وIntune
• خيارات عمليّة بعد انتهاء دعم Windows 10 ── جدول قرار لـ ESU وLTSC والاستبدال
• أتمتة تجهيز الحواسيب بـ winget + PowerShell ── جعل الكتيّب قابلاً للتنفيذ
• دليل BitLocker العمليّ ── تشفير المحرّك بدءاً من إدارة مفتاح الاستعادة
• دليل عمليّ لـ Windows LAPS ── إخراج كلمة مرور المدير المحلّيّ المشتركة عبر كلّ الحواسيب

مجالات الاستشارة ذات الصلة

تتعامل شركة كومورا سوفت ذ.م.م. مع تصميم ترحيل مرحليّ من بيئة AD+GPO إلى Entra ID+Intune (جرد GPO الحاليّة، سياسة إعادة إنتاج الإعدادات، خطّة تجريب)، ومراجعة مقارنة استبدال خادم مقابل انتقال سحابيّ، واستشارات تعيد استخدام تطبيقات أعمال قائمة وأصول تجهيز. يصحّ البدء من النظر معاً في «هل نشتري خادم AD آخر».

• الاستشارة التقنيّة ومراجعة التصميم
• ترحيل الأصول القائمة والاستفادة منها
• تواصل معنا

روابط مرجعيّة

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

إن رحّلنا من GPO إلى Intune، هل نستطيع إعادة إنتاج كلّ إعداد نهج مجموعة نستخدمه اليوم؟

لا تستطيع إعادة إنتاجها كلّها. كتالوج إعدادات Intune فيه آلاف إعدادات Windows، بما فيها الآتية من ADMX، ومعظم إعدادات الأمن والقيود يمكن نقلها، لكنّ أشياء ── تعيين محرّكات عبر سكربتات تسجيل الدخول، نشر الطابعات بالجملة ── لا إعداد MDM مقابلاً لها. إن استوردت تصديراً XML لـ GPO الحاليّة إلى Group Policy analytics في Intune، يُصنَّف كلّ إعداد Ready for migration أو Not supported أو Deprecated. للإعدادات بلا مقابل، تغطّيها بنشر سكربت PowerShell، أو تحويل العمل إلى تطبيق، أو ببساطة إيقاف ذلك الإعداد.

أيّ ترخيص نحتاج لاستخدام Intune؟

الأساس Microsoft Intune Plan 1. يمكنك الاشتراك فيه وحده، لكن في المنشآت الصغيرة والمتوسّطة الشائع استخدامه كجزء من Microsoft 365 Business Premium (حتّى 300 مستخدم). يشمل Business Premium أيضاً Entra ID P1، لذا يمكنك بلوغ الجمع بين سياسات الامتثال والوصول المشروط. بعض الميزات، مثل Remediations، تتطلّب منفصلة ترخيصاً من فئة Windows Enterprise E3/E5. تركيب الخطط يتغيّر كثيراً، فأكِّد أحدث التفاصيل على صفحات ترخيص مايكروسوفت الرسميّة قبل التوقيع (هذا المقال حتّى أغسطس 2026).

هل يجب أن نُخرج خادم AD فوراً؟

لا. الحواسيب المُدارة بـ Entra join زائد Intune والحواسيب المُدارة بانضمام نطاق AD زائد GPO يمكن أن تتعايش على شبكة الشركة نفسها. ترحيل مرحليّ ── إبقاء AD لمصادقة خادم الملفّات وأنظمة الأعمال القائمة، وانضمام Entra للحواسيب الجديدة فقط ── واقعيّ. بالمقابل، لا طريقة مدعومة «لتحويل» حاسوب منضمّ للنطاق قائم إلى Entra join؛ يلزم مسح (إعادة ضبط)، لذا النمط المستقرّ استبدال الآلات القائمة في دورة تجديد العتاد. يكفي النظر في إخراج AD بعد أن تفرغ GPO وتجرد الأدوار المتبقّية.

لماذا لا يُطبَّق نهج المجموعة على حواسيب العمل عن بُعد؟

لأنّ GPO يُجلَب ويُطبَّق عندما يستطيع الحاسوب بلوغ متحكّم نطاق. حاسوب خارج المكتب لا يستقبل أحدث سياسة إلا عندما يستطيع بلوغ متحكّم نطاق عبر VPN أو ما شابه، وحاسوب منزليّ لا يستخدم VPN في الجوهر لا يحصل عليها أبداً. Intune (MDM) يزامِن السياسة عبر الإنترنت، لذا تستطيع إدارة حاسوب أينما كان؛ مشكلة إدارة الحواسيب خارج الموقع تُحلّ ببنية MDM. إضافة إلى مزامنة دوريّة نحو كلّ 8 ساعات، تجري أيضاً مزامنة مدفوعة بإشعار عند تغيّر السياسة.

إن نشرنا الإعداد نفسه من GPO وIntune كليهما، أيّهما يفوز؟

افتراضيّاً، إعداداً متعارضاً يفوز به نهج المجموعة. ضبط سياسة MDMWinsOverGP إلى 1 يجعل جانب MDM (Intune) يفوز، لكنّ تلك الآليّة تنطبق فقط على إعدادات تحت Policy CSP؛ ولا تنطبق على إعدادات معرَّفة في CSP أخرى مثل Defender CSP. الاعتماد على ضبط الأسبقيّة يجعل السلوك صعب التنبّؤ، لذا عمليّاً المبدأ «لا تنشر الإعداد نفسه من القناتين»، ومتى انتقل إعداد إلى Intune احذفه من GPO الأصليّ لتجنّب الإدارة المزدوجة.

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

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