מבוא לפרופיל המשתמש ב-Windows - AppData ו-NTUSER.DAT

המאמר הזה נכתב כמידע כללי עבור צוותי IT שמנהלים Windows, אחראי פריסת מחשבים, ומפתחי אפליקציות Windows. התרשימים הם תרשימי מושג. בסביבת Markdown שתומכת ב-Mermaid הם יוצגו כתרשים.

התוכן מבוסס על מידע רשמי של Microsoft שניתן היה לאמת נכון לאפריל 2026.[1][4][7][10][13][14]

מדריך קריאה

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

בפניות בנושא Windows, המילה “פרופיל” משמשת בטווח רחב למדי.

• מה תוכן C:\Users\שם_משתמש
• איך מחלקים בין %AppData% ל-%LocalAppData%
• מה זה פרופיל נודד בסביבת domain
• מה ההבדל בין פרופיל Mandatory לפרופיל Temporary
• מה בוחרים ב-PC משותף,‏ RDS,‏ VDI,‏ Azure Virtual Desktop
• מאיפה בודקים כשהפרופיל נשבר

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

במאמר הזה, קודם נציב נקודת מבט שרואה את פרופיל המשתמש ב-Windows כתרשים תכנון אחד, ואז נסדר לפי סדר את החלוקה של AppData, נדידה,‏ Mandatory,‏ Temporary,‏ FSLogix, ואיך בודקים כשקורית תקלה.

1. קודם כל - המסקנה

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

• פרופיל המשתמש ב-Windows הוא לא רק תיקיית C:\Users\שם_משתמש. זה סט של קבוצת קבצים + ‏hive של רישום המשתמש (‏NTUSER.DAT‏).[1]
• ב-PC מקומי רגיל, ברירת המחדל היא יצירת פרופיל מקומי. בכניסה הראשונה נוצר פרופיל חדש על בסיס C:\Users\Default.[11][12]
• לא כדאי לקבוע את מיקום השמירה של אפליקציה בשרירותיות, והכלל הבסיסי הוא הגדרות שרוצים לשאת לכל מקום לפי משתמש - ב-%APPDATA%, מטמון או מצב זמני שמיוחד ל-PC הזה - ב-%LOCALAPPDATA%.[2][3]
• פרופיל נודד הוא מנגנון “מטים את כל הפרופיל לצד המשותף”, ו-Folder Redirection הוא מנגנון “מטים רק תיקייה מוכרת כמו Documents למקום אחר” - הם לא זהים.[4][5]
• פרופיל Mandatory הוא פרופיל לקריאה בלבד ל”נותנים להשתמש אבל לא שומרים”. פרופיל Temporary הוא מוצא חירום בזמן שגיאה, ומניח שהוא נמחק בכל פעם.[7][8][9]
• פרופיל נודד שחוצה דורות מערכת הפעלה דורש זהירות. יש אי-תאימות בין Windows 10 /‏ Server 2016 ואילך לבין הגרסאות שלפני כן, וכדאי לחשוב מתוך הנחה שמפרידים בין גרסאות פרופיל.[6]
• ב-RDS /‏ VDI /‏ Azure Virtual Desktop, יש הרבה מצבים שבהם עדיף לשקול כמועמד ראשון את מכולת הפרופיל של FSLogix, במקום להסתמך לבד על פרופיל נודד מסורתי. גם Microsoft ממליצה על FSLogix ב-Azure Virtual Desktop.[13][14]
• בזמן תקלה, לפני שנוגעים ישירות ב-C:\Users, נכון יותר להסתכל על יומן Application, יומן Operational /‏ Diagnostic של User Profile Service, נתיב משותף, ומאפיין והרשאות של NTUSER.DAT /‏ USRCLASS.DAT.[10][11][16]

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

1.1 קיצורים שבשימוש במאמר הזה

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

מפת הידע של המאמר

פרופיל המשתמש ב-Windows בנוי משתי שכבות - קבוצת קבצים כמו Desktop ו-AppData, ו-hive של רישום המשתמש בשם NTUSER.DAT - ונוצר בכניסה הראשונה על בסיס C:\Users\Default. AppData מתחלק ל-Roaming,‏ Local ו-LocalLow, ומחלקים את מיקום השמירה בין הגדרות שרוצים לשאת, מטמון ייחודי ל-PC, ושטח ייעודי לתהליכים ברמת שלמות נמוכה. פרופיל מקומי הוא הבסיס, ופרופיל נודד משמש כשרוצים לשתף הגדרות בכמה PC, Folder Redirection כשרוצים ניהול מרכזי רק למסמכים, ומכולת הפרופיל של FSLogix מומלצת ב-RDS/VDI/Azure Virtual Desktop. פרופיל Mandatory מתאים למחשבי חינוך ו-kiosk, ובעיית הרשאות ב-NTUSER.DAT או אירוע 1509 מנתיב ארוך הם סיבות אופייניות להפיכה לפרופיל זמני.

flowchart LR
    accTitle: מפת הידע של פרופיל המשתמש ב-Windows
    accDescr: תרשים שמראה שפרופיל המשתמש בנוי מ-NTUSER.DAT ומ-Roaming/Local/LocalLow של AppData, את ההבדל בין השיטות מקומי, נודד,‏ Mandatory,‏ Temporary ו-FSLogix, ואיך זה מתקשר לאירוע 1509 מנתיב ארוך ולהפיכה לפרופיל זמני.
    windows_user_profile["פרופיל המשתמש"]
    ntuser_dat["NTUSER.DAT"]
    default_profile["פרופיל ברירת המחדל (Default)"]
    copyprofile["CopyProfile"]
    roaming_appdata["%APPDATA%(Roaming)"]
    local_appdata["%LOCALAPPDATA%"]
    appdata_locallow["AppData\LocalLow"]
    low_integrity_level["רמת שלמות נמוכה"]
    local_user_profile["פרופיל מקומי"]
    roaming_user_profile["פרופיל נודד"]
    mandatory_profile["פרופיל Mandatory"]
    temporary_profile["פרופיל Temporary"]
    fslogix_profile_container["מכולת פרופיל של FSLogix"]
    profile_version_incompatibility["אי-תאימות של פרופיל נודד בין דורות מערכת הפעלה"]
    folder_redirection["Folder Redirection"]
    azure_virtual_desktop["Azure Virtual Desktop"]
    shared_pc_mode["תצורת מחשב משותף או אורח"]
    profile_auto_cleanup_policy["מדיניות מחיקה אוטומטית של פרופילים ישנים"]
    group_policy["מדיניות קבוצתית (Group Policy)"]
    event_1509["אירוע 1509 (כישלון טעינת פרופיל בנתיב ארוך)"]
    user_profile_service_log["היומן של User Profile Service"]
    windows_user_profile -->|"משתמש ב"| ntuser_dat
    windows_user_profile -.->|"מחייב"| default_profile
    default_profile -->|"מוגדר באמצעות"| copyprofile
    windows_user_profile -->|"משתמש ב"| roaming_appdata
    windows_user_profile -->|"משתמש ב"| local_appdata
    windows_user_profile -->|"משתמש ב"| appdata_locallow
    low_integrity_level -->|"משתמש ב"| appdata_locallow
    windows_user_profile -.->|"משתמש ב"| local_user_profile
    windows_user_profile -.->|"משתמש ב"| roaming_user_profile
    windows_user_profile -.->|"משתמש ב"| mandatory_profile
    windows_user_profile -.->|"משתמש ב"| temporary_profile
    windows_user_profile -.->|"משתמש ב"| fslogix_profile_container
    roaming_user_profile -.->|"עלול לגרום ל"| profile_version_incompatibility
    mandatory_profile -->|"משתמש ב"| ntuser_dat
    windows_user_profile -.->|"משתמש ב"| folder_redirection
    fslogix_profile_container -->|"מענה מומלץ ל"| azure_virtual_desktop
    roaming_user_profile -.->|"שימוש לא מומלץ ל"| azure_virtual_desktop
    windows_user_profile -.->|"משתמש ב"| shared_pc_mode
    shared_pc_mode -.->|"משתמש ב"| profile_auto_cleanup_policy
    profile_auto_cleanup_policy -->|"מוגדר באמצעות"| group_policy
    roaming_user_profile -.->|"עלול לגרום ל"| event_1509
    event_1509 -.->|"עלול לגרום ל"| temporary_profile
    temporary_profile -->|"נבדק באמצעות"| user_profile_service_log
    ntuser_dat -.->|"עלול לגרום ל"| temporary_profile

