Help corner: Timeout problems when initiating an RDP session

As an IT pro, you can often learn a lot from real-world troubleshooting stories shared by colleagues. While crowdsourcing doesn’t always work as an approach to troubleshooting, may suggestions can still provide you with a few tips you can file away in your IT toolbox. Who knows? One day you might just face a situation where something you picked up from some discussion might just be the right tool for solving your own difficulty you face as you try to do your job. The value of this was brought home to me a while back when one of the readers of our popular weekly newsletter WServerNews sent us a cry for help concerning an issue he had been facing with a Windows Server Remote Desktop Services (RDS) farm belonging to a customer he worked with. The reader, a senior consultant working in California, had already tried working with Microsoft Support on the RDP session problem but to no avail. He described the issue as follows:

“When the issue arises, users attempting to initiate an RDP session are able to enter their login credentials no problem, but the session just hangs on the part where the RDP client says ‘Initiating Remote Connection’ and eventually just times out saying it cannot connect. I have let this condition run overnight to see if it was temporary, but it did not appear to be. Each time this occurs, I must force a reboot of the OS and when the system reboots everything is back to normal and new RDP connections are created just fine. What’s even more perplexing is that the web-based app and some scheduled tasks set up under the Windows Scheduler appear to continue to work fine even during the periods where the server will not create an RDP session from the client. I don’t believe the server itself is hung, as these other tasks work, and work the same as normal in terms of performance. But whatever is preventing the establishment of the new RDP session has so far always required a reboot. We have been unable to find anything conclusive in the Terminal Services Event Logs.”

I redirected his request for help to our WServerNews community and received a flood of responses in return, and I’ve included a sampling of them here in this article in case any of you reading this work with RDS in your environment. So file these away in your brain as possible tips you can use if you should face a similar problem sometime in the future.

Are there enough server memory resources?

Bill, who is president of a software and consulting company, recommended that he “Check server memory resources. Specifically, the Paged Pool and the Non-Paged Pool. My own Win 2008 server has been leaking nonpaged pool memory of late, and when it gets to around 650MB in size, some functions fail outright, requiring a reboot to fix it. I’ve even written a nightly VBScript process that checks the nonpaged pool size every night, and when it tops 450MB, it sends me an email so that I can proactively reboot the server the next morning to avoid a mid-day outage.”

Are there still available connections?

RDP session
Pixabay

A reader named Jackie offered a different take on the RDP session problem by suggesting two things to look at. “Check how many simultaneous RDP connections the server allows — you might have hit the limit. Also, when you get to the point where the server is hanging on more RDP connections, check to see who is already connected. You might have abandoned sessions that never disconnected, service accounts that are logged on instead of actual users, etc., using up the available connections. The fact that only a forced reboot is the only way to resolve the situation leads me to suspect this scenario.”

Have you tried doing any of these?

Another reader named Matt who lives in Australia offered a bunch of possible steps to try for resolving the issue:

“That guy with the RDP session connection problem may like to try these ideas:

  • Use a port other than 3389 for RDP.
  • Get the clients having trouble connecting, to ‘disconnect’ all network drives/connections within Explorer prior to attempting to connect.
  • Get the clients having trouble connecting, to ‘remove’ all network printers prior to attempting to connect.
  • Don’t run any login or terminal server login scripts.
  • Make sure print drivers for all home-based/user owned printers are installed on the terminal server.”

Matt also added that “In my experience, I’ve found that when logins take a while to complete, it’s due to name resolution problems or the machine looking for network resources that no longer exist such as shared folders, printers, etc.”

Could it be a name resolution problem?

RDP session
Shutterstock

Kevin, an IT administrator in Milwaukee, indicated he had been facing a similar problem and thought that DNS name resolution issues might have something to do with why it was happening. He also offered a possible workaround for the problem. “I had/have the same problem when connecting from home. I am able to VPN into my company’s network just fine, but when trying to RDP to my PC, it times out. I had no trouble earlier several months ago. I brought my home PC to work and connected it to our router with external IP addresses. I was able to connect both VPN and RDP. The difference was I use a hard connection (with a cable) and at home, I used a USB wireless connection. I went back home and tried again with wireless with no luck until I used my internal IP address of my PC instead of the DNS name or full computer name and I was able to connect. Somehow my wireless connection would not recognize DNS or full computer name. Anyway, no real reason or solution here, but it was a workaround for me.”

Not quite the same issue but could be related

And here is what William, a manager of information technology for a manufacturing company in Massachusetts, shared. “Being a similar company, multiple RDS servers and many users, we have not experienced exactly what was described, however we periodically need to correct for the following situations. Some of these, in specific circumstances, could potentially result in a similar occurrence. First, we have lost connection to our Terminal Server Licensing server. As a result, while the session is being initiated, a license cannot be acquired, and the session would typically be reset. Second, a very common occurrence is the loading of a large profile. Since this is coming from a network share, the user can sit for an extended period while the files are copied. If the share gets disconnected midstream, I cannot even speculate what the logon session might experience. Finally, there have been numerous occurrences here where profile folder (on the RDS platform {c:\users}) becomes cluttered with multiple profiles for the same user. The folders are named with numeric extensions to allow the users to at least establish the connection. If the file system is so full that it runs out of space, anything could happen.”

The RDP session problem is (sort of) resolved

Unfortunately, not every IT problem ends up having a clean and tidy resolution. While the original reader greatly appreciated these suggestions from our newsletter readers, none of them seemed to resolve the underlying issue he was facing. But a few weeks later he was able to get a lead on what might have been causing his RDP session connection problem. “In drilling into this one more, it appears as though this may be related to the AV software I am using. I eventually found this post after finally discovering a chronological association between the error 4005 in the Event Viewer and the login issue. When I read this post, it was as if I had written much of it. Only after reading the associated threads down to the bottom did I discover that there was some kind of issue potentially with the Webroot AV software. I then contacted their support and received a special build of the client/agent to install and test. I was escalated to senior support at Webroot and had them confirm that my anecdotal observation is correct in that there is a correlation between the number of users on the system (user sessions) and the frequency of the occurrence. Just this morning they sent me an older build to test to see if the issue ‘goes away’ and then if it does, they want to apply the next build and see if it reappears…”

The story ends there as we moved on to other things in our newsletter, but it highlights some of the challenges we face daily as IT pros because of the complexity of the environments we have to manage in the real world. My hope, however, is that you won’t face such frustrating challenges too frequently in your IT profession, and building up the IT toolbox in your brain is still the best way of being ready to face such challenges should they arise.

Got an IT issue you’re facing?

Maybe you don’t have an RDS farm deployed as part of your company’s infrastructure, but perhaps you’re facing some IT issue that you aren’t able to resolve. What can you do? Well besides posting to vendor and third-party forums asking for help, why not subscribe to our WServerNews newsletter and then send us a description of the problem you’re facing? We can feature your problem in the Ask Our Readers section of an upcoming issue of WServerNews, and with our half-million subscribers, you’re bound to get at least a few good suggestions, which we’ll publish in a follow-up issue of our newsletter. WServerNews is a great resource both for sharing your own IT expertise and asking for help from other IT pros, so why not take advantage of it today by subscribing to WServerNews.

Featured image: Shutterstock

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top