מ-GPO ל-Intune: מדריך מעבר לניהול מכשירים ב-SMB

«חלון התמיכה של השרת נגמר, אז אנחנו מתכננים החלפה. אבל איבדנו את הביטחון שכדאי לקנות עוד שרת AD ולהריץ את ה-domain ו-Group Policy לעוד מחזור (חמש שנים).» «ה-Group Policy שהחלטנו עליה במשרד אף פעם לא חלה על המחשבים הניידים לעבודה מהבית. אם היא חלה רק כשהם מתחברים ל-VPN, אפשר באמת לומר שאנחנו מנהלים אותם?» בשנים האחרונות, פניות מהסוג הזה מלקוחות SMB גדלו בהתמדה.

הרקע הוא שינוי באיך אנשים עובדים. Active Directory (AD) מקומי ו-Group Policy (GPO) הם מנגנון שמניח «המחשב נמצא ב-LAN הארגוני ויכול תמיד להגיע ל-domain controller». עכשיו שמחשבים ניידים לעבודה ועבודה מהבית הם הנורמה, זו ההנחה שנשברה. מעל זה, WSUS — ברירת המחדל הארוכה לניהול עדכונים — הוצא משימוש בספטמבר 2024,¹ ומרכז הכובד של ניהול המכשירים של Microsoft עבר ל-Entra ID ו-Intune (MDM).

flowchart TB
    accTitle: ההנחה שנשברה והמעבר במרכז הכובד
    accDescr: AD ו-GPO מניחים שהמחשב ב-LAN הארגוני ויכול תמיד להגיע ל-domain controller, אבל מחשבים ניידים ועבודה מהבית כנורמה שברו את ההנחה, ועם הוצאת WSUS משימוש מרכז הכובד של הניהול עבר ל-Entra ID ול-Intune
    adgpo["AD ו-GPO מקומיים"] -.-> premise["הנחה: ה-DC תמיד בר-הגעה"]
    work["מחשבים ניידים ועבודה מהבית כנורמה"] --> broken["זו ההנחה שנשברה"]
    premise --> broken
    wsus["WSUS הוצא משימוש"] --> shift["מרכז הכובד עובר ל-Entra ID+Intune"]
    broken --> shift

איור 1: ההנחה של AD+GPO ש«המחשב ב-LAN הארגוני» נשברה כשדרכי העבודה השתנו, ומרכז הכובד של הניהול עבר ל-Entra ID+Intune.

עם זאת, מעבר אינו הכול-או-לא-כלום. מחשבים שמנוהלים עם Entra join ו-Intune ומחשבים מצורפי-domain AD ו-GPO יכולים לדור יחד באותה חברה,² ומעבר מדורג אפשרי: להשאיר AD ל-file server, ולהעביר מחשבים חדשים לניהול Intune. המאמר מיועד לאנשי IT ולבעלי עסקים ב-SMB. הוא מסדר — מעוגן במקורות ראשוניים כמו Microsoft Learn נכון לאוגוסט 2026 — את ההבדלים באיך GPO ו-MDM עובדים, את התצורות המוקדמות, רישוי, איך למנות GPO נוכחיות, תרחיש מעבר מדורג והמלכודות.

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

• GPO חלה כשמתחברים לרשת ה-domain; Intune (MDM) מסנכרן דרך האינטרנט. בעיית «ההגדרה לא מגיעה למחשב ביתי» לא קורית במבנה של MDM. סנכרון במצב יציב הוא בערך כל 8 שעות, וכשמדיניות משתנה רץ גם סנכרון מונע-הודעה.³
• מעבר אינו הכול-או-לא-כלום; התשובה המציאותית היא מעבר מדורג בהנחת דו-קיום. Microsoft עצמה ממליצה: מחשבים חדשים ב-Entra join, מחשבים קיימים מצורפי-domain נשארים hybrid join ומוחלפים במחזור רענון.²
• אפשר לרכוש Intune בנפרד, אבל ב-SMB המציאותי הוא Intune Plan 1 כחלק מ-Microsoft 365 Business Premium (נכון לאוגוסט 2026). הרכב התוכניות ממשיך להשתנות, לכן לפני חתימה מאשרים תמיד מקור ראשוני.⁴⁵
• למיון GPO נוכחיות משתמשים ב-Group Policy analytics המובנה ב-Intune. מייבאים ייצוא XML של GPO ומקבלים מיון לפי הגדרה אם אפשר להעביר, ואפשר להמיר הגדרות נתמכות למדיניות Settings catalog.⁶
• לרוב העבודה העיקרית מתקופת GPO יש מקבילה ב-Intune. שווה-ערך לתבניות ניהול הוא Settings catalog,⁷ ל-WSUS הוא Windows Update for Business, למפתח שחזור BitLocker שמירה ב-Entra ID,⁸ לסיסמת local Administrator הוא Windows LAPS,⁹ ולפריסת אפליקציות Win32 apps (.intunewin)¹⁰ ו-Microsoft Store apps (תשתית winget).¹¹
• הנציגים שאי אפשר להעביר כמו שהם הם logon scripts, מיפוי כוננים ופריסת מדפסות. מחליפים בפריסת סקריפט PowerShell,¹² Remediations (לשעבר Proactive remediations),¹³ הפיכה לאפליקציה, או «מפסיקים את ההפעלה הזו».
• אל תפרסו את אותה הגדרה גם מ-GPO וגם מ-MDM. כברירת מחדל, בהתנגשות GPO מנצחת. MDMWinsOverGP=1 גורם ל-MDM לנצח, אבל זה חל רק על הגדרות Policy CSP.¹⁴
• מכונות domain-joined ומכונות Entra join יכולות לדור יחד, ומכונת Entra join יכולה לגשת גם ל-file server מקומי. ביטול מיידי של AD אינו תנאי למעבר.²

במשפט אחד, את השאלה «האם להחליף עוד מחזור שרת AD» צריך להחליף בשאלה «בחמש השנים הבאות, במה מנהלים מחשבים שנמצאים מחוץ למשרד».

