Introduction to Windows User Profiles - AppData and NTUSER.DAT

This article is written as a general overview for IT staff who manage Windows, people responsible for device deployment, and Windows application developers. The diagrams are conceptual. In Markdown environments that support Mermaid, they render as diagrams.

The content is based on official Microsoft documentation that we could verify as of April 2026. [1][4][7][10][13][14]

In Windows consultations, the word “profile” is used very broadly.

• What exactly is inside C:\Users\<username>?
• How should %AppData% and %LocalAppData% be used differently?
• What is a roaming profile in a domain environment?
• What is the difference between a mandatory profile and a temporary profile?
• What should you choose for shared PCs, RDS, VDI, or Azure Virtual Desktop?
• When a profile breaks, where should you start looking?

These questions mix accounts, folders, the registry, synchronization mechanisms, and operational policy all at once, so discussions go off track quickly.

In this article, we first establish a view of the Windows user profile as a single design blueprint, and then walk through how to use AppData, roaming, mandatory and temporary profiles, FSLogix, and how to investigate problems, in order.

1. The Conclusions First

Before getting into the details, here are the practical conclusions up front.

• A Windows user profile is not just the C:\Users\<username> folder. It is a set of files plus a user registry hive (NTUSER.DAT). [1]
• On an ordinary local PC, a local profile is created by default. At first sign-in, a new profile is created using C:\Users\Default as the template. [11][12]
• You should not decide application storage locations casually. The basic split is: per-user settings you want to carry around go in %APPDATA%, and machine-specific caches or transient state go in %LOCALAPPDATA%. [2][3]
• A roaming profile is a mechanism that “moves the entire profile to a file share,” while Folder Redirection “moves only known folders such as Documents to another location.” They are not the same thing. [4][5]
• A mandatory profile is a read-only profile for “letting users work without letting them save changes.” A temporary profile is an emergency fallback used on errors, and it is discarded every time. [7][8][9]
• Be careful with roaming profiles that span OS generations. Windows 10 / Server 2016 and later are incompatible with earlier versions, so you should plan around separate profile versions. [6]
• For RDS / VDI / Azure Virtual Desktop, rather than pushing through with traditional roaming profiles alone, there are many situations where FSLogix profile containers should be the first candidate. Microsoft also recommends FSLogix for Azure Virtual Desktop. [13][14]
• When troubleshooting, instead of touching C:\Users right away, it is sounder to look at the Application log, the User Profile Service Operational / Diagnostic logs, the share path, and the attributes and permissions of NTUSER.DAT / USRCLASS.DAT first. [10][11][16]

In short, the Windows profile story comes down to “where you put what, how far it travels, and how you recover when something fails.”

2. What Exactly Is a Windows “User Profile”?

To begin with, things become easier if you separate accounts from profiles.

