Windows 用户配置文件入门 - AppData 与 NTUSER.DAT

本文面向管理 Windows 的信息系统人员、终端部署负责人以及 Windows 应用开发者，以一般性论述的方式进行整理。 图为概念图。在支持 Mermaid 的 Markdown 环境中会以图表形式显示。

内容基于截至 2026 年 4 月能够确认到的 Microsoft 官方信息。[1][4][7][10][13][14]

在与 Windows 相关的咨询中，「配置文件（Profile）」这个词的使用范围相当广泛。

• C:\Users\用户名 里面到底是什么
• %AppData% 和 %LocalAppData% 该如何区分使用
• 域环境中的漫游配置文件是什么
• Mandatory 配置文件与 Temporary 配置文件有什么区别
• 共享 PC、RDS、VDI、Azure Virtual Desktop 该选哪种方案
• 配置文件损坏时，应该从哪里开始排查

这一带，账户、文件夹、注册表、同步方式、运维策略一下子混在一起，话题很容易跑偏。

本文首先建立把 Windows 用户配置文件当作一张设计图来看的视角，然后按顺序整理AppData 的使用区分、漫游、Mandatory、Temporary、FSLogix、故障时的排查思路。

1. 先说结论

在深入细节之前，先把实务上的结论列出来。

• Windows 的用户配置文件不是单纯的一个 C:\Users\用户名 文件夹，而是文件组 + 用户注册表配置单元（NTUSER.DAT）的组合。[1]
• 普通的本地 PC 默认会创建本地配置文件。首次登录时，会以 C:\Users\Default 为基础创建新的配置文件。[11][12]
• 应用程序的保存位置不应随意决定，基本原则是：想随用户一起带走的设置放在 %APPDATA%，该电脑专属的缓存或临时状态放在 %LOCALAPPDATA%。[2][3]
• 漫游配置文件（Roaming Profile）是「把整个配置文件都寄放到共享位置」的机制，Folder Redirection 则是「只把 Documents 等已知文件夹寄放到别处」的机制，两者并不相同。[4][5]
• Mandatory 配置文件是一种「让人使用但不保存变更」的只读配置文件。Temporary 配置文件则是出错时的紧急应对，前提是每次都会被删除。[7][8][9]
• 跨 OS 世代的漫游配置文件需要特别留意。Windows 10 / Server 2016 及之后版本与更早版本之间不兼容，应该考虑按配置文件版本分开处理。[6]
• 在 RDS / VDI / Azure Virtual Desktop 中，与单纯依赖传统漫游配置文件相比，很多场景下更应该优先考虑FSLogix 配置文件容器。Microsoft 在 Azure Virtual Desktop 中也推荐使用 FSLogix。[13][14]
• 出现问题时，不要一开始就直接动 C:\Users，先查看Application 日志、User Profile Service 的 Operational / Diagnostic 日志、共享路径、NTUSER.DAT / USRCLASS.DAT 的属性和权限，这样思路更清晰。[10][11][16]

总而言之，Windows 配置文件的话题归结起来就是：「把什么放在哪里、能带多远、失败时如何恢复」。

2. Windows 的「用户配置文件」到底是什么

首先，把账户和配置文件分开来看，理解起来会更轻松。

flowchart LR
    A[用户账户<br/>谁在登录] --> B[用户配置文件<br/>该用户的设置与数据]
    C[终端 / OS] --> B
    B --> D[桌面设置]
    B --> E[AppData]
    B --> F[Documents / Desktop 等]
    B --> G[HKCU 中可见的设置]

• 账户用来标识某个人
• 配置文件是该用户工作环境的实体
• 终端是加载并使用该配置文件的场所

Microsoft Learn 中也说明，用户配置文件包含文件系统上的配置文件文件夹组与注册表配置单元 NTUSER.DAT，登录时会加载该配置单元并将其用作 HKEY_CURRENT_USER。[1]

2.1 不仅是「文件夹」，还「包含注册表」

这一点很重要。

flowchart TD
    A[登录] --> B[定位配置文件文件夹]
    B --> C[加载 NTUSER.DAT]
    C --> D[作为 HKCU 使用]
    B --> E[准备 Desktop / Documents / AppData]
    D --> F[用户设置生效]
    E --> F

也就是说，只看 C:\Users\用户名 还只看到了一半。

