# TermsrvPatcher: patching termsrv.dll for multiple RDP sessions > TermsrvPatcher is a single PowerShell script that rewrites termsrv.dll on a Windows 10 or 11 machine so several remote users can hold RDP sessions at once. It is small, MIT licensed and easy to read, but it patches a protected system file, offers no rollback and comes with a scheduled task that runs as SYSTEM. **fabianosrc/TermsrvPatcher** — Patch termsrv.dll so that multiple remote users can open an RDP session on a non-Windows Server computer - Repository: https://github.com/fabianosrc/TermsrvPatcher - Stars: 530 · Forks: 80 - Language: PowerShell - License: MIT - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/fabianosrc-termsrvpatcher ## The single restriction TermsrvPatcher removes TermsrvPatcher exists to work around one constraint in the client editions of Remote Desktop. A Windows 10 or 11 machine ships with a Remote Desktop service and a terminal server DLL, but it hands over a single interactive session: the first remote user connects and a second connection is refused. The repository description is blunt about the goal, patching termsrv.dll so that multiple remote users can open an RDP session on a non-Windows Server computer. The audience is therefore narrow and practical. An administrator who maintains a shared lab machine, a developer who reaches a home workstation from two places, or a support engineer who wants a second console on a personal PC all hit the same wall. The author also lists Windows Server 2016, 2019, 2022 and 2025 among the supported Terminal Services versions, which says the script is aimed at client SKUs first while still covering server builds. ## Five files, one script and no installer The repository is unusually small. The top level holds five entries: .gitignore, LICENSE, README.md, TermsrvPatcher.ps1 and TermsrvPatcherScheduledTask.xml. There is no installer, no module manifest, no package feed and no configuration file. The whole product is one PowerShell script, and the prerequisites ask for PowerShell 5.1 or higher with a link to download and install Windows PowerShell 5.1. That shape has a direct effect on how the project can be evaluated. There is no versioned release to pin, and the repository has no GitHub releases, so changes arrive as edits on the main branch rather than as tagged artefacts. The only formal grant is the MIT licence file sitting in the repository root, and the README adds no separate terms about redistribution. The scheduled task definition next to the script exists so the patch can be re-applied after an update, which is the subject of a later section. ## Running the patch the first time The first use is short because there is nothing to build. The usage section says to download TermsrvPatcher.ps1, place it in any folder, and run it from that folder: ```powershell .\TermsrvPatcher.ps1 ``` Expect the script to rewrite termsrv.dll, a protected system file, which is why it needs elevated rights. The README does not describe any output, log file, confirmation prompt or undo step, and it does not document rollback, so the original DLL has to come from somewhere else if the change ever needs to be reversed. The script itself is short enough to read before running, which is the practical advantage of a project with no build step and no hidden dependencies. Nothing else in the repository needs to be deployed for a manual run. ## Why a scheduled task is needed after each Windows update Because a servicing update replaces the patched binary, the patch does not survive on its own, and the README treats that as the reason for the second file. To run the script automatically after updates, import the task into Windows Task Scheduler: ```bash taskschd.msc ``` From there, select Action, then Import Task, and choose the TermsrvPatcherScheduledTask.xml definition shipped in the repository. The default path baked into the task is C:\TermsrvPatcher.ps1, and the README points to Actions, Edit, and the script path inside the Arguments input when the script lives elsewhere. The task then runs the script as the machine boots, which is when the DLL may have been replaced. One consequence is easy to miss: the definition fixes a single path, so a renamed or moved script quietly stops re-patching until an administrator edits the Arguments field by hand. ## The script file becomes the attack surface The security notice in the README is the most valuable paragraph in the project, and it should be read before anything is scheduled. The task runs as SYSTEM with HighestAvailable privileges and passes -ExecutionPolicy Bypass to PowerShell, because the task has to modify a protected system file without a UAC prompt at boot. The consequence the author spells out is that whoever controls the script file controls what runs as SYSTEM, which is why TermsrvPatcher.ps1 should live in a location writable only by administrators such as C:\ or C:\Program Files, and never in a user-writable folder such as Downloads or AppData. The author also says not to use the scheduled task on shared or multi-tenant systems where non-administrator users could replace the script. Anyone deploying this on a personal machine should weigh that warning against the fact that the same script will then run unattended at every boot. ## Where the supported version list stops Version coverage is broad and explicitly enumerated, which is unusual for a project of this size. The supported Terminal Services versions are Windows 7 Pro SP1 64-bit, Windows 10, Windows 11 22H2, 23H2, 24H2, 25H2 and 26H2, plus Windows Server 2016, 2019, 2022 including the Datacenter Azure Edition and HCI build 25398, and Windows Server 2025. The README header announces that Windows 11 26H2 support was added. Two gaps are worth noticing. The list covers 64-bit client systems and says nothing about Windows on Arm, and Windows 8 and 8.1 appear nowhere. Since the technique depends on the internal layout of termsrv.dll, a release outside that list is a case where the project documents no behaviour at all. ## The author points you at a different project The README says at the top and again at the end that a more complete solution called RDPControl is available and is the recommended replacement. The difference in approach is the real point. TermsrvPatcher is a single script that rewrites one system file and leaves everything else to the operating system. RDPControl is described as a full PowerShell module covering everything TermsrvPatcher did and more: multi-session configuration with a -DryRun preview, automatic snapshot and restore, a self-healing watchdog that survives Windows Updates, port management and firewall rules, user access control, session management, a full audit trail, and PowerShell Gallery readiness. TermsrvPatcher itself has no restore, no watchdog and no audit trail. If a patch and nothing else is what you want, the script is enough; if you want to preview a change before it happens and undo it afterwards, the module is the different proposition. ## Conclusion Adopt TermsrvPatcher if you need a second or third Remote Desktop session on a single Windows 10 or 11 workstation and you are prepared to patch termsrv.dll by hand and re-apply the patch after updates. Do not adopt it on shared or multi-tenant machines where a non-administrator could replace the script, and do not adopt it when an undo path or an audit trail matters. Before the first run, check your exact Windows build against the supported versions list, keep a copy of the original termsrv.dll, and confirm that TermsrvPatcher.ps1 sits in a location writable only by administrators such as C:\ before importing TermsrvPatcherScheduledTask.xml. ## FAQ ### Does TermsrvPatcher work on Windows 11 26H2? The README header states that Windows 11 26H2 support was added, and the supported Terminal Services versions list includes Windows 11 22H2, 23H2, 24H2, 25H2 and 26H2 alongside Windows 10 and Windows 7 Pro SP1 64-bit. ### What does TermsrvPatcher actually change on the system? It patches termsrv.dll so that multiple remote users can open an RDP session on a non-Windows Server computer. The README does not document the byte pattern or offset inside the DLL that gets rewritten. ### How is the patch re-applied after a Windows update? The repository ships TermsrvPatcherScheduledTask.xml, and the README describes importing it into Task Scheduler so the script runs again after updates. The default script path in that task is C:\TermsrvPatcher.ps1, and the task runs as SYSTEM with HighestAvailable privileges. ## Sources - [fabianosrc/TermsrvPatcher on GitHub](https://github.com/fabianosrc/TermsrvPatcher) - [Issues](https://github.com/fabianosrc/TermsrvPatcher/issues) - [License: MIT](https://github.com/fabianosrc/TermsrvPatcher/blob/main/LICENSE) - [README](https://github.com/fabianosrc/TermsrvPatcher/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/fabianosrc-termsrvpatcher