企业官网建设流程全解析

干 Windows Server 2016 运维的，基本都撞见过这个弹窗：你登录一台装了远程桌面服务（Remote Desktop Services，简称 RDS）角色的服务器，想打开本地用户和组，或者给某个账号加个 Remote Desktop Users 组成员，屏幕正中突然蹦出一句“The task you are trying to do can't be completed because Remote Desktop Service is currently busy”，下面还跟一句“Please try again after a few minutes”。第一次遇到，多数人会老老实实等几分钟再试，结果半小时过去，该报错还报错，一点面子不给。这篇文章不绕弯子，直接讲这个报错是在哪一步触发的、TermService 在后台到底经历了什么，以及按什么顺序处理最省时间。如果你正好被这个问题卡住，照着后面几个步骤往下走就行。

1. 先搞清楚：这个报错究竟在哪一步出现

1.1 典型故障现场

这问题最容易出现在“远程桌面会话主机”上，也就是你把服务器装成了 RD Session Host，一堆用户通过远程桌面登录上来干活。管理员本身也远程在这台机器上操作，打开“本地用户和组”（lusrmgr.msc），准备改一个用户的密码、看他的属性，或者干脆新建一个用户。点开用户属性的一瞬间，对话框就弹出来了，提示 Remote Desktop Service 正忙。

关键点在于：弹窗出现后，你点“确定”也好，点右上角关闭也好，那个操作就是做不下去。有时候你换个用户再试，或者换一台机器远程连上来操作，同一个动作还是被拦住，说明问题出在服务器自身的服务状态上，不是单纯某一次鼠标操作碰巧触发。

1.2 最容易踩中的三种操作

我在这几年处理类似工单的过程中，发现触发场景相对集中。以下三类操作最容易把这个弹窗逼出来：

实际案例里，第一种占比最高。很多管理员平时不装 RDS 角色，很少见到这个弹窗；一旦在 RDS 会话主机上做用户管理，几乎躲不掉。

1.3 受影响的范围有多大

有一点要说明：这个弹窗只影响“管理操作”，不影响普通用户远程登录。换句话说，用户该连连、该用用，但你作为管理员想通过 GUI 改点东西，就是被挡住。这种情况下，最稳妥的做法是别跟弹窗较劲，先用后面的命令行方案把活儿干完，再抽空处理服务本身的问题。

如果弹窗伴随“所有新远程桌面连接都连不上、老会话也卡死”，那就不是单纯管理操作被拦，而是 TermService 已经接近整体瘫痪，处理优先级要立刻提高。

2. 报错背后的机制：Remote Desktop Service 到底在忙什么

2.1 一次 MMC 管理单元的调用链

要理解这个报错，先要明白“本地用户和组”这个管理单元在 RDS 会话主机上不是单纯读 SAM 数据库那么简单。它要展示的用户信息里，有一部分来自终端服务层，比如会话状态、用户是否在线、组策略层面的会话配置。MMC 想拿到这些信息，会通过 WMI（Win32_UserAccount、Win32_LoggedOnUser 等）和 RPC 向 TermService 发请求。

打个比方：你打电话给对方公司前台，说要找某个部门的人办个手续。正常情况前台接起来转接就好；但对方前台自己正卡在一通长电话里，你的请求就一直排队。等太久没回复，MMC 只能放弃，并弹一个“对方正忙，请稍后再试”的提示。TermService 并不是真的在三秒后就能缓过来，而是你这次请求已经超时了。

2.2 四类常见的根本原因

第一类，TermService 服务本身状态不对。最常见的是启动类型被改成“手动”或“禁用”，或者进程停在“启动中”“停止中”半吊子状态。很多人没意识到，装了 RDS 角色以后，TermService 是核心，不是像 Print Spooler 那种可以随便关的组件。

第二类，RDS 授权模式没配置或处于“宽限期”异常状态。Windows Server 2016 安装 RDS 角色后，会给你一个大约 120 天的临时授权期。如果宽限期过了还没配好授权服务器，或者授权模式（按设备/按用户）和实际使用情况对不上，TermService 整体状态就会变得不太稳定，管理操作报忙是典型表现之一。

第三类，残留的断开会话太多。RDP 断线重连过程中，会留下不少“已断开”状态的会话。这些会话本身不一定会立刻把服务拖垮，但当它们积累了足够多，TermService 在枚举会话、刷新状态时会非常吃力，WMI 调用超时，于是弹窗就来了。

第四类，系统补丁安装后没重启，或者某些第三方管理工具改了终端服务相关的注册表/服务依赖。Windows 更新对 TermService 相关 DLL 做了替换，但服务器一直没重启，新文件和旧服务进程共存，管理操作就时好时坏。

2.3 为什么“等几分钟”通常是在浪费时间