בתרשים, קו מלא מציין קשר שמתקיים תמיד וקו מקווקו מציין קשר מותנה (תנאי ההתקיימות מפורטים בהסבר של כל קשר בעמוד המפורט). רשימת כל הקשרים (סך הכול 24, עם אסמכתה ורמת ודאות) והגדרות המושגים המרכזיים מרוכזות בעמוד המפורט של מפת הידע (ביפנית). נתונים: JSON-LD / Turtle

2. בעצם, מה זה “פרופיל משתמש” ב-Windows

תחילה, נוח יותר לחשוב בנפרד על חשבון ו-פרופיל.

flowchart LR
    accTitle: ההבדל בין חשבון לפרופיל
    accDescr: תרשים שמראה שחשבון משתמש מזהה מי נכנס למערכת, שהמחשב טוען את הפרופיל, ושפרופיל המשתמש מכיל הגדרות שולחן עבודה, AppData, תיקיות כמו Documents ו-Desktop, והגדרות שנראות ב-HKCU.
    A[חשבון משתמש - מי נכנס למערכת] --> B[פרופיל משתמש - ההגדרות והנתונים]
    C[מחשב / מערכת הפעלה] --> B
    B --> D[הגדרות שולחן עבודה]
    B --> E[AppData]
    B --> F[Documents / Desktop וכדומה]
    B --> G[הגדרות שנראות ב-HKCU]

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

• חשבון מזהה מישהו
• פרופיל הוא הישות של סביבת העבודה של אותו אדם
• המכשיר הוא המקום שטוען את הפרופיל ומשתמש בו

גם ב-Microsoft Learn מוסבר שפרופיל המשתמש כולל קבוצת תיקיות פרופיל במערכת הקבצים ו-‏hive רישום NTUSER.DAT, ושבזמן הכניסה למערכת ה-hive הזה נטען ומשמש כ-HKEY_CURRENT_USER.[1]

2.1 זה לא “רק תיקייה”, אלא “כולל גם רישום”

זו נקודה חשובה.

flowchart TD
    accTitle: מה קורה בזמן הכניסה למערכת
    accDescr: תרשים שמראה שבזמן הכניסה מזהים תיקיית פרופיל, טוענים את NTUSER.DAT לשימוש כ-HKCU, ובמקביל מכינים את Desktop, Documents ו-AppData, וכששני הצדדים מוכנים הגדרות המשתמש נכנסות לתוקף.
    A[כניסה למערכת] --> B[מזהים תיקיית פרופיל]
    B --> C[טוענים את NTUSER.DAT]
    C --> D[משמש כ-HKCU]
    B --> E[מכינים Desktop / Documents / AppData]
    D --> F[הגדרות המשתמש נכנסות לתוקף]
    E --> F

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

כלומר, אם מסתכלים רק על C:\Users\שם_משתמש, זה עדיין רק חצי.

לפרופיל Windows יש בגדול שתי שכבות אלה.

1. שכבת קבצים ‏Desktop,‏ Documents,‏ Downloads,‏ AppData וכדומה
2. שכבת רישום ‏HKCU שנטען מ-NTUSER.DAT

מה שמסבך את נושא ההתקלקלות של הפרופיל הוא שיש מקרה שרק צד התיקייה נשבר ו-מקרה שהבעיה מתגלה בצד ה-hive של הרישום.[1][11]

2.2 בכניסה הראשונה, Default הוא הבסיס

כשמשתמש חדש נכנס לראשונה למחשב הזה, Windows יוצר פרופיל מקומי על בסיס C:\Users\Default.[11]

flowchart LR
    accTitle: בכניסה הראשונה, Default הוא הבסיס
    accDescr: תרשים שמראה שבכניסה הראשונה של משתמש חדש, Windows יוצר את C:\Users\שם_משתמש על בסיס C:\Users\Default, טוען את NTUSER.DAT, וכך נוצרת סביבה ייעודית לאותו משתמש.
    A[C:\Users\Default] --> B[כניסה ראשונה]
    B --> C[יוצר C:\Users\שם_משתמש]
    C --> D[טוען את NTUSER.DAT]
    D --> E[הופך לסביבה ייעודית לאותו משתמש]

איור 3: בכניסה הראשונה, Default הוא הבסיס, ונוצר פרופיל ייעודי לאותו משתמש.

אם מטפלים בזה ברשלנות בהקשר של פריסת image או kitting, זה מקשה מאוד בהמשך.

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

3. איך רואים את C:\Users\שם_משתמש

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

flowchart TD
    accTitle: מבנה תיקיית הפרופיל
    accDescr: תרשים שמראה שתיקיית C:\Users\שם_משתמש מכילה את Desktop, Documents, Downloads, Pictures, AppData ו-NTUSER.DAT, ושתיקיית AppData מתחלקת הלאה ל-Roaming, Local ו-LocalLow.
    A["C:\Users\שם_משתמש"] --> B[Desktop]
    A --> C[Documents]
    A --> D[Downloads]
    A --> E[Pictures]
    A --> F[AppData]
    A --> G[NTUSER.DAT]
    F --> H[Roaming]
    F --> I[Local]
    F --> J[LocalLow]

איור 4: הפרופיל בנוי מקבוצת תיקיות ומ-NTUSER.DAT, ו-AppData מתחלק לעוד שלושה.

המקומות הראשונים שבודקים בפועל הם בערך אלה.

3.1 מחלקים את AppData לשלושה

בפיתוח אפליקציית Windows ובחקירת תקלות, כאן המקום שהכי קל שיתערבב.

במדריך של Microsoft מומלץ להשתמש ב-FOLDERID_RoamingAppData (‏Roaming AppData) עבור נתונים ייחודיים לאפליקציה, ו-FOLDERID_LocalAppData עבור קבצים זמניים או נתונים שלא ישמשו במחשב אחר.[2]

