Group Policy בפועל — איך זה עובד, אישור apply, ובחירה בין GPO ל-Intune

“ההגדרה הזאת מופצת דרך GPO”, “המחשבים אצל הלקוח נעולים ב-Group Policy” — כל מי שעובד עם מערכות עסקיות ב-Windows שומע את המילה “GPO” כל הזמן. אבל כשמגיע הרגע לקחת על עצמכם את ניהול AD, או לפרוס אפליקציה במחשב domain-joined אצל לקוח, מפתיע כמה מעטים יכולים להסביר במדויק מתי, מאיפה, ובאיזה סדר עדיפות Group Policy חלה.

“שיניתי את ההגדרה, והיא לא נכנסה לתוקף”, “אמרו לי להריץ gpupdate אבל אני לא יודע מה זה באמת עושה”, “האפליקציה עובדת במכונת הפיתוח ולא אצל הלקוח, והתברר שזו הייתה GPO” — המאמר הזה מיועד למפתחי אפליקציות עסקיות שנתקלים במצבים האלה, ולאנשי IT בעסקים קטנים ובינוניים שירשו ניהול AD. הוא מסדר איך Group Policy עובדת (סדר ה-apply LSDOU), מתי היא חלה, איך מאבחנים עם gpresult ועם Event Log, ADMX וה-Central Store, ואיך בוחרים בין GPO ל-Intune (MDM), על בסיס מקורות ראשוניים נכון לאוגוסט 2026.

1. קודם כל, המסקנות

• Group Policy היא “האחרון מנצח”. היא מעובדת בסדר Local → Site → Domain → OU (LSDOU), ו-GPO שמעובדת מאוחר יותר מקבלת עדיפות בהתנגשות. ה-GPO המקומית (gpedit.msc) היא השכבה החלשה ביותר.¹
• תזמון ה-apply הוא “foreground ועוד background”. Computer Configuration חלה תמיד ב-startup ו-User Configuration תמיד ב-logon; ומעליהן, כברירת מחדל יש background refresh בערך כל 90 דקות ועוד היסט אקראי של 0-30 דקות (5 דקות ב-domain controllers).²
• gpupdate /force “מחיל מחדש כל הגדרה” — זה אינו תרופת-פלא. חלק מההגדרות, כמו software installation ו-Folder Redirection, מעובדות רק ב-logon או ב-restart (וזו בדיוק הסיבה שקיימות האפשרויות /logoff ו-/boot).³
• נקודת הפתיחה לאבחון היא דוח RSoP מ-gpresult /h. הוא מציג גם את ה-GPO שהוחלו וגם את אלה שנדחו, עם סיבות. לחפירה עמוקה יותר משתמשים ב-Operational log של GroupPolicy (Microsoft-Windows-GroupPolicy/Operational).⁴⁵
• ככלל, מדיניות Administrative Templates נכתבת למפתחות המדיניות הייעודיים ב-Registry (Software\Policies וכדומה). ערך המדיניות מקבל עדיפות על ההגדרה של האפליקציה עצמה, ו-Not Configured לא כותב דבר. עם זאת, יש מדיניות שכותבת מחוץ למפתחות הייעודיים (פרק 5).⁶
• ה-Central Store של ADMX הוא תיקיית PolicyDefinitions ב-SYSVOL. ברגע שיוצרים אותה, GPMC מתחיל להפנות להגדרות התבניות המשותפות ל-domain משם.⁷
• בחירה בין GPO ל-Intune לפי תשתית הזהות של המכשיר. הגדרת אותה הגדרה בשניהם לא מבטיחה תוצאה. Group Policy analytics יכול לעזור כששוקלים migration.⁸⁹
• למפתחים, GPO היא סיבה קלאסית לכך שאפליקציה “נכשלת רק אצל הלקוח”. הגדרות שמשנות את הנחות האפליקציה — Execution Policy, כיבוי Merge local rules ב-Firewall, תצורת proxy וכוננים ועוד — מופצות בניהול מרכזי.¹⁰¹¹

ב-diagram, solid line מציינת relation שתמיד מתקיים ו-dashed line מציינת relation מותנה (התנאים מופיעים בהסבר של כל relation ב-detail page). הרשימה המלאה של ה-relations (סה”כ 29, כולל evidence ו-certainty) וההגדרות של ה-concepts המרכזיים נמצאות ב-detail page של ה-knowledge map (ביפנית). Data: JSON-LD / Turtle

2. מהי Group Policy —‏ GPO מקומית ו-GPO domain

Group Policy היא מנגנון שמאפשר למנהל להגדיר באופן מרכזי הגדרות Windows ולאכוף אותן על מחשבים ומשתמשים יעד. חבילת הגדרות נקראת GPO (Group Policy Object). ל-GPO יש שני מקומות אפשריים.

מחשב workgroup (שאינו domain-joined) מעבד רק את ה-GPO המקומית.¹ לכן בפועל, כשאומרים שמכונה “מנוהלת ב-GPO”, כמעט תמיד מתכוונים ל-GPO domain.

flowchart TB
    accTitle: GPO שמעבדים מחשב workgroup ומחשב domain-joined
    accDescr: מחשב workgroup מעבד רק GPO מקומית, ואילו מחשב domain-joined מעבד בנוסף GPO domain שמופצת מ-Active Directory
    pc{"מהי צורת ה-join של המחשב?"}
    pc -->|workgroup| wg["מעבד רק GPO מקומית"]
    pc -->|domain-joined| dom["GPO מקומית+GPO domain"]
    dom -.-> note["בפועל כמעט כל GPO היא GPO domain"]

איור 1: מחשב workgroup מעבד רק GPO מקומית, ומחשב domain-joined מעבד גם GPO domain.

בכל GPO, התוכן מתחלק בגדול לשתי מערכות.

• Computer Configuration: הגדרות שחלות על כל מי שנכנס למחשב הזה. חלות ב-startup.
• User Configuration: הגדרות שחלות על המשתמש הזה בלי קשר לאיזה מחשב הוא נכנס אליו. חלות ב-logon.

הציר הזה — “האם ההגדרה קשורה למחשב או לאדם” — חוזר באופן עקבי גם בסדר ה-apply וגם באישור שהיא נכנסה לתוקף, בהמשך המאמר. יש פריטים שקיימים בשתי התצורות, לכן כדאי להפוך להרגל תמיד לבדוק את שני הענפים כשמחפשים הגדרה.

flowchart TB
    accTitle: שתי המערכות בתוכן של GPO
    accDescr: לכל GPO יש שתי מערכות, Computer Configuration ו-User Configuration; Computer Configuration חלה ב-startup ומשפיעה על כל מי שנכנס למחשב, ו-User Configuration חלה ב-logon ומשפיעה על המשתמש הזה בכל מחשב שהוא נכנס אליו
    gpo["תוכן ה-GPO"] --> comp["Computer Configuration"]
    gpo --> user["User Configuration"]
    comp --> boot["חלה ב-startup"]
    user --> logon["חלה ב-logon"]
    boot -.-> anyone["חל על כל מי שנכנס"]
    logon -.-> anypc["חל בכל מחשב"]

