During a recent infrastructure audit, we encountered a perplexing scenario where a Windows Server 2012 R2 system would gradually lose network connectivity despite showing normal connection counts. The server would consistently hit ephemeral port exhaustion after approximately two weeks of uptime, even when monitoring tools reported only 500-1500 active connections.

# Sample PowerShell to monitor port usage
while($true) {
    $tcpStats = Get-NetTCPConnection -State Established,TimeWait | Measure-Object
    $portUsage = [math]::Round(($tcpStats.Count/65535)*100,2)
    Write-Host "[$(Get-Date)] Active ports: $($tcpStats.Count) ($portUsage%)"
    Start-Sleep -Seconds 30
}

The system exhibited several peculiar behaviors during failure states:

• Localhost resolution would revert from IPv6 (::1) to IPv4 (127.0.0.1)
• Database connectivity failures preceded by TCP/IP warnings 4227 and 4231
• Service-specific restarts (particularly mail services) temporarily resolved the issue

The root cause appears to be in how Windows handles port allocation behind the scenes. Even with proper registry tuning:

# Current registry settings we verified
reg query "HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" /v TcpTimedWaitDelay
reg query "HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" /v MaxUserPort

The system was still experiencing port starvation due to:

1. Socket handle leaks in certain network-intensive applications
2. Improper connection pooling in legacy .NET applications
3. Network driver issues with the Intel 82575EB adapter

After extensive testing, we implemented a multi-layered solution:

# PowerShell script for proactive port management
function Reset-TCPStack {
    Restart-Service -Name "Remote Access" -Force
    netsh int ipv4 reset
    netsh int ipv6 reset
    netsh winsock reset
    Write-EventLog -LogName System -Source "TCP Maintenance" -EntryType Information -EventId 1001 -Message "TCP stack reset performed"
}

# Scheduled to run daily during maintenance window
Register-ScheduledJob -Name "TCPStackReset" -ScriptBlock ${function:Reset-TCPStack} -Trigger (New-JobTrigger -Daily -At "3:00 AM")

For the Intel network adapter specifically:

• Updated to latest drivers (version 12.15.22.3 or later)
• Disabled TCP Offload Engine features
• Adjusted interrupt moderation settings

:: Batch script for NIC optimization
@echo off
set NIC="Intel(R) 82575EB Gigabit Network Connection"
powershell -command "Disable-NetAdapterLso -Name %NIC% -IPv4 -IPv6"
powershell -command "Set-NetAdapterAdvancedProperty -Name %NIC% -DisplayName 'Interrupt Moderation' -DisplayValue 'Disabled'"

Created a custom monitoring solution to track per-process port usage:

# Port usage by process breakdown
Get-NetTCPConnection | 
Where-Object {$_.State -eq "Established" -or $_.State -eq "TimeWait"} |
Group-Object OwningProcess |
ForEach-Object {
    $proc = Get-Process -Id $_.Name -ErrorAction SilentlyContinue
    [PSCustomObject]@{
        PID = $_.Name
        Process = if($proc){$proc.Name}else{"Unknown"}
        Connections = $_.Count
        Ports = ($_.Group.LocalPort | Sort-Object -Unique) -join ","
    }
} | Sort-Objects Connections -Descending | Format-Table -AutoSize

After weeks of smooth operation, your Windows Server 2012 R2 suddenly refuses database connections despite showing normal TCP connection counts. The Event Log reveals the telltale signs:

Event ID 4227: TCP/IP failed to allocate an ephemeral port
Event ID 4231: TCP/IP reached port exhaustion (global TCP port space)

Counter metrics show only ~1,500 connections via:

Get-Counter -Counter \\TCPv4\\*
Get-Counter -Counter \\TCPv6\\*
netstat -abn | find /c ":"

While most guides suggest modifying these registry values:

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
    TcpTimedWaitDelay = 30 (decimal)
    MaxUserPort = 65530 (decimal)

The real culprit often lies in TCP connection recycling behavior and NIC hardware limitations.

As noted in your updates, restarting mail services temporarily resolves the issue. This suggests SMTP connection pooling misbehavior. Modern mail servers like hMailServer or Exchange maintain persistent connections that may not properly release ports.

Try this PowerShell script to monitor SMTP-specific connections:

$smtpPorts = @(25,587,465)
Get-NetTCPConnection -State Established | 
    Where-Object { $smtpPorts -contains $_.RemotePort } |
    Measure-Object | Select-Object -ExpandProperty Count

The Intel 82575EB NIC has known issues with TCP chimney offloading. Disable these features:

netsh int tcp set global chimney=disabled
netsh int tcp set global rss=disabled

Then verify with:

netsh int tcp show global

Implement this three-layer defense:

1. Connection Recycling:

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

2. Socket Leak Prevention:

   [System.Net.ServicePointManager]::MaxServicePoints = 1000
   [System.Net.ServicePointManager]::DefaultConnectionLimit = 100
   

3. Automated Monitoring:

   $portUsage = (Get-NetTCPConnection).Count
   if ($portUsage -gt 30000) {
       Restart-Service -Name "SMTPSVC" -Force
       Write-EventLog -LogName Application -Source "PortMonitor" -EntryType Warning -EventId 5001 -Message "Forced SMTP service restart due to port usage: $portUsage"
   }
   

Remember to schedule weekly server reboots during maintenance windows until the root cause is fully resolved.