בנוסף, בהגדרה של Known Folders, נתיבי ברירת המחדל מסודרים כך.[3]

• ‏%APPDATA% = %USERPROFILE%\AppData\Roaming
• ‏%LOCALAPPDATA% = %USERPROFILE%\AppData\Local
• ‏LocalLow = %USERPROFILE%\AppData\LocalLow

flowchart LR
    accTitle: החלוקה של AppData לשלושה
    accDescr: תרשים שמראה ש-AppData מתחלק ל-Roaming להגדרות שרוצים לשאת ומצב משתמש קטן, Local למטמון ולנתונים ייחודיים ל-PC, ו-LocalLow לשטח שתהליכים ברמת שלמות נמוכה יכולים לכתוב אליו.
    A[AppData] --> B[Roaming]
    A --> C[Local]
    A --> D[LocalLow]

    B --> B1[הגדרות שרוצים לשאת]
    B --> B2[מצב משתמש קטן]

    C --> C1[מטמון]
    C --> C2[נתונים שאפשר ליצור מחדש]
    C --> C3[מצב ייחודי לאותו PC]

    D --> D1[שטח שתהליכים עם רמת שלמות נמוכה יכולים לכתוב]

איור 5: Roaming להגדרות שרוצים לשאת, Local ייחודי ל-PC, LocalLow לתהליכים ברמת שלמות נמוכה.

‏LocalLow הוא לא “מקום שלא משתמשים בו”, אלא “מקום לאפליקציה בהרשאה נמוכה”

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

לתהליכי Windows יש דרגת הרשאה בשם רמת שלמות (integrity level), ותהליך שרץ ברמת שלמות נמוכה לא יכול לכתוב לרוב AppData\Roaming,‏ AppData\Local, או HKCU. אם כך, לא יהיה שום מקום לשמור, ולכן הוכן מקום שגם רמת שלמות נמוכה יכולה לכתוב אליו. זה %USERPROFILE%\AppData\LocalLow בצד הקבצים, ו-HKEY_CURRENT_USER\Software\AppDataLow בצד הרישום.[19]

אם מסדרים, זה נראה כך.

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

מבחינת מפתח אפליקציה, המסקנה פשוטה.

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

איך חושבים על החלוקה בפועל

גם בהגדרת ה-known folders של Microsoft, ProgramData מוגדר כ-נתוני אפליקציה לכל המשתמשים, מיועד לנתונים משותפים שלא נודדים.[3]

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

3.2 ל-Public ול-Default יש תפקידים שונים

גם כאן קל להתבלבל.

flowchart LR
    accTitle: התפקידים השונים של Default ו-Public
    accDescr: תרשים שמראה שתחת C:\Users, Default הוא הזרע ליצירת פרופיל חדש, Public הוא שטח משותף שנראה מכל המשתמשים, וכל תיקיית משתמש היא הישות של המשתמש הבודד.
    A["C:\Users"] --> B[Default]
    A --> C[Public]
    A --> D[כל משתמש]

    B --> B1[הזרע ליצירת פרופיל חדש]
    C --> C1[משותף שנראה מכל המשתמשים]
    D --> D1[הישות של המשתמש הבודד]

איור 6: Default הוא זרע ליצירה חדשה, Public הוא שטח משותף, וכל תיקיית משתמש היא ישות בודדת.

• Default הוא תבנית ליצירת פרופיל חדש
• Public הוא שטח משותף שנראה לכל המשתמשים
• כל תיקיית משתמש היא הישות הייחודית לאותו אדם

שלושת אלה נראים דומים, אבל התפקיד שלהם שונה לגמרי.

4. סידור סוגי הפרופיל

גם אם קוראים לזה “פרופיל” במילה אחת, בתפעול יש לפחות את הסוגים האלה.

flowchart TD
    accTitle: 5 סוגי הפרופיל בתפעול
    accDescr: תרשים שמראה שפרופילי Windows מתחלקים בתפעול לפרופיל מקומי, פרופיל נודד, פרופיל Mandatory, פרופיל Temporary, ומכולת פרופיל של FSLogix.
    A[פרופילי Windows] --> B[פרופיל מקומי]
    A --> C[פרופיל נודד]
    A --> D[פרופיל Mandatory]
    A --> E[פרופיל Temporary]
    A --> F[מכולת פרופיל של FSLogix]

איור 7: בתפעול יש לפחות 5 סוגי פרופיל, ממקומי ועד FSLogix.

4.1 פרופיל מקומי

ב-PC רגיל, זו ברירת המחדל.

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

גם Microsoft מסבירה שכברירת מחדל Windows יוצרת פרופיל משתמש מקומי.[14]

4.2 פרופיל נודד

לפי Microsoft Learn, פרופיל משתמש נודד נשמר בשיתוף שרת, ומאפשר לקבל את אותן הגדרות מערכת הפעלה/אפליקציה בכמה מחשבים.[4][5]

flowchart LR
    accTitle: פרופיל נודד על שרת משותף
    accDescr: תרשים שמראה שכמה מחשבים מקבלים באופן דו-כיווני פרופיל ששוכן על שרת משותף אחד.
    A[פרופיל על שרת משותף] <--> B[PC-A]
    A <--> C[PC-B]
    A <--> D[PC-C]

איור 8: פרופיל נודד הוא מנגנון שבו כמה PC מקבלים פרופיל ששוכן על שרת משותף.

עם זאת, בפועל יש נקודות תשומת לב אלה.

• ההעתקה או הסנכרון בכניסה/יציאה נוטים להכביד
• קשה אם AppData\Local מחזיק נתונים גדולים
• מקבל בקלות בעיות של הבדל בגרסת מערכת ההפעלה
• מושפע חזק מנתיב השיתוף ומאיכות הרשת

4.3 פרופיל Mandatory

פרופיל Mandatory הוא “פרופיל נודד שלא נשמר”, שהמנהל יוצר.[7][8]

לפי ההסבר של Microsoft, בפרופיל Mandatory, גם אם המשתמש משנה משהו במהלך ה-session, זה לא נשמר כמו בפרופיל נודד רגיל.[7]

בנוסף, בתיעוד Win32 מוסבר ש-

• שינוי שם NTUSER.DAT ל-NTUSER.MAN הופך אותו ל-Mandatory
• אם סיומת שם תיקיית נתיב הפרופיל מסתיימת ב-.man, זה הופך ל-Super-mandatory

.[8]

flowchart LR
    accTitle: פרופיל Mandatory לא שומר שינויים
    accDescr: תרשים שמראה שהמנהל מכין פרופיל, המשתמש נכנס ויכול לשנות תוך כדי שימוש, אבל ביציאה השינוי לא נשמר.
    A[פרופיל שהכין המנהל] --> B[המשתמש נכנס]
    B --> C[אפשר לשנות תוך כדי שימוש]
    C --> D[יציאה]
    D --> E[השינוי לא נשמר]

איור 9: Mandatory הוא פרופיל שהמנהל מכין, ושינוי בזמן השימוש לא נשמר ביציאה.

לדוגמה, זה מתאים לשימושים כאלה.

