دليل عمليّ لنهج المجموعة (GPO) ── كيف يعمل، وتأكيد التطبيق، والاختيار بين GPO وIntune

«هذا الإعداد موزَّع عبر GPO»، «حواسيب الزبون مقيَّدة بنهج المجموعة» ── من يعمل مع أنظمة أعمال Windows يسمع كلمة «GPO» تُرمى باستمرار. غير أنّه عندما يحين فعلاً تسلُّم مهام إدارة AD، أو نشر تطبيق على حاسوب منضمّ للنطاق في موقع زبون، قليلون على نحو مفاجئ يستطيعون أن يشرحوا بدقّة متى، ومن أين، وبأيّ ترتيب أسبقيّة يُطبَّق نهج المجموعة.

«غيّرت الإعداد لكنّه لم ينعكس»، «قيل لي أن أشغِّل gpupdate ولا أعرف ماذا يفعل فعلاً»، «التطبيق يعمل على آلة التطوير ولا يعمل عند الزبون، وتبيّن أنّ السبب GPO» ── موجَّه إلى مطوِّري تطبيقات الأعمال الذين يواجهون هذه المواقف، وإلى موظّفي تقنيّة المعلومات في المنشآت الصغيرة والمتوسّطة الذين ورثوا إدارة AD. يرتِّب المقال كيف يعمل نهج المجموعة (ترتيب تطبيق LSDOU)، ومتى ينعكس، وكيف تشخِّصه بـ gpresult وسجلّ الأحداث، وADMX والمخزن المركزيّ، وكيف تختار بين GPO وIntune (MDM)، كلّ ذلك استناداً إلى مصادر أوّليّة حتّى أغسطس 2026.

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

• نهج المجموعة «الأخير يفوز». يُعالَج بالترتيب محلّيّ → موقع → نطاق → OU (LSDOU)، وأيّ GPO تُعالَج لاحقاً تتقدَّم عند التعارض. GPO المحلّيّة (gpedit.msc) هي الطبقة الأضعف.¹
• توقيت التطبيق «مقدّمة زائد خلفيّة». تكوين الحاسوب يُطبَّق دائماً عند البدء وتكوين المستخدم دائماً عند تسجيل الدخول؛ وفوق ذلك، افتراضيّاً هناك تحديث خلفيّ نحو كلّ 90 دقيقة زائد إزاحة عشوائيّة 0–30 دقيقة (5 دقائق على متحكّمات النطاق).²
• gpupdate /force «يعيد تطبيق كلّ إعداد» ── ليس دواءً لكلّ داء. بعض الإعدادات، مثل تثبيت البرمجيّات وإعادة توجيه المجلّدات، لا تُعالَج إلا عند تسجيل الدخول أو إعادة التشغيل (وهذا بالضبط سبب وجود خيارَي /logoff و/boot).³
• نقطة انطلاق التشخيص تقرير RSoP من gpresult /h. يعرض GPO المطبَّقة وGPO المرفوضة، مع الأسباب. للتعميق استخدم سجلّ تشغيل GroupPolicy ‏(Microsoft-Windows-GroupPolicy/Operational).⁴⁵
• كقاعدة، سياسات القوالب الإداريّة تُكتَب إلى مفاتيح سياسة مخصَّصة في السجلّ (Software\Policies وما شابه). قيمة السياسة تتقدَّم على إعداد التطبيق نفسه، و«غير مكوَّن» لا يكتب شيئاً البتّة. غير أنّ بعض السياسات تكتب خارج المفاتيح المخصَّصة (الفصل 5).⁶
• المخزن المركزيّ لـ ADMX هو مجلّد PolicyDefinitions في SYSVOL. متى أنشأته، تبدأ GPMC بالإشارة إلى تعريفات القوالب على مستوى النطاق من هناك.⁷
• اختر GPO أو Intune وفق أساس هويّة الجهاز. ضبط الإعداد نفسه في كليهما لا يضمن ناتجاً. Group Policy analytics يساعد عندما تفكِّر في الترحيل.⁸⁹
• للمطوِّرين، GPO سبب كلاسيكيّ لأن يعمل التطبيق «عند الزبون فقط ولا يعمل». إعدادات تغيّر افتراضات تطبيقك ── سياسة التنفيذ، تعطيل دمج قواعد الجدار المحلّيّة، تكوين الوكيل والمحرّكات، وغيرها ── تُوزَّع عبر إدارة مركزيّة.¹⁰¹¹

2. ما نهج المجموعة ── GPO المحلّيّ وGPO النطاق

نهج المجموعة آليّة تتيح للمدير أن يعرِّف إعدادات Windows مركزيّاً ويفرضها على الحواسيب والمستخدمين المستهدفين. حزمة الإعدادات تُسمَّى GPO (كائن نهج المجموعة). يمكن أن تعيش GPO في أحد مكانين.

حاسوب مجموعة عمل (غير منضمّ للنطاق) يعالج GPO المحلّيّة فقط.¹ لذا عمليّاً، عندما يقول الناس إنّ آلة «تُدار بـ GPO»، فإنّهم يقصدون شبه دائماً GPO نطاق.

flowchart TB
    accTitle: GPO التي يعالجها حاسوب مجموعة عمل وحاسوب منضمّ للنطاق
    accDescr: حاسوب مجموعة العمل يعالج GPO المحلّيّة فقط، بينما يعالج الحاسوب المنضمّ للنطاق GPO المحلّيّة زائداً GPO النطاق التي يوزِّعها Active Directory
    pc{"ما شكل انضمام الحاسوب؟"}
    pc -->|مجموعة عمل| wg["معالجة GPO المحلّيّة فقط"]
    pc -->|انضمام نطاق| dom["محلّيّ زائد GPO نطاق"]
    dom -.-> note["عمليّاً GPO تعني GPO النطاق"]

الشكل 1: حاسوب مجموعة العمل يعالج GPO المحلّيّة فقط، أمّا الحاسوب المنضمّ للنطاق فيعالج GPO النطاق أيضاً.

أيّاً كانت GPO، ينقسم محتواها على نطاق واسع إلى فئتين.

• تكوين الحاسوب: إعدادات تسري على أيّ شخص يسجِّل الدخول إلى ذلك الحاسوب. تُطبَّق عند البدء.
• تكوين المستخدم: إعدادات تسري على ذلك المستخدم أيّاً كان الحاسوب الذي يسجِّل الدخول إليه. تُطبَّق عند تسجيل الدخول.

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

flowchart TB
    accTitle: السلسلتان داخل GPO
    accDescr: كلّ GPO فيه سلسلتان تكوين الحاسوب وتكوين المستخدم، فتكوين الحاسوب يُطبَّق عند البدء ويسري على أيّ شخص يسجّل الدخول إلى ذلك الحاسوب، وتكوين المستخدم يُطبَّق عند تسجيل الدخول ويسري أيّاً كان الحاسوب الذي يسجّل المستخدم الدخول إليه
    gpo["محتوى GPO"] --> comp["تكوين الحاسوب"]
    gpo --> user["تكوين المستخدم"]
    comp --> boot["يُطبَّق عند البدء"]
    user --> logon["يُطبَّق عند تسجيل الدخول"]
    boot -.-> anyone["يسري على أيّ مسجّل دخول"]
    logon -.-> anypc["يسري على أيّ حاسوب"]