flowchart LR
    accTitle: החלפת השאלה שצריך להחליט עליה
    accDescr: את השאלה אם להחליף עוד מחזור שרת AD מחליפים בשאלה במה מנהלים בחמש השנים הבאות מחשבים שנמצאים מחוץ למשרד
    q1["עוד מחזור שרת AD?"] -->|מחליפים| q2["בחמש השנים הבאות במה מנהלים מחשבים מחוץ למשרד?"]

איור 2: שאלת החלפת השרת מוחלפת ב«בחמש השנים הבאות, במה מנהלים מחשבים שנמצאים מחוץ למשרד».

2. איך GPO ו-MDM נבדלים — השוואת מנגנוני ההחלה

קודם משווים את השניים באותו מגרש. מנגנון GPO עצמו (סדר החלה LSDOU, איך מאשרים ב-gpupdate/gpresult) מכוסה בפירוט ב-«מדריך מעשי ל-Group Policy (GPO)»; כאן מצמצמים להבדלים שמשפיעים על החלטת מעבר.

להחלטת מעבר החשובות ביותר הן השורה הראשונה והשלישית. GPO לא מגיעה למחשב ביתי לא כי יש תקלה, אלא כי הנחת העיצוב «המחשב נמצא במקום שמגיע ל-DC» כבר לא מתאימה לדרכי העבודה של היום. אפשר להאריך את חיי GPO בכפיית VPN תמיד-דלוק לכל העובדים, אבל זו בחירה שמחזיקים גם תשתית VPN נפרדת.

flowchart TB
    accTitle: הבחירה בין להמשיך GPO לבין מעבר ל-MDM
    accDescr: GPO לא מגיעה למחשב ביתי כי הנחת העיצוב כבר לא מתאימה לדרכי העבודה של היום, והמשך GPO בכפיית VPN תמיד-דלוק הוא בחירה שמחזיקים גם תשתית VPN נפרדת
    gap["הנחת העיצוב לא מתאימה לדרכי העבודה"] --> sel{"איך מתמודדים?"}
    sel -->|המשך בכפיית VPN תמיד-דלוק| vpn["ממשיכים GPO"]
    sel -->|מעבר ל-MDM| mdm["ניהול דרך האינטרנט"]
    vpn --> cost["מחזיקים גם תשתית נפרדת"]

איור 3: המשך GPO בכפיית VPN תמיד-דלוק הוא גם בחירה שמחזיקים תשתית VPN נפרדת.

מצד שני, מרווח הסנכרון של MDM (בערך 8 שעות) גס יותר מרענון המחזורי של GPO (בערך 90 דקות), ותחושת «חילקנו, אז זה חל מיד» לא מחזיקה. בהקצאה או בשינוי מדיניות נשלחת הודעה למכשיר והסנכרון קורה יחסית מהר,³ אבל בקרה שצריכה מיידיות (חסימה דחופה וכדומה) צריך לעצב מתוך הנחת מרווח הסנכרון.

flowchart TB
    accTitle: נתיב החלת המדיניות של GPO ושל MDM
    accDescr: GPO חלה רק כשאפשר להגיע ל-DC בארגון ולכן מחשב ביתי תלוי VPN, ואילו Intune מסנכרן דרך האינטרנט בערך כל 8 שעות ובשינוי מדיניות גם בהודעה ולכן מגיע בלי קשר למקום
    officepc["מחשב במשרד"] -->|בהפעלה / sign-in וברענון מחזורי| dc["Domain controller"]
    homepc["מחשב ביתי"] --> vpn{"מגיע ל-DC דרך VPN?"}
    vpn -->|כן| dc
    vpn -->|לא| miss["המדיניות העדכנית לא מגיעה"]
    anypc["מחשב בכל מקום"] -->|סנכרון בערך כל 8 שעות| intune["שירות Intune"]
    intune -.-> notify["בשינוי מדיניות גם סנכרון בהודעה"]

איור 4: GPO חלה רק כשמגיעים ל-DC; Intune מסנכרן דרך האינטרנט בלי קשר למקום.

3. מיון התנאים המוקדמים — שלוש הצורות: domain join, hybrid join ו-Entra join

ל-«איך מחשב Windows מצטרף לחברה» יש שלוש צורות, והבחירה קובעת אילו אמצעי ניהול זמינים.²

Hybrid join הוא צורה ש-«נותנת תעודת זהות בענן למחשב domain-joined קיים», ואפשר להתחיל Intune ו-Conditional Access תוך שימוש בנכסים קיימים. אבל Microsoft לא ממליצה על hybrid join כיעד סופי, וממליצה לעשות Entra join למחשבים חדשים ולמחשבי החלפה.²

כאן יש אילוץ אחד שצריך לתפוס. אין אמצעי נתמך בידי Microsoft להמיר מחשב domain-joined קיים (כולל hybrid join) ל-Entra join; נדרש reset (wipe) של Windows. לכן גם Microsoft ממליצה לעבור ל-Entra join בתזמון של רענון חומרה או החלפת OS.²

flowchart TB
    accTitle: שלוש צורות הצירוף ונתיב המעבר
    accDescr: מחשב ב-domain join ל-AD בלבד אפשר לרשום גם ב-Entra ID ולהפוך ל-hybrid join, אבל אין אמצעי המרה ישירה ל-Entra join ונדרש wipe, ולכן מומלץ לעשות Entra join למחשבים חדשים ולהחלפות
    adonly["Domain join ל-AD בלבד (GPO)"] -->|רישום גם ב-Entra ID| hybrid["Hybrid join (GPO ו-Intune)"]
    hybrid -.->|אין אמצעי המרה ישירה| wipe["נדרש wipe (איפוס)"]
    wipe --> entra["Entra join (Intune)"]
    newpc["מחשבים חדשים והחלפות"] -->|מומלץ| entra

איור 5: אין אמצעי רשמי להמיר מכונה domain-joined קיימת ל-Entra join; הדפוס הוא לעבור ממחשבים חדשים ומהחלפות.

מכאן אפשר לשים ל-SMB יעד מציאותי כזה.

