إصلاح نهج المجموعة (Group Policy) في ويندوز 11: دليل GPResult وGPSVC 2026

آخر تحديث: 4 أغسطس 2026

عندما لا يُطبَّق نهج المجموعة (Group Policy) في ويندوز 11 داخل مؤسسة مرتبطة بـ Active Directory، فالإجابة القصيرة هي: شغّل الأمر gpresult /h C:\Temp\rsop.html على الجهاز المتأثر، افتح التقرير، وابحث عن قسم "GPOs were not applied because they were filtered out" — سيُخبرك مباشرة إن كان السبب تصفية أمان، أو مرشّح WMI، أو توريث معطّل، أو صراع مع سياسة Intune. أمر gpupdate /force لا يُصلح سبب الرفض؛ فقط يُعيد تطبيق ما هو مسموح به بعد إصلاح السبب الجذري. هذا الدليل يشرح مسار التشخيص الكامل لمكتب المساعدة في 2026.

• ابدأ دائماً بـ gpresult /r أو gpresult /h قبل gpupdate /force؛ الأول يُخبرك لماذا فشل التطبيق، والثاني يُعيد المحاولة فقط.
• ثلاثة أحداث GPSVC تحكم 80% من مكالمات الدعم: 1058 (تعذّر قراءة gpt.ini من SYSVOL)، 1030 (عرض ثانوي مصاحب لـ 1058)، و1129 (تعذّر الوصول إلى وحدة تحكم النطاق).
• مرشّحات WMI المكتوبة بـ Version LIKE "10.0.19%" لن تُطابق ويندوز 11 (24H2 يستخدم الأرقام 10.0.26100+). راجع كل مرشّح بعد ترقية الأسطول.
• في السيناريوهات الهجينة مع Intune، يفوز نهج المجموعة افتراضياً؛ فعّل CSP الخاص بـ ControlPolicyConflict/MDMWinsOverGP لجعل Intune يفوز، لكنه ينطبق فقط على إعدادات Policy CSP.
• الأمر gpupdate /force يُعيد تطبيق كل إعداد، لكن إعدادات إعادة توجيه المجلدات وتثبيت البرامج تتطلب تسجيل خروج/دخول أو إعادة تشغيل حقيقية.
• عند تلف Registry.pol، أعِد تسميته بدلاً من حذفه ثم شغّل gpupdate /force. يُنشئ ويندوز نسخة جديدة نظيفة تلقائياً.

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

في تجربتي مع مئات تذاكر مكتب المساعدة، تنقسم أسباب "نهج المجموعة لا يعمل" في ويندوز 11 إلى ست عائلات واضحة، ومعرفة العائلة الصحيحة يوفّر ساعات من محاولات الحل العشوائي. أولاً، إصدار ويندوز غير مدعوم: النسخة المنزلية Windows 11 Home لا تحتوي على محرّر نهج المجموعة المحلي ولا تعالج معظم إعدادات GPO الخاصة بالمؤسسات؛ فحصٌ سريع عبر winver يحسم الموضوع قبل بدء التشخيص. ثانياً، الجهاز غير متصل فعلياً بوحدة تحكم النطاق: بعد VPN منقطع، أو DNS يشير إلى موجّه المنزل بدل خوادم DNS الخاصة بالمجال، لن يستطيع عميل نهج المجموعة قراءة SYSVOL وسيسجّل حدث 1058.

