רענון ועדכון פוליסי Endpoint Manager

רענון מדיניות והגדרת פוליסי לתחנות קצה על גבי Intune עובד עם מנגנון CSP, ולעיתים נראה כי הפוליסי אינו מתעדכן כלל או שלוקח לפוליסי המון זמן להתעדכן. מה עושים במצבים כאלה? יש מספר אפשרויות אוטומטיות או ידניות.

ישנם דרכים שונות לרענן ולעדכן מדיניות הגדרות מתוך Intune לתחנות מבוססות Windows 10, אך לצד זה ישנם הבדלים שונים בין גרסאות שונות (ברמת בילד) של Windows 10 וניתן לחלק את ההבדלים בין מה שניתן לבצע לאחר גרסת Windwos 10 עם בילד 1903 ומעלה, לבין גרסת Windows 10 בילד 1903 ומטה.

רענון ועדכון מדיניות למכשירים נחלקת למספר סוגים ולכן ישנם הבדלים בין Windows 10, לבין MacOS ובין מכשירים חכמים, ומכאן צריך להבין כי שליחת פוליסי למערכות הפעלה עובד על גבי מנגנונים שונים וזאת בגלל סוגי מערכות הפעלה אשר מתחברות אל Intune, אך המנגנון המרכזי שבהם מנגנון CSP.

המסמכים הרשמיים של Microsoft לגבי רענון ועדכון מדיניות והגדרות למכשירים היא שונה בין מכשיר שהוא Enroll לבין מכשיר שהוא Registered, ויחד עם זה ישנם הבדלים בין מכשיר אשר קיבל נוטיפיקציה לרענון מדיניות לבין מכשיר שלא קיבל נוטיפיקציה כלל.

מתוך מאמר שאלות ותשובות לגבי סנכרון מכשירים

מהו CSP

מנגנון ניהול מדיניות ועדכונים של Intune לתחנות קצה מבוססות Windows 10  נעשה על גבי מנגנון Configuration Service Provider (בקצרה CSP) מתוך השירות של Intune. רכיב CSP קיים בנוסף בתוך Windows 10, ולכן תצורת העבודה דומה מאוד לרכיב Client Side Extension של Group Policy.

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

הערה: גם במערכות הפעלה מבוססות Windows 10 ישנם הבדלים בין הבילדים השונים.

למשל, אם נקח לדוגמה מבנה CSP של הגדרת ביטלוקר נוכל להבין כי ברגע שמגדירים פוליסי מסוג ביטלוקר ישנם הגדרות נוספות הקשורות לפוליסי זה ובפרט הגדרות BitLocker CSP, וכמו כל הגדרה אנו מדברים על הגדרות עם ערך של 0 או 1 ברמת התחנה.

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

מאחורי הקלעים של מנגנון CSP עובד מנגנון Open Mobile Alliance – Uniform Resource Identifier או בשמו הקצר OMA-URI, שמנגיש את כל ההגדרות בממשק פשוט לתפעול ורכיב OMA-URI בנוי על הגדרות ברמת מכשיר, משתמש, סוגי מערכות הפעלה, סוג פוליסי (Configuration, Compliance, App) ולכן בכל הגדרה ישנו נתיב ארוךהבנוי על אותם הגדרות, למשל >>> ./Vendor/MSFT/Policy/Config/DeviceLock/EnforceLockScreenAndLogonImage

ומה קורה כאשר ישנם הגדרות או פוליסי שאינם קיימים ברמת CSP? תמיד אפשר להשתמש עם מנגנון Custom OMA-URI אשר מכיל Data Type רבים ואפשר לומר אינסופי, כלומר כל הגדרה אשר קיימת ברמת Windows 10 ניתן לדחוף מתוך Intune (בתנאי שתחנת הקצה תומכת בכך)

טיפ: החוזקה של Custom OMA-URI היא שאנו יכולים לדחוף כל הגדרה אשר נתמכת בתחנת קצה מבלי להמתין שהגדרה זאת תהיה זמינה בממשק Intune.

בנוסף לכך ניתן להחיל הגדרות באמצעות ADMX-backed policies המרחיב את האפשרויות הקיימות של CSP מול Group Policy, וניתן לאכיפה החל מגרסת Windows 10 בילד 1703.

רענון מדיניות והגדרות

בעיה מרכזית באכיפת מדיניות והגדרות Intune היא הזמן (Intervals) שבו לוקח לאכוף את ההגדרות ובגלל שכל מערכת הפעלה עובדת בצורה שונה אז עלולות להיות בעיות, ולכן חשוב לי להדגיש כי ניתן לאכוף מדיניות, להחיל הגדרות ולבצע יישום מול תחנות קצה באופן מיידי!

טיפ: זמן אכיפת מדיניות וסנכרון שונה בתצורות Intune שונות, כלומר ישנם הבדלים בין מצב Standalone לבין Hybrid.