Windows 配置文件大致由以下两层构成。

1. 文件层 Desktop、Documents、Downloads、AppData 等
2. 注册表层 加载了 NTUSER.DAT 的 HKCU

关于配置文件损坏之所以复杂，是因为存在只有文件夹一侧损坏的情况，也存在注册表配置单元一侧出问题的情况。[1][11]

2.2 首次登录时以 Default 为基础

新用户第一次在该电脑上登录时，Windows 会以 C:\Users\Default 为基础创建本地配置文件。[11]

flowchart LR
    A[C:\Users\Default] --> B[首次登录]
    B --> C[生成 C:\Users\用户名]
    C --> D[加载 NTUSER.DAT]
    D --> E[成为该用户专属的环境]

在镜像部署或装机场景中，如果在这一点上处理得比较随意，后面会相当痛苦。

Microsoft 说明，关于自定义默认配置文件，受官方支持的方法是使用 CopyProfile。手动复制或老旧的粗放式复制方式，会带入多余的信息，有时还会给应用程序或系统稳定性带来问题。[12]

3. 如何看待 C:\Users\用户名

从文件夹的角度来看用户配置文件，大致是这样的结构。

flowchart TD
    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]

在实务中，最先要看的位置大致就是下面这些。

3.1 把 AppData 分成 3 部分来看

在 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
    A[AppData] --> B[Roaming]
    A --> C[Local]
    A --> D[LocalLow]

    B --> B1[想要随用户带走的设置]
    B --> B2[较小的用户状态]

    C --> C1[缓存]
    C --> C2[可重新生成的数据]
    C --> C3[该电脑专属的状态]

    D --> D1[特殊用途]

实务中的使用区分可以这样考虑

ProgramData 在 Microsoft 的已知文件夹定义中被定位为面向所有用户的应用程序数据，用于不会漫游的共享数据。[3]

这里最应该避免的，就是把每个用户各自的运行时数据放在 Program Files 中。 这样很容易一下子打乱配置文件的整理结构和权限设计。

3.2 Public 与 Default 的角色不同

这里也容易混淆。

flowchart LR
    A["C:\Users"] --> B[Default]
    A --> C[Public]
    A --> D[各用户]

    B --> B1[新配置文件的种子]
    C --> C1[所有用户可见的共享内容]
    D --> D1[各个用户的实体]

• Default 是用来创建新配置文件的模板
• Public 是展示给所有用户的共享区域
• 各用户文件夹是该用户专属的实体

这三者看起来相似，但角色完全不同。

4. 梳理配置文件的种类

「配置文件」这个说法虽然简单，但在运维上至少存在以下这些种类。

flowchart TD
    A[Windows 的配置文件] --> B[本地配置文件]
    A --> C[漫游配置文件]
    A --> D[Mandatory 配置文件]
    A --> E[Temporary 配置文件]
    A --> F[FSLogix 配置文件容器]

4.1 本地配置文件

普通 PC 默认使用的就是这一种。

• 在该 PC 的本地磁盘上创建
• 不会自动带到其他 PC
• 在单机场景下最为简单

Microsoft 也说明，Windows 默认会创建本地用户配置文件。[14]

4.2 漫游配置文件

Microsoft Learn 中说明，漫游用户配置文件保存在服务器共享中，是一种让多台计算机能够获得相同 OS / 应用设置的机制。[4][5]

flowchart LR
    A[共享服务器上的配置文件] <--> B[PC-A]
    A <--> C[PC-B]
    A <--> D[PC-C]

不过，实务中有以下几点需要注意。

• 登录 / 注销时的复制或同步容易变得沉重
• 如果 AppData\Local 中积累了大量数据会很痛苦
• 容易受到 OS 版本差异问题的影响
• 会强烈受到共享路径和网络质量的影响

4.3 Mandatory 配置文件

Mandatory 配置文件是管理员创建的「不会保存变更的漫游配置文件」。[7][8]

根据 Microsoft 的说明，在 Mandatory 配置文件中，即使用户在会话期间做了更改，也不会像普通漫游配置文件那样被保存。[7]

此外，Win32 文档中还说明：

• 把 NTUSER.DAT 重命名为 NTUSER.MAN，就会变成 Mandatory
• 把配置文件路径的文件夹名末尾改成 .man，就会变成 Super-mandatory