ثالثاً، تصفية أمان أو مرشّح WMI يستبعد المستخدم أو الجهاز. وهذا السبب الأكثر إحباطاً لأن كل شيء يبدو "صحيحاً" في GPMC لكن الـ GPO يُصفَّى خارج النطاق. رابعاً، توريث معطّل (Block Inheritance) على وحدة تنظيمية أعلى في السلسلة، مصحوباً أحياناً بعلامة "Enforced" مفقودة على السياسة الأم. خامساً، تلف في Registry.pol على العميل، وعادةً بعد إغلاق قسري أثناء التطبيق أو انقطاع كهرباء. سادساً، صراع مع سياسة Intune في الأجهزة المُدارة بشكل مشترك (Co-managed). هنا لا يوجد "خطأ" تقني، بل قرار أسبقية بين GPO وMDM. الأدوات الثلاث القادمة (gpresult، RSOP، سجل الأحداث) ستُخبرك أيّ عائلة من هذه الست تواجهها في أول 60 ثانية.

كيف يعمل نهج المجموعة في ويندوز 11 اليوم؟

لفهم لماذا تفشل السياسة، يجب فهم دورة حياتها الكاملة على العميل. عند إقلاع الجهاز، تعمل خدمة Group Policy Client (gpsvc) بشكل غير متزامن افتراضياً. أي أن سطح المكتب يظهر قبل انتهاء تطبيق سياسات الحاسوب، وهذه هي "Fast Logon Optimization" التي تُسبّب أحد أشيع الشكاوى: "السياسة لم تُطبَّق بعد إعادة التشغيل الأولى". السياسات ذات المكوّن الأمامي (Foreground). مثل إعادة توجيه المجلدات، وتثبيت البرامج، وسكربتات تسجيل الدخول. تحتاج دورتَي تسجيل دخول متتاليتين في أسوأ الحالات لتُطبَّق بالكامل.

بعد تسجيل الدخول، تُطبَّق سياسات المستخدم، ثم يعمل تحديث الخلفية (Background Refresh) كل 90 دقيقة مع إزاحة عشوائية 0–30 دقيقة لتجنّب إغراق وحدة تحكم النطاق. عميل GP يتّبع مساراً محدّداً: يحلّ اسم النطاق عبر DNS، يعثر على أقرب DC عبر DC Locator، يقرأ gpt.ini من \\domain.local\SYSVOL، يقارن رقم النسخة (Version Number) مع المخزّن محلياً في HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\History، وينزّل فقط ما تغيّر. الأخطاء تظهر عادةً في ثلاث نقاط: فشل تحليل DNS (يظهر حدث 1129)، أو تعذّر قراءة SYSVOL (حدث 1058)، أو تلف في مسار التخزين المؤقت المحلي. عرفت نقطة الفشل، عرفت الأمر الذي يجب تشغيله أولاً.

لمن يريد التعمّق في التسلسل الرسمي والاعتماديات الشبكية، وثيقة Applying Group Policy troubleshooting guidance من Microsoft Learn تبقى المرجع الأدقّ لأنماط الفشل والأحداث المتوقعة لكل خطوة. هذه الوثيقة محدَّثة لدعم Windows 11 وWindows Server 2022/2025.

تشخيص GPResult خطوة بخطوة

gpresult هو أول أمر أشغّله دائماً. قبل gpupdate، وقبل فتح Event Viewer، وقبل سؤال المستخدم عن أي شيء. الأمر يقرأ الذاكرة المحلية لحالة تطبيق آخر سياسة، ويُخبرك على الفور: أي GPOs طُبّقت، وأي GPOs رُفضت، وسبب الرفض. الفارق بينه وبين gpupdate /force جوهري: gpupdate يُعيد التطبيق دون تفسير، بينما gpresult يشرح ما حدث فعلياً.

الأوامر الأساسية لطبقة أولى

# عرض ملخّص GPOs المطبّقة والمرفوضة للمستخدم والحاسوب معاً
gpresult /r

# نفس المعلومات لكن مع تفاصيل موسّعة (Verbose)
gpresult /v

# أفضل خيار للتذاكر: تقرير HTML كامل يمكن إرفاقه بالتذكرة
gpresult /h C:\Temp\rsop.html /f

# استعلام مستخدم محدّد على نفس الجهاز (مفيد للحسابات المشتركة)
gpresult /r /user CONTOSO\ahmed.saleh