כאשר תחנות קצה מבוססות Widnows 10 מחוברות מול שירות Intune במצב של Enroll הם מבצעות טריגר מסוים בכדי לקבל פוליסי (MDM Refresh Policy), כל אותם טריגרים יכולים להיות מצד התחנה או שירות Intune.

ישנם מספר טריגרים ובמאמר הזה נתמד בשלושה עיקריים:

• Intune Notification – מגיע מתוך שירות Intune
• מצב ידני – נעשה ידנית מתוך תחנת הקצה
• מתוזמן – נעשה באופן אוטומטי מתוך תחנת הקצה

ישנם מצבים נוספים של שליחת טריגרים באמצעות PowerShell מתוך תחנת הקצה או שירות Intune באופן אוטומטי, או הגדרת ערך ברישום (Registry) שיבצע סנכרון מדיניות כל פרק זמן מסוים.

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

התראות

הטריגר על גבי נוטיפיקציות עובד בצורה כזאת שניתן לבצע טריגר מתוך ממשק Intune והפעולות הבאות מתרחשות ברגע:

1. מתבצע טריגר מתוך הממשק
2. Intune מצבע בדיקה האם התחנה זמינה
3. במידה והתחנה זמינה נוצר קשר על פרוטוקול SyncML
4. תחנת הקצה מבצע Device Checked-in מול שירות Intune
5. Intune מבצע בדיקה לגבי הבקשה ולאחר מכן שולח את המדיניות (התקנת אפליקציה, שינוי הגדרות וכן הלאה)
6. אכיפת המדיניות נעשית בהתאם לבקשה ובמידה ומדובר על התקנת אפליקציה תתבצע בדיקה האם ישנו Intune Extnsion ולאחר מכן תתבצע הפעולה, במידה ואין Intune Extenstion יותקן Agent ורק לאחר מכן תתבצע הפעולה

טיפ: פרוטוקול SyncML הוא פרוטוקול שמיועד לבצע תקשורת בין תחנת הקצה לבין שירות Intune במטרה להעביר בקשות ולאכוף מדיניות, ולכן Intune מתמש בפרוטוקול זה בשביל לאפשר תקשורת מול פרוטוקול נוסף והוא OMA-DM.

כאשר מתבצע Device Checked-in ישנם הבדלים בין אכיפת מדיניות מבוססת משתמש או מערכת.

מצב ידני

סנכרון ידני או ביצוע טריגר ידני הוא למעשה נישתי כי לרוב אדמינים משתמשים בו וניתן לבצע מתוך התחנה באמצעות Settings < Access Work > Sync, ובמצב כזה נכנס לפעולה  omadmclient.exe שמתחיל לבצע פעולות סנכרון מול שירות Intune.

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

מצב ידני נחלק לשניים:

• סנכרון ידני באמצעות Settings Panel
• סנכרון ידני באמצעות Company Portal

בשני המצבים נעשה ייעשו אותן פעולות של יצירת תקשורת באמצעות MDM על גבי OMA-DM עם מזהה EnrollmentID של התחנה מול שירות Intune בשמהלכה תתבצע הזדהות, בדיקות שונות של Intune מול תחנת הקצה ורק לאחר מכן יתחיל הסנכרון ועדכון מדיניות מול התחנה.

סנכרון מתוזמן

המצב האידיאלי והמומלץ שצריכים לעבוד איתו הוא סנכרון מתוזמן, ולאחר ביצוע Enroll של תחנת קצה אל שירות Intune מתרחשים מספר אירועים מאחורי הקלעים ואחד מהם הוא יצירת שלושה scheduled tasks שמבצעים טריגר מול שירות Intune.

טיפ: נמצאים בתיקיית Task Scheduler at Microsoft > Windows > EnterpriseMgmt > tenantId

המשימות שנוצרו מוגדרות עם שלושה פרמטרים שונים:

• הראשון לביצוע טריגר כל 3 דקות בפרק זמן של 15 דקות
• השני לביצוע טריגר כל 15 דקות בפרק זמן של שעתיים
• והשלישי לביצוע טריגר כל 8 שעות

טיפ: לא מומלץ ולא נתמך לגעת בהגדרות המתוזמנות שנוצרות לאחר ביצוע Enroll, וכן ניתן להגדיר חדשות על סמך אותם פרמטרים.

במהלך ביצוע הטריגר נכנסת לפעולה הותכנית deviceenroller.exe לפי הגדרות התזמון, ומבצע בדיקה של הפוליסי גם לאחר החלת הפוליסי (CSP).

דוגמה לפקודות אשר רצות בכל תזמון

Schedule 1 >>> created by the enrollment client %windir%\system32\deviceenroller.exe /o “{enrollmentId}” /c
Schedule 2 >>> created by the enrollment client %windir%\system32\deviceenroller.exe /o “{enrollmentId}” /c
Schedule 3 >>> created by the enrollment client %windir%\system32\deviceenroller.exe /o “{enrollmentId}” /c /b

לסיכום

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