Randomly users disconnections from RDS

Question

Hello everyone,

We've build new RDS-Farm:

1) RDCB+RDLS+RDS WebAccess
2) Session-Host
3) Session-Host
4) Session-Host
5) Session-Host

we getting strange issue, users randomly disconnected from session for one second and then they reconnect again
I did deep research and didn't find much information only some related events.

there is no network related issue and firewall also

Does anyone has any idea what it's could be?

Answer 1

Hello @Arnold MIshaev

Thank you for the file provided previously.

Now I wonder if you can review the steps below please:

• Configure keep-alive connection interval group policy(Configure keep-alive connection interval)
• gpupdate /force (From CMD terminal)

Furthermore, I was thinking of confirming the routing path for this client session by running the next commands(MTU Path discovery,Port listening or exhaustation,Fragmentation):

C:\Users\user01\Downloads\platform-tools>ping 8.8.8.8  
      
        Pinging 8.8.8.8 with 1450 bytes of data:  
        Reply from 8.8.8.8: bytes=68 (sent 1450) time=60ms TTL=113  
        Reply from 8.8.8.8: bytes=68 (sent 1450) time=61ms TTL=113  
        Reply from 8.8.8.8: bytes=68 (sent 1450) time=60ms TTL=113  
        Reply from 8.8.8.8: bytes=68 (sent 1450) time=59ms TTL=113  
          
        Ping statistics for 8.8.8.8:  
            Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),  
        Approximate round trip times in milli-seconds:  
            Minimum = 59ms, Maximum = 61ms, Average = 60ms  
      
C:\Users\user01\Downloads\platform-tools>  
  
--------------------------------------------------------------------------------------------------------------------------------  
  
  
C:\Users\user01\Downloads\platform-tools>ping 8.8.8.8 -l  1450 -f  
      
    Pinging 8.8.8.8 with 1450 bytes of data:  
    Reply from 8.8.8.8: bytes=68 (sent 1450) time=66ms TTL=113  
    Reply from 8.8.8.8: bytes=68 (sent 1450) time=63ms TTL=113  
    Reply from 8.8.8.8: bytes=68 (sent 1450) time=61ms TTL=113  
    Reply from 8.8.8.8: bytes=68 (sent 1450) time=59ms TTL=113  
      
    Ping statistics for 8.8.8.8:  
        Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),  
    Approximate round trip times in milli-seconds:  
        Minimum = 59ms, Maximum = 66ms, Average = 62ms  
      
C:\Users\user01\Downloads\platform-tools>  
  
  
--------------------------------------------------------------------------------------------------------------------------------  
  
  
C:\Users\user01\Downloads\platform-tools>ping 8.8.8.8 -l  1500 -f  
      
    Pinging 8.8.8.8 with 1500 bytes of data:  
    Packet needs to be fragmented but DF set.  
    Packet needs to be fragmented but DF set.  
    Packet needs to be fragmented but DF set.  
    Packet needs to be fragmented but DF set.  
      
    Ping statistics for 8.8.8.8:  
        Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),  
      
C:\Users\user01\Downloads\platform-tools>  
  
--------------------------------------------------------------------------------------------------------------------------------  
  
C:\Users\user01\Downloads\platform-tools>netsh int ipv4 show dynamicport tcp  
  
Protocol tcp Dynamic Port Range  
---------------------------------  
Start Port      : 49152  
Number of Ports : 16384  
  
  
C:\Users\user01\Downloads\platform-tools>  
  
  
--------------------------------------------------------------------------------------------------------------------------------  
  
C:\Users\user01\Downloads\platform-tools>netsh int ipv4 show dynamicport udp  
  
Protocol udp Dynamic Port Range  
---------------------------------  
Start Port      : 49152  
Number of Ports : 16384  
  
  
C:\Users\user01\Downloads\platform-tools>  
  
--------------------------------------------------------------------------------------------------------------------------------  
  
C:\Users\user01\Downloads\platform-tools>netsh interface ipv4 show interfaces  
  
Idx     Met         MTU          State                Name  
---  ----------  ----------  ------------  ---------------------------  
  1          75  4294967295  connected     Loopback Pseudo-Interface 1  
 11          50        1500  connected     Wi-Fi  
 22           5        1500  disconnected  Ethernet  
 19          25        1500  disconnected  Local Area Connection* 1  
  5          25        1500  disconnected  Local Area Connection* 2  
 21          25        1500  connected     VirtualBox Host-Only Network  
  
  
C:\Users\user01\Downloads\platform-tools>  
  
--------------------------------------------------------------------------------------------------------------------------------  
  