# تشغيل على جهاز بعيد عبر PowerShell Remoting
Invoke-Command -ComputerName WKS-042 -ScriptBlock { gpresult /r }

# تصدير تقرير HTML من جهاز بعيد إلى مشاركة شبكية
gpresult /s WKS-042 /h \\fileserver\reports\WKS-042-rsop.html /f

عند فتح تقرير HTML، انزل مباشرةً إلى قسم "The following GPOs were not applied because they were filtered out". هذا القسم هو الذهب. يُخبرك بالسبب الحقيقي: "Denied (Security)" يعني تصفية أمان، "Filtering: Not Applied (Empty)" يعني السياسة فارغة، "Filtering: Not Applied (Unknown Reason)" غالباً مرشّح WMI فشل التقييم. لا تشغّل gpupdate /force قبل قراءة هذا القسم؛ إن لم يُصلح الجذر، سيبقى الرفض قائماً.

سكربت PowerShell لطبقة أولى

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

# -- Bulk-Gpresult.ps1 --
# الغرض: جمع تقارير RSoP HTML من قائمة أجهزة بعيدة
# للاستخدام: عدّل $Computers و $OutFolder ثم شغّل بصلاحيات إدارية
$Computers  = Get-Content "C:\Support\targets.txt"   # قائمة أسماء الأجهزة، جهاز في كل سطر
$OutFolder  = "\\fs01\helpdesk$\GPResult\$(Get-Date -Format 'yyyyMMdd')"

# 1) أنشئ مجلد الإخراج إن لم يكن موجوداً
New-Item -Path $OutFolder -ItemType Directory -Force | Out-Null

