RDS 会话主机为何给用户挂上临时配置文件？一次 User Profile Disk 与磁盘配额的排查记录

Sun, 27 Sep 2026 09:00:00 +0800

问题背景

公司研发与客服部门约 200 人日常通过 RDS 远程桌面农场办公，农场由 3 台 Windows Server 2022 会话主机组成，用户配置文件统一走 User Profile Disk（UPD，即 UVHD 虚拟磁盘），存放在一台专用文件服务器的共享目录上。这套架构运行了两年多，此前只出过零星的配置文件小毛病，重启会话主机都能解决。

9 月 26 日上午开始，服务台陆续接到同一类投诉：用户登录远程桌面后桌面图标全没了，Outlook 需要重新配置，浏览器收藏夹清空，任务栏提示"已使用临时配置文件登录"。投诉从早上 9 点的 3 个，到中午涨到 27 个，且分布在三台会话主机上，不是集中在某一台——这个分布特征说明问题大概率不在单机，而在共享的配置文件存储层。

故障现象

登上一台会话主机复现检查，故障表现集中且一致：

事件日志里出现 Event ID 1511：Windows 找不到服务器本地配置文件的副本，因此使用临时配置文件登录；伴随 Event ID 1515，Windows 已将该用户放入临时配置文件的兼容模式。
出问题的用户目录下，C:\Users\<用户名> 变成了 C:\Users\TEMP，用户在会话里做的任何改动，注销后全部丢失。
文件服务器上对应的 UVHD 虚拟磁盘文件（<用户名>.vhdx）本身还在，大小和修改时间都正常，没有损坏迹象。
报障用户没有规律性——老用户新用户都有，同一用户有时重登一次就恢复正常，有时连续几次都是临时配置文件。
三台会话主机各自的本地磁盘空间都在 60% 左右，资源监控曲线平稳，看不出异常。

诡异之处在于：UVHD 文件完好、主机磁盘空间充足、故障随机分布在三台主机，单看任何一台机器都查不出必然原因。

排查过程

先从最可疑的文件服务器入手。登录文件服务器检查共享目录 D:\RDS-Profiles，NTFS 权限和共享权限两年来没人动过，最近一次变更记录还是 8 个月前的例行加固。但接着看磁盘配额时发现了第一条线索：D:\RDS-Profiles 启用了 NTFS 磁盘配额，硬上限是每用户 5GB——这个配额是按"每个 UVHD 文件不超过 5GB"的预期设的，当时 UVHD 平均大小只有 1.2GB。

用 dirquota quota list 逐项核对，发现配额统计的是共享目录下所有归属该用户的文件，而除了 <用户名>.vhdx 之外，部分用户目录下还堆积了 Outlook OST 缓存同步产生的临时文件和几次应用崩溃留下的 dump 文件。抽了几个报障用户的目录核对，他们的配额占用全部在 4.9GB～5GB 之间，距离硬上限只差毫厘。

第二条线索来自事件时序。在文件服务器的 System 日志里过滤 SMB 与存储事件，发现 9 月 26 日 8:52 有一个 SvhdMount 的失败记录，时间与第一批用户报障完全吻合。回头看磁盘曲线：D: 盘从 25 日晚间的 71% 一路涨到 26 日早上 8:50 的 96%——某个用户的 UPD 在当晚被 Outlook 的 OST 重同步写爆了，vhdx 从 2GB 膨胀到 4.8GB，把整盘可用空间压到了几百 MB。

第三步做交叉验证：UPD 是会话登录时动态挂载的 VHDX，挂载过程需要在卷上预留写空间并创建挂载点；当目标卷剩余空间低于阈值、或配额剩余量不足以支撑写操作时，挂载会静默失败，会话主机拿不到 UPD，只能按 Event 1511 的逻辑回退到本地临时配置文件。这解释了所有现象：UVHD 文件"看着完好"是因为膨胀发生在文件内部；故障随机分布是因为只有配额余量不足的那部分用户才触发；重登偶尔恢复是因为那几分钟内别的会话注销释放了写压力。

最后排除了另外两个常见嫌疑：域控侧的 ProfilePath 属性三台主机读取一致，GPO 的 UPD 排除项列表近 30 天无变更；会话主机的 RDSessionHost 注册表键与集合配置比对正常，排除了配置漂移。

解决方案

止血分三步，按影响面从小到大执行：

立即释放空间：在文件服务器上清理 OST 同步临时文件与 dump 文件约 11GB，将 D: 盘余量拉回 30% 以上；对配额占用超过 4.5GB 的 7 个用户，临时把硬上限调到 8GB。执行完这两步后让服务台通知报障用户重新登录，全部恢复正常配置文件。
结构性整改：把 UPD 共享目录迁移到独立卷 E:\RDS-Profiles，与其他业务数据物理隔离；NTFS 配额对 vhdx 文件单独设 10GB 软上限 + 阈值告警，不再让"目录里其他杂项文件"挤占 vhdx 的配额空间。
预防性监控：对 E: 盘加 80%/90% 两级空间告警；对配额占用超过 90% 的用户每日出报表，提前通知用户清理或由管理员扩容；在会话主机上对 Event ID 1511/1515 配置告警规则，出现 3 次以上即触发服务台工单，而不是等用户投诉。

另外和研发部门约定了 OST 缓存策略：远程桌面会话内 Outlook 使用在线模式，本机 OST 同步只保留在物理办公机上，避免同类膨胀再次发生。

根因分析

直接根因是用户 UPD 虚拟磁盘当晚被 OST 重同步写爆，连带把整个配置文件卷的可用空间压到挂载阈值以下，后续用户的 UPD 挂载静默失败，RDS 回退到临时配置文件。

深层根因有三个：

配额设计错位：配额对象是"用户在目录下的全部文件"而非 vhdx 本身，且从未给配额占用本身设监控——以为防住了单用户膨胀，实际没防住。
共享卷未隔离：配置文件存储与临时文件、dump 等杂项同卷，任何一个用户的异常膨胀都会外溢成全局故障。
监控盲区：会话主机的磁盘告警只盯着本机，作为单点的文件服务器反而只有容量告警、没有挂载失败告警，故障要等用户投诉才被发现。

预防措施

UPD 存储独立成卷、独立配额策略，配额对象精确到 vhdx 文件本身；
文件服务器对 Event 1511/1515、SvhdMount 失败配置主动告警，容量告警阈值下调到 80%；
每日配额占用报表推送运维群，90% 以上用户次日必处理；
把"UPD 挂载失败回退临时配置文件"写进 RDS 故障手册首条，服务台遇到同类投诉直接按手册第 2 节核对文件服务器，不再逐台查会话主机。

总结

这次故障的表象是"用户配置文件坏了"，实际是"共享存储的配额与空间管理失守"。RDS 这类中心化桌面架构里，单台会话主机的健康度好查，共享层——文件服务器、配额、挂载链路——才是真正的单点；监控和告警如果只覆盖了看得见的机器，看不见的那一层就会用最安静的方式出问题。故障当天从第一单投诉到全量恢复用了 3 小时，其中 2 小时花在"逐台查会话主机"的错误方向上；把共享层检查写进手册之后，这类问题的定位路径应该缩短到 10 分钟以内。

磁盘配额 on Zero Day Notes