• מחשבי חינוך
• מסופי קבלה
• kiosk
• מכשירים משותפים שרוצים להחזיר למצב נקי בכל פעם

4.4 פרופיל Temporary

פרופיל Temporary הוא לא בחירה בתכנון, אלא מוצא בזמן שהפרופיל האמיתי לא נטען עקב שגיאה.[9]

לפי Microsoft Learn, כשלא ניתן לטעון את הפרופיל האמיתי בגלל תנאי שגיאה, מונפק פרופיל Temporary, שנמחק בסיום ה-session, וכל שינוי הולך לאיבוד.[9]

flowchart TD
    accTitle: פרופיל Temporary הוא מוצא בזמן כישלון טעינה
    accDescr: תרשים שמראה שאם ניתן לטעון את הפרופיל הרגיל מתבצעת כניסה רגילה, ואם לא, נכנסים עם פרופיל Temporary שאפשר לעבוד בו, אבל השינוי נעלם ביציאה.
    A[מתחילים לטעון פרופיל רגיל] --> B{ניתן לטעון?}
    B -->|כן| C[כניסה רגילה]
    B -->|לא| D[כניסה עם פרופיל Temporary]
    D --> E[אפשר לעבוד]
    E --> F[יציאה = השינוי נעלם]

איור 10: Temporary הוא מוצא בזמן כישלון טעינה, וביציאה השינוי נעלם.

כלומר, מצב שבו פועלים עם פרופיל Temporary הוא בעצמו סימן לחריגה.

4.5 מכולת הפרופיל של FSLogix

FSLogix מוסבר ב-Microsoft Learn כ-מנגנון שמאחיד את חוויית פרופיל המשתמש של Windows בסביבת שולחן עבודה וירטואלי.[13]

מכולת הפרופיל של FSLogix היא שיטה שבה כל פרופיל המשתמש מוחזק כ-VHD /‏ VHDX, ומצומד (attach) בזמן הכניסה, ונראה כמו פרופיל native.[13][14]

flowchart LR
    accTitle: FSLogix מצמיד פרופיל בזמן כניסה
    accDescr: תרשים שמראה שפרופיל שנמצא על VHD או VHDX מוצמד בזמן הכניסה, נראה כמו C:\Users\משתמש רגיל על ה-session host, ומנותק ביציאה.
    A[פרופיל על VHD / VHDX] --> B[הצמדה בזמן כניסה]
    B --> C[נראה כ-C:\Users\משתמש על ה-session host]
    C --> D[ניתוק ביציאה]

איור 11: FSLogix מצמיד בזמן הכניסה פרופיל שנמצא על VHD, ומציג אותו כ-native.

ב-Azure Virtual Desktop, Microsoft ממליצה להשתמש ב-FSLogix profile containers.[14]

5. מה ההבדל בין פרופיל נודד,‏ Folder Redirection ו-FSLogix

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

flowchart TD
    accTitle: שלוש השיטות לנשיאת מצב המשתמש
    accDescr: תרשים שמראה שנשיאת מצב המשתמש מתבצעת בשלוש שיטות - פרופיל נודד שמעביר את כל הפרופיל לשיתוף, Folder Redirection שמעביר רק תיקייה מוכרת, ו-FSLogix שמצמיד VHD או VHDX.
    A[נשיאת מצב המשתמש] --> B[פרופיל נודד]
    A --> C[Folder Redirection]
    A --> D[FSLogix]

    B --> B1[כל הפרופיל אל השיתוף]
    C --> C1[רק תיקייה מוכרת למקום אחר]
    D --> D1[הצמדת VHD/VHDX]

איור 12: שלוש השיטות שונות בהיקף מה שנושאים - הכול, רק תיקייה מוכרת, או הפיכה למכולה.

אם מיישרים לפי הסידור של Microsoft Learn, קל יותר להבין את ההבדל כך.[4][5][14]

5.1 ‏Folder Redirection מטה “רק תיקייה מוכרת”

לפי Microsoft Learn, Folder Redirection הוא מנגנון ש-מפנה את הנתיב של תיקייה מוכרת (known folder) למקום אחר.[4]

לדוגמה, אם מטים את Documents לשיתוף קבצים, המשתמש רואה את זה כמו מקומי, אבל הישות נמצאת במקום אחר.[4]

flowchart LR
    accTitle: Folder Redirection מעביר רק תיקייה
    accDescr: תרשים שמראה ש-Documents מקבל ישות בשיתוף קבצים, בעוד ש-Desktop יכול לקבל הגדרה נפרדת אם צריך, ו-AppData נשאר כמות שהוא או מטופל בשיטה אחרת.
    A[Documents] --> B[הישות בשיתוף קבצים]
    C[Desktop] --> D[הגדרה נפרדת אם צריך]
    E[AppData] --> F[נשאר כמות שהוא, או שיטה אחרת]

איור 13: Folder Redirection הוא לא חלופה לכל הפרופיל, אלא העברת מיקום ברמת תיקייה.

כלומר, Folder Redirection הוא לא תחליף לכל הפרופיל, אלא העברת מיקום ברמת תיקייה בודדת.

5.2 לא מערבבים פרופיל נודד בין דורות מערכת הפעלה ברשלנות

Microsoft מסבירה שפרופיל נודד ב-Windows 10 /‏ Server 2016 ואילך לא תואם לגרסאות Windows שלפני כן.[6]

flowchart LR
    accTitle: ערבוב דורות מערכת הפעלה בפרופיל נודד
    accDescr: תרשים שמראה שערבוב פרופיל נודד ממשפחת Windows 7/8.1 ומ-Windows 10/Server 2016 ואילך באותו שיתוף גורם לאי-עקביות, תקלות בתפריט התחל ותקלות בסרגל המשימות.
    A[משפחת Windows 7 / 8.1] -.אזהרת ערבוב.-> B[אותו שיתוף]
    C[Windows 10 / Server 2016 ואילך] -.אזהרת ערבוב.-> B
    B --> D[גורם לאי-עקביות / תקלת תפריט התחל / תקלת סרגל משימות]

איור 14: ערבוב פרופיל נודד מדורות שונים של מערכת הפעלה באותו שיתוף גורם לאי-עקביות.

מה שחשוב כאן הוא -

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

.[6]

6. מיקומי שמירה שמפתח או אחראי תפעול צריכים לקבוע מראש

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

flowchart TD
    accTitle: קביעת מיקום השמירה לפי סוג הנתונים
    accDescr: תרשים שמראה שנתונים שרוצים לשמור מסתעפים לפי הסדר - אם זה תוצר של המשתמש הולך ל-Documents, אם ייחודי ל-PC הולך ל-LOCALAPPDATA, אם הגדרה לפי משתמש הולך ל-APPDATA, ואם משותף לכל המשתמשים הולך ל-ProgramData עם ACL.
    A[נתונים שרוצים לשמור] --> B{תוצר שיצר המשתמש?}
    B -->|כן| C[Documents וכדומה]
    B -->|לא| D{ייחודי לאותו PC?}
    D -->|כן| E[%LOCALAPPDATA%]
    D -->|לא| F{הגדרה לפי משתמש?}
    F -->|כן| G[%APPDATA%]
    F -->|לא| H{נתונים משתנים משותפים לכל המשתמשים?}
    H -->|כן| I[ProgramData + ACL]
    H -->|לא| J[בודקים מחדש את המיקום]