الشكل 2: في GPO سلسلتان: تكوين الحاسوب المربوط بالجهاز، وتكوين المستخدم المربوط بالشخص.

3. كيف يعمل التطبيق ── «الأخير يفوز» في LSDOU والتحكّم في الوراثة

3.1. LSDOU: محلّيّ → موقع → نطاق → OU

على حاسوب منضمّ للنطاق، تُعالَج GPO بالترتيب التالي.¹

1. GPO المحلّيّة
2. GPO المربوطة بـ الموقع
3. GPO المربوطة بـ النطاق
4. GPO المربوطة بـ OU (وحدة تنظيميّة) ── تُعالَج من OU الأعلى نزولاً، وتُعالَج أخيراً GPO على OU التي ينتمي إليها الحاسوب/المستخدم المستهدف مباشرة

أخذ الحروف الأولى يعطي الترتيب اسمه، LSDOU. النقطة المهمّة أنّ هذا ليس «الأعلى أولويّة أوّلاً» بل ترتيب معالجة GPO. عندما تضبط عدّة GPO الإعداد نفسه، أيّها تُعالَج لاحقاً تفوز (الإعدادات التي لا تتعارض تُضاف ببساطة بعضها إلى بعض).¹ بعبارة أخرى، GPO على OU الأقرب للهدف هي الأقوى، وGPO المحلّيّة هي الأضعف. «أصلحته في gpedit.msc فعاد كما كان» ليس عطلاً ── إنّه هذه المواصفة تعمل كما صُمِّمت تماماً.

flowchart TB
    accTitle: ترتيب معالجة LSDOU والأخير يفوز
    accDescr: تُعالَج GPO بالترتيب محلّيّ ثمّ موقع ثمّ نطاق ثمّ OU، وعند التعارض تفوز GPO المعالجة لاحقاً، لذا GPO على OU الأقرب للهدف هي الأقوى وGPO المحلّيّة الأضعف
    l["1. GPO المحلّيّة"] --> s["2. الموقع"]
    s --> d["3. النطاق"]
    d --> ou["4. OU（من الأعلى نزولاً）"]
    ou --> win["عند التعارض الأخير يفوز"]
    win -.-> strongest["GPO على OU الأقرب هي الأقوى"]
    win -.-> weakest["GPO المحلّيّة هي الأضعف"]

الشكل 3: LSDOU ترتيب معالجة، وعندما يتعارض الإعداد نفسه تفوز GPO التي عولجت لاحقاً.

عندما تُربَط عدّة GPO بالموقع أو النطاق أو OU نفسه، تُقرَّر الأسبقيّة بينها بـ ترتيب الرابط في علامة تبويب «كائنات نهج المجموعة المربوطة» في GPMC. GPO ذات أصغر رقم ترتيب رابط تُعالَج أخيراً وتحظى بأعلى أولويّة.¹

flowchart TB
    accTitle: ترتيب الرابط عندما تتعدّد GPO في المكان نفسه
    accDescr: عندما تُربَط عدّة GPO بالموقع أو النطاق أو OU نفسه يُحدَّد ترتيب المعالجة بترتيب الرابط في GPMC، وGPO ذات أصغر رقم تُعالَج أخيراً وتحظى بأعلى أولويّة
    multi["عدّة GPO في المكان نفسه"] --> tab["يُحدَّد بترتيب رابط GPMC"]
    tab --> last["أصغر رقم يُعالَج أخيراً"]
    last --> win["الأخير يفوز بأعلى أولويّة"]

الشكل 4: في وجهة الرابط نفسها، GPO ذات أصغر رقم ترتيب رابط تُعالَج أخيراً وتفوز.

3.2. حظر الوراثة والفرض (Enforced)

يمكنك إنشاء استثناءات للترتيب الافتراضيّ.¹

• حظر الوراثة: يُضبَط على نطاق أو OU، فيوقف وراثة GPO من مستويات أعلى. إنّه أداة «هذه OU وحدها ينبغي ألا تتلقّى معيار الشركة كلّه».
• الفرض (Enforced، الاسم السابق: No Override): يُضبَط على رابط GPO، فيجعل تلك GPO تُطبَّق دائماً، حتّى إن ضبط مستوى أدنى حظر الوراثة، ولم يعد بالإمكان الكتابة فوقها بـ GPO أدنى. عندما يتعارض حظر الوراثة والفرض، يفوز الفرض.¹

flowchart TB
    accTitle: علاقة حظر الوراثة والفرض
    accDescr: حظر الوراثة يوقف وراثة GPO من الأعلى، لكنّ GPO المفروضة تُطبَّق دائماً حتّى إن حُظرت الوراثة في مستوى أدنى ولا تُكتَب فوقها GPO أدنى
    upper["GPO من مستوى أعلى"] --> blocked{"حظر وراثة في الأدنى؟"}
    blocked -->|لا| inherit["تُورَث كما هي"]
    blocked -->|نعم| enforced{"هل للـ GPO فرض؟"}
    enforced -->|لا| stop["تتوقّف الوراثة"]
    enforced -->|نعم| apply["تُطبَّق حتماً"]
    apply -.-> noover["لا تُكتَب فوقها GPO أدنى"]

الشكل 5: حظر الوراثة يوقف الوراثة من الأعلى، لكنّ GPO المفروضة تتجاوز الحظر وتُطبَّق حتماً.

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

3.3. ترشيح الأمن

إلى جانب مكان الرابط، يمكنك أيضاً تضييق من تُطبَّق عليه GPO، لكلّ GPO. لتطبيق GPO، يجب أن يملك المستخدم أو الحاسوب المستهدف إذني «قراءة» و«تطبيق نهج المجموعة» كليهما على تلك GPO. افتراضيّاً يُمنَح الاثنان لـ Authenticated Users (الذي يشمل المستخدمين والحواسيب كليهما)، فتُطبَّق GPO على الجميع تحت وجهة الرابط. ترشيح الأمن هو كيف تضيِّق هذا إلى مجموعات أمن محدَّدة. يعمل المرشّح على GPO ككلّ؛ لا يمكنك تنويعه لكلّ إعداد داخل GPO.¹³

ثمّة تحذير مهمّ واحد. عند تضييق النطاق، لا تنزع أيضاً «قراءة» من Authenticated Users الافتراضيّ. منذ تحديث الأمن MS16-072 (2016)، تُجلَب سياسة المستخدم في سياق أمن الحاسوب، لذا إن لم يستطع حساب الحاسوب قراءة GPO، فإنّ GPO الموجَّهة للمستخدم لن تُطبَّق حتّى إن ملك المستخدم المستهدف الإذنين كليهما.¹⁴ الطريقة الصحيحة لتضييق النطاق منح «قراءة + تطبيق نهج المجموعة» للمجموعة المستهدفة مع إبقاء «قراءة» فقط على Authenticated Users (أو Domain Computers).¹⁴