1. מחשבים חדשים והחלפות מנוהלים ב-Entra join+Intune
2. מחשבים domain-joined קיימים לא נוגעים בהם בכוח, ומחליפים אותם באופן טבעי במחזור רענון
3. AD נשאר לעת עתה לתפקידים שנשארו כמו אימות file server, ורק את תוכן ה-GPO מרוקנים בהדרגה

flowchart TB
    accTitle: תצורת דו-קיום במעבר מדורג
    accDescr: מכונות Entra join ומכונות domain-joined יכולות לדור יחד באותה סביבה ארגונית; הראשונות מנוהלות ב-Intune והאחרונות ב-GPO, ו-AD נשאר לעת עתה לתפקידים שנשארו תוך ריקון הדרגתי של תוכן ה-GPO
    env["אותה סביבה ארגונית"] --> ejoin["מכונות Entra join"]
    env --> djoin["מכונות domain-joined"]
    ejoin --> intune["ניהול ב-Intune"]
    djoin --> gpo["ניהול ב-GPO"]
    gpo -.-> shrink["מרוקנים את התוכן בהדרגה"]
    env -.-> ad["AD נשאר לתפקידים שנשארו"]

איור 6: מכונות Entra join ומכונות domain-joined יכולות לדור יחד באותה סביבה ארגונית, ו-AD נשאר לעת עתה לתפקידים שנשארו.

מכונות Entra join ומכונות domain-joined יכולות לדור יחד באותה סביבה, ומכונת Entra join יכולה לגשת גם לנכסים פנימיים כמו file server מקומי.² אבל ל-SSO הזה שני תנאים. ① המשתמש הוא hybrid identity שסונכרן מ-AD מקומי ב-Entra Connect (או Cloud Sync) (משתמש שקיים רק בענן לא מקבל credentials של Kerberos/NTLM של AD), ② מהמחשב אפשר להגיע ל-DC ברשת (מחוץ למשרד נדרש VPN וכדומה).¹⁵ בתוכנית המעבר מאשרים קודם שאין משתמשים ותרחישי שימוש שלא מקיימים את שתי הנקודות.

flowchart TB
    accTitle: התנאים ל-SSO ממכונת Entra join לנכס מקומי
    accDescr: כדי שמכונת Entra join תיגש ל-file server מקומי צריך לקיים שני תנאים: hybrid identity שסונכרן ב-Entra Connect וכדומה, והגעה ל-DC
    pc["מכונת Entra join"] --> cond1{"Hybrid identity?"}
    cond1 -->|כן| cond2{"אפשר להגיע ל-DC?"}
    cond1 -->|לא| ng1["לא מקבלים credentials של AD"]
    cond2 -->|כן| ok["SSO ל-file server"]
    cond2 -->|לא| ng2["מחוץ למשרד נדרש VPN וכדומה"]

איור 7: ל-SSO ממכונת Entra join לנכס מקומי שני תנאים: hybrid identity והגעה ל-DC.

4. רישוי ועלות — אילו תוכניות כוללות Intune (נכון לאוגוסט 2026)

רישיון הבסיס של Intune הוא Microsoft Intune Plan 1, ומוצע גם כמנוי נפרד וגם כחלק מתוכניות Microsoft 365 שונות.⁴

ל-SMB מה שחשוב הוא ש-Microsoft 365 Business Premium עד 300 משתמשים כולל Intune Plan 1.⁵ Business Premium כולל גם Microsoft Entra ID P1 ו-Microsoft Defender for Business, כך שגם תצורת compliance policy + Conditional Access שתידון בהמשך נגמרת בתוך התוכנית הזו. לעומת זאת Business Standard/Basic לא כוללים Intune. כשיוצאים מחוזה של דואר ו-Office בלבד לניהול מכשירים, עלות השדרוג ל-Business Premium היא בפועל עלות הכנסת Intune.

flowchart TB
    accTitle: הקשר בין תוכניות ל-SMB ל-Intune
    accDescr: Business Premium עד 300 משתמשים כולל Intune Plan 1, Entra ID P1 ו-Defender for Business ומגיע עד Conditional Access; Business Standard/Basic לא כוללים Intune
    bp["Business Premium"] -.-> cap["עד 300 משתמשים"]
    bp --> intune["Intune Plan 1"]
    bp --> p1["Entra ID P1"]
    bp --> dfb["Defender for Business"]
    p1 --> ca["נגמר עד Conditional Access"]
    dfb ~~~ std["Business Standard/Basic"]
    std --> noint["לא כוללים Intune"]

איור 8: Business Premium כולל Intune Plan 1 ו-Entra ID P1; Business Standard/Basic לא כוללים Intune.

שתי הסתייגויות.

• הרכב התוכניות משתנה לעיתים קרובות. גם ב-2026 נמשכת חלוקה מחדש של יכולות Intune Suite לתוכניות Microsoft 365 עליונות (E3/E5 וכו’), ותוכן החבילות ממשיך להישקל מחדש.⁴ את הפרק הזה מתייחסים אליו כנכון לאוגוסט 2026, ולפני חתימה מאשרים תמיד מידע עדכני בדפי הרישוי והמחיר של Microsoft.
• יש תכונות שנראות במסך Intune אבל דורשות רישיון נפרד. הנציג הוא Remediations שיידון בהמשך; נדרש רישיון ברמת Windows Enterprise E3/E5 (כלול ב-Microsoft 365 E3/E5 וכו’), ולא זמין בהיקף Business Premium.¹³

השוואת עלות אינה «עלות מנוי Intune» מול «אפס». גם בצד GPO יש עלויות: החלפת חומרה של שרת AD, רישיון Windows Server ו-CAL, בנייה, חמש שנות תחזוקה, גיבוי וטיפול בתקלות. ההשוואה הנכונה היא לשים זה ליד זה את הצעת המחיר להחלפת שרת ואת הפרש חמש שנים של Business Premium, ואז להוסיף את פערי היכולת «האם הניהול מגיע למחשב מחוץ למשרד».

