מ-Group Policy ל-Intune — מדריך מיגרציית ניהול מכשירים לעסקים קטנים ובינוניים

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

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

flowchart TB
    accTitle: ההנחה שנשברה והמעבר במרכז הכובד
    accDescr: AD ו-GPO מניחים שהמחשב ב-LAN הארגוני ויכול תמיד להגיע לבקר דומיין, אבל מחשבים ניידים ועבודה מרחוק כנורמה שברו את ההנחה, ועם הוצאת 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 ומחשבים מצורפי-דומיין AD ועוד GPO יכולים לדור יחד באותה חברה,² ומיגרציה מדורגת אפשרית: להשאיר AD לשרת הקבצים, ולהעביר מחשבים חדשים לניהול Intune. מיועד לאנשי IT ולבעלי עסקים בעסקים קטנים ובינוניים, המאמר הזה מסדר — מעוגן במקורות ראשוניים כמו Microsoft Learn נכון לאוגוסט 2026 — את ההבדלים באיך GPO ו-MDM עובדים, את התצורות המוקדמות, רישוי, איך למנות GPO נוכחיות, תרחיש מיגרציה מדורגת והמלכודות.

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

• GPO חלה כשהמחשב מחובר לרשת הדומיין; Intune ‏(MDM) מסנכרן דרך האינטרנט. הבעיה ש”הגדרות אף פעם לא מגיעות למחשב ביתי” לא מתעוררת מבנית עם MDM. סנכרון מצב יציב הוא בערך כל 8 שעות, ורץ גם סנכרון מונע-הודעה כשמדיניות משתנה.³
• מיגרציה אינה הכול-או-לא-כלום; מיגרציה מדורגת שמניחה דו-קיום היא התשובה המציאותית. Microsoft עצמה ממליצה לעשות Entra join למחשבים חדשים, ולהשאיר מחשבים מצורפי-דומיין קיימים כ-hybrid join ולהחליף אותם במחזור רענון החומרה.²
• אפשר להירשם ל-Intune בנפרד, אבל לעסקים קטנים ובינוניים הנתיב המציאותי הוא להשתמש ב-Intune Plan 1 הכלול ב-Microsoft 365 Business Premium (נכון לאוגוסט 2026). הרכב התוכניות ממשיך להשתנות, לכן תמיד מאשרים מקורות ראשוניים לפני חתימה.⁴⁵
• כדי למנות GPO נוכחיות, משתמשים ב-Group Policy analytics המובנה של Intune. מייבאים ייצוא XML של GPO וכל הגדרה מסווגת לפי האם אפשר למגר; הגדרות שיש להן מקבילה אפשר להמיר למדיניות קטלוג הגדרות.⁶
• העבודות העיקריות של עידן ה-GPO כמעט לכולן יש מקבילה ב-Intune. תבניות ניהול ממופות לקטלוג ההגדרות,⁷ WSUS ל-Windows Update for Business, מפתחות שחזור BitLocker לאחסון ב-Entra ID,⁸ סיסמאות מנהל מקומי ל-Windows LAPS,⁹ ופריסת אפליקציות לאפליקציות Win32 ‏(.intunewin)¹⁰ ולאפליקציות Microsoft Store (מבוססות-winget).¹¹
• הדברים הקלאסיים שלא עוברים כמו שהם הם סקריפטי התחברות, מיפוי כוננים ופריסת מדפסות. מחליפים אותם בפריסת סקריפט PowerShell,¹² ‏Remediations (לשעבר Proactive remediations),¹³ הפיכת העבודה לאפליקציה, או “הפסקת הפרקטיקה הזאת”.
• לא פורסים את אותה הגדרה גם מ-GPO וגם מ-MDM. כברירת מחדל GPO מנצחת בהתנגשות. הגדרת MDMWinsOverGP ל-1 גורמת ל-MDM לנצח, אבל היא חלה רק על הגדרות Policy CSP.¹⁴
• מכונות מצורפות-דומיין ומכונות מצורפות-Entra יכולות לדור יחד, ומכונה מצורפת-Entra יכולה לגשת לשרת קבצים מקומי. הוצאה מיידית של AD אינה תנאי למיגרציה.²