[8]

flowchart LR
    A[管理员准备好的配置文件] --> B[用户登录]
    B --> C[使用期间可以修改]
    C --> D[注销]
    D --> E[变更不会保存]

例如，这种方式适合以下用途。

• 教学终端
• 前台接待终端
• 自助终端（kiosk）
• 希望每次都恢复到干净状态的共享终端

4.4 Temporary 配置文件

Temporary 配置文件不是一种可以主动选择的设计方案，而是在发生错误、无法加载本来的配置文件时启用的应急去处。[9]

Microsoft Learn 中说明，当出现错误条件、无法加载本来的配置文件时，会启用 Temporary profile，它会在会话结束时被删除，期间的变更都会丢失。[9]

flowchart TD
    A[开始加载常规配置文件] --> B{能否加载}
    B -->|Yes| C[正常登录]
    B -->|No| D[以 Temporary 配置文件登录]
    D --> E[可以继续工作]
    E --> F[注销后变更消失]

也就是说，正在以 Temporary 配置文件运行这件事本身，就是一种异常信号。

4.5 FSLogix 配置文件容器

关于 FSLogix，Microsoft Learn 中说明它是一种让 Windows 用户配置文件体验在虚拟桌面环境中保持一致的机制。[13]

FSLogix 配置文件容器的方式是，把整个用户配置文件作为 VHD / VHDX 保存，登录时挂载该文件，使其看起来像原生配置文件。[13][14]

flowchart LR
    A[VHD / VHDX 上的配置文件] --> B[登录时挂载]
    B --> C[在会话主机上表现为 C:\Users\用户]
    C --> D[注销时卸载]

在 Azure Virtual Desktop 中，Microsoft 推荐使用 FSLogix profile containers。[14]

5. 漫游配置文件、Folder Redirection、FSLogix 有什么区别

这三者常被放在一起谈论，但角色其实并不相同。

flowchart TD
    A[携带用户状态] --> B[漫游配置文件]
    A --> C[Folder Redirection]
    A --> D[FSLogix]

    B --> B1[把整个配置文件寄放到共享位置]
    C --> C1[只把已知文件夹寄放到别处]
    D --> D1[挂载 VHD/VHDX]

参照 Microsoft Learn 的整理方式，用下面这样的方式来看会更容易理解区别。[4][5][14]

5.1 Folder Redirection 只寄放「已知文件夹」

Microsoft Learn 中说明，Folder Redirection 是一种把 known folder（已知文件夹）的路径指向别处的机制。[4]

例如，把 Documents 寄放到文件共享后，用户看到的样子和本地一样，但实体其实在别的位置。[4]

flowchart LR
    A[Documents] --> B[实体在文件共享中]
    C[Desktop] --> D[需要时另行设置]
    E[AppData] --> F[保持原样或采用其他方式]

也就是说，Folder Redirection 并不是整个配置文件的替代方案，而是按文件夹单位的位置调整。

5.2 漫游配置文件不要随意跨 OS 世代混用

Microsoft 说明，Windows 10 / Server 2016 及之后版本的漫游配置文件，与更早期的 Windows 不兼容。[6]

flowchart LR
    A[Windows 7 / 8.1 系列] -.混用需注意.-> B[同一个共享]
    C[Windows 10 / Server 2016 及之后] -.混用需注意.-> B
    B --> D[不一致 / 开始菜单异常 / 任务栏异常的原因]

这里重要的是：

• 按 OS 世代区分配置文件版本
• 不要认为「同一个用户，用同一个文件夹就行」
• 在终端部署或更换时，把配置文件的兼容性纳入迁移计划

这几点。[6]

6. 开发者与运维人员应优先确定的存储位置

配置文件的话题，最终都会回到这一点上——该把什么放在哪里。

flowchart TD
    A[想保存的数据] --> B{是否是用户创建的成果物}
    B -->|Yes| C[Documents 等]
    B -->|No| D{是否该电脑专属}
    D -->|Yes| E[%LOCALAPPDATA%]
    D -->|No| F{是否是用户各自的设置}
    F -->|Yes| G[%APPDATA%]
    F -->|No| H{是否是全用户共享的可变数据}
    H -->|Yes| I[ProgramData + ACL]
    H -->|No| J[重新考虑存放位置]

