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]

How to read this article

This is a long article, so here are entry points by role.

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.

1.1 Abbreviations Used in This Article

Here are the abbreviations that appear from the very beginning, spelled out.

In the diagram a solid line marks a relation that always holds and a dashed line marks a conditional one (the conditions are given per relation on the detail page). The full list of relations (24 in total, with evidence and certainty) and the definitions of the main concepts are collected on the knowledge map detail page (in Japanese). Data: JSON-LD / Turtle

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]

Figure 1: The account is the identifier, the profile is the actual settings and data, and the device loads and uses it.

• 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

Figure 2: At sign-in, the folders are prepared and NTUSER.DAT is loaded, and together they make the user settings take effect.

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]

Figure 3: At first sign-in, a profile dedicated to that user is created from the Default template.

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]

Figure 4: A profile is made of folders plus NTUSER.DAT, and AppData splits further into three.

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[Area writable by low integrity processes]

Figure 5: Roaming holds settings to carry around, Local holds what is specific to that PC, and LocalLow is where low integrity processes write.

LocalLow Is Not “the Place Nobody Uses” - It Is Where Low-Privilege Apps Write

Of the three, LocalLow tends to get the shortest explanation, but that is only because its purpose is narrow. Its reason for existing is perfectly clear.

Windows processes have a privilege tier called the integrity level, and a process running at low integrity cannot write to AppData\Roaming, AppData\Local, or most of HKCU. Since such a process could otherwise save nothing at all, Windows provides places that remain writable at low integrity: %USERPROFILE%\AppData\LocalLow on the file system, and HKEY_CURRENT_USER\Software\AppDataLow on the registry side. [19]

Summarized, it looks like this.

The classic example is an application, such as a browser, that deliberately drops the component handling content straight from the internet down to a lower privilege level. The design intent is that even if that process is compromised, the damage stays confined inside LocalLow.

From an application developer’s point of view, the conclusion is simple.

• If your application does not run at low integrity, there is no reason to use LocalLow. Use Local.
• Conversely, if unfamiliar folders are piling up under LocalLow, whatever is writing there is running at low integrity. That is a useful clue during a disk usage investigation.

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]

Figure 6: Default is the seed for new profiles, Public is the shared area, and each user folder is an individual instance.

• 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]

Figure 7: Operationally, profiles split into at least five kinds, from local all the way to FSLogix.

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]

Figure 8: A roaming profile is a mechanism where several PCs receive the same profile from a server share.

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 never saves, 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]

Figure 9: A mandatory profile is prepared by an administrator and discards the session’s changes at sign-out.

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

• Educational devices
• Reception terminals
• Kiosks
• 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]

Figure 10: A temporary profile is the fallback for a failed load, and the changes disappear 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]

Figure 11: FSLogix attaches a profile on a VHD at sign-in and presents it as a native one.

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]

Figure 12: The three approaches differ in how much travels: the whole profile, only known folders, or a container.

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]

Figure 13: Folder Redirection relocates individual folders rather than the entire profile.

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]

Figure 14: Mixing roaming profiles from different OS generations on the same share causes inconsistencies.

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]

Figure 15: Sort the data to store in this order: deliverable, machine-specific, per-user setting, then shared.

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.

flowchart TB
    accTitle: Separating deliverables from internal application state
    accDescr: A diagram showing that unless the deliverables a user consciously works with are treated as business data in places such as Documents, and internal application state such as settings and caches is treated as storage kept for the application's own convenience, both backups and migrations break easily.
    sp1["Files to store"] --> sp2["Deliverables the user is aware of"]
    sp1 --> sp3["Internal application state"]
    sp2 -.-> sp4["Business data such as Documents"]
    sp3 -.-> sp5["Settings and caches exist for the app"]

Figure 16: Even for the same file, business data and application-owned data deserve different locations and handling.

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]

Figure 17: Customizing the default profile goes through the Sysprep and CopyProfile path.

Approaches such as manually copying 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]

Figure 18: Whether logon succeeds and whether everything looks reset split profile problems into three categories.

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

On Japanese-language Windows, the left-hand Event Viewer tree reads アプリケーションとサービス ログ (Applications and Services Logs) > Microsoft > Windows > User Profile Service > Operational. Everything from the provider name downward stays in English.

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

Figure 19: Investigation goes deeper in order: Application log, Operational, Diagnostic, then 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.

The Three Logs Live in Three Different Places

This is the first thing people get lost in, so let us settle it up front. [10]

The Diagnostic log does not appear in the tree as-is. In Event Viewer, turn on Action pane > View > Show Analytic and Debug Logs, select Diagnostic, and then run Enable Log. Once the investigation is over, always turn it back off. It is far too verbose a log to leave running. [10]

Getting the Same Data Without Opening the GUI

When you want reproducibility, or when you are investigating a remote machine, collecting the data by command is more reliable. Being able to say “run this command and send me the output” is far faster than talking someone through the Event Viewer UI second-hand.

# 1) List only User Profile Service events from the Application log, newest first
Get-WinEvent -FilterHashtable @{
    LogName      = 'Application'
    ProviderName = 'Microsoft-Windows-User Profiles Service'
} -MaxEvents 50 | Select-Object TimeCreated, Id, LevelDisplayName, Message

# 2) Read the Operational log directly
Get-WinEvent -LogName 'Microsoft-Windows-User Profile Service/Operational' -MaxEvents 50 |
    Select-Object TimeCreated, Id, LevelDisplayName, Message

# 3) Narrow down to Event ID 1509, the long-path case
Get-WinEvent -FilterHashtable @{
    LogName      = 'Application'
    ProviderName = 'Microsoft-Windows-User Profiles Service'
    Id           = 1509
} | Format-List TimeCreated, Id, Message