איור 2: ל-GPO יש שתי מערכות: Computer Configuration הקשורה למחשב, ו-User Configuration הקשורה לאדם.

3. איך ה-apply עובד — “האחרון מנצח” של LSDOU ושליטה בירושה

3.1. LSDOU: Local → Site → Domain → OU

במחשב domain-joined, GPO מעובדות בסדר הבא.¹

1. GPO מקומית
2. GPO שמקושרות ל-Site
3. GPO שמקושרות ל-Domain
4. GPO שמקושרות ל-OU (organizational unit) — מעובדות מה-OU העליונה כלפי מטה, כש-GPO של ה-OU שאליה המחשב/המשתמש היעד שייך ישירות מעובדת אחרונה

ראשי התיבות נותנים לסדר את שמו, LSDOU. הנקודה החשובה היא שזה אינו “העדיפות הגבוהה ביותר קודם” אלא סדר העיבוד. כשכמה GPO מגדירות את אותה הגדרה, זו שמעובדת מאוחר יותר מנצחת (הגדרות שאינן מתנגשות פשוט מתווספות זו לזו).¹ כלומר, ה-GPO של ה-OU הקרובה ביותר ליעד היא החזקה ביותר, וה-GPO המקומית היא החלשה ביותר. “תיקנתי ב-gpedit.msc וזה חזר” אינו תקלה — זה המפרט שעובד בדיוק כמתוכנן.

flowchart TB
    accTitle: סדר העיבוד של LSDOU והאחרון מנצח
    accDescr: GPO מעובדות בסדר Local, Site, Domain ו-OU, ובהתנגשות מנצחת ה-GPO שעובדה מאוחר יותר, לכן GPO של ה-OU הקרובה ליעד היא החזקה ביותר ו-GPO מקומית היא החלשה ביותר
    l["1. GPO מקומית"] --> s["2. Site"]
    s --> d["3. Domain"]
    d --> ou["4. OU (מלמעלה למטה)"]
    ou --> win["בהתנגשות האחרון מנצח"]
    win -.-> strongest["GPO של ה-OU הקרובה היא החזקה"]
    win -.-> weakest["GPO מקומית היא החלשה"]

איור 3: LSDOU הוא סדר העיבוד, וכשאותה הגדרה מתנגשת מנצחת ה-GPO שעובדה מאוחר יותר.

כשכמה GPO מקושרות לאותו Site, Domain או OU, העדיפות ביניהן נקבעת לפי סדר הקישור בלשונית Linked Group Policy Objects ב-GPMC. ה-GPO עם מספר סדר הקישור הנמוך ביותר מעובדת אחרונה ומקבלת את העדיפות הגבוהה ביותר.¹

flowchart TB
    accTitle: סדר קישור כשיש כמה GPO באותו מקום
    accDescr: כשכמה GPO מקושרות לאותו Site, Domain או OU, סדר העיבוד נקבע לפי סדר הקישור ב-GPMC, וה-GPO עם המספר הקטן ביותר מעובדת אחרונה ומקבלת את העדיפות הגבוהה ביותר
    multi["כמה GPO באותו מקום"] --> tab["נקבע לפי סדר קישור ב-GPMC"]
    tab --> last["GPO עם המספר הקטן ביותר מעובדת אחרונה"]
    last --> win["מנצחת כי עובדה אחרונה"]

איור 4: באותו יעד קישור, ה-GPO עם מספר סדר הקישור הקטן ביותר מעובדת אחרונה ומנצחת.

3.2. Block Inheritance ו-Enforced

אפשר ליצור חריגות לסדר ברירת המחדל.¹

• Block Inheritance: מוגדרת על Domain או OU, ועוצרת ירושה של GPO מלמעלה. זה הכלי ל-“ה-OU הזאת לא צריכה לקבל את הסטנדרט הארגוני”.
• Enforced (לשעבר No Override): מוגדרת על קישור של GPO, וגורמת ל-GPO הזאת לחול תמיד, גם אם רמה למטה הגדירה Block Inheritance, והיא כבר לא ניתנת לדריסה על ידי GPO נמוכה יותר. כש-Block Inheritance ו-Enforced מתנגשות, Enforced מנצחת.¹

flowchart TB
    accTitle: הקשר בין Block Inheritance ל-Enforced
    accDescr: Block Inheritance עוצרת ירושה של GPO מלמעלה, אבל GPO שנכפתה חלה תמיד גם אם למטה חסמו ירושה, ואינה נדרסת על ידי GPO נמוכה יותר
    upper["GPO מלמעלה"] --> blocked{"Block Inheritance למטה?"}
    blocked -->|לא| inherit["ירושה כרגיל"]
    blocked -->|כן| enforced{"יש Enforced על ה-GPO?"}
    enforced -->|לא| stop["הירושה נעצרת"]
    enforced -->|כן| apply["חלה בכל מקרה"]
    apply -.-> noover["לא נדרסת על ידי GPO למטה"]

איור 5: Block Inheritance עוצרת ירושה מלמעלה, אבל GPO שנכפתה חוצה את החסימה וחלה תמיד.

Enforced היא מנגנון ששובר את עקרון “האחרון מנצח”, לכן שימוש יתר אומר שיותר ויותר תוצאות בקריאת RSoP ירגישו מנוגדות לאינטואיציה. הפרקטיקה המקובלת היא לשמור אותה להגדרות אבטחה שהארגון כולו חייב לקיים.

3.3. Security filtering

מעבר למיקום הקישור, אפשר גם לצמצם על מי GPO חלה, לכל GPO. כדי ש-GPO תחול, למשתמש או למחשב היעד חייבות להיות גם הרשאת Read וגם Apply Group Policy על אותה GPO. כברירת מחדל שתיהן ניתנות ל-Authenticated Users (שכוללת גם משתמשים וגם מחשבים), כך שה-GPO חלה על כולם תחת יעד הקישור. Security filtering הוא הדרך לצמצם את זה לקבוצות אבטחה ספציפיות. הסינון פועל על ה-GPO כולה; אי אפשר לשנות אותו לפי הגדרה בתוך ה-GPO.¹³

יש הסתייגות חשובה אחת. כשמצמצמים את ההיקף, אל תסירו גם Read מ-Authenticated Users שבברירת המחדל. מאז עדכון האבטחה MS16-072 (2016), מדיניות משתמש נשלפת בהקשר האבטחה של המחשב, כך שאם חשבון המחשב לא יכול לקרוא את ה-GPO, GPO שמיועדת למשתמש לא תחול גם אם למשתמש היעד יש את שתי ההרשאות.¹⁴ הדרך הנכונה לצמצם היקף היא לתת “Read + Apply Group Policy” לקבוצת היעד, ולהשאיר רק Read ל-Authenticated Users (או Domain Computers).¹⁴