flowchart TB
    accTitle: حكم تطبيق مرشّح الأمن
    accDescr: لتطبيق GPO يجب أن يملك المستخدم أو الحاسوب المستهدف إذني القراءة وتطبيق نهج المجموعة كليهما، وGPO الموجَّهة للمستخدم تتطلّب أيضاً أن يستطيع حساب الحاسوب القراءة
    target["هدف تحت وجهة رابط GPO"] --> perm{"إذنا القراءة والتطبيق؟"}
    perm -->|لا| deny["رفضه المرشّح"]
    perm -->|نعم| usergpo{"GPO موجَّهة للمستخدم؟"}
    usergpo -->|لا| apply["تُطبَّق"]
    usergpo -->|نعم| comp{"الحاسوب يستطيع القراءة؟"}
    comp -->|نعم| apply
    comp -->|لا| deny2["لا تُطبَّق（MS16-072）"]

الشكل 6: التطبيق يحتاج «قراءة» و«تطبيق نهج المجموعة» كليهما، وGPO الموجَّهة للمستخدم تحتاج أيضاً قراءة حساب الحاسوب.

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

flowchart TB
    accTitle: حتّى ينعكس تغيير المجموعة على المرشّح
    accDescr: عضويّة المجموعة تُقيَّم برمز أمن أُنشئ عند تسجيل الدخول، لذا تغيير المستخدم ينعكس بعد إعادة تسجيل الدخول وتغيير الحاسوب بعد إعادة التشغيل عندما يصير الرمز جديداً
    change["تغيير أعضاء المجموعة"] --> old["رمز قديم لا يعكس التغيير"]
    old --> u["المستخدم يعيد تسجيل الدخول"]
    old --> c["الحاسوب يعاد تشغيله"]
    u --> token["تقييم برمز جديد"]
    c --> token
    token --> ok["ينعكس على المرشّح"]
    old -.-> bg["تحديث خلفيّ لا يحله"]

الشكل 7: تغيير المجموعة لا ينعكس على المرشّح إلا عندما يُنشأ رمز جديد بتسجيل خروج أو إعادة تشغيل.

ثمّة أيضاً وضع خاصّ يُسمَّى معالجة الالتفاف، لحالات مثل الحواسيب المشتركة أو خوادم سطح المكتب البعيد، حيث تريد أن يحصل أيّ من يسجِّل الدخول إلى ذلك الحاسوب على تكوين مستخدم مُستبدَل (آليّة تطبِّق إعدادات المستخدم استناداً إلى موقع الحاسوب، بوضعَي الاستبدال والدمج).¹⁵ إنّها ميزة متقدِّمة تُستخدم على آلات الأكشاك وحواسيب الصفوف، لذا سيكتفي هذا المقال بالإشارة إلى وجودها.

flowchart TB
    accTitle: فكرة معالجة الالتفاف
    accDescr: معالجة الالتفاف وضع خاصّ يطبِّق تكوين المستخدم استناداً إلى موقع الحاسوب، وفيه وضعا الاستبدال والدمج، وتُستخدم في حواسيب مشتركة وأكشاك عندما تريد إعدادات مستخدم واحدة لكلّ من يسجّل الدخول
    shared["حواسيب مشتركة وأكشاك وغيرها"] --> lb["معالجة الالتفاف"]
    lb --> base["يُقرَّر بموقع الحاسوب"]
    base --> rep["وضع الاستبدال"]
    base --> mrg["وضع الدمج"]
    lb -.-> aim["يسري على كلّ مسجّلي الدخول"]

الشكل 8: معالجة الالتفاف وضع خاصّ يطبِّق تكوين المستخدم استناداً إلى موقع الحاسوب، وفيه وضعا الاستبدال والدمج.

4. متى ينعكس الإعداد ── معالجة المقدّمة وتحديث الخلفيّة

نصف «ضبطتُه لكنّه لم ينعكس» هو ببساطة أنّ توقيت التطبيق لم يحن بعد. للتطبيق نوعان.²

بعبارة أخرى، لـ جهاز شغّال يستطيع بلوغ متحكّم نطاق، فإنّ الإعدادات التي تدعم التحديث الخلفيّ ستنتشر خلال نحو ساعتين بعد تغيير GPO، بلا إجراء إضافيّ. الأجهزة غير المتّصلة، أو الحواسيب المحمولة الخارجة عن الموقع بلا اتّصال VPN، لن تحصل عليه حتّى تبلغ متحكّماً في المرّة التالية. الإعدادات التي لا تُطبَّق إلا عبر معالجة المقدّمة ستحتاج بالإضافة إلى ذلك انتظار بدء أو تسجيل دخول. إن كنت مستعجلاً، شغِّل gpupdate على الحاسوب المستهدف. افتراضيّاً تُطبَّق الإعدادات التي تغيّرت فقط؛ وإضافة /force تعيد تطبيق كلّ إعداد، سواء تغيّر أم لا.³

rem تحديث الإعدادات التي تغيّرت فقط (يكفي عادةً)
gpupdate

rem إعادة تطبيق كلّ إعداد (عندما تشكّ في حالة مخزَّنة مؤقّتاً)
gpupdate /force

flowchart TB
    accTitle: إمكان بلوغ المتحكّم وكيفيّة وصول التطبيق
    accDescr: على جهاز شغّال يستطيع بلوغ متحكّم نطاق تصل الإعدادات الداعمة للتحديث الخلفيّ خلال نحو ساعتين، أمّا حاسوب أوفلاين أو محمول بلا VPN فلا تصل حتّى يتّصل بالمتحكّم في المرّة التالية
    pc{"هل يبلغ متحكّم النطاق؟"}
    pc -->|نعم| ok["تنتشر خلال نحو ساعتين"]
    pc -->|لا| ng["لا تصل حتّى يتّصل"]
    ng -.-> ex["أوفلاين أو محمول بلا VPN"]

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

ما ينبغي الانتباه إليه أنّ بعض الإعدادات ببساطة لا تنعكس عبر gpupdate. تثبيت البرمجيّات الموجَّه للمستخدم وإعادة توجيه المجلّدات لا يُعالَجان إلا عند تسجيل الدخول، وتثبيت البرمجيّات الموجَّه للحاسوب إلا عند البدء. يوفِّر gpupdate خيارَي /logoff (تسجيل خروج بعد التحديث) و/boot (إعادة تشغيل بعد التحديث) لهذا بالضبط.³ قبل أن تشكو أنّ «نفّذت gpupdate /force وما زال لم يدخل»، تحقّق ممّا إذا كان الإعداد من الأنواع التي تتطلّب إعادة تشغيل أو تسجيل دخول.

