As an acting network administrator, I know that the word vacation is a synonym for trouble. Thus, when I got back from a short vacation, I wasn't too surprised that our primary Windows NT server was losing client connections. Periodically throughout the day, all the connected client systems lost their connection to the NT server, and the server mysteriously disappeared from the Network Neighborhood. Checking the system event log on the NT server revealed the ambiguous message that one of the other networked systems had forced a master browser election — the result of losing the NT server connection. However, the log presented no diagnostic messages that revealed the cause of the problem. To reconnect the client systems, I brought up the Network Neighborhood on the server.
A colleague suggested that the master browser might be the culprit, so I changed a Registry entry to make sure that the NT server was the master browser. Unfortunately, the problem recurred after a couple of hours.
I began looking for more obscure solutions. I checked the log of changes I had made to the network before I left for vacation and found two suspicious entries. I had installed a new networking application on the server and more memory to handle the new application. I had also set up another networked system as an Internet router. Because the NT server was the system having the problems, I checked it first.
Going over the TCP/IP networking configuration, I found that the software application had changed my TCP/IP subnet mask from 255.255.255.0 to 255.255.0.0. All my lost connections were local systems, so I didn't see how the subnet mask change would affect the problem. Just in case, I changed the subnet mask to its original value and rebooted the server. But all the client connections dropped again.
Next, I went to the NT system that was acting as a router and restored its previous configuration — essentially turning off the option to forward IP packets. In half an hour, I learned that this change was of no avail.
The only component I hadn't checked was the memory. The added memory had been working fine before my vacation, and the memory check during the system boot gave no hint of any problems. Because the memory was the only item left on my short list, it had to go.
When I moved into the computer room, I noticed that the server's standby mode was activated and the server's monitor had gone into shutdown mode. This activity wasn't unusual; but I was suspicious, so I checked the connection of the network node where I was sitting. The node was still connected. After 20 minutes, I rechecked the connection. It was down.
I pressed the space bar on the server, which broke the standby condition, and the server's monitor jumped back to life. I rechecked the connection at the network node. Much to my surprise, I found that it was up. To make sure, I repeated this sequence. After 15 minutes of system inactivity, I watched the server's monitor power down. After another 20 minutes, the connection was down. When I moved the mouse to break standby mode, the monitor lit up, and the client connection was up. I had originally thought that using the Network Neighborhood restored the connection, but any activity that broke standby mode restored the connection.
After bringing the system down, I ran the BIOS setup program and checked the system's Standby and Suspend settings. In any system where the BIOS supports Advanced Power Management, the Standby option powers down the monitor, and the Suspend option shuts down the system. Sure enough, someone had enabled the Suspend option and configured it to kick in 20 minutes after the system goes into Standby mode. I must have inadvertently changed this setting when I added the memory and didn't notice the problem then because I was using the server a lot that week. After disabling Suspend and rebooting the server, I had fixed my lost connections problem.