There is one trap here. The source name on the Application log side is Microsoft-Windows-User Profiles Service (Profiles, plural), while the channel name of the Operational log is Microsoft-Windows-User Profile Service/Operational (Profile, singular). When a copy-and-paste does not run, this is usually why.

Event ID 1509 shows up in the Application log, not the Operational log. Its level is Warning, and the body is a message of the form “Windows cannot copy file \\server\share\... to location C:\Users\...” followed by DETAIL - The filename or extension is too long. That last line is the decisive clue that path length is the cause. [16]

There is one more thing worth knowing that saves time in practice. Microsoft states explicitly that User Profile Service event 1530, “Windows detected your registry file is still in use by other applications or services,” can be ignored. [10] Chasing it produces nothing.

flowchart TB
    accTitle: The singular and plural trap in the log names
    accDescr: A diagram showing that the source name on the Application log side is Profiles in the plural while the channel name of the Operational log is Profile in the singular, and that mixing the two up is usually why a copied and pasted command fails to run.
    lg1["The command does not run"] --> lg2{"Which log name was used"}
    lg2 -->|"Application source name"| lg3["Profiles, plural"]
    lg2 -->|"Operational channel name"| lg4["Profile, singular"]
    lg3 -.-> lg5["Mixing them up is the classic cause"]
    lg4 -.-> lg5

Figure 20: Two deceptively similar log names are the classic reason a pasted command fails.

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]

Figure 21: If the DAT files cannot be accessed, the result is a logon failure or a fallback to a temporary profile.

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]

Figure 22: Registry information left behind by a careless deletion creates inconsistencies at the next logon.

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]

Figure 23: The first-choice approach changes with the usage pattern, from primarily local all the way to FSLogix.

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]

Figure 24: Multiple session hosts attach and use a VHDX profile that lives on shared storage.

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.

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

all get in the way. In particular, for roaming across OS generations, Microsoft itself assumes profile version separation. [6]

flowchart TB
    accTitle: Why a crude copy migration is dangerous
    accDescr: A diagram showing that migrating a user folder by copying it wholesale is dangerous because it carries the problems of OS version compatibility, NTUSER.DAT, permissions, application-specific state, and cross-contamination with the default profile.
    mv1["Copy the whole folder"] --> mv2["Looks like the migration worked"]
    mv2 -.-> mv3["OS compatibility and NTUSER.DAT issues remain"]
    mv2 -.-> mv4["Permissions and default profile get tangled"]
    mv3 --> mv5["A migration that breaks later"]
    mv4 --> mv5

Figure 25: A profile is more than folders, so a copy cannot carry it across.

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.

flowchart TB
    accTitle: The three questions behind profile design
    accDescr: A diagram showing that profile design comes down to three questions - what goes where, how far it travels, and how you recover when something fails - and that settling them makes device deployment, application design, and failure investigation easier.
    dq1["What goes where"] --> dq2["How far it travels"]
    dq2 --> dq3["How you recover from a failure"]
    dq3 -.-> dq4["Deployment, design, and investigation get easier"]

Figure 26: Answer these three questions and profile design is essentially settled.

11. Related Articles

• When Do You Actually Need Administrator Privileges on Windows? - UAC, Protected Areas, and How to Tell by Design
• How to Speed Up App 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

There are a lot of sources, so here is an index you can enter from the question you have.

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.

19. Microsoft Learn, Designing Applications to Run at a Low Integrity Level That %USERPROFILE%\AppData\LocalLow and HKEY_CURRENT_USER\Software\AppDataLow are provided as the places a low integrity process can write to.

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.

Frequently Asked Questions

Common questions about the topic of this article.

What is NTUSER.DAT?

NTUSER.DAT is the file that holds the user registry hive contained in a Windows user profile. It sits directly under C:\Users\<username>, is loaded at sign-in, and is used as HKEY_CURRENT_USER (HKCU). In other words, a user profile is made of two layers: the files such as Desktop and AppData, and the registry layer centered on NTUSER.DAT. If NTUSER.DAT is marked read-only or the required access rights are missing, loading the profile fails, which causes logon failures or a fallback to a temporary profile.

What is a Windows user profile, and how is it different from an account?

An account identifies who signs in; a user profile is the actual working environment of that person. A profile is not merely the C:\Users\<username> folder - it is the set of files such as Desktop, Documents, and AppData plus the user registry hive NTUSER.DAT. When a new user signs in for the first time, a new profile is created using C:\Users\Default as the template. How far the settings travel with the user depends on which approach you choose: local, roaming, Folder Redirection, or FSLogix.

How should I decide between %APPDATA% and %LOCALAPPDATA%?

As a rule, settings you want each user to carry around go in %APPDATA% (AppData\Roaming), and caches or transient state specific to that PC go in %LOCALAPPDATA% (AppData\Local). Roaming regenerable caches and large work files tends to make sign-in and sign-out slow, so keep them on the Local side. Mutable data shared by all users is a candidate for ProgramData, but that has to be designed together with the ACLs that decide who reads and who writes. Putting per-user runtime data in Program Files should be avoided.

What should I do when a user is logged on with a temporary profile?

A temporary profile is an emergency fallback issued when an error prevents the real profile from being loaded; it is deleted at sign-out and the changes are lost. Continuing to work in that state risks losing important data, so it is a state to get out of. When investigating, do not go straight to C:\Users - check the Application log and the User Profile Service Operational log first, and the Diagnostic log if necessary. Common causes include attribute or permission problems on NTUSER.DAT / USRCLASS.DAT, roaming destination paths that are too long, and registry information left behind by an incomplete deletion.

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.