flowchart TB
    accTitle: مسار انعكاس الإعداد
    accDescr: تغيير GPO يصل إن دعم التحديث الخلفيّ خلال نحو 90 دقيقة زائد إزاحة 0 إلى 30 دقيقة، والإعدادات التي لا تُطبَّق إلا بمعالجة المقدّمة تنتظر البدء أو تسجيل الدخول، وحتّى gpupdate عند العجلة يتطلّب /logoff أو /boot لإعدادات المقدّمة
    change["تغيير GPO"] --> kind{"يدعم التحديث الخلفيّ؟"}
    kind -->|نعم| bg["تحديث نحو 90د+0–30د"]
    kind -->|لا| fg["يُطبَّق عند البدء أو الدخول"]
    bg --> done["انعكاس"]
    fg --> done
    rush["عند العجلة"] -.-> upd["تشغيل gpupdate"]
    upd -.-> force["/force لإعادة تطبيق الكلّ"]
    upd -.-> reboot["المقدّمة تحتاج /logoff أو /boot"]

الشكل 10: التحديث الخلفيّ يوصل الإعدادات الداعمة فقط، والإعدادات التي لا تُطبَّق إلا بمعالجة المقدّمة تحتاج بعد gpupdate أيضاً إلى تسجيل خروج أو إعادة تشغيل.

5. التشخيص عندما لا ينعكس الإعداد ── gpresult وسجلّ الأحداث والسجلّ

5.1. تأكيد RSoP بـ gpresult /h

gpresult هي الأداة القياسيّة للتحقّق من الناتج النهائيّ (RSoP: مجموعة السياسة الناتجة) بعد أن تتراكب عدّة GPO. إنتاج تقرير HTML من موجِّه أوامر مرتفع الصلاحيّة هو النهج الأيسر قراءة.⁴⁵

rem إخراج تقرير HTML لـ RSoP للمستخدم والحاسوب معاً
gpresult /h C:\temp\gp-report.html /f

rem للاطّلاع على الملخّص فقط في وحدة التحكّم
gpresult /r
gpresult /scope computer /r

أوّل ثلاث نقاط تفحصها في التقرير:

1. قائمة GPO المطبَّقة ── هل GPO التي تبحث عنها موجودة؟
2. قائمة GPO المرفوضة، مع الأسباب ── أسباب عدم التطبيق، مثل ترشيح الأمن أو مرشّح WMI أو GPO فارغة، تظهر هنا⁵
3. «GPO الفائزة» لكلّ إعداد ── أيّ قيمة GPO حسمت الإعداد الذي تبحث عنه. إن كانت GPO أخرى تفوز، ارجع وأعد النظر في قواعد الأسبقيّة في الفصل 3

flowchart TB
    accTitle: ثلاث نقاط تُرى أوّلاً في تقرير RSoP
    accDescr: في تقرير gpresult انظر أوّلاً هل GPO المطلوبة في قائمة GPO المطبَّقة، ثمّ قائمة GPO المرفوضة وأسبابها، وأخيراً GPO الفائزة لكلّ إعداد لتحديد أيّ قيمة فازت
    rep["افتح تقرير RSoP"] --> one["1. قائمة GPO المطبَّقة"]
    one --> two["2. GPO المرفوضة وأسبابها"]
    two --> three["3. GPO الفائزة لكلّ إعداد"]
    three -.-> review["راجع إن فازت GPO أخرى"]

الشكل 11: تقرير RSoP يُقرأ بترتيب GPO المطبَّقة، ثمّ GPO المرفوضة وأسبابها، ثمّ GPO الفائزة لكلّ إعداد.

5.2. سجلّ تشغيل GroupPolicy

عندما لا يكفي gpresult ── مثلاً، المعالجة تفشل أصلاً، أو تستغرق وقتاً أطول بكثير ── انظر سجلّ تشغيل GroupPolicy في عارض الأحداث. مكانه «سجلات التطبيقات والخدمات > Microsoft > Windows > GroupPolicy > Operational» (اسم السجلّ Microsoft-Windows-GroupPolicy/Operational). يسجِّل هذا كامل مدى معالجة السياسة، من البداية إلى النهاية، مع قائمة GPO المطبَّقة وقائمة GPO المرفوضة (مع الأسباب). تُسنَد لكلّ جولة معالجة سياسة ActivityID فريد، لذا إجراء مايكروسوفت الموصى به التقاط ActivityID من حدث تحذير أو خطأ في سجلّ النظام، ثمّ استخدام عرض مخصَّص لتضييق ذلك إلى تلك الجولة وحدها.⁵

flowchart TB
    accTitle: خطوات تضييق سجلّ تشغيل GroupPolicy
    accDescr: في سجلّ تشغيل GroupPolicy يُسنَد ActivityID فريد لكلّ جولة معالجة سياسة، لذا التقط ActivityID من تحذير أو خطأ في سجلّ النظام وضيِّق بعرض مخصَّص إلى أحداث تلك الجولة وحدها ثمّ اقرأها
    sys["تحذير أو خطأ سجلّ النظام"] --> aid["التقط ActivityID"]
    aid --> cv["ضيِّق بعرض مخصَّص"]
    cv --> one["اقرأ أحداث جولة واحدة"]
    one -.-> rec["قوائم التطبيق والرفض مع الأسباب"]

الشكل 12: سجلّ التشغيل يُقرأ بالتقاط ActivityID من سجلّ النظام ثمّ التضييق بعرض مخصَّص إلى جولة معالجة سياسة واحدة.

5.3. العلاقة بمفتاح Policies في السجلّ

سياسات القوالب الإداريّة (الفصل التالي) تُكتَب في النهاية قيماً في السجلّ. كقاعدة، تُكتَب إلى مفاتيح السياسة المخصَّصة التالية.⁶

• HKEY_LOCAL_MACHINE\Software\Policies (تكوين الحاسوب؛ المكان الموصى به)
• HKEY_CURRENT_USER\Software\Policies (تكوين المستخدم؛ المكان الموصى به)
• HKLM\Software\Microsoft\Windows\CurrentVersion\Policies / HKCU\Software\Microsoft\Windows\CurrentVersion\Policies

ثمّة مبدأ تصميم مهمّ يعمل هنا. تطبيق واعٍ بالسياسة يتصرَّف بأن يقرأ مفتاح Policies أوّلاً؛ إن وُجدت قيمة هناك تتقدَّم؛ وإلا يعود التطبيق إلى إعداده هو (تفضيل) أو الافتراضيّ. سياسة «غير مكوَّنة» لا تكتب شيئاً إلى السجلّ البتّة.⁶ بعبارة أخرى، سياسات القوالب الإداريّة لا تعيد كتابة إعداد التطبيق نفسه وتترك «وشماً (tattooing)» ── بل قيمة مفروضة محفوظة في مكان منفصل تُراجَع بأسبقيّة. أوقف تكوين السياسة، فيعود التطبيق إلى طاعة قيمة إعداده هو.