flowchart LR
    A[User account<br/>who signs in] --> B[User profile<br/>that person's settings and data]
    C[Device / OS] --> B
    B --> D[Desktop settings]
    B --> E[AppData]
    B --> F[Documents / Desktop etc.]
    B --> G[Settings visible under HKCU]

• An account identifies who someone is
• A profile is the actual substance of that person’s working environment
• A device is where that profile is loaded and used

Microsoft Learn also explains that a user profile includes the profile folders on the file system and the registry hive NTUSER.DAT, and that this hive is loaded at logon and used as HKEY_CURRENT_USER. [1]

2.1 Not “Just Folders” - the Registry Is Included Too

This is the important part.

flowchart TD
    A[Sign in] --> B[Locate profile folder]
    B --> C[Load NTUSER.DAT]
    C --> D[Use as HKCU]
    B --> E[Prepare Desktop / Documents / AppData]
    D --> F[User settings take effect]
    E --> F

In other words, if you are only looking at C:\Users\<username>, you are only seeing half of the picture.

A Windows profile has two major layers.

1. The file layer Desktop, Documents, Downloads, AppData, and so on
2. The registry layer HKCU, backed by the loaded NTUSER.DAT

What makes profile-corruption discussions confusing is that there are cases where only the folder side breaks and cases where the problem is on the registry hive side. [1][11]

2.2 At First Sign-In, Default Is the Template

When a new user signs in to a PC for the first time, Windows creates a local profile based on C:\Users\Default. [11]

flowchart LR
    A[C:\Users\Default] --> B[First sign-in]
    B --> C[Create C:\Users\username]
    C --> D[Load NTUSER.DAT]
    D --> E[Becomes that user's dedicated environment]

If you handle this carelessly in the context of image deployment or device provisioning, it becomes quite painful later.

Microsoft explains that the supported way to customize the default profile is to use CopyProfile. Manual copying and old-fashioned crude duplication can drag in unwanted information and cause problems with applications and system stability. [12]

3. How to Read C:\Users\<username>

Viewed from the folder side, a user profile has roughly this structure.

flowchart TD
    A["C:\Users\username"] --> 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]

In practice, the first places to look are usually these.

3.1 Think of AppData as Three Separate Areas

In Windows application development and troubleshooting, this is where things get mixed up most easily.

Microsoft’s guidance says to use FOLDERID_RoamingAppData (Roaming AppData) for application-specific data, and FOLDERID_LocalAppData for temporary files and data that is not used on other computers. [2]

In addition, in the Known Folders definitions, the default paths are organized as follows. [3]

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

flowchart LR
    A[AppData] --> B[Roaming]
    A --> C[Local]
    A --> D[LocalLow]

    B --> B1[Settings to carry around]
    B --> B2[Smaller user state]

    C --> C1[Caches]
    C --> C2[Regenerable data]
    C --> C3[State specific to that PC]

    D --> D1[Special purposes]

How to Decide in Practice

ProgramData is also defined in Microsoft’s known folder definitions as application data for all users, intended for shared data that does not roam. [3]

The thing you most want to avoid here is putting per-user runtime data in Program Files. It tends to wreck both your profile organization and your permission design at once.

3.2 Public and Default Have Different Roles

This is another spot where things get mixed up.

flowchart LR
    A["C:\Users"] --> B[Default]
    A --> C[Public]
    A --> D[Each user]

    B --> B1[Seed for creating new profiles]
    C --> C1[Shared items visible to all users]
    D --> D1[Each individual user's data]

• Default is the template used to create new profiles
• Public is the shared area visible to all users
• Each user folder is that person’s own data

These three look similar but have completely different roles.

4. Sorting Out the Types of Profiles

Even though we say “profile” as a single word, operationally there are at least the following kinds.

flowchart TD
    A[Windows profiles] --> B[Local profile]
    A --> C[Roaming profile]
    A --> D[Mandatory profile]
    A --> E[Temporary profile]
    A --> F[FSLogix profile container]

4.1 Local Profiles

On an ordinary PC, this is the default.

• Created on that PC’s local disk
• Does not automatically travel to other PCs
• The simplest option for a standalone PC

Microsoft also explains that by default, Windows creates a local user profile. [14]

4.2 Roaming Profiles

Microsoft Learn describes roaming user profiles as a mechanism where the profile is stored on a server share so that users receive the same OS and application settings on multiple computers. [4][5]

flowchart LR
    A[Profile on a shared server] <--> B[PC-A]
    A <--> C[PC-B]
    A <--> D[PC-C]

In practice, however, there are the following caveats.

• Copying and synchronization at sign-in / sign-out tends to become slow
• Holding large data in AppData\Local is painful
• Susceptible to OS version differences
• Strongly affected by the share path and network quality

4.3 Mandatory Profiles

A mandatory profile is a “roaming profile that does not save,” created by an administrator. [7][8]

According to Microsoft, with a mandatory profile, even if users make changes during a session, those changes are not saved the way they would be with a normal roaming profile. [7]

Furthermore, the Win32 documentation explains that

• renaming NTUSER.DAT to NTUSER.MAN makes the profile mandatory
• appending .man to the profile path’s folder name makes it super-mandatory

[8]

flowchart LR
    A[Profile prepared by an administrator] --> B[User signs in]
    B --> C[Changes are possible during use]
    C --> D[Sign out]
    D --> E[Changes are not saved]

For example, this is well suited to use cases such as:

• Educational devices
• Reception kiosks
• Kiosk terminals
• Shared devices you want returned to a clean state every time

4.4 Temporary Profiles

A temporary profile is not something you choose as a design; it is the fallback used when the real profile cannot be loaded due to an error. [9]

Microsoft Learn explains that when an error condition prevents the real profile from being loaded, a temporary profile is issued, it is deleted at the end of the session, and changes are lost. [9]

flowchart TD
    A[Start loading normal profile] --> B{Can it be loaded}
    B -->|Yes| C[Normal logon]
    B -->|No| D[Logon with temporary profile]
    D --> E[Work is possible]
    E --> F[Changes lost at sign-out]

In other words, running on a temporary profile is itself a sign that something is wrong.

4.5 FSLogix Profile Containers

FSLogix is described on Microsoft Learn as a mechanism that makes the Windows user profile experience consistent in virtual desktop environments. [13]

An FSLogix profile container is an approach where the entire user profile is held as a VHD / VHDX, attached at sign-in, and presented as if it were a native profile. [13][14]

flowchart LR
    A[Profile on VHD / VHDX] --> B[Attached at sign-in]
    B --> C[Appears as C:\Users\user on the session host]
    C --> D[Detached at sign-out]

For Azure Virtual Desktop, Microsoft recommends using FSLogix profile containers. [14]

5. How Do Roaming Profiles, Folder Redirection, and FSLogix Differ?

These three are often discussed as if they were the same thing, but their roles differ.

flowchart TD
    A[Carry user state around] --> B[Roaming profile]
    A --> C[Folder Redirection]
    A --> D[FSLogix]

    B --> B1[Entire profile to a share]
    C --> C1[Only known folders to another location]
    D --> D1[Attach a VHD/VHDX]

Following Microsoft Learn’s framing, the differences are easiest to see like this. [4][5][14]

5.1 Folder Redirection Moves “Only Known Folders”

On Microsoft Learn, Folder Redirection is a mechanism that points the path of a known folder to a different location. [4]

For example, if you redirect Documents to a file share, users see it as if it were local, but the actual data lives elsewhere. [4]

flowchart LR
    A[Documents] --> B[Actual data on a file share]
    C[Desktop] --> D[Separate setting if needed]
    E[AppData] --> F[As is, or a different approach]

In other words, Folder Redirection is not a replacement for the entire profile; it is a per-folder relocation.

5.2 Do Not Casually Mix Roaming Profiles Across OS Generations

Microsoft explains that roaming profiles for Windows 10 / Server 2016 and later are incompatible with earlier versions of Windows. [6]

flowchart LR
    A[Windows 7 / 8.1 era] -.beware of mixing.-> B[Same share]
    C[Windows 10 / Server 2016 and later] -.beware of mixing.-> B
    B --> D[Cause of inconsistencies / broken Start menu / broken taskbar]

What matters here is:

• Separate profile versions per OS generation
• Do not assume “same user, so the same folder is fine”
• For device deployment and refresh projects, include profile compatibility in the migration plan

[6]

6. Storage Locations Developers and Operators Should Decide First

The profile discussion always comes back to this: what goes where.

flowchart TD
    A[Data to store] --> B{Is it a deliverable the user creates}
    B -->|Yes| C[Documents etc.]
    B -->|No| D{Is it specific to that PC}
    D -->|Yes| E[%LOCALAPPDATA%]
    D -->|No| F{Is it a per-user setting}
    F -->|Yes| G[%APPDATA%]
    F -->|No| H{Is it mutable data shared by all users}
    H -->|Yes| I[ProgramData + ACL]
    H -->|No| J[Reconsider the location]

6.1 Separate User-Created Files from Internal Application State

If you mix these, both backups and migrations break easily.

• Deliverables the user consciously works with Documents, Pictures, business-specific save folders
• Internal application state Settings, caches, thumbnails, session information, work files

The former is business data; the latter exists for the application’s convenience. Even though both are “files,” they should be handled separately.

6.2 What Goes in %APPDATA%

Roughly speaking, this is where you put:

• Smaller settings
• Per-user preferences
• State you want to look the same on multiple devices
• Things that are fine to travel along with the profile

The Fast User Switching documentation also points to FOLDERID_RoamingAppData as the place for application-specific data. [2]

6.3 What Goes in %LOCALAPPDATA%

What you want here is anything that should stay local, from the perspective of regenerability and portability.

• Caches that can be regenerated
• State that is only meaningful locally
• Large work files
• Things you do not want to roam, for performance reasons

In the Known Folders definitions too, LocalAppData is %USERPROFILE%\AppData\Local. [3]

6.4 What Goes in ProgramData

Data that is common to all users but changes at runtime is a candidate for ProgramData. [3]

For example:

• Shared dictionaries
• Definition files common to all users
• Mutable data shared between a service and multiple users

However, this area must be considered together with ACL design. Not “it’s shared, so just dump it in ProgramData,” but deciding who reads and who writes is what matters.

6.5 When You Want to Customize the Default Profile

In image deployment, it is perfectly normal to want “the same initial settings for every new user.” In that case, rather than crudely modifying Default, build it with the Microsoft-supported CopyProfile-based method. [12]

flowchart LR
    A[Initial setup with an admin account] --> B[Sysprep + CopyProfile]
    B --> C[Applied to Default profile]
    C --> D[Applied to subsequent new users]

Approaches such as “manually copy C:\Users\A from one PC to Default on another PC” may look quick, but they break things later. [12]

7. How to Investigate When a Profile Breaks, Becomes Temporary, or Stops Syncing

This is the most painful part in the field. Worse, the symptoms look similar, so if your triage is sloppy you can easily go too deep down the wrong path.

7.1 First, Split the Symptoms into Three Groups

flowchart TD
    A[Looks like a profile problem] --> B{Can the user log on}
    B -->|Yes| C{Does everything look reset}
    B -->|No| D[Load-failure category]
    C -->|Yes| E[Temporary / corrupted / different profile]
    C -->|No| F{Do only some settings revert}
    F -->|Yes| G[Roaming / redirection / sync category]
    F -->|No| H[Possibly an app-specific problem]

Broadly, there are three categories:

1. Failure at logon
2. Logon succeeds, but everything looks reset
3. Only some things fail to sync

7.2 The Logs to Look at First

Microsoft Learn advises looking at the following, in this order, when investigating profile problems. [10]

1. The Application log
2. The User Profile Service Operational log
3. The Diagnostic log, if needed
4. ETL traces, if needed beyond that

The specific paths are as follows. [10]

• Event Viewer Applications and Services Logs > Microsoft > Windows > User Profile Service > Operational
• For more detail ... > User Profile Service > Diagnostic

flowchart LR
    A[Application log] --> B[Operational log]
    B --> C[Diagnostic log]
    C --> D[ETL trace]

In the field, rather than jumping straight into registry repairs or folder deletion, it is safer to use the logs to get a sense of the direction first: “load failure,” “copy failure,” “access denied,” “path too long,” “cannot write to the share,” and so on.

7.3 Common Causes

Attributes and Permissions on NTUSER.DAT / USRCLASS.DAT

Microsoft explains that if NTUSER.DAT or USRCLASS.DAT is marked read-only, or lacks the required access rights, profile loading can fail. [11]

It is an unglamorous cause, but missing it makes investigations drag on.

flowchart LR
    A[Profile load] --> B{Can the DAT files be accessed}
    B -->|No| C[Logon failure / default desktop / temporary]
    B -->|Yes| D[Normal load]

Long Paths During Roaming Copy

A Microsoft KB describes a case where the server name or share name on the share-path side is long, making the overall destination path too long, and the user falls into a temporary profile together with Event ID 1509. [16]

What looks like a simple path-length limitation can in fact be caused by the design of the roaming destination itself.

Registry / Folder Information Left Behind by Incomplete Deletion

Microsoft has an article with sample scripts for cleaning up orphaned information left in the registry and C:\Users to prevent TEMP profiles. [15]

The lesson here is that deleting just the folder is not the end of it.

flowchart LR
    A[Crudely delete an old profile] --> B[Registry information remains]
    B --> C[Inconsistency at next logon]
    C --> D[Cause of TEMP profiles or extra folders]

7.4 What to Check First

8. Which Approach Should You Choose?

There is no single correct answer here. It depends on the usage pattern.

flowchart TD
    A[Usage pattern] --> B[Personal dedicated PC]
    A --> C[Domain-joined business PC]
    A --> D[Shared PC / educational device]
    A --> E[RDS / VDI / AVD]

    B --> B1[Primarily local]
    C --> C1[Folder Redirection / roaming as needed]
    D --> D1[Mandatory / Shared PC / cleanup]
    E --> E1[FSLogix as first candidate]

8.1 Personal Dedicated PCs

A local profile is basically sufficient.

• User settings in AppData
• Deliverables in Documents
• If needed, document sync via a separate layer such as OneDrive

This is the simplest configuration.

8.2 Domain-Joined Business PCs

Depending on requirements, combine the following.

• Want to centrally manage document data → Folder Redirection
• Want the same settings carried across multiple PCs → Roaming profiles
• Mixed OS versions or very large profiles → Careful design, or reconsider the approach

Microsoft Learn also notes that Folder Redirection and Roaming User Profiles help with centralization, offline availability, and easier backups. [4]

8.3 Shared PCs / Educational Devices / Kiosks

For these use cases, returning to a clean state every time matters more than “preserving personal customization.”

There are three candidates.

• Mandatory profiles
• Shared PC mode
• Policies that automatically delete old profiles

Microsoft has a policy called Delete user profiles older than a specified number of days on system restart, which deletes profiles unused for the specified number of days at restart. [17]

The Shared PC guidance also presents an approach that combines automatic account / profile management and deletion on shared devices. [18]

8.4 RDS / VDI / Azure Virtual Desktop

Here, traditional roaming profiles alone are often not enough.

Microsoft recommends FSLogix profile containers for Azure Virtual Desktop, explaining that a VHDX / VHD is attached at sign-in and treated like a native user profile. [14]

flowchart LR
    A[Multiple session hosts] --> B[Shared storage]
    B --> C[User profile on VHDX]
    C --> D[Attached to the connected host]

Considering FSLogix first is particularly worthwhile under conditions such as:

• The session host changes every time
• Outlook / OneDrive / Microsoft 365 services are in use
• Non-persistent VDI where profile portability is mandatory
• Roaming-profile sign-in delays are a problem

9. Common Misconceptions

9.1 “If I Create an Account, the Same Profile Is Used Everywhere”

Not so. The account is an identifier; the profile is the device-side substance. How far it travels depends on the approach: local, roaming, Folder Redirection, FSLogix, and so on. [4][14]

9.2 “Copying C:\Users\<username> Is Enough for a Migration”

A crude copy is dangerous, because of:

• OS version compatibility
• NTUSER.DAT
• Permissions
• Application-specific state
• Cross-contamination with the default profile

In particular, for roaming across OS generations, Microsoft itself assumes profile version separation. [6]

9.3 “Mandatory and Temporary Are Pretty Much the Same”

These two are different things. A mandatory profile is a read-only profile an administrator creates deliberately; a temporary profile is the fallback used when the real profile cannot be read due to an error. [8][9]

9.4 “If You Want Sync, Just Put Everything in Roaming”

That is risky. If you put settings and huge caches in the same box, sign-in / sign-out and failure handling become heavy. Operations are easier if you separate what should roam from what should stay local. [2][3]

9.5 “If I End Up on a Temporary Profile, I Can Just Keep Using It”

Better avoided. A temporary profile is designed to disappear at sign-out, so if you keep working in that state, you risk placing important data somewhere that will later vanish. [9]

10. Summary

A Windows user profile is not just a term for the folders under C:\Users.

• The files
• The user registry, centered on NTUSER.DAT
• The operational approach: where the profile lives, how it syncs, and how it gets deleted

Thinking of all of this as one design gives you a much clearer view.

The six points worth nailing down first in practice are:

• For standalone PCs, take a local profile as the baseline
• Split application storage between Roaming / Local / ProgramData
• In domain environments, do not confuse roaming profiles with Folder Redirection
• For shared devices, consider mandatory profiles / cleanup / Shared PC
• For RDS / VDI / AVD, put FSLogix at the top of the candidate list
• When something breaks, look at the User Profile Service logs first

In the end, profile design is not about “where to save,” but about “what belongs to whom, and how far it should travel.” With that settled, device deployment, Windows application design, and failure investigation all become considerably easier.

11. Related Articles

• When Does Windows Actually Require Administrator Privileges? - UAC, Protected Areas, and How to Tell by Design
• Speeding Up Windows App Development Validation with Windows Sandbox

12. Services Related to This Topic

Windows Application Development

How you split storage locations for user settings, logs, caches, and shared data has a major impact on the operability and maintainability of a Windows application. If you want to cover everything from requirements analysis through design, implementation, and long-term operations, this topic fits naturally into the Windows application development context.

View the service / Contact us

Technical Consulting and Design Review

Choosing between local / roaming / FSLogix, changing how existing devices are operated, and drawing the boundaries for storage locations make a big difference when sorted out before implementation. If you want to start from approach selection and boundary design, this topic is easy to carve out as a technical consulting / design review engagement.

View the service / Contact us

Bug Investigation and Root Cause Analysis

Triaging temporary-profile fallbacks, logon failures, save failures at sign-out, and share-path issues is a very good fit for bug investigation work. It serves as a consultation entry point when you want to pin down hard-to-reproduce profile problems from logs, events, permissions, and share configuration.

View the service / Contact us

13. References

1. Microsoft Learn, About User Profiles (Windows) The components of a user profile, NTUSER.DAT, and the basics of temporary profiles.

2. Microsoft Learn, Fast User Switching Guidance to use FOLDERID_RoamingAppData for application-specific data and FOLDERID_LocalAppData for data not used on other computers.

3. Microsoft Learn, KNOWNFOLDERID, CSIDL Definitions of the known folders, including %APPDATA%, %LOCALAPPDATA%, LocalLow, and ProgramData.

4. Microsoft Learn, Folder Redirection and Roaming User Profiles in Windows and Windows Server The difference between Folder Redirection and Roaming User Profiles, and the central-management mindset.

5. Microsoft Learn, Deploy roaming user profiles Practical steps for deploying roaming profiles: share permissions, GPOs, and versioning.

6. Microsoft Learn, Roaming user profiles of earlier versions of Windows are incompatible with Windows 10, Windows Server 2016, and later versions Incompatibility between OS generations and profile versioning.

7. Microsoft Learn, Create mandatory user profiles The purpose of mandatory user profiles and how to create them.

8. Microsoft Learn, Mandatory User Profiles The definitions of NTUSER.MAN and super-mandatory profiles.

9. Microsoft Learn, Temporary User Profiles The definition and properties of temporary profiles.

10. Microsoft Learn, Troubleshoot user profiles with events Triage using the 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 New profile creation starting from C:\Users\Default, and attribute / permission problems with NTUSER.DAT / USRCLASS.DAT.

12. Microsoft Learn, Customize the default local user profile when you prepare an image of Windows The supported way to customize the default profile using CopyProfile.

13. Microsoft Learn, What is FSLogix, Types of Containers FSLogix basics and the profile container concept.

14. Microsoft Learn, User profile management for Azure Virtual Desktop with FSLogix profile containers, Configure profile containers using FSLogix The recommendation for Azure Virtual Desktop and the VHD / VHDX-based profile container approach.

15. Microsoft Learn, Scripts: Clean up profile folder information and prevent TEMP user profiles from being created The relationship between orphaned profile information and TEMP profiles.

16. Microsoft Learn, User profile cannot be loaded with Event ID 1509: DETAIL - The filename or extension is too long The long-path problem when saving roaming profiles.

17. Microsoft Learn, ADMX_UserProfiles Policy CSP Policy definitions including 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 and account / profile management for shared devices.

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.