6.1 区分用户创建的文件与应用内部状态

如果把这两者混在一起，备份和迁移都会很容易出问题。

• 用户主动处理的成果物 Documents、Pictures、业务保存文件夹
• 应用内部的状态 设置、缓存、缩略图、会话信息、工作文件

前者是业务数据，后者是出于应用自身需要。 即使同样是「文件」，也最好分开处理。

6.2 放在 %APPDATA% 中的内容

这里存放的大致是这样的内容。

• 较小的设置
• 每个用户各自的偏好设置（preference）
• 想在多个终端上保持相同外观的状态
• 可以跟随配置文件一起携带的内容

在 Fast User Switching 的文档中，也建议将 FOLDERID_RoamingAppData 作为应用专属数据的存放位置。[2]

6.3 放在 %LOCALAPPDATA% 中的内容

应该放在这里的，是从重新生成和是否需要携带的角度来看、应封闭在本地的内容。

• 可以重新生成的缓存
• 只在本地才有意义的状态
• 较大的工作文件
• 出于性能考虑不想让它随用户漫游的内容

在 Known Folders 的定义中，LocalAppData 也是 %USERPROFILE%\AppData\Local。[3]

6.4 放在 ProgramData 中的内容

全体用户共用，但在运行期间会变化的数据，可以考虑放在 ProgramData 一侧。[3]

例如：

• 共享字典
• 全体用户共用的定义文件
• 服务与多个用户共享的可变数据

不过，这里需要连同 ACL 设计一起考虑。 不能只是「因为是共享的所以先放 ProgramData」，重要的是决定谁能读、谁能写。

6.5 想要定制默认配置文件时

在镜像部署中，「想让所有新用户都获得相同的初始设置」是很常见的需求。 这种情况下，不要随意修改 Default，而是采用 Microsoft 官方支持的基于 CopyProfile 的方法来搭建，这样更安全。[12]

flowchart LR
    A[以管理员账户进行初始设置] --> B[Sysprep + CopyProfile]
    B --> C[反映到 Default profile]
    C --> D[应用于此后的新用户]

像「把某台 PC 的 C:\Users\A 手动复制到另一台 PC 的 Default」这样的做法，表面上看起来很快，但之后很容易出问题。[12]

7. 损坏、变成临时配置文件、不同步时的排查思路

这是现场最令人头疼的部分。 而且症状看起来很相似，如果排查得不够细致，很容易越查越深、迟迟找不到头绪。

7.1 先把症状分成 3 类

flowchart TD
    A[疑似配置文件问题] --> B{能否登录}
    B -->|Yes| C{外观是否被初始化}
    B -->|No| D[加载失败类]
    C -->|Yes| E[Temporary / 损坏 / 其他配置文件]
    C -->|No| F{是否只有部分设置被还原}
    F -->|Yes| G[漫游 / 重定向 / 同步类]
    F -->|No| H[可能是应用个别问题]

大致可以分成以下 3 大类。

1. 登录时失败
2. 能登录，但看起来像是被初始化了
3. 只有部分内容没有同步

7.2 首先应该查看的日志

Microsoft Learn 建议，在排查配置文件问题时按以下顺序查看。[10]

1. Application 日志
2. User Profile Service 的 Operational 日志
3. 必要时查看 Diagnostic 日志
4. 如仍需要，进一步查看 ETL 跟踪

具体路径如下。[10]

• 事件查看器（Event Viewer） Applications and Services Logs > Microsoft > Windows > User Profile Service > Operational
• 需要查看更多细节时 … > User Profile Service > Diagnostic

flowchart LR
    A[Application 日志] --> B[Operational 日志]
    B --> C[Diagnostic 日志]
    C --> D[ETL 跟踪]

在现场，与一开始就直接修复注册表或删除文件夹相比，先通过日志把握「加载失败」「复制失败」「访问被拒绝」「路径过长」「无法写入共享」等方向，会更安全。

7.3 常见原因

NTUSER.DAT / USRCLASS.DAT 的属性或权限

Microsoft 说明，如果 NTUSER.DAT 或 USRCLASS.DAT 变成了 Read-only（只读），或者缺少所需的访问权限，配置文件加载就可能失败。[11]

这个原因看起来不起眼，但一旦被忽略，问题就会拖得很久。