flowchart TB
    accTitle: أسبقيّة قيمة السياسة وإعداد التطبيق
    accDescr: تطبيق واعٍ بالسياسة يقرأ مفتاح Policies أوّلاً فإن وُجدت قيمة يقدِّمها وإلا استخدم إعداده أو القيمة الافتراضيّة، وسياسة غير مكوَّنة لا تكتب شيئاً في السجلّ
    app["تطبيق واعٍ يقرأ الإعداد"] --> haspol{"قيمة في مفتاح Policies؟"}
    haspol -->|نعم| pol["تُقدَّم قيمة السياسة"]
    haspol -->|لا| pref["يستخدم إعداده أو الافتراضيّ"]
    notconf["سياسة غير مكوَّنة"] -.-> nowrite["لا تكتب شيئاً في السجلّ"]

الشكل 13: السياسة لا تعيد كتابة إعداد التطبيق نفسه، بل تُراجَع قيمة مفروضة موضوعة في مكان منفصل بأسبقيّة.

غير أنّ ليست كلّ سياسة تكتب إلى مفتاح مخصَّص. بعض إعدادات نظام التشغيل المضمَّنة (مثلاً، «تمكين مسارات Win32 الطويلة» يكتب إلى LongPathsEnabled تحت HKLM\SYSTEM\CurrentControlSet\Control\FileSystem)، مع قوالب جيل أقدم أو من طرف ثالث، تكتب إلى مسارات اعتباطيّة خارج المفاتيح المخصَّصة. لإعدادات كهذه، تبقى القيمة في مكانها حتّى بعد أن توقف تكوين السياسة. راجع تعريف ADMX، أو نصّ وصف الإعداد، أو تقرير gpresult لترى إلى أيّ مفتاح يكتب إعداد بعينه فعلاً.

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

# مثال للتحقّق مباشرة من قيمة وزَّعتها السياسة (تُكتب معظم السياسات تحت Policies)
Get-ChildItem "HKLM:\SOFTWARE\Policies" -Recurse | Select-Object Name
Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\System" -ErrorAction SilentlyContinue

flowchart TB
    accTitle: خطوات التشخيص عندما لا ينعكس الإعداد
    accDescr: أكِّد أوّلاً GPO المطبَّقة والمرفوضة بتقرير RSoP من gpresult، وإن لم يكفِ ضيِّق سجلّ تشغيل GroupPolicy بـ ActivityID، والقيمة الفعليّة الموزَّعة تُتحقَّق مباشرة من مفتاح Policies في السجلّ
    start["الإعداد لا ينعكس"] --> rsop["أكِّد RSoP بـ gpresult /h"]
    rsop --> found{"تُعرف أسباب التطبيق والرفض؟"}
    found -->|نعم| fix["راجع الأسبقيّة أو المرشّح"]
    found -->|لا| oplog["انظر سجلّ تشغيل GroupPolicy"]
    oplog -.-> aid["ضيِّق جولة بـ ActivityID"]
    rsop -.-> reg["أكِّد القيمة في مفتاح Policies"]

الشكل 14: التشخيص ينطلق من gpresult /h، وإن لم يكفِ فسجلّ تشغيل GroupPolicy، والقيمة الفعليّة تُؤكَّد مباشرة من مفتاح Policies.

6. القوالب الإداريّة (ADMX) والمخزن المركزيّ

التعريفات وراء الإعدادات المدرجة تحت «القوالب الإداريّة» في GPMC مكتوبة كـ ملفّات ADMX (جسم التعريف) زائد ملفّات ADML (سلاسل العرض لكلّ لغة). كلّ حاسوب يملك التعريفات التي يوفِّرها نظام التشغيل تحت C:\Windows\PolicyDefinitions، وتحمِّل أدوات الإدارة هذه لبناء شاشة الإعدادات.⁷

إن كنت تعمل داخل نطاق، الخطوة الأساسيّة إنشاء مخزن مركزيّ. أنشئ مجلّد PolicyDefinitions تحت SYSVOL لمتحكّم نطاق (مثلاً، \\contoso.com\SYSVOL\contoso.com\policies\PolicyDefinitions)، فيُنسَخ محتواه إلى كلّ متحكّم نطاق في النطاق؛ ثمّ تشير أدوات نهج المجموعة إلى المخزن المركزيّ افتراضيّاً.⁷ هذا يلغي مشكلة «إصدار القالب يختلف من محطّة إدارة إلى التالية، والإعدادات الظاهرة لا تتطابق». ملفّات ADML تذهب إلى مجلّدات فرعيّة حسب اللغة (ja-JP لليابانيّة).⁷

flowchart TB
    accTitle: آليّة المخزن المركزيّ
    accDescr: إنشاء مجلّد PolicyDefinitions تحت SYSVOL لمتحكّم نطاق ينسخ المحتوى إلى كلّ متحكّمات النطاق، وأدوات نهج المجموعة تشير افتراضيّاً إلى المخزن المركزيّ فيزول اختلاف التعريفات بين محطّات الإدارة
    create["يُنشأ تحت SYSVOL"] --> cs["PolicyDefinitions"]
    cs --> repl["يُنسَخ إلى كلّ المتحكّمات"]
    cs --> ref["أدوات GP تشير افتراضيّاً"]
    ref -.-> benefit["يزول اختلاف التعريف بين الأجهزة"]
    cs -.-> adml["ADML إلى مجلّدات حسب اللغة"]

الشكل 15: PolicyDefinitions في SYSVOL يُنسَخ إلى كلّ متحكّمات النطاق، وتشير إليه أدوات نهج المجموعة افتراضيّاً.

ثمّة تحذيران تشغيليّان. الأوّل، مايكروسوفت توزِّع ملفّات ADMX جديدة لكلّ إصدار Windows جديد، وعندما تحدِّث تستبدل جانب المخزن المركزيّ. استبدال C:\Windows\PolicyDefinitions على كلّ حاسوب على حدة بالنسخة المنزَّلة غير مدعوم.⁷ الثاني، عند تحديث مخزن مركزيّ قائم، الإرشاد ألا تكتب فوق PolicyDefinitions الإنتاج مباشرة. بدلاً من ذلك، اجمع مجموعة ADMX الكاملة ── لنظام التشغيل وللتطبيقات مثل Office وEdge ── في مجلّد عمل باسم الإصدار مثل PolicyDefinitions-24H2، أعد تسمية المجلّد الحاليّ جانباً إلى شيء مثل PolicyDefinitions-23H2، ثمّ أعد تسمية مجلّد العمل إلى PolicyDefinitions لترقيته إلى إنتاج.⁷ أدوات نهج المجموعة تشير فقط إلى المجلّد المسمّى حرفيّاً PolicyDefinitions، لذا مجرّد وضع ملفّات في مجلّد باسم إصدار لا أثر له. مزيّة هذا النهج أنّه إن نشأت مشكلة، يمكنك الرجوع إلى المجلّد الذي نحّيته جانباً.⁷

flowchart TB
    accTitle: خطوات تحديث المخزن المركزيّ
    accDescr: التحديث يجمع مجموعة ADMX الكاملة لنظام التشغيل والتطبيقات في مجلّد عمل باسم الإصدار، ثمّ يعيد تسمية المجلّد الحاليّ جانباً ويعيد تسمية مجلّد العمل إلى اسم الإنتاج PolicyDefinitions، وإن حدثت مشكلة يُعاد إلى المجلّد القديم
    work["مجلّد عمل باسم الإصدار"] --> gather["اجمع حصّة النظام والتطبيقات"]
    gather --> evac["أعد تسمية الحاليّ جانباً"]
    evac --> rename["مجلّد العمل إلى اسم الإنتاج"]
    rename --> live["يُشار إليه كإنتاج"]
    live -.-> back["عند مشكلة أعد القديم"]

