Windows 使用者設定檔入門 - AppData 與 NTUSER.DAT

本文以管理 Windows 的資訊系統人員、終端裝置佈署負責人、Windows 應用程式開發者為對象，整理成一般性的說明。 圖為概念圖。在支援 Mermaid 的 Markdown 環境中會顯示為圖表。

內容以 2026 年 4 月時點可確認的 Microsoft 官方資訊為前提。[1][4][7][10][13][14]

在 Windows 相關的諮詢中，「設定檔」這個詞的使用範圍相當廣。

• 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]
• 漫遊設定檔 是「把整個設定檔集中到共用位置」的機制，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，登入時會載入這個 hive 並作為 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

設定檔損壞的討論之所以複雜，是因為既有 只有資料夾端損壞的情況，也有 登錄檔（hive）端出問題的情況。[1][11]

2.2 第一次登入時以 Default 為基礎

當新使用者第一次登入該台 PC 時，Windows 會 以 C:\Users\Default 為基礎建立本機設定檔。[11]

flowchart LR
    A[C:\Users\Default] --> B[第一次登入]
    B --> C[產生 C:\Users\使用者名稱]
    C --> D[載入 NTUSER.DAT]
    D --> E[成為該使用者專用的環境]

在映像部署或初始配置（kitting）的情境下，如果隨便處理這一塊，之後會相當麻煩。

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 分成三種來思考

在 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[該 PC 專屬的狀態]

    D --> D1[特殊用途]

實務上這樣區分使用

在 Microsoft 的已知資料夾定義中，ProgramData 也被定位為 給所有使用者用的應用程式資料，適合不會漫遊的共用資料。[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 設定檔容器

在 Microsoft Learn 中，FSLogix 被說明為 讓 Windows 使用者設定檔體驗，在虛擬桌面環境中保持一致的機制。[13]

FSLogix 設定檔容器是一種 把整個使用者設定檔以 VHD / VHDX 的形式保存，登入時再將其掛接（attach），讓它看起來就像原生設定檔 的方式。[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{是該 PC 專屬的嗎}
    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% 的內容

放在這裡的大致是這類東西。

• 較小的設定
• 每位使用者的偏好設定
• 想在多台裝置上維持相同外觀的狀態
• 可以跟著設定檔一起帶走的東西

在 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 先把症狀分成三種

flowchart TD
    A[疑似設定檔問題] --> B{能不能登入}
    B -->|Yes| C{畫面看起來被初始化了嗎}
    B -->|No| D[載入失敗類]
    C -->|Yes| E[Temporary / 損壞 / 其他設定檔]
    C -->|No| F{只有一部分設定被還原嗎}
    F -->|Yes| G[漫遊 / 重新導向 / 同步類]
    F -->|No| H[可能是應用程式個別問題]

大致可以分成以下三個系統。

1. 登入時失敗
2. 能登入，但看起來像被初始化了
3. 只有一部分沒有同步

7.2 首先該看的記錄

Microsoft Learn 建議在調查設定檔問題時，依以下順序查看。[10]

1. Application 記錄
2. User Profile Service 的 Operational 記錄
3. 需要時再看 Diagnostic 記錄
4. 若還需要，再看 ETL 追蹤

具體路徑如下。[10]

• 事件檢視器 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／教育用裝置／資訊站

在這種用途下，比起「保留個人化設定」，每次都恢復乾淨的狀態 更重要。

可考慮的方式有以下三種。

• 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 系列產品
• 在非持久性（non-persistent）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 就好」

那樣很危險。如果把設定和巨大快取放進同一個容器，登入／登出或發生故障時的處理都會變得很沉重。 把 想漫遊的東西 和 應該侷限在 Local 的東西 分開，維運起來會比較容易。[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 的使用者登錄檔的組合。新使用者第一次登入該台電腦時，會以 C:\Users\Default 為基礎建立新的設定檔。設定要延續到什麼程度，則取決於本機、漫遊、Folder Redirection、FSLogix 等方式的選擇。

%APPDATA% 和 %LOCALAPPDATA% 該怎麼區分使用？

基本原則是：想讓每位使用者隨身帶著走的設定放在 %APPDATA%（AppData\Roaming），該台電腦專用的快取或暫時性狀態放在 %LOCALAPPDATA%（AppData\Local）。可重新產生的快取或較大的工作檔案如果放進漫遊範圍，容易讓登入、登出變慢，所以應該歸到 Local 這一側。所有使用者共用的可變資料可以考慮放在 ProgramData，但必須連同「誰能讀、誰能寫」的 ACL 設計一起規劃。應避免把使用者個別的執行期資料放在 Program Files。

以臨時設定檔（Temporary profile）登入時該怎麼處理？

Temporary 設定檔是在發生錯誤、無法載入原本設定檔時所發出的緊急替代方案，登出時會被刪除，變更內容也會遺失。若照常繼續作業，重要資料有可能消失，因此應該避免停留在這個狀態。調查時不要一開始就直接動 C:\Users，應先確認 Application 記錄和 User Profile Service 的 Operational 記錄，必要時再看 Diagnostic 記錄。常見原因包括 NTUSER.DAT / USRCLASS.DAT 的屬性或權限問題、漫遊目的地路徑過長的問題，以及因刪除不完整而殘留的登錄檔資訊等。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。