flowchart TB
    accTitle: החלטת ה-apply של security filtering
    accDescr: כדי ש-GPO תחול, למשתמש או למחשב היעד חייבות להיות גם הרשאת Read וגם Apply Group Policy, וב-GPO למשתמש נדרש בנוסף שחשבון המחשב יוכל לקרוא
    target["יעד תחת קישור ה-GPO"] --> perm{"גם Read וגם Apply?"}
    perm -->|לא| deny["נדחה בסינון"]
    perm -->|כן| usergpo{"GPO למשתמש?"}
    usergpo -->|לא| apply["חלה"]
    usergpo -->|כן| comp{"המחשב יכול לקרוא?"}
    comp -->|כן| apply
    comp -->|לא| deny2["לא חלה (MS16-072)"]

איור 6: ל-apply נדרשות גם Read וגם Apply Group Policy, וב-GPO למשתמש נדרשת גם קריאה של חשבון המחשב.

בפועל, שתי המעידות הקלאסיות הן “הוספתי לקבוצה ועדיין לא חל (זו הגדרה למחשב, אבל הוספתי רק את המשתמש לקבוצה)” ו”הוצאתי מהקבוצה וזה ממשיך לחול”. האחרונה לא תיפתר גם אם מחכים ל-background refresh. חברות בקבוצה מוערכת לפי access token שנוצר ב-logon, כך ששינוי קבוצה של משתמש מגיע לסינון רק אחרי מחזור logoff/logon, ושינוי קבוצה של מחשב רק אחרי restart — ברגע ש-token חדש הונפק.

flowchart TB
    accTitle: עד ששינוי קבוצה משתקף בסינון
    accDescr: חברות בקבוצה מוערכת לפי access token שנוצר ב-logon, לכן שינוי של משתמש דורש logon מחדש ושינוי של מחשב דורש restart עד שה-token החדש משתקף בסינון
    change["משנים חבר בקבוצה"] --> old["עם token ישן זה לא משתקף"]
    old --> u["משתמש: logon מחדש"]
    old --> c["מחשב: restart"]
    u --> token["הערכה ב-token חדש"]
    c --> token
    token --> ok["משתקף בסינון"]
    old -.-> bg["background refresh לא פותר"]

איור 7: שינוי קבוצה משתקף בסינון רק אחרי ש-logoff או restart יוצרים token חדש.

יש גם מצב מיוחד שנקרא loopback processing, למצבים כמו מחשבים משותפים או שרתי Remote Desktop, שבהם רוצים שכל מי שנכנס למחשב הזה יקבל User Configuration מוחלפת (מנגנון שמחיל הגדרות משתמש לפי מיקום המחשב, עם מצבי Replace ו-Merge).¹⁵ זו תכונה מתקדמת שמשתמשים בה במכונות kiosk ובמחשבי כיתה, לכן המאמר הזה רק מציין שהיא קיימת.

flowchart TB
    accTitle: הרעיון של loopback processing
    accDescr: Loopback processing הוא מצב מיוחד שמחיל User Configuration לפי מיקום המחשב, עם שני מצבים של Replace ו-Merge, ומשמש במחשבים משותפים וב-kiosks כשרוצים שאותן הגדרות משתמש יחולו על כל מי שנכנס
    shared["מחשב משותף / kiosk וכו'"] --> lb["loopback processing"]
    lb --> base["נקבע לפי מיקום המחשב"]
    base --> rep["מצב Replace"]
    base --> mrg["מצב Merge"]
    lb -.-> aim["חל על כל מי שנכנס"]

איור 8: Loopback processing הוא מצב מיוחד שמחיל User Configuration לפי מיקום המחשב, עם שני מצבים של Replace ו-Merge.

4. מתי ההגדרות חלות — foreground processing ו-background refresh

מחצית מ”הגדרתי וזה לא נכנס לתוקף” היא פשוט שתזמון ה-apply עוד לא הגיע. יש שני סוגי apply.²

כלומר, במכשיר פעיל שיכול להגיע ל-domain controller, הגדרות שתומכות ב-background refresh יתגלגלו תוך בערך שעתיים אחרי ששיניתם את ה-GPO, בלי פעולה נוספת. מכשירים offline, או מחשבים ניידים שהוצאו מהאתר בלי חיבור VPN, לא יקבלו אותה עד הפעם הבאה שהם מגיעים ל-DC. הגדרות שחלות רק דרך foreground processing יצטרכו בנוסף לחכות ל-startup או ל-logon. אם ממהרים, מריצים gpupdate במחשב היעד. כברירת מחדל חלות רק הגדרות שהשתנו; הוספת /force מחילה מחדש כל הגדרה, בלי קשר לשאלה אם היא השתנתה.³

rem עדכון רק של ההגדרות שהשתנו (בדרך כלל מספיק)
gpupdate

rem החלת כל הגדרה מחדש (כשחושדים במצב במטמון)
gpupdate /force

flowchart TB
    accTitle: האם אפשר להגיע ל-DC ואיך ה-apply מגיע
    accDescr: למכשיר פעיל שיכול להגיע ל-domain controller, הגדרות שתומכות ב-background refresh מגיעות תוך כשעתיים, אבל למחשב offline או נייד בלי VPN הן לא מגיעות עד החיבור הבא ל-DC
    pc{"אפשר להגיע ל-DC?"}
    pc -->|כן| ok["מגיע תוך כשעתיים"]
    pc -->|לא| ng["לא מגיע עד החיבור"]
    ng -.-> ex["מחשב offline או נייד בלי VPN"]

איור 9: למכשיר פעיל שיכול להגיע ל-DC ההגדרות מגיעות תוך כשעתיים, אבל למכשיר offline הן לא מגיעות עד החיבור הבא ל-DC.

הדבר שצריך לשים לב אליו הוא שיש הגדרות שפשוט לא נכנסות לתוקף דרך gpupdate. Software installation שמיועדת למשתמש ו-Folder Redirection מעובדות רק ב-logon, ו-software installation שמיועדת למחשב רק ב-startup. gpupdate מספק בדיוק בשביל זה את האפשרויות /logoff (logoff אחרי העדכון) ו-/boot (restart אחרי העדכון).³ לפני שמתלוננים ש”הרצתי gpupdate /force ועדיין לא נכנס”, בודקים אם ההגדרה שייכת לסוג שדורש restart או logon.

