Just over a year ago, I posted a blog entry which gives a 10,000 feet view of Microsoft ISA Server 2000. I haven’t done anything with ISA Server since then but over the last few days, I’ve been installing an new ISA Server 2000 array into an existing enterprise for a client.

Nothing too complicated about that – once I had secured the network interfaces and installed the ISA servers, there were just a few extra settings to configure (see getting started with ISA Server) to ensure that the new array would allow outbound traffic, but I did start to doubt myself when my test clients were receiving error 10060 connection timeouts (although the logs from the upstream firewall reported that it was letting the outbound requests pass). It transpired that there was an issue with the ISP’s network, but as anyone who has ever been in that situation will know, convincing an ISP that there is a problem their end is not always easy, and I also asked two of my colleagues to check my configuration (just in case!).

Although I installed in integrated mode (for future flexibility), my client only needed the caching functionality, so I stopped and disabled the Microsoft Firewall service. Everything seemed fine as the clients were connecting okay via HTTP, HTTPS or FTP and the upstream firewall logs reported all the client requests as coming from my proxy servers; but I wanted to be sure that the array servers were co-operating and that the cache was being populated as my test clients hit the new array.

Understanding how the client requests are processed is straightforward – by default, ISA Server maintains a log file in %programfiles%\Microsoft ISA Server\ISALogs\, which for the Microsoft Web Proxy service is named webextdyyyymmdd.txt. This file contains a whole host of information about requests received and how they were answered, including a useful field called s-object-source, which shows where the request was retrieved from (e.g. “member” for another member of the array, “inet” for the Internet or “cache” for the ISA Server cache – full details can be found in the Microsoft Internet Security and Acceleration Server Enterprise Edition product documentation). From looking at the ISA Server logs, I was confident that both servers were working, and resolving requests between one another using the cache array routing protocol (CARP) but I still wanted to check that the caches on both of the ISA Servers in the array were being populated.

Microsoft provides a useful utility with ISA Server 2000 – the ISA Server Cache Directory Tool (cachedir.exe), found on the ISA Server CD in the \support\tools\troubleshooting\ folder. Once copied to the ISA Server folder (by default, %programfiles%\Microsoft ISA Server\), this can be used to view the contents of the cache. I could see some entries in the cache on one server, but not the most recent requests, and running the tool on the other server returned an empty cache. Then I remembered that ISA server caches in memory first (by default 50% of available RAM), and only uses (slow) disk cache when the (fast) memory cache is full. The different results on each server were because I had restarted the Microsoft Web Proxy service on one server but not on the other. Once I restarted the Microsoft Web Proxy service on the second server, I could see all of the expected cache entries on disk as the memory cache is flushed to disk when the Web Proxy service is stopped. For reference, the ISA Server documentation gives an explanation of the ISA cache files.

All in all, it has been a successful implementation, if slightly protracted by the ISP issues and my stupidity around cache contents. Now I can put those issues down to experience, but I thought posting them into the blogosphere might help out some other poor soul with an ISA server to configure in a hurry.