Forum Discussion

ExceedKevin's avatar
ExceedKevin
Copper Contributor
Jul 07, 2022

Login failure from tssdis.exe on RDS server

Remote desktop server in AD environment [Windows Server 2019 standard, running RDweb, RDG, and session host, etc] periodically has service tssdis.exe (remote desktop session broker) failing to login,...
RDS
mjdavison's avatar
mjdavison
Copper Contributor
Oct 28, 2023

Hi,

 

We're in the middle of deploying NTLM blocking on our network, and this is very similar to an issue we encountered with the tssdis service during this process.

 

Brokers use kerberos correctly when first started, but would randomly switch to NTLM fallback about once a month, after which the service needed restarting.

 

It turned out that these correlate perfectly with the Connection Broker server *changing it's machine account password in AD*.

 

We've had some success with a scheduled task triggered off NetLogon event ID 5823 (the machine account password) which restarts the tssdis service.

Jo_Lambrecht's avatar
Jo_Lambrecht
Copper Contributor
Nov 03, 2023

mjdavison 

Hi, i've been struggelling with this issue for months. Can you describe in a liitle more in depth what you are doing to "(re)start" the hanging tssdis service or to prevent it from hanging.

Thank you.

 

  • rresistor's avatar
    rresistor
    Copper Contributor
    Apr 01, 2024
    Actually, there is no need to wait for password replication.

    It will be immediately replicated to PDC emulator, and all other DCs that didn't yet receive the new password will check it against PDC emulator whenever on-board passsword check failed.
  • mjdavison's avatar
    mjdavison
    Copper Contributor
    Nov 08, 2023

    Jo_Lambrecht 

     

    In our scenario, the issue was resolved by creating a scheduled task on the connection broker to restart the tssdis service, with a trigger on NETLOGON event ID 5823. (Begin the task: On an Event). This causes the connection broker service to restart whenever the machine account password was changed. We used a delay of one minute on the task so that the password change had been replicated to all DCs in the site prior to restarting the connection broker service.

     

    This has resolved the issues we were having.

     

     

     

     

  • Jo_Lambrecht's avatar
    Jo_Lambrecht
    Copper Contributor
    Nov 07, 2023

    Okay thank you for the response.
    Our situatuion is a little different, in the sence that the tssdis is "hanging". It is is still running, but it doesn't respond anymore. manualy stopping the service and restarting is the only solution that works as for now.
    So all of a sudden users start calling that they are unable to connect their vdi machines.
    If we then logon to the server, and check the state of tssdis (Remote Connection Broker Service)
    What i do then is:
    logon on to the remoteDesktop server.
    Start taskmanager -> go to DETAILS and look for TSSDIS.EXE, take note of the PID
    Then start the command prompt as adminitrator and stop the task
    Taskkill /pid /f
    (the service is now stopped)
    Start services.msc (Run -> services.msc)
    Look for "Remote Desktop Connection Broker" and start the service
    Voila, all connections are available again. (Without the need of rebooting)

    I also had the idea of using our RMM to restart the service if it was failing but "it isn't".
    I also don't know how to "poke" a service to see if it still responses?

    Any advice or help would be welcome.
    Thx.

  • Thomas_001's avatar
    Thomas_001
    Copper Contributor
    Nov 07, 2023
    Hi Jo_

    In our case the service wasn't started so we have leveraged our RMM to detected when a service is set to automatic and stopped and have it start the service, which appears to have worked around the issue for now.