flowchart TB
    accTitle: הנתיבים שבהם הגדרה נכנסת לתוקף
    accDescr: שינוי GPO מגיע בהגדרות שתומכות ב-background refresh כברירת מחדל כ-90 דקות ועוד היסט 0-30, והגדרות שחלות רק ב-foreground processing ממתינות ל-startup או ל-logon, וגם gpupdate דחוף דורש /logoff או /boot להגדרות foreground
    change["משנים GPO"] --> kind{"תומך ב-background refresh?"}
    kind -->|כן| bg["כ-90 דק'+0-30 לרענון"]
    kind -->|לא| fg["חלה ב-startup / logon"]
    bg --> done["משתקף"]
    fg --> done
    rush["כשצריך מהר"] -.-> upd["מריצים gpupdate"]
    upd -.-> force["/force מחיל מחדש הכול"]
    upd -.-> reboot["foreground דורש /logoff או /boot"]

איור 10: Background refresh מגיע רק להגדרות שתומכות בו, והגדרות שחלות רק ב-foreground processing דורשות logoff או restart גם אחרי gpupdate.

5. אבחון הגדרה שלא חלה — gpresult, Event Log וה-Registry

5.1. בדיקת RSoP עם gpresult /h

gpresult הוא הכלי הסטנדרטי לבדיקת התוצאה הסופית (RSoP: Resultant Set of Policy) אחרי שכמה GPO נערמו זו על זו. הפקת דוח HTML משורת פקודה elevated היא הגישה הקריאה ביותר.⁴⁵

rem הפקת דוח HTML של RSoP למשתמש ולמחשב
gpresult /h C:\temp\gp-report.html /f

rem לבדיקת תקציר בלבד במסוף
gpresult /r
gpresult /scope computer /r

שלושת הדברים הראשונים לבדוק בדוח הם:

1. רשימת Applied GPOs — האם ה-GPO שאתם מחפשים נמצאת שם?
2. רשימת Denied GPOs, עם סיבות — סיבות לאי-החלה, כמו security filtering, WMI filter, או GPO ריקה, מוצגות כאן⁵
3. “Winning GPO” לכל הגדרה — ערך של איזו GPO קבע את ההגדרה שאתם מחפשים. אם GPO אחרת מנצחת, חוזרים ושוקלים מחדש את כללי העדיפות בפרק 3

flowchart TB
    accTitle: שלושת הדברים הראשונים בדוח RSoP
    accDescr: בדוח gpresult קודם בודקים אם ה-GPO המבוקשת ברשימת Applied GPOs, אחר כך מאשרים את רשימת Denied GPOs והסיבות, ולבסוף מזהים לפי Winning GPO לכל הגדרה איזה ערך ניצח
    rep["פותחים דוח RSoP"] --> one["1. רשימת Applied GPOs"]
    one --> two["2. Denied GPOs והסיבה"]
    two --> three["3. Winning GPO לכל הגדרה"]
    three -.-> review["אם GPO אחרת מנצחת — בודקים מחדש"]

איור 11: בדוח RSoP מסתכלים בסדר הזה: Applied GPOs, Denied GPOs והסיבה, ואז Winning GPO לכל הגדרה.

5.2. Operational log של GroupPolicy

כש-gpresult אינו מספיק — למשל העיבוד נכשל לגמרי, או שהוא לוקח יותר מדי זמן — מסתכלים ב-Operational log של GroupPolicy ב-Event Viewer. המיקום הוא “Applications and Services Logs > Microsoft > Windows > GroupPolicy > Operational” (שם היומן Microsoft-Windows-GroupPolicy/Operational). כאן נרשם כל טווח עיבוד המדיניות, מההתחלה עד הסוף, יחד עם רשימת ה-GPO שהוחלו ורשימת ה-GPO שנדחו (עם סיבות). לכל מחזור עיבוד מדיניות מוקצה ActivityID ייחודי, לכן ההליך ש-Microsoft ממליצה עליו הוא לאסוף את ה-ActivityID מ-event אזהרה או שגיאה ב-System log, ואז להשתמש ב-Custom View כדי לצמצם רק לאותו מופע.⁵

flowchart TB
    accTitle: הליך הצמצום של Operational log של GroupPolicy
    accDescr: ב-Operational log של GroupPolicy מוקצה ActivityID ייחודי לכל מחזור עיבוד מדיניות, לכן אוספים את ה-ActivityID מאזהרה או שגיאה ב-System log ומצמצמים ב-Custom View רק לאירועי אותו מחזור
    sys["אזהרה / שגיאה ב-System log"] --> aid["אוספים ActivityID"]
    aid --> cv["מצמצמים ב-Custom View"]
    cv --> one["קוראים אירועי מחזור אחד"]
    one -.-> rec["רשימת apply ודחייה עם סיבות"]

איור 12: ב-Operational log אוספים ActivityID מ-System log, ומצמצמים ב-Custom View למחזור עיבוד מדיניות אחד.

5.3. הקשר למפתח Policies ב-Registry

מדיניות Administrative Templates (הפרק הבא) נכתבת בסופו של דבר כערכי Registry. ככלל, היא נכתבת למפתחות המדיניות הייעודיים הבאים.⁶

• HKEY_LOCAL_MACHINE\Software\Policies (Computer Configuration; המיקום המומלץ)
• HKEY_CURRENT_USER\Software\Policies (User Configuration; המיקום המומלץ)
• HKLM\Software\Microsoft\Windows\CurrentVersion\Policies / HKCU\Software\Microsoft\Windows\CurrentVersion\Policies

פועל כאן עקרון תכנון חשוב. אפליקציה שמודעת למדיניות מתנהגת כך: קודם קוראת את מפתח Policies; אם יש שם ערך הוא מקבל עדיפות; אם לא, האפליקציה חוזרת להגדרה שלה עצמה (preference) או לברירת המחדל. מדיניות Not Configured לא כותבת דבר ל-Registry.⁶ כלומר, מדיניות Administrative Templates אינה דורסת את ההגדרה של האפליקציה עצמה ומשאירה “tattooing” — במקום זאת, ערך כפוי שנשמר במקום נפרד נקרא בעדיפות. מפסיקים להגדיר את המדיניות, והאפליקציה חוזרת לציית לערך ההגדרה שלה.

flowchart TB
    accTitle: יחס העדיפות בין ערך מדיניות להגדרת האפליקציה
    accDescr: אפליקציה שמודעת למדיניות קודם קוראת את מפתח Policies ואם יש ערך נותנת לו עדיפות, ואם אין משתמשת בהגדרה שלה או בברירת מחדל, ומדיניות Not Configured לא כותבת דבר ל-Registry
    app["אפליקציה מודעת-מדיניות קוראת הגדרה"] --> haspol{"יש ערך במפתח Policies?"}
    haspol -->|כן| pol["ערך המדיניות מקבל עדיפות"]
    haspol -->|לא| pref["משתמשים בהגדרה עצמית או ברירת מחדל"]
    notconf["מדיניות Not Configured"] -.-> nowrite["לא כותבים דבר ב-Registry"]