flowchart TB
    accTitle: איך לחשוב נכון על השוואת עלות
    accDescr: גם בצד GPO יש עלויות החלפת שרת AD, רישוי וחמש שנות תחזוקה, ולכן שמים זה ליד זה את הצעת החלפת השרת ואת הפרש חמש שנים של Business Premium ואז מוסיפים את פערי היכולת אם הניהול מגיע למחשב מחוץ למשרד
    gpocost["עלות המשך GPO"] --> hw["החלפת שרת, רישוי, CAL"]
    gpocost --> ops["בנייה, תחזוקה, גיבוי"]
    bpcost["עלות מעבר ל-Intune"] --> sub["Business Premium לחמש שנים"]
    hw --> diff["שמים זה ליד זה את הפרש חמש השנים"]
    ops --> diff
    sub --> diff
    diff --> ability["מוסיפים אם הניהול מגיע למחשב מחוץ למשרד"]

איור 9: שמים זה ליד זה את הצעת החלפת השרת וחמש שנים של Business Premium, ומוסיפים את פער היכולת של ניהול מחשבים מחוץ למשרד.

5. איך לעשות ב-Intune מה שהייתם עושים עם GPO

לכל עבודה עיקרית בהפעלת GPO, מקבילה ב-Intune בטבלת התאמה.

כמה השלמות.

• Settings catalog הוא מסך שקול ל-«GPO editor בענן», וגם Microsoft ממקמת אותו כ-«יעד מעבר טבעי כשרוצים להגדיר ברזולוציה דומה ל-GPO מקומית». כלולות גם מדיניות ADMX-backed (גרסת MDM של הגדרות שמוגדרות ב-ADMX), ויש גם יכולת לקלוט ADMX של צד שלישי (preview).⁷
• Compliance policy + Conditional Access הוא רעיון שלא היה ב-GPO. מגדירים תנאי תאימות כמו «BitLocker דלוק, OS עדכני, Defender רץ», ואפשר לחסום גישה ל-Microsoft 365 ממכשיר שלא מקיים. Conditional Access היא יכולת Entra ID P1, וכלולה ב-Business Premium.¹⁶
• Remediations שינה שם מ-Proactive remediations. זה מנגנון שמריץ מחזורית זוג סקריפט זיהוי וסקריפט תיקון, ומחליף הפעלת GPO בסגנון «מתקנים משהו בכל logon», אבל כאמור נדרש רישיון ברמת Windows Enterprise E3/E5.¹³ בהיקף Business Premium המציאותי הוא לשלב platform scripts (רצים בשינוי סקריפט או הקצאה, ועם retry בכישלון)¹² עם detection rules של Win32 apps.
• פירוט אפשרויות ניהול עדכונים (WUfB, Autopatch, המשך WSUS) מכוסה ב-«ניהול Windows Update אחרי הוצאת WSUS משימוש», ועיצוב BitLocker ו-LAPS ב-«מדריך מעשי ל-BitLocker» וב-«מדריך מעשי ל-Windows LAPS».

flowchart TB
    accTitle: הזרימה של compliance policy ו-Conditional Access
    accDescr: Compliance policy רק שופטת מצב תאימות של מכשיר לפי תנאי תאימות; רק כשמדיניות Conditional Access דורשת מכשיר תואם, מכשיר תואם מותר ומכשיר לא-תואם נחסם
    policy["מגדירים תנאי תאימות"] -.-> cond["BitLocker דלוק, OS עדכני וכו"]
    policy --> state["שופטים מצב תאימות של המכשיר"]
    state --> ca["Conditional Access דורש תאימות"]
    ca -->|תואם| allow["גישה ל-Microsoft 365 מותרת"]
    ca -->|לא תואם| block["הגישה נחסמת"]

איור 10: שיפוט מצב התאימות הוא תפקיד compliance policy, החסימה היא תפקיד Conditional Access. רק השילוב חוסם בפועל.

6. מיון GPO נוכחיות — מיון עם Group Policy analytics

העבודה הראשונה בתוכנית המעבר היא מיון ה-GPO הנוכחיות. ב-Intune יש יכולת ייעודית Group Policy analytics; בלי לקרוא GPO ידנית אפשר למיין לפי הגדרה «האם יש מקבילה ב-MDM».⁶

ההליך כדלקמן.⁶

1. ב-domain controller וכדומה פותחים Group Policy Management Console (GPMC.msc), לוחצים ימנית על GPO היעד → «Save Report» ומייצאים כ-קובץ XML (עד 4MB לקובץ)
2. במרכז הניהול של Intune, «Devices» → «Group Policy analytics», מייבאים את ה-XML (אפשר כמה)
3. אחרי ניתוח אוטומטי מוצג לכל GPO אחוז תמיכת MDM (שיעור שיש לו הגדרה שקולה ב-Intune)
4. בדוח «Group Policy migration readiness» מאשרים לכל הגדרה מיון Ready for migration / Not supported / Deprecated
5. הגדרות Ready for migration אפשר להמיר כמו שהן למדיניות Settings catalog ולהפיץ

flowchart TB
    accTitle: זרימת המיון ב-Group Policy analytics
    accDescr: מייצאים GPO כ-XML מ-GPMC ומייבאים ל-Intune, מוצגים אחוז תמיכת MDM ומיון לפי הגדרה אם אפשר להעביר, והגדרות Ready for migration אפשר להמיר למדיניות Settings catalog
    export["ייצוא GPO כ-XML מ-GPMC"] --> import["ייבוא ל-Intune"]
    import --> rate["הצגת אחוז תמיכת MDM"]
    rate --> report["דוח מוכנות מעבר"]
    report --> ready["Ready for migration"]
    report --> notsup["Not supported"]
    report --> dep["Deprecated"]
    ready --> convert["המרה למדיניות Settings catalog"]

איור 11: זרימת Group Policy analytics היא ייצוא XML, ייבוא, מיון לפי הגדרה והמרה ל-Settings catalog.

בסביבה שאינה אנגלית יש הסתייגות חשובה. ניתוח הגדרות שאינן-ADMX ב-Group Policy analytics תומך באנגלית בלבד; ייבוא GPO שכולל הגדרות בשפה שאינה אנגלית עלול להפוך את אחוז תמיכת MDM ללא-מדויק.⁶ השתמשו באחוז כהערכה גסה, ואת ההחלטה הסופית עשו לפי רשימת ההגדרות אחת-אחת.