איור 15: הנתונים שרוצים לשמור מסתעפים לפי הסדר - תוצר, ייחודי ל-PC, הגדרת משתמש, או משותף.

6.1 מפרידים בין קובץ שהמשתמש יוצר לבין מצב פנימי של האפליקציה

אם מערבבים כאן, גם גיבוי וגם מעבר נשברים בקלות.

• תוצר שהמשתמש מטפל בו במודע ‏Documents,‏ Pictures, תיקיית שמירה עסקית
• מצב פנימי של האפליקציה הגדרות, מטמון, thumbnail, מידע session, קובצי עבודה

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

flowchart TB
    accTitle: הפרדה בין תוצר למצב פנימי של האפליקציה
    accDescr: תרשים שמראה שאם לא מפרידים בין תוצר שהמשתמש מטפל בו במודע כנתון עסקי כמו Documents, לבין מצב פנימי של האפליקציה כמו הגדרות ומטמון שהוא צורך של האפליקציה, גם גיבוי וגם מעבר נשברים בקלות.
    sp1["קובץ לשמירה"] --> sp2["תוצר שהמשתמש מודע לו"]
    sp1 --> sp3["מצב פנימי של האפליקציה"]
    sp2 -.-> sp4["נתון עסקי כמו Documents"]
    sp3 -.-> sp5["הגדרות ומטמון הם צורך האפליקציה"]

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

6.2 מה שמים ב-%APPDATA%

מה ששמים כאן הוא בערך דברים כאלה.

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

גם בתיעוד Fast User Switching, מומלץ FOLDERID_RoamingAppData כמקום לנתונים ייחודיים לאפליקציה.[2]

6.3 מה שמים ב-%LOCALAPPDATA%

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

• מטמון שניתן ליצור מחדש
• מצב שיש לו משמעות רק מקומית
• קובצי עבודה גדולים
• מה שלא רוצים לשאת מתוך עדיפות לביצועים

גם בהגדרת Known Folders,‏ LocalAppData הוא %USERPROFILE%\AppData\Local.[3]

6.4 מה שמים ב-ProgramData

נתונים משותפים לכל המשתמשים, אבל שמשתנים תוך כדי ריצה - ProgramData הוא מועמד.[3]

לדוגמה,

• מילון משותף
• קובץ הגדרה משותף לכל המשתמשים
• נתונים משתנים ששירות וכמה משתמשים חולקים

עם זאת, כאן צריך לחשוב כולל תכנון ACL. לא “משותף אז שמים ב-ProgramData בפשטות”, אלא חשוב לקבוע מי קורא ומי כותב.

6.5 כשרוצים לבנות פרופיל ברירת מחדל

בפריסת image, זה רגיל לרצות “להכניס אותה הגדרה ראשונית לכל המשתמשים החדשים”. במקרה כזה, בטוח יותר לא לגעת ב-Default ברשלנות, אלא לבנות בשיטה מבוססת CopyProfile שנתמכת על ידי Microsoft.[12]

flowchart LR
    accTitle: בניית פרופיל ברירת המחדל דרך CopyProfile
    accDescr: תרשים שמראה שהגדרה ראשונית בחשבון מנהל עוברת דרך Sysprep ו-CopyProfile, מיושמת לפרופיל Default, וחלה על כל המשתמשים החדשים מכאן ואילך.
    A[הגדרה ראשונית בחשבון מנהל] --> B[Sysprep + CopyProfile]
    B --> C[מיישמים לפרופיל Default]
    C --> D[חל על משתמשים חדשים מכאן ואילך]

איור 17: בניית פרופיל ברירת המחדל נעשית דרך המסלול של Sysprep ו-CopyProfile.

שיטה כמו “מעתיקים ידנית את C:\Users\A של PC אחד ל-Default של PC אחר” נראית מהירה, אבל קל שתישבר בהמשך.[12]

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

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

7.1 קודם מחלקים לשלושה תסמינים

flowchart TD
    accTitle: חלוקת בעיית פרופיל לשלושה סוגים
    accDescr: תרשים שמראה שלפי היכולת להיכנס ולפי איפוס המראה, בעיית פרופיל מתחלקת לכישלון טעינה, הפיכה לפרופיל Temporary או התקלקלות, סוג של נדידה או הפניה או סנכרון, או בעיה ספציפית לאפליקציה.
    A[נראה כמו בעיית פרופיל] --> B{ניתן להיכנס?}
    B -->|כן| C{המראה מאותחל?}
    B -->|לא| D[סוג של כישלון טעינה]
    C -->|כן| E[Temporary / התקלקלות / פרופיל אחר]
    C -->|לא| F{רק חלק מההגדרות חוזר?}
    F -->|כן| G[סוג של נדידה / הפניה / סנכרון]
    F -->|לא| H[אפשרות של בעיה ספציפית לאפליקציה]

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

בגדול, מדובר בשלושת הסוגים האלה.

1. כישלון בזמן הכניסה למערכת
2. הכניסה מצליחה, אבל נראה כמאותחל
3. רק חלק לא מסתנכרן

7.2 היומן שכדאי לבדוק ראשית

לפי Microsoft Learn, בחקירת בעיית פרופיל, ההמלצה היא לבדוק בסדר הזה.[10]

1. יומן Application
2. יומן Operational של User Profile Service
3. אם צריך, יומן Diagnostic
4. אם צריך עוד, ‏ETL trace

הנתיבים המדויקים הם כך.[10]

• Event Viewer ‏Applications and Services Logs > Microsoft > Windows > User Profile Service > Operational
• לצפייה מפורטת יותר ‏... > User Profile Service > Diagnostic

ב-Event Viewer של גרסת Windows בעברית או ביפנית, העץ בצד שמאל נראה בערך כ-יומני יישומים ושירותים > Microsoft > Windows > User Profile Service > Operational. מתחת לשם ה-provider, זה נשאר באנגלית.

flowchart LR
    accTitle: סדר העמקת החקירה ביומנים
    accDescr: תרשים שמראה שהחקירה מעמיקה בסדר מיומן Application ליומן Operational, אחר כך ליומן Diagnostic, ולבסוף ל-ETL trace.
    A[יומן Application] --> B[יומן Operational]
    B --> C[יומן Diagnostic]
    C --> D[‏ETL trace]

איור 19: החקירה מעמיקה בסדר מ-Application ל-Operational,‏ Diagnostic, ולבסוף ETL trace.

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

3 היומנים נמצאים ב”מקומות שונים”

זו נקודה שקל להתבלבל בה בהתחלה, ולכן נסדר אותה מראש.[10]

יומן Diagnostic לא מופיע בעץ במצב ברירת המחדל. מדליקים ב-Event Viewer את חלון הפעולה > תצוגה > הצג יומני ניתוח ואיתור באגים, בוחרים אחר כך Diagnostic, ומבצעים הפעלת יומן. אחרי סיום החקירה, חובה להחזיר את זה למצב כבוי. זה יומן מפורט מדי, לא מהסוג שמשאירים דלוק כל הזמן.[10]

