リモートデスクトップサーバーで一時プロファイルになるときは、Windows が本来のユーザープロファイルを読み込めず、代わりに TEMP プロファイルでサインインさせている状態です。まず重要なのは、TEMP のまま仕事を続けないことです。Event ID 1511 や We can't sign into your account が出ているなら、そのセッションで作った変更はサインアウト時に失われる可能性があります。
原因は1つではありません。ユーザープロファイル自体の破損だけでなく、NTUSER.DAT / USRCLASS.DAT の属性や権限、ProfileList の .bak や孤立エントリ、User Profile Disks（UPD）や FSLogix の共有ストレージの権限・容量・接続性まで見る必要があります。遠回りに見えても、最初にログと影響範囲を押さえるのが最短です。
リモートデスクトップサーバーで一時プロファイルになる意味
一時プロファイルは、「ログオンできているように見える失敗」です。C:\Users\TEMP や C:\Users\TEMP.<ドメイン> でセッションが開き、Outlook やアプリ設定が消えたように見えることがあります。本来のプロファイルが読み込めていないためで、サインアウトするとそのセッションでの変更は残りません。
RDS で UPD や FSLogix を使っている環境では、サインイン時に共有上の VHD/VHDX を接続できないと、同じ「一時プロファイル」症状に見えやすくなります。ユーザー単位の問題か、共有ストレージ側の問題かを分けて考えるのがポイントです。
一時プロファイルが出たときに最初にやること
TEMP の中の作業を先に退避する
すでに TEMP でログオンできているなら、最優先はファイル退避です。最後に正常ログオンできてから作成・更新したファイルを、共有フォルダーなど別の場所へコピーしてからサインアウトしてください。TEMP 側の変更は失われる前提で動いたほうが安全です。
Event Viewer は 2 か所見る
最初に見るのは Windows Logs > Application の Microsoft-Windows-User Profiles Service です。次に Applications and Services Logs > Microsoft > Windows > User Profile Service > Operational を開き、同じ時刻の詳細を追います。Application と Operational は既定で有効で、これで足りなければ Diagnostic ログも有効化できます。
見るべきイベントの考え方はシンプルです。Event ID 1511 は「本来のローカルプロファイルが見つからず TEMP でログオンした」状態、1500 や 1502 はプロファイル読み込み失敗の手掛かりです。一方、1530 はアプリがレジストリハンドルを開いたままにしたという警告で、設計上起こり得るため、それだけで主因と決め打ちしないほうが安全です。
切り分けは「誰に」「どのホストで」「いつから」
特定ユーザーだけなら、そのユーザーのプロファイル破損や ProfileList の .bak を先に疑います。新規ユーザーだけ失敗するなら C:\Users\Default 由来の NTUSER.DAT / USRCLASS.DAT の属性や ACL が有力です。複数ユーザーが複数ホストで同時に一時プロファイルになるなら、UPD / FSLogix の共有ストレージ、認証、更新の影響から見たほうが早く切り分けられます。
一時プロファイルになる主な原因
ユーザープロファイル自体が壊れている
RDP で Event ID 1511 が出る代表例の1つは、ユーザーのローカルプロファイルが壊れていて、さらに新しいローカルプロファイルも正常に作れないケースです。同じホストで別ユーザーは正常、問題ユーザーだけ毎回一時プロファイルになるなら、この線が濃くなります。新規のテストアカウントで正常ログオンできるかを見ると判断しやすいです。
NTUSER.DAT / USRCLASS.DAT の属性・権限・ロック
Microsoft は、NTUSER.DAT や USRCLASS.DAT が読み取り専用になっている、または必要な NTFS 権限が足りないと、プロファイル読み込みが失敗すると案内しています。新規プロファイルは C:\Users\Default から派生するため、新規ユーザーだけ失敗するなら C:\Users\Default\NTUSER.DAT を、既存ユーザーだけ失敗するならそのユーザー配下の NTUSER.DAT / USRCLASS.DAT を優先して確認するのが実務的です。
サインイン時に動くセキュリティソフトや周辺アプリの影響で症状が出ることもあります。再起動を数回試しても変わらない場合は、検証目的で一時的に無効化して再現性を確かめる、という切り分けは有効です。恒久対策は「無効化したまま運用」ではなく、例外設定や製品側の調整で戻す前提で進めます。
ProfileList の .bak や孤立した情報が残っている
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList に .bak が残っていたり、レジストリ上のプロファイル情報と C:\Users 側の実体が食い違っていたりすると、一時プロファイルの温床になります。Microsoft Learn でも、不完全または不適切にプロファイルを削除すると、追加のユーザーフォルダーが作られたり、ログオン時に TEMP プロファイルを受け取る可能性があると明記しています。
よくある失敗は、C ドライブ逼迫時に C:\Users\ユーザー名 フォルダーだけを手で消すことです。これをやると、ProfileList 側や関連 GUID 情報だけが残り、次回ログオンでさらに状態が悪化しやすくなります。.bak を触るときは、必ず ProfileImagePath で対象ユーザーを特定し、変更前にバックアップを取ってから進めてください。組み込みの S-1-5-18、-19、-20 は消してはいけません。
UPD / FSLogix の共有ストレージに問題がある
User Profile Disks は、コレクション単位の共有に保存されたユーザーごとの VHD をサインイン時に接続する仕組みです。つまり、RDS で一時プロファイルが複数ユーザーに同時発生するなら、まず共有パスの到達性とストレージ状態を疑うべきです。
FSLogix でも考え方はほぼ同じです。Microsoft は、FSLogix プロファイルコンテナーでは SMB 共有の権限が正しく構成されていることを前提にしており、さらにストレージの容量や性能が上限に達すると、ユーザーが新しいコンテナーを作れず、一時プロファイルやローカルプロファイルになることがあると案内しています。共有レベル権限と NTFS ACL、空き容量、I/O、名前解決までまとめて確認してください。
なお、FSLogix の AccessNetworkAsComputerObject=1 は例外的な設定です。Microsoft も、通常は使うべきではなく、コンピューターオブジェクトに権限を与える必要があり、VHD(x) へのアクセス範囲が広がるためセキュリティリスクになると注意喚起しています。権限問題の場当たり的な回避策として入れるのは避けたほうが安全です。
更新や再起動をきっかけに表面化することもある
一時プロファイルは「更新が壊した」と見えやすいのですが、実際には更新で権限チェックが厳密になり、もともとあった属性・ACL の問題が露呈することがあります。Microsoft も、Update 3021674 で NTUSER.DAT / USRCLASS.DAT へのアクセスチェックが追加され、読み取り専用属性や権限不足でプロファイル読み込みが失敗するケースを説明しています。
再起動起点の既知問題もあります。少なくとも Windows Server 2012 の RDS では、予期しない再起動後に Remote Desktop profile manager の不具合で一時プロファイルになるケースが修正対象として案内されていました。更新直後や障害復旧直後から急増したなら、ユーザー側だけでなくホスト側の既知問題や更新履歴も見たほうが早いです。
FSLogix を SMB 共有に置く環境では、認証要件の変化も要注意です。Microsoft は 2026 年 4 月の Windows Server 更新で、Kerberos の既定暗号が RC4 から AES-SHA1 に変わり、対応していない共有ではアクセス問題が起こり得ると案内しています。更新後に一時プロファイルが増えたら、FSLogix 側の権限設定だけでなく、共有の認証方式まで確認してください。
復旧を急ぐときの対処手順
変更前にバックアップを取る
.bak の削除や ProfileList の修正は有効なことがありますが、戻し手段なしでレジストリを触るのは危険です。VM スナップショットやレジストリバックアップを先に取り、復旧失敗時に戻せる状態を作ってから作業してください。
まず発生ホストを固定する
RDS ファームなら、まず「どの RD Session Host で起きるのか」を固定します。1 台だけで再発するなら、そのホストを新規接続から外して切り分けると被害を広げにくくなります。特定ユーザーだけならユーザー側、特定ホストに寄るならホスト側、複数ホストにまたがるなら共有ストレージ側、という見方が実務では有効です。
Event Viewer で原因の系統を絞る
Application と Operational を同時刻で確認し、1511、1500、1502、1542 が並ぶかを見ます。1530 だけなら後回しで構いません。ここで「読み込み失敗」なのか、「アプリがハンドルを開きっぱなし」なのかを分けるだけでも、無駄な再作成をかなり減らせます。
ProfileList の .bak と ProfileImagePath を確認する
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList で ProfileImagePath を確認し、対象ユーザーの SID に .bak が残っていないか見ます。対象ユーザーを特定しないまま一括削除しないでください。組み込み SID の S-1-5-18、-19、-20 は除外が基本です。
NTUSER.DAT / USRCLASS.DAT と C:\Users\Default を点検する
新規ユーザーだけ失敗するなら C:\Users\Default、既存ユーザーだけなら対象ユーザープロファイル配下を優先して、NTUSER.DAT / USRCLASS.DAT の読み取り専用属性と ACL を確認します。ここは「見落としやすいのに効果が大きい」確認ポイントです。特に更新後から発生した場合は、ここで引っかかることがあります。
UPD / FSLogix の共有をまとめて確認する
UPD / FSLogix 環境なら、共有レベル権限、NTFS ACL、空き容量、性能、名前解決、VHD/VHDX の接続成否を確認します。FSLogix ならエージェントのバージョンとサービス状態も合わせて見ます。複数ユーザーが一斉に一時プロファイルになるなら、個別ユーザーより先に共有側を見るべきです。
ホスト全体が怪しいなら DISM と SFC を実行する
ホスト全体で症状が出る、または更新後から不安定なら、DISM.exe /Online /Cleanup-image /Restorehealth のあとに sfc /scannow を実行します。sfc が実行できない場合は、セーフモードでの実行も選択肢です。RDS 本番機では業務影響を見て、メンテナンス時間帯で行うのが無難です。
直らないならプロファイルを作り直す
同じユーザーだけ再発するなら、プロファイルを作り直して必要な業務データだけ戻すほうが早いことがあります。新規アカウントや新規プロファイルで正常なら、元プロファイル破損の可能性が高いと判断できます。戻すのはドキュメントやデスクトップなど必要データを中心にし、壊れた設定ファイルまで丸ごと戻さないのがコツです。
やってはいけない対処
- 一時プロファイルのまま Outlook やアプリを再設定し続けること。設定変更が残らず、原因切り分けもしにくくなります。
C:\Users\ユーザー名を先に手で消すこと。レジストリや関連 GUID が残り、余計に直しにくくなります。- .bak を見つけたら何も考えず削除すること。
ProfileImagePathで対象を特定し、バックアップしてから触るのが基本です。 - Event ID 1530 だけを見て大規模な再構築に進むこと。1530 自体は設計上起こり得る警告です。
- FSLogix の権限問題を、その場しのぎで
AccessNetworkAsComputerObjectに逃がすこと。通常は非推奨で、セキュリティリスクが増えます。
再発を防ぐ運用ポイント
- 古いプロファイルを整理するときは、フォルダーだけでなくプロファイル情報全体を整合性のある形で削除します。Microsoft Learn には孤立プロファイルを検出・掃除するサンプルスクリプトもありますが、サンプルはサポート対象外なので、本番投入前に検証が必要です。
- User Profile Service の
ApplicationとOperationalを定期的に見て、1511 や 1500/1502/1542 の増加を監視します。1530 は「頻発しているアプリがないかを見る」程度にとどめるのが現実的です。 - FSLogix / UPD では、共有の権限と空き容量を運用監視に入れます。特に FSLogix はストレージ上限や性能不足で一時プロファイル化しやすいため、サーバー監視だけでは足りません。
- 更新は全ホスト一斉適用より、まず 1 台で適用・再起動・ログオン確認まで済ませてから広げるほうが安全です。更新や再起動を契機に既知問題や認証要件の変更が表面化することがあるためです。
迷ったときの優先順位
特定ユーザーだけなら、ProfileList の .bak と NTUSER.DAT / USRCLASS.DAT を先に見てください。新規ユーザーだけなら C:\Users\Default を優先します。複数ユーザーが同時に一時プロファイルになるなら、ユーザー単位の修復より先に、UPD / FSLogix の共有権限・容量・認証方式を確認したほうが復旧は早いです。
結論として、リモートデスクトップサーバーで一時プロファイルになる問題は、「ユーザー設定が消えた」のではなく「本来のプロファイルが読めていない」状態です。今すぐやるべき順番は、TEMP 側の作業退避 → Event Viewer 確認 → ProfileList と DAT ファイル確認 → 共有ストレージ確認 → 必要ならプロファイル再作成 です。この順番なら、無駄な再設定や誤削除をかなり減らせます。
コメント