الشكل 16: التحديث يجمع المجموعة في مجلّد عمل، وينحّي الحاليّ جانباً، ثمّ يرقّيه بإعادة التسمية إلى إنتاج.

7. GPO مقابل Intune (MDM/CSP) مقابل النشر اليدويّ/بالسكربت ── جدول قرار

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

محور القرار بسيط: أساس هويّة الجهاز (AD، أو Microsoft Entra) وأين يقع الجهاز. GPO الأوثق لأسطول حواسيب مكتبيّة ثابتة منضمّة بالكامل إلى AD محلّيّ؛ GPO ببساطة لا تصل البتّة إلى حواسيب جوّالة منضمّة لـ Entra.

في الواقع، معظم المنشآت الصغيرة والمتوسّطة تجلس في الوسط، في إعداد هجين (منضمّ للنطاق زائد مسجَّل في Intune)، وأسوأ ما يمكنك فعله هنا «ضبط الإعداد نفسه عبر GPO وMDM كليهما». لدى Policy CSP سياسة تُسمَّى MDMWinsOverGP تتيح لـ MDM أن يفوز عندما تتعارض GPO وMDM، لكنّ نطاقها مقصور على السياسات المقابلة داخل Policy CSP. مايكروسوفت نفسها صريحة في أنّ ضبط إعداد خارج ذلك التحكّم عبر GPO وMDM كليهما يُنتج حالة سباق بلا ضمان أيّهما يفوز، وأنّ التكوين المزدوج ينبغي تجنّبه.⁸ المبدأ الأوّل للتشغيل الهجين أن تقرِّر، مجال إعداد فمجال إعداد، «هذا لـ GPO، وهذا لـ Intune»، وتلتزم بسلطة إدارة واحدة.

flowchart TB
    accTitle: الاختيار بين GPO وIntune
    accDescr: إن كانت هويّة الجهاز AD محلّيّاً والجهاز مقيماً في المكتب فـ GPO أنسب، وإن كان انضمام Entra أو خارج الموقع فـ Intune أنسب، وفي الهجين تجنّب التكوين المزدوج للإعداد نفسه وأسند كلّ مجال إدارة إلى جهة واحدة
    q{"أساس الجهاز وموقعه؟"}
    q -->|انضمام AD ومقيم داخليّاً| gpo["GPO موثوق وأدقّ تفصيلاً"]
    q -->|انضمام Entra أو خارج الموقع| intune["Intune يصل خارج المكتب"]
    q -->|هجين| split["أسند كلّ مجال لجهة واحدة"]
    split -.-> warn["التكوين المزدوج بلا ضمان ناتج"]
    split -.-> ana["الفرز بـ Group Policy analytics"]

الشكل 17: الاختيار يُقرَّر بأساس هويّة الجهاز وموقعه، وفي الهجين لا تضبط الإعداد نفسه عبر GPO وMDM كليهما.

متى صرت في مرحلة التفكير في ترحيل من GPO إلى Intune، فإنّ Group Policy analytics في Intune هو المدخل. استورد GPO مصدَّرة من GPMC ‏(XML)، فتحلِّل ما إذا كان كلّ إعداد مدعوماً بـ MDM، أو غير مدعوم/مُهمَلاً؛ والإعدادات المدعومة يمكن ترحيلها إلى سياسة كتالوج إعدادات Intune.⁹ الأدقّ أن تفكِّر في هذا كأداة لـ «فرز ما يمكن نقله، وما لا يمكن، وما يُطرَح» لا لـ «نقل كلّ شيء». سلطة إدارة Windows Update تُعاد تنظيمها على الخطوط نفسها أيضاً ── انظر كذلك «إدارة تحديثات Windows بعد إهمال WSUS».

flowchart TB
    accTitle: الفرز بـ Group Policy analytics
    accDescr: استيراد GPO مصدَّرة XML من GPMC إلى Group Policy analytics يفرز كلّ إعداد حسب دعم MDM أو الإهمال أو عدم الإمكان، والإعدادات المدعومة يمكن ترحيلها إلى سياسة كتالوج إعدادات
    exp["صدِّر XML من GPMC"] --> imp["استورد إلى analytics"]
    imp --> ana["حلِّل حالة الدعم لكلّ إعداد"]
    ana --> ok["مدعوم في MDM"]
    ana --> dep["مُهمَل أو غير مدعوم"]
    ok --> mig["رحِّل إلى سياسة كتالوج الإعدادات"]

الشكل 18: Group Policy analytics يستورد GPO مصدَّرة ويفرز الإعدادات التي يمكن نقلها إلى MDM عن التي لا يمكن.

8. نقطة عمياء للمطوّر ── كيف تغيّر GPO الزبون سلوك تطبيقك

أخيراً، أمر يستحقّ معرفته إن كنت تطوِّر بعقد. GPO الزبون تعيد كتابة افتراضات تطبيقك بهدوء. إلى جانب الجدران ومكافحة الفيروسات، GPO مُدان منتظم وراء «يعمل على آلة التطوير ولا يعمل في موقع الزبون». إليك أمثلة ملموسة.

• سياسة تنفيذ PowerShell: يمكن ضبط سياسة التنفيذ مركزيّاً عبر GPO، ونطاقات MachinePolicy/UserPolicy الآتية من GPO تتقدَّم دائماً على قيمة مضبوطة محلّيّاً أو على العمليّة.¹⁰ إن بُني مثبِّت أو سكربت تشغيليّ على افتراض أنّ «إضافة -ExecutionPolicy Bypass ستجعله يعمل»، فلن يُقلَع أصلاً تحت إدارة GPO. انظر «سياسة تنفيذ PowerShell وتوقيع السكربتات ── دليل عمليّ للتخلّص من تشغيل «السدّ بـ Bypass»» للتفاصيل.
• تعطيل دمج القواعد المحلّيّة على الجدار: في بيئات يُدار فيها الجدار مركزيّاً عبر GPO/Intune، يمكن تعطيل «دمج القواعد المحلّيّة» (AllowLocalPolicyMerge) لكلّ ملفّ تعريف. حيث يُعطَّل، فإنّ قاعدة واردة سجَّلها مثبِّت محلّيّاً موجودة لكنّها غير مطبَّقة.¹¹ نقطة يجب تأكيدها قبل نشر تطبيق من نوع خادم؛ وهي مشمولة بالتفصيل في «جدار حماية Windows وتطبيقات الأعمال».
• تكوين البيئة مثل تعيينات المحرّكات والوكلاء: تعيين محرّكات الشبكة والطابعات وما شابه يُوزَّع عادة عبر تفضيلات نهج المجموعة (Preferences).¹⁶ افتراضات عن البيئة ── «محرّك Z ينبغي أن يوجد»، «الوكيل ينبغي أن يكون اتّصالاً مباشراً» ── يمكن أن تُنقَض بحسب المستخدم المسجِّل الدخول أو عضويّة OU للحاسوب. من السهل أيضاً أن يُغفَل، لتطبيق مقيم، أنّ الإعدادات الموزَّعة عبر تكوين المستخدم لا تسري بطبيعة الحال على الحساب الذي تعمل تحته خدمة أو مهمّة مجدولة.
• الإعداد ببساطة «لا يمكن إرجاعه»: الإعدادات الآتية من القوالب الإداريّة عادة لا يستطيع المستخدم تغييرها عبر الواجهة أصلاً (البند رماديّ). أنّ «اجعل الزبون يغيِّر الإعداد فحسب» لا ينجح له أثر حقيقيّ على كيف تصمِّم نهج الدعم.

