מדוע הכניסה דרך VPN נגררת: פרופיל, הפניה או קבצים לא מקוונים

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

שלוש המתנות ושלושה אחראים שונים

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

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

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

מדדו מי באמת ממתין

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

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

Get-CimInstance Win32_UserProfile | Select-Object LocalPath, Loaded, SID
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\*' | Select-Object ProfileImagePath
Measure-Command { Get-ChildItem '\\fs01.corp.internal\profiles\a.singh' | Out-Null }

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

החיבור מגיע אחרי שההמתנה התחילה

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

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

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

השאירו מסמכים מחוץ לפרופיל

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

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

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

בדקו את כל ארבעת התרחישים לפני שתכריזו שזה תוקן

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

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

Get-WinEvent -LogName 'Microsoft-Windows-User Profile Service/Operational' -MaxEvents 30
gpresult /r /scope:user
Measure-Command { Get-ChildItem '\\fs01.corp.internal\users\a.singh\Documents' | Out-Null }

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