איור 13: מדיניות אינה דורסת את ההגדרה של האפליקציה עצמה, אלא ערך כפוי במקום נפרד נקרא בעדיפות.

עם זאת, לא כל מדיניות כותבת למפתח ייעודי. חלק מהגדרות מערכת ההפעלה המובנות (למשל “Enable Win32 long paths” כותבת ל-LongPathsEnabled תחת HKLM\SYSTEM\CurrentControlSet\Control\FileSystem), יחד עם תבניות מדור ישן או מצד שלישי, כותבות לנתיבים שרירותיים מחוץ למפתחות הייעודיים. בהגדרות כאלה הערך נשאר גם אחרי שמפסיקים להגדיר את המדיניות. בודקים את הגדרת ה-ADMX, את טקסט התיאור של ההגדרה, או את דוח gpresult כדי לראות לאיזה מפתח הגדרה נתונה באמת כותבת.

במילים אחרות, התכנון המנומס שתואר למעלה מחזיק רק בגבול Administrative Templates (מפתחות המדיניות הייעודיים). ערכים שסקריפטים או Group Policy Preferences כותבים מחוץ למפתח Policies מתנהגים כמו ערכי Registry רגילים, ולמסגרת הזאת אין מנגנון שמחזיר אותם אוטומטית ברגע שמפסיקים להפיץ אותם. בפועל, באבחון, הגישה המהירה והאמינה ביותר היא להסתכל ישירות אם ההגדרה שאתם מחפשים כתובה תחת מפתח 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: קודם מאשרים בדוח RSoP של gpresult אילו GPO הוחלו ואילו נדחו, ואם זה לא מספיק מצמצמים את Operational log של GroupPolicy לפי ActivityID, ואת הערך בפועל שמופץ בודקים ישירות במפתח Policies ב-Registry
    start["ההגדרה לא חלה"] --> rsop["מאשרים RSoP עם gpresult /h"]
    rsop --> found{"ברורות סיבות ה-apply והדחייה?"}
    found -->|כן| fix["בודקים מחדש עדיפות או סינון"]
    found -->|לא| oplog["מסתכלים ב-Operational log של GroupPolicy"]
    oplog -.-> aid["מצמצמים למחזור אחד לפי ActivityID"]
    rsop -.-> reg["בודקים ישירות ערך במפתח Policies"]

איור 14: האבחון מתחיל ב-gpresult /h, ואם זה לא מספיק ממשיכים ל-Operational log של GroupPolicy ולבדיקה ישירה של הערך במפתח Policies.

6. Administrative Templates (ADMX) וה-Central Store

ההגדרות שמאחורי הפריטים שמופיעים תחת Administrative Templates ב-GPMC כתובות כקבצי ADMX (גוף ההגדרה) ועוד קבצי ADML (מחרוזות התצוגה לכל שפה). לכל מחשב יש את ההגדרות שמגיעות עם מערכת ההפעלה תחת C:\Windows\PolicyDefinitions, וכלי הניהול טוענים אותן כדי לבנות את מסך ההגדרות.⁷

אם מפעילים בתוך domain, המהלך הבסיסי הוא ליצור Central Store. יוצרים תיקיית PolicyDefinitions תחת ה-SYSVOL של domain controller (למשל \\contoso.com\SYSVOL\contoso.com\policies\PolicyDefinitions), והתוכן שלה משוכפל לכל domain controller ב-domain; כלי Group Policy אז מפנים ל-Central Store כברירת מחדל.⁷ זה מבטל את הבעיה שבה “גרסת התבנית שונה מתחנת ניהול אחת לאחרת, וההגדרות הנראות לא תואמות”. קבצי ADML הולכים לתת-תיקיות לפי שפה (he-IL לעברית).⁷

flowchart TB
    accTitle: איך ה-Central Store עובד
    accDescr: כשיוצרים תיקיית PolicyDefinitions תחת SYSVOL של domain controller התוכן משוכפל לכל domain controllers, וכלי Group Policy מפנים ל-Central Store כברירת מחדל כך שהגדרות שונות בין תחנות ניהול נעלמות
    create["יוצרים תחת SYSVOL"] --> cs["PolicyDefinitions"]
    cs --> repl["משוכפל לכל ה-DC"]
    cs --> ref["כלי GP מפנים אליו כברירת מחדל"]
    ref -.-> benefit["הגדרות שונות בין תחנות נעלמות"]
    cs -.-> adml["ADML לתיקיות לפי שפה"]

איור 15: PolicyDefinitions ב-SYSVOL משוכפל לכל domain controllers, וכלי Group Policy מפנים אליו כברירת מחדל.

יש שתי הסתייגויות תפעוליות. ראשית, Microsoft מפיצה קבצי ADMX חדשים לכל גרסת Windows חדשה, וכשמעדכנים מחליפים את צד ה-Central Store. החלפת C:\Windows\PolicyDefinitions בכל מחשב בנפרד בגרסה שהורדתם אינה נתמכת.⁷ שנית, כשמעדכנים Central Store קיים, ההנחיה היא לא לדרוס את PolicyDefinitions של production ישירות. במקום זאת מרכיבים את סט ה-ADMX המלא — גם למערכת ההפעלה וגם לאפליקציות כמו Office ו-Edge — בתיקיית עבודה בשם גרסה כמו PolicyDefinitions-24H2, משנים את שם התיקייה הנוכחית הצידה למשהו כמו PolicyDefinitions-23H2, ואז משנים את שם תיקיית העבודה ל-PolicyDefinitions כדי לקדם אותה ל-production.⁷ כלי Group Policy מפנים רק לתיקייה ששמה המילולי הוא PolicyDefinitions, כך שפשוט לשים קבצים בתיקייה בשם גרסה אין לו השפעה. היתרון של הגישה הזאת הוא שאם מתעוררת בעיה, אפשר לחזור לתיקייה ששמרתם בצד.⁷

flowchart TB
    accTitle: הליך עדכון ה-Central Store
    accDescr: בעדכון מרכיבים את סט ה-ADMX המלא של מערכת ההפעלה והאפליקציות בתיקיית עבודה בשם גרסה, משנים את שם התיקייה הנוכחית ושומרים אותה בצד, ואז משנים את שם תיקיית העבודה לשם production PolicyDefinitions, ואם יש בעיה חוזרים לתיקייה הישנה
    work["תיקיית עבודה בשם גרסה"] --> gather["אוספים OS ואפליקציות"]
    gather --> evac["משנים שם ושומרים את הנוכחית"]
    evac --> rename["משנים את תיקיית העבודה לשם production"]
    rename --> live["מפנים אליה כ-production"]
    live -.-> back["בבעיה חוזרים לתיקייה הישנה"]