רואים את אותו דבר בלי לפתוח GUI

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

# 1) בודקים רק את אירועי User Profile Service מיומן Application, מהחדש לישן
Get-WinEvent -FilterHashtable @{
    LogName      = 'Application'
    ProviderName = 'Microsoft-Windows-User Profiles Service'
} -MaxEvents 50 | Select-Object TimeCreated, Id, LevelDisplayName, Message

# 2) מסתכלים ישירות על יומן Operational
Get-WinEvent -LogName 'Microsoft-Windows-User Profile Service/Operational' -MaxEvents 50 |
    Select-Object TimeCreated, Id, LevelDisplayName, Message

# 3) מסננים רק את Event ID 1509 שנגרם מנתיב ארוך
Get-WinEvent -FilterHashtable @{
    LogName      = 'Application'
    ProviderName = 'Microsoft-Windows-User Profiles Service'
    Id           = 1509
} | Format-List TimeCreated, Id, Message

יש כאן מלכודת אחת. שם המקור בצד יומן Application הוא Microsoft-Windows-User Profiles Service (‏Profiles ברבים), ושם הערוץ ביומן Operational הוא Microsoft-Windows-User Profile Service/Operational (‏Profile ביחיד). כשההעתק-הדבק לא עובד, כמעט תמיד זו הסיבה.

Event ID 1509 מופיע ביומן Application ולא ביומן Operational. הרמה היא אזהרה, וגוף ההודעה הוא בפורמט “Windows לא יכולה להעתיק את הקובץ \\server\share\... אל C:\Users\...”, ואחריו DETAIL - The filename or extension is too long. השורה האחרונה הזו היא ההוכחה המכרעת שהסיבה היא אורך הנתיב.[16]

עוד דבר שכדאי לדעת בשטח, וחוסך זמן: Microsoft מציינת במפורש ש-אירוע 1530 של User Profile Service, “קובץ הרישום עדיין בשימוש על ידי אפליקציה או שירות אחר”, מותר להתעלם ממנו.[10] אם רודפים אחריו, זה יגמר בכלום.

flowchart TB
    accTitle: המלכודת של יחיד וריבוי בשמות היומן
    accDescr: תרשים שמראה ששם המקור בצד יומן Application הוא Profiles ברבים, ושם הערוץ ביומן Operational הוא Profile ביחיד, וכשפקודה שהועתקה והודבקה לא עובדת, כמעט תמיד הסיבה היא בלבול בין השניים.
    lg1["הפקודה לא עובדת"] --> lg2{"באיזה שם יומן השתמשתם"}
    lg2 -->|"שם המקור של Application"| lg3["Profiles ברבים"]
    lg2 -->|"שם הערוץ של Operational"| lg4["Profile ביחיד"]
    lg3 -.-> lg5["הבלבול הוא הסיבה השכיחה"]
    lg4 -.-> lg5

איור 20: שני שמות יומן דומים אך שונים הם הסיבה הקלאסית לכישלון העתק-הדבק.

7.3 סיבות נפוצות

מאפיין או הרשאות של NTUSER.DAT /‏ USRCLASS.DAT

Microsoft מסבירה שאם NTUSER.DAT או USRCLASS.DAT הפכו ל-Read-only, או שאין הרשאת גישה נדרשת, טעינת הפרופיל עלולה להיכשל.[11]

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

flowchart LR
    accTitle: השפעת גישה לקובץ DAT על טעינת הפרופיל
    accDescr: תרשים שמראה שאם אי אפשר לגשת לקובץ ה-DAT, טעינת הפרופיל מובילה לכישלון כניסה, שולחן עבודה ריק, או הפיכה לפרופיל Temporary, ואם אפשר לגשת, מתבצעת טעינה רגילה.
    A[טעינת פרופיל] --> B{אפשר לגשת לקובץ DAT?}
    B -->|לא| C[כישלון כניסה / שולחן עבודה ריק / Temporary]
    B -->|כן| D[טעינה רגילה]

איור 21: אם אי אפשר לגשת לקובץ DAT, זה מוביל לכישלון כניסה או להפיכה לפרופיל זמני.

נתיב ארוך בזמן העתקת נדידה

ב-KB של Microsoft מוסבר מקרה שבו שם השרת או שם השיתוף בצד הנתיב המשותף ארוכים, וכל נתיב היעד להעתקה נעשה ארוך מדי, מה שגורם לירידה לפרופיל זמני יחד עם Event ID 1509.[16]

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

מידע רישום / תיקייה שנשאר עקב מחיקה לא שלמה

ל-Microsoft יש מאמר עם script לדוגמה ל-ניקוי מידע יתום שנשאר ברישום וב-C:\Users, כדי למנוע יצירת פרופיל TEMP.[15]

מה שרואים מזה הוא ש-מחיקת התיקייה בלבד לא מספיקה.

flowchart LR
    accTitle: מחיקה רשלנית משאירה מידע רישום
    accDescr: תרשים שמראה שמחיקת פרופיל ישן ברשלנות משאירה מידע רישום, שגורם לאי-עקביות בכניסה הבאה, ובסופו של דבר לפרופיל TEMP או לתיקייה נוספת.
    A[מחיקת פרופיל ישן ברשלנות] --> B[מידע רישום נשאר]
    B --> C[אי-עקביות בכניסה הבאה]
    C --> D[גורם לפרופיל TEMP או לתיקייה נוספת]

איור 22: מידע רישום שנשאר עקב מחיקה רשלנית יוצר אי-עקביות בכניסה הבאה.

7.4 מה בודקים ראשית

8. באיזו שיטה כדאי לבחור

כאן אין “פתרון אחד נכון”. זה משתנה לפי צורת השימוש.

flowchart TD
    accTitle: המועמד הראשון לפי צורת השימוש
    accDescr: תרשים שמראה שלפי צורת השימוש - PC אישי, PC עסקי בתוך domain, PC משותף או מחשב חינוך, ו-RDS/VDI/AVD - המועמד הראשון משתנה בין מרכז מקומי, Folder Redirection או נדידה, Mandatory או Shared PC או cleanup, ו-FSLogix.
    A[צורת שימוש] --> B[PC אישי]
    A --> C[PC עסקי בתוך domain]
    A --> D[PC משותף / מחשב חינוך]
    A --> E[RDS / VDI / AVD]

    B --> B1[מרכז מקומי]
    C --> C1[Folder Redirection / נדידה לפי צורך]
    D --> D1[Mandatory / Shared PC / cleanup]
    E --> E1[FSLogix כמועמד ראשון]

איור 23: לפי צורת השימוש, המועמד הראשון משתנה - ממרכז מקומי ועד FSLogix.

8.1 PC אישי

הבסיס - פרופיל מקומי מספיק.

• הגדרת משתמש ב-AppData
• תוצר ב-Documents
• אם צריך, סנכרון מסמכים בשכבה נפרדת כמו OneDrive

ההרכב הזה הכי פשוט.

8.2 PC עסקי בתוך domain

לפי הדרישה, משלבים את אלה.