flowchart TB
    accTitle: הסתייגות בניתוח GPO שאינו באנגלית
    accDescr: ניתוח הגדרות שאינן-ADMX ב-Group Policy analytics תומך באנגלית בלבד, ו-GPO שכולל הגדרות ביפנית עלול להפוך את אחוז תמיכת MDM ללא-מדויק, לכן האחוז נשאר הערכה גסה וההחלטה הסופית היא לפי רשימת ההגדרות
    jgpo["GPO שכולל הגדרות שאינן באנגלית"] --> limit["ניתוח שאינו-ADMX תומך באנגלית בלבד"]
    limit --> rate["אחוז התמיכה עלול להיות לא מדויק"]
    rate --> use1["האחוז נשאר הערכה גסה"]
    rate --> use2["ההחלטה הסופית לפי רשימת ההגדרות"]

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

בפועל מחלקים את תוצאת המיון לשלוש ערימות.

1. הגדרות שזורקים — הגדרות מתקופת Internet Explorer, הגדרות למערכת שכבר יצאה משימוש, הגדרות שאף אחד לא יכול להסביר. ההישג הגדול ביותר של המיון הוא היכולת לזרוק את הערימה הזו. ב-GPO שעבד עשר שנים מצטבר די הרבה מורשת.
2. הגדרות שמעבירים ל-Intune — מתוך Ready for migration, מה שעדיין נחוץ. ממירים ל-Settings catalog ובודקים בקבוצת פיילוט.
3. הגדרות שמעצבים להן חלופה — מתוך Not supported, מה שעדיין נחוץ. נציגים וכיוון חלופה כדלקמן.

flowchart TB
    accTitle: שלוש הערימות של תוצאת המיון
    accDescr: את תוצאת המיון מטפלים בשלוש ערימות: הגדרות שזורקים, הגדרות שמעבירים ל-Intune ובודקים, והגדרות בלי מקבילה שמעצבים להן חלופה
    result["תוצאת המיון"] --> discard["הגדרות שזורקים"]
    result --> move["הגדרות שמעבירים ל-Intune"]
    result --> alt["הגדרות שמעצבים להן חלופה"]
    discard -.-> legacy["זורקים מורשת שהצטברה"]
    move --> pilot["ממירים ל-Settings catalog ובודקים"]
    alt --> design["פריסת סקריפט או הפיכה לאפליקציה"]

איור 13: תוצאת המיון מחולקת לשלוש ערימות: «זורקים», «מעבירים ל-Intune», «מעצבים חלופה».

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

מחלקים את הכול לחמישה שלבים, ולכל שלב שמים תנאי סיום. לקבוע מראש «מתי אפשר לומר שסיימנו» הוא הטריק שמונע ממעבר של איש IT יחיד להיתקע.

flowchart TB
    accTitle: תרחיש מעבר בחמישה שלבים
    accDescr: מתקדמים מדורג מפיילוט למדיניות בסיס, פריסת אפליקציות, החלפת מחשבים קיימים במחזור רענון, וצמצום תפקיד AD, ובסוף הגדרות שמופצות ב-GPO באפס
    s1["① פיילוט"] --> s2["② מדיניות בסיס"]
    s2 --> s3["③ פריסת אפליקציות"]
    s3 --> s4["④ החלפה טבעית של מחשבים קיימים"]
    s4 --> s5["⑤ צמצום תפקיד AD"]
    s5 -.-> goal["הגדרות שמופצות ב-GPO באפס"]

איור 14: המעבר מתקדם בחמישה שלבים מפיילוט עד צמצום תפקיד AD, ואת תנאי הסיום של כל שלב קובעים מראש.

נקודות לכל שלב.

• ① פיילוט מתחילים במחשב שקונים בכל מקרה — מחשב עובד חדש הבא, מכונת החלפה לתקלה. אפשר להתחיל בלי השקעה נוספת, וכישלון אפשר wipe ולנסות שוב — זה היתרון בהתחלה ממכונה חדשה. כשמספר המכונות גדל, שוקלים Windows Autopilot שמאוטט מ-OOBE (הקמה ראשונית) עד Entra join+רישום Intune.²
• ② מדיניות בסיס אל תשאפו לשחזר את כל הגדרות ה-GPO. קודם מצמצמים לחמש נקודות: עדכונים, הצפנה, Defender, נעילת מסך, LAPS, ומנראים מצב תאימות ב-compliance policy. הפעלת «רק מכשיר תואם» ב-Conditional Access היא אחרי שאישרתם שאין false positive בפיילוט.¹⁶
• ③ פריסת אפליקציות נמשכת מאוטומציית kitting. אם כבר יש לכם נוהל מבוסס winget («אוטומציית kitting מחשבים עם winget + PowerShell»), הנכס הזה עובר כמעט כמו שהוא כ-wrapper של Store app (חדש) או Win32 app.¹¹
• ④ מחשבים קיימים, כפי שנאמר בפרק 3, אין נתיב המרה ל-Entra join, ולכן כעיקרון החלפה טבעית. ארגון שעדיין יש לו תוכנית החלפה מ-Windows 10 («אפשרויות מעשיות אחרי סיום התמיכה ב-Windows 10») יכול להריץ את ההחלפה הזו במקביל ל-④ ולהימנע מעבודה כפולה.
• ⑤ צמצום תפקיד AD: גם אחרי ש-GPO ריקה, AD לא בהכרח מיותר מיד. אם נשארו אימות file server, הפניית LDAP של אפליקציה ישנה וכו’, AD ממשיך מצומצם כ-«שרת אימות». המיון של אלה וקביעת תאריך הם עבודת השלב הזה.

