מדריך מעשי ל-Group Policy ‏(GPO) — איך זה עובד, אישור החלה, ובחירה בין GPO ל-Intune

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

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

1. השורה התחתונה קודם

• Group Policy היא «האחרון מנצח». היא מעובדת בסדר מקומי → אתר → דומיין → OU ‏(LSDOU), ו-GPO שמעובדת מאוחר יותר מקבלת עדיפות בהתנגשות. ה-GPO המקומית (gpedit.msc) היא השכבה החלשה ביותר.¹
• תזמון ההחלה הוא «חזית ועוד רקע». תצורת מחשב חלה תמיד בהפעלה ותצורת משתמש תמיד בכניסה; ומעליהן, כברירת מחדל יש רענון ברקע בערך כל 90 דקות ועוד היסט אקראי של 0–30 דקות (5 דקות בבקרי דומיין).²
• gpupdate /force «מחיל מחדש כל הגדרה» — זה אינו תרופת-פלא. חלק מההגדרות, כמו התקנת תוכנה והפניית תיקיות, מעובדות רק בכניסה או בהפעלה מחדש (וזו בדיוק הסיבה שקיימות האפשרויות /logoff ו-/boot).³
• נקודת הפתיחה לאבחון היא דוח RSoP מ-gpresult /h. הוא מציג גם את ה-GPO שהוחלו וגם את אלה שנדחו, עם סיבות. לחפירה עמוקה יותר משתמשים ביומן התפעול של GroupPolicy ‏(Microsoft-Windows-GroupPolicy/Operational).⁴⁵
• ככלל, מדיניות תבניות ניהול נכתבת למפתחות המדיניות הייעודיים ברישום (Software\Policies וכדומה). ערך המדיניות מקבל עדיפות על ההגדרה של האפליקציה עצמה, ו«לא הוגדר» לא כותב דבר. עם זאת, יש מדיניות שכותבת מחוץ למפתחות הייעודיים (פרק 5).⁶
• המאגר המרכזי של ADMX הוא תיקיית PolicyDefinitions ב-SYSVOL. ברגע שיוצרים אותה, GPMC מתחיל להפנות להגדרות התבניות המשותפות לדומיין משם.⁷
• בחירה בין GPO ל-Intune לפי תשתית הזהות של המכשיר. הגדרת אותה הגדרה בשניהם לא מבטיחה תוצאה. Group Policy analytics יכול לעזור כששוקלים מיגרציה.⁸⁹
• למפתחים, GPO היא סיבה קלאסית לכך שאפליקציה «נכשלת רק אצל הלקוח». הגדרות שמשנות את הנחות האפליקציה — מדיניות ההרצה, כיבוי מיזוג כללים מקומיים בחומת האש, תצורת פרוקסי וכוננים ועוד — מופצות בניהול מרכזי.¹⁰¹¹

2. מהי Group Policy — GPO מקומית ו-GPO דומיין

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

מחשב בקבוצת עבודה (שאינו מצורף לדומיין) מעבד רק את ה-GPO המקומית.¹ לכן בפועל, כשאומרים שמכונה «מנוהלת ב-GPO», כמעט תמיד מתכוונים ל-GPO דומיין.

flowchart TB
    accTitle: GPO שמעבדים מחשב בקבוצת עבודה ומחשב מצורף לדומיין
    accDescr: מחשב בקבוצת עבודה מעבד רק GPO מקומית, ואילו מחשב מצורף לדומיין מעבד בנוסף GPO דומיין שמופצת מ-Active Directory
    pc{"מהי צורת ההצטרפות של המחשב?"}
    pc -->|קבוצת עבודה| wg["מעבד רק GPO מקומית"]
    pc -->|מצורף לדומיין| dom["GPO מקומית+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 של ה-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["GPO עם המספר הקטן ביותר מעובדת אחרונה"]
    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, לא יקבלו אותה עד הפעם הבאה שהם מגיעים ל-DC. הגדרות שחלות רק דרך עיבוד בחזית יצטרכו בנוסף לחכות להפעלה או לכניסה. אם ממהרים, מריצים gpupdate במחשב היעד. כברירת מחדל חלות רק הגדרות שהשתנו; הוספת /force מחילה מחדש כל הגדרה, בלי קשר לשאלה אם היא השתנתה.³

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

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

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

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

הדבר שצריך לשים לב אליו הוא שיש הגדרות שפשוט לא נכנסות לתוקף דרך 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: Resultant Set of Policy) אחרי שכמה 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 ייחודי, לכן ההליך ש-Microsoft ממליצה עליו הוא לאסוף את ה-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; אם יש שם ערך הוא מקבל עדיפות; אם לא, האפליקציה חוזרת להגדרה שלה עצמה (preference) או לברירת המחדל. מדיניות «לא הוגדר» לא כותבת דבר לרישום.⁶ כלומר, מדיניות תבניות ניהול אינה דורסת את ההגדרה של האפליקציה עצמה ומשאירה «קעקוע (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 כדי לראות לאיזה מפתח הגדרה נתונה באמת כותבת.

במילים אחרות, התכנון המנומס שתואר למעלה מחזיק רק בגבול תבניות הניהול (מפתחות המדיניות הייעודיים). ערכים שסקריפטים או העדפות Group Policy Preferences כותבים מחוץ למפתח 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: קודם מאשרים בדוח RSoP של gpresult אילו GPO הוחלו ואילו נדחו, ואם זה לא מספיק מצמצמים את יומן התפעול של 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), והתוכן שלה משוכפל לכל בקר דומיין בדומיין; כלי Group Policy אז מפנים למאגר המרכזי כברירת מחדל.⁷ זה מבטל את הבעיה שבה «גרסת התבנית שונה מתחנת ניהול אחת לאחרת, וההגדרות הנראות לא תואמות». קבצי ADML הולכים לתת-תיקיות לפי שפה (he-IL לעברית).⁷

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

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

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

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

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

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

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

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

