Windows Server 远程桌面开多用户RDPWrap 配置全流程与踩坑记录【免费下载链接】rdpwrap.iniRDPWrap.ini for RDP Wrapper Library by StasM项目地址: https://gitcode.com/GitHub_Trending/rd/rdpwrap.ini凌晨两点第三台 Windows Server 的远程桌面又连不进去了前两个管理员的会话还挂着新窗口弹回连接数已达上限。RDPWrap 本来能解除这种单会话限制、让多用户并发接入但这台机器上组策略把 MaxUserSessions 刷新回了 1补丁的强制值根本没接管。后来排查下来问题出在配置文件没跟上系统的 build 号——这套工具能否生效全靠本仓库里这一份份按版本对齐的 rdpwrap.ini 文件。 为什么是 RDPWrap 而不是原生终端服务策略先说原生终端服务方案卡在哪。想在 Windows Server 上正规地开多用户远程桌面得把 Terminal Services 那一整套配齐RDSH 角色、CAL 许可服务器、对应数量的客户端访问许可。许可少一张termsrv 就会把会话踢掉——策略写对了门还是关的。我们只是想让两三个运维同时在线不想为这个买单原生路线在许可这一层就走不下去了而组策略里那几项开关改完还会被定时刷新的策略打回原形。RDPWrap 补的是另一层拼图termsrv.dll 内部那个写死的判断。它通过 hook SLInit 相关调用把 bServerSku、lMaxUserSessions 这些内存里的值强制成服务器 SKU、会话数不限的状态整个过程不落盘、不改注册表重启后服务再应用一遍。所以原生策略被刷回什么对最终结果影响很小。与此同时它接管了策略读取这一层[SLPolicy] 段就是工具回读策略时使用的替身值。部署后核对这几行是否就位TerminalServices-RemoteConnectionManager-AllowMultipleSessions1 TerminalServices-RemoteConnectionManager-MaxUserSessions0 TerminalServices-RemoteConnectionManager-AllowAppServerMode1这也是为什么注册表里看着是 1、实际却能进多个会话——真正被读走的不是那个值。 RDPWrap 配置文件怎么选按系统版本来三个主流 Server 版本各有一条线核对要点不一样。选文件的唯一依据是 systeminfo 里的 build 号第四位也要逐位对。Windows Server 201610.0.14393配置在主文件里先说个容易忽略的事实autogenerated/ 目录里没有 14393 开头的文件。2016 这条线直接用顶层的 rdpwrap.ini先找到 build 号对应的 [10.0.14393.xxx] 段。以 .5582 为例需要核对的是[10.0.14393.5582] SingleUserOffset.x6425FA4 SingleUserCode.x64Zero DefPolicyCode.x64CDefPolicy_Query_eax_rcx这个版本同一段里 x86 和 x64 的偏移是两套x86 的 SingleUserOffset 是 3A1E5拿配置时先把架构后缀确认对——拿错架构比拿错版本更隐蔽因为段标题看起来是对的。Windows Server 201910.0.177632019 是在用机器里最多的版本配置取 autogenerated/ 下对应文件例如 10.0.17763.5830-autogenerated_x64.ini。核心核对三行[10.0.17763.5830] SingleUserOffset.x6416F41 DefPolicyOffset.x6420435 DefPolicyCode.x64CDefPolicy_Query_eax_rcx原因很直接偏移量随每次累积更新漂移.5830 的文件不能硬套在 .7919 的系统上build 第四位差一位就该换另一份文件。Windows Server 202210.0.20348RDPWrap 补丁段核对2022 线例如取 10.0.20348.1311-autogenerated_x64.ini[10.0.20348.1311] SingleUserOffset.x6408982 DefPolicyOffset.x641BA65 DefPolicyCode.x64CDefPolicy_Query_eax_rcx这个版本比 2019 多一层要求文件尾部还挂着一张 [10.0.20348.1311-SLInit] 偏移表bInitialized.x64 等因为 2022 改了 SLInit 结构体的地址布局。只核对主段、漏掉这张表补丁会静默不生效而且安装状态照样显示正常。完整文件列表见 autogenerated/主配置文件是同级的 rdpwrap.ini。✅ RDPWrap 部署检查单五步走完把上面几节的结论压成一条操作线每次新机器照着走一遍确认版本与架构管理员终端跑systeminfo | findstr /B OS Name OS Version预期看到 Windows Server 2022 Standard 和 10.0.20348.1311 这样的两行它们决定第 2 步选哪个文件。放入配置文件把对应 .ini 拷到 RDPWrap 安装目录并命名为 rdpwrap.ini预期文件里的段标题与第 1 步的 build 号逐位一致2022 的还要带 SLInit 偏移表。安装并启动服务执行RDPWrap.exe /install再RDPWrap.exe /start预期 services.msc 里 RDPWrap 状态为 Running并在生成日志文件 \rdpwrap.txt。放行防火墙执行netsh advfirewall firewall set rule groupremote desktop new enableYes预期 3389 入站放行。NLA 保持客户端与服务端两端一致一边开一边关会在握手阶段直接失败。双会话验收两个不同账号同时发起远程桌面预期第二个会话进入时第一个不被挤掉。这一步过了才算真正部署完成。 上线后最容易翻车的三件事跑起来不等于跑得住下面三个现场都真实发生过。组策略刷新后 MaxUserSessions 又被改回 1周一早上第二路会话突然进不来注册表里 MaxUserSessions 又变回 1。先别急着再改策略真正决定会话数的是 SLInit hook 强制的结构体值策略里的 1 只是表象——出现这个症状大概率是 RDPWrap 服务没在跑打完更新之后尤其常见。查 services.msc 和 \rdpwrap.txt 最近几行RDPWrap.exe /stop加/start重启服务再用第 5 步的双会话验收一次。防再犯把服务状态检查加进每日巡检别拿策略值当健康指标。autogenerated 配置和系统 build 号差了一位某台机器打了月度更新后RDPWrap 安装状态还是成功但新会话就是连不上日志里能看到补丁没命中的记录。拿 systeminfo 的 build 号去对配置文件的段标题会发现系统已经是 10.0.20348.1340文件还停在 10.0.20348.1311。修复方式是整体替换换一份最新的完整 rdpwrap.ini 或对应的 autogenerated 文件而不是手工把单个 [10.0.x] 段拷进旧文件——较新的 build 依赖 [PatchCodes] 表里的新条目段标题对了、补丁码没跟上照样失败Readme.md 顶部就专门警告过这一点。防再犯每次打累积更新前先确认新 build 已有对应配置再安排安装。服务 Running 但 3389 还是不通服务状态是绿的远程桌面却超时这类问题基本不在补丁层。先在本机netstat -an | findstr 3389确认端口在监听再查防火墙跑一遍检查单第 4 步那条 netsh 命令。如果两端 NLA 配置不一致客户端强制 NLA 而服务端证书或版本不支持连接会在建立阶段直接失败把两边 NLA 设置对齐即可。防再犯每台新机器上线都完整走一遍检查单第 4、5 步别假设别的机器配过、这台也一样。这个仓库大约每月更新一次新 build 支持节奏可以看 Readme.md 里的 History。建议把 autogenerated/ 目录加进例行巡检清单每次系统更新后第一件事就是核对 build 号有没有对应的配置。【免费下载链接】rdpwrap.iniRDPWrap.ini for RDP Wrapper Library by StasM项目地址: https://gitcode.com/GitHub_Trending/rd/rdpwrap.ini创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