flowchart TB
    accTitle: מה עושים עם AD אחרי ש-GPO ריקה
    accDescr: גם אחרי ש-GPO ריקה, אם נשארו אימות file server או הפניית LDAP של אפליקציה ישנה AD ממשיך מצומצם כשרת אימות, ועבודת השלב הסופי כוללת מיון תפקידים שנשארו וקביעת תאריך
    gpoempty["GPO ריקה"] --> remain{"אילו תפקידים נשארו?"}
    remain -->|אימות file server| keep["המשך מצומצם כשרת אימות"]
    remain -->|הפניית LDAP של ישן| keep
    remain -->|אין תפקיד| retire["שוקלים ביטול AD עצמו"]
    keep --> task["עושים גם מיון וקביעת תאריך"]

איור 15: גם אחרי ש-GPO ריקה, אם נשארו תפקידים AD ממשיך מצומצם כשרת אימות.

8. המלכודות

8.1. החלה כפולה של GPO ו-MDM — כברירת מחדל GPO מנצחת

בתקופת המעבר נוצרים מצבים שבהם גם GPO וגם Intune מפיצים הגדרה לאותו מחשב (מכונת hybrid join). כאן, אם אותה הגדרה מתנגשת, כברירת מחדל צד GPO קודם. אם מגדירים MDMWinsOverGP של Policy CSP ל-1, הגדרת צד MDM קודמת והגדרת GPO המקבילה נחסמת, אבל המנגנון הזה חל רק על הגדרות תחת Policy CSP, ולא על הגדרות שמוגדרות ב-CSP אחרים כמו Defender CSP. גם Microsoft עצמה כותבת במפורש שאם מגדירים גם ב-GPO וגם ב-MDM הגדרה שאינה תחת MDMWinsOverGP נוצר מצב התנגשות בלי ערובה מי מנצח.¹⁴

flowchart TB
    accTitle: יחסי הקדימות כש-GPO ו-MDM מתנגשים
    accDescr: אם מפיצים את אותה הגדרה גם מ-GPO וגם מ-MDM, כברירת מחדל GPO קודמת; MDMWinsOverGP=1 נותן קדימות ל-MDM רק להגדרות תחת Policy CSP, וב-CSP אחרים אין ערובה מי מנצח
    both["מפיצים את אותה הגדרה גם מ-GPO וגם מ-MDM"] --> flag{"MDMWinsOverGP=1?"}
    flag -->|לא| gpowin["GPO קודמת (ברירת מחדל)"]
    flag -->|כן| csp{"הגדרה תחת Policy CSP?"}
    csp -->|כן| mdmwin["MDM קודמת"]
    csp -->|לא| unknown["אין ערובה מי מנצח"]
    both -.-> avoid["העיקרון: לא מפיצים משני הצדדים"]

איור 16: כברירת מחדל GPO מנצחת, ו-MDMWinsOverGP חל רק תחת Policy CSP. העיקרון הוא להימנע מהפצה כפולה.

העיקרון בפועל פשוט. אל תסתמכו על בקרת קדימות, ואל תפיצו את אותה הגדרה משני הצדדים. הגדרה שעברה ל-Intune מחזירים בצד GPO המקביל ל-«Not Configured», או מנתקים את הקישור של כל ה-GPO. רשימת מה שהועבר בפרק 6 היא גם ה-inventory לזה.

8.2. תלות בנכסים מקומיים — כונני רשת ומדפסות

רוב נקודות התקיעה במעבר אינן יכולת Intune אלא החיבור לנכסים מקומיים. גישה מ-Entra join ל-file server מקומי אפשרית בעצמה,² אבל אם מיפוי כוננים ופריסת מדפסות היו תלויים ב-logon script של GPO, אמצעי ההפצה הזה נעלם קודם. עד שלב ③ תשזרו מעבר שיתוף ל-OneDrive/SharePoint או החלפה ל-Universal Print, או תחברו לעת עתה בפריסת סקריפט,¹² ותחליטו את זה בפיילוט.

flowchart TB
    accTitle: החלפת הפצה שתלויה בנכס מקומי
    accDescr: אם מיפוי כוננים ופריסת מדפסות תלויים ב-logon script של GPO, אמצעי ההפצה נעלם קודם במעבר, ולכן בפיילוט מחליטים אם לעבור שיתוף ל-OneDrive או SharePoint, להחליף ל-Universal Print, או לחבר לעת עתה בפריסת סקריפט
    dep["תלות ב-logon script"] --> lost["אמצעי ההפצה נעלם במעבר"]
    lost --> share["מעבר ל-OneDrive/SharePoint"]
    lost --> print["החלפה ל-Universal Print וכו"]
    lost --> script["חיבור בפריסת סקריפט"]
    share --> decide["מחליטים מדיניות בפיילוט"]
    print --> decide
    script --> decide

איור 17: הפצה שתלויה ב-logon script מאבדת אמצעי קודם במעבר, לכן מחליטים יעד החלפה בפיילוט.

8.3. עיצוב מחדש של kitting —‏ Autopilot אינו «חובה»

לעיתים ממליצים להכניס Windows Autopilot כסט עם מעבר ל-Intune, אבל בהיקף רכש של כמה עד יותר מעשר מכונות בשנה, הפעלה ידנית של Entra join ב-OOBE עם work account אין לה נזק ממשי. Autopilot מתחיל להשתלם כשמספר הרכש גדל ויש ערך להקמה לא-מאוישת מהוצאה מהניילון, או כשאפשר להשתמש ברישום מכשיר בצד החנות. אפשר להוסיף אחרי ש-②③ מסודרים; זה לא תנאי מוקדם למעבר.

flowchart TB
    accTitle: החלטת הכנסת Autopilot
    accDescr: בהיקף רכש של כמה עד יותר מעשר מכונות בשנה אין נזק ממשי להפעלת Entra join ידנית ב-OOBE, וכשמספר הרכש גדל ויש ערך להקמה לא-מאוישת מוסיפים Autopilot אחר כך
    scale{"מה היקף הרכש השנתי?"} -->|כמה עד יותר מעשר| manual["Entra join ידני ב-OOBE"]
    scale -->|כשמספר המכונות גדל| ap["אוטומציה ב-Autopilot"]
    ap -.-> later["מוסיפים אחרי ש-②③ מסודרים"]

