התחברות ל-VPN אינה מריצה מחדש את סקריפט הכניסה שלכם

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

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

סקריפטים רוכבים על אירועי מחזור חיים שאינכם יכולים להריץ מחדש

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

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

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

קשרו את העבודה לחיבור, לא לכניסה

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

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

בדקו מוכנות לפני פעולה, והיכשלו בקול רם

אירוע חיבור יכול להגיע לפני ש-DNS או שרת הקבצים שמישים, ולכן המשימה צריכה לבדוק את מה שהיא צריכה במקום להניח. פתרו את השם המסוים, נסו את החיבור המסוים, ונסו שוב עם גבול ועיכוב: Resolve-DnsName files.corp.example בתוך לולאה קצרה מפריד בין עדיין-לא לבין לעולם-לא. דווחו על כשל ממשי אחרי הניסיון האחרון, עם השם והשגיאה בתוכו.

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

אמתו ארבעה דברים, ואז הפכו את זה לחזרתי

במהלך הפיילוט רשמו ארבע תצפיות במקום אחת: אירוע החיבור נורה, המשימה החלה, המשאב ענה, והשינוי המבוקש באמת התקבל. אם היומן עוצר בהמשימה החלה, הכשל האמיתי נשאר בלתי נראה ולא משנה כמה תמתינו. אחר כך הריצו gpresult /scope user /v כדי לראות איזו מדיניות ההפעלה חושבת שיש לה, והשוו למוגדר שציפיתם לו. דוח שמפרט את ה-GPO כמיושם עדיין אינו אומר דבר על מיפוי.

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

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