flowchart TB
    accTitle: افتراضات التطبيق التي تغيّرها GPO الزبون
    accDescr: GPO الزبون تغيّر افتراضات التطبيق بفرض سياسة التنفيذ وتعطيل دمج القواعد المحلّيّة للجدار وتعيين المحرّكات والوكيل وحالة لا يستطيع المستخدم فيها إرجاع الإعداد، فتصير سبباً لحدث لا يعمل إلا في موقع الزبون
    gpo["GPO الزبون"] --> ep["فرض سياسة التنفيذ"]
    gpo --> fw["تعطيل دمج القواعد المحلّيّة"]
    gpo --> env["تعيين محرّكات ووكيل"]
    gpo --> lock["لا يمكن إرجاع الإعداد"]
    ep --> sym["سبب لعدم العمل عند الزبون فقط"]
    fw --> sym
    env --> sym
    lock --> sym

الشكل 19: GPO الزبون تعيد بهدوء كتابة افتراضات التطبيق مثل سياسة التنفيذ والجدار وتكوين البيئة.

ثمّة ثلاثة احتياطات واقعيّة في جانب التطوير. الأوّل، وثِّق كمتطلّب نشر افتراضات البيئة التي يعتمد عليها تطبيقك ── سياسة التنفيذ، منافذ الاستماع، أين يكتب، مسار الوكيل، وما شابه ── واجعل تقنيّة معلومات الزبون تؤكِّدها قبل النشر. الثاني، عندما تنشأ متاعب، راجع تقرير gpresult /h الفعليّ والقيم الحقيقيّة تحت HKLM\Software\Policies، بدل التخمين (الفصل 5). الثالث، افصل في مرحلة التصميم أيّ عمليّات تحتاج امتيازات مدير وأيّها لا تحتاج (هذا الخطّ مرسوم في «متى يصبح Windows admin privilege ضروريّاً - UAC والمناطق المحميّة وكيفيّة التمييز على مستوى التصميم»). GPO ليست العدوّ ── إنّها مواصفة البيئة. عاملها كمواصفة، فيصير التشخيص آليّاً.

flowchart TB
    accTitle: ثلاث احتياطات من جانب التطوير
    accDescr: احتياطات التطوير ثلاثة توثيق افتراضات البيئة التي يعتمد عليها التطبيق كمتطلّب نشر وطلب تأكيدها من تقنيّة معلومات الزبون قبل النشر، وعند المتاعب تأكيد تقرير gpresult والقيم الفعليّة لمفتاح Policies، وفصل المعالجات التي تحتاج امتياز مدير في مرحلة التصميم
    dev["احتياطات جانب التطوير"] --> doc["1. وثِّق افتراضات البيئة"]
    dev --> chk["2. أكِّد بـ gpresult والقيمة"]
    dev --> priv["3. افصل الحاجة للامتياز تصميماً"]
    doc -.-> ask["اطلب التأكيد من تقنيّة معلومات الزبون قبل النشر"]

الشكل 20: احتياطات التطوير ثلاثة: توثيق افتراضات البيئة، والتأكيد بـ gpresult والقيمة الفعليّة، وفصل الحاجة لامتياز المدير في التصميم.

9. الخلاصة

• نهج المجموعة آليّة تعالج إعدادات على مستوى GPO بالترتيب محلّيّ → موقع → نطاق → OU (LSDOU)، وتُحَلّ التعارضات على أساس الأخير يفوز. GPO على OU الأقرب للهدف هي الطبقة الأقوى، وGPO المحلّيّة الأضعف.
• حظر الوراثة والفرض (Enforced) وترشيح الأمن تتيح لك التحكّم في التدفّق الافتراضيّ. الفرض يهزم حظر الوراثة أيضاً، لذا ينبغي ألا يُكثَر منه.
• التطبيق يجري عبر قناتين: معالجة مقدّمة عند البدء/تسجيل الدخول، وتحديث خلفيّ نحو كلّ 90 دقيقة زائد إزاحة عشوائيّة افتراضيّاً. gpupdate /force يعيد تطبيق كلّ إعداد، لكن لا أثر له على إعدادات لا تُعالَج إلا عند تسجيل الدخول أو إعادة التشغيل.
• عندما لا ينعكس إعداد، شخِّصه آليّاً بالترتيب gpresult /h → سجلّ تشغيل GroupPolicy → مفتاح Policies في السجلّ. GPO المرفوضة تُعرَض مع سبب.
• تعريفات القوالب الإداريّة هي ADMX/ADML، وتشغيل النطاق ينبغي أن يجمعها في المخزن المركزيّ في SYSVOL. عند التحديث، استبدل جانب المخزن المركزيّ بدل استبدال مجلّد PolicyDefinitions المحلّيّ.
• استخدام GPO أو Intune يُقرَّر بأساس هويّة الجهاز وموقعه؛ في إعداد هجين، تجنّب التكوين المزدوج للإعداد نفسه وأبقِ سلطة الإدارة في جانب واحد. Group Policy analytics يساعد في فرز الترحيل.
• للمطوِّرين، GPO الزبون جزء من مواصفة البيئة. وثِّق الافتراضات حول سياسة التنفيذ والجدار وتعيينات المحرّكات وتكوين الوكيل، وابنِ عادة تأكيدها بـ gpresult ── ومعظم حالات «يفشل عند الزبون فقط» تتوقّف عن أن تكون مخيفة.

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

• جدار حماية Windows وتطبيقات الأعمال ── سجِّل قواعد واردة من المثبِّت
• إدارة تحديثات Windows بعد إهمال WSUS ── كيف تختار بين WUfB وAutopatch وIntune
• سياسة تنفيذ PowerShell وتوقيع السكربتات ── دليل عمليّ للتخلّص من تشغيل «السدّ بـ Bypass»
• أتمتة تجهيز الحواسيب بـ winget + PowerShell ── جعل الكتيّب قابلاً للتنفيذ
• دليل التخلّص من الاعتماد على وضع IE
• متى يصبح Windows admin privilege ضروريّاً - UAC والمناطق المحميّة وكيفيّة التمييز على مستوى التصميم

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