C:\Users\user01\Downloads>mturoute google.com -x -d  
* ICMP Fragmentation is not permitted. *  
* Speed optimization is enabled. *  
* Maximum payload is 10000 bytes. *  
+ ICMP payload of 1472 bytes succeeded.  
- ICMP payload of 1473 bytes is too big.  
Path MTU: 1500 bytes.  
  
C:\Users\user01\Downloads>  

Besides that, Please also check if there is any Network session stuck at the process ID level as well... If you find that any session is not being release so proceed to kill it by the PID. Finally, You might check if automatic metric option is enabled on the server too.

Looking forward to your feedback,

Cheers,

Please "Accept the answer" if the information helped you. This will help us and others in the community as well.

Answer 2

Hello @risolis

Thanks for your participant in this discussion.

1) The routing path seems to go smoothly even perfect
2) I didn't try yet configure "keep-alive connection interval" - i don't understand how it's suppose to help we don't have issue with session redirection, when the user got reconnect message he redirecting to same session after one second
3) there isn't network sessions stuck
4) automatic metric is enabled on servers

As i said previously we find the solution\workaround on end-clients, but client want to find a solution on server side
The work around is:
https://admx.help/?Category=Windows_10_2016&Policy=Microsoft.Policies.TerminalServer::TS_CLIENT_TURN_OFF_UDP

Answer 3

Hello @risolis

I've configured "keep-alive connection interval" and it's doesn't help

Answer 4

Hi @Arnold MIshaev again : )

There is one remaining step to check or perform on this case scenario.

Some days ago I was assisting on another post and after a deep troubleshooting steps, I did recall that DNS delay can be a huge issue on some scenarios...

So, I found this info on internet after reading more details about your set up as well as for me this can be very relevant or might fit into your issue and let me paste it below:

According to this theory, Microsoft's RDS Gateway (unfortunately) exposes the RDS Session host's computer name (including its .local extension) to the remote/external RDP client, and therefore the 60 second delay is caused by the remote/external RDP client taking time to look for the SSL certificate for the session host, which doesn't exist.

Having said that, you can double check if this is the issue or putting additional DNS server, you can prevent this from happening.

Having a good one.

Cheers!

Answer 5

Hello @Arnold MIshaev

Thanks for your patience on this one.

I would think that I am going to split my response into 2 segments for better understanding. So, I would give you the step for the solution/workaround answer first : )

As a friendly reminder, before changing the listening port for this to worked.... Please refer to the next article, to double-check you will not break up any existing working session service on the server as well as just remind one relevant detail that is shown on it.

URL >>> https://www.meridianoutpost.com/resources/articles/well-known-tcpip-ports.php

Ports 0 to 1023 are Well-Known Ports.
Ports 1024 to 49151 are Registered Ports (often registered by a software developer to designate a particular port for their application)
Ports 49152 to 65535 are Public Ports.

Those are the steps given from an official document from MS and it is just for you to be sure that you will not provoke any downtime on your environment. Please read below:

• Remote Desktop server listener availability
• The listener component runs on the Remote Desktop server and is responsible for listening for and accepting new Remote Desktop Protocol (RDP) client connections, thereby allowing users to establish new remote sessions on the Remote Desktop server. There is a listener for each Remote Desktop Services connection that exists on the Remote Desktop server. Connections can be created and configured by using the Remote Desktop Services Configuration tool.
• • To perform these tasks, refer to the following sections.
• • Determine which application is using the same port as RDP
• You can run the netstat tool to determine whether port 3389 (or the assigned RDP port) is being used by another application on the Remote Desktop server:
• • On the Remote Desktop server, click Start, click Run, type cmd, and then click OK.
• At the command prompt, type netstat -a -o and then press Enter.
• Look for an entry for TCP port 3389 (or the assigned RDP port) with a status of Listening. This indicates another application is using this port. The PID (Process Identifier) of the process or service using that port appears under the PID column.
• To determine which application is using port 3389 (or the assigned RDP port), use the tasklist command-line tool along with the PID information from the netstat tool:
• • On the Remote Desktop server, click Start, click Run, type cmd, and then click OK.
• Type tasklist /svc and then press Enter.
• Look for an entry for the PID number that is associated with the port (from the netstat output). The services or processes that are associated with that PID appear on the right.
• Change the port assigned to RDP
• You should determine whether this application can use a different port. If you cannot change the application's port, you must change the port that is assigned to RDP.
• • Important
• • We recommend that you do not change the port that is assigned to RDP.
• • If you have to change the port assigned to RDP, you must change the registry. To do this, you must be a member of the local Administrators group, or you must have been granted the appropriate permissions.