השתמשו במאמר זה כדי לעזור לכם לאתר ולפתור שגיאות בסקריפטים.
פתרון תקלות בכשל בסקריפט
שלבים לאיתור תקלות כאשר סקריפט נכשל באופן כללי.
1. בדקו אם המכשיר מגיב. ניתן לעשות זאת על ידי פתיחת מודולים כמו מנהל המשימות, מנהל השירותים וכו'. אם אלו לא פועלים, ייתכן שיש בעיות רשת בין הסוכן לשרתים שלנו. קראו את המאמר פתרון תקלות בסוכן של Atera (Windows) למידע נוסף על פתרון בעיות תקשורת.
2. ודאו שהסקריפט ב-Atera משתמש בסוג הקובץ הנכון. אם הסקריפט ב-Atera משתמש בסוג קובץ שגוי, הוא ייכשל, לכן צרו מחדש את הסקריפט עם הסוג הנכון.
3. אם הסקריפט כולל קבצי התקנה כמו *.exe או *.msi, ודאו שהוספתם את הפרמטרים הנדרשים להתקנה שקטה. סקריפטים שרצים דרך Atera מבוצעים בשקט על מכשירי Windows, ולכן כשכוללים קבצי התקנה, ייתכן שתצטרכו להוסיף פרמטרים לסקריפט כדי לציין התקנה שקטה של התוכנה. אם הסקריפט לא מוגדר לכלול את הפרמטרים הדרושים להתקנה שקטה, הוא ירוץ ללא ממשק משתמש, מה שימנע מהמשתמש הסופי לתקשר עם אשף ההתקנה ולבסוף יגרום לכישלון הסקריפט.
4. שנו את אופן שליחת הרשאות הסקריפט מהקונסולה של Atera – משתמש נוכחי או מערכת, והריצו שוב את הסקריפט על אותו מכשיר.
5. בדקו את קודי היציאה של הסקריפט. אלו הם קודי היציאה הנפוצים ביותר בהם תיתקלו בעת הרצת סקריפטים מסוג batch.
| 0 | התוכנית הושלמה בהצלחה. |
| 1 | פונקציה שגויה. מציין שהפעולה ניסתה להריץ פקודה לא מזוהה ב-cmd.exe של Windows. |
| 2 | המערכת לא מצליחה למצוא את הקובץ שצוין. מציין שהקובץ לא נמצא במיקום שצוין. |
| 3 | המערכת לא מצליחה למצוא את הנתיב שצוין. מציין שהנתיב שצוין לא נמצא. |
| 5 | הגישה נדחתה. מציין שלמשתמש אין הרשאות גישה למשאב שצוין. |
עבור סקריפטים של Powershell, הפלט יספק לכם את המידע הדרוש לגבי הבעיה. קודי היציאה הנפוצים ביותר:
| 0 | התוכנית הושלמה בהצלחה. |
| 1 | הסקריפט נכשל בהרצה. |
6. ודאו שהסקריפט רץ בצורה תקינה על המחשב המקומי. אם זה נכשל, הבעיה היא בסקריפט עצמו.
- אם הסקריפט דורש הרשאות מנהל, אפשר לנסות להריץ את הסקריפט ב-Atera באמצעות "System".
עם זאת, לחשבון המערכת יש מגבלות מסוימות, ראו את סעיף Session 0. כפתרון, הריצו את הסקריפט כ"משתמש נוכחי", וודאו שלמשתמש יש הרשאות מנהל במחשב הזה. - אם הסקריפט רץ היטב מקומית, עם או בלי הרשאות מנהל, עברו לשלב הבא.
7. פנו לצוות התמיכה של Atera, וספקו להם את המידע הבא.
- שלחו לצוות התמיכה צילום מסך של הפלט בעת הרצת הסקריפט מקומית, גם עם הרשאות מנהל וגם בלי.
- הסקריפט שאתם מנסים להריץ, הסבר קצר מה הוא אמור לבצע, יחד עם הפלט מ-Atera ומהמחשב המקומי של הסקריפט.
כשל בהורדת סקריפט ממאגר Atera
כדי לתקן שגיאה זו, הריצו את הפקודות הבאות על המכשיר שלכם.
reg delete "HKEY_LOCAL_MACHINE\SOFTWARE\ATERA Networks\AlphaAgent" /v AccountId /f
rmdir "C:\Program Files\ATERA Networks\AteraAgent\Packages\AgentPackageSystemTools" /s /q
rmdir "C:\Program Files (x86)\ATERA Networks\AteraAgent\Packages\AgentPackageSystemTools" /s /q
אם הבעיה עדיין נמשכת, פנו לצוות התמיכה שלנו.
פתרון תקלות בסקריפט מהספרייה המשותפת
כשמדובר בסקריפטים שהורדו מהספרייה המשותפת, אנו יכולים להציע רק את הפעולות הבאות.
- ודאו שסוג הקובץ נכון.
- בדקו את הסקריפט גם כ-System וגם כ-Current user.
צוות התמיכה שלנו אינו מנהל/מטפל בתקלות בסקריפטים מהספרייה המשותפת, הסקריפטים נבדקים רק לזדוניות ולא לפונקציונליות.
אם יש לכם בעיה עם סקריפט מהספרייה המשותפת, פנו ליוצר הסקריפט לקבלת עזרה.
Windows Session 0
מה זה Windows Session 0 ולמה זה חשוב?
Windows Session 0 היא סשן ייחודי ב-Windows שבו כל רכיבי התוכנה, כולל ממשקי משתמש גרפיים (פופ-אפים, תיבות דו-שיח) ועוד, מאותחלים בבידוד מוחלט מהסשן הרגיל של המשתמש המחובר.
ההפרדה הזו מכוונת, מתוכננת ומיושמת על ידי מערכת ההפעלה. הבידוד הזה החל מ-Windows Vista/Server 2008 כדי להתמודד עם חששות אבטחה שונים.
היסטוריה קצרה:
-
Windows NT (1993)
נולד הרעיון של מספר סשנים במקביל. Session 0 נוצר בעת האתחול, והמשתמש הראשון שמתחבר נכנס ל-Session 0. -
Windows Vista (2007)
כדי להתמודד עם פרצות שונות, מיקרוסופט אוסרת על משתמשים להתחבר ל-Session 0. נוצר שירות "Interactive Services Detection" שמאפשר לאדמינים גישה זמנית ל-Session 0. המשתמש הראשון שמתחבר נכנס ל-Session 1. -
Windows 8 & Windows Server 2012
שירות Interactive Detection מושבת כברירת מחדל. זה מונע מכל אחד לעבור ל-Session 0 (אלא אם מעדכנים מפתח ברג'יסטרי). -
Windows 10 & Windows Server 2016
התקני קלט/פלט כבר לא עובדים ב-Session 0. ההתנהגות הזו נחשבה לבאג, אך למעשה זו הייתה פעולה מכוונת למנוע אינטראקציה עם Session 0. -
Windows 10, גרסה 1803 (2018)
שירות Interactive Services Detection הוסר רשמית. מעבר ל-Session 0 נאסר לחלוטין.
למה זה חשוב עבור Atera?
מכיוון שהסוכן שלנו הוא שירות שמריץ תהליכים, רוב התהליכים שלנו מתחילים תחת Session 0, כך שהם לא יוצגו למשתמשי הקצה שלכם. בנוסף, AteraAgent רץ כחשבון המובנה של Windows "NT Authority/System" כדי לנצל את ההרשאות שלו.
אז איך זה נראה בפועל? דוגמה נפוצה:
אתם מריצים סקריפט .bat על מחשב של משתמש קצה דרך Atera, והוא אמור ליצור תיבת דו-שיח שמחכה ללחיצה על "אישור" או "ביטול". אם הסקריפט רץ כ-"NT Authority/System", האפליקציה מחכה לקלט בחלון קופץ, אבל הממשק לא מוצג בסשן של המשתמש.
מנקודת המבט של המשתמש, האפליקציה נראית תקועה/קפואה, למרות שהיא פועלת כרגיל ופשוט מחכה לתגובה שהמשתמש לא יכול לראות.
כפי שכבר שמתם לב, זו בעיה. כפתרון, אפשר להריץ את הסקריפט כ"משתמש נוכחי", או להשתמש ב-Runas