تتعامل شركة كومورا سوفت ذ.م.م. مع التحقيق في سبب عدم تشغيل تطبيق أعمال في بيئة زبون تحت إدارة GPO، وتنظيم متطلّبات النشر (سياسة التنفيذ، الجدار، افتراضات الشبكة)، والاستشارة التقنيّة حول جرد السياسات وخطط الإدارة المشتركة مع Intune لموظّفي تقنيّة المعلومات الذين ورثوا بيئة AD. يصحّ البدء من مرحلة مبكِّرة مثل «تعالَ اقرأ تقرير gpresult معنا».

• الاستشارات التقنيّة ومراجعة التصميم
• التحقيق في الأخطاء وتحليل السبب الجذري
• تطوير تطبيقات ويندوز
• التواصل معنا

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

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

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

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

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

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

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

نفّذت gpupdate /force، لكنّ الإعداد ما زال غير مطبَّق. لماذا؟

أوّلاً تحقّق ممّا إذا كان الإعداد من الأنواع التي لا يطبِّقها تحديث خلفيّ أبداً. تثبيت البرمجيّات الموجَّه للمستخدم وإعادة توجيه المجلّدات لا يُعالَجان إلا عند تسجيل الدخول، وتثبيت البرمجيّات الموجَّه للحاسوب لا يُعالَج إلا عند البدء، لذا بعد انتهاء gpupdate تحتاج إلى تسجيل خروج (/logoff) أو إعادة تشغيل (/boot). ثانياً، شغِّل gpresult /h لإنتاج تقرير RSoP وتحقّق ممّا إذا كانت تلك GPO تظهر ضمن «GPO المطبَّقة»، أو ضمن «GPO المرفوضة» مع سبب. إن كانت مطبَّقة لكنّ السلوك لم يتغيّر، اشتبه بأنّ GPO أخرى أعلى أسبقيّة تكتب فوق الإعداد نفسه (الأخير يفوز). يعرض التقرير «GPO الفائزة» لكلّ إعداد، فتحدِّد أيّ GPO تفوز بالضبط.

ماذا يعني ظهور «مرفوض - ترشيح» في تقرير gpresult؟

يعني أنّ GPO داخل النطاق من حيث مكان رابطها، لكنّ الترشيح أخرجها من التطبيق الفعليّ. السبب الأشيع ترشيح الأمن: لتطبيق GPO يجب أن يملك المستخدم أو الحاسوب إذني «قراءة» و«تطبيق نهج المجموعة» كليهما على تلك GPO. افتراضيّاً يُمنَح الاثنان لـ Authenticated Users، لكن إن ضيَّقت ذلك إلى مجموعات محدَّدة، فإنّ عضويّة مجموعة فائتة ── نسيان إضافة المجموعة، أو نسيان إضافة حساب الحاسوب ── تُسبِّب الرفض. لـ GPO الموجَّهة للمستخدم، منح الإذنين للمستخدم المستهدف وحده لا يكفي. منذ MS16-072 تُجلَب سياسة المستخدم في سياق أمن الحاسوب، لذا يلزم إبقاء «قراءة» (لا «تطبيق») لـ Authenticated Users أو Domain Computers. أسباب أخرى تشمل مرشّح WMI لا يطابق، أو تعطيل تكوين المستخدم/الحاسوب على GPO نفسها. سبب الرفض يُسجَّل في تقرير gpresult وفي سجلّ تشغيل GroupPolicy كليهما.

هل أدير الجهاز بـ GPO أم بـ Intune؟

القاعدة الأساسيّة مواءمة أساس هويّة الجهاز. إن كانت أجهزتك في الغالب منضمّة لنطاق AD محلّيّ ومتّصلة دائماً بالشبكة الداخليّة، فـ GPO الخيار الأوثق والأدقّ تفصيلاً. إن كثرت الأجهزة المنضمّة إلى Microsoft Entra، أو حواسيب العمل من المنزل التي لا تلمس متحكّم نطاق، فإنّ Intune (MDM/CSP)، الذي يوصل التكوين خارج المكتب أيضاً، أنسب. في بيئة هجينة يتعايش فيها الاثنان، ضبط الإعداد نفسه عبر GPO وMDM يُنتج تعارضاً بلا فائز مضمون، لذا المبدأ أن تقرِّر، مجال إعداد فمجال إعداد، أيّهما يديره، وتلتزم بذلك الواحد. متى صرت تفكِّر في الترحيل، فإنّ استيراد GPO القائمة إلى Group Policy analytics في Intune يفرز الإعدادات إلى ما يدعمه MDM أصلاً وما هو غير مدعوم أو مُهمَل.

إعداد ضبطته بمحرِّر نهج المجموعة المحلّيّ (gpedit.msc) يُكتَب فوقه إعداد النطاق باستمرار. أهذا متوقَّع؟

نعم، هذا بالتصميم. يُعالَج نهج المجموعة بالترتيب محلّيّ → موقع → نطاق → OU (LSDOU)، وأيّ GPO تُعالَج لاحقاً تفوز عند التعارض، ما يجعل GPO المحلّيّة الطبقة الأضعف. إن كوَّنت GPO نطاق الإعداد نفسه، فسيُكتَب فوق تغييرك المحلّيّ دائماً. بالمقابل، إن ترك جانب النطاق ذلك الإعداد «غير مكوَّن»، فإنّ قيمة GPO المحلّيّة تبقى كما هي. حتّى إن أردت أن تتقدَّم القيمة المحلّيّة لأغراض الاختبار، لا طريقة لعكس ترتيب الأسبقيّة هذا على حاسوب منضمّ للنطاق، لذا المساران الواقعيّان إنشاء OU اختبار مخصَّص وضبط GPO جانب النطاق، أو استخدام آلة اختبار غير منضمّة للنطاق.

تطبيق الأعمال الذي طوّرناه لا يعمل في بيئة الزبون. هل من طريقة للتحقّق ممّا إذا كانت GPO السبب؟

الخطوة الأولى أن تطلب من مدير الزبون تشغيل gpresult /h report.html من موجِّه أوامر مرتفع الصلاحيّة على الحاسوب المتأثّر ومراجعة تقرير RSoP. ابحث عن إعدادات تغيّر سلوك تطبيقك: سكربتات يحظرها سياسة التنفيذ، تعطيل دمج قواعد الجدار المحلّيّة، أو وكيل وتعيينات محرّكات مكوَّنة. يفيد أيضاً التحقّق ممّا إذا كُتبت قيم سياسة للمنتج المعنيّ تحت HKLM\Software\Policies وHKCU\Software\Policies في السجلّ، ما يتيح لك تعليم أيّ إعدادات مفروضة آتية من القوالب الإداريّة آليّاً. في جانب التطوير، الاحتياط العمليّ توثيق الافتراضات التي يعتمد عليها تطبيقك ── سياسة التنفيذ، منافذ الاستماع، المجلّد الذي يكتب إليه، وما شابه ── كمتطلّب نشر، وجعل تقنيّة معلومات الزبون تؤكِّدها قبل النشر.

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

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

غو كومورا

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

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