למה משתמשים מכבים את Always On והפרופיל משאיר אותו כבוי
ביטול הסימון של התחברות אוטומטית כותב את שם הפרופיל לרשימה נשמרת, ולכן התקנה מחדש עשויה לא לשחזר אותו. קראו את המצב השמור לפני עדכון.
משתמש מסיר את הסימון של התחברות אוטומטית, והפרופיל מפסיק להתחבר. חודשים לאחר מכן צוות הפריסה שולח פרופיל מעודכן עם אותו שם, מצפה שהטריגר יחזור, והוא לא חוזר. הסיבה היא שהבחירה מעולם לא הייתה רק בפרופיל: Windows תיעד את החלטת המשתמש מול שם הפרופיל הזה במצב שלו עצמו, והתקנה מחדש לא מוחקת אותו. קובץ הפרופיל הוא רק חצי מהתצורה.
מה תיבת הסימון באמת כותבת
הסרת אפשרות החיבור האוטומטי היא החלטה לכל מכשיר שנשמרת מחוץ ל-XML של הפרופיל. Microsoft מתעדת אותה כרשימת שמות פרופילים שהטריגר האוטומטי שלהם מושבת, ולכן ההגדרה שורדת גם אחרי שהפרופיל מוסר ונוסף מחדש.
העיצוב הזה הגיוני מנקודת המבט של המשתמש. מי שנמצא על חיבור עם מכסה ומכבה את החיבור האוטומטי לא מצפה שעדכון המדיניות הבא יפעיל אותו מחדש בשקט.
פירוש הדבר גם ששם הפרופיל הוא זהות, לא תווית. שני פרופילים עם אותו שם הם אותה רשומה מבחינת הרשימה הזו, ושינוי שם יוצר זהות חדשה בלי שום העדפה שמורה.
למה התקנה מחדש של הפרופיל לא מאפסת אותו
מחיקת חיבור VPN והוספתו מחדש מקובץ מעודכן מסירה ויוצרת מחדש את אובייקט הפרופיל. היא לא מסירה את הרשומה של החלטת המשתמש, מפני שהרשומה הזו מקושרת לשם ולא למזהה הפנימי של הפרופיל.
כך העדכון מגיע, הפרופיל קיים ומוגדר כראוי, והטריגר עדיין לא פועל. שום דבר בפרופיל לא מסביר את זה, ולכן זה מוסלם כאירוע פריסה שבור.
אפשר להשתמש בהתנהגות הזו במכוון: שמרו על שם הפרופיל יציב כשהעדכון אמור לשמר את אותו חיבור, ושנו אותו רק כשאתם רוצים התחלה חדשה. שינוי שם כדי לחמוק מהעדפה שמורה עובד, והוא גם משאיר את הרשומה הישנה מאחור, כך שהמכשיר צובר שמות שכבר לא תואמים דבר.
החליטו איזו מהשתיים אתם רוצים לפני שאתם נוגעים ב-XML, מפני שהשם הוא המתג.
פרופיל פעיל אחד, כמה כשירים
Windows מחיל טריגרים אוטומטיים על קבוצה מוגבלת של פרופילים, וקיומם של כמה פרופילים כשירים לא גורם לכולם להתחבר כברירות מחדל מתחרות. אחד פעיל, והאחרים ממתינים.
זה חשוב כאשר מכשיר מקבל גם פרופיל בהיקף משתמש וגם פרופיל בהיקף מכשיר עם שמות דומים. אלה אינם אותו חיבור, והאחד שמתחבר אוטומטית הוא זה שכללי הבחירה בחרו, לא בהכרח זה שבדקתם. בדיקה שעברה על הפרופיל האחר לא מוכיחה דבר על הטריגר. רשמו איזה פרופיל ענה לפני שתשנו משהו.
קראו את המצב השמור לפני עדכון
לפני שליחת כל שינוי בפרופיל, בדקו מה המכשיר מחזיק כעת: אובייקט החיבור, מצבו והרשימה השמורה של טריגרים אוטומטיים מושבתים.
הפקודות האלה מפרטות את חיבורי ה-VPN ומחפשות ברישום את הערך המתועד:
Get-VpnConnection | Select-Object Name,ConnectionStatus,SplitTunneling
reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Network /s /f AutoTriggerDisabledProfilesListרשומה שמתאימה לפרופיל שאתם עומדים לפרוס אומרת שהבחירה של המשתמש כבר תועדה. זה לא פגם שצריך לתקן בשקט; זה המצב שהמדיניות שלכם חייבת להתחשב בו.
החליטו איזו מדיניות אתם רוצים
יש שתי מדיניויות שאפשר להגן עליהן והרגל רע אחד. הראשונה מכבדת את הסירוב של המשתמש עד שהמשתמש משנה אותו, ומתעדת שהטריגר הוא המלצה במכשירים מנוהלים. השנייה מתייחסת לחיבור אוטומטי כדרישת ציות, ואז לא צריך להציע את הסירוב מלכתחילה.
ההרגל הרע הוא לכתוב מחדש מצב לא קשור כדי לכפות את הטריגר בחזרה, מה שעובד עד הרענון הבא ומשאיר את המכשיר עם הגדרות שאיש לא יכול להסביר.
רשמו את הבחירה במקום שבו הפרופיל מתוחזק, יחד עם ארבעת המעברים ששווה לבדוק: ההקצאה הראשונה, טריגר רגיל, שינוי מותר של המשתמש ועדכון לאותו שם. אוטומציה, היקף ניתוב ואכיפת מצב מנותק הם בקרות נפרדות, והתווית Always On אינה ערובה לאף אחד מהם.