User profile ב-Windows: AppData ו-NTUSER.DAT

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

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

איך לקרוא

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

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

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

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

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

1. קודם המסקנה

לפני הפרטים, המסקנות מהשטח.

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

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

1.1 קיצורים במאמר

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

ב-diagram, solid line מציינת relation שתמיד מתקיים ו-dashed line מציינת relation מותנה (התנאים מופיעים בהסבר של כל relation ב-detail page). הרשימה המלאה של ה-relations (סה”כ 24, כולל evidence ו-certainty) וההגדרות של ה-concepts המרכזיים נמצאות ב-detail page של ה-knowledge map (ביפנית). Data: JSON-LD / Turtle

2. בכלל, מה זה “user profile” ב-Windows

קודם מפרידים חשבון מ-profile. ככה זה נהיה קל יותר.

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

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

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

גם ב-Microsoft Learn, user profile כולל תיקיות profile במערכת הקבצים ואת ה-registry hive NTUSER.DAT, וב-logon ה-hive הזה נטען ומשמש כ-HKEY_CURRENT_USER.[1]

2.1 לא רק תיקייה. גם Registry

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

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

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

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

ל-Windows profile יש בערך שתי שכבות:

1. שכבת קבצים Desktop, Documents, Downloads, AppData וכו’
2. שכבת Registry HKCU אחרי ש-NTUSER.DAT נטען

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

2.2 ב-sign-in הראשון, Default הוא הבסיס

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

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

איור 3: ב-sign-in הראשון, Default הוא הבסיס לפרופיל הייעודי של המשתמש.

בפריסת image וב-kitting, אם מתייחסים לזה בגסות, אחר כך זה כואב.