איור 18: כל עוד היקף הרכש קטן מספיק Entra join ידני, ו-Autopilot אפשר להוסיף אחר כך.

8.4. הטעות ש«זה לא טוב אלא אם הכול ב-Intune»

האחרונה אינה טכנולוגיה אלא הנחה. דו-קיום של מכונות Entra join ומכונות domain-joined הוא תצורה נתמכת רשמית,² ו-«AD נשאר = המעבר נכשל» אינו נכון. חברות שמריצות כמה שנים במקביל עם כמה הגדרות שנשארו ב-GPO אינן נדירות, ועדיין יש ערך גדול למצב «כל מחשב חדש מנוהל בענן, והבקרה עובדת גם מחוץ למשרד». העדיפו התקדמות קטנה שאפשר לחזור ממנה על יופי של מעבר מלא.

flowchart TB
    accTitle: הערך של ריצה במקביל בלי להתעקש על מעבר מלא
    accDescr: זה לא נכון ש-AD שנשאר הוא כישלון מעבר; גם ריצה במקביל כמה שנים עם הגדרות שנשארו ב-GPO יש לה ערך גדול במצב שכל מחשב חדש מנוהל בענן והבקרה עובדת גם מחוץ למשרד
    miscon["AD שנשאר = כישלון מעבר?"] -->|לא| run["ריצה במקביל כמה שנים עם GPO שנשארה"]
    run --> value["מחשבים חדשים בבקרה גם מחוץ למשרד"]
    value -.-> forward["מעדיפים התקדמות קטנה"]

איור 19: גם ריצה במקביל עם AD שנשאר יש לה ערך גדול במצב שכל מחשב חדש מנוהל בענן.

9. תשובה מציאותית ל-IT של אדם אחד

לבסוף, עיצוב הפעלה בחברה שיש בה אחראי אחד (או במשרה חלקית).

• מצמצמים מראש את פריטי הניהול. אם מנסים להכניס את כל הגדרות תקופת GPO, המיון לבדו מתיש. התחילו מחמש הנקודות של ② בפרק 7 (עדכונים, הצפנה, Defender, נעילת מסך, LAPS), והוסיפו רק הגדרה שצצה צורך — «עיצוב חיסור». Settings catalog מציע אלפי הגדרות,⁷ אבל אין חובה להשתמש.
• קובעים תמונת מחשב סטנדרטית אחת. מחזיקים סט אחד בלבד: «המחשב בחברה הזו הוא קבוצת המדיניות הזו וקבוצת האפליקציות הזו». חריגים לפי מחלקה אפשר לבטא בקבוצות וב-filters, אבל ככל שיש יותר חריגים אדם אחד כבר לא מצליח לסובב.
• מבקשים מפרטנר חיצוני עיצוב ותבניות, ואת ההפעלה היומית עושים בפנים. כישלון נפוץ במיקור חוץ של מעבר Intune הוא לזרוק את הבנייה החוצה ולהישאר במצב «אף אחד לא מבין מה אומר מסך הניהול». בקשו מבחוץ עיצוב ראשוני, תבניות מדיניות ודיון בהחלטות מעבר, והיעד הוא מצב שבו הוספת מחשב יומית וכיוונון מדיניות אתם יכולים לעשות בעצמכם. ולהפך: בחרו פרטנר שמוסר עד לשם.
• שינוי אחד בכל פעם. משנים מדיניות אחת-אחת, מאשרים תוצאה בדוחות Intune (מצב החלת מדיניות, כישלון הקצאה) ואז ממשיכים. סנכרון MDM הוא במחזור של בערך 8 שעות,³ ורוב «לא חל» אינו תקלה אלא עניין של זמן.

flowchart TB
    accTitle: מחזור הפעלת שינוי מדיניות
    accDescr: משנים מדיניות אחת-אחת, מאשרים מצב החלה בדוחות Intune ואז ממשיכים לשינוי הבא. רוב מה שלא חל נפתר בהמתנה לסנכרון במחזור של בערך 8 שעות
    change["משנים מדיניות אחת בלבד"] --> report["מאשרים מצב החלה בדוח"]
    report --> next["אם אין בעיה, לשינוי הבא"]
    next --> change
    report -.-> wait["רוב מה שלא חל הוא המתנה לסנכרון"]

איור 20: משנים מדיניות אחת-אחת, מאשרים תוצאה בדוח ואז ממשיכים.

10. סיכום

• GPO הוא מנגנון שמניח הגעה ל-DC, ולמחשב מחוץ למשרד הוא לא מגיע במבנה. Intune (MDM) מסנכרן דרך האינטרנט ולכן פותר את הבעיה מהשורש.
• מעבר אינו הכול-או-לא-כלום. מכונות Entra join ומכונות domain-joined יכולות לדור יחד, והתשובה המציאותית ל-SMB היא מעבר מדורג שמעביר מחשבים חדשים ל-Entra join+Intune. אין נתיב המרה למכונות קיימות, ולכן הדפוס הוא החלפה במחזור רענון.
• ב-SMB המציאותי הוא להתחיל Intune ב-Microsoft 365 Business Premium (Intune Plan 1+Entra ID P1). אבל הרכב התוכניות ממשיך להשתנות, ויש תכונות כמו Remediations שדורשות רישיון עליון, לכן אל תבלעו את המאמר הזה נכון לאוגוסט 2026 בלי לאשר מקור ראשוני.
• מיון GPO נוכחיות אפשר לאוטט ב-Group Policy analytics. הגדרות שאפשר להעביר ממירים ל-Settings catalog; logon scripts ופריסת מדפסות בלי מקבילה מחליפים בפריסת סקריפט, הפיכה לאפליקציה או הפסקת הפעלה. ב-GPO שאינו באנגלית אחוז התמיכה עלול להיות לא מדויק.
• המעבר מתקדם בחמישה שלבים «פיילוט → מדיניות בסיס → פריסת אפליקציות → החלפה טבעית של מחשבים קיימים → צמצום תפקיד AD», ואת תנאי הסיום של כל שלב קובעים מראש.
• בהתנגשות החלה כפולה כברירת מחדל GPO מנצחת. MDMWinsOverGP הוא מנגנון מוגבל ל-Policy CSP, ולכן העיקרון הוא «לא מפיצים את אותה הגדרה משני הצדדים».
• הרגע שבו מגיעה הצעת מחיר להחלפת שרת הוא התזמון הטוב ביותר לשקול את המעבר הזה. לפני «עוד מחזור AD», חשבו איפה ייעשה שימוש במחשבים של חמש השנים הבאות.

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

