Group Policy לא חל על המחשב — מדריך אבחון ותיקון לטכנאי Helpdesk (2026)
כשה-GPO לא חל על המחשב, הבעיה כמעט תמיד ב-SYSVOL, Secure Channel או Security Filtering. מדריך אבחון מעשי עם gpresult, Event Viewer ופקודות PowerShell מוכנות.
אם Group Policy לא חל על המחשב, הסיבה כמעט תמיד אחת מארבע: המחשב לא מגיע ל-SYSVOL של הדומיין, יש בעיית Kerberos או Secure Channel, ה-GPO מסונן החוצה על-ידי Security Filtering או WMI Filter, או שהתוצאה של חישוב ה-Resultant Set of Policy (RSoP) מוסיפה מדיניות אחת שדורסת את השנייה. בעשר שנים של עבודה על שרתי AD, לא נתקלתי כמעט אף פעם במשהו מחוץ לרשימה הזאת. אז בואו נצלול פנימה. המדריך הזה עובר על שלבי האבחון בסדר הנכון, מ-gpresult /r ועד תיקון channel שנשבר, עם פקודות PowerShell מוערות שאפשר להעביר לטכנאי שכבה 1.
gpresult /r /scope:computer היא הפקודה הראשונה שאתם מריצים, לא gpupdate. היא מראה איזה GPO חל, איזה נדחה, ולמה.
גישה ל-\\domain.local\SYSVOL ול-\\domain.local\NETLOGON חייבת לעבוד גם למחשב וגם למשתמש; זו הסיבה הנפוצה ביותר לכשל של Group Policy Processing.
שלושת אירועי ה-Event Viewer שחייבים להכיר: 1058 (לא ניתן לקרוא GPT.INI), 1030 (עיבוד GPO נכשל), 5719 (אין Domain Controller זמין).
אחרי כל שינוי GPO בצד השרת חכו לפחות 5 דקות לרפליקציה של SYSVOL לפני שאתם מריצים gpupdate /force על התחנה.
Loopback Processing במצב Replace דורס את כל מדיניות המשתמש. זו הסיבה הכי נפוצה ל-"למה המשתמש לא מקבל את ההגדרות שלו על השרת".
אם ה-Secure Channel של המחשב שבור (Test-ComputerSecureChannel מחזיר False), שום GPO לא יחול עד שתחדשו אותו או תעשו rejoin לדומיין.
למה Group Policy לא חל על המחשב שלי?
ה-Group Policy הוא לא איזה שירות מיסטי. הוא סתם קליינט (Group Policy Client, gpsvc) שרץ על התחנה, מוריד קבצים מ-\\domain\SYSVOL\Policies ומחיל אותם דרך Client-Side Extensions (CSEs) כמו Registry, Security, Software Installation ו-Preferences. אם משהו באמצע נשבר, המדיניות פשוט לא חלה. הכשלים מתחלקים לחמש משפחות עיקריות שאני רואה חוזרות שוב ושוב אצל טכנאים בשכבה 1:
בעיות רשת/DNS: התחנה לא יודעת מי ה-DC, או מגיעה אליו אבל לא לשיתוף SYSVOL.
Secure Channel שבור: סיסמת חשבון המחשב לא סונכרנה עם AD (קורה אחרי שחזור snapshot או ריסטור מ-image ישן).
סינון GPO: Security Filtering שלא כולל את המחשב/משתמש, או WMI Filter שלא תואם.
סדר עדיפויות / דריסה: GPO אחר עם קדימות גבוהה יותר דורס, או Enforced חוסם Block Inheritance.
שגיאה בתוכן ה-GPO עצמו: CSE נופל, Script לא נמצא, MSI חסר או Preference עם Item-Level Targeting שגוי.
הכלי שהופך את זה מ"נחש והחלף" ל"תשובה" הוא gpresult. בסעיף הבא נריץ אותו נכון. לעומק על שכבת AD שמתחת ל-GPO (DNS, sites, replication), ראו את המדריך המקיף שלנו לפתרון תקלות Active Directory. הרבה מקרי GPO שנראים "משונים" הם למעשה תקלות רפליקציה של AD שמפילות את SYSVOL עם המשקולת.
איך מריצים gpresult /r כדי לראות איזה GPO חל בפועל
gpresult הוא הכלי הכי חשוב באבחון Group Policy, ורוב הטכנאים משתמשים בו לא נכון. הפקודה הבסיסית שאני מעביר לכל טכנאי חדש היא gpresult /r, אבל היא לא מספיקה: היא רצה בהקשר של המשתמש הנוכחי ומחזירה רק תקציר של Computer Configuration אם הרצתם אותה כ-Administrator.
הפקודות שאתם באמת צריכים
# פקודה 1: תקציר של מדיניות שחלה על המחשב הנוכחי
# ורצה כ-Administrator - אחרת לא תראו את חלק ה-Computer
gpresult /r /scope:computer
# פקודה 2: תקציר של המדיניות שחלה על משתמש ספציפי
# מריצים בלי הרשאות מוגברות (או עם /user domain\username)
gpresult /r /scope:user
# פקודה 3: דוח HTML מלא לפתרון בעיות מורכבות
# מייצר קובץ שאפשר להעביר ל-Tier 2 עם כל ה-CSE, WMI Filters ו-RSoP
gpresult /h C:\Temp\gpresult.html /f
# פקודה 4: לבדיקה מרחוק (Remote Desktop לא נדרש)
gpresult /s WORKSTATION-01 /u DOMAIN\svc_admin /p * /h \\fileserver\it\gp_WS01.html /f
מה שמעניין אתכם בדוח ה-HTML הוא הסקציה של Denied GPOs. שם תראו את הסיבה: Access Denied (Security Filtering), Filtering: Denied (WMI), Empty (GPO ריק) או Disabled Link. אם ה-GPO שמצפים שיחול נמצא ברשימת ה-Denied, פתרתם 80% מהחקירה בפקודה אחת.
לקרוא נכון את ה-Applied GPOs
הסדר בדוח לא רנדומלי. GPOs מוצגים בסדר עיבוד: Local, Site, Domain, ואז OU מהחוץ פנימה. GPO שמופיע בסוף הרשימה גובר על מה שמעליו (Last Writer Wins), אלא אם ה-GPO העליון מסומן כ-Enforced. זו הסיבה למקרים שבהם GPO עם Password Length מינימלי 8 "לא עובד". יש GPO אחר שמוגדר עם 6 שנטען אחריו ודורס. הרמתי גבה כמה פעמים על זה בעצמי לפני שהבנתי.
איך מכריחים עדכון Group Policy עם gpupdate /force
המחזור הרגיל של Group Policy מרענן את עצמו כל 90 דקות עם offset אקראי של 0-30 דקות. Domain Controllers מרעננים כל 5 דקות. אם עשיתם שינוי ואתם צריכים אותו עכשיו, הפקודה היא gpupdate /force. חשוב להבין מה ה-/force באמת עושה: היא לא סתם מפעילה עדכון, היא מתעלמת מהסטטוס של "כבר החלנו את זה" ומאלצת את כל ה-Client-Side Extensions לרוץ מחדש.
וריאנטים חשובים של gpupdate
# עדכון רגיל - מחיל רק שינויים חדשים
gpupdate
# עדכון מלא - כל ה-CSE ירוצו מחדש, גם אם לא השתנה כלום
gpupdate /force
# עדכון של מדיניות משתמש בלבד עם logoff אוטומטי אחרי הסיום
# שימושי כשמדיניות משתמש דורשת logoff (Folder Redirection, Drive Maps)
gpupdate /target:user /force /logoff
# עדכון של מדיניות מחשב בלבד עם boot אוטומטי
# שימושי כשמדיניות מחשב דורשת restart (Software Installation, Startup Scripts)
gpupdate /target:computer /force /boot
# חכה עד 300 שניות לתוצאה במקום להיכנס לרקע
gpupdate /force /wait:300
ב-Windows Server 2012 R2 ומעלה יש גם דרך להפעיל gpupdate על תחנות מרוחקות דרך GPMC: קליק ימני על OU, ואז Group Policy Update. תחת המכסה זה מריץ Invoke-GPUpdate:
# עדכון GPO על כל המחשבים ב-OU דרך PowerShell
# דורש RSAT + Windows Firewall Rules פתוחות ל-WMI על היעדים
Get-ADComputer -Filter * -SearchBase "OU=Workstations,DC=corp,DC=local" |
ForEach-Object {
# השהיה אקראית של 0-600 שניות למנוע overload של DC
Invoke-GPUpdate -Computer $_.Name -RandomDelayInMinutes 10 -Force
}
אירועי Event Viewer קריטיים: 1058, 1030, 5719 ו-7017
אחרי gpresult, Event Viewer הוא הבית של האמת. פתחו את Applications and Services Logs → Microsoft → Windows → GroupPolicy → Operational, וגם את System. יש רק ארבעה אירועים שאתם באמת חייבים להכיר בעל-פה כטכנאי Helpdesk. שאר מאות ה-Event IDs של Userenv הם נגזרות של הארבעה האלה.
Event ID 1058: The processing of Group Policy failed. Windows attempted to read the file gpt.ini
המשמעות: התחנה לא הצליחה לגשת לקובץ gpt.ini של GPO ספציפי ב-SYSVOL. הסיבה כמעט תמיד DFSN/DFSR (רפליקציית SYSVOL), הרשאות NTFS על תיקיית ה-GPO, או שהתחנה מדברת עם DC לא נכון. הפקודה הראשונה שאני מריץ:
# בדיקה ידנית של גישה ל-SYSVOL
# החליפו corp.local בשם הדומיין שלכם
dir \\corp.local\SYSVOL\corp.local\Policies
# אם זה נכשל - נסו לגשת ל-DC ספציפי
dir \\dc01.corp.local\SYSVOL\corp.local\Policies
# הקבוצה הנכונה לגישה: Authenticated Users חייבים Read
icacls \\corp.local\SYSVOL\corp.local\Policies\{GUID-of-GPO}
Event ID 1030: The processing of Group Policy failed
הודעה כללית יותר: עיבוד נכשל אבל לא בהכרח בגלל קובץ ספציפי. תראו אותה יחד עם 1058 ברוב המקרים. אם 1030 מופיעה לבד ללא 1058, זה בדרך כלל CSE שהתרסק (בדקו את ה-Description לשם ה-CSE), או Timeout ברשת איטית שדורש להגדיר Group Policy slow link detection.
Event ID 5719: This computer was not able to set up a secure session with a domain controller
Netlogon לא מצא DC. זה כמעט תמיד DNS. הפקודה הבאה מגלה תוך שניות אם התחנה בכלל יודעת איפה ה-DC:
# בדיקה שהתחנה יכולה למצוא DC דרך DNS SRV records
nltest /dsgetdc:corp.local
# אימות המחשב עצמו בדומיין (Secure Channel)
# אם מחזיר False - זו הסיבה שה-GPO לא חל, לא הרשת
Test-ComputerSecureChannel -Verbose
Event ID 7017: Group Policy processing was cancelled
מופיע כשהחיבור לרשת נחשב "Slow Link" (ברירת מחדל: מתחת ל-500 Kbps). Windows יבטל בכוונה עיבוד של CSEs "כבדים" כמו Software Installation, Folder Redirection ו-Scripts. הפתרון: או להגדיל את הסף עם ה-GPO Configure Group Policy slow link detection, או להתאים את ה-CSE להתעלם מסטטוס Slow Link. לעולם לא לכבות את הזיהוי לגמרי, כי משתמשי VPN יקבלו טיימאאוט של 20 דקות ב-logon.
בדיקת גישה ל-SYSVOL ו-NETLOGON, הסיבה הנפוצה מספר 1
SYSVOL היא תיקיית שיתוף שנמצאת על כל DC ב-C:\Windows\SYSVOL\sysvol, והיא הבית של כל קבצי ה-Group Policy (Registry.pol, GPT.INI, סקריפטים). NETLOGON היא תת-תיקייה בה נמצאים סקריפטי Logon ישנים. אם התחנה לא מצליחה לקרוא מהשיתופים האלה, לא חשוב כמה יפה ה-GPO בנוי ב-GPMC, הוא פשוט לא יחול.
רשימת בדיקה של SYSVOL בסדר הנכון
שיתוף קיים על ה-DC?net share ב-DC צריך להראות SYSVOL ו-NETLOGON.
התחנה מצליחה לגשת?dir \\domain\SYSVOL מהתחנה של המשתמש.
הרשאות SMB נכונות? Authenticated Users צריכים Read Share Permissions.
הרשאות NTFS נכונות? Authenticated Users צריכים Read & Execute על התיקיות ותת-התיקיות.
רפליקציה DFSR ירוקה?dfsrdiag ReplicationState /verbose על כל DC.
# אבחון מלא של SYSVOL ב-DC
# הפקודה הראשונה מציגה את סטטוס הרפליקציה
dfsrdiag ReplicationState /verbose
# בדיקה שכל DC רואה את אותה תיקיית Policies
# אמור להחזיר אותו מספר תיקיות בכל DC
Get-ADDomainController -Filter * | ForEach-Object {
$dc = $_.HostName
$count = (Get-ChildItem "\\$dc\SYSVOL\$env:USERDNSDOMAIN\Policies" -Directory).Count
"$dc : $count policies"
}
# הרצת DCDiag שמתמקד ב-SYSVOL
dcdiag /test:SysVolCheck /v
dcdiag /test:NetLogons /v
אם רואים אי-התאמה במספר התיקיות בין DCs שונים, יש בעיית רפליקציה של DFSR. זו לא בעיה של Helpdesk לפתור, אז סמנו טיקט ל-AD Team. אבל אתם יכולים לספק להם את הפלט של dcdiag ולחסוך שעה של אבחון. יש לנו כתבה נפרדת על אבחון רשת ופתרון תקלות שכוללת את הבדיקות הראשוניות של DNS ו-SMB. התחילו שם אם הבעיה לא רק ב-GPO אלא בגישה כללית לשרתים.
שגיאות Kerberos, DNS ו-Secure Channel שגורמות ל-GPO ליפול
Group Policy Client דורש שלושה דברים לפני שהוא בכלל מנסה להוריד GPO: שם DNS תקין של הדומיין, Kerberos ticket תקף למחשב, ו-Secure Channel פתוח. אם אחד משלושת אלה נשבר, שום gpupdate לא יעזור.
אבחון DNS ראשוני
# האם התחנה יודעת מה שם הדומיין שלה?
[System.Net.Dns]::GetHostByName($env:COMPUTERNAME).HostName
# האם ה-SRV records של Kerberos ו-LDAP מגיבים?
nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.local
nslookup -type=SRV _kerberos._tcp.dc._msdcs.corp.local
# מה ה-DC שהתחנה משתמשת בו כרגע?
nltest /dsgetdc:corp.local /force
# בדיקה מקיפה של קליינט הדומיין
nltest /sc_verify:corp.local
Secure Channel שבור, התיקון הכי לא מובן
כשמחשב מתחבר לדומיין, הוא מקבל סיסמת חשבון מחשב שמתחדשת אוטומטית כל 30 יום. אם החזרתם snapshot ישן של VM, או שיחזרתם image מלפני 45 יום, הסיסמה בין ה-AD לתחנה לא תואמת ו-Secure Channel נשבר. כל התסמינים נראים כמו בעיית GPO: הכל נכשל בשקט. הפתרון החדש והנכון (Windows 8 ומעלה):
# בדיקה - אם מחזיר False, זו הסיבה
Test-ComputerSecureChannel
# תיקון בלי להוציא מהדומיין ובלי restart
# חובה להריץ עם חשבון Domain Admin ולציין -Credential
Test-ComputerSecureChannel -Repair -Credential (Get-Credential)
# אלטרנטיבה: איפוס Secure Channel דרך Reset-ComputerMachinePassword
# רלוונטי כשהמחשב עדיין מדבר עם DC אבל הסיסמה השתבשה
Reset-ComputerMachinePassword -Credential (Get-Credential) -Server dc01.corp.local
לעולם לא לעשות Leave Domain + Rejoin לתקלת Secure Channel. זה יוצר חשבון מחשב חדש, שובר את כל ה-Group Policy Preferences שמבוססים על WMI Filter של שם המחשב, ופעמים רבות דורש איפוס BitLocker כי ה-TPM מזהה שינוי בזהות. במקום זה השתמשו ב-Test-ComputerSecureChannel -Repair. אני עצמי חטפתי את הלקח הזה בפרויקט של שיחזור VMware אחרי incident, וזה חינך אותי מהר מאוד. ראו את המדריך שלנו על Windows Update נכשל או תקוע, כי הרבה מקרים של Secure Channel שבור נובעים מ-Windows Update שהחליף Netlogon.dll ולא השלים reboot.
הסקציה הזאת היא איפה שהרבה טכנאי שכבה 2 נכשלים. GPO יכול להיות מקושר ל-OU נכון, להיות Enabled, ולא לחול על אף מחשב, בגלל אחד משלושה מנגנוני סינון. אני עובר עליהם לפי סדר בדיקה במקרה אמיתי.
Security Filtering: מי מותר לו לקרוא את ה-GPO
ברירת המחדל ב-GPMC היא Authenticated Users, קבוצה שכוללת כל משתמש וכל מחשב שהתחבר לדומיין. ב-2016 Microsoft פרסמה עדכון אבטחה (MS16-072) שדרש הרשאת קריאה למחשב, לא רק למשתמש. הרבה GPOs "ישנים" נשברו כי המחשב הוסר מ-Security Filtering אבל נשאר במקום Authenticated Users כ-Read בלבד. הבדיקה:
# מציג את הרשאות Security Filtering של GPO ספציפי
Get-GPPermissions -Name "Corp Password Policy" -All
# תיקון: הוסיפו הרשאת Read למחשבים גם אם הם לא ב-Security Filtering
# הסקריפט הבא מוסיף Domain Computers כ-Read לכל GPO בדומיין
Get-GPO -All | ForEach-Object {
# אם כבר קיימת הרשאה - מדלגים
if (-not (Get-GPPermissions -Guid $_.Id -TargetName "Domain Computers" -TargetType Group -ErrorAction SilentlyContinue)) {
Set-GPPermissions -Guid $_.Id -PermissionLevel GpoRead -TargetName "Domain Computers" -TargetType Group
}
}
WMI Filters: סינון דינמי לפי מאפיינים
WMI Filter יכול לסנן GPO להחלה רק על Windows 11, רק על מחשבים ניידים, רק בקומה שלישית וכו'. הבעיה: אם ה-WMI query שגוי או ה-WMI Repository על התחנה פגום, ה-GPO פשוט לא חל. בדיקה ידנית:
# הריצו את אותו WMI query שה-Filter משתמש בו
# דוגמה: "רק מחשבים ניידים"
Get-CimInstance -Namespace root\CIMv2 -Query "SELECT * FROM Win32_ComputerSystem WHERE PCSystemType = 2"
# דוגמה: "רק Windows 11 22H2 ומעלה"
Get-CimInstance -Namespace root\CIMv2 -Query "SELECT * FROM Win32_OperatingSystem WHERE Version >= '10.0.22621'"
# תיקון WMI Repository פגום - הפקודה הסטנדרטית
# רק אחרי ש-winmgmt /verifyrepository מחזיר inconsistent
winmgmt /salvagerepository
Loopback Processing: הרוצח השקט של Terminal Server
Loopback Processing היא הגדרה שגורמת ל-GPO של Computer Configuration להחיל User Configuration על כל משתמש שמתחבר למחשב. יש שני מצבים: Merge (מוסיף על מדיניות המשתמש הרגילה) ו-Replace (דורס לגמרי). ב-Terminal Server ו-Windows Virtual Desktop זה קריטי, אבל אם שכחתם שהגדרתם את זה, פתאום המשתמשים "לא מקבלים את המיפוי לכונן Z" והתשובה היא ש-Loopback במצב Replace מבטל את כל מדיניות המשתמש מה-OU של המשתמש. תמצאו את זה תחת:
Computer Configuration → Administrative Templates → System → Group Policy → Configure user Group Policy loopback processing mode
עבודה עם Local Group Policy ו-Windows 11 מנותק מדומיין
לא כל מחשב מחובר לדומיין. Kiosks, לפטופים של קבלנים, מכונות בסניפים מרוחקים, כולם מקבלים מדיניות דרך Local Group Policy, ומ-2022 גם דרך Microsoft Intune / Endpoint Management. אם ה-Group Policy Editor הרגיל (gpedit.msc) לא זמין (Windows 11 Home) או שאתם צריכים להחיל מדיניות מרוכזת ללא דומיין, הכלי הוא Microsoft Security Compliance Toolkit ו-LGPO.exe.
ייבוא ויצוא של Local GPO עם LGPO.exe
# ייצוא Local GPO קיים לקובץ backup
# יוצר תיקייה עם Registry.pol, GptTmpl.inf, ואודיט settings
lgpo.exe /b C:\Backup\LocalGPO
# ייבוא Registry.pol שנוצר במחשב אחר
lgpo.exe /m C:\GPOs\Baseline\User\registry.pol
lgpo.exe /m C:\GPOs\Baseline\Machine\registry.pol
# איפוס מוחלט של Local GPO (Windows 10/11)
# מומלץ לפני החלת baseline חדש כדי למנוע קונפליקטים
Remove-Item -Path "$env:WinDir\System32\GroupPolicy" -Recurse -Force
Remove-Item -Path "$env:WinDir\System32\GroupPolicyUsers" -Recurse -Force
gpupdate /force
Windows 11 24H2 ו-Configuration Service Provider (CSP)
Windows 11 24H2 (שיצא באוקטובר 2024 ומגיע עם עדכונים לאורך 2026) הרחיב את התמיכה ב-Policy CSP, מנגנון שמאפשר החלת מדיניות דרך MDM כמו Intune במקום GPO קלאסי. הרבה הגדרות שפעם דרשו Group Policy עכשיו זמינות גם דרך CSP. הפקודה הבאה מציגה את כל ה-CSP המוגדרים על התחנה:
# הצגת כל ה-CSP שהוגדרו על המחשב דרך MDM/Intune
Get-CimInstance -Namespace root\cimv2\mdm\dmmap -ClassName MDM_Policy_Config01_System02
# רשימה מלאה של providers של MDM על המחשב
Get-CimInstance -Namespace root\cimv2\mdm\dmmap -ClassName * | Select-Object CimClass -Unique
לעומק על ההבדל בין Group Policy קלאסי, LGPO ו-CSP ראו את התיעוד הרשמי של Policy CSP. חשוב להבין: אם אותה הגדרה מוגדרת גם דרך GPO וגם דרך MDM CSP, המדיניות של MDM גוברת ברוב המקרים (למעט חריגים ב-Enterprise SKU). זה מסביר למה בסביבות היברידיות "פתאום" ה-GPO לא חל אחרי הרשמה ל-Intune.
שאלות נפוצות
כמה זמן לוקח ל-Group Policy חדש לחול על כל התחנות?
אחרי שינוי GPO ב-GPMC, ה-DC מרפלק את SYSVOL תוך כ-5-15 דקות (תלוי בגודל הדומיין). תחנות עבודה מרעננות מדיניות כל 90 דקות עם offset אקראי של 0-30 דקות, כך שההתייצבות המלאה על הרשת יכולה לקחת עד שעתיים. אם דחוף, השתמשו ב-Invoke-GPUpdate על ה-OU הרלוונטי.
מה ההבדל בין gpupdate ל-gpupdate /force?
gpupdate רגיל מוריד ומחיל רק שינויים חדשים. אם מדיניות לא השתנתה מאז ההחלה האחרונה, ה-CSE לא ירוץ. gpupdate /force מתעלם מסטטוס ה-"כבר יושם" ומריץ מחדש את כל ה-Client-Side Extensions. השתמשו ב-/force רק כשאתם באמת חייבים החלה מיידית, כי הוא צורך יותר משאבים ומעמיס על ה-DC.
למה gpresult /r מחזיר "Access Denied" למרות שאני Administrator?
UAC. חייבים להריץ CMD או PowerShell כ-"Run as Administrator" מפורש כדי לראות את חלק ה-Computer Configuration. חלופה: gpresult /scope:user יעבוד גם ללא הרשאות מוגברות ויציג את מדיניות המשתמש בלבד. לדוח מלא של שני הצדדים השתמשו ב-gpresult /h report.html /f מ-elevated prompt.
איך יודעים איזה GPO קבע מפתח רישום מסוים?
הדרך הקלה: הריצו gpresult /h report.html /f, פתחו את הדוח בדפדפן, וחפשו את שם המפתח או ההגדרה. הדוח מציג עבור כל הגדרה איזה GPO קבע אותה. חלופה מ-command line: gpresult /z מציג את כל השינויים ב-Registry עם שם ה-GPO המקור, אבל הפלט ארוך מאוד.
מה עושים כש-gpupdate /force מחזיר "The Group Policy Client Side Extension was unable to apply"?
ההודעה מציינת CSE ספציפי שנפל. קוראים את ה-Event Viewer תחת GroupPolicy/Operational כדי לזהות איזה. הגורמים הנפוצים: Software Installation CSE שלא מגיע לשרת MSI, Folder Redirection CSE שלא מצליח ליצור תיקייה בשרת קבצים, או Scripts CSE שלא מוצא סקריפט. תיקון: אמתו שהיעד של ה-CSE (share, script, MSI) זמין מהתחנה עם החשבון של המחשב, לא של המשתמש.
האם Microsoft Intune ו-Group Policy יכולים לרוץ יחד?
כן, אבל צריך תכנון. במחשב Hybrid-Joined ששייך גם ל-AD וגם ל-Intune, שתי המדיניות רצות. במקרה של קונפליקט על אותה הגדרה, מ-Windows 10 1809 ואילך ברירת המחדל היא ש-MDM (Intune) גובר על GPO, אלא אם מפעילים את ה-Policy CSP של MDMWinsOverGP להיפך. תכננו: או שהגדרה מוגדרת רק ב-GPO, או רק ב-Intune, לעולם לא בשניהם.
מדריך מעשי לפתרון התקלות הנפוצות ביותר ב-Active Directory: נעילות חשבונות, DNS, GPO ושכפול. כולל פקודות PowerShell, טבלת תקלות מהירה, ושינויי Entra ID הקריטיים של 2026.