במציאות, רוב העסקים הקטנים והבינוניים יושבים באמצע, בתצורה היברידית (מצורף-דומיין ועוד רשום ב-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 או מחוץ לאתר 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 Update אחרי הוצאת WSUS משימוש».

flowchart TB
    accTitle: מיון ב-Group Policy analytics
    accDescr: כשמייבאים ל-Group Policy analytics GPO שיוצאה מ-GPMC בפורמט XML אפשר למיין לכל הגדרה אם היא נתמכת ב-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 ויישומים עסקיים».
• תצורת סביבה כמו מיפויי כוננים ופרוקסי: מיפוי כונני רשת, מדפסות וכדומה מופץ בדרך כלל דרך העדפות Group Policy 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 אצל הלקוח דורסת בשקט הנחות של האפליקציה כמו מדיניות הרצה, חומת אש ותצורת סביבה.

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

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

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

9. סיכום

• Group Policy היא מנגנון שמעבד הגדרות ברמת 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 Update אחרי הוצאת WSUS משימוש — איך לבחור בין WUfB, Autopatch ו-Intune
• מדיניות הרצה וחתימת סקריפטים ב-PowerShell — מדריך מעשי ליציאה מ”כיסוי עם Bypass”
• אוטומציית קיטינג מחשבים עם winget + PowerShell — הפיכת ספר הריצה לניתן-להרצה
• מדריך ליציאה מתלות במצב IE
• מתי באמת נדרשות הרשאות מנהל ב-Windows - UAC, אזורים מוגנים, ואיך מבחינים בתכנון

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

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

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

מקורות

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

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

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

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

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

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

שאלות נפוצות

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

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

קודם בודקים אם ההגדרה שייכת לסוג שרענון ברקע לעולם לא מחיל. התקנת תוכנה שמיועדת למשתמש והפניית תיקיות מעובדות רק בכניסה, והתקנת תוכנה שמיועדת למחשב רק בהפעלה, לכן אחרי ש-gpupdate מסתיים נדרשת יציאה (/logoff) או הפעלה מחדש (/boot). אחר כך מריצים gpresult /h כדי לייצר דוח RSoP ובודקים אם ה-GPO מופיעה בין «GPO שהוחלו», או בין «GPO שנדחו» עם סיבה. אם היא חלה אבל ההתנהגות לא השתנתה, חושדים ש-GPO אחרת בעדיפות גבוהה יותר דורסת את אותה הגדרה (האחרון מנצח). הדוח מציג את «ה-GPO המנצחת» לכל הגדרה, כך שאפשר לזהות בדיוק איזו GPO מנצחת.

מה אומר «Denied - Filtering» בדוח 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) ממשיכה להידרס על ידי הגדרת הדומיין. זה מתוכנן כך?

כן, זה לפי התכנון. Group Policy מעובדת בסדר מקומי → אתר → דומיין → OU ‏(LSDOU), ו-GPO שמעובדת מאוחר יותר מנצחת בהתנגשות, מה שהופך את ה-GPO המקומית לשכבה החלשה ביותר. אם GPO דומיין מגדירה את אותה הגדרה, השינוי המקומי תמיד יידרס. להפך, אם צד הדומיין משאיר את ההגדרה כ«לא הוגדר», ערך ה-GPO המקומית נשאר. גם אם רוצים שההגדרה המקומית תקבל עדיפות לצורך בדיקה, אין דרך להפוך את סדר העדיפות הזה במחשב מצורף-דומיין, לכן הגישות המציאותיות הן ליצור OU ייעודי לבדיקות ולכוונן את ה-GPO בצד הדומיין, או להשתמש במכונת בדיקה שאינה מצורפת לדומיין.

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

הצעד הראשון הוא לבקש ממנהל הלקוח להריץ gpresult /h report.html משורת פקודה מוגבהת במחשב הבעייתי ולעיין בדוח RSoP. מחפשים הגדרות שישנו את התנהגות האפליקציה: סקריפטים שנחסמו על ידי מדיניות ההרצה, מיזוג כללים מקומיים של חומת האש שכובה, או פרוקסי ומיפויי כוננים שהוגדרו. כדאי גם לבדוק אם ערכי מדיניות למוצר הרלוונטי נכתבו תחת HKLM\Software\Policies ו-HKCU\Software\Policies ברישום, מה שמאפשר לסמן באופן מכני כל הגדרה כפויה שמגיעה מתבניות ניהול. בצד הפיתוח, ההכנה המעשית היא לתעד את ההנחות שהאפליקציה תלויה בהן — מדיניות הרצה, פורטי האזנה, התיקייה שהיא כותבת אליה וכן הלאה — כדרישת פריסה, ולבקש מאנשי ה-IT של הלקוח לאשר אותן לפני הפריסה.

פרופיל הכותב

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

Go Komura

מנהל KomuraSoft LLC

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