איור 16: בעדכון מרכיבים את הסט בתיקיית עבודה, שומרים את הנוכחית בצד, ואז מקדמים ל-production בשינוי שם.

7. GPO מול Intune (MDM/CSP) מול פריסה ידנית/בסקריפט — טבלת החלטה

GPO כבר אינה האפשרות היחידה לניהול תצורת מכשירי Windows. MDM, ש-Intune מייצגת אותה, מגדירה הגדרות מערכת הפעלה דרך מנגנון שנקרא CSP (Configuration Service Provider). הנה טבלת החלטה סביב איזו מהן לבנות את הגישה.

ציר ההחלטה פשוט: תשתית הזהות של המכשיר (AD, או Microsoft Entra) ואיפה המכשיר נמצא. GPO היא האמינה ביותר לצי מחשבי משרד נייחים שמצורפים במלואם ל-AD מקומי; ל-GPO פשוט אין הגעה כלל למחשבים ניידים Entra-joined.

במציאות, רוב העסקים הקטנים והבינוניים יושבים באמצע, בתצורה היברידית (domain-joined ועוד רשום ב-Intune), והדבר הגרוע ביותר שאפשר לעשות כאן הוא “להגדיר את אותה הגדרה גם ב-GPO וגם ב-MDM”. ל-Policy CSP יש מדיניות בשם MDMWinsOverGP שמאפשרת ל-MDM לנצח כש-GPO ו-MDM מתנגשים, אבל ההיקף שלה מוגבל למדיניות המתאימה בתוך Policy CSP. Microsoft עצמה מבהירה במפורש שהגדרת הגדרה מחוץ לבקרה הזאת גם ב-GPO וגם ב-MDM מייצרת מצב מרוץ בלי ערובה מי מנצח, ושצריך להימנע מתצורה כפולה.⁸ העיקרון הראשון של תפעול היברידי הוא להחליט, תחום-הגדרה אחר תחום-הגדרה, “זה GPO, זה Intune”, ולהישאר אצל סמכות ניהול אחת.

flowchart TB
    accTitle: הבחירה בין GPO ל-Intune
    accDescr: אם תשתית הזהות של המכשיר היא AD מקומי והוא נשאר במשרד GPO מתאימה, אם הוא Entra-joined או מחוץ לאתר Intune מתאימה, ובהיברידי נמנעים מתצורה כפולה של אותה הגדרה ומצמצמים את סמכות הניהול לאחד לפי תחום
    q{"מהי תשתית המכשיר והמיקום?"}
    q -->|AD-joined ובמשרד| gpo["GPO אמינה וברזולוציה דקה"]
    q -->|Entra או מחוץ לאתר| intune["Intune מגיע גם מחוץ לאתר"]
    q -->|היברידי| split["מצמצמים לאחד לפי תחום"]
    split -.-> warn["תצורה כפולה לא מבטיחה תוצאה"]
    split -.-> ana["למיון: Group Policy analytics"]

איור 17: הבחירה נקבעת לפי תשתית הזהות של המכשיר והמיקום, ובהיברידי לא מגדירים את אותה הגדרה גם ב-GPO וגם ב-MDM.

ברגע שמגיעים לשלב של שקילת migration מ-GPO ל-Intune, Group Policy analytics של Intune הוא נקודת הכניסה. מייבאים GPO שיוצאו מ-GPMC (XML), והכלי מנתח אם כל הגדרה נתמכת ב-MDM, או שאינה נתמכת/deprecated; הגדרות נתמכות אפשר להעביר למדיניות Settings catalog של Intune.⁹ מדויק יותר לחשוב על זה ככלי ל-“מיון מה אפשר להעביר, מה לא, ומה לזרוק” מאשר ל-“העברת הכול”. גם סמכות הניהול של Windows Update עוברת ארגון מחדש באותו הקשר — ראו גם “ניהול Windows Update אחרי ש-WSUS הפך ל-deprecated”.

flowchart TB
    accTitle: מיון ב-Group Policy analytics
    accDescr: כשמייבאים ל-Group Policy analytics GPO שיוצאה מ-GPMC בפורמט XML אפשר למיין לכל הגדרה אם היא נתמכת ב-MDM או deprecated או שאינה ניתנת להעברה, והגדרות נתמכות אפשר להעביר למדיניות Settings catalog
    exp["מייצאים XML מ-GPMC"] --> imp["מייבאים ל-analytics"]
    imp --> ana["מנתחים תמיכה לכל הגדרה"]
    ana --> ok["נתמך ב-MDM"]
    ana --> dep["deprecated / לא נתמך"]
    ok --> mig["מעבירים למדיניות Settings catalog"]

איור 18: Group Policy analytics מייבא GPO שיוצאה וממיין הגדרות שאפשר להעביר ל-MDM מול כאלה שאי אפשר.

8. נקודת עיוורון של מפתח — איך GPO אצל הלקוח משנה את התנהגות האפליקציה

לבסוף, משהו שכדאי לדעת אם עושים Custom Software Development. ה-GPO אצל הלקוח דורסת בשקט את הנחות האפליקציה שלכם. לצד Firewalls ותוכנות antivirus, GPO היא עבריינית קבועה מאחורי “עובד במכונת הפיתוח שלי ולא אצל הלקוח”. הנה כמה דוגמאות ממשיות.

• Execution Policy של PowerShell: אפשר להגדיר את Execution Policy באופן מרכזי דרך GPO, וההיקפים MachinePolicy/UserPolicy שמגיעים מ-GPO תמיד מקבלים עדיפות על ערך שהוגדר מקומית או ב-process.¹⁰ אם installer או סקריפט תפעולי בנוי על ההנחה ש”הוספת -ExecutionPolicy Bypass תגרום לזה לעבוד”, הוא אפילו לא יושק תחת ניהול GPO. לפירוט ראו “Execution Policy וחתימת סקריפטים ב-PowerShell — מדריך מעשי ליציאה מ"כיסוי עם Bypass"”.
• כיבוי Merge local rules ב-Firewall: בסביבות שבהן Firewall מנוהל באופן מרכזי דרך GPO/Intune, אפשר לכבות Merge local rules (AllowLocalPolicyMerge) לפי פרופיל. במקום שבו זה כבוי, inbound rule ש-installer רשם מקומית קיים אבל לא חל.¹¹ זו נקודה שחייבים לאשר לפני פריסת אפליקציה מסוג שרת; היא מכוסה בפירוט ב”Windows Firewall ואפליקציות עסקיות”.
• תצורת סביבה כמו מיפויי כוננים ו-proxy: מיפוי כונני רשת, מדפסות וכדומה מופץ בדרך כלל דרך Group Policy Preferences.¹⁶ הנחות על הסביבה — “כונן Z אמור להיות שם”, “ה-proxy אמור להיות חיבור ישיר” — יכולות להתפרק לפי המשתמש שנכנס או לפי השתייכות ה-OU של המחשב. קל גם להחמיץ, באפליקציה תושבת, שהגדרות שמופצות דרך User Configuration כמובן לא חלות על החשבון ש-service או scheduled task רצים תחתיו.
• ההגדרה פשוט “לא ניתנת להחזרה”: הגדרות שמגיעות מ-Administrative Templates בדרך כלל המשתמש לא יכול לשנות בכלל דרך ה-UI (הפריט מוצג באפור). העובדה ש”פשוט תבקשו מהלקוח לשנות את ההגדרה” לא עובדת משפיעה באמת על איך מתכננים את גישת התמיכה.