flowchart LR
    A[加载配置文件] --> B{能否访问 DAT 文件}
    B -->|No| C[登录失败 / 初始桌面 / Temporary]
    B -->|Yes| D[正常加载]

漫游复制时路径过长

Microsoft 的 KB 文章中说明了这样的例子：由于共享路径一侧的服务器名或共享名过长，导致目标路径整体过长，从而伴随 Event ID 1509 而落到临时配置文件的情况。[16]

看起来只是简单的路径长度限制，但实际上原因有时出在漫游目标本身的设计上。

因删除不完整而残留的注册表 / 文件夹信息

Microsoft 提供了一篇示例脚本文章，介绍如何清理残留在注册表和 C:\Users 中的孤立信息，以防止出现 TEMP 配置文件。[15]

从这一点可以看出，并不是删除文件夹就万事大吉。

flowchart LR
    A[随意删除旧配置文件] --> B[注册表信息残留]
    B --> C[下次登录出现不一致]
    C --> D[成为 TEMP 配置文件或附加文件夹的原因]

7.4 首先应该确认什么

8. 应该选择哪种方式

这里并不存在「唯一正确答案」。 应根据使用形态而有所不同。

flowchart TD
    A[使用形态] --> B[个人专用 PC]
    A --> C[加入域的办公 PC]
    A --> D[共享 PC / 教学终端]
    A --> E[RDS / VDI / AVD]

    B --> B1[以本地为主]
    C --> C1[视需要采用 Folder Redirection / 漫游]
    D --> D1[Mandatory / Shared PC / cleanup]
    E --> E1[优先考虑 FSLogix]

8.1 个人专用 PC

基本上使用本地配置文件就足够了。

• 用户设置放在 AppData
• 成果物放在 Documents
• 如有需要，可通过 OneDrive 等其他层面来同步文档

这种结构最为简单。

8.2 加入域的办公 PC

根据需求，可以组合使用以下方式。

• 想要集中管理文档数据 → Folder Redirection
• 想让多台 PC 保持相同设置 → 漫游配置文件
• 存在 OS 混用或超大配置文件的情况 → 需要谨慎设计，或重新审视方式

Microsoft Learn 中也提到，Folder Redirection 和 Roaming User Profiles 有助于实现集中管理、离线使用、简化备份等目标。[4]

8.3 共享 PC / 教学终端 / 自助终端

在这类用途中，比起「保留个人化设置」，更重要的是每次都能恢复到干净状态。

可选方案有以下 3 种。

• Mandatory 配置文件
• Shared PC 模式
• 旧配置文件自动删除策略

Microsoft 提供了名为 Delete user profiles older than a specified number of days on system restart 的策略，可以在重启时删除超过指定天数未被使用的配置文件。[17]

另外，在 Shared PC 的指南中也提出了在共享终端上组合使用账户 / 配置文件自动管理与删除的思路。[18]

8.4 RDS / VDI / Azure Virtual Desktop

在这类场景下，很多情况下单靠传统的漫游配置文件已经力不从心。

Microsoft 在 Azure Virtual Desktop 中推荐使用 FSLogix profile containers，说明会在登录时挂载 VHDX / VHD，并将其当作原生用户配置文件来处理。[14]

flowchart LR
    A[多台会话主机] --> B[共享存储]
    B --> C[VHDX 中的用户配置文件]
    C --> D[挂载到所连接的主机]

尤其是在以下这些条件下，优先考虑 FSLogix 更有价值。

• 会话主机每次都会变化
• 使用 Outlook / OneDrive / Microsoft 365 系列产品
• 非持久化 VDI 中必须携带配置文件
• 漫游配置文件的登录延迟成为问题

9. 常见的误解

9.1 「只要创建账户，配置文件也会在任何地方使用同一份」

并非如此。账户只是标识符，配置文件才是终端一侧的实体。 能带到多远，取决于本地、漫游、Folder Redirection、FSLogix 等方式的选择。[4][14]

9.2 「复制 C:\Users\用户名 就能完成迁移」

随意复制是很危险的。

• OS 版本兼容性
• NTUSER.DAT
• 权限
• 应用专属状态
• 与默认配置文件之间的混线

都会带来影响。特别是在存在 OS 世代差异的漫游场景中，Microsoft 也是以配置文件版本分离为前提的。[6]

