I had this issue before with users getting an error that the exchange server is unavailable and the event logs show they have "too many sessions" open. The problem was resolved with the netsh tcpchimney disable command. That resolved it instantly for the affected users. However now I have one user who is still having this problem from time to time. I know of no way to remove her login sessions except to reboot the exchange server, and I am not going to do that for one user unless it's the president of the organization! Has anyone else encountered this problem and found a way to remove the excess login sessions? Moving her mailbox does work, but then she is without any email for about an hour. Exchange 2007 SP1 rollup 6. She has no open outlook sessions on any computer and it still shows 34 logins on the server.
Please don't suggest increasing the number of allowed sessions. All I want to know is if anyone has found a way to kick off the old "stale" sessions without rebotting the exchange server.
I already know the specific machine. Using the Exchange 2003 exchange system manager I can add the client IP address column and see what system is logging in. So I know the machine. Once again the question I have is, is there a way to kick off the stale sessions on the Exchange server without rebooting it? I don't need help finding out the problematic machine. And anyway when this happens she can't open Outlook on any machine and shutting down the "problem" machine does not disconnect the sessions from the Exchange server.
You might be able to shutdown a specific process thread using the procmon or procexp utility that is associated with a particular session open to that machine.
Another thing - if it is a specific machine, is there something different about that machine or will the problem follow her to another machine? Can you create a virtual machine for her to use and see if the problem happens in that environment? It could be a local machine problem and not a server problem. The netstat -ano command will also help you see if there are any open tcp connections to the client computer and what process is using that connection.
Unfortunately there is nothing I can do regarding this machine. As previously stated, rebooting or even turning off her machine does NOT disconnect the existing "stale" login sessions on the Exchange server. We ARE going to have her machine re-imaged to hopefully keep the problem from coming back, but in the mean time, once more, the solution I am looking for is how to kick off the stale sessions which still exist on the exchange server without having to move her mailbox or reboot the exchange server. Moving her mailbox DOES get rid of the stale sessions and I guess that is the only solution I can use at this time if nooone has any other ideas. Please remember this question is about the stale sessions which exist on the exchange server. I am not asking for help with the problematic pc which caused them. Thanks.
I am also referring to running these tools on the server side too. They are not just client oriented. They can be run to diagnose issues on servers also.
Thank you Troy. You said that command will let you see if there are any open tcp connections to the client computer. Do you know of anything that will allow me to close them if there are? That is what I am looking for. Thanks.
The challenge with this is that the same process might have multiple connections open using the same PORT on the host side. Think about the SMTP port 25. There can be multiple inbound connections on this port, so killing the SMTP service kills all of the connections. The useful part of the netstat -ano command is that it will show you the PIDs and the ports associated with client connections.
I'm not sure if a TCP reset might close the connections on both the client and the server, but it might be worth a try. A potential tool for resetting tcp connections is called HPING. You can "manufacture" lots of different packet types. Use at your own risk.
Per hping.org
hping is a command-line oriented TCP/IP packet assembler/analyzer. The interface is inspired to the ping(8) unix command, but hping isn't only able to send ICMP echo requests. It supports TCP, UDP, ICMP and RAW-IP protocols, has a traceroute mode, the ability to send files between a covered channel, and many other features.
You will need to download the Windows version and winpcap.
There are possibly some better "point and click" tools out there but they are probably more in the underground world and not easily found.
The Sysinternals procmon utility is the best one to see the process/thread connecting to the particular client computer. Unfortunately you cannot kill a process using this tool. That is where the procexp utility comes into play. It can be used to kill the process. However, like mentioned before, if there are other client connections attached to the same process, killing the process will drop all of the other client connections also.
The other stuff I mentioned above about sending TCP RST's and such are man-in-the-middle type session hijacking or hacking methods. They are not a simple solution.
If rebuilding the client computer does not fix the issue, you may need to open a support case with Microsoft or post something on the Microsoft support forums.
Troytate,
Thank you for the helpful information! You have given me plenty of routes to pursue and try and will keep these in my arsenal should this problem re-occur. The user's system was apparently also creating mutiple connections to more than just the exchange server, so we are certain the problem lies there and are hopeful the rebuild will correct it. Closing all connections associated with this client pc to any and all other systems would be acceptible, so I thank you so much for all the information!
Run get-logonstatistics command:
get-logonstatistics -id username
aldo
get-logonstatistics -id username | ft clientipaddress
This will tell you which client PC IP address has too many open sessions.
Then use the TCPView utility to view those sessions and close them.
We have the issue but have not found the cause. We do know how to close the sessions with a program called tcpview from sysinternals. you want to make sure when you use the program to "close the sessions" and not "end the process" or it'll bring down the exchange server for everyone. you can look for the ip address of the client or have the program resolve the ip to client names. works very well. we've also noticed that we only see multiple sessions on notebooks and never on desktops. we use Dell notebooks and desktops so i don't know if it occurs on other vendors.
Free Guide: Managing storage for virtual environments
Complete a brief survey to get a complimentary 70-page whitepaper featuring the best methods and solutions for your virtual environment, as well as hypervisor-specific management advice from TechTarget experts. Don’t miss out on this exclusive content!
Discuss This Question: 14  Replies