flowchart TB
    accTitle: הנחות האפליקציה ש-GPO אצל הלקוח משנה
    accDescr: GPO אצל הלקוח משנה את הנחות האפליקציה בכפיית Execution Policy, בכיבוי Merge local rules ב-Firewall, בהפצת כוננים ו-proxy, ובמצב שבו המשתמש לא יכול להחזיר הגדרה, וזה אחד הגורמים לכשל שקורה רק אצל הלקוח
    gpo["GPO אצל הלקוח"] --> ep["כפיית Execution Policy"]
    gpo --> fw["Merge local rules כבוי"]
    gpo --> env["הפצת כוננים / proxy"]
    gpo --> lock["אי אפשר להחזיר הגדרה"]
    ep --> sym["גורם לכשל רק אצל הלקוח"]
    fw --> sym
    env --> sym
    lock --> sym

איור 19: GPO אצל הלקוח דורסת בשקט הנחות של האפליקציה כמו Execution Policy, Firewall ותצורת סביבה.

יש שלוש הכנות מציאותיות בצד הפיתוח. ראשית, מתעדים כדרישת פריסה את הנחות הסביבה שהאפליקציה תלויה בהן — Execution Policy, פורטי האזנה, לאן היא כותבת, נתיב proxy וכן הלאה — ומבקשים מאנשי ה-IT של הלקוח לאשר אותן לפני הפריסה. שנית, כשמתעוררת תקלה, בודקים את דוח gpresult /h בפועל ואת הערכים האמיתיים תחת HKLM\Software\Policies, במקום לנחש (פרק 5). שלישית, מפרידים בשלב התכנון אילו פעולות צריכות הרשאות Administrator ואילו לא (הקו הזה נמתח ב”מתי באמת נדרשות הרשאות Administrator ב-Windows - UAC, אזורים מוגנים, ואיך מבחינים בתכנון”). GPO אינה האויב — היא מפרט של הסביבה. מתייחסים אליה כמפרט, והאבחון הופך למכני.

flowchart TB
    accTitle: שלוש ההכנות בצד הפיתוח
    accDescr: ההכנות בצד הפיתוח הן שלוש: לתעד את הנחות הסביבה שהאפליקציה תלויה בהן כדרישת פריסה ולבקש אישור מ-IT הלקוח לפני הפריסה, לאשר בזמן תקלה את דוח gpresult ואת הערך במפתח Policies, ולהפריד בשלב התכנון אילו פעולות דורשות הרשאות Administrator
    dev["ההכנות בצד הפיתוח"] --> doc["1. מתעדים הנחות סביבה"]
    dev --> chk["2. מאשרים ב-gpresult ובערך בפועל"]
    dev --> priv["3. מפרידים צורך בהרשאות בתכנון"]
    doc -.-> ask["לפני הפריסה מבקשים אישור מ-IT הלקוח"]

איור 20: שלוש ההכנות בצד הפיתוח הן תיעוד הנחות סביבה, אישור ב-gpresult ובערך בפועל, והפרדת הצורך בהרשאות Administrator בתכנון.

9. סיכום

• Group Policy היא מנגנון שמעבד הגדרות ברמת GPO בסדר Local → Site → Domain → OU (LSDOU), והתנגשויות נפתרות לפי האחרון-מנצח. ה-GPO של ה-OU הקרובה ביותר ליעד היא השכבה החזקה ביותר, וה-GPO המקומית היא החלשה ביותר.
• Block Inheritance, Enforced ו-security filtering מאפשרים לשלוט בזרימת ברירת המחדל. Enforced מנצחת גם את Block Inheritance, לכן אין להשתמש בה יתר על המידה.
• ה-apply קורה בשני ערוצים: foreground processing ב-startup/logon, ו-background refresh בערך כל 90 דקות ועוד היסט אקראי כברירת מחדל. gpupdate /force מחיל מחדש כל הגדרה, אבל אין לו השפעה על הגדרות שמעובדות רק ב-logon או ב-restart.
• כשהגדרה לא חלה, מאבחנים באופן מכני בסדר gpresult /h → Operational log של GroupPolicy → מפתח Policies ב-Registry. Denied GPOs מוצגות עם סיבה.
• הגדרות Administrative Templates הן ADMX/ADML, ותפעול domain צריך לרכז אותן ב-Central Store ב-SYSVOL. בעדכון מחליפים את צד ה-Central Store במקום להחליף את תיקיית PolicyDefinitions המקומית.
• הבחירה בין GPO ל-Intune נקבעת לפי תשתית הזהות של המכשיר והמיקום; בתצורה היברידית נמנעים מתצורה כפולה של אותה הגדרה ומשאירים את סמכות הניהול בצד אחד. Group Policy analytics יכול לעזור במיון migration.
• למפתחים, GPO אצל הלקוח היא חלק ממפרט הסביבה. מתעדים את ההנחות סביב Execution Policy, Firewall, מיפויי כוננים ותצורת proxy, ובונים הרגל לאשר אותן עם gpresult — ורוב מקרי “נכשל רק אצל הלקוח” מפסיקים להפחיד.

מאמרים קשורים

• Windows Firewall ואפליקציות עסקיות — רישום inbound rules מה-installer
• ניהול Windows Update אחרי ש-WSUS הפך ל-deprecated — איך לבחור בין WUfB, Autopatch ו-Intune
• Execution Policy וחתימת סקריפטים ב-PowerShell — מדריך מעשי ליציאה מ”כיסוי עם Bypass”
• אוטומציית PC kitting עם winget + PowerShell — הפיכת ספר הריצה לניתן-להרצה
• מדריך ליציאה מתלות במצב IE
• מתי באמת נדרשות הרשאות Administrator ב-Windows - UAC, אזורים מוגנים, ואיך מבחינים בתכנון

תחומי ייעוץ קשורים