9.3 「Mandatory 和 Temporary 是类似的东西」

这两者是完全不同的东西。Mandatory 是管理员有意创建的只读配置文件，Temporary 则是在出错、无法读取本来的配置文件时使用的应急去处。[8][9]

9.4 「想同步的话，把所有内容都放进 Roaming 就好」

这样很危险。如果把设置和巨大缓存放进同一个「箱子」，登录 / 注销以及故障处理都会变得沉重。 把想要漫游的内容和应封闭在本地的内容区分开来，运维起来会更轻松。[2][3]

9.5 「即使变成了临时配置文件，照样用下去也没关系」

最好避免这样做。因为 Temporary profile 本来就是以注销后会被删除为前提的， 如果在这种状态下继续工作，就有可能把重要数据放在了之后会被删除的位置，存在这样的风险。[9]

10. 总结

Windows 的用户配置文件，并不只是指 C:\Users 下面的某个文件夹。

• 文件组
• 以 NTUSER.DAT 为核心的用户注册表
• 该配置文件存放在哪里、如何同步、如何删除等运维方式

把这些一并纳入考虑、当作一个整体设计来看待，思路就会变得清晰。

在实务中，希望大家优先掌握以下这 6 点。

• 单机 PC 的话，首先以本地配置文件为基准来考虑
• 应用的存放位置要区分 Roaming / Local / ProgramData
• 在域环境中，不要把漫游配置文件和 Folder Redirection 混为一谈
• 在共享终端上，考虑 Mandatory / cleanup / Shared PC
• 在 RDS / VDI / AVD 中，把 FSLogix 作为首选
• 出现故障时，先查看 User Profile Service 的日志

归根结底，配置文件的设计不在于「保存到哪里」，而在于「把什么当作是谁的东西、能带到多远」的设计。 只要这一点确定下来，无论是终端部署、Windows 应用的设计，还是故障排查，都会变得容易许多。

11. 相关文章

• Windows 什么时候需要管理员特权 - UAC、受保护区域与设计上的判断方法
• 用 Windows 沙盒加快 Windows 应用开发验证的方法

12. 与本主题相关的服务

Windows 应用开发

如何划分用户设置、日志、缓存、共享数据的存放位置，会在很大程度上左右 Windows 应用的可运维性与可维护性。 如果想从需求整理一直延伸到设计、实现与长期运维，这是一个和 Windows 应用开发场景很契合的主题。

查看服务 / 联系我们

技术咨询与设计评审

该选择本地、漫游还是 FSLogix，要如何改变现有终端的运维方式，存放位置又该如何划分——这些问题在实现之前是否整理清楚，会带来相当大的差别。 如果想从方式选型和边界设计开始梳理，这是一个很适合作为技术咨询、设计评审来切入的主题。

查看服务 / 联系我们

故障排查与原因分析

转为 Temporary 配置文件、登录失败、注销时保存失败、共享路径相关的问题排查，都与故障排查这项工作非常契合。 如果想从日志、事件、权限、共享结构等角度来彻查难以重现的配置文件问题，这里可以作为咨询的入口。

查看服务 / 联系我们

13. 参考资料

1. Microsoft Learn, About User Profiles (Windows) 用户配置文件的构成要素、NTUSER.DAT、Temporary profile 的基础知识。

2. Microsoft Learn, Fast User Switching 应用专属数据使用 FOLDERID_RoamingAppData，不在其他计算机上使用的数据使用 FOLDERID_LocalAppData 的整理方式。

3. Microsoft Learn, KNOWNFOLDERID, CSIDL %APPDATA%、%LOCALAPPDATA%、LocalLow、ProgramData 等已知文件夹的定义。

4. Microsoft Learn, Folder Redirection and Roaming User Profiles in Windows and Windows Server Folder Redirection 与 Roaming User Profiles 的区别，以及集中管理的思路。

5. Microsoft Learn, Deploy roaming user profiles 漫游配置文件的部署、共享权限、GPO、版本管理的实务步骤。

6. Microsoft Learn, Roaming user profiles of earlier versions of Windows are incompatible with Windows 10, Windows Server 2016, and later versions OS 世代之间的不兼容性与配置文件版本管理。