Microsoft כותבת ששיטת התאמה נתמכת ל-Default profile היא CopyProfile. copy ידני או שכפול ישן מכניסים מידע מיותר, וזה יכול לשבור אפליקציות ויציבות מערכת.[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[cache]
    C --> C2[נתונים שאפשר לייצר מחדש]
    C --> C3[מצב ייחודי ל-PC הזה]

    D --> D1[אזור ש-process ב-low integrity יכול לכתוב אליו]

איור 5: Roaming להגדרות שנוסעות, Local לייחודי ל-PC, LocalLow ל-process ב-low integrity.

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

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

ל-process ב-Windows יש integrity level. process שרץ ב-low integrity לא יכול לכתוב לרוב AppData\Roaming, AppData\Local ו-HKCU. בלי מקום אחר הוא לא יכול לשמור כלום, אז יש מקום שאפשר לכתוב אליו גם ב-low integrity. זה %USERPROFILE%\AppData\LocalLow, וב-Registry — HKEY_CURRENT_USER\Software\AppDataLow.[19]

כלומר:

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

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

• אם האפליקציה שלכם לא רצה ב-low integrity, אין סיבה להשתמש ב-LocalLow. משתמשים ב-Local.
• ולהפך, אם ב-LocalLow מופיעות תיקיות לא מוכרות, מי שכותב לשם הוא משהו שרץ ב-low integrity. זה רמז בחקירת נפח.

איך מחלקים בשטח

ProgramData מוגדר גם ב-Known Folders כ-application data לכל המשתמשים, לנתונים משותפים שלא עושים roaming.[3]

מה שחשוב להימנע ממנו: לשים נתוני runtime לפי משתמש ב-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. סוגי הפרופילים

“profile” אחד, אבל בתפעול יש לפחות את הסוגים האלה.

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

איור 7: בתפעול, הפרופיל מתפצל לפחות לחמישה סוגים, מ-local עד FSLogix.

4.1 local profile

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

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

גם Microsoft כותבת שכברירת מחדל Windows יוצר local user profile.[14]

4.2 roaming profile

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

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

איור 8: roaming profile מקבל את הפרופיל שעל שרת השיתוף בכמה PCs.

בשטח יש כמה נקודות:

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

4.3 Mandatory profile

Mandatory profile הוא roaming profile שהמנהל הכין, ושלא נשמר.[7][8]

לפי Microsoft, ב-Mandatory profile שינויים שהמשתמש עושה ב-session לא נשמרים כמו ב-roaming רגיל.[7]

ובתיעוד Win32:

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

כך זה מוסבר.[8]

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

איור 9: Mandatory הוא פרופיל שהמנהל מכין, ושינויים במהלך השימוש לא נשמרים ב-sign-out.

מתאים למשל ל:

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

4.4 Temporary profile

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

Microsoft Learn כותבת שבמצב שגיאה כזה מונפק Temporary profile, הוא נמחק בסוף ה-session, והשינויים הולכים לאיבוד.[9]

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

איור 10: Temporary הוא יעד מילוט כשהטעינה נכשלת, וב-sign-out השינויים נעלמים.

כלומר, מצב של Temporary profile הוא עצמו סימן שמשהו לא תקין.

4.5 FSLogix profile container

FSLogix מוסבר ב-Microsoft Learn כ-מנגנון שמיישר את חוויית ה-user profile בסביבת virtual desktop.[13]

FSLogix profile container מחבר את כל הפרופיל כ-VHD / VHDX, וב-sign-in מצמיד אותו כך שהוא נראה כמו פרופיל native.[13][14]

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

איור 11: FSLogix מצמיד פרופיל על VHD ב-sign-in, ונראה native.

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

5. במה שונים roaming, Folder Redirection ו-FSLogix

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

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

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

איור 12: שלוש השיטות נבדלות בטווח הנשיאה: הכול, רק known folders, או container.

לפי הסידור ב-Microsoft Learn, ההבדל נראה כך.[4][5][14]

5.1 Folder Redirection מטה רק known folders

ב-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 לא לערבב roaming בין דורות OS

Microsoft כותבת ש-roaming profile של 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[סיבה לאי-עקביות / Start menu / taskbar]

איור 14: ערבוב roaming profiles מדורות OS שונים באותו שיתוף הוא סיבה לאי-עקביות.

הנקודות:

• מפרידים profile version לפי דור OS
• לא חושבים “אותו משתמש אז אותה תיקייה מספיקה”
• בפריסת מחשבים ובהחלפה, תאימות פרופיל נכנסת לתוכנית המעבר

כך זה.[6]

6. מה מפתחים ואנשי תפעול צריכים להחליט קודם: איפה שומרים

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

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

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

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

אם מערבבים, גם backup וגם מעבר נשברים.

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

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

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

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

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

בערך אלה:

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

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

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

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

• cache שאפשר לייצר מחדש
• מצב שמשמעותי רק מקומית
• קובצי עבודה גדולים
• דברים שלא רוצים לשאת, משיקולי ביצועים

גם ב-Known Folders, LocalAppData הוא %USERPROFILE%\AppData\Local.[3]

6.4 מה שמים ב-ProgramData

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

למשל:

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

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

6.5 כשרוצים לבנות Default profile

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

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

איור 17: בניית Default profile עוברת דרך Sysprep ו-CopyProfile.

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

7. כשנשבר, נהיה Temporary, או לא מסתנכרן — מאיפה מסתכלים

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

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

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

איור 18: לפי אפשרות logon ולפי איפוס נראה, בעיית profile מתפצלת לשלושה מסלולים.

בגדול שלושה מסלולים:

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

7.2 אילו לוגים בודקים קודם

Microsoft Learn מכוונת לבדוק בסדר הזה בחקירת בעיית profile.[10]

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

הנתיבים:[10]

• Event Viewer Applications and Services Logs > Microsoft > Windows > User Profile Service > Operational
• לפירוט נוסף ... > User Profile Service > Diagnostic

ב-Windows בעברית, העץ משמאל הוא יומני יישומים ושירותים > Microsoft > Windows > User Profile Service > Operational. משם המטה, שמות הספקים נשארים באנגלית.

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

איור 19: החקירה מעמיקה מ-Application, דרך Operational ו-Diagnostic, עד ETL trace.

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

שלושת הלוגים יושבים במקומות שונים

כאן נתקעים בהתחלה, אז מקדימים.[10]

Diagnostic log לא מופיע בעץ כמו שהוא. ב-Event Viewer מדליקים Actions > View > Show Analytic and Debug Logs, בוחרים Diagnostic, ומפעילים את הלוג. אחרי החקירה מחזירים לכבוי. זה לוג מפורט מדי, לא מסוג שמשאירים דולק.[10]

לראות את אותו דבר בלי GUI

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

# 1) Application ログから User Profile Service のイベントだけを新しい順に見る
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 log הוא Microsoft-Windows-User Profiles Service (Profiles ברבים), ושם הערוץ של Operational הוא Microsoft-Windows-User Profile Service/Operational (Profile ביחיד). כש-copy-paste לא רץ, בדרך כלל זה זה.

Event ID 1509 יוצא ב-Application log, לא ב-Operational. הרמה היא Warning, וההודעה בפורמט “Windows cannot copy file \\server\share\... to C:\Users\...”, ואחריה DETAIL - The filename or extension is too long. השורה האחרונה הזו היא הראיה שאורך הנתיב הוא הסיבה.[16]

עוד דבר שחוסך זמן בשטח: Microsoft כותבת במפורש שאפשר להתעלם מאירוע 1530 של User Profile Service, “The registry file is still in use by other applications or services”.[10] לרדוף אחריו זה ריק.

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

איור 20: שני שמות לוג שנראים דומה הם מלכודת copy-paste קלאסית.

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

תכונות והרשאות של NTUSER.DAT / USRCLASS.DAT

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

זה נשמע קטן, ומאריך חקירה אם מפספסים.

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

איור 21: בלי גישה לקובץ DAT מגיעים לכשל logon או ל-Temporary profile.

נתיב ארוך ב-copy של roaming

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

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

שאריות Registry / תיקיות ממחיקה לא שלמה

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

מה שיוצא מזה: מחיקת תיקייה לבד אינה סוף הסיפור.

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

איור 22: מידע Registry שנשאר ממחיקה גסה יוצר אי-עקביות ב-logon הבא.

7.4 מה בודקים קודם

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

אין כאן תשובה אחת. זה תלוי בצורת השימוש.

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

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

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

8.1 PC אישי ייעודי

local profile מספיק כבסיס.

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

זו התצורה הכי פשוטה.

8.2 PC ארגוני ב-domain

לפי הדרישה משלבים:

• רוצים לנהל מסמכים במרכז → Folder Redirection
• רוצים גם אותן הגדרות בכמה PCs → roaming profile
• יש ערבוב OS או פרופיל גדול → תכנון זהיר, או בחינה מחדש של השיטה

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

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

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

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

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

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

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

8.4 RDS / VDI / Azure Virtual Desktop

כאן roaming מסורתי לבד לרוב לא מספיק.

Microsoft ממליצה ב-Azure Virtual Desktop על FSLogix profile containers, ומתארת attach של VHDX / VHD ב-sign-in כך שזה נראה כמו user profile native.[14]

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

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

במיוחד בתנאים האלה שווה לבדוק FSLogix קודם:

• ה-session host משתנה בכל פעם
• משתמשים ב-Outlook / OneDrive / Microsoft 365
• VDI לא-persistent עם חובה לשאת פרופיל
• עיכוב sign-in של roaming הוא בעיה

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

9.1 “אם יוצרים חשבון, אותו profile זמין בכל מקום”

לא. חשבון הוא מזהה, profile הוא ישות בצד המחשב. עד כמה זה נוסע תלוי בשיטה: local, roaming, Folder Redirection, FSLogix.[4][14]

9.2 “מעתיקים C:\Users\שם_משתמש וזה מעבר”

copy גס מסוכן.

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

במיוחד ב-roaming שחוצה דורות OS, גם Microsoft מניחה הפרדת profile versions.[6]

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

איור 25: profile אינו רק תיקייה, ולכן אי אפשר לשאת אותו ב-copy.

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

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

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

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

9.5 “נהיה Temporary profile, אפשר להמשיך לעבוד”

עדיף לא. Temporary profile נמחק ב-sign-out, אז אם ממשיכים לעבוד במצב הזה, עלולים לשים נתונים חשובים במקום שייעלם אחר כך.[9]

10. סיכום

user profile ב-Windows אינו סתם המילה לתיקייה תחת C:\Users.

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

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

בשטח, שש הנקודות האלה כדאי לתפוס קודם:

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

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

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

איור 26: אם יש תשובה לשלוש השאלות, תכנון ה-profile כמעט מגובש.

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

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

12. שירותים שהנושא הזה מתחבר אליהם

Windows Custom Software Development

איך מחלקים מיקום שמירה של הגדרות משתמש, לוגים, cache ונתונים משותפים משפיע חזק על תפעול ותחזוקה של אפליקציית Windows. אם מסתכלים מאיסוף דרישות עד תכנון, מימוש ותפעול ארוך, זה נושא שמתאים ל-Windows Custom Software Development.

לעמוד השירות / צור קשר

ייעוץ טכני ו-design review

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

לעמוד השירות / צור קשר

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

Temporary profile, כשל logon, כשל שמירה ב-sign-out, ובידוד סביב נתיב שיתוף — מתאימים מאוד לחקירת תקלות. זו נקודת כניסה כשרוצים לדחוק בעיית profile שקשה לשחזר, מלוגים, אירועים, הרשאות ותצורת שיתוף.

לעמוד השירות / צור קשר

13. מקורות

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

1. Microsoft Learn, About User Profiles (Windows) רכיבי user profile, 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 פריסת roaming profile, הרשאות שיתוף, GPO, ו-versioning בשטח.

6. Microsoft Learn, Roaming user profiles of earlier versions of Windows are incompatible with Windows 10, Windows Server 2016, and later versions אי-תאימות בין דורות OS ו-profile versioning.

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 logs.

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 התאמת Default profile נתמכת עם 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, ושיטת profile container עם VHD / VHDX.

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

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

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 mode וניהול חשבונות / פרופילים במחשב משותף.

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

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

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

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

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

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

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

שאלות נפוצות

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

מה זה NTUSER.DAT?

NTUSER.DAT הוא הקובץ הפיזי של ה-user registry hive בתוך ה-user profile ב-Windows. הוא יושב ישירות תחת C:\Users\שם_משתמש, נטען ב-sign-in, ומשמש כ-HKEY_CURRENT_USER (HKCU). כלומר ה-user profile בנוי משתי שכבות: קבצים כמו Desktop ו-AppData, ושכבת Registry סביב NTUSER.DAT. אם ל-NTUSER.DAT יש תכונת read-only או שחסרה הרשאת גישה, טעינת הפרופיל נכשלת — וזה גורם לכישלון logon או להחלפה ל-Temporary profile.

מה זה user profile ב-Windows? זה שונה מחשבון?

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

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

הגדרות שרוצים לשאת לפי משתמש שמים ב-%APPDATA% (AppData\Roaming). cache או מצב זמני ששייך ל-PC הזה שמים ב-%LOCALAPPDATA% (AppData\Local). cache שאפשר לייצר מחדש או קובצי עבודה גדולים ב-roaming מכבידים על sign-in/sign-out, ולכן מטים אותם ל-Local. לנתונים משתנים שמשותפים לכל המשתמשים, ProgramData הוא מועמד — אבל רק יחד עם תכנון ACL של מי קורא ומי כותב. נתוני runtime לפי משתמש לא שמים ב-Program Files.

מה עושים כשנכנסים עם Temporary profile?

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

פרופיל הכותב

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

Go Komura

מנהל KomuraSoft LLC

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