部署向导说"成功"了，但 Broker 说这个部署根本不存在——一次 RDS 农场重建记

公司决定把 RDS（远程桌面服务）整体升级到 Windows Server 2025，新建一套完整的农场——新的连接代理、新的 RD Web Access、新的会话主机，替换掉服役多年的旧 RDS 环境。按微软标准流程走 Server Manager 里的”Add Roles and Features”向导：选 Remote Desktop Services 部署、标准部署、会话型部署，依次勾选连接代理、Web Access、会话主机三个角色，Deploy。

进度条走完，界面提示需要重启服务器完成安装。重启回来之后，一切都不对了。

“部署成功”之后，部署本身不存在了

Server Manager 里的 Remote Desktop Services 概览页直接给出一句冷冰冰的提示：“A Remote Desktop Services deployment does not exist in the server pool.” 用 PowerShell 确认：

Get-RDSessionCollection -ConnectionBroker RDS-BROKER.corp.local

返回的是一堆红字：

A Remote Desktop Services deployment does not exist on RDS-BROKER.corp.local. This operation can be performed after creating a deployment…

向导明明报告三个角色服务全部安装成功，重启一次之后，系统却矢口否认自己有过这次部署。 服务器管理器的任务详情里能看到线索：一条”Automatic Refresh”任务标着失败，附带一条更具体的错误——

The WS-Management service cannot process the request. The computed response packet size (516467) exceeds the maximum envelope size that is allowed (512000).

根因：一个太小的默认值,新服务器没人调过

WinRM（Windows 远程管理）对单次响应报文的大小有一个上限，默认是 500KB（512000 字节）。 全新安装的 Windows Server 2025 上,这个值还是出厂默认;而 RDS 部署这类涉及多角色、多服务器协同的配置操作,在两台服务器之间交换的状态信息量,恰好在某些时刻刚好超过了这个默认上限（本例中是 516467 字节,超出不到 1%）。请求一旦超限就被直接拒收,Server Manager 的”刷新”操作因此持续失败——这不是部署真的丢了,是负责汇报部署状态的通信管道被自己的默认配置掐断了。

修复只需要在两台服务器上把这个上限调大：

Set-Item WSMan:\localhost\MaxEnvelopeSizekb 8192
Restart-Service WinRM

向导留下的空白,靠命令行手工补上

放大上限之后,Server Manager 里依然显示”部署不存在”——图形界面的状态从来没有正确写入过,得手工用 PowerShell 重新声明这次部署：

Import-Module RemoteDesktop
New-RDSessionDeployment `
  -ConnectionBroker "RDS-BROKER.corp.local" `
  -WebAccessServer "RDS-BROKER.corp.local" `
  -SessionHost "RDS-HOST1.corp.local"

执行后重新打开 Server Manager，部署终于以正确状态呈现——连接代理、Web Access、会话主机三个角色服务都能被正常查询和管理，后续创建会话集合、添加第二台会话主机、配置证书，一路顺畅。

WinRM 的默认 500KB 报文上限，在全新的多角色 RDS 部署里被状态同步请求撞破——Server Manager 的刷新任务持续失败，图形界面从未真正写入过部署状态，只能靠 PowerShell 手工声明一次部署

向导报告的”成功”，只是它自己没有检测到失败；真正的状态从未同步过

顺手记下的第二个坑：农场里不能直连计算机名

农场搭好之后，IT 想直接远程进某台会话主机做维护，mstsc 敲了主机名连接，弹出的却是：

The remote computer rds-host2 that you are trying to connect to is redirecting you to another remote computer named RDS-HOST1.corp.local. Remote Desktop Connection cannot verify that the computers belong to the same RD Session Host server farm. You must use the farm name, not the computer name…

这是 RD 连接代理的会话重定向机制在起作用：普通的 RDP 连接请求会被代理按负载均衡策略重定向到集合里的某台主机，客户端看到目标从”我请求连的机器”变成”另一台机器”，出于安全考虑直接拒绝了这次跳转。错误信息里其实已经给出了答案——加上 /admin 参数，绕开集合的负载均衡逻辑，直接管理这台指定的机器：

mstsc /admin /v:RDS-HOST2.corp.local

教训

全新安装的服务器上，WinRM 的默认限制不一定适配即将要做的操作——多角色、多服务器协同的部署（RDS、集群、复杂的 GPO 同步）在服务器间交换的状态信息量可能超出 WinRM 报文大小的出厂默认值，遇到”操作莫名其妙失败但没有直接报错”时，值得检查 WinRM 的事件和限制配置；
部署向导的”成功”提示不等于状态被正确持久化——图形界面的刷新逻辑依赖底层通信正常，通信层出问题时，向导可能已经完成了它认为该做的动作，但后续查询看到的是一个空的部署，这时候不要怀疑操作本身，去查真正负责传输状态的服务；
修不好图形界面时，PowerShell 模块通常保留着手工声明状态的入口——New-RDSessionDeployment 这类 cmdlet 是向导背后调用的同一套 API，图形界面卡住时可以绕过去直接调用；
RDS 农场里，管理员直连某台会话主机要用 /admin 参数——不加这个参数，RDP 客户端会遵循集合的负载均衡重定向逻辑，把你带到别的机器上去，这是设计使然，不是故障。