• רוצים ניהול מרכזי לנתוני מסמכים -> Folder Redirection
• רוצים לשאת גם הגדרות זהות בכמה PC -> פרופיל נודד
• יש ערבוב מערכות הפעלה או פרופיל גדול -> תכנון זהיר, או בחינה מחדש של השיטה

גם ב-Microsoft Learn נכתב ש-Folder Redirection ו-Roaming User Profiles מסייעים בריכוז מרכזי, שימוש offline, והקלה על גיבוי.[4]

8.3 PC משותף / מחשב חינוך / kiosk

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

שלושת המועמדים הם:

• פרופיל Mandatory
• מצב Shared PC
• מדיניות מחיקה אוטומטית של פרופילים ישנים

ל-Microsoft יש מדיניות בשם Delete user profiles older than a specified number of days on system restart, שמאפשרת למחוק בזמן הפעלה מחדש פרופילים שלא נעשה בהם שימוש למספר ימים שצוין.[17]

גם במדריך ה-Shared PC מוצג רעיון שמשלב ניהול או מחיקה אוטומטית של חשבונות/פרופילים במכשיר משותף.[18]

8.4 RDS /‏ VDI /‏ Azure Virtual Desktop

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

Microsoft ממליצה על FSLogix profile containers ב-Azure Virtual Desktop, ומסבירה שמצמידים VHDX /‏ VHD בזמן כניסה, ומטפלים בו כמו פרופיל משתמש native.[14]

flowchart LR
    accTitle: כמה session host מצמידים פרופיל VHDX
    accDescr: תרשים שמראה שכמה session host ניגשים לאחסון משותף שבו נמצא פרופיל המשתמש כ-VHDX, ומצמידים אותו ל-host שאליו התחברו.
    A[כמה session host] --> B[אחסון משותף]
    B --> C[פרופיל משתמש ב-VHDX]
    C --> D[מצמידים ל-host שהתחברו אליו]

איור 24: כמה session host מצמידים ומשתמשים בפרופיל VHDX שנמצא באחסון משותף.

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

• ה-session host משתנה בכל פעם
• משתמשים ב-Outlook /‏ OneDrive /‏ Microsoft 365
• ב-VDI לא-persistent, נשיאת פרופיל היא הכרחית
• עיכוב הכניסה של פרופיל נודד הוא בעיה

9. אי-הבנות נפוצות

9.1 “אם יוצרים חשבון, גם הפרופיל זהה בשימוש בכל מקום”

זה לא נכון. החשבון הוא מזהה, והפרופיל הוא הישות בצד המכשיר. עד כמה נושאים תלוי בשיטה - מקומי, נודד,‏ Folder Redirection,‏ FSLogix וכדומה.[4][14]

9.2 “אם מעתיקים את C:\Users\שם_משתמש אפשר להעביר”

העתקה רשלנית מסוכנת.

• תאימות גרסת מערכת הפעלה
• ‏NTUSER.DAT
• הרשאות
• מצב ייחודי לאפליקציה
• ערבוב עם הפרופיל ברירת המחדל

בגלל אלה. בפרט בנדידה עם הבדל דור מערכת הפעלה, גם Microsoft מניחה הפרדת גרסת פרופיל.[6]

flowchart TB
    accTitle: למה מעבר עם העתקה רשלנית מסוכן
    accDescr: תרשים שמראה שמעבר על ידי העתקה רשלנית של תיקיית המשתמש נושא בעיות של תאימות גרסת מערכת הפעלה, NTUSER.DAT, הרשאות, וערבוב עם הפרופיל ברירת המחדל, ולכן זה מסוכן.
    mv1["מעתיקים את כל התיקייה"] --> mv2["נראה שהעברה הצליחה"]
    mv2 -.-> mv3["נשארת בעיית תאימות OS ו-NTUSER.DAT"]
    mv2 -.-> mv4["ערבוב הרשאות ופרופיל ברירת מחדל"]
    mv3 --> mv5["הופך למעבר שנשבר בקלות בהמשך"]
    mv4 --> mv5

איור 25: הפרופיל הוא לא רק תיקייה, ולכן אי אפשר להעביר אותו רק בהעתקה.

9.3 “Mandatory ו-Temporary דומים”

שני אלה שונים לגמרי. Mandatory הוא פרופיל לקריאה בלבד שהמנהל יוצר בכוונה, ו-Temporary הוא מוצא בזמן שגיאה שבה הפרופיל האמיתי לא נטען.[8][9]

9.4 “אם רוצים סנכרון, פשוט שמים הכול ב-Roaming”

זה מסוכן. אם שמים הגדרות ומטמון ענק באותה קופסה, הטיפול בכניסה/יציאה או בזמן תקלה נעשה כבד. עדיף להפריד בין מה שרוצים לתת נדידה ל-מה שצריך להישאר Local - זה קל יותר לתפעל.[2][3]

9.5 “גם אם הפכתי לפרופיל זמני, אפשר פשוט להמשיך להשתמש”

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

10. סיכום

פרופיל המשתמש ב-Windows הוא לא סתם מילה שמתכוונת לתיקייה מתחת ל-C:\Users.

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

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

בפועל, 6 הנקודות שכדאי לתפוס מראש הן:

• ב-PC בודד, קודם חושבים לפי בסיס פרופיל מקומי
• מיקום השמירה של האפליקציה מפרידים ל-Roaming /‏ Local /‏ ProgramData
• בסביבת domain, לא מבלבלים בין פרופיל נודד ל-Folder Redirection
• במכשיר משותף, בודקים Mandatory /‏ cleanup /‏ Shared PC
• ב-RDS /‏ VDI /‏ AVD, מכניסים את FSLogix כמועמד ראשון
• כשמשהו נשבר, קודם מסתכלים על יומן User Profile Service

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

flowchart TB
    accTitle: שלוש השאלות בתכנון פרופיל
    accDescr: תרשים שמראה שתכנון הפרופיל מתמצה בשלוש שאלות - מה שמים איפה, עד כמה נושאים, ואיך מחזירים בזמן כישלון - וכשאלה מוצקות, פריסת מכשירים, תכנון אפליקציה, וחקירת תקלות נעשים קלים יותר.
    dq1["מה שמים איפה"] --> dq2["עד כמה נושאים"]
    dq2 --> dq3["איך מחזירים בזמן כישלון"]
    dq3 -.-> dq4["פריסה, תכנון וחקירה נעשים קלים יותר"]

איור 26: אם עונים על שלוש השאלות, תכנון הפרופיל כמעט מוצק.

11. מאמרים קשורים

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

12. שירותים שקשורים לנושא הזה

פיתוח אפליקציות Windows

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

לשירות /‏ יצירת קשר

ייעוץ טכני וסקירת תכנון

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

לשירות /‏ יצירת קשר

חקירת תקלות וניתוח שורש

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

לשירות /‏ יצירת קשר

13. מקורות

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

1. Microsoft Learn, About User Profiles (Windows) מרכיבי פרופיל המשתמש,‏ NTUSER.DAT, ויסודות ה-Temporary profile.

2. Microsoft Learn, Fast User Switching סידור שבו FOLDERID_RoamingAppData לנתונים ייחודיים לאפליקציה, ו-FOLDERID_LocalAppData לנתונים שלא ישמשו במחשב אחר.

