• rdp mystery

    From T@T@invalid.invalid to alt.comp.os.windows-11 on Wed Apr 22 18:52:21 2026
    From Newsgroup: alt.comp.os.windows-11

    Hi All,

    Client: W11 w5H2

    RDP server: W11 24H2, then upgraded to 25H2

    I have a customer that used RDP (mstsc) to connect to
    his work computer.

    Something is constant turning off his office computer's
    RDP enable in
    sysdm.cpl
    Remote tab
    Remote Desktop

    Very easy to fix, but what in the world is constantly
    turning it off?

    Yours in Confusion,
    -T
    --- Synchronet 3.21f-Linux NewsLink 1.2
  • From JJ@jj4public@gmail.com to alt.comp.os.windows-11 on Thu Apr 23 09:37:08 2026
    From Newsgroup: alt.comp.os.windows-11

    On Wed, 22 Apr 2026 18:52:21 -0700, T wrote:
    Hi All,

    Client: W11 w5H2

    RDP server: W11 24H2, then upgraded to 25H2

    I have a customer that used RDP (mstsc) to connect to
    his work computer.

    Something is constant turning off his office computer's
    RDP enable in
    sysdm.cpl
    Remote tab
    Remote Desktop

    Very easy to fix, but what in the world is constantly
    turning it off?

    Yours in Confusion,
    -T

    Probably a third party system "optimizer" tool.
    Tool like that always bite its owner if used blindly.
    --- Synchronet 3.21f-Linux NewsLink 1.2
  • From VanguardLH@V@nguard.LH to alt.comp.os.windows-11 on Thu Apr 23 00:36:51 2026
    From Newsgroup: alt.comp.os.windows-11

    T <T@invalid.invalid> wrote:

    Hi All,

    Client: W11 w5H2

    RDP server: W11 24H2, then upgraded to 25H2

    I have a customer that used RDP (mstsc) to connect to
    his work computer.

    Something is constant turning off his office computer's
    RDP enable in
    sysdm.cpl
    Remote tab
    Remote Desktop

    Very easy to fix, but what in the world is constantly
    turning it off?

    Yours in Confusion,
    -T

    Leaving RDP connections alive when not in use was a no-no at my old
    employer. There was a limit of just 2 concurrent connections to the RDP
    server (we didn't have a license for more connects). Actually up to 3 concurrent connects were allowed, but one was an admin-only connect
    specially used to manage the other connections -- like killing off the
    dead connects to allow other users to use the same RDP server. If the
    user leaves up the RDP connection when they are gone, and that host
    needs access to more than just that one user, we had to use the admin
    session to kill off the dead connects. It was ridiculous trying to find
    the offending host that left up the RDP connection since the server was
    at a different physical location. That's when we discovered the admin
    session. I don't know if your customers have local admins keen on using
    RDP to know about managing the RDP sessions (killing off the dead ones).

    The above would not be an issue if the remote host to which you using is RDP'ing is his assigned host, and NO ONE ELSE is allowed remote access
    to it. Since it seems you are discussing a company/corporate host,
    seems no employee would own or have sole access to the host which is
    merely assigned to him.

    If your user is connecting from home to a host in his employer's
    network, you sure the firewall isn't configured to kill idle connects?
    For company resources exposed to external access, and without a lot more security than RDP affords, seems appropriate a corporate firewall should
    kill dead connects.

    As I recall, there was a timeout on dead sessions in RDP, but could also
    be configured for no timeout hence the need above to abort dead
    connects. See:

    https://learn.microsoft.com/en-us/answers/questions/2188302/remote-desktop-how-to-increase-lock-timeout
    https://woshub.com/remote-desktop-session-time-limit/

    Note that a locked (timed out) session does not get the connection
    terminated, just unusable until unlocked by the user (owner) of the RDP session, or by using the admin RDP session. The connection may get
    locked after just 5 to 30 minutes, or whatever is the idle timeout
    configured for the RDP server, but the RDP session could survive for
    hours, and why we had to use the admin RDP session to kill the locked or
    dead sessions. Too many users would walk away from their workstations
    while leaving the RDP session active, only 2 where allowed at the same
    time, and the remote RDP host was a shared resource. Lazy users were
    blocking use of a shared resource.

    Even if this user has sole access to the remote host to which RDPs,
    there is a session lockout timer to prevent malicious use when the user
    has left the RDP session unattended. It's a security feature.
    --- Synchronet 3.21f-Linux NewsLink 1.2
  • From Ammammata@ammammata@tiscali.it to alt.comp.os.windows-11 on Thu Apr 23 08:23:11 2026
    From Newsgroup: alt.comp.os.windows-11

    VanguardLH wrote on 23/04/2026 :
    Actually up to 3
    concurrent connects were allowed, but one was an admin-only connect

    give more details, please
    --
    /-\ /\/\ /\/\ /-\ /\/\ /\/\ /-\ T /-\
    -=- -=- -=- -=- -=- -=- -=- -=- - -=-
    ........... [ al lavoro ] ...........
    -.-. .... . ... .. ...- .. -. -.-. .- --- -.-. .... . ... .. .--. . .-.
    -.. .- ..-. --- .-. --.. .- - --- .-. --- . .--- ..- ...- . -- . .-.
    -.. .-
    --- Synchronet 3.21f-Linux NewsLink 1.2
  • From T@T@invalid.invalid to alt.comp.os.windows-11 on Thu Apr 23 00:12:15 2026
    From Newsgroup: alt.comp.os.windows-11

    On 4/22/26 23:23, Ammammata wrote:
    VanguardLH wrote on 23/04/2026 :
    Actually up to 3
    concurrent connects were allowed, but one was an admin-only connect

    Hi Ammammata,

    VanguardLH did not realize

    1) I have him kill filed

    2) this is a W11 workstation acting like an
    RDP server. He is thinking Windows Server.
    Workstation only allows one connection at
    a time, admin or otherwise.

    Any computer can act as a server or a client
    or both depending on what you are doing with
    it. Obviously "Windows Server" had more
    server toys.


    give more details, please


    This W10, W11, Mac OS, Fedora clients connecting
    (one at a time) to a Windows 11 Pro Workstation
    through RDP (mstsc).

    Something on the W11 RDP server is flipping off
    the enable part of RDP:

    https://ibb.co/KjHrH2Wt

    -T


    --- Synchronet 3.21f-Linux NewsLink 1.2
  • From VanguardLH@V@nguard.LH to alt.comp.os.windows-11 on Thu Apr 23 04:36:37 2026
    From Newsgroup: alt.comp.os.windows-11

    T <T@invalid.invalid> wrote:

    On 4/22/26 23:23, Ammammata wrote:
    VanguardLH wrote on 23/04/2026 :
    Actually up to 3
    concurrent connects were allowed, but one was an admin-only connect

    Hi Ammammata,

    VanguardLH did not realize

    1) I have him kill filed

    2) this is a W11 workstation acting like an
    RDP server. He is thinking Windows Server.
    Workstation only allows one connection at
    a time, admin or otherwise.

    Any computer can act as a server or a client
    or both depending on what you are doing with
    it. Obviously "Windows Server" had more
    server toys.

    give more details, please

    This W10, W11, Mac OS, Fedora clients connecting
    (one at a time) to a Windows 11 Pro Workstation
    through RDP (mstsc).

    Something on the W11 RDP server is flipping off
    the enable part of RDP:

    https://ibb.co/KjHrH2Wt

    -T

    Even if workstation editions of Windows 11 (Home and Pro) allow only 1 connection at a time, the user could still leave his computer with an
    active session thereby blocking anyone else from RDP'ing to that host.
    Are the RDP policy settings unavailable or ignored on workstations, and
    only effective on server editions of Windows?

    Pro has gpedit.msc for the policy editor. Home doesn't have a policy
    editor, but all policies are registry entries. I recall Microsoft had
    an Excel spreadsheet of all the policies, and the matching registry
    entry for each. So, you could define the policy using regedit. Or
    maybe someone published an article, or posted in a forum, what are the
    registry entries for the RDP timeout policies.

    You sure RDP on workstations doesn't have an admin mode session (mstsc
    /admin) in addition to a current user session? From reports by others
    trying to discern if an RDP session consumed a license, they looked into
    the rd license manager. If a user consumes a license, the connection
    was NOT made using the /admin switch.

    https://v2cloud.com/blog/how-to-open-rdp-sessions-using-mstsc-admin
    "Using RDP sessions with admin rights gives you full control without
    consuming a Client Access License (CAL), making it a cost-effective and practical solution for remote management."

    However, it does mention "server", so maybe you cannot get admin RDP
    sessions on the remote host that is a workstation.

    I don't use RDP on any of my workstations (as a client or server), so I
    cannot test at home, and I'm not putzing with my employer's hosts,
    especially those that are not in our QA group (all of which are busy
    almost all the time all day long). Use across separate networks, like
    from home to work, or home to some other home, require punching holes in
    the firewalls (in Windows, and in the cable modem), like allowing
    unsolicited inbound connections on port 3389.

    When your user has an active (whether locked out or not) RDP session,
    you cannot use "mstsc /admin" (on another host) in an admin command
    shell to get another connection to the remote RDP host?

    While you were thinking a server edition of Windows was needed for
    multiple concurrent RDP sessions, or for 1 user RDP session and 1 admin
    RDP session, I'm wondering if your hosts are running the Pro edition of Windows.

    https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remotepc/remote-desktop-supported-config#supported-pcs

    That lists the Pro editions, not the Home editions. Alas, Microsoft
    doesn't date stamp most of their articles, so no way to know how old is
    this article as to whether it might be out of date, or not. On my
    Windows 10 Home edition desktop PC, when I go to Windows settings ->
    System -> Remote Desktop, it says "Your Home edition of Windows doesn't
    support Remote Desktop". Possibly Windows 11 Home got included, but the
    above article doesn't list Windows 11 Home. Must be your user's hosts
    are Pro editions, but your mention Pro for only "Windows 10" and
    "Windows 11" for clients connecting to a "Windows 11 Pro" host. Not
    sure non-Pro to Pro is a supported configuration.

    I'd also check the remote services. Run services.msc, and look at:

    Remote Access Connection Manager (Auto, Running)
    Remote Desktop Configuration (Manual)
    Remote Desktop Services (Manual)

    Since the first one is set to Automatic startup (on Windows startup), it
    should be running. The others are set to Manual startup which some
    caller process wanted to use those services, and should not be running
    until then.

    https://www.tenforums.com/tutorials/92433-enable-disable-remote-desktop-connections-windows-10-pc.html

    Option 5 there mentions a registry setting for a policy that would
    disable RDP, so I'd check that after you find RDP got disabled.

    As I mentioned using RDP requires punching a hole in a firewall on the
    remote host (Windows 11 Pro, in your case) for inbound *unsolicited* connections on port 3389 if using the default RDP port, and possibly a
    redirect to just the one "server" host at the destination to which the
    inbound connect gets redirected, and possibly allow only one IP address
    to get through the redirect hole in the firewall(s)? I'd add the IP
    address if it was static at the client host to block anyone else from
    sneaking through the firewall rule. Some folks report that defining an
    Allow rule on port 3389 with a specific IP doesn't work as they can
    still get through port 3389 for other hosts with different IPs. They
    suggest first defining a Block rule (deny all) on port 3389 followed by
    an Allow rule on port 3389 for just the IP address of the authorized
    host; however, that won't work if the client host is getting a dynamic
    IP address. The hole has to get punched in all firewalls between your
    client and server RDP hosts, like in Windows' firewall, and a firewall
    in your cable/modem or other WAN-side device.

    For the reasons explained in the following article, RDP'ing from home to
    work often leaves the corporate network vulnerable to malicious attack.
    Most time when reading about RDP, the suggestion is to change client and
    server endpoint hosts for RDP to use a different port. Even TeamViewer,
    which is easier to use, is more secure.

    https://jumpcloud.com/blog/rdp-network-port

    When someone is at the client endpoint host trying to use RDP, and you
    don't see an inbound firewall rule on the server endpoint host to allow unsolicited connects through port 3389, is there someone that can be at
    the remote host (Windows 11 Pro) to respond to the firewall prompt
    asking if it should create an inbound rule?

    While you mention the user does get an RDP session, but it times out or
    becomes unusable, it's possible with all the cleanup tools or scripts
    that the firewall rules are getting deleteted or modified. For RDP to
    work, you have to get through the WAN device (cable modem) firewall and
    the Windows firewall where RDP is listening as a server. If the setting
    for enabling/disabling RDP is changing as you mention, maybe something
    else is changing, too, like policies or firewall rules.
    --- Synchronet 3.21f-Linux NewsLink 1.2
  • From rbowman@bowman@montana.com to alt.comp.os.windows-11 on Thu Apr 23 23:32:04 2026
    From Newsgroup: alt.comp.os.windows-11

    On Wed, 22 Apr 2026 18:52:21 -0700, T wrote:

    Very easy to fix, but what in the world is constantly turning it off?

    New group policy?
    --- Synchronet 3.21f-Linux NewsLink 1.2
  • From T@T@invalid.invalid to alt.comp.os.windows-11 on Thu Apr 23 17:27:32 2026
    From Newsgroup: alt.comp.os.windows-11

    On 4/23/26 16:32, rbowman wrote:
    On Wed, 22 Apr 2026 18:52:21 -0700, T wrote:

    Very easy to fix, but what in the world is constantly turning it off?

    New group policy?


    It sure smells like that, but nothing has changed in gp for over
    a year that I know of.
    --- Synchronet 3.21f-Linux NewsLink 1.2