报错文案里写“Please try again after a few minutes”，这句话特别有迷惑性。它本意是“服务繁忙，稍后重试”，但实际情况多半不是繁忙，而是挂起。一个正常的忙碌服务，过几分钟确实能缓过来；一个已经挂死或者依赖链断掉的服务，等多久都不会自己恢复。我见过不少同事真的每隔五分钟点一次，点了十几次，最后放弃治疗，重启服务器解决。

记住一条判断原则：如果弹窗是偶尔出现，比如上午一次下午一次，那可能是瞬时并发高；如果弹窗从某个时间点开始持续出现、每次必现，那就是服务进入了非正常状态，别再傻等。

3. 实操解决：从无风险操作到重启的完整路线

3.1 第一步：确认并重启 Remote Desktop Services 服务

打开管理员身份的 CMD，先看服务和启动类型：

sc query TermService sc qc TermService

正常情况 STATE 应该是 RUNNING，START_TYPE 应该是 AUTO_START。如果 START_TYPE 不是 AUTO_START，先用下面命令改回来：

sc config TermService start= auto

注意start=后面必须跟一个空格，这是 sc 命令的老毛病。然后重启服务：

net stop TermService net start TermService

或者用 PowerShell：

Restart-Service TermService -Force

执行完别急着去点 lusrmgr，先等十几秒让服务完全起来，再试一次管理操作。

注意：如果net stop TermService卡住超过一两分钟，说明服务内部有线程挂死，反复停根本没用，直接跳到第五步安排重启服务器。

3.2 第二步：清理残留的 RDP 会话

服务重启完，弹窗还在，优先考虑是不是残留会话太多。先用 qwinsta 看看当前会话：

qwinsta

输出里能看到会话名、用户名、会话 ID、状态。状态为“已断开”（Disc）且用户名不是 Active 的会话，都是可以清掉的。用 logoff 命令注销指定会话：

logoff 会话ID

比如会话 ID 是 5，就执行logoff 5。如果某个会话彻底卡死，连 logoff 都赶不动，可以用：

reset session 5

这会强制重置会话连接。

操作前一定确认会话对应的用户没有未保存的工作。生产环境清理会话，建议先通知用户，不要看哪条不顺眼就踢谁。最稳妥的做法是只清理“已断开”状态、且该用户名已经不在线的会话。

清完之后再试管理操作。这个方法性价比极高，很多时候弹窗就这么消失了。

3.3 第三步：检查并配置 RDS 授权

如果会话干净了还报错，就要看授权。打开 Server Manager，依次进入“工具 → 远程桌面服务 → Remote Desktop Licensing Manager”。在许可证管理界面里，看服务器的状态。如果显示“Notification period”或者“未激活”，说明 RDS 还处于临时授权期或者授权服务器没配置好。

有一种常见误区：以为只有用户连不上桌面时才需要查授权。实际上授权状态不对，TermService 的管理接口一样会受影响。配置授权时，要到本地组策略或域策略里，把“远程桌面授权模式”指定正确。策略位置是：

计算机配置 → 管理模板 → Windows 组件 → 远程桌面服务 → 远程桌面会话主机 → 授权

里面有两个关键策略：

微软默认的 120 天宽限期，很多人不知道，等到超了才发现用户登不上，才想起来配授权。这里提醒一句：配授权要保证授权服务器本身工作正常，如果之前随便装过个激活失败的授权角色，建议先清理干净再重新配置。

3.4 第四步：用命令行绕开 GUI 先把活干完

业务不等人，弹窗还在时，最简单粗暴的办法就是不用 GUI。你想做的操作，绝大多数都能用命令行完成。

给用户加远程桌面权限：

net localgroup "Remote Desktop Users" 机器名\用户名 /add

如果这台机器在域环境，把机器名换成域名即可。PowerShell 版本更直观：

Add-LocalGroupMember -Group "Remote Desktop Users" -Member "CONTOSO\zhangsan" Get-LocalGroupMember "Remote Desktop Users"

改用户密码：

net user 用户名 *

按提示输入两遍新密码。看用户状态、是否锁定：

Get-LocalUser | Select-Object Name, Enabled, PasswordRequired, LastLogon

新建本地用户并设密码：

net user 用户名 密码 /add

这些命令和 GUI 操作最终修改的是同一个底层数据库，效果完全一致。命令行能用，说明底层的 SAM 读写没问题，问题确实集中在 TermService 的管理接口上，心里更有底了。

3.5 第五步：检查事件日志与重启收尾

命令行把业务续上了，接下来该认真收尾。打开事件查看器，定位到：

应用程序和服务日志 → Microsoft → Windows → TerminalServices-LocalSessionManager → Operational

