The IIS Server Error Log Timer_ConnectionIdle causes the server to be inaccessible,

The IIS Server Error Log Timer_ConnectionIdle causes the server to be inaccessible,
Description: The Error means The connection with the server has been terminated.
Problem description: this error is caused by server connection interruption.

If you check out the C: "Windows" system32 "LogFiles" HTTPERR "httperr *. log files on the distribution server, you'll likely see either Timer_MinBytesPerSecond errors or Timer_ConnectionIdle errors. these are caused by IIS 'default settings, contained within its metabase, which define the minimum traffic flow rate for a connection to be kept alive and the maximum idle time allowed before a connection is dropped. for some reason, SUS servers seem to take their good old time while downloading updates, and these parameters are exceeded and the distribution server drops 'em.

This problem is caused by improper default settings of IIS in some applications.

1) From IIS Manager, right click on the Internet Information Server (IIS) Manager root level folder and go to Properties. Check the box to enable direct metabase editing. Click OK.
1) Open the Internet Information Service (IIS) manager, right-click "my computer"-properties, and select "allow directly edit configuration database (N)". OK.
2) Open the C: "Windows" system32 "inetsrv" MetaBase. xml file in Notepad. do a search for "MinFileBytesPerSec ". change the setting for MinFileBytesPerSec from 240 to 0. do another search, this time for "ConnectionTimeout" to be 600. save changes and exit.
2) edit the C: "Windows" system32 "inetsrv" MetaBase. xml file, change the value of MinFileBytesPerSec from 240 to 0, and set ConnectionTimeout to 600.
3) Restart the IIS Admin service to effect the changes.
3) restart the IIS service.

Alternative Method

If you install the latest for Windows Server 2003, the network connection may be too slow after ServicePack. Network tracking is used to determine whether the customer receives the response and the latency in retransmission data packets. To fix this problem, reduce or disable IIS 6.0 to prevent the MinFileBytesPerSec attribute from closing the slow client connection early.

Comments and experiences of other netizens on the solution:

I think there are problems with these solutions. If the vehicle anti-theft alarms often sound, the correct solution is to find out who often hits your car or put the car in a safer place, rather than turning off the alarm.
HTTP services occupy TCP connections, while TCP connections occupy system resources, and IIS also needs to allocate resources for each connection. The current host can process tens of thousands of connections, which can be said to be a good software and hardware design (see C10K ). If a malicious user initiates a large number of connections through one or more machines, and does not request content (this does not require much bandwidth to attack the machine ), in this way, server resources can be greatly consumed to achieve the purpose of DOS.
Therefore, IIS needs to disable connections that are not active for a long time. This is the error of Timer_ConnectionIdle.

It turns out that attackers can intentionally send and receive content to the server and consume server resources. This can prevent the server from protecting Timer_ConnectionIdle. The corresponding IIS protection is set by MinFileBytesPerSec, the MinFileBytesPerSec attribute prevents malicious or abnormal clients from consuming resources by keeping connections with the smallest amount of data. If the throughput is lower than the value set by MinFileBytesPerSec, the connection is terminated. The LOG displays the Timer_MinBytesPerSecond error (some Timer_MinBytesPerSecond errors are caused by the http. sys error of windows 2003. The solution is to add the latest ServicePack.