3. Microsoft Learn, KNOWNFOLDERID,‏ CSIDL הגדרת ה-known folders כמו %APPDATA%,‏ %LOCALAPPDATA%,‏ LocalLow,‏ ProgramData.

4. Microsoft Learn, Folder Redirection and Roaming User Profiles in Windows and Windows Server ההבדל בין Folder Redirection ל-Roaming User Profiles, ורעיון הניהול המרכזי.

5. Microsoft Learn, Deploy roaming user profiles הליכי פריסה בפועל של פרופיל נודד, הרשאת שיתוף,‏ GPO, וגרסאות.

6. Microsoft Learn, Roaming user profiles of earlier versions of Windows are incompatible with Windows 10, Windows Server 2016, and later versions אי-תאימות בין דורות מערכת הפעלה, וגרסאות פרופיל.

7. Microsoft Learn, Create mandatory user profiles שימוש ואופן יצירה של Mandatory user profile.

8. Microsoft Learn, Mandatory User Profiles הגדרת NTUSER.MAN ו-Super-mandatory profile.

9. Microsoft Learn, Temporary User Profiles הגדרה ותכונות של Temporary profile.

10. Microsoft Learn, Troubleshoot user profiles with events בידוד באמצעות יומני Application /‏ Operational /‏ Diagnostic.

11. Microsoft Learn, Error occurs during desktop setup and desktop location is unavailable when you log on to Windows for the first time יצירת פרופיל חדש שמתחילה מ-C:\Users\Default, ובעיות מאפיין/הרשאה של NTUSER.DAT /‏ USRCLASS.DAT.

12. Microsoft Learn, Customize the default local user profile when you prepare an image of Windows שיטה נתמכת להתאמה אישית של פרופיל ברירת המחדל דרך CopyProfile.

13. Microsoft Learn, What is FSLogix,‏ Types of Containers יסודות FSLogix, ורעיון ה-Profile Container.

14. Microsoft Learn, User profile management for Azure Virtual Desktop with FSLogix profile containers,‏ Configure profile containers using FSLogix ההמלצה ב-Azure Virtual Desktop, ושיטת מכולת הפרופיל עם VHD /‏ VHDX.

15. Microsoft Learn, Scripts: Clean up profile folder information and prevent TEMP user profiles from being created הקשר בין מידע פרופיל יתום לבין TEMP profile.

16. Microsoft Learn, User profile cannot be loaded with Event ID 1509: DETAIL - The filename or extension is too long בעיית נתיב ארוך בזמן שמירת פרופיל נודד.

17. Microsoft Learn, ADMX_UserProfiles Policy CSP הגדרת מדיניות כמו Delete user profiles older than a specified number of days on system restart.

18. Microsoft Learn, Configure a shared or guest Windows device מצב Shared PC, וניהול חשבון/פרופיל במכשיר משותף.

19. Microsoft Learn, Designing Applications to Run at a Low Integrity Level ההכנה של %USERPROFILE%\AppData\LocalLow ו-HKEY_CURRENT_USER\Software\AppDataLow כמקום כתיבה עבור תהליכים ברמת שלמות נמוכה.

מאמרים קשורים

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

נושאים קשורים

העמודים האלה ממקמים את הנושא בהקשר רחב יותר של שירותים והחלטות.

שירותים הקשורים לנושא הזה

המאמר קשור ישירות לשירותים הבאים.

שאלות נפוצות

שאלות נפוצות בפניות בנושא המאמר.

מה זה NTUSER.DAT?

NTUSER.DAT הוא הקובץ הפיזי שמייצג את ה-hive של רישום המשתמש שכלול בפרופיל המשתמש ב-Windows. הוא נמצא ישירות תחת C:\Users\שם_משתמש, נטען בזמן הכניסה למערכת, ומשמש כ-HKEY_CURRENT_USER (‏HKCU‏). כלומר פרופיל המשתמש בנוי משתי שכבות - קבוצת קבצים כמו Desktop ו-AppData, ושכבת רישום שמרוכזת סביב NTUSER.DAT. אם ל-NTUSER.DAT יש מאפיין קריאה בלבד או שאין הרשאת גישה נדרשת, טעינת הפרופיל נכשלת, וזה גורם לכישלון כניסה או להפיכה לפרופיל זמני.

מה זה פרופיל משתמש ב-Windows? זה שונה מחשבון?

חשבון מזהה 'מי נכנס למערכת', ופרופיל המשתמש הוא הישות הממשית של סביבת העבודה של אותו אדם. הפרופיל הוא לא רק תיקיית C:\Users\שם_משתמש, אלא קבוצת קבצים כמו Desktop,‏ Documents,‏ AppData, יחד עם NTUSER.DAT שהוא ה-hive של רישום המשתמש. כשמשתמש חדש נכנס למערכת בפעם הראשונה, נוצר פרופיל חדש על בסיס C:\Users\Default. עד כמה נושאים את ההגדרות תלוי בבחירת השיטה - מקומי, נודד,‏ Folder Redirection, או FSLogix.

איך מחלקים בין %APPDATA% ל-%LOCALAPPDATA%?

הגדרות שרוצים לשאת לכל מקום לפי המשתמש שמים ב-%APPDATA% (‏AppData\Roaming‏), ומטמון או מצב זמני שמיוחד ל-PC הזה שמים ב-%LOCALAPPDATA% (‏AppData\Local‏) - זה הבסיס. אם מטמון שניתן ליצור מחדש או קובצי עבודה גדולים נודדים, הכניסה והיציאה נוטות להיות איטיות, ולכן מטים אותם לצד Local. עבור נתונים משתנים משותפים לכל המשתמשים, ProgramData הוא מועמד, אבל צריך לחשוב עליו יחד עם תכנון ACL של מי קורא וכותב. עדיף להימנע מלמקם נתוני זמן ריצה ספציפיים למשתמש בתוך Program Files.

מה עושים כשמתחברים עם פרופיל זמני (Temporary profile)?

פרופיל Temporary הוא מוצא חירום שמונפק כשלא ניתן לטעון את הפרופיל האמיתי עקב שגיאה, והוא נמחק ביציאה, כך שכל שינוי הולך לאיבוד. המשך עבודה במצב הזה מסוכן כי נתונים חשובים עלולים להיעלם, ולכן זה מצב שכדאי להימנע ממנו. בחקירה, במקום לגעת מיד ב-C:\Users, קודם בודקים את יומן Application ואת היומן Operational של User Profile Service, ואם צריך גם את יומן Diagnostic. הסיבות הנפוצות כוללות בעיות במאפיין או בהרשאות של NTUSER.DAT‏/‏USRCLASS.DAT, נתיב יעד נדידה ארוך מדי, ומידע רישום שנשאר עקב מחיקה לא שלמה.

פרופיל הכותב

עמוד היכרות עם כותב המאמר.

Go Komura

מנהל KomuraSoft LLC

מתמחה בפיתוח תוכנה עבור Windows, ייעוץ טכני וחקירת תקלות, בעיקר בפרויקטים עם מערכות קיימות ובאגים שקשה לשחזר.