另外还有 RemoteDesktopServices-RdpCoreTS 对应的日志。先看最近一两个小时有没有大量 Error/Warning，尤其关注 TermService 启动失败、会话枚举超时这类记录。不看具体事件 ID 也行，先看时间密集度：如果几分钟一条报错，基本坐实服务长期不健康。

查到这一步如果还是没头绪，检查一下系统是否有“待重启”标记。很多时候补丁装完不重启，服务用着用着就开始抽风。PowerShell 下执行：

Test-Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations'

返回 True 说明有文件改名操作在等重启，直接安排重启。如果服务器能重启，到这一步没有犹豫的必要，把维护窗口打开，重启后测试 lusrmgr，大概率直接恢复。

经验之谈：能重启的机器，重启永远是效率最高的解药。卡在“先查日志再查授权”的死循环里，不如先重启，让所有挂起的调用归零，再观察问题是否复现。

4. 高频问题速查与独家避坑心得

4.1 问题与对策速查表

这里有个容易忽略的点：TermService 的服务依赖关系很直接，它依赖的远程过程调用模块如果出问题，表现就是所有终端服务管理接口集体超时。这种情况下，日志里可能根本看不到 TermService 自己的报错，而是大量底层 RPC 超时记录。所以排查时别只盯着 TermService 一个词，看到 RPC、WMI 相关的报错同样要重视。

4.2 事件日志的正确过滤方式

我喜欢把日志排查分成两步走，这样效率最高。第一步看最近时间窗有多少条错误，第二步按来源过滤。来源重点看这几个：

事件 ID 不用死记，我平时都是“按来源 + 按时间”过滤，然后看错误级别的内容描述。排查经验多了你会明白，事件 ID 只是索引，描述才是关键。

4.3 关于 120 天授权宽限期，我想多说两句

很多人第一次接触 RDS 角色，根本不知道宽限期这回事。装完 RDS 角色，系统会发临时许可证，允许你合法地用一段时间，大概 120 天。这段时间里日常管理、用户连接都正常，于是有人就忘了配置授权服务器。

等宽限期过了，首先崩的是新用户远程登录，老用户有时还能续上。管理端会不会弹“Remote Desktop Service is currently busy”这个提示？不完全一定，但在授权状态异常时，TermService 的整体稳定性会下降，管理接口偶尔抽风很正常。

所以我的建议很明确：装完 RDS 角色，第一件正经事就是把授权模式和授权服务器定下来。按用户还是按设备，要根据公司账号数和设备数来算。账号多、设备也多，但每个人只在固定设备上登录，按设备更划算；人员流动大、设备不固定，按用户更省心。拿不准就问一下预算和人员规模，不要在服务器上自己猜。

4.4 为什么我劝你别乱跑“优化脚本”

很多“服务器优化工具”或“安全加固脚本”会把一些非核心服务改成手动甚至禁用，美其名曰“释放资源”。损失是显而易见的：TermService、RDP-Tcp、Remote Procedure Call 这类服务一旦被改动，轻则管理界面报忙，重则远程桌面直接没法用。

我处理过一起奇怪的案例：某台服务器上 TermService 的启动类型显示是自动，但服务实际没跑起来，手动启动还报依赖错误。最后查出来是优化脚本把“Remote Desktop Services UserMode Port Redirector”这个依赖项处理出问题了。这种间接依赖问题在界面上很难一眼看出，得用sc queryex TermService看依赖链。

所以这里给个硬建议：生产服务器上不要跑来路不明的优化脚本。真要做资源优化，用 Server Manager 自带功能，或者老老实实把 SQL Server、IIS、文件服务这类业务角色规划清楚，别拿终端服务开刀。

5. 最后分享一个真实处理经历

之前有次帮某客户的 2016 会话主机排查这个报错，客户说“每天总有那么几次点不开用户属性，过会又好了”。我上去看了一下，TermService 状态正常，授权也在宽限期内，就是会话列表密密麻麻排了几百条。特别扎眼的是大量“Disc”状态的老会话，有些甚至是几周前留下的。

我先按上面的流程把断开会话清掉，再把授权模式对齐到“按用户”，观察了一周，弹窗再没出现过。后来客户反馈，之前一直没人敢清会话，怕踢掉用户未保存的工作，结果一个个堆积下来，终于把 TermService 的管理接口拖垮了。

这个案例给我最大的教训就是：清理会话属于日常运维，不是事故处理。只要提前通知到位，在维护窗口清理断开会话，成本极低。别心疼那点操作，服务器卡到弹窗的时候，浪费的时间才是真的心疼。

再补充一点个人心得：遇到这个报错，顺序千万别乱。先服务重启，再会话清理，再授权检查，最后才考虑系统重启。一盘菜刚端上来就掀桌（直接重启），有时候会掩盖真正的根因，下次照样复发。按顺序走一遍，多数问题都能定位到具体环节，就算最终还是要重启，你也知道重启之后该防什么了。