# 2) نفّذ gpresult على كل جهاز بالتوازي (throttle 10 اتصالات)
Invoke-Command -ComputerName $Computers -ThrottleLimit 10 -ScriptBlock {
    $ReportPath = "C:\Windows\Temp\$($env:COMPUTERNAME)-rsop.html"
    # /f يستبدل التقرير القديم؛ /h يُنتج HTML
    gpresult /h $ReportPath /f 2>&1 | Out-Null
    Get-Item $ReportPath
} | ForEach-Object {
    # 3) اسحب التقرير من كل جهاز إلى المشاركة المركزية
    Copy-Item -Path "\\$($_.PSComputerName)\C$\Windows\Temp\$($_.Name)" `
              -Destination $OutFolder -Force
}

Write-Host "تم. راجع التقارير في: $OutFolder"

استخدام RSOP.msc ونمذجة GPMC

عندما يريد المسؤول عرضاً مرئياً شجرياً لكل الإعدادات المطبّقة على جهاز أو مستخدم، rsop.msc هو الأداة الصحيحة. يشغّل الأمر Snap-In لوحدة إدارة Microsoft، ويعرض شجرة كاملة: القوالب الإدارية، الإعدادات الأمنية، إعادة توجيه المجلدات، السكربتات، وسياسات AppLocker/Defender. كل إعداد يعرض عمود "Winning GPO" الذي يكشف مباشرةً أيّ سياسة فازت في حال التعارض. وهذا يوفّر ساعات مقارنة يدوية بين GPOs متعدّدة تحاول ضبط نفس المفتاح.

لكن rsop.msc له عيبان مهمّان: أولاً، لا يعرض Group Policy Preferences (تفضيلات نهج المجموعة). الأدوات مثل ربط الطابعات ومحرّكات الشبكة تظهر فقط في gpresult الكامل. ثانياً، يعمل فقط في وضع "Logging" على الجهاز الحالي؛ للتخطيط أو محاكاة "ماذا لو" استخدم بديلاً أقوى.

نمذجة نهج المجموعة (Group Policy Modeling)

داخل GPMC، انقر بزر الفأرة الأيمن على "Group Policy Modeling" واختر "Group Policy Modeling Wizard". حدّد وحدة تنظيمية للمستخدم ووحدة تنظيمية للحاسوب، اختر موقع Active Directory (لمحاكاة السياسات المرتبطة بالموقع)، وحدّد عضويات المجموعات الأمنية إن كنت تختبر حالة "ماذا لو انضم المستخدم لمجموعة أخرى". النتيجة: تقرير كامل يُظهر أيّ GPOs ستُطبَّق، بأيّ ترتيب، وأيّها سيُرفَض. كل ذلك دون الحاجة لتوفّر الجهاز الهدف على الشبكة. هذه الأداة هي السلاح الأمضى قبل نشر سياسة جديدة على 3000 جهاز.

# تشغيل نمذجة عبر PowerShell (يتطلّب GroupPolicy module)
# استيراد الوحدة النمطية إن لم تكن محمّلة
Import-Module GroupPolicy

# نمذجة لمستخدم في OU معيّن على جهاز في OU آخر
Get-GPResultantSetOfPolicy `
    -User    "CONTOSO\ahmed.saleh" `
    -Computer "CONTOSO\WKS-042" `
    -ReportType Html `
    -Path "C:\Temp\modeling-report.html"

للمزيد عن أوامر gpresult ومقارنتها بأدوات RSOP الرسومية، راجع مرجع أمر gpresult الرسمي من Microsoft. يحوي جدول المفاتيح الكامل بما فيها /scope و/user و/x لتصدير XML.

تحليل أحداث GPSVC: 1058 و1030 و1129

ثلاثة أحداث في سجل System (المصدر: Microsoft-Windows-GroupPolicy) تُلخّص 80% من مكالمات مكتب المساعدة المتعلّقة بـ GPO. حفظها في ذاكرتك يوفّر وقتاً حقيقياً.

Event ID	المعنى	السبب الجذري الأكثر شيوعاً	الإصلاح السريع
1058	تعذّر قراءة gpt.ini من SYSVOL	تأخير DFS-R، DNS خاطئ، أو حجب SMB بين العميل وDC	تحقّق من nslookup و Test-NetConnection -Port 445
1030	تعذّر استرداد إعدادات نهج المجموعة	عرض ثانوي مصاحب لـ 1058 (نفس السبب الجذري)	حلّ 1058 أولاً — 1030 سيختفي تلقائياً
1129	خدمة GPSVC لم تستطع الوصول لوحدة تحكم النطاق	LDAP (منفذ 389) محجوب، أو الشبكة لم تكتمل عند الإقلاع	فعّل "Always wait for the network at computer startup and logon"

خذ 1129 كمثال عملي. يحدث كثيراً على أجهزة محمولة تعمل عبر Wi-Fi للشركات. بطاقة الشبكة لم تُصادق على 802.1X قبل أن يبدأ gpsvc أول محاولة تطبيق. النتيجة: خطأ واحد يظهر عند الإقلاع ثم يختفي عند الدورة التالية (بعد 90 دقيقة). إن كان الحدث يظهر مرة واحدة ثم يختفي، لا داعي للقلق. أما إن استمرّ، فعّل السياسة التالية:

مسار السياسة: Computer Configuration → Administrative Templates → System → Logon → Always wait for the network at computer startup and logon. اضبطها إلى Enabled. هذا يُجبر ويندوز على انتظار توفّر الشبكة الكامل قبل بدء تطبيق سياسات الحاسوب، مما يزيد زمن الإقلاع ثانيتين إلى خمس، لكنه يُنهي حدث 1129 نهائياً.

لحدث 1058، ابدأ من العميل واعمل نحو DC:

# 1) هل يستطيع العميل حلّ اسم النطاق؟
nslookup contoso.local

# 2) هل يستطيع الوصول إلى SYSVOL عبر SMB (منفذ 445)؟
Test-NetConnection -ComputerName contoso.local -Port 445

# 3) هل يستطيع قراءة الملف نفسه؟
Get-Item "\\contoso.local\SYSVOL\contoso.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini"

# 4) هل حالة DFS-R على DCs متزامنة؟ (شغّل هذا على DC)
dfsrdiag ReplicationState /verbose

تفعيل سجل التشخيص المطوّل gpsvc.log

عندما لا يُقدّم Event Viewer تفاصيل كافية. مثلاً السياسة تُصفَّى دون سبب واضح، أو تحدث حالة سباق بين مكوّنات GP وCredential Provider. فعّل Debug Logging لخدمة GPSVC. هذا يُنتج ملف %windir%\debug\usermode\gpsvc.log بتتبّع كامل لكل خطوة تطبيق سياسة، بما فيها استعلامات LDAP وقراءات ملفات SYSVOL وقرارات التصفية.

# تفعيل عبر PowerShell (شغّل كمسؤول)
# ينشئ مفتاح Diagnostics وقيمة GPSvcDebugLevel = 0x30002
$RegPath = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Diagnostics"
if (-not (Test-Path $RegPath)) { New-Item -Path $RegPath -Force | Out-Null }
Set-ItemProperty -Path $RegPath -Name "GPSvcDebugLevel" -Value 0x30002 -Type DWord

# افرض تحديث السياسة لبدء التتبّع
gpupdate /force

# افتح السجل وابحث عن أول "ERROR" أو "warning"
Get-Content "$env:windir\debug\usermode\gpsvc.log" -Tail 200 |
    Select-String -Pattern "error|warn|fail" -CaseSensitive:$false

# لإيقاف التتبّع بعد الانتهاء (مهم!)
Remove-ItemProperty -Path $RegPath -Name "GPSvcDebugLevel"

عند تحليل gpsvc.log، ابحث عن الأنماط التالية: CGroupPolicyManager::EvaluateDeferredPolicies يعني بدء دورة تطبيق، ProcessGPO يعني بدء معالجة GPO محدّد، وEndRSoPExtendedError مصحوباً برمز خطأ ست عشري يُخبرك ما فشل بالضبط (مثلاً 0x80070005 يعني رفض وصول. تحقّق من صلاحيات SYSVOL).

إصلاح ملف Registry.pol التالف

إذا ظهرت رسالة "Computer policy could not be updated successfully" عند تشغيل gpupdate، السبب في 90% من الحالات ملف Registry.pol تالف. هذا الملف هو المخزن المحلي لكل إعدادات القوالب الإدارية التي طُبّقت، ويقع في مسارين:

• سياسات الحاسوب: C:\Windows\System32\GroupPolicy\Machine\Registry.pol
• سياسات المستخدم: C:\Windows\System32\GroupPolicy\User\Registry.pol

الحلّ الصحيح: أعِد التسمية بدلاً من الحذف (لتحتفظ بنسخة احتياطية سريعة في حال احتجت التراجع)، ثم شغّل gpupdate /force. سيُنشئ ويندوز ملف Registry.pol جديداً نظيفاً من السياسات النشطة الحالية.

# شغّل نافذة PowerShell أو CMD كمسؤول
$Stamp = Get-Date -Format "yyyyMMdd-HHmmss"
$GPPath = "$env:windir\System32\GroupPolicy"

# 1) أعِد تسمية ملفَي Registry.pol (احتفاظ آمن بالنسخة القديمة)
if (Test-Path "$GPPath\Machine\Registry.pol") {
    Rename-Item "$GPPath\Machine\Registry.pol" "Registry.pol.bak-$Stamp"
}
if (Test-Path "$GPPath\User\Registry.pol") {
    Rename-Item "$GPPath\User\Registry.pol" "Registry.pol.bak-$Stamp"
}

# 2) امسح ذاكرة سياسات المجموعة من السجلّ
Remove-Item -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\History" `
            -Recurse -Force -ErrorAction SilentlyContinue

# 3) أعِد التطبيق من المصدر
gpupdate /force /boot

# 4) بعد نجاح الإقلاع، تأكّد بالأمر التالي
gpresult /r | Select-String "Applied Group Policy Objects" -Context 0,20

إن استمر الخطأ بعد إصلاح Registry.pol، شغّل sfc /scannow ثم DISM /Online /Cleanup-Image /RestoreHealth لإصلاح مكوّنات النظام التي يعتمد عليها عميل نهج المجموعة. هذه الأوامر تعالج تلف userenv.dll وgpapi.dll. وهو تلف نادر لكنه يُسبّب فشلاً كاملاً في تطبيق السياسة حتى مع Registry.pol سليم.

مرشّحات WMI وأرقام بناء ويندوز 11

هذا الفخ الأكثر إحراجاً في 2026: مؤسسات كثيرة كتبت مرشّحات WMI منذ أيام ويندوز 10 بصيغة مثل:

Select * from Win32_OperatingSystem Where Version LIKE "10.0.19%"

هذا المرشّح يُطابق ويندوز 10 (البنى 10.0.19041 و10.0.19045) لكنه يفشل تماماً في مطابقة ويندوز 11، الذي يستخدم أرقام بناء 10.0.22000 لإصدار 21H2، و10.0.22621/22631 لإصدار 22H2/23H2، و10.0.26100 لإصدار 24H2. النتيجة: كل الأجهزة المرقّاة إلى ويندوز 11 تسقط خارج نطاق سياسات مهمّة (مثل تشفير BitLocker أو قواعد Firewall) دون أيّ تحذير في GPMC.

مرشّحات WMI صحيحة لبيئة مختلطة 10/11

# -- تحديد ويندوز 11 فقط (كل الإصدارات) --
# Windows 11 = OS Version >= 10.0.22000 AND ProductType = 1
Select * from Win32_OperatingSystem
Where Version >= "10.0.22000" AND ProductType = 1

# -- تحديد ويندوز 11 24H2 وما بعده فقط --
Select * from Win32_OperatingSystem
Where Version >= "10.0.26100" AND ProductType = 1

# -- تحديد ويندوز 10 فقط (استبعاد 11) --
Select * from Win32_OperatingSystem
Where Version LIKE "10.0.19%" AND ProductType = 1

# -- تحديد Windows Server 2022 وما بعده --
# ProductType = 3 يعني Domain Controller أو Member Server
Select * from Win32_OperatingSystem
Where Version >= "10.0.20348" AND ProductType <> 1

بعد تحديث كل مرشّح، اختبره بالأمر wbemtest على جهاز عيّنة أو استخدم Get-WmiObject -Query "..." في PowerShell. لا تعتمد على GPMC لاختبار المرشّح. نمذجة GPMC تعرض النتيجة النظرية فقط، بينما تنفيذ الاستعلام على الجهاز الفعلي يكشف مشاكل الفهرسة الحقيقية.

تعايش نهج المجموعة مع Intune وMDMWinsOverGP

في بيئة Hybrid Entra Joined (منضم لـ Active Directory وEntra ID معاً)، يستطيع الجهاز استقبال سياسات GPO التقليدية و سياسات Intune MDM في نفس الوقت. عندما تحاول السياستان تعديل نفس مفتاح تسجيل. مثلاً كلمة مرور BitLocker، أو تعطيل Cortana، أو إعدادات Windows Update. يحتاج ويندوز قرار أسبقية.

القاعدة الافتراضية: نهج المجموعة يفوز. السبب معماري: gpsvc جزء عميق من عملية Winlogon، ودورات التحديث كل 90 دقيقة تُعيد كتابة أيّ إعداد كتبه MDM. حتى في 2026، مع كل التحوّل إلى Intune، هذا السلوك يبقى الافتراضي. وسمعت مسؤولين كثر يفترضون العكس ثم يتفاجؤون.

جعل Intune يفوز عبر MDMWinsOverGP

منذ Windows 10 1803 (وطبعاً ويندوز 11)، يمكنك قلب هذه الأسبقية باستخدام CSP الخاص بـ ControlPolicyConflict/MDMWinsOverGP. الطريقة:

1. في Intune Admin Center، أنشئ Configuration Profile جديد من نوع Templates → Custom.
2. أضف OMA-URI التالي:
   ./Device/Vendor/MSFT/Policy/Config/ControlPolicyConflict/MDMWinsOverGP
3. نوع البيانات: Integer، القيمة: 1.
4. عيّن الملف الشخصي على مجموعة الأجهزة الهجينة، ثم انتظر دورة مزامنة Intune.

لكن انتبه للقيود الثلاث: أولاً، MDMWinsOverGP يعمل فقط للسياسات المُدارة عبر Policy CSP. لا يشمل Settings Catalog، ولا سياسات Endpoint Security، ولا PowerShell Scripts. ثانياً، لا يُطبَّق بأثر رجعي؛ السياسات التي طُبّقت قبل تفعيل CSP تبقى مكتوبة بالطبقة السابقة. ثالثاً، بعض الإعدادات (خاصة السياسات القديمة مثل بعض قواعد Firewall) ليست موجودة في Policy CSP أصلاً، وهنا لا خيار سوى إزالة GPO يدوياً.

خارطة الطريق العملية للانتقال

في مؤسستنا اتّبعنا هذا التسلسل، وأنصح به بشدّة:

1. افتح Group Policy Analytics في Intune. يستقبل ملف XML مصدَّر من GPMC ويُخبرك بالنسبة المئوية للسياسات القابلة للترحيل إلى Settings Catalog.
2. ابدأ بمجموعة أجهزة تجريبية (50 جهازاً). فعّل MDMWinsOverGP وراقب gpresult على مدى أسبوع.
3. رحّل السياسات ذات الأولوية (الأمن، التشفير، إعدادات المتصفح) أولاً؛ اترك سياسات تعيين محرّكات الشبكة وسكربتات Logon حتى النهاية (هذه أصعب في Intune).
4. عند اكتمال الترحيل، فكّ ربط GPO من OU (لا تحذف السياسة. أبقها معطّلة كنسخة احتياطية لمدة 30 يوماً على الأقل).

لتفاصيل أعمق عن CSPs المتاحة والقيود التقنية، راجع مرجع Policy CSP – ControlPolicyConflict الرسمي. لمن يديرون Intune يومياً، وثيقة Group Policy Analytics في Microsoft Intune تشرح خطوات الاستيراد وتفسير تقرير التوافق. ودليلنا حول استكشاف أخطاء Microsoft Intune وAutopilot يغطّي الجانب المكمّل من التسجيل والتوافق.

قائمة التحقق النهائية لمكتب المساعدة

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

1. تحقّق من الإصدار: winver. هل الجهاز Windows 11 Pro/Enterprise/Education؟ Home لن يعمل مع GPO المؤسسي.
2. اقرأ RSoP الحالي: gpresult /h C:\Temp\rsop.html /f. افتح التقرير وابحث عن قسم "GPOs were not applied because they were filtered out". هذا 60% من الحل.
3. افحص الشبكة إلى DC: Test-NetConnection -ComputerName <domain> -Port 445 و nslookup <domain>.
4. افحص أحداث GroupPolicy: Event Viewer → System → صفِّ بـ Source = GroupPolicy. ركّز على 1058 / 1030 / 1129 / 7016.
5. افرض التحديث: gpupdate /force. إن فشل بـ "Computer policy could not be updated successfully"، اذهب لخطوة إصلاح Registry.pol.
6. افحص مرشّحات WMI: إن كان الجهاز يُقرأ خارج نطاق سياسة معيّنة رغم عضويته في OU الصحيح، شغّل الاستعلام يدوياً بـ wbemtest وتحقّق من مطابقة رقم البناء.
7. افحص صراع Intune: على الأجهزة الهجينة، افتح Settings → Accounts → Access work or school ثم Info → Sync، ثم شغّل dsregcmd /status للتأكّد من الحالة الهجينة الصحيحة.
8. الملاذ الأخير. إعادة الانضمام للنطاق: بعد فشل كل الخطوات السابقة، فكّ الجهاز من النطاق، أعِد الإقلاع، ثم أعِد ضمّه. هذه الخطوة تُصلح تلف قاعدة بيانات LSA وSecure Channel لكنها تُعيد بناء ملف تعريف المستخدم. نسّق مع المستخدم مسبقاً.

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

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

الأسباب الست الأكثر شيوعاً: إصدار ويندوز غير مدعوم (Home)، انقطاع الاتصال بوحدة تحكم النطاق، تصفية أمان أو مرشّح WMI يستبعد الجهاز، توريث معطّل على وحدة تنظيمية، تلف في Registry.pol، أو صراع أسبقية مع سياسة Intune. شغّل gpresult /h rsop.html لمعرفة السبب المحدّد في أقل من دقيقة.

كيف أفرض تحديث نهج المجموعة على جهاز بعيد؟

استخدم PowerShell Remoting: Invoke-Command -ComputerName WKS-042 -ScriptBlock { gpupdate /force }. للأجهزة المتعدّدة، مرّر مصفوفة أسماء إلى -ComputerName مع -ThrottleLimit. من GPMC يمكنك النقر بزر الفأرة الأيمن على OU واختيار "Group Policy Update" لتحديث كل الأجهزة تحته دفعة واحدة.

ما الفرق بين GPResult وRSOP؟

كلاهما يُنتج بيانات "Resultant Set of Policy". gpresult أداة سطر أوامر تعرض نتائج نصية أو HTML من ذاكرة السياسة المحلية على الجهاز، ومناسب للتشخيص السريع. rsop.msc واجهة رسومية Snap-In تعرض شجرة كاملة للإعدادات (لكنها لا تُظهر Group Policy Preferences). نمذجة GPMC هي الأقوى. تُحاكي سيناريوهات "ماذا لو" دون الحاجة لتوفّر الجهاز.

هل يتجاوز Intune نهج المجموعة تلقائياً؟

لا، الافتراضي عكس ذلك: نهج المجموعة يفوز على Intune عند تعارضهما على نفس الإعداد. لجعل Intune يفوز، فعّل CSP ./Device/Vendor/MSFT/Policy/Config/ControlPolicyConflict/MDMWinsOverGP بقيمة 1 عبر ملف تكوين مخصّص. القيد المهم: هذا يعمل فقط للسياسات المُدارة عبر Policy CSP، لا لكل إعدادات Intune.

ما سبب Event ID 1058 لنهج المجموعة؟

الحدث 1058 يعني أن العميل لم يستطع قراءة ملف gpt.ini من مشاركة SYSVOL. الأسباب الشائعة: تأخير في DFS-R بين وحدات تحكم النطاق، DNS يشير إلى خادم خاطئ، منفذ SMB (445) محجوب على الشبكة، أو صلاحيات NTFS معطوبة على مجلد Policies في SYSVOL. ابدأ بـ Test-NetConnection -Port 445 ثم dfsrdiag ReplicationState.

كيف أعرف أيّ GPO يُطبَّق على مستخدم معيّن؟

شغّل gpresult /r /user CONTOSO\username على جهاز سجّل المستخدم الدخول عليه مؤخراً، أو استخدم Group Policy Modeling Wizard في GPMC لمحاكاة النتائج عن بُعد. سيعرض القسم الأول قائمة "Applied Group Policy Objects" مرتّبة حسب أسبقية التطبيق، والقسم الثاني قائمة السياسات المرفوضة مع سبب الرفض.