• מדריך מעשי ל-Group Policy (GPO) — איך זה עובד, אישור החלה, ובחירה בין GPO ל-Intune
• ניהול Windows Update אחרי הוצאת WSUS משימוש — איך לבחור בין WUfB, Autopatch ו-Intune
• אפשרויות מעשיות אחרי סיום התמיכה ב-Windows 10 — טבלת החלטה ל-ESU, LTSC והחלפה
• אוטומציית kitting מחשבים עם winget + PowerShell — הפיכת ספר הריצה לניתן-להרצה
• מדריך מעשי ל-BitLocker — הצפנת כונן שמתחילה בניהול מפתח השחזור
• מדריך מעשי ל-Windows LAPS — הוצאת סיסמת המנהל המקומי המשותפת בכל המחשבים

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

KomuraSoft LLC מטפלת בתכנון מעבר מדורג מסביבת AD+GPO ל-Entra ID+Intune (מיון GPO נוכחיות, מדיניות שחזור הגדרות, תוכנית פיילוט), בסקירה השוואתית של החלפת שרת מול מעבר לענן, ובייעוצים שממחזרים אפליקציות עסקיות קיימות ונכסי kitting. בסדר להתחיל משקילה יחד של «האם לקנות עוד שרת AD».

• ייעוץ טכני וסקירת תכנון
• שימוש חוזר והעברה של נכסים קיימים
• יצירת קשר

קישורי עיון

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

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

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

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

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

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

שאלות נפוצות

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

אם נעבור מ-GPO ל-Intune, אפשר לשחזר כל הגדרת Group Policy שאנחנו משתמשים בה היום?

אי אפשר לשחזר את כולן. בקטלוג ההגדרות של Intune יש אלפי הגדרות Windows, כולל כאלה שמגיעות מ-ADMX, ורוב הגדרות האבטחה וההגבלות אפשר להעביר, אבל לדברים כמו מיפוי כוננים דרך logon scripts או פריסת מדפסות בכמות אין הגדרת MDM מקבילה. אם מייבאים ייצוא XML של ה-GPO הנוכחיות ל-Group Policy analytics של Intune, כל הגדרה מסווגת כ-Ready for migration, Not supported או Deprecated. להגדרות שאין להן מקבילה מכסים בפריסת סקריפט PowerShell, בהפיכת העבודה לאפליקציה, או פשוט בהפסקת ההגדרה הזאת.

איזה רישיון צריך כדי להשתמש ב-Intune?

הבסיס הוא Microsoft Intune Plan 1. אפשר להירשם אליו בנפרד, אבל ב-SMB מקובל להשתמש בו כחלק מ-Microsoft 365 Business Premium (עד 300 משתמשים). Business Premium כולל גם Entra ID P1, כך שאפשר להגיע עד שילוב compliance policy עם Conditional Access. חלק מהתכונות, כמו Remediations, דורשות בנפרד רישיון ברמת Windows Enterprise E3/E5. הרכב התוכניות משתנה לעיתים קרובות, לכן מאשרים את הפרטים העדכניים בדפי הרישוי הרשמיים של Microsoft לפני חתימה (המאמר הזה נכון לאוגוסט 2026).

חייבים להוציא את שרת ה-AD מיד?

לא. מחשבים שמנוהלים עם Entra join ו-Intune ומחשבים שמנוהלים עם domain join ל-AD ו-GPO יכולים לדור יחד באותה רשת ארגונית. מעבר מדורג — להשאיר AD לאימות file server ולמערכות עסקיות קיימות, ולעשות Entra join רק למחשבים חדשים — הוא מציאותי. לעומת זאת, אין דרך נתמכת "להמיר" מחשב שכבר מצורף ל-domain ל-Entra join; נדרש wipe (איפוס), לכן הדפוס המבוסס הוא להחליף מכונות קיימות במחזור רענון החומרה. מספיק לשקול הוצאת AD אחרי שה-GPO ריקות ומיניתם את התפקידים שנשארו.

למה Group Policy לא חלה על מחשבים לעבודה מהבית?

כי GPO נשלף וחל כשהמחשב יכול להגיע ל-domain controller. מחשב מחוץ למשרד יכול לקבל את המדיניות העדכנית רק כשהוא יכול להגיע ל-DC דרך VPN או דומה, ומחשב ביתי שלא משתמש ב-VPN למעשה לעולם לא מקבל אותה. Intune (MDM) מסנכרן מדיניות דרך האינטרנט, כך שאפשר לנהל מחשב בכל מקום; בעיית ניהול מחשבים מחוץ לאתר נפתרת במבנה של MDM. בנוסף לסנכרון מחזורי של בערך כל 8 שעות, רץ גם סנכרון מונע-הודעה כשמדיניות משתנה.

אם פורסים את אותה הגדרה גם מ-GPO וגם מ-Intune, מי מנצח?

כברירת מחדל, הגדרה מתנגשת מנצחת Group Policy. הגדרת מדיניות MDMWinsOverGP ל-1 גורמת לצד MDM (Intune) לנצח, אבל המנגנון הזה חל רק על הגדרות תחת Policy CSP; הוא לא חל על הגדרות שמוגדרות ב-CSP אחרים כמו Defender CSP. הסתמכות על בקרת קדימות הופכת התנהגות לקשה לחיזוי, לכן בפועל העיקרון הוא "לא לפרוס את אותה הגדרה משני הערוצים", ואחרי שהגדרה עברה ל-Intune מוחקים אותה מה-GPO המקורית כדי להימנע מניהול כפול.

פרופיל הכותב

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

Go Komura

מנהל KomuraSoft LLC

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