asked on

Ephemeral Port Exhaustion (IIS)

One of our 2012R2 IIS web servers starting having a weird issue with port exhaustion resulting in an error 'Tcpip 4231'. All of the outgoing ports are in use. This was a brand new server, not serving any pages, but we monitor the availability. We assumed it was related to a Windows update and began looking in to the issue; but then another server which hasn't had updates since April 2017 started having the same issue.

When I ran netstat, lo and behold every port in the range was in use by IIS. It looks like there were ~120 inbound connections but the full port range was in use. I was able to work around it temporarily by extending the range from 10000 - 65535 but this is a temporary fix.

So far as I can tell, no Windows 2008R2 IIS servers have become problematic.

I'll post more info as I have more detail, but if anyone has run across this before it would be helpful.

Thanks in advance!

ASKER CERTIFIED SOLUTION

Dan McFadden

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

Dustin Saunders

ASKER

I don't think the monitoring application is the source, we've been using that for years with no issues then suddenly I have the problem with several 2012R2 IIS servers, only one of which is less than 8 months old; which made me think a bad update might be the culprit.

It looks like KB4012219 is a probable culprit as the 3 servers now showing the problem have this patch and the highest traffic 12R2 server (which did not get that specific patch) is unaffected. KB4015553, KB4019213, KB4015550, KB4015547 and KB4019215 apparently also may roll the problem.

KB4025335 apparently has a fix for this issue, so I'll try rolling back KB4012219 one one server and applying the hotfix on the other to see if either/both resolve the problem and report back here.
https://support.microsoft.com/en-us/help/4025335/windows-8-1-windows-server-2012-r2-update-kb4025335

@Dan Thanks for your post, the additional information is helpful. Assuming the KB resolves I'll be happy to assign points for the help.

In case anyone else runs into the issue with a production server as per the article Dan shared

netsh int ipv4 set dynamicport tcp start=10000 num=55535

Open in new window

will extend the range past the default, and can be run on the fly without a reboot. Revert with:

netsh int ipv4 set dynamicport tcp start=49152 num=16384

Open in new window

Dustin Saunders

ASKER

The hotfix seems to fix the issue, no problems over the weekend since applying it and this morning.

The links you posted were helpful as well-- setting the port range and timeouts I'll leave in place and they solved the issue on the fly with no downtime.