KomuraSoft LLC מטפלת בחקירת למה אפליקציה עסקית לא רצה בסביבת לקוח בניהול GPO, בארגון דרישות פריסה (Execution Policy, Firewall, הנחות רשת), ובייעוץ טכני על מינוי מדיניות ותכנון ניהול משותף עם Intune לאנשי IT שירשו סביבת AD. בסדר להתחיל משלב מוקדם כמו “בואו נקרא יחד דוח gpresult”.

• ייעוץ טכני וסקירת תכנון
• חקירת תקלות ואיתור גורמים
• פיתוח אפליקציות Windows
• יצירת קשר

מקורות

מאמרים קשורים

מאמרים עדכניים עם אותן תגיות, להעמקה בנושאים קרובים.

נושאים קשורים

העמודים האלה ממקמים את הנושא בהקשר רחב יותר של שירותים והחלטות.

שירותים הקשורים לנושא הזה

המאמר קשור ישירות לשירותים הבאים.

שאלות נפוצות

שאלות נפוצות בפניות בנושא המאמר.

הרצתי gpupdate /force, ובכל זאת ההגדרה לא חלה. למה?

קודם בודקים אם ההגדרה שייכת לסוג ש-background refresh לעולם לא מחיל. Software installation שמיועדת למשתמש ו-Folder Redirection מעובדות רק ב-logon, ו-software installation שמיועדת למחשב רק ב-startup, לכן אחרי ש-gpupdate מסתיים נדרשת logoff (/logoff) או restart (/boot). אחר כך מריצים gpresult /h כדי לייצר דוח RSoP ובודקים אם ה-GPO מופיעה בין Applied GPOs, או בין Denied GPOs עם סיבה. אם היא חלה אבל ההתנהגות לא השתנתה, חושדים ש-GPO אחרת בעדיפות גבוהה יותר דורסת את אותה הגדרה (האחרון מנצח). הדוח מציג את Winning GPO לכל הגדרה, כך שאפשר לזהות בדיוק איזו GPO מנצחת.

מה אומר "Denied - Filtering" בדוח gpresult?

זה אומר שה-GPO נמצאת בהיקף מבחינת מיקום הקישור, אבל הסינון הוציא אותה מה-apply בפועל. הסיבה הנפוצה ביותר היא security filtering: כדי ש-GPO תחול, למשתמש או למחשב חייבות להיות על אותה GPO גם הרשאת Read וגם Apply Group Policy. כברירת מחדל שתיהן ניתנות ל-Authenticated Users, אבל אם צמצמתם לקבוצות ספציפיות, חברות קבוצה שהוחמצה — שכחתם להוסיף את הקבוצה, או שכחתם להוסיף את חשבון המחשב — תגרום לדחייה. ב-GPO שמיועדות למשתמש, מתן שתי ההרשאות למשתמש היעד בלבד אינו מספיק. מאז MS16-072, מדיניות משתמש נשלפת בהקשר האבטחה של המחשב, לכן צריך להשאיר Read (לא Apply) ל-Authenticated Users או ל-Domain Computers. סיבות אחרות כוללות WMI filter שלא מתאים, או שתצורת המשתמש/המחשב כבויה על ה-GPO עצמה. סיבת הדחייה נרשמת גם בדוח gpresult וגם ב-Operational log של GroupPolicy.

צריך לנהל מכשיר עם GPO או עם Intune?

הכלל הבסיסי הוא להתאים את עצמכם לתשתית הזהות של המכשיר. אם המכשירים בעיקר domain-joined ל-AD מקומי ומחוברים באופן קבוע לרשת הפנימית, GPO היא האפשרות האמינה והדקה ביותר. אם יש יותר מכשירים Entra-joined, או מחשבים לעבודה מהבית שלעולם לא נוגעים ב-domain controller, Intune (MDM/CSP), שיכול להעביר תצורה גם מחוץ למשרד, מתאימה יותר. בסביבה היברידית שבה שניהם מתקיימים יחד, הגדרת אותה הגדרה גם ב-GPO וגם ב-MDM יוצרת התנגשות בלי ערובה מי מנצח, לכן העיקרון הוא להחליט, תחום-הגדרה אחר תחום-הגדרה, מי מנהל אותה, ולהישאר אצלו. ברגע ששוקלים migration, ייבוא ה-GPO הקיימות ל-Group Policy analytics של Intune מאפשר למיין הגדרות לאלה שכבר נתמכות ב-MDM ולאלה שאינן נתמכות או ש-deprecated.

הגדרה שקבעתי ב-Local Group Policy Editor (gpedit.msc) ממשיכה להידרס על ידי הגדרת ה-domain. זה מתוכנן כך?

כן, זה לפי התכנון. Group Policy מעובדת בסדר Local → Site → Domain → OU (LSDOU), ו-GPO שמעובדת מאוחר יותר מנצחת בהתנגשות, מה שהופך את ה-GPO המקומית לשכבה החלשה ביותר. אם GPO domain מגדירה את אותה הגדרה, השינוי המקומי תמיד יידרס. להפך, אם צד ה-domain משאיר את ההגדרה כ-Not Configured, ערך ה-GPO המקומית נשאר. גם אם רוצים שההגדרה המקומית תקבל עדיפות לצורך בדיקה, אין דרך להפוך את סדר העדיפות הזה במחשב domain-joined, לכן הגישות המציאותיות הן ליצור OU ייעודי לבדיקות ולכוונן את ה-GPO בצד ה-domain, או להשתמש במכונת בדיקה שאינה domain-joined.

האפליקציה העסקית שפיתחנו פשוט לא רצה בסביבת הלקוח. יש דרך לבדוק אם GPO היא הסיבה?

הצעד הראשון הוא לבקש ממנהל הלקוח להריץ gpresult /h report.html משורת פקודה elevated במחשב הבעייתי ולעיין בדוח RSoP. מחפשים הגדרות שישנו את התנהגות האפליקציה: סקריפטים שנחסמו על ידי Execution Policy, Merge local rules של Firewall שכובה, או proxy ומיפויי כוננים שהוגדרו. כדאי גם לבדוק אם ערכי מדיניות למוצר הרלוונטי נכתבו תחת HKLM\Software\Policies ו-HKCU\Software\Policies ב-Registry, מה שמאפשר לסמן באופן מכני כל הגדרה כפויה שמגיעה מ-Administrative Templates. בצד הפיתוח, ההכנה המעשית היא לתעד את ההנחות שהאפליקציה תלויה בהן — Execution Policy, פורטי האזנה, התיקייה שהיא כותבת אליה וכן הלאה — כדרישת פריסה, ולבקש מאנשי ה-IT של הלקוח לאשר אותן לפני הפריסה.

פרופיל הכותב

עמוד היכרות עם כותב המאמר.

Go Komura

מנהל KomuraSoft LLC

מתמחה בפיתוח תוכנה עבור Windows, ייעוץ טכני וחקירת תקלות, בעיקר בפרויקטים עם מערכות קיימות ובאגים שקשה לשחזר.