7. Microsoft Learn, Create mandatory user profiles Mandatory user profile 的用途与创建方法。

8. Microsoft Learn, Mandatory User Profiles NTUSER.MAN、Super-mandatory profile 的定义。

9. Microsoft Learn, Temporary User Profiles Temporary profile 的定义与性质。

10. Microsoft Learn, Troubleshoot user profiles with events 使用 Application / Operational / Diagnostic 日志进行排查的方法。

11. Microsoft Learn, Error occurs during desktop setup and desktop location is unavailable when you log on to Windows for the first time 以 C:\Users\Default 为起点创建新配置文件的过程，以及 NTUSER.DAT / USRCLASS.DAT 的属性、权限问题。

12. Microsoft Learn, Customize the default local user profile when you prepare an image of Windows 使用 CopyProfile 进行受支持的默认配置文件自定义方法。

13. Microsoft Learn, What is FSLogix, Types of Containers FSLogix 的基础知识，以及 Profile Container 的设计思路。

14. Microsoft Learn, User profile management for Azure Virtual Desktop with FSLogix profile containers, Configure profile containers using FSLogix Azure Virtual Desktop 中的推荐做法，以及使用 VHD / VHDX 的配置文件容器方式。

15. Microsoft Learn, Scripts: Clean up profile folder information and prevent TEMP user profiles from being created 孤立的配置文件信息与 TEMP profile 之间的关系。

16. Microsoft Learn, User profile cannot be loaded with Event ID 1509: DETAIL - The filename or extension is too long 漫游配置文件保存时出现的路径过长问题。

17. Microsoft Learn, ADMX_UserProfiles Policy CSP Delete user profiles older than a specified number of days on system restart 等策略的定义。

18. Microsoft Learn, Configure a shared or guest Windows device Shared PC 模式与共享终端的账户 / 配置文件管理。

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

常见问题

汇总了咨询这一主题时常见的问题。

NTUSER.DAT 是什么？

NTUSER.DAT 是 Windows 用户配置文件中所包含的用户注册表配置单元（registry hive）的实体文件。它位于 C:\Users\用户名 目录下，登录时会被加载并作为 HKEY_CURRENT_USER（HKCU）使用。也就是说，用户配置文件由 Desktop、AppData 等文件组，以及以 NTUSER.DAT 为核心的注册表层这两层构成。如果 NTUSER.DAT 变成只读属性，或者缺少所需的访问权限，就会导致配置文件加载失败，从而引发登录失败或转为临时配置文件的问题。

Windows 的用户配置文件是什么？和账户不一样吗？

账户用于标识「谁在登录」，而用户配置文件则是这个人工作环境的实体。配置文件不只是一个 C:\Users\用户名 文件夹，而是由 Desktop、Documents、AppData 等文件组，以及名为 NTUSER.DAT 的用户注册表配置单元组合而成。新用户第一次登录该电脑时，Windows 会以 C:\Users\Default 为基础创建新的配置文件。至于设置能被带到多远，则取决于本地、漫游、Folder Redirection、FSLogix 等方式的选择。

%APPDATA% 和 %LOCALAPPDATA% 应该怎么区分使用？

基本原则是，想随用户一起带走的设置放到 %APPDATA%（AppData\Roaming），而该电脑专属的缓存或临时状态则放到 %LOCALAPPDATA%（AppData\Local）。如果把可以重新生成的缓存或较大的工作文件也一起漫游，登录、注销就容易变得缓慢，因此这类数据应偏向放在 Local 一侧。全体用户共用的可变数据可以考虑放在 ProgramData，但需要同时设计好谁能读写的 ACL（访问控制列表）。应避免把用户各自的运行时数据放在 Program Files 中。

以临时配置文件（Temporary profile）登录时该怎么办？

临时配置文件是在发生错误、无法加载原本的配置文件时启用的紧急应对措施，注销时会被删除，期间的所有更改都会丢失。如果就这样继续工作，就有丢失重要数据的风险，因此这是应该避免的状态。排查时不要一开始就直接动 C:\Users，而应先查看 Application 日志和 User Profile Service 的 Operational 日志，必要时再查看 Diagnostic 日志。常见原因包括 NTUSER.DAT / USRCLASS.DAT 的属性或权限问题、漫游目标路径过长的问题，以及因删除不完整而残留的注册表信息等。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。