במשפט אחד: את השאלה “האם להחליף את שרת ה-AD לעוד מחזור” צריך לנסח מחדש כ”לחמש השנים הבאות, במה ננהל מחשבים שיושבים מחוץ למשרד” ולהחליט על הבסיס הזה.

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

איור 2: מנסחים מחדש את שאלת החלפת השרת כ”לחמש השנים הבאות, במה ננהל מחשבים שיושבים מחוץ למשרד” ומחליטים על הבסיס הזה.

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

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

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

flowchart TB
    accTitle: הבחירה בין להשאיר GPO בחיים למיגרציה ל-MDM
    accDescr: GPO לא מגיעה למחשב ביתי כי הנחת התכנון כבר לא תואמת איך אנשים עובדים היום, ונתיב כפיית VPN תמיד-מחובר כדי להשאיר GPO בחיים הוא בחירה לקחת תחזוקה של פיסת תשתית נפרדת, פלטפורמת ה-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 חלה רק כשהמחשב יכול להתחבר לבקר דומיין פנימי, לכן מחשב ביתי תלוי ב-VPN; Intune מסנכרן דרך האינטרנט בערך כל 8 שעות ומסנכרן גם בהודעה כשמדיניות משתנה, כך שהיא מגיעה למחשב בכל מקום
    officepc["מחשב פנימי"] --> dc["בקר דומיין"]
    officepc -.-> when["הפעלה והתחברות"]
    when -.-> when2["ועוד רענון מחזורי"]
    homepc["מחשב ביתי"] --> vpn{"מגיע ל-DC דרך VPN?"}
    vpn -->|"כן"| dc
    vpn -->|"לא"| miss["המדיניות אף פעם לא מגיעה"]
    anypc["מחשב בכל מקום"] --> intune["שירות Intune"]
    anypc -.-> every["סנכרון בערך כל 8 שעות"]
    intune -.-> notify["שינוי מונע-הודעה"]
    dc ~~~ homepc
    miss ~~~ anypc

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

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

יש שלוש צורות של “איך מחשב Windows מצטרף לחברה”, והבחירה קובעת אילו כלי ניהול אפשר להשתמש בהם.²

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

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

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

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

ממה שלמעלה, אפשר לנסח יעד מציאותי לעסק קטן או בינוני כך.

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

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

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

מכונות מצורפות-Entra ומכונות מצורפות-דומיין יכולות לדור יחד באותה סביבה, ומכונה מצורפת-Entra יכולה לגשת לנכסים פנימיים כמו שרת קבצים מקומי.² עם זאת, לכניסה יחידה הזאת יש שני תנאים מוקדמים. (1) המשתמש הוא זהות היברידית שמסונכרנת מ-AD מקומי עם Entra Connect (או Cloud Sync) (משתמש שקיים רק בענן לא יכול לקבל אישורי Kerberos/NTLM של AD), ו(2) למחשב יש נגישות רשת לבקר דומיין (מחוץ לאתר נדרש VPN או דומה).¹⁵ בתוכנית המיגרציה, מאשרים קודם שאין משתמשים או תרחישי שימוש שנכשלים בשתי הנקודות האלה.

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

איור 7: ל-SSO ממכונה מצורפת-Entra לנכסים מקומיים יש שני תנאים: זהות היברידית ונגישות לבקר דומיין.

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

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

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

flowchart TB
    accTitle: איך תוכניות לעסקים קטנים ובינוניים קשורות ל-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 מוצגת בטבלת מיפוי.

כמה הערות.

• קטלוג ההגדרות הוא מסך שמקביל ל”מהדורת הענן של עורך ה-GPO”, ו-Microsoft עצמה ממקמת אותו כ”יעד המיגרציה הטבעי כשרוצים להגדיר באותה רזולוציה כמו GPO מקומית”. הוא כולל מדיניות מגובה-ADMX (מהדורת MDM של הגדרות שמוגדרות ב-ADMX), ויש גם תכונה (תצוגה מקדימה) לייבוא ADMX של צד שלישי.⁷
• מדיניות תאימות ועוד Conditional Access היא רעיון שלא היה ל-GPO. מגדירים תנאי תאימות כמו “BitLocker דולק, מערכת ההפעלה עדכנית, Defender רץ” ואפשר לחסום גישת Microsoft 365 ממכשירים שלא עומדים בהם. Conditional Access היא תכונת Entra ID P1 והיא כלולה ב-Business Premium.¹⁶
• Remediations שונה שמה מ-Proactive remediations. זה מנגנון שמריץ מחזורית זוג סקריפט-זיהוי ועוד סקריפט-תיקון, והוא יכול להחליף את סוג תפעול ה-GPO ש”מתקן משהו בכל התחברות”, אבל כאמור דורש רישיון ברמת Windows Enterprise E3/E5.¹³ בהיקף Business Premium, התחליף המציאותי הוא לשלב סקריפטי פלטפורמה (רצים כשהסקריפט או ההקצאה משתנים, ומנסים שוב בכשל)¹² עם כללי זיהוי של אפליקציות Win32.
• הבחירות המפורטות לניהול עדכונים (החלטה בין WUfB, Autopatch והמשך WSUS) מכוסות ב”ניהול Windows Update אחרי הוצאת WSUS משימוש”, ותכנון BitLocker ו-LAPS ב”מדריך מעשי ל-BitLocker” וב”מדריך מעשי ל-Windows LAPS” בהתאמה.

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

איור 10: שיפוט מצב התאימות הוא עבודת מדיניות תאימות; החסימה היא עבודת Conditional Access. רק בשילוב החסימה נכנסת לתוקף.

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

העבודה האמיתית הראשונה של תוכנית מיגרציה היא מינוי GPO נוכחיות. ל-Intune יש תכונה ייעודית, Group Policy analytics, שיכולה לסווג, לפי הגדרה, “האם MDM יכול להחליף את זה” בלי לקרוא GPO ביד.⁶

השלבים הם כדלקמן.⁶

1. פותחים את Group Policy Management Console ‏(GPMC.msc) בבקר דומיין או דומה, לוחצים ימנית על ה-GPO היעד ← Save Report ומייצאים כקובץ XML (4 MB או פחות לקובץ)
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 אפשר להמיר כמו שהן למדיניות קטלוג הגדרות ולפרוס

flowchart TB
    accTitle: זרימת המינוי עם Group Policy analytics
    accDescr: מייצאים GPO כ-XML מ-GPMC ומייבאים ל-Intune; אחוז תמיכת MDM ומוכנות מיגרציה לפי הגדרה מוצגים, והגדרות Ready for migration אפשר להמיר למדיניות קטלוג הגדרות
    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["ממירים למדיניות קטלוג הגדרות"]

איור 11: מייצוא XML דרך ייבוא, סיווג לפי הגדרה והמרה לקטלוג ההגדרות — זו זרימת Group Policy analytics.

יש זהירות חשובה בסביבות יפניות. ניתוח הגדרות שאינן-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 שעדיין תצטרכו. ממירים אותן לקטלוג ההגדרות ומאמתים עם קבוצת פיילוט.
3. הגדרות שעבורן מתכננים תחליף — אלה מבין Not supported שעדיין תצטרכו. דוגמאות מייצגות וכיווני החלפה הם כדלקמן.

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

איור 13: מפצלים תוצאות מינוי לשלוש הערמות “לזרוק”, “להעביר ל-Intune” ו”לתכנן תחליף”.

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

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

flowchart TB
    accTitle: תרחיש מיגרציה בחמישה שלבים
    accDescr: מתקדמים בשלבים מהפיילוט דרך מדיניות בסיס, פריסת אפליקציות, החלפת מחשבים קיימים במחזור רענון החומרה וכיווץ תפקיד AD, ולבסוף מביאים הגדרות שנפרסו דרך GPO לאפס
    s1["（1）פיילוט"] --> s2["（2）מדיניות בסיס"]
    s2 --> s3["（3）פריסת אפליקציות"]
    s3 --> s4["（4）החלפה טבעית של מחשבים קיימים"]
    s4 --> s5["（5）כיווץ תפקיד AD"]
    s5 -.-> goal["הגדרות שנפרסו דרך GPO הן אפס"]

איור 14: מקדמים את המיגרציה בחמישה שלבים מהפיילוט דרך כיווץ תפקיד AD, ומחליטים את קריטריון היציאה של כל שלב מראש.

נקודות המפתח של כל שלב.

• (1) פיילוט מתחיל במחשב שהייתם קונים בכל מקרה — מחשב העובד החדש הבא, החלפת תקלה/תיקון וכדומה. התחלה ממכונה חדשה יש לה את היתרון שאפשר להתחיל בהשקעה נוספת אפס, ואם זה נכשל אפשר לעשות wipe ולהתחיל מחדש. ברגע שהספירה גדלה, שוקלים להשתמש ב-Windows Autopilot כדי לאוטומט מ-OOBE (הגדרה ראשונית) דרך Entra join ועוד רישום Intune.²
• ב(2) מדיניות בסיס, לא שואפים לשחזר כל הגדרת GPO. קודם מצמצמים לחמשת: עדכון, הצפנה, Defender, נעילת מסך ו-LAPS, וממחישים מצב תאימות עם מדיניות תאימות. הפעלת “מכשירים תואמים בלבד” ב-Conditional Access באה אחרי שאישרתם שאין חיוביים כוזבים בפיילוט.¹⁶
• (3) פריסת אפליקציות רציפה עם אוטומציית קיטינג. אם כבר יש הליך מבוסס-winget במקום (“אוטומציית קיטינג מחשבים עם winget + PowerShell”), הנכס הזה יכול להיות ממוחזר כמעט כמו שהוא כעטיפת אפליקציית Store (חדשה) או אפליקציית Win32.¹¹
• (4) מחשבים קיימים, כמו שאמר פרק 3, אין נתיב המרה ל-Entra join, לכן העיקרון הוא החלפה טבעית. ארגונים שעדיין יש להם תוכנית החלפת Windows 10 (“אפשרויות מעשיות אחרי סיום התמיכה ב-Windows 10”) יכולים להימנע מלעשות את העבודה פעמיים בקידום ההחלפה הזאת באותו זמן עם (4).
• ב(5) כיווץ תפקיד AD, ריקון GPO לא אומר בהכרח ש-AD מיותר מיד. אם אימות שרת קבצים, חיפושי LDAP מאפליקציות מדור קודם וכדומה נשארים, AD ממשיך בצורה מכווצת כ”שרת אימות”. מינוי אלה וקביעת מועדים הם העבודה של השלב הזה.

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

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

8. המלכודות

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

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

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 היא גם הפנקס לזה.

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

רבים מהמקומות שמיגרציה נתקעת בהם אינם תכונות Intune אלא קישוריות לנכסים מקומיים. הגישה עצמה ממכונה מצורפת-Entra לשרת קבצים מקומי אפשרית,² אבל אם מיפוי כוננים ופריסת מדפסות היו תלויים בסקריפט התחברות של GPO, אמצעי הפריסה הזה נעלם קודם. מחליטים במהלך הפיילוט אם לקפל מיגרציית שיתוף ל-OneDrive/SharePoint או החלפה ב-Universal Print לשלב (3), או לגשר לעת עתה בפריסת סקריפט.¹²

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

איור 17: פריסות שתלויות בסקריפט התחברות מאבדות את האמצעי שלהן קודם במיגרציה, לכן מחליטים על התחליף במהלך הפיילוט.

8.3. עיצוב מחדש של קיטינג — Autopilot אינו “חובה”

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

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

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

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

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

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

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

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

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

• מצמצמים את פריטי הניהול מההתחלה. אם מנסים להביא כל הגדרת עידן-GPO, תתישו את עצמכם על המינוי לבדו. מתחילים מחמשת של פרק 7 (2) (עדכון, הצפנה, Defender, נעילת מסך, LAPS) ועושים “תכנון חיסור” שמוסיף הגדרה רק כשהצורך מתעורר. קטלוג ההגדרות מציע אלפי הגדרות,⁷ אבל אין חובה להשתמש בהן.
• מחליטים על תמונת מחשב סטנדרטית אחת. מתחזקים רק סטנדרט אחד: “מחשב בחברה הזאת הוא הסט הזה של מדיניות והסט הזה של אפליקציות”. חריגות מחלקתיות אפשר לבטא בקבוצות ובמסננים, אבל ככל שהחריגות גדלות כך אדם אחד פחות יכול לעמוד בקצב.
• מבקשים משותף חיצוני את התכנון ואת יצירת התבניות; משאירים תפעול יום-יומי בפנים. מיקור החוץ של מיגרציית Intune שנכשל בקלות הוא המקרה שבו זורקים את הבנייה מעבר לקיר ומסיימים במצב שבו “אף אחד לא מבין מה המסכים הניהוליים אומרים”. מבקשים מהחוץ את התכנון הראשוני, תבניות מדיניות ולוח תהודה להחלטות מיגרציה, ועושים ליעד מצב שבו אפשר להוסיף מחשב ולכוונן מדיניות בעצמכם יום-יום. במילים אחרות, צריך לבחור שותף שימסור עד לשם.
• משנים דבר אחד בכל פעם. עושים שינויי מדיניות אחד-אחד, ועוברים רק אחרי שאישרתם את התוצאה בדוחות Intune (מצב החלת מדיניות וכשלי הקצאה). סנכרון MDM הוא במחזור של כ-8 שעות,³ ורוב “זה לא חל” הוא עניין של זמן, לא תקלה.

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

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

10. סיכום

• GPO הוא מנגנון שמניח נגישות לבקר דומיין, והוא מבנית לא מגיע למחשבים מחוץ לאתר. Intune ‏(MDM) מסנכרן דרך האינטרנט, ולכן פותר את הבעיה הזאת מן השורש.
• מיגרציה אינה הכול-או-לא-כלום. מכונות מצורפות-Entra ומכונות מצורפות-דומיין יכולות לדור יחד, ומיגרציה מדורגת שמעבירה מחשבים חדשים ל-Entra join ועוד Intune היא התשובה המציאותית לעסקים קטנים ובינוניים. אין נתיב המרה למכונות קיימות, לכן החלפה במחזור רענון החומרה היא הדפוס המבוסס.
• לעסקים קטנים ובינוניים, התחלת Intune עם Microsoft 365 Business Premium ‏(Intune Plan 1 ועוד Entra ID P1) מציאותית. הרכב התוכניות ממשיך להשתנות, עם זאת, וחלק מהתכונות כמו Remediations דורשות רישיון גבוה יותר, לכן אל תיקחו את מאמר אוגוסט 2026 הזה כבשורה; מאשרים מקורות ראשוניים.
• מינוי GPO נוכחיות אפשר לאוטומט עם Group Policy analytics. ממירים הגדרות Ready for migration לקטלוג ההגדרות, ומחליפים סקריפטי התחברות ופריסת מדפסות שאין להן מקבילה בפריסת סקריפט, בהפיכת העבודה לאפליקציה, או בהפסקת הפרקטיקה. שימו לב שב-GPO יפנית אחוז התמיכה יכול להיות לא-מדויק.
• מקדמים את המיגרציה בחמשת השלבים “פיילוט ← מדיניות בסיס ← פריסת אפליקציות ← החלפה טבעית של מחשבים קיימים ← כיווץ תפקיד AD”, ומחליטים את קריטריון היציאה של כל שלב קודם.
• התנגשות החלה כפולה מנצחת GPO כברירת מחדל. MDMWinsOverGP הוא מנגנון Policy CSP בלבד, לכן העיקרון הוא “לא לפרוס את אותה הגדרה משניהם”.
• כשמגיעה הצעת החלפת שרת זה הזמן הטוב ביותר לשקול את המיגרציה הזאת. לפני “עוד מחזור של AD”, חושבים איפה ייעשה שימוש במחשבים של חמש השנים הבאות.

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

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

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

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

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

קישורים

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

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

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

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

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

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

שאלות נפוצות

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

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

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

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

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

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

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

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

כי GPO נשלף וחל כשהמחשב יכול להגיע לבקר דומיין. מחשב מחוץ למשרד יכול לקבל את המדיניות העדכנית רק כשהוא יכול להגיע לבקר דומיין דרך 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, ייעוץ טכני וחקירת תקלות, בעיקר בפרויקטים עם מערכות קיימות ובאגים שקשה לשחזר.