IIS Informant: Solving the Mystery of the Missing .gif Files

I recently installed a new IIS 5.0 server that's a duplicate for our primary IIS server. However, when I access the Web site on the duplicate server, the server doesn't deliver .gif files. Instead, Microsoft Internet Explorer (IE) times out waiting for the main menu to display. I reinstalled IIS 5.0 and its service packs on the duplicate server, but the problem still occurs. However, the duplicate server successfully delivers a simple Active Server Pages (ASP) file that shows the time of day. The ISP insists that the problem lies on my end, but I haven't received any error messages in the duplicate server's Event Viewer log or encountered any other symptoms that would indicate a problem with the server. How do I troubleshoot this problem?

This problem can have many possible causes. Because you have another server that's successfully running the same software, you know that the software can work if it's configured properly. Because the duplicate server doesn't return an error message and delivers an ASP file, you know that the server is in reasonably good health overall. However, you need to conclusively determine whether the server is working correctly.

GIF files are static content and thereby delivered in process. As a result, setting IIS 5.0's Application Protection to Medium (Pooled) or High (Isolated) on the Home Directory tab of the Web site's Properties page isn't a viable diagnostic test. Instead, back up your metabase, then try to load a .gif file directly in a URL (e.g., http://servername/sample.gif) from a remote system. If the URL fails, clearly something is wrong. To determine what's wrong, work from the inside out—that is, look for possible causes of the problem inside the server before you look for possible causes outside the server.

First, determine whether IIS is sending the .gif file. One approach is to use Network Monitor. Connect your problem IIS server and another computer from which you will run Network Monitor to a hub (not a switch). Then, from the monitoring computer, launch IE and try to load .gif files located on the problem IIS server. The resulting capture of the network traffic will provide definitive proof that your server is sending or isn't sending the requested .gif file. If IIS sent the .gif file, tell your ISP representative that you're going to bill the ISP for your time troubleshooting its network problems. You proved that IIS is sending files, but the ISP isn't sending them for some reason.

If the Network Monitor test is difficult to conduct in your environment because of the network architecture, you can inspect the IIS log instead. From a remote system, try to load a .gif file in a URL, then inspect the IIS log files on the problem Web server. Look for an entry with the result code of 200, which indicates that IIS successfully sent the .gif file. If you see this result code, you should be suspicious of your hardware or the ISP. To see whether the NIC is failing, replace it and try the URL again.

Author's note: After troubleshooting the problem, the reader found that the duplicate server was sending the .gif file, so he contacted the ISP. The ISP eventually replaced its router and modem, and the .gif images started to work on the duplicate server. Although the original server and duplicate server were on the same subnet, the original server had its own router and modem